Re: menu/toolbar/key customization API (was Re: Unidentified subject!)

[Tom Tromey <tromey cygnus com>]

Oskar> * Believe it or not, in Word 97 you can create new toolbars or
Oskar> choose from a set of 13 default. Menus are considered toolbars,
Oskar> and they can both be modified with drag and drop. All keyboard
Oskar> accelerators are also configurable.

This is cool, and definitely where we should be aiming.

Oskar> At least two new object classes need to be implemented, Command
Oskar> Manager and Automatic User Interface classes. All function
Oskar> names and parameters are preliminary and need better names.

At least names should start `gnome_'.

Oskar>   I think speed matters, that's why commands may be referenced
Oskar>   by either name or uint32 id. (Should the command manager by
Oskar>   implemented with one signal for each command? Or one signal
Oskar>   for all commands? Or no signals at all - like it is now?)

I don't really know enough about the Gtk signal system to answer this
definitively.

However, it seems to me that if you had just one signal for all
commands, then you'd have to run a large number of functions for every
command dispatch.  So I think this is ruled out.

Using signals is probably a good thing, though.  Signals have some
nice features beyond what simple callbacks provide.

Oskar>   cmdman_call_command(cmdman, name, ...)
Oskar>   cmdman_call_command_by_id(cmdman, id, ...)
Oskar>   cmdman_callv_command(cmdman, name, argc, argv)
Oskar>   cmdman_callv_command_by_id(cmdman, id, argc, argv)
Oskar>     Calls the function bound to command 'name' or 'id'. fixme: command
Oskar>     return codes, return codes if 'name' doesn't exist?

What are the arguments here?  And how are they specified?

Maybe it's better to view a command the same way we view menu
callbacks right now: just a function and a piece of user data.

Oskar>   cmdman_global_callback(cmdman, callback)
Oskar>     The global callback is a function which will called instead
Oskar>     of the function bound to a command. (To improve
Oskar>     performance.) If callback==NULL remove the global
Oskar>     callback. (fixme: will this function be necessary at all?)

Do you have an example of how this would be used?

Oskar>   cmdman_add_command(cmdman, name, id, callback, [long_name, help_string,
Oskar>      icon_pixmap])
Oskar>     Register a command by name and id. fixme: The extra options
Oskar>     are used for help in the customization dialog. icon_pixmap
Oskar>     could be used as the default toolbar/menu image.

This is fine but I don't see how you can easily implement extra
arguments.  You'll need multiple functions.

Note that any property of a command must be changeable and viewable at
runtime (IMHO).  So you'll need functions to get and set each of these
properties.

Also, you'll need a way to disable a command (which should have the
effect of disabling the corresponding toolbar or menu entry).

I wonder if you want to support checkbutton/radiobutton items somehow.
For menus the implementation is obvious.  For toolbars there are
various potential renderings (e.g., radiobuttons could be represented
as comboboxes, or as "sunken icons").

The callback argument should be eliminated in favor of using signals.
(If not, then this code needs more additions: user data and a delete
function.  See the instructions on writing wrapper-friendly code that
were recently announced.)

I think the id should be assigned by the command manager, not chosen
by the user.  I don't see any value in letting the user specify the
values, but I do see potential problems there.  You can easily have
cmdman_add_command return the id value.

Oskar> Automatic User Interface, "autoui" (derrived from GtkObject)

I think that this must interface with the gnome-app code somehow.  For
instance, you might consider giving each gnome-app object its own AUI,
Command Manager object, or (probably) both.

This might have some effect on the API you design.  I dunno.

Oskar>   autoui_parse_config(autoui, lines)
Oskar>   autoui_parse_subconfig(autoui, object_name, lines)
Oskar>     Parses and installs configuration from a string. The *_subconfig
Oskar>     function parses configuration and installs it for the menu, toolbar,
Oskar>     or keyset specified by object_name (fixme: remove?).

Oskar>   autoui_load_default_config(autoui)
Oskar>   autoui_load_config(autoui, file)
Oskar>   autoui_load_config_fd(autoui, fd)
Oskar>     Loads and parses default or separate configuration, from
Oskar>     either a named file or file descriptor. These functions use
Oskar>     autoui_parse_config to parse what has been read.

I'm not totally sure that these are necessary.  Wouldn't it be better
to layer the config info on top of gnome-config somehow?  Preferably
in such a way that naive applications don't have to do anything
special -- the config key to use can be computed from preexisting
global information, the same way that the menubar and toolbar know how
to save themselves right now.

Oskar>   container = autoui_menutoolbar_dialog_make([defaultmenu])
Oskar>   container = autoui_keyset_dialog_make([defaultmenu])
Oskar>     Creates a Gtk container/box that contains necessary widgets
Oskar>     for creating, removing and modifying menus. (fixme lazy:
Oskar>     How to handle OK/Apply/Cancel stuff?)

I don't understand the question here.


I don't know enough about Gtk accelerator handling to comment
intelligently on the key binding stuff.

I think the key binding code ought to support multi-key bindings.  I
really, really want to be able to use my Emacs bindings everywhere :-)


Overall your proposal looks nice.  Looking forward to the code.

It would probably be worthwhile to pick an application as a testbed,
much the same way that gnome-mdi was first tried on ghex.

Tom