Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[markf2748]

32.0.19 (2/19/2024)
5. Changed: Made the alphabet above a file list stretch to the full width instead of being all left aligned.

32.0.20 (2/22/2024)
3. Changed: The view header alphabet allows clicks in the space around letters instead of only on the letters.

I like both of these changes.  However, in MC's alphabetical lists, entries starting with numbers are at the top of the list, preceding the letter "A", which is the usual convention.  So why is the numbers entry in the alphabet header last, all the way to the right, following "Z"?  I would prefer it to obey the same logic as the lists themselves, i.e. "0-9" all the way to the left, preceding "A".

[gappie]

i agree with this, i love the changes, and 0-9 at the left would be more logical.

 
gab

[Matt]

Deal.  Thanks.

[HPBEME]

Since you're already in that area doing some work, can I tag on one more enhancement request?  The huge mouse target area around the letters is awesome, but the underlined letter is a little difficult to see.

In the attached picture I mocked up an idea where it would be both highly visible and I think easy to implement. As the mouse moves over the letters, simply swap the header background and text colors to highlight.

[markf2748]

Deal.  Thanks.

and ...

It occurs to me that having "0-9" rightmost is useful in the following sense:  if mouse is over to the right, then easy access to "0-9" provides a quick jump to the top of the list (without moving mouse across the screen), a move which I perform far more often than clicking any single letter.  "0-9" is effectively a "return to top" button.

So consider "bookending" the alphabet header list with "0-9" at both ends!  Seriously, I would like to try this. I also think it would look cool as a design element - balanced like having two spectrum displays in the header.  Worth a try, but I understand if others disagree.

Speed Moves:  Currently, multiple slow single clicks on an alphabet header letter marches the highlight through the entries for that letter one at a time, starting with the first.  Nice feature, but something I barely use because it is too slow in most cases.

Speed it up with <double click> or <shift><click> on a letter as an alternative to mouse searching/scrolling:
1) jumps highlight to last entry for that letter
or
2) jumps highlight forward, for example 5 or 10 entries at a time, through that letter and beyond
or
3) jumps highlight forward one line at a time in the case of thumbnail display

<Ctrl><double click> or <Ctrl><Shift><click> respectively would reverse direction of the highlight moves.

<Shift><double click> and <Alt><double click> or other perhaps more logical combos could implement more than one entry in the above list.  You get the idea... 

[HPBEME]

It's occurs to me that having "0-9" rightmost is useful in the following sense:  if mouse is over to the right, then easy access to "0-9" is a quick way to jump to the top of the list (without moving mouse across the screen), a move which I perform far more often than clicking any single letter.  It is effectively a "return to top" button.

Dude! You're killing me! Or more accurately, you're killing Matt. 

I actually had the exact same thought, that having it on the right saves having to move across the entire screen real estate to get to the beginning.  But Matt already agreed to move it to the left, so I wasn't going to push for it.

That said, I like your idea of book ending it for the reasons you state.  Also like your idea for additional functionality via double-click. 

Does anyone like my idea for improved highlighting as you hover over letters?

[markf2748]

Does anyone like my idea for improved highlighting as you hover over letters?

It already underlines the selected letter, and bolds it, which definitely helps.  But the bolding is barely noticeable on my smallish monitor - slightly modified Black on Black skin with Segoe UI Semibold 10 font.  The underlining should be made thicker, maybe double what it is now, and positioned slightly lower if possible.

Improved highlighting by switching local background color under the letter would further help.  It would have to be done in a way that works across all, or at least most, skins. The same skin highlighting used when mouse hovers over a line might be a good "universal" choice (if it can be limited to region around a single letter).  Your illustration of reversing colors over the letter "K" (which I initially missed) should also be a good universal solution that maintains the contrast built into the skin.

[HPBEME]

It already underlines the selected letter, and bolds it, which definitely helps.  The bolding is barely noticeable on my smallish monitor

I think the bolding is barely noticeable because the letters are not bolded. I zoomed in at 500% and when I hover over it there is no difference. Matt can confirm if bold is currently included or not.

Improved highlighting by switching local background color under the letter would surely help.  It would have to be done in a way that works across all, or at least most, skins. The same skin highlighting used when mouse hovers over a line, or hovers over a tab as you illustrate, might be good "universal" choices (if it can be limited to region around a single letter).

It will definitely work across all skins, as long as <LIST> Text is used, and not OverText, SelectedText, HotText, or DisabledText. Obviously Matt can specify which to use.  For the other swap color, <View Header> Background should be used, and not HeaderBackground.

As someone who has spent a great deal of time working with skins, I can say with confidence that if these two suggestions are followed, it will work well with every skin. I've evaluated the 30+ skins I have locally, and all would have high contrast (or at least as high contrast as it is with current highlighting) using this approach.

[markf2748]

I think the bolding is barely noticeable because the letters are not bolded. I zoomed in at 500% and when I hover over it there is no difference. Matt can confirm if bold is currently included or not.

Attached combined screenshot shows "K" deselected (left) and selected (right) from my desktop monitor (old Dell U2412M 24" 1920x1200, monitor brightness/contrast = 48/48).  The brightness difference is more subtle than I would like, a bit of a struggle, but it is there and noticeable at MC View > Size > 100%.

The strong pixelated coloration (likely the limit of anti-aliasing), especially in the diagonals, is apparent if you download and zoom into the attached image.  It's acceptable for visual appearance at actual size and viewing distance on my monitor, but would very likely be improved by using Sego UI Semibold 10 font, still without going whole hog bright and thick.

Another approach, while keeping bold + underline, would be to kick up the font size by a couple of points when letter is selected.  That will make the selection quite apparent, look alive without a color blast, and would be my preference.

[HPBEME]

The difference you're seeing in the text letter upon hover is not because it is changing from standard to bold. For Modern Cards Dark, the OverText color (A3A3A3) is a slightly brighter color than the standard Text color (909090).  This is why the change is so "subtle".  See the relevant code from the XML's list section below.

https://www.color-hex.com/color/909090
https://www.color-hex.com/color/a3a3a3

Relevant Code:
<LIST>
<!-- Note that Text color will also affect borders around certain items. -->
<Colors Text="909090" Back="2b2b2b" SelectedText="000000" SelectedBack="3A3A3A" HotText="018fff" Gridline="333333" GridlineBack="2f2f2f" OverText="a3a3a3" />

[HPBEME]

FYI: this is why trying to control the highlighting using only <LIST> text colors is unwise.  <LIST> text hex colors vary drastically across the multitude of MC skins which will result in very inconsistent highlighting outcomes for different skins that you were concerned about.

My suggestion of combining the <LIST> text color with the <VIEWHEADER> HeaderBackground color solves the issue.  The background color is always going to be something highly contrasting with the text color… Simple as that.

[markf2748]

@HPBEME:  Thanks for all your insights and suggestions about skinning the header alphabet.

In the old Black on Black skin which I use, many of the <LIST> <Colors ... /> attribute settings in its main.xml file are not active, for example SelectedBack, OverText, OverTextColor don't do anything AFAICT.  I find that SelectedText actually behaves like OverTextColor for this skin with current Header Alphabet, in that it determines mouseover color and the color does not stick through a selection.  Thankfully it has no influence on tab labels.

That is all OK for me.   After an alphabet jump I usually scroll around album thumbnails, oftentimes leaving the original jump letter region.  I really don't want to visually "cement in" the Header Alphabet letter from which I jumped - it no longer carries any useful information.  I view it as a momentary pushbutton.

It seems the mouseover underline is not skinnable - at least I could not identify a multi-state bitmap image that controls the background.  It is the common underline for mouseovers on a lot of text (for example immediately under thumbnails in the Content Panel) and seems pretty well baked in at this point.  Not a problem since I have the contrasting mouseover color.

So the solution for improved mouseover highlighting is simple but unexpected:  Choose a contrasting color for the Header Alphabet text mouseover and use it to set <List> <Colors ... SelectedText= " " .../> </LIST> (at least in this skin).

Bug:  Setting SelectedText color to solve this problem has the effect of setting and holding the color for other List selections (as one would expect).  It looks like there is a bug here with OverTextColor, which does not work as it should for Header Alphabet.  I am not sure if there is an error in the way the Header Alphabet is programmed (most likely), in the skin itself, or my understanding.

Feature Request:  Add a Skin Item <HEADERALPHABET> ... </HEADERALPHABET> in main.xml to allow independent skinning, including font, font size, etc.

Win 11 23H2 64-bit | MC 32.0.21 (current beta)

[Matt]

The alphabet uses the list text color and list selected text color.

[markf2748]

The alphabet uses the list text color and list selected text color.

That is the problem.  The List SelectedTextColor does not stick after selection for the alphabet, but it does stick, as expected, for other selections such as tracks in a list.  So there is something wrong here.

But the action I am really looking for is OverTextColor, I think.  I want text color to change during mouseover, but revert to list color when mouse moves away.  Currently I have to set SelectedTextColor to do this, which is wrong.  At least that is what I find for the Black on Black skin.  I have not checked other skins.

Both List coloration actions should work for the alphabet to satisfy a wide range of users.  Ideally, alphabet should have its own "sub area"  Name section with additional options, but I realize that may be a lot more work to program.

[Matt]

Next build we'll try this:
Changed: The view header alphabet uses the text over color instead of the text selected color on mouse over.

[HPBEME]

Next build we'll try this:
Changed: The view header alphabet uses the text over color instead of the text selected color on mouse over.

Using only <LIST> text colors will have unintended consequences for ALL list items - and MC uses lists everywhere.

By making the <LIST> OverText and Text colors different in order to better highlight the alphabet, also means when moving your mouse over a long list, the text color will also change there.  BUT... Hovering over list items is already highlighted by the List Selection PNG file.  Standard GUI guidance recommends against using two strong/different methods to highlight a single element. Doing so is redundant and generally unattractive.

Not saying there is never an exception to this, but my personal preference is that the List Selection image PNG does the list highlighting, and NOT have the text color change too. This must have been how the original skin authors felt as well (using only a list selection image and NOT changing text color), since the majority of skins do NOT use different colors for OverText and Text. Consequently, this change will have zero impact on most skins (i.e. underlining the letter will be the only detectable highlighting).

Knowledgeable users can of course modify existing skin XML's to some preferred color, but that defeats the whole purpose of making a feature request that is universal. In order for this to work across all skins, JRiver would need go through each one and adjust the various <LIST> text color inputs as needed, or the highlight effectiveness and attractiveness will be wildly unpredictable from skin to skin. I am pretty confident no one at JRiver wants to spend time doing that.

Unless my suggestion is exceedingly difficult programmatically, I am baffled as to why there is such resistance to flipping the background and text colors to create the alphabet letter highlight. This will not conflict anywhere, and it will work - guaranteed - for every skin. This is because if there wasn't contrast between the list text and the background, the entire skin would be effectively unusable. 

The only adjustment I would make to my original request is to use the <LIST> Back color.  The only reason for that is because the oldest/original MC skins (Aruba, Green Eyes, Noire, PixOS, Thunderstorm) do not have a <VIEW HEADER> section, and thus not possible to use a background color from a nonexistent XML section.

[markf2748]

BUT... Hovering over list items is already highlighted by the List Selection PNG file.  Standard GUI guidance recommends against using two strong/different methods to highlight a single element. Doing so is redundant and generally unattractive.

OK, but if alphabet is a <LIST> item, then why does the highlighting from List Selection PNG file not show up in an alphabet letter selection?   Does it need to be specifically implemented in the alphabet programming?

Unless my suggestion is exceedingly difficult programmatically, I am baffled as to why there is such resistance to flipping the background and text colors to create the alphabet letter highlight. This will not conflict anywhere, and it will work - guaranteed - for every skin. This is because if there wasn't contrast between the list text and the background, the entire skin would be effectively unusable. 

The only adjustment I would make to my original request is to use the <LIST> Back color.  The only reason for that is because the oldest/original MC skins (Aruba, Green Eyes, Noire, PixOS, Thunderstorm) do not have a <VIEW HEADER> section, and thus not possible to use a background color from a nonexistent XML section.

How does the programming effort involved in this suggestion compare to that of giving alphabet its own named section in the main.xml file, which I think, perhaps naively, would solve the problem in the most general and flexible way?

Thanks.

[HPBEME]

OK, but if alphabet is a <LIST> item, then why does the highlighting from List Selection PNG file not show up in an alphabet letter selection? 

I presume because the MC code doesn't use list selection PNG for the alphabet letters.  As for why it doesn't use it, that is a question for Matt.

How does the programming effort involved in this suggestion compare to that of giving alphabet its own named section in the main.xml file, which I think, perhaps naively, would solve the problem in the most general and flexible way?

I am not a coder, so I cannot say. I know the skin XML file probably probably better than anybody with the possible exceptions of Matt and Marko, but the XML is merely an input file that the actual MC code ingests.  That said, I would speculate my approach would be far easier… Why?

- The <LIST> text & back inputs already exist in every single skin, even ones that are 20+ years old. I am guessing the code revision would only require which hex color inputs are pointed at for alphabet letter highlighting.

- Your suggestion requires adding a brand spanking new section to every single skin, old or new. Then, colors have to be picked and tested for suitability/effectivity for every skin. This is not a five or ten minute task. I think my request is potentially a five or ten minute task.

[markf2748]

- The <LIST> text & back inputs already exist in every single skin, even ones that are 20+ years old. I am guessing the code revision would only require which hex color inputs are pointed at for alphabet letter highlighting.

- Your suggestion requires adding a brand spanking new section to every single skin, old or new. Then, colors have to be picked and tested for suitability/effectivity for every skin. This is not a five or ten minute task. I think my request is potentially a five or ten minute task.

I don't know the code either of course, but the effort will be the same for both approaches in terms of deriving the default colors for header alphabet highlighting in every skin according to your universal inversion suggestion.  It's only implementing such default colors that is different in the two approaches.

Meanwhile, I think Matt is initially headed in the direction of perceived least resistance:  simply use a subset of the skin's <LIST> <colors ... />, don't worry about a "universal" high contrast color choice, and use the default bitmap to get the underline.  I really look forward to this as an easy, acceptable compromise that just requires a little adjustment to my preferred skin.

However, as you point out, the simple List solution inherently couples the Header Alphabet appearance with other List items in the skin.  So to work well "out of the box" in many existing skins, the List solution needs to accept a user-defined List bitmap file, such as list_selection.png, acting on a per letter basis in the Header Alphabet.  Your <List> text & back is a prescribed alternative to this, which also addresses potential loss of contrast due to back color.

A more flexible solution is to introduce a new Sub Area for Header Alphabet within <LIST> or add a new Skin Item (external to <LIST>).   As you know, Sub Area name sections have been done many many times before for other UI features - they are found throughout main.xml.  They may take some additional programming effort compared to <List> text & back, but I don't know how much.

If a new Sub Area becomes available, I strongly suspect (and hope) there is no requirement whatsoever to add the new Sub Area to every existing main.xml file, since as you say it is merely an input file.  Hopefully an encoded default such as your universal default, or optionally leave it alone, can be used in the absence of the new Sub Area in the file.  But if a knowledgeable user, or skin designer for that matter, wants something different, then I hope they could simply add the appropriate <Entry Name="HeaderAlphabet" .../> line within <LIST>...</LIST> or add a new Skin Item <HEADERALPHABET> .. .</HEADERALPHABET> to their favorite main.xml file.  Then they can be off and running to choose options for any desired colors restricted to header alphabet alone (assuming minimal specification documentation is available).

Wiki Reference:  Standard View Skinning SDK
https://wiki.jriver.com/index.php/Standard_View_Skinning_SDK

3/2/2024 Edited for clarity multiple times.
3/6/2024 Add wiki reference and modify terminology to agree with it.

[HPBEME]

I live for the day where you simply just agree with one of my posts... that day is not today.