XYplorer Beta Club

highend wrote:By adding a column, right clicking it and select from the context menu?

I am sorry, but I do not see any option to add text when I right click on a newly-added column. I am still a new user of XY, so could someone dumb this down a bit for me, please?

The first three entries of the context menu. Define "Text". Which "text" do you want to add?

Hi'

I'd spent quite some time searching for the ideal DAM/Cataloging tool and never found a satisfying one either, so I'd finally settled on XY for this task, and thanks to its scripting it's already quite powerful.

Short version: Maybe if several of us brainstorm enough, we could come up with a reasonable idea to push XYplorer in the Cataloging direction —without changing its purpose...

Have a nice day,
Flux

---------------------------

Brainstorming:

A few thoughts/comments on what has already been said:

Indeed, images ('Covers') seem the best way to use as quick visual identification + metadata placeholders

About (meta)data:
It could be stored in: 1. XY tags, 2. user-made tag DB, 3. (circumvented) proprietary tags, 4. part of cover filename.
1. XY tags:
   + easy to assign and search
   + variety (tags, labels, comment)
   + quantity (~as much as you want)
   + versatility of display (through easily configurable columns)
   - everything depends on XY tag database, which is also used by your other tags, labels, etc.
     So if there's a problem with it... Ouch! If you're working in a 'frail' environment (electricity/computer/softs/etc. prone to failure), then you'll lose everything you've made since your last save of settings (I've mapped CTRL+S to Save all settings for this very reason!).
2. User-coded tag database:
   + slightly better reliability, only thanks to the differentiation with regular non-cataloging tags and labels
   - much harder to implement and maintain, (i.e. to code)
   ~ same speed to assign and search (depending on code)
3. Proprietary tags: e.g. placing generic data in EXIF
   + reliability (since it's embedded in files)
   - hard to assign
   - slower to search
4. Filenames: i.e. renaming cover filenames to contain metadata
   + reliability/portability (each item has its own metadata)
   + easy to assign
   + very easy to search
   + versatility of display in any explorer
   ~ versatility of display in XY (dedicated columns can easily display only relevant parts of filename, but needs coding first)
   - limited quantity of data (to avoid filenames > 256)
   - "amateurish" touch (because of the long filenames)

About custom columns:
   — As was mentioned, browsing may quickly become slow if you're using lots of columns with scripting on big folders (the heavier the scripting, the slower ofc).
   — OTOH, combined with tabsets, they offer a tremendous versatility. You can have distinct column sets dedicated to specific types of data and they can display pretty much whatever you want whenever you want.

About automation:
— It's hard to find reliable ways to gather/extract covers and metadata for real and digital assets, the problem being their variety and the lack of comprehensive databases.
— It's not entirely impossible though, I've one very reliable script to gather "real" (or digitalized) movie covers with genres and artists. For real books, it very hit-and-miss, especially the data; though for ebooks, generally usable covers can be extracted from most PDF and ebooks (via scripting for the latter).


My implementation:
For reliability reasons, I've settled on the filename approach.
This implementation may still be far from an ideal do-it-all/please-all solution... but nonetheless it works really easily, really well, and amazingly fast (thanks to XY scripting), plus I can combine it with labels to mark "in progress", "seen/read"... (I use it mainly for real books, real movies, ebooks, movies...): Collection Manager (as mentioned by Sammay, thanks )
Woops, I realize I'm at v1.2 vs the v0.9 posted, I'll upload it soon!

FluxTorpedoe wrote:Maybe if several of us brainstorm enough, we could come up with a reasonable idea to push XYplorer in the Cataloging direction —without changing its purpose...

Have a nice day,
Flux

Hi Flux,

Wonderful ideas, all. I love everything Don has done/is doing with XY, but something that is (very sadly) a deal breaker for me is the fact that XY cannot handle tags that contain commas, such as "Surnames, Jewish—Lists and Histories." The comma breaks the tag up into two separate tags. I will most likely need to build something myself in Access, but I need to find a guru who can mentor me. Please tell me more about Collection Manager!

FluxTorpedoe wrote:    - everything depends on XY tag database, which is also used by your other tags, labels, etc.
     So if there's a problem with it... Ouch! If you're working in a 'frail' environment (electricity/computer/softs/etc. prone to failure), then you'll lose everything you've made since your last save of settings (I've mapped CTRL+S to Save all settings for this very reason!).

1) It's planned to handle different databases. The Save As..., Load... kind of thing. Maybe that relaxes it a bit...
2) I'm also thinking about local databases that are located in the folders they refer to, and are only loaded into memory when you browse/search such a folder.

2) "that are located in the folders they refer to" -- Why litter? Why not just save these dbs inside <xydata>?

SammaySarkar wrote:2) "that are located in the folders they refer to" -- Why litter? Why not just save these dbs inside <xydata>?

Easier to maintain when folders are renamed or moved. But sure, littering is a price to pay.

Maybe if several of us brainstorm enough, we could come up with a reasonable idea to push XYplorer in the Cataloging direction —without changing its purpose...

The comma issue is troublesome to me... I need to add tags such as "Surnames, Jewish—Lists and Histories" to files and then I wish to search for the files that are associated with such tags. As matters stand, XY splits such a tag into two tags due to the presence of the comma. There must be a way around this!!!

1) replace your comma with ;

2) use Comment instead of Tags

admin wrote:

SammaySarkar wrote:2) "that are located in the folders they refer to" -- Why litter? Why not just save these dbs inside <xydata>?

Easier to maintain when folders are renamed or moved. But sure, littering is a price to pay.

Make the format optional (ie, with/without full portability) and everyone'll be happy. 15 years of cleanness depict in favor of the app. Anyway, I'd be completely happy to pay the price in this case. And a simple system-wide search + minimum scripting solve the problem of general chaos, if needed. Same as disk thumbnailing: better having it than not to.

SkyFrontier wrote:

admin wrote:

SammaySarkar wrote:2) "that are located in the folders they refer to" -- Why litter? Why not just save these dbs inside <xydata>?

Easier to maintain when folders are renamed or moved. But sure, littering is a price to pay.

Make the format optional (ie, with/without full portability) and everyone'll be happy. 15 years of cleanness depict in favor of the app. Anyway, I'd be completely happy to pay the price in this case. And a simple system-wide search + minimum scripting solve the problem of general chaos, if needed. Same as disk thumbnailing: better having it than not to.

I'm with you entirely. Everything else on the market that tries to compete with XY is completely inferior, quite frankly. The system-wide search is a must-have.

admin wrote:1) replace your comma with ;

2) use Comment instead of Tags

Wouldn't it be possible to format the program's Tag field the same way as the Comment field? I really need to reserve the Comment field for other information. It seems obvious that Don has that enviable level of expertise in programming that we associate with people like Bill Gates, so I am sure this feature will be smoothed out when he can find the time.

The tags are stored as comma-separated values, so you see the problem in using a comma as part of a tag.

I had an idea of allowing escape codes in tag.dat, such as tag\, first, tag 2, tag 3. But I fear that might cause a considerable performance hit.

Ryan wrote:

admin wrote:1) replace your comma with ;

2) use Comment instead of Tags

Wouldn't it be possible to format the program's Tag field the same way as the Comment field? I really need to reserve the Comment field for other information. It seems obvious that Don has that enviable level of expertise in programming that we associate with people like Bill Gates, so I am sure this feature will be smoothed out when he can find the time.

3) I have another idea: Do you need multiple tags per item at all? Otherwise I could simply skip the splitting at commas.
4) Is there anybody else unhappy with the comma? Of course, I *could* make that configurable/tweakable (rendering your current tag DBs useless junk).

4) Is there anybody else unhappy with the comma?

<-

I think it's good to make this adjustable but please elevate it to the gui so that everyone is able to see how it's currently configured

(rendering your current tag DBs useless junk)

I'll write a converter xD