multivew branch status & UI decisions

View: New views
14 Messages — Rating Filter:   Alert me  

multivew branch status & UI decisions

by Jared Moore-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 :)

(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 decisions

by Luca Cappelletti :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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 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 decisions

by Jared Moore-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi 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 decisions

by Dylan McCall :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi 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

signature.asc (196 bytes) Download Attachment

Re: multivew branch status & UI decisions

by Calum Benson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


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.


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 decisions

by Calum Benson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 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 decisions

by Luca Cappelletti :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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 decisions

by Luca Cappelletti :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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 decisions

by Jared Moore-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi 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 decisions

by Luca Ferretti :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

> 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

signature.asc (196 bytes) Download Attachment

Re: multivew branch status & UI decisions

by Jared Moore-4 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

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 decisions

by Cosimo Cecchi-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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 sources

by Christian Neumair-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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           | ******


* 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 sources

by John Stowers :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On 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