Re: [Usability]Re: GNOME Panel Menu inconsistancies - breaking string/UI freeze.
- From: Havoc Pennington <hp redhat com>
- To: Jonathan Blandford <jrb redhat com>
- Cc: Calum Benson <calum benson sun com>, usability gnome org, desktop-devel-list gnome org
- Subject: Re: [Usability]Re: GNOME Panel Menu inconsistancies - breaking string/UI freeze.
- Date: 11 Mar 2002 16:40:52 -0500
Jonathan Blandford <jrb redhat com> writes:
> Havoc Pennington <hp redhat com> writes:
>
> > Calum Benson <calum benson sun com> writes:
> > > Hmm, not really sure where this would best fit in our current motley
> > > collection of dialogs-- it almost sounds like a window manager
> > > keybinding thing. I'm pretty sure not many people would think to look
> > > for it in the panel preferences dialog, though... anybody got any other
> > > ideas about where it could go?
> > >
> >
> > I believe we should have a control panel for "desktop keybindings"
> > that includes these panel bindings, the window manager bindings,
> > perhaps the key theme (or the toolkit bindings at higher-resolution
> > even).
>
> I'm not sure we'll have this for GNOME-2.0. To really do this right, we
> might need some GTK+ support. In the interim, I can put a key themes
> option in the keyboard capplet. Anyone else think this is a good idea?
>
I don't like that much. Keyboard != keybindings, other than they both
have the substring "key"; and having to clutter the capplet now and
unclutter it later is sort of not worth it.
Not having the key theme thing for 2.0 seems OK to me.
But I don't think a keybindings applet is hard if we don't
overengineer it. It's one list widget using eggcellrendererkeys, with
hardcoded knowledge of the panel and WM for now.
I would suggest moving panel, etc. to all use my same gconf
arrangement from gnome-terminal/metacity, and then the capplet can use
these generically.
The arrangement is:
- "keybindings" subdir
- contains one key for each binding
- each key can be a gtk_accelerator_name() string, or the string "disabled"
And add:
- short description in the schema is the thing to display in the list
view in the keybindings editor (my short descs aren't currently
right for this)
Then the keybindings capplet only needs to hardcode the list of
"keybindings" dirs to look at, and a human-readable name of each
dir. But the dir contents aren't hardcoded. The capplet lists each
keybindings subdir, gets the short desc for each key, and puts each
key in the list.
Should certainly start doing this, even if it doesn't end up making
GNOME 2.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]