headers
Gregory Merchan | 1 Apr 2003 01:00

Re: [Fwd: Re: commit: AbiWord is now a Nautilus View.]

On Mon, Mar 31, 2003 at 11:08:09AM -0500, Alexander Larsson wrote:
> You keep saying [a non-editing view] gets in the way more often than not,
> but you give no reason or argument why this is so. In my experience
> files/documents are read more often than they are edited/written, so I
> would say views that view the content of files are not pointless. . . .

If you wish to view a document and it opens in a editor, all is well.*
If you wish to view a document and it opens in a viewer, all is well.
If you wish to edit a document and it opens in a editor, all is well.
If you wish to edit a document and it opens in a viewer, you're screwed.

* The exceptions to this being non-WYSIWYG editors and very complex editors.
  Non-WYSIWYG editors are less popular for any format as soon as a decent
  WYSIWYG editor is available. Audio/Video editors may be very complex, but
  their use is rare so that the default can be to play the file.
--

-- 
nautilus-list mailing list
nautilus-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/nautilus-list
Permalink | Reply | 3 comments |
headers
Wesley Leggette | 1 Apr 2003 02:25
Favicon

Re: Dealing with files in Gnome

Regarding Pick up and drop, I think the semantics are no better. What
happens if you "pick up" one object, then another, and then drop? It
would defy all expectations to "drop" both of them at the new location
if this is simply a change in cut, copy, paste. So assuming that that it
would work this same way, the change in terminology is pointless. We all
know what cut, copy, and paste mean and it's more than logical to assume
our users do to.

But of course there is a utility for remembering multiple cuts and
placing them all in the new paste spot. But users would have to be able
to easily remember what they have currently cut (some sort of cursor
tag-a-long that shows the icon's they are carrying and allows them to
drop all or some of them unchanged?). If this sort of behavior were
implemented, "pick up" and "drop" would make a lot of sense, and since
it's different that traditional cut and paste, the name change would be
appropriate. And hey, we could always have a preferences toggle between
the two modes of operation.

On Mon, 2003-03-31 at 11:48, MArk Finlay wrote:
> The (very) recent discussion on the nautilus list[1] about whether or
> not nautilus view should be editable got me thinking about the way gnome
> deals with files in general. Atm we have the "Open with" menu in
> nautilus which is divided into internal viewers and external
> applications which can both be either viewers or editors.
> 
> There is a lot of duplication here. eg. we have internal and external
> image viewers: "Open with gthumb" "Open with eog" and "Open with Image
> viewer". All in all, it's less than ideal IMHO.
> 
> Maybe others greater than myself have done it before, but I stepped back
(Continue reading)

Permalink | Reply | 4 comments |
headers
Martin Sevior | 1 Apr 2003 03:15
Picon
Picon
Favicon

Re: [Fwd: Re: commit: AbiWord is now a Nautilus View.]

On Mon, 31 Mar 2003, Alexander Larsson wrote:

> On Mon, 31 Mar 2003, Dave Bordoley wrote:
> 
> > When I talked about this general issue with Nils awhile back he made a 
> > good point that if you don't support editting in these views than you 
> > are really just getting in the user's way more often than not. On the 
> > other hand, to the best of my knowledge nautilus won't default to using 
> > a view over an app, but this leads me to wonder whats the point of the 
> > view really anyway.
> 
> You keep saying it gets in the way more often than not, but you give no 
> reason or argument why this is so. In my experience files/documents are 
> read more often than they are edited/written, so I would say views that 
> view the content of files are not pointless. They are a pretty useful 
> part of browsing the filesystem.
> 
> The problem with editing in a view is that the state is so temporary. 
> Whenever you go up, back or something like that you loose all the changes 
> you made. And the sort of complicated UI needed for domain specific 
> editing of files is mostly to complex to fit nicely into the Nautilus
> window without severe conflicts and UI overload.
> 
It would be trivial (and in fact is the default behaviour) to pop up a 
dialog on dirty document (in AbiWord and almost certainly in other 
editable views) and ask if you want to save it. I don't think 
this would be confusing to the user.

Martin
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Camp | 1 Apr 2003 07:06

Eel and Nautilus 2.2.3.1 are released

Eel and Nautilus 2.2.3.1, "We love you, list view" are released

This release continues the work on the UI bugs that make nautilus
tougher to use.  In particular we've focused on the list view, a
long-neglected part of the nautilus family.  Anybody using the list
view on a regular basis should upgrade, we think you'll be pleased.

Here is a partial list of the changes in 2.2.3.  See the NEWS file for
more:

* List view mouse behavior is much improved.  Drag and Drop is more
  natural, single click mode is usable, and selection behaves more like
  selection in the icon view.

* The list view doesn't cut off bits of icons anymore.

* List and icon view both have keynav and mouse selection improvements.

* Easier to trigger auto scrolling during drag and drop in the icon
  view

* Much better thumbnail queue handling. Visible thumbnails are
  prioritized.

* Show volume and free space in the property dialog for directories

* Clean up by name doesn't leave icons outside the screen anymore

* Automatic notes emblem (requires gnome-icon-theme 1.0.2)
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Su | 1 Apr 2003 08:46
Picon

I cannot compile nautilus 2.2.3.

Hi,
I failed to compile nautilus 2.2.3, the error message is:

/bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..
-I.. -pthread -DORBIT2=1 -I/usr/include/eel-2 -I/usr/include/gconf/2
-I/usr/include/gtk-2.0 -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/gnome-vfs-2.0
-I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libart-2.0
-I/usr/include/libgnome-2.0 -I/usr/include/libgnomeui-2.0
-I/usr/include/libxml2 -I/usr/include/gail-1.0
-I/usr/include/libglade-2.0 -I/usr/include/orbit-2.0
-I/usr/include/linc-1.0 -I/usr/include/bonobo-activation-2.0
-I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/X11R6/include -I/usr/include/freetype2
-I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0
-I/usr/include/libbonoboui-2.0 -DG_DISABLE_DEPRECATED
-DGDK_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED
-DGTK_DISABLE_DEPRECATED -DGNOME_DISABLE_DEPRECATED
-DDATADIR=\""/usr/share"\" -O2 -march=i586 -c
nautilus-view-component-stubs.c
../libtool: line 1: s%^.*/%%: No such file or directory
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
../libtool: line 1: -e: command not found
(Continue reading)

Permalink | Reply | 1 comment |
headers
Roberto Rosselli Del Turco | 1 Apr 2003 08:41
Picon
Picon

Re: [Usability]Dealing with files in Gnome

MArk Finlay wrote:
> The (very) recent discussion on the nautilus list[1] about whether or
> not nautilus view should be editable got me thinking about the way gnome
> deals with files in general. Atm we have the "Open with" menu in
> nautilus which is divided into internal viewers and external
> applications which can both be either viewers or editors.
> 
> There is a lot of duplication here. eg. we have internal and external
> image viewers: "Open with gthumb" "Open with eog" and "Open with Image
> viewer". All in all, it's less than ideal IMHO.

I only find it "less than ideal" when you have already opened a file, 
let's say an image, and you have all those options appearing as buttons 
in the sidebar: awkward and not very elegant IMHO.

> Maybe others greater than myself have done it before, but I stepped back
> and asked myself this: "A user is looking at a folder of files, what
> could they want to do with them?" There are the obvious move, delete,
> rename, copy which I'm not going to go into[2]. 
> 
> Aside from those - they generally either want to view a file or edit it.
> The distinction between them is really useful as it allows us to use eog
> instead of the gimp when we just want to look at a picture.
> I may be totally wrong about that, but If I'm not then it makes sense
> to me that "Edit" and "View" be more prevelent in the general ui.
> 
> Would it not make more sense to have "View with.." and "Edit with.."
> items in the nautilus context menu, than to have an "Open with.." item
> with a mixture of viewers and editors, and with no obvious distinction
> between them?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Waugh | 1 Apr 2003 09:03
Gravatar

Re: I cannot compile nautilus 2.2.3.

<quote who="James Su">

> I failed to compile nautilus 2.2.3, the error message is:

> Is it a bug of nautilus? Maybe the configure script is wrong.

Grab 2.2.3.1, which went up soon after 2.2.3. There seem to be a few
interesting build environments making poopy tarballs around these days. :)

- Jeff

-- 
linux.conf.au 2004: Adelaide, Australia         http://lca2004.linux.org.au/

  "Linux continues to have almost as much soul as James Brown." - Forrest
                                 Cook, LWN
--

-- 
nautilus-list mailing list
nautilus-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/nautilus-list
Permalink | Reply | 0 comments |
headers
Julien Olivier | 1 Apr 2003 11:57

Re: [Fwd: Re: commit: AbiWord is now a Nautilus View.]

> If you wish to view a document and it opens in a editor, all is well.*
> If you wish to view a document and it opens in a viewer, all is well.
> If you wish to edit a document and it opens in a editor, all is well.
> If you wish to edit a document and it opens in a viewer, you're screwed.
> 
> * The exceptions to this being non-WYSIWYG editors and very complex editors.
>   Non-WYSIWYG editors are less popular for any format as soon as a decent
>   WYSIWYG editor is available. Audio/Video editors may be very complex, but
>   their use is rare so that the default can be to play the file.

I don't totally agree:
 - most of the time, viewers are less bloated and, thus, are faster to
start. Just compare GIMP with EOG.
 - most of the time, viewer have functions that editors don't have and
that you'd miss if you opened your document in an editor. For example,
gthumb has a slide-show and GIMP doesn't.

--

-- 
nautilus-list mailing list
nautilus-list <at> gnome.org
http://mail.gnome.org/mailman/listinfo/nautilus-list
Permalink | Reply | 0 comments |
headers
Julien Olivier | 1 Apr 2003 12:07

Re: Dealing with files in Gnome

Let me introduce a new idea.

Imagin you are browsing a folder containing - say - pictures, OOO
documents and music.

Double-clicking on an icon should open an editor (if available, else
default to a viewer) as a standalone app (here, GIMP, OOO (editors) and
XMMS (viewer app)). Now, Nautilus should also have a "browse files in
this folder" button (directly on the toolbar). This button should launch
another Nautilus window. In this new window, Nautilus should show the
first document using an embedded viewer and you should be able to use
previous/next icons to move from one file to another.

Wouldn't that be great ?
Permalink | Reply | 2 comments |
headers
Reinout van Schouwen | 1 Apr 2003 11:32
Picon
Picon

Re: [Usability]Dealing with files in Gnome

Hi Julien,

On Tue, 1 Apr 2003, Julien Olivier wrote:

> XMMS (viewer app)). Now, Nautilus should also have a "browse files in
> this folder" button (directly on the toolbar). This button should launch
> another Nautilus window. In this new window, Nautilus should show the
> first document using an embedded viewer and you should be able to use
> previous/next icons to move from one file to another.
>
> Wouldn't that be great ?

I don't really like that idea. It would introduce different "modes of
operation" in Nautilus. When a user would activate this, go somewhere else
and come back again, how would (s)he know if the second window is in
"file browsing" or in "folder" mode?

Also I think your idea places the role of Nautilus as an application too
much on the foreground. By this I mean that I believe Nautilus should act
as "transparent" and unobtrusive as possible. By having users perform a
magical dance to activate internal viewers I think you're not doing them a
service.

regards,

--

-- 
Reinout van Schouwen			Artificial Intelligence student
email: reinout <at> cs.vu.nl			mobile phone: +31-6-44360778
GPG public key http://www.cs.vu.nl/~reinout/reinout.asc
MandrakeClub member
(Continue reading)

Permalink | Reply | 1 comment |

Gmane