"Virtual Locations" or what?

[admin]

crazy - yes but only if taken literally - clever people make crazy work - who ever thought someone could design electronics based on uncertainty -

Are you talking about the improbability drive (Douglas Adams)? Yep, clever!

[graham]

try,

http://www.youtube.com/watch?v=KT7xJ0tjB4A

Back to crazy VF's - it would indeed be crazy to automate updating of VF based on the properties I suggested but in reality one would select in the properties the VF to apply to a small range of folders, fields and other criteria - once the VF is established it could be available to present 'usable file content' but for simplicity require the user to initiate and activate the 'update' process which would be quick (use of db) unless one got silly and included massive folders but... I can see that to have such a facility would mean that 'special' files would always be available at the press of a key - specific cached searching but a bit more?

[admin]

Okay, back to the upcoming killer hype VFOs (Virtual Folders)!

I currently plan 3 types of VFOs (repeating parts of post #1 of this thread):

(1) Tags: Tags (or patterns matching tags) can be addressed as "locations" (and used for everything locations can be used to in XY!). Syntax:

Code: Select all

tag:red
tag:r*
tag:red; gr*; *x
tag:red?a* (= all items with tag red and beginning with "a"! :mrgreen: ... know what I mean...)
etc.

Files will be read directly from tag.dat in supersonic zero-time!

(2) Comments: Same story with Comments.

Code: Select all

cmt:2009; ocean; sun (show all files which have the words "2009", "ocean", or "sun" in the comment.
cmt:+2009 +ocean -rain (or maybe this syntax, AND-combined...?)
etc.

(3) Data Files: And again almost same story with any file containing a simple list of path/filenames. Syntax:

Code: Select all

dat:MyFiles.dat (default path <xydata>\vloc)
dat:C:\MyFiles.dat
dat:\\server\share\MyFiles.dat
etc.

Now I'm not 100% sure about the syntax. These things will be fed into the Address Bar and must work without ambiguities. Is xxx: good enough? Will/Does it conflict with anything MS has in store? An alternative syntax would be to prefix another "\:", so e.g. \:tag:red...

[jacky]

The xxx: syntax sounds good to me, although my only concern would be regarding the use of such things on (Mini)Tree, where the use of a label/caption would be very nice (leaving the actual/full "definition" to the tooltip).
Boolean syntax sounds pretty cool: "Water all around"cmt:2009 AND (ocean OR sea) AND NOT rain

Question: list of items is always read directly from a file, what will happen when one of the item cannot be found: displayed without info (dates, site, etc -- and no/special icon) or will they simply be "ignored." Cause the former idea sounds like it could be something interesting... (maybe it could be one of the "arguments" from the "definition"?)

[admin]

The xxx: syntax sounds good to me, although my only concern would be regarding the use of such things on (Mini)Tree, where the use of a label/caption would be very nice (leaving the actual/full "definition" to the tooltip).
Boolean syntax sounds pretty cool: "Water all around"cmt:2009 AND (ocean OR sea) AND NOT rain

Question: list of items is always read directly from a file, what will happen when one of the item cannot be found: displayed without info (dates, site, etc -- and no/special icon) or will they simply be "ignored." Cause the former idea sounds like it could be something interesting... (maybe it could be one of the "arguments" from the "definition"?)

Boolean: easy, easy... let's not get crazy now... multi-patterns as in other places of XY should do for now.

cannot be found: yes, I'm aware of it and open to suggestions. Currently, as you know, the cached searches will simply omit items that do not exist anymore.

[jacky]

Boolean: easy, easy... let's not get crazy now... multi-patterns as in other places of XY should do for now.

Yeah, sorry... But you started it!

cannot be found: yes, I'm aware of it and open to suggestions. Currently, as you know, the cached searches will simply omit items that do not exist anymore.

And that makes sense. OTOH I could see situations where listing items not available (disk not in drive, network not connected, etc) might be an interesting addition. (Also, could be used to do some clean up...)
Maybe a simple trick such as "tag:red" means tagged red & exists, whereas "tag!:red" or something would mean tagged red, whether or not it exists...

[admin]

The xxx: syntax sounds good to me, although my only concern would be regarding the use of such things on (Mini)Tree, where the use of a label/caption would be very nice (leaving the actual/full "definition" to the tooltip).
Boolean syntax sounds pretty cool: "Water all around"cmt:2009 AND (ocean OR sea) AND NOT rain

VFOs in the MiniTree... a thrilling topic. What's your vision of it?

[jacky]

VFOs in the MiniTree... a thrilling topic. What's your vision of it?

Well, I think we might have discussed this topic already in the past, but I'm not sure what was said in the end. The basic idea would simply be to have those VFOs on Tree. I seem to remember you mentioning an idea of having a new node "Virtual Folders" or something, not unlike "My Network Places," under which all VFOs would be found. I'm not sure I would like this idea, and I think I would prefer if it was more "straight-forward" and simply add VFOs just like we have drives (same level, right under My Computer).

So we would define which VFO to add alongside a label, and it would then show up on Tree much like all other drives, except with a different icon and instead of a letter (e.g. "D:") only "VFO" after its label (Let the whole VFO definition (e.g. "tag:red; gr*; *x") be on tooltip). I think I'd like that better just because it would allow us to have our VFOs amongst drives where we want on Tree, and also saves some space without the requirement for some "unnecessary" node (e.g. "Virtual Folders").
(Of course, there could also be a way, when adding a VFO to Tree, to specify whether it should go under "Virtual Folders" or "My Computer" thus allowing everyone to decide, and one a per-VFO basis even!)

After that, the behavior of those nodes on Tree should be pretty much the same as everywhere else. So the "root" couldn't be a source or target of drop operation, since that location doesn't exists anywhere and could be a listing of items from all over the place (BTW I hope you haven't forgotten the bit about when using a file, having prefix > before a folder not to add that folder but all its content into the VFO).

But, all the folders contained on that VFO would appear on Tree, and be browsable as any other folder. One could then drag those folders anywhere else, or use them as drop target, which wouldn't mean anything else but a regular move/copy operation, for that folder to be moved/copied where it was dropped, or for items to be moved/copied into that folder -- that is its actual location (which I assume would be shown when hovering the folder's icon).
(This would mean one could grab a folder from a VFO, and move it somewhere, and yet it stays there under that VFO, if said folder was on the "root" of the VFO (e.g. tagged "red"), since the D&D would only move the actual folder on disk, but not affect its tagging (i.e. its belonging to the VFO).)

As for Tree's highlighting features (Highlighted Folder/Boxed Branch), I think VFOs should have their own. So one folder could have two different boxed color, depending whether it is viewed "directly" (actual location) or from a VFO. I'm just not sure what would be best to save those paths: use the VFO's definition, or label? Mimicking how it works now would tend to say using the definition, but the way I see it now (might be wrong) is that we would add VFOs on Tree manually (or through scripting), as opposed to XY would "list them all" as it does with everything else pretty much, so there should be a way (manually and scripting-wise) to update a VFO's definition, so that one could for example add/remove a tag in the list of tags making a VFO, without losing all its Highlighted Folders/Boxed Branches.

Lastly, this all sounds like one adds a VFO to Tree as a "direct operation" : using a (scripting/manual) command that says "add this VFO (definition) using this label," and it would have to be repeated each time. But a better way of course would be to have a "cached list" of VFOs, which could be dealt with under LM, that would be like:

Code: Select all

"Some Colors" tag:red; gr*; *x
"Recent Water" cmt:2009; ocean; sun 
"Some Project" dat:MyFiles.dat

Each of them should have a checkbox, indicating whether XY should add them on Tree automatically or not (on start up). And again, maybe a prefix somewhere could indicate whether it should be loaded under "My Computer" directly, or under an extra node "Virtual Folders."

[admin]

VFOs in the MiniTree... a thrilling topic. What's your vision of it?

Well, I think ...

Thanks! I'll make up my mind while implementing CTB which turns out to be a very relaxed little job...

[jjk]

CTB : what is it ?

[jacky]

Thanks! I'll make up my mind while implementing CTB which turns out to be a very relaxed little job...

Good to hear, cause it will be a very cool & useful feature!

CTB : what is it ?

Custom Toolbar Buttons -- you can have a "preview" in the latest beta, which features one "User button" already...

[jjk]

Thanks for the explain.
Meanwhile I checked a bit CTB
Seems wonderful.

[Stefan]

I currently plan 3 types of VFOs

(3) Data Files: And again almost same story with any file containing a simple list of path/filenames. Syntax:

Code: Select all

dat:MyFiles.dat (default path <xydata>\vloc)
dat:C:\MyFiles.dat
dat:\\server\share\MyFiles.dat
etc.

I need some help please for clarifying,

* Does this mean we could store a list of paths to an file like jacky does >here< and load this as VFO?

* And store an find result and load this as VFO? (or take find result directly to an VFO)

* "tag:red" means find all files with tag 'red' and show them in VFO?

Now I'm not 100% sure about the syntax. These things will be fed into the Address Bar and must work without ambiguities. Is xxx: good enough?

xxx: is easy, but why not vfo: ?

[admin]

I currently plan 3 types of VFOs

(3) Data Files: And again almost same story with any file containing a simple list of path/filenames. Syntax:

Code: Select all

dat:MyFiles.dat (default path <xydata>\vloc)
dat:C:\MyFiles.dat
dat:\\server\share\MyFiles.dat
etc.

I need some help please for clarifying,

* Does this mean we could store a list of paths to an file like jacky does >here< and load this as VFO?

* And store an find result and load this as VFO? (or take find result directly to an VFO)

* "tag:red" means find all files with tag 'red' and show them in VFO?

Now I'm not 100% sure about the syntax. These things will be fed into the Address Bar and must work without ambiguities. Is xxx: good enough?

xxx: is easy, but why not vfo: ?

Yes. Yes. Yes. There will be various formats but a simple TXT file with one item per line and nothing else in it will be one of the supported formats.

xxx: should have been ???: (wildcards!).

[Stefan]

Thanks

xxx: should have been ???: (wildcards!).

Ahhh, like tag:, cmt:, dat: now i get it.