Re: Nokia OS2008 port
- From: "Pipeline" <nokipipe@xxxxxxx>
- To: <emelfm2@xxxxxxxxxxxxx>
- Date: Mon, 7 Apr 2008 23:26:23 -0400
Thanks for your inputs, i will address comments below :
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.
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.
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.
The context menu does not always display correctly.
Gtk is supposed to "push in" a menu, such that it's all visible as close
as possible to the intended position.
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".
I'm sure you are right. I am currently forcing the top of menu as high as
possible so it only mildly affects program use... perhaps future OS upgrade
will resolve this.
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.
Thanks, i will update that screenshot since i did not change the behavior of
that button... in fact all icons behave identically to what you intended
now.
In case your interested, the program has pretty good 'feel' on this consumer
electronics device. There are three hardware buttons on top of device,
fullscreen, zoom in, and zoom out and i have mapped zoomin/zoomout to left
pane and right pane. There is dpad which simulates arrow keys and
dpad-enter for enter and another menu button i have mapped to context menu.
This is common to both n800/n810 (which has additional keyboard). So with
one hand one can essentially navigate the filesystem and perform certain
simple operations without stylus. Its also much smoother/faster than the
swf demo appears (if you saw it).
And finally (just because i would want to know if i were you) I have
upgraded to your 0.4 source release and since releasing new version in last
2 days 150 unique users have downloaded the upgrade. The previous build i
did (of your last 0.3.6 release) had total 1354 downloads over a month (my
estimate of 500 assumes reinstalls and reflashing os, i really have no idea
how many devices that equates to). There are however 15,700 registered
users on internettablettalk.com though so this could grow alot and/or
actually lean more towards the 1k mark.
--
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.
- Follow-Ups:
- Re: Nokia OS2008 port
- From: tpgww
- References:
- Nokia OS2008 port
- From: Pipeline
- Re: Nokia OS2008 port
- From: tpgww
- Re: Nokia OS2008 port
- From: Pipeline
- Re: Nokia OS2008 port
- From: tpgww
Other related posts:
- » Nokia OS2008 port
- » Re: Nokia OS2008 port
- » Re: Nokia OS2008 port
- » Re: Nokia OS2008 port
- » Re: Nokia OS2008 port
- » Re: Nokia OS2008 port
- » Re: Nokia OS2008 port
- » Re: Nokia OS2008 port
Gtk is supposed to "push in" a menu, such that it's all visible as close as possible to the intended position. 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".The context menu does not always display correctly.
- Re: Nokia OS2008 port
- From: tpgww
- Nokia OS2008 port
- From: Pipeline
- Re: Nokia OS2008 port
- From: tpgww
- Re: Nokia OS2008 port
- From: Pipeline
- Re: Nokia OS2008 port
- From: tpgww