[SOLVED] Positioning DynamicDisplayable in LiveComposite

[Aoide]

I was wondering if it is possible to have the displayables within a DynamicDisplayable that is inside of a LiveComposite have different positions from each other?

Basically, I have code that is structured similar to this:

Code: Select all

LiveComposite(
	(h,w),
	(x1,y1), DynamicDisplayable1,
	(x2,y2), DynamicDisplayable2,
	(x3,y3), DynamicDisplayable3
)

Let's say DynamicDisplayable3 is used to switch between Image1, Image2, and Image3 (all of which are LiveCrop type displayables). Is there a way to make it so that the displayables can all have different positions in the LiveComposite? (Ie. when Image1 is being displayed it won't be in the same place as when Image2 is being displayed.)

In this thread Onishion suggested declaring them as an image and setting the position that way, but since they are LiveCrop displayables I can't do that. I tried putting a Transform() on the displayables both before I declared the LiveComposite and also when they were called by the DynamicDisplayable update function, but it had no effect.

I know there has to be a solution but I just can't see it... Any help on this matter would be much appreciated!

[Roboduck]

I had trouble with using LiveCrop and LiveComposite together too. What solved it for me was to use im.Crop instead of LiveCrop and im.Composite instead of LiveComposite.

[Aoide]

I had trouble with using LiveCrop and LiveComposite together too. What solved it for me was to use im.Crop instead of LiveCrop and im.Composite instead of LiveComposite.

Thanks for the advice! I switched LiveCrop to im.Crop and then tried to set the position using Image(), but it still displays at the coordinates specified in the LiveComposite (I can't use im.Composite because of the DynamicDisplayables) instead of taking into account the position specified in Image(). There has to be a step or something I'm missing...

[philat]

Hmm... I don't see a particularly easy way of doing this. If you really want to go through the hassle, perhaps wrapping the DD inside a ConditionSwitch with appropriate offsets (i.e., having the ConditionSwitch be a displayable containing the DD with appropriate blank space). That's a heck of a hassle though...

[Aoide]

Hmm... I don't see a particularly easy way of doing this. If you really want to go through the hassle, perhaps wrapping the DD inside a ConditionSwitch with appropriate offsets (i.e., having the ConditionSwitch be a displayable containing the DD with appropriate blank space). That's a heck of a hassle though...

Yeah, it would probably be easier just to recompile the LiveComposite with the new coordinates but I was trying to avoid that. Thanks for the suggestion, though!

[xela]

It's a bit of a weird setup, DD allows you have more control than a fixed (LC). You can use just the DD and control everything as you see fit.

[nyaatrap]

Rather than including DD in other displayables, including other displayables in DD makes more sense.

Code: Select all

def dd_func():
   #calculate layers in python
   return Fixed(*displayables)

[xela]

Rather than including DD in other displayables, including other displayables in DD makes more sense.

Code: Select all

def dd_func():
   #calculate layers in python
   return Fixed(*displayables)

That's what I said

[Aoide]

Rather than including DD in other displayables, including other displayables in DD makes more sense.

I mean, that's really a matter of opinion? Unless I find that having multiple DD is causing lag, it makes more sense for my particular design to keep the parts in their own DD, instead of trying to make a complicated switcher code for all the dynamic parts in a "parent" DD and using that to recompile the image each time it's updated.

In any case, I noticed that you used Fixed() in your example and realized that it was the solution I was looking for. I substituted it for the LiveComposite in my code and it worked basically perfectly. So, thanks for your help!

ETA: Actually, I take it back; Fixed isn't positioning properly. It looks like rebuilding the LiveComposite every time a part of the image needs updating is the only way to go :/

[xela]

ETA: Actually, I take it back; Fixed isn't positioning properly. It looks like rebuilding the LiveComposite every time a part of the image needs updating is the only way to go :/

LiveComposite is a function that returns Fixed, it creates one for you and positions your displayable within the fixed. It doesn't do anything else.

It's ok to recreate the displayable, it shouldn't cause lag or anything like that.

[nyaatrap]

return Fixed(d1(pos=(x1,y1)), d2(pos=(x2,y2)), xysize=(x,y))
DD is a displayable that you can control when to update. If your displyables need update, why not use it? You can also include DD in DD with no noticable performance issue (if you are using any im.Manipulators, they cause lag)

I think DD is the most versatile displayable among all default displayables. If DD can't work, then it's time to make your own UDD.
Make your Transform displayable in python is another solution.

[Aoide]

LiveComposite is a function that returns Fixed, it creates one for you and positions your displayable within the fixed. It doesn't do anything else.

Whatever it does to position the displayables within the Fixed was different than what I was doing and I couldn't manage to replicate it. LiveComposite properly displayed my displayables at the default transform; I tried a bunch of pos/anchor combinations with Fixed to do the same but nothing worked. I mean, I know it's possible to make it work right but it's not worth spending my time trying to figure it out. Recompiling the LiveComposite if the pos of a part changes is just easier within the system I have in place already.

DD is a displayable that you can control when to update. If your displyables need update, why not use it?

Well, most of the children of the LiveComposites are DDs, so they are what gets told to update. In the end i just went with having their update function call the function that recreates the LiveComposite when the position needs to be changed. It isn't exactly the most elegant solution, but it works and shouldn't be costly enough to cause lag. I'm glad I didn't have to make a UDD; those are a pain to code.

Anyway thanks again to both of you for your help!