Imported widgets get wrong position with pos() and size()
Closed this issue · 18 comments
<Cabbage>
form caption("Example") size(300, 180), import("ImportExample.xml"), pluginid("xmpl")
Widgets pos(30, 30) size(50, 50), channel("Import1"), namespace("Widgets")
rslider pos(30,100), size(50,50) channel("Knob2"), prefix("Prefix Test: "), postfix(" Postfix Test.")
</Cabbage>
<CsoundSynthesizer>
<CsOptions>
-n -d -+rtmidi=NULL -M0 -m0d --midi-key-cps=4 --midi-velocity-amp=5
</CsOptions>
<CsInstruments>
nchnls = 2
0dbfs = 1
</CsInstruments>
<CsScore>
f0 z
</CsScore>
</CsoundSynthesizer>And the xml that renders properly:
<?xml version="1.0" encoding="UTF-8"?>
<plant>
<namespace>Widgets</namespace>
<name>Widgets</name>
<cabbagecode>
image bounds(0,0,50,50) colour(0, 0, 0,0) {
rslider pos(0,0), size(50,50) channel("Knob"), prefix("Prefix Test: "), postfix(" Postfix Test.")
}
</cabbagecode>
<csoundcode>
</csoundcode>
<help>
Example to show position difference in imported widgets when using bounds() vs. pos() and size()
bounds() will render in the correct position
pos() and size() will render in an incorrect position
</help>
</plant>Here's an example where it's position renders incorrectly:
<?xml version="1.0" encoding="UTF-8"?>
<plant>
<namespace>Widgets</namespace>
<name>Widgets</name>
<cabbagecode>
image pos(0,0) size(50,50) colour(0, 0, 0,0) {
rslider pos(0,0), size(50,50) channel("Knob"), prefix("Prefix Test: "), postfix(" Postfix Test.")
}
</cabbagecode>
<csoundcode>
</csoundcode>
<help>
Example to show position difference in imported widgets when using bounds() vs. pos() and size()
bounds() will render in the correct position
pos() and size() will render in an incorrect position
</help>
</plant>Thanks, I'll take a look.
@tgrey1, this appears to work fine for me here with the lateat dev branch? Both bounds() and pos()/size() give me the same positioning?
The imported knob doesn't appear roughly 30 pixels further to the left than it should? I can test again with the new build, but it definitely was for the one I tested with last night.
Interesting, when I swapped out bounds() for pos/size() I aw no difference in their positions? Can you try with the latest build and let me know. I might be dreaming 😆
Interesting, just to make sure we're talking about the same location... this was using bounds() for the image container widget in the xml file, not in the csd file calling the imported widgets?
edit: And will do with testing on the new build once it's done
I was testing with the rslider contained within the image widget in the xml code?
Ah, no... the image container itself!
I confirmed this still is present with the new build (it took a while to complete, so just got to test)
Also, this build seems EXTREMELY slow. It might be my system, but I don't think so... perhaps some very hefty debug code was still enabled?
Thanks, I see the issue now. Although I'm not sure what might be causing the slow-down you mention..
New builds on its way now that shouldn't hopefully address the pos/size issue.
Confirmed, new build fixes this... thanks!
I'll close this issue and open another for the performance issues if I can manage to track that down... so far it seems like it's only affecting to gentable widgets that's tables are being re-drawn based on widget inputs.
I'm reopening this because my fix causes another issue when dragging and dropping widget with the GUI editor. I'll try to get a fix for this tomorrow.
I had another look at this, and it's not that simple. I will return to it again, but for now can you just use bounds()?
Yeah, it's not a big issue at all right now. I'd like to convert everything to pos/size eventually, but it can wait.
Can I ask why? Seems to me that bounds() is tidier than two unique identifiers?
Because to me location and size are two separate attributes, especially if you start moving anything ;)
Really tho, it's just a brain thing... for some reason to me logically it makes more sense at first glace to see pos/size as discrete values. Is bounds preferred? I can start switching back.
I randomly decided to test this on an example or two today, and it appears to have "regressed to fixed"? ;)
Not sure when that snuck in, I hadn't been testing for it... but if that sounds right to you, this issue can probably be closed.
Regressed to fixed, hmmm 😆 Hopefully it does progress to broken again in the near future!
Already mentioned to Rory, but reopening for tracking... I was wrong in my testing.