Is DOpus right for me?:: user-generated collection xml

Help & Support
1

background:
If you're in a hurry, just read the question section.

I'm a new user of DOpus, installed version 9.1.0.1.2947.x86 for evaluation, deciding whether to purchase the product. I've Read the FAQs, I've Read the intro by Leo; I intend to be a purchaser and "power user" (and perhaps plugin developer) of DOpus if I can get a few more insights on unanswered questions.

overview:
I don't know DOpus well (yet), but I do know that the "collections" feature is going to be very useful for me if it can support dynamically created collections that come from external programs. After looking around a bit, I notice that collection.col files are XML and they apparently specify what gets seen in the collection root.

question:
Is it possible for the user to generate her own collection.col xml files so they can be seen and understood and real-time-refreshed by DOpus? Is there any documentation for what a valid collection.col xml file must contain? I've tried creating a collection.col xml file by hand and putting it in the same directory as the rest, paying close attention to the cues given by the "normally" generated files, but to no avail.

See also:
resource.dopus.com/viewtopic.php ... ection+xml

rationale:
You may be wondering "why would you want to do this"? Answer: easy extensibility. I can already think of a few "missing features" that are not yet in DOpus (I know, because I've searched the forum to confirm they are in fact missing) that I know I could implement myself very quickly and easily, if only I could populate my own collection.col xml files using my own custom scripts.

If DOpus can deliver on this, I will be well on my way to buying this and recommending it to all my geek friends.

Thanks,

2

The collection file format isn't officially documented unfortunately, although being XML it is of course fairly obvious. There's no API for adding things directly and changes made outside of Opus won't be noticed until Opus is reloaded. There are plans to add some sort of external collection API but at the moment there isn't one.

However, you can add files to collections externally using dopusrt.exe to send a Copy command to Opus. For example, assume you had a collection called "TestColl" and you wanted to add the file C:\Test.txt to it. The following command would do that:

"C:\Program Files\GPSoftware\Directory Opus\dopusrt.exe" /cmd Copy C:\Test.txt TO coll://TestColl
3

Excellent, works perfectly. Can you show also the raw command syntax for removing a specific file from a specific collection using dopusrt? I cant quite figure out from the raw command documenation how it would be done.

Even better would be if you could show raw commands for all of the following, or show me how i can figure them out from the docs, by creating buttons, or otherwise:

-- add a new collection -- coll://TestCol
-- add a new sub-collection -- coll://TestColl/subtest
-- rename an existing collection
-- delete an existing collection
-- add a file to an existing collection (already shown above)
-- remove a file from an existing collection (with ability to specify which collection, in case the file belongs to more than one collection)
-- move a file from one collection to another

thanks for your help

4

File collections act for the most part like a normal filesystem, so think what commands you would use for a normal folder and you have your answer :slight_smile:

Create collection / sub-collection - CreateFolder coll://CollName[/SubName]
Delete file from collection - Delete coll://CollName/FileName
Delete collection - Delete coll://CollName
Rename collection - Rename coll://CollName TO NewName
Move between collections - Copy coll://OtherCollName

5

Note that the Delete file from collection example will delete the actual file.

I'm not sure if there is a way to remove a file from a collection via a command so I've just sent in a feature request asking for it.

6

Very interesting thread...
I've got some perl scripts that I'd like to be able to use to deal with collections like this so that I could show similar files within a directory opus lister (by similar, I mean that I have a fairly complex algorythm that looks at diferent components of the filenames and determines how similar they are).

I'll have to play with this... if there were some kind of API for doing this, that'd be even better.

7

Hi Supacon,

It would seem you are catching on to one reason that motivated my question in the first place. If the programming model is sufficiently flexible, this aspect of DOpus could be used for a lot of very useful features, some of which have not even been thought of yet probably.

Here's another thread from this forum that might get your thoughts flowing as well.

[File tagging/searching (Was: Now, if DOpus did THIS...))

The key idea here is, give the end-user the ability to specify arbitrary groupings of items in a lister based on whatever criteria she deems useful ... and don't require them to code it in C++ or use by-hand "drag n drop". Let the list of items come from anywhere the user can think of.

Using this approach, seemingly-complex features such as those specified in the linked thread above become a piece of cake to implement.

DOpus is already part-way there with this pretty powerful feature "file collections" ... all that remains is a clean way to get DOpus to recognize real-time dynamically-generated file collections, where the generator is your own script, a database, content scraped from a search-engine-results-page on the web, or anything else your imagination can fathom.

I've been looking for a well-designed app that can do this for a long time.

8

Writing a VFS plugin is probably a better route to do that than generating collections.

In terms of the tagging idea, you could write a VFS plugin where typing the path

tags://winter/ben/sports

returned a list of all files which were tagged with "winter", "ben" and "sports". it wouldn't have to use / to separate the tags directory style (VFS plugins can parse their own paths if they want to, and respond arbitrarily to the Parent button, double-clicks on sub-folders, and so on), but I'd say it makes sense in this example.

The advantage of using the VFS plugin API is that Opus will always query your code to get the list of files. You don't have to worry about keeping the list up-to-date "just in case", or restarting Opus so that it picks up the new Collections XML, or any of that stuff.

The VFS API is also already part of Opus and ready to use right now.

9

[i]Writing a VFS plugin is probably a better route to do that than generating collections.

The advantage of using the VFS plugin API is that Opus will always query your code[/i]

That's a good piece of additional information, although there are disadvantages as well:

  1. someone who doesn't have the time or inclination to download the SDK, read up to 232 pages and learn the DOpus API is out of luck;
  2. This approach seems to assume that the user/developer both knows and is willing to code in C++ to get the job done;
  3. Someone who already has a pre-existing application that implements some sophisticated algorithm will have to retro-fit or rewrite it from scratch to conform to the DOpus API;
  4. Someone who has a pre-existing application that already outputs a list of files into XML might scratch their head and wonder why they are re-writing the whole thing in C++ when DOpus already uses XML files to define file collections to begin with; and
  5. If DOpus were capable of reading collection.xml files more dynamically, this would enable a user/developer to code in any language capable of generating XML, which of course means not just C++.

Not that having a documented API to fall back on is a bad thing of course. Lots of applications don't even provide that. It's just that there are other options that could be made available that would make things much easier, and DOpus even that much more flexible and powerful.

Just my .02

10

Since you mentioned an interest in writing plugins at the start of all/most of your posts, I assumed that the suggestion of writing a plugin might not be a bad idea. :slight_smile:

Obviously, if someone already has some code that just so happens to fit into one way of doing things, then bending it to work with another way will add some effort. That works both ways and something that is more like a filesystem or database would, IMO, be a lot easier to turn into a VFS plugin than to turn into an "XML generation triggered by events or timers" system.

Either way, it will work better as a VFS plugin.

Also, I am not suggesting that end-users should have to write VFS plugins to get their list of files in the lister. It sounded like you wanted a system to allow users to do that with minimal programing knowledge. Since you talked about writing plugins, I assumed you were talking about writing such a system/program which would output XML collections for Opus to consume. In which case, as I see it, making a VFS plugin will work a lot better. That VFS plugin itself could consume XML files that the user generates, or run a script, or query a database, or whatever.

The VFS API docs are long but you can actually ignore most of the information as there are a lot of optional features which don't need to be implemented or used.

You don't have to use C++ to write VFS plugins. Any language which can create a DLL can be used, although using anything other than C++ will be a pain for the first person who does it a particular language as they will need to convert the headers and map things from C++ to their language, which implies someone who knows at least a bit of C or C++ will need to pioneer the way for each language. So C++ is definitely the easiest language to write plugins in but there's no technical reason for it to be the only language. One or two people have written Viewer plugins in Delphi, for example.

I keep thinking of writing a plugin in C#.Net just to show it can be done, but so far there hasn't been anything which would benefit from C# over C++. I doubt people would appreciate the bloat that the .Net runtime adds in a .Net plugin written purely for the sake of it, so the idea has remained on the shelf. It would be fun, though, and might open plugin writing to more people. I like C# and .Net on the whole but so far all of the plugins I've written or thought of writing have needed to talk to existing C++ libraries and/or Win32 API stuff, which can be done in C# but is both easier and better done in C++.

11

All good points. API and plugins definitely not a bad idea, and you are definitely right, there's no technical reason why someone could not code a plugin in VB or Perl, for that matter. Even without knowing the API though, I know that would not be fun.

I think you may be overestimating, however, the sophistication needed to make XML-based development useful with DOpus. As far as I can see, simply having the ability to generate DOpus XML by external process as an alternative to Drag-n-drop, and enabling a refresh (via something as crude as F5, for example) would be brain-dead simple to implement, and actually require zero programming experience for the user.

Yes I might be interested in plugin development, but I'm also interested in paths of least resistance :slight_smile:. I'd not shed a single tear if I could get all the functionality I needed from DOpus without ever having to fire up Visual Studio a single time.

A few more bits.

12

Is there a switch that you can use to ignore a file if it is already in the collection when copying?

I don't want it to pop-up a dialog box saying it already exists. I want it to silently just bypass it.

This is for a special need I have here:

[url]Automatically Adding To a Collection]

13

I don't think there's a way to suppress the error message when the item already exists.

I've just sent GPSoftware a feature request for WHENEXISTS=skip to work when adding to collections so maybe in a future version.