Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#271 closed enhancement (fixed)

MUIA_IgnoreSameSize

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

Objects with an explicitly set fixed size (i.e. by MUIA_FixWidth) are now kept at this size even if the surrounding group enforces all child objects to always have the same size (i.e. due to MUIA_Group_SameSize set to TRUE). This makes it possible to have a fixed size spacing in a row of equally sized buttons.

Description

I think we need a new Area tag named MUIA_IgnoreSameSize. Imagine the following situation: You have a HGroup of 6 buttons and you want all of them to have the same size but you also want to have a fixed pixel padding space betweens buttons 3 and 4, i.e. in the middle of the 6 buttons. Let's say you want to have 100 pixels of padding space between buttons 3 and 4.

I think something like this is currently impossible because MUIA_Group_SameSize would affect the HSpace object used as padding space as well. But this group child should never inherit the MUIA_Group_SameSize! That's why I propose to add a new attribute named MUIA_IgnoreSameSize or similar. Children that have this attribute set, should simply be ignored by MUIA_Group_SameSize.

I think there is currently no other way to achieve what I want to do. If there is, just let me know. Writing a custom layout hook is of course not an acceptable alternative ;)

Change History (6)

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

Priority: undecidednormal
Status: newaccepted

This requests sound sensible.

I was wondering whether it would suffice already to exploit the already existing MUIA_FixWidth/Height attributes for this purpose. For example, MUIA_FixWidth is already set for something like HSpace(2). This would definitely be enough already without the need of three additional attributes(MUIA_IgnoreSameSize/Width/Height), but I cannot say if this would cause any unwanted side effects for already existing applications which might put fixed size objects in a group with MUIA_Group_SameSize/Width/Height. But on the other hand the objects in such a group would never have been sized as intended until now. When seen from this point of view then the automatic usage of MUIA_FixWidth/Height to prevent an object from being resized would be very intuitive and eventually repair such affected applications.

What do you think?

comment:2 Changed 4 years ago by Andreas Falkenhahn

I'd go for compatibility even if there are probably no apps that would be affected by your proposed change but who knows…. in earlier MUI versions MUIA_Group_SameSize overrode MUIA_FixWidth/Height so I'd keep it that way and add new attributes. If you don't want to implement three new attributes for IgnoreSameSize/Width/Height you could also just go with one single new attribute like MUIA_EnforceFixedSize. If this is set, MUIA_FixWidth/Height *will* override MUIA_Group_SameSize. Then it would be a reasonably clean solution that is backwards compatible at the same time.

comment:3 in reply to:  2 Changed 4 years ago by Thore Böckelmann

Owner: set to Thore Böckelmann
Status: acceptedassigned

My intended implementation of MUIA_IgnoreSameXXX would define the attributes as [I..] instead of [IS.]. Hence they must be specified at object creation time. But this will require a manual creation of an object which does the same job as HSpace(x), just to be able to use the new attributes. Being able to set() such an attribute would make things far more complicated, because then the layout must be recalculated after each modification of the attribute. This is why attributes like MUIA_FixWidth are not settable either.

However, deriving the desired inability to resize a fixed size object like HSpace(x) would be much easier from your personal point of view, because you won't have to change anything on the object creation, except adding MUIA_Group_SameXXX to your group object. And like I said before already, the fixed size nature of such objects would eventually work as intended without any additional work.

This is why I will make the behaviour "automatic" and derive it from the presence of the MUIA_FixWidth/Height attributes, which is the fact for HSpace() and VSpace() objects.

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

Resolution: fixed
Status: assignedclosed

In 4993:

  • Group.c: objects with an explicitly set fixed size (i.e. by MUIA_FixWidth) are now kept at this size even if the surrounding group enforces all child objects to always have the same size (i.e. due to MUIA_Group_SameSize set to TRUE). This makes it possible to have a fixed size spacing in a row of equally sized buttons. This closes #271.

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

Release Notes: modified (diff)

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

Milestone: future release4.0-2015R4
Note: See TracTickets for help on using tickets.