Re: gnome-multi-term

Hi Havoc,

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

	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)
to do:

/app/wherever/keybindings/VerbName	"<Control>Enter"

	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 [1]. 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
terminal though.

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



[1] - is anyone running / testing / fixing Sawfish ?

 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]