Bug 38440 - [Qt] use QT_MOBILE_THEME in Symbian
Summary: [Qt] use QT_MOBILE_THEME in Symbian
Status: CLOSED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Normal
Assignee: Luiz Agostini
URL:
Keywords: Qt
Depends on: 38439
Blocks: 35784
  Show dependency treegraph
 
Reported: 2010-05-02 13:49 PDT by Luiz Agostini
Modified: 2010-05-14 08:41 PDT (History)
7 users (show)

See Also:


Attachments
patch 1 (1.34 KB, patch)
2010-05-02 13:56 PDT, Luiz Agostini
no flags Details | Formatted Diff | Diff
patch 2 (1.30 KB, patch)
2010-05-06 08:16 PDT, Luiz Agostini
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Luiz Agostini 2010-05-02 13:49:49 PDT
Putting QT_MOBILE_THEME into use for Symbian.
Comment 1 Luiz Agostini 2010-05-02 13:56:07 PDT
Created attachment 54889 [details]
patch 1
Comment 2 Simon Hausmann 2010-05-02 14:34:12 PDT
(In reply to comment #1)
> Created an attachment (id=54889) [details]
> patch 1

rs=me :)
Comment 3 Janne Koskinen 2010-05-05 06:41:23 PDT
Umm... why would we use maemo5style on Symbian ?

We have s60Style that we currently use albeit yes it sucks with dissappearing check-boxes etc.. If that QT_MOBILE_THEME style/palette is considered to be the best color scheme for mobiles and is accepted by S60 LAF guides I see why not take it in. But then the class name has to be changed from maemo5style.
Comment 4 Yael 2010-05-05 06:48:53 PDT
(In reply to comment #3)
> Umm... why would we use maemo5style on Symbian ?
> 
> We have s60Style that we currently use albeit yes it sucks with dissappearing
> check-boxes etc.. If that QT_MOBILE_THEME style/palette is considered to be the
> best color scheme for mobiles and is accepted by S60 LAF guides I see why not
> take it in. But then the class name has to be changed from maemo5style.

Funny :-)
I thought we were going to use QHbStyle in Symbian^4.
Comment 5 Simon Hausmann 2010-05-05 08:32:32 PDT
(In reply to comment #3)
> Umm... why would we use maemo5style on Symbian ?
> 
> We have s60Style that we currently use albeit yes it sucks with dissappearing
> check-boxes etc.. If that QT_MOBILE_THEME style/palette is considered to be the
> best color scheme for mobiles and is accepted by S60 LAF guides I see why not
> take it in. But then the class name has to be changed from maemo5style.

Yes, the name maemo5style is confusing, but essentially this is about using the windows style plus a custom stylesheet for the rendering of form elements, instead of the native style with buttons and input fields with finger friendly sizes that break web site layout.

Luiz, can you elaborate a bit on that? :)
Comment 6 Luiz Agostini 2010-05-05 10:40:10 PDT
(In reply to comment #5)
> (In reply to comment #3)
> > Umm... why would we use maemo5style on Symbian ?
> > 
> > We have s60Style that we currently use albeit yes it sucks with dissappearing
> > check-boxes etc.. If that QT_MOBILE_THEME style/palette is considered to be the
> > best color scheme for mobiles and is accepted by S60 LAF guides I see why not
> > take it in. But then the class name has to be changed from maemo5style.
> 
> Yes, the name maemo5style is confusing, but essentially this is about using the
> windows style plus a custom stylesheet for the rendering of form elements,
> instead of the native style with buttons and input fields with finger friendly
> sizes that break web site layout.
> 
> Luiz, can you elaborate a bit on that? :)

Maemo5Style is responsible for rendering radio buttons, checkboxes and combo boxes buttons. All other elements are rendered by webkit using a customized style sheet. Any other QStyle, if provided, will be ignored.

What is now been enabled for Symbian is the use of Maemo5Style class, customized style sheet and replacing list boxes by combo boxes. There are some screen shots of the expected result in bug 36370.

All <select> elements will be rendered as combo boxes but customized popups are not provided. To provide customized popups it is needed to create a platform plugin. See bug 38438.

Yes the name Maemo5Style does not make sense now. I plan to rename files and class in future patch.

I an submitting this patch and previous one (bug 38439) because I understood that it was agreed that it should be done. Please let me know if I am wrong.
Comment 7 Janne Koskinen 2010-05-06 02:50:54 PDT
Hi, I know the background of the bug and I do agree that we need webstyle which is separated from user themes for visibility and usability reasons. Esp. on S60 where native controls don't fit to webpage layouts and color schemes at all. What worries here in your comments is that controls would be smaller. It is already very difficult in e.g. 5800 to use elements due to their small size.

non-touch S60 UI uses popups for all of these elements (radiobutton, checkbox, combobox). I think we might need to extend the work you've done to combobox popup to apply to radiobuttons and checkboxes as well when UI style is non-touch. We have a fullscreen list for combobox type already available but this doesn't allow multiselection. How much should be put effort supporting non-touch UI is bit questionable and I don't have answer for it.

Yael's concern about orbit is also valid as that is Direct single touch UI where I could see combobox being operated in-place. Anyone know if Orbit even has comboboxes? How does combobox work in DUI (Maemo6/MeeGo)? Plugin mechanism is the technical answer, now we need to find out how many plugin variations we need to implement.

But let's put it in, and test it with full range of devices we have to see what are the implications.

I'm fairly certain I will find this change from my mail box quite often in upcoming months :D
Comment 8 Luiz Agostini 2010-05-06 08:16:35 PDT
Created attachment 55241 [details]
patch 2

As everyone seems to be ok with the changes I will land it and deal with the issues as they come.
I will also supply a patch renaming Maemo5WebStyle to DefaultMobileWebStyle or something similar.

Thanks for the comments Janne, Yael and Simon.
Comment 9 WebKit Commit Bot 2010-05-06 13:38:15 PDT
Comment on attachment 55241 [details]
patch 2

Clearing flags on attachment: 55241

Committed r58906: <http://trac.webkit.org/changeset/58906>
Comment 10 WebKit Commit Bot 2010-05-06 13:38:22 PDT
All reviewed patches have been landed.  Closing bug.
Comment 11 Simon Hausmann 2010-05-07 01:11:10 PDT
While I agree that this is the right way forward and that the platform plugins will help to smoothen things out even further, I would like to double check if we _do_ want this change in the QtWebKit 2.0 release.

The 2.0 release on Symbian is going to be used only on platforms that use Avkon and where the Browser uses Avkon appearance for the buttons, etc. in form elements.

In the context of this, is the integration into the release still intentional?
Comment 12 Janne Koskinen 2010-05-07 02:09:41 PDT
(In reply to comment #11)
> The 2.0 release on Symbian is going to be used only on platforms that use Avkon
> and where the Browser uses Avkon appearance for the buttons, etc. in form
> elements.

This patch doesn't touch buttons. Only checkboxes , radiobuttons and comboboxes.

> In the context of this, is the integration into the release still intentional?

We have no styled radiobutton nor checkboxes for Avkon base S60Style. What we have is terrible hack which doesn't work properly on white nor black background.
What we would need for 2.0 release is the combobox implementation.

So, yes the integration is intentional.
Comment 13 Yael 2010-05-07 05:12:37 PDT
(In reply to comment #11)
> While I agree that this is the right way forward and that the platform plugins
> will help to smoothen things out even further, I would like to double check if
> we _do_ want this change in the QtWebKit 2.0 release.
> 
> The 2.0 release on Symbian is going to be used only on platforms that use Avkon
> and where the Browser uses Avkon appearance for the buttons, etc. in form
> elements.
> 
> In the context of this, is the integration into the release still intentional?

Chang worked on the Avkon integration. cc'ing him as well.
Comment 14 Kenneth Rohde Christiansen 2010-05-07 05:40:03 PDT
You probably still need to modify the CSS etc for Avkon right?
Comment 15 Simon Hausmann 2010-05-14 08:41:18 PDT
Revision r58906 cherry-picked into qtwebkit-2.0 with commit c5f27fb7e594c65e12239faa6e1c316c3534817b