Let's make writing Java plugins fun!

[jmwap]

Hey jmwap, thanks for your reply!
With that I'm hoping to be able to make it actually feasible - or even worth - trying; for someone...
You see, I'm desparately looking for feedback, and even a vague idea of what you have in mind would certainly help me .

ok, I was thinking on some plugin that:
- works whenever I am under a certain type of root dir (that is, I am in C:\...\abc or lower, and abc is determined of being of the interested type by having some name or existence of a file in it etc)
- whenever I view some files (from a selected list I decide) inside those dir, instead of just the usual F3 behaviour, I run an number of check/calculations/etc and show that information instead.

not very ambitious, I know

[meisl]

Thanks, jmwap. This indeed brings up new things!

not very ambitious, I know

Oh, errmm... are you sure ?

Your 1st requirement is nice and fine even for demonstrating ease of implementation.
It also suggests a more general approach of specifying when the plugin is applicable. Currently it's totally file-centric; mainly about the file name's extension.

The 2nd one gives me headaches: you're mentioning F3 -> lister (WLX) plugin.
Although this will be covered sometime - right now it's all about content (WDX) plugins (custom columns).

Btw: should your computation be (occasionally) expensive - that'd even be a good thing!

So the question is: what is this information you want to compute?
Would it make sense to sqeeze it (or part of it) into a custom column?
I mean at least for the time being...
EDIT: oh, and we need a name for it

When not applicable (wrong root dir, non-matching sub-folder) the column would be empty or filled with eg "n/a".
Also note that editable fields are within reach. That means that the full info could be displayed via detour "Files" | "Change Attributes" | "Load from file under cursor" | ">>". Again, as a workaround for now.

What d'ya think?

[milo1012]

would it handle (cancellation of) more than 1 concurrent bg op on the same file correctly?

No, it wouldn't.
Sure I could adapt a counter, but even that wouldn't work when TC re-requests fields after contentStopGetValue,
so it doesn't make any difference, because the name-hash is deleted anyway when a new contentGetValue starts.
Still it needs to be thread-safe (critical section) since contentStopGetValue is randomly triggered in the fg thread while the bg thread is active and checks for that value.
We're only dealing with two threads here.
If I would create threads on my own to parallelize my calculations, things need to be different of course.
Maybe I'll add this in future versions of the plugin.

I went back to re-check it - and oops - it had changed to the flawed behaviour!.

Well, good to know that it's completely reproducible.
So we can't do anything as already mentioned and after reading the official statement.
Maybe a tight timer would be possible to check for re-requests that come too soon after an abort.

It's only relevant for custom columns anyway, for the normal search things should work for big files, but with bad or no response time until the search is finished, due to the single thread.
That's why I made a global size limit option for PCREsearch.

[meisl]

Understand, that really helped me to get things clear.
You know, I'm not so much into C++ as I am into Java, and I have only read your code - so I had to ask. Thanks for your patience.

If I would create threads on my own to parallelize my calculations, things need to be different of course.
Maybe I'll add this in future versions of the plugin.

Actually that's what I was thinking of. It's about an API here, and obviously such a feat could be covered by it. Another one is to re-use plugin code and provide it as stand-alone tool, virtually with no effort. But then it really needs not to have such assumptions, so...

So we can't do anything as already mentioned and after reading the official statement.

I kind of understand what that statement says, but honestly: wrt the matter it doesn't help me in any way...

[meisl]

Sergii Belei (Белей Сергей) made a WDX plugin "GitDetails", using Eclipse's jgit library.

EDIT: @jmwap, this is similar to your requirement #1, as git stores its stuff under a hidden folder ".git" at the root of the repo. So this plugin needs to search for that, and is applicable only when inside a git repo (= under a folder with a ".git" in it).

[jmwap]

Thanks, jmwap. This indeed brings up new things!

not very ambitious, I know

Oh, errmm... are you sure ?

Your 1st requirement is nice and fine even for demonstrating ease of implementation.
It also suggests a more general approach of specifying when the plugin is applicable. Currently it's totally file-centric; mainly about the file name's extension.

The 2nd one gives me headaches: you're mentioning F3 -> lister (WLX) plugin.
Although this will be covered sometime - right now it's all about content (WDX) plugins (custom columns).

Btw: should your computation be (occasionally) expensive - that'd even be a good thing!

So the question is: what is this information you want to compute?
Would it make sense to sqeeze it (or part of it) into a custom column?
I mean at least for the time being...
EDIT: oh, and we need a name for it

When not applicable (wrong root dir, non-matching sub-folder) the column would be empty or filled with eg "n/a".
Also note that editable fields are within reach. That means that the full info could be displayed via detour "Files" | "Change Attributes" | "Load from file under cursor" | ">>". Again, as a workaround for now.

What d'ya think?

oh, so there is already something similar, that git plugin...great then. NO the info I would like to gather is not suited for a column, it must be a lister plugin.

If you want to see if you new api is well suited to a real world scenario, I guess you have a good candidate in the laready existing git plugin

[meisl]

Yes, GitDetails is a good one. Tried to get into contact with the author.

WLX will be next, will come back to you, jmwap.

Currently I'm working on making it really, really easy to give it a try. It'll be called "tc_java-NG" (EDIT: or just "tc_java", depending on Ken Händel) and it will remain a github repo. You won't, however, need to use git if you don't want to.
I'm aiming for the following as to be the most basic hands-on:

• - make sure you have a JDK installed
  
  - download a .zip from github and extract it somewhere (alternatively: git clone, for easy updates)
  
  - start a DOS batch file and tell it where your JDK is located (only once, will be remembered)
  
  - possibly tell it where TC is installed (if not under %PROGRAM_FILES%\totalcmd; again necessary only at most once)
  
  - double-click on generated .zip file of example plugin, which will trigger an auto-installation of the chosen example plugin in TC
  
  - actually use it in TC, eg for WDX: add a column to custom view

I'll also add `wget-it.bat` files which, provided wget for Windows is on your PATH, will download the right thing and put it into place whereever possible.

Next, making your own plugin is planned to be as simple as:

• - start another batch, specify new plugin's name and type
  
  - edit/extend sample java code in created sub-folder
  
  - run build.bat
  
  - double-click on created auto-installing .zip file

Eclipse and JUnit 4 will be supported as well, but neither one will be an absolute requirement.
Plugin projects may reside in their own repo and still profit from mentioned auto-(re-)installing .zip creation.
Of course there'll be a README and HOWTOs, too.

EDIT: or maybe better implement the auto-install .zip creation in Java itself, as in issue #12?
@all: feel kindly invited to comment on the issues on github, or open new ones!

@milo1012: looks like it's within reach that the "Queue" problem finally gets some serious attention. I guess precise instructions on how to reproduce would help. And: the more concise (=shorter, yet exact), the better...

[meisl]

@milo1012: as of v8.5 the "Queue" problem is no more, it seems
Would be great if you could take the effort of trying to confirm on your side.

[milo1012]

Yes, I already saw the post and tested it.
Seems completely fixed to me. Thx for that!

I don't use the beta for my main system yet and therefore also didn't use it for testing plugins, but normally I would already see this fix in the changelog, which is and was quite detailed.
But I couldn't find any entries directly related to this. I can only guess it's somehow fixed within this entry:

09.09.13 Fixed: Search - Duplicate file finder - by plugin field didn't work correctly with delay-loaded fields like in lotsofhashes plugin (32/64)

So I don't think it was a "failure of communication", it just wasn't clear until someone actually mentioned or tested it.
In any case, it works now, but I'll still wait for the final 8.50 before any new test cases.

[meisl]

Great, I'm really glad that this one can be considered solved!
(Ok, you're right: it ain't final until it's final - and confirmed! But fair enough for me)

I don't use the beta yet and therefore also didn't use it for testing plugins

Neither did I, and missed to clearly state so...

So I don't think it was a "failure of communication", it just wasn't clear until someone actually mentioned or tested it.

Well, mentioned it was, a long time ago. And tested. And described. And again and again so since.
Only it wasn't heard/understood properly up until recently...

But anyways, let's stop nitpicking and looking back. I, for one, consider it a non-issue now