Re: [Texmacs-dev] Reorganization of the menus

[David Allouche]

On Sun, Jul 28, 2002 at 04:23:05PM +0200, Joris van der Hoeven wrote:
>
> I don't give a fuck about what the Macintosh user interface guidelines
> specify on this issue; I hate abusive capitalization, except in German,
> where it is part of the language. I also checked several applications and
> I did not encounter any application yet which applies this convention
> in a consistent way. We might specify an option though which does
> this capitalization automatically for English and which may be made
> default on MacOS. But I do not want it elsewhere.

Please stay polite.

I do not know which applications you looked at. But I can tell that
Abiword, OpenOffice, Mozilla, Nautilus and M$IE (none on Macintosh)
respect that rule. What is common to these applications? They are
professional software where there are people who have a clue about GUI
design, and who have the power to enfore the Right Thing against
hard-headed programmers.

What is the difference with the software you probably checked
(Assuming you check stuff like KWord or Gnumeric)? These other
softwares are done by amateurs who may be good at coding apps but
generally only have a small clue about GUI design.

If you cannot be talked out in doing the right thing that is not a
very important problem, since a lot of developpers are already doing
it wrong (as you noticed), so that may pass unnoticed in TeXmacs.

At least I had tried.


> > I agree that other languages (esp. French, where the convention is to
> > capitalize only the first letter) can have other conventions, but I do
> > not see why that should prevent us from doing the right thing for
> > English.
> 
> Because Macintosh has no patent on "the right thing".

Once again, that rule is also used in the KDE User Interface Guideline
and in Microsoft applications, and in any other professional
application I checked.

Maybe you should realize that you, neither, have the patent on "the
right thing".


> > Actually, "Revert...".
> 
> You mean "Revert"?
> What about Reload by the way?

No, I do mean "Revert...". In my first message I explained that, in
principle, menu items which simply show a confirmation dialog should
not be followed by ellipsis, but since at the moment everything is
done modelessly in the minibuffer it is good to break that rule so
that the user know when to look at the minibuffer.

I do not like "Load..." and "Reload".

Every professional software use "Open..." and "Revert".

Users do not say "I load a file" but "I open a document", neither they
say "I reload a dirty file in the buffer" but "I revert to the last
saved version".

> > > OK; on dialogues & emacs-style entering arguments in the footer:
> > > this should really be an option for the user. Many Emacs users
> > > just hate dialogues and so do I.
> > 
> > You can make good dialogs which are quick to navigate using the
> > keyboard. Then you loose very little in efficiency. But I am not for
> > making that mandatory.
> 
> I will not do this before we have a new GUI anyway.

Of course, I was just saying that the emacsish despise for dialogs is
not necessarily justified.

That makes me think of the TeX vs WYSIWYG argument. Emacs was unable
to use dialogs for long, so its user tend to think that not using
dialog in the only Right Way, in the same manner as typesetting
systems were not able to be WYSIWYG for long so their user developped
a rationale for why that is a good thing.


> > And I consider that it makes more sense to put the page size
> > configuration in the "Page Setup..." where every other GUI application
> > I know put it, then along with the default font, paragraph setting and
> > text language of the document.
> 
> What does the text language have to do with the *page* setup?

Sorry, I actually meant

    And I consider that it makes more sense to put the page size
    configuration in the "Page Setup..." where every other GUI
    application I know put it, RATHER THAN along with the default
    font, paragraph setting and text language of the document.

I agree those other options really should be in the Document menu.
  
> What should really be done is something like the following: the printer
> maybe setup in the File or the Settings menu or both and/or later inside
> the Print... dialogue box. The printer settings for "Page size" are taken
> as the defaults for a document, but it is possible to specify something
> else in the Document->Page menu. A warning should show up if both
> sizes do not match and the user is prompted to specify what he wants.

So, one page size in the "File->Page Setup" menu (which is actually a
persistent application setting with the system setting as a default),
and another in the Document menu (which is a document setting).

I have never seen that in any word processor. It is interesting if the
application does have some advanced page swapping features like
printing two pages by sheet or producing booklets (then the paper
thickness must be taken in account to correct the margins).
 
But it does make some kind of sense if there is a meaningful system
paper size. Is it really the case on GNU/Linux?


> No we need something like
> 
> Orientation
>     Default
>   -----------
>   * Portrait
>     Landscape
> 
> This needs some work, but it should be not too hard.

No, we do not want a hierarchical menu for any option with more than
two choices. Maybe:

  Use Default Orientation
  Use Portrait/Landscape Orientation

But I really do not think that there is a need for a "Default
Orentation".

 
> > > > "File->export->postcript" is redundand with "File->print->print all to
> > > > file" and should be removed.
> > > 
> > > There is a slight difference: if I remember well, everything is printed
> > > to a single page in one of the cases. Anyway, this should be made clearer
> > > if we want to keep this possibility.
> > 
> > May I beg you pardon? What con be the use of generating PostScript in
> > papyrus style? I remember of that behaviour having been reported as a
> > bug.
> 
> It allows you to see a text as an image.

I am absolutely not convinced it is a useful feature. All the
PostScript files I have seen in my life were paginated.

But if you have the use for this feature, that is an obvious proof it
can be useful.
 

> > > > The "File->export" submenu should be moved to the "Export" dialog in
> > > > the form of a pop-up menu.
> > > 
> > > Or to save as, if you want to be consistent with what you said above.
> > 
> > You are right.
> 
> You want to make this modification in the file chooser?
> Don't forget to keep a "By extension" or "Automatic" option.

Well, I could do it when I have the time. Probably not anytime soon.
But since you wanted me to give all my propositions, I did so.


> > > > The two menus "Tools->selection->import" and
> > > > "Tools->selection->export" should be moved back to the Edit menu where
> > > > they really belong and be renamed "Pasting imports >" and "Copying
> > > > exports >". This phrasing make it clear that these menu are only meant
> > > > to change the behaviour of the copy and paste command when relating to
> > > > external applications.
> > > 
> > > Well, this is not what other users tend to say.
> > 
> > I remember very well the whole affair about these submenus. They were
> > labelled simply "import" and export" right in the "Edit" menu and were
> > confused for the "import file" and "export file" commands. Your
> > request was roughly "can anyone think of better names". Since nobody
> > had, you moved them off where they were less likely to confuse the
> > users.
> > 
> > Well, I though of better names, which I think very unlikely to be
> > confused with "import file" or "export file" since they explicitey
> > state that they are associated to copying or pasting operations.
> 
> Another idea: would it be somehow possible to merge "Export" and
> "Copy to" together, as well as "Import" and "Paste from"?

There could be several possibilities:

  Having Import put the imported document at the position of the
  cursor. I am not sure that is a good idea. For example, how would
  the documentclass of imported LaTeX document be handled? And haw
  would formats which rely on specific packages (like HTML) would be
  imported?
 
  Symmetrically having export only export the selection (region). I am
  not sure that is a good idea for similar reasons.

  "Export clipboard" and "Import clipboard" stateless commands to
  perform a conversion on the content of the clipboard. Generally,
  that would be less convenient than the current stateful behaviour.
  That will probably become more useful the day we have intelligent
  cut'n'paste with other programs.

I still think the current commands are fine. The only issues I see are
with their naming and their location in the menu hierarchy.


> > > > The "cancel" command is not really an edition command, and its
> > > > presence in the Edit menu is absolutely not informative. Emacs users
> > > > instinctively use C-g when they want cancel. Other users may use
> > > > various tricks. I guess all non-emacs user get out of incremental
> > > > search by moving the caret (either by clicking or with the arrows).
> > > 
> > > I agree that one among cancel and clear there might be one too much.
> > > Maybe cancel is just at the wrong place.
> > 
> > What is relationship???
> > 
> > Cancel and clear are two completely independent commands AFAIK.
> 
> I think that it is good to have Cancel => Clear

Could you explain me why Cancelling a spell check or an interactive
minibuffer should ever clear my precious clipboard?

The clipboard sometimes contains critical information, we must not
erase its contents unless the user is taking some action which is well
known for its side effects on the clipboard: that is Cut or Copy.
 

> > Ok! So there is a bug. Move does not work when the caret is after the
> > end of the selection, and in the same STRING block as the selection.
> > That was the first thing I tried, and since it did not move I was
> > perplexified.
> 
> Please give me a more precise example; I failed to reproduce this bug.

Create a new document. Type "Hello World.". Select "Hello" using the
mouse. *Quickly* click at the end of the line, select move. If the
click is too late, the command works as expected. It seems the problem
appears when the delay between clicks is close to the double-click
time.


> > And I disagree with you about changing paste to move. Paste is not
> > expected to remove the selection. Move is fine as it is, it just need
> > to be fixed. Hopefully, one day this feature can be implemented by
> > drag'n'drop.
> 
> This is not what I say: the name of the menu item remains Paste,
> but its action in case of an active selection is Move.

That would be giving Cut semantics (removing the selection) to Paste.
It seems obvious it is a bad thing. One expected behaviour would be to
overwrite the selection by the contents of the clipboard.

But actually the problem may be more to decide which kind of selection
semantics we want to use by default. X11 semantics, where selecting is
implicitely copying? Or Macintosh (and basically the rest of the word
including Windows and Mozilla) semantics where copying must be
explicit?

Most GNU/Linux apps, even KDE and GNOME ones (but, interestingly, not
AbiWord) just do not seem to be able to decide. That leads to various
mixes of the two semantics which I keep finding confusing.


> > Actually the Table menu is annoying since its just pops up and is
> > orthogonal to the context mode. Maybe we could simply remove it from
> > the toolbar since all its commands are accessible from the toolbar.
> 
> No, because certain people may prefer the menus.

Ok.


> > Once again your rationale is wrong. The user does not care where stuff
> > is defined. When the user want to insert an image he go to this menu
> > and will fiddle around with the menu items, if figures and images are
> > kept toghether, the user will promptly 'figure' out that the first
> > step is inserting a figure, and then an image in the figure.
> > 
> > So image and figure must be moved toghether to the Structure menu.
> 
> No, then we should keep it in the Insert menu,
> because images can also be inserted in Math mode.

Is that useful? In which context? Is would it not be better to ask for
an embedded text environment, just as an embedded math environment is
required if one want to insert symbols in a text?

 
> > Do you use footnotes and floating objects in math context?
> > I sincerely think that makes no sense and should be forbidden.
> 
> I think that this is indeed not often the case,
> but I am not sure that you would *never* want to do this.
> I can imagine a long eqnarray* where you detail a given step
> in a footnote.
> 
> > For one thing, footnotes cannot be used in math context for fear of
> > being confused with math notation, and for the other thing floating
> > objects are top-level and, thus, must be placed in text context.
> 
> But it is true that they can be confused with mathematical notation.
> 
> Clearly, marginal notes might be used in math mode in the future too.

So you agree that page insertions should go in the Structure menu?


> > > > Header and footer insertion commands should be moved out of the
> > > > Document->page menu and to the Insert menu.
> 
> You are right from a technical point of view, but I am not sure that
> users will intuitively search for these issues in the Insert menu.
> In current applications, it is often part of the Edit menu.

Anyway, it is much more intuitive there than buried in a fourth level
submenu of the Document menu!


> Things might become possibile with a format menu.
> We should examine that possibility.

I would not mind moving them in another menu later, but at the moment
I just think you are confusing the discussion with that "Format" menu.
 

> > I can think of no other menu to put them in, and obviously these are
> > inserstions, preamble mode is orthogonal to the context mode so they
> > cannot be put in the Structure/Mathematics mode-local menu.
> 
> Another possible menu would be a top level menu for editing
> in preamble mode. This is probably a good idea anyway.

So? Do you want MORE or LESS top level menus? You are confusing the
discussion.

Let us do things incrementally by small logical steps. When the
current reorganisation is done we well see how we can specialize the
menus for the preamble mode.


> > > Missing: entries for "strong, emphasize, etc."
> >  
> > Maybe. Actually they are missing now, and no-one seems to mind since
> > they are obvious and accessible on the toolbar. Maybe we can unclutter
> > the menus by reducing duplication with the toolbar...
> 
> Yes, but there are less obvious entries like abbr, dfn and acronym,
> which are not available on the iconbar.

Which, anyway, are available nowhere but by using keybindings or
cammand names. Please stop trying to confuse me.

Let us find a good organisation for the existing items, and then add
commands for lost structures, and then, maybe, go for another round of
restructuring.


> > I think we should set a clear policy on this point.
> > 
> > One can notice that all items currently in the first part of the
> > Insert menu when in text context can be accessed from the toolbar...
> > and I would really not mind being able to access all math-specific
> > menu items from the toolbar too... Moreover, session context also has
> > some command accessible only through the toolbar.
> 
> We'll virtually anything might become accessible from the toolbars
> when well done (Load and Save too...), but we probably should design
> the menus layout independently from the toolbars.

Ok, so we are going to keep duplication functionnality between the
toolbar and the menubar.

For permanent entries (like those of the file menu) that is no problem
to me; but for transient entries (Structure, Table, Math) there would
be an opportunity for uncluterring the menubar.


> > I already discussed that. I propose *one* transient menu. Having a
> > permanent Table menu does not waste room since it is orthogonal with
> > other menus and we need to have the room to display it anyway.
> 
> And Tree, when it will be ready? That one will be orthogonal too.
> I can come up with dozens of such things...

And a Tree in an Equation in a Table in a Structure?

You are not giving any answer, just pointing out that we need to move
things out the menubar.


> > Settings->printer items should be in "Files->Page Setup..."
> 
> I don't like your "Files->Page setup" menu.

I'll be back.

 
> > Security could be moved to the Tools menu.
> 
> No, it is part of the Settings.

Right, but it would not make much sense to keep the Settings menu if
the only option left is the Security submenu...


> > The GUI language is essentially a system feature, configured through
> > the environment variables documented in the locale(1) man page. It can
> > be an extra to allow explicit setting in the GUI, even though that is
> > not the way it is done anywhere else. We could put this submenu in the
> > File menu (you can notice you put in the same toolbar as File menu
> > commands), or simply not let it be configured by menu since it can be
> > set by toolbar.
> 
> No, it should remain in the Settings menu (and later to
> "Edit->Preferences..."). I think we should keep it, because certain
> users do not know how to configure their locale, or they are using
> the software at a foreign university for a short amount of time.

Okay.
 
> > One thing, though: I think "View->load in new window" should be in the
> > File menu as "Open in New Window.." after "Open...".
> 
> And "Clone buffer"?

You mean "Clone Window"? It should stay in the View menu since it is
not related to opening or closing buffers, just to managing views.

-- 

                             -- David --