Re: [Texmacs-dev] Reorganization of the menus

[David Allouche]

On Tue, Jul 30, 2002 at 01:23:40PM +0200, Joris van der Hoeven wrote:
> 
> No, but I have the right to make the application please me
> as much as possible. I hate abusive capitalization in titles,
> whether they occur in GUI's or in scientific papers.
> There are people who share my opinion and there are others who don't.
> So there is no "right thing" here. You claimed proposing
> the right thing; I never did: I just say what I like most.

Ok, so we will only "phrase" capitalization. Just be aware that I
think that is wrong (but less so than the current all-lowercase
style).


> > 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".
> 
> I'm not sure; in all web browsers I know of the similar functionality
> is called Reload.

Actually the use cases are completely different:

"Revert" means "discard the changes I have done since I last saved or
last opened the document".

"Reload" means "update the page with the changes which have been done
(by someone else) on that page since the last load".

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.


> > 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.
> 
> Yes, but sometimes these rationales really exist.
> I agree that dialogue boxes are fine for certain operations,
> but using the footer has one big advantage:
> it does not screw up the screen. The main disadavantage
> is that you do not have a global view of what you are doing
> in the case when you have to enter several things with
> possible optional arguments. It therefore seems that
> the footer is well-suited for very simple operations,
> when you know precisely what you are doing.
> For complex operations or in the case of non expert users,
> dialogue boxes are better.

I agree.


> > But it does make some kind of sense if there is a meaningful system
> > paper size. Is it really the case on GNU/Linux?
> 
> Think of the following situation: I am writing a joint paper
> with someone in the US. He sends me the paper with the "letter"
> paper size. I attempt to print it out. What should happen?
> It should be possible for a document to have a different
> page size as the default printer settings. If I attempt to
> print such a document, I guess that a dialogue box
> should popup (or a question in the footer).

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?

If it is so, it makes sense to distinguish the page size settings of
the documents and of the system.

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


> 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 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.
> 
> I once had a use for it, but for simplicity we might leave it out.

Okay.


> > > 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.
> 
> This is not urgent. We can leave things as they are now and
> do this when you have time.

I concur.


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

 
> >   "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.
> 
> Also notice that we may keep the option to set the default behaviour
> in the preferences.

And make it an application-wide setting?  Agreed!

By the way, verbatim export is still really broken.


> > I still think the current commands are fine. The only issues I see are
> > with their naming and their location in the menu hierarchy.
> 
> My concern is to keep the Edit menu reasonably short.

Okay.


> > > 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?
> 
> I use C-c for this. But it is true that this is not very clear.
> I also wanted a simple keystroke for "Clear". Maybe we should
> make C-g do a Cancel in your sense and C-z a real clear.
> What is commonly used for Clear as a keyboard shortcut?

In the Macintosh convention (what you call M$ style, but that is just
abusive since that was Apple who just first popularized that kind of
GUI behaviour), no shortcut is associated to clear, since the
behaviour is "erase selection on type". (More on that further).

I do not know what is the X11 convention, if there is such a thing. In
GNU Emacs I know of no shortcut for clear, if you want to do that on
keyboard, it seems that the action your are supposed to take is "Cut".


> Also, what about putting "Cancel" just after "Undo" and "Redo"
> at the top of the "Edit" menu?

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.

Putting it near "Undo" will introduce confusion, unless it is renamed
in a less ambiguous way, like "Interrupt", meaning "interrupt current
interactive minibuffer input".


> > 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.
> 
> Strange; please put this on the bug list...

Done.

 
> > > > 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.
> 
> You are right that this is another possible interpretation
> (more M$ than Unix style); this should be called "Replace selection".

Your are right in the abstract.

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.


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


> > 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.
> 
> Right; I prefer the X11 semantics. Explicitly copying just
> additionally clears the active selection. There is another difference:
> in M$ application, selections are naturally overwritten when
> you start typing. I think that this is *very bad*.
> We already discussed this before on the texmacs-users list.

Yes *you* did. But you still do not understand what it is really about.

In the Macintosh style, the selection is very transient. Any mouse
action (but select-dragging, shift-clicking and maybe drag-moving)
cause it to disappear. So do any action from, say, the Insert or
Structure menus, and without overwriting the selection with the
inserted element. Additionally, in this convention, you cannot easily
detach the selection from the caret (we can make this happen for the
sake of keybord based move, but then we have a kind of "weak"
selection).

So having pasting or typing erase the selection is not that bad
because the selection is very unstable, and easy to disable, and it
does provide some useful usage patterns. And anyway, it is the
expected behaviour.


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

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.

Anyway, an image has no semantic meaning as far as TeXmacs is
concerned.


> > So you agree that page insertions should go in the Structure menu?
> 
> 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?


> > > > > > 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!
> 
> OK, lets put it in Insert.

Thanks.

 
> > > 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.
> 
> Yes, Format should only insert with-like structure.

As you like to say: "we'll see".


> I think that an extra menu in preamble mode is acceptable,
> because only expert users will really need it.

That makes sense. But then we can think of removing all commands wich
insert trivial non-primitive elements in Preamble mode.

 
> > > 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?
> 
> Yes! You will need to buy a larger screen!

I was just saying that the policy you are proposing cannot avoid
cluttering the menubar.

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.


> > > > Settings->printer items should be in "Files->Page Setup..."
> > > 
> > > I don't like your "Files->Page setup" menu.
> > 
> > I'll be back.
> 
> I do not like "Page setup", but we might want "Printer settings",
> like this is the case in some other word processors.

Which ones?

-- 

                             -- David --