Re: A Qt replacement for KGlobal::ref and deref
On Thursday 10 February 2011, Thiago Macieira wrote: 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 be sent [this has hit my wife a few times in kmail!]. And if a systray I don't dispute that. I'm simply asking that there is some kind of feedback *while* that is happening. Imagine you send an email, close the kmail, and now you want to suspend your computer. How do I know that the email sending has finished? OK, there should be a job notification. However that is done in another process for better integration with the desktop. There are two problems with this: imagine the case of trying to upload my file to a server while my connection is down. First of all, the application continues running after I told it to quit. Second, I don't see the fact that there's an important upload running. I don't understand this example. If your connection is down, the job will fail quickly and the app will exit fast. Only if it's down when you start the job. If the connection goes down while the transfer is in progress, there's at least 30 seconds timeout -- and that's if there's a timeout at all. OK, solved by the notification too. 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 the user gets feedback. You assume the progress window is in-process, but this leads to ugly unorganized popups all the time so in KDE nowadays we show progress in kuiserver / plasma instead. So you can't use the window as a don't quit now refcounting, you need the job for that. Right, but there's no API for doing that from Qt. Well, there's QtDBus. Remember, you wrote it :-) So today any Qt application requires a window to display its progress. See Cornelius, why we can't move kdelibs functionality to Qt? Because the Qt developers consider that Qt is only meant for standalone apps, not for an integrated desktop :( I don't understand the problem. Instead of just counting open windows, you also count other things which ask to be counted - systray icon and jobs. Systray icon, yes. Jobs with visual feedback (even if out-of-process), yes. Jobs with no visual feedback, no. Great, then let's add an API in Qt for letting running jobs increase/decrease the refcount, and let's document it as don't use this if you are not showing any visual feedback. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Re: A Qt replacement for KGlobal::ref and deref
Em domingo, 13 de fevereiro de 2011, às 07:44:22, Aaron J. Seigo escreveu: that is easily provably wrong: KDE apps are also Qt apps, they don't require a window to display its progress and therefore refcounting is needed. i can trivially write a Qt app that uses the notification dbus service and end up in the same place. True. Let me skip to the point: an app-global reference count allows the application to handle this very real use case; without it, the use case is not feasible. it's not Qt's job to prevent developers from shooting themselves in the foot with features that are otherwise needed to get a certain task done. I agree, as long as the reference count is tied to the window count. People should understand that a GUI application running with no GUI makes no sense and should be avoided. So from a usability point of view, you can run jobs, provided that you get a notification about them, somewhere. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: A Qt replacement for KGlobal::ref and deref
I agree, as long as the reference count is tied to the window count. People should understand that a GUI application running with no GUI makes no sense and should be avoided. RSIBreak has no GUI, only a stats window and a config window. It only has a tray icon. Probably the famous exception to the rule? Do I need to change anything in my app for this? Best, -- Tom Albers
Re: A Qt replacement for KGlobal::ref and deref
On Monday 14 February 2011, Tom Albers wrote: I agree, as long as the reference count is tied to the window count. People should understand that a GUI application running with no GUI makes no sense and should be avoided. RSIBreak has no GUI, only a stats window and a config window. It only has a tray icon. Probably the famous exception to the rule? Do I need to change anything in my app for this? A tray icon *is* a GUI. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Re: A Qt replacement for KGlobal::ref and deref
Em segunda-feira, 14 de fevereiro de 2011, às 12:16:08, David Faure escreveu: On Monday 14 February 2011, Tom Albers wrote: I agree, as long as the reference count is tied to the window count. People should understand that a GUI application running with no GUI makes no sense and should be avoided. RSIBreak has no GUI, only a stats window and a config window. It only has a tray icon. Probably the famous exception to the rule? Do I need to change anything in my app for this? A tray icon *is* a GUI. I agree. What I don't want is an app that has no way for me to quit it, other than opening a shell and killing it (or the amazing ksysguard). My pet peeve with this issue is kmail 1.x that used to close its window when I Ctrl+Q'ed it and then continue running in the background, indefinitely. If I hadn't been burned by this before, I'd have been a lot more receptive of the idea. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: A Qt replacement for KGlobal::ref and deref
On Monday 14 February 2011, Thiago Macieira wrote: What I don't want is an app that has no way for me to quit it, other than opening a shell and killing it (or the amazing ksysguard). My pet peeve with this issue is kmail 1.x that used to close its window when I Ctrl+Q'ed it and then continue running in the background, indefinitely. If I hadn't been burned by this before, I'd have been a lot more receptive of the idea. So because something could potentially be used to make buggy applications, it shouldn't be in Qt at all? With this reasoning Qt should be completely empty then :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Re: A Qt replacement for KGlobal::ref and deref
On Monday 14 February 2011, David Faure wrote: On Monday 14 February 2011, Thiago Macieira wrote: What I don't want is an app that has no way for me to quit it, other than opening a shell and killing it (or the amazing ksysguard). My pet peeve with this issue is kmail 1.x that used to close its window when I Ctrl+Q'ed it and then continue running in the background, indefinitely. If I hadn't been burned by this before, I'd have been a lot more receptive of the idea. So because something could potentially be used to make buggy applications, it shouldn't be in Qt at all? With this reasoning Qt should be completely empty then :-) ... and especially, setQuitOnLastWindowClosed(false) shouldn't exist then, since it can lead to the *exact* same bug! -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
Re: A Qt replacement for KGlobal::ref and deref
On Monday, February 14, 2011, Thiago Macieira wrote: I agree, as long as the reference count is tied to the window count. People should understand that a GUI application running with no GUI makes no sense and should be avoided. agreed; so just to be painfully clear (it's a monday morning here, i worked all weekend and i still have house packing to do, please excuse my obtuseness ;): IF a refcoutning patch is offered which ties all window visibility (setQuitOnLastWindowClosed, QSystemTray, etc) to the refcounting behind the scenes but which also exposes said refcounting as the quit-on-last-window feature with stern and accurate descriptions on how it works, that would be accepted? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: A Qt replacement for KGlobal::ref and deref
On Monday 14 February 2011, David Faure wrote: On Thursday 10 February 2011, Thiago Macieira wrote: 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 be sent [this has hit my wife a few times in kmail!]. And if a systray I don't dispute that. I'm simply asking that there is some kind of feedback *while* that is happening. Imagine you send an email, close the kmail, and now you want to suspend your computer. How do I know that the email sending has finished? OK, there should be a job notification. However that is done in another process for better integration with the desktop. Actually, with Akonadi, the sending will be done with yet another (non- GUI) process. Again, for better integration with the desktop. Because why should an application like KAlarm start KMail just to send a notification. For obvious reasons KMail will not wait until the message is sent before it quits. It will quit as soon as it has passed the message to the dispatcher. Just like in the good old times when sending was done by passing a message to sendmail. But, of course, as David explained, there will be a job notification (unlike with sendmail where the user didn't get any UI feedback). Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: A Qt replacement for KGlobal::ref and deref
Aaron J. Seigo wrote:
On Wednesday, February 9, 2011, Stephen Kelly wrote:
http://techbase.kde.org/Projects/KDELibsModifications
good to see people thinking about these things. however:
this page belongs on commuity.kde.org. it's already linked from here:
http://community.kde.org/KDE_Core
and it should be moved over.
Done.
one thing that jumps out at me is the use of terms like library when
really it means classes. there's an implicit assumption on that page
that libraries like kdecore will be split up into N different libraries.
That's what I was suggesting on the page, yes. I don't know about how much
granularity makes sense there, but that is what I was suggesting.
while i think there's an easier case to be made for some of other
libraries such as kdeui (which is a huge collection of rather different
kinds of things) and kio (which quite evidently mixes framework and
platform concepts into one library), it's less obvious that this applies
to kdecore.
Sure, well that's up for discussion of course. Why do you say that? Because
kdecore depends on qtcore and little else? Why does that matter? Can't we
have the 'lowest level' libraries in kdelibs depend on QtXml, QtGui
QtDeclarative etc - ie any parts of Qt. Does the 'lowest level' kde gui
library/classes have to depend on kdecore for some reason?
yes, there are different kinds of things in kdecore, but there are both
interdependencies and the open question of how many of those basic items
does a typical application end up using. there's little point in splitting
it up if a significant % of apps will use a significant % of features
together from that library: they'll just end up linking to all the smaller
libraries individually and we'll end up with a more complex system to
maintain.
Sure, I get the complexity argument. It would take more buildsystem stuff to
maintain, but the thinking was towards the 'Qt developers' like Gregory
Schlomoff who think it makes more sense to fork and extract kimap/kmime/kjob
than to simply depend on them as is. I agree with him that currently the
forking like that makes sense for Qt developers, but I think it's changable.
You might think in terms of how much a typical KDE application ends up
using, but I'm thinking in terms of how much a typical Qt application ends
up using. Gregory is not going to end up using KLocale KConfig KDateTime etc
just because he wants to use kimap. I'm thinking in terms of the Qt
community and broader appeal - the people I interact with on qt-interest,
not the KDE community.
For KDE applications I don't see anything changing. ${KDECORE_LIBRARIES}
would be expanded to contain libkjob.so libklocale.so libkitemviews.so etc
to whatever granularity makes sense.
imho what kdecore can benefit from is streamlining the KDE-only details in
it, such as the global ref/deref and other such things.
I'm not sure what you mean by streamlining here? You mean streamlining to
mean getting supportive API into Qt for this kind of stuff?
this should help
make it smaller and get the lines between it and QtCore a bit more clear
and clean. the ultimate goal of splitting out KJob, though? personally,
i'm less convinced.
My ultimate goal is to reduce 'uncle dependencies' and artificail
dependencies of classes and functionalities and libraries in kdelibs and
make it easier for those functionalities to be used by the broader Qt
community. The goal is to make forking make less sense than as-is
consumption. I know of 4 Qt based email solutions. Why don't they all use
kimap?
There's also a lot of other useful stuff in kdepimlibs which doesn't need to
depend on all of kdelibs as it currently does. Do you think a Qt-only
akonadi client library would be useful? I do. Most of the classes in akonadi
that are useful for implementing akonadi clients have only Qt class
dependencies (like the model view stuff etc). KJob is the only part of
kdelibs that the core functional parts of libakonadi really need.
By uncle dependencies by the way I mean - kjob and related classes do not
depend on gettext. Those classes are in kdecore. KLocale is in kdecore.
KLocale depends on getttext. kjob depends on gettext by association with
klocale through kdecore, so gettext is an uncle dependency of kjob.
The 'artificial' dependencies of kdeui/itemviews are far more, though
there's no dependence of that stuff on anything but Qt.
Thanks for your feedback on this by the way. It's useful to get others
talking on it. I'm going to continue to try to be at 1.0 on the spectrum of
wanting a granular kdelibs - to the point of playing devils advocate if
needed :). I know that others have differing viewpoints, and that's great.
All the best,
Steve.
Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?
Michael Pyne wrote: 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 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 they don't need the features of K_GLOBAL_STATIC that you mentioned). If you (re)move it, we'd all just end up copying the macro into our own codebases, so that wouldn't achieve much. Phonon should have a copy of K_GLOBAL_STATIC. I noticed K_GLOBAL_STATIC uses QBasicAtomicPointer, which doesn't seem to be public API. Is that going away too? That would break K_GLOBAL_STATIC. Although you raise a good point, their docs are quite clear that the API is not public, so pointing out *other* uses of non-public APIs doesn't really help the argument, as Nokia is still within their rights to move non-public API to non-installed headers. What I was getting at was really just that if the recommendation is to use K_GLOBAL_STATIC, but then QBasicAtomicPointer gets moved to some _p.h file, that is screwed too. Then using K_GLOBAL_STATIC is not a good recommendation. The recommendation should be to use something that doesn't use Qt internals. FWIW I'm totally in favor of giving Q_GLOBAL_STATIC whatever features it doesn't have that make K_GLOBAL_STATIC the current better choice, possibly breaking existing users of Q_GLOBAL_STATIC in the process if it means making it public API. 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 it would by my problem, not theirs. It also wouldn't really break K_GLOBAL_STATIC, as the code could simply be freed from Qt in the event that were to happen, or be reimplemented in a different fashion (such as gcc intrinsics, I would imagine). Yes, but krandomapplication is supposed to run against kdelibs 4.6 which has the current implementation of K_GLOBAL_STATIC. If QBasicAtomicPointer is removed in Qt 4.8, krandomapplication 4.6 won't work if linked against Qt 4.8. That's the kind of breakage I mean. Regards, Steve.
Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?
On Tuesday, February 15, 2011 00:12:42 Thiago Macieira wrote: On Monday, 14 de February de 2011 23:46:55 Stephen Kelly wrote: What I was getting at was really just that if the recommendation is to use K_GLOBAL_STATIC, but then QBasicAtomicPointer gets moved to some _p.h file, that is screwed too. Then using K_GLOBAL_STATIC is not a good recommendation. The recommendation should be to use something that doesn't use Qt internals. QBasicAtomicPointer is a base class of the public class QAtomicPointer. The split between them is that one is POD, the other isn't. Well to play devil's advocate, is it not possible in theory to make QAtomicPointer derive from QBasicAtomicPointer2 in Qt 4.8, in a way such that users of *only* QAtomicPointer still worked but users of QBasicAtomicPointer broke? Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?
Thiago Macieira wrote: QBasicAtomicPointer is a base class of the public class QAtomicPointer. I see. That does make it harder to remove anyway.
Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?
On Monday, 14 de February de 2011 18:22:20 Michael Pyne wrote: On Tuesday, February 15, 2011 00:12:42 Thiago Macieira wrote: On Monday, 14 de February de 2011 23:46:55 Stephen Kelly wrote: What I was getting at was really just that if the recommendation is to use K_GLOBAL_STATIC, but then QBasicAtomicPointer gets moved to some _p.h file, that is screwed too. Then using K_GLOBAL_STATIC is not a good recommendation. The recommendation should be to use something that doesn't use Qt internals. QBasicAtomicPointer is a base class of the public class QAtomicPointer. The split between them is that one is POD, the other isn't. Well to play devil's advocate, is it not possible in theory to make QAtomicPointer derive from QBasicAtomicPointer2 in Qt 4.8, in a way such that users of *only* QAtomicPointer still worked but users of QBasicAtomicPointer broke? It is. So what you want is for QBasicAtomicXXX to be documented? Sounds fair. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?
On Tuesday, February 15, 2011 00:51:38 Thiago Macieira wrote: On Monday, 14 de February de 2011 18:22:20 Michael Pyne wrote: Well to play devil's advocate, is it not possible in theory to make QAtomicPointer derive from QBasicAtomicPointer2 in Qt 4.8, in a way such that users of *only* QAtomicPointer still worked but users of QBasicAtomicPointer broke? It is. So what you want is for QBasicAtomicXXX to be documented? Sounds fair. That would be exceedingly nice, yes. I would at least feel less bad about my current usage of QBasicAtomicInt (on non-PA-RISC), especially if the statement about being POD and non-POD were also to be explicitly added to the API. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part.
Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?
Am Donnerstag 10 Februar 2011, 23:41:13 schrieb Thiago Macieira: 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 it would by my problem, not theirs. That works in all platforms except HP PA-RISC. In that platform, you have to initialise the 4 other words to -1. Since I have some of these machines: is there any detail on this available somewhere? Does this count for HP-UX only or also for Linux? Eike
Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?
On Tuesday, 15 de February de 2011 07:53:15 Rolf Eike Beer wrote: Since I have some of these machines: is there any detail on this available somewhere? Does this count for HP-UX only or also for Linux? You can find the info in Qt's source code: src/corelib/arch/qatomic_parisc.h and src/corelib/arch/parisc/* Linux on PA-RISC is not supported. We have no clue if it even compiles. It probably does if the assembler can compile src/corelib/arch/parisc/q_ldcw.s. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?
On Monday, 14 de February de 2011 20:46:29 Michael Pyne wrote: On Tuesday, February 15, 2011 00:51:38 Thiago Macieira wrote: On Monday, 14 de February de 2011 18:22:20 Michael Pyne wrote: Well to play devil's advocate, is it not possible in theory to make QAtomicPointer derive from QBasicAtomicPointer2 in Qt 4.8, in a way such that users of *only* QAtomicPointer still worked but users of QBasicAtomicPointer broke? It is. So what you want is for QBasicAtomicXXX to be documented? Sounds fair. That would be exceedingly nice, yes. I would at least feel less bad about my current usage of QBasicAtomicInt (on non-PA-RISC), especially if the statement about being POD and non-POD were also to be explicitly added to the API. Meanwhile, you should initialise with Q_BASIC_ATOMIC_INITIALIZER(0). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
