Re: Functions for UrgencyHint

[Gregory Merchan <merchan phys lsu edu>]

Any discussion following this should be on the usability list, not gtk-devel.
ReplyTo set accordingly.

On Fri, Jan 11, 2002 at 11:39:31AM -0500, Havoc Pennington wrote:
> 
> Gregory Merchan <merchan baton phys lsu edu> writes:
> > GtkMessageDialog should set this hint so these might be used
> > internally until they can be added to the API.
> 
> How would message dialog know whether to set it? All errors aren't
> urgent (most are not).
> 
> Havoc

I think that if the urgency hint should not be set then GtkMessageDialog
is an inappropriate form of feedback. A statusbar message or some other
inline notification is more appropriate.

(I'm going to call it an alert from here to end. What follows applies to
 any alert, not just those provided by Gtk+. Alert is also shorter ;-)

The following behavior is expected, but not exclusive:

  An alert should set its state as:

    _NET_WM_STATE[] = {
                        _NET_WM_STATE_MODAL,
                        _NET_WM_STATE_STICKY,       /* Conditionally */
                        _NET_WM_STATE_SKIP_TASKBAR,
                        _NET_WM_STATE_SKIP_PAGER    /* Maybe */
                      }

   The alert should be modal to whatever it applies; if there is no reason
   for the mode, then there is no reason to map another window or interrupt
   the user with such a distraction.

   The sticky state will indicate relative importance. Something needing
   immediate attention, regardless of the user's current activity,
   would set this; most would not. Information alerts triggered by alarms
   set by the user and alerts for errors which could affect other work
   should be the only ones of such urgency.

   An alert is not a user window, so there should be no reason to present
   it on the taskbar. Unless it might be useful for the pager to show
   that an alert is present on another part of the workspace or in another
   workspace, the alert should also skip the pager.

   Though an alert is not resizable, the window manager may be taking the
   maximized state as indication to lock the window position or limit its
   moveablity, so the maximized hints should not be set; an ICCCM
   mechanism exists to indicate non-resizeable windows.

  The window manager should:

    Regard the combination of UrgencyHint and _NET_WM_WINDOW_TYPE_DIALOG
    as indicating an alert window.

    Set the _NET_WM_VISIBLE_NAME to "". The title of an alert should not
    convey any more information than the text of the alert, and
    duplication there would waste the time for the user who read it.

    Keep the alert stacked above the window for which it is transient.
    This may be above all windows. If the alert is sticky, then it should
    be above all windows because the stickiness indicates that much urgency.

    Provide only a shade control on the frame, if any control at all.

    Allow the edges or any grabable part of the window to be used to move
    the window. Since selecting alert text can be useful, it is best if the
    window manager leaves the alert internal area alone.


Something to consider for 2.2 or later, perhaps when sensitivity is fixed
for tooltips:

 Modality is an unwelcome restriction of action, but it is still sometimes
 necessary to prevent additional problems. Scrollling and selecting should
 not affect data in any way that could cause problems and may be desirable
 or needed to exit the mode. (There may be other such actions, but I can't
 think of any at the moment.) Ultimately the only possible mode should be
 a temporary read-only mode which leaves scrolling, selection, Copy (to
 clipboard), and perhaps viewing of controls such as menus.


Cheers,
Greg Merchan