Perspective wish list feature request

[PRAMANJ]

Layer is not an unreasonable request and its not difficult to build! Its just another property in each component telling which layer it belongs to! Rendering displays those components belonging to selected layers and hides others!

Of course its not that difficult to build a UI tool to make life of a user easier. In fact the UI editor tool for creating an HMI is a big product differentiator!. Like Vision has so may features built in over past decade. Perspective will also eventually reach that level and beyond using modern technologies which are superior than previous generation technologies.

However I think open sources should also not be ignored, so that we leverage what is already developed by others if possible. We must build on what’s freely available as far as possible instead of developing everything ground up again and again! But it has its own downside as well I guess!

[liam1]

Would it be possilbe to add the ability to create @keyframe code in the designer and link them using the class system without have to edit a css file in the themes folder? or add more functionallity to the styles sheets in the designer which expose this functionality?

[kyle_fineran]

@PerryAJ

As has been mentioned, some of these items are already on the roadmap. Specifically: 1, 2, 3, 4 (and 5 may come with 4) are planned for future releases. Don't have any estimate as to when.

Could we get an over/under on 3 years?

Two weeks ago when I found I didn't have a "group" tool like in vision,
and if I tried to move them all as one with coordinates it stacks them,
and if I undo that it sets them all to the previously calculated upper left of the whole selection, rather than putting them back,
I assumed this was a problem of a newly implemented platform, not something that had been known about for at least 32 months.

[PerryAJ]

I'm going to preface this with an admission that I'm not highly involved in Perspective these days, but since you quoted me, I'll offer what I can.

Two weeks ago when I found I didn’t have a “group” tool like in vision

No, it doesn't. Instead it provides first-class support for embedding 'views as components'. If you want a group, do it in a view, and embed that view into others. While slightly less convenient that Vision's system, it's a far more powerful way to compose and group collections of components and offers a ton of benefits that Vision groups lack. If it doesn't meet your needs, then let us know why.

and if I tried to move them all as one with coordinates it stacks them

I'm assuming you are editing positional properties of multiple-selections? If true, I think this is more of a misunderstanding of how multi-selected-component property editing works. It's stacking them because you are literally telling it to set the same value to the x/y of all the things you have selected. I think there's maybe room for adding some sort of 'relative selected component movement', can see something like that being useful. Not planned right now AFAIK. Moving groups is possible with both the mouse as well as hotkeys. Multi-select components, moving with the mouse or arrow keys works.

and if I undo that it sets them all to the previously calculated upper left of the whole selection, rather than putting them back

Undo/Redo has seen a ton of work since the original release. What you describe sounds like a bug. Editing multi-selections should appropriately play into undo/redo as far as I am aware. I'll make a point to try and verify and will create a bug ticket if true.

Going back to the original list:

1. While possibly still needing some attention, undo/redo supports the majority of interactions that one may do in a perspective view editor.

2. Done

3. Done (not sure about animated movement, would have to check)

4. Partial Solution - the pipe and symbol system was created to solve the most common problems people face when trying to create P&ID screens. Basic Vector drawing tools might some day come into perspective, but not planned right now - Inkscape is a free and open source option that's super powerful. Some learning curve, but is so much more capable than anything we'd ever add to the Designer that it's hard to justify trying to make a lite clone of it. Just doesn't make a lot of sense for us to dedicate the time to it when there are still so many other highly requested things to address.

5. Not sure if this has changed.

6. Reporting Done. SFC not.

7. As noted elsewhere in the forums/posts, controlling zoom in a browser from the client is not really feasible - The 'cluttering/decluttering' behavior is something we still plan on supporting and it will support behavior akin to 'zoom in and out', but won't actually change the browser's zoom. Some "layer" or "layer-like" system is likely to play a role in order to trigger component visibility depending on the context/settings of the container (e.g. - zoom level, size, or some other environmental state). No timeline, but we're edging closer to getting something going here than we were last time I responded.

8. I don't think this is something that's feasible right now, and probably not likely to be so in the future. That said - improving the APIs, tools, and documentation for perspective component/module authors is on the TODO list, and should get some attention in the coming months.

9. Again - composing views is the 'native perspective solution' to grouping

10. Not sure where this is at.

11. Done.

12. Not planned at this time.

13. Not planned at this time. I won't say 'never'; we've certainly given the idea lots of thought over the years, but at this moment there is no plan to support client-side JS scripting natively in Ignition

14. IIRC, touch is supported in some of the charts, but may benefit additional touch behaviors.

15. Adding custom fonts is supported (discussed here), but there is still room for improving the Designer and Client Session handling to make the process easier. No plans right now AFAIK.

So I guess that's the update I can offer right now. Of the 8 or so wish list items that we had planned on supporting, most of them are now in the product. One is still in planning stages, and a couple more I'd have to look into.

Needless to say, Perspective is far from 'done' (probably won't ever be 'done'), and there is still a lot on the roadmap in terms of features, and improving stability/performance is a never-ending quest, but we continue to make strides.

[nminchin]

@PerryAJ

it’s a far more powerful way to compose and group collections of components and offers a ton of benefits that Vision groups lack

Embedded Views are to Perspective as Templates are to Vision, so this isn't really a benefit for Perspective as Vision has a directly similar component for that.

I agree 100% that 'grouping' in Perspective is rather frustrating, especially for coordinate containers, for a few reasons (keep in mind I'm speaking from 8.1.5 and have no idea if any of these have been remedied):

• to group components, you add them into one of the various container types in Perspective (coord, flex, etc.). But you can't select multiple components and add them into one of these containers directly from the context menu like you can in Vision. You can add a single component to a container but not multiple.

• nested coord containers are interesting beasts to configure and get them to scale properly with the parent. TBH I don't know why there is a prop.aspectRatio where you have to manually create this ratio field. There should just be a "maintainAspectRatio" boolean as why would you ever set the aspect ratio to not the aspect ratio of the designed container size? You either want to ignore aspect ratio or you want to use the ratio of the designed component

[PerryAJ]

Fair points Nick.

• to group components, you add them into one of the various container types in Perspective (coord, flex, etc.). But you can’t select multiple components and add them into one of these containers directly from the context menu like you can in Vision. You can add a single component to a container but not multiple.

You mean as in selecting multiple components and choosing the 'wrap' them in a new container? I know there are some significant challenges to trying to re-map component locations, and I'd guess that's the primary barrier to more complex behaviors like this. Still, would be nice to support.

nested coord containers are interesting beasts to configure and get them to scale properly with the parent. TBH I don’t know why there is a prop.aspectRatio where you have to manually create this ratio field. There should just be a “maintainAspectRatio” boolean as why would you ever set the aspect ratio to not the aspect ratio of the designed container size? You either want to ignore aspect ratio or you want to use the ratio of the designed component

I like this idea, will make a ticket to see if the perspective folks think it's something we should look at.

[kyle_fineran]

Thanks for the response.

I find embedded views to be an unsatisfactory replacement for being able to quickly group and ungroup things. For me, its a sandboxing work flow issue. If I knew how I wanted things grouped and arranged then it would be no big deal. I’d group them from the start, get them all aligned, and then play with the embedded view. But I don’t know my layout from the beginning, I figure that out through trial and error, moving things around until I find a configuration that works well. When the alignment of a particular set of components requires navigating to another window, and you cant see how its going to work with the big picture while you’re editing it, it makes things more challenging.

The stacking when I assign them all the same coordinates was the part that made sense, I apologize for lumping that in like it was one of the problems. It was wishful thinking when I didn’t find a “group” tool. I thought “well maybe it’s just clever enough that it will move the whole selection rather than each component.” Turns out no, and that’s not that surprising. The part that was surprising and frustrating was when I hit undo and they all just moved to a slightly different location and remained stacked. I got to go through and realign all of them manually.

After your response I wondered if maybe I just did something wrong, so I replicated it with a simple test. 2 components, select both, x and y read as the x and y of whatever component was selected first. change a coordinate, it stacks them. Hit undo and it changes the edited coordinate back to what it read before, but for both components, so they remain stacked, at the original location of the component that was selected first.

Lastly, sorry about the snark. I should be better about letting my frustration pass before sending off messages.

[PerryAJ]

I find embedded views to be an unsatisfactory replacement for being able to quickly group and ungroup things.

I can see how that might not be the ideal workflow. Not being as involved with Perspective lately, I'm not actually sure what's on the roadmap; I know design improvements are an ever-present focus, so I'll make sure appropriate eyes see your post.

Hit undo and it changes the edited coordinate back to what it read before, but for both components, so they remain stacked, at the original location of the component that was selected first.

Ya, I don't think this is working as intended. I'm opening a ticket for it.

@kyle_fineran

Lastly, sorry about the snark. I should be better about letting my frustration pass before sending off messages.

It happens, we're all guilty of publishing something on the internet that could have perhaps been a little more tactful. I also know what it's like to be frustrated by software that does something it shouldn't or is unexpected, think most of us can relate. Obv though, we really don't want users having these kinds of frustrations, and I'm glad you said something - we can't fix what we're not aware of.