KNotificationItem specification - first draft

Hello everyone,
In the past few months in KDE we worked on a new way to represent the
systemtray icons to overcome the following limitations:
-lack of communication between the systemtray area and the items, that
mean we don't know about their status, their importance of if they are
being used or not
-the xembed process is quite slow and doesn't give control to the
systray on the paining
-it's not possible to have more than one systray (useful in multi
monitor setups)

The new protocol is based upon D-Bus, and separates the presentation
of the items from the logic, in our case the painting is completely
controlled by Plasma and the applications registers via D-bus (with a
small clien library shared across KDE) to a central server, while
there can be zero or more instances of the systemtray.
if either the serve or no instances of systemtrays that supports this
protocol are registered the system will fall back using the old
freedesktop.org systray specification.

KDE has already a complete and working implementation of the protocol,
usedby several core applications

the specification is on gitorious:
http://gitorious.org/~notmart/xdg-specs/notmart-xdg-specs/commits/notificationitem

questions and comments are more than welcome

Cheers,
Marco Martin
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Aurélien Gâteau-3]

Hi,

I am probably a bit late at this, but thought I would ask anyway.

Why did you choose the term "KNotificationItem"? I am afraid this is
going to cause confusion with the existing notification systems.

A name like KSystemTrayItem would avoid such confusions. I know it is
probably not very appropriate because it describe a visualization rather
than the content, but I feel it would still be better than
KNotificationItem (Think about a new developer faced with choosing
between the KNotification and KNotificationItem classes...)

Aurelien

PS: To get more feedback about the spec, I suggest you generate an html
output of it and upload it somewhere.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Monday 07 September 2009, Aurélien Gâteau wrote:
> Hi,
>
> I am probably a bit late at this, but thought I would ask anyway.
>
> Why did you choose the term "KNotificationItem"? I am afraid this is
> going to cause confusion with the existing notification systems.

the choice of the name has been a bit painful, it has gone trough several
renames.
iirc this was chisen because in gnome and windows the systray is already
called notification area and we didn't want to confuse the current
implementation with the protocol, since the last goal is to remove some of the
icons from the system tray, probably representing the items of "application"
category in the taskbar, this would make the "SystemTray" term less meaningful

> A name like KSystemTrayItem would avoid such confusions. I know it is
> probably not very appropriate because it describe a visualization rather
> than the content, but I feel it would still be better than
> KNotificationItem (Think about a new developer faced with choosing
> between the KNotification and KNotificationItem classes...)
>
> Aurelien
>
> PS: To get more feedback about the spec, I suggest you generate an html
> output of it and upload it somewhere.

yeah, good idea, here it is:
http://www.notmart.org/misc/notificationitem

Cheers,
Marco Martin
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Aurélien Gâteau-3]

Marco Martin wrote:

> On Monday 07 September 2009, Aurélien Gâteau wrote:
>> Hi,
>>
>> I am probably a bit late at this, but thought I would ask anyway.
>>
>> Why did you choose the term "KNotificationItem"? I am afraid this is
>> going to cause confusion with the existing notification systems.
>
> the choice of the name has been a bit painful, it has gone trough several
> renames.
> iirc this was chisen because in gnome and windows the systray is already
> called notification area and we didn't want to confuse the current
> implementation with the protocol, since the last goal is to remove some of the
> icons from the system tray, probably representing the items of "application"
> category in the taskbar, this would make the "SystemTray" term less meaningful

I understand the reasons, but I still think this is confusing. Is it too
late to change the name, or can it still be brainstormed?

>> PS: To get more feedback about the spec, I suggest you generate an html
>> output of it and upload it somewhere.
> yeah, good idea, here it is:
> http://www.notmart.org/misc/notificationitem
Thanks for this!

Here are some corrections/suggestions:

3.3. Signals
3.3.1. NewTitle

I suggest reporting the new title as a signal parameter to avoid a
round-trip from the host to the item to fetch the text.

4.1.4. RegisterNotificationHost

Wrong method name in the prototype

7. Markup

Supporting markup means opening a whole can of worms: you can't count on
app developers to properly escape the content they send and you may end
up with using heuristics to determine whether the '<' character is a
single character or the beginning of a tag.

