User talk:Derf

From PS3 Developer wiki
Jump to navigation Jump to search

Wiki manteinance feedback

Syntaxhighlight

After some experiments i can confirm the syntaxhighlight extension is working, the reason why it was confusing me latelly is because time ago (when everything was working fine) we was using a different color selection for the xml language highlights
Long story short... we was trying to use the same default xml colors than notepad++ that looks a bit like this color sample and are a lot more friendly, but it was not exactly the same colors (was simplifyed for wiki)
As far i remember it was euss who did after a talk we had, but he never told me what he did, and now i think he customized some colors, today i been reading a bit the documentation and it seems there is a file named Genshi.css where the colors can be configured, i dont have access to that file but im guessing the changes was made in it, but im wondering it was lost years ago in one of the defyboy attempts to fix syntaxhighlight, if you have some old backup please take a look if there is some file with that color settings
For curiosity sake... at some point i was doing a tricky combination of templates "broken" in pieces where i was using real systaxhighlight tags with fake ones (forcing the color highlighting manually with <span style>) to match with the custom colors from the real syntaxhighllight. IE: in this section (click in edit to see how is composed and which xml code is real or fake highlight) that is loading chunks of the table from this template

  • Basically... i was doing this color selection (attributes in blue color:#000077, and the value of attributes in red color:#ff3333):
    • <span style="font-family:Courier New;">'''<Entry''' <span style="color:#000077;">positionX</span><span style="color:#ff3333;">="100"</span> '''/>'''</span>
  • To display it like this:
    • <Entry positionX="100" />

Right now i dont remember how i "chery picked" that colors, all i remember is i dedicated some time to match with what the sysntaxhighlight was doing (and all the other details about bold and font family was important because syntaxhighlight is doing it too), but as you can see the current color selection looks very different:

  • <Entry positionX="100" /> <--- Current
  • <Entry positionX="100" /> <--- Colored manually by me to match with the "old style"

So far thats the explanation of why i was not sure latelly if syntaxhighlight was working, and a rough resume of how it was customizzed, now if you want to know my oppinion about what to do with this there are some things to consider. The custom xml colors used by euss really looks way better than the defaults (this was an improvement). And some of the pages i made have a dependancy with that color selection (i know, this was a bad idea but at that time i was experimenting a bit with wiki, as usual). I would like to restore that custom colors but if there is some room for improvements im fully into it. As far i understand euss customized only 2 xml colors, but in notepadd++ are at least 3 and are asigned in a different way than what euss did, the idealistic color selection to match 100% with notepad++ would be something like this (with 3 custom colors):

  • <element attribute="value" />

If you find how to configure it to match this notepad++ color selection please do it because is better than what euss did --Sandungas (talk) 11:41, 22 April 2023 (CEST)

  • I don't have any experience with the extension, but I vaguely recall seeing an option to choose what color scheme you want to be default (like a preset palette) or an option to choose it via a parameter on the element via page editor. I'll look into it more when I get a chance - probably next weekend. Derf (talk) 23:59, 22 April 2023 (CEST)
  • The other day i found a way to remove all custom color dependencies that was matching with the old custom color settings of syntaxhighlight in the templates loaded by RCOXML Objects and RCOXML Animations. I dont remember if i was doing the same in other pages but incase some of you find more let me know and i will fix it, or fix it yourself this way (the magic is made by passing the variable {{{1|Element}}} to syntaxhighlight with the #tag: prefix to change the displayed xml code dinamically). We dont need to worry about this problem anymore, we can configure syntaxhighlight with any custom color (better than what we was using years ago) and that templates should load the new colors fine--Sandungas (talk) 13:04, 30 April 2023 (CEST)

In Special pages ---> Version it can be seen we are running MediaWiki v1.35.10 and SyntaxHighlight v2.0
I been lurking in the repositories of some versions of syntaxhighlight and it seems the old ones was using a file dedicated to each programming language (there was tenths, one of them named xml.css) but as far i understand the modern syntaxhighlight we are using that was shipped with mediawiki 1.35 is using a general color config file named pygments.generated.css. I guess you have this file in the server (under path "modules"), right ?
Well, one way or the other (in a dedicated file named xml.css or in a common file shared by all languages named pygments.generated.css) it works by assigning an unique ID to every hghlighted item, basically... to improve the xml highlighting you need to modify the nt (Name.Tag), the na (Name.Attribute), and the s (String)

Line 47: .mw-highlight .nt { color: #008000; font-weight: bold } /* Name.Tag */
Line 37: .mw-highlight .na { color: #7D9029 } /* Name.Attribute */
Line 36: .mw-highlight .s { color: #BA2121 } /* Literal.String */

For the new colors (trying to stick to some standard) i been lurking in the notepad++ repositories to copy the colors they are using that looks nice. Are set in the file named stylers.model.xml, are pretty much the same identifyers (TAG, ATTRIBUTE, SINGLE STRING)

Line 1436: <WordsStyle name="TAG" styleID="1" fgColor="0000FF" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
Line 1439: <WordsStyle name="ATTRIBUTE" styleID="3" fgColor="FF0000" bgColor="FFFFFF" fontName="" fontStyle="0" fontSize="" />
Line 1435: <WordsStyle name="SINGLE STRING" styleID="7" fgColor="8000FF" bgColor="FFFFFF" fontName="" fontStyle="1" fontSize="" />

To summarize:

  • nt (#008000) needs to be replaced by #0000FF
  • na (#7D9029) needs to be replaced by #FF0000
  • s (#BA2121) needs to be replaced by #8000FF

And the result should be: <Tag attribute="string">
To see the results while testing the new changes are handy the pages that appears in Template:File Formats under group "XMB Config" (i.e: XMB-Game), there is a lot of xml code in them
Sandungas (talk) 23:47, 3 May 2023 (CEST)


Good job narrowing it down to the exact lines. I made the changes, it looks good User:Sandungas! Derf (talk) 01:58, 4 May 2023 (CEST)


It looks better than ever :), a couple of details i did learn and i would like to mention before concluding this talk, just for the record
It seems the color config was intended to be generated automatically from a generic stylesheet.css the idea was to take a generic stylesheet as input (i.e: the vector-white skin we are using in wiki) and generate a syntaxhighligt color palette from it just by running a python command, is mentioned here in the original official documentation (a bit obsolete though, the syntaxhighlight used by mediawiki is an evolved version derivated from this)
The problem i see with that ptocedure is that is almost imposible that method could generate a nice color palette. Because you know... what we really need is a color selection that covers all programming languages, it should be intuitive and should be approved by lot of programmers that are already using it... and we dont care at all about aesthetics because it doesnt needs to looks pretty and doesnt needs to match with the wiki skin (vector, dark, or whatever you add later, the general skin doesnt matters), our only priority is for practical reasons
I dont really know where to get that kind of color selection, maybe there is something stable and well mantained from linux (debian, ubuntu, etc...), but by now the notepad++ color palette we added is fine and standard enought (notepad++ is a popular app anyway), if someone else wants to continue "importing" colors from notepad++ stylers.model.xml settings for the other programming languages please publish your suggestions here, im not going to do it, but i know there is room for improvements
The remaining problem i see right now is we "fixed" only the xml colors, but the color selection for all other programming languages looks like shit (it still amazes me syntaxhighlight is distributed with that default color selection, who made that color palette with cucumbers and pistacchios ?, dolce and gabbana ?, we are geeks, if some mediawiki dude is reading us, please give us intuitive RGBYK colors and thats all, this is one of the cases where the beauty is in the simplicity)
In the meantime i figured another alternative way to improve it that should work fine and should give a bit of consistency with what we already did, take a look at this, in the official page there is a live demo where it can be seen that it was intended to be configured by using only 11 colors !!! (and we already changed 3 of them), the weird detail is the file pygments.generated.css contains a lot more color definitions, but most of them are repeated for different programming languages
So... following that concept of using only 11 colors shared by all programming languages... i figured we could replace all apparences of #008000 by #0000FF (repeated 10 times), #7D9029 by #FF0000 (repeated 1 time), and #BA2121 by #8000FF (repeated 9 times) in pygments.generated.css. This should replace most of the default "vegetal" colors by the new colors we used for xml
Im not sure about the results, but i guess it worths a try. For the tests... there is a sample of javascript in Coldboot.raf#Script, python in CXML_Containers#CXML_decompiler, C++ in Syscon_Thermal_Configs/structs, TCL in PS3MFW_Builder, bash in Debian_LiveCD
Bonus: in one of the random google searches i found a dark theme, is mostly a curiosity because most probably doesnt matches at all with the vector-white skin we are using (the contrast in between white and black is going to be too much disturbing), but if at some point you implement the vector-dark skin or any other dark skin it could fit
--Sandungas (talk) 19:45, 5 May 2023 (CEST)


@Sandungas I went ahead and replaced all instances of those colors as you suggested to purge the vegetables out. I think it did the trick! This fix is fine, I'll just have to write a note to remember to make those replacements again when I update MediaWiki, since it will probably overwrite it. Regarding dark mode, I plan on eventually rolling out a dark mode to the site. Not sure if any are maintained at the moment, as when I setup ConsoleMods.org there were no maintained dark mode version of Vector, so I just made my own dark mode via Common.css. I should be able to paste it over to the devwikis once it's on the same MediaWiki version as ConsoleMods (which I'll update to 1.40 when it comes out). I should be able to just toss in a Common.css override for the SyntaxHighlight changes for dark mode (which I guess I could have done to solve this problem to begin with). Derf (talk) 05:44, 8 May 2023 (CEST)


Right now im not sure if there is some color conflict with other languages different than xml (eventually some wiki user could complain about what we did), but at first sight all them looks better than default, as far i remember i did read somewhere that there is a way to load the custom colors from an external .css file, this feature would be the less intrusive way to configure it and i guess it should survive the "update" procedure (mostly because the updater is going to recognize the custom edit and is going to preserve it in the new installation) but anyway yeah... better make a .txt somewhere to take notes of all customizations you did because the syntaxhighlight config can be improved a lot more, right now there are a couple of details that comes in mind. In the sony xml language there are a couple of characters (as far i remember one of them is &) that doesnt follows the .xml standards, and as a consequence most xml parsers and highlighters displays the code "broken" after the presence of that characters (the same problem happens in notepadd++ and any other app), and i guess they did the same in PS4, Vita an even PS5. While reading the legacy syntaxhighlight documentation i think i saw an option to add an identifyer for this kind of keywords that doesnt follows the language standards. Another thing that can be improved is the highlights for bash language, if you take a look at the legacy file dedicated for it in older syntaxhighlight packages you are goin to see it contains a huge list of kwywords to identify all the unique bash commands
I dont know how to do any of this two things, but eventually we could return to it and try to see if we find how to do it, by now i dont want to enter in this forest because would extend this conversation too much
I thought there was only a Skin:DarkVector, and it was considered official and well mantained but sadly is abandoned. And the other dark skins in Category:All_skins differs too much with vector, thats a problem
Right now i only see two options, either use the abandoned skin i mentioned (i like the color palette but im not so sure how much differs from the default vector), or what you did about taking the vector skin and customize it (only the colors, not positions, sizes or anything else, we need it to be simple to swap back and forth from vector-white to vector-dark without hassle), you could install both as a temporal test
Btw, im pretty sure one of the tricks i been doing in some wikitables to hide table cells is going to be problematic with a dark skin because i was filling the table cell backgrounds and borders with white in RGB notation color:#FFFFFF (invisible over a white background, but very notable over a black background, oooops), the solution is easy, we need to use RGBA notation color:rgba 0,0,0,0 (fully transparent black) or with syntax color:transparent, if some of you finds this kind of mistakes feel free to fix them
--Sandungas (talk) 14:00, 8 May 2023 (CEST)