Reaction Floating Speedbar

[kas1e]

@Chris

When the window opens it resizes to the maximum width available.

Mmm.. for me seems not. I have 1440x900, and for me window size the same size as on my shoot: i.e. about 2/3 by X, and 1/3 are "free".

It's not terribly obvious, but the gadgets are all getting truncated at the window border. If I try to resize it, it only lets me resize it to bigger sizes (bigger than the width of my screen).

I can't resize window to the minimum when its all compiled with disabled CHILD_MinWidht, 160 , but i can resize it bigger. And i even can move it over the borders, from both sides of screen (i.e. begining of window put to the left side, and resize it till end to the right side). Can move it to any direction and resize as i wish: no bugs or distorted borders or gadgets.

What resolution are you running in? Perhaps you need to make the button text longer for the resulting gadget to be wide enough to show the problem?

1440x900. I test now CHILD_MinWidth, 1600, and while whole window resizes and fits to the full screen , i have some small glitch which override right border. But once i make active any window, its refreshes to looks ok. But no gadgets corruption or so at all, just a border line. Maybe you also didn't have it, jut you can't see it. Or maybe its all depends on what theme you/i use (for me silver green, for you seems default one). Or maybe some wb settings somethere. But cleary that i can't normally reproduce what you have, but roots of my "overlap border line" imho the same as for you when you loose everything include gadgets.

If I try to resize it, it only lets me resize it to bigger sizes (bigger than the width of my screen).

For my "1600" test its imho ok and fine that it give me ability to only resize to the bigger sizes: because i set 1600 minimum. But if i set CHILD_MinWidth, less that 1440, then its all fits ok, no overlaping or anything like that.

Yes, at least that's what I would expect from a user interface perspective. A button bar with no visible buttons is clearly not intuitive! I'd argue the same for when there are too many buttons to fit - it's not obvious there are further buttons that aren't currently visible.

speedbarbug2.jpg

mm.. rechecked your second attach 10 times and still can't get what you try to show there All seems ok. Maybe its just wrong image attached ? Its the same ok as for my previous attaches imho ?

Anyway, there then 2 moments:

1). Overlaping of right border in some conditions (when the Child_MinWidth are bigger that actual screensize) - so that kind of bug. As it should just resizes to the full screen with no overlaping. But pressing on the window and allowing to resize it only bigger imho right and as should be. nope ?

2). Suggestion about "to show the speedbar buttons with moved-truncated text in, but not delete it fully" already reported few years ago in BZ 5313 by Ssolie, here is text of BZ:

----
The speedbar.gadget may hide buttons when there is not enough space
to render them all. There is also a scrolling feature that will scroll
the space to show the hidden buttons.

What is missing is a way to notify the user that buttons are hidden.
There is no visual indication at all.
----

So while with second one its reported already (right?) , with first one its all still not clear. Did we have the same and only one bug, or you also have something else ..

ps. And i can't at all "scroll" anything in your example btw, not with left-shift-lmb, not with right-shit-lmb. How and what i can scroll there ?

[chris]

@Chris

When the window opens it resizes to the maximum width available.

Mmm.. for me seems not. I have 1440x900, and for me window size the same size as on my shoot: i.e. about 2/3 by X, and 1/3 are "free".

OK, that's bigger than mine. Make the text "this is quite long text for a speedbar button gadget" even longer, and then try again.

What resolution are you running in? Perhaps you need to make the button text longer for the resulting gadget to be wide enough to show the problem?

1440x900. I test now CHILD_MinWidth, 1600, and while whole window resizes and fits to the full screen , i have some small glitch which override right border. But once i make active any window, its refreshes to looks ok. But no gadgets corruption or so at all, just a border line. Maybe you also didn't have it, jut you can't see it. Or maybe its all depends on what theme you/i use (for me silver green, for you seems default one). Or maybe some wb settings somethere. But cleary that i can't normally reproduce what you have, but roots of my "overlap border line" imho the same as for you when you loose everything include gadgets.

That's the same effect I'm seeing. The gadgets overwrite the border (and if queried internally they report a size that doesn't fit in the window either). It was more obvious on my NetSurf screenshot, where the space.gadget NetSurf renders into is running off the screen, yet the scrollbar thinks the entire width is being shown.

The attachment shows the correct and broken screenshots alongside, the bottom button has no right-hand border and there is no space between it and the window border. The window border always redraws itself before I can get a screenshot, hence why the effect isn't terribly obvious from a screenshot.

mm.. rechecked your second attach 10 times and still can't get what you try to show there All seems ok. Maybe its just wrong image attached ? Its the same ok as for my previous attaches imho ?

Correct image. Attachment shows yours and mine alongside - the gadgets are being truncated by the window border.

Anyway, there then 2 moments:

1). Overlaping of right border in some conditions (when the Child_MinWidth are bigger that actual screensize) - so that kind of bug. As it should just resizes to the full screen with no overlaping. But pressing on the window and allowing to resize it only bigger imho right and as should be. nope ?

