XYplorer Beta Club

Posted: **12 Feb 2014 12:53**

The lengths you're going to just to avoid adding 'Remove Data' or 'Not Set' to the edit options impresses me!

I think this makes a lot more sense though, hopefully others agree.

Plus users get a new bonus feature!

They can take an existing extra column, switch its type to checkbox, and they now have a quick clean way of seeing which items are "tagged" with anything for that column. For instance, a user can now turn their "Rating Stars" column into just a "Rated?" column.

Though if that use case catches on v2.0 might need to include a CEC option to make the checkbox type read-only, to avoid accidental unchecking.

----

LittleBiG wrote:Regarding the 1, I realized that aliases work well. So we can live without caption.

Nice find!

It's a good thought, but I'd rather not have to clutter up my aliases just to have useful captions.

Considering that the "Caption" Location format is well supported throughout XY, it is expected that it would work here as well.

Plus, because it supports anything go-to this will quickly become used for quick scripting where it's going to look quite ugly with more than a caption being displayed.

Posted: **12 Feb 2014 13:32**

Plus users get a new bonus feature!

Yep, I saw that too (also the issue with unchecking = destroying unknown data).

I added the captions.

I will also add a (more) uniform right-click experience.

Posted: **12 Feb 2014 16:40**

Hm... I can see nothing useful in this now:

Code: Select all

To match all unchecked items in the database you do this:
          ex4:0

Posted: **12 Feb 2014 16:57**

Much happier with .0128!

But now I realize we have the same problem with the Number type with it showing not set items as 0.

Also, a bit of a pony but...
Can we make the ID parameter optional in ExtraTag?
When omitted ExtraTag would return all of the definitions one per a line.

Posted: **12 Feb 2014 17:27**

LittleBiG wrote:Hm... I can see nothing useful in this now:
Code: Select all
To match all unchecked items in the database you do this:
          ex4:0

ex4:0    will search for items in tag.dat whose Extra 4 field is empty.
ex4:1    will search for items in tag.dat whose Extra 4 field is not empty.
ex4:!1   will search for items in tag.dat whose Extra 4 field is empty and items not in tag.dat.

Posted: **12 Feb 2014 20:42**

TheQwerty wrote:But now I realize we have the same problem with the Number type with it showing not set items as 0.

Ok, I will show not set items as nothing.

But non-numeric items will continue to be shown as "0", and part-numeric will show the part number ("23 skidoo" will shown as "23").

EDIT1: This however generates a new little problem: "" and 0 are both sorted as 0 (it is a numeric sort in this column type) so a sorted column can end up with ""s and 0s chaotically mixed up. Not nice.

EDIT2: OK, solved EDIT1.

Posted: **13 Feb 2014 19:29**

I like the improvements to ExtraTag and I wanted to show the Tag command the same love but I'm having a harder time...

It's from the time before functions, wouldn't we rather it be a function that returns the current/old value?
I just cannot accept remapping 3 to ex1, and I hate to have it be much different from ExtraTag and search in how it refers to the Extra Columns.
I'm at a loss as to how to fix it without breaking backwards compatibility.

So I nominate the tag command for deprecation.
Unfortunately, I think doing so also means we cannot use "tag" for a new function, so I propose: tagitems.

Code: Select all

+ Scripting got a new function.
    Name: tagitems
  Action: Tags item(s).
  Syntax: tagitems(field, [value], [itemlist])
    field:       One of the following:
          lbl, label  [Default] Label Field.
           tag, tags  Tag Field.
        cmt, comment  Comment Field.
        1-5, ex1-ex5  Extra Tag 1 - Extra Tag 5.
             ex:Name  Extra Tag with Column Caption "Name".
    value:       Tag value, which (depending on field) can be label name or
                 ID, tag(s), comment, or data.
                 Empty string ('') is treated similar to "Remove Data".
                 If omitted, field is retrieve but not set.
    itemlist:    |-separated list of items (full path) to tag;
                 if empty then current list selections are tagged.
    return:      The old value(s) for this field.

Why "ex:Name" instead of just "Name"? Hopefully this makes the future less painful.

I'm not sure how to refer to what value can be for the Extra Tag fields, so I went with data to match the context options.

In the cases where the itemlist/list selection consists of multiple items, I think the return value should be a |-separated list of values with the token indexes the same as itemlist.

I dropped tag's mode because I didn't feel it was necessary anymore. If the user wants to modify the existing value instead of replacing it they can retrieve it by using tagitems() with value omitted, modify it, and then set it to the modified value.

Sorry to be suggesting a big new scripting function at this time, but after spending a couple hours with extratag and the tag command I feel this is necessary.

Posted: **13 Feb 2014 21:21**

Nice!

I implemented it -- but under cover, no docs.

Small deviations from your design:

1) It always returns the old value
2) It only returns the old value for the first of the passed files, or the focused file (if none passed).

I supported the "ex:Name" syntax. It feels safe, though I did not see a compelling case for it. What does it protect us against?

