36305 - Proxy icon in title bar

Status: NEW

(Core :: XUL, enhancement, P3)

Description

[Henri Sivonen (:hsivonen)]

Since Mac OS 8.5 there has been an option to include a draggable icon in the
window title bar. In Mozilla the icon (if added) could function as a reference
to the location remote file or a direct reference to a local file. The
appearance of the icon would change depending on the the location (remote/local)
of the file. Dragging a reference to a remote file to Finder would create an
Internet pointer to the remote file and set the name of the Internet pointer to
the title of the document. Dragging to a target accepting text would be
equivalent to dragging the URL as text. Dragging a reference to a local file
would have the same effect as dragging the file in Finder.

Comment 1

[Peter Trudelle]

XPToolkit has no time to do this, targetting M30, adding helpwanted keyword.

Comment 2

[Andrew Thompson]

Also, becoming convention to support Finder behaviour by showing enclosing 

contexts when command clicking the name in the title bar.



e.g. the Finder shows enclosing folders

BBEdit and CodeWarrior should folders enclosing file being worked on

IE5 shows enclosing folders in url....



so 



www.foo.com/bar/baz/bat/index.html



would give a menu containing



www.foo.com

www.foo.com/bar/

www.foo.com/bar/baz/

www.foo.com/bar/baz/bat



Will investigate docs and try to attach a URL describing icon trick for 

reference by whoever might find time to implement this. (or I might do it myself

if it looks easy enough)

Comment 3

[Andrew Thompson]

Here is URL of docs - looks easy enough to support default behaviour, as
Mozilla browser windows aren't document orinented, so simply creating an 
internet shrotcut, similar to how dragging the icon in the URL bar on the mac 
should work. Indeed, it looks like the WindowManager may do this for you.

Supporting in composer and messenger will be more interesting, as these have the 
concept of unsaved documents...

http://developer.apple.com/techpubs/macos8/HumanInterfaceToolbox/WindowManager/
ProgWMacOS8.5WindowMgr/WindowMgr.5.html

Comment 4

[Andrew Thompson]

Tracking a Proxy icon drag:
http://developer.apple.com/techpubs/macos8/HumanInterfaceToolbox/WindowManager/﷒0﷓

Displaying a popup path menu:
http://developer.apple.com/techpubs/macos8/HumanInterfaceToolbox/WindowManager/﷒1﷓

Comment 5

[Peter Trudelle]

There may be other issues with this if/when we take over the native windows in XUL.

Comment 6

[Henri Sivonen (:hsivonen)]

Why would you want to take over the window border rendering in XUL? Why reinvent the 
wheel? My guess is that trashing native windows would not only prompt even more 
complaints from Mac users, but would also prompt complaints from Linux/UNIX users and 
even some complaints from Windows users.

Comment 7

[Peter Trudelle]

Everything we are doing could be seen as 'reinventing the wheel'.  In this 
case, taking over drawing of window borders allows us to do webtops/desktops, 
MDI-style UI, and skin the entire window.

Comment 8

[Matthew T (active 1999-2002)]

Oh, come on. This has stopped being funny now.
* Doing `webtops/desktops' is the role of the OS, if indeed it is a good idea
  (and how much of a good idea it is can be gauged by the popularity, or lack
  thereof, of Microsoft's `Active Desktop').
* MDI is an abomination unto the user, and should never have been invented.
* Skinning the entire window is the role of the OS.

If Mozilla stops using native windows on any OS which has them, the first thing I 
will do is laugh. The second thing I will do is leave the sinking ship -- quit 
contributing to Mozilla UI design/QA/documentation/anything else, and go and 
volunteer for another project. (Mnemonic is looking interesting ...)

Re lordpixel's comment about unsaved documents: in that case, the icon in the 
title bar should appear disabled -- as it does in BBEdit.

Comment 9

[Marko Macek]

MDI, eeekk!

OS/2 has draggable icon too.

On X this would require window manager support. I was considering adding this to
icewm based on _MOZILLA_URL X property (just need to get Xdnd finished). Icewm
already has the icon in proper location (OS/2 like). If anybody is interested in
this, mail me.

If mozilla ever draws the border/titlebar (on windows only, it's not workable
proposition for X), I hope it is *considerably* faster responding to user input
than it is now. Any delay >> 0.1 second ever would be totally unacceptable.
Right now mozilla often goes to sleep for several seconds without responding.
This is why X has superior window management, one process is responsible for it
and apps cannot interfere a lot (unless the toolkit is broken and grabs the
mouse and locks up, which reminds me that I need to file a bug about mozilla
doing this on Windows).

Comment 10

[Henri Sivonen (:hsivonen)]

Reality check:

* Mozilla is not the only app around. It is not even the only browser around. It not the only 
software technology around that attempts to be a middleware platform for cross-platform 
apps.

* End users will run other apps, too. Other apps will use native widgets and windows. 
Mozilla will not look good among the crowd, if it doesn't respect the system-wide theme 
settings.

* Styling window borders is a job for the system-wide window manager. The window 
manager can be built-in to the OS (Mac OS, Windows) or up to the user to choose (X11).

* The desktop belongs to the system. The desktop software can be built-in to the OS (Mac 
OS, Windows) or up to the user to choose (X11).

* The UI for launching apps belongs to the system.

* MDI makes interapplication operations more difficult to conduct. Users who don't want 
to see multiple apps at the same time can use the hiding features of the windowing 
system they are using. They don't need MDI to hide other apps. Savvy users who want to 
work with multiple apps won't like MDI style windowing. While Windows users may 
silently accept MDI, there is no good reason why Mac and Linux/UNIX users should 
accept MDI style windowing.

* Mac users are known to care a lot about the UI. They didn't choose a Mac for nothing.

* Linux/UNIX users choose their window manager for a reason. They are not going to like 
an app that doesn't respect their choice.

* There is a lot work being done to bring consistency to UI toolkits, desktops and 
windowing on Linux. Doing things differently will not only be counter-productive on Mac 
and Windows, it will also be counter-productive on Linux.

* Windows and Mac users can continue using IE if Mozilla fails to respect platform 
conventions.

* Moving from normal native windows to borderless native windows with XUL borders 
does not yield considerable benefits in terms of managing events. In fact, it would be 
more diffucult to implement things like window moving and resizing.

Comment 11

[Peter Trudelle]

I don't think it is appropriate to start discussing long lists of issues and 
points here.  This is a bug report, and it is effectively not assigned.  If 
anyone wants to comment on the requested enhancement, or take on the work, that 
would be great; but please post more general comments, and the ensuing 
discussions, in the appropriate newsgroups.  Thank you.

Comment 12

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 13

[Matthew T (active 1999-2002)]

Adding 4xp because IE 5 has this (on both Windows and Mac OS), pp because it 
will require different implementations on each platform.

Comment 14

[Henri Sivonen (:hsivonen)]

Nominating for Mozilla 1.0. This is a feature new apps are expected to have.

Comment 15

[Andrew Thompson]

heh. mine.

Here's a code fragment:

case inProxyIcon:
			{
				RgnHandle dragRgn = ::NewRgn();
				DragReference theDrag;
				OSStatus status;
				const char * url = "http://www.apple.com";
				SetWindowModified(whichWindow, false);
				status = ::BeginWindowProxyDrag(whichWindow, &theDrag, dragRgn);
				
				::AddDragItemFlavor(theDrag, 0, 'url ' ,url,20, 0);
				
    			if( status == errUserWantsToDragWindow ) {
        			//fall through into inDrag
 	   			} else if( status == noErr ) {
 	   				status = ::TrackWindowProxyFromExistingDrag( whichWindow, 
anEvent.where, theDrag, dragRgn  );
    				if( status == errUserWantsToDragWindow ) {
        				//fall through into inDrag
 	   				} else if( status == noErr ) {
 	   				
 	   				}
 	   				status = ::EndWindowProxyDrag(whichWindow, theDrag);
 	   				if( status == errUserWantsToDragWindow ) {
        				//fall through into inDrag
 	   				} else {
       			   		if (dragRgn) ::DisposeRgn(dragRgn);
       			   		break;
       			   	}
       			}
       			//before falling through, clean up
       			if (dragRgn) ::DisposeRgn(dragRgn);
        	}
        	case inDrag:

All this does (when combined with a couple of other trivial changes) is to make 
the Proxy icon in the Mac title bar draggable to the desktop, where it magically 
becomes a shortcut to www.apple.com.

Much more work is needed

(i) Only add icons to windows which currently support it. I'll probably do

	* Navigator
	* Bookmarks - maybe, if I can get the currently selected URL...
	* ?Messenger? Drag a URL to the news story currently in the 3 pane?
	* Mail compose
	* Composer

As you go down the list, the less likely I am to implement that window type.
If we don't have it implemented yet, that window should not have an icon.

(ii) Determine what sort of window is having its icon dragged when the drag 
begins. If (i) is fixed then only supported windows will ever have drags, so 
this'll be a simple dispatch...

(iii) if its a Navigator window get the URL in the addressbar and make a shortcut 
if its dropped in the finder, etc...

(iv) For compose windows, need to manage dirty state of window (as you can't drag 
when there are unsaved changes) with a document state listener. Need to find out 
where to add this listener - i.e. what file to put my functions in. If the window 
is clean, then need to associate proxy icon with file on disk.

My main focus will be to get Navigator windows going. Once that's fixed I may 
well file new bugs for each other kind of window to encourage each team to fix 
their own.

Comment 16

[Matthew T (active 1999-2002)]

Cool! Andy, I suggest this bug just be for the ability to use XUL or JS to 
specify icon data (image, URL of data which the icon represents, and
enabled/disabled status) for a document window in any XP Toolkit application, and 
for this to work the right way in Mac OS *and* in Windows and OS/2 (so you'll 
need to reassign to someone for the Windows part once you're done on Mac). 
Separate depending bugs can then be filed to hook this up for specific windows in 
the Mozilla application in particular.

[Removing 4xp, since the definition of 4xp has changed.]

Comment 17

[David Hallowell]

Can we leave this out of Win32, the fact that (Internet) Explorer does this just
defys win32 platform conventions. In every win32 app that I've used (except for
the explorer file manager and IE) the menu that appears when you click the mouse
button appears on mousedown, in explorer it appears on mouse up.

I still have a habit of using this menu, probably because of my days of using
win3.1 so the fact that menus appear on mouse up in explorer is annoying when
you like to mousedown, drag and release to activate a menu.

I'd like to know what benefit this would bring to anyone on a Windows
platform,the icon next to the URL bar can be used for drag and drop.

Comment 18

[Andrew Thompson]

Seems fair enough to me. I think this all got mixed up in the desire to have 
different icons for Mail and News, Navigator, Addressbook, in the windows 
taskbar. The drag behaviour isn't really necessary on windows for the reasons you 
note.

I note the icon bits been done in NS 6.1

Comment 19

[Christian Reis]

*** Bug 93155 has been marked as a duplicate of this bug. ***

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.