Feature: 3 tags per file

[mhkull]

In order to work with a larger number of files it would be of great help, to be able to add tags to files like: opener, workshop, closer, fast, smooth, morden, country ....

[danlyke]

I'd like a tagging thing too. The front page is already getting pretty crowded (which is why I added the "View->Compact" menu option, for my little netbook that I use to call), so I haven't been sure how to do this. One possibility: Another tab for the currently playing song that has meta information, and then a pop-up dialog that lets you search by that meta info? Maybe making the "Type" field search that meta info as well?

[mhkull]

Using the files meta tags is IMHO the best way to do it.

The only alternative I can think of is a directory solution. patter and subdirectories. However the automatic loop is only set to patter not its subdirectories. With this subdirectory solution you can select via the theme field - it works.

[danlyke]

So just musing out-loud: Some sort of right-clickable dialog that lets you put in text that gets appended to the "Type", those tags can then be used for searching and in the "what type of song is this?" controls?

[mpogue2]

Other suggestions for tags have been made: "high energy", "needs work"

[mpogue2]

Another way to do this, similar to what was suggested above: Allow tagging of a file, but instead of having a separate mechanism/columns, tagged files have a symbolic link created in the same directory where they are, and THAT becomes searchable via the type column.

For example, if there's /singing/Winter Wonderland.mp3, then it shows up as singing type. Adding the tag "Christmas" would create a subdirectory in singing called "Christmas", with a symbolic link to /singing/Winter Wonderland.mp3. It would need to inherit the song settings of the root file, rather than having a separate set. Maybe this could be simple: when double clicking on a file that is a symbolic link, it just opens up the original file.

Right clicking would allow assigning tags to individual files, based on known tags.

This would allow us to have only a single copy of each MP3 file, but would allow any number of tags, with the existing type mechanism.

[mpogue2]

Couple of ideas that we talked about: View > Tags > Irish, Energy, etc. View > Tags > Check all, Uncheck all Tags show up in smaller font, with a colored background (start with white on grey, or similar) tags show up after the title, not in their own column entry is via Context menu (right click) To search, use normal text in the title search field, e.g. "Summer Irish" would match "Summer Sound" with an "Irish" tag.

[danlyke]

Take a look at 5eef088c45b1f5c6812c139a7739036d963da6c4 . It just allows you to append text to the end of the title for each song. It shows up in a different color (right now it's reddish). I need to make searching work by breaking the words and then searching for subsequent substrings, but this is at least something that's broken that we can fix.

[danlyke]

Okay, 8e444170fdcee86ae3003abb68cea84e2a2e48e6 does the search for subsequent substrings thing.

[danlyke]

Oh, I should note the mechanism: Right-click on a song, select "Edit Tags ...", get a pop-up with a text input.

[danlyke]

Enhancement I need to add: Make it so we don't match the "<font color="... text that's inserted into the title, and make it so that any of the tags match no matter their order; the order stuff only counts for the title itself.

[danlyke]

Okay, I realized that tags should be searchable in any order, so a91823029c8a6abb0c383257bec2d363a4b57354 allows that. It also strips the "<font color=..." stuff so that searching on "font" or "color" no longer gives false positives.

[danlyke]

How do you feel about a '-' prefix as an exclusion operator? eg: '-sfgs' would exclude all songs tagged with 'sfgs'...

[danlyke]

Okay, bd4ed3bcf56ef7f389877b0d1a980a951da9b13d solves the double-click problem that I introduced when I changed that table widget to a label in order to get the rich text.

[danlyke]

85a62b0b5578c73b13bac4cadee9b909ae967906 has a background color for tags...

[danlyke]

Okay. We should choose a better (and stock) set of default background colors, but 7073c0803be152aa0e263e2e9c2223de5c4e8dca adds foreground and backgrounds selection on the main prefs page.

(Kinda freaky to add a preference. I'd forgotten that I'd had all of that automated preprocessor stuff, so I was like "okay, where do I add the saving and the... oh, right. Magic.")

[mpogue2]

OK, I finally have a chance to play with these! They are looking better and better! Bugs:

• I changed the FG color, and all of the fonts in the Title column went to "tiny". Cmd-0 brought them back to correct size.
• Tags are not currently persistent on Mac OS X at least...

Features:

• I am really hoping that each tag will have a separate FG/BG color. So, e.g. Irish would be white on green, etc. I think this means having a new Tags dialog box, or a Tags tab in Preferences, to be able to set these for each tag.
• "Edit tag ..." --> "Edit tag..." (get rid of the extra space?)
• Is there a way to do rounded corners on the tags in the Title column? This is a minor wish.
• The tags should ideally be in a somewhat smaller font.
• For assigning tags, it would be nice to have a pulldown menu of the existing tags, that could be "checked off" to add a tag, or "New tag..." to pull up the new tag dialog...I think this would work better than the string currently used.

Overall, I am really looking forward to this feature...I find that I want to use it already!

[danlyke]

On Sat, 10 Mar 2018 03:15:12 +0000 (UTC) Mike Pogue notifications@github.com wrote:

OK, I finally have a chance to play with these! They are looking better and better! Bugs:

• I changed the FG color, and all of the fonts in the Title column went to "tiny". Cmd-0 brought them back to correct size.

Okay, that's kinda weird. I suspect that there's something about the text edit that's going wrong.

• Tags are not currently persistent on Mac OS X at least...

We need to figure this out. It's working on Linux. They're going into the "tags" field of the "songs" table, though I did have one situation where I lost tags, but I was doing enough dev stuff that I might have nuked my database on that platform and started again.

Features:

• I am really hoping that each tag will have a separate FG/BG color. So, e.g. Irish would be white on green, etc. I think this means having a new Tags dialog box, or a Tags tab in Preferences, to be able to set these for each tag.

Yep, I think this means we need an editor, kinda like the sessions editor. That's a bit more work...

• "Edit tag ..." --> "Edit tag..." (get rid of the extra space?)

Easy enough. dfe881200cbb3ee415b59d439eae9888791d4d46

• Is there a way to do rounded corners on the tags in the Title column? This is a minor wish.

It might be possible, see the last decade of "how do I do rounded tags in CSS", I don't know how much QT does for this.

• The tags should ideally be in a somewhat smaller font.

I think this is possible.

• For assigning tags, it would be nice to have a pulldown menu of the existing tags, that could be "checked off" to add a tag, or "New tag..." to pull up the new tag dialog...I think this would work better than the string currently used.

Hmmm... I'll have to think about this a little.

Overall, I am really looking forward to this feature...I find that I want to use it already!

Yep, I'm gonna put it on my calling laptop today or tomorrow, there's too much good functionality there for me to hold off on.

[danlyke]

Whoops. Found a possible cause of disappearing tags, fixed that in a5f6a7c082ac4803d521feb4fcc060cc9fb67f32

Re font size: In mainwindow.cpp, SetTagsColorsFromPrefsManager, it's possible to put a "font-size: 10pt;" in that style declaration, but wiring it to deal with zoom is going to be more complicated.

[danlyke]

border-radius: on the <span ...> style does not work.

[mpogue2]

Bug: On Top of Tree (a5f6a7c082ac4803d521feb4fcc060cc9fb67f32), changing the color of tags causes font size to get small.

Feature: I say let's try the 10pt font for tags, and see what it looks like...I can help with zoom (I think!)...

[mpogue2]

Ah, the 10pt font does not work well at all, because the background color is still the height of the full-size text, so it doesn't look right. I also tried a bunch of CSS font properties, and most did not do anything. I was hoping to be able to change the height of the span, but it appears to be fixed. Small-caps looked nice, but still had the full-height-background-color problem.

I guess let's go with the full-size text for now. I think once we have the ability to set FG/BG colors for individual tags, this will look pretty good.

Idea: we might want a [X] Show Tags checkbox under View, in case they become too distracting, they can be turned off (but are still searchable?).

[danlyke]

Still searchable would be a PITA, at least until I can resurrect the song model notion that I was working on but abandoned because it became way too complex.

Once we get there... we may be able to do this by creating a much more complex sub-widget structure within the table: Create a Horizontal Layout widget, and encapsulate the individual text blocks within that.

[danlyke]

Duh moment on "still searchable": Could be white on white.

[mpogue2]

Sorry to say this but....background color for songTable rows alternates in color, and neither color is "white"... :-). OK, so maybe if they are turned off, they aren't searchable. That seems a small price to pay for having them available when they are needed.

[danlyke]

In retrospect, I should not have done this in the master branch, but...

There's now a color editor.

did not, alas, work to make tags invisible.

I still need to make the popup menu list the tags with check boxes.

[danlyke]

