experiments with browser widget (Linux)

[tperry2x]

experiments with browser widget (Linux)

browser-test.oxtstack

(6.91 KiB) Downloaded 305 times

This might be a 'scatter-gun' approach, but using:

Code: Select all

zgrep 'install ' /var/log/dpkg.log* | sort | cut -f1,2,4 -d' ' > ~/Desktop/Package.list

I can dump a file to my desktop, with all the latest packages / libs I've installed by date order.

browser-linux.png (273.83 KiB) Viewed 6813 times

I eventually got the browser working (see above). I doubt it needs all of these, so my next step is to test in a linux vm and see what I can whittle the installed list shown on the screenshot down to.

[richmond62]

Getting the browser working in Linux is a well braw achievement.

[tperry2x]

Transferring to a generic linux vm that it doesn't work on, first problem becomes evident:
Can't open the "browser-test.oxtstack" as it locks up oxt lite.

So, resaved a version without the browser widget - which just does the dependency checks.

browser-deps-test.oxtstack

(6.64 KiB) Downloaded 154 times

From here, I'll now go through identifying which of these dependencies makes the browser widget work.
The unticked things are the dependencies that didn't come included, so it's likely to be one of / combination of one of these:

comparison.png (72.96 KiB) Viewed 6799 times

Top pic is basics of what a new minimal distro comes with, underneath - what I'd installed on another computer to get it working.... so time will tell in due course.

[tperry2x]

additional.png (6.11 KiB) Viewed 6793 times

After installing these, I get the browser widget to show up (it renders the globe widget with the name 'browser' in). However, it's non-functional.
Probably because the following libraries are no longer available:

Code: Select all

The following package(s) are missing, or have been obsoleted:
E: Unable to locate package python-all
E: Unable to locate package libpython2.7
E: Couldn't find any package by glob 'libpython2.7'
E: Couldn't find any package by regex 'libpython2.7'
E: Unable to locate package libpython2.7-dbg
E: Couldn't find any package by glob 'libpython2.7-dbg'
E: Couldn't find any package by regex 'libpython2.7-dbg'
E: Unable to locate package libpython2.7-dev
E: Couldn't find any package by glob 'libpython2.7-dev'
E: Couldn't find any package by regex 'libpython2.7-dev'
E: Unable to locate package libpython2-dev
E: Unable to locate package libpython-all-dev
E: Unable to locate package libpython2-dbg
E: Unable to locate package libpython-all-dbg
E: Unable to locate package python2.7-dbg
E: Couldn't find any package by glob 'python2.7-dbg'
E: Couldn't find any package by regex 'python2.7-dbg'
E: Unable to locate package python2.7-dev
E: Couldn't find any package by glob 'python2.7-dev'
E: Couldn't find any package by regex 'python2.7-dev'
E: Unable to locate package python2-dbg
E: Unable to locate package python2-dev
E: Unable to locate package python-all-dbg
E: Package 'python-all-dev' has no installation candidate
E: Unable to locate package libpython3.10-dev
E: Couldn't find any package by glob 'libpython3.10-dev'
E: Couldn't find any package by regex 'libpython3.10-dev'
E: Unable to locate package python3.10-dev
E: Couldn't find any package by glob 'python3.10-dev'
E: Couldn't find any package by regex 'python3.10-dev'
E: Unable to locate package libllvm11
E: Unable to locate package libclang-common-11-dev
E: Unable to locate package libclang-cpp11
E: Package 'clang-11' has no installation candidate
E: Unable to locate package libclang1-11
E: Unable to locate package llvm-11-linker-tools
E: Unable to locate package llvm-11
E: Unable to locate package llvm-11-runtime
E: Unable to locate package llvm-11-tools
E: Unable to locate package llvm-11-dev
E: Package 'libjpeg8-dev' has no installation candidate
E: Package 'libjpeg-turbo8-dev' has no installation candidate
E: Unable to locate package libtiffxx5
E: Unable to locate package lib2geom1.1.0
E: Couldn't find any package by glob 'lib2geom1.1.0'
E: Couldn't find any package by regex 'lib2geom1.1.0'
E: Unable to locate package libnetpbm10
E: Package 'libturbojpeg' has no installation candidate
E: Unable to locate package libmng2

This kind of stops anyone easily being able to install them, as not everyone is going to mess around with Synaptic, backporting libraries from older sources and adding runtimes with no verification signature.

Where does that leave me? Well - I have a plan-c. More on this another time. Reality is calling.

[tperry2x]

Got a bit further this morning:
https://www.tsites.co.uk/otherstuff/bro ... st-new.mp4

Still getting weird graphical glitches with the 'group' button, and the remnants of the green selector handles are for some reason left at the top when the browser activates. You can see that my terminal also produces a few graphics warning / crash errors. So, I have this to sort out.

