Chris Millensifer have you zoomed out to see if anything is just out of the range of what’s showing? That’s what I found. Items don’t land where I would expect them to be. After adding an item, I have to zoom out to find it, and then drag it to where I want it to be.
Style copy works for objects in a panel if object copied is not contained in a panel. For nested panels, the top level panel is the one that gets copied, regardless of where the things that you’re copying are located.
So obviously something’s gone sideways with the way you point to things inside the wormhole: the top level panel is the only object being copied.
…but I’m getting that “trying to solve a triple integral in my head” feeling again, and, since I am not Stephen Hawking, I will trust in your brilliance to solve this, if you haven’t already ;-P
Half the time you’ve been fixing the bugs faster than I can manage to get a bug report written, so if it takes a day or two to figure out this one, I think that will probably be okay with my service. 🙂
No over achievement considering the number of bugs 😉
But the good news is that this one is mostly fixed. I say “mostly” because there is a functional problem here. What happens is that both the panel and the item report a click event. The app needs to select which one matters. Previously the first one was selected, and the panel was first, now the strategy is more elaborated: it selects the component that is either in the same container, or which is not a panel. This way it is possible to copy style between items inside a panel, and copy the style of a panel too, but this is not possible to copy style across panels, because usually in edit mode items from other panels are not selectable. So the new behavior is better, but not optimal.
< ![CDATA[
Yes, true that.
]]>
< ![CDATA[
I can’t get anything I add to a panel to show up. Is there some sort of secret to getting items to show up?
]]>
< ![CDATA[
Chris Millensifer have you zoomed out to see if anything is just out of the range of what’s showing? That’s what I found. Items don’t land where I would expect them to be. After adding an item, I have to zoom out to find it, and then drag it to where I want it to be.
]]>
< ![CDATA[
What Carolyn Boyle said. I added the same icon several times at first.
]]>
< ![CDATA[
Regarding the style copy, this is annoying, I don’t know how to fix this (yet) !
Regarding the bad position, I can see that too, when using an item detached from the grid !
]]>
< ![CDATA[
Pierre Hébert more (hopefully useful ) info:
Style copy works for objects in a panel if object copied is not contained in a panel. For nested panels, the top level panel is the one that gets copied, regardless of where the things that you’re copying are located.
So obviously something’s gone sideways with the way you point to things inside the wormhole: the top level panel is the only object being copied.
…but I’m getting that “trying to solve a triple integral in my head” feeling again, and, since I am not Stephen Hawking, I will trust in your brilliance to solve this, if you haven’t already ;-P
Half the time you’ve been fixing the bugs faster than I can manage to get a bug report written, so if it takes a day or two to figure out this one, I think that will probably be okay with my service. 🙂
]]>
< ![CDATA[
Is Pierre over achieving again?
]]>
< ![CDATA[
No over achievement considering the number of bugs 😉
But the good news is that this one is mostly fixed. I say “mostly” because there is a functional problem here. What happens is that both the panel and the item report a click event. The app needs to select which one matters. Previously the first one was selected, and the panel was first, now the strategy is more elaborated: it selects the component that is either in the same container, or which is not a panel. This way it is possible to copy style between items inside a panel, and copy the style of a panel too, but this is not possible to copy style across panels, because usually in edit mode items from other panels are not selectable. So the new behavior is better, but not optimal.
]]>
< ![CDATA[
I even follow that, Pierre. 😊
]]>
< ![CDATA[
Understood, sound like the optimal solution to me. Great!
]]>