Have the "data" object from ScriptPanel on any ScriptComponent.

[Lindon]

@jonhallur said in Have the "data" object from ScriptPanel on any ScriptComponent.:

I find the data object on the ScriptPanel extremely useful. It is especially useful to pass information into components for LAF styling.
My preferred way of working is having all the components positions and layout not be in code, so that a non coder designer can design and layout the plug without having to shuffle around pixel values in a list somewhere. That way I can just loop through a list of control IDs data structure that contains all the information for how a control should be styled.

I wish that the data object would be available for all objects that inherit from ScriptComponent and I could easily do that change and make a PR if other people would find it as useful as I would.

Surely it would create some memory footprint, and I have no idea how much a new DynamicObject on everything would add, but assuming it is empty for most cases I think it would be minimal.

What do you think, would any one else use it ?

Alternatively, does anyone has other ideas for passing data into LAFs without changing HISE source code ?

well the "simple" solution is to put all this data into a json file...

[d.healey]

I have a script called Theme which is essentially a big object with all the styling info.

But it's mostly just properties that are set on init. What do you want to pass in your data object that isn't already available in the obj? I assume you're using local laf and not global so you can target functions to specific controls.

[jonhallur]

@d-healey that is absolutely true, I could make a separate local LAF object for each item I want to style. But I was thinking more in the spirit of data driven programming.

Lets image I'm making a toolbar of 20 buttons and I want each to have two separate SVG paths for the on and the off state for each of my buttons, 40 different SVGs.

LAF method: Make 20 local LAF objects, overwrite drawToggleButton 20 times, copy paste the same code only to change 2 variables in each function. Apply the LAF object to 20 Buttons.

Method 2: Make one LAF object, register one LAF function. Create a list of objects that contains the name of the button and both the SVG data variables needed for the button. Loop through the list of buttons, create paths from the variables, slap them to the data object and add the LAF object to the button in loop.

One is more verbose than other. Sure you can extract the functionality of your LAF function to a different function you pass the SVG data into as separate function parameters, but you would still have to write laf.registerFunction() 20 times.

Non coders would find it easier to come into a project, having only to edit a list that has a pretty straight forward structure, I would argue to it would be more of a learning curve to explain to them, find these functions, and change these two function parameters here.

[d.healey]

@jonhallur You only need to change the icon right, so put the icon name in the button's text property and now you can use the same local LAF function for all your icon buttons (this is what I do). https://github.com/davidhealey/LibreWaveBoilerplate/blob/master/LookAndFeel.js

[jonhallur]

@d-healey That is clever, thanks for this.

I still think the data thing is valid :)

[d.healey]

@jonhallur Sure it's valid, but I don't see a use case for it yet that isn't already covered in an elegant way.

[d.healey]

Here's an example. All the buttons share a single local LAF function, assigned in a loop.

They all have different icons, can have different colours, etc. All a designer would need to do is edit values in the property editor, they would never need to edit the script. It's also possible to have icons and text in the same button, but that's a little more complicated.

HiseSnippet 2477.3ocsXstihibEFlYXz18lDkUJO.n4W8Hl3f4lgrJZG6xXv.FWcigF5nnUtsMfMFaiuBrZe2xaPdUxaPxorc2Pm4dmD9A7UUcN041WU3iw9tZFAAt9EJdgxAOiBE+MklbvIbMZspoSAQdxD1p5c2qt0y1n.2AO0f.C8BEK9xdDIJdwqJj94e9Sbp1pNZFmlpPgYtlZFiL2ZFdZV76GZZaKnpanXt8Loa7dQMWGjqsaD3MurT0BdpZaTWYLVkH1KJUn3q6paF55OITMzH.jgyU+vj0tINYxOyLv7dvIgAzEl.aT1zEPqMs0wODoAEJT7U3Sw8Kyh6+PIIScyGm+T7+6SWn7IMNOGT7EeNWh9avkJdlK8pLW5GJMQy2zK7zJD+46KI5DZ3uTU6okiLYK7h+w2WB4BR3DRsUcigfOL3QMtpU0puqL70a+wKuzARrAPR1nLVMbcvk+xkW3arpbP7Jd0P0e7xKf5QPXYSxOk+Kk+ke8GKCet7hKu3O8mJypqe4E4hBK9lZsaQEVcln.VEuYNkGWxLAdm4OAud17sbhY38zss4zZ6vKX4z0yEueIkAq3cqtaf076uwWMGOpOdVlrhHNqtfrztX+TrhnvRuTLlOCuNQLgKGawxxPM07V2A7KvTxfeD6wIJjhmVevNtoC2mJacOhs4YmtlMb.uJfW7D7JuU0AeJC6Nr4.kf9slgctqdHwmX5x6IDtCuNMVxvKvKWmKaZr5bW+vS4ik6.bddBvhz023kiA6R0Soa3dORdKl3G6.amgSiElsd44WXsiBYwp4TAJJp2.UrrBTZEiRUWGJLOvEz7M.JJoPeET6OIBksqpNPR1RJjWkWPIRjVkAds+SJy0a2AJy1SVeSK70CoItORSpE1JHZG2FVsjwJQGa3Aofa8QUGpEBt+YXyaQsf0383ptdd7XK7xwPY6ZZg3wGUuoqGdjVycHo36VMPQyrcSrEWKGNQ6ogsZhiD65wccUkvbanHsY2C13L71njlXS+jcbryD2M1ZCpCXip0h7FyKcnhGd28NdnoR5ICNJOcWSbcKGefZreVTSrm5cAbZclEL9nqp6N71no6PZMm0DrwY3fIGZh6z1LlawVC+wV8tSyGu1s2T+wJl919XwjQ6Pt65MXnBk5wlXs1J6g3XYb8lXcmMIbKZWOZr0dZAe7L4Nfr9ArCsleBeria2V31LZIbahL1O1RahIXCVt56GCTPGe79Qz9ntTwhC461YTKbuEQIvwKEmgsvzRZwbSad2973XSns+CwwILeikxsvCuWKfKYc8iiOdayA.Udifb0wJ2JKrCe8pIAHsMlQCTRq42Pp4RyVjy2dfHE.7juDYiHyWfsYDFZ5rJ3ILt1sZCLNZoFFLXDWLEJglQSKGCGd5BXsIVTnE2zumLTYDhw85Fkftd.C0HdUVV5DD6NdpQVy6cGSBZCuYmgJJ8g8K3PkNbAhK5IqXE3FALwQT.VR2LBO5vlDjjdi5CO5ReKCtQqsc3Rns5OiAOTCUgvXnUXvUTp0gSxnFurBd4tHrVmdIHfUzbHuZJNPmuNTYSwIUOTcn0PILCV2sBCW6JFHYqaaJC1lMfgKGyx5DmIqBlZ.CdWOVv1yRwo9gn.ZceFPtvNbZS1yJeTtZPDNT+1XTCFIFv1M1fiQ.yoIX6CiFDiDIwB+sUpzBertTGto0sqLNOtazTBvsXhhvKrODgRFA4ni0L5zBGOfkjyGKSwfc5JC4bgaMf8nAdAEh0OrBv96JFCx0LBI0mBA476uINGaMut71brRXmZsf+DnCEZytJsGaEUYRLv1Rw2d27XbprPQQXD+VdlVXvgXQIB9q6jiEEhaBXCuVv7UqA1NY2pXXMpXjlKRDrsn.3GAFMEAaC6UDZgSvfQ7yZvPh6Jbn12rEzqd2CfsmNlhRl2RhNF3PPNZi5ZoQVTC4YvgGGh.ayTqKCdBjtPhyzE6wfWbMOB0vpOmLO838wXSRspZqnQfsyv1LvdLOEOsEu7HKl8CYH1Fg5xsDIyK0oBXa1oH9bbEB2HU1iQUtF3khFfsoSwTriPPb2VaBC99N8QnM9RckU50MIFeX07DjFaigfsMTLRPsmA9g07tg.200.hEd4JpL3qqMGgjRl2S9XeARb6Fl.7bsNQfsm.mIlRxQJg5vYIFGcNHtuIAzSsMFhaZwU2yfGrWfCcs90vdLukdL9Xsp.etFoVoNeSkbLvyc5uOCebbES3ro6JVRMsu7wJo0a2DB91MxwXlsfrhDtwwzy2bjyzRyfyM0hQcusBoFdM8pb7wMcPLXAdFVnVWgR1pSGx9kgawzOFmJ6zQTTiT1VQhA2EQA70YdqljikFPIjKqI2RHGEUgmTqH3E33diTRkMopAGpZC3rox8s2Fe1ev93kY4WU8EuzKWtO0Ee+54OF1HW2MrN5BFF1jGF6ziewEEF557A1Zjqlp8YJc0aezCyzfBddNy.3Y+DhbzBMcct5M59pIJtqVYajIxadW4kOr3p2U18dq2d4EfwuHFtQmbALLCkJXNXqg89hUjPJ6ozuJ6m.pDyv0r1dqUuhHrYnw1rUnS2OJ2XC+x+TYZppk+ykqR09sD2D1nkPe.ooqzG+jJMg8WIJDZrO7u8txo+wvulkjV55W9p8kMcdLErxHj01F4t0y0AFGb0atOKfdKD.6Id4GjdNCScJIklzt7gjPYWmwtgFxNW8VRM.rc4+ykVt7itFww7cssM7+nKS51w+yo3UNQau2v+ckiUsiLdTPncfm1iwq+55wPKKOclftNhNlgxdF4iEbs0I8NPveXGIExSzPuIuL2CATXZmI+t7NSxRfELgM4hRYo+pERc+y6Brv2f5z+2odsOh5SEIm0HsXkGQPT5Y3GZRRlE4MhgdTyZ35hR7FAaBc8RC4bhUghe2WQPu+jIEe+gyGjXpGt9zD7uesg4p0gmOCguWnXoRviiW3zoGPhW+ufO44fuA2g9S5NK95cmWWh7.a+Owep8o7m+98e89ykkd3tzOkO8gcPC8t6pGYqF9zF5Iu4h7EfSfOoKZRmxNAlgGN+Ma7Mzke0OaW9est3OTBaFps9i6iu3i3i.69+G9X96F42Vp6xkFZgmbvWURX9y8Eg7EL+MtQjprjZnuIPaJMNZ6DnRqY.V2wwvF17REeAgBlMtJYLICLwvQOc.gPjuHMYbw7EoeXwBaU07c+Ysr6UHu8kuKcFvmbReYSWTRhLt7i2FUpTUppE1Zpa9yZZjv+OBWY9w0o1yPm5OCcZ7Lzo4yPmVOCcXdF5z9ypC4cvwFE5tM63.LAta505EK10QEXVorvB+a.9NdTH

[jonhallur]

@d-healey I already agreed with you, no need to take me to school. :)

In my case I would just need to have object one level deeper with a list of on and off state.

g.fillPath(Paths.icons[obj.text][obj.value], obj.area);

And I agree, it is an elegant solution.
My mind is just already committed on the data object.

[d.healey]

@jonhallur said in Have the "data" object from ScriptPanel on any ScriptComponent.:

In my case I would just need to have object one level deeper with a list of on and off state.

This isn't necessary, let's keep our designers out of the code :)

You can use the text property for all kinds of magic. For example you could put on icon,off icon and in your laf function you can check if , appears in the text and if it does you convert the text to an array using join and now you can use the button's value to get the correct icon name.

My mind is just already committed on the data object.

Sometimes it's easier to change the way the system works instead of changing the way the programmer works :p

Edit: Oh I just noticed I have some implementation of that in the link I posted before (it's not as nice as the solution I just suggested though) - https://github.com/davidhealey/LibreWaveBoilerplate/blob/master/LookAndFeel.js#L293

[jonhallur]

You can use the text property for all kinds of magic. For example you could put on icon,off icon and in your laf function you can check if , appears in the text and if it does you convert the text to an array using join and now you can use the button's value to get the correct icon name.

String parsing in every draw call ?
Now you are just asking for bugs :)

[jonhallur]

This isn't necessary, let's keep our designers out of the code :)

@lalalandsynth straight from the horses mouth

[d.healey]

@jonhallur

String parsing in every draw call ?
Now you are just asking for bugs

There shouldn't be any issue with this, it's all happening on the UI thread (and I've been using it in a lot of projects :) ). There was a post a while ago from Christoph that warned against using external data in LAF functions, not sure if this also applied to local LAF. I'll see if I can find the thread.

Edit: Here it is - https://forum.hise.audio/topic/3228/look-and-feel-toggle-buttons-and-the-midi-sources-panel/26?_=1671280536688

[lalalandsynth]

@jonhallur I would have to agree :)

[jonhallur]

There shouldn't be any issue with this, it's all happening on the UI thread (and I've been using it in a lot of projects :) ). There was a post a while ago from Christoph that warned against using external data in LAF functions, not sure if this also applied to local LAF. I'll see if I can find the thread.

Edit: Here it is - https://forum.hise.audio/topic/3228/look-and-feel-toggle-buttons-and-the-midi-sources-panel/26?_=1671280536688

I know I am confusing the LAF for buttons draw functions and the setPaintRoutine() for panels, I know local LAF functions would not have access to the data object and this like the ScriptPanel functions have.

If I could access the data object in a LAF call that would also mean I wouldn't have to use external data, like he warns in this post.

[ustk]

@jonhallur I’m currently using external paths inside LAF, so I imagine this falls into the forbidden zone… What about colour constants ? (like Coulours.red) aren’t they considered external too ?

So perhaps in this case populating a data object prior to the LAF would make it more stable, if any of the above can create instabilities of course.

As for the relevance of a data object regarding the programming workflow, I can understand the importance of it though I don’t feel personally concerned (at least for today)

[d.healey]

@ustk I'm using some external data too in my LAF functions and haven't noticed any issues. I wonder if it was just Christoph being cautious or if the issue was fixed.

[Christoph Hart]

It's still a good advice to avoid using external data if possible, but I did in fact work on some multithreading issues since I posted the warning so yes by now it's safe enough to use static preallocated path objects in a LAF function.