XYplorer Beta Club

jjk wrote:

admin wrote:

serendipity wrote:Could there be a way to separate paths from current PC that are truly dead (because of rename, move etc) to paths on other PCs which look dead now but are actually alive.

I don't see a way.

Perhaps by List Management, by hand ? provided that we can delete several lines in one shot.

Perhaps...

I will now enter feedback collection mode for a while. A young feature needs time to ripen. For now I don't want to add anymore twists to it or relating to it.

admin wrote:I will now enter feedback collection mode for a while. A young feature needs time to ripen. For now I don't want to add anymore twists to it or relating to it.

OK, sorry

PS: Oh, there will be an easy way once we have VFOs! You simply show all tagged items using "tag:*". You will then recognize non-existing items by some mark that I'm still thinking about... then you can untag them manually.

admin wrote:I will now enter feedback collection mode for a while. A young feature needs time to ripen. For now I don't want to add anymore twists to it or relating to it.

Does that mean you won't add scripting-support for this feature just now ? You know, things like new fields {Comment}, {Tag} and {TagID} for function report(), and new commands like tag <tagid>[, <itemlist>] and comment <tagid>[, <itemlist>] Just so that scripts can both get & set tags and comments. (Which will be even better when report() supports an <itemlist> parameter as well )

Not that it's useless without it, but since we have scripting it only make sense to support it there too, plus I know if I want to really/fully use this feature, I need to be able to use it in my scripts...

jacky wrote:

admin wrote:I will now enter feedback collection mode for a while. A young feature needs time to ripen. For now I don't want to add anymore twists to it or relating to it.

Does that mean you won't add scripting-support for this feature just now ? You know, things like new fields {Comment}, {Tag} and {TagID} for function report(), and new commands like tag <tagid>[, <itemlist>] and comment <tagid>[, <itemlist>] Just so that scripts can both get & set tags and comments. (Which will be even better when report() supports an <itemlist> parameter as well )

Not that it's useless without it, but since we have scripting it only make sense to support it there too, plus I know if I want to really/fully use this feature, I need to be able to use it in my scripts...

Okay, added {Comment}, {Tag} and {TagID} (which I had totally forgotten about, thanks!). The rest later...

TheQwerty wrote:And I really think you need to make use of PapayaWhip.

I just saw that my default "Green" should clearly be named "MichelleObamaGreen"! It's damn close...

7.90.0082
Thanks for the quasi-illimited number of TagIDs.

jjk wrote:7.90.0082
Thanks for the quasi-illimited number of TagIDs.

I might provide a way to add more name/color schemes at a later stage. But I don't think the menus plus keyboard shortcuts will get any larger. So anything > #15 will be a non-GUI approach, but fully functional in terms of sorting and searching/VFOs (later).

admin wrote:

jjk wrote:7.90.0082
Thanks for the quasi-illimited number of TagIDs.

I might provide a way to add more name/color schemes at a later stage. But I don't think the menus plus keyboard shortcuts will get any larger. So anything > #15 will be a non-GUI approach, but fully functional in terms of sorting and searching/VFOs (later).

Yes, no problem for me. With SC edittag I play with Tag IDs

Don, are you planning on adding the tag menu options to the "Mark" menu of tree folder context menu? As there is also a unused separator bar at the bottom of the "Mark" menu....and because it would seem to thus match the "Favorites" menu,

j_c_hallgren wrote:Don, are you planning on adding the tag menu options to the "Mark" menu of tree folder context menu? As there is also a unused separator bar at the bottom of the "Mark" menu....and because it would seem to thus match the "Favorites" menu,

No, I'll keep the tagging stuff in the list. The menus are big enough.

The unused separator was a bug that is fixed in the meantime

admin wrote:Okay, added {Comment}, {Tag} and {TagID} (which I had totally forgotten about, thanks!). The rest later...

Thanks! (Looking forward to later )

Suggest that on http://www.xyplorer.com/release_7.90.htm#0100, the location of where the tags are stored be documented, as well as some clarification about tags for items on external devices...

Also, it implies that tags are retained with file operations in all cases, but this isn't the case when destination exists, right?

j_c_hallgren wrote:Suggest that on http://www.xyplorer.com/release_7.90.htm#0100, the location of where the tags are stored be documented, as well as some clarification about tags for items on external devices...

Also, it implies that tags are retained with file operations in all cases, but this isn't the case when destination exists, right?

1. No, this is not the place for such details.
2. No, they are retained in all cases.

Don't want to argue with you but must point out a couple of things:

admin wrote:

j_c_hallgren wrote:Suggest that on http://www.xyplorer.com/release_7.90.htm#0100, the location of where the tags are stored be documented,

1. No, this is not the place for such details.

Huh? So why then...On http://www.xyplorer.com/tour/index.php?page=catalog, I see this: "All catalog data are saved in a small file called catalog.dat and is ready for take-away." and on http://www.xyplorer.com/tour/index.php?page=cks, I see this: "The shortcuts are saved in a small binary file called ks.dat that you can travel with. "...so why shouldn't tag.dat get the same treatment?

Those are just two examples from XY site of what I meant...

admin wrote:

j_c_hallgren wrote:Also, it implies that tags are retained with file operations in all cases, but this isn't the case when destination exists, right?

2. No, they are retained in all cases.

Ok...so I didn't quite say it fully correctly either but I was referring to a couple of cases, such as move, where a "non-tag does NOT overwrite old tag: old tag stays", so while the tag status of the overwitten item is retained, the status of the replacing item is lost, ok?

And while you do't explicitly say "Copy" in the "with file operations (e.g. move or rename).", it can be inferred via the "e.g" that it does include that, and since copy doesn't retain tags (right?), then this is in conflict with the 'retained in all cases'....adding a "as logically appropriate" could maybe be enough.