[Panel-devel] System tray

[Georges A.K.]

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 <l.lunak at suse.cz> 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-0002.bin