Re: A Qt replacement for KGlobal::ref and deref
On Saturday, 21 de May de 2011 05:39:44 Stephen Kelly wrote: > Thiago Macieira kde.org> writes: > > 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? > > > > I think so. You'd have my support. > > > > But I'm not the maintainer for QApplication. > > I'm revisiting this issue now. Who is the maintainer of QApplication? Can I > get an irc nick or email address suitable for public mailing lists? There isn't a maintainer. It's either shared responsibility or orphaned, as many things in Qt are. The assignment of maintainers isn't done yet. The mailing list for discussing these things is lacking. The next best thing is qt5-feedback. -- 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
Thiago Macieira kde.org> writes: > 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? > > I think so. You'd have my support. > > But I'm not the maintainer for QApplication. > I'm revisiting this issue now. Who is the maintainer of QApplication? Can I get an irc nick or email address suitable for public mailing lists? Thanks, Steve.
Re: A Qt replacement for KGlobal::ref and deref
Stefan Majewsky wrote: > On Wed, Feb 16, 2011 at 5:31 PM, Aaron J. Seigo wrote: >> which begs the question: "is KConfig (as ane exmple) platform or app >> dev"? fun conversations to be had and digging to be done :) > > From my experience, KConfig is actually two things at once: > > 1. framework for reading and writing INI-like files > 2. utility for locating and merging user-specific plus system-wide > configuration > > Only part 2 is platform. Part 1 is already a great thing in itself > even if applied to single files. Usages of KConfig for the purpose of > defining custom, human-readable file formats include (here in > kdegames) KGameTheme description files, Palapeli puzzle metadata, > Palapeli collections, Kolf courses, etc.pp. Part 2 is "just" a bonus > for application configuration files, just like KConfigXT which is not > useful for custom file formats. > > So a possible idea could be to refactor the KConfig class into two > classes, one for stand-alone config files and one for application > configuration in KStandardDirs' "config" prefix. The latter class > would then move into the KDE platform thingy, while the other one does > not have any KStandardDirs dependency. (Dunno about other low-level > dependencies, though.) To see how that kind of thing can work, see here: http://websvn.kde.org/trunk/playground/pim/contacts/kgrantleeintegration.cpp?revision=1221333&view=markup Grantlee has API for setting where to look for stuff like templates and plugins. In a KDE application you don't want to have to specify those things explicitly because KStandardDirs knows the right places to look. So the KGrantleeIntegration simply calls all the necessary Grantlee APIs with the output from KStandardDirs. This way we achieve platform integration (kaddressbook only needs to create a KGrantleeIntegration object, but doesn't need to tell it where to look for stuff), and Grantlee remains a Qt only library, something that belongs on Tier1 on my diagram.
Re: A Qt replacement for KGlobal::ref and deref
On 17.02.11 13:43:11, Stefan Majewsky wrote: > On Wed, Feb 16, 2011 at 5:31 PM, Aaron J. Seigo wrote: > > which begs the question: "is KConfig (as ane exmple) platform or app dev"? > > fun > > conversations to be had and digging to be done :) > > From my experience, KConfig is actually two things at once: > > 1. framework for reading and writing INI-like files > 2. utility for locating and merging user-specific plus system-wide > configuration > > Only part 2 is platform. Part 1 is already a great thing in itself > even if applied to single files. Usages of KConfig for the purpose of > defining custom, human-readable file formats include (here in > kdegames) KGameTheme description files, Palapeli puzzle metadata, > Palapeli collections, Kolf courses, etc.pp. Part 2 is "just" a bonus > for application configuration files, just like KConfigXT which is not > useful for custom file formats. > > So a possible idea could be to refactor the KConfig class into two > classes, one for stand-alone config files and one for application > configuration in KStandardDirs' "config" prefix. The latter class > would then move into the KDE platform thingy, while the other one does > not have any KStandardDirs dependency. (Dunno about other low-level > dependencies, though.) I don't see why 2. would be a platform-thingie. Its useful for an app itself when it needs to have different levels of configuration where a more specific level needs to be able to override a more general level. Think of apps that have some kind of session, some settings might be useful across all sessions you use, but some are specific to a given session. So I actually think there are 3 parts in KConfig: 1. ini-style reading/writing 2. merging of kconfig-files representing different level of configuration 3. locating of config-stuff And here the 3. one would be platform-thingie (unless one has a backend for different platforms). Andreas -- Save energy: be apathetic.
Re: A Qt replacement for KGlobal::ref and deref
On Wed, Feb 16, 2011 at 5:31 PM, Aaron J. Seigo wrote: > which begs the question: "is KConfig (as ane exmple) platform or app dev"? fun > conversations to be had and digging to be done :) >From my experience, KConfig is actually two things at once: 1. framework for reading and writing INI-like files 2. utility for locating and merging user-specific plus system-wide configuration Only part 2 is platform. Part 1 is already a great thing in itself even if applied to single files. Usages of KConfig for the purpose of defining custom, human-readable file formats include (here in kdegames) KGameTheme description files, Palapeli puzzle metadata, Palapeli collections, Kolf courses, etc.pp. Part 2 is "just" a bonus for application configuration files, just like KConfigXT which is not useful for custom file formats. So a possible idea could be to refactor the KConfig class into two classes, one for stand-alone config files and one for application configuration in KStandardDirs' "config" prefix. The latter class would then move into the KDE platform thingy, while the other one does not have any KStandardDirs dependency. (Dunno about other low-level dependencies, though.) Greetings Stefan
Re: A Qt replacement for KGlobal::ref and deref
Aaron J. Seigo wrote: > On Tuesday, February 15, 2011, Stephen Kelly wrote: >> http://steveire.com/kdelibs-modular.png >> >> * It's broad at the base - Qt developers can pick and choose what they >> want. There are less interdependencies - you can use the itemviews stuff >> without also pulling in KLocale KConfig etc. If you're happy with >> QSettings and QLocale (and Qt developers are happy with those), then you >> don't use them. * All the platformy stuff is at the top instead of at the >> bottom. >> * KDE applications know no difference. The platformy stuff is provided to >> them still. > > what's interesting is that we aren't as far from your "desired" diagram > already. your "what it looks like now to a qt developer" diagram is as > much a matter of perspective as it is of the reality. yes, we have > modularization to do (the item views, for instance, perhaps being a good > example; kdeui has several such things in it), but libkdecore is not such > a big issue imho. don't want kconfig? don't use it. splitting it out to > its own library is likely to be more burdone that benefit. If it were that easy, Gregory wouldn't have forked. He's not the only one either. The MeeGo use of KCal includes forked KDE stuff: http://conference2010.meego.com/session/organise-your-life-calendar-meego http://meego.gitorious.org/meego-middleware/meego-kcalcore Yes, part of the reason is about communicating, part of it is about consequences of using kdecore. There's daemons to be run etc, you're pulling in stuff which you know you don't want to use, like the locale and config stuff and a k plugin system, and you don't know why they exist. > > there's also libraries like solid, phonon, attica, qca(, akonadi?) which > are already in that "tier 1" line. even so, we don't communicate that well > at all and our build system layout and the "social contracts" we have with > packagers don't help at all. Another thing to remember is that Qt developers wouldn't necessarily use packages from debian or whatever, especially if they're putting together an application or software which they distribute or bundle by their own means. Splitting in packages might be useful from the communication or discoverability angle (Oh! apt-cache tells me libsolid only depends on Qt. I'll use that!), I don't think it helps a lot technically in the appeal to the Qt community. > > so, good news is that we're closer than one might think from the outside > looking in. bad news is we still have quite a bit of work, particularly in > kdeui, kio and our build/packaging/communication targets. > Yes, it's not as bad as it might look like I'm claiming :), there's a lot of useful changes within reach, or currently just out of reach. I think if no kde library needed to depend on kglobal or any other internal parts of kde which creates interdependencies by nature that would be a huge win. Why does KGlobal::locale() exist, for example? Why isn't that a static method on KLocale? That would mean locale-needing libraries can use that without depending on KConfig. More food for thought.
Re: A Qt replacement for KGlobal::ref and deref
On Wednesday, February 16, 2011, David Jarvie wrote: > There would be a major benefit from splitting KConfig etc out of kdecore: > Qt developers could use the stripped down library confident in the > knowledge that they could use any class in it without having to worry > about whether they might accidentally introduce a dependence on platformy > stuff. it just introduces a new complexity: which of these bazillion libraries do i use and what's the overhead of having so many of them? (not to mention the complications for us actually making that library). QtCore isn't a bazillion libraries either. what i do agree with, however, is that kdecore (as example) does need: * to be properly documented from a higher level than it is now * should have KDE platform features separated out from app dev framework features which begs the question: "is KConfig (as ane exmple) platform or app dev"? fun conversations to be had and digging to be done :) -- 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 Wed, February 16, 2011 1:44 am, Aaron J. Seigo wrote: > On Tuesday, February 15, 2011, Stephen Kelly wrote: >> http://steveire.com/kdelibs-modular.png >> >> * It's broad at the base - Qt developers can pick and choose what they >> want. There are less interdependencies - you can use the itemviews stuff >> without also pulling in KLocale KConfig etc. If you're happy with >> QSettings and QLocale (and Qt developers are happy with those), then you >> don't use them. * All the platformy stuff is at the top instead of at >> the bottom. >> * KDE applications know no difference. The platformy stuff is provided >> to them still. > > what's interesting is that we aren't as far from your "desired" diagram > already. your "what it looks like now to a qt developer" diagram is as > much a > matter of perspective as it is of the reality. yes, we have modularization > to > do (the item views, for instance, perhaps being a good example; kdeui has > several such things in it), but libkdecore is not such a big issue imho. > don't > want kconfig? don't use it. splitting it out to its own library is likely > to be more burdone that benefit. There would be a major benefit from splitting KConfig etc out of kdecore: Qt developers could use the stripped down library confident in the knowledge that they could use any class in it without having to worry about whether they might accidentally introduce a dependence on platformy stuff. Having all the kdecore classes mixed together in a single library, as now, would mean that Qt developers have to check all the time which classes are "safe" to use and which aren't - and currently, that isn't even documented clearly. That puts up a big barrier to others using our library. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: A Qt replacement for KGlobal::ref and deref
On Tuesday, February 15, 2011, Stephen Kelly wrote: > http://steveire.com/kdelibs-modular.png > > * It's broad at the base - Qt developers can pick and choose what they > want. There are less interdependencies - you can use the itemviews stuff > without also pulling in KLocale KConfig etc. If you're happy with > QSettings and QLocale (and Qt developers are happy with those), then you > don't use them. * All the platformy stuff is at the top instead of at the > bottom. > * KDE applications know no difference. The platformy stuff is provided to > them still. what's interesting is that we aren't as far from your "desired" diagram already. your "what it looks like now to a qt developer" diagram is as much a matter of perspective as it is of the reality. yes, we have modularization to do (the item views, for instance, perhaps being a good example; kdeui has several such things in it), but libkdecore is not such a big issue imho. don't want kconfig? don't use it. splitting it out to its own library is likely to be more burdone that benefit. there's also libraries like solid, phonon, attica, qca(, akonadi?) which are already in that "tier 1" line. even so, we don't communicate that well at all and our build system layout and the "social contracts" we have with packagers don't help at all. so, good news is that we're closer than one might think from the outside looking in. bad news is we still have quite a bit of work, particularly in kdeui, kio and our build/packaging/communication targets. i think we should have diagrams like those on the wall at the Platform 11 meeting. :) > I'd like kdelibraries to be something Qt developers use and recommend. > Currently they no neither. KDE should provide a set of high quality Qt > based libraries, it should be to Qt what boost is to C++. i like that statement a lot. -- 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
Alexander Neundorf wrote:
> On Monday 14 February 2011, Stephen Kelly wrote:
>> 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.
>
> Can you try to add some graphic to the tier 0/1/2 explanation, or
> elaborate it a bit more ?
> I have a hard time understanding it exactly.
Here's a picture of what I think kde looks like to a Qt developer:
http://steveire.com/kdelibs-current.png
* It all converges to a point. It's an inverted pyramid.
* Lots of stuff depends on each other, even just by association (like the
itemviews stuff - the classes themselves only depend on Qt, but by being in
kdeui come with a lot more baggage).
* I know there are several entry points - you can use kdecore independently
of
the rest, even kdeui only needs kdecore etc, but in practice Qt developers
fork what they want instead of depending on it. And that makes sense today.
http://dot.kde.org/2010/10/15/gregory-schlomoff-betterinbox-kde-development-
platform
Here's what I'd like it to look like:
http://steveire.com/kdelibs-modular.png
* It's broad at the base - Qt developers can pick and choose what they want.
There are less interdependencies - you can use the itemviews stuff without
also pulling in KLocale KConfig etc. If you're happy with QSettings and
QLocale (and Qt developers are happy with those), then you don't use them.
* All the platformy stuff is at the top instead of at the bottom.
* KDE applications know no difference. The platformy stuff is provided to
them still.
I'd like kdelibraries to be something Qt developers use and recommend.
Currently they no neither. KDE should provide a set of high quality Qt based
libraries, it should be to Qt what boost is to C++.
>
>> > 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?
>
> I think they depend e.g. on KDE-wide settings like single vs. double
> click, completion, translation settings, ...
That's only a description of the platformy stuff. There is a lot of code in
kdelibs which provides functionality - not platform integration which you
are describing. There's no need for the functionality parts to depend on the
platform integration in all cases (in some, yes).
> Haven't actually written any C++ code for KDE since I'm caring for the
> buildsystem...
> Anyway, if such dependencies are inside the K-classes, it should be
> possible to refactor them out, so these settings are set from the outside
> (wrapping class).
I'm not certain I understand what you say here.
>
> ...
>> 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.
>
> By doing that, the borders between the KDE- and Qt-communities would
> blurr, which would be a good thing. I'm all for it.
>
>> 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, thoug
Re: A Qt replacement for KGlobal::ref and deref
Alexander Neundorf wrote:
> On Monday 14 February 2011, Stephen Kelly wrote:
>> 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.
>
> Can you try to add some graphic to the tier 0/1/2 explanation, or
> elaborate it a bit more ?
> I have a hard time understanding it exactly.
Here's a picture of what I think kde looks like to a Qt developer:
http://steveire.com/kdelibs-current.png
It all converges to a point. It's an inverted pyramid.
Lots of stuff depends on each other, even just by association (like the
itemviews stuff - the classes themselves only depend on Qt, but by being in
kdeui come with a lot more baggage).
I know there are several entry points - you can use kdecore independently of
the rest, even kdeui only needs kdecore etc, but in practice Qt developers
fork what they want instead of depending on it.
>
>> > 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?
>
> I think they depend e.g. on KDE-wide settings like single vs. double
> click, completion, translation settings, ...
> Haven't actually written any C++ code for KDE since I'm caring for the
> buildsystem...
> Anyway, if such dependencies are inside the K-classes, it should be
> possible to refactor them out, so these settings are set from the outside
> (wrapping class).
>
> ...
>> 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.
>
> By doing that, the borders between the KDE- and Qt-communities would
> blurr, which would be a good thing. I'm all for it.
>
>> 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.
>
> I guess we need to figure out groups which make sense.
> I.e. making lists of classes which belong together in some way
> (functionality ? dependencies ? level of integration ?)
> At least functionality wise they are already grouped quite well by the
> subdirectories inside kdecore, kdeui, etc.
>
>> By uncle dependen
Re: A Qt replacement for KGlobal::ref and deref
On Monday 14 February 2011, Stephen Kelly wrote:
> 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.
Can you try to add some graphic to the tier 0/1/2 explanation, or elaborate it
a bit more ?
I have a hard time understanding it exactly.
> > 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?
I think they depend e.g. on KDE-wide settings like single vs. double click,
completion, translation settings, ...
Haven't actually written any C++ code for KDE since I'm caring for the
buildsystem...
Anyway, if such dependencies are inside the K-classes, it should be possible
to refactor them out, so these settings are set from the outside (wrapping
class).
...
> 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.
By doing that, the borders between the KDE- and Qt-communities would blurr,
which would be a good thing. I'm all for it.
> 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.
I guess we need to figure out groups which make sense.
I.e. making lists of classes which belong together in some way
(functionality ? dependencies ? level of integration ?)
At least functionality wise they are already grouped quite well by the
subdirectories inside kdecore, kdeui, etc.
> 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 th
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: 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
On Monday, 14 de February de 2011 09:11:28 Aaron J. Seigo wrote: > 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? I think so. You'd have my support. But I'm not the maintainer for QApplication. -- 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, 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 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 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
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, 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
> 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
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
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
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. 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. 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. 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. imho what kdecore can benefit from is streamlining the KDE-only details in it, such as the global ref/deref and other such things. 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. -- 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 Thursday, February 10, 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? > > > > 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. > > > > 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. So today any Qt > application requires a window to display its progress. Therefore, the API > for refcounting isn't needed. 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. now look at it from the other side: applications which don't require this feature don't need to touch the refcount, and for those Qt apps the world remains the same. and of course, by your same reasoning then setQuitOnLastWindowClose shouldn't exist either. you're tryng to make Qt into a straightjacket that fights against some very real use cases. what's really unfortunate is that those use cases represent a much more modern, multi-process view of the world than "all my UI is running this my app". > > 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. that's obviously up to the application, not Qt alone. > So the way I see it, ref/unref is just a way to increase and decrease the > number of windows this process has when the window is actually > out-of-process. Abuse of that will lead to bad usability. shall i list all the things that are easily abused in Qt for bad usability? 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. -- 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 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 already count as a window? If I set > quitOnLastWindowClosed to true and the application creates a systray > icon, and then I close the application window, does the application > quit? I guess so. At least, Qt's example for QSystemTrayIcon explicitly sets quitOnLastWindowClosed to false to prevent this from happening: http://doc.qt.nokia.com/latest/desktop-systray-main-cpp.html Regards, Ingo signature.asc Description: This is a digitally signed message part.
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 governance gives us a Qt development mailing list. >> It works in KDE of course because all KDE libraries and >> applications use KGlobal::ref and deref, which perpetuates our walled >> garden. > > They already do. The KGlobal::ref()/deref() function is already separate > and all libraries need to use it. All KDE libraries which are part of the feature, yes, like KJob, KRun, kuiserver (?). Currently, all non-KDE libraries have to become KDE libraries to use it, and KJob can't become a non-KDE library with the same feature set. >> 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. Presumably that should be through kuiserver/plasma then (just guessing, I don't know anything about kuiserver). > 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. So today any Qt > application requires a window to display its progress. Therefore, the API > for refcounting isn't needed. I might be missing something, but isn't this snake-tail logic? There's no way in Qt to implement a refcounting quit, therefore today you need a window, therefore Qt doesn't need the API and the application needs a window. Isn't this thread about changing that? > 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 already count as a window? If I set quitOnLastWindowClosed to true and the application creates a systray icon, and then I close the application window, does the application quit?
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 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? > > 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. > > 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. So today any Qt application requires a window to display its progress. Therefore, the API for refcounting isn't needed. > > They already do. The KGlobal::ref()/deref() function is already separate > > and all libraries need to use it. > > But KMainWindow, KJob and KSystemTrayIcon use it, so for the application > developer, it's all transparent. And that's fine. > If this is added to Qt, then QMainWindow and QSystemTrayIcon should use it, > otherwise people will just forget. Yes. > 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. So the way I see it, ref/unref is just a way to increase and decrease the number of windows this process has when the window is actually out-of-process. Abuse of that will lead to bad usability. -- 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
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 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. > >> > >> This assumption breaks in KDE because the progress is displayed by the > >> kuiserver. > > > > But we're no longer talking about a KDE application. This is a Qt > > application, with no access to kuiserver. > > But surely such functionality isn't unique to KDE? Having operations > not associated with a QWidget that need to finish before an > application closes seems pretty normal. David summed it up: "Instead > of just counting open windows, you also count other things which ask > to be counted - systray icon and jobs." I disagree. 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. Dialogs are too. Running for 30 seconds in the background with no indication is not acceptable. Worse is the application that doesn't quit ever after telling it to quit -- KMail 1.x did this all the time. I had to kill it or kquitapp after closing it to quit. Maybe it's a refcount bug, but one that would be easy to tell if there was still some kind of visual feedback enforced. -- 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 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 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. >> >> This assumption breaks in KDE because the progress is displayed by the >> kuiserver. > > But we're no longer talking about a KDE application. This is a Qt application, > with no access to kuiserver. But surely such functionality isn't unique to KDE? Having operations not associated with a QWidget that need to finish before an application closes seems pretty normal. David summed it up: "Instead of just counting open windows, you also count other things which ask to be counted - systray icon and jobs." Ian
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 once: there is a window open, so it's not yet a quit from > > QCoreApplication's sense, and the user gets feedback. > > This assumption breaks in KDE because the progress is displayed by the > kuiserver. But we're no longer talking about a KDE application. This is a Qt application, with no access to kuiserver. -- 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 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 last mainwindow while there's still a download going on in the background -- or a systray icon -- or a mail being sent". > 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 icon increases the refcount it's also a way to easily implement "only quit the process once there's no more mainwindow -and- no more systray icon". > 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. > 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. > > Thiago did also offer the solution of a separate service providing the > > refcounted quit functionality, but the problem with that is that all > > libraries and applications need to use the same ref/deref code otherwise > > it won't work. If I create a separate library with a service providing > > that functionality it wouldn't help because there would be no guarantee > > that all apps and libraries would use it. The solution would need to be > > in Qt. It works in KDE of course because all KDE libraries and > > applications use KGlobal::ref and deref, which perpetuates our walled > > garden. > > They already do. The KGlobal::ref()/deref() function is already separate > and all libraries need to use it. But KMainWindow, KJob and KSystemTrayIcon use it, so for the application developer, it's all transparent. If this is added to Qt, then QMainWindow and QSystemTrayIcon should use it, otherwise people will just forget. 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. -- 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 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 the user gets feedback. This assumption breaks in KDE because the progress is displayed by the kuiserver. Greetings Stefan
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 the KGlobal methods currently do, and QMainWindow (or > maybe all top level QWidgets) would use them. > > Obviously there would need to be more thought into how it would react with > setQuitOnLastWindowClosed etc, but it doesn't matter because Thiago said the > patch would not be applied. The argument against it was that if the last > window of a gui app is closed, the app should quit and any running jobs > should be either completed by then or terminated before the last window is > allowed to be closed. Thiago thought that ref/deref were a bad idea in the > first place and shouldn't be in Qt. I disagree, but there you have it. Well, first of all, Thiago is not the highest authority in Qt. You just had my opinion, not of all people. Second: I don't think this should be in QCoreApplication unless there's a *much* better control of it. It would have to be used automatically by all top-level windows and it would have to be in-sync with setQuitOnLastWindowClosed -- in other words, ref() should be at least the number of top-level windows opened and maybe + 1. My argument against this solution is that when I tell the application to Quit, I expect it to do it. I certainly don't expect it to continue running in the background until certain services finish running, in the background. 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. 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. > Thiago did also offer the solution of a separate service providing the > refcounted quit functionality, but the problem with that is that all > libraries and applications need to use the same ref/deref code otherwise it > won't work. If I create a separate library with a service providing that > functionality it wouldn't help because there would be no guarantee that all > apps and libraries would use it. The solution would need to be in Qt. It > works in KDE of course because all KDE libraries and applications use > KGlobal::ref and deref, which perpetuates our walled garden. They already do. The KGlobal::ref()/deref() function is already separate and all libraries need to use it. Unless you can come up with a good integration with the window count, it will be a separate solution *anyway*. -- 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 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 should have been more clear I guess. When I wrote kjob there I meant a > > library for asynchronous job execution containing kjob, kcompositejob and > > perhaps the rest of the contents of kdecore/jobs > > ahh... unless your intent is to provide your own implementation of > KIO, "asynchronous job execution" involves more than just > kdecore/jobs. No it does't (well, except a job-tracker gui). KIO is async IO on top of KJob, you can very easily use plain KJob to do other stuff. KJob is just a contract to the outside how an async job looks and behaves like and it covers the common functionality of such jobs. Anything that you need to implement on top of kjob is custom to your problem space anyway. The only thing that really is not in kdecore is the mentioned job-tracking ui which allows for monitoring, cancelling etc. of the jobs (thats in kdeui though IIRC). Andreas -- All the troubles you have will pass away very quickly.
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 KLocale, KConfig, KMimeType etc. Some developers decide KLineEdit is not worth it and create a library in kdesupport, other developers decide it is worth it and create a library in kdelibs. I think we should create a facility which is better than kdesupport at accomodating those who don't think it's worth it to inter-depend on the KDE platfrom, but still want to be part of the KDE community, the KDE release schedule, and the KDE brand, and create a library which can be marketted and accessible to Qt developers as something useful. I think that can be done to some extent without losing functionality by (1) using different designs than 'share code with inheritance' and do more delegation to functionality providing classes instead (2) moving platformy stuff 'higher' (the apps still depend on the platform, where the functionality you're talking about is moved to). > > Of course in an ideal world, QLineEdit would get all the KLineEdit > features, but that's not going to happen and we know it. > Right. That doesn't mean we have the current situation can't be improved. > Albert
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? Discussed it already, it's in the archives, search them. Albert > > -Todd
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 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 will lead us to either less functionality or repeated > >> > code. > >> > >> How so? The libraries that are in kdesupport (such as attica to pick the > >> first) could just as easily be in kdelibs. If it was in kdelibs, would > >> you object to moving it out? What loss of functionality or repeated code > >> would occur if attica was moved out (imagining it was in to begin with). > > > > Of course attica won't lose any functionality becuase it is Qt only > > already. But if attica had been designed to be a KDE library and not as a > > Qt-only library it would be using KLineEdit instead of QLineEdit, so > > obviously moving it out of kdelibs (which i guess in your world means > > stop using KLineEdit) would be a functionality loss. > > > > Albert > > That depends on where KLineEdit appears in kdelibs and where attica > appears. The library KLineEdit is in, kdeui or whatever, could be a Tier 1 > or Tier2 library in the scheme I wrote about on the wiki. Tier1 doesn't > mean no QtGui or anything like it. > > If the attica developers don't actually need the extra completion modes > provided by KLineEdit, they could make it attica a Tier1 or Tier2 library, > depending on whether they need something else from kdelibs. > > Using KLineEdit instead of QLineEdit does not necessarily provide extra > functionality if the features it provides are not used. 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. 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
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 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 will lead us to either less functionality or repeated >> > code. >> >> How so? The libraries that are in kdesupport (such as attica to pick the >> first) could just as easily be in kdelibs. If it was in kdelibs, would >> you object to moving it out? What loss of functionality or repeated code >> would occur if attica was moved out (imagining it was in to begin with). > > Of course attica won't lose any functionality becuase it is Qt only > already. But if attica had been designed to be a KDE library and not as a > Qt-only library it would be using KLineEdit instead of QLineEdit, so > obviously moving it out of kdelibs (which i guess in your world means stop > using KLineEdit) would be a functionality loss. > > Albert That depends on where KLineEdit appears in kdelibs and where attica appears. The library KLineEdit is in, kdeui or whatever, could be a Tier 1 or Tier2 library in the scheme I wrote about on the wiki. Tier1 doesn't mean no QtGui or anything like it. If the attica developers don't actually need the extra completion modes provided by KLineEdit, they could make it attica a Tier1 or Tier2 library, depending on whether they need something else from kdelibs. Using KLineEdit instead of QLineEdit does not necessarily provide extra functionality if the features it provides are not used.
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 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 will lead us to either less functionality or repeated code. > > How so? The libraries that are in kdesupport (such as attica to pick the > first) could just as easily be in kdelibs. If it was in kdelibs, would you > object to moving it out? What loss of functionality or repeated code would > occur if attica was moved out (imagining it was in to begin with). Of course attica won't lose any functionality becuase it is Qt only already. But if attica had been designed to be a KDE library and not as a Qt-only library it would be using KLineEdit instead of QLineEdit, so obviously moving it out of kdelibs (which i guess in your world means stop using KLineEdit) would be a functionality loss. Albert > > We could simply make it a goal (or condition) of modularisation to not end > up with less functionality or duplication. > > > Less mandatory internal dependencies via plugable > > backends/functionality/whatever might be a good idea though. > > > > Albert
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 guess. When I wrote kjob there I meant a
>> library for asynchronous job execution containing kjob, kcompositejob and
>> perhaps the rest of the contents of kdecore/jobs
>
> ahh... unless your intent is to provide your own implementation of
> KIO, "asynchronous job execution" involves more than just
> kdecore/jobs. You have to suck in almost all of the classes in
> kdelibs/kio/kio, which of course depends on libkdecore.
I'm afraid I don't know kio to that kind of detail. Could that stuff also be
in a kjob library?
I'm more talking about kimap. Of kde stuff, That uses kjob and kmime.
kde-devel@bishop:~/dev/src/KDE/kdepimlibs/kmime{master}$ grep -h include * |
egrep -i "<(k|K)" | sort | uniq
#include
#include
#include
#include
#include
#include
# include
#include
#include // for kFatal()
#include // for strcasestr
#include
#include
#include
#include
#include
kde-devel@bishop:~/dev/src/KDE/kdepimlibs/kmime{master}$ cd ../kimap/
kde-devel@bishop:~/dev/src/KDE/kdepimlibs/kimap{master}$ grep -h include * |
egrep -i "<(k|K)" | sort | uniq
#include
#include
#include
#include
#include
#include
#include
* #include
#include
Even though this is quite few dependencies on KDE stuff, it could even be
less. kimap only uses KGlobal for K_GLOBAL_STATIC. Qt provides the same
functionality, though not as public API (currently) so that's one down
potentially.
kimap could depend only on Qt, KJob, KMime, and KLocale with some re-
arrangement of the existing kdelibs. That would make it far more accessible
to Qt developers. The only Qt developer I'm aware of to use kimap actually
forked it to pretty much as I described above (he also took out the KLocale
dependency). When people have to fork stuff because it's not modular enough
it means we can do better.
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 thinking about it long before KDE5. And we have to. Qt has its own release cycle. If we don't start thinking about this stuff now we will end up with an idea for KDE5 which requires stuff in Qt that nobody tried to put in there, and that gets vetoed/rejected when attempting to put it in. Qt won't magically grow features that KDE needs. Lets get stuff in there/rejected/vetoed now so that KDE5 is just a 'deprecate old stuff, use Qt stuff that we worked on getting in there' step to the extent possible. I figure there's no harm in not waiting until the summer and started on the mailing list now. At the very least it's discussion points for the summer sprint.
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, but i do, less internal dependencies is a bad > idea as it will lead us to either less functionality or repeated code. How so? The libraries that are in kdesupport (such as attica to pick the first) could just as easily be in kdelibs. If it was in kdelibs, would you object to moving it out? What loss of functionality or repeated code would occur if attica was moved out (imagining it was in to begin with). We could simply make it a goal (or condition) of modularisation to not end up with less functionality or duplication. > Less mandatory internal dependencies via plugable > backends/functionality/whatever might be a good idea though. > > Albert
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 there I meant a > library for asynchronous job execution containing kjob, kcompositejob and > perhaps the rest of the contents of kdecore/jobs ahh... unless your intent is to provide your own implementation of KIO, "asynchronous job execution" involves more than just kdecore/jobs. You have to suck in almost all of the classes in kdelibs/kio/kio, which of course depends on libkdecore.
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 kjob there I meant a > library for asynchronous job execution containing kjob, kcompositejob and > perhaps the rest of the contents of kdecore/jobs > > > 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. > > KLocale, KConfig, KStandardDirs, KMimeType and it's associated runtime > services etc etc are also in kdecore. Why should a Qt application wanting > to use kjob have to take all that stuff as well? I'm not sure if you read > the wiki page or the linked mailing list thread in it? 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. > > > Christoph Feck (kdepepo) Sorry, I misinterpreted your original mail, got blended by the (wrong) idea of ripping out stuff from KDE libraries just to make them Qt libraries. 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. Christoph Feck (kdepepo)
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 will lead us to either less functionality or repeated code. Less mandatory internal dependencies via plugable backends/functionality/whatever might be a good idea though. Albert
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, > are entirely optional), so it can be used by Qt applications. Please read the Techbase page Steve linked to in his message. Then think again. Regards, Ingo signature.asc Description: This is a digitally signed message part.
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 kjob, kcompositejob and perhaps the rest of the contents of kdecore/jobs > 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. KLocale, KConfig, KStandardDirs, KMimeType and it's associated runtime services etc etc are also in kdecore. Why should a Qt application wanting to use kjob have to take all that stuff as well? I'm not sure if you read the wiki page or the linked mailing list thread in it? 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. > > Christoph Feck (kdepepo)
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. Christoph Feck (kdepepo)
