Re: [Texmacs-dev] Reorganization of the menus

[David Allouche]

I knew that making that kind of big proposal would put me into
trouble, but you did not give the choice but doing it or keeping
quiet.


On Sat, Jul 27, 2002 at 09:00:26PM +0200, Joris van der Hoeven wrote:
> 
> > Menus must be stable. They must not appear and disappear. If some
> > items cannot be used in a certain context, they must be dimmed out. If
> > all items in a menu are dimmed, the menu title must be dimmed, yet
> > still allow the user to unroll it.
> 
> This needs some changes in the code. I prefer to wait for a new GUI port 
> before doing this. Also, this criterion will not always work in TeXmacs
> (see below).

I do not believe that is so difficult to do. And if you do not want to
do it now, you will have accept non-trivial menu restructuring when
this feature is available.

As a temporary work-around, you could simply put disabled menu items
names in parenthesis.


> > In principle, all menus items which require further information from
> > the user, and only these, must be followed by ellipsis ("..."). Menu
> > items which merely prompt for confirmation must not be followed by
> > ellipsis.
> 
> This can be taken care of. I would like a more structural thing than
> ellipses though. I do not know if the Chinese use ellipses...

The Japanese do. Anyway that is of no concern for English menus.


> > All menu items must be capitalized in title style.
> 
> 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 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.

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

And many toggled menus do not even need some kind of checkmark. In
many cases that is even harmful. For example, the hyphenation menu
would be best changed to two items depending on the context: "Enable
Professional Hyphenation" and "Disable Professional Hyphenation". Idem
for the mode menu: "Enable/Disable Preamble Mode". There was a
rational at the URL I gave in my previous mail.


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

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.

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

Actually, "Revert...".

 
> > The import and export menus items are only useful if they perform
> > importation in the current document, or exportation of the current
> > selection.
> 
> No, they are used for importation from and exportation to extern formats.

Yes they do. That is why they are redundant with open and save.


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


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

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


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

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


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


> > Edit menu:
> > ==========
> > 
> > First, a bit of terminology. Xlib has brain damaged terminology
> > regarding copy and paste. What Xlib calls the "selection", is the
> > "clipboard" to the rest of the world. For the civilized world (not
> > Xlib) the selection is only what emacs calls the "region".
> 
> 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.

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

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

 
> > Also, the "Edit->clear selection" submenu must be removed.
> 
> We'll see, this depends on the reply to the previous question.

So, it must be removed.

 
> > For the cancel command to be of any use, it must be extended with the
> > name of the action to cancel (e.g. "Cancel Search" or "Cancel
> > Customize Margins"). Actually, I think that "Interrupt" would be much
> > more meaningful.
> 
> Not sure; interrupt has another meaning during sessions to.

Ho, nice remark! Actually from a user point of view, these may be the
same action. Anyway the "interrupt session" button cannot be confused
with de "Edit->interrupt" item, since one of them is only in the menu
while the other is only in the toolbar (and does have a distinctive
tooltip).


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

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.

 
> > The item "Structure->Description" must not be hierarchic when it
> > contains only one item.
> 
> There will be more later.

But when there is only one, there is no point in making a hierarchical
menu. In this respect, the toolbar button is behaving correctly.


> > This menu should be broken in three separate menus: Structure, Math,
> > and Insert.
> 
> We do not have space for this.
> The number of top level menus has to remain reasonably small.
> Math is also ugly, because it is an abbreviation.
> Also, we cannot avoid a certain degree of context dependency
> in the menus. When switching to a radically different mode,
> like math mode, or worse, when editing a technical drawing,
> we should make an exception to the stable-menus criterion.

You are right, I was overreacting.

What I think is a bad idea is to have silent change in visible
commands when switching contexts. So having a menu whose title and
contents change depending on the context may be a good solution.

So we would have a either a Structure menu, or a Mathematics menu, or
a Biology menu, etc. which would change according to the context mode,
but the items in this menu would be stable.

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.

 
> > The submenu Insert->image should be moved to the Structure menu. Its
> > items should be made permanent. Of course the "Small Figure" and "Big
> > Figure" items should only be enable in text context.
> 
> No: the figures should be moved, not the images.

I understand your motivation. You think "figures are part of the
stylesheet so they belong in Structure, but images are primitives so
they belong in Insert".

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

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.

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

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

Since there is no concept of a page in the document structure, you
cannot do with footer definition as I propose to do with vertical
spacing and indentation flags, so proposing different solution is no
incoherence at all.

My point is that headers and footers *are* insertions because you can
cut them off. The current definition of the Document menu I gave
earlier (which itself is questionable) clearly does not include
anything which has a location in the document and can be cut'n'pasted.
So I think *you* are not being coherent.

One the other hand, what is set in all other menus from Insert to
Paragraph *can* be cut'n'pasted, so it makes perfect sense to put
headers and footers there. What can be discussed is which of these
menus is the best. I made the smallest possible decision by suggesting
to put them in Insert, but I think it could also be put in Paragraph.


> > The submenus "citation", "index entry" and "glossary entry" of the
> > "Insert->link" submenus must be moved to the "Structure" menu, since
> > they are only relevant in text context.
> 
> I am not quite sure about this. I think that semantic closeness
> with other types of links should be privileged here.
> We may just disable the entries in math-mode. It is true that the precise
> borderline of what should be in Insert and what should be in Structure is
> not yet clear to me. I gave a rough criterion, but it does not seem
> to work always.

I too am not really sure of this one...
 
> > 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?

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.

> > The submenu "Insert->executable->programming" has a too generic name,
> > "Control" (as in flow control, or execution control) would be a better name.
> 
> Same story.

I was just proposing a change of the name.

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

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.

But I think we should not do it all at the same time. Let us put a
submenu for "strong, emphasize, etc." at the moment, and when we are
done with the Structure/Mathematics menu we can come back to this
problem.


> > I strongly believe we can avoid almost all hierachical menus of more
> > than just one level of depth. However the introduction of the
> > Structure, Mathematics and Table menus may make us lack some room.
> 
> Yes, and that is why we do not want permanent Mathematics and Table menus.
> We might have a Mathematics menu in math mode though, but I am not even
> sure that we have room for this.

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.

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

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

Settings->shaw items should be toggled items in the View menu.

I think language and security are not enough for a menu of their own.
The right location to set them would be a Preferences dialog
(accessible from the Edit menu). We could follow our convention to use
hierarchic menu where we should use dialogs, but you seem not to like
this idea.

Security could be moved to the Tools menu.

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.

 
> Please let me know of your other ideas about the other menus.
> It is still time to incorporate (some of) them.
> However, they are less stable anyway.

Well... I do not see many other important changes at the moment (other
than some flattening of the menu hierarchy), but we should first
settle the current issues.

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

-- 

                             -- David --