Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#279 closed bug (fixed)

Support MUIA_MinWidth and MUIA_MinHeight for MUIC_Scrollgroup

Reported by: Andreas Falkenhahn Owned by: Thore Böckelmann
Priority: normal Milestone: 4.0-2016R1
Component: Scrollgroup.mui Version: 4.0-2015R3
Severity: minor Keywords:
Cc: OS Platform: All
Blocked By: Blocking:
Release Notes:

Description

AFAICS MUIA_MinWidth and MUIA_MinHeight aren't working for MUIC_Scrollgroup. I have a scrollgroup that contains 640x480 pixels of content. By default, MUI displays the complete 640x480 pixels because the screen is large enough. But I'd like to have only 320x240 pixels visible and the rest should be visible only through scrolling the MUIC_Scrollgroup or resizing the window. Thus, it would be good if MUIA_MinWidth and MUIA_MinHeight also worked for MUIC_Scrollgroup. Then I could just set MUIA_MinWidth to 320 and MUIA_MinHeight to 240 and the initial size of the scrollgroup would be 320x240.

Attachments (1)

Class1.c (8.8 KB) - added by Andreas Falkenhahn 5 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 Changed 51 years ago by Andreas Falkenhahn

Status: pendingnew

comment:1 Changed 5 years ago by Thore Böckelmann

Priority: undecidednormal
Status: newpending

Let me try to understand this. You want an object to get a smaller size than the default maximum and you want to archive this by setting a minimum size. Sorry, but this is the wrong way to approach this problem. You should be enforcing a maximum size for this purpose. That's why you wanted MUIA_MaxWidth/Height to be implemented.

Another possibility would (again) be a creating a subclass of Scrollgroup.mui and set your desired minimum, default and maximum dimensions in MUIM_AskMinMax.

Please keep in mind that one of the most basic features of MUI is the fact that the GUI is fully resizable. This requires that there are as little fixed size objects as possible. Enforcing fixed sizes, or at least very restricted sizes, contradicts the resizability.

comment:2 Changed 5 years ago by Andreas Falkenhahn

Using MUIA_MaxWidth/Height with 320x240 is not a solution because it would limit the size to 320x240 but that's not what I want. I want the initial size when opening the window to be 320x240 but it should still be resizable to a larger size. Of course I could override MUIM_AskMinMax to do what I want but isn't this also somehow possible using Area.mui attributes?

BTW, MUIA_MaxWidth/Height on a scrollgroup doesn't seem to work at all. Check out the attached sample. Drawing is messed up when setting MUIA_MaxWidth/Height on the scrollgroup.

Changed 5 years ago by Andreas Falkenhahn

Attachment: Class1.c added

comment:3 Changed 5 years ago by Thore Böckelmann

Status: newpending

Take a look at your own code. You are setting inconsistent maximum dimensions. The MUIA_MaxWidth/Height restrict the virtual group's size to something lots smaller than what the MUIM_AskMinMax method returns. Of course MUI has to choose the smaller values as these impose the stronger restriction.

MUI tries to set up dimensions equal to what the MUIM_AskMinMax method returns as default dimension. But it is allowed to resize the object within the minimum and maximum dimensions as it is required. The default dimensions are just a wish, no rule. MUI tries to fulfil this wish as good as possible, but it is not possible to enforce fixed default dimensions while still allowing full resizability. This is a contradiction in itself. An object is either fixed sized or resizable within certain limits. The contents of a virtual group should never be restricted regardin the maximum size (unless you have very good reasons to do so) as this defeats the purpose of virtual groups.

Even if you manage to end up with a scrollgroup of a definite visible size after opening the window, how would you expect MUI to react when the user resizes the window? You are trying to restrict the initial visible maximum size while still having unrestricted virtual size and having unrestricted visible maximum size afterwards. You see the contradiction? Or did I misunderstand you?

comment:4 Changed 5 years ago by Thore Böckelmann

I had a deeper look at how Group.mui, Virtgroup.mui and Scrollgroup.mui do interact, just to understand whose dimension is restricted when and how.

The dimension of a virtual group's inner contens is never restricted in any way, because this would defeat the purpose of a virtual group otherwise. Only the visible area can be restriced by the known methods and attributes. If the inner contents are smaller than the visible area they might be resized to fit the visible area, otherwise they will always be resized to their default size. Scrollgroup.mui will adjust the bars according to the virtual group's inner contents size and the virtual group's visible size and it will show/hide the scroll bars accordingly if allowed.

But as with any other object the virtual group's default (visible) size is just treated as wish. If this wish cannot be fulfilled (i.e. because the window is larger and other objects cannot be resized) then it will be resized within the defined minimum and maximum limits. This is how MUI's layout engine works. The MUIM_AskMinMax method defines the object's size range and the MUIM_Layout method sets a definite position and size.

comment:5 Changed 5 years ago by Thore Böckelmann

Milestone: future release4.0-2015R4
Resolution: worksforme
Status: pendingclosed

No answer from you within 3 weeks. I think this issue is cleared up then.

comment:6 Changed 5 years ago by Andreas Falkenhahn

Sorry, I forgot about this. Maybe let's go through this one by one. The first thing I don't understand is this:

Take a look at your own code. You are setting inconsistent maximum dimensions. The MUIA_MaxWidth/Height restrict the virtual group's size to something lots smaller than what the MUIM_AskMinMax method returns. Of course MUI has to choose the smaller values as these impose the stronger restriction.

In the example I provided MUIA_MaxWidth and MUIA_MaxHeight are set for the ScrollgroupObject, not for the VirtgroupObject. Thus, I'd expect it to only apply to the scrollgroup object. So why are you talking about the virtual group size at all? What I want to do is to set the maximum dimensions for the scrollgroup object, i.e. the container object for the virtgroup. Why can't I set this to any size I'd like? (as long as it's large enough to comprise two scrollbars). I don't see a contradiction here. Why should it be a contradiction to say that the scrollgroup object must not be larger than 320x240? This doesn't have anything to do with the virtgroup in it at all. There could be a 10000x10000 virtgroup in a 320x240 scrollgroup, couldn't it?

I'm really only talking about limiting the size of the scrollgroup, i.e. the widget that contains the virtgroup. This currently doesn't work and I don't really see why. I can set MUIA_MaxWidth/MUIA_MaxHeight to set the maximum size of a listview for example. Why isn't it possible in the same way for a scrollgroup?

comment:7 Changed 5 years ago by Thore Böckelmann

You are right. The embedded virtual group still enforces a minimum size for the surrounding Scrollgroup object. If you set a maximum size larger than the virtual group's dimension then everything is ok. I'll see what I can do about this.

But I must add that your demo explicitly forbids horizontal scrolling by setting MUIA_Scrollgroup_FreeHoriz to FALSE. However, the requested minimum width of 320 pixels exceeds the virtual group's minimum width of 338 pixels (on my setup) and hence the complete layout fails. So no matter how a possible solution might look like it is necessary to allow the Scrollgroup object to scroll its contents in the restricted direction, otherwise things cannot work as expected.

comment:8 Changed 5 years ago by Thore Böckelmann

Milestone: 4.0-2015R44.0-2016R1
Resolution: worksforme
Status: closedreopened

comment:9 Changed 5 years ago by Thore Böckelmann

Owner: set to Thore Böckelmann
Status: reopenedassigned

comment:10 Changed 5 years ago by Thore Böckelmann

After lots of debugging I came to the conclusion that this issue is still caused by a misunderstanding. In fact removing "MUIA_Scrollgroup_FreeHoriz,FALSE," makes everything work.

The point is that your demo is enforcing a smaller dimension for the scrollgroup that its contents' dimension in both directions. But if the virtual group is not allowed to extend horizontally due to MUIA_Scrollgroup_FreeHoriz=FALSE then of course things must fail. What would you expect otherwise? The same applies for MUIA_Scrollgroup_FreeVert=FALSE if the virtual group contents become higher than the scrollgroup's maximum height.

To make it short: if you are asking for restricted visible dimensions of a scrollgroup you must allow the embedded virtual group to have unrestricted size in that direction.

For me your demo is working as expected with MUIA_Scrollgroup_FreeHoriz removed.

comment:11 Changed 5 years ago by Thore Böckelmann

Some more information from my side.

If a virtual group is not allowed to have an unrestriced dimension, which effectively happens by setting MUIA_Scrollgroup_FreeHoriz/Vert to FALSE, then it is a very bad idea to restrict the scrollgroup's dimension in that direction. This all boils down to the fact that the set fixed dimension applies to the full dimension of the scrollgroup object, including the frame and and the scrollbars. Even if you know that the virtual group's dimension exactly matches the fixed dimension set for the scrollgroup the scrollgroup still must be a little larger than the virtual group, because usually there is an additional frame of at least 1 pixel width plus the possible scrollbars.

Setting MUIA_Scrollgroup_FreeHoriz/Vert to FALSE, which effectively sets MUIA_Virtgroup_FreeHoriz/Vert to the same value, enforces a size dependency between the scrollgroup and the embedded virtual group, because the scrollgroup is not allowed to be scrolled in that direction and hence the virtual group defines the scrollgroup's dimension. Vice versa the scrollgroup defines the virtual group's dimension if it is resized. This is why such a scrollgroup cannot become smaller than the embedded virtual group.

comment:12 Changed 5 years ago by Andreas Falkenhahn

