62819 - Named window manager

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement, P3)

Description

[Azrael AOD]

This is a feature request.
The ability to right-click on a link, and from the menu choose:
   'Open into new named window'

Selecting this then pops up a box inside which is listed the names of all open 
windows, you can then either select one of the current open windows to open the 
link into, or type in a new name and create a window with that name.

This way say I am on an index style page with lots of links, I might want to 
open the links into new windows, one at a time, but rather than close a window 
and re-open a new one, get them all to open into that new second window by 
naming it and directing links to that name.

Essentially this would behave like adding in a target="<whatever>" to the link 
selected.

Only a feature request, so I don't expect to see this appear over night :)

Comment 1

[Boris Zbarsky [:bzbarsky]]

Over to XP apps: gui features.  Setting bug status to New -- looks like a useful
feature to have.

Comment 2

[Blake Ross]

This sounds

* very confusing
* like something that doesn't belong in a context menu (it probably doesn't 
even deserve a UI)
* like nothing that the user has ever seen or done before (naming windows? how 
can I see the name of each window at a glance?)

I recommend wontfix.

Comment 3

[timeless]

Hrm, the ability to change window names would be neat, but I think the way to do
this is to implement a mozilla _content manager that is a drop target.

Reference(s): BeOS Workspaces, OMNIWeb, IE5mac

The most likely place for this currently would be a sidebar panel [and most
likely the user would use the n6 floating sidebar instead of a docked sidebar].

I think I would implement this as a tree. [Maybe a long time in the future we'll
be able to change from tree view to some other forms ...]

The example used here is fictitious.
 Name       FT|Type   | Location
----------------------------------------
*(none)      %|Window | about:blank
-w3         $%|Window | http://www.w3.org/
 *Outline    %|Frame  | http://www.w3.org/sitemap.html
 -Content    %|Frame  | http://www.w3.org/content.html
  *(none)     |iFrame | http://www.w3.org/embedded.html
 +Sidebar     |Sidebar| chrome://sidebar/content/
-mozilla     %|Window | http://www.mozilla.org/
 -Sidebar    %|Sidebar| chrome://sidebar/content/
  *Tinderbox %|iFrame | http://tinderbox.mozilla.org/
  *Search    %|iFrame | chrome://sidebar/content/search.xul
-developer   %|Window | http://developer.netscape.com/
 *Outline     |Frame  | http://www.w3.org/sitemap.html
 *Content     |Frame  | http://www.w3.org/content.html
 +Sidebar     |Sidebar| chrome://sidebar/content/
-(collected)  |bFolder| bookmarks://collected/
the top (none) will have the following hints:
{Name Hover hint} <setting this name will create a new window in the background
with this name>
{Type Hover hint} <You may only set the type of window to Window or Sidebar,
iFrame and Frame are based on content>
{Location Hover hint} <entering or dropping a url here will open a new unnamed
window with the url>

% indicates a named window that others can reference.
$ indicates the currently active
Changing focus manually by selecting a different $ should cause its children to
get % on a first come first serve basis. The top '(none)' would be considered
first in line, even before the window's items. Items that had % and that weren't
clobbered by the $ shift retain their %.

All tree rows should be DnD, so a user could drop a page into any sidebar or
other frame they wish. Lastly, people like the idea of dragging links to a
temporary location for later browsing, but for some reasons they don't find the
current bookmarks system useful, so somewhere in this tree (bottom? top?) could
(should?) be a reference into bookmarks.

Reporter: I agree with blake, open in named window doesn't belong in the context
menu, but this way you can drag a link to (none) and then change the window
name, or create a window by renaming (none) and then drag your link to the new
window/entry.

mpt: please come up with a detailed list of why this is unnacceptable ;-)

Bonus points to allow users to manage frames and windows according to semi
predictable behavior: <delete> => window.close() | frame.delete() |
sidebar.hide(). <insert> => window.addFrame() | sidebar.addFrame() |
bookmark.addFolder()

Comment 4

[Azrael AOD]

well.. umm.. that looked a bit complex... I know this is something as yet un-
done.. and thus new.. but the way I said it would be fast and simple.. I agree 
hiding it somewhere in the menubar would be better.. or perhaps in preferences 
an option to show it up in the right-click context menu.
The sidebar panel idea looks cool.. but would it be qucik and simple.. or time 
consuming and complicated?
Actually glad someone liked the idea.. :)

Comment 5

[HJ]

This kind of window is known as 'linked-window', and used in Opera Browsers!

Friendly, HJ.

Comment 6

[Matthew T (active 1999-2002)]

> mpt: please come up with a detailed list of why this is unnacceptable ;-)



It's unacceptable because:

* I can't understand a word of it

* even if I could understand a word of it, I couldn't see how it could be useful

* even if I could see how it would be useful, I couldn't agree that Mozilla needs

  to provide its own window manager in addition to the one which the user is

  already running

* copying GUI ideas from Opera is like copying engineering ideas from the Leaning

  Tower of Pisa.

Comment 7

[Azrael AOD]

Well firstly I am not copying the idea from Opera because I haven't used it.
And to combat your other points, I'll try to explain a little better.

For the example I'm going to give its easier if the choice is available from 
the right click contact menu, how it gets there (user turning it on from 
somewhere else) is currently irrelevant.

I have one browser window open and it has 10 links on the page. I want to visit 
all ten of these links, but do not want to visit them in the current window and 
use the back button after each one. So I open the first into a new window. To 
do this on every one, but only have 2 windows open at any time, I'll keep 
having to clsoe the new window, and open the next link in a new window.
Say I had another choice: 'Open link into a _named_ window'
I right click on the link, select that option, and a mini window appears with a 
text box and a drop down menu. Into the text box I can type a name, or select 
names of open windows from the drop down box (if any open windows have specific 
names).
I decide to call the second window 'DoubtingThomas' and into it opens the 
target of the first link.
I read the page, and then move onto the next link I want to read.
I right click, select 'open into named window', then from the drop down I 
choose 'DoubtingThomas' and voila, the target of link two appears into the 
second opened browser window.
Thus allowing me to control where pages open up.
Now I hope you do understand what I mean.
You don't have to like the idea or see it as being useful. But I like it. I'd 
use it. And I'm sure I'm not unique in that respect.

Which actually brings up a question.... is there any built in customisable 
ability for the right-click context menu? A way in which extra options can be 
coded in easily by third parties? 

Comment 8

[Azrael AOD]

umm.. context window.. don't know where contact came from.. 

Comment 9

[Daniel Brooks [:db48x]]

I think the stuff timeless has proposed here are really something that would
satisfy those Frame Info bugs. I think it'd be better to open up the current
"Open Web Location" box from the file menu, and add a list of mozilla windows as
choices in the dropdown box. In fact, the Open Web Location should probably be
offering those choices anyway.

The way I look at it, pretty much anything that gets done for this would require
a context menu item, except for timeless' idea for a sidebar panel. A menu item
would have no way of knowing _which_ link to open in an existing window, unless
you wanted it to open the currently focused link, which would, in my opinion, be
more problematic than it's worth.

I say we fix up the open web location dialog so that it shows a list of open
mozilla windows, then implement timeless's idea as a frame info window for bug
41443. (unfortunatly, that would impact the fix blake has for bug 47139, but I
think this would be the better solution anyway...)

Comment 10

[Azrael AOD]

Interesting idea... but if this is done from the 'Open Web Location' then it 
would only work when manually typing in links (can you drop and drag links to 
the open web location box??) I think, so would it then work on links in a page?

Comment 11

[Daniel Brooks [:db48x]]

If we put something the context menu, we can prefill the open web location box
with whatever url the context menu was opened for.

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

Sounds like a good add-on for someone to make. But not me. ->[e-mail]

Comment 13

[Azrael AOD]

just looking back through bugs I had reported.. and thinking it's about time
this one got closed as a wontfix. Anyone?

Comment 14

[John Levon]

Come on then, I dare you !

Comment 15

[Daniel Brooks [:db48x]]

why wontfix it? no one has decided it shouldn't be fixed.

Comment 16

[John Levon]

comment 2
comment 6
comment 13 (reporter)

:shrugs

Let's let this one just sit here pointlessly for another 2 years, yippee

Comment 17

[Azrael AOD]

after careful analysis, I suggest this bug should not be fixed - thus hopefully
answering commment #15's point

Comment 18

[Tony Mechelynck [:tonymec]]

(In reply to comment #16)
> comment 2
> comment 6
> comment 13 (reporter)
> 
> :shrugs
> 
> Let's let this one just sit here pointlessly for another 2 years, yippee

(In reply to comment #17 by the reporter)
> after careful analysis, I suggest this bug should not be fixed - thus hopefully
> answering commment #15's point

Almost five and a half years with no reaction to these (and others above) -- resolving WONTFIX.