Menubar on text only terminals

Menubar on text only terminals

[Nick Roberts]

I can make a menu item work like a toolbar icon on a text only terminal with
the following:

(define-key global-map [menu-bar compile] `(,(propertize "[compile]" 'face 'bold) . compile))

I've used a bold face (blue background with my setup) to try to emphasize the
button.  Unfortunately the space after the item name displays with the same
face.  Is it possible to prevent this?

This probably isn't for the release, but I think toolbar functionality maps
better onto text only terminals than the menubar because there are no pull
down menus to worry about.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Menubar on text only terminals

[Richard Stallman]

    I can make a menu item work like a toolbar icon on a text only terminal with
    the following:

I don't entirely understand what that means.

    This probably isn't for the release, but I think toolbar functionality maps
    better onto text only terminals than the menubar because there are no pull
    down menus to worry about.

I am really lost there.

Re: Menubar on text only terminals

[Nick Roberts]

 >     I can make a menu item work like a toolbar icon on a text only terminal
 >     with the following:
 > 
 > I don't entirely understand what that means.

One mouse click on a menu item is sufficient to perform the underlying function
(before my change on 2007-03-30 a mouse click popped up a completions list).
This is just how the toolbar functions.

 >     This probably isn't for the release, but I think toolbar functionality
 >     maps better onto text only terminals than the menubar because there are
 >     no pull down menus to worry about.
 > 
 > I am really lost there.

With tmm, sub-menus have to be navigated through completions lists, which some
find inconvenient.  Toolbars don't have that extra complexity.  I'm just
trying to say that toolbars and text terminals (with use of the mouse) are a
more natural fit.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Menubar on text only terminals

[Giorgos Keramidas]

On 2007-04-01 09:36, Nick Roberts <nickrob@snap.net.nz> wrote:
>>     This probably isn't for the release, but I think toolbar
>>     functionality maps better onto text only terminals than
>>     the menubar because there are no pull down menus to worry
>>     about.
>> 
>> I am really lost there.
> 
> With tmm, sub-menus have to be navigated through completions
> lists, which some find inconvenient.  Toolbars don't have that
> extra complexity.  I'm just trying to say that toolbars and
> text terminals (with use of the mouse) are a more natural fit.

That's kind of debatable.  Programs like the text-mode elinks web
browser work quite nicely with a text mode menubar.  The menu bar
of Emacs works in a different way than the elinks menu bar, but I
don't see why this makes it less useful than the toolbar.

Re: Menubar on text only terminals

[Nick Roberts]

 > > With tmm, sub-menus have to be navigated through completions
 > > lists, which some find inconvenient.  Toolbars don't have that
 > > extra complexity.  I'm just trying to say that toolbars and
 > > text terminals (with use of the mouse) are a more natural fit.
 > 
 > That's kind of debatable.  Programs like the text-mode elinks web
 > browser work quite nicely with a text mode menubar.  The menu bar
 > of Emacs works in a different way than the elinks menu bar, but I
 > don't see why this makes it less useful than the toolbar.

Maybe for the reason I just gave?

I'm not familiar with Elinks but if it works as well as you say, perhaps, ATR
it would a good idea to redesign Emacs text mode menubar along the same lines.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Menubar on text only terminals

[Giorgos Keramidas]

On 2007-04-02 16:56, Nick Roberts <nickrob@snap.net.nz> wrote:
>>> With tmm, sub-menus have to be navigated through completions
>>> lists, which some find inconvenient.  Toolbars don't have
>>> that extra complexity.  I'm just trying to say that toolbars
>>> and text terminals (with use of the mouse) are a more natural
>>> fit.
>> 
>> That's kind of debatable.  Programs like the text-mode elinks
>> web browser work quite nicely with a text mode menubar.  The
>> menu bar of Emacs works in a different way than the elinks
>> menu bar, but I don't see why this makes it less useful than
>> the toolbar.
> 
> Maybe for the reason I just gave?

That's where the 'debatable' part fits.  Some users may find it
more useful to use completions to access the menu, rather than
try to hit a particular menu entry with a mouse pointer.  Others
may, obviously, disagree.

> I'm not familiar with Elinks but if it works as well as you
> say, perhaps, ATR it would a good idea to redesign Emacs text
> mode menubar along the same lines.

This is a good idea, IMHO.

Maybe we can aim for making something like this available for
Emacs 23, and make it also possible to switch between two 'modes'
for accessing the menu.  The current completion-based mode, and
something that resembles elinks :)

Re: Menubar on text only terminals

[David Kastrup]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On 2007-04-02 16:56, Nick Roberts <nickrob@snap.net.nz> wrote:
>>>> With tmm, sub-menus have to be navigated through completions
>>>> lists, which some find inconvenient.  Toolbars don't have
>>>> that extra complexity.  I'm just trying to say that toolbars
>>>> and text terminals (with use of the mouse) are a more natural
>>>> fit.
>>> 
>>> That's kind of debatable.  Programs like the text-mode elinks
>>> web browser work quite nicely with a text mode menubar.  The
>>> menu bar of Emacs works in a different way than the elinks
>>> menu bar, but I don't see why this makes it less useful than
>>> the toolbar.
>> 
>> Maybe for the reason I just gave?
>
> That's where the 'debatable' part fits.  Some users may find it
> more useful to use completions to access the menu, rather than
> try to hit a particular menu entry with a mouse pointer.  Others
> may, obviously, disagree.
>
>> I'm not familiar with Elinks but if it works as well as you
>> say, perhaps, ATR it would a good idea to redesign Emacs text
>> mode menubar along the same lines.
>
> This is a good idea, IMHO.
>
> Maybe we can aim for making something like this available for
> Emacs 23, and make it also possible to switch between two 'modes'
> for accessing the menu.  The current completion-based mode, and
> something that resembles elinks :)

tmm is not really helpful in most cases since it requires refocusing
one's attention all the time.  It is possible that it may work better
with screen readers and/or Emacspeak, but I doubt it.  I think I
remember someone blind actually being using X11 since the screen
readers get along with it reasonably well.

I think that the MSDOS port has a more traditional text menu (which
closely resembles the graphical menus by appearing in-place).

It would probably be better to port that functionality to text
terminals in general before thinking about what to do with toolbars: I
don't think that many people consider tmm a good idea.  And it
certainly is a good hint that for MSDOS, one of the few console-only
parts, someone went to the pain to implement something else.

-- 
David Kastrup

Re: Menubar on text only terminals

[Giorgos Keramidas]

On 2007-04-02 09:25, David Kastrup <dak@gnu.org> wrote:
>Giorgos Keramidas <keramida@ceid.upatras.gr> writes:
>>> I'm not familiar with Elinks but if it works as well as you
>>> say, perhaps, ATR it would a good idea to redesign Emacs text
>>> mode menubar along the same lines.
>>
>> This is a good idea, IMHO.
>>
>> Maybe we can aim for making something like this available for
>> Emacs 23, and make it also possible to switch between two 'modes'
>> for accessing the menu.  The current completion-based mode, and
>> something that resembles elinks :)
> 
> tmm is not really helpful in most cases since it requires refocusing
> one's attention all the time.  It is possible that it may work better
> with screen readers and/or Emacspeak, but I doubt it.  I think I
> remember someone blind actually being using X11 since the screen
> readers get along with it reasonably well.
> 
> I think that the MSDOS port has a more traditional text menu (which
> closely resembles the graphical menus by appearing in-place).
> 
> It would probably be better to port that functionality to text
> terminals in general before thinking about what to do with toolbars: I
> don't think that many people consider tmm a good idea.  And it
> certainly is a good hint that for MSDOS, one of the few console-only
> parts, someone went to the pain to implement something else.

Right.  This 'in place' appearance of menu entries is what elinks does,
and what I was referring to above :)

Re: Menubar on text only terminals

[David Kastrup]

Giorgos Keramidas <keramida@ceid.upatras.gr> writes:

> On 2007-04-02 09:25, David Kastrup <dak@gnu.org> wrote:
>
>> I think that the MSDOS port has a more traditional text menu (which
>> closely resembles the graphical menus by appearing in-place).
>> 
>> It would probably be better to port that functionality to text
>> terminals in general before thinking about what to do with
>> toolbars: I don't think that many people consider tmm a good idea.
>> And it certainly is a good hint that for MSDOS, one of the few
>> console-only parts, someone went to the pain to implement something
>> else.
>
> Right.  This 'in place' appearance of menu entries is what elinks
> does, and what I was referring to above :)

My fault for not reading carefully: I thought this was still about
toolbars.  Hm, looking at the subject line, it might have never been
about toolbars in the first place.

-- 
David Kastrup

Re: Menubar on text only terminals

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Mon, 02 Apr 2007 09:25:15 +0200
> Cc: Nick Roberts <nickrob@snap.net.nz>, rms@gnu.org, emacs-devel@gnu.org
> 
> I think that the MSDOS port has a more traditional text menu (which
> closely resembles the graphical menus by appearing in-place).
> 
> It would probably be better to port that functionality to text
> terminals in general before thinking about what to do with toolbars: I
> don't think that many people consider tmm a good idea.  And it
> certainly is a good hint that for MSDOS, one of the few console-only
> parts, someone went to the pain to implement something else.

Indeed.  I suggested long ago to retrofit the MSDOS code into a Posix
text terminal.  This should be almost trivial: all we need is to
replace direct screen writes with terminfo commands and stdio output.
All the rest can be kept almost verbatim.  The relevant functions are
XMenuCreate, XMenuAddPane, XMenuAddSelection, XMenuLocate,
XMenuActivate, and XMenuDestroy (and their few subroutines), all found
on src/msdos.c.  Of these, XMenuActivate is the only one that is
complicated; all the rest are really trivial.

Re: Menubar on text only terminals

[Nick Roberts]

 > Indeed.  I suggested long ago to retrofit the MSDOS code into a Posix
 > text terminal.  This should be almost trivial: all we need is to
 > replace direct screen writes with terminfo commands and stdio output.
 > All the rest can be kept almost verbatim.  The relevant functions are
 > XMenuCreate, XMenuAddPane, XMenuAddSelection, XMenuLocate,
 > XMenuActivate, and XMenuDestroy (and their few subroutines), all found
 > on src/msdos.c.  Of these, XMenuActivate is the only one that is
 > complicated; all the rest are really trivial.

I'm surprised that it is so easy given that tmm.el isn't a simple piece of
code.  What happens with toggle and radio buttons?  Are they also handled?

If someone writes some code, I'll be happy to test it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Menubar on text only terminals

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > Indeed.  I suggested long ago to retrofit the MSDOS code into a
>  > Posix text terminal.  This should be almost trivial: all we need
>  > is to replace direct screen writes with terminfo commands and
>  > stdio output.  All the rest can be kept almost verbatim.  The
>  > relevant functions are XMenuCreate, XMenuAddPane,
>  > XMenuAddSelection, XMenuLocate, XMenuActivate, and XMenuDestroy
>  > (and their few subroutines), all found on src/msdos.c.  Of these,
>  > XMenuActivate is the only one that is complicated; all the rest
>  > are really trivial.
>
> I'm surprised that it is so easy given that tmm.el isn't a simple
> piece of code.

Eli did not say that the MSDOS code was a simple piece of code.  He
just said that it should be easy to retrofit into other terminals.

> What happens with toggle and radio buttons?  Are they also handled?

My guess would be yes (how else would the port be functional?), but
Eli will be better equipped to answer that.

-- 
David Kastrup

Re: Menubar on text only terminals

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Tue, 3 Apr 2007 11:28:32 +1200
> Cc: David Kastrup <dak@gnu.org>, keramida@ceid.upatras.gr,
> 	emacs-devel@gnu.org
> 
> I'm surprised that it is so easy given that tmm.el isn't a simple piece of
> code.

tmm tries to do a very different job; msdos.c just emulates the few
relevant Xlib functions.

> What happens with toggle and radio buttons?  Are they also handled?

Yes, they are supported, but it's not msdos.c that does it, it's
xmenu.c.  Look in single_menu_item there, around line 635, and you
will see that it shows "[X]" for toggles and "(*)" for radio buttons.

IOW, what we have for the non-toolkit build on X already does a large
part of the job, so that only the actual display of the menus is
missing.  And that is where we can lift most of the code from msdos.c,
as I wrote earlier.  The only _real_ problem with that is that msdos.c
gets mouse events via system calls in plain C, whereas text terminals
use Lisp code in t-mouse.el or some such, and it might be tricky to
call Lisp during menu display.

> If someone writes some code, I'll be happy to test it.

If I had time to write the code, I'd do it a long time ago.  But
thanks for volunteering, maybe someone else will step forward for the
coding job (after the release, of course).