This forum uses cookies. Click X button to hide this message. What is stored? / Privacy
Total Commander Forum Index Total Commander
Forum - Public Discussion and Support
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Plugin scripting poll. Please participate

 
Post new topic   Reply to topic    Total Commander Forum Index -> Total Commander Polls (English) Printable version
View previous topic :: View next topic  

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
30%
 30%  [ 7 ]
No, I like good old fashion Delphi plugins for speed
17%
 17%  [ 4 ]
No, Completely useless
4%
 4%  [ 1 ]
No, I prefer fast and small C++ plugins
30%
 30%  [ 7 ]
I have no clue
17%
 17%  [ 4 ]
Total Votes : 23

Author Message
billiebub
Member
Member


Joined: 12 Apr 2011
Posts: 170

PostPosted: Thu Nov 08, 2012 10:45 am    Post subject: Plugin scripting poll. Please participate Reply with quote

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.
Back to top
View user's profile Send private message
Sob
Power Member
Power Member


Joined: 19 Jan 2005
Posts: 903

PostPosted: Thu Nov 08, 2012 12:34 pm    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message Send e-mail
Balderstrom
Power Member
Power Member


Joined: 11 Oct 2005
Posts: 2148

PostPosted: Thu Nov 08, 2012 3:14 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
Hacker
Moderator
Moderator


Joined: 06 Feb 2003
Posts: 10845
Location: Bratislava, Slovakia

PostPosted: Thu Nov 08, 2012 7:00 pm    Post subject: Reply with quote

Moderation:
Moved to the Polls forum.

Hacker (Moderator)

_________________
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.
Back to top
View user's profile Send private message Send e-mail
billiebub
Member
Member


Joined: 12 Apr 2011
Posts: 170

PostPosted: Fri Nov 09, 2012 10:50 am    Post subject: Reply with quote

Quote:
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.
Back to top
View user's profile Send private message
billiebub
Member
Member


Joined: 12 Apr 2011
Posts: 170

PostPosted: Fri Nov 09, 2012 10:55 am    Post subject: Reply with quote

Quote:
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
Back to top
View user's profile Send private message
billiebub
Member
Member


Joined: 12 Apr 2011
Posts: 170

PostPosted: Fri Nov 09, 2012 11:18 am    Post subject: Reply with quote

Quote:
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
Back to top
View user's profile Send private message
Balderstrom
Power Member
Power Member


Joined: 11 Oct 2005
Posts: 2148

PostPosted: Fri Nov 09, 2012 11:48 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
billiebub
Member
Member


Joined: 12 Apr 2011
Posts: 170

PostPosted: Fri Nov 09, 2012 11:55 am    Post subject: Reply with quote

@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.
Back to top
View user's profile Send private message
Balderstrom
Power Member
Power Member


Joined: 11 Oct 2005
Posts: 2148

PostPosted: Fri Nov 09, 2012 1:31 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
Sob
Power Member
Power Member


Joined: 19 Jan 2005
Posts: 903

PostPosted: Fri Nov 09, 2012 6:35 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message Send e-mail
MVV
Power Member
Power Member


Joined: 03 Aug 2008
Posts: 8001
Location: Russian Federation

PostPosted: Sat Nov 10, 2012 7:11 am    Post subject: Reply with quote

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.
_________________
TCFS2 + TCFS2Tools: Full-screen mode for TC etc (forum)
TOTALCMD.NET: AskParam, CopyTree, NTLinks, Sudo, VirtualPanel…
Back to top
View user's profile Send private message Send e-mail
hansg
Junior Member
Junior Member


Joined: 14 Jun 2015
Posts: 3

PostPosted: Sun Jun 14, 2015 4:16 am    Post subject: Reply with quote

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 Sad.

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Total Commander Forum Index -> Total Commander Polls (English) All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Imprint/Impressum: This site is maintained by Ghisler Software GmbH
Privacy Policy | Datenschutzerklärung | Politique de Confidentialité

Using phpBB © phpBB Group