From miles@amazon.com
Received: (qmail 20174 invoked from network); 24 Jan 2000 05:40:37 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 24 Jan 2000 05:40:37 -0000
Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.156])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id AAA01806
for <gnome-list@gnome.org>; Mon, 24 Jan 2000 00:40:37 -0500
Received: from mail-proxy-1.amazon.com (mail-proxy-1.amazon.com [10.16.42.201])
by smtp-outgoing.amazon.com (Postfix) with ESMTP id 099155FA
for <gnome-list@gnome.org>; Sun, 23 Jan 2000 21:40:07 -0800 (PST)
Received: by mail-proxy-1.amazon.com id VAA11858; Sun, 23 Jan 2000 21:40:05 -0800 (PST)
Sender: miles@amazon.com
Message-ID: <388BE89F.EB883254@amazon.com>
Date: Sun, 23 Jan 2000 21:52:31 -0800
From: Miles Lane <miles@amazon.com>
Organization: Amazon.com
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: gnome-list@gnome.org
Subject: Micro$oft-style dragable, resizable, stackable menu/button bars.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi,
One of the nice UI elements Micro$oft has come up with
is the menubar/buttonbar UI class that enables dragging,
resizing and stacking of menu/buttonbars.
These bars were initially implemented and used in IE 4.0.
As soon as I saw them, I thought "that's how menu and
buttonbars should always work!"
Netscape has its expanding and contracting bars, but they
aren't nearly as nice to use. For example, you can't
stack and resize bars. You can reorder them vertically,
but they always run the width of the window. They can't
share a single row with another bar. Micro$oft's bars
even allow a user to drag bars on a shared row to reorder
the bars in the row.
In IE and some of M$'s other software, clicking on the
lower edge of a buttonbar and dragging the edge up or
down causes the text under the buttons to be displayed
or hidden. I really like this feature.
This cannot be rocket science. I am amazed that this
functionality isn't in Gnome already. This is an area
where Gnome is running behind Micro$oft in usability.
Let's get this in and take another hunk out of M$'s
desktop usability lead.
Miles
From miles@amazon.com
Received: (qmail 24471 invoked from network); 24 Jan 2000 06:50:20 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 24 Jan 2000 06:50:20 -0000
Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.156])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id BAA04176
for <gnome-list@gnome.org>; Mon, 24 Jan 2000 01:50:19 -0500
Received: from mail-proxy-1.amazon.com (mail-proxy-1.amazon.com [10.16.42.201])
by smtp-outgoing.amazon.com (Postfix) with ESMTP
id 1A8995AA; Sun, 23 Jan 2000 22:49:49 -0800 (PST)
Received: by mail-proxy-1.amazon.com id WAA20123; Sun, 23 Jan 2000 22:49:47 -0800 (PST)
Sender: miles@amazon.com
Message-ID: <388BF8F4.70B40AA7@amazon.com>
Date: Sun, 23 Jan 2000 23:02:12 -0800
From: Miles Lane <miles@amazon.com>
Organization: Amazon.com
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.11 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Renze de Ruiter <renze@ihug.co.nz>, gnome-list@gnome.org
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
References: <388BE89F.EB883254@amazon.com> <00012419330300.05898@ziggy>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Renze de Ruiter wrote:
>
> On Mon, 24 Jan 2000, Miles Lane wrote:
>
> > This cannot be rocket science. I am amazed that this
> > functionality isn't in Gnome already. This is an area
> > where Gnome is running behind Micro$oft in usability.
>
> Tried this with Gnumeric's toolbars, by any chance? :)
Okeedokee. I had not seem them before. They are close
to what I am talking about, but not all the way there.
Specifically, Micro$soft's button/menubars support
hiding some of the right-hand portion of a tool/menubar.
For example, is I stack two buttonbars in a single row
and there isn't room for both bars to be displayed in
their entirety, one (or both?) of the bars can be placed
such that some of the bar buttons scroll off the end of
the bar. In place of having everything be visable, this
symbol ">>" indicates that something is not seen. Clicking
on the ">>" symbol scrolls the buttons to the left, unhiding
the hidden buttons. Obviously, as the buttons get scrolled,
a "<<" symbol shows up on the lefthand side of the bar
so the user can scroll back.
Also, when a window is resized horizontally, the ">>"
symbol will appear as the toolbar shrinks to fit in the
window and a some of the toolbar buttons become hidden.
This is really quite nicely implemented and works very
intuitively and smoothly.
Also, the ability to hide and unhide the button labels
by dragging the bar's lower edge up and down does not
appear to be there.
That said, "Woohoo!" It's looking much, much better!
Thanks,
Miles
From jgotts@www.tqstats.com
Received: (qmail 3213 invoked from network); 25 Jan 2000 05:54:10 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 25 Jan 2000 05:54:10 -0000
Received: from www.tqstats.com (0@www.tqstats.com [139.171.2.5])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id AAA19715
for <gnome-list@gnome.org>; Tue, 25 Jan 2000 00:53:39 -0500
From: jgotts@www.tqstats.com
Received: from www.tqstats.com (108@localhost [127.0.0.1])
by www.tqstats.com (8.9.0/8.9.0) with ESMTP id AAA08589;
Tue, 25 Jan 2000 00:53:32 -0500 (EST)
Message-Id: <200001250553.AAA08589@www.tqstats.com>
To: Miles Lane <miles@amazon.com>
cc: gnome-list@gnome.org
Reply-To: jgotts@linuxsavvy.com
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
In-reply-to: Your message of "Sun, 23 Jan 2000 23:02:12 PST."
<388BF8F4.70B40AA7@amazon.com>
Date: Tue, 25 Jan 2000 00:53:27 -0500
In message <388BF8F4.70B40AA7@amazon.com>, Miles Lane writes:
>Specifically, Micro$soft's button/menubars support
>hiding some of the right-hand portion of a tool/menubar.
>For example, is I stack two buttonbars in a single row
>and there isn't room for both bars to be displayed in
>their entirety, one (or both?) of the bars can be placed
>such that some of the bar buttons scroll off the end of
>the bar. In place of having everything be visable, this
>symbol ">>" indicates that something is not seen. Clicking
>on the ">>" symbol scrolls the buttons to the left, unhiding
>the hidden buttons. Obviously, as the buttons get scrolled,
>a "<<" symbol shows up on the lefthand side of the bar
>so the user can scroll back.
>Also, when a window is resized horizontally, the ">>"
>symbol will appear as the toolbar shrinks to fit in the
>window and a some of the toolbar buttons become hidden.
>This is really quite nicely implemented and works very
>intuitively and smoothly.
Don't take this the wrong way; I'm trying to offer constructive criticism.
See the Interface Hall of Shame for why this is a bad idea:
http://www.iarchitect.com/mshame.htm
The concept of the button bar is that commonly accessed menu items are one
click away versus the two to three clicks required to access a menu item. When
you introduce the concept of a scrolling button bar you might as well just
force the user to use the menubar, because the utility of the button bar is
completely lost. Think of the example where the button bar is twice as wide as
the application. How much time will it take the user to find the icon for his
or her task? How do you indicate what portion of the virtual button bar is
visible? And what if you wrap the button bar to a stack of button bars? How
useful is it to stare at more than a dozen different icons, moving your mouse
from icon to icon trying to discern the function of each from their tooltips?
Since you have to resort to reading text, you might as well use the menubar.
I'm not against new features, but introducing new user interface concepts just
for the technical challenge is a straw man argument when you want your
grandmother to be using GNOME.
I think WinXX is easy to use, but its abuse of button bars (and also tabbed
regions) does not help matters.
John
--
John GOTTS <jgotts@linuxsavvy.com> http://www.linuxsavvy.com/staff/jgotts
From frantb@rpi.edu
Received: (qmail 12564 invoked from network); 25 Jan 2000 06:09:41 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 25 Jan 2000 06:09:41 -0000
Received: from mail.rpi.edu (root@mail.rpi.edu [128.113.100.7])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id BAA20335
for <gnome-list@gnome.org>; Tue, 25 Jan 2000 01:09:40 -0500
Received: from frantb (nidorina-05.dynamic.rpi.edu [128.113.139.174])
by mail.rpi.edu (8.9.3/8.9.3) with SMTP id BAA77154;
Tue, 25 Jan 2000 01:09:38 -0500
Message-ID: <009101bf66fb$0ecfff40$ae8b7180@dynamic.rpi.edu>
From: "Ben FrantzDale" <frantb@rpi.edu>
To: <jgotts@linuxsavvy.com>, "Miles Lane" <miles@amazon.com>
Cc: <gnome-list@gnome.org>
References: <200001250553.AAA08589@www.tqstats.com>
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
Date: Tue, 25 Jan 2000 01:11:45 -0500
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
----- Original Message -----
From: <jgotts@www.tqstats.com>
To: Miles Lane <miles@amazon.com>
Cc: <gnome-list@gnome.org>
Sent: Tuesday, January 25, 2000 12:53 AM
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button
bars.
> In message <388BF8F4.70B40AA7@amazon.com>, Miles Lane writes:
>
> >Specifically, Micro$soft's button/menubars support
> >hiding some of the right-hand portion of a tool/menubar.
> >For example, is I stack two buttonbars in a single row
> >and there isn't room for both bars to be displayed in
> >their entirety, one (or both?) of the bars can be placed
> >such that some of the bar buttons scroll off the end of
> >the bar. In place of having everything be visable, this
> >symbol ">>" indicates that something is not seen. Clicking
> >on the ">>" symbol scrolls the buttons to the left, unhiding
> >the hidden buttons. Obviously, as the buttons get scrolled,
> >a "<<" symbol shows up on the lefthand side of the bar
> >so the user can scroll back.
>
> >Also, when a window is resized horizontally, the ">>"
> >symbol will appear as the toolbar shrinks to fit in the
> >window and a some of the toolbar buttons become hidden.
> >This is really quite nicely implemented and works very
> >intuitively and smoothly.
>
> Don't take this the wrong way; I'm trying to offer constructive criticism.
>
> See the Interface Hall of Shame for why this is a bad idea:
>
> http://www.iarchitect.com/mshame.htm
>
> The concept of the button bar is that commonly accessed menu items are one
> click away versus the two to three clicks required to access a menu item.
When
> you introduce the concept of a scrolling button bar you might as well just
> force the user to use the menubar, because the utility of the button bar
is
> completely lost. Think of the example where the button bar is twice as
wide as
> the application. How much time will it take the user to find the icon for
his
> or her task? How do you indicate what portion of the virtual button bar
is
> visible? And what if you wrap the button bar to a stack of button bars?
How
> useful is it to stare at more than a dozen different icons, moving your
mouse
> from icon to icon trying to discern the function of each from their
tooltips?
> Since you have to resort to reading text, you might as well use the
menubar.
>
> I'm not against new features, but introducing new user interface concepts
just
> for the technical challenge is a straw man argument when you want your
> grandmother to be using GNOME.
>
> I think WinXX is easy to use, but its abuse of button bars (and also
tabbed
> regions) does not help matters.
>
> John
>
I understand what you mean but in windows I use this feature on all apps
that support it and find the benefit greatly outweighs the UI costs. Turning
hidden entries into menus is a way to deal with the probelm that alowing
menubars to run off the window creates. With default settings that problem
basicly doesn't show up.
The benefit of having less blank space and more room to work is a great UI
enhancement IMHO. The ability to have the menubar, buttonbar and addressbar
of IE on the same line (saving about 60pxls of vertical space) is priceless
(for me at least :-)
--Ben
From u07ih@abdn.ac.uk
Received: (qmail 32107 invoked from network); 25 Jan 2000 13:14:08 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 25 Jan 2000 13:14:08 -0000
Received: from abdn.ac.uk (mailhub2.abdn.ac.uk [139.133.7.24])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id IAA02902
for <gnome-list@gnome.org>; Tue, 25 Jan 2000 08:14:04 -0500
From: u07ih@abdn.ac.uk
Received: from sysa.abdn.ac.uk (sysa.abdn.ac.uk [139.133.7.110])
by abdn.ac.uk (8.9.3/8.9.3) with SMTP id NAA22879;
Tue, 25 Jan 2000 13:13:29 GMT
Message-Id: <S200001251313.NAA14418@sysa.abdn.ac.uk>
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
To: frantb@rpi.edu (Ben FrantzDale)
Date: Tue, 25 Jan 2000 13:13:29 +0000 (GMT)
Cc: jgotts@linuxsavvy.com, miles@amazon.com, gnome-list@gnome.org
In-Reply-To: <009101bf66fb$0ecfff40$ae8b7180@dynamic.rpi.edu>
from "Ben FrantzDale" at Jan 25, 0 01:11:45 am
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
> The benefit of having less blank space and more room to work is a great UI
> enhancement IMHO. The ability to have the menubar, buttonbar and addressbar
> of IE on the same line (saving about 60pxls of vertical space) is priceless
> (for me at least :-)
I agree about putting the addressbar on the same line as the menus. It gives
more room for the html :)
It would take 2 changes I think in the gnome-app.c file. From what I can tell
the GNOME_DOCK_ITEM_BEH_EXCLUSIVE flag needs to be removed from
gnome_app_set_menus and gnome_app_set_toolbar
Iain
From miles@amazon.com
Received: (qmail 1627 invoked from network); 25 Jan 2000 21:54:59 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 25 Jan 2000 21:54:59 -0000
Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.156])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA09358
for <gnome-list@gnome.org>; Tue, 25 Jan 2000 16:54:58 -0500
Received: from mail-proxy-2.amazon.com (mail-proxy-2.amazon.com [10.16.42.202])
by smtp-outgoing.amazon.com (Postfix) with ESMTP
id EAD56337; Tue, 25 Jan 2000 13:54:27 -0800 (PST)
Received: from amazon.com by mail-proxy-2.amazon.com with ESMTP
(crosscheck: [10.21.16.100])
id NAA23794; Tue, 25 Jan 2000 13:54:27 -0800 (PST)
Message-ID: <388E1BAE.F08441D7@amazon.com>
Date: Tue, 25 Jan 2000 13:54:54 -0800
From: Miles Lane <miles@amazon.com>
Organization: Amazon.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: u07ih@abdn.ac.uk
Cc: Ben FrantzDale <frantb@rpi.edu>, jgotts@linuxsavvy.com,
gnome-list@gnome.org
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
References: <S200001251313.NAA14418@sysa.abdn.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
In the case of the addressbar, it may be best to not embed it in the
menubar. The notion is to allow users to move bars around as they wish.
For me, this is useful. If I am surfing a site with long URLs and I want
to see most of the URL, I might drag the addressbat to its own row.
Otherwise, I'd probably tuck it into a corner of a row so that I could
type URLs and paths in on an occaisional basis.
u07ih@abdn.ac.uk wrote:
>
> > The benefit of having less blank space and more room to work is a great UI
> > enhancement IMHO. The ability to have the menubar, buttonbar and addressbar
> > of IE on the same line (saving about 60pxls of vertical space) is priceless
> > (for me at least :-)
>
> I agree about putting the addressbar on the same line as the menus. It gives
> more room for the html :)
> It would take 2 changes I think in the gnome-app.c file. From what I can tell
> the GNOME_DOCK_ITEM_BEH_EXCLUSIVE flag needs to be removed from
> gnome_app_set_menus and gnome_app_set_toolbar
>
> Iain
From u07ih@abdn.ac.uk
Received: (qmail 6107 invoked from network); 25 Jan 2000 21:59:34 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 25 Jan 2000 21:59:34 -0000
Received: from abdn.ac.uk (mailhub2.abdn.ac.uk [139.133.7.24])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA09720
for <gnome-list@gnome.org>; Tue, 25 Jan 2000 16:59:33 -0500
From: u07ih@abdn.ac.uk
Received: from sysa.abdn.ac.uk (sysa.abdn.ac.uk [139.133.7.110])
by abdn.ac.uk (8.9.3/8.9.3) with SMTP id VAA22245;
Tue, 25 Jan 2000 21:59:01 GMT
Message-Id: <S200001252159.VAA20527@sysa.abdn.ac.uk>
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
To: miles@amazon.com (Miles Lane)
Date: Tue, 25 Jan 2000 21:59:01 +0000 (GMT)
Cc: u07ih@abdn.ac.uk, frantb@rpi.edu, jgotts@linuxsavvy.com,
gnome-list@gnome.org
In-Reply-To: <388E1BAE.F08441D7@amazon.com> from "Miles Lane" at Jan 25, 0 01:54:54 pm
X-Mailer: ELM [version 2.4 PL21]
Content-Type: text
I wasn't advocating putting anything into the same place as the menubar by
default. I was saying how easy it would be to make it possible.
But at the moment, nothing can go onto the menu bar, as the menu bar
has it's row in the gnome-dock exclusively. If the GNOME_DOCK_ITEM_BEH_EXCLUSIVE
flag is removed, then things can go in the menu bar, if you want them too, or
they can stay where they are....your choice.
Maybe this should go into the ui-properties capplet
"[x]Menu bar takes up whole row"
"[ ]Toolbar takes up whole row"
Iain
>
> In the case of the addressbar, it may be best to not embed it in the
> menubar. The notion is to allow users to move bars around as they wish.
> For me, this is useful. If I am surfing a site with long URLs and I want
> to see most of the URL, I might drag the addressbat to its own row.
> Otherwise, I'd probably tuck it into a corner of a row so that I could
> type URLs and paths in on an occaisional basis.
>
> u07ih@abdn.ac.uk wrote:
> >
> > > The benefit of having less blank space and more room to work is a great UI
> > > enhancement IMHO. The ability to have the menubar, buttonbar and addressbar
> > > of IE on the same line (saving about 60pxls of vertical space) is priceless
> > > (for me at least :-)
> >
> > I agree about putting the addressbar on the same line as the menus. It gives
> > more room for the html :)
> > It would take 2 changes I think in the gnome-app.c file. From what I can tell
> > the GNOME_DOCK_ITEM_BEH_EXCLUSIVE flag needs to be removed from
> > gnome_app_set_menus and gnome_app_set_toolbar
> >
> > Iain
>
From miles@amazon.com
Received: (qmail 16438 invoked from network); 25 Jan 2000 22:28:40 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 25 Jan 2000 22:28:40 -0000
Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.153])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id RAA11597
for <gnome-list@gnome.org>; Tue, 25 Jan 2000 17:28:39 -0500
Received: from mail-proxy-1.amazon.com (mail-proxy-1.amazon.com [10.16.42.201])
by smtp-outgoing.amazon.com (Postfix) with ESMTP
id F079737D; Tue, 25 Jan 2000 14:28:29 -0800 (PST)
Received: by mail-proxy-1.amazon.com id OAA29678; Tue, 25 Jan 2000 14:28:29 -0800 (PST)
Message-ID: <388E23A8.999649AA@amazon.com>
Date: Tue, 25 Jan 2000 14:28:56 -0800
From: Miles Lane <miles@amazon.com>
Organization: Amazon.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: u07ih@abdn.ac.uk
Cc: frantb@rpi.edu, jgotts@linuxsavvy.com, gnome-list@gnome.org,
Miguel de Icaza <miguel@nuclecu.unam.mx>
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
References: <S200001252159.VAA20527@sysa.abdn.ac.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thanks for the clarification.
I think the "make XXXbar take up a whole row" option is extraneous.
If toolbars can be dragged and dropped, I would think that any bar
that is placed alone on a bar should expand to occupy the entire
row, instead of being display as a box around the UI elements (buttons
or menu items).
NOTE: The bars that are currently implemented in Gnumeric *do not do this*.
Instead, the width of each toolbar is fixed.
Miguel has informed me that Anders Carlson (andersca@gnu.org) has written
a hack for the toolbar code that allows toolbars to shrink when a window
is resized smaller than the contents of the toolbars. The behavior is that
some toolbar elements essentially drop out of sight past the right edge
of the toolbar. I have not yet checked out this implementation. It doesn't
solve all the toolbar needs, but it is a step in the right direction.
-miles
u07ih@abdn.ac.uk wrote:
>
> I wasn't advocating putting anything into the same place as the menubar by
> default. I was saying how easy it would be to make it possible.
> But at the moment, nothing can go onto the menu bar, as the menu bar
> has it's row in the gnome-dock exclusively. If the GNOME_DOCK_ITEM_BEH_EXCLUSIVE
> flag is removed, then things can go in the menu bar, if you want them too, or
> they can stay where they are....your choice.
> Maybe this should go into the ui-properties capplet
> "[x]Menu bar takes up whole row"
> "[ ]Toolbar takes up whole row"
>
> Iain
> >
> > In the case of the addressbar, it may be best to not embed it in the
> > menubar. The notion is to allow users to move bars around as they wish.
> > For me, this is useful. If I am surfing a site with long URLs and I want
> > to see most of the URL, I might drag the addressbat to its own row.
> > Otherwise, I'd probably tuck it into a corner of a row so that I could
> > type URLs and paths in on an occaisional basis.
> >
> > u07ih@abdn.ac.uk wrote:
> > >
> > > > The benefit of having less blank space and more room to work is a great UI
> > > > enhancement IMHO. The ability to have the menubar, buttonbar and addressbar
> > > > of IE on the same line (saving about 60pxls of vertical space) is priceless
> > > > (for me at least :-)
> > >
> > > I agree about putting the addressbar on the same line as the menus. It gives
> > > more room for the html :)
> > > It would take 2 changes I think in the gnome-app.c file. From what I can tell
> > > the GNOME_DOCK_ITEM_BEH_EXCLUSIVE flag needs to be removed from
> > > gnome_app_set_menus and gnome_app_set_toolbar
> > >
> > > Iain
> >
From miles@amazon.com
Received: (qmail 20738 invoked from network); 25 Jan 2000 22:32:52 -0000
Received: from mail.redhat.com (199.183.24.239)
by lists.redhat.com with SMTP; 25 Jan 2000 22:32:52 -0000
Received: from smtp-outgoing.amazon.com (smtp-outgoing.amazon.com [209.191.164.153])
by mail.redhat.com (8.8.7/8.8.7) with ESMTP id RAA11937
for <gnome-list@gnome.org>; Tue, 25 Jan 2000 17:32:51 -0500
Received: from mail-proxy-1.amazon.com (mail-proxy-1.amazon.com [10.16.42.201])
by smtp-outgoing.amazon.com (Postfix) with ESMTP
id 072709A5; Tue, 25 Jan 2000 14:32:21 -0800 (PST)
Received: by mail-proxy-1.amazon.com id OAA01642; Tue, 25 Jan 2000 14:32:20 -0800 (PST)
Message-ID: <388E248F.30DD995A@amazon.com>
Date: Tue, 25 Jan 2000 14:32:47 -0800
From: Miles Lane <miles@amazon.com>
Organization: Amazon.com
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: u07ih@abdn.ac.uk, frantb@rpi.edu, jgotts@linuxsavvy.com,
gnome-list@gnome.org, Miguel de Icaza <miguel@nuclecu.unam.mx>
Subject: Re: Micro$oft-style dragable, resizable, stackable menu/button bars.
References: <S200001252159.VAA20527@sysa.abdn.ac.uk> <388E23A8.999649AA@amazon.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Oops. Typo.
This paragraph should read:
> I think the "make XXXbar take up a whole row" option is extraneous.
> If toolbars can be dragged and dropped, I would think that any bar
> that is placed alone on a _row_ should expand to occupy the entire
> row, instead of being display as a box around the UI elements (buttons
> or menu items).