Closed Bug 7696 Opened 25 years ago Closed 12 years ago

Tear-off menus

Categories

(Core :: XUL, enhancement, P5)

Product:
Core
Component:
XUL
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: roland.mainz, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: arch, helpwanted, uiwanted, Whiteboard: Please reopen or verify bug 148057 when this bug is resolved [wontfix?])

Attachments

(1 file)

Screenshot of Motif window (CDE Filemanager "dtfile") and it's tear-off windows...
34.55 KB, image/gif
Details 
Please add "Tear-offs" in all cases where they make sense, including the menus
(Motif has this feature, and GTK+ AFAIK, too).

Send me a mail if you need source examples !!
Status: NEW → ASSIGNED
Priority: P3 → P5
Target Milestone: M15
enhancement request, not currently on our schedule.  If someone wanted to add
this in a cross-platform way, we would happily fold it into the code.  But the
editor team will not be coding this feature any time soon.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → REMIND
cc'ing Akkana and Saari.  Unless I hear otherwise from one of them, I'm marking
this REMIND since we won't have time to get to it in 5.0.
Status: RESOLVED → REOPENED
Component: Editor → XP Toolkit/Widgets
Assignee: buster → trudelle
Status: REOPENED → NEW
What does this have to do with the editor?  Isn't this an xpfe menu request?

Reopening and assigning to xptoolkit -- they can indicate whether tear-offs are
in the schedule or not (I'm guessing no).
Status: NEW → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: REMIND → LATER
resolving as later
Any change here ?
IMHO tear-offs are very simple - in Motif it's a simple flag to turn on
tear-offs for menus...
My team has no plans to do this work in the current release schedule, but you or
anyone else who wants to is free to implement it and submit it for inclusion.
Note that we don't use Motif on the major platforms we are targetting, although
someone may be working on a port.  The menus are XP on Unix and Windows, so
you'd be adding this support to the toolkit, not just enabling it for a menu.
Any status change here ?

Can you give us a hint where (src path) to start an implementation ?
I'm not a menu expert by any means, but if no one gives you more specific info,
one place to start might be to look at
layout/xul/base/src/nsMenuFrame.cpp and the other related files in that
directory.

You can also use lxr -- http://lxr.mozilla.org/seamonkey/ -- to search around
for other files with the name "Menu" in them.
reopening all latered bugs
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Moving all latered bugs to M20 as ordered by project manager.  Although these 
bugs are now open, assigned and targetted, XPToolkit has no plans to 
fix/implement them in the current release cycle, if ever.
Target Milestone: M15 → M20
Why ? GTK has tear-offs, Motif has tear-offs... why not impelementig tear-offs.
They're VERY usefull, at least in the editor...
Please tell us at least 3 good reasons why not implementing tear-offs ?
Sure, tear-offs are great, but:

1) We're not using GTK (for menus anyway)
2) We're not using Motif.
3) We don't have the time/resources to do it.

But this is open source.  Why aren't *you* implementing them?  You give *me*
three reasons.  ;-)


1. Someone has to learn how Mozilla works - the beats is pretty complex ;-(
2. Someone has to learn XPToolkit
3. Somone has to spend time for implementing this
4. Some has to spend time for implemeting usefull features in Mozilla =:-)

