Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

On Thursday, 10 de February de 2011 17:11:42 Michael Pyne wrote: > I say this as someone who uses QAtomicInt assuming a mode of operation that > is not explicitly documented (i.e. it is safe to initialize its memory > with 0 and avoid running the ctor). If Nokia changes it I would grumble, > but i

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

On Thursday, February 10, 2011 16:35:20 Stephen Kelly wrote: > Thiago Macieira wrote: > > On Thursday, 10 de February de 2011 21:08:05 Stephen Kelly wrote: > >> Thiago Macieira wrote: > >> > It should have been in a qglobalstatic_p.h. We might even do that -- > >> > and intentionally break applicat

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Thiago Macieira wrote: > On Thursday, 10 de February de 2011 21:08:05 Stephen Kelly wrote: >> Thiago Macieira wrote: >> > It should have been in a qglobalstatic_p.h. We might even do that -- >> > and intentionally break applications that are abusing the API. >> >> A quick grep says that would bre

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

On Thursday 10 February 2011, Stephen Kelly wrote: > Thiago Macieira wrote: > > If the user can't get any kind of feedback, the application > > shouldn't be running anymore. > > > > System tray icons are a kind of feedback. > > Again, I might be missing something here. > > Does a systray icon al

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

On Thursday, 10 de February de 2011 21:08:05 Stephen Kelly wrote: > Thiago Macieira wrote: > > It should have been in a qglobalstatic_p.h. We might even do that -- and > > intentionally break applications that are abusing the API. > > A quick grep says that would break akonadi, grantlee, qca, phon

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

Thiago Macieira wrote: > Well, first of all, Thiago is not the highest authority in Qt. You just > had my opinion, not of all people. Sure. I'd call a 'no' from any troll a veto. The only repsonse I got was a no on #qt-labs. That's the only way I have of reaching 'all people' until open governa

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Thiago Macieira wrote: > It should have been in a qglobalstatic_p.h. We might even do that -- and > intentionally break applications that are abusing the API. > A quick grep says that would break akonadi, grantlee, qca, phonon, qxt and a couple of places in KDE that use it already (presumably t

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

On Thursday, 10 de February de 2011 19:57:42 Alex Fiestas wrote: > On 02/10/2011 09:04 AM, Thiago Macieira wrote: > > Even if that is the case, KDE should use K_GLOBAL_STATIC, which is > > better than Q_GLOBAL_STATIC. > > I don't know why is better (I haven't check the code) but then, maybe we > c

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

On 02/10/2011 09:04 AM, Thiago Macieira wrote: Even if that is the case, KDE should use K_GLOBAL_STATIC, which is better than Q_GLOBAL_STATIC. I don't know why is better (I haven't check the code) but then, maybe we can add a new public macro to Qt with the goodness of K_GLOBAL_STATIC and set

Re: Merge or Cherry-Pick?

On Thursday 10 February 2011, Ian Monroe wrote: > On Thu, Feb 10, 2011 at 04:31, Johannes Sixt wrote: > > Am 2/10/2011 10:40, schrieb Ben Cooksley: > >> On Thu, Feb 10, 2011 at 9:35 PM, Johannes Sixt > >> wrote: > >>> git push origin KDE/4.6 > >> > >> This is wrong, as it would try to push the

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

Em quinta-feira, 10 de fevereiro de 2011, às 12:45:58, David Faure escreveu: > > I certainly don't expect it to continue > > running in the background until certain services finish running, in the > > background. > > I can tell you, users definitely expect their download to finish, their mail > to

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

Em quinta-feira, 10 de fevereiro de 2011, às 09:04:09, Ian Monroe escreveu: > On Thu, Feb 10, 2011 at 08:43, Thiago Macieira wrote: > > Em quinta-feira, 10 de fevereiro de 2011, às 10:49:08, Stefan Majewsky > > > > escreveu: > >> On Thu, Feb 10, 2011 at 9:14 AM, Thiago Macieira wrote: > >> > The

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

On Thu, Feb 10, 2011 at 08:43, Thiago Macieira wrote: > Em quinta-feira, 10 de fevereiro de 2011, às 10:49:08, Stefan Majewsky > escreveu: >> On Thu, Feb 10, 2011 at 9:14 AM, Thiago Macieira wrote: >> > The correct way to solve this problem is to show another window >> > indicating that it is doi

Re: Merge or Cherry-Pick?

On Thu, Feb 10, 2011 at 04:31, Johannes Sixt wrote: > Am 2/10/2011 10:40, schrieb Ben Cooksley: >> On Thu, Feb 10, 2011 at 9:35 PM, Johannes Sixt wrote: >>>  git push origin KDE/4.6 >> >> This is wrong, as it would try to push the content of HEAD (the merge >> of origin/KDE/4.6 into a checkout of

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

Em quinta-feira, 10 de fevereiro de 2011, às 10:49:08, Stefan Majewsky escreveu: > On Thu, Feb 10, 2011 at 9:14 AM, Thiago Macieira wrote: > > The correct way to solve this problem is to show another window > > indicating that it is doing something and tell me what. We solve both > > problems at o

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

On Thursday 10 February 2011, Thiago Macieira wrote: > My argument against this solution is that when I tell the application to > Quit, I expect it to do it. Sure, and KGlobal::ref/deref does not break that. But we're not talking about calls to qApp->quit here, we're talking about "closing the la

Re: Merge or Cherry-Pick?

Am 2/10/2011 10:40, schrieb Ben Cooksley: > On Thu, Feb 10, 2011 at 9:35 PM, Johannes Sixt wrote: >> git push origin KDE/4.6 > > This is wrong, as it would try to push the content of HEAD (the merge > of origin/KDE/4.6 into a checkout of origin/master) into KDE/4.6. Now you made me think about

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

On Thu, Feb 10, 2011 at 9:14 AM, Thiago Macieira wrote: > The correct way to solve this problem is to show another window indicating > that it is doing something and tell me what. We solve both problems at once: > there is a window open, so it's not yet a quit from QCoreApplication's sense, > and

Re: Merge or Cherry-Pick?

On Thu, Feb 10, 2011 at 9:35 PM, Johannes Sixt wrote: > Am 2/9/2011 18:28, schrieb John Layt: >> 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. J

Re: Merge or Cherry-Pick?

Am 2/9/2011 18:28, schrieb John Layt: > 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

Re: Review Request: User-friendly error messages in Solid

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/100603/#review1333 --- solid/solid/solidnamespace.h

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

On Wednesday, 9 de February de 2011 21:01:09 Stephen Kelly wrote: > I asked Thiago if I the patch would be applied if I wrote one for > QCoreApplication to fill the role instead, so that we could do > s/KGlobal::ref/qApp->ref/g in KDE, and QCoreApplication::ref and deref would > fill the role that

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

On Thursday, 10 de February de 2011 00:25:12 Olivier Goffart 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. Even if that is t