Since the content of tooltips aim to be short, I suggest not supporting
markup.

If you think this is too restrictive, then I suggest to either:
State that everything is markup and a '<' character should *always* be
escaped to '<'.

or:
State that if an item wishes to use markup, then it must enclose the
whole text in a <markup> tag.

In both cases you want to check the first implementations of
NotificationHost strictly enforce these rules.

8. Icons

You should also explicitly state the byte order of the image-data. Is it
ARGB, RGBA? is it endian-independent?

Aurelien
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

(dropping the other two lists as CC's as one list should be enough for
discussing this, and xdg is the most appropriate?)

On September 7, 2009, Aurélien Gâteau wrote:

> > the choice of the name has been a bit painful, it has gone trough several
> > renames.
> > iirc this was chisen because in gnome and windows the systray is already
> > called notification area and we didn't want to confuse the current
> > implementation with the protocol, since the last goal is to remove some
> > of the icons from the system tray, probably representing the items of
> > "application" category in the taskbar, this would make the "SystemTray"
> > term less meaningful
>
> I understand the reasons, but I still think this is confusing. Is it too
> late to change the name, or can it still be brainstormed?

it's not too late in the sense that we have until 4.4.0 in January when we
become committed to it.

what we didn't like about "System Tray" is that it doesn't really say what the
point of it is. "System Tray" is "where those things appear" while
"Notification Item" says "what those things are supposed to be doing".

there's also the issue that we classes like QSystemTrayIcon and
KSystemTrayIcon which complicates things further (as a Notification Item falls
back to that SystemTrayIcon implementation)

then there's the "System Tray Protocol Specification" on freedesktop.org:

        http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html

the two specs really have very little in common other than both can be used to
make an icon appear in the panel.

as for the root of the problem of "it's confusing", "notification area" is a
term used on a couple of platforms already, including the most widely used one
(Windows). it's not exactly a new term. in relation to notifications, those
things which pop up when an application asks to tell the user something,
actually relating these two things together semantically is a good thing IMHO:
they are both about pushing information to the user's attention and they
should probably coordinate in some fashion as well (e.g. in a visual
representation, it may make sense to have app notifications visually
associated with their notification item; possibly combine that with
notification item + task bar integration)

> Supporting markup means opening a whole can of worms: you can't count on
> app developers to properly escape the content they send and you may end
> up with using heuristics to determine whether the '<' character is a
> single character or the beginning of a tag.
>
> Since the content of tooltips aim to be short, I suggest not supporting
> markup.

it's a simple subset of markup and is something that app developers routinely
ask for, at times even with quite valid use cases ;)
 
> If you think this is too restrictive, then I suggest to either:
> State that everything is markup and a '<' character should *always* be
> escaped to '<'.

yes, if the spec says "markup" then this would be implied.

> or:
> State that if an item wishes to use markup, then it must enclose the
> whole text in a <markup> tag.

that would work as well. it's a small amount of overhead for not much pain. it
could also be that we look for the "<pre>" tag instead, and make markup the
default.

> 8. Icons
>
> You should also explicitly state the byte order of the image-data. Is it
> ARGB, RGBA?

ARGB.

> is it endian-independent?



--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Monday 07 September 2009, Aurélien Gâteau wrote:

> Marco Martin wrote:
> > On Monday 07 September 2009, Aurélien Gâteau wrote:
> >> Hi,
> >>
> >> I am probably a bit late at this, but thought I would ask anyway.
> >>
> >> Why did you choose the term "KNotificationItem"? I am afraid this is
> >> going to cause confusion with the existing notification systems.
> >
> > the choice of the name has been a bit painful, it has gone trough several
> > renames.
> > iirc this was chisen because in gnome and windows the systray is already
> > called notification area and we didn't want to confuse the current
> > implementation with the protocol, since the last goal is to remove some
> > of the icons from the system tray, probably representing the items of
> > "application" category in the taskbar, this would make the "SystemTray"
> > term less meaningful
>
> I understand the reasons, but I still think this is confusing. Is it too
> late to change the name, or can it still be brainstormed?

