Req: Better Actions and History Handling

[cathodeRay]

Fresh from the pain of trying to record a long and complex series of steps to set up a Wavelet Decomposition Action, and following up on a post by Ken, I thought it might be timely to start a new thread considering what people would like to see and have available in the History Panel and Actions. The two overlap but are not, obviously, the same. For me, the things I would welcome are:

The History Panel:

(1) the ability to select items in the History panel and convert them into an Action. It is very frustrating when doing experimental stuff to suddenly have a Bingo moment and then have to manually go back and tease out exactly what it was that worked. Yes, I should probably write down each step as I do it for future reference, but I am not perfect.

The Actions Panel:

(1) for me, at the moment, the whole thing is just too clunky. Recording a complex action is like walking on eggshells and through treacle. As noted in the previous post, recording the wavelet decomposition action was so painful, I gave up: so an action that could have been didn't happen.

(2) the current system of recording what you do is fine for simple actions and should obviously remain as a key way of setting up an action. However, when the Action is more complicated, it seems to me there are two things that would make a huge difference:

(a) the ability to edit the action as a text file. I find it much easier to scan and correct text (things like find, and find and replace can be a great help, and if the action involves repeating a number of steps over and over then cut and paste is very helpful etc etc) than to dance around in the Actions Panel wondering when it's all gong to blow up in my face.

(b) better debugging, notably a much easier way of stepping through a an action, either in part or in whole. This in fact is where I gave up on the wavelet decomposition action: I did record, or so I thought, after several tries, all the steps, but something wasn't right (running the action went haywire). Had I been able to step easily though the action, I might have been able to spot and correct the error (again, being able to view the action as text would also be useful here - the error might be obvious in plain (albeit code) text, and simply corrected with a bit of typing).

On a related matter, my hunch is the action went haywire because the action was selecting the wrong layers. As the action involved an awful lot of moving up and down through the layers, along with insertions and deletions, once it had got out of step with itself it just went more and more off the rails. I was using both the arrow keys and mouse to select the relevant layer - maybe that confused things? Again, if it was possible to see the action as text, then it would be easier to spot what was wrong. I do appreciate relative selection (move two layers down) is always potentially tricky: maybe the layers could either be given a (current) number (eg move to the layer that is currently third from the bottom) or the ability to move to a (uniquely) named layer. It might add the steps of having to name the layers, but that is often done anyway, and if implemented would ensure the correct layer was always selected.

Any thoughts anyone?

cathodeRay

[bkh]

(1) the ability to select items in the History panel and convert them into an Action. It is very frustrating when doing experimental stuff to suddenly have a Bingo moment and then have to manually go back and tease out exactly what it was that worked. Yes, I should probably write down each step as I do it for future reference, but I am not perfect.

Not sure if that's really useful. When trying an approach, I usually do a lot of trial and error, and sorting out what's needed and what's not is probably more work than to re-record what I really need.

(1) for me, at the moment, the whole thing is just too clunky. Recording a complex action is like walking on eggshells and through treacle. As noted in the previous post, recording the wavelet decomposition action was so painful, I gave up: so an action that could have been didn't happen.

Try to record partial actions (e.g., one radius at a time). You can even copy the radius 1 action, change the radius in the copy to 2, and you'll have the next step. Afterwards, you can either call them from within another action (you can use one actin within another, like a subroutine).

(b) better debugging, notably a much easier way of stepping through a an action, either in part or in whole. This in fact is where I gave up on the wavelet decomposition action: I did record, or so I thought, after several tries, all the steps, but something wasn't right (running the action went haywire). Had I been able to step easily though the action, I might have been able to spot and correct the error (again, being able to view the action as text would also be useful here - the error might be obvious in plain (albeit code) text, and simply corrected with a bit of typing).

But it's easy to step through an action: just play back each step separately. (I'd love a command where I can play back a step and PL advances to the next step automatically, but that's just a minor issue.) You can also insert break points using Pause commands (use "cancel" to stop at the break point, turn the break point off using the check mark). You can also edit the names of the action steps, e.g., to insert comments.

When developing actions, I always work like this, correcting errors and recording missing commands as I go. This is something that would be very hard to achieve using a text based approach.

Apart from the single step feature, one thing I'm often missing in the Actions panel is the possibility to select/copy/paste/delete multiple action steps at once. But again, that's a minor issue.

Cheers

Burkhard.

[cathodeRay]

Burkhard - I'm not asking for anything very fancy. Just the ability to read and edit the action as a text file. I could even live with it if it was stored as say an xml file. It is just the ability to go in and do a quick or for that matter major bit of surgery.

Converting the history into a script (action) is something vaguely remembered from an ancient version of Photo-Paint. I agree it isn't useful very often, but when it is useful, it can be very useful.

The wavelet decomposition action is an obvious candidate for a loop of some kind (no, I am not going so far as to ask for loops), and I did wonder about calling an action from within an action, but decided that as some of the steps differed in small but crucial ways, that would not work. Nor have I mastered how to step though an action, one step at a time, without doing an awful lot of mouse clicking to turn steps on and off (and sooner or later getting hopelessly confused. The wavelet decomposition action probably had getting on for a hundred steps in it, so it was very easy to get lost.

I also agree that the inability to select and work on multiple steps at the same time is unfortunate, but probably wouldn't relegate it to a minor issue! With that, as I think you are suggesting, I could have recorded one run of the loop, debugged that run to get it right, and then copied it four times, and made the small changes needed to get the desired end result.

cR

[bruce1951]

Er, ar, uhm, er some weeks back I also asked for a 'better' history feature. Got 'yelled' at!!!
I often do complex editing. Find the result I want and then think, "why didn't I record it as an action?" But if it was that simple every time you start a project you would record one HUGE action. Doesn't work that way. You would end up with something that has a LOT of undos in it.

I second the motion that the history be saved as a xml file. Give us the ability then to open the xml file as a text file. Then when you need it you can at least dump it and read through the history steps. Then cherry pick the history file to create an action. If not needed then it can't hurt having an xml file floating around. They are easy to delete.

How about giving us an option in Preference to record the history as an xml file. Then the ability to convert that xml file into a simple text file. Sounds easy hey???e

regards

[photoken]

(1) the ability to select items in the History panel and convert them into an Action. It is very frustrating when doing experimental stuff to suddenly have a Bingo moment and then have to manually go back and tease out exactly what it was that worked. Yes, I should probably write down each step as I do it for future reference, but I am not perfect.

Not sure if that's really useful. When trying an approach, I usually do a lot of trial and error, and sorting out what's needed and what's not is probably more work than to re-record what I really need.

That's where having a History panel with non-linear selections, undos and replays comes in very handy. You can do as much trial-and-error as you wish, and it's super easy to later select only the "good" steps to convert into an action.

[Herbert123]

I think actions are great to create relatively short and simpler chains of commands. Beyond that a scripting language is really the way to go.

Compare Krita: Krita currently does not offer scripting either. Last year most of Krita's users who sponsored their second Kickstarter (myself included) voted for the addition of Python scripting: https://www.kickstarter.com/projects/kr ... ts/1598331

Only two wishes stood out: a scripting interface (wish #1), and Interestingly enough the second most-wanted thing: SVG import/export. I am pretty sure that if SVG had already been implemented, scripting would have had attracted even more votes.

The Krita devs are well on their way now integrating Python scripting.

I really think this is the Achilles' heel of PhotoLine: the lack of a scripting language that exposes most (preferably all!) of its functionality, and offers the option to create custom GUI panels to control the scripts. The Hubers have mentioned before that they looked into scripting , but were debating how to implement this.

Perhaps a node-based "visual scripting" interface would be a possible solution? Similar to Fusion, Blender, and Nuke? With GUI elements control, and these noodles could also be linked to layers - that would be awesome to have.

Anyway, Python scripting in PhotoLine with custom GUI control would be absolutely awesome, and allow PL users to create their own custom functionality. We would no longer be as dependent on the Hubers for new functions, and we'd be able to share and/or sell our creations. Just look at the Photoshop ecosystem: many missing niche features are being catered for by users creating their own scripts.

I really think a scripting interface is the last crucial missing element in PhotoLine. Actions can only do so much, and become entirely unwieldy at some point.

[photoken]

Just look at the Photoshop ecosystem: many missing niche features are being catered for by users creating their own scripts.

I think that's the whole point -- PhotoLine is so feature-rich that the additional cost and complexity of implementing scripting can't be justified for the sake of allowing "niche features".

As a reality check, one only needs to look at Corel's PaintshopPro (which is a general-purpose image editor in the same price range as PL, costing about $20 more than PL). It allows Python scripting to control its behavior. I used to use that program before I discovered PL, and I still monitor PSP's user forum. Over the last 3 years, the thousands of user messages dealing with PSP's scripting fall into 2 main categories:

• Attempts to correct for PSP's severe bugs.
• Attempts to correct PSP's severely limited functionality.

It should be noted that well over 95% of that missing PSP functionality is already provided in PhotoLine.

When I first started using PL, I was surprised that it did not have scripting, but that surprise was simply because I was used to PSP having it. As I became familiar with PL's very rich feature set, I realized that scripting is very much not needed.

It's far better to spend the time implementing the requests for image editing features the PL users have asked for than to open up a whole new can of worms providing and troubleshooting a scripting capability.

[bruce1951]

As I see it one of the problems is not defining the 'problem'. And is it even a 'problem'?
I think what we are really looking for are new features. Then the 'problem' becomes something that is user dependent. I want, you want, they want. So whos 'wants' are more important? (My bet is the mass market simply wants a reliable feature rich editor).

Now if you start to include 'flexibility' and 'customizing' features you open up complexities and the possibility of new 'bugs/problems' that makes it very difficult for the developers to solve. Due to the users customizations. I would warn against going down this path.

The solution? Do what I want and forget everything else!!!!!

Seriously. I edit with a huge amount of trial and error looking for effects that suit the image I'm working on. Actions are great for 'common' repeatable adjustments. But what I want/need is a way to save all my adjustments. Undos and all. Then cherry pick that 'history' so that I can repeat the results without out the need for all the trial and error work. Simply give me the option, in Preferences, to save my history in some format that I can later recall/dump into a text file. Let me, the user, worry about how I use that file.

regards

[bkh]

Simply give me the option, in Preferences, to save my history in some format that I can later recall/dump into a text file. Let me, the user, worry about how I use that file.

Not a serious proposition, but maybe this makes my point clear: Press "record action" before you start your work. Save your action. Convert it to hexadecimal digits/binhex64/any other ascii format. Edit in your favourite text editor, convert back, load the edited action back into PL.

I guess that's not what you are asking for: you'll probably want a human readable representation of all the macro steps, including all parameters etc. Otherwise, you'll not be able to recognise the individual steps. (Probably still difficult enough to recognise your curves settings or similar if you just see the raw numbers and not the resulting curve – I still find double clicking on an action step and looking at the curve itself much more intuitive.) Even keeping track of what layer is the active layer can be really hard to follow, given just the text representation.

Honestly, if you have problems sorting out the action steps recorded by PL, I doubt that you'll succeed with a text based representation. Plus, as I wrote above, you lose all debugging facilities which PL provides to analyse the action. Keep in mind, the current trend in programming goes away from text based programming to more visual methods, especially for beginners (and I doubt that many PL users have many years of programming experience).

Cheers

Burkhard.

[bruce1951]

Burkhard I have no issues with Actions. My main issue with 'using' Actions is remembering to use Actions. The need to start recording before you start doing anything. And what if you have to work on many files in one day? There would be hundreds of Actions to name and keep track of.
So wouldn't it be easier to simply check 'Save History' in Preferences and have all files with a sidecar file?

But we all have different requirements. And as you point out. How much detail can be saved in a History sidecar file?

Maybe the developers can come back to us with what is and isn't possible before we kill too many brain cell brainstorming the impossible!

regards

[cathodeRay]

Interesting discussion, with as I see it many good points, but I do also see a common theme, which is that for many, actions quickly become unwieldy - as Herbert123 put it, 'entirely unwieldy', once you start to do anything more than a simple small number of steps action. As Bruce says, there is also the usability or 'ergonomics' of remembering to turn recording on and off etc, what I called the clunkyness. I suppose in another way it's another example of what I call the bookshelf problem: just as a bookshelf can only hold so many books, so our brains can only so many active ideas in itself at any one time. Since, present writer excepted, there are some very brainy people hereabouts, we might not be surprised that others less brainy struggle even more.

I agree with Ken that getting primary functionality in PL, as native tools in the box, is usually the best option. There might be a point at which the sheer number of options becomes unwieldy - maybe then would be the time to enable some sort of user-defined filtering on what is available. However, I am also not afraid of a bit of low level (actually I think I mean high level, because I do it in human readable plain language) scripting/programming. The tipping point, for me, comes at whatever point in the wavelet decomposition action that I became overwhelmed by the complexity of dealing with it only via the actions interface. That's when I thought a bit of text editing might have been a great help.

I'm not asking for a full blown IDE, or even loops etc, just the ability to open read and edit the actual action/action file. At the moment action.actions can be opened in a text editor (or a hex editor) and there is some human readable stuff in there; 'SetBackgroundColorAction' etc but the rest is gobbledy-gook (binary data?). If instead it had say 'SetBackgroundColorAction(128,128,128)', then I think we would all know what that meant - and how to change it, if we wanted to.

Useful as direct access to say Python would be for those occasions when it made sense, echoing Ken, I am inclined to think it appears most commonly in image editors that have significant deficiencies of their own. GIMP, for example, often installs with Python already fully embedded. But let us not forget that GIMP is still not fully 16 bit in its current stable release. Hullo? I did however wonder if there might be a way to send a PL image to a python script, much as we can send an image to an external editor. Maybe converting the .py script into a .exe executable - I presume that is possible - might do it, for those rare occasions when an external script was the way to go (eg my plotting input sat vs output sat - I very much doubt, indeed I wouldn't even ask for, the ability to do such plots natively in PL, but being able to do it externally in a simpler runtime way - well, that would be welcome).

I also take Burkhard's point about keeping track of what is the active layer in a text file, but this isn't insurmountable, and is a common problem, eg what is the active cell in my spreadsheet?

So all I am really asking for is that the actions file is written as a text file, not a mixed text/?binary file. It would then be up to us as individuals as to whether we chose to open read and/or edit the file.

The other thing is the History: I'm not to keen on side-car files - as others have noted it means a lot of file clutter, a lot of losing track of what's what eg when renaming/deleting etc - just the sort of unwieldyness I want to avoid. However, I would like just one thing: the ability to turn whatever is currently in the Undo list into an action, from which I could then cherry pick the bits I want to keep (ideally in a text editor - just go in and delte what is not wanted etc, if not through the Actions panel).

cR

[bkh]

Burkhard I have no issues with Actions. My main issue with 'using' Actions is remembering to use Actions. The need to start recording before you start doing anything. And what if you have to work on many files in one day? There would be hundreds of Actions to name and keep track of.

Of course one shouldn't need to remember to record an action – imo, PL might automatically record an action for every open document. For me, a good solution would link this action to the Undo list, so that you could select two stages in history and just ask PL to save the associated action steps to a new action. In this way, it would be relatively easy to pick the action steps you really need. Recording an action of an entire PL session, even with a single document and trying to find the relevant steps by hand is extremely difficult, and won't be much easier with a human readable sidecar file.

Since recording actions is already there, I guess that this shouldn't be a lot of work to implement.

I'm not asking for a full blown IDE, or even loops etc, just the ability to open read and edit the actual action/action file. At the moment action.actions can be opened in a text editor (or a hex editor) and there is some human readable stuff in there; 'SetBackgroundColorAction' etc but the rest is gobbledy-gook (binary data?). If instead it had say 'SetBackgroundColorAction(128,128,128)', then I think we would all know what that meant - and how to change it, if we wanted to.

Even a "simple" SetBackgroundAction command can get quite involved if you have to specify a gradient or a texture (not sure if actions allow to record patterns, but that would also be quite longish), and the output format has to identify all the possible variants (otherwise you can't read it back in), so even setting a simple background colour in RGB can't be written down that easily.

What about "CreateCurvesPanel(3, 5, 15, 164 , 158, 103 , 189, 146 , 215, 58 , 253, 233 , 5, 54, 148 , 174, 232 , 199, 171 , 203, 3 , 254, 240,
5, 15, 164 , 158, 103 , 189, 146 , 215, 58 , 253, 233 , 5, 54, 148 , 174, 232 , 199, 171 , 203, 3 , 254, 240, 23, 89, 17)"

This all can be done, of course (just write a program to decode/encode a binary PL action into something human readable)– I just doubt that this would be useful for many PL users.

Maybe converting the .py script into a .exe executable - I presume that is possible - might do it, for those rare occasions when an external script was the way to go (eg my plotting input sat vs output sat - I very much doubt, indeed I wouldn't even ask for, the ability to do such plots natively in PL, but being able to do it externally in a simpler runtime way - well, that would be welcome).

Normally, you'd just write a shell script (.bat file under windows) which calls python with your script, passing on the command line argument (i.e., the file to edit).

On macOS, you'll probably need an automator script which converts the Open apple event into a command line argument for your script. In any case, that should be easy.

Cheers

Burkhard.

[Herbert123]

Just look at the Photoshop ecosystem: many missing niche features are being catered for by users creating their own scripts.

I think that's the whole point -- PhotoLine is so feature-rich that the additional cost and complexity of implementing scripting can't be justified for the sake of allowing "niche features".

You are confusing "niche" with "hardly used". For example, sprite sheets are a common output format for game developers and web developers. I have to create these things regularly as well, which takes a long time to do manually. Sure, utilities exist to create these, but it would be far more convenient to export these straight out of PhotoLine.

If PhotoLine had had scripting, I would have written a simple script to do this automatically for me long ago. Even better, I could have created a small control panel for this, and shared it with anyone else who needs this functionality, opening up PhotoLine for other game and web developers. Now, however, it is difficult to convince these groups of users to even install PhotoLine, because base functionality is missing. Photoshop lacks a spritesheet export function - but someone wrote a script to take care of this (https://www.johnwordsworth.com/projects ... or-script/).

The PhotoLine devs only have a limited amount of time to work on new features. Off-loading part of the work to their user base just makes sense.

As a reality check, one only needs to look at Corel's PaintshopPro (which is a general-purpose image editor in the same price range as PL, costing about $20 more than PL). It allows Python scripting to control its behavior. I used to use that program before I discovered PL, and I still monitor PSP's user forum. Over the last 3 years, the thousands of user messages dealing with PSP's scripting fall into 2 main categories:

• Attempts to correct for PSP's severe bugs.
• Attempts to correct PSP's severely limited functionality.

It should be noted that well over 95% of that missing PSP functionality is already provided in PhotoLine.

PSP seems to be a quite bug-ridden mess nowadays. I understand from your experience that scripting in PSP is used as a stop-gap measure to fix things. I recall using it 15 years ago for a bit, but it just did not compare at all to Photoshop. I'd rather compare to Photoshop, and modern software such as Krita.

But in other applications scripting is not about fixing broken things. Why do you think the majority of Krita users wanted scripting? Because it gives us, the users, the option to extend Krita with new workflow (automation) features.

When I first started using PL, I was surprised that it did not have scripting, but that surprise was simply because I was used to PSP having it. As I became familiar with PL's very rich feature set, I realized that scripting is very much not needed.

You forgot to add [not needed] for you! I use PhotoLine within game dev, web dev, texturing, graphic design, image adjustment workflows. PhotoLine misses a number of crucial things that would be easily fixed with scripting. I cannot expect the Hubers to accommodate all my wishes or all your wishes.

It's far better to spend the time implementing the requests for image editing features the PL users have asked for than to open up a whole new can of worms providing and troubleshooting a scripting capability.

I feel this is a bit of a short-sighted view. The Hubers just do not have the time to implement all feature requests. Even massive development teams, like the ones working at Adobe, have to choose what to work on. Many feature requests could be resolved by the PL community. And I don't really understand your "scripting" equals "bugs" connection. A scripting interface does not automatically lead to more bugs, if well implemented. I would argue that it may possibly lead to less bugs, since not every single function for every particular workflow needs to be integrated in the base application.

It is great when features are built-in, but you, me, and the other PhotoLine users: we all have our own wishes and requests (which is great!). We cannot expect all of those to be implemented.

I would actually argue that a scripting interface would LIGHTEN the workload for the developers: no longer do they need to integrate every single bell and whistle in the main program, but can quickly and efficiently use their scripting interface to develop additional features. A scripting interface would open up new avenues for feature implementation to the Hubers as well. And debugging may be sped up as well, since it is no longer required to make changes to the main code base of PhotoLine. A script is far easier to debug than a function that was added to the main code base. That, at least, is how it works in other applications with scripting support. For example, PhotoLine's guide manager could have been easily done via scripting, instead of pushing it into the main code base, for example. And this also allows PL users to expand the existing guide manager with their own functions (like multiple guide systems).

Instead, PhotoLine remains a black box: we (the users) cannot extend its functionality at all. Sure, there are actions, but actions are very limited, and, besides, the current implementation is clunky and actions are difficult (often impossible) to debug properly.

Aside from all this, scripting is less about features, it is more about improving workflow integration. It's fine if you feel that your requirements are being met, but in my line(s) of work I am having to rely on too many external tools (in my opinion) for basic operations outside of PhotoLine to create assets. While the Hubers have been extremely helpful in implementing various feature requests made by me over the years, there are still ESSENTIAL fundamental things I cannot do in PhotoLine - things that are basic to anyone working in Web dev and game asset design. With a scripting interface I would not have to bother them all the time with requests, nor would I have to defend those requests against you or other users.

And scripting would allow me to install the functionality I need, while it prevents you, Ken, from having to deal with yet more functions in PhotoLine you never use and never wanted in the first place.

Scripting would open up PhotoLine to many professionals working in various industries and allow integration in various workflows. Scripting is about EMPOWERING your users.

[photoken]

You are confusing "niche" with "hardly used". For example, sprite sheets are a common output format for game developers and web developers. I have to create these things regularly as well, which takes a long time to do manually. Sure, utilities exist to create these, but it would be far more convenient to export these straight out of PhotoLine.

I'm equating "niche" with "not necessary for a general-purpose image editor", which means that those features will hardly be ever used by the image editing public. If you have a specialized need for a niche usage which is already met by existing utilities, the convenience of performing those steps in PL is not very convincing.

PSP seems to be a quite bug-ridden mess nowadays.

Your perception of that is spot-on!

I understand from your experience that scripting in PSP is used as a stop-gap measure to fix things. I recall using it 15 years ago for a bit, but it just did not compare at all to Photoshop. I'd rather compare to Photoshop, and modern software such as Krita.

But in other applications scripting is not about fixing broken things. Why do you think the majority of Krita users wanted scripting? Because it gives us, the users, the option to extend Krita with new workflow (automation) features.

I think its always very valid to measure PL against the "best in class", in this case Photoshop. But it's also imperative to never lose sight of the fundamental concept of PL being an image editor. There are already many complaints about Photoshop having become way too heavy and encumbered for that purpose.

Whether or not it is actually a "majority" of Krita users who wanted scripting, I always look at such requests with some skepticism because there are always many people who will always say "Yes" to getting more features.

When I first started using PL, I was surprised that it did not have scripting, but that surprise was simply because I was used to PSP having it. As I became familiar with PL's very rich feature set, I realized that scripting is very much not needed.

You forgot to add [not needed] for you! I use PhotoLine within game dev, web dev, texturing, graphic design, image adjustment workflows. PhotoLine misses a number of crucial things that would be easily fixed with scripting. I cannot expect the Hubers to accommodate all my wishes or all your wishes.

You're right -- for me, scripting is very much not needed in PL. The specialized fields you mention will necessarily have their own specialized needs. That's why this discussion is worthwhile. There's no way I will convince you that you don't need such-and-such a feature, nor am I trying to do that. We each express our opinion, debate the merits, and let the Hubers decide what is appropriate for PL.

It's far better to spend the time implementing the requests for image editing features the PL users have asked for than to open up a whole new can of worms providing and troubleshooting a scripting capability.

I feel this is a bit of a short-sighted view. The Hubers just do not have the time to implement all feature requests. Even massive development teams, like the ones working at Adobe, have to choose what to work on. Many feature requests could be resolved by the PL community.

For me, the choice of a piece of software is determined not only by the feature set of the software, but also by whether or not the concept and direction of the developers is in tune with my needs. PL does that for me, without scripting.

And I don't really understand your "scripting" equals "bugs" connection. A scripting interface does not automatically lead to more bugs, if well implemented. I would argue that it may possibly lead to less bugs, since not every single function for every particular workflow needs to be integrated in the base application.

The additional bugs and troubleshooting time comes from implementing the scripting interface. Even if the scripting interface is well-implemented, there will always be complaints that scripts don't work. Just read the messages in PSP's user forum for examples.

Non-Windows users won't like this, but the best implementation of scripting capability is to use Microsoft's Visual Studio Tools for Applications (VSTA). CorelDraw uses that, and it apparently requires little work for the application developer to implement, other than exposing the application's inner workings as a Common Language Runtime (CLR) framework. You get the superb Visual Studio development editor (complete with IntelliSense, code completion, etc.) to make coding very easy and smooth. In addition, you can write the code in the CLR language of your choice, C# in my case. Even with those advantages, I've experienced problems with having my code run when a newer version of CorelDraw is released.

Like I said, adding scripting adds more complexity, bugs and troubleshooting problems.

It is great when features are built-in, but you, me, and the other PhotoLine users: we all have our own wishes and requests (which is great!). We cannot expect all of those to be implemented.

Very true. But, again, I prefer to trust the Huber's decisions about that.

...there are still ESSENTIAL fundamental things I cannot do in PhotoLine - things that are basic to anyone working in Web dev and game asset design

Again, "essential" may or may not be essential for most users....

[bruce1951]

Ah a conspiracy. I've been trying to make a post along with an attachment. But they aren't being posted. Does someone not like me?

Ignore this as it's just a test!

Bruce