Plugin scripting poll. Please participate

Only forum where polls are allowed. You may announce a new poll in the matching support forum.

Moderators: white, Hacker, petermad, Stefan2

Post Reply

Do you see a benefit to script plugins?

Yes, it's much quicker to write and make use of scripting modules like Python or Ruby
8
32%
No, I like good old fashion Delphi plugins for speed
4
16%
No, Completely useless
1
4%
No, I prefer fast and small C++ plugins
8
32%
I have no clue
4
16%
 
Total votes: 25

billiebub
Member
Member
Posts: 187
Joined: 2011-04-12, 19:49 UTC

Plugin scripting poll. Please participate

Post by *billiebub »

I'm posting a poll to see how many people see it beneficial to script plugins. An an example, write plugins in Python scripts to make use of its rich modules and API.

A benefit to this is if you need something quick and want to make use of the different plugin interfaces (Lister, Content, Compression, and File System).

Quick plugins like parsers, malware checkers, etc.

Please share your comments or examples of how you see it or not see it beneficial.
Sob
Power Member
Power Member
Posts: 941
Joined: 2005-01-19, 17:33 UTC

Post by *Sob »

Well, sure, it could be benefical. Putting something quick'n'dirty together is almost always faster using some scripting language. It's just that I'm not sure what exactly you're asking for.

Either there would have to be some kind of wrapper, script intepreter embedded in dll or something. Probably doable, but not easy or practical in all regards. There's at least one good thing about this, you would not need cooperation from author.

Or you do not really want plugins in the current sense, but rather some script intepreter directly in TC, i.e. internal scripting. But I don't see how this could easily work. Some limited scripting maybe. But "Python with everything"? How?
User avatar
Balderstrom
Power Member
Power Member
Posts: 2148
Joined: 2005-10-11, 10:10 UTC

Post by *Balderstrom »

Prior to TC x64, I could get most things accomplished with AHK as necessary - although some hackish workarounds were required. Unfortunately, TC x64 makes most interfacing via AHK problematic due to all control elements having a WindowXX class name.

If Ghisler would do a little more work on the WM_COPYDATA messaging that was added to TC8 -- e.g. more messages that could be sent/acknowledged by TC and responded to (messaged back), then we wouldn't need internal scripting at all.

Already we can send pretty much any command to TC, aside from the ones that require input, except for CD. We can use WM_COPYDATA to query a handful of things from TC, and if it was expanded almost anything could be accomplished with a scripting tool.

I mean, with a little work even you could use a TC tab as a virtual-file-panel that doesn't require such an obscure syntax to use - like MVV's does, and doesn't suffer from CMD.exe incompatibilities.

I didn't vote, I think the Poll is highly incomplete when it only mentions Python and Ruby --- considering pretty much ALL the scripting that has been done with TC in the last 10 years has been AHK, AutoIT and PowerPro.

Also, Polls are supposed to be in the Poll forum only.
User avatar
Hacker
Moderator
Moderator
Posts: 13052
Joined: 2003-02-06, 14:56 UTC
Location: Bratislava, Slovakia

Post by *Hacker »

[mod]Moved to the Polls forum.

Hacker (Moderator)[/mod]
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
billiebub
Member
Member
Posts: 187
Joined: 2011-04-12, 19:49 UTC

Post by *billiebub »

Either there would have to be some kind of wrapper, script intepreter embedded in dll or something. Probably doable, but not easy or practical in all regards. There's at least one good thing about this, you would not need cooperation from author.

Or you do not really want plugins in the current sense, but rather some script intepreter directly in TC, i.e. internal scripting. But I don't see how this could easily work. Some limited scripting maybe. But "Python with everything"? How?
The whole point of this is to leverage the richness of other languages in an interpreted form for rapid development. In other words, to have plugins written in a scripted form and making use of the richeness of such scripting languages by using its modules (Python for examples has many modules that are very beneficial and easy to use). In a few lines of scripting code, one could develop a plugin that does all sorts of things by relying on the scripting languages modules.
billiebub
Member
Member
Posts: 187
Joined: 2011-04-12, 19:49 UTC

Post by *billiebub »

I didn't vote, I think the Poll is highly incomplete when it only mentions Python and Ruby --- considering pretty much ALL the scripting that has been done with TC in the last 10 years has been AHK, AutoIT and PowerPro.
@Balderstrom, it seems like you're hacking your way around TC using Windows messaging APIs through the use of AHK, etc. That's fine for a while, but you seem to have issues now with the 64-bit version.

So, the hacking and bastardizing way of doing things will eventually come to a halt. The whole point of this poll is to provide the option to write plugins using a scripting language. How you ask? embed a scripting engine such as Python or Ruby, or whatever into TC and start writing the plugins in one of them. Simple, clear, and rapid
billiebub
Member
Member
Posts: 187
Joined: 2011-04-12, 19:49 UTC

Post by *billiebub »

But "Python with everything"? How?
Python has a clear description of how to embed the interpreter into applications. Check the link out:

http://docs.python.org/3/extending/embedding.html
User avatar
Balderstrom
Power Member
Power Member
Posts: 2148
Joined: 2005-10-11, 10:10 UTC

Post by *Balderstrom »

I said some of the things were hackish since unlike a plugin en external script doesn't have direct access to some things.

The problem with TC 8 x64 are that everything except for the Filepanels have a class of "WindowXX" e.g. Window1 Window2 etc. Now since depending on the user's prefs certain interface elements may or may not be present - which means you can't reliably query/detect a given interface element by name, since Window3 will mean one element when certain things are enabled, and something else when they are not.

Prior to TC8 x64 and still true for x32, you can query a given control by a fairly distinct name (aside from a few exceptions - which was the workaround part I was referring to).

As I stated, if WM_COPYDATA messaging was expanded to include the ability to specifically query for either:
1) What is the current name of the element
2) What is the current ID of the element, AND Possibly
3) What is the contents of an element

Then we could reliably get information out of TC without workarounds. And it would work the same in TC x64/x32.

E.g. the ability to "ask" TC what is the name/or ID of the command-line, then one could reliably query the text in the command-line, or set text in the command-line instead of trying to figure out which given "WindowXX" name relates to the command-line.

Now one exception is the current Tab/the Tab control name/ID. Just having the control name/ID of the tab isn't enough as that info is private as far as Windows is concerned, and it can't be queried normally. To accurately get the current Tab-name/or current tab number - that would specifically need support in WM_COPYDATA --- but most everything else could be done just by reliably being able to find out what a given control's name/ID is.
*BLINK* TC9 Added WM_COPYDATA and WM_USER queries for scripting.
billiebub
Member
Member
Posts: 187
Joined: 2011-04-12, 19:49 UTC

Post by *billiebub »

@Balderstrom, I'm referring here to writing plugins in a few lines of code in notepad and be able to make use of it very quickly. If I'm writing the plugin in Python and aiming to develop a content plugin, I would open notepad, implement all the content plugin interfaces and save.

I'm not talking about querying TC for elements, controls or what not. For that I would need to make use of the messaging API you've mentioned but that's not what I'm trying to get across here.

In the simplest and layman's form, It would be such an amazing thing to open notepad, write a few lines of "readable" interpreted lines of code that I can call a plugin and be able to use in TC. Much of what we can already do with the scriptWFX but in a generic and wider use to include all plugin interfaces.
User avatar
Balderstrom
Power Member
Power Member
Posts: 2148
Joined: 2005-10-11, 10:10 UTC

Post by *Balderstrom »

I don't see how this would be possible without an overhaul of the current Plugin system, which would necessitate intervention by Mr.Ghisler.

It would require either:
1) An interpreter layer that can message between the script and the current plugin-system -- which expects C++ code (if I recall correctly).
or,
2) A complete overhaul of the plugin system to simplify plugin creation from any standpoint, be it C++, Pascal, or another language.

Depending on usage, option 1 would likely be too slow for certain plugin types, e.g. FileSystem. Also option 1 would quite possibly require a significant library setup.

Now one thing to consider, Lazarus (x64 compiler) has scripting built-in (Pascal Script) - but afaik Ghisler has not enabled that aspect, or has provided no interface for it.

There would definitely be some advantages to a simpler option for plugin creation - also some negatives ... if the plugin interface/creation becomes too easy, then you will likely wind up with a huge swath of plugins being submitted: becomes even more difficult than it is now to find a quality plugin to do a given task.

Now you may not think we are talking about the same thing, but there are more similarities than differences.

What you are basically talking about is a way to get information from TC, easily modify it via a script and hand it back.
E.g. plugins that can provide information in a custom-column, or a Search, MRT, or SyncDirs plugin.

I could definitely see an advantage to that, and it would certainly benefit TC-Users in general to have two different types of plugins.
Basic: Simple Data manipulation (read/process/return)
Advanced: The current plugin implementation.

Whereas I was talking about getting information from TC (Gui/Control), modify or do something with it, and hand it back or send a command after processing. The only real difference between what you are talking about is a more refined way to hand the data back.

Both are really (primarily) about (easily) Getting Data from TC and being able to give it back, as either a modification of said data or into a given TC GUI element. The only non-plugin aspect of what I was talking about is the ability to relay a command back to TC.

If any of this was to happen, it wouldn't make much sense to leave out the aspect of handing a command back to TC to perform. Otherwise you would wind up with a pretty incomplete implementation.

I think it would be great if something like this was done, but it seems awfully close to internal-scripting (as far as the support code that would be needed to implement it) ... and Ghisler has stated he is not interested in doing that. The file managers that have provided an internal scripting interpreter are pretty cool (at least in that aspect) and in the power it gives their users to control and manipulate their data.
Sob
Power Member
Power Member
Posts: 941
Joined: 2005-01-19, 17:33 UTC

Post by *Sob »

Ok, so you can easily embed Python in C or C++ program. TC is Pascal (Delphi for 32-bit, Free Pascal/Lazarus for 64-bit), but surprisingly, I found a project aiming just for that. Not much active, according to SVN commits, but not dead either. So it might be possible. Still there are some concerns.
Wouldn't it make TC a little (at least ;) bloated? Would it really be worth it? Also it looks like quite a big thing, I mean not exactly simple "put it in and forget about it". Wouldn't it be too much to handle? There's no big team doing TC development, quite the opposite.
And then there's this thing... as you may know, author's dedication to backward compatibility is unmatched, so far the only system he dropped support for was Windows 3.1. :) I wouldn't bet much that Python developers have it the same way. I may be wrong, but if they really don't, I'm not sure if author is ready to drop support for I'd guess pretty much everything before Windows XP. Personally I wouldn't mind too much, but it's not up to me.
Also some people might ask why Python? It's not like Python is universally accepted as the World's best scripting language. It could start a religious war. ;)

Seriously, don't hold your breath. If you really want Python plugins, think about some effective way to create proxy between current plugin interface and Python.
User avatar
MVV
Power Member
Power Member
Posts: 8702
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

Scripting support is useless w/o interface allowing to change settings/execute commands etc. It is not hard to create plugin that would allow to write scripts in different languages but that scripts won't allow to do more than regular external scripts started from buttonbar button.
hansg
Junior Member
Junior Member
Posts: 3
Joined: 2015-06-14, 09:36 UTC

Post by *hansg »

Even if it was not obvious for me, one of the main reasons I use TC is the raw speed of the UI: it's extremely snappy, and combined with shortcuts can't be beaten.

This is why I can't get used to ANY of the TC clones on Linux :(.

IMHO scripting even if it's very flexible tends to be perceivable slower compared to native stuff. I also use it allot, but I think in the context of TC it won't help.
Post Reply