Request/Suggestion to all TPV creators

[Extrude Ragu]

Markdown support would be perfect IMO. It could just be a checkbox to turn on to maintain backwards compatibility.

My reasoning being: The majority of Notecards most consumers on SL deal with are product notecards they receive after purchasing products. What do product notecards contain? Structured information, instructions, FAQ's, different sections..

The easier it is for the consumer to consume structured information (readability) the faster they are enjoying their product and the less mental stress that comes with parsing a wall of text with their brain. Enjoyable shopping experience = more sales, healthier SL economy

/tedtalk

[Henri Beauchamp]

24 minutes ago, Lucia Nightfire said:

When we're talking about features that do not yet exist, they invest in things they assume will be popular once implemented, whether or not there is already public demand or industry standards.

I can only speak for myself, but my main motivation for new features is their actual usefulness to me in the first place (after all, the Cool VL Viewer has been created for myself in the first place, I never pretended it would suit everyone's needs and preferences).

This is, for example, the case of the viewer-side Lua scripting feature that I developed. I wanted it for myself, in order to customize the viewer for circumstantial or specific needs, that would be too much of a burden (and too much added bloat) to implement in C++... This feature also happens to offer to all users a way to customize the viewer features and even UI to their own needs... I could well add a way to change text fields background color or fonts in Lua, rather than adding yet another setting to only note card floaters.

Edited August 16, 2022 by Henri Beauchamp

[Qie Niangao]

Computing in 2022: Creation of virtual world 3D content is relegated to standalone third-party applications, but text editing? That "core functionality" gets a proprietary implementation embedded right in the platform! And in SL, each third party viewer contributes their uniquely incompatible editor geegaws and doohickeys.

[Ansariel Hiller]

18 hours ago, Lucia Nightfire said:

Nice. Now if only something could be done about that harsh white background during editing, then it will all be complete.

Maybe notecard background and text color options in a new Preferences > Color > Notecard tab?

Hmmm... okay: https://vcs.firestormviewer.org/phoenix-firestorm/changeset/75e50d06708f3b97245f4c3b729536ca16a2999f 😁

[Love Zhaoying]

Gosh, with all this positive feedback, Phil may ask for other stuff too!

[Phil Deakins]

23 hours ago, Coffee Pancake said:

Different people like different things or have different needs.

 

So you're saying that some people actually like to be given notecards where the formatting is way off? Of course they don't.

[Phil Deakins]

4 hours ago, Love Zhaoying said:

Gosh, with all this positive feedback, Phil may ask for other stuff too!

Lol. What positive feedback? Qie is the only one I've seen who supports notecard compatibility between viewers. Everyone else seems to be happy that notecard formatting gets screwed up between viewers.

[Love Zhaoying]

2 minutes ago, Phil Deakins said:

Lol. What positive feedback? Qie is the only one I've seen who supports notecard compatibility between viewers. Everyone else seems to be happy that notecard formatting gets screwed up between viewers.

The ones showing information on related Firestorm features are implicitly agreeing with you. A lot of new features start in TPV's and end up in the official Linden Second Life viewer later. 

[Phil Deakins]

10 minutes ago, Love Zhaoying said:

The ones showing information on related Firestorm features are implicitly agreeing with you. A lot of new features start in TPV's and end up in the official Linden Second Life viewer later. 

Oh. I hadn't noticed them. My mistake. I didn't read very carefully, and I thought people were maybe mentioning TPV options that could change fonts for notecards. It's the default fonts that I'd like to be standardised, so that a notecard written in one viewer will display the same in other viewers (I'm not concerned with the background).

This doesn't need a new feature. The official viewer uses a font. All I ask is that TPVs don't change it. When LL produces a new viewer, the TPV producers get the code and change bits of it to what they want. All I ask is, don't change the notecard font. It'll save a bit of work

It's not a very good attitude to decide to change the font, knowing that the notecard formatting will look bad if it isn't viewed in the same viewer.

Edited August 17, 2022 by Phil Deakins

[Solar Legion]

Congrats - if you want standardization, use the standard viewer or petition Linden Lab itself to enforce such.

Outside of that, all you can do is use what tools TPV dev teams give you to make requests/suggestions and hope they adopt them.

Edited August 17, 2022 by Solar Legion

[Lucia Nightfire]

6 hours ago, Ansariel Hiller said:

Hmmm... okay: https://vcs.firestormviewer.org/phoenix-firestorm/changeset/75e50d06708f3b97245f4c3b729536ca16a2999f 😁

Thanks a lot. Can't wait to try it out.

[Ardy Lay]

Deja Vu?  I am relatively sure Linden Lab changed notecard and floating text with the release of Viewer 2.0 and caused much screaming and yelling in the forum.

[Kathrine Jansma]

14 minutes ago, Ardy Lay said:

Deja Vu?

Totally. They changed it to the DejaVu font. (with some Helvetica in between, that got exchanged for DejaVu)

https://bitbucket.org/lindenlab/viewer/commits/d6101558a171dbd2390792ac1e78d09fc2c27711#chg-indra/newview/skins/default/xui/en/fonts.xml

Edited August 17, 2022 by Kathrine Jansma
Clarify that i was Helvetica first.

[Coffee Pancake]

No one mention unicode. Shhhhh!

[Istelathis]

On 8/16/2022 at 2:01 PM, Henri Beauchamp said:

Nice...

I got another suggestion. Add an option to make SL less of an eye sore, something like this, for example:

🤣

I like this idea, and have seen it implemented through an apple ][c

 

Personally, I would like to see this added to a Commodore 64.  

[Coffee Pancake]

46 minutes ago, Istelathis said:

Personally, I would like to see this added to a Commodore 64.  

I've seen this done with a beefy FPGA pumping data into the userport .. so .. more computing power to do the encode than the machine rendering the display.

[NiranV Dean]

On 8/16/2022 at 8:22 PM, Henri Beauchamp said:

This is not a ”requirement”, just a possibility offered to advanced and motivated users...

Requiring TPV developers to implement a gazillion configuration options is not wiser, especially when a new user will be faced with such an enormous amount of configuration options that they will get lost. Not to mention code bloat...

At least in V2 you do not need to add any code for color options. All colors found in colors.xml can be changed and hooked up to a color swatch UI widget without a single line of code. HOWEVER. You cannot change script floater colors, notecard colors should be fine though.

To add to what you wrote: Changing the notecard colors will require you to go into the notecard floater file (preview_notecard.xml) and change its text field colors to either a different one found in the colors.xml that are already existent or added for this purpose (which can then be targeted via color swatches). Otherwise you'd have to change the global colors for all text fields, this may have unintended results as some text fields may be set up to use a certain color, changing them might make the text unreadable.

Back in Nirans Viewer i did offer a host of common UI colors to change via the color swatches to recolor the total UI to your liking. I have long dropped that idea, while it was cool it was... too subtle and ultimately not supported anymore with Black Dragon's new skin that was made to offer a very specific look, changing the colors would impair readability and destroy the overall look.

On 8/15/2022 at 12:52 PM, Phil Deakins said:

I am frequently disappointed when I find that notecards written in one viewer are literally spoiled in others. It's because the lengths of the = and - characters are different in different viewers. Those characters are commonly used for lines in instructions, and lines in one viewer can be almost half as long again, or shorter by a third in another viewer. Also tabs vary in width in different viewers.

I'm assuming that different TPVs choose different fonts for notecards and, if that's true, then it should never happen. So TPV creators, please don't change the default notecard font from what's in the official viewer. If you've already changed it, please change it back. Let's have notecards displaying the same in all viewers.

Thank you.

 

BD uses the default font LL uses. I have not touched fonts and i don't recommend changing them either because the UI is absolutely trash when it comes to fitting itself to different fonts. The entire UI is designed for a very specific font, replacing it would break large parts of the UI.

(also why is it scaling this image slightly up rather than showing it in its original size, its making it blurry...)

(also hhnngg why is that edit button one pixel off to the left... *insert Heavy "who touched my Sasha" meme*)

[Wulfie Reanimator]

On 8/15/2022 at 8:57 PM, Lucia Nightfire said:

I'm still waiting on a monospace checkbox in notecards. And color options. The white background is harsh.

https://jira.secondlife.com/browse/BUG-4706

My notecards have a black background. It's been that way for so long I don't remember if it's something I did (probably), or if something affects it... but it stays that way between viewer versions, so there's hope for you!

Edited August 18, 2022 by Wulfie Reanimator

[Ansariel Hiller]

1 hour ago, NiranV Dean said:

HOWEVER. You cannot change script floater colors, [...]

Really? Hmmm.... 😏

[NiranV Dean]

48 minutes ago, Ansariel Hiller said:

Really? Hmmm.... 😏

Is it possible in the official without editing the keywords file? I was referring to Henri saying that it requires extra code to set it up, giving an example how it doesn't with notecards and most of the UI and another example how it does require code for the script floater specifically because it isn't using the colors.xml. Also, i forgot to mention that any color in colors.xml is saved meaning any UI part using them will survive relogs.

Edited August 18, 2022 by NiranV Dean

[Henri Beauchamp]

1 hour ago, Ansariel Hiller said:

Really? Hmmm.... 😏

What a nice colour for a demonstration !... In French it is called ” jaune caca d'oie” (which would translate to ”goose poo yellow”). 🤣

Edited August 18, 2022 by Henri Beauchamp

[Henri Beauchamp]

3 hours ago, NiranV Dean said:

I have not touched fonts and i don't recommend changing them either because the UI is absolutely trash when it comes to fitting itself to different fonts.

That's one of the very reasons why I did not change the original v1 fonts for another in my v1 viewer... Finding a font that looks as good as the original one in all UI elements is close to an impossible task. That's also why the ”one font fits all viewers” wish of the OP will never happen (at least never for my own viewer), but I just added a debug setting to allow changing the note card editor font with any font present in your system...

Quote

All colors found in colors.xml can be changed

Yes, in all viewers, via the debug settings floater... Just give the color name as the debug setting name. Colors are defined in the skin/whatever/color_base.xml file in v1 viewers, and this file can be overridden by the user (as I already explained in my former posts) to avoid having to edit it every time they update the viewer.

Quote

you do not need to add any code for color options

Well, yes, you do, if you want to make it a user-friendly changeable option: you need to add color reverting code support in a preference tab menu, for example... Firestorm obviously coded it as a separate preference floater for the script editor.

Quote

HOWEVER. You cannot change script floater colors

You can in the Cool VL Viewer, since I added skin-able color names for all script editor colors years ago already.

And I just added new skin color names for the note card editor, so there, people will be free to change that as well (including via Lua now), if they so wish...

Edited August 18, 2022 by Henri Beauchamp

[NiranV Dean]

2 hours ago, Henri Beauchamp said:

Yes, in all viewers, via the debug settings floater... Just give the color name as the debug setting name. Colors are defined in the skin/whatever/color_base.xml file in v1 viewers, and this file can be overridden by the user (as I already explained in my former posts) to avoid having to edit it every time they update the viewer.

No via preferences.

The baseline preferences window has color swatches hooked up to a function to retrieve colors and set them already (for nametag colors for instance). It looks as follows:

<color_swatch
can_apply_immediately="true"
follows="left|top"
height="40"
layout="topleft"
left_delta="-49"
enabled_control="NameTagShowDisplayNames"
name="mismatch"
top_pad="7"
width="44">
  <color_swatch.init_callback
  function="Pref.getUIColor"
  parameter="NameTagMismatch" />
  <color_swatch.commit_callback
  function="Pref.applyUIColor"
  parameter="NameTagMismatch" />
</color_swatch>

Pref.getUIColor and Pref.applyUIColor can be used on any color swatch inside preferences and filled with the name of the color in colors.xml we want to target in the parameter slot. This allows targeting any and all colors as long as they are defined inside the colors.xml, which in turn means any color that is set somewhere in any of the UI files since we can just set any UI widget to use any given color defined in colors.xml (or define our own directly). This means the entire UI is recolorable, by simply creating an override skin. Since the skinning system is intelligent enough to take any missing parts from the base skin we can simply write a very basic override for any part of the UI by navigating down the folder structure inside the file and targeting whatever parameter (in this case color) we want to change.

For the above color swatch inside my panel_preferences_ui_colors.xml this could be as simple as the following file:

<panel name="UI Colors">
   <scroll_container name="ui_scroll">
      <panel name="ui_colors_panel">
      	<color_swatch name="mismatch" can_apply_immediately="false"/>
     </panel>
  </scroll_container>
</panel>

This would change the attribute "can_apply_immediately" to false for the color swatch named "mismatch" inside UI Colors/ui_scroll/ui_colors_panel panel folder structure. We can do the same with say color, text_color, bg_alpha_color and so on to change the colors and ONLY the colors of something.

Doing so would save the changes past updates and using the color swatch to change a defined color in colors.xml allows us to save the color changes past sessions and updates too.

This is why i love V2 skinning, its so wonderfully dynamic and infinitely extendable... and i hate it because LL abuses it to do bad UI translations, constantly redefining width and height of buttons they translate when they REALLY shouldn't and the translation fits into the button just fine... or they could... you know have the base button (english) immediately be laid out to fit for ALL languages, in fact why can't the entire UI just be laid out to fit them all. It grinds my gears when you change something in the english UI and suddenly a polish, russian, spanish or whatever user comes up and is like "my UI looks completely *****ed" because in the localization they redefine a lot of layout parameters turning the UI into a freaky amalgamation of the localization and the original and if you don't know that you look around trying to figure out why its breaking.... THIS is why i got rid of all languages besides english and german.

2 hours ago, Henri Beauchamp said:

Well, yes, you do, if you want to make it a user-friendly changeable option: you need to add color reverting code support in a preference tab menu, for example... Firestorm obviously coded it as a separate preference floater for the script editor.

My Viewer still has no reset for color swatches but that's actually a good idea, resetting colors either involves manually deleting the entry from your colors.xml file in AppData, deleting the entire file (which resets ALL colors) or using the menu entry buried somewhere in advanced/develop i think (which also resets all). The user friendly color swatches don't need any extra code, at least not in V2 where color swatches can be easily added via XML only and preferences has a generic retrieve and apply color function that can be used (as described above).

2 hours ago, Henri Beauchamp said:

You can in the Cool VL Viewer, since I added skin-able color names for all script editor colors years ago already.

But i wasn't talking about your Viewer. Baseline the script editor defines its text colors in the keywords.ini file which makes sense as it allows us define a separate color for every single LSL command or data type but has the issue that we cannot change them easily via the UI unless we specifically code it to use targetable colors (from colors.xml for instance) or separate debug setting colors (which would be stupid to do if there's colors.xml already offering a much better solution free from our settings file). While yes the script floater is at its core just a text editor and we can change its background color (since its just a text field widget) we cannot change the text inside it without editing the keywords.ini file making a lot of the text potentially unreadable or very eye soring depending on the chosen color. Also editing the keywords.ini file is not saved past updates either.

What you should do is make a dynamic system that lists all available script commands and allows you to sort them into color groups, so people can recolor every single LSL command dynamically to their liking, the system would be infinitely extendable, anyone can create a new group for any commands and give them a specific color... well or you could just hardcode the... what is it? 12 colors?

[Henri Beauchamp]

14 minutes ago, NiranV Dean said:

Baseline the script editor defines its text colors in the keywords.ini file

I changed that, over 5 years ago, when I implemented skin-able script editor colors (color values have been replaced with Lsl*Color setting names that are themselves mapped to actual color values in each skin colors_base.xml file).

Edited August 18, 2022 by Henri Beauchamp

[Phil Deakins]

23 hours ago, Solar Legion said:

Congrats - if you want standardization, use the standard viewer or petition Linden Lab itself to enforce such.

Outside of that, all you can do is use what tools TPV dev teams give you to make requests/suggestions and hope they adopt them.

It's nothing to do with LL. It's not them who mess things up. My post requests TPV producers to not change the font that LL uses for notecards, because it messes the formatting up for people who don't use the same viewer. There is absolutely no need to do it. It's just a change that improves nothing, but does screw something up.