Okay 8e704dd713eac10382f9f343e930a0447354abac adds a "Tags" field with submenu off the context menu. We could promote this into the menu itself, but I wasn't sure how that felt with moving the rest of the menu around (it can get pretty large, depending on how you use tags).

[danlyke]

You can free-form tag with the "Edit Tags..." option, under the Preferences dialog edit tag colors and add or remove tags, and tags are also controllable in the sub-menu from the "Tags ▶" entry in the context menu.

Known remaining issues (aside from knowing that I've missed something I'm not accounting for right): Haven't figured out how to make 'em invisible but still searchable.

[mpogue2]

I'm playing with it now! Bug: In the submenu, there's a blank item at the top. If you choose it, it attaches a sliver of a tag to that song (presumably a tag with name ""?). You can unattach it from the song, too.

[mpogue2]

Hmmm...it went away when I added a tag to one song, but now it's back and I can't get rid of it. Try adding a tag that is a single space. Then I think it gets into this weird state...

[mpogue2]

Bug: when changing tag colors in Preferences, the colors of existing tags don't change when the dialog closes.

Related? Bug: ensureSchema : QSqlError("1", "Unable to execute statement", "unrecognized token: \"\u0003\"") ensureSchema : QSqlError("1", "Unable to execute statement", "unrecognized token: \"\u0003\"") "CREATE TABLE tag_colors (\n tag TEXT PRIMARY KEY,\n background TEXT,\n foreground TEXT,\n tag_colors tX0\u0003\u0001,\n songs_songname songs(songname),\n songs_name_idx songs(name),\n session_name_idx sessions(name),\n song_play_song_session_played_idx song_plays(song_rowid,session_rowid,played_on),\n call_taught_on_dance_program_call_name_session call_taught_on(dance_program, call_name, session_rowid)\n\n)\n" getTagColors : QSqlError("1", "Unable to execute statement", "no such table: tag_colors") getTagColors : QSqlError("1", "Unable to execute statement", "no such table: tag_colors") "SELECT tag,background, foreground FROM tag_colors"

[mpogue2]

Bug?: In Tag Preferences, there are two small color boxes at the lower left. I can click on them, but they don't seem to do anything. Maybe these are relevant?

QMetaObject::connectSlotsByName: No matching signal for on_pushButtonTagAdd_clicked() QMetaObject::connectSlotsByName: No matching signal for on_pushButtonTagRemove_clicked()

Question/bug?: How do I get back to the #RRGGBB notation? When I change a color, it just colors the whole cell with that color.

Looking pretty good so far...this is exciting!

[danlyke]

That create schema error is very concerning, because that looks like memory corruption that's occurring very early in the startup process.

The visible #RRGGBB notation is actually a bug, I'm using the exact same code to set the colors after selection as I am on creation, they should just be colors.

The blank tag thing seems like I need to make my tag split more aggressive, and not let us save blank tags...

Thanks. If you have any leads on the memory corruption issue that'd be awesome, I'll find some time to chase the others.

[danlyke]

Probably doesn't belong in this feature request, but with the latest master, 99f0df25ff3c33561425012299a8583cd5fc5dcb, I'm getting a pair of QIODevice::write (QTcpSocket): device not open warnings when the application first hits the main event loop.

I'll continue on the other stuff and hopefully this'll just go away... (he said, hopefully...)

[danlyke]

The two boxes on the lower left are supposed to be add and remove a tag. The mismatched slots name was causing that to not work. They're appearing with "+" and "-" in my build, but I may have gotten resource names wrong...

I think I've addressed the last 24 hours of bugs, aside from the memory corruption issue, I'll take a moment to go back and see if I can summarize...

[danlyke]

I changed the FG color, and all of the fonts in the Title column went to "tiny". Cmd-0 brought them back to correct size.

I think I need a little more detail to replicate this one.

Is there a way to do rounded corners on the tags in the Title column? This is a minor wish.

I think current state is "no, but would be nice"

The tags should ideally be in a somewhat smaller font.

This seemed like it'd have to be tied to a better way to render backgrounds, because the rectangles stay the same size.

I think 364e7a53f8e95f0f1149b26f3276397df8a4910f solves your song name color issue. I need a rundown on what's supposed to happen here, because I think there's a really cool feature that I'm not seeing on Linux, if I understand what it's supposed to do correctly.

[danlyke]

So that leaves us with a view/hide situation... For consistency, I think we don't want to allow tag interactions when tags are hidden.

[danlyke]

Thinking about this further, because I'm lazy and really don't want to do it, in what situations would someone tag their music library but want to suppress the tag display?

