Template classes for user defined complex item instances (re-usable)
Template classes for user defined complex item instances (re-usable)
Regarding elements which are made of multiple other elements (compound objects) it would be wonderful to be able to define a "template class" for such elements in order to instance them multiple times. Changing the template would also change all instances of this compound object.
This would allow to define "classes" with a user defined layout and inner logic and then create multiple instances of these. Each template would be made of all available other elements (including other template classes = nesting of template elements!) in LL and allow to manage this compound object as if it was a "native" element in LL.
Each template class shall really inherit its layout and behavior to all instanciated items of this template. So in a sense it acts like a real class.
The advantages are great:
- behavior and properties of a user defined design have only to be defined once and can be re-used multiple times
- changing the template "class" automatically changes all instances across LL = saves time and is really powerful
- the inner logic of a class would include scripts, variables, properties and events and defines the layout and behavior of a template class
Defining a template class would not even require a separate editor. All that's required would be a method to combine a selection of multiple elements in a template class. This class then is bound together as if it was one object.
Each template class would define some properties for the "outside" world so that you can still configure it. So a list of "exposed" propeties and methods as they exist for Java classes as well would be perfect to control an instance of the template class.
A additional page "public properties" and "public scripts" or something would make sense. All other properties and scripts are used internally only in the template class. So the user can define what should be exposed, including new user-defined properties that are used internally for calculations etc.
As an example a exspose "public property" could be a color. This color could be aplied to multiple elements inside of the instance. Variants of this color could be claculated inside the instance to generate shades of this color. But from "outside" the user only has to define one color and the rest is part of the template class.
Changing a template class would open the elements of the compound object as if it was on a separate desktop. There these elements live in their own local coordiante system and you can add an remove elements as desired and define the behavior of the template class through scripts, properties and variables.
I believe LL already has a lot of mechanisms to support such a template system. And it would be really very powerful.
I hope you like it
This would allow to define "classes" with a user defined layout and inner logic and then create multiple instances of these. Each template would be made of all available other elements (including other template classes = nesting of template elements!) in LL and allow to manage this compound object as if it was a "native" element in LL.
Each template class shall really inherit its layout and behavior to all instanciated items of this template. So in a sense it acts like a real class.
The advantages are great:
- behavior and properties of a user defined design have only to be defined once and can be re-used multiple times
- changing the template "class" automatically changes all instances across LL = saves time and is really powerful
- the inner logic of a class would include scripts, variables, properties and events and defines the layout and behavior of a template class
Defining a template class would not even require a separate editor. All that's required would be a method to combine a selection of multiple elements in a template class. This class then is bound together as if it was one object.
Each template class would define some properties for the "outside" world so that you can still configure it. So a list of "exposed" propeties and methods as they exist for Java classes as well would be perfect to control an instance of the template class.
A additional page "public properties" and "public scripts" or something would make sense. All other properties and scripts are used internally only in the template class. So the user can define what should be exposed, including new user-defined properties that are used internally for calculations etc.
As an example a exspose "public property" could be a color. This color could be aplied to multiple elements inside of the instance. Variants of this color could be claculated inside the instance to generate shades of this color. But from "outside" the user only has to define one color and the rest is part of the template class.
Changing a template class would open the elements of the compound object as if it was on a separate desktop. There these elements live in their own local coordiante system and you can add an remove elements as desired and define the behavior of the template class through scripts, properties and variables.
I believe LL already has a lot of mechanisms to support such a template system. And it would be really very powerful.
I hope you like it
- TrianguloY
- Posts: 109
- Joined: Thu Jan 24, 2019 9:46 am
Re: Template classes for user defined complex item instances (re-usable)
So, you mean expanding the current hierarchical properties (each container has default properties for their items, that can use them or override) to a sort of hierarchical templating system similar to classes where every 'style' is derived from an existing one (or even more that one with order).
This could be very powerful indeed! although will probably require big changes. Interesting nonetheless.
This could be very powerful indeed! although will probably require big changes. Interesting nonetheless.
Re: Template classes for user defined complex item instances (re-usable)
Yes you're basically right. However the "public properties" of template classes are overridden in the other direction. While the current properties are overriden on a hierarchy level below template properties are overriden a level ABOVE the defined template class. Because each template class defines a set of "exported" or "public" properties that can be overriden per instance.
You can really see the template class as a reference design that equals a Java class. It has properties (variables) and methods (scripts). If you instanciate such a template then all the attributes from the template class which were defined "public" (interface) are also present in the instance and can be overriden at EACH instance in a diffent way.
Internally the template class uses all these properties and methods to define a behavior and the layout / look of the element.
As an example let's assume you define an element which is composed of three other elements. An icon, a text and a background circle which is created by using a custom view.
The "interface" of the templete class exposes three properties: "label", "color" and "size". These properties are fully user added within the template class. These are initially not directly correlated to anything when you add them. They are a string ("label"), a color value ("color") and a ranged float from 20.0% ... 500.0% ("size").
Internally the template class applies the "label" property string to the text element that it includes. So the value for the text element in the template needs to be linked to the exposed property value of "label". For that it's required that properties can be evaluated using scripts or scriptlets so that something like "<template.label>" can be used to define the content for text.
The property "color" is used for the color of the circle. As the circle is created by a script in a custom view element this element reads the value for "color" within the script. The value color could be read by accessing "template.color".
The custom view script also reads the value of "size" that has been publically exposed. So the script would also access "template.size" to draw a circle wioth the user defined size.
Whenever an exposed instance variable changes the instance of a template needs to update itself.
Methods could be also done using scripts. So each template could expose methods which take none to several parameters. These methods could be called by the outer context which has access to an instance of a template. Calling this "method" would then call the script which is executed in the scope of the template and could do anything (because it's a script).
This is indeed a VERY powerful mechanism to extend LL by user defined elements which could be used almost as if they were internal elements. A library of such elements could also be saved and restored to be used on other devices or by other users.
The biggest advantage of this approach is that instances of such template classes would change if you change the template class. So "batch changing" elements regarding layout or behavior, adding or removing child elements is no problem anymore. Custom designs and behaviors can be done and re-used everywhere. Even on multiple devices.
Really hope that Pierre likes this approach
You can really see the template class as a reference design that equals a Java class. It has properties (variables) and methods (scripts). If you instanciate such a template then all the attributes from the template class which were defined "public" (interface) are also present in the instance and can be overriden at EACH instance in a diffent way.
Internally the template class uses all these properties and methods to define a behavior and the layout / look of the element.
As an example let's assume you define an element which is composed of three other elements. An icon, a text and a background circle which is created by using a custom view.
The "interface" of the templete class exposes three properties: "label", "color" and "size". These properties are fully user added within the template class. These are initially not directly correlated to anything when you add them. They are a string ("label"), a color value ("color") and a ranged float from 20.0% ... 500.0% ("size").
Internally the template class applies the "label" property string to the text element that it includes. So the value for the text element in the template needs to be linked to the exposed property value of "label". For that it's required that properties can be evaluated using scripts or scriptlets so that something like "<template.label>" can be used to define the content for text.
The property "color" is used for the color of the circle. As the circle is created by a script in a custom view element this element reads the value for "color" within the script. The value color could be read by accessing "template.color".
The custom view script also reads the value of "size" that has been publically exposed. So the script would also access "template.size" to draw a circle wioth the user defined size.
Whenever an exposed instance variable changes the instance of a template needs to update itself.
Methods could be also done using scripts. So each template could expose methods which take none to several parameters. These methods could be called by the outer context which has access to an instance of a template. Calling this "method" would then call the script which is executed in the scope of the template and could do anything (because it's a script).
This is indeed a VERY powerful mechanism to extend LL by user defined elements which could be used almost as if they were internal elements. A library of such elements could also be saved and restored to be used on other devices or by other users.
The biggest advantage of this approach is that instances of such template classes would change if you change the template class. So "batch changing" elements regarding layout or behavior, adding or removing child elements is no problem anymore. Custom designs and behaviors can be done and re-used everywhere. Even on multiple devices.
Really hope that Pierre likes this approach
Re: Template classes for user defined complex item instances (re-usable)
Because a picture is worth a thousand words I took the time to illustrate how template classes could be used.
The example constructs a template class that can be used for apps in order to give them a custom layout with a badge, a background circle and a label.
You could imagine much more complex designs here. It's just a simple example to show how this shall work.
Hope you like it
The example constructs a template class that can be used for apps in order to give them a custom layout with a badge, a background circle and a label.
You could imagine much more complex designs here. It's just a simple example to show how this shall work.
Hope you like it
- Attachments
-
- template class.jpg (928.14 KiB) Viewed 31418 times
Re: Template classes for user defined complex item instances (re-usable)
Once you have some template classes defined you can press [+],
go to the tab "templates" (which has yet to be added...)
and select your own class. This creates an instance of that
class with its own instance properties that can be changed.
It would feel like your own template classes were always
part of LL in the first place.
I believe this would be an amazing feature
go to the tab "templates" (which has yet to be added...)
and select your own class. This creates an instance of that
class with its own instance properties that can be changed.
It would feel like your own template classes were always
part of LL in the first place.
I believe this would be an amazing feature
Re: Template classes for user defined complex item instances (re-usable)
What's really important:
Instances shall CHANGE when the original class is changed. They are always linked to the original design of the template class. This shall work even when there are instances of the class already existing. These instances will change when you change the design of the template class. This way you can fine-tune a class until you like it. And even change it again at any time later.
Instances shall CHANGE when the original class is changed. They are always linked to the original design of the template class. This shall work even when there are instances of the class already existing. These instances will change when you change the design of the template class. This way you can fine-tune a class until you like it. And even change it again at any time later.
Re: Template classes for user defined complex item instances (re-usable)
sounds like a class idea (see what i did there ) probably to much work for the current version though maybe something for LLX2
Re: Template classes for user defined complex item instances (re-usable)
Thanks
Whether anytime soo or for a coming V2 update - this feature is one of the most powerful upgrades for LL and would let it stand out a lot against the competition! You could basically create your own custom widgets which include all elements from LL plus all widgets of your phone plus scripting plus all features that LL offers on top of that and it would be perfectly integrated with the launcher as well.
I would really love to design and create my own elements and then re-use them across all of my desktops. This would be an amazing addition to the feature set of LL! I believe it fits really well in there, too.
I really hope Pierre shares the same love for this feature and makes it a reality
Whether anytime soo or for a coming V2 update - this feature is one of the most powerful upgrades for LL and would let it stand out a lot against the competition! You could basically create your own custom widgets which include all elements from LL plus all widgets of your phone plus scripting plus all features that LL offers on top of that and it would be perfectly integrated with the launcher as well.
I would really love to design and create my own elements and then re-use them across all of my desktops. This would be an amazing addition to the feature set of LL! I believe it fits really well in there, too.
I really hope Pierre shares the same love for this feature and makes it a reality
Re: Template classes for user defined complex item instances (re-usable)
Great picture!
Yes of course I like the idea. And of course it's a massive change in the architecture The only way to do this properly is to rework some fundamental aspects of the app in a way it would make it incompatible with previous versions. For this reason I never implemented the class based approach. The only solution is to create a new app.
Having some kind of component based system is however possible (although without hierarchy). You can define composite items (panels is a way to do that), and expose a public interface (methods, configuration menus and screens, etc.). In short, this is object based, not class based. And for this, you need to make some scripts and that's a problem... Look at the bottom of the page of https://www.lightninglauncher.com/wordpress/scripting/, there are a few samples, maybe they can be of interest.
Yes of course I like the idea. And of course it's a massive change in the architecture The only way to do this properly is to rework some fundamental aspects of the app in a way it would make it incompatible with previous versions. For this reason I never implemented the class based approach. The only solution is to create a new app.
Having some kind of component based system is however possible (although without hierarchy). You can define composite items (panels is a way to do that), and expose a public interface (methods, configuration menus and screens, etc.). In short, this is object based, not class based. And for this, you need to make some scripts and that's a problem... Look at the bottom of the page of https://www.lightninglauncher.com/wordpress/scripting/, there are a few samples, maybe they can be of interest.
Re: Template classes for user defined complex item instances (re-usable)
ThanksPierrot wrote: ↑Sun Apr 14, 2019 8:12 amGreat picture!
Yes of course I like the idea. And of course it's a massive change in the architecture The only way to do this properly is to rework some fundamental aspects of the app in a way it would make it incompatible with previous versions. For this reason I never implemented the class based approach. The only solution is to create a new app.
Well and what does that mean?
- Class based approach in coming end of this year in a new app?
- Class based approach is coming much later?
- Class based approach will never come??
If I were you (and I am obviously not you ) I would finish LL as soon as possible with no futher extensions. Fix the little issues here and there, add minor changes but then leave it behind to start the "next generation" of LL - maybe just call it "Extreme Launcher" or "Launchzilla" or "Launchtime". Create a new app that builds on the experience of LL and goes way beyond. The core of such an app could be the mentioned class based system and then you could add requested alpha / clipping masks and many other things currently pending.
I would be willing to pay twice or even three times the price of LL for a new app based on this approach. It would be a whole new level of customizablity. Way beyond anything that's available right now. But it must be user friendly to use. I believe that without a potent editor for creating these classes and editing the instances of them it would stay a nerd's tool.
Scripting is not my issue - at all. I am a dev guy (mostly C / C++) and scripting / writing code is my daily business. BUT... I prefer powerful and flexible WYSIWYG editors over scripting because my phone is a tool that should serve me very quickly. Instantly. But still be VERY cistomizable. Scripting takes time and I already spend too much time doing home automation, music production and other fun stuff. You see - I almost write concepts for other apps (and that's not the only case here) So... Too many other projects and things going on. Otherwise I would eventually do it myself because doing an Android app would be interesting. But no time for that because I have a different focus ATM. Still I like to suggest things in hope they might be done by someone else Looking for these win-win things you know.
So I really hope that you can start this rather sooner than later. Because I (a) believe you are the right guy to do it and (b) the potential is definitely there. Done right this would be the most powerful Launcher for a long time to come.
So - not trying to persuade you... But would you, could you, maybe...?
Re: Template classes for user defined complex item instances (re-usable)
I'd like to do it, but as you imagine, this requires a massive investment. And that's currently a problem for me because I don't have much bandwidth.
Lightning has never been a profitable project and the development cost is way beyond the Play Store sales. It has been possible to develop it because I regularly spent time on the project for several years. Little things after little things, the app grew from a tiny app to a somewhat monstrous launcher. It has been a fully iterative project without plan nor roadmap, I made big mistakes, but overall the thing is working (more or less).
Now, I know precisely what should be done or avoided, and also I know how to do it, but the fact is that launching a new app is difficult without prior funding. I'm also unable to say how many time people would have to wait for a first version. This might well be too much.
Lightning has never been a profitable project and the development cost is way beyond the Play Store sales. It has been possible to develop it because I regularly spent time on the project for several years. Little things after little things, the app grew from a tiny app to a somewhat monstrous launcher. It has been a fully iterative project without plan nor roadmap, I made big mistakes, but overall the thing is working (more or less).
Now, I know precisely what should be done or avoided, and also I know how to do it, but the fact is that launching a new app is difficult without prior funding. I'm also unable to say how many time people would have to wait for a first version. This might well be too much.