Re: First test release of gPodder for Fremantle
 

Ah, good =) I am specifically referring to these dialogs though:

http://khan.thpinfo.com/~thp/images/...ces_090616.png
http://khan.thpinfo.com/~thp/images/...ory-090616.png

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?

Re: First test release of gPodder for Fremantle
 

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?

Re: First test release of gPodder for Fremantle
 

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

Re: First test release of gPodder for Fremantle
 

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.

Re: First test release of gPodder for Fremantle
 

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...

Re: First test release of gPodder for Fremantle
 

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.

Re: First test release of gPodder for Fremantle
 

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.

That AppMenu problems you are having are quite strange, as it works here in the beta SDK. Are you the only one having this problem or are other testers also experiencing missing AppMenu items? Do you have the latest version of python-hildon installed? (see bug 4492)

Why is that not going to be fixed? It's the default in the UI, and if developers have to set that property every time they use this (adding a TextView into a PannableArea is something that is problably going to be done often). Also, it does not look so horrible in the theme of the SDK. Is it vovershoot-max that needs to be set to 0?

I need to know which list is affected, so I can reproduce and fix it here. The podcast list, the episode list or the downloads list?

Might be because the cover image is loaded/scaled. Does the loading time differ for different podcasts?

That'd be helpful, thanks! :)

Ok.

Might this be related to https://bugs.maemo.org/show_bug.cgi?id=4492?

Re: First test release of gPodder for Fremantle
 

Fremantle dialogs do not misuse screen estate. You get it all wrong:

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... :eek:

( 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!]

Re: First test release of gPodder for Fremantle
 

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.

Re: First test release of gPodder for Fremantle
 

The AppMenu problem is being discussed at https://bugs.maemo.org/show_bug.cgi?id=4682 - please subscribe there to help.

No, they're defined in the GtkBuilder .ui file as HildonButton with the properties "label", "visible" and "size" set:

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.

Filed as https://bugs.maemo.org/show_bug.cgi?id=4709 - you can subscribe there to get notified when this has been fixed and is ready for a new review.

Filed a bug report at https://bugs.maemo.org/show_bug.cgi?id=4710

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 :/