Nabble - Gnome - Nautilus

Re: Console output form Nautilus?

2009-12-21T17:54:07Z

On Sun, Dec 20, 2009 at 6:33 AM, Jason Heeris <jason.heeris@...> wrote:

> I'm developing an extension for Nautilus, and so I tend to rely on
> console output when something goes seriously wrong. I recently
> upgraded to 2.28.1 (under Debian Squeeze), and it seems I can no
> longer use my old trick of running "nautilus -q; nautilus
> --no-desktop" to run Nautilus and see messages in the console (despite
> the fact that I have Nautilus set to *not* draw the desktop). All that
> happens now is that it starts up as some sort of background process
> (or, in certain cases, starts up many, many instances until I have to
> use killall or log out... I'm not sure exactly how to reproduce that,
> though).
>
> Is there some way to get console messages from Nautilus? Or is there a
> log somewhere?

The log code is really busted, so that's disabled for now. The real
problem is that gnome-session likes to respawn nautilus after it goes
black for even just a moment, so you have to put a stop to that first.
The easiest way is just 'chmod -x /usr/bin/nautilus', and then kill
it. After that, gnome-session stops trying to respawn it and you can
run it directly from a terminal. The same problem makes it somewhat
harder to debug as well, but you can get around that by attaching gdb
to a running nautilus process (gdb --pid=`pidof nautilus`) and use
G_BREAKPOINT() instead of printf() debugging.

HTH,
-A. Walton

>
> Thanks,
> Jason
> --
> 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

Re: Console output form Nautilus?

2009-12-21T07:19:54Z

>
> I'm developing an extension for Nautilus, and so I tend to rely on
> console output when something goes seriously wrong. I recently
> upgraded to 2.28.1 (under Debian Squeeze), and it seems I can no
> longer use my old trick of running "nautilus -q; nautilus
> --no-desktop" to run Nautilus and see messages in the console
> (despite
> the fact that I have Nautilus set to *not* draw the desktop). All
> that
> happens now is that it starts up as some sort of background process
> (or, in certain cases, starts up many, many instances until I have to
> use killall or log out... I'm not sure exactly how to reproduce that,
> though).

Hi Jason,

As an extension developer too, I've already seen the "Nautilus
starts many many many instances" syndrom: this has appeared
after 'killall nautilus' to take into account a new version of
the extension library. It seems that the system believes that
Nautilus has terminated, so starting a new instance, but the
initial Nautilus process is always in memory.
One reason: one buggy extension library, failing to initialize.

Also, I use g_debug+syslog for debugging messages.

Regards
Pierre
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Console output form Nautilus?

2009-12-20T03:33:28Z

I'm developing an extension for Nautilus, and so I tend to rely on
console output when something goes seriously wrong. I recently
upgraded to 2.28.1 (under Debian Squeeze), and it seems I can no
longer use my old trick of running "nautilus -q; nautilus
--no-desktop" to run Nautilus and see messages in the console (despite
the fact that I have Nautilus set to *not* draw the desktop). All that
happens now is that it starts up as some sort of background process
(or, in certain cases, starts up many, many instances until I have to
use killall or log out... I'm not sure exactly how to reproduce that,
though).

Is there some way to get console messages from Nautilus? Or is there a
log somewhere?

Thanks,
Jason
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

[PATCH] In icon view, wrapping to next row after pressing "right" fails in compact layout

2009-12-19T06:43:14Z

Hi!,
I've submitted a patch for http://bugs.gnome.org/604604 , patch also
attached to this mail, please review.

Thanks :-)

[0001-Fix-wrap-to-next-row-in-compact-layout-bug-604604.patch]

From ba6fea6df79c80e6cbfe37c24cb8d94d62421b1b Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Nelson=20Ben=C3=ADtez=20Le=C3=B3n?= <nbenitezl+gnome@...> Date: Sat, 19 Dec 2009 14:44:56 +0100 Subject: [PATCH] Fix wrap to next row in compact layout, bug #604604 diff --git a/libnautilus-private/nautilus-icon-container.c b/libnautilus-private/nautilus-icon-container.c index 7bf4c12..6de8dbc 100644 --- a/libnautilus-private/nautilus-icon-container.c +++ b/libnautilus-private/nautilus-icon-container.c @@ -3134,18 +3134,12 @@ next_row_leftmost (NautilusIconContainer *container, if (compare_icons_vertical_first (container, best_so_far, candidate) > 0) { /* candidate is above best choice, but below the current row */ return TRUE; } - - if (compare_icons_horizontal_first (container, - best_so_far, - candidate) > 0) { - return TRUE; - } } return best_so_far == NULL; } static gboolean -- 1.6.0.4

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Undo-Redo support patch (updated for gio)

2009-12-18T11:14:57Z

On Mi, 16.12.2009 18:43, BROCCO Amos wrote:

>I've updated my previous patch for undo-redo support to work with GIO.

>Testing, reviews and comments are greatly appreciated!!!

I can only give a personal comment. I did not yet look at or test the
code, just watched the demo, and that looks great. Being
a huge fan of extensive undo/redo capabilities myself, I like the idea
of the patch a lot.

On the other hand, I'd really like a general purpose undo/redo manager
in GTK+ instead of every application having to roll their own. The
corresponding bug entry is
https://bugzilla.gnome.org/show_bug.cgi?id=322194 but I don't know how
far away (or even wanted) such a feature in GTK+ would be.

Holger
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus 2.29.1 released - change in focus

2009-12-17T11:07:05Z

On Thu, 2009-12-17 at 18:09 +0100, Alexander Larsson wrote:

> On Thu, 2009-12-17 at 17:58 +0100, Alexander Larsson wrote:
>
> > First of all we have switched to browser mode by default (spatial is
> > still available from the prefs), secondly we have reorganized the
> > browser UI and added a split view functionality.
>
> Here is a quick screenshot of the current UI in case you're
> interested but don't want to build it:
>
> http://www.gnome.org/~alexl/nautilus-2-29-1.png

Some confusion here, this screenshot is obviously very busy since it
shows off all the new features. A default window will have a lot less
UI. Something like this:

http://www.gnome.org/~alexl/nautilus-2-29-1-2.png

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's a fiendish soccer-playing barbarian with a passion for fast cars. She's a
vivacious blonde journalist with someone else's memories. They fight crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus 2.29.1 released - change in focus

2009-12-17T09:09:36Z

On Thu, 2009-12-17 at 17:58 +0100, Alexander Larsson wrote:

> First of all we have switched to browser mode by default (spatial is
> still available from the prefs), secondly we have reorganized the
> browser UI and added a split view functionality.

Here is a quick screenshot of the current UI in case you're
interested but don't want to build it:

http://www.gnome.org/~alexl/nautilus-2-29-1.png

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's a one-legged drug-addicted vampire hunter with a secret. She's a
sarcastic out-of-work single mother from a family of eight older brothers.
They fight crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Nautilus 2.29.1 released - change in focus

2009-12-17T08:58:19Z

I don't usually do announce mails for Nautilus, (the NEWS file gets
posted on the ftp-release-list anway :) ). However, this release has
some changes that I'd like to point out.

As discussed on the list[1] recently the Nautilus project is going to
make a slight change of focus. Since a long time nautilus has been to a
large extent the "shell" of the Gnome user interface for a lot of
operations, but with the advent of gnome shell we want to make the shell
interface the primary way to interact with the desktop when starting
activities.

This means that when nautilus is started it is more likely to be because
the user wants to do some more advanced file management like
restructuring the directory structure, or copying lots of files, rather
than just locating a file and start working on it. This leads to the
shift in focus which will in turn lead to a few changes in the UI.

First of all we have switched to browser mode by default (spatial is
still available from the prefs), secondly we have reorganized the
browser UI and added a split view functionality. We're also in
discussions about whether to have nautilus manage the desktop or not,
and if so how it should look.

This is all work in progress and further changes are coming as things
mature. Follow the nautilus and gnome-shell list for further
discussions.

Note that we're not shipping gnome-shell (at least by default) for Gnome
2.30, so it could be considered a bit early to do these changes in
Nautilus. I don't necessarily disagree with that, but I want to do these
changes now so that we have enough time to finish and test them before
Gnome 3.0. And, since many distros disable spatial mode by default
anyway its not such a large change.

1)
http://mail.gnome.org/archives/nautilus-list/2009-December/msg00001.html

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's a globe-trotting soccer-playing ex-con She's a sarcastic wisecracking
mermaid in the wrong place at the wrong time. They fight crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Undo-Redo support patch (updated for gio)

2009-12-16T09:43:49Z

Hello,
I've updated my previous patch for undo-redo support to work with GIO.
I've made a patch available on bugzilla (https://bugzilla.gnome.org/show_bug.cgi?id=167501#c34) against Nautilus 2.28.1.

It supports Undo-Redo for the following operations:
- copy / duplicate
- move
- trash
- rename
- make link
- create new folder
- create new file
- create file from template

I've tried to touch the existing code (mainly nautilus-file-operations.c) as
little as possible.

Testing, reviews and comments are greatly appreciated!!!
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-14T15:46:31Z

On Wed, 2009-12-02 at 16:08 +0100, Alexander Larsson wrote:
> For instance, gnome-shell focuses a lot on using search to find files
> and other things of interest. Nautilus also does search, but only
> for files. The g-s search is more integrated in the desktop and gives
> multiple types of results, but the nautilus search allows a more
> detailed view of the results (multiple view types, previews, etc) and
> also allows more interesting operations on the results (file ops,
> nautilus extensions like sendto, etc). Maybe we could integrate these
> better, or at least make them more similar?

I have been thinking about this thread since it started. I often think
that I would like to see a separate overview just for file browsing. I
am pretty sure this goes against the design idea of shell, that seems to
to try to unite apps and files, but I think using the full screen to
find/manage files can be a good thing (although it makes the ability to
drag somewhat moot).

I think files and places are pretty much second class citizens in the
current overview, but that might change.

See you,

--
Gustavo Noronha Silva <gns@...>
GNOME Project

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Icon display issue

2009-12-14T13:04:55Z

Hi,

Am Montag, den 14.12.2009, 18:05 +0800 schrieb Mia zhao:
> Have you ever seen the issue before:
> Icon is displayed uncompletely in Gnome desktop and filemanager as if
> the right part was cut off.
>
> I think it's margin setting issue caused by nautilus.
> Could you give me some suggestion to solve it pls?
> Thanks.

Please provide a screenshot (of the icon only, not the complete
desktop).

Thanks,
andre
--
mailto:ak-47@... | failed
http://www.iomc.de/ | http://blogs.gnome.org/aklapper

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-14T12:48:11Z

This might be of interest to you, it's quite nifty: http://ubuntuforums.org/showthread.php?t=1065369

On Fri, Dec 4, 2009 at 14:30, Brent Foor <brentfoor@...> wrote:

As far as a messy desktop goes I'm in the same boat. In fact that is one of the reasons i love the stack idea. the papers on my desktop ain't evenly spaced out in a grid i pile related things together. basically I'm mentally tagging them. I love the idea of being able to lasso a group of files and have them stack on my desktop i could then tag making it basicly a sexy looking folder. If i want to see the files in the stack i click on them and the rest of the desktop darkens and my files explode out to a grid. i can also search for the tag in the overlay.

...at least thats how i imagine the stack idea.

Foor

On Fri, Dec 4, 2009 at 12:35 PM, Cosimo Cecchi <cosimoc@...> wrote:

On Fri, 2009-12-04 at 10:28 +0100, Alexander Larsson wrote:

> As a start, here is what the gnome-shell design docs say on the desktop:

[cut]

Right, I already read that paragraph, and I do not completely agree with
it. IRL, the top of my desk is as messy as my desktop, I'm fine with it,
and I know many people who have even more mess on it, and are fine with
it too ;)
I don't want to say that confusion should be a goal, but different
people develop different mental patterns when it comes to look for
things, and I think the desktop is a perfectly flexible space for this.

Removing the ease to save files on the desktop seems a bit to me like
forcing a pattern to people, and a waste of incredibly useful space
(unless we are going to reintroduce something like Piles, but I'll
comment on that later on).
Sure, we could do a lot better than we do now for people who want their
desktop to be tidy (ensure we never overlap icons would be a good
start :)), but these are just implementation bugs IMO.

> Yes, its quick to reach, but so is the activities overview (press the
> windows key or move the mouse to the top-left corner. It all depends on
> why you want to reach the desktop. If its for something like launching
> an app/location then doing that via the activities overview is as
> efficient as the desktop (and its an advantage imho to only have one
> consistent way to do this). So, this argument is only valid if you're
> doing something you can't do on the activities overview.

I agree with you for the application case (though I'd like even more a
gnome-do-like launcher). I'm not so sure about opening documents. Recent
files and files that are currently being saved on the desktop might
conceptually overlap, but they do not always do. So, unless we're going
to have a storage-like place in the overview (which IMO brings to a
problem, see some next paragraph), this is a big change in the
interaction model.

> It is very big, but its often covered and its limited in space (and thus
> doesn't scale). Its also problematic in that its fixed size changes when
> the resolution changes meaning you might "lose" files when that
> happens.
>
> The main advantage to the desktop is really that its a logical default
> storage location for starting something and for temporary things that is
> easy to reach. If we remove the desktop the likely place that things
> like this would be done is the home directory, but thats not as nice as
> its full of stuff thats always there, so you can't easily clean it up or
> get an overview of only the stuff you've temporarily created.

Yes, I agree.

> Ideally it should be as easy to reach these with gnome-shell as the
> desktop, and if its not we should instead fix it. Using the activities
> overview its pretty easy to reach a mounted volume as they are listed on
> the left.

I think this brings up another issue: considering that most of the space
in the activities overview is taken by the workspaces view, we have to
deal with a limited free room there. On my Thinkpad X60, which has a
1024x768 resolution, the activities view looks quite crowded, and we
have to carefully consider which things are worth to put in there.
Having recent documents + applications + search + volumes + a file
storage place seems too much to me. You could smartly hide/expand some
items, but this implies more clicks for the user to reach a target. The
desktop as it is now, instead, seems to nicely fit the purpose of
showing volumes and working files.

This could be an issue in netbooks as well, where a 1024x600 screen
resolution seems to be standard.

> However, for the case of a newly mounted volume we should probably
> integrate with the shell notification system so that plugging in a cd
> will show you some notification that this is now availible, letting you
> quickly click on it to open the mounted location.

Agreed. This is orthogonal to the desktop though IMHO.

> I'm always worried about adding non-file things to the nautilus views. A
> lot of people has historically used gnome-vfs modules + nautilus to
> create "lists" of things (fonts, themes and whatnot). This is almost
> always a bad idea. All of the nautilus UI is specialized at showing
> files and their properties. And the operations available on items expect
> them to generally act like normal files. Adding other types of objects
> always leads to strange behaviour due to this. (Not to mention that a
> custom list dialog could contain the special features needed to make
> listing the new type of object better.)
>
> Additionally I think its kinda unexpected to open the file management
> application and have its search return a preference dialog. Especially
> with the new focus on "file management" rather than being a shell.
>
> However, it would be cool for instance to have the search results in
> gnome-shell have a link in the "files" section of the results that
> opened up a nautilus search.
>
> It would also be nice if the search result picked up things like custom
> icons and emblems from nautilus. And if the files had context menus with
> things like "open with other...", and "show in file manager" operations.

I agree with you here.

> What do you think of my proposal about piles?

I'm not a big fan of auto-hiding/sliding interfaces, and there's already
a near hot corner :)
I'd rather either see them on the desktop itself, like a small file
view, or in another keystroke-triggered layer over the applications, so
you can easily DnD to/from them. Also, I have to think more about it,
but we could associate them with a name and make it real folders on the
filesystem (with symlinks?), under ~/Desktop, with a default one which
is ~/Desktop itself.

> > By the way, if we're going to stop drawing the desktop, what would be
> > drawn on it and who would be responsible for that?
>
> If nautilus just stops this then the default will be for
> gnome-settings-daemon to set the desktop background and for X to render
> it. However, if gnome-shell instead managed it we could do nice things
> like having different backgrounds for different workspaces.

I think I did not make myself understood with my last question: what
would be on the desktop after Nautilus stops drawing it? Would it just
be empty?
By the way, there's a patchset for libgnome/Nautilus to handle different
backgrounds right now :)

Cheers,

Cosimo

_______________________________________________
gnome-shell-list mailing list
gnome-shell-list@...
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

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

Re: Selection tracking

2009-12-14T05:11:38Z

----- "Alexander Larsson" <alexl@...> a écrit :
>
> Yes, that is planned and some initial work has been done on it, but
> its not yet finished.
>

Well, in the meanwhile, I've written a light C extension which does
the trick. Final use case was to be able to define keyboard shortcut
to an action (see [1])

Regards
Pierre

[1] https://bugzilla.gnome.org/show_bug.cgi?id=435820
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Icon display issue

2009-12-14T02:05:08Z

Hi there,

Have you ever seen the issue before:
Icon is displayed uncompletely in Gnome desktop and filemanager as if the right part was cut off.

I think it's margin setting issue caused by nautilus.
Could you give me some suggestion to solve it pls?
Thanks.

GNOME Nautilus version: 2.26.2
Kernel version: 2.6.31

BR,
Mia

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Custom Home Button

2009-12-14T01:09:28Z

On Fri, 2009-12-11 at 13:06 -0600, Eric Pruitt wrote:

> Hello,
>
> I modified Nautilus to make it so that the Home button will take the
> user to a custom directory if the environment variable "NAUTILUS_HOME"
> is set with the following code:
> File: nautilus-window-manage-views.c, Line 682
>
> if !(g_getenv ("NAUTILUS_HOME"))
> {
> home = g_file_new_for_path (g_get_home_dir ());
> } else {
> home = g_file_new_for_path (g_getenv ("NAUTILUS_HOME"));
> }
>
> How would I go about trying to get the feature implemented in Nautilus
> since I have already created a patch?

What exactly is your usecase here? You can already change the HOME env
var and nautilus should pick up that.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's a suicidal Amish boxer with a secret. She's a plucky Buddhist pearl diver
looking for love in all the wrong places. They fight crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Selection tracking

2009-12-14T01:07:33Z

On Tue, 2009-12-08 at 23:52 +0100, Pierre Wieser wrote:

> Hi,
>
> I have some requests from Nautilus-Actions users to have a
> command-line
> tool to run actions from outside of Nautilus. Obviously the main issue
> would be to get the current selection.
>
> I note that, as a side effect of the implementation, a menu provider
> is
> able to track the selection. Starting from this, I may imagine an
> extension which provides the current selection list in response to a
> DBus request.
>
> I know that some guys already work on Nautilus DBus interfaces. Is
> such
> an interface, which would give the current selection, already planned
> ?

Yes, that is planned and some initial work has been done on it, but its
not yet finished.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's a world-famous devious gangster searching for his wife's true killer.
She's a cold-hearted bisexual journalist who can talk to animals. They fight
crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Custom Home Button

2009-12-11T11:06:34Z

Hello,

I modified Nautilus to make it so that the Home button will take the user to a custom directory if the environment variable "NAUTILUS_HOME" is set with the following code:
File: nautilus-window-manage-views.c, Line 682

if !(g_getenv ("NAUTILUS_HOME"))
{
home = g_file_new_for_path (g_get_home_dir ());
} else {
home = g_file_new_for_path (g_getenv ("NAUTILUS_HOME"));
}

How would I go about trying to get the feature implemented in Nautilus since I have already created a patch?

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

split-view landed in master

2009-12-10T09:19:13Z

I just landed the split-view branch from Holger Berndt with some rework
from me on git master.

It also includes some restructuring of the navigation window UI. To make
split views work we put the location bar on itself and moved the other
toolbar items to the standard toolbar. Then i landed the border addition
patches and moved the tabs to the bottom (to avoid visual clutter at
top).

I'm sure there will be issues, and we may want to discuss the exact UI
details more, but I wanted to get something out there for testing, as
this is a rather large code change.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's a fast talking moralistic boxer on the edge. She's an orphaned psychic
magician's assistant with a song in her heart and a spring in her step. They
fight crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Selection tracking

2009-12-09T03:14:49Z

----- "Bruce van der Kooij" <brucevdkooij@...> a écrit :
>
> In response to a similar request a few months ago[1] I wrote an
> extension that does this. See:
>
> http://rabbitvcs.googlecode.com/svn/other/NautilusDBus.py

Hi Bruce,
Yes, this is what I was searching for :)
Do you have some sort of release/package of it, so I could define
a Nautilus-Actions dependancy on this ?

> Best regards,
> Bruce

Regards
Pierre

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Selection tracking

2009-12-09T01:46:55Z

Pierre Wieser wrote:
> I note that, as a side effect of the implementation, a menu provider is
> able to track the selection. Starting from this, I may imagine an
> extension which provides the current selection list in response to a
> DBus request.
>
> I know that some guys already work on Nautilus DBus interfaces. Is such
> an interface, which would give the current selection, already planned ?

In response to a similar request a few months ago[1] I wrote an
extension that does this. See:

http://rabbitvcs.googlecode.com/svn/other/NautilusDBus.py

Of course, in the end this kind of functionality should be exposed by
Nautilus itself, but while progress is being made there you could still
work out your ideas in the meantime.

References:

[1] http://mail.gnome.org/archives/nautilus-list/2009-March/msg00132.html

Best regards,

Bruce

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

signature.asc (269 bytes) Download Attachment

Selection tracking

2009-12-08T14:52:03Z

Hi,

I have some requests from Nautilus-Actions users to have a command-line
tool to run actions from outside of Nautilus. Obviously the main issue
would be to get the current selection.

I note that, as a side effect of the implementation, a menu provider is
able to track the selection. Starting from this, I may imagine an
extension which provides the current selection list in response to a
DBus request.

I know that some guys already work on Nautilus DBus interfaces. Is such
an interface, which would give the current selection, already planned ?

Thanks in advance for your opinions.

Regards
Pierre
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-07T07:27:17Z

Le 03/12/2009 17:04, Cosimo Cecchi a écrit :

> Hi Alex,
>
> On Wed, 2009-12-02 at 16:08 +0100, Alexander Larsson wrote:
>
>> This leads to two initial conclusions from my side. First of all we
>> should disable the drawing of the desktop by default. Second we should
>> default to browser mode. This might seem a bit suprising since I've
>> generally been on the spatial side. But, this has mainly been because
>> I've seen nautilus as much more used as a kind of file activation
>> shell rather than a hardcore file manager, and when that changes the
>> rationale for spatial mode change too.
>
> While I completely agree about enabling browser mode by default, I'm
> not completely sold on Nautilus not drawing the desktop by default:
> * even with many applications opened, the desktop is just one
> click (or one keystroke) away from you (Ctrl+Alt+D or the "Show
> Desktop" applet).
> * it's a very big space to save things. If we're going to have
> something like a file stack in gnome-shell, we should make it
> sure it has the right amount of space. For instance, I find it
> confusing to use the stacked "Downloads" icon on the OSX dock,
> as it becomes just too messy and out-of-control when the number
> of files is high. You can always clean up your desktop instead
> when there are too many things on it, just like you'd do with a
> real one :)
> * orthogonal to the previous one, there are some items which are
> very handy to have on the desktop anyway, for instance, newly
> mounted volume icons.

<Putting my distro hat>
I have to concur with you.

When we first shipped KDE 4.1 with Mandriva release, a lot of people (I
think I can say a majority) used to "desktop" metaphor were completely
lost when the Plasmoid metaphor where there was no longer a "Desktop"
visible for their files stored there (and I'm not even talking about
migration issues).

We had to put a small "desktop" view on KDE default desktop and with
last Mandriva release, we changed KDE default configuration to use a
"full desktop directory" view, just like the old time. And users aren't
confused anymore.

I know GNOME isn't KDE but we have to be careful to not duplicate
mistakes from our fellow Qt desktop hackers ;)
</distro hat>

--
Frederic Crozat
Mandriva
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Saving search

2009-12-07T03:23:13Z

On Mon, Dec 7, 2009 at 12:16 PM, Alexander Larsson <alexl@...> wrote:

> Those two bugs seems to be about different things. One is that the
> feature of saved searches (or search folders or what you want to call
> it) is hard to find, the other thing seems to be about saving the result
> of a particular search operation.

True.. sorry.

> Are search folders really created so often that having a button in the
> UI (taking up space) is really a good idea? It means less space for
> other things and more visual clutter/complexity.
>
> I agree that saved searches are kinda hard to find, but i think
> improving the docs and maybe pimping the feature in other ways is a
> better solution than making it an always visible icon in everyones file
> manager all the time.
>

I'm not thinking on something present all the time in the ui, but a small button
present near the search bar (or near the search options) when a search
are in place
don't seem (at least to me) a bad idea.

--
michele tameni
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Saving search

2009-12-07T03:16:30Z

On Sat, 2009-12-05 at 13:53 +0000, Michele Tameni wrote:
> Hi guys,
> I've found two bug, G#332299 [1] and G#325146 [2], on GNOME Bugzilla.
> I think that save search could be very useful for many user,
> especially with the ongoing tracker 0.7 integration.
> Atm save the search are very difficult [i don't know that i can
> already do it before reading the two bugs above], so i've looked a bit
> into the code for understand what i can do.

Those two bugs seems to be about different things. One is that the
feature of saved searches (or search folders or what you want to call
it) is hard to find, the other thing seems to be about saving the result
of a particular search operation.

> Possible places where a "Save search" are search bar (next to the text
> entry), or in the query builder.
> Add the button is not so difficult, but i see that the relevant code
> that do the save are located in file-manager/fm-directory-view.c .
> I really don't know anything about how-to-do-thing in nautilus and how
> things are organized, and i haven't so much time in this period for
> looking deep into the code, so someone point me in the right direction
> for obtain the wanted result?

Are search folders really created so often that having a button in the
UI (taking up space) is really a good idea? It means less space for
other things and more visual clutter/complexity.

I agree that saved searches are kinda hard to find, but i think
improving the docs and maybe pimping the feature in other ways is a
better solution than making it an always visible icon in everyones file
manager all the time.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's a lonely pirate ex-con gone bad. She's a man-hating impetuous bounty
hunter with a birthmark shaped like Liberty's torch. They fight crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-07T03:09:23Z

On Fri, 2009-12-04 at 18:35 +0100, Cosimo Cecchi wrote:
> On Fri, 2009-12-04 at 10:28 +0100, Alexander Larsson wrote:
> Removing the ease to save files on the desktop seems a bit to me like
> forcing a pattern to people, and a waste of incredibly useful space
> (unless we are going to reintroduce something like Piles, but I'll
> comment on that later on).
> Sure, we could do a lot better than we do now for people who want
> their
> desktop to be tidy (ensure we never overlap icons would be a good
> start :)), but these are just implementation bugs IMO.

Yeah, trying to figure out ways to replace the features of the desktop
is hard. The piles feature while cool doesn't solve the imho most
important aspect of being a default storage locations for new/active
files. So, I'm more and more disagreeing with removing the desktop from
being handled by the file manager.

Of course, we should probably still think of ways we can change it to
work better in the gnome-shell world. For instance, maybe it would be
nice to be able to show different desktop contents on different
workspaces? This would match with using workspaces as a way to manage
separate "activities". Of course, that would be sort of problematic when
you're accessing the desktop directory from e.g. the file selector.

> > Ideally it should be as easy to reach these with gnome-shell as the
> > desktop, and if its not we should instead fix it. Using the
> activities
> > overview its pretty easy to reach a mounted volume as they are
> listed on
> > the left.
>
> I think this brings up another issue: considering that most of the
> space
> in the activities overview is taken by the workspaces view, we have to
> deal with a limited free room there. On my Thinkpad X60, which has a
> 1024x768 resolution, the activities view looks quite crowded, and we
> have to carefully consider which things are worth to put in there.
> Having recent documents + applications + search + volumes + a file
> storage place seems too much to me. You could smartly hide/expand some
> items, but this implies more clicks for the user to reach a target.
> The
> desktop as it is now, instead, seems to nicely fit the purpose of
> showing volumes and working files.

Yeah, the activities overview as it stands right now obviously focuses
on managing running applications. File handling is sort of included but
clearly a secondary feature.

> > What do you think of my proposal about piles?
>
> I'm not a big fan of auto-hiding/sliding interfaces, and there's
> already a near hot corner :)

Yeah, but always-visible screen space is very valuable, and shouldn't be
wasted on thing you're not using that often. auto-hiding is the obvious
way around this, but as you say its already used for somethings and its
getting crowded. Its interesting to think of what other possible
solutions there are to the desktop features though.

> I'd rather either see them on the desktop itself, like a small file
> view, or in another keystroke-triggered layer over the applications,
> so you can easily DnD to/from them. Also, I have to think more about it,
> but we could associate them with a name and make it real folders on
> the filesystem (with symlinks?), under ~/Desktop, with a default one which
> is ~/Desktop itself.

Real folders is how OSX implement the stacks in the dock. Its possible
but limits it to files and the other disadvantages i listed in my other
mail.

> > If nautilus just stops this then the default will be for
> > gnome-settings-daemon to set the desktop background and for X to
> render
> > it. However, if gnome-shell instead managed it we could do nice
> things
> > like having different backgrounds for different workspaces.
>
> I think I did not make myself understood with my last question: what
> would be on the desktop after Nautilus stops drawing it? Would it just
> be empty?

I don't think there are any proposals for this atm, so my guess is
empty. Another possibility would be "gadgets" but it seems gnome-shell
has decided to put these in a sidebar, so that seems unlikely.

> By the way, there's a patchset for libgnome/Nautilus to handle
> different backgrounds right now :)

Its kinda hard to solve this in a correct fashion though. What you can
do is monitor the current active workspace and change the background
when it changes. However, that doesn't really work well in e.g. the
gnome-shell activities overview because you'll get N_WORKSPACES x the
currrent background.

A more correct solution would be to integrate tighter with the window
manager and have one desktop window per workspace.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's an unconventional shark-wrestling firefighter on his last day in the job.
She's a cynical winged single mother with an MBA from Harvard. They fight
crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-07T02:51:57Z

On Fri, 2009-12-04 at 00:58 +0100, Giacomo Bordiga wrote:

> 2009/12/4 Зоран Рилак <zoran.rilak@...>
> For what it's worth, I need to interject here. I know many
> people
> (myself included) who turn desktop icons off, not because I
> keep many
> windows open all the time (it's easy to access desktop as
> Cosimo wrote),
> but because I hate to look at the messy, unevenly shaped,
> partially
> overlapping icons, sometimes with large gaps between them.
> More than,
> say, 5 or 6 icons on the desktop simply demand my attention;
> they
> scream: "Drag us around! Make us look neat!" Then I have to
> keep doing
> that for every new couple of icons that land on the desktop.
>
> This [1] is a mockup I made 1 year and half ago. I'm not sure if it
> can still be interesting/useful in the next gnome evolution. Still to
> me is a step forward to the current desktop icon management.
>
> In addition to Cosimo's points i think the desktop is also often used
> as a "buffer" for temporary file operation, works in progress or not
> yet categorized files.
>
> [1] http://www.flickr.com/photos/7449355@N06/2329133852/

I don't think enforcing a layout like this on the desktop is a good
idea. I guess it might be nice to have some form of better arrangement
when you "Clean up by name", but having a fixed layout like that gives
you less space for your own files and forces the use of the desktop as
more of a place to launch other locations. The current main usecase for
the desktop is being a location where the user works on his current set
of active files, although that may change with gnome-shell as per this
discussion.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's a lonely misogynist barbarian trapped in a world he never made. She's a
virginal hypochondriac snake charmer who can talk to animals. They fight
crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-07T02:44:41Z

On Sun, 2009-12-06 at 01:45 +0100, Mark wrote:

> > I've seen nautilus as much more used as a kind of file activation
> > shell rather than a hardcore file manager, and when that changes the
> > rationale for spatial mode change too.
>
> Now this is interesting. I guess it was roughly 2 years ago that i
> proposed the exact same thing about browser mode. Back then it ended
> up in a huge flame war. Now you out of all people are proposing the
> same thing and suddenly you get positive responses and even gnome
> people that agree with it. Even a gnome person that proposes it! i
> must have been ahead of my time when i proposed it. More on this some
> lines down.

Interesting. You proposed gnome-shell as the replacement for nautilus as
the desktop shell two years ago? Got any links to that proposal?

> Now i didn't read every reply in this thread but i did saw the part to
> split nautilus from the file management part and the mount part. Also
> something i proposed a few years ago which was smashed down hard by a
> lot of people, you included, so i hope the following proposal isn't
> going to be smashed down since it's along the same lines just..
> different.

I don't think splitting out the automounting stuff has ever been
controversial. We're talking about a few hundred lines of code here. In
fact, its only recently that nautilus has started doing this, it was
done by gnome-volume-manager before.

> KDE did a smart thing with KDE 4. They had konqueror as there file
> management program but simply left it the way it was and made up
> Dolphin just to restart the file management from scratch and be clean
> again.
>
> I would propose to not touch nautilus! Make a new file manager just
> like KDE did for KDE 4. Make that file manager to __only__ manage the
> files! So you basically get a Dolphin only for Gnome. That way you can
> leave the people that want to use nautilus happy and people that want
> to use gnome-shall can use the new file manager (lets say: Sulituan
> which is nautilus in reverse).

KDE did this because konqueror was mainly a web browser. Nautilus is
already only for managing files basically. I don't understand which part
of nautilus you think are not for managing files.

> If you don't like this idea then at the very least make nautilus less
> tied with gnome. Split the desktop part, the mount part and probably
> some other part that i don't even know right now off of nautilus. Let
> nautilus do one thing: manage files. Not the desktop, not the mounts;
> only files!

What exactly do you mean by "mount part"?

Its not really possible to split the "desktop part", its just a nautilus
window without menus or toolbar. It requires as much of the nautilus
codebase as any other nautilus window.

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl@... alexander.larsson@...
He's a jaded guitar-strumming werewolf with a robot buddy named Sparky. She's
a high-kicking kleptomaniac angel with her own daytime radio talk show. They
fight crime!

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-05T22:50:02Z

Am Sonntag, den 06.12.2009, 01:45 +0100 schrieb Mark:
> Now this is interesting. I guess it was roughly 2 years ago that i
> proposed the exact same thing about browser mode. Back then it ended
> up in a huge flame war. Now you out of all people are proposing the
> same thing and suddenly you get positive responses

Might have to do with the fact that Alex provided a good argumentation
for it.

andre

--
mailto:ak-47@... | failed
http://www.iomc.de/ | http://blogs.gnome.org/aklapper

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-05T16:45:18Z

Hi
On Wed, Dec 2, 2009 at 4:08 PM, Alexander Larsson <alexl@...> wrote:

> With gnome-shell being the direction that Gnome is going with for 3.0
> I've been thinking some about how this affects nautilus, and how file
> management should work with gnome-shell.
>
> The current ideas behind the design of nautilus is that its the main
> way to access files. By this I mean everyday stuff like finding and
> opening your files, rather than "file management" (reorganizing files,
> copying files, etc). This together with the desktop having links to
> important places (as well as being a repository for currently worked
> on files) makes this a sort of "desktop shell" in the sense that its
> how apps are launched to a large degree. This is also why spatial mode
> is the default for the desktop icons (and why browser mode is
> availibile in the menus as "File Browser" for those times you want to
> do intense file management).
>
> However, in the gnome-shell design a lot of the things nautilus is
> currently used for (locating and opening files) is integrated into the
> shell and mixed together with the ui for locating and starting
> applications. This makes a lot of sense to me as launching
> applications and opening files with an application are closely related
> actions, and a merged UI could do a lot better than the current sort
> of double UI with the panel launching apps and the desktop launching
> files. The shell also wants to de-emphatize the desktop as a place for
> storing files in use and launching links, for good reasons (read the
> design paper[1] for details).
>
> This leads to two initial conclusions from my side. First of all we
> should disable the drawing of the desktop by default. Second we should
> default to browser mode. This might seem a bit suprising since I've
> generally been on the spatial side. But, this has mainly been because
> I've seen nautilus as much more used as a kind of file activation
> shell rather than a hardcore file manager, and when that changes the
> rationale for spatial mode change too.

Now this is interesting. I guess it was roughly 2 years ago that i
proposed the exact same thing about browser mode. Back then it ended
up in a huge flame war. Now you out of all people are proposing the
same thing and suddenly you get positive responses and even gnome
people that agree with it. Even a gnome person that proposes it! i
must have been ahead of my time when i proposed it. More on this some
lines down.

>
> This is a slight change in focus for nautilus, as its now to a larger
> degree used when the user wants to do more complex file
> operations. I think with this we can feel more confident that
> for instance the split-view branch would fit better into
> nautilus. Another thing is that we have more screen space now by
> default, which I'd like to use to do a more expressive UI. For
> instance, I've long wanted to do a metadata/tags/live-preview pane
> somewhat like:
>
> http://2.bp.blogspot.com/_Xie1ydrCav4/RdH5i6KvUOI/AAAAAAAAACk/NMXxtde1198/s1600-h/nautilus-metadata-tile-5.png
>
> There are still a bunch of questions as to how nautilus and
> gnome-shell should work together:
>
> For instance, gnome-shell focuses a lot on using search to find files
> and other things of interest. Nautilus also does search, but only
> for files. The g-s search is more integrated in the desktop and gives
> multiple types of results, but the nautilus search allows a more
> detailed view of the results (multiple view types, previews, etc) and
> also allows more interesting operations on the results (file ops,
> nautilus extensions like sendto, etc). Maybe we could integrate these
> better, or at least make them more similar?
>
> With the desktop gone we don't have a place for shorttime "storage" of
> actively used files. There is "recent files" which is accessible from
> the activities overview, but the activities view is very much a
> "launch some new activity" thing rather than something you actively
> work with during an activity. For instance, your current app is zoomed
> out and you lose all possibility to interact with it and the recent
> files with e.g. drag and drop.
>
> I'd like to add some way to put files (file references really)
> somewhere in the shell UI. Maybe just drag them to the side to make a
> pile or a drawer. That way you could temporary put the files you're
> working there and work on them easily from multiple apps. This does
> require quite a bit of cooperation between the shell and nautilus
> though in order for the files in the shell to have a look and
> behaviour like that of nautilus (same icons, same operations, etc).
>
> In fact, this is a general problem for the shell. The files as
> represented in the shell UI just isn't as expressive as they are in
> nautilus. You can't get their sizes, emblems, there is no open with
> menus, extensions, scripts, property dialogs, etc. I'm not saying we
> want all this in the shell, just that what the shell does for files is
> not always enough, sometimes you want more, and we need to make sure
> nautilus can take over in a nice fashion when you need it.
>
> Another question is how we reformulate the UI for selecting spatial
> mode. Right now its a checkbox for enabling "Always open in browser
> windows", and rather than just having this True by default i'd like to
> somehow have a checkbox to enable spatial mode. I just can't think of
> a good way to describe spatial mode in the UI. Does anyone have an idea?
>
> With nautilus not handling the desktop there really is no reason to
> run all of nautilus all the time. Its currently needed for the
> automount handling, and its possible to turn on daemon mode so it can
> do this even if the desktop is not visible. However, this seems a bit
> unnecessary, so we should try to factor out the automount stuff to a
> separate binary.
>
> Gnome-shell will not be the default in the next gnome release (2.30),
> but since this kind of large changes take a long time to design and
> stabilize I'm thinking we should probably start to work towards this
> already in this release.
>

Now i didn't read every reply in this thread but i did saw the part to
split nautilus from the file management part and the mount part. Also
something i proposed a few years ago which was smashed down hard by a
lot of people, you included, so i hope the following proposal isn't
going to be smashed down since it's along the same lines just..
different.

KDE did a smart thing with KDE 4. They had konqueror as there file
management program but simply left it the way it was and made up
Dolphin just to restart the file management from scratch and be clean
again.

I would propose to not touch nautilus! Make a new file manager just
like KDE did for KDE 4. Make that file manager to __only__ manage the
files! So you basically get a Dolphin only for Gnome. That way you can
leave the people that want to use nautilus happy and people that want
to use gnome-shall can use the new file manager (lets say: Sulituan
which is nautilus in reverse).

If you don't like this idea then at the very least make nautilus less
tied with gnome. Split the desktop part, the mount part and probably
some other part that i don't even know right now off of nautilus. Let
nautilus do one thing: manage files. Not the desktop, not the mounts;
only files!

I hope this was some useful feedback.

Good luck,
Mark
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Saving search

2009-12-05T05:53:59Z

Hi guys,
I've found two bug, G#332299 [1] and G#325146 [2], on GNOME Bugzilla.
I think that save search could be very useful for many user,
especially with the ongoing tracker 0.7 integration.
Atm save the search are very difficult [i don't know that i can
already do it before reading the two bugs above], so i've looked a bit
into the code for understand what i can do.

Possible places where a "Save search" are search bar (next to the text
entry), or in the query builder.
Add the button is not so difficult, but i see that the relevant code
that do the save are located in file-manager/fm-directory-view.c .
I really don't know anything about how-to-do-thing in nautilus and how
things are organized, and i haven't so much time in this period for
looking deep into the code, so someone point me in the right direction
for obtain the wanted result?
Also a patch like this are welcome?

Thanks a lot, hope that can i help a bit. :)
Michele
[1] https://bugzilla.gnome.org/show_bug.cgi?id=332299
[2] https://bugzilla.gnome.org/show_bug.cgi?id=325146

--
michele tameni
--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-04T12:30:53Z

As far as a messy desktop goes I'm in the same boat. In fact that is one of the reasons i love the stack idea. the papers on my desktop ain't evenly spaced out in a grid i pile related things together. basically I'm mentally tagging them. I love the idea of being able to lasso a group of files and have them stack on my desktop i could then tag making it basicly a sexy looking folder. If i want to see the files in the stack i click on them and the rest of the desktop darkens and my files explode out to a grid. i can also search for the tag in the overlay.

...at least thats how i imagine the stack idea.

Foor

On Fri, Dec 4, 2009 at 12:35 PM, Cosimo Cecchi <cosimoc@...> wrote:

On Fri, 2009-12-04 at 10:28 +0100, Alexander Larsson wrote:

> As a start, here is what the gnome-shell design docs say on the desktop:

[cut]

Right, I already read that paragraph, and I do not completely agree with
it. IRL, the top of my desk is as messy as my desktop, I'm fine with it,
and I know many people who have even more mess on it, and are fine with
it too ;)
I don't want to say that confusion should be a goal, but different
people develop different mental patterns when it comes to look for
things, and I think the desktop is a perfectly flexible space for this.

Removing the ease to save files on the desktop seems a bit to me like
forcing a pattern to people, and a waste of incredibly useful space
(unless we are going to reintroduce something like Piles, but I'll
comment on that later on).
Sure, we could do a lot better than we do now for people who want their
desktop to be tidy (ensure we never overlap icons would be a good
start :)), but these are just implementation bugs IMO.

> Yes, its quick to reach, but so is the activities overview (press the
> windows key or move the mouse to the top-left corner. It all depends on
> why you want to reach the desktop. If its for something like launching
> an app/location then doing that via the activities overview is as
> efficient as the desktop (and its an advantage imho to only have one
> consistent way to do this). So, this argument is only valid if you're
> doing something you can't do on the activities overview.

I agree with you for the application case (though I'd like even more a
gnome-do-like launcher). I'm not so sure about opening documents. Recent
files and files that are currently being saved on the desktop might
conceptually overlap, but they do not always do. So, unless we're going
to have a storage-like place in the overview (which IMO brings to a
problem, see some next paragraph), this is a big change in the
interaction model.

> It is very big, but its often covered and its limited in space (and thus
> doesn't scale). Its also problematic in that its fixed size changes when
> the resolution changes meaning you might "lose" files when that
> happens.
>
> The main advantage to the desktop is really that its a logical default
> storage location for starting something and for temporary things that is
> easy to reach. If we remove the desktop the likely place that things
> like this would be done is the home directory, but thats not as nice as
> its full of stuff thats always there, so you can't easily clean it up or
> get an overview of only the stuff you've temporarily created.

Yes, I agree.

> Ideally it should be as easy to reach these with gnome-shell as the
> desktop, and if its not we should instead fix it. Using the activities
> overview its pretty easy to reach a mounted volume as they are listed on
> the left.

I think this brings up another issue: considering that most of the space
in the activities overview is taken by the workspaces view, we have to
deal with a limited free room there. On my Thinkpad X60, which has a
1024x768 resolution, the activities view looks quite crowded, and we
have to carefully consider which things are worth to put in there.
Having recent documents + applications + search + volumes + a file
storage place seems too much to me. You could smartly hide/expand some
items, but this implies more clicks for the user to reach a target. The
desktop as it is now, instead, seems to nicely fit the purpose of
showing volumes and working files.

This could be an issue in netbooks as well, where a 1024x600 screen
resolution seems to be standard.

> However, for the case of a newly mounted volume we should probably
> integrate with the shell notification system so that plugging in a cd
> will show you some notification that this is now availible, letting you
> quickly click on it to open the mounted location.

Agreed. This is orthogonal to the desktop though IMHO.

> I'm always worried about adding non-file things to the nautilus views. A
> lot of people has historically used gnome-vfs modules + nautilus to
> create "lists" of things (fonts, themes and whatnot). This is almost
> always a bad idea. All of the nautilus UI is specialized at showing
> files and their properties. And the operations available on items expect
> them to generally act like normal files. Adding other types of objects
> always leads to strange behaviour due to this. (Not to mention that a
> custom list dialog could contain the special features needed to make
> listing the new type of object better.)
>
> Additionally I think its kinda unexpected to open the file management
> application and have its search return a preference dialog. Especially
> with the new focus on "file management" rather than being a shell.
>
> However, it would be cool for instance to have the search results in
> gnome-shell have a link in the "files" section of the results that
> opened up a nautilus search.
>
> It would also be nice if the search result picked up things like custom
> icons and emblems from nautilus. And if the files had context menus with
> things like "open with other...", and "show in file manager" operations.

I agree with you here.

> What do you think of my proposal about piles?

I'm not a big fan of auto-hiding/sliding interfaces, and there's already
a near hot corner :)
I'd rather either see them on the desktop itself, like a small file
view, or in another keystroke-triggered layer over the applications, so
you can easily DnD to/from them. Also, I have to think more about it,
but we could associate them with a name and make it real folders on the
filesystem (with symlinks?), under ~/Desktop, with a default one which
is ~/Desktop itself.

> > By the way, if we're going to stop drawing the desktop, what would be
> > drawn on it and who would be responsible for that?
>
> If nautilus just stops this then the default will be for
> gnome-settings-daemon to set the desktop background and for X to render
> it. However, if gnome-shell instead managed it we could do nice things
> like having different backgrounds for different workspaces.

I think I did not make myself understood with my last question: what
would be on the desktop after Nautilus stops drawing it? Would it just
be empty?
By the way, there's a patchset for libgnome/Nautilus to handle different
backgrounds right now :)

Cheers,

Cosimo

_______________________________________________
gnome-shell-list mailing list
gnome-shell-list@...
http://mail.gnome.org/mailman/listinfo/gnome-shell-list

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: User home and Desktop folder; position in Places sidebar

2009-12-04T12:04:23Z

On Fri, 2009-12-04 at 11:50 +1100, Paul Trevethan wrote:

> On Thu, 03 Dec 2009 17:37:22 -0600
> David Siegel <djsiegel@...> wrote:
>
> > In the Nautilus Places sidebar, why are my Home folder and Desktop
> > folder with the disks, and not with my other bookmarked folders, as they
> > are in the Places menu? From a user's perspective, these are just
> > folders containing their stuff. How do we justify this placement to
> > users?
> >
> > http://img171.imageshack.us/img171/5161/screenshotli.png
> >
> >
> > (Left screen shot depicts current state of affairs; right mockup depicts
> > the change I'd like to discuss.)
> >
> > David
> >
> >
>
> I would think it has something to do with the fact that the existence of these
> two folders is 'system' generated & controlled, whereas the others are purely
> 'user' options.
>
> Just a thought.
> Paul.

I am mostly concerned about what the user thinks of the positioning, and
not why HOME or Desktop are special cases in terms of not being
removable, or being placed there by the system.

My intuition is that users view the items above the separator as "disks and
system stuff" and the items below the separator as "my stuff". I
think it's not controversial that most users consider Home and Desktop as "my stuff",
so placing them in the top section, instead of near Documents, for example, is confusing.
To test, ask a lay user "do your home folder and desktop folder belong with your documents
and photos folders, or with your disks and trash; keep in mind that you cannot delete your
home folder." I'm willing to bet that users will choose the former.

Of course, Hilke's solution is great (http://www.bomahy.nl/hylke/blog/clutter-in-nautilus-sidebar/)
because it makes the groups explicit by labeling them, but this looks like more work than
simply moving Home and Desktop to the bookmarks section.

David

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-04T09:41:00Z

Cosimo Cecchi skrev:

> On Fri, 2009-12-04 at 12:09 +0100, Alexander Larsson wrote:
>
>> On Fri, 2009-12-04 at 10:37 +0100, John Stowers wrote:
>>
>>>> This is a slight change in focus for nautilus, as its now to a
>>>>
>>> larger
>>>
>>>> degree used when the user wants to do more complex file
>>>> operations. I think with this we can feel more confident that
>>>> for instance the split-view branch would fit better into
>>>> nautilus. Another thing is that we have more screen space now by
>>>> default, which I'd like to use to do a more expressive UI.
>>>>
>>> Speaking of UI changes, it would be great to see Cosimo's toolbar
>>> editor
>>> branch [1], or something similar, make it into the default install.
>>> This
>>> would hopefully allow uses of nautilus like [2].
>>>
>>> John
>>>
>>> [1] http://github.com/cosimoc/nautilus/tree/toolbareditor
>>> [2] http://davidsiegel.org/nautilus-simplified/
>>>
>> Yes, i'm interested in getting this in and looking at simplify the
>> default toolbars. However, i have not gotten a ping from cosimoc that
>> the changes are ready for review yet, so i haven't looked at it. (In
>> fact, last i asked it was not ready.)
>>
>
> (Note that most of the initial code for this has been written by Marcus
> Carlson, so credits go to him first :))
>
>

Actually the credit should go to Christian Neumair who did the really
initial code - I just brought it up to date :)

> It's still not ready for review, and honestly I don't think I will have
> time to work on it during this cycle, as I'm deep into my university
> thesis.
> John, if you or anyone else want to jump in and help with the code,
> that's obviously appreciated and warmly welcomed!
> So, if any of you is interested in working on this, feel free to ping me
> on IRC or by mail for an overview of the changes that still needs to be
> done.
>
>

I'd like to help out, but I didn't have enough skills last time to pull
i through - but maybe with some help...?

M
> Cheers,
>
> Cosimo
>
>

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-04T09:35:48Z

On Fri, 2009-12-04 at 10:28 +0100, Alexander Larsson wrote:

> As a start, here is what the gnome-shell design docs say on the desktop:

[cut]

Right, I already read that paragraph, and I do not completely agree with
it. IRL, the top of my desk is as messy as my desktop, I'm fine with it,
and I know many people who have even more mess on it, and are fine with
it too ;)
I don't want to say that confusion should be a goal, but different
people develop different mental patterns when it comes to look for
things, and I think the desktop is a perfectly flexible space for this.

Removing the ease to save files on the desktop seems a bit to me like
forcing a pattern to people, and a waste of incredibly useful space
(unless we are going to reintroduce something like Piles, but I'll
comment on that later on).
Sure, we could do a lot better than we do now for people who want their
desktop to be tidy (ensure we never overlap icons would be a good
start :)), but these are just implementation bugs IMO.

> Yes, its quick to reach, but so is the activities overview (press the
> windows key or move the mouse to the top-left corner. It all depends on
> why you want to reach the desktop. If its for something like launching
> an app/location then doing that via the activities overview is as
> efficient as the desktop (and its an advantage imho to only have one
> consistent way to do this). So, this argument is only valid if you're
> doing something you can't do on the activities overview.

I agree with you for the application case (though I'd like even more a
gnome-do-like launcher). I'm not so sure about opening documents. Recent
files and files that are currently being saved on the desktop might
conceptually overlap, but they do not always do. So, unless we're going
to have a storage-like place in the overview (which IMO brings to a
problem, see some next paragraph), this is a big change in the
interaction model.

> It is very big, but its often covered and its limited in space (and thus
> doesn't scale). Its also problematic in that its fixed size changes when
> the resolution changes meaning you might "lose" files when that
> happens.
>
> The main advantage to the desktop is really that its a logical default
> storage location for starting something and for temporary things that is
> easy to reach. If we remove the desktop the likely place that things
> like this would be done is the home directory, but thats not as nice as
> its full of stuff thats always there, so you can't easily clean it up or
> get an overview of only the stuff you've temporarily created.

Yes, I agree.

> Ideally it should be as easy to reach these with gnome-shell as the
> desktop, and if its not we should instead fix it. Using the activities
> overview its pretty easy to reach a mounted volume as they are listed on
> the left.

I think this brings up another issue: considering that most of the space
in the activities overview is taken by the workspaces view, we have to
deal with a limited free room there. On my Thinkpad X60, which has a
1024x768 resolution, the activities view looks quite crowded, and we
have to carefully consider which things are worth to put in there.
Having recent documents + applications + search + volumes + a file
storage place seems too much to me. You could smartly hide/expand some
items, but this implies more clicks for the user to reach a target. The
desktop as it is now, instead, seems to nicely fit the purpose of
showing volumes and working files.

This could be an issue in netbooks as well, where a 1024x600 screen
resolution seems to be standard.

> However, for the case of a newly mounted volume we should probably
> integrate with the shell notification system so that plugging in a cd
> will show you some notification that this is now availible, letting you
> quickly click on it to open the mounted location.

Agreed. This is orthogonal to the desktop though IMHO.

> I'm always worried about adding non-file things to the nautilus views. A
> lot of people has historically used gnome-vfs modules + nautilus to
> create "lists" of things (fonts, themes and whatnot). This is almost
> always a bad idea. All of the nautilus UI is specialized at showing
> files and their properties. And the operations available on items expect
> them to generally act like normal files. Adding other types of objects
> always leads to strange behaviour due to this. (Not to mention that a
> custom list dialog could contain the special features needed to make
> listing the new type of object better.)
>
> Additionally I think its kinda unexpected to open the file management
> application and have its search return a preference dialog. Especially
> with the new focus on "file management" rather than being a shell.
>
> However, it would be cool for instance to have the search results in
> gnome-shell have a link in the "files" section of the results that
> opened up a nautilus search.
>
> It would also be nice if the search result picked up things like custom
> icons and emblems from nautilus. And if the files had context menus with
> things like "open with other...", and "show in file manager" operations.

I agree with you here.

> What do you think of my proposal about piles?

I'm not a big fan of auto-hiding/sliding interfaces, and there's already
a near hot corner :)
I'd rather either see them on the desktop itself, like a small file
view, or in another keystroke-triggered layer over the applications, so
you can easily DnD to/from them. Also, I have to think more about it,
but we could associate them with a name and make it real folders on the
filesystem (with symlinks?), under ~/Desktop, with a default one which
is ~/Desktop itself.

> > By the way, if we're going to stop drawing the desktop, what would be
> > drawn on it and who would be responsible for that?
>
> If nautilus just stops this then the default will be for
> gnome-settings-daemon to set the desktop background and for X to render
> it. However, if gnome-shell instead managed it we could do nice things
> like having different backgrounds for different workspaces.

I think I did not make myself understood with my last question: what
would be on the desktop after Nautilus stops drawing it? Would it just
be empty?
By the way, there's a patchset for libgnome/Nautilus to handle different
backgrounds right now :)

Cheers,

Cosimo

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list

Re: Nautilus vs gnome-shell and the future

2009-12-04T05:54:37Z

> John, if you or anyone else want to jump in and help with the code,
> that's obviously appreciated and warmly welcomed!

OK thanks, I might take a look. I am still slowly hacking on my nautilus
coverflow branch [1][2] but will try to find some time.

John

[1] http://github.com/nzjrs/nautilus
[2] http://github.com/nzjrs/nautilus/tree/liststore

--
nautilus-list mailing list
nautilus-list@...
http://mail.gnome.org/mailman/listinfo/nautilus-list