Editing the Viewer's Look & Feel

[EnCore Mayne]

a long, long time ago ... sometime around or about the v2 rewrite there was a lot of talk about tweaking the revolutionary changes made to the viewer's UI to make it more palletable for new users. of course, since i didn't have a computer science degree i thought some genius would heed the call and generate a viewer that was both useful and far less "feature rich". something more atuned to a new user's sensibility, not one providing mana to a nuclear physicist (as it is currently).

not that all the bells and whistles aren't technically applicable (to the short list of hackers and coding doctoral candidates) it's just a little much to be offering up tweaks that at a single button press could undermine the actual  ability to ever launch the damned thing again. so, yeah, providing these scrumptuously powerful functions (to any and everyone) may have had some deliterious affects on maintaining and/or preserving the unwitting curious user.

aside from all the other myriad amount of applied excuses for plunging user retainment, to which i'm unable to facilitate anything other than complaining to the wind, i've actually taken up a new study that seems to warrant wasting an inexorably lengthy amount of my time. and, without having any other skills outside of editing text inside the viewer's xml files i seem to have created what i think is a better UI.

no C++, python, GitHub pulls, or similarly antithetical computer/human interface logic. the whole user experience can be customized just by tweaking the viewer's xml files! what a boon to humanity. how come no one ever told me: your world, your imagination...?

so..., after countless hours pouring over the extraordinarily excessive xml skin files my viewer's look and functionality is getting closer and closer to being what i had wished for for far too long.

hence, the reason to originate this topic. i'll be using it to release significant "code" snippets that alter the status quo. some are subtle while others completely revolutionize how one interacts with our little world. i'm hoping those "in the know" can offer helpful advise and discussions. if any disruptors wish to send the topic sideways i would suggest compiling a voluminous Ignore page. if i don't respond, you'll know why.

that being said, i'm looking forward to using this forum to promote and encourage others who might want to reduce their frustrations with the way things are with a little effort on their part to make the viewer act the way you want it to. no excuses, it's really quite simple.

i'll try to format my posts along the way with a feel for a non-technical, ordinary human language. thanks for your indulgence and patience as i organize my findings. tooodly-do.

[EnCore Mayne]

welllllll, if i only knew what kinda work it was gonna take to put some coherent details of this process online, ....

sheesh.

when it comes to explaining just how to get to where i've gotten it takes a mite stepping back into memory and routines that i've developed to a comfortable level of functionality and efficiency. unravelling that horrific pile of interwoven entangled mess (my education as well as the order the code has revealed to me) is a grueling chore. least alone illustrating the various poignant points along the way. you're welcome. it's a calling. i expect nothing but the best.

getting that out of the way, yes i'll soldier on, just don't expect installments to be rapid fire. these posts will NOT be on a schedule. should i get to the dishes, or put another graphic together.... decisions, decisions.

of course, i'm sure everyone's got their own way of organizing their flow. i'll just lay out what i've been doing and some fundamentals might fall out along the way. in other words, you don't have to follow all the steps i've taken (if there are workarounds and alternate paths please inform me).

this adventure began with a noodle in my head saying: wouldn't my second life be better if i could move that button over there, what about reducing the screen size of some floaters?, how about making that widget smaller, larger, etc., etc..  come along for the ride if you've ever had similar notions as to making the viewer conform to what you think is best for you.

just be warned. there are a total of 634 xml files in the default folder. not counting the files for the Starlight variant (10), i've tweaked 150 in some manner or another. nonetheless, if you only want a menu option moved you might stick to only editing a few. but believe me, once you know how, you won't want to stop on just that one.

anywho, to another day. (how to find the xml files you will need to tweak)

[Love Zhaoying]

Have you tried, or considered trying using AI to tweak the files? Just curious, I haven't tried anything with AI myself (at all, except building a resume).

 

Edited January 9 by Love Zhaoying

[Love Zhaoying]

Hi @EnCore Mayne, I got your message in-world.  Putting my question about using AI aside:

Are you familiar with applications used specifically to edit XML files? I am referring to applications that "understand" the XML file format. NOT applications such as Notepad, Notepad++, Word, etc. (text editors).  If not, then I can see how it would be especially tedious to edit the files.

Personally, I have only used XML file editors that come with various development tools.  I could search for some "free" ones online (or see if any with my "free" development tools work nicely).  Unfortunately, these days I only really use JSON file editors - so will have to do a little basic research.

Sorry if I asked anything that you mentioned in your post or message.

[Love Zhaoying]

Separate answer: If all you need to do is "mass search and replace", you can use a tool like "PowerGREP". (I was familiar with GREP but not "PowerGREP".)

https://stackoverflow.com/questions/31463847/mass-find-and-replace-in-multiple-xml-files

[Nalates Urriah]

Hummmm......  🤔

NiranV has the same idea, make a better user interface. You can see his efforts in Black Dragon.

Henri likes the old v1 user interface. You can see that in use in Cool VL Viewer.

The Firestorm Viewer has multiple user interfaces a  user can switch between.

The SL Viewer has a UI designed by professionals trained in UI design. They have done considerable A-B testing with the SL Viewer. The Lindens think the SL Viewer is best for the new user. Debatable.

The SL Viewer and third-party viewers have very similar features built into the viewer's foundation code. The major difference is in the UI. Firestorm makes many more features available in their version. Apparently, users prefer the more complex viewer as about 75% of users use the Firestorm Viewer.

Your idea of editing the UI XML files is not something a newbie is going to do. Those making viewers already work with the XML files. I don't expect anyone to pick up your idea of editing and publishing a modified viewer. So, if you think it is a good idea, you'll need to do it yourself.

 

[Katherine Heartsong]

1 hour ago, Nalates Urriah said:

The SL Viewer has a UI designed by professionals trained in UI design. They have done considerable A-B testing with the SL Viewer.

I hope this doesn't get me into too much trouble, so I'll be a diplomatic as I can, but ...

As someone who has spent a 30+ year career in UX/UI for some awfully major corporations globally, and now spends my days directing the entire design process and strategic design directions for that type of company, I find that statement just a tiny bit difficult to reconcile with the current UX/UI of the default LL viewer.

[LittleMe Jewell]

3 hours ago, Katherine Heartsong said:

I hope this doesn't get me into too much trouble, so I'll be a diplomatic as I can, but ...

As someone who has spent a 30+ year career in UX/UI for some awfully major corporations globally, and now spends my days directing the entire design process and strategic design directions for that type of company, I find that statement just a tiny bit difficult to reconcile with the current UX/UI of the default LL viewer.

Yeah, well, you aren't the only one. 

Nobody actually provided the credentials of the 'UI professionals', so......

 

This would also be why she said (with me highlighting her opinion on the statement):

5 hours ago, Nalates Urriah said:

The Lindens think the SL Viewer is best for the new user. Debatable.

 

[Katherine Heartsong]

20 minutes ago, LittleMe Jewell said:

Yeah, well, you aren't the only one. 

Nobody actually provided the credentials of the 'UI professionals', so......

This would also be why she said (with me highlighting her opinion on the statement):

I saw that word and fully agree.

[EnCore Mayne]

the xml (eXtensible Markup Language) files used in the SL viewer are similar to HTML files as they utilize opening and closing tags containing elements with attributes. and, please, if you do consult the wiki be prepared for the state of confusion inherent in having C++ code monkey ENGINEERS describing a graphical interface. it's like they were from a different world altogether. did they ever imagine their little toy would be used by non-geeks? in the present state, with far too little effort concentrated on the code's graphical look and feel, i think not.

there's a right way and a wrong way to dump data. without a graphical and workflow sensitivity, as we are attempting to communicate with this series, one can accept all manner of defects and flaws as long as it runs. praise be to whatever gods they prayed to that they left us with a way to move the bits and bytes around without tromping on their viper's nest of code. whoever conceived of using xml for the viewer was a far-sighted genius and belongs in the SL Hall of Fame.

nonetheless, suffice it to say, xml should be a simple way to graphically represent the underlying code data. at its best it's like arranging graphical blocks. unfortunately, at this retarded level of development no none's decided there should be a graphical interface to preview changes on the xml file so it's all text based editing. yes, after 20 years. it is what it is.

there are a couple of rudimentary methods to view the results of your xml edits i'll get to later, but since there are sometimes a complex number of files dictating the look of any one specific element their usefulness is clearly limited. that's another failure of the overall development strategy. since, from my study, there doesn't seem to have been any overarching policy regarding adhering to any existing norms it's devolved into a "do whatever works" attitude. so; duplications, redundancies, and complications abound. can you say, "a mess"?

a closer look to streamlining or decluging the entire repository of xml files would take a higher level project authorization. a small number of xui zealots might take a month or two to throw together something were they supervised correctly. it's not impossible, would NOT affect any code, and would certainly make editing a smooth forward trajectory.

unfortunately, we are where we are. so before they catch up and ruin our fun, let's describe how changes are made (by me) presently.

this is a snippet of some of the language and formatting used in an xml file to communicate back to the SL app. this particular file controls what elements the SL program puts onto the screen when you click on a store's vendor.

there's a whole bunch of gobbledeegoo happening behind the scenes (the source code referencing this xml file is here) but essentially the xml tells the program where various bits like buttons, checkboxes, icons, sliders, etc. should go. where the money goes is anyone's guess. how we came to find this particular file for the Pay Resident window/floater/whatsit takes a bit of sleuthing. it's not just a matter of right clicking the object in the development viewer and you're given all the files that paint this on the screen. i wonder if the Lab has a tool for that? (call me). one must resort to doing a text search for the floater's heading text. there are other ways to narrow down all the files but that will have to be in the next installment. there's a lot of guessing and praying. as it is for this instance, i use Notepad++ for one of its primo features. not only is it a good lsl and xml editor but it's a formidable tool for looking for search terms inside an entire directory's text files.  plug in the "Pay Resident" as the search term, match the case, and Search in Files brings up two resultant files that are subsequently loaded into the editor. the code snippet appears in the image above.

that's as far as i'll go for now, stay tuned as we go into specific elements applied to resolve the nuisance of not having the creator's entire product text showing in the window as well as revealing some handy dandy tools divining what's hiding in plain sight.

Edited January 11 by EnCore Mayne
edited out goobledee***** -banned word

[EnCore Mayne]

another method of divining which xml files are used to create the various interactive components is the XUI Preview Tool that can be brought up before one actually logs in. that can be handy since a lot of the edited components need a relog to see what changes you've made. the intention of the Preview Tool, i suppose, was to give one a live view of the affects made in editing the xml.

	unfortunately, the title column isn't normally populated with anything for the majority of the components and relying on the filename supposes a greater knowledge than one might have should one be idly wanting to fool about with editing the UI. but, nonetheless, it does reveal some semblance of usability. it lists all the files within the default skin folder. in this instance for my install, that's C:\Program_Files\FirestormVersion\skins\default\xui. if you are using any variant of the Firestorm's skins (i'm using the Starlight skin) you won't be able to use the Preview tool unless you swap out the default file with the Starlight file you'd like to be privileged to get a live preview of. unless you have a good grasp of where your skin files are and you have considerable experience replacing edited files with your backups (an absolute must!) i wouldn't adventure into changing the default skin files. as it is, should one want to fool about with any of the skin files i would HIGHLY RECOMMEND you make a backup of any or all files before you edit anything. a single errant button press can stall the viewer from loading. if you do take on the challenge, i suggest you save frequently. perhaps after a single width= edit or whatever may appear as an insignificant alteration. you'll be amazed at just what havoc you can cause with the simplest attempts.
with my chosen editor Notepad++ (you can plug in whatever is your choice in the Editor Path) Ctrl-Z will soon become your best friend. no, editing the XUI is not for the timid. but formidable graphical eyecandy can be achieved should one venture to learn. just be prepared to undo what you just broke. there are plenty of peculiar unforseen traps.
once you've taken the appropriate precautions of backing up any file you wish to alter you can mash away at the system file with abandon. let's just be a little circumspect as to just what you are atempting to do. the columns are alphabetically sortable. sorting the "File" column will reveal there are essentially three types, floaters, menus, and panels. floaters are the overarching container that houses panels. menus don't have a preview. choose any particular file by highlighting its listing and then Show will reveal what the component looks like. it's dragable and the various elements are active. so, changing sliders, radio options, and number parameters WILL affect inworld settings! we're only editing the look and feel so don't mess with those settings. there's no X for closing what's showing so it must be closed with the Hide button. clever, huh? i'm not sure what the other buttons available buttons are but if you want to experiment with them be my guest, just don't blame me when your entire life's destroyed. did i mention you should BACKUP BACKUP BACKUP and BACKUP? i think we've gotten ourselves in as much trouble as necessary for this segment. next we'll find a XUI bug in the newest version of Firestorm and fix it ourselves.

