Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 6 hrs, 22 mins ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 2 days, 3 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 3 days ago - more...
| The Following User Says Thank You to fms For This Useful Post: | ||
|
2009-06-16
, 13:28
|
|
Posts: 1,418 |
Thanked: 1,541 times |
Joined on Feb 2008
|
#22
|
In fact, after some thinking, why not expand the list of podcasts to take the entire screen width (so that you can read the explanations) and move buttons to the bottom, making the dialog full-screen and adding a "close" button?
| The Following User Says Thank You to fms For This Useful Post: | ||
 |
|
2009-06-16
, 13:34
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#23
|
Originally Posted by fms
Yep, that's probably a good idea. The dialog should probably converted to a StackableWindow like the "New episodes avaialbe" dialog as seen in post 19. This would allow more space and the buttons would not take any space, as they can be put in the AppMenu.
In fact, after some thinking, why not expand the list of podcasts to take the entire screen width (so that you can read the explanations) and move buttons to the bottom, making the dialog full-screen and adding a "close" button?
I've added this as an UI bug: https://bugs.maemo.org/show_bug.cgi?id=4690
|
|
2009-06-16
, 14:02
|
|
Posts: 341 |
Thanked: 607 times |
Joined on Dec 2008
|
#24
|
There was a syntax error when I tried to install 0.16.1-5, in gui.py line 1970, just an extra ) at the end of the line.
After removing it gPodder launches, but I only get the main window. Application menu still doesn't work. Some comments based on this:
- The lists with the podcasts is quite slow. Is it doing any expensive operations while redrawing? Is it a direct child of the pannable area?
- The details page looks fine now, but I would put a big play button in the top right. The application menu is not discoverable enough. The option is also missing from my application menu, I only get "Do not download" or "Mark as new".
- The overshooting effect of the pannable with HildonTextView should be disabled, it doesn't look good with the way we draw the text view border (and that's not going to be fixed). There is a property for this.
- Still no highlight on the list when I tap, but the right item is selected when I go back.
- It also takes a pretty long time to get to the details after tapping on a podcast. If it needs to make a network connection, this would be a good time to enable the progress indicator while it's loading (hildon_gtk_window_set_progress_indicator()).
Regarding some earlier comments of you:
"I am currently using Pango Markup to create the style. If you can tell me how to use that styling in Pango markup (or point me to the docs), that'd be helpful."
That came up recently, but it's surprisingly involved right now for cell renderers. I'll try to get some example code.
"I'll currently leave this as-is, but maybe the suggested splitting is a good idea for later. It would make too much navigation interaction in my opinion (go through three screens to read an episode description instead of two)."
In practice, this is much less of a hassle than it sounds like. You trade one quick extra tap for much larger action buttons and clearer labels. If you absolutely want to stick with the two column layout, then it would still be preferable to remove the GtkPaned and just use a properly spaced HBox (like the HildonPicker with multiple columns).
"Yep, that's a bug. The AppMenu should be there already. Please send me the output of running
Code:
gpodder --maemo --verbose
in osso-xterm when trying to reproduce the bug"
Sadly, there's no output at all while tapping on the menu area. A lot of output before that. Without the --verbose flag, the most significant appear to be (shortened, can't copy and paste right now):
uibase.py:59: Unknown property: HildonPannableArea.window-placement
uibase.py:59: Unknown property: HildonPannableArea.shadow-type
gui.py:432: Cannot change the selection mode to anything other than GTK_SELECTION_NONE if hildon-ui-mode is GTK_HILDON_UI_MODE_NORMAL.
Although none of them seem to be critical.
There has just been another update while I'm writing this. This fixed the syntax error and the treeview scrolls faster now. Everything else is still the same though.
After removing it gPodder launches, but I only get the main window. Application menu still doesn't work. Some comments based on this:
- The lists with the podcasts is quite slow. Is it doing any expensive operations while redrawing? Is it a direct child of the pannable area?
- The details page looks fine now, but I would put a big play button in the top right. The application menu is not discoverable enough. The option is also missing from my application menu, I only get "Do not download" or "Mark as new".
- The overshooting effect of the pannable with HildonTextView should be disabled, it doesn't look good with the way we draw the text view border (and that's not going to be fixed). There is a property for this.
- Still no highlight on the list when I tap, but the right item is selected when I go back.
- It also takes a pretty long time to get to the details after tapping on a podcast. If it needs to make a network connection, this would be a good time to enable the progress indicator while it's loading (hildon_gtk_window_set_progress_indicator()).
Regarding some earlier comments of you:
"I am currently using Pango Markup to create the style. If you can tell me how to use that styling in Pango markup (or point me to the docs), that'd be helpful."
That came up recently, but it's surprisingly involved right now for cell renderers. I'll try to get some example code.
"I'll currently leave this as-is, but maybe the suggested splitting is a good idea for later. It would make too much navigation interaction in my opinion (go through three screens to read an episode description instead of two)."
In practice, this is much less of a hassle than it sounds like. You trade one quick extra tap for much larger action buttons and clearer labels. If you absolutely want to stick with the two column layout, then it would still be preferable to remove the GtkPaned and just use a properly spaced HBox (like the HildonPicker with multiple columns).
"Yep, that's a bug. The AppMenu should be there already. Please send me the output of running
Code:
gpodder --maemo --verbose
in osso-xterm when trying to reproduce the bug"
Sadly, there's no output at all while tapping on the menu area. A lot of output before that. Without the --verbose flag, the most significant appear to be (shortened, can't copy and paste right now):
uibase.py:59: Unknown property: HildonPannableArea.window-placement
uibase.py:59: Unknown property: HildonPannableArea.shadow-type
gui.py:432: Cannot change the selection mode to anything other than GTK_SELECTION_NONE if hildon-ui-mode is GTK_HILDON_UI_MODE_NORMAL.
Although none of them seem to be critical.
There has just been another update while I'm writing this. This fixed the syntax error and the treeview scrolls faster now. Everything else is still the same though.
|
|
2009-06-16
, 14:12
|
|
Posts: 1,418 |
Thanked: 1,541 times |
Joined on Feb 2008
|
#25
|
Originally Posted by thp
The funny part is, it looks like due to the way Fremantle dialogs misuse screen estate, there is never a reason to use them for anything serious. Wondering if this should be filed as a bug for Fremantle...
The dialog should probably converted to a StackableWindow like the "New episodes avaialbe" dialog as seen in post 19. This would allow more space and the buttons would not take any space, as they can be put in the AppMenu.
|
|
2009-06-16
, 14:36
|
|
Posts: 341 |
Thanked: 607 times |
Joined on Dec 2008
|
#26
|
Originally Posted by thp
Or if you can live without "select all" and "select none", you could use an edit mode toolbar and place the "Add" button on the toolbar. Unfortunately I don't think you can have an application many at the same time. But you should not have a required action (like Add) which is only available from the application menu, so placing it on the edit mode toolbar would be a better fit.
Yep, that's probably a good idea. The dialog should probably converted to a StackableWindow like the "New episodes avaialbe" dialog as seen in post 19. This would allow more space and the buttons would not take any space, as they can be put in the AppMenu.
I've added this as an UI bug: https://bugs.maemo.org/show_bug.cgi?id=4690
|
|
2009-06-16
, 15:07
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#27
|
Originally Posted by kanishou
Yep, the list is a direct child. The list itself is a GtkTreeView. It seems like it depends on how much text there is in the list.
- The lists with the podcasts is quite slow. Is it doing any expensive operations while redrawing? Is it a direct child of the pannable area?
- The details page looks fine now, but I would put a big play button in the top right. The application menu is not discoverable enough. The option is also missing from my application menu, I only get "Do not download" or "Mark as new".
- The overshooting effect of the pannable with HildonTextView should be disabled, it doesn't look good with the way we draw the text view border (and that's not going to be fixed). There is a property for this.
- Still no highlight on the list when I tap, but the right item is selected when I go back.
- It also takes a pretty long time to get to the details after tapping on a podcast. If it needs to make a network connection, this would be a good time to enable the progress indicator while it's loading (hildon_gtk_window_set_progress_indicator()).
That came up recently, but it's surprisingly involved right now for cell renderers. I'll try to get some example code.
In practice, this is much less of a hassle than it sounds like. You trade one quick extra tap for much larger action buttons and clearer labels. If you absolutely want to stick with the two column layout, then it would still be preferable to remove the GtkPaned and just use a properly spaced HBox (like the HildonPicker with multiple columns).
"Yep, that's a bug. The AppMenu should be there already. Please send me the output of running
Code:
gpodder --maemo --verbose
in osso-xterm when trying to reproduce the bug"
Sadly, there's no output at all while tapping on the menu area.
 |
|
2009-06-16
, 19:45
|
|
Posts: 3,790 |
Thanked: 5,718 times |
Joined on Mar 2006
@ Vienna, Austria
|
#28
|
Originally Posted by fms
Fremantle dialogs do not misuse screen estate. You get it all wrong:
The funny part is, it looks like due to the way Fremantle dialogs misuse screen estate, there is never a reason to use them for anything serious. Wondering if this should be filed as a bug for Fremantle...
Originally Posted by ragnar
See? Vertical space is more useful than horizontal space, therefore it's a good thing to... I mean, it's more useful to have ample space above buttons than to be able to read the full text... I mean...
For the dialog layouts, the idea there was to get more vertical space for dialogs, while at the same time doing a change that could be done for the Fremantle scope and timeframe. Yes, horizontal space is therefore reduced, but since we're pretty much getting rid of all the split screen UI designs anyway, vertical space is more useful than horizontal space.
( b f i
M e r n
a c o
y a m F
b u _ i
e s t n
_ e o l
i _ p a
t t _ n
' h t d
s e o .
_ y _ )
o _ b
n w o
l r t
y i t
_ t t
_ e o
_ _ m _ [Simply accept!]
|
|
2009-06-17
, 13:04
|
|
Posts: 341 |
Thanked: 607 times |
Joined on Dec 2008
|
#29
|
I seem to have a version of python-hildon that should have the fix, so it's probably not that bug. But otherwise that would seem very likely.
Anyway, I am getting the startup dialog again, so some more comments based on that:
- On the Welcome to gPodder! screen, the buttons are thumb sized now, but not properly themed. I wonder what is up with that. Are those just standard buttons created with HILDON_SIZE_THUMB_HEIGHT, and you are not changing the widget name afterwards?
In the authentication dialog for my.gpodder:
- Entries should be HildonEntries and perhaps use placeholder text instead of labels. It works well here, because the entries are not filled by default. I'm not sure if password entries support placeholder text, but I think so. If you keep the labels, they should not be bold and perhaps use SecondaryTextColor.
- The descriptive text seems unnecessary, I would just keep the lock icon and the "login to my.gpodder.org" label, and not use bold text. If you keep two lines, a common way to format it would be to use standard font for the first line, standard font (or SmallSystemFont) with SecondaryTextColor for the second line.
- Some padding between the descriptive text and the entries would be nice though.
- The "New user button" should be above the OK button, instead of top aligned.
- The OK button has a mnemonic that isn't necessary (we should disable that of course, but it may not be a good idea to use stock IDs for now), and it would be more fitting to use a verb label, e.g. "Sign in".
- Entries still don't have the right size. Buttons don't get the right themeing hint. I'm starting to wonder if it might be a limitation of the SDK or Python bindings.
As for getting pango compatible strings for logical fonts and colors, this should help:
For colours, you should be able to get the GdkColor from a logical string with gtk_style_lookup_color() and then turn it into a pango compatible string with gdk_color_to_string().
For logical fonts, you can get the GtkStyle with gtk_rc_get_style_by_paths() (using the logical color name as widget_path), and pango_font_description_to_string() on the font-desc member of the style.
None of this is confirmed or tested, but hopefully it will help you out.
Anyway, I am getting the startup dialog again, so some more comments based on that:
- On the Welcome to gPodder! screen, the buttons are thumb sized now, but not properly themed. I wonder what is up with that. Are those just standard buttons created with HILDON_SIZE_THUMB_HEIGHT, and you are not changing the widget name afterwards?
In the authentication dialog for my.gpodder:
- Entries should be HildonEntries and perhaps use placeholder text instead of labels. It works well here, because the entries are not filled by default. I'm not sure if password entries support placeholder text, but I think so. If you keep the labels, they should not be bold and perhaps use SecondaryTextColor.
- The descriptive text seems unnecessary, I would just keep the lock icon and the "login to my.gpodder.org" label, and not use bold text. If you keep two lines, a common way to format it would be to use standard font for the first line, standard font (or SmallSystemFont) with SecondaryTextColor for the second line.
- Some padding between the descriptive text and the entries would be nice though.
- The "New user button" should be above the OK button, instead of top aligned.
- The OK button has a mnemonic that isn't necessary (we should disable that of course, but it may not be a good idea to use stock IDs for now), and it would be more fitting to use a verb label, e.g. "Sign in".
- Entries still don't have the right size. Buttons don't get the right themeing hint. I'm starting to wonder if it might be a limitation of the SDK or Python bindings.
As for getting pango compatible strings for logical fonts and colors, this should help:
For colours, you should be able to get the GdkColor from a logical string with gtk_style_lookup_color() and then turn it into a pango compatible string with gdk_color_to_string().
For logical fonts, you can get the GtkStyle with gtk_rc_get_style_by_paths() (using the logical color name as widget_path), and pango_font_description_to_string() on the font-desc member of the style.
None of this is confirmed or tested, but hopefully it will help you out.
|
|
2009-06-18
, 21:19
|
|
Posts: 1,391 |
Thanked: 4,272 times |
Joined on Sep 2007
@ Vienna, Austria
|
#30
|
Originally Posted by kanishou
The AppMenu problem is being discussed at https://bugs.maemo.org/show_bug.cgi?id=4682 - please subscribe there to help.
I seem to have a version of python-hildon that should have the fix, so it's probably not that bug. But otherwise that would seem very likely.
On the Welcome to gPodder! screen, the buttons are thumb sized now, but not properly themed. I wonder what is up with that. Are those just standard buttons created with HILDON_SIZE_THUMB_HEIGHT, and you are not changing the widget name afterwards?
http://repo.or.cz/w/gpodder.git?a=bl.../fremantle#l62
Also, it looks fine in the SDK:
http://khan.thpinfo.com/~thp/images/...ome_090616.png
Having a different theme/engine in the SDK and in the device (with major differences in rendering buttons, etc...) is really bad. Developers can test how things look in the SDK, but it's hard to find out what is wrong when not being able to test directly with the real theme. At least the theme *engine* should be the same in the SDK, if you don't want to publish the "final" theme (engine + colors, graphics, styles) right now.
In the authentication dialog for my.gpodder:
As for getting pango compatible strings for logical fonts and colors, this should help:
For colours, you should be able to get the GdkColor from a logical string with gtk_style_lookup_color() and then turn it into a pango compatible string with gdk_color_to_string().
For logical fonts, you can get the GtkStyle with gtk_rc_get_style_by_paths() (using the logical color name as widget_path), and pango_font_description_to_string() on the font-desc member of the style.
None of this is confirmed or tested, but hopefully it will help you out.
I can't implement this, as the current theme on the devices seems to be different from the themes in the beta SDK, and I can't reproduce most of the UI/style/theme bugs you have here. Kind of an awkward situation :/
Especially in the second shot, it is easy to see that the empty space above the buttons in the right column can be much better utilized by expanding OPML address entry there. Also, the vacant space above the dialog is basically lost. Given that this dialog badly needs more vertical space, why not just make it full-screen and have a "close" button instead?
Computer and Console Emulators for Maemo, Symbian, and more.
Pack Rat: The Maemo Package Aggregator.