[ubuntu-art] Intuitive application lister and other loopy discussions (was Re: next meeting)

[Dylan McCall]

That much (about desktop-neutrality) is definitely true, Jan. That's why the
idea of building an application lister applet is a slow one, at best...

A GNOME-centric proof of concept wouldn't hurt, but it would definitely be
sensible to have a solid addition to the FreeDesktop standards somewhere. I
think it would make sense to stop the application lister from listing
windows on its own, and instead use a common protocol to determine open
projects (documents, web pages, etc.) which can be swapped between with it.
Right now, the systems are very tied to window managers, which doesn't
strike me as an ideal solution for scalability. That's probably another
thought for another day. (Not really urgent...)

Mind you, the existing systems require no real input from applications, and
the GNOME applet could theoretically fall back to guessing, as well. The
extra functionality would only be an addition gained from applications that
talk to that particular applet when possible.

And no, I don't think using the notification area to minimize applications
should be encouraged, even when there is currently no alternative. The
standards say not to, and as long as an application breaks those standards
this system gets more and more confuddled. I was reminded a moment ago that
Evolution's (otherwise good) mail notification /blinks/, likely to attract
attention to itself in the only way reliably possible while it is surrounded
by iconified music players. Notifications should not need to blink; simply
being present in the notification area should be demonstration enough (to
both the underlying software systems and the user) that they are notable.
Blinking is on par with those spam-like Flash-powered advertisements with
ugly voice-overs and pink text overlapping the page.

The idea that becoming a notification saves space is a very, very bad
assumption. The notification area could easily consume half the screen in
one desktop environment, while the window list exists as a small menu (like
the panel's Window Selector applet). One very important point of these
standards is that the desktop environment can predict how applications
behave, thus ensuring consistent behaviour and a significant level of
freedom for the developers of said environment. Application developers
needn't worry at all about how a particular environment is handling a
minimized application - in fact, it would be to everyone's benefit if they
_did not_ at the application level. Application developers arbitrarily
deciding "hey, that notification area is smaller and tidier to minimize to
in the desktop environment I am using!" is a lot like people throwing in
ugly CSS hacks to support Internet Explorer, such as utilizing that
horrendous comments parsing bug to work around certain browsers' lack of
min-width. It may do the trick here, but will it work everywhere else?

The system is designed so that the application is not in (much) control of
anything outside its window, just as an HTML / CSS page is not really in
control over how the browser displays it. It's about ensuring that the
visual reresentation (the web browser in that latter example) can freely
change, producing a more flexible and scalable environment while the
applications that live in it transparently adapt, quietly getting better and
better with the only cost of entry being some initial integration effort.
With GTK, for example, the end user can change the language or font size
while the user-land programs that use GTK do not need any actual changes
themselves to support this /significant/ alteration to the the final output.
As soon as a program decides to take resizing widgets upon itself, however,
that stops working.


By all means, I encourage anyone to show concern about notifications and
window switchers at the desktop environment level -- after all, something
clearly needs work. We have a glorious future to seal here, before
applications get too set in the current ways!



-Dylan


On Sun, Feb 10, 2008 at 12:49 PM, Jan Niklas Hasse <jhasse at gmail.com> wrote:

>
>
> On Feb 10, 2008 8:30 PM, Troy James Sobotka <troy.sobotka at gmail.com>
> wrote:
>
> > Dylan McCall wrote:
> > > The notification area
> > > exists for programs to present information about notable happenings.
> > > That Rhythmbox is running is by no means a notable happening.
> >
> > If you want to make a difference, get involved in the specifications
> > that matter.  Most importantly -- _FILE BUGS_ against apps that break
> > the specification in Ubuntu.
> >
> >
> > http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html
> >
> > Quote:
> > "From a UI standpoint, the system tray is normally used for transient
> > icons that indicate some special state, while full-blown "applets" are
> > used for permanent dock/panel features. For example, a system tray icon
> > might appear to tell the user that they have new mail, or have an
> > incoming instant message, or something along those lines."
>
>
>
> GNOME Applets aren't an alternative because they are only available for
> GNOME. XCFE, KDE, Windows for example use GTK+ applications, too!
> So please stop blaming developers that they shouldn't use the notification
> area without providing an alternative with the same quality or wait until
> such an alternative is available.
>
> --
> ubuntu-art mailing list
> ubuntu-art at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-art
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-art/attachments/20080210/f15e564d/attachment.htm