not until 4.4.0 would mean to break and unbreak the whole trunk again but oh,
well, got used to :)
but has to be -really- worth it and i don't see really better names right now,
systemtray is even more problematic

> >> PS: To get more feedback about the spec, I suggest you generate an html
> >> output of it and upload it somewhere.
> >
> > yeah, good idea, here it is:
> > http://www.notmart.org/misc/notificationitem
>
> Thanks for this!
>
> Here are some corrections/suggestions:
>
> 3.3. Signals
> 3.3.1. NewTitle
>
> I suggest reporting the new title as a signal parameter to avoid a
> round-trip from the host to the item to fetch the text.
>
> 4.1.4. RegisterNotificationHost
>
> Wrong method name in the prototype

whoops, corrected
>
> 7. Markup
>
> Supporting markup means opening a whole can of worms: you can't count on
yeah, i know :/
> app developers to properly escape the content they send and you may end
> up with using heuristics to determine whether the '<' character is a
> single character or the beginning of a tag.
>
> Since the content of tooltips aim to be short, I suggest not supporting
> markup.

i would love to dictate a really simple aspect,
i've seen that many aplications wrote their own tooltips to make really fancy
stuff, since with this spec this wouldn't be possible anymore (again the
problem is to know that those are icons and where it is) i don't think it's
really realistic to ask everybody to drop that feature, we dropped some of
them already that makes people not really happy...

> If you think this is too restrictive, then I suggest to either:
> State that everything is markup and a '<' character should *always* be
> escaped to '<'.

i think i like more this way

> or:
> State that if an item wishes to use markup, then it must enclose the
> whole text in a <markup> tag.
>
> In both cases you want to check the first implementations of
> NotificationHost strictly enforce these rules.

yes. and maybe strip the not allowed tags?
how it was done in the Notification spec in the end?

> 8. Icons
>
> You should also explicitly state the byte order of the image-data. Is it
> ARGB, RGBA? is it endian-independent?
>
> Aurelien
At the moment, (should make it more clear in the spec) is ARGB and is not
designed to be network transparent, so the endian should be the same of the
machine for both the client and the server

--
Marco Martin
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jon Cruz]

On Sep 7, 2009, at 10:11 AM, Marco Martin wrote:

> At the moment, (should make it more clear in the spec) is ARGB and  
> is not
> designed to be network transparent, so the endian should be the same  
> of the
> machine for both the client and the server

I'd say this point was a HUGE red flag.

For commercial app development (and here at home too) I've had to  
support remote X11 between different architectures. Especially since  
Mac's are officially UNIX(tm) one does not even have to install Linux  
on a mac to take advantage of this (although I often do).
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jon Cruz]

On Sep 7, 2009, at 2:36 AM, Aurélien Gâteau wrote:

>
> A name like KSystemTrayItem would avoid such confusions. I know it is
> probably not very appropriate because it describe a visualization  
> rather
> than the content, but I feel it would still be better than
> KNotificationItem (Think about a new developer faced with choosing
> between the KNotification and KNotificationItem classes...)

Even in Microsoft Windows, it has never been called "system tray".  
They had been careful from the beginning to call it the "notification  
area" in APIs, user documentation, etc. Early on some people outside  
of MS noticed "systray.exe" and so gave it a nickname.

So for developers who look into this at all, even Windows developers,  
should be able to cope with the industry standard term.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jannis Pohlmann-3]

On Mon, 7 Sep 2009 19:11:31 +0200
Marco Martin <notmart@...> wrote:

> On Monday 07 September 2009, Aurélien Gâteau wrote:
> > Marco Martin wrote:
> > > On Monday 07 September 2009, Aurélien Gâteau wrote:
> > >> Hi,
> > >>
> > >> I am probably a bit late at this, but thought I would ask anyway.
> > >>
> > >> Why did you choose the term "KNotificationItem"? I am afraid
> > >> this is going to cause confusion with the existing notification
> > >> systems.
> > >
> > > the choice of the name has been a bit painful, it has gone trough
> > > several renames.
> > > iirc this was chisen because in gnome and windows the systray is
> > > already called notification area and we didn't want to confuse
> > > the current implementation with the protocol, since the last goal
> > > is to remove some of the icons from the system tray, probably
> > > representing the items of "application" category in the taskbar,
> > > this would make the "SystemTray" term less meaningful
> >
> > I understand the reasons, but I still think this is confusing. Is
> > it too late to change the name, or can it still be brainstormed?
>
> not until 4.4.0 would mean to break and unbreak the whole trunk again
> but oh, well, got used to :)
> but has to be -really- worth it and i don't see really better names
> right now, systemtray is even more problematic

BTW, I wonder about the use of the org.freedesktop namespace. I know
this is only a draft but assuming we try to follow this new
freedesktop.org specification process now (which I'd like go through
one or two more revision threads because I remember I disagreed with a
few points), then I guess it'd be better not to use org.freedesktop
until the spec is adopted by others.

  - Jannis


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Monday 07 September 2009, Jannis Pohlmann wrote:

> On Mon, 7 Sep 2009 19:11:31 +0200
>
> Marco Martin <notmart@...> wrote:
> > On Monday 07 September 2009, Aurélien Gâteau wrote:
> > > Marco Martin wrote:
> > > > On Monday 07 September 2009, Aurélien Gâteau wrote:
> > > >> Hi,
> > > >>
> > > >> I am probably a bit late at this, but thought I would ask anyway.
> > > >>
> > > >> Why did you choose the term "KNotificationItem"? I am afraid
> > > >> this is going to cause confusion with the existing notification
> > > >> systems.
> > > >
> > > > the choice of the name has been a bit painful, it has gone trough
> > > > several renames.
> > > > iirc this was chisen because in gnome and windows the systray is
> > > > already called notification area and we didn't want to confuse
> > > > the current implementation with the protocol, since the last goal
> > > > is to remove some of the icons from the system tray, probably
> > > > representing the items of "application" category in the taskbar,
> > > > this would make the "SystemTray" term less meaningful
> > >
> > > I understand the reasons, but I still think this is confusing. Is
> > > it too late to change the name, or can it still be brainstormed?
> >
> > not until 4.4.0 would mean to break and unbreak the whole trunk again
> > but oh, well, got used to :)
> > but has to be -really- worth it and i don't see really better names
> > right now, systemtray is even more problematic
>
> BTW, I wonder about the use of the org.freedesktop namespace. I know
> this is only a draft but assuming we try to follow this new
> freedesktop.org specification process now (which I'd like go through
> one or two more revision threads because I remember I disagreed with a
> few points), then I guess it'd be better not to use org.freedesktop
> until the spec is adopted by others.

yes, the actual implementation uses org.kde right now,
this is just for the document, i can change it there as well, but anyways
until it's not adopted it's just an unofficial draft..

>   - Jannis


--
Marco Martin
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Monday 07 September 2009, Jon A. Cruz wrote:

> On Sep 7, 2009, at 10:11 AM, Marco Martin wrote:
> > At the moment, (should make it more clear in the spec) is ARGB and
> > is not
> > designed to be network transparent, so the endian should be the same
> > of the
> > machine for both the client and the server
>
> I'd say this point was a HUGE red flag.
>
> For commercial app development (and here at home too) I've had to
> support remote X11 between different architectures. Especially since
> Mac's are officially UNIX(tm) one does not even have to install Linux
> on a mac to take advantage of this (although I often do).

right now when the dbus spec is not supported (i.e. local instances of
NotificationItemWatcher and NotificationHost aren't on the bus) it falls back
to the xembed based systray, and is what happens also when using remote
displays, given that on the remote machine doesn't run a full blown workspace.

now i'm not sure about the current status of the tcp transport of dbus, but
once it works i don't see particular problems, big endian machines would have
to invert the bytes of the image by hand, that is something that somebody will
inevitably have to do in a mixed environment. i think it's possible to avoid
an extra field for that anyways

--
Marco Martin
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Jon Cruz]

On Sep 7, 2009, at 11:54 AM, Marco Martin wrote:

> now i'm not sure about the current status of the tcp transport of  
> dbus, but
> once it works i don't see particular problems, big endian machines  
> would have
> to invert the bytes of the image by hand, that is something that  
> somebody will
> inevitably have to do in a mixed environment. i think it's possible  
> to avoid
> an extra field for that anyways

A general approach has been to define things as network byte order...  
aka big-endian.

Regardless, it should be made explicit and the future use explicitly  
covered. If I recall correctly, X11 address this for datatypes by  
being explicit about data types and sizes, and then for multi-byte  
values the system automatically handles client/server differences in  
byte order.

This does come up for clipboard and drag-n-drop operations also. In  
fact, I recall having some problems with Qt/KDE color types not being  
defined correctly. The color format was 16-bit component values, but  
Qt/KDE gave 8-bit format for the 16-bit data. In that case 16-bit  
format would be converted automatically by the transport, but 8-bit  
format required some kludges and trying to standardize on the byte  
order, etc. The most likely cause was simply oversight on the part of  
Trolltech, combined with not enough time/resources to run some  
heterogenous tests.

It probably would be good if new protocols would avoid problems  
initially. Then we won't have to add work-arounds and such later.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On September 7, 2009, Jon A. Cruz wrote:

> On Sep 7, 2009, at 11:54 AM, Marco Martin wrote:
> > now i'm not sure about the current status of the tcp transport of
> > dbus, but
> > once it works i don't see particular problems, big endian machines
> > would have
> > to invert the bytes of the image by hand, that is something that
> > somebody will
> > inevitably have to do in a mixed environment. i think it's possible
> > to avoid
> > an extra field for that anyways
>
> A general approach has been to define things as network byte order...
> aka big-endian.

yes, this would make sense imo. while there is no non-local parts to this
system today, it likely will eventually have to deal with such things.

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Aurélien Gâteau-3]

[Dropping some CC as well]
Marco Martin wrote:

>> or:
>> State that if an item wishes to use markup, then it must enclose the
>> whole text in a <markup> tag.
>>
>> In both cases you want to check the first implementations of
>> NotificationHost strictly enforce these rules.
>
> yes. and maybe strip the not allowed tags?

Yes, you definitly want to strip the not allowed tags.

> how it was done in the Notification spec in the end?

(So I guess it shows I went through that with the Notification spec, uh? :))

Well, nothing was done, because it was too late. That's what I hope will
not happen with this spec.

The spec does not provide a way for an app to indicate whether it's
using plain text or markup. As a consequence, some apps send plain text,
others send markup... The default implementation (notification-daemon)
copes with that. In notify-osd we had to resort to regexes to strip
markup in an hopefully sane way.

The default implementation also does not strip unsupported markup, so
applications started to make use of it as well.

Aurelien
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Aurélien Gâteau-3]

Aaron J. Seigo wrote:

> it's not too late in the sense that we have until 4.4.0 in January when we
> become committed to it.
>
> what we didn't like about "System Tray" is that it doesn't really say what the
> point of it is. "System Tray" is "where those things appear" while
> "Notification Item" says "what those things are supposed to be doing".

Agreed.
[snip]

> as for the root of the problem of "it's confusing", "notification area" is a
> term used on a couple of platforms already, including the most widely used one
> (Windows). it's not exactly a new term. in relation to notifications, those
> things which pop up when an application asks to tell the user something,
> actually relating these two things together semantically is a good thing IMHO:
> they are both about pushing information to the user's attention and they
> should probably coordinate in some fashion as well (e.g. in a visual
> representation, it may make sense to have app notifications visually
> associated with their notification item; possibly combine that with
> notification item + task bar integration)

I believe it's called "Notification Area" on Windows because it is very
strongly tied with Windows notifications: the MSDN states this:

"Does your program need to display a notification? If so, you /must/ use
a notification area icon."
(http://msdn.microsoft.com/en-us/library/aa511448.aspx#rightui)

Since this spec aims to be desktop independent, whether notification
bubbles and notification items should be visually grouped is an
implementation detail. It should not be up to the spec to suggest this.

I am not that much into fancy names, but I thought about it a bit and
came with those semi-lame ideas:

- AppSatellite
- SatelliteItem

>> Supporting markup means opening a whole can of worms: you can't count on
>> app developers to properly escape the content they send and you may end
>> up with using heuristics to determine whether the '<' character is a
>> single character or the beginning of a tag.
>>
>> Since the content of tooltips aim to be short, I suggest not supporting
>> markup.
>
> it's a simple subset of markup and is something that app developers routinely
> ask for, at times even with quite valid use cases ;)

I would be interested in these use cases.

>> If you think this is too restrictive, then I suggest to either:
>> State that everything is markup and a '<' character should *always* be
>> escaped to '<'.
>
> yes, if the spec says "markup" then this would be implied.

It should be explicitly stated in the spec IMO.

>> or:
>> State that if an item wishes to use markup, then it must enclose the
>> whole text in a <markup> tag.
>
> that would work as well. it's a small amount of overhead for not much pain. it
> could also be that we look for the "<pre>" tag instead, and make markup the
> default.

Doing it this way is not good. It can fail in the (admittedly rare) case
where the plain text contains the closing tag.

>
>> 8. Icons
>>
>> You should also explicitly state the byte order of the image-data. Is it
>> ARGB, RGBA?
>
> ARGB.

Same thing, it should be explicitly mentioned in the spec. Together with
endianess dependency or independency (note that Qt ARGB format is
endianess dependent).

Aurelien
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Sat, Sep 05, 2009 at 01:34:14AM +0200, Marco Martin wrote:
> The new protocol is based upon D-Bus,
>
my initial reaction to that is "argh". other than the currently
non-existing remote transport (as already raised by somebody else),
there is also the logical association of the application with the
display and specificlly *not* the session (i could start an app on a
remote display within my session, and i definitely do not want its
window on the remote display but the tray icon on the local display).
see also http://lists.freedesktop.org/archives/xdg/2009-May/010461.html
for my opinion on excessive d-bus usage.

anyway, given that the tools for developing d-bus interfaces are so much
nicer than for some x11 property based protocols, i wonder whether it
wouldn't be possible to create an x11 transport for d-bus (possibly in
form of an x11 extension)? as a bonus, one wouldn't have to deal with
environment variables and additional firewall setup.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On September 8, 2009, you wrote:
> Aaron J. Seigo wrote:

> Since this spec aims to be desktop independent, whether notification
> bubbles and notification items should be visually grouped is an
> implementation detail. It should not be up to the spec to suggest this.

it doesn't suggest this, it just suggests that this technology is in the same
category as "stuff that communicates application information to the user".
 
> I am not that much into fancy names, but I thought about it a bit and
> came with those semi-lame ideas:
>
> - AppSatellite
> - SatelliteItem

i have no idea what those mean, and i doubt any developer would without
consulting documentation. they also don't speak to the function/purpose: "what
does a satellite do? why do i need one? what is it a satellite of?"

at least NotificationItem uses a well known term and speaks to what they do.

what you are looking for is a way to disambiguate between "notifications, the
things that pop up in bubbles" and "notification items, which communicate
status information and allow some basic user interaction", correct? so ..
StatusNotificationItem? starts to get long. doesn't really speak to the
interaction bits, but then neither does NotificationItem.

and i'm left wondering if this isn't solving a problem that doesn't really
have any consequences as it currently stands? we haven't actually had any
confusion to date, but then it hasn't been widely used either. it's not a
user-facing issue, in any case, so the bar is not as high as usually required.
 

> >> Supporting markup means opening a whole can of worms: you can't count on
> >> app developers to properly escape the content they send and you may end
> >> up with using heuristics to determine whether the '<' character is a
> >> single character or the beginning of a tag.
> >>
> >> Since the content of tooltips aim to be short, I suggest not supporting
> >> markup.
> >
> > it's a simple subset of markup and is something that app developers
> > routinely ask for, at times even with quite valid use cases ;)
>
> I would be interested in these use cases.

providing visual emphasis for the significant parts of a message such as a
file name or returned message text; enumerating lists of items ...
 
> >> If you think this is too restrictive, then I suggest to either:
> >> State that everything is markup and a '<' character should *always* be
> >> escaped to '<'.
> >
> > yes, if the spec says "markup" then this would be implied.
>
> It should be explicitly stated in the spec IMO.

fair enough ... this sounds very much like stating something remarkably
obvious, but it can't hurt.
 

> >> or:
> >> State that if an item wishes to use markup, then it must enclose the
> >> whole text in a <markup> tag.
> >
> > that would work as well. it's a small amount of overhead for not much
> > pain. it could also be that we look for the "<pre>" tag instead, and make
> > markup the default.
>
> Doing it this way is not good. It can fail in the (admittedly rare) case
> where the plain text contains the closing tag.

how is that different from using <markup>? this just says that rich text is
the default, and if you want plain text to use <pre> around your text.

or maybe a less hackish way to go about it all would be to add a bool member
to the ToolTip structure that says whether or not this is markup or not.

in practice, i'm not sure how much this matters one way or the other. we've
had rich text tooltips for a while now and there hasn't been any incidents
with "but i wanted plain text only! the tooltip unexpectedly looks like crap
now!"

so i'm not sure what the push back on allowing some basic formatting in
messages is due to. there's a reason most document formats allow for more than
plain text.
 
> >> 8. Icons
> >>
> >> You should also explicitly state the byte order of the image-data. Is it
> >> ARGB, RGBA?
> >
> > ARGB.
>
> Same thing, it should be explicitly mentioned in the spec.

sure; that can be added to the section describing the dbus data structure. i
suppose the assumption was that "ARGB" means "ARGB" and note "RGBA" ;)

> Together with
> endianess dependency or independency (note that Qt ARGB format is
> endianess dependent).

correct.

--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Aurélien Gâteau-3]

Aaron J. Seigo wrote:

>>>> or:
>>>> State that if an item wishes to use markup, then it must enclose the
>>>> whole text in a <markup> tag.
>>> that would work as well. it's a small amount of overhead for not much
>>> pain. it could also be that we look for the "<pre>" tag instead, and make
>>> markup the default.
>> Doing it this way is not good. It can fail in the (admittedly rare) case
>> where the plain text contains the closing tag.
>
> how is that different from using <markup>? this just says that rich text is
> the default, and if you want plain text to use <pre> around your text.

Imagine an application which does not markup, but shows text which is
not known at compile time. From the app point of view, it uses some a
"template like this:

<pre>Static text\n%1\nMore static text</pre>

Then in the (admittedly rare) case where %1 is "Foo</pre>", your text is
cut. Unless of course you do not check for the closing tag, which
(thinking aloud) you don't really need to... but it feels a bit more
hackish than having to escape markup.

> or maybe a less hackish way to go about it all would be to add a bool member
> to the ToolTip structure that says whether or not this is markup or not.

Yes, it's probably simpler.

> in practice, i'm not sure how much this matters one way or the other. we've
> had rich text tooltips for a while now and there hasn't been any incidents
> with "but i wanted plain text only! the tooltip unexpectedly looks like crap
> now!"

Things can go wrong when an app uses dynamic text and the content of the
dynamic text contents markup which the app did not escape because it
thought everything was plain-text. By not making markup the default, you
avoid this.

Aurelien
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Tuesday 08 September 2009, Aurélien Gâteau wrote:

> Aaron J. Seigo wrote:
> > it's not too late in the sense that we have until 4.4.0 in January when
> > we become committed to it.
> >
> > what we didn't like about "System Tray" is that it doesn't really say
> > what the point of it is. "System Tray" is "where those things appear"
> > while "Notification Item" says "what those things are supposed to be
> > doing".
>
> Agreed.
> [snip]
>
> > as for the root of the problem of "it's confusing", "notification area"
> > is a term used on a couple of platforms already, including the most
> > widely used one (Windows). it's not exactly a new term. in relation to
> > notifications, those things which pop up when an application asks to tell
> > the user something, actually relating these two things together
> > semantically is a good thing IMHO: they are both about pushing
> > information to the user's attention and they should probably coordinate
> > in some fashion as well (e.g. in a visual representation, it may make
> > sense to have app notifications visually associated with their
> > notification item; possibly combine that with notification item + task
> > bar integration)
>
> I believe it's called "Notification Area" on Windows because it is very
> strongly tied with Windows notifications: the MSDN states this:
>
> "Does your program need to display a notification? If so, you /must/ use
> a notification area icon."
> (http://msdn.microsoft.com/en-us/library/aa511448.aspx#rightui)

that's actually a good thing, the problem is that in windows it was so misused
that it kinda becoma a dumpster, the target is kinda the same with the status
property: if there is nothing to notify, hide it

> Since this spec aims to be desktop independent, whether notification
> bubbles and notification items should be visually grouped is an
> implementation detail. It should not be up to the spec to suggest this.
>
> I am not that much into fancy names, but I thought about it a bit and
> came with those semi-lame ideas:
>
> - AppSatellite
> - SatelliteItem
>
> >> Supporting markup means opening a whole can of worms: you can't count on
> >> app developers to properly escape the content they send and you may end
> >> up with using heuristics to determine whether the '<' character is a
> >> single character or the beginning of a tag.
> >>
> >> Since the content of tooltips aim to be short, I suggest not supporting
> >> markup.
> >
> > it's a simple subset of markup and is something that app developers
> > routinely ask for, at times even with quite valid use cases ;)
>
> I would be interested in these use cases.
>
> >> If you think this is too restrictive, then I suggest to either:
> >> State that everything is markup and a '<' character should *always* be
> >> escaped to '<'.
> >
> > yes, if the spec says "markup" then this would be implied.
>
> It should be explicitly stated in the spec IMO.
>
> >> or:
> >> State that if an item wishes to use markup, then it must enclose the
> >> whole text in a <markup> tag.
> >
> > that would work as well. it's a small amount of overhead for not much
> > pain. it could also be that we look for the "<pre>" tag instead, and make
> > markup the default.
>
> Doing it this way is not good. It can fail in the (admittedly rare) case
> where the plain text contains the closing tag.
>
> >> 8. Icons
> >>
> >> You should also explicitly state the byte order of the image-data. Is it
> >> ARGB, RGBA?
> >
> > ARGB.
>
> Same thing, it should be explicitly mentioned in the spec. Together with
> endianess dependency or independency (note that Qt ARGB format is
> endianess dependent).
>
> Aurelien
> _______________________________________________
> xdg mailing list
> xdg@...
> http://lists.freedesktop.org/mailman/listinfo/xdg

--
Marco Martin
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

On Tuesday 08 September 2009, Aurélien Gâteau wrote:

> Aaron J. Seigo wrote:
> >>>> or:
> >>>> State that if an item wishes to use markup, then it must enclose the
> >>>> whole text in a <markup> tag.
> >>>
> >>> that would work as well. it's a small amount of overhead for not much
> >>> pain. it could also be that we look for the "<pre>" tag instead, and
> >>> make markup the default.
> >>
> >> Doing it this way is not good. It can fail in the (admittedly rare) case
> >> where the plain text contains the closing tag.
> >
> > how is that different from using <markup>? this just says that rich text
> > is the default, and if you want plain text to use <pre> around your text.
>
> Imagine an application which does not markup, but shows text which is
> not known at compile time. From the app point of view, it uses some a
> "template like this:
>
> <pre>Static text\n%1\nMore static text</pre>
>
> Then in the (admittedly rare) case where %1 is "Foo</pre>", your text is
> cut. Unless of course you do not check for the closing tag, which
> (thinking aloud) you don't really need to... but it feels a bit more
> hackish than having to escape markup.
>
> > or maybe a less hackish way to go about it all would be to add a bool
> > member to the ToolTip structure that says whether or not this is markup
> > or not.
>
> Yes, it's probably simpler.

agree

> > in practice, i'm not sure how much this matters one way or the other.
> > we've had rich text tooltips for a while now and there hasn't been any
> > incidents with "but i wanted plain text only! the tooltip unexpectedly
> > looks like crap now!"
>
> Things can go wrong when an app uses dynamic text and the content of the
> dynamic text contents markup which the app did not escape because it
> thought everything was plain-text. By not making markup the default, you
> avoid this.

well, if the protocol mandates the text has markup the app has to support it
no?
however i'm fine with adding a new paramer to the tooltip struct to define
this

> Aurelien
> _______________________________________________
> xdg mailing list
> xdg@...
> http://lists.freedesktop.org/mailman/listinfo/xdg


--
Marco Martin
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg