Blog update, added new article.

blogs/2022/2022-06-12_please_do_theme_your_distro.md

@@ -0,0 +1,170 @@
+# Please do theme your distro
+
+---
+
+This article is mainly written as a complaint against a number of GNOME
+application developers, who had decided to complain against distro maintainers
+that install non-standard themes in their distributions. One such notable example
+is https://stopthemingmy.app/, but there exist more such movements out there. In
+short, these devs want distro maintainers to always ship the GNOME desktop in
+its default theme.
+
+Now this might not sounds like a lot. Admittedly it's not. It's one of those
+things where I just think someone is straight up wrong, and trying to push their
+wrong deeper into the world.
+
+## The argument
+
+GNOME devs are currently expressing a desire to remove theming support from
+the GNOME desktop, which arguably already is half-removed. As it currently
+stands, using themes (better known as GTK stylesheets) already requires
+installing some tools just to access the feature. But it's there, and can be
+used if desired. Some linux distributions, like Ubuntu, by default ship with a
+custom theme.
+
+However, GNOME devs argue that custom themes break their applications. Well,
+some of them do anyway, largely depending on the theme even. Yet it's enough
+to set some over the edge and complain about it. Quoting from the
+before-mentioned webpage, "GTK Stylesheets can make applications look broken,
+and even unusable." They continue to argue even about icon themes as well, noting
+that "Icon Themes can change icon metaphors" and "Changing an app's icon denies
+the developer the possibility to control their brand."
+
+In a way, what they argue for is complete control of the visual representation
+of their applications. Including icons and all.
+
+## What I think they got right
+
+While there's a lot wrong with their arguments, let's first focus on what I do
+agree with; a dev needs a certain amount of guarantee that their app is going
+to at least look properly and functional in the system where it's distributed on.
+That means certain visual components should have a predictable look. Icons should
+be what you predict them to be.
+
+There's also something to be said about their argument regarding programs like
+Blender, Atom and Telegram.
+
+> We are tired of having to do extra work for setups we never intended to
+> support, just to have that used against us when people tell us the breakage
+> from theming is “not that bad”. You are not doing this to Blender, Atom,
+> Telegram, or other third party apps. Just because our apps use GTK that does
+> not mean we’re ok with them being changed from under us.
+
+It is indeed unjust if the platform tools you use leave you at a particular
+disadvantage, in contrast to those not even using platform-specific tools.
+However, wanting the design-freedom of an electron app is an entirely different
+topic.
+
+## Where they dropped the ball
+
+What I do not agree with however, is their demand for total control. While the
+argument is aimed at distro maintainers, what I wonder is how much that even
+would do; in the end, users most often will do a little theming of their own
+if it suits them. And icon theme here, a little gtk stylesheet there, are not
+difficult to install. Which leads me to my first counter argument:
+
+*If your application relies so heavily on a particular look, why use platform
+tools like GTK?*
+
+GTK (formerly the GIMP ToolKit) is a toolkit made for designing graphical
+applications. It provides you with standardized controls and widgets, that
+adhere to the system theme coloring and other styling properties. That's the
+job of the toolkit; to provide a standard-compliant set of tools for you.
+However, that also binds you to such standards and the limitations they have.
+If you want your application to fit in with GNOME, you use GTK. If you want
+you application to live its own life, make an electron app.
+
+This is also why such mentioned apps like Telegram and Atom have an "edge".
+These are basically web applications, styled by their own CSS stylesheet,
+ignoring the desktop theming completely. This isn't because GTK devs or distro
+maintainers are purposely making things difficult, it's the inate difference
+between GTK and electron. Speaking of electron and CSS:
+
+*Your application won't break if you set your style classes correctly.*
+
+Yes, the things that so often break are in fact custom controls, made with
+custom CSS styling that does not adhere to the system styling. To complain
+that a different theme breaks them is more an admittance of shoddy programming.
+Such custom controls are often added "to set the application apart from others"
+which in and by itself isn't a bad thing to do, but it's more often done for
+the visual "wow factor", rather than functional ingenuity. Which also brings me
+to:
+
+*Your application is a tool, not a brand.*
+
+Computer programs have a fundamental purpose on a computer. It's to make the
+computer do *thing*. The purpose of a program should be to perform a particular
+task, to help the user do something. Billboards were made to promote brands.
+Besides, I'm a firm believer that a good program will promote itself. People
+will always come back to an application that does exactly what they want, as
+easy as possible.
+
+Adding to that, I would argue it's not the right of the developer to tell a
+user (or distro maintainer for that matter) how to use their system. If they
+want the authentic Hot Dog Stand experience, that's their prerogative. The
+user controls their system, and distro maintainers control their distro. This
+brings me to my next point:
+
+*Distro maintainers have the right to make their distro anything they want.*
+
+After all, the distro maintainers already have a fairly involved job. Theirs is
+to compile a large sum of software in order to create a linux distribution, a
+system suitable for daily use with all the tools people would want. It's not
+far-fetched to consider that it is therefore also the duty of the maintainers
+to cater to the presentation of their distro, not merely to promote their image,
+but to provide a pleasant, convenient and consistent desktop experience for
+users. After all, a distro that looks like a cluttered mess is not very nice
+to use.
+
+Regarding convenience and a consistent desktop, let's also consider another
+particular group of users: those that require accessibility tools. No doubt
+the bane of these devs, because they need things like *custom high contrast
+themes*, *enlarged icons*, and perhaps even more particular things that no doubt
+would make an application look hideous. But for these people, it is a must.
+
+*People with physical limitations need accessibility options.*
+
+While it is fair to state that this is strictly about end-users and not the
+distro maintainers, I do still think this is a fair counter point to make.
+Maintainers should have a way of adding options to help people with limitations
+use their distro. And that could very well be implemented in the form of modified
+looks meant to increase contrast and readability, which would naturally conflict
+with all sorts of custom GUIs, worst offenders being electron apps, which
+straight up don't listen to such settings most of the time. This also really
+boils back to the "your application is a tool" argument, if your program is not
+usable for these people, there's little point to whatever fancy look it might have.
+
+## What they can do about it
+
+Frankly, much of what the GNOME application developers say is just straight up
+bonkers. As said before, what they want is a form of control, over both the
+distro maintainers and users, basically telling them "your system should look
+like we tell you to". This however flies straight in the face of what open-source
+development is supposed to entail. It's about being open and collaborative, not
+about being closed and dictating.
+
+*If you don't want users tinkering with your application, consider not developing
+open source software.*
+
+Now that line I should not need to say considering GNOME devs are supposed to be
+GNU people. But GNOME has been so anti-open in the recent times that I would think
+it's needed now.
+
+Another suggestion I can give to application developers is to not rely on hacky
+toolkit exploits and Adwaita-specific quirks to build your programs, as that
+quite locks you into being a full-blown quirk-program, entirely dependent on
+those exploits. This naturally does not carry over well to anything that isn't
+an Adwaita theme, so doing things that way, you kinda set yourself up to fail.
+
+*Do not rely on quirks. Keep it simple, and compliant.*
+
+Lastly, I would wholeheartedly invite the GNOME devs to open their minds to what
+the linux community has to say. We don't complain because we like to bash. We do
+so because we're fed up with the dictative abuse. The same things that made us
+run from Windows and OSX, are now the very things seeping into GNOME. Such would
+be a shame, given how much the GNOME desktop meant to people in older times.
+
+As to the other readers, I would say "please continue theming your system". It's
+your system, you do with it what you want, and nobody can tell you otherwise.
+The same goes for distro maintainers; please provide us with a consistent, good
+looking desktop right out of the box. Give us a system we can *use*.

index.html

@@ -103,9 +103,13 @@
                         </p>
 
                         <h2>2022</h2>
-                        <p>
+                        <table class="blog-table">
-                            Yes I am writing some new stuff, please wait :3
+                            <tr>
-                        </p>
+                                <td>12 Jun 2022</td>
+                                <td>"Please do theme your distro"</td>
+                                <td><a href="blogs/2022/2022-06-12_please_do_theme_your_distro.md">.md</a></td>
+                            </tr>
+                        </table>
 
                         <h2>2021</h2>
                         <table class="blog-table">
@@ -227,10 +231,10 @@
                 </div>
                 <div class="content-tab" id="changelog">
                     <h1>Changelog</h1>
-                    <ol>
+                    <ul>
-                        <li>first</li>
+                        Blog update:
-                        <li>second</li>
+                        <li>Added new blog entry "Please do theme your distro".</li>
-                    </ol>
+                    </ul>
                     <ul>
                         1.5.1 Patch:
                         <li>Added colored logo</li>