Lubos, have you looked at my proposition ? I'm attaching a new version (just added a new option and modified another one). Georges. On 7/1/05, Lubos Lunak wrote: > On Thursday 30 of June 2005 20:06, Aaron J. Seigo wrote: > > On Thursday 30 June 2005 08:24, Lubos Lunak wrote: > ... > > > systray[6], yet you don't like my proposals how to solve it and I don't > > > see anywhere how you would like to solve them. > > > > i'd like to see it solved by having a some simple IPC done between > > applications and the systray. i don't want it to require an X window, and > i > > don't want any XEmbed'd widgets. > > My patches then clearly are not good for this, for these and more reasons. > > > > - if KNode suddenly starts showing number of messages too, is it > suddenly > > > ok for it be minimized to the tray too? > > > > sure. > > > > > - how do you want to solve the close button mess, with some apps > quiting > > > and some not (I hope you see a certain problem with "solving" it using > > > the "this app will actually not quite, it will just hide, got it?" and > > > "are you really sure you want to quit?" dialogs)? > > > > this is the whole "what is a service, and what isn't" disccusion all over > > again. "services", which are capabilities that are not tied to a window > > (e.g. instant messaging, audio players) ought not quit until all elements > > are dismissed. every thing else which is tied to a specific, usually > > visual, context and meaningless without it should behave like any other > > window-centric app. > > I see. KNode is no service, but it starts showing a number of messages and > it > suddenly is, with all the consequences. > > > > - you're perfectly fine with having two completely different ways of > > > implementing e.g. a CPU monitor for the panel? > > > > if you're asking if the systray is the right place for a cpu monitor, i > > don't think so, no. i also don't see a way to stop that from hapenning by > > policy that doesn't make other valid uses impossible at the same time, > > however. > > Ok, this seems to be my mistake, so you don't intend to use the systray for > > what the applets are a better fit. Even though AFAICS a CPU monitor > perfectly > fits your description belong of what the systray should be. > > > > > , take more time for developers (note how i'm > > > > always trying to make things easier for people who would like to make > > > > KDE better?) > > > > > > Like, by giving them two ways of doing things? You said in one of the > > > mails in the threads that something (KNetLoad or whatever, I don't > > > remember) is a systray icon instead of an applet because that was > simpler > > > for the developer. Sadly, I can't find that post right now, and I also > > > can't find a post somewhere by an author of similar (or even this) > > > utility where he said he had converted his network monitor systray to > an > > > applet, which was fine, except that it doesn't work without KDE now. > > > People don't prefer writing systray apps to applets because it's > simpler > > > or whatever, they do that because it's more portable. > > > > once again you are taking what i say and changing the context. good job! > > > > when i've talked about simple vs hard i've been discussing it in the > > context of things like kmail which would, were they to use a panel APPLET > > versus a systray ICON, mean that they would have to set up a DCOP > > communication between the applet and the application and manage > > starting/stoping the applet. it would also be another lib for them to > > install and probably 2-3x the LOC for the applet vs the icon. > > You're doing a good job too. I don't remember having ever talked about > KMail's applet. KMail's always been case 1) systray icon with a mainwindow > associated, which should be moved to the taskbar, not case 2) applet-like > systray icons where the mainwindow is the icon itself, which should become > applets (in my proposal at least). No DCOP or anything like that, no > complexity added. > > In fact, given you cpu monitor comment, we probably agree on my 2). It's > just > that you still don't get what I mean with 2) and keep refusing it because of > > arguments based on things that don't belong to 2) at all. > > > > > BUT all of this is ballanced against the MOST important > > > > point which you constantly forget to add: > > > > > > > > moving them out of the systray doesn't substantially fix anything > > > > > > Last time I checked, everybody thought systray was a random mess that > > > sucked in various ways, and we had two ways of adding applets to the > > > panel. > > > > well, no shit sherlock! god this conversation is really starting to try > my > > patience. > > Well, don't worry anymore, I give up. We seem to have some fundamental > misunderstanding or a communication problem or whatever. You don't get what > I > say, I apparently don't get what you say, this is leading nowhere. You're > the > boss, do whatever you want with the systray. > > > > - what do you want to do with those you don't want in systray (and how > do > > > you want to achieve that, just ask the authors to be nice)? > > > > i don't think we can ever fully lock out clever programmers, but we can > > certainly educate them, yes. > > > > > > i don't know how many times i can say this before just throwing my > > > > hands up in the air and giving up completely on the matter. this is > now > > > > probably the 4th or 5th forum in which i've communicated this. what > > > > part is difficult to understand? > > > > > > See above. For the 4th or 5th time, I think the basic problem is that > > > nobody has really specified what the systray is. > > > > here's my take: > > > > it should be a place to put continuous informational feedback > > representations and provide small light-weight interfaces to running > > services that otherwise may not be available via a GUI. > > > > continuous informational feedback -> that's something that needs to be > > shown all the time and so is not a candidate for a passive popup (e.g. > your > > unread mail count). a hallmark of these items is that they aren't driven > by > > events but are equally important during periods of no events. > > > > services -> capabilities which, from a user's perspective, are not tied > to > > a window > > With the current status of everybody being confused about the purpose of > the > systray, I'm sure it will be suddenly clear with such good description like > > this and examples like the KNode one. > > -- > Lubos Lunak > KDE developer > --------------------------------------------------------------------- > SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org > Drahobejlova 27 tel: +420 2 9654 2373 > 190 00 Praha 9 fax: +420 2 9654 2374 > Czech Republic http://www.suse.cz/ > _______________________________________________ > Panel-devel mailing list > Panel-devel at kde.org > https://mail.kde.org/mailman/listinfo/panel-devel > -------------- next part -------------- A non-text attachment was scrubbed... Name: systray_config.ui Type: application/x-designer Size: 9462 bytes Desc: not available Url : http://mail.kde.org/pipermail/panel-devel/attachments/20050705/78be2ad9/systray_config-0001.bin