Disclaimer

This is MY Viewer, i decide which feature i want to add and which to remove, i share this Viewer to show the world that user base size is not important, i do rate quality by effort, thought and love put into the project, not some rough estimated numbers. I consider feature requests only if i you can name proper valid reasons i can agree on. It is my unpaid time i'm putting into this project, i'm not here to cater to every Joe's desires.

Wednesday, September 10, 2014

Progress Update to 2.4 (#5)

Seems like i will be using today's free time for changing so tiny things that you will never notice not even if i told you... the question is, why do i tell you anyway? I. Don't. Know.

Did you ever open up floaters like 'Inventory' and 'People' and thought: "Something in this floater looks incredibly fishy and i can't seem to find out what it is..."? I tell you what it is... these tiny little inconsistencies scattered throughout the entire UI are really annoying, so annoying they make my AV's boobs flat out pop like balloons. Look:


Just look at them, soak it up like a sponge and let the anger flow. It's really REALLY cringe worthy. Cut off buttons and slider drag bars, totally dis-aligned inventory panels, too much or too less space in-between widgets and so on.

I tried fixing this mess several times already, especially the Inventory which seems to be completely resistant to any change in its XML files, guess why, its because its another prime example of why doublehubletripledipplenipple hard-coding attributes of a widget and/or rewriting its functionality and or behavior several times throughout the code, overwriting the absolutely fine and properly working automated UI creation when working with the XMLUI system they made. Example?

In XML:

A button. It should follow the top and left edges of its containing panel. It is 200 pixel wide and 23 pixel high. It will toggle debug 'TestDebug'.

In code:

Above mentioned button should follow all sides. It should move horizontally depending on another button that is by default on the left of it. It has a parameter and function wired up that does essentially the same as toggling 'TestDebug' just in 5 times more steps and shows/hides another panel.

Outcome:

That button will now follow everything, resulting in it ignoring the predefined width and height and it will double-toggle 'TestDebug' which then shows/hides another panel, it will also move to the right depending on the width of the button on its left.

The problem:

That button now scales with the containing panel, which might have been a panel that is as big as the button was predefined as but now is not available anymore because i removed it, making it crazily big and filling the entire major panel/floater minus a given width on the left due to the button, which is also not there anymore because i moved it somewhere else (on the right as example), making the button re-position itself behind it causing it to go off panel/floater/screen. It will also hide that panel that may or may not be there anymore because i removed it because it only contained a button that had a fixed position that never changes no matter what and then made the button itself hide only, this could lead to a crash in worst case as the viewer is trying to execute an action with a not existing widget. There are more problems caused by this but i don't want to go more into detail here, i think that's a big example already.

The solution:

DO NOT HARD CODE THINGS THAT CAN BE EASILY DONE VIA XML SUCH AS TOGGLING A DEBUG OR SHOWING/HIDING A PANEL AND DO NOT EVER PLS HARD CODE ATTRIBUTES SUCH AS follows="" IN CODE, IT'S HORRIBLE AND CAUSES A LOT OF PAIN WHEN WORKING WITH THIS UI. Not to mention that it would save me going through several files looking for the problem, changing all kinds of UI code, just to fix a stupid inventory scrolling bar which is cut of a little.

Here's the fixed version (far left red rectangle):


The other red rectangles show these inconsistencies i'm talking about, too much space in-between widgets, dis-aligned buttons etc.

I know you may say why the fuck am i even doing this, this is just a stupid pixel being cut off. It may be just a stupid pixel cut off or a pixel too much space but it a huge part of the overall extremely low and buggy quality that is present in Second Life and i want these fixed, even if i have to go on a war with these.

What did we learn from this?
STOP DOING THIS MESS LINDEN.
Thanks.

PS: look into llfloatertools.cpp and floater_tools.xml and start removing all those double hard coded attributes, they don't belong there, they cause problems, they limit customizing and they can somewhat destroy and/or limit the translation process if you limit certain buttons and texts to certain widths and follows.

No comments:

Post a Comment