Re: KJob::Capabilities and KWidgetJobTracker

On Wednesday 9 February 2011 23:29:18 Matthias Fuchs wrote: > Ok. > Would a patch -- if I find the time -- including proper Capabilities > support for the KWidgetJobTracker be welcome? Sure, I'd prefer two separate patches though if you don't mind. Regards. -- Kévin Ottens, http://ervin.ipsquad.

Re: A Qt replacement for KGlobal::ref and deref

On 09.02.11 16:01:31, Dawit A wrote: > On Wed, Feb 9, 2011 at 3:29 PM, Stephen Kelly wrote: > > Christoph Feck wrote: > > > >> On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote: > >>> KJob would be a Qt only library > >> > >> ? KJob is not a library, but a class in kdecore. > > > > I shou

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Le Wednesday 09 February 2011, Stephen Kelly a écrit : > Thiago Macieira wrote: > > Q_GLOBAL_STATIC is not public API. Don't use it. > > Would it be an option to make it public API by documenting it or is that > out of the question? I'm in favor of making it public API. Make a merge request that

Re: Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

Albert Astals Cid wrote: > KLineEdit is integrated with KDE, QLineEdit is not, we can discuss this > all you want, but not using KLineEdit gives your users a poorer user > experience. Ok. I'm not sure what that integration is and why it's not possible to have a KLineEdit that doesn't depend on K

Re: Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

A Dimecres, 9 de febrer de 2011, todd rme va escriure: > On Wed, Feb 9, 2011 at 5:25 PM, Albert Astals Cid wrote: > > Of course in an ideal world, QLineEdit would get all the KLineEdit > > features, but that's not going to happen and we know it. > > > > Albert > > Why wouldn't it happen? Discus

Re: KJob::Capabilities and KWidgetJobTracker

Am Mittwoch 09 Februar 2011, 19:59:34 schrieb Kevin Ottens: > On Wednesday 9 February 2011 19:21:26 Matthias Fuchs wrote: > > Am Mittwoch 09 Februar 2011, 19:06:41 schrieb Kevin Ottens: > > > On Wednesday 9 February 2011 18:52:57 Matthias Fuchs wrote: > > > > I wonder wether setting capabilties for

Re: Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

On Wed, Feb 9, 2011 at 5:25 PM, Albert Astals Cid wrote: > Of course in an ideal world, QLineEdit would get all the KLineEdit features, > but that's not going to happen and we know it. > > Albert Why wouldn't it happen? -Todd

Re: Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: > Albert Astals Cid wrote: > > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: > >> (Creating a new thread) > >> > >> Albert Astals Cid wrote: > >> > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: > >> >> You seem

Re: Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

Albert Astals Cid wrote: > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: >> (Creating a new thread) >> >> Albert Astals Cid wrote: >> > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: >> >> You seem to be >> >> challenging the idea that less internal dependencies in kdel

Re: Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: > (Creating a new thread) > > Albert Astals Cid wrote: > > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: > >> You seem to be > >> challenging the idea that less internal dependencies in kdelibs is a > >> good thing, but I th

Re: A Qt replacement for KGlobal::ref and deref

Dawit A wrote: > On Wed, Feb 9, 2011 at 3:29 PM, Stephen Kelly wrote: >> Christoph Feck wrote: >> >>> On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote: KJob would be a Qt only library >>> >>> ? KJob is not a library, but a class in kdecore. >> >> I should have been more clear I gue

Re: A Qt replacement for KGlobal::ref and deref

Christoph Feck wrote: > I am all for splitting KDE libraries, but I wasn't aware that we are > "already" doing it; it looked like KDE 5 material to me. Well, there is the Platform 11 sprint to get people together thinking about kdelibs modularisation. That's this summer, so we're already thinkin

Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

(Creating a new thread) Albert Astals Cid wrote: > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: >> You seem to be >> challenging the idea that less internal dependencies in kdelibs is a good >> thing, but I think that's for a separate thread anyway. > > Not sure if Christoph does

Re: A Qt replacement for KGlobal::ref and deref

On Wed, Feb 9, 2011 at 3:29 PM, Stephen Kelly wrote: > Christoph Feck wrote: > >> On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote: >>> KJob would be a Qt only library >> >> ? KJob is not a library, but a class in kdecore. > > I should have been more clear I guess. When I wrote kjob ther

Re: A Qt replacement for KGlobal::ref and deref

On Wednesday 09 February 2011 21:29:47 Stephen Kelly wrote: > Christoph Feck wrote: > > On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote: > >> KJob would be a Qt only library > > > > ? KJob is not a library, but a class in kdecore. > > I should have been more clear I guess. When I wrote

Re: A Qt replacement for KGlobal::ref and deref

A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: > You seem to be > challenging the idea that less internal dependencies in kdelibs is a good > thing, but I think that's for a separate thread anyway. Not sure if Christoph does, but i do, less internal dependencies is a bad idea as it w

Re: proposal: remove KTextEditor interface from kdelibs repository

On Wednesday 09 February 2011, Stephen Kelly wrote: > Alexander Neundorf wrote: > > On Wednesday 09 February 2011, Stephen Kelly wrote: > >> Aaron J. Seigo wrote: > >> > On Tuesday, February 1, 2011, Harri Porten wrote: > >> >> On Tue, 1 Feb 2011, Aaron J. Seigo wrote: > >> >> > we could end up wit

Re: Review Request: New KIO::http_post and KIO::StoredHttpPost APIs that accept a QIODevice as input...

> On Feb. 9, 2011, 9:59 a.m., David Faure wrote: > > kioslave/http/http.cpp, line 3809 > > > > > > Hmm, yeah, doesn't this make this all useless, if we end up making a > > QByteArray with the whole data in it anyway

