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.