This is a new widget though that I'm working on, to completely replace the Linux browser widget.
It doesn't use the [Chrome / CEF] engine, it uses the midori browser instead.

This does not affect the Win and Mac version - it's only a change that will appear in the Linux version of OXT Lite.

The control appears like a standard button, so *shouldn't* cause any problems when saved into a stack, then opened on Mac and Win... more testing to follow.

[richmond62]

I am more than happy to give that a go on my Xubuntu laptop: but, by what you say, it isn't quite at that stage yet.

[tperry2x]

Yes, not quite. I don't want to inflict this on anyone just yet...
I wasn't decided on what web-engine to use.

As we know, the CEF engine external is comparatively huge.
(221MB)

cef.png (7 KiB) Viewed 6747 times

(Plus, I seem to have an aversion to any browser that's Google-Chrome-based).

In my first alternative browser test (above), I tried using midori - built from source. This is smaller and comes in at 80MB, which is okay.... but, not as small as I wanted.

I've just been experimenting with NeoSurf (a fork of netsurf, focussed on security and privacy). Netsurf (and NeoSurf) use the lightweight Hubbub rendering engine, rather than webkit - which is why it's so small. (more on this further down).

After compiling this, and creating an appimage of it, I can get it down to 2.7MB (which is a respectable size in my opinion).

Here, I've adjusted my 'widget' - if you can call it that. It's not a full-on widget, as LCB syntax still evades me.
But, you can see it loading a simple "503 service unavailable" page - which is just an html with CSS that I had knocking around. It works as a test though.

Demo video:
https://www.tsites.co.uk/otherstuff/min ... engine.mp4

I have a couple of hurdles to overcome:

1. How do I create a widget so that this control (which is essentially a preset, styled button as far as the stack format is concerned), is created when someone drags it off the tools palette? (I had a random idea about this here)

2. How do I get this appimage to be bundled in a linux standalone at point of compiling a standalone within OXT Lite?
(I have a nasty feeling I have to change the standalone-builder scripts).

I've tested this on 2 alternative linux distros, and a blank VM and seems to work well. Does not need any other dependencies. I've saved 218MB off the size of OXT Lite and essentially restored browser functionality for Linux, so that's pretty cool in my opinion. I think I'm getting there slowly.

[tperry2x]

Further experimentation on what it takes to get the browser working. We are up to a ridiculous amount of possible dependencies. Some I've eliminated as not being relevant, but quite frankly - this is getting a bit silly now:
(links to browser tests)
Of course, I'm hoping to reduce this list of possible suspects down - so we know what the bare-minimum is to get this working.
(hence why my logic in using the neosurf alternative to CEF, above)

browser test 2.png (129.46 KiB) Viewed 6670 times

[richmond62]

I cannot help wondering if the 'weight' of the dependencies (plus the sheer bother of having to install them all) doesn't work out almost as 'expensively' as the thing you are removing?

[tperry2x]

I cannot help wondering if the 'weight' of the dependencies (plus the sheer bother of having to install them all) doesn't work out almost as 'expensively' as the thing you are removing?

Yes, it really does. CEF takes over 220MB in itself, then these dependencies take 415MB too - that's just to support the bundled CEF browser in Linux which is included in LCC (and subsequently OXT). The 'nail in the coffin' as far as CEF support in Linux is concerned, is that if I make a standalone linux program on this machine (with a working browser widget), when I open that standalone on another linux machine without those dependencies, it won't actually render that browser window (just silently fails). Implying that the libraries aren't gathered up and included in the standalone.

So that's a pain, because it means in practical terms, if someone wants to create a standalone with a browser widget instance - then whoever runs that standalone is expected to install all that other stuff too. Which is very far from ideal.

With the netsurf version above, it's 2.7MB and it's an appimage, so you don't need any dependencies - so this is by far my preferred way of doing it. It's getting closer to providing something 'that just works' (to coin a phrase). I've just got to work out how to package this up at the point of making a standalone, and we are back to a working solution as far as I can tell.

I will have to include the original license documentation for netsurf in the Help menu > About dialog > License info, but that's not the end of the world.

I've also placed a non-cef version in the downloads folder. You can see how much of a smaller download it is. Of course, it's sans any browser-related widgets or shenanigans as a result, but as these are going to be non-functional for most people anyway, I don't see the harm in removing them. (Other people may disagree, so that's why there's a traditional one with CEF still there).

[richmond62]

That is an excellent explanation, and I hope it makes as much sense to other prople reading it as it does to me.

My main worry was that you were investing a lot of time and effort in something that might have been unnecessary: and now it is crystal clear that what do are doing is highly desirable.

BUT . . . the other Q I have is how that is going to work if one wishes to build standalones with the web-browser capacity for Windows or Macintosh on a Linux box.

[tperry2x]

BUT . . . the other Q I have is how that is going to work if one wishes to build standalones with the web-browser capacity for Windows or Macintosh on a Linux box.

That is a good question. My thinking on those would be that the Win and Mac versions stay as they are, with CEF in Windows as that's working. The Mac versions use the built-in webkit api (included in the OS anyway), so there's nothing need to be done there.

If someone opens a stack that features a browser widget, in the non-CEF version of OXT Lite in Linux for example, OXT lite doesn't crash - it just does not attempt to render the browser widget (there's a blank space where the widget once was).

This is an improvement over including a non-functional-CEF in linux, as otherwise it would just lock up the stack and the IDE, which then had to be force quit with a task manager (not a good impression).

Working the other way around, if someone creates a 'new-browser' object with my netsurf-based widget as a stack on linux, saves that and opens it on MacOS or Windows, it just renders like a button with the web-browser globe (as shown in the above video). It doesn't do anything when clicked on, apart from put up a dialog saying "This browser object does not function in MacOS or Windows. It is only for the Linux version. Please replace this with a standard 'Browser' widget now".

Or better still, upon opening a stack with a 'new browser'-netsurf-widget, it gets automatically converted to a standard browser widget and replaced automatically on win and Mac os.

[tperry2x]

Or better still, upon opening a stack with a 'new browser'-netsurf-widget, it gets automatically converted to a standard browser widget and replaced automatically on win and Mac os.

Quoting myself here, but after looking into that - not sure how easy that would be.
Perhaps I'd have something built in to at least warn the user of any conversion... not sure yet.

Progress continues. Quite a few number of changes to the neosurf OXT Lite implementation behind the scenes.
You'll see it's grown from 2.6MB to 6MB unfortunately. This is to make it compatible with GTK+ and Wayland.

browser-progress.gif (783.47 KiB) Viewed 6560 times

[tperry2x]

Just out of morbid curiosity more than anything, I thought I'd compile a list of all the dependencies LCC uses (and therefore OXT Lite uses) on linux during normal use.
This is the result of a standard memory stack trace:

Code: Select all

lsof -P -T -p 19421 > ~/Desktop/deps-dump.txt

(where 19421 is the process ID of your currently running LCC/OXT Lite program on linux)

I then put a stack together so you can check for dependencies....

Hang on a minute, I bet you are thinking, If I'm running LCC/OXT then surely I already have all the dependencies I need?
Well - kind of. OXT and LCC will run without some of these but will silently generate errors if the libraries aren't available.

If nothing else, it might be useful if we want OXT to run on more exotic OS choices in future.

screenshot.gif (18.67 KiB) Viewed 6291 times

[tperry2x]

Ah, but what of the browser on Linux you may ask.
Well - it's a bit of a case of one step forward, 2 steps back.

I can get the browser to load and integrate it (simplistically) into a stack, however whereas the window transition was seamless for some linux distros, it didn't work for all of them and popped open into a new window.
So this is the step back, while I essentially ponder how to embed a program in something like an iframe (to use web terminology) in a stack.

Note: you will need to be running Linux as an OS (but I'm sure you guessed that), and have OXT Lite 1.04 (or greater) to try this stack attached.

[OpenXTalkPaul]

Ah, but what of the browser on Linux you may ask.
Well - it's a bit of a case of one step forward, 2 steps back.

I can get the browser to load and integrate it (simplistically) into a stack, however whereas the window transition was seamless for some linux distros, it didn't work for all of them and popped open into a new window.
So this is the step back, while I essentially ponder how to embed a program in something like an iframe (to use web terminology) in a stack.

Note: you will need to be running Linux as an OS (but I'm sure you guessed that), and have OXT Lite 1.04 (or greater) to try this stack attached.

So this widget uses a command line to open shell command to create a browser engine window (and can possibly attach that window to a stack window on compatible distros)? It does seem like these problems come when with attaching external process windows to the stack window, but only on certain distros. On Pantheon / Elementary OS the OXT browser widget-widget actually shows two window frames.

[tperry2x]

Yes, I wasnt happy with the result. I was using xdotool to hide the browser's window title and set the frame to 0, while also anchoring it to the absolute screen rect of the browser widget passed from OXT.
However doesn't seem to work on all distros, and doesn't support totally frameless wds on 'buntu distros, so I'd disabled the wd merge part. At the moment this just provides a streamlined minimal way of popping a non-blocking browser shell with a url from the stack, but I hope it can eventually do a lot more. Either way, it's still an improvement on the original behaviours of locking up the IDE. It's not how I want it to be though. Currently there's a bug with the neo browser, where it can't hide the url bar, but this is coming in the next version - so I'll update the 6mb appimage when that's available.