Just hacked it in, no big testing. Play with it.

Posted: **13 Feb 2014 22:10**

admin wrote:1) It always returns the old value
2) It only returns the old value for the first of the passed files, or the focused file (if none passed).

For 1, it is always the old value, but what's old is current if you don't set a new value, so always returning the old value is what I intended. Was that not clear?

For 2, I debated this and settled on what I thought was most consistent. When dealing with one item I want to get and set equally, but when dealing with multiple items it shifts to more frequently setting, and I rarely find much use in the return value when setting anyhow. Only returning the focused or first value is okay with me; it's not a real loss of functionality since the data for each item can be retrieved with report or a loop.

admin wrote:I supported the "ex:Name" syntax. It feels safe, though I did not see a compelling case for it. What does it protect us against?

I cannot read the future and thus have no way of knowing what future fields might come into being. As the name part can be pretty much anything the user desires I figured it best to have a way to indicate it was the caption of an extra column, just in case the future brings something that would cause confusion. That said, it save us from easily avoidable confusion caused by poor user decisions which can occur today.

Currently the user is free to name their extra columns 'label', 'comment', 'tags', the shortened versions, or even name Extra 2 '5' and by using 'ex:Name' tagitems shouldn't give them any unexpected results.

EDIT: I'm partially thinking this 'ex:Name' format should also be used in search and ExtraTag for consistency's sake.
And then that leads me to thinking these same rules should be added to the Report's {extra} template.

/

A little surprised by the decision to make it undocumented. Obviously I haven't played with it yet, but if it is as close to what I wrote as you suggest then I don't see why we wouldn't want to deprecate 'tag' and make this the preferred method going forward.

Is that just for now or are you planning to keep it a secret well after 13.80?

Posted: **13 Feb 2014 22:21**

Return: Oh yes, you were clear. I misread something, sorry.

ex:Name: User can also call their columns "ex:Name". Anyway, I find it too complicated for use in Find Files and Report.

no documentation: just for now. 13.80 needs to come out without further delays.

beta coming...

Posted: **13 Feb 2014 22:32**

admin wrote:ex:Name: User can also call their columns "ex:Name". Anyway, I find it too complicated for use in Find Files and Report.

That's not a problem though, they'd just have to give TagItems 'ex:ex:Name' since the desired column is now named 'ex:Name'.

So long as you don't add a new acceptable value to the parameter that starts with 'ex:' there should never be a problem with it. Now in 5 years when 'Extended', 'External', or some other 'ex-' tags are added it might be a poor decision as I struggle to come up with a valid parameter option for them.

admin wrote:beta coming...

I probably won't get to play with it until Monday, but thank you!

EDIT:

admin wrote:13.80 needs to come out without further delays.

Sorry for causing delays, but I thought you preferred me finding things before major releases rather than the week following.

Posted: **13 Feb 2014 23:01**

Enjoy the weekend!

Posted: **15 Feb 2014 13:32**

Hi'
While trying Extra Tags for the first time (I just couldn't earlier), I realized my answer to "How are you (will you be) using Extra Tags?" would make you

because it's not implemented yet, I had read the beta posts too quickly...
So I hope you won't see me as a

for coming up so late with another suggestion but here it is:
My main use for E.T. would be to tag items with "non-exclusive pop-up lists" like genres, e.g.
• Pop-up list = "Comedy; Romance; Adventure; Drama"
- Movie 1: "Comedy; Romance"
- Movie 2: "Comedy; Adventure"
- Movie 3; "Drama; Romance"...
Later, one could easily search for all movie files (extra)tagged "Romance", or "Comedy" and "Romance"...

Same goes for ebooks with e.g. "Art; Photo; Painting; Science; Maths...", etc.

Right now, the Pop-up List is an exclusive "single entry" radio list, so my suggestion is to have another Pop-up List column type based on "multiple entries" checked list.

Well, well... I'm sorry I didn't show up earlier during the elaboration process, I hope you're not too crossed.

Maybe you'll keep this idea for a later iteration of Extra Tags...

Have a nice day,
Flux

Posted: **15 Feb 2014 13:43**

Hm, damn it, why didn't I have this idea myself?!

Well, for 13.80 it's too late, but it will come with 13.90 for sure.

Posted: **15 Feb 2014 16:15**

admin wrote:
LittleBiG wrote:When I change a column type, the right click menu remains the previous one.
Also when I change the type back to text, the right justification should change back to left justification, not only after restart.
In addition, the justification should be changeable. For example the yesno box looks not so good right justified.
Confirmed.

I like them better right justified.

Changed my mind.

XYplorer Beta Club

New Columns

Re: New Columns

Re: New Columns

Re: Define current column layout as default

Re: New Columns

Re: Define current column layout as default

Re: New Columns

Re: New Columns

Re: New Columns

Re: New Columns

Re: New Columns

Re: New Columns

Re: New Columns

Re: New Columns

Re: New Columns

Re: New Columns