[EnCore Mayne]

vid showing the process for correcting the newest Firestorm's XML for the "Buy Contents" floater (floater_buy_contents.xml).

JIRA report

Edited January 17 by EnCore Mayne
add jira report

[EnCore Mayne]

i've chosen another floater, this one; the viewer's  newest feature to add thumbnails to any inventory item, to illustrate the capacity for the simplest XML edits for making remarkable changes in the look and feel to the user's experience. take a look at the illustration below and see if the changes don't fulfill your every desire.

instead of a YouTube vid i've posted a heavily documented file online for anyone to peruse. it's just one file, so if you're brave enough you can copy and paste it into your skin folder as: floater_change_item_thumbnail.xml. just make sure you've made a backup of your original because, well, come on, you should know by now.

there are a few other files affected by this floater (the snapshot button opens a new floater floater_simple_snapshot.xml) that i've edited but not documented as of yet. i'll put it up later and post its link when i can. as it is now you'll just have to deal with the jarring inconsistencies.

[EnCore Mayne]

! DANGER WILL ROBINSON DANGER !

if anyone using the XUI Preview Tool is having a hard time reconciling what the preview tool is showing from the edits they are doing you're not going insane. seems there's a bug that, in my case, shows the Starlight file instead of the default skin's file.

until i can get my head around this new information i can't recommend using the XUI Preview Tool. i'm thinking maybe NOT having a copy in the Starlight folder might suffice. updates on this issue may be forthcoming.

[EnCore Mayne]

okay, looks like the problem is loading a file into the XUI Preview Tool. everything works just the same if you edit outside the tool. as in, load the file into your editor from its directory, saves will be updated in the tool's viewer. DON'T load from inside the tool's Browse to Editor Path option.

thanks to fabulous Zi Ree for jumping on this. fix will be in the next release.

Edited January 22 by EnCore Mayne

[EnCore Mayne]

i've come to rely on the XUI Preview Tool for tweaking the viewer's xml files. it's so much better than waiting through the login process just to see one itty bitty change; a pixel here, a pixel there. the tedium of perfection is always challenging.

unfortunately, when the tool was designed there was no such thing as Firestorm's medley of skin choices. now that the devs have been made aware of the monstrous amount of foraging through code to fix the Tool's issues, i can only offer them my condolences. the way the open sourced viewer has been put together the viewer's capacity for utilizing multiple skins is not something i'd want to rethink. but what do i know, it could just be a simple variable and all the files the Tool lists could one day be from the applicable user defined skin files. 

until that day i've altered the Tool's xml to have additional details presented as to how it can be confidently used. don't mind the removal of some of the peculiar non sensical buttons and options they just complicate matters.

as it is, the file listed in the Tool only displays default skin files BUT the preview shown is derived from the user defined skin, in this case my customized Starlight silver_blue theme. knowing which default file has an overriding user defined skin file is going to take some exploring. at this time i've only needed to edit 11 of the available 78. so there's a good chance you'll only be editing the default files. you'll know when nothing happens to the shown preview. time to go looking for the alternate.

if anyone wants to swap in this file it's here. it's from the 6.6.14 version of FS but it should work with the 6.6.17 version. need i remind you? backup, backup, backup....

nonetheless, the only way to know is to see if the filename listed has a user defined file.

[LittleMe Jewell]

Do you ever feel like you are talking to yourself here?

[EnCore Mayne]

if you really want to get serious in personalizing your viewer, have a look at mine above and picture one for your self. it's only one xml file (panel_fs_nui_login.xml) and no you can't mess up your logins fiddling around with the look and feel the xml files provide. no functions or calls are altered, we're just arranging graphic blocks again.

