Resizing Aligned content (split from wishlist)

Thanks for the reply. I took a look at the Epic Arpeggiator, it’s nicely done, a great tool! But it seems to me that you’re not facing the same problem as I. Your aligners are horizontal but your dynamic content is vertical so the aligners will never need to realign (or resize). In my case I have a vertical aligner with vertical dynamic content. The aligner is realigning it’s content to a dynamic size of other racks and doesn’t reduce in size.

What’s happening when we resize()? If I understand the API correctly we’re targeting an id of the outermost rack and asking it to regenerate it’s size according to it’s children’s collective size. For children that are racks with an undefined size, the sizes will also be regenerated, probably via resize() as a recursive function. Which would explain why aligners do not resize when resizing their container rack (because aligners don’t have a resize() method in the first place).

Then again I don’t understand why content is automatically resized when it grows but not when it shrinks? (maybe taktik has an answer?)

But a fix for my problem can be done, so maybe this isn’t such a big issue.
For this example:
The container is a rack (vb:column, vb:row)
The content is any ViewBuilder object
The aligner is a vertical_ or horizontal_aligner

  1. remove the aligner from it’s container
  2. remove the content from the aligner
  3. resize the container
  4. create a new aligner with the content (this aligner has now no size)
  5. reattaching the new aligner to the container.

This will force the aligner to regenerate it’s size to the reduced available space after resize.

I think it would be better to have aligner:resize() but a hack will have to do for now.

An aligner needs to be bigger than the summ of its nested views in order to align something. For example:

  
+-------------+  
| |V1|V2|  
+-------------+  
outer box is an aligner with alignment mode "right", V1 and V2 are some nested views.   
  

a resize() would make its alignment mode useless:

  
+-----+  
|V1|V2|  
+-----+  
  

So you could simply use a “row”, a rack instead of an aligner? Why do you need it to be an aligner at all in this case?

I think he wants to have certain stuff always off-centered depending on the amount child racks next to it That’s a tough one to maintain, because you need scale-tables for that and the solution Mogue already described is one way solve it.

Ofcourse, if this should be for centered stuff, i guess the better solution is using the margins instead.

Of course I don’t need it to be an aligner. But it’s more aesthetically pleasing, to say the least.

I realized this when I tried to contain the aligner within a rack that I resized. Resulting in what you point out. This is why a direct resize of the aligner should work in inversion of the rack:resize().

The aligner:resize() should be the same as rack:resize() for the unaligned axis of the aligner. But the aligned axis (ie. vertical for vertical_aligner) should resize to it’s parent’s size.

An aligner:resize() method (for the aligned axis) should resize to it’s parents size while rack:resize() should adapt to it’s chilren’s size. This is what happens when you initialize the views so it should also happen when you resize. You can think of resize as a general update function.

Achk, it’s hard to describe box model layouts through text without pictures.

Trying to put it simply: In my mind racks wrap children, aligners fill parents

This is for centered stuff indeed. How would you use margins?

Yeah, you have got good a point here (if you did meant that marging affects all sides of objects and fields)
I think that you don’t need aligner:resize() but aligner:realign(). This should then reread the new actual proportions of the field your realignable object is placed in and then readjust the position according to where you want it to have.

I think you can do this currently by simply stuff your row creations in a function
It is not the neatest way to do it when it regards code-friendly programming but it is one of the reasons i did it in a couple of tools:

[luabox]

create_obj(obj_chooser, ‘’, 265,0,0,area_to_process,‘chooser’,‘’, {“Selection in track”,“Track in pattern”, “Track in song”, “Column in track”, “Column in song”}, function(value) set_area_selection(value,vb) end,vb)


function create_obj(type,palgn,pwdth,pmin,pmax,pval,pid,pttip,ptxt,pnot,vb)

–This is the main GUI creation function
–It is not necessary to have a function like this, you can always embed the below vb:code
–into your source-snippets, this was just a test to see if structurizing it made things
–clearer.
–Descriptions for the less obvious abbreviations:
–p stands for Property, id = Identity, ttip = tooltip, not = notifier, vb = ViewBuilder

if palgn == ‘’ then
palgn = ‘left’
end

if type == obj_textlabel then
return vb:text {
id=pid,
align=palgn,
width=pwdth,
tooltip=pttip,
text=ptxt}
end

if type == obj_button then
return vb:button {
id=pid,
width=pwdth,
tooltip=pttip,
text=ptxt,
notifier=pnot}
end

if type == obj_checkbox then
return vb:checkbox {
id=pid,
width=pwdth,
tooltip=pttip,
value=pval,
notifier=pnot}
end

if type == obj_switch then
return vb:switch {
id=pid,
width=pwdth,
tooltip=pttip,
items=ptxt,
value=pval,
notifier=pnot}
end

if type == obj_popup then
return vb:popup {
id=pid,
width=pwdth,
tooltip=pttip,
items=ptxt,
value=pval,
notifier=pnot}
end

if type == obj_chooser then
return vb:chooser {
id=pid,
width=pwdth,
tooltip=pttip,
items=ptxt,
value=pval,
notifier=pnot}
end

if type == obj_valuebox then
return vb:valuebox {
id=pid,
width=pwdth,
tooltip=pttip,
min=pmin,
max=pmax,
value=pval,
notifier=pnot}
end

if type == obj_slider then
return vb:slider {
id=pid,
width=pwdth,
tooltip=pttip,
min=pmin,
max=pmax,
value=pval,
notifier=pnot}
end

if type == obj_minislider then
return vb:minislider {
id=pid,
width=pwdth,
tooltip=pttip,
min=pmin,
max=pmax,
value=pval,
notifier=pnot}
end

if type == obj_textfield then
return vb:textfield{
id=pid,
align=palgn,
width=pwdth,
tooltip=pttip,
value=pval,
notifier=pnot}
end

end

[/luabox]

Whenever the object is (re)created, the aligners shall also always adjust themselves accordingly/

IC. Thats indeed something we should consider.

That describes it very well, is exactly how the aligner was meant to work.

All this is a bit hard to discuss without some real life examples. Could you setup a simple view construct that shows the problem? Maybe we can then treat this like a bug and fix the “unaligned axis” resizing for the next update, can do this without a manual resize().

I attached an XRNX to this post, the simplest example I could think of.

Good stuff. Would it be possible to lose the rack:resize() too, automate shrinking all the way?

After giving the aligners some thought I see some potential in using them as containers. Let’s look at an earlier quote:

This is because currently aligners will address overflow of their size by acting as a rack. Which is not likely what we want (although it may be in some cases). Overflow can be addressed in many ways with cutting, scrollbars and other navigation.

Scrolling overflow could allow for better control of dynamic content. We can take a look at renoises Track DSP tab to see an example of what this might look like, when overflowing the renoise window we get a horizontal scrollbar. Could be thought of as a horizontal_aligner in left mode with scroll overflow.

With scroll overflow you could even further define dock spaces within renoise and create aligner views to adjust to the available space each time. Perhaps a solution to the “tools in renoise without dialog” ideas, you could define “spaces” as aligners and dialogs as racks.

But these ideas might be difficult to implement. I don’t think they’re critical but could be interesting related to requests I’ve been reading. It’s worth the thought.

Thanks for the example mogue. This makes it pretty clear.

Instead of fumbling around with new "resize"s, we should prefer straightening this approach:
“racks wrap children, aligners fill parents”

To do so, racks (column, row in the viewbuilder) should also automatically be shrinked as soon as you remove views from it or hide them. Right now they expand only. And we should force to resize aligners !always! to cover up its parents size. This will make the current rack:resize() obsolete and simplify things a lot.

I’ve tested a new implementation, but am not yet sure if we can add this in a 2.6.1 bugfix update. Will do some more tests to decide this. Even when not included in a bugfix, this should definitely be part or a bigger API update -> Renoise 2.X


As workaround, you can manually update the width of the aligner manually, to give it whatever size you want it to be. This is quite ugly, but will do the job for now:

  
local view = vb:column {  
 id = "dialog_id",  
 margin = 10,  
 spacing = 6,  
 vb:row {  
 id = "row_id",  
 vb:button {  
 text = "Toggle content",  
 released = function ()  
 if (content.visible == false) then  
 content.visible = true  
 else  
 content.visible = false  
 end  
 vb.views.row_id:resize()  
 vb.views.aligner_id.width = vb.views.row_id.width  
 vb.views.dialog_id:resize()  
 end  
 },  
 content  
 },  
 vb:horizontal_aligner {  
 id = "aligner_id",  
 mode = "right",  
 vb:text { text = "right aligner" }  
 }  
 }  
  

Sorry to reopen this issue. But it has not been properly addressed.

Aligners do not shrink properly yet.

I reattached the test tool with an updated API version and removed the dialog:resize() call as it is not needed anymore.

The test tool should return to it’s’ original size when the content is toggled off, but does not.

The aligner does shrink slightly, so it is being resized, but it’s not the right size.

It only aligns vertically but not horizontally when using more columns right? I experienced this problem with one of my own projects as well.

The issue is that the aligned axis of the aligner does not resize properly when reducing it’s parents content (ig. when the aligners siblings or their children are removed/hidden the aligner will still remain too big).

It happens with both vertical and horizontal aligners. See attachment.