[mpogue2]

"I changed the FG color, and all of the fonts in the Title column went to "tiny". Cmd-0 brought them back to correct size. -- I think I need a little more detail to replicate this one." I will replicate and provide more detail. This was easily reproducible on earlier builds. I'll check with the latest!

rounded corners: "no, but would be nice" -- yep. P1 feature, not needed for shipment to Beta.

tags in smaller font: -- yes, I played with this, and could not seem to workaround it. the BG color is still full-size, even though the font is smaller. There's probably a way, but it may be more complex. I think we can put this on the list as a future feature request for now. This is also a nice-to-have P1 feature -- would not gate shipment to Beta users.

Tag hiding -- why? Lots of tags becomes visual clutter pretty rapidly, I think, and tags are only needed when we want to search by the tags. So, when we don't actually need to search-by-tag, it's nice to be able to hide them to reduce the clutter. Similar to being able to turn columns off when not sorting by them, or go to compact mode when those sliders are not needed. Saves space, reduces clutter, and easily turned back on when needed. Is this a critical feature? no. I would release to Beta without it. But, it's nice-to-have, I think. I think that makes it a P1, rather than a P0... :-)

[mpogue2]

I started up top of tree, and got this when the app came up (font size of Title is small):

After doing Cmd-0, then Cmd-+ several times, it previously went back to normal, but now in this build it's still small. Title is always the same size right now.

[mpogue2]

You can see that the colors are correct for Title now. The #RRGGBB is gone now, too...

[mpogue2]

Colors of tags are still not persistent, although SOME of them did change to the right new colors, but then they went back to black on green.

[mpogue2]

PLUS+ and MINUS- buttons look like this on Mac OS X:

[danlyke]

Aha! And Doh. Fixed the color persistence/table create warning error in 4511a5a9c4665a9554d9dae61c82a62130687223

[danlyke]

Can you open up preferencesdialog.ui in designer on your platform and copy the appropriate "list-add" and "list-remove" into those buttons? I can't see the difference between those and the session items, even looking directly at the XML.

[mpogue2]

@danlyke It doesn't look right in Designer, but I'm not sure how to fix it!

Do an all-files search for lock_icon, which works. Then do an all-files search for list-add, which doesn't. It looks to me like the iconset needs to be "resources.qrc", but it's currently "list-add". And, the normalon&off should be "/graphics/lock_icon.png", but it's currently ".". Same for list-remove.

QAbstractButton in the Designer shows "Theme" = "list-add", maybe that's the "iconset"? And, the NormalOff = "test123", maybe that's what "." does? This resources stuff has always been opaque to me...

I'm not quite sure how to fix this, but I suspect that the lock_icon is the model of what we should try....do you see icons on your screen on Linux? or "+"? or...?

[mpogue2]

Bug: header row no longer scales font size as the other items in the songtable change font size Bug: When I hide the tags, and the font size was large, the font size in the title column goes to small (should remain large).

[mpogue2]

General comment: tags seem pretty usable to me right now! They are colored nicely with user-selectable colors, they are persistent, when I change the colors, they change in the songTable, they are searchable without having to figure out some separate method to search them. Wow, when I hide the tags, type "hallo", I see just the songs with "hallo" in them, and then when I unhide the tags, it redoes the search to include both titles and tags. Exactly as I would have expected.

Nice.

I've gone ahead and merged in the bug fixes I was doing on a branch into master: 9cc692fc9e3613923e97f8de118fca40224522ba .

[danlyke]

I see icons on Linux, and I think I copied that over from the sessions editor, which I also see the icons for.

Okay, I've reworked all of those using the XML directly to look like the lock icon. Would you check out 380679e0f5db2d09b98358d4331fa3b589088287 please? Hopefully that has all the icons there.

[danlyke]

And if that works, I think our outstanding issue with tags is the header row font size (I don't know why that's wrong, but I can probably figure it out) and the font size changing when tags are hidden?

[mpogue2]

Yes, that worked! Cool!

Couple of minor UI things: In the "Edit tags" dialog, I think we would be fine using the filename without .mp3 at the end, rather than the whole path. Could even just be the Title, rather than the Label - Title. The dialog would be narrower. Maybe some help text, too, in a smaller font? (are they space-separated tags, case sensitive, commas not allowed, or ?). Maybe an example?

Yep, I think the only major open item is the header font size and the title column font size. It doesn't happen just when hidden....