Re: Nokia OS2008 port

On Mon, 7 Apr 2008 23:26:23 -0400
"Pipeline" <nokipipe@xxxxxxx> wrote:

> Certainly.  I do realize that true fullscreen (no title bar; no 
> minimize/maximize/etc buttons) is not particularly useful to desktop users 
> though.   That is why i expected this to be maemo specific hack.  I should 
> also add that even if emelfm2 caches the maximized size on exit, when 
> emelfm2 is next launched (on maemo) you can 'attempt' to set it to any 
> resolution you want... maemo will force it to fit into client area so this 
> is not a concern for me and would not affect current behavior.

In the absence of anything to 'force' a resize, such as you describe, logging 
full-screen size for next session is a bit unpleasant to recover from.

svn code now has an action named 'toggle.fullscreen', by default it will be 
bound to <Shift>F12 but not to any button.

> > Well, treeviews are as wide as they need to be, having regard to the 
> > content, and column-titles, and any change of column-width by the user or 
> > code. Gtk apparently defaults to auto-sizing of columns, and e2 doesn't 
> > intervene, in config dialogs, anyway.
> > I must say that dual horizontal scrollbars (one for treeview, the other 
> > for related buttons) are unpleasant, I guess that those 2 bars are what 
> > you mean by "scrolling within scrolling". I've never been affected enough 
> > to bother about a more glamorous way of dealing with the situation.
> 
> Yes i meant that the (inner) treeview scrollbars are not always visible 
> within the content pane and when they are visible i see only part of them 
> since they are so wide/tall... so i have to scroll content page to find 
> scroll bar and then scroll treeview which is partially obscured.   Removing 
> one dimension would help alot so i would think if the treeview height could 
> be enforced (via hack?) to maintain a treeview of around 360px or 8 rows 
> then i can mostly use just two scrollbars when dealing with the treeview... 
> any suggestions on how to force this?  Forcing horizontal has more 
> implications with alignments and honestly with 800 pixels i can resize the 
> width of content pane to fit most of the width (minus space used by both 
> vertical scrollbars).  If you are interested, and prefer more elegant 
> solution, let me know... otherwise i will pursue maemo-hack approach.

I suspect that the most useful solution (though quite a bit messy to implement) 
is to abandon the 'inner' scrolled window, leaving just a single horizontal 
bar, always visible, related to the width of treeview or the upper row of 
buttons, whichever is greater. Then, to avoid having to scroll horizontally to 
get to those buttons, there would need to be an overflow-menu arrangement like 
the default for filelist toolbars. There may be different opinions about 
including the upper row of button inside vertical scrolling, or not, depending 
on ease of accessing the buttons vs seeing more treeview.

Regards
Tom


-- 
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: