policy change related to kdelibs snapshots

Tue Jul 11 17:47:38 BST 2006

On Tuesday 11 July 2006 6:39, Gary Cramblitt wrote:
> For example, it appears that a decision was made to remove KSystemTray from
> kdelibs?  

no. and there was great misunderstanding around this change, apparently. let's 
see if i can sort it out once and for all:

ksystemtray provides a system tray implementation that does a few things 
automatically for your app: a context menu with things like application quit 
and hiding/showing the associated window.

unfortunately, ksystemtray was broken in some ways (didn't do the xdg thing), 
used the old xembed code and now duplicates qsystemtray in qt 4.2.

so what i did was port ksystemtray to be a subclass of qsystemtray. this 
limited the amount of code in kdelibs, removed the brokenness and cleaned up 
the api considerably.

the "problem" was that there is no middle click support in qsystemtray because 
(surprise!) that's not portable. i did try using an eventfilter on the 
systray just in case that would work, but nope. that said, i'm really 
unconvinced that that is what the systemtray is there for.

as for why it took a qwidget rather than a qobject for a parent, it's pretty 
simple: it needs a widget to hook up the show/hide window stuff. if you don't 
need that (which is most of what ksystemtray adds for you) then you probably 
don't need ksystemtray (and can just use qsystemtray). if you really do need 
that context menu but don't have a widget to pass it and want it 
automagically memory managed, well, that is an issue (albeit a very small 
one) but not one i see in the code base right now.

note that qwidget is a qobject that also takes a qwidget as a parent ;)

and finally, seli and i laid out a plan for a new, improved mechanism to 
replace most of our systray usage in kde4 based on seli's ideas and 
conversations we had in the last 2 years.

> From my perspective, this "decision" came from nowhere. 

it came from looking at each class in kdeui and determining it's current usage 
and future usefulness. yes, change goes against the human grain, but every it 
may be just what's needed every 5-6 years .. 

thinking about what might help things ... do you think it would help you if a 
message was posted to kde-core-devel with a subject line such as "[API] 
<classname>" with the API change noted in it when such changes are made?

> Why was  
> this decision made and what am I supposed to use for my KTTS user realtime
> management gui instead?

what exactly does your "KTTS user realtime management GUI" require 
interaction-wise?

> regularly.  But I'm not sure the needs of application devs are being fully
> considered.

i'm more of an application developer than a library developer, and i find the 
current status painful as well. my hope is that if we push hard enough right 
now instead of bogging down (again!) that we can get past this library hurdle 
and start doing app devel.

> From my perspective as a part time app dev, there is a disturbing tendency
> to discard functionality before a good alternative is fully ready.  For
> example, I have concerns about dbus.  I fear we may have made a mistake in
> jumping to an immature dbus architecture. 

just as i would be remiss to second-guess the design of ktts without actually 
delving into it, i would suggest it's not helpful for application developers 
to do the same to the library developers.

there was no way to know what dbus support would take until we started using 
it. it was developed first at trolltech, then implemented in a branch in kde 
svn, then several apps were ported to it immediately and in Trysil we ironed 
out most if not all of the kinks (including the "calling dbus interfaces from 
within the same app" and "starting dbus on desktop log in" problems) and 
identified the rest...

to speak candidly, i think what's happening is that the length of time that 
kdelibs is taking is making application devs question the lib devs (to draw a 
largely artificial line between the two ;). this is unfortunate and needs to 
be addressed. a kdelibs development modus that is more useful for app devs 
should help a lot, which is the point of this thread.

> implementation so that devs can code against it and evaluate it, but how do
> you maintain two IPC
> implementations in a single library?

exactly why what you suggest was not done. not to mention people would just 
hold on to their dcop stuff and dbus would remain half baked and we'd ship a 
mess with kde 4.0.

> What I'd like to see is a process where someone proposes a change,
> announces it on kde-core mailing list, stating reasons for change,
> alternatives to be used instead, and stating when the change will occur. 

so instead of doing this in high-bandwidth face-to-face meetings like Trysil 
or in real time on irc you'd like this to be done one kde-core-devel 
where -everyone- can bikeshed to their hearts content? i think this is 
inserting bureaucracy at the wrong point in the timeline.

earlier i suggest a reporting mechanism for API changes: an email to 
kde-core-devel with "[API] <classname>" as the title. would that work?

> Something like this:  " I plan to remove KFoo from kdelibs because 1) it is
> lame, 2) it is broken, 3) coolo says it is bad.  Instead, please use KBar. 
> I have added KBar to the library for you to start migrating your apps. 
> Instructions are in kbar.h.  If nobody violently objects, I will remove
> KFoo on nn aaa nnnn ( two weeks from today)."

this is good for API decisions that:

 a) are far reaching
 b) have not been discussed elsewhere (e.g. at a face-to-face with the 
involved devs)

otherwise i don't really see the point.

> The parallel time period 
> should be appropriate for the level of disruption the change requires.  A
> minor change could be implemented in a week; a major change for a month or
> two. 

.. and kde 4.0 in 3 years time.

> Before removing KFoo, the implementor should give some consideration 
> to whether adequate feedback has been received, especially from app devs. 
> Silence isn't necessarily a good thing.  It may mean that nobody has had
> time to evaluate the change.

so we just sit on our hands? no.. lib devs need to be able to judge things and 
we have a number of tools at hand to help with that ranging from lxr.kde.org 
to code in svn to experiment on to our logical minds. app devs can (and 
should) certainly provide feedback but waiting for that to happen would 
likely induce a molasses like effect on development.

> It would be really nice if there were a single place (wiki?) where I could
> see all the upcoming changes listed on some sort of calendar.  "Hmm, I see
> they plan to remove KSystemTray in two weeks.  My app is using that. 
> What's up with that?  I better look into <fill in alternative> and provide
> feedback before it is too late."

that would be cool. just need people to keep it up to date. good luck ;) with 
the emails to kde-core-devel, this could be somewhat automated. and i think 
it's unecessary to know when kdelibs devels =will= do someting, it's more 
important to know that if you update svn from a july 1 checkout to a july 10 
checkout what will have changed.

> Lest anyone get wrong impression, I really appreciate the hard work devs
> have/are putting into kdelibs.

=)

-- 
Aaron J. Seigo
Undulate Your Wantonness
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060711/51a1228d/attachment.sig>