Re: Nokia OS2008 port

  • From: "Pipeline" <nokipipe@xxxxxxx>
  • To: <emelfm2@xxxxxxxxxxxxx>
  • Date: Thu, 10 Apr 2008 20:44:01 -0400

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

Thanks, this will be helpful not only for future maemo versions but also upcoming x86 (atom) mobile linux devices which use 800x480 which will have different button mappings.

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.

I am not entirely sure which inner scrolled window you are referring to abandoning. Are you referring to the treeview itself or the content pane (holding pages)? Unfortunately i haven't been able to find where the pages (such as key bindings page) are defined to be able to determine a good place to insert any diagnostic 'hacks'.

If you would like to see screenshots of best case (fullscreen) and worst case (non-fullscreen) resolutions work i have uploaded some here :

Since you are more familiar with implications of reorganizing these regions, hopefully you will see which methods would be useful or useless with such space restrictions and/or gtk implementations. If this needs to be a maemo-hack can you advise best location to look at?

Eventually (if there were 10 of me or 1 me who was 10x smarter) it might be interesting to add stylus tap and hold (to simulate right mouse context menu with stylus) and possibly get the gimp thumnail plugin to compile for arm... and dare i dream kinetic scrolling :) Well thats probably more than i can do but things i might eventually look into adding and are things that are relevant to maemo and future Mobile Internet Devices (MIDs).

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: