Notification area links (Was: XML libs, Was: gconf backend)



On Sun, Sep 28, 2003 at 02:18:02AM -0400, Havoc Pennington wrote:
> On Sat, 2003-09-27 at 18:42, Daniel Veillard wrote:
<snip>
> > > > <note> I would love to see the system tray implementation debugged and
> > > > integrated as maintained APIs in the toolkits for example ;-) </note>
> > > 
> > > As would I, unfortunately the spec and implementation are both totally
> > > screwed up. ;-)
> > 
> >   Can I quote you on the bug reports I get <grin/>
> 
> If you must ;-) Link to the d-d-l threads on the UI for it, that will
> keep people busy. ;-)

Handy HIG bug here for the UI:

  http://bugzilla.gnome.org/show_bug.cgi?id=99175

Crosspost threads containing Mark's proposal for notification area guidelines:

  http://mail.gnome.org/archives/desktop-devel-list/2003-March/msg00351.html
  http://mail.gnome.org/archives/usability/2003-March/msg00039.html

Why the notification area takes a window, not an icon:

  http://mail.gnome.org/archives/desktop-devel-list/2003-April/msg00337.html

Blinking - consistency and accessibility:

  http://mail.gnome.org/archives/desktop-devel-list/2003-April/msg00360.html

My proposal for notification area preferences:

  http://mail.gnome.org/archives/usability/2003-June/msg00233.html

API RFE bug:

  http://bugzilla.gnome.org/show_bug.cgi?id=105101

API discussion is scattered through April 2003. Fragments begin at:

  http://mail.gnome.org/archives/gtk-devel-list/2003-April/msg00035.html
  http://mail.gnome.org/archives/gtk-devel-list/2003-April/msg00042.html
  http://mail.gnome.org/archives/gtk-devel-list/2003-April/msg00049.html
  http://mail.gnome.org/archives/gtk-devel-list/2003-April/msg00084.html
  http://mail.gnome.org/archives/gtk-devel-list/2003-April/msg00161.html
  http://mail.gnome.org/archives/gtk-devel-list/2003-April/msg00168.html

Some significant reports at bugzilla.gnome.org:

  http://bugzilla.gnome.org/show_bug.cgi?id=110239
  http://bugzilla.gnome.org/show_bug.cgi?id=115704

    This would seem to reveal flaws in the specs at freedesktop.org.
    Reparenting clients should not map reparented windows until
    ReparentNotify has been received with valid data - e.g., the new
    parent is what's expected. I did not see any warnings about this
    at freedesktop.org, nor did I see any checks in the GNOME code.
    Also, I didn't see the specs prohibiting to-be-reparented windows
    from mapping themselves.

    Furthermore, it seems someone is not checking screens. Embedder
    and embedee must be on the same screen of the display.

  http://bugzilla.gnome.org/show_bug.cgi?id=96123

    The EggTrayIcon widget is not designed to allow someone unfamiliar
    with the spec to make a properly functioning object. (Maybe that's
    a good thing if it discourages bad ones.) There are a few events
    that a (functionally) good tray icon will watch for and act on.
    These include plug destruction, mapping, unmapping, and resizing.
    A GObject encapsulation with signals for all important events
    is a sound approach; see the old dock API in the 1.x gnoem-panel.

  http://bugzilla.gnome.org/show_bug.cgi?id=122391

    This is probably related to the previous bug.


Things mentioned in various places by various people (myself included)
for which I'm not going to look up the links at this time:

  Transient device icons for mounted drive, hotplug devices, and the like
  should be placed in the notification area because:
   - Except for items such as the trash, the desktop should the user's space.
   - The desktop may be obscured by many windows, but the panel (on which
     is the notification area) stays above all but a few windows. Thus
     transient device icons in the notification area provide ready access
     to objects needed for what is often the user's task at hand.
   - WindowsXP does it; make your marketroid happy.

  Some applets such as the weather, mail, and wireless connectivity applets
  should be notification area items. Some items presently appearing in the
  notification area should be applets instead.


Cheers,
Greg



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]