Re: [Texmacs-dev] Reorganization of the menus

[Joris van der Hoeven]

> > I hate abusive capitalization in "Start Up the Computer".
> > This is ugly, even in titles, and very language dependent.
> > I am willing to capitalize the first letter, not the rest.
> 
> The Macintosh User Interface Guidelines *specifies* menu items should
> be capitalised that way (actually, I made some copy-paste of the
> definition of title capitalization style).
> 
> The KDE User Interface Guideline does not seem to say anything
> explicitely about that, but all the menus it shows *are* capitalized
> in title style.
> 
> The Microsoft Windows User Experience is not online, but it seems that
> English part of my Window installation (on VMware) use that convention
> too. Some exceptions are parts of the same menu hierachies which are
> in French.
> 
> Title captalization *is* the right way to go, at least in English.

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.

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

> > > All submenus with only two non-interactive items will be removed and
> > > replaced by toggled menu items.
> > 
> > Yes; but we need to modify the code for this;
> > again I prefer to wait a while with this.
> 
> That can be done completely in GUILE. In the past, I made some ugly
> patch for that, but you can make someting less ugly with, say, "hollow
> bullet" and "filled bullet".

No, this is not true, because the indentation will be screwed up.
All this will take a few days of work and it is worth to do it.
I'll see whether I have time for it.

> > I also see a difference between choosing an item (like a shrinking factor)
> > and selection of an environment change (like an italic font).
> > Both things should be indicated in the menus, but in a different way.
> > Since TeXmacs is particular on this issue, we must not follow
> > the classical rules here.
> 
> Well, shrinking factor is a typical case where a classical checkmarked
> set of menus items is needed. For italic font, I have no idea, and I
> would no propose to change the current menu layout.

We need checkmarks, bullets and something new, but bullet-like,
like a star or a hollow bullet.

> But we could use some more intelligence in the editor. For example if
> an italic block of text is selected and another, incompatible, text
> property is applied (like roman), then the italic environment should
> be replaced by an environment for the new property. Maybe choosing the
> property of the selected enviroment should remove the environment.

This is already more or less the case.

> > > Why "revert buffer" instead of just "revert", or "revert to saved"?
> > 
> > If you want I can replace it by revert.
> 
> Actually, "Revert...".

You mean "Revert"?
What about Reload by the way?

> > > The print menu should use a dialog. So we keep on with the same
> > > hierarchic menu.
> > 
> > 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.

> > >   -- "Document->page->size" should be moved to "File->Page
> > >       Setup->Size" and keeped as is.
> > 
> > I disagree; this is clearly a document property and has nothing
> > to do with file handling.
> 
> There is a fundamental assumption on how those menus should be
> organized which I would like to be revised, or at least discussed with
> other users.
> 
> Your assumption is that menus which relate to the same kind of object
> should be grouped in the same menu.
> 
> I think that is perfectly ok as long as the object is something which
> is obvious to the user. "Insert", "Structure", "Text" and "Paragraph"
> are good examples of this. "Insert" inserts non-modal, non-structuring
> tags; "Structure/Mathematics" inserts modal environments and tags.
> Text set attributes for a span of text, and Paragraph set attributes
> for the current paragraph or a range thereof.
> 
> Document is also a menu which is currently well defined: it stores all
> items which relate to global state stored in the document. Wait! "state
> stored in the document"... that is an implementation detail,
> programmer perspective... To the user, state should be stored when it
> makes sense.
> 
> 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?

> No user want to think "I want, to set the page size; wait, page size
> is an information which I want to be stored in the document, so it is
> not in the file menu; it is an information which do not belong to
> anywhere in particular, so it is probably in the Document menu; let me
> read the items of the document menu... well... if it is here, it must
> definitely be in the page submenu... haha! there is a size subsubmenu!
> Ok, got it!"
> 
> Instead, it is arguably much more natural to think "Page size is about
> printing, so it is next to the print item. Ha, there is the usual Page
> Setup... item, it should be there. Ok, got it!" 

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.

> > >   -- "Document->page->orientation" should become a toggled menu item
> > >      associated to the actions "Use Landscape Orientation" (initially)
> > >      and "Use Portrait Orientation" (when the current orientation is
> > >      landscape).
> > 
> > OK, but we do not have toggles yet.
> 
> Yes we do have toggles:
> 
>     (-> "orientation"
>       ("default" (begin
>                    (init-default "page orientation")
>                    (set-page-parameters)))
>       ---
>       ("portrait" (set-page-orientation "portrait"))
>       ("landscape" (set-page-orientation "landscape"))
>       ---
>       (if (equal? "portrait" (get-env "page orientation"))
>           ("Use Landscape Orientation"
>            (set-page-orientation "landscape")))
>       (if (not (equal? "portrait" (get-env "page orientation")))
>           ("Use Portrait Orientation"
>            (set-page-orientation "portrait"))))
> 
> That replacement for the Document->page->orientation submenu features
> an additionnal item which has the desired toogled behaviour. There may
> be means of doing something more factorised, but you know the
> semantics of menu construction better than I do.

No we need something like

Orientation
    Default
  -----------
  * Portrait
    Landscape

This needs some work, but it should be not too hard.

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

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

> > I prefer selection to clipboard as a terminology,
> > also because we can have multiple selections.
> 
> We can say "multiple clipboards" instead of multiple selection.
> 
> I really do not see why you insist on using that confusing terminology.

We'll see.

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

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

> > > Questions: What is the use of Edit->move?
> > 
> > The selected region is moved to the current cursor position.
> > I actually would like to make this the default behaviour of paste,
> > when a region is being selected; in that case we do not need
> > this item anymore.
> 
> 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.

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

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

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

> > > The submenu "Insert->page insertion" should be moved to the Structure
> > > menu and enabled only in text context.
> > 
> > No.
> 
> 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.

> > > Menus items relating to vertical space insertion and indentation flags
> > > should be moved to the Paragraph menu since they only work on
> > > paragraph blocks. Menus items from "Insert->space" not related to
> > > vertical spaces should be moved to the top-level of the Insert menu.
> > 
> > I am not sure, but this might be an idea.
> 
> I am pretty sure of this one. But actually my proposal was not
> complete: the vertical spacing should also exhibit the new, smarter,
> behaviour that you just approved for indentation switches (cited
> below).
> 
>     > > Indentation switches like "disable/enable indentation
>     > > before/after" should be made more smart. For example, in
>     > > normal mode, they should insert a tag at the beginning (ident.
>     > > before) or a the end (indent. > > after) of the current
>     > > paragraph. Before displaying the menu texmacs > > should check
>     > > the current environment and the tags in the current > >
>     > > paragraph to display the appropriate "disable/enable" prefix.
>     > 
>     > Yes.

We'll see; this also depends on how I would like to let this evoluate.
I have no time to think about this in detail now.

> > > Header and footer insertion commands should be moved out of the
> > > Document->page menu and to the Insert menu.
> > 
> > This is not coherent with what you say above.
> > 
> > In fact, you mix things up here: header and footer definitely
> > should stay where they are, since these are not *insertions*;
> > these are rather properties of the page.
> 
> On the contrary, I am being perfectly coherent.
> 
> Nothing can be a "property of the page" because *there is no* concept
> of a page in the document structure. Pages are visual elements (aka
> boxes) inferred by the typesetter from its input (aka trees). Well
> maybe there should be one (for page composition applications), but
> currently that is not the case and it certainly does not fit with the
> current semantics of setting headers and footers.

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.

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

> > > The items of "Insert->executable" must be moved in a new group at the
> > > top-level of the "Insert" menu.
> > 
> > They really should be enabled only in something like preamble mode.
> 
> Agreed. But why not let them in the Insert menu?

That is fine.

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

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

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

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

> > > Maybe we could get some room back by scaterring the items of the
> > > Settings menu in the appropriate semantic categories, or all in the
> > > Edit menu where the Preference menu item (displaying a dialog) should
> > > be.
> > 
> > No.
> 
> Well... I think that is a poor argumentation...

I agree; I did not want to think about this.

Anyway, I agree that Settings might rebecome a "Preferences..." menu item.
But we do not have the appropriate dialogue system yet.

> Settings->printer items should be in "Files->Page Setup..."

I don't like your "Files->Page setup" menu.

> Security could be moved to the Tools menu.

No, it is part of the Settings.

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

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