Bundling AppImages with Themes.

One of the projects which I have been undertaking in recent weeks has been, to teach myself GUI programming using the Qt5 GUI Library, of which I have version 5.7.1 installed on a good, tower computer, along with the IDE “Qt Creator”. What can be observed about this already is, that under Debian 9 / Stretch, which is a specific build of Linux, in addition to just a few packages, it’s really necessary to install many additional packages, before one is ready to develop Qt Applications, because of the way Debian breaks the facility into many smaller packages. Hypothetically, if a person was using the Windows, Qt SDK, then he or she would have many of the resources all in one package.

Beyond just teaching myself the basics of how to design GUIs with this, I’ve also explored what the best way is, to deploy the resulting applications, so that other people – technically, my users – may run them. This can be tricky because, with Qt especially, libraries tend to be incompatible, due to even minor version differences. So, an approach which can be taken is, to bundle the main libraries required into an AppImage, such that, when the developer has compiled everything, the resulting AppImage – a binary – is much more likely actually to run, on different versions of Linux specifically.

The tool which I’ve been using, to turn my compiled binaries into AppImage’s, is called ‘linuxdeployqt‘, and is not available in the Debian / Stretch repositories. However, it does run under …Stretch.

But a developer may have questions that go beyond just this basic capability, such as, what he or she can do, so that the application will have a predictable appearance – a “Style” or “Theme” – on the end-user’s Linux computer. And essentially, I can think of two ways to approach that question: The ‘official but slightly quirky way’, and ‘a dirty fix, that seems to get used often’…

The official, but slightly quirky way:

Within the AppImage, there will be a ‘plugins’ directory, within which there will be a ‘platformthemes’ as well as a ‘styles’ subdirectory. It’s important to note, that these subdirectories serve officially different purposes:

  • The ‘platformthemes’ subdirectory will contain plugins, that allow the application to connect with whatever theme engine the end-user’s computer has. Its plugins need to match libraries that the eventual user has, determining his desktop theme, And
  • The ‘styles’ subdirectory may contain plugins, which the end-user does not have installed, but were usually compiled by upstream developers, to make use of one specific platform-engine each.

Thus, what I had in these directories, for better or worse, was as shown:

 

dirk@Phosphene:~/Programs/build-Dirk_Roots_GUI_1-Desktop-Release/plugins/platformthemes$ ls
KDEPlasmaPlatformTheme.so  libqgtk2.so  libqgtk3.so
dirk@Phosphene:~/Programs/build-Dirk_Roots_GUI_1-Desktop-Release/plugins/platformthemes$ 


dirk@Phosphene:~/Programs/build-Dirk_Roots_GUI_1-Desktop-Release/plugins/styles$ ls
breeze.so  libqgtk2style.so
dirk@Phosphene:~/Programs/build-Dirk_Roots_GUI_1-Desktop-Release/plugins/styles$ 

 

The reader may already get, that this was a somewhat amateurish way, to satisfy themes on the end-user’s machine. But in reality, what this set of contents, of the AppImage, does rather well is, to make sure that the 3 main theme engines on an end-user’s computer are recognized:

  1. Gtk2,
  2. Gtk3,
  3. Plasma 5.

And, if the application tries to make no attempts to set its own theme or style, it will most probably run with the same theme, that the end-user has selected for his desktop. But, what the point of this posting really is, is to give a hint to the reader, as to how his AppImage could set its own theme eventually. And so, according to what I just cited above, my application could choose to select “Breeze” as the Style with which to display itself, or “Gtk2″. But, here is where the official way gets undermined, at least as the state of the art was, with v5.7.1 of Qt:

  • ‘Breeze’ can only be set (by the application), if the end-user’s machine is running Plasma 5 (:1), And
  • ‘Gtk2′ can only be set (by the application), if the end-user’s machine supports Gtk2 themes, which many Plasma 5 computers have the additional packages installed, to do.

What this means is that, even though I could try to create a predictable experience for the end-user, what the end-user will see can still vary, depending on what, exactly, his platform is. And beyond that, even though I could set the ‘Gtk2′ Style with better reliability in the outcome, I could also just think, that the classical, ‘Gtk2′ style is a boring style, not worthy of my application. Yet, in this situation, I can only select the “Breeze” theme from within my application successfully, if the end-user is based on Plasma 5. If the end-user is not, then my application’s attempt to set “Breeze” will actually cause Qt v5.7.1 to choose the “Fusion” theme, that Qt5 always supports, that might look okay, but that is not “Breeze”…

 

So, what other options does the application developer have?

(Updated 9/12/2020, 18h15… )

Continue reading Bundling AppImages with Themes.

How the Internet still possesses Gopher-Holes.

