|
View:
New views
14 Messages
—
Rating Filter:
Alert me
|
|
|
multivew branch status & UI decisionsHi all,
I have been making progress in my multiview (i.e. tabs) development branch [1]. If you have a look at the whiteboard on that page you will see a brief status overview (TODO, DONE, etc). I'd like to bring up the following UI design decisions that need to be made. By the way if these descriptions don't make sense to anybody except me then I apologise :) (1) Open tab on middle click button press or button release? The behaviour in Epiphany is rather inconsistent: history window middle click will activate on button press, "Home" button in toolbar will activate on middle click (i.e. press and release without leaving the button), and "Bookmarks" menu entries will activate on button release (regardless of where you pressed). The current behaviour in my Nautilus branch is to open a tab on button press. I should probably change this to button release, since that is generally the standard for most UIs (although I can't see anything specific in the HIG). What are people's thoughts about this? If button release is preferred then I guess a bug should be filed against the Epiphany history view. (2) Labels for menu items in "Tabs" menu There are really 2 main options for this - either a (semi)-full path like in gnome-terminal (e.g. "~/Pictures/2006/Beach holiday") or just the current folder (e.g. "Beach holiday"). I am leaning towards the former since it is a bit more informative, although the latter is obviously simpler ( and easier to implement ^.^ ). Currently the latter is implemented because I'm lazy. Thoughts? (3) Open tab by middle clicking on folder in main view Currently in Christian's branch this is a double-middle-click, which is inconsistent - to me this operation seems analogous to middle-clicking a hyperlink in Epiphany. I'd like to change this but first I'd like to check what other people think before I blatantly change the UI decision that Christian made :) Cheers, Jared [1] https://code.launchpad.net/~cornflake-pirate/nautilus/multiview-jm -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsOn Thu, Jun 5, 2008 at 4:24 PM, Jared Moore <jaredm@...> wrote:
Hi all, I think an interesting idea to evaluate is to provide "spring folder" like capability through tabs to let users fly over tabs during a drag and drop action. :) Luca -- --- Luca Cappelletti http://developer.infodomestic.com "...Together we stand, divided we fall." .O. ..O OOO GTalk,MSN: luca <dot> cappelletti <at> gmail <dot> com Linux Registered User: #223411 Ubuntu Registered User: #7221 "l'intelligenza è utile per la sopravvivenza se ci permette di estinguere una cattiva idea prima che la cattiva idea estingua noi" "La chiave di ogni uomo è il suo pensiero. Benché egli possa apparire saldo e autonomo, ha un criterio cui obbedisce, che è l'idea in base alla quale classifica tutte le cose. Può essere cambiato solo mostrandogli una nuova idea che sovrasti la sua" "Uno studioso è soltanto un modo in cui una biblioteca crea un'altra biblioteca " -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsHi Luca,
Thanks for the idea, I didn't think of that! Actually, I just checked, and if I understand you correctly then it seems like that's already implemented. I could be wrong but I think maybe it's part of GtkNotebook - try dragging anything random onto a tab in any random program (e.g. gnome-appearance-properties) and you'll see that it does the right thing. :) Cheers, Jared 2008/6/6 Luca Cappelletti <luca.cappelletti@...>: > > I think an interesting idea to evaluate is to provide "spring folder" like > capability through tabs to let users fly over tabs during a drag and drop > action. > > :) > > Luca > > nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsHi folks,
One problem I have with tabs is that they work just like windows; as superficial entities. They can be dragged, but that simply moves them. It may be moving them to a convenient place, but that is no different from moving a window to another place. Has anyone considered having the tabs work like the breadcrumbs currently do in Browser mode, where they can be dragged and dropped as files, or have files dropped into them, to quickly manipulate files? It would be a nice boost to functionality, and at least the dragging part should be relatively simple to implement. (That's assuming it works the same for tabs as it does for other widgets). With that in place, tabs would be very similar to the breadcrumbs metaphor, except with the user dropping crumbs himself instead of that being an automatic thing. Besides this, drag and drop is awesome but can only work if it happens everywhere. Bye, -Dylan PS: I must admit to being afraid of Nautilus' code to this day, so it is unlikely I could implement this myself. -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsOn Mon, 2008-06-09 at 20:30 -0700, Dylan McCall wrote: > Has anyone considered having the > tabs work like the breadcrumbs currently do in Browser mode, where they > can be dragged and dropped as files, or have files dropped into them, to > quickly manipulate files? It would be a nice boost to functionality, and > at least the dragging part should be relatively simple to implement. To generalise that idea, what you're really talking about here is having some part of any window (e.g. the icon in its tab or titlebar) act as a proxy for the document(s) it contains. Sun's OpenWindows desktop used to do this quite extensively[1]; MacOS X still does it today in a rather more half-hearted fashion. Cheeri, Calum. [1] <http://docs.sun.com/app/docs/doc/806-2901/6jc3a4lqj?l=en&a=view> [2] <http://theappleblog.com/2007/07/20/quick-tip-window-title-bar-icon/> -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.benson@... GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsOn Tue, 2008-06-10 at 13:10 +0100, Calum Benson wrote: > On Mon, 2008-06-09 at 20:30 -0700, Dylan McCall wrote: > > > Has anyone considered having the > > tabs work like the breadcrumbs currently do in Browser mode, where they > > can be dragged and dropped as files, or have files dropped into them, to > > quickly manipulate files? It would be a nice boost to functionality, and > > at least the dragging part should be relatively simple to implement. > > To generalise that idea, what you're really talking about here is having > some part of any window (e.g. the icon in its tab or titlebar) act as a > proxy for the document(s) it contains. Sun's OpenWindows desktop used > to do this quite extensively[1]; MacOS X still does it today in a rather > more half-hearted fashion. And just to finish the email that Evolution sent before I was ready: this has come up as an idea on GNOME mailing lists etc. a few times before, but it's never progressed beyond the 'that sounds cool' stage, for whatever reason. Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:calum.benson@... GNOME Desktop Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsOn Thu, Jun 5, 2008 at 4:24 PM, Jared Moore <jaredm@...> wrote:
> (3) Open tab by middle clicking on folder in main view > > Currently in Christian's branch this is a double-middle-click, which > is inconsistent - to me this operation seems analogous to > middle-clicking a hyperlink in Epiphany. I'd like to change this but > first I'd like to check what other people think before I blatantly > change the UI decision that Christian made :) > I found really useful on how you can add new tab using a visual item near the last opened tab as you can see i.e. in Gecko based Flock or new MS IE8: [tab 1] [tab 2] [tab 3] [+] Here's a screenshot of what I mean: http://live.gnome.org/LucaCappelletti/Nautilus -- --- Luca Cappelletti http://developer.infodomestic.com "...Together we stand, divided we fall." .O. ..O OOO GTalk,MSN: luca <dot> cappelletti <at> gmail <dot> com Linux Registered User: #223411 Ubuntu Registered User: #7221 "l'intelligenza è utile per la sopravvivenza se ci permette di estinguere una cattiva idea prima che la cattiva idea estingua noi" "La chiave di ogni uomo è il suo pensiero. Benché egli possa apparire saldo e autonomo, ha un criterio cui obbedisce, che è l'idea in base alla quale classifica tutte le cose. Può essere cambiato solo mostrandogli una nuova idea che sovrasti la sua" "Uno studioso è soltanto un modo in cui una biblioteca crea un'altra biblioteca " -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsOn Thu, Jun 5, 2008 at 4:24 PM, Jared Moore <jaredm@...> wrote:
> Hi all, > > I have been making progress in my multiview (i.e. tabs) development > branch [1]. If you have a look at the whiteboard on that page you will > see a brief status overview (TODO, DONE, etc). > > I'd like to bring up the following UI design decisions that need to be > made. By the way if these descriptions don't make sense to anybody > except me then I apologise :) > If you're interested I made a SpatialBundle for ubuntu 8.04 of the 2008 06 06 trunk of Nautilus multiview jm found on launchpad. I think it's useful just for pure testers that does not want to recompile but just download click and run directly test and report issues and bugs. Here's the url: http://sourceforge.net/project/showfiles.php?group_id=199098&package_id=246689 does not require installation nor root password to run, just chmod +x and click. I use it with profit for daily usage after substituted from my gnome session and save the session before logout. ciao :) Luca. -- --- Luca Cappelletti http://developer.infodomestic.com "...Together we stand, divided we fall." .O. ..O OOO GTalk,MSN: luca <dot> cappelletti <at> gmail <dot> com Linux Registered User: #223411 Ubuntu Registered User: #7221 "l'intelligenza è utile per la sopravvivenza se ci permette di estinguere una cattiva idea prima che la cattiva idea estingua noi" "La chiave di ogni uomo è il suo pensiero. Benché egli possa apparire saldo e autonomo, ha un criterio cui obbedisce, che è l'idea in base alla quale classifica tutte le cose. Può essere cambiato solo mostrandogli una nuova idea che sovrasti la sua" "Uno studioso è soltanto un modo in cui una biblioteca crea un'altra biblioteca " -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsHi Luca,
I agree with you, but as far as I know it's not currently possible to do that using GtkNotebook. Have a look at this bug: http://bugzilla.gnome.org/show_bug.cgi?id=116650 Cheers, Jared -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsIl giorno ven, 06/06/2008 alle 00.24 +1000, Jared Moore ha scritto:
> Hi all, > > (1) Open tab on middle click button press or button release? > > The behaviour in Epiphany is rather inconsistent: history window > middle click will activate on button press, "Home" button in toolbar > will activate on middle click (i.e. press and release without leaving > the button), and "Bookmarks" menu entries will activate on button > release (regardless of where you pressed). Maybe it's just a bug in Ephy, not a design choice. > The current behaviour in my Nautilus branch is to open a tab on button > press. I should probably change this to button release, since that is > generally the standard for most UIs (although I can't see anything > specific in the HIG). What are people's thoughts about this? I agree on release. > If button release is preferred then I guess a bug should be filed > against the Epiphany history view. IMHO, let's go and file it :-) > (2) Labels for menu items in "Tabs" menu > > There are really 2 main options for this - either a (semi)-full path > like in gnome-terminal (e.g. "~/Pictures/2006/Beach holiday") or just > the current folder (e.g. "Beach holiday"). I am leaning towards the > former since it is a bit more informative, although the latter is > obviously simpler ( and easier to implement ^.^ ). Currently the > latter is implemented because I'm lazy. Thoughts? gedit is using only file name (full path showed in statusbar when menuitem is focuses). IMHO is the best choice. BTW, gedit also provide a tooltip for tab labels with full path and additional info, matching previous Tabs menu layout. Maybe could be good in Nautilus too (I don't have a fresh multiview branch build to check current behavior). Oh, maybe in Finder history or recent files menu in MacOS, I don't remember exactly, but one of them or both should have the really interesting feature to provide only the filename when it's unique and the full path otherwise. Example: <Menu> Document 1 Document 2 /first/path/to/README /second/path/to/README Could be really cool have it in Gtk+ > (3) Open tab by middle clicking on folder in main view > > Currently in Christian's branch this is a double-middle-click, which > is inconsistent - to me this operation seems analogous to > middle-clicking a hyperlink in Epiphany. I'd like to change this but > first I'd like to check what other people think before I blatantly > change the UI decision that Christian made :) Ephy is a web browser, so it works only with single-clicks. Nautilus is a file manager, I think we should respect the double/single click option in preferences (Edit->Preferences >> Behavior tab). So, if you have double-clic on left button, you should have double-middle-clic on middle button. And if you have single-click on left button, you should have single-middle-click on middle button. Right button always and only works with single clic, I suppose. PS Is it planned (or maybe yet implemented) a "create a new window dragging out a tab" feature? PPS are you (and Christian) keeping track of feature in order to update the user guide? We'll have to document how the tabs works... -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsHi,
FYI all my work has been committed to Christian's SVN branch, so I have taken down the Launchpad bzr branch. On Wed, Jun 11, 2008 at 4:28 PM, Luca Ferretti <elle.uca@...> wrote: > Il giorno ven, 06/06/2008 alle 00.24 +1000, Jared Moore ha scritto: >> Hi all, >> > >> (1) Open tab on middle click button press or button release? >> >> The behaviour in Epiphany is rather inconsistent: history window >> middle click will activate on button press, "Home" button in toolbar >> will activate on middle click (i.e. press and release without leaving >> the button), and "Bookmarks" menu entries will activate on button >> release (regardless of where you pressed). > > Maybe it's just a bug in Ephy, not a design choice. > >> The current behaviour in my Nautilus branch is to open a tab on button >> press. I should probably change this to button release, since that is >> generally the standard for most UIs (although I can't see anything >> specific in the HIG). What are people's thoughts about this? > > I agree on release. > Ok, that's easily fixed. >> If button release is preferred then I guess a bug should be filed >> against the Epiphany history view. > > IMHO, let's go and file it :-) Filed: http://bugzilla.gnome.org/show_bug.cgi?id=537731 > >> (2) Labels for menu items in "Tabs" menu >> >> There are really 2 main options for this - either a (semi)-full path >> like in gnome-terminal (e.g. "~/Pictures/2006/Beach holiday") or just >> the current folder (e.g. "Beach holiday"). I am leaning towards the >> former since it is a bit more informative, although the latter is >> obviously simpler ( and easier to implement ^.^ ). Currently the >> latter is implemented because I'm lazy. Thoughts? > > gedit is using only file name (full path showed in statusbar when > menuitem is focuses). IMHO is the best choice. > > BTW, gedit also provide a tooltip for tab labels with full path and > additional info, matching previous Tabs menu layout. Maybe could be good > in Nautilus too (I don't have a fresh multiview branch build to check > current behavior). I didn't notice that tooltip feature. Makes sense to have it in Nautilus. Another thing I didn't notice in gedit was the statusbar message when changing tabs using the "Documents" menu. I'll have a look into that for Nautilus too. > > Oh, maybe in Finder history or recent files menu in MacOS, I don't > remember exactly, but one of them or both should have the really > interesting feature to provide only the filename when it's unique and > the full path otherwise. Example: > > <Menu> > Document 1 > Document 2 > /first/path/to/README > /second/path/to/README > > Could be really cool have it in Gtk+ > That's a good idea, since it allows for both conciseness and unambiguity. I think that should definitely be the default. Do you think it's worth adding a hidden GConf preference? >> (3) Open tab by middle clicking on folder in main view >> >> Currently in Christian's branch this is a double-middle-click, which >> is inconsistent - to me this operation seems analogous to >> middle-clicking a hyperlink in Epiphany. I'd like to change this but >> first I'd like to check what other people think before I blatantly >> change the UI decision that Christian made :) > > Ephy is a web browser, so it works only with single-clicks. > > Nautilus is a file manager, I think we should respect the double/single > click option in preferences (Edit->Preferences >> Behavior tab). > > So, if you have double-clic on left button, you should have > double-middle-clic on middle button. And if you have single-click on > left button, you should have single-middle-click on middle button. Right > button always and only works with single clic, I suppose. > Good point. Now that I check, it looks like that's how Christian has implemented it so I'll leave it that way. > > PS Is it planned (or maybe yet implemented) a "create a new window > dragging out a tab" feature? I might implement that sometime soon but maybe not. I see no good reason for it to not be implemented eventually though :) If & when the tabs code lands in trunk, perhaps a new "Tabs" component should be added in bugzilla. > > PPS are you (and Christian) keeping track of feature in order to update > the user guide? We'll have to document how the tabs works... > Keeping track mentally at the moment. It's in the Changelog anyway, in case I forget or disappear off the face of the Earth. :) Thanks for all your suggestions! Cheers, Jared Moore -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: multivew branch status & UI decisionsOn Wed, 2008-06-11 at 16:59 +1000, Jared Moore wrote:
> Hi, > > FYI all my work has been committed to Christian's SVN branch, so I > have taken down the Launchpad bzr branch. Great work! That's good news to hear :) [snip] > > PPS are you (and Christian) keeping track of feature in order to update > > the user guide? We'll have to document how the tabs works... > > > > Keeping track mentally at the moment. It's in the Changelog anyway, in > case I forget or disappear off the face of the Earth. :) I suggest to mail gnome-doc-list@... for a language and screenshot review for this :) Cheers! -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
document icons as DND sourcesAm Dienstag, den 10.06.2008, 13:10 +0100 schrieb Calum Benson:
> On Mon, 2008-06-09 at 20:30 -0700, Dylan McCall wrote: > > > Has anyone considered having the > > tabs work like the breadcrumbs currently do in Browser mode, where they > > can be dragged and dropped as files, or have files dropped into them, to > > quickly manipulate files? It would be a nice boost to functionality, and > > at least the dragging part should be relatively simple to implement. > > To generalise that idea, what you're really talking about here is having > some part of any window (e.g. the icon in its tab or titlebar) act as a > proxy for the document(s) it contains. Sun's OpenWindows desktop used > to do this quite extensively[1]; MacOS X still does it today in a rather > more half-hearted fashion. > > > [1] <http://docs.sun.com/app/docs/doc/806-2901/6jc3a4lqj?l=en&a=view> > [2] > <http://theappleblog.com/2007/07/20/quick-tip-window-title-bar-icon/> I am a huge fan of DND concepts, and making icons represent documents is totally intuitive from a user perspective, and a major step forward. If this is adopted, it should be done across the entire desktop. I often wanted to to directly trash a downloaded PDF documents, or move it to a particular folder. Some random notes: * [If we re-use the Sun concept]: Where to place the icon / drag handle. The RHS of the toolbar, or an area overlapping both the menu bar and the toolbar seem to be a good choice - where we put a spinner for file and web browsers: [ file edit ... ] | ****** | T O O L | *icon* | B A R | ****** * What other drag handles can we come up with. For instance, window lists could also be used as a drag source. * What actions to offer. move/copy DND is fine, but for PDF documents we may also offer dedicated file operation shortcuts on right-clicking (Trash, Cut, Copy). It would be amazing if you do some UI studies how this could actually look, then we can discuss about getting this into GNOME. :) best regards, Christian Neumair -- Christian Neumair <cneumair@...> -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
|
|
Re: document icons as DND sourcesOn Wed, 2008-06-11 at 21:01 +0200, Christian Neumair wrote:
> Am Dienstag, den 10.06.2008, 13:10 +0100 schrieb Calum Benson: > > On Mon, 2008-06-09 at 20:30 -0700, Dylan McCall wrote: > > > > > Has anyone considered having the > > > tabs work like the breadcrumbs currently do in Browser mode, where they > > > can be dragged and dropped as files, or have files dropped into them, to > > > quickly manipulate files? It would be a nice boost to functionality, and > > > at least the dragging part should be relatively simple to implement. > > > > To generalise that idea, what you're really talking about here is having > > some part of any window (e.g. the icon in its tab or titlebar) act as a > > proxy for the document(s) it contains. Sun's OpenWindows desktop used > > to do this quite extensively[1]; MacOS X still does it today in a rather > > more half-hearted fashion. > > > > > > [1] <http://docs.sun.com/app/docs/doc/806-2901/6jc3a4lqj?l=en&a=view> > > [2] > > <http://theappleblog.com/2007/07/20/quick-tip-window-title-bar-icon/> > > I am a huge fan of DND concepts, and making icons represent documents is > totally intuitive from a user perspective, and a major step forward. > > If this is adopted, it should be done across the entire desktop. I often > wanted to to directly trash a downloaded PDF documents, or move it to a > particular folder. > > Some random notes: > > * [If we re-use the Sun concept]: Where to place the icon / drag > handle. The RHS of the toolbar, or an area overlapping both the menu bar > and the toolbar seem to be a good choice - where we put a spinner for > file and web browsers: > > [ file edit ... ] | ****** > | T O O L | *icon* > | B A R | ****** I quite like the look of http://tango.freedesktop.org/Window_Experiments > > > * What other drag handles can we come up with. For instance, window > lists could also be used as a drag source. > > * What actions to offer. move/copy DND is fine, but for PDF documents we > may also offer dedicated file operation shortcuts on right-clicking > (Trash, Cut, Copy). > > It would be amazing if you do some UI studies how this could actually > look, then we can discuss about getting this into GNOME. :) > > best regards, > Christian Neumair > > -- > Christian Neumair <cneumair@...> > > -- > nautilus-list mailing list > nautilus-list@... > http://mail.gnome.org/mailman/listinfo/nautilus-list -- nautilus-list mailing list nautilus-list@... http://mail.gnome.org/mailman/listinfo/nautilus-list |
| Free embeddable forum powered by Nabble | Forum Help |