Randy Chung aoshi at OCF.Berkeley.EDU
Fri Aug 20 09:45:13 CEST 2004

My repsonses to a few of your points below...

Brian J. Tarricone wrote:
> 2) it would probably make sense to have a "close tab" option in the file 
> menu.  yes, i know, quitting the shell in a tab will close it too.  but 
> for completeness' sake...

This is trivial to implement.  I'll have a patch rolling around shortly.

> 3) resizing.  you should be able to make the window smaller than its 
> initial size.  also, it should set size increment hints so the window 
> manager will constrain the window size to increments of the column 
> widths/row heights.

While it'd be nifty to be able to do this so the window is resized in 
character multiples, I lean more towards the OCD side and like it when 
my windows are arranged in a way such that they all snap together and 
meet at screen borders nicely.  This comes with the unfortunate caveat 
that sometimes window size isn't exactly at a character multiple.  Maybe 
this should go into a preferences menu.

> 4) adding tabs shouldn't resize the window.  in fact, nothing should 
> ever automatically resize the window except a font size change.

This is a bit trickier to deal with, since (from my cursory glances at 
the GTK API) there isn't a way you can do this.  You can disable window 
resizing entirely for the user, but there aren't any real ways to 
maintain window size when you add a tab that has a name bigger than the 
window.  What I have now is a patch that'll simply add the new tab to a 
scrollbar, so if you're about to overflow it'll just scroll some tabs 
off so it fits into the current window size; I don't recall if I sent 
the patch in earlier or not, so let me know if I didn't and I'll send it in.

> 5) a scrollbar would be nice ^_^.

Also trivial to do.  Will have a patch shortly.

> 6) options options options....   size of scrollback buffer, run as login 
> shell, color options (i like a black BG, but the grey FG isn't bright 
> enough for me), ability to hide the menubar...

This will take longer, simply due to the raw amount of typing :)

> 7) menu accelerators.  i know why you disabled them (that is, alt+f for 
> File menu, etc.), but it would be nice to be able to have some kind of 
> keyboard way to get to the menus (without having to remember the 
> shortcuts for each item).  i wonder if you can change the mnemonic 
> behavior on a per-widget-basis so you could do alt+shift+f for the file 
> menu...  hmm, actually, this sounds doable, if you set up a separate 
> accel object.  maybe.  something to think about for later, anyway.

Actually, I could put together a generic accel key rebinder for all the 
accel keys so you could go nuts and change them to your heart's content. 
  You could set Ctrl+U for a new tab, if you want to piss off the 
bash/zsh users on your system.

> that's all i can think of for now.  this is a great start - something 
> nicely in between xterm and gnome-terminal.  prettier than xterm, but 
> not as slow to start as gnome-terminal.  and supporting AA fonts, unlike 
> eterm...
>    -brian

I actually have some beef with AA fonts, because they take a bit more 
time to load on my machine and sometimes I just want a snappy terminal 
to pop up real quick so I can do quick and dirty admin tasks with them, 
but that's something for me to hammer out on my own later :)



More information about the Xfce4-dev mailing list