65008 - Add resizing grippy to bottom-right of BeOS windows

Status: RESOLVED INCOMPLETE

(Core :: XUL, enhancement)

Description

[David Hallowell]

Based off Windows bug 27795

I think the BeOS port of Mozilla needs a resising grippy in the lower right of
the Window a lot more than the Windows version does because I've found BeOS
windows a lot harder to resise because you can only resise using the mouse in
the corner of the window unlike in Windows where you can drag any of the borders
to resise.

I've noticed many beos programs don't have this grippy but the ones that do it
makes resising so much easier. I'm sure you know what I mean but if you don't
I'll attach some screenshots.

Comment 1

[Kent Tessman]

How does this fit into the existing window design/layout?  I've looked at a
couple of skins, and it looks like there's room there to put the standard BeOS
grip widget, although that may not be the proper way depending on what happens
with the skinning proposal in bug (27795).

I do have some relatively simple code (used in BeHugo, for instance) that pops
the resizing grip in and out depending on if the mouse is hovering over the
bottom-right corner of the window, if that would be of interest/use.

Comment 2

[timeless]

ooh that could be cool.

Comment 3

[Kent Tessman]

Attachment: A brief example of how to make the BWindow sizing grip appear and disappear

Comment 4

[David Hallowell]

The biggest question is what happens if you remove the taskbar? Does the
resising grippy stay (I assume it does unless you code something to detect
whether the taskbar is there or not), if so will the lock icon move out of the
way or will it be obscured by the resising grippy?

I can't remember what happens on MacOS and I don't have a mac here

Comment 5

[Matthew T (active 1999-2002)]

A grippy which only appears when the user mouses over the edge of the window 
would be no use. The target area for the resizing would appear to be just as 
small, and the user would therefore take just as much care (and waste just as 
much time) positioning the cursor, as if the enlarged grippy never appeared at 
all.

Comment 6

[:deanis74]

...the first time he tries.

Comment 7

[Andrew Thompson]

Misses the point - the target zone the user has to put the cursor in is no bigger 
(unless you mean it should pop out when the cursor is near the target but not 
actually over it). Popout controls like this really do have little benefit if 
they make the target the user has to hit with the mouse to start a drag no 
bigger.

Comment 8

[:deanis74]

I think the intent is that the sizing grip appears when the mouse is near the 
grip's area.  From the comments in the attachment, "depending on if the mouse 
is over the area where a grip should be."

Comment 9

[Matthew T (active 1999-2002)]

Then what, exactly, is the point of having it hidden ever?

Comment 10

[:deanis74]

Screen real estate would be my guess.

Comment 11

[Kent Tessman]

The original issue, it seems, is the relative difficulty of resizing the BeOS
window versus, say, the resize-on-any-side Win32 window.  The problem is that
the "nice" BeOS GUI way of doing this is a resizing grip that, as things are
currently laid out, would cover part of the Mozilla chrome.  If there were a
standard grippy widget that occupied the bottom-right corner of real estate, we
could use that.  But as it is, and in order to not interfere with the Mozilla
chrome (by consistently having something covering that bottom-right corner) one
idea is to have the grip pop up whenever the mouse is in the vicinity, and have
it hidden the rest of the time.

The coarseness of the area in which the grip will detect the need to appear can
be adjusted, of course; it doesn't have to be _exactly_ the area of the grip. 
Whenever you swing the mouse down to that province of the window, it could
appear, but you'd probably want to stick closer to the actual grip area in order
to avoid exactly the covering/obscuring problem described above.

Comment 12

[Matthew T (active 1999-2002)]

The size grippy already does cover the bottom-right 16*16 pixels of the Mozilla 
chrome on Mac OS, and bug 27795 asks to do the same thing on Windows. So chrome 
authors wouldn't have to do anything to cope with BeOS having this grippy, more 
than they already have to do to cope with Mac OS and (eventually) Windows having 
the grippy.

Therefore there is no point in hiding the grippy on BeOS, because the app author 
won't (unless se is clueless) put anything in that part of the chrome anyway.

Comment 13

[kurros (Wade Majors)]

Attachment: diff -u nsWindow.cpp

Comment 14

[kurros (Wade Majors)]

This patch adds the 16x16 resize grippy to all windows

Comment 15

[:deanis74]

eWindowType_dialog is resizable?

Comment 16

[Matthew T (active 1999-2002)]

AFAIK, there's a flag for specifying whether or not a dialog should be resizable. 
Whether specific dialogs should or should not be resizable is outside the scope 
of this bug ... but the BeOS code should respect this flag.

Comment 17

[Yannick Koehler]

No more working on Bezilla

Comment 18

[Paul]

Attachment: Removed grippy from dialogs, because it just doesn't look right.

Comment 19

[Dennis Jakobsen]

Bezilla resizing grippy looks fine now. marking FIXED.

Comment 20

[Sergei Dolgov]

Paul, i don't see if this was checked in.
Still TITLED look for normal windows instead DOCUMENT

Comment 21

[Paul]

the resizing grippy cannot be added to a window, as it would overlap the security icon in
the bottom right corner.  ALL themes would need to be changed to accomidate this.  If you
think it should be added, you may re-open the bug.

Comment 22

[timeless]

um, mozilla should already have correct support for this because macos demanded 
it. (it looks a bit ugly because it's imprecise on macos, but you don't lose 
your security icon)

Comment 23

[Paul]

as per timeless's comments, I will reopen this bug.

Is there a flag that needs to be set somewhere to shift the icons on the bottom
of the window to the left a bit?

Comment 24

[timeless]

you might need to implement
-moz-appearance: resizer
i'm having trouble picking through this stuff

i think hewitt's wXP work broke macos classic, so my guess is that you *don't*
need to implement -moz-appearance, but that the specific reference i'm providing
might still be helpful.

Comment 25

[timeless]

nah, wrong tree (to bark up). it's padding-right on the statusbar.

the fix is to change beos to use macclassic or fork a beclassic (which we kind
of might need anyway).

Comment 26

[Paul]

I take it, you mean modifying the classic theme, to make room for the grippy.  Not knowing
much about mozilla's themeing (haven't looked at it in a LONG time), would other themes 
taken from the next have their status bar adjusted as well?

Comment 27

[Matthew T (active 1999-2002)]

I assume BeZilla is currently using Windows Classic. Windows Classic needs
modifying to make way for the grippy too, it's just that no-one has implemented
the grippy yet (bug 27795).

Comment 28

[Sergei Dolgov]

change in  platformXUL.css is needed.
Something like:
+ statusbar {
+  padding-right: 14px;
+  height: 12px;
+  }.
Though, probably it needs also creating ./beos folder in
mozilla/xpfe/global/resources/content/
and chaning Makefile/Makefile.in
because now it uses ./unix.

Comment 29

[Sergei Dolgov]

as i know HOWTO :)

Comment 30

[Paul]

Sergei,
I know you were working on this.  Have you been able to create a new patch?

Comment 31

[Sergei Dolgov]

Attachment: zip-file - content of mozilla/xpfe/global/resources/content/beos

OK, starting.
First, files for mozilla/xpfe/global/resources/content/beos in *.zip package
Files are based on unix version, but corrected following Mac example

Comment 32

[Sergei Dolgov]

Attachment: Patch for Makefile.in

Continue.
Patch for mozilla/xpfe/global/resources/content/Makefile.in

Comment 33

[Sergei Dolgov]

Attachment: Patch - nsWindow.cpp

Finishing.
Patch for mozilla/widget/src/beos/nsWindow.cpp
Adding resizing grippy to "independent" top-level windows including parentless
dialogs.
Changing some appearance flags for dialogs with parent.

Though, look is still bit imperfect, because i couldn't reduce
statusbar/statusbarholder height (maybe by removing 3D-eyecandies) - i'm not
css expert.

Comment 34

[hacker formerly known as [e-mail]]

Comment on attachment 102138 [details] [diff] [review]
Patch for Makefile.in

r=cls

Comment 35

[Paul]

Comment on attachment 102142 [details] [diff] [review]
Patch - nsWindow.cpp

Sergei,
Are we sure we want to make all subset windows non-resizeable?	Last night, I
was trying to use the "File Bookmark" dialog, and the window that was created
was not resizeable, and so I could not see the bottom part of the dialog.  i.e.
the view was larger than the window, but I could not resize the window to see
the entire view.  It was late, and I did not get a chance to look into it
further, but I will tonight.

