Re: [Usability] Resizability of windows

["Elijah Newren" <newren gmail com>]

On 5/3/06, Matthew Paul Thomas <mpt myrealbox com> wrote:
> On May 3, 2006, at 1:53 AM, Elijah Newren wrote:
> > On 5/2/06, Matthew Paul Thomas <mpt myrealbox com> wrote:
> > <snip>
> >> Having said all that, I don't understand why the Theme Preferences
> >> window is not a dialog and is resizable, but doesn't become
> >> maximizable automatically. That looks like too much flexibility in
> >> Metacity.
> >
> > There's code in metacity that turns off the maximization ability for
> > any window not of META_WINDOW_NORMAL type (e.g. dialogs).
>
> According to the HIG, the Theme Preferences window is not a dialog,
> it's a utility window, and I agree wholeheartedly.
> <http://developer.gnome.org/projects/gup/hig/2.0/windows-utility.html>
> <http://developer.gnome.org/projects/gup/hig/2.0/windows-dialog.html>

Dialogs was only one example; Metacity also currently turns of the
maximization capability for utility windows, toolbars, menus,
splashscreens, docks (e.g. panels), and desktops -- not that it
necessarily should in all these cases, I'm just telling you the
current behavior.  :)

Also, according to the hints provided by theme preferences authors,
Metacity can only tell that it's a dialog.  In a terminal, run
  xprop | grep _NET_WM_WINDOW_TYPE
and then click on the theme preferences window.  See
http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507144
for a list of possible types.  A utility window is one of them, though
I don't think Metacity really has much special support for utility
windows and toolbars and such (yet) so changing it probably won't
currently have much effect.

> > I don't know why the code does that; is it in the HIG?
>
> No. The HIG tells you to "See the description of each particular window
> type for a list of appropriate window commands", but then forgets to do
> so for either instant-apply *or* explicit-apply windows.
> <http://developer.gnome.org/projects/gup/hig/2.0/windows.html#window-
> props-borders>
> <http://developer.gnome.org/projects/gup/hig/2.0/windows-
> utility.html#windows-instant-apply>

Ah, ok.  Looking at it more and remembering some old bugs, I think the
cause of these problems is merely the fact that the Metacity code
handling of functionality-allowed-for-windows is totally messed up
(see bugs 90420, 94111, 115247, 122640, and 315910).  ;-)

> Relatedly, I disagree strongly with the HIG (and Metacity) on which
> buttons should be in the title bar for each type of window. It is

Calum already addressed how the authors of the HIG also disagree with
the HIG (and Metacity) on this issue.  Further, I don't think the
authors of Metacity agree with it either, given the many open bug
reports I mentioned above (especially given some of the reporters of
those bugs).  Anyway, this particular issue is filed as bug 319723,
FWIW.  I just added a comment too about how the EWMH end of the deal
is already done so it just needs gtk+ and metacity support.

/me wonders whether he should make a tracker bug for all these issues

> And as I alluded to in bug 338660, the uniformity of title
> bar buttons between window types wastes a valuable visual clue to how a
> window will behave.
> <http://bugzilla.gnome.org/show_bug.cgi?id=338660#c3>

I think it's more related to the fact that metacity's code in this
area sucks rather than there being too many flags for application
developers to twiddle.  Granted, that might be causing problems too,
but

> I would love to help find a way out of these holes.

Cool, that means I can pester you with questions.  :-)