Right, removing MUIA_Scrollgroup_FreeHoriz solves the MUIA_MaxWidth/MUIA_MaxHeight issue and I agree it's nonsense to set FreeHoriz here. I don't really know why I set this attribute and I should have noticed that this is of course a contradiction. Sorry.

But remember the original problem was different (see my very first post): The original problem was to force the Scrollgroup's default size to 320x240 but still keep it sizable. I don't see how this is possible. What would I have to do to force the Scrollgroup to use a default size of 320x240 when the window opens and no previous size information has been stored in ENV:MUI? Is this possible by setting some attributes or do I have to derive a custom class from MUIC_Scrollgroup and set the default size explicitly in mAskMinMax()?

I agree that this ticket is really pretty misleading. My MUIA_MinWidth and MUIA_MinHeight remarks of course don't have anything to do with the topic either. It's really only about how to set the default size of the Scrollgroup which is by default larger than 320x240 but I want to enforce a default size of 320x240. Is this possible without subclassing Scrollgroup?

comment:13 Changed 5 years ago by Thore Böckelmann

No, the default dimensions can only be set by implementing MUIM_AskMinMax in a subclass. And this isn't something that I will implement as a pair of attributes analog to MUIA_MinWidth/Height.

I know what you are trying to archive, but in the end the default dimensions are just a hint, nothing more. If the window does fit on the screen with the objects' default dimensions (ok, quite unlikely today considering the average screen size) it will be will resized anyway. Furthermore once the window has been resized and/or snapshotted by the user the default dimensions as void anyway. And even if you manage to archive a default dimension like you desire it this most probably still won't get you the desired result of a fully embedded virtual group, because the object's default size includes its frame plus the scrollbars. Hence the remaining visible area for the embedded virtual group will definitely be smaller. And you must not make any guesses about the user's frame settings, so this cannot be correctly respected at compile time by assuming certain constant sizes. Again, the only solution would be a subclass which obtains the object's frame size during MUIM_Setup by using the _addleft(), _addtop(), _subwidth() and _subheight() macros. Although these are documented to be used during MUIM_Draw only their respective values are set up during MUIM_Setup and do not change afterwards. That way you can determine the scrollgroup's remaining inner dimension to let its MUIM_AskMinMax method return slightly larger default dimensions. The scrollbars' dimensions can be obtained by get()ing MUIA_Scrollgroup_Horiz/VertBar and asking the retured objects (might be NULL!) for their size. All in all quite much work for a specific default dimension that cannot even be guaranteed and most probably isn't going to last for long…

comment:14 Changed 5 years ago by Andreas Falkenhahn

I think I know now why this was about MUIA_MinWidth and MUIA_MinHeight. You implemented MUIA_MinWidth and MUIA_MinHeight for me to easily be able to specify the initial dimensions for an object. For example, these attributes could be used to create a listview that is 800x400 pixels.

This will work fine EXCEPT in the case the gadget's default size is larger than the size set with MUIA_MinWidth/Height. In that case, MUI will use the default size of course.

That's why I think we need an additional tag named, e.g. MUIA_OverrideDefaultSize. If this is set in addition to MUIA_MinWidth/Height then MUI should make sure that the size specified in MUIA_MinWidth/Height is also set as the gadget's default size.

Of course, all this only applies in case valid dimensions are specified. If the user specifies any dimensions that are too small then of course MUI should enforce valid sizes. That's obvious, of course.

comment:15 Changed 5 years ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

Such an attribute but be far too specific just to archive an effect for which most probably your are the only person who really desires it. Furthermore that desired effect is void as soon as the user resizes the window, and that is very likely to happen. Finally, and I said this about 100 times by now, the default size is just wish. There is absolutely no guarantee that the object will really come up with that dimension initially. You really need to let MUI decide about the object dimensions when they are variable, do not enforce them.

Really, just create a subclass and implement MUIM_AskMinMax as described above. It isn't that hard and scary as you might think.

comment:16 in reply to:  15 Changed 5 years ago by Andreas Falkenhahn

Each and every toolkit I have seen so far allows specifying an initial object size. And of course it's absolutely obvious that this is just a WISH and might not be honoured but that's absolutely ok. If I set a listview's initial size to 600x400 and the user is running 640x256 then of course MUI should just ignore that wish and fall back to something useful.

Subclassing wouldn't be a problem but keep in mind that I need this for each and every class and honestly, it's too much work. I just won't go about and subclass *every single class* just to be able to specify an initial object size. That's ridiculously much overhead and it defies any common sense. If there was a general way to do it, I'd implement it, but no, I'd have to subclass over 40 classes just to be able to specify an initial size. I won't do that. It's nonsense. This is something that should be added to Area.mui because it's absolutely common to be able to specify an initial object size.

Note: See TracTickets for help on using tickets.