i can't stress this enough, for those squeamish in wrangling the xml files, i assure you, no code has been harmed in any of the processes we've done to date. the consequences may result in numerous crashes (if you don't dot your t's and cross your i's) but at worse you'll just have to revert to an earlier backup. nonetheless, you won't destroy anything that the far more daunted code-monkeys-underlying-it-all have avoided/created.

the scary C++ references are in there, inside the xml code, but we just move their entire functional "blocks" from one place to another. not having a GUI to help in moving text-based graphic elements is certainly no fun but once your head is sufficiently programmed in the basics it'll become natural, hahahaha....

i suppose we should delve into some of the commonly used elements we're trying to arrange. continuing along with the login page example the most significant blocks used in this particular screen are:

•     web browser,
•     icons,
•     drop down boxes (or combo boxes as they're referred to in SLspeak),
•     check boxes,
•     buttons,
•     line edit boxes, and
•     text boxes.

i'll have another graphic that illustrates how, what, where, and why these elements appear in the code. until then, you're more than welcome to chat with me inworld. don't be shy.

[erineni]

tl;dr fully. But for what I've read is just as me imagined before. Too big of a mess.
One year ago me tried to change the font that SL Viewer uses to show all Unicode characters. There's not much to tell 'xcept it was like useless to change coz it wont work. . . nonetheless me had a dream a dream for a videogame-level kind of UI. one that was immersive...  
Your approach seems feasible. And I would love to learn more about all this

Ta for the info! and me will deff try 10/10 
 

[EnCore Mayne]

10 hours ago, erineni said:

One year ago me tried to change the font that SL Viewer uses to show all Unicode characters. There's not much to tell 'xcept it was like useless to change coz it wont work. . . nonetheless me had a dream a dream for a videogame-level kind of UI. one that was immersive...  
Your approach seems feasible. And I would love to learn more about all this

Ta for the info! and me will deff try 10/10 
 

i feel ya. it's a nightmarish hellhole to be sure. the Linden responsible for the xml upkeep (if they exist at all) should be ashamed.

not so clued in about unicode. i have added some extended ascii symbols to the menus tho, so there's that....

glad to see the vision is still alight. check out:

for a real futuristic feel. not sure they are still with us tho. true genius no matter.

[EnCore Mayne]

 

well, that was a deep rabbit hole. i don't think we give graphical illustrators enough credit. making sense of the code is one thing. i think i have the capacity for that. but putting together a cohesive rendering of the exploratory vision is sending my time accounting for this topic outside of expected parameters. following this seemingly endless journey to understand what-does-what-and-how may seem unweildy in its length but hang in there it's best if you were committed.

as referenced earlier, the login graphic has a small number of elements that appear on our screens.  i've reordered them to better illustrate the coherence between the graphic and the code behind it. each of the elements are easily recognizable, they're graphical, that's easy.  recognizing that particular element's actual code amonst all the other foreign terms can get a mite difficult if you don't know how the xml file is constructed. that's why i've arranged the elements the way they are. as the code is written/read top to bottom, that's how the elements are arranged. it's not always that way, but for this instance, it works. how that exception is understood, think of it like putting the element code on the inside of a box bracketed by start and stop tags. so, if you put the code for a bottom appearing element in a box at the top of the xml code it might not show up where you might think it might. fun huh? non the matter, our current example follows a top down design. so, keep in mind that the code for each element can be shown as a box as i've illustrated by the red box below. that code, depending on where it goes in the overall package, paints the code's instructions. for example, this is the code for the web browser: we're not going to get into the attribute details of this element yet. we have to address the box that these various graphic elements go into. a box within a box. in this case the <web_browser /> code goes into the initial box as constructed by the xml code's tag <panel> ...content... </panel>. the initial panel tag, called the root in xml speak, contains ALL of the elements. everything between the starting tag to the end. so everything written in the xml file, the entire 298 lines, falls within the start/stop tags of the root panel and is constrained by the attribute's quoted string values. there's a bunch of attributes that can be utilized for any element. since we're only editing the existing code, we're not going to experiment in the XML Preview Tool to find out just which attribute works. most terms are pretty much common sense as to what they describe. remember, these xml tags were conceived by the original designers of the viewer. they're proprietary and won't work in any other application. i'll explain each of the individual attributes next post.