Issue "3" (better: "spend time in other projects than his/her own ones...") is
currently my biggest problem which prevents me from doing "1." and "2."... ;-(

Please... what about a prototype implemenation - or at least the "HELPWANTED"
keyword...
And there's only the need for an Unix-implemenation - WinXX?? users shouldn't
get such usefull things (without paying something to M$... =:-)
Whoever wants them can add HelpWanted, it isn't something we are asking for help
on. As far as I"m concerned, 'someone' is you.  An XP implementation would be
best...

Added HELPWANTED...

----

> As far as I'm concerned, 'someone' is you.

You may take a look at the CC line... I'm not alone :-)
Keywords: helpwanted
Resummarizing -- no real reason this should apply just to Unix, or just to menus.
Summary: Unix: "tear-offs" → Tear-off menus/toolbars
> Resummarizing -- no real reason this should apply just to Unix, or just to
menus.
But I would be nice if Mozilla won't look equal on all platforms. There should
be some platform-dependent visual&functional changes to "fit" better into that
specific environment (for example special skins for WinXX??, Mac, Unix (CDE,
KDE, Enlightment etc.)... Should I file a RFE for this ?
Yes, but the fact that some feature is typically only found in apps on a 
particular platform is, by itself, no reason not to make it available to other 
platforms. For example, just because dragging some text from an app to the 
desktop usually produces a text clipping on MacOS, and only MacOS, that doesn't 
mean that when that is implemented in Mozilla it should only happen on MacOS, 
when an equivalent feature (producing a .txt document, say) could just as easily 
be implemented on Windows and X at the same time.

There are already bugs open for making Mozilla look and feel more like a native 
app on various platforms. But in general, look and feel != functionality.

We already have lots of mechanisms for making UI items appear different, a way
for a "skin" to collect a lot of these looks together (e.g. into a "skin that
looks like MacOS"), and a way of letting the user personally override many of
these if he doesn't like the skin.

If you have a specific need that isn't filled by the existing mechanisms, then
yes, you should file a bug on that need.  (This bug, on tear-offs would be one
such example of something which our current architecture doesn't support, but
which would be needed to make a UI look like, say, Motif.)

You should probably have a look at the skin architecture (which has changed
recently and is much more powerful now), at XBL, and at nsLookAndFeel stuff to
see what works now.

You'll get basically no sympathy for "I want to add a feature on platform X but
include ifdefs to make sure it won't work on platform Y."  One of the beauties
of our architecture is that someone who'se used to platform X, who moves to
platform Y and says YUCK!, can then set their skins and prefs and so forth to
make mozilla on platform Y look just like it did on platfor X.
Sorry, I just now read this bug. If someone is interested in working on tear off 

menus I can help get you started. You'll want to be looking at the 

nsMenuPopupFrame to see how XP menus are implemented. You'll probably need a new 

menu dismissal listener with different behavior. The hard part would be deciding 

how to do the tearing off. You could probably render a grippy at the top of the 

menu that orphaned the menu's content model when it got clicked on. Then you 

could move the menu around by the grippy. Just a rough guess of how to do this.


Mass move of all M20 bugs to M30.
Mass move of M20 bugs to M30
Target Milestone: M20 → M30
Status: REOPENED → ASSIGNED
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
Has any work begun on this ?
Arthur Barrett: no, would you like to do it for us?

But seriously, in order to do this, we need a way to create floating objects 
and a decision about how they should appear.  MacOS and Windows have mini 
windows w/ smaller close boxes and no menus.  Linux has no standard, I don't 
pay enough attention to gtk to know for sure.  Personally I think i'd want a 
close widget on whatever floating objects we have. But maybe that should be 
discussed in a newsgroup.
Keywords: arch
IMHO on Unix/Linux we should follow the Motif-behaviour for "floating" objects
like tear-offs.
I'll attach a screenshot for this.
Note that sizing/iconificaton of those "floating" windows have been disabled
(they'll be iconified with the parent window), e.g. they work like normal Motif
"dialogs".

*** Bug 48926 has been marked as a duplicate of this bug. ***
Nominating for moz1.0. IMHO this is a glaring omission from the toolkit.

Note: I just marked 48926 as a dup, which was requesting in particular that
toolbars be able to horizontally stack, as well as vertically. Not exactly the
same bug, but the work on this should naturally encompass it.
Keywords: mozilla1.0
I recommed to get the look&feel of the Motif2 tear-offs...
Target Milestone: Future → mozilla1.0
roland: you cannot change the target milestone of bugs not assigned to you.
hopefully trudelle will assign it to somebody who'll do it in the 1.0 timeframe.
Keywords: softui
Target Milestone: mozilla1.0 → Future
trudelle: Sorry... I saw the "mozilla1.0" keyword and forgot that this only is a
"nomination for..." ;-((
*** Bug 15646 has been marked as a duplicate of this bug. ***
all toolkit-owned toolbar enhancements -> ben. nominating moz1.0.
Assignee: trudelle → ben
Status: ASSIGNED → NEW
saari, wouldn't it be better if instead of a grippy being put on the top, on 
could use the grippy already on the menus by dragging them? By grippy, I mean 
the grippy that makes the menu hide when you click on it. Along with that, 
parts of the menu that aren't a button should also work (windows-style).

Timeless: 

How about instead of a close button, making it possible to right click on a 
menu or grippy to hide it (if its hideable).

I personally detest close buttons because I always click on them by accident. ;-
)

I am thinking of implementing this. Saari, how much work do you think it would 
be for someone not to familiar with the menu system but familiar with XPCOM?
Filed bug 88582 as a solution to timeless's idea.
netdemon: you're doomed.
I have some code that may be of use to someone doing this implementation. It is
a box object for XUL popups. 

Code exists already in xpfe/global/resources/content/bindings/popup.xml for
resizable draggable popup windows. 


Uhm...
From a end-users perspective, tearoff *MENUS* are extremely annoying.
Nobody will *EVER* want to tear-off say, "Edit" menu.

Draggable toolbars is fine. Tearoff toolbars is fine too, as long as this doesnt
get in the way.

But tearoff menus ALWAYS get in the way.
No, Motif did NOT get this one right.
And neither did GTK.

Whoever is/will be working on this feel free to add this feature but a clearly
visible pref (enabled by default) should be present to remove all tearoff menu
features completely.
I changed my mind. I don't have time for this at the moment.
I feel confident in proxying pink in saying that by default, none of our *menus*
will ever be tear-off. 
I still strongly vote _FOR_ tearoff menus. They are usefull in most cases -
think abou Nedit and other editors...
you can vote, but you'll be outvoted ;) 

I seriously recommend removing the tear off menu part from this bug and placing
it in a new bug (which should get marked future, nobody, helpwanted). It seems
there is not much support for tearoff menus at the moment and it is more of a
cutesy feature. Where it can come in handy though is for nested menus.
Therefore, maybe someday but not today.


On the other hand, tearoff menus are like really cool dude! Not having tear off
menus is pretty BAAAAAAAAAd ;-)
Doh! I mean tear off toolbars for part 2. Need sleepy.

BTW - sometimes it is BAAAAAAAAAtter not to put multiple features in one bug
when they are so diiiiifferent.
Summary: Tear-off menus/toolbars → Tear-off toolbars
Tearoff toolbars sounds good, tearoff menus, not really.
Changing description.
Please file a new bug for "tearoff toolbars".
This original bug is about "Unix tearoffs" (which means: "Motif menu tearoffs").
Summary: Tear-off toolbars → Tear-off menus
Oh, well if this bug is just for tear-off menus, then Ben: I suggest you resolve
this as WONTFIX. I eagerly await docking toolbars however.
I don't agree with this being marked WONTFIX since it is a valid request, but
there seems to be higher priorities ATM. If the whole menu bar tore off it still
might be useful to tear off just one menu, although I can't see how it would be
done gracefully. Sometimes people drag a menu accidentally or click multiple
times when their system bogs down. Some people even right click on a menu by
accident. I was thinking of a double click and drag or a shift and drag as an
option. But I think a double click and drag (as in click once, twice and hold,
and drag) would be a cool way to go about this.
Status: NEW → ASSIGNED
Blocks: 148057
Blocks: 148058
Ben, will you be fixing this bug? Or should this bug be reassigned to
nobody@mozilla.org?
Whiteboard: Please reopen or verify bug 148057 when this bug is resolved
Assignee: bugs → jag
Status: ASSIGNED → NEW
QA Contact: sujay → xptoolkit.widgets
Assignee: jag → nobody
Whiteboard: Please reopen or verify bug 148057 when this bug is resolved → Please reopen or verify bug 148057 when this bug is resolved [wontfix?]
Does anyone have a clear description of what this actually is? Alex, is this something Mozilla wants to implement, and if so, can we get a design spec of sorts?
Keywords: uiwanted
>uiwanted

Starting a triage of bugs marked with uiwanted.  Overall our goal is to perfectly match the surrounding desktop environment.  So if we were to implement tear off menus, we should only provide the functionality if it were available and enabled for all other apps, and we definitely would not want cross platform support for platforms like OS X and Windows where this behavior is not standard or expected.
I don't think any current desktop environment in common use have tear-off menus. Closing. Too bad it didn't make it for the Netscape 5.0 release.
Status: NEW → RESOLVED
Closed: 25 years ago → 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: