Romulus, it looks like you missed my point completely.

First, I was mentioning the Powershell Toolkit simply as an example of "non-plugin thing" which apparently does NOT need to be deployed in Studio application folder and still works without problems (as opposed to your claims in the article).

This has absolutely nothing with PowerShell requiring IT knowledge or not. And while we are at that, RUNNING PS scripts does not require any it knowledge at all... just as RUNNING any application doesn't.

Maybe you think that PS scripts have to be run only from PS console, or so... that's simply not true. Not only it's possible to run PS script e.g. using a simple hybrid batch file (which is BTW what I use in my enhanced PS Toolkit), but PS scripts can be even compiled to standard executables, with normal GUI etc., so user doesn't even know that he's running PS script.

I'm not against plugins as a concept, when it makes sense... but I'm against nonsensical forced integration of everything just because someone finds it cool and wants to make a buzz about plugins.

Putting things closer to users does NOT mean to make everything a plugin...

You want to make things easier to use? Then fix the poor UX and some long-standing design flaws in the first place... stop leaving things half-baked and unfinished...

I mentioned applications depending only on libraries already present in OS to contradict your claim that standalone application MUST have an installer. Sure, complex applications MAY (and most of them do) need own installer, but it's definitely not a must. Especially if we are talking about small application which may be essentially just calling a few Studio API functions.

This leads me to my example of why I do not want Studio plugin, but standalone application - because I do NOT want to click million times to do my stuff. I want my actions to be scriptable - e.g. to create a project using info parsed in the form of plain text (list of languages, project location, TMs location, etc.) from some external system and passed to this application as command line parameters... and the same for e.g. importing translation packages - did you ever tried to import like 36 return packages MANUALLY ONE-BY-ONE (which is the only option in Studio - ref. above to the part about poor UX)? I better use the script to tell Studio "import all packages located in C:\foo into project located in C:\bar" and that's it! Why would I bother clicking through some GUI to export target files if it can be done easily using command like "ts et c:\bar d:\export" (which can be stored in a script, so I can do it using a SINGLE push on Enter)?

Seems to me that people are so degenerated by all the clicking and taping and scrolling that they don't know anymore what "effectivity" is and means :(

Romulus, it looks like you missed my point completely.

First, I was mentioning the Powershell Toolkit simply as an example of "non-plugin thing" which apparently does NOT need to be deployed in Studio application folder and still works without problems (as opposed to your claims in the article).

This has absolutely nothing with PowerShell requiring IT knowledge or not. And while we are at that, RUNNING PS scripts does not require any it knowledge at all... just as RUNNING any application doesn't.

Maybe you think that PS scripts have to be run only from PS console, or so... that's simply not true. Not only it's possible to run PS script e.g. using a simple hybrid batch file (which is BTW what I use in my enhanced PS Toolkit), but PS scripts can be even compiled to standard executables, with normal GUI etc., so user doesn't even know that he's running PS script.

I'm not against plugins as a concept, when it makes sense... but I'm against nonsensical forced integration of everything just because someone finds it cool and wants to make a buzz about plugins.

Putting things closer to users does NOT mean to make everything a plugin...

You want to make things easier to use? Then fix the poor UX and some long-standing design flaws in the first place... stop leaving things half-baked and unfinished...

I mentioned applications depending only on libraries already present in OS to contradict your claim that standalone application MUST have an installer. Sure, complex applications MAY (and most of them do) need own installer, but it's definitely not a must. Especially if we are talking about small application which may be essentially just calling a few Studio API functions.

This leads me to my example of why I do not want Studio plugin, but standalone application - because I do NOT want to click million times to do my stuff. I want my actions to be scriptable - e.g. to create a project using info parsed in the form of plain text (list of languages, project location, TMs location, etc.) from some external system and passed to this application as command line parameters... and the same for e.g. importing translation packages - did you ever tried to import like 36 return packages MANUALLY ONE-BY-ONE (which is the only option in Studio - ref. above to the part about poor UX)? I better use the script to tell Studio "import all packages located in C:\foo into project located in C:\bar" and that's it! Why would I bother clicking through some GUI to export target files if it can be done easily using command like "ts et c:\bar d:\export" (which can be stored in a script, so I can do it using a SINGLE push on Enter)?

Seems to me that people are so degenerated by all the clicking and taping and scrolling that they don't know anymore what "effectivity" is and means :(