--nextPart1606860.NsLUNS22mF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline i'm CC'ing kde-core-devel on this, i hope you don't mind. there isn't anyth= ing=20 inflamatory or personal in your email, so i don't see why it would be a=20 problem. (for k-c-d readers this is a discussion about the upcoming changes to apple= ts=20 and the system tray that will affect kicker in KDE 4. see=20 http://aseigo.bddf.ca/?pID=3D1092 for the brief write up i did that Own is= =20 responding to) On Saturday 12 February 2005 05:59, Owen Taylor wrote: > 1. Come up with a new, good notification API (probably using DBUS) > that meets the requirements of a KDE UI design and a GNOME UI > design. it's more than notification. if we look at what people actually use the sys= tem=20 tray for, notification is one of the things its used for. if we say "only=20 notification, every one else go elsewhere" we will end up with the same=20 problems, only not in the system tray. instead, we'll have a bunch of apple= ts=20 on the panel taking up even more space and committing the exact same abuses= =2E=20 not a brilliant solution. we must, IMHO, allow for more than notification in the system tray, while=20 setting out some basic guidelines that eliminate things like "using the=20 system tray as a means to keep your app running and accessible even with no= =20 windows showing". > 2. Do something to enable Windows tray icon compatibility for things > like Wine. good idea. > 3. Write a spec for arbitrary GUI panel applets that uses XEMBED > but is better thought out than the systray ... allowing for > size notification, menus, and activation. (Add an applet...) i am vehemently against the use of XEMBED in kicker. i just got through=20 removing XEMBED usage in kicker, except the systray of course, due to the=20 number and scope of problems it created.=20 i hope you understand that it's more than a little frustrating to be the on= e=20 who is actually going to be implementing this stuff and who is saying,=20 "please don't hobble kicker by making me use XEMBED" only to be basically=20 ignored by those creating cute standards but who aren't going to be writing= =20 the code or maintaining the mess afterwards. > For 3, I think using XEMBED and out-of-process is a real gain. > > - Cross-desktop applets are useful ... agreed. let's find a better way to do them than via an out-of-process,=20 X11-specific mechanism. let's round up all the applets that we'd like to se= e=20 cross-desktop and see if there are commonalities amongst them that would=20 allow us to create a _scriptable_ applet. loading Python scripts into kicke= r=20 as an applet, for instance, is fairly trivial. it was actually done a coupl= e=20 years ago as a proof of concept, even. the question would be: what set of=20 Python interfaces would be required to give applet writers enough of a tool= =20 set to do what they need to? and hey! suddenly we'd open up applet writing to scripters. i don't know ab= out=20 your experience with vendors and writing these sorts of tools, but they see= m=20 to prefer script based solutions over writing in C/C++. YAST, Mandrake=20 Control Center and many others spring to mind. and this would also work in environments w/out X11! XEMBED is a tempting solution because we know it well, because it's near at= =20 hand. but it's a bad solution (see below for specifics); we just need to=20 apply some creativity and maybe a little extra groundwork to get something= =20 good. > - Ability to have an applet in the same address space of the > app. theoretically interesting, but history has shown this to be unnecessary. th= is=20 is what we have IPC for, and DCOP has shown that it's easy enough to use th= at=20 there is little benefit here. in fact, there are downsides to this, namely that the applications start=20 popping up applets on their own and users have to around cleaning up after= =20 them. people tend to customize their panels; it's not a place for apps to b= e=20 messing with on their own. that said, having applets that come and go with an application sounds like = a=20 bit of a usability mess, since now the applet (which is seen as a unique,=20 distinct entity from the application itself by a user) is now tied to the=20 app. it's bad enough that we have icons coming and going in the system tray= ,=20 moving this to general panel entries is worse. applets in the process of other apps also means that those other apps MUST= =20 remain responsive at all times. having parts of the panel GUI freeze up is= =20 not an option. in other words, the panel would suddenly rely on all sorts o= f=20 3rd party apps to "get it right" (which, looking at history, many/some won'= t)=20 to provide a proper user experience. > - Stability kicker deals with this just fine w/out xembed. in fact, it deals with it=20 better _now_ than it did when xembed was used. morover, even WITH xembed, i= t=20 was possible to crash kicker depending on what was happening at the moment= =20 the xembed'd widget went bye-bye on us. > The downside of XEMBED and out-of-process is that you have to > write X specifications and do IPC rather than just writing a > widget class for people to subclass. well, that's not true either. in KDE we have a subclass that does all the=20 XEMBED stuff for an ap using the system tray. the same could be done with a= n=20 in-process applet. this isn't a downside of XEMBED. the fact that it's=20 X-specific is. XEMBED gave us problems with drag and drop into applets, it gave us problem= s=20 with doing things like requesting the applets to give kicker an=20 applet-specific menu to show in a standard location (the applet handle menu= ),=20 it increased overhead as you have N processes with N event loops going on,= =20 etc... kicker in KDE 4 is not going to be the placid little grey square it current= ly=20 is. in KDE4, kicker will need to be able to ask an applet what sort of=20 information it's displaying, give it "stage directions" as to how to presen= t=20 itself and likely other interesting UI enhancement. well, unless i'm forced to use XEMBED, in which case forget about doing=20 anything truly interesting with kicker. XEMBED makes things slightly easier= =20 for certain types of application developers, primarily *vendors*. the=20 collateral costs are born partly by me and other panel developers, but most= ly=20 by our *users*. this is not an acceptable trade off in my mind. =3D( let's = find=20 something that works for everyone. > of your writeup. I dont't know if I fully understand the scope > of what you consider appropriate uses of the systray, but it's > clearly not about arbitrary unconstrained user interface. > If you allowed in-process embedding of arbitrary widgets, you'd > have most of the same problems that you discussed. i fear you didn't understand what i wrote then. =3D) the idea i'd like to see for the system is thus: o a DBUS bus that applications can publish "i have a system tray entry, he= re=20 are the details of it". the application would update this information as=20 state changed. think about autohiding icons, for instance, and the need to= =20 know the current state of an application (idle, important stuff happening,= =20 etc). o host apps (e.g. the systray applet in kicker) would consume this data to= =20 present an interface. the interface would be 100% under the control of the= =20 host app, including what to do when the user, for instance, right clicks on= =20 an entry versus left clicks on an entry. the application with a systray entry would only publish data, (and receive= =20 event notifications, for instance "the user wants to see a context menu for= =20 this entry") and not have anything to do with the actual presentation or=20 management of the GUI. this immediately puts some limits on the system tray= ,=20 allows the host app to sanely and powerfully manage the information in its= =20 display and separates the publish/display actions. =2D-=20 Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 --nextPart1606860.NsLUNS22mF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCD9uh1rcusafx20MRAmcbAJ9kSIC6aoQbsp9HkT1PVtEtA4baXgCgkRYM P7bSgT4HKgAptOYMXrIUoZo= =3U+R -----END PGP SIGNATURE----- --nextPart1606860.NsLUNS22mF--