Re: Regressions in GNOME 2 vs 1.x

[Gregory Merchan <merchan phys lsu edu>]

On Fri, Feb 08, 2002 at 08:47:24PM -0500, Havoc Pennington wrote:
<snip> 
> > They are not always the same, nor should they be so. If (say) Abiword
> > is an application and I'm running it twice on the same display, then
> > I have two clients, but I would probably want only one group. (Or is a
> > client something other than an X client?)
> 
> A client is a session client, really.

ok.

(I've mucked with Xlib too much so I usually read client as "something
 running that has called XOpenDisplay() and not XCloseDisplay()")

> In practice both group and client leader will be set by the toolkit
> and will identify a single process, though there should be API for
> sufficiently enthusiastic app authors to do better than this.

Perhaps the implementation of GtkWindowGroup could be extended to do this?
The simplest way I see to get the first instance is to own or manage
a selection like _GNOME_app where app is the name of the particular app.
E.g. _GNOME_ABIWORD. Later instances would then request conversion
to a WINDOW type suitable for use as the group leader. Perhaps simpler
would be to just use the selection owner as the group leader, but I think
that might conflict with special window requirement for a managed selection.
The details of watching for owner destruction and marking a new leader
could be done in the library too, thus introducing no new issues for
the application developer.

This is assuming that the group leader is only used for application
identification. Something like a work area would be more involved but 
could probably be handled by a toolkit level command line option.

<snip>
> 
> > Sorry if this is too abstract, theoretical or academic for this
> > list. I don't know what other list would be appropriate for talking
> > about such things.  Perhaps we need a new list for talking about
> > making use of the existing technology and planning implementation
> > and integration? It seems a waste to run on X and not make use of
> > what it makes possible.
> 
> No, this is on topic for desktop-devel-list.

Ok. I'll take some liberty for a lengthy presentation here. It's not
feasible for 2.0 and probably not the next release either, but
hopefully it's worth keeping in some corner of the mind. The first
part of this is relevant now though.

> AFAIK we do use the group leader, however. It's what WnckApplication
> is based on. On wm-spec-list Jim Gettys confirmed that a window group
> was supposed to be "an application" and we decided to clarify that
> interpretation in the spec, I think. I don't know if I ever got around
> to actually patching the spec.
> 
> Havoc

He seemed unsure to me.

http://mail.gnome.org/archives/wm-spec-list/2001-September/msg00002.html
>
> I believe this is the correct meaning of window group.
>
> Generally, if I minimize the main window of an application,
> I'd like any open dialog boxes to be minimized at the same time,
> at least for most applications.
>
> Or that was my thoughts on the topic before the ICCCM existed
> (and I threw together the first set of window properties for window
> managers to use).

The dialog boxes would typically have WM_TRANSIENT_FOR set and that would
be more useful than the group for something like minimization. Using
the group could result in odd behavior as it could lead to multiple document
windows minimizing at once. This is almost certainly not a useful default
behavior for the minimize button on a window frame.

ICCCM Section 4.1.11 - Window Groups
> A set of top-level windows that should be treated from the
> user's point of view as related (even though they may belong
> to a number of clients) should be linked together using the
> window_group field of the WM_HINTS structure.

There may be no connection between instances of AbiWord, one might simply
be using the same application for unrelated tasks. However, if I select
a few documents, spreadsheets, and images in Nautilus and open them all
at once, then I'm probably working on those items as a group; i.e., they
comprise a task. The OS/2 work area functioned like this; though the
interface was a folder with a special flag. IIRC, actions on the group
leader would affect the members, but otherwise the members would open,
close, minimize et al. independently.

An example of how this could be used:
A folder containing the source and build files for a program
is marked as a work area. An additional file is included to indicate
other programs, such as a debugger, to be run; alternativelly,
links to those programs are included, though this would require
tarballing to skip those. By default when this folder is opened,
various files in it open and some programs are run. (It's the default
action because the user marked it as a work area; a plain opening
would still be available from the folder context menu.) All that is
needed now is for these programs to work together. For this we have
selections (see Xlib Programming Manual 12.4.2 for a nicely germane
example ;-) and CORBA. This is your basic IDE, except the parts aren't
stuck together in one window. Unlike your typical IDE, the parts are
more readily interchangable and many more can be easily integrated.
And it doesn't have to be a programmer's IDE. The contents could be html,
images, legal briefs, or accounting data - or any mix of those you might
need. This is much like using console tools: many small parts working
together and still you can use large mega-apps if you so desire. Unlike
the console, you don't need to memorize commands or hunt for them with
apropos and man; you merely open up your work and the system finds
the tools and knows what to pipe about. The only thing missing here
is a template system.


Cheers,
Greg Merchan