- From: Michael Meeks <michael ximian com>
- To: Havoc Pennington <hp redhat com>
- Cc: Alan <alan ufies org>, Gediminas Paulauskas <menesis delfi lt>, Mark McLoughlin <mark skynet ie>, desktop-devel-list gnome org
- Subject: Re: gnome-multi-term
- Date: 11 Feb 2002 11:03:11 +0000
On Fri, 2002-02-08 at 16:41, Havoc Pennington wrote:
> > Of course, it would be really nice to write this once for the
> > BonoboUIHandler, and serialize the result as an XML <keybinding>
> > section, but ...
> They aren't menu accelerators, they're things like Alt+1 to switch
Sure - and the UI handler keybindings section deals with keybindings
such as you describe, not menu accelerators particularly.
> I think keybindings are nicest in gconf as:
> keybindings/tab_out_of_terminal "<Ctrl>Tab"
> keybindings/switch_to_tab_1 "<Alt>1"
> rather than:
> keybindings/all_keybindings "<big-ass XML string>"
> etc. - since this is sane in gconf-editor.
Whatever - I don't much care how it is stored; it would be nice if it
was compatible though; if this is what you want then it'd be best (IMHO)
or whatever, so that the UI handler can grab that directory and turn
the key/values into a keybindings mapping trivially. Alternatively a
list of string pairs might do it nicely.
> I plan to have a global toggle that makes Alt+f for file menu, Ctrl+v
> to paste, etc. pass to GTK vs. go to the terminal. I don't have any
> better ideas for handling those. However I'm not sure how I'm going
> to implement making them pass to GTK... it may involve some rather
> questionable hacks.
> I hope there's no working against going on. I don't consider trying
> multiple approaches at once to be a bad thing or against anyone.
They are a waste of effort - surely, merging projects is better than
forking them in terms of wasting effort.
> I would encourage anyone to fix gnome-terminal. And I would encourage
> people who start full rewrites not to commit the initial broken state
> into CVS as the default implementation.
People knowing there is a re-write going on by a prominent contributor
means that testing and development resources stultify, until the FUD has
been cleared . Hence I believe having a single terminal project is
most likely to result in people actually working on it instead of
sitting on their hands.
> If "eclectic maintainership" means "we have no idea who maintains this
> thing" I would prefer to avoid it - I would like to review all
> profterm changes because I understand that code as a whole. I don't
> want people to just commit stuff.
Sure - patches should be reviewed, I merely have some concerns ( as I
have outlined before ) that the terminal should be nicely integrated
with the platform, re-use existing code, and support whatever features
are introduced there. My worries are subservient to having a working
> Maybe I should put that more strongly - if I have to agree to random
> people changing the terminal in arbitrary ways
Nobody is asking for that.
 - is anyone running / testing / fixing Sawfish ?
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
] [Thread Prev