-
-
Notifications
You must be signed in to change notification settings - Fork 317
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic Groups: Allow dynamic groups to resize auras #4057
Comments
Link to an experimental implementation mrbuds@29c82b5 Idea was to have ability to set a minimum and/or maximum width & height
This approach resize each children, all grow functions needs to be slightly rewritten to handle it. An other approach i have in mind to simplify implementation is to make it change group scale instead of children's size. Handling of parent resizing is not handled on this implementation |
This comment was marked as off-topic.
This comment was marked as off-topic.
I guess I should post what I posted on your commit also to this ticket, so that it's all in one place: think this goes in the right direction. A few conceptual comments: Adding a fixed/parent size mode to dynamic groups changes that. For fixed mode, the DG now applies a size to its children.
This creates problems in three cases:
** Text Auras **
** Nested DGs **
For dynamic groups, they obviously don't have a static size. So if we don't have any fixed mode settings, I think it's obvious how it should work. The auras A get shown/hidden, C layouts A determines its size. GP is informed that C size change and uses C's dg own size to layout. If C has a fixed size, then that's taken into account in the layout, and its own size should respect the fixed size. But what if GP has a fixed size set and wants to set a size on C. That obviously can't work, as now the size of C is both controlled by itself via its children and GP. ** Data Size Condition Sizes **
** Animations **
** Layouting with region size ** I think this can be worked out for fixed sizes. I'm more sceptical about "parent" size, because it has all the same problems but also issues on its own:
WIth that said conceptually I think my preferred solution looks like this: Each region has 3 properties:
Setting any of them calls a function updateEffectiveSize(), which based on our logic sets the actual frame size to the effective size. Currently that is directly done in SetRegionSize, that basically inserts an additional indirection in between. The old code in SetRegionSize is moved to updateEffectiveSize, and SetRegionSize now calls updateEffectiveSize. I think the logic in updateEffectiveSize should be:
For Dynamic Groups
Now to your implementation, it's obvious a first take. I think instead of doing the size adjustments directly in getMinMax size, the size should be an output of the grow. Also some of the calculations are done per aura that never changes. As to your implementations, the most complex will certainly be grid. then centered and lastly the simple horizontal/vertical. For grid, let's talk through a complex example:
So first question if the grid exceeds the sizes, should everything be scaled by the same ratio? To make the big icons fit, their width needs to be reduced from 180 total, to 120. Should the small icons be also reduced in size? My conclusion Then we essentially rerun the layouting algorithm with the scaling factor. |
Currently dynamic groups take over the positioning of auras.
With dragonflight users have been experimenting/requesting functionality that allows for resizing auras.
One very common layout has a resource bar (Or in the case of rogue combo points) in a row, and below that a number of icons and the width of these should be synced by either resizing the resource row or resizing the icons.
Sometimes there are additional rows of icons, sometimes the aspect ratio of the icons should be kept.
Additional things to consider
Potential approaches are:
Multiple dynamic groups, e.g. for the progress bar adjusts to icons beneath:
** DG1 contains icons
** DG2 contains progress bar and is attached to DG1. DG2 is set to "adjust width to DG1"
More powerful grow functions
** [...]
The text was updated successfully, but these errors were encountered: