Enhance settings mgmt

[RalphM]

With all the new functions at our hands, namely UDC, KS, catalog and now scripting, I find myself doing more and more of the same work on my home and work computers to keep 'em both somehow in synch.
Yes I know, I could just run XY from an USB stick, but problem is the setups of the two computers are not really the same and I don't have much influence on the setup of the work one....
Anyway, I was thinking, if a different approach to manage those settings would solve my problem, let's say we had different catalog.dat-files and could set in the ini which ones are loaded and in which order.

So I could set up three files, let's name 'em:
1. catalog_shared.dat
2. catalog_work.dat
3. catalog_home.dat
Then I would load files 1 and 3 on my home pc and files 1 and 2 at work.

The same would work for the other .dat-files as well.

I'm aware, this would need some changes in the UI to manage these settings, but would probably save a lot of people a lot of synching work - I guess.

Or does anybody have a clever solution for this problem, maybe a script???

[admin]

Hmmm, difficult... but I see your point... will meditate...

Exporting/Importing parts from Catalog is on my list since long. Catalog Categories should be easily shareable between users (colleagues) that work together on a project...

Reading 2 Catalog files into XY would be easy. But saving?

UDC is difficult because of the fixed function IDs. You cannot have two independent udc.dat files...

Needs a bit of thought...

[Muroph]

Reading 2 Catalog files into XY would be easy. But saving?

how about saving categories instead of the whole thing.

[admin]

Reading 2 Catalog files into XY would be easy. But saving?

how about saving categories instead of the whole thing.

One file per category... hmm... might be a cool idea.... right now, I'm busy elsewhere, but I keep it in the back of my mind.

[RalphM]

Struggling to keep my home and work pc in synch was actually just triggering that idea, but it could lead to further improving XY especially in workgroup or company-wide setups. Think of a network admin that would like to outfit a workgroup's pc's with XY, but wants to keep partial control of catalog items, UDC's aso. With my suggested multi .dat-file setup he could actually put the workgroup-wide items in dat-files that reside in read only system folders, but still give the users their own set of commands in their own dat-files. (Oops, this would not only need multiple files but also multiple locations)

XY offers a lot of functions that not only cracks will love, but to understand them all and have them set up properly might be too much hassle for them.

At work XY is pretty much my switchboard to all work related information on the network, with heaps of catalog entries, UDC and now even some scripts. Being able to share these to some extent might help to sell XY even better for whole workgroups.

Sorry for the long post, but I thought it's time to share my further ideas on this concept. I hope it's not too confusingly written.

[j_c_hallgren]

Reading 2 Catalog files into XY would be easy. But saving?

how about saving categories instead of the whole thing.

One file per category... hmm... might be a cool idea.... right now, I'm busy elsewhere, but I keep it in the back of my mind.

So...how about making the file that category is in as one more hierarchy level? It could be partially hidden if needed...Sorta a parent to category...and let user define which file(s) to read via Config.

And as far as export/import...I'd look to RegEdit style of handling it, where one can pick the key level to export and it puts the needed info in a file that can be edited/read easily by another text editor if desired, and also then can be Imported back into system...that would be my preference, I believe.

[admin]

Struggling to keep my home and work pc in synch was actually just triggering that idea, but it could lead to further improving XY especially in workgroup or company-wide setups. Think of a network admin that would like to outfit a workgroup's pc's with XY, but wants to keep partial control of catalog items, UDC's aso. With my suggested multi .dat-file setup he could actually put the workgroup-wide items in dat-files that reside in read only system folders, but still give the users their own set of commands in their own dat-files. (Oops, this would not only need multiple files but also multiple locations)

XY offers a lot of functions that not only cracks will love, but to understand them all and have them set up properly might be too much hassle for them.

At work XY is pretty much my switchboard to all work related information on the network, with heaps of catalog entries, UDC and now even some scripts. Being able to share these to some extent might help to sell XY even better for whole workgroups.

Sorry for the long post, but I thought it's time to share my further ideas on this concept. I hope it's not too confusingly written.

I see.

As I mentioned before, exporting/importing catalog categories is already on my list and also finished in my head. That would be a start.

Distributed files and locations... sounds good, but sounds also like something that can lead to trouble and confusion... there might be better ways to achieve the same. Let's take some more meditation time outs...

[admin]

Reading 2 Catalog files into XY would be easy. But saving?

how about saving categories instead of the whole thing.

One file per category... hmm... might be a cool idea.... right now, I'm busy elsewhere, but I keep it in the back of my mind.

So...how about making the file that category is in as one more hierarchy level? It could be partially hidden if needed...Sorta a parent to category...and let user define which file(s) to read via Config.

And as far as export/import...I'd look to RegEdit style of handling it, where one can pick the key level to export and it puts the needed info in a file that can be edited/read easily by another text editor if desired, and also then can be Imported back into system...that would be my preference, I believe.

Yes, would be possible.


export/import... RegEdit style -- yep, jc, that's exactly how I plan to do it.