Bug 38440

Created attachment 54889 [details] patch 1

(In reply to comment #1) > Created an attachment (id=54889) [details] > patch 1 rs=me :)

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.

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

(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? :)

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

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

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 on attachment 55241 [details] patch 2 Clearing flags on attachment: 55241 Committed r58906: <http://trac.webkit.org/changeset/58906>

All reviewed patches have been landed. Closing bug.

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?

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

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

You probably still need to modify the CSS etc for Avkon right?

Revision r58906 cherry-picked into qtwebkit-2.0 with commit c5f27fb7e594c65e12239faa6e1c316c3534817b