Add resizing grippy to bottom-right of BeOS windows

RESOLVED INCOMPLETE

Status

()

Core
XUL
--
enhancement
RESOLVED INCOMPLETE
17 years ago
6 years ago

People

(Reporter: David Hallowell, Assigned: Sergei Dolgov)

Tracking

Trunk
x86
BeOS
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 3 obsolete attachments)

(Reporter)

Description

17 years ago
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

17 years ago
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

17 years ago
ooh that could be cool.

Comment 3

17 years ago
Created attachment 22539 [details]
A brief example of how to make the BWindow sizing grip appear and disappear
(Reporter)

Comment 4

17 years ago
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

17 years ago
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

17 years ago
...the first time he tries.

Comment 7

17 years ago
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

17 years ago
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

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

Comment 10

17 years ago
Screen real estate would be my guess.

Comment 11

17 years ago
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

17 years ago
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

17 years ago
Created attachment 24866 [details] [diff] [review]
diff -u nsWindow.cpp

Comment 14

17 years ago
This patch adds the 16x16 resize grippy to all windows

Comment 15

17 years ago
eWindowType_dialog is resizable?

Comment 16

17 years ago
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

17 years ago
No more working on Bezilla
Assignee: koehler → nobody

Comment 18

17 years ago
Created attachment 45339 [details] [diff] [review]
Removed grippy from dialogs, because it just doesn't look right.

Comment 19

16 years ago
Bezilla resizing grippy looks fine now. marking FIXED.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Comment 20

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

Comment 21

16 years ago
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

16 years ago
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

16 years ago
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 24

16 years ago
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

16 years ago
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

16 years ago
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

16 years ago
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).
(Assignee)

Comment 28

16 years ago
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.
(Assignee)

Comment 29

16 years ago
as i know HOWTO :)
Assignee: nobody → sergei_d
Status: REOPENED → NEW

Comment 30

16 years ago
Sergei,
I know you were working on this.  Have you been able to create a new patch?
(Assignee)

Comment 31

16 years ago
Created attachment 102137 [details]
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
(Assignee)

Comment 32

16 years ago
Created attachment 102138 [details] [diff] [review]
Patch for Makefile.in

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

Comment 33

16 years ago
Created attachment 102142 [details] [diff] [review]
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.
Attachment #24866 - Attachment is obsolete: true
Attachment #45339 - Attachment is obsolete: true
Comment on attachment 102138 [details] [diff] [review]
Patch for Makefile.in

r=cls
Attachment #102138 - Flags: review+

Comment 35

16 years ago
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.
(Assignee)

Comment 36

16 years ago
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

15 years ago
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?
(Assignee)

Comment 38

15 years ago
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

15 years ago
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.
(Assignee)

Comment 40

15 years ago
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.
(Assignee)

Comment 41

15 years ago
Created attachment 110206 [details] [diff] [review]
patch with borderstyle

quick patch to take in account eBorderStyle info. Prevents from adding grippy
to unappropriated window types.
Attachment #102142 - Attachment is obsolete: true

Comment 42

15 years ago
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.
(Assignee)

Comment 43

15 years ago
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

15 years ago
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.
(Assignee)

Comment 45

13 years ago
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
(Assignee)

Comment 46

13 years ago
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

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

Updated

7 years ago
QA Contact: jrgmorrison → xptoolkit.widgets
Reverting vandalism.

Gerv
BeOS is gone.
Status: NEW → RESOLVED
Last Resolved: 16 years ago6 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.