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

[Martin Sevior <msevior physics unimelb edu au>]

On Tue, 1 Apr 2003, Alexander Larsson wrote:

> On Mon, 31 Mar 2003, Gregory Merchan wrote:
> 
> > 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.
> 
> I think you are oversimplifying this. An viewer is not an editor with
> editing disabled. A viewer is an application specifically designed for
> viewing a file, with the features and user interface suited to view
> files of a particular type, including functionallity an editor might
> just not have (e.g. an image viewer might have fullscreen mode, while
> gimp doesn't). Using such a viewer to show e.g. your photos gives a
> much better user experience than launching the gimp for every file. 
> 
> Furthermore, we're currently talking about views that are embedded in
> Nautilus. I think the idea of launching a full-featured editing app
> such as e.g. the Gimp inside Nautilus is really bad. I mean, what are
> you gonna do with all the tool windows and other UI you need? The
> nautilus window will suddenly launch palette windows and allow stuff
> such as opening a new view of the image (does that open a gimp window
> or a Nautilus window?).
> 
> As an example of viewers vs editors, take the component in question:
> http://www.abisource.com/information/news/2003/nautilus-abiword.png
> 
> Clearly its a bug that it has its own menu bar, ideally it should use
> menu merging so that there is only one menu/toolbar set.
> 

The menu bar has been removed. If and when we decide to move forward with 
this we'll do menu merging provided Nautilus can de-merge on exiting
abiword.


> If you were to actually use this to edit a document we'd quickly see
> some issues:
> * The menus are full of items from nautilus that are just in the way
>   when editing. In fact they are dangerous. If you accidentally select
>   something in the "Bookmarks" menu thinking it has something to do
>   with bookmarks in documents you'll go to some other location,
>   possibly losing your work. 

Not neccessarily. If you edit then leave the document without saving this 
can be easily detected and the user given a pop-up menu asking if the doc 
wants to be saved.

> * There is some amount of duplication in the UI, which can lead to
>   confusion. Take for instance Preferences. Is it the Nautilus prefs
>   or the AbiWord prefs? Or the Zoom widgets, which is duplicated in
>   the Nautilus menu/toolbar and the AbiWord menu.

All true. I wasn't sure how menu merging is supposed to work. Is there and 
API which allows us to overide the nautilus menus?

> * If you enable the AbiWord toolbars the amount of menus/toolbars in
>   the window will be huge, giving you little area to edit in.
>   You can of course disable the Nautilus toolbars you don't use while
>   editing the document, however this has side-effects such as changing
>   the nautilus show toolbar prefs.

I don't think we need to do toolbars. There has to be some reason for 
running abi as a stand alone app :-) The idea would be to allow a user the 
option of making a quick change to a doc and or print it. For this we can 
just use the menus.

> * A lot of the normal functionallity in AbiWord has to be disabled
>   since it makes little sense. For instance, none of Open, New, recent
>   files or New Window work well when there AbiWord widget is
>   controlled and embedded by another application.

True. We can leave these out for Nautilus though other apps might want 
them.

> * Keyboard shortcut conflicts. Does Ctrl-B mean "Bold" or does it mean
>   "Edit Bookmarks"?

Yeah. This is a genuine conflict. I don't have an easy answer. Right now 
the answer is "Bold".

>   
> However, if you were to redesign the AbiWord component with the
> intention of making it a kick ass way to view existing documents, and
> browse among documents in Nautilus you would make some changes that
> makes no sense for an editor:
> 
> * Remove the toolbars and rulers to get more screen space to read in.

Done!

> * Use the nautilus menus and other UI functionallity for things like
>   zoom and text copy, avoiding duplication.

Sure we can do that. We already zoom nicely on the zoom in/zoom out
buttons. BTW is there ever going to be a bonobo print interface?


> * Merge in a few easy to find operations in the menus to do things you
>   commonly want do do when viewing a document, such as: print, view
>   fullscreen, text search, fit to width etc.

Easy enough.


> * Be able to have a very short context menu with only the few
>   operations you are normally interested in.

We can just reuse our existing context menu system.

> * Maybe add some navigation features not in AbiWord, such as a table
>   of content dialog that lets you see what page sections are on and
>   lets you go there quickly.

We should add this feature to abiword anyway - but not before 2.0 I think.

> * Allow key navigation to be more natural for reading a
>   document. Arrow  keys scroll, page up/down flips pages. No need to
>   move the cursor around unless you specifically want to select some
>   text to copy it. 

Well I think users natually expect the document to move around with the 
cursor.

> 
> 
> If you were to do something like this it would be true value-add,
> not just a new (slightly worse) way to edit documents. If you want to
> edit or write a document you'd use the best way to do that (i.e. AbiWord), 
> but if you're just browsing around looking at documents you get a really
> slick, integrated and efficient way to do that.
> 
> Now, that would rock!
> 

Yeah. This can certainly be done. Even now with debug build the abiword
view opens small docs about as fast as the text view. Since there is no
overhead in building the gtk interface on startup, 5 page or smaller docs
open apparently instantly on my laptop. One issue users often have with
computers is finding the document they want. With Nautilus set to
instantly open docs on single click I can very quickly see the contents of
my disk and find the file I really want.

We can make several different abiword bonobo menus and access them via
different bonobo-activation interfaces. Abiword in evolution would have
different needs for example. We can certainly design an optimal interface
for Nautilus.

Cheers

Martin