policy change related to kdelibs snapshots

[Gary Cramblitt]

On Tuesday 11 July 2006 12:47, Aaron J. Seigo wrote:
> 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 ;)

Thanks for the explanation.  It would have been helpful if this information 
were posted for all to see before the changes were committed.

It sounds like qsystemtray will meet my needs except for one thing.  I'd like 
to provide user with ability to map global shortcuts to the speech operators 
(pause, resume, stop/delete).  Do you think I'll be able to do that with 
qsystemtray or ksystemtray?

> 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.

It would be nice to know what those plans are, but I'm guessing it is too 
early for you to do that.

>
> > 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 ..

I'm not arguing against change.

>
> 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?

If you mean adding a CCMAIL to the commit, probably not.  I read all the 
commit messages for kdelibs every day.  For most of them, its pretty 
difficult to understand what is going on without digging through a lot of 
code.  Something part-timers like me don't have time for.  Furthermore, 
finding out about the change at commit time is too late.

>
> > 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?

It provides a menu with "Pause",  "Resume", "Stop/Delete", and "Configure" 
(which launches KCMKttsMgr in a separate process), "About", and "Help".   It 
also provides a balloon status message on mouse hover.

>
> > 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.

Since my dbus concerns are not relevant to this thread, I'll post about them 
separately.  My main point is that there was no transition.   We talked and 
talked about changing to dbus (at least a year now, but it seems longer).  
When it finally happened, it happened suddenly with zero opportunity to 
evaluate.  Wasn't there *some* intermediate implementation possible?  
Couldn't the dcop objects have stayed in the library for at least a few 
weeks?

> 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.

If the QtDBus implementation had been added with an announcement that "dcop 
will be deleted in 3 weeks", I believe most would have cooperated, including 
me.

> > 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.

I am not saying that face-to-face and irc should not be done.  I am not saying 
that changes should not be made.  I am not saying that "permission" from the 
user community is necessary before changes are made.  I am saying that it 
would be better if the decision makers (and implementors) kept the rest of us 
better informed as to what is going on.

>
> 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.

Either kdelibs devs *want* app devs involved in the process or not.  From most 
of your reply, I have the sense that you don't want our input.  OK, message 
received.  Goodbye and good luck.  (I sincerely hope that isn't what you're 
saying and that I've misunderstood.)  I'm operating under the assumption that 
kdelibs will be a better product if application developers are more involved 
in the process.

Is it so terrible to ask that you at least keep us informed about what is 
going on, especially when it involves significant api changes?

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

-- 
Gary Cramblitt (aka PhantomsDad)
KDE Text-to-Speech Maintainer
http://accessibility.kde.org/developer/kttsd/index.php