--nextPart12468401.Yecetr8EXL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 14 February 2005 10:06, Havoc Pennington wrote: > > the application with a systray entry would only publish data, (and > > receive event notifications, for instance "the user wants to see a > > context menu for this entry") and not have anything to do with the actu= al > > presentation or management of the GUI. this immediately puts some limits > > on the system tray, allows the host app to sanely and powerfully manage > > the information in its display and separates the publish/display action= s. > > This is a different problem space than what we discussed at XDevConf. > You're talking about some form of notification system here, our if you mean a "notification system" in the sense of what we have in KNotify= ,=20 no. if you mean a "notification system" in the sense that the application=20 wanting to appear in the system tray and the system tray itself (which may = be=20 a non-gui representation for e.g. accessibility) communicate via IPC, yes.= =20 > discussion of that was "we need to know what the interaction designers > want it to do, then we can discuss it after that" and we moved on. > > For applets the people in the room (Owen, Lubos, clee, Lars Knoll, > myself, probably I'm forgetting someone) felt we had a better idea what > the desired design would be like. (Maybe we didn't, though it sounds > like you're disagreeing on implementation, not design.) for applets, yes, i think we agree on the concept that cross desktop applet= s=20 are important. how that will happen is the big question. > What we=20 > discussed was to have both in-process applets (which would be desktop- > specific) and out-of-process (which would be sort of like the system > tray spec). it's that last part that gives me chills. the system tray spec sucks and i= =20 don't want to spend the next 3-5 years maintaining similar suckage for pane= l=20 applets. if we open the doorway to XEMBED applets as a x-platform standard= =20 for KDE4, it won't be removable for a long time. this is a non-trivial=20 decision, and i would far prefer something that allows me to make kicker mo= re=20 than a lobotomized gray rectangle. i understand the needs of applet writers= ,=20 but please consider the needs of panel writers and the users who rely on=20 those panels. > As an aside, I think most of your XEMBED problems were probably due to a > bad implementation of it; I don't think the Qt XEMBED widget was ever > really finished? I could be wrong. But anyhow, that spec works fine for > GNOME applets and such. the GNOME XEMBED implementation allows me to take a popupmenu that lives in= =20 the applet's process and manipulate it and then show it in the host panel's= =20 process? this is the trivial example i keep using because: a) it's trivial= =20 and i haven't seen it able to be done yet, and b) it's a real world example= =20 used by kicker. > I agree with you that some kind of script approach (like Apple > Dashboard) would be very interesting. yes. i'll start looking into this and keep you abrest of that research. it= =20 won't start until after KDE 3.4 is out and i start working on the next=20 iteration of kicker. > Can we keep conceptually separate the various discussions though: > - applets check > - "some kind of notification system designed top-down" i don't think this is in-scope here. in KDE notifications are much more tha= n=20 what we're discussing here and i think that makes sense.=20 i keep trying to describe a system tray that works over IPC and you and Owe= n=20 keep coming back at it with "notification system". i hope this is just a=20 communication error where we are using different words for the same thing. for me and those whom i support with that code, the system tray is not just= a=20 notification system. at least not on our platform. while it is not the plac= e=20 to park desktop-neutral applets and minimized applications, the system tray= =20 is more than simply a notification system. this can (and will) be=20 accomplished in a sane manner without functionally eviscerating it. more li= ke=20 performing an apendectomy, really ;) > - support Windows-style tray icons check > - how to implement vs. what the design specs are sometimes these two things have effects on each other. as much as possible= =20 i'll keep them separate, but where implementation and design interact i thi= nk=20 it's important to acknowledge those interactions. =3D) > I feel that we have to continue to support the current tray icon spec, > since *tons* of apps are using it; and given that, it may as well be the > answer for "Windows-style tray icons"; for a new spec, we should start > with a designed UI that makes more sense. Tray icons are a broken idea > inherited from some ancient Windows version, MS itself keeps trying to > get rid of them; we should just support them as a back compat thing and > replace with some better-thought-out features. agreed. if you read the rest of this thread on kde-core-devel i think you'l= l=20 see i've thought a fair amount about this and have some half-decently=20 structured thoughts on this. =2D-=20 Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 --nextPart12468401.Yecetr8EXL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCEOcZ1rcusafx20MRApxkAKCnzHQoeqgzvN13RqS6Lgk0U8fzAACeMYz0 OOYhXG/WHGS4TPzya0eoCmc= =z7ax -----END PGP SIGNATURE----- --nextPart12468401.Yecetr8EXL--