Linux 'Native' Library

[richmond62]

The thinking people who use Macs (i.e. NOT Paris Hilton and the 'in' crowd) will, eventually realise that they are paying more and more for less and less, and the majority will gravitate towards Linux because a lot of the reason they used Macs to start with was because they didn't like Windows.

AND unless Haiku and few others can finally . . .

The release of the relatively cheap M4 Mac Mini may indeed be the result of Apple realisìng they are in danger of losing a large chunk of their erstwhile market.

[OpenXTalkPaul]

I wonder what 'market'-share MX-Linux holds of the desktop world:

I'm sure it doesn't even cast a shadow on the usage charts, however I kind of like that.
I mean - the entire usage for Linux is only about 6% at the moment (but it's a 2% increase over last year, so I'll take that as a win).

That's more of the market than Apple had most of its first 30 years of existence! If you include all others, Unix-Like OSes, BSDs or Haiku for example, that could be another 1 or 2%.

There's a video on YouTube, not sure how accurate the numbers are:
https://www.youtube.com/watch?v=cTKhqtll5cQ

[tperry2x]

I am using MX Linux currently, specifically because you are using that.

- although I think I'm getting different results to you. Possibly due to different hardware?

It's a Library Extension with a testing stack in it's 'samples' sub-folder (where demo stacks go), it's on mega collab in the 'other' folder. So if you sync that, it should be there. It probably will likely only work if you have installed GTK2. I have 2.4.something that I installed from Synaptic, along with GTK 3 and 4 (plus GStreamer, WebKitGTK, and a bunch of other packages). I don't think the '-dev' packages are really needed for our purposes, most of that sort of .h header stuff can be looked at on the web anyway.

gtk2.png (56.85 KiB) Viewed 8017 times

I do have all the GTK2 stuff installed anyway, as you can see - so gave this a spin.

The mini browser stuff works brilliantly while it's active, but when I close the browsers - the CPU use climbs and then goes to 100% - at which point I have to force quit the IDE.

cpu-zombie-proc.png (91.91 KiB) Viewed 8017 times

I could embed the compiled extension module (.lcm) into a demo stack and load it from there, so that it could work without installing the module, but that would still needs GTK2 installed to do its tricks (the Engine itself binds to GTK2 for some things anyway).

I tried to add the GTK button, and it seems to add fine via the extension manager, but doesn't have an icon on the tools (comes through blank). When I drag it in, I get the following error:

eh-foreign.png (86.99 KiB) Viewed 8017 times

Sorry - none of this is supposed to be a criticism, as I couldn't do half of that. I'm just merely echoing what I'm getting when testing.

[OpenXTalkPaul]

I'm not sure when you tried it, but these are experiments that I may have been actively (or interrupted from) modifying when you tried it. I was trying different versions (GTK3). I have split them out into separate xBuilder experiment files. Originally the experiment was done with GTK2-quartz on macOS! So I had to add separate bindings for the Linux x11 version of GTK2.

The binding string for that button for GTK2 Linux look something like
'binds to "'c:libGTK-x11-2.0.so>gtk_function_name_goes_here"
So libGTK-x11-2.0.so, that's the actual library name that needs to be installed for it to find the GTK2 lib (could be a sym-link).

The other stuff in that 'GTK Lib' experimnent binds to GDK (pre-existing-Window/Stack manipulation tests), which I'm not sure if all of that is affected by the 'No-Mixing-GTK2 with 3 & 4' rule.

I suppose .AppImage, Flatpak, Snap, WINE wrappers, etc. container 'build's are the way to try to ensure that the Engine as it currently is compiled will run as expected, because GTK2 and other old dependencies can be included with the distribution.

Probably differences in our hardware can affect how things work differently. For Linux I'm using my old-old laptop which is like a 4th Gen i5 with only the Intel iGPU (HD4000).

It seems to me that GNUStep + Window Maker (or AfterStep) is THE Linux Combo that works 100%, at least the Browser Widget seems to works fine like it does on Mac / Win with that combo. I guess this kind of makes sense since the Engine was originally designed for that sort of environment in the early 1990s. I think that is using OpenGL for compositor. My 'get Window Manager script' returns empty when running under Window Maker.

Now I've moved on to reading up on Qt a lot, which in some ways is similar to GTK and I think it links to some GNOME stuff too. Certainly Qt is quite a bit more robust. In fact it would take a massive amount of work to manually make wrappers for all of it. But It has its own QtWebView that can run JS, which is mainly what I'm after.

Buttons, menus, text containers, etc. aren't very interesting as we have enough ways to do UI widgets/'controls' already, but maybe some other things such as the PDF-viewer Qt widget would be good to tap into as well.

I like that Qt widgets can be compiled to WebASM and used in a browser. 'QML' GUI mark-up seems real nice too.

I'll be doing some Qt binding experiments as soon as I have some time.

[OpenXTalkPaul]

OK Sorry, that was the case I had mac-quartz version and another (failed) version for Linux GTK3 in there.
I organized the folders better now, and put the binding back to GTK2-x11 in the xBuilder source and it compiles again,

Fixed.png (315.35 KiB) Viewed 7869 times

The extension folder GTK Lib is a library extension with test stack, it creates an GTK/GDK Window, and tests passing a stack window (XID) to the library to manipulate it with GDK (for example putting the window into a ' full screen' mode).

I'm reading up on Qt now. I figure I'll give that QtWebView a try instead since I can't mix GTK2 with GTK3 in a single process and since GTK2 is too old for Webkit2GTK.

Another option might be to run an off-screen Webkit instance in a separate process and buffering pixels into a rectangle on our card. I'm pretty sure that is the way that it currently (doesn't quite) works, but it would get around the GTK2 + 3 mixing problem.

Back in the early - mid 90s I would use HyperTalk scripts to tag ASCII text with HTML tags for the brand spankin new web protocol. I had my web editor save to temp .html files and launch the page in the major browsers at the time, Netscape, IE, and AOL (lol) web browser. If you're building for running in web browsers you're going to want to test with a few major browsers anyway, Even with the Browser Widget, you can't see the page as rendered while the engine is in edit mode anyway, it only renders 'native layer' widgets while the engine is in 'run mode' (unlike the canvas drawing rendered widgets, which can render identically on all platforms). The point is that I only ever needed the 'launch' command to work with HTML, so I guess I'm OK with 'Browser' functionality being some sort of slave-mode mini-browser sub process. The MiniBrowser that comes with Webkit is meant for debugging webkit. Not sure why that might spike your CPU usage after closing? But doing a 'kill' on that processID should take care of it.

That reminds me that I think that is the problem with 'Player' controls on Linux (besides not having any UI controls overlaid onto it by the engine, like it does on mac and win), it seems that it does not terminate the playing process properly. I've actually seen it in some instances where you can list open processes and see those 'playing process, I think I was poling the open files or the open processes IDs. The 'play' file command on macOS I know that sort of does this, you can't "play stop'' (even if it's making horrible retching noises because it can't handle mp3s), you have to kill each playing process to stop it (and then recheck the open process IDs to make sure they've all been killed). Anyway, I can get the player control on Linux to play that little test .mpeg file in most cases, once, and only once. Then to play again you have to set the filename to the file/to/play again or the thing will not play again.

If nothing else having hooks to HTML web engine guarantees us a video playback mechanism.

[OpenXTalkPaul]

The biggest problem I'm having with trying to use Qt5 or Qt6 is that it's a huge ecosystem onto itself. Really it's like enough stuff to be the core of a OS, which makes sense for why KDE has a long-term deal with the Qt Group to ensure the GPL version of it continues.

The first thing that is a bit of an annoyance is that it's much like LC Community Edition in that you are (since around 2020) forced to make a User account with The Qt Group company before you can install the toolkit ( I'm aware there are waysto get around that, like compiling it from source, which takes a ton of time and disk space).

For macOS Qt6 is only officially available for Sonoma / Sequoia. On macOS it's rpobably better to stick with Cocoa UI or SwitftUI/UIKit anyway, but that obviously makes it a bit more difficult to develop cross-platform solutions.

Qt5 with all of it's extra bits, Dev files, Webssembly compiler, etc. is MASSIVE, depending on options we're talking 10s of gigabytes of disk space to install, it can be worse than having to have 3 XCode versions installed. As I didn't have engough space left on my mac SSD, I did not isntall it on mac.

In contrast, wxWidgets installed easily and is about 30mb (Sans other library dependencies), even GTK2 is easier to deal with on macOS than Qt is.

[OpenXTalkPaul]

wxWidgets is out of the running... It seems like a really solid toolkit that's been around as long as our engine has since the early 1990s, but the whole point of wxWidgets is that it uses 'Native' OS UI kits to create it's controls. On Linuxes that currently means it uses GTK3 (with wxGTK4 support being worked on), which again that conflicts with GTK2 that the engine is linked against.

So it's Qt by default... that or a 'Browser' that runs as a slave sub process.