Re: proposal: remove KTextEditor interface from kdelibs repository

Alexander Neundorf wrote: > On Wednesday 09 February 2011, Stephen Kelly wrote: >> Aaron J. Seigo wrote: >> > On Tuesday, February 1, 2011, Harri Porten wrote: >> >> On Tue, 1 Feb 2011, Aaron J. Seigo wrote: >> >> > we could end up with a "new kdelibs" module that contains just the >> >> > core st

Re: A Qt replacement for KGlobal::ref and deref

On Wednesday 09 February 2011, Christoph Feck wrote: > On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote: > > KJob would be a Qt only library > > ? KJob is not a library, but a class in kdecore. And kdecore only has > Qt dependencies (the other dependencies, such as libbzip or libxz, > ar

Re: A Qt replacement for KGlobal::ref and deref

Christoph Feck wrote: > On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote: >> KJob would be a Qt only library > > ? KJob is not a library, but a class in kdecore. I should have been more clear I guess. When I wrote kjob there I meant a library for asynchronous job execution containing

Re: proposal: remove KTextEditor interface from kdelibs repository

On Wednesday 09 February 2011, Stephen Kelly wrote: > Aaron J. Seigo wrote: > > On Tuesday, February 1, 2011, Harri Porten wrote: > >> On Tue, 1 Feb 2011, Aaron J. Seigo wrote: > >> > we could end up with a "new kdelibs" module that contains just the > >> > core stuff such as kdecore, kdeui, kio ..

Re: A Qt replacement for KGlobal::ref and deref

On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote: > KJob would be a Qt only library ? KJob is not a library, but a class in kdecore. And kdecore only has Qt dependencies (the other dependencies, such as libbzip or libxz, are entirely optional), so it can be used by Qt applications. Ch

A Qt replacement for KGlobal::ref and deref

Hi, KGLobal::ref and KGLobal::deref are used in KDE instead of QApplication::setQuitOnLastWindowClosed(true). The reason for this is that with the (de)ref solution * KJobs which were not finished before the last window was closed will be completed before the app exits * KRun completes its tas

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Thiago Macieira wrote: > Q_GLOBAL_STATIC is not public API. Don't use it. Would it be an option to make it public API by documenting it or is that out of the question?

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

On Wednesday, 9 de February de 2011 20:08:31 Stephen Kelly wrote: > Hi, > > K_GLOBAL_STATIC predates Q_GLOBAL_STATIC as far as I know, but with Wrong. K_GLOBAL_STATIC is newer. > Q_GLOBAL_STATIC in Qt, should we port to that wherever K_GLOBAL_STATIC > features are not needed? > > This is part o

Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Hi, K_GLOBAL_STATIC predates Q_GLOBAL_STATIC as far as I know, but with Q_GLOBAL_STATIC in Qt, should we port to that wherever K_GLOBAL_STATIC features are not needed? This is part of reducing dependencies of kde-libraries on KGlobal and other platformyness. All the best, Steve.

Re: proposal: remove KTextEditor interface from kdelibs repository

Aaron J. Seigo wrote: > On Tuesday, February 1, 2011, Harri Porten wrote: >> On Tue, 1 Feb 2011, Aaron J. Seigo wrote: >> > we could end up with a "new kdelibs" module that contains just the core >> > stuff such as kdecore, kdeui, kio .. there could be requirements in >> > there about allowable de

Re: KJob::Capabilities and KWidgetJobTracker

On Wednesday 9 February 2011 19:21:26 Matthias Fuchs wrote: > Am Mittwoch 09 Februar 2011, 19:06:41 schrieb Kevin Ottens: > > On Wednesday 9 February 2011 18:52:57 Matthias Fuchs wrote: > > > I wonder wether setting capabilties for KJobs should be "required". > > > Currently you are presented with

Fwd: ABI breaking between kdelibs 4.5 and 4.6

Hi, There is an API/ABI break in kdelibs because a patch was committed to 4.5 but not 4.6. The patch applies cleanly and is easily cherry-pickable. It is a break of API freeze on 4.6 branch so I thought I'd mention that it's going to happen. However, this shouldn't have happened. What do w

Re: KJob::Capabilities and KWidgetJobTracker

Am Mittwoch 09 Februar 2011, 19:06:41 schrieb Kevin Ottens: > On Wednesday 9 February 2011 18:52:57 Matthias Fuchs wrote: > > I wonder wether setting capabilties for KJobs should be "required". > > Currently you are presented with a "Pause" button in KWidgetJobTracker, > > even if the job does _not

Re: KJob::Capabilities and KWidgetJobTracker

On Wednesday 9 February 2011 18:52:57 Matthias Fuchs wrote: > I wonder wether setting capabilties for KJobs should be "required". > Currently you are presented with a "Pause" button in KWidgetJobTracker, > even if the job does _not_ have the Suspendable capability. Isn't it more a problem of the t

KJob::Capabilities and KWidgetJobTracker

Hi, I wonder wether setting capabilties for KJobs should be "required". Currently you are presented with a "Pause" button in KWidgetJobTracker, even if the job does _not_ have the Suspendable capability. Imo what would be nicer is jobs emiting a signal capabilitiesChanged to which all the graph

Re: Merge or Cherry-Pick?

On Tuesday 08 February 2011 17:49:12 Nicolás Alvarez wrote: > >> Or should I give up and cherry-pick ? (I'd really like not to). > > > > My recommendation: Keep the fix in 4.6 only for the moment. Just wait > > until the initial merge has happened - and lets hope (HOPE BIG TIME) that > > the perso

Re: Review Request: New KIO::http_post and KIO::StoredHttpPost APIs that accept a QIODevice as input...

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100516/#review1324 --- kioslave/http/http.cpp