478149 - Fix up win32 window styles on WinCE

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: use win32 codepath for wince, with some tweaks

Currently, they're all mapped to very simple styles, which is appropriate for Fennec on Windows Mobile; however, for Windows CE, we need the full range.

This still isn't ideal for CE, because native CE apps have a unified menubar/toolbar/close button in one horizontal span, but it's better than before.

We could probably just add a close button to the toplevel chrome and not deal with a menubar, depends if we will ever be non-fullscreen.

Comment 1

[Doug Turner (:dougt)]

Comment on attachment 361922 [details] [diff] [review]
use win32 codepath for wince, with some tweaks

drop the changes to nsAppRunner.cpp.

I am not sure about the comment "Fennec should just specify the right window type".  File a seperate bug to spec out this work, or just drop the comment.  I am not really sure how an application would specify the right window type.

why do you want to add the other options to a eWindowType_toplevel?  I am pretty sure we don't want most of that (screenshot coming up)

the spacing is off in the changes around @@ -5772,8 +5787,11.  I think you can just space the SW_THICKFRAME over.

Comment 2

[Doug Turner (:dougt)]

Attachment: window style badness

vlad, this image shows the result of changing the window style for windows mobile.

Comment 3

[Doug Turner (:dougt)]

Comment on attachment 361922 [details] [diff] [review]
use win32 codepath for wince, with some tweaks

of course the style is probably busted because your patch for WINCE_WINDOWS_MOBILE
 has not landed yet.

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #1)
> (From update of attachment 361922 [details] [diff] [review])
> drop the changes to nsAppRunner.cpp.
> 
> I am not sure about the comment "Fennec should just specify the right window
> type".  File a seperate bug to spec out this work, or just drop the comment.  I
> am not really sure how an application would specify the right window type.

Hm, I was under the impression that CSS and/or XUL attributes on <window> could override the window type; that doesn't seem to be the case.  We might want to extend that.  Either way though, part of the comment is true -- namely that apps on Windows Mobile probably want the "simpler" types.  I can see some apps maybe not wanting the simpler types though.

> why do you want to add the other options to a eWindowType_toplevel?  I am
> pretty sure we don't want most of that (screenshot coming up)

Ugh, I didn't qrefresh.. yeah, the WINDOWS_MOBILE path should have identical window types as they are now. 

> the spacing is off in the changes around @@ -5772,8 +5787,11.  I think you can
> just space the SW_THICKFRAME over.

New patch coming up.

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: use win32 codepath for wince, with some tweaks (v2)

Updated.

Comment 6

[Doug Turner (:dougt)]

Comment on attachment 361960 [details] [diff] [review]
use win32 codepath for wince, with some tweaks (v2)

this looks fine, but we need to have WINCE_WINDOWS_MOBILE defined on windows mobile before this is commited.

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Attachment: updated patch to check in

Updated patch; ended up splitting out the codepaths to avoid the #ifdef explosion.

Comment 8

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Checked in.