Yes, that's the same effect (probably the same bug - I think CHILD_MinWidth is internally being set to a high value, when it should probably be 0). The resizing is correct - this is because the layout gadget knows the actual size and won't resize to a smaller value.

On second thoughts, there may be two bugs here - one is that the width of speedbar.gadget is being set wrong, the second is that the window is opening too small for the gadgets - it should either open bigger than the screen (if off-screen moving is set in Prefs) or refuse to open at all.

2). Suggestion about "to show the speedbar buttons with moved-truncated text in, but not delete it fully" already reported few years ago in BZ 5313 by Ssolie, here is text of BZ:

----
The speedbar.gadget may hide buttons when there is not enough space
to render them all. There is also a scrolling feature that will scroll
the space to show the hidden buttons.

What is missing is a way to notify the user that buttons are hidden.
There is no visual indication at all.
----

So while with second one its reported already (right?)

Yes, that's almost word-for-word what I said in an earlier post, so you can ignore that one.

ps. And i can't at all "scroll" anything in your example btw, not with left-shift-lmb, not with right-shit-lmb. How and what i can scroll there ?

Nothing, the example I modified had many more gadgets and could scroll. Mine only has one, so there's nothing to scroll.

[kas1e]

@Chris

OK, that's bigger than mine. Make the text "this is quite long text for a speedbar button gadget" even longer, and then try again.

Yep, i make it 2 times bigger, and now on running (with disable CHILD_MinWidth, 160,) it resizes to full screen, but data of the window override right border of the window (=>bug for sure)

Now question is: When we didn't have CHILD_MinWidth set to any value, should it be 0 by default, or should be it "full size of screen" by default ? Did it noted anywhere in the docs maybe ? Because if i set CHILD_MinWidth to 0, its resize to the minimum possible size where text are still ok and visibly (but button disappear and nothing can be seen at place of button). For me, its sounds logical to assume, that default state (when nothing is set), should be the same as CHILD_MinWidht, 0. But i am not expert, maybe "full size as default" done for purposes ?

On second thoughts, there may be two bugs here - one is that the width of speedbar.gadget is being set wrong

What you mean by widht of speedbar.gadget is being set wrong ? That it should be by default 0, and not fullsize, or you mean something else ? (sorry, i looses here, already count 2 suggestions, and 2 bugs (?) ). Or you mean that if you set 160, its in reality not 160 ?

the second is that the window is opening too small for the gadgets - it should either open bigger than the screen (if off-screen moving is set in Prefs) or refuse to open at all.

For me gadgets of window not corrupts. Only right border of the window overrides by the data of window, but all the gadgets (depth, iconify , resize) are fine and visibly.

[chris]

Yep, i make it 2 times bigger, and now on running (with disable CHILD_MinWidth, 160,) it resizes to full screen, but data of the window override right border of the window (=>bug for sure)

That's confirmed then!

Now question is: When we didn't have CHILD_MinWidth set to any value, should it be 0 by default, or should be it "full size of screen" by default ?

I think the default is ~0: "layout.gadget will ask the object, using GM_DOMAIN", whatever that means. It should be responding with something closer to 0 I guess. Full size (ie. so all gadgets are visible but no more) *might* be correct, but at the moment it seems to be selecting around four times full size.

What you mean by widht of speedbar.gadget is being set wrong ? That it should be by default 0, and not fullsize, or you mean something else ? (sorry, i looses here, already count 2 suggestions, and 2 bugs (?) ). Or you mean that if you set 160, its in reality not 160 ?

Yes, as above, same thing.

the second is that the window is opening too small for the gadgets - it should either open bigger than the screen (if off-screen moving is set in Prefs) or refuse to open at all.

For me gadgets of window not corrupts. Only right border of the window overrides by the data of window, but all the gadgets (depth, iconify , resize) are fine and visibly.

Window border gadgets are fine, the ones *in* the window are wrong - that's why they are overwriting the window border.

Got to go, sorry if message makes no sense.

[tbreeden]

The problem is that the speedbar itself seems to autosize to fit about four images (AISS 24x24) ....

Can one of the OS4 devs/betatesters please confirm this and raise it as a bug? I can confirm the same happens on NetSurf, even if I only have one long-ish titled text button which easily fits in the window, the speedbar.gadget itself sizes itself to fit at least four of these across. ... This is a pretty serious layout defect.

