Re: Nokia OS2008 port

On Sun, 6 Apr 2008 10:56:47 -0400
"Pipeline" <nokipipe@xxxxxxx> wrote:

> Thanks, i found a good (enough) place to intercept these keypresses and 
> implemented fullscreen for main window, file viewer, and file editor.  I 
> mostly just tapped into _e2_keybinding_key_press_cb and handle GDK_F6 along 
> with module level toggle variable to call gtk_window_(un)fullscreen.   Maemo 
> forces apps to be maximized to entire client area and its their convention 
> that apps handle F6 fullscreen on their own (which it now does).
Well, if that's enough, go with it.

Normally, I'd create a new action, say 'window.fullscreen', and allow any key 
(in your case, F6) or any other UI operation to be bound to it.

Really, we should notice when a window is maximised, and don't cache the 
maximised size, so that the next-session behaviour conforms to the way it works 
when the window is minimised. Such change also supports bullet-proof toggling 
of full-screen window. Then it's no big deal to add an action such as 
described. I'll put these things into TODO for next release.


> In the configuration dialog there are pages with treeviews like bookmarks, 
> aliases, keymappings, filetypes, etc. Pages with those treeviews dont fit 
> and this requires complicated scrolling within scrolling that doesnt work 
> well at all for maemo.  Can each page be made aware of its width (or even 
> screen width minus a little for options bar)?  If not do you know of a good 
> way i can hack these treeview to set size to something like 500width (like 
> filetypes tree for example).

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.

Thinking out loud ... if the treeview is narrower than the buttons, we don't 
care ? If it's wider than the buttons, and it's possible to make column(s) 
narrower, then do so until the width matches the buttons width ? If there's 
discretion, which column(s) ? This could get fairly complicated ...

> The context menu does not always display correctly.  Since the total 
> resolution is 800x480 (even less is usable when not fullscreen), the default 
> positioning of the menu wont fit so i guess maemo relocates it.

Gtk is supposed to "push in" a menu, such that it's all visible as close as 
possible to the intended position.

  This would 
> be fine except when the menu is populated it starts populating in middle of 
> menu, leaving empty space at top and requiring scrolling to get to lower 
> menu items that could have fit.

It seems to me that this is inside maemo. Vanilla gtk has no API for scrolling 
menus, and I don't know how a maemo menu gets to have such  capabilities, or 
about the algorithm for populating a scrolled menu. From past dealings with 
re-positioning of filelist vertical adjustment, I recall it can be a bit tricky 
to get a view filled "properly".

BTW, I peeked at your website, and have a small suggestion. There's mention of 
a button for "sort by". Unless you've added some capability, and this button is 
not doing its default thing, then it would be better somehow described as 
related to limiting/filtering of displayed items. There's no sorting involved.

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: