The notorious Xffm window resizing

[Joakim Andreasson]

On 24 Mar 2003 21:58:09 -0600
edscott wilson garcia <edscott at imp.mx> wrote:

> Joakim:
> 
>   It's good to get your feedback. Let's see...
> 
> El lun, 24-03-2003 a las 20:40, Joakim Andreasson escribió:
> > Hi Edscott et al.,
> > 
> > Having recently tried out Xffm again I am sad to say the frequent
> > resizing of the window (yes even with the Paths Abreviated option
> > set) to a size considerably larger than my screen just makes it too
> > cumbersome to use for me on a day to day basis -- it just gets too
> > irritating in the long run to have to manually resize the window all
> > the time.
> > 
> > You see, even if the file names themselves are abrivated the command
> > used to open the files when double-clicked is not, which in the case
> > the command is something like "sudo mplayer -vo dga -ao oss
> > -framedrop -idx"(for movie files) the window gets insanely wide on
> > my 800x600 screen. But even with shorter commands it is irritating
> > when the window resizes. Now, I never have a problem with file names
> > being too long in the tree view, it is rather a problem having them
> > abbreviated because I cannot allways tell them apart. The problem
> > occurs only with them being printed in the status line.
> > 
> > So I would most humbly (sp?) ask, could there be an option to
> > disable the status line alltogether? This way those who like the
> > current resizing behaviour wouldn't be bothered. Otherwise, could
> > the commands used to open files be abbreviated too (but there still
> > are other rather long-winded things being printed in the status
> > line, so...)? And could the "Paths abbreviated" options be made to
> > only apply to what's being written in the status line? Dragging the
> > column titles in the Treeview abbreviates much more flexibly there.
> 
> As you noted, not only paths cause this unwanted growth. Trying to
> solve each individual case does not work very well. The best,
> simplest, and quickest solution would be to tell gtk2 *not* to resize
> the whole window when the text does not fit into the status line.
> Maybe by truncating any text sent to the status line to a certain
> width. That's an easy fix. The difficult part is to determine how many
> characters are acceptable for a status line.  
> Any opinions on status line length?

Well on my screen, that would be ~48 characters, but I guess that people
running with a maximized window on a 1600x1248 screen wouldn't agree.
Maybe an approximation based on window geometry would work? On the other
hand, I've seen gtk apps that prints stuff to the status line which just
dissapears if beyond a certain length (sylpheed is such an app), maybe
they use an useful routine?

(Ok, so I just checked xftree and it works the same, ie. what gets
printed in the statusline does not alter the window geometry. Is the
method used there incompatible with gtk2?)

Then there still is the problem when opening a dialog for frex deleting
a file with a long name, couldn't the name be line-wrapped in such a
case?

> The option to disable the status line should also happen, but not on
> the first release. On the first release the status line has to work
> properly(no unwanted resizing).

What is the "Long status line"-option supposed to do?

> 
> > 
> > There also seem to be a few bugs in the mcs plugin for Xffm, since
> > if I try to set some options from there does other things than
> > intended. Frex, trying to get Xffm to display the navigation toolbar
> > from there only disables the menubar.
> 
> Hmmm. Unfortunately you are right. It must be fixed before rc1.

There is also a problem if you try to right click a file when you've
descended into a few directories from $HOME: the directory tree gets
collapsed and the file unselected. To avoid this you have to right click
some file in $HOME visible without scrolling before doing anything else.

> 
> thanks for the feedback,

You're welcome =)

Regards,
Joakim