One of the subjects which I have written a Blog-page about, concerns How antiquated ideas in Web-design, may still affect how well readers can appreciate the Web. What that page outlined, was the fact that Web-links – aka hyperlinks – can have an arbitrary appearance in a browser-window, which some readers might not recognize. And I suggested that this would mainly be due to the application of Cascading Style Sheets – aka Styles. Well even though that page did not go into this question further, I’m aware that other means have existed, by which Web-authors can change the colors of hyperlinks. Many moons ago, this would have been done with simpler HTML Tags, the use of which has become deprecated, in favor of using Styles. But I felt that I should point out another way, in which the appearance of hyperlinks is decided, which many readers have run in to before, but of which some readers may not have been conscious. And this would be, in the form of ‘Gopher Holes’ .

Gopher Holes existed in the early Web, as an alternative to hyperlinks specified within HTML Files, and they still exist today. But to understand where and when Gopher Holes will exist today, the reader will need to put himself or herself into the perspective of a Web-author.

(Edit 8/27/2020, 14h00:

This entire article expounds on a factual error, which I came to believe for various reasons… )

One of the historic, basic ways in which Web-sites were once organized, was into folders that exist on the server, which have sub-folders, but which also contain files. The way modern, sophisticated Web-servers are configured, any such folder will have one out of a list of file-names, that act as the default page-name for the folder, and which may be such file-names as ‘index.html’ or ‘index.php’ …  When the server receives a request to deliver a folder from the browser, defined by a Folder-URL, for which there is an actual folder on the server, what the server will do first, is to look in that folder, for a file which has been defined with one of the default file-names. If that file is present, then the server will return whatever that file tells it to do – in cases where the file-name actually specifies A CGI Script – And such a file then also acts as a non-default index for the folder. But if none of the defined file-names actually occur in the folder, then what this system falls back to, is serving up the folder as a Gopher Hole, which can also be thought of as a more basic index of any folder. And the way such an index appears in the browser, is then defined entirely by the browser:

gopherhole_1

The default appearance is, a list of sub-folders, followed by a list of file-names, all presented as hyperlinks.

The way in which this seems to fly in the face of what I wrote before, is in the fact that nobody got the chance to specify a CSS-File, for which reason the appearance of these URLs cannot be determined on the side of the server.

(Edit 12/23/2018, 13h50 :

Therefore, examples still exist on the Web today, which may lead readers to think, that hyperlinks will always have a uniform, old-fashioned appearance, without the readers realizing that they are looking at a Gopher Hole. And in this one case, the appearance is, blue underlined text for unvisited links, purple underlined text for previously-visited links, and red underlined text, for currently-activated links. The familiarity of the style in which these links are displayed by the browser can mislead readers. )

But then, such an example also serves as a hint to Web-authors, as to how they can prevent any one of their folders from becoming a Gopher Hole, which is to make sure that each and every folder on their server, actually does possess a file by the name of one of the default file-names, to act as a managed, explicit index.

The only valid reason why some folders may still appear as Gopher Holes, is the possibility that the Web-author may want readers to be able to download files, but where there was never a need for the appearance of the page to be controlled, by the author.


 

 

(Update 8/27/2020, 14h00: )

What I have learned about this subject is the fact that, in the early days of the Internet, actual Gopher Holes were something different, from what this posting, and what some of my other postings, keep referring to as such an example.

Actual Gopher Holes were served on Port 70, while non-encrypted Web servers listen on port 80, and encrypted, httpS:// URLs are served via port 443.

What some Web-servers do, including mine, is to generate HTML automatically, that gives the simplistic appearance, just as real Gopher Holes were once simplistic in their behaviour. But the fact is also that none of my servers are actually listening on Port 70! So what I have is a kind of backwards-emulation, of a directory listing, in the form of HTML, that the Apache Server generates automatically.

 

Dirk

 

Revisiting HTML, this time, With CSS.

When I first taught myself HTML, it was in the 1990s, and not only has the technology advanced, but the philosophy behind Web-design has also changed. The original philosophy was, that the Web-page should only contain the information, and that each Web-browser should define in what style that information should be displayed. But of course, when Cascading Style-Sheets were invented – which in today’s laconic vocabulary are just referred to as “Styles” – they represented a full reversal of that philosophy, since by nature, they control the very appearance of the page, from the server.

My own knowledge of HTML has been somewhat limited. I’ve bought cuspy books about ‘CSS’ as well as about ‘JQuery’, but have never made the effort to read each book from beginning to end. I mainly focused on what some key concepts are, in HTML5 and CSS.

Well recently I’ve become interested in HTML5 and CSS again, and have found, that to buy the Basic license of a WYSIWYG-editor named “BlueGriffon“, proved informative. I do have access to some open-source HTML editors, but find that even if they come as a WYSIWIG-editor, they mainly tend to produce static pages, very similar to what Web-masters were already creating in the 1990s. In the open-source domain, maybe a better example would be “SeaMonkey“. Beyond that, ‘KompoZer‘ can no longer be made to run on up-to-date 64-bit systems, and while “BlueFish”, a pronouncedly KDE-centric solution available from the package-manager, does offer advanced capabilities, it only does so in the form of an IDE.

(Updated 03/09/2018, 17h10 : )

Continue reading Revisiting HTML, this time, With CSS.