Editing features ( mega-topic ) ( unimplemented )
-
@Nils About "Variables". These are mostly supported in VS (styles are actually variables). The only missing thing is to add new "variable" types, like stroke width and maybe allow the combination of multiple variables to build up an attribute.
This is doable, but not immediately (not in then current sprint).
-
@Nils Question about Variables: would these be only real (number) values? or something else also?
The Styles panel already handles the variable editing scheme in general, so I would be inclined to have these "number" variables there also.
Having a separate panel is only advantageous if restricted to a specific variable type
(in case of Conditions, we have a Styles panel restricted to show condition variables). -
@vectoradmin I was thinking more about something apart from styles. As I outlined above I meant direct references to variables with arbitrary values in any field that takes a primitive value with the syntax # variable_name.
The reason I was thinking that was that I noticed you only add attribute styles step-wise and I thought "why not abstract this process in one sweep?".
-
@Nils said in Editing features ( mega-topic ) ( unimplemented ):
@vectoradmin I was thinking more about something apart from styles. As I outlined above I meant direct references to variables with arbitrary values in any field that takes a primitive value with the syntax # variable_name.
The problem with this is that it will only work for fields (values) that explicitly support this. Having all internal numbers as "variables" could result in some performance impact.
For example: currently a "shape" can a variable, as it is a larger "attribute", but the width of the rectangle shape cannot currently be a variable (detailed attributes). If we are to allow all detailed attributes to be variables, we need to "resolve" these, that means a "variant" like storage (more memory) and at least a check of their type when accessing, and this will slow things down considerably.
One thing that can be done, is to converge in the future to more and more variable use for areas where it is needed, as long as it can be handled without performance impact.
But there is an alternate solution for this, that is currently doable: using (numeric) variables to override deep properties in objects / attributes. This would have minor performance impact (and only if used), and would not require any changes to the storage or memory model of existing objects.
I just have to find the right UI presentation of this.
-
@vectoradmin said in Editing features ( mega-topic ) ( unimplemented ):
using (numeric) variables to override deep properties in objects / attributes
Yes, that is probably 98% of what I would use. I assume such overrides wouldn't affect clone links and such, right?
-
@Nils said in Editing features ( mega-topic ) ( unimplemented ):
Yes, that is probably 98% of what I would use. I assume such overrides wouldn't affect clone links and such, right?
Depends on what object the override is added. If added to the source object, then the clone would inherit it. If on the clone, then it would overwrite (localize) a cloned attribute of the source.
-
@vectoradmin I see. You mentioned not possible in the "current sprint". When do you expect the current and the next sprint to end approximately?
-
@Nils Thinking about this: the UI could be implemented in a way to hide the complexity from the user and have variable names in regular numeric fields.
The only limitation is that some fields would accept variables and other not. This limitation could evolve over time, if variable support is added to more places. -
@vectoradmin Why do not all fields have variable support? From a programming perspective that seems quite strange.
-
@Nils said in Editing features ( mega-topic ) ( unimplemented ):
@vectoradmin Why do not all fields have variable support? From a programming perspective that seems quite strange.
Internal class "fields" or numeric "fields" in UI?
I as referring to numeric fields in UI
In VS, internal class "fields" are properties (there are very few fields as in C++ syntax). These can have variable support if stored as variants (a lot are not), or if a variable override sets them (possible for all).
UI numeric "fields": these have an associated "formatter" that determines what is a correct input and how to interpret it. Most numeric fields have a number "formatter" type. These would need to be changed in resources.