Comment 36

[Sergei Dolgov]

Tested "File Bookmark" dialog just now. Seems ok here. But sure, i seen this bug
in older Win32 Mozilla.
Feel free to remove NOT_RESIZABLE flag, if it causes problems for you, but din;t
remove "flags" and "look" variables - i'm starting to implement yer
unimplemented window_style handling.

Comment 37

[Paul]

Sergei,
Tried the patch.  Works great.  One thing, however, is that small windows, like
the installer window, also get the resizing grippy.  Try installing a new theme,
and you'll see what I mean.  Though, I'm not sure if we can do much about it.

Any ideas?

Comment 38

[Sergei Dolgov]

Not only there, Paul. I tried some apps from mozdev, and those also sometimes
looks weird with this grippy, as they haven't anything like statusbar.

Though, as i mentioned in comment #36, i will try later to implement yet
unimplemented window style handling, which may solve this problem. But i prefer
to do it in next bug, not here.

Comment 39

[Paul]

Well, the way it is right now, I don't think it should be checked in.  Even though it worksfine for "normal" windows, with a status bar at the bottom, it does not work for other windows.If you can resolve the problem, great.  Otherwise, I don't think this is important enoughto worry about.

Comment 40

[Sergei Dolgov]

Paul, can you point onto exact way to get/reproduce those windows where grippy
shouldn't be?
I cannot reproduce your example with theme installation window here with current
patch. 

Probably it should be parentless dialog or top-level window, as for other cases
patch creates BWinows without grippy.

Comment 41

[Sergei Dolgov]

Attachment: patch with borderstyle

quick patch to take in account eBorderStyle info. Prevents from adding grippy
to unappropriated window types.

Comment 42

[Paul]

not that i don't like the idea of the resize grippy on the window, but, i just
noticed that, if you put mozilla into "full screen" mode, the grippy remains. 
plus, in "full screen" mode, the status bar is hidden at the bottom, and scroll
bars extend to the bottom of the screen.  In this case, the grippy is drawn
overtop of the bottom scroll buttons on the scrollbar.

Comment 43

[Sergei Dolgov]

Ok, i think now we postpone this patch until full implementation of "BorderStyle"
in BeOS port. Also i will think a bit about initial example, where grippy is
"dynamical", maybe it also allows us to change cursor shape to "resizer" when it
is on right-bottom corner. Currently as far as i remember, Modern theme
inplements its own XUL-grippy and also cursor shape change works there, but that
XUL-grippy perferms Mozilla-driven resize, which is ugly for known reason.

At all i think about resizing after long experiments, we should move to
B_OUTLINE_RESIZE mode, because it seems only possibility under BeOS to generate
FrameResized events on mouse stop/release only. Current workaround with
ResizeRunner in BeOS port is still ugly, if page isn't blank, and even on simple
pages creates visually awful lagging. Problem is that we initiate rendered page
recalculation/reflow on each FrameResize event (or bit less with ResizeRunner)
and i don't see any way to speed-up such hard task.
But that's for another bug.

Comment 44

[Paul]

i plan on implementing the all of the border styles as my next patch, stay 
tuned.

I agree with the outline resize comment as well.  I can create a patch for that 
as well, but will do the border style patch first, since, the same section of 
code will need to be modified.

Comment 45

[Sergei Dolgov]

tqh, you came later, but i think it is useful if you know about this old bug, as
you are working now at window create and border styles patch. Maybe we should
even put some dependency here

Comment 46

[Sergei Dolgov]

I think this bug is still actual in some sence.
This is usability problem, and even if we don't plan to use B_DOCUMENT_WINDOW,
it is still good idea to add BeOS CSS overlay in order to create some free space
at right side of statusbar panel.
When i'm trying to resize window, frequently even with little misplace of cursor
it results in clicking at "security" button or, for now, at "adblock" panel.
Really annoying thing.

Comment 47

[tqh]

I already knew about it. I go thru the bug-list from time to time to see what
would be fun to work on.

Comment 48

[Gervase Markham [:gerv]]

Reverting vandalism.

Gerv

Comment 49

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

BeOS is gone.