Re: Nokia OS2008 port
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Mon, 7 Apr 2008 17:32:36 +1000
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:
