KNotificationItem specification - first draft

Marco Martin notmart at gmail.com
Fri Sep 18 09:49:52 BST 2009


On Friday 18 September 2009, Michael Pyne wrote:
> On Thursday 17 September 2009 10:17:50 Marco Martin wrote:
> > just to keep things updated..
> > i've put the requirement of images in network byte order in the current
> > rev of the spec and updated our implementation accordingly
>
> Have you seen my feedback on the KDE implementation that I posted on
> Tuesday? There was a question as to whether it would be possible to query

sorry, totally slipped out :(
i'll respond right now :)

> for the position of the system tray icon for applications that want to
> create popups near the system tray.  Normally the (x,y) is provided to the
> application when a signal where it is needed is emitted (i.e. activate or
> contextMenu) but it may be useful for the application to know this (or an
> approximation) before a signal is ever generated by the user.  For
> instance, in the event of a complex tooltip (the spec's Markup section
> notes that complex tooltips may need to be application-generated)

the use cases for multiple systrays are multi monitor, where it's reasonable 
someone could want an identical panel on both of them.
other than that, since icons can have those four categories, it could also be 
that there are different systemtrays each one displaying a different subset of 
categories, that may or may not be the same (this will probably be the 
default, since the taskbar could implement some parts of the protocol in the 
future, to make task entries know about their associated systray entry, if 
any)

at the moment the notificationitem itself doesn't know anything about it's 
geometries, is the systray that sends the coordinated upon signals, we could 
do as Alex said, the systray passing to the item the coordinates upon 
registration (but it should be kept in sync, removed if that systray stops 
displaying that icon etc), quite complex but uuuh, yeah..

> If this is going to be too complex to work in at this point I can certainly
> workaround it in the application I'm worried about, but it would be nice to
> have.
>
> Regards,
>  - Michael Pyne


-- 
Marco Martin




More information about the kde-core-devel mailing list