Did you try the suggestion by salass00 (with no specified MinWidth)?

set CHILD_NominalWidth to TRUE.

The NominalWidth seems to be exactly to fit the number of buttons. For your example with one button, it should result in a speedbar without the extra space. ie, MinWidth will be for one button rather than the usual four. Be nice if that were mentioned in the Autodocs, though; I was thinking of the NominalWidth as always resulting in a width bigger than the original MinWidth.

Tom

[chris]

Did you try the suggestion by salass00 (with no specified MinWidth)?

set CHILD_NominalWidth to TRUE.

The NominalWidth seems to be exactly to fit the number of buttons. For your example with one button, it should result in a speedbar without the extra space. ie, MinWidth will be for one button rather than the usual four. Be nice if that were mentioned in the Autodocs, though; I was thinking of the NominalWidth as always resulting in a width bigger than the original MinWidth.

I just set CHILD_MinWidth to 0. Didn't try NominalWidth - the AutoDocs give the impression that it will try and resize to fit all the buttons in, which isn't what I want (as it will force the window to open bigger).

Anyway, this doesn't change the fact that the default is wrong

[kas1e]

@Chris + all

So, i will make just 2 bz for speedup then ?

1. BUG: overriding data of the window when window is bigger that screen (even if CHILD_MinWidth is used)
2. SUGGESTION: change way of how Child_Wild works: make ~0 (i.e. possible minimum depends on data-size) as default, if no CHILD_MinWidth is used

Right ? Nothing more ?

[chris]

@Chris + all

So, i will make just 2 bz for speedup then ?

1. BUG: overriding data of the window when window should open bigger that screen (even if CHILD_MinWidth is used)
2. SUGGESTION: change way of how Child_Wild works: make ~0 (i.e. possible minimum depends on data-size) as default, if no CHILD_MinWidth is used

Right ? Nothing more ?

Looks good, minor amendment to #1 to make it a little clearer.

[kas1e]

@Chris

Ok, done, check if all is all right:

BZ #8190
change way of how Child_Wild works: make ~0 (i.e. possible minimum depends on data-size) as default, if no CHILD_MinWidth is used

If we didn't use CHILD_MinWidth when construct a speedbarobject, then the size of the whole window resized strangely. But when we set CHILD_MinWidth to 0, then window by default resized to the small as possible size (to fit main data visibly).

So, suggestion is: if CHILD_MinWidht is not set, make it by default like CHILD_MinWidht,0. Or, alternative, we should add to autodocs notice about why it can't be 0, and why it resized, so developers will no guess. But i assume its can be kind of small bugs as well.

I attached source code done from speedbarexample.c and a bit striped out to show actual problem. There you will find out at line 406: commented line "CHILD_MinWidth,0". If you compile it like this, then size of window will be strangely big. But if you will uncomment that line (i.e. manually set CHILD_MinWidht to 0), then everything will be ok (well, ok in terms of CHILD_MinWidht, but you can see that text of speedbar are not visibly, and that is reported already in diffrent BZ: BZ #5313)

I also attach screenshots to show how it looks like in end.

BZ #8191
Overriding of the right window borders when window should open bigger that screen (with and without CHILD_MinWidth)

That bug can be related to BZ #8190 and even maybe a bit to BZ #5313.

The bug is that when the main window is should be bigger than screen by X (for example if CHILD_MinWidht is set to bigger value by X in compare with current
used resolution, or, when the text of speedbar button is long enough and no CHILD_MinWidth is used, or, when its all mixed together with big values/datas),
i.e. in any of that cases : the right border of the window are overrides by the content of the window. I.e. its seems just like right values of the bounds of screen calcualtes wrong somehow.

Once you try to resize window, overriding disappear, and everyhing looks fine. But at first run, its all very visibly. Expectually if you will just move window a bit to the left side, you will see what happens with the right border.

As test case, i upload the same source code as from BZ#8190, where i just set CHILD_MinWidth to very big value (bigger than my screenmode), so i set there 2000. But if you by some reassons have bigger resolution, just set it bigger.

As well as i upload exactly the same sources, where i comment out CHILD_MinWidht, and instead make the text of speedbar button much more bigger (line 322), so it also can't fit to the screen, and so, will be the same resize window to bigger than screen size, and override ride borders of the window. If your screensize is bigger that 1440x1024, then just make line 322 bigger, so it will not fits to screen when resizes, to see bug.

Feel free to add anything and i will update them.

[chris]

@kas1e

Perfect, thanks!