Re: [Texmacs-dev] Reorganization of the menus

[David Allouche]

On Tue, Jul 30, 2002 at 04:20:48PM +0200, Joris van der Hoeven wrote:
> >
> > You will notice that web pages are loaded as in "download", but that
> > files are opened as in "reopen an old case", "open a customer
> > account", etc.
> 
>         .->
> No, the |   icon is called "Reload".
>         .-/

Never said it was not. But it sure is not labeled Revert.

> Remember that it should be possible to consider a web location
> in a similar way as any other storage medium like a hard disk.

I though you would understand that "dowload" is essentially a
read-only operation. Most users do no publish, they just consume (see
various RIAA sponsored laws in the US).

The whole term of Loading is associate to read-only semantics: you
load a program, a library, a web page... You may even load a safe on a
truck.

When you are going to edit a file, you must open it. Just as you must
open a safe to edit its contents.

Metaphor and analogy are the two breats of GUI design.

> > That was exactly the kind of thing I was thinking of. My question was
> > whether there was really a meaningful default paper size on GNU/Linux?
> 
> Yes, look at my (get-default-paper-size) scheme command.

Ok. So there is a document page format and a system page format.

 
> > > > But I really do not think that there is a need for a "Default
> > > > Orentation".
> > > 
> > > We have to be consistent.
> > 
> > Consistent? I just want to be consistent too. Anything which can be
> > move up a level is going up.
> 
> I mean that options which are set globally (init-env)
> should always be accompanied by an option to use
> the default settings (init-default). One submenu for
> a not-so-important option like Portrait/Landscape is
> better then two items in the parent menu.

I agree with neither of your arguments.

Maybe there should be a few, group-related "Revert to default
settings" commands (e.g. only one for page size, orientation and
margins) but not one for every individual setting.

Once again you are designing the GUI based on the underlying
implementation, which is just the wrong way to go 90% of the time.

And I do not agree with your saying "a submenu is better than two
items", and even more so since I think these two items are not needed.


> > > By the way, one may also have Seascape and Upside-down.
> > 
> > You are not being serious. For one thing Seascape and Upside-down just
> > do not exist yet in TeXmacs, and for the other that would be
> > ridiculous: ever tried to type text while your screen is turned upside
> > down? So if that must exist on day, that must be in the "Page
> > Setup..." dialog (which hopefully we will have before).
> 
> It may be interesting for setting the header of the exported
> Postscript document (not for editing of course).

Well, for one thing they are not yet there.

For the other, I think the "Type", "Orientation", "Layout" submenus
items should be moved one level to the Page submenu (which could be
renamed "Page Layout". And the "Page->size" item may be moved up to
the "Document" menu since it.

"Page->Screen Layout" should be moved to the View menu, and
"Page->Header and footer" to the "Insert" menu, but for the "Header
and footer->Show on screen" wich should go to the View menu.

 
> > > > > Another idea: would it be somehow possible to merge "Export" and
> > > > > "Copy to" together, as well as "Import" and "Paste from"? 
> > > 
> > > I meant "Import from clipboard" and "Export to clipboard".
> > 
> > I think I understand: have the "Copy To" and "Paste From" submenu have
> > an item group which provide conversion and copying/pasting to/from the
> > system clipboard? Seems reasonable to me.
> 
> Right, but my problem was to find the appropriate name.

Well, I do not see what is the problem with:

Copy To >
  LaTeX
  HTML
  Scheme
  Verbatim
  ---
  Primary
  Secondary
  Ternary

Yet... I am not sure Primary is really useful, since that is  the
default anyway.

Maybe

Copy To >
  LaTeX
  HTML
  Scheme
  Verbatim
  ---
  Clipboard 2
  Clipboard 3
  Other...

Or "Secondary Clipboard" (etc.), or maybe just plain "Secondary"...
not sure of this one...
 
> > I really do not like the Cancel item. Actually it seems to be the
> > collection of all the cancel buttons in all the missing dialogs.
> 
> Notice that I *really* prefer the Emacs-style searching to
> what is done in other word processors. During searches,
> part of the text is covered by the popup and if you found
> something it might actually be hidden! Then you move the popup,
> and the next occurence may be hidden again...

I agree, that style of searching is often a nuisance. Yet, maybe
"return" or "esc" should stop the ISearch... that is the natural
behaviour for emacs users.

For other users, there could be a "Stop" button next to the ISearch
input field (currently that would be in the minibuffer) with the
appropriate tooltip (say, "return").

> > But GUI is widely a matter of convention (like having "Page Setup..."
> > in the File menu). A bad convention is often better than no conventian
> > at all. It seems that the universal convention nowadays is more and
> > more the Macintosh style.
> > 
> > The fact you do not like this convention (I am not even really sure
> > you understand it well) should not be a reason to force the default
> > binding to follow the X11 convention.
> > 
> > If you like the X11 style, you are the best person to customize it
> > out, and why not make a first step toward GUI profiles by introducing
> > the first extra profile in the distribution: "Joris style".
> > 
> > That too is part of making TeXmacs fits the world instead of the
> > opposite.
> 
> We may use different defaults on different platforms.

Obviously you want to make your liking the default, and you will not
be talked out of that.


> > > My concern is again to keep the number of keyboard bindings small...
> > > I think that C-x, C-c and C-v do not really conflict with
> > > Emacs bindings, because C-x and C-c only make sense
> > > in the case when a selection is active (and the Emacs bindings
> > > like C-x C-s have no particular meaning in that case).
> > > The Emacs C-v is not really useful anyway,
> > > because the page-down button is available on most keyboards now.
> > 
> > What do keyboard bindings do here?
> > 
> > Are not we discussing the menu hierarchy?
> 
> Yes, but in this particular case I think that the behaviour
> has to be uniform (we will propose the corresponding keyboard
> binding in the menus; not the corresponding icon...).

I do not get your point. And anyway I think that mixing emacs-like
binding with M$ like binding and Mac-like binding is recipe for
disaster.

For example, one have "C-y" for pasting and "C-w" for cutting just as
in Emacs but "E-w" does not copy as expected... Even without
mentioning the fact the your shortcut for cut is "E-x", copy "E-c",
leading the user to think that your may be following the
Macintosh-style shortcuts (remember, Esc is Meta in TeXmacs) but "E-v"
do not paste, but move, while "E-r" clears the primary clipoard
instead of redoing...

I can make pages of this.

BTW: I still do not understand the interest of Clear as in "Clear
Clipboard". Maybe a "Clear Clipboards" could be useful to free some
memory after some intensive processing could be useful... but really I
do not see the point of being able to clear clipboard individually.
 

> Yes, so you convinced me that different default actions
> for such elementary operations are appropriate on different platforms.
> I think that this is what is actually the case for applications
> like netscape.

At least I did that :-)

 
> > > I am not sure, but I am not sure of the contrary either.
> > > For instance, a commutative diagram may be seen as an image
> > > with a mathematical meaning.
> > 
> > If it has a mathematical meaning (which I think is a bit hairy an
> > argument) it must be kept in the math menu.
> 
> Hmm, I misexplained my feelings: if images have a mathematical
> meaning (in the sense of structure), then they should indeed be
> in the "Mathematics" menu. If they only have a meaning in
> the sense that they "make sense inside mathematics",
> then we should have images in the Edit menu. But the same is true
> for including images or not in the "Text" menu (which you may
> have found by now in 1.0.0.11). So I think that we should keep
> them in the Insert menu as being some kind of "general objects",
> which may make sense everywhere.

Agreed.
 
> > Did you notice that in my proposal all markup with contextual meaning
> > was moved out of the Insert menu? Which only kept formatting markup
> > and a few universal tools like hyperlinking.
> 
> Right this is exactly what I am working towards to and
> I see images, tables and trees (hey!) as such universal tools.

Ho so much agreed!

BTW: superscripting is often useful in text mode too...


> > > No, because I rather interpret page insertions as physical than
> > > logical decisions. On the other hand, logical markup which relies on
> > > page insertions for its presentation should be moved into "Structure".
> > 
> > Footnote. Floating Table. Floating Figure.
> > 
> > That looks very much like "logical markup which relies on page
> > insertions for its presentation".
> > 
> > Maybe "Floating Object" could be left in the "Insert" menu. But is it
> > really useful anywhere but in text mode? I recognize the need might
> > arise, but is it likely enough not to ask for defining a new macro?
> 
> Right, there is still some confusion here, also because footnotes are
> not exactly implemented in the way that they should be.

I see no confusion here. It seems to me that a footnote is very much
logical markup, and it seems very unlikely to me that users would use
the low-level footnate facility even if it was implemented as it
should be.
 

> > > Yes, Format should only insert with-like structure.
> > 
> > As you like to say: "we'll see".
> 
> What I say seems indeed to be more and more the case:
> all physical typesetting related markup (spaces,
> breaks, resized boxes, etc.) should rather be in Insert.

I keep on disliking being able to have some inline content applied
paragraph markup. The editor should really know better (center should
span paragraphs, indentiation flags should be on the ends, etc...).
The right implementation should allow intelligent merging and
splitting of paragraph, and easy insertion of text at the ends of the
paragraph...

But I admit it make sense to put all physical layout markup in the
Layout menu, putting inline and block features in different groups.


> > So, I propose an alternative:
> > 
> >  -- one mode-specific menu (Text, Mathematics, Biology, Poetry).
> > 
> >  -- one block-specific menu (Table, Tree, Drawing, anything) matching
> >     the innermost block the caret is in.
> 
> This makes sense, but I am not completely sure yet.
> We really should be able to cover lots of situations...
> For instance, the preamble mode is orthogonal to all this...

I would rather have a very different layout in Preamble mode. Giving
easy access to TeXmacs primitives, and secondary access to everything.

 
> > > I do not like "Page setup", but we might want "Printer settings",
> > > like this is the case in some other word processors.
> > 
> > Which ones?
> 
> AbiWord, for instance.

Here, AbiWord has a plain classic "Page Setup..." item in the file
menu and no "Printer settings" item I can see.

Using version 1.0.2.

-- 

                             -- David --