[openbox] usability

[Ben Jansens]

On Sun, Jun 29, 2003 at 06:51:01PM +0200, Peter Chiocchetti wrote:
> On Sun, Jun 29, 2003 at 12:08:26AM -0400, Ben Jansens wrote:
> > > Theres a bug with the selection of icons for starters in the
> > > gnome-panel that kills ob, but only if gnome-session is active.
> 
> After cvs-update today, this is no more.

Good.

> > > Its also quite hard to have gnome-session fully recognise ob,
> > > the foot hangs about a minute
> 
> Looks like offtopic now: this must be about xconsole (which is
> likely not session-aware, at least not gnome-session...)

gnome-session uses the same protocol as xsm and any others. As far as I know
the only extensions it uses are additional session properties.

> > In layers and groups. GTK2 currently provides some issues with that. Some
> > apps work really nicely, like gimp, and some not as nice, like nautilus,
> > since it groups all of an apps windows together no matter what. I'm giong to
> > take this up with Owen Taylor shortly.
> > 
> > I have been replacing the stacking code over the last couple days, and the
> > unable-to-lower-behind-a-group-member (phew) bug is gone. Let me know if the
> > problem you were experiencing is still there of course, in case im reading
> > this wrong.
> 
> If I understand fully, layers are set via the titlebar's menu.

Windows of different types are placed in different layers (desktop windows,
docks, etc). The option in the titlebar places windows above/below others in
their layer.

> Some windows in a layer are grouped, so they raise, lower, but
> not iconify together: gnome-terminals eg. herd, while xterms
> stay singles.

I believe this is caused by a deficiency in GTK+:
http://bugzilla.gnome.org/show_bug.cgi?id=116278

Gnome-terminals should not be grouped as such.

> Since updating, lowering the gimp at the canvas, lowers the
> canvas below the dialogues (and all other windows of course).
> Being able to drag a window, without raising it, makes working
> with the gimp already a lot easier.
> 
> <rant>But there is more to it, and the wm cant do it all on
> its own, I think.  Compare with the vector drawing app sketch:
> its dialogs stay above the canvas, whichever window one raises
> or lowers. they dont even show up in the window list. They
> have the TRANSIENT_FOR hint set, I guess thats why. This is
> how it should be with the gimp too. But the gimp may have
> several canvasses at the same time, and it opens with the
> tools-palette first. The transients mechanism may be too weak
> to support this kind of grouping.  NET_WM has DIALOGs, not all
> apps use them though (rox does for bookmarks window, but
> sodipodi doesnt, for stroke settings eg.); maybe openbox
> should honour dialogues in stacking? maybe it already does,
> but the clients set their LEADERS wrong?  all in all this
> sounds like graph theory (mathematics, shudder).</rant>

NET_WM's dialog type is used for any transients, but not used specifically
for stacking. Rather, transients are kept above parents. Its also posible to
specify a window as transient for its group. In this case the window is kept
above all members of its groups.

> Still a happy user, and whats the preferred format for
> documentation?

Simple XHTML (no font/etc tags, just structure tags such h1, p, ul, etc).
This way we can add it to the website easily, and also include it in the
distribution.

You can see the current stuff in http://openbox.org/3/content/en/docs/

Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://icculus.org/pipermail/openbox/attachments/20030629/d57cd272/attachment.pgp>