Before the release is after the release. Of course, now that the first version of AmiFox is released I think about how to improve it for the next release. One wish I heard some time was to copy text from webpages. Which got me thinking, you can select texts with the click and drag feature I introduced, so it should be possible to copy these texts as well.
Also there are this neat javascript buttons which copy a text into the clipboard (like gitlab has for the URL of the repository) would be also nice to catch this contents. (btw. github had in the past such button, but now they replaced it and it also does not work in my regular webbrowser, so no wonder it also does not work in AmiFox)
And after some playing around I got a way to catch the selected text as well as the clipboard contents. This btw. is a bit strange you have to execute a javascript for the chrome browser to get it, strange but works.
On thing I found really annoying with AmitFox was the scrollbars, (in the picture) because even you know you want to the end of the page (or to start) you have to click multiple times for every page and wait to let the page load. It would be much easier just to click and drag directly to the position you want it. In principle it is not difficult just remember the down position and record the position where the mouse button was released and sent both position to server instead of just this one position.
Then on server emulate a down at the starting position a move to the destination and a mouse button release. Sounds easy and it is actually. But of course the WRP is written in go and I’m not fluent in that language, therefore it took a while to understand how this stuff works. Luckily the normal mouse click routine works exactly the same way, just without the move in between, so there is a good example.
Finally it works. And good news it works awesomely one scrollbars also in Openstreetmap (even I would still prefer to use MUIMapparium 😀 ). Strangely it does not work in Google maps or Google Streetview, really weird especially because it is Chrome in WRP. Maybe I have to emulate touch movement for that needs more testing.
I was looking more into the WRP code, to check if there is any way to make file downloads work, and yes, it is possible, not a very elegant way for now but it somehow works… now I really think If I should add that before we release the first version.
Again got some ideas from Michal Bergseth (Amix , Amitopia) what to implement for Amiga. Basically it is the same idea as for AmiTube. Do something, the Amiga is too slow for, on the server and only sent the result to Amiga. This time it’s webpages… the usual webrowsers are either rather old and do not support CSS (like AWeb, Voyager), newer but still do not support CSS (iBrowse) or newer support CSS but are very slow (Netsurf).
I started with „CutyCapt“ to make a simple docker container which can load a webpage and make a screenshot. But with that you only get a screen shot nothing more. No idea how to navigate. My second try was to also load the actual HTML and parse for links. This is rather easy using the THTMLDocument class for Free Pascal but this gives you just the links and nothing more, so I put just a list under the image. This was not really a good solution.
Then I noticed when you let CutyCapt print the webpage as PDF, then the PDF contains all the links with position information. Therefore I wrote a PDF parser to get the links and position from the PDF and create a map for the image. Which worked reasonable good, but not very fast (printing is rather slow, also the transfer from PDF to PNGs is slow). But it was good enough for a first test version:
This was the first time it came a bit to public and wide audience attention. So I got some more hints that such systems already exists, some very good and some rather poor, I tried a lot of them and none really satisfied my needs. Some like wkhtml are very fast and do not need an X-Server in the docker, which is nice, but has a lot of problems with some webpages (cnn.com, image are VERY low resolution, theguardian.com all images are missing and so on).
The best I found is definitely WRP – Web Rendering Proxy which is very fast already has a lot of settings build in, it is already nicely usable in your IBrowse if you like. But there is a big BUT it is single user only, so not suitable for a public service like AmiTube is, and which is the ultimate goal.
So an other Member of the AmiTube Discord Channel (going by the name McDope) will try to create a server with this WRP which can be used by some more users. I meanwhile make a little app, which feels like a real Webbrowser but is in fact just an interface to the WRP. It solves also the problem that you cannot type in anything into any forms like search engines or so. Kinda. A little video to demonstrate.
A long time before when I was working on the LCL for AROS I tested out some 3rd Party LCL application code to compile for AROS with the newly created LCL. It worked quite nicely. On of them was LazSokoban a Sokoban clone written by a russian guy which worked nicely on AROS.
Some Texts in the GUI where in russian and I translated them to english for the AROS release, some I had forgotten or mistyped a bit. Now I got a request to fix that problem, first there was the big problem to find such and old source code, but luckily it’s included in the archive I published (it’s GPL2, so I had to 😉 ) but I also found in on my Harddisk in the backup.
The changes where not to difficult to make, but the curious thing was if it would still work with the latest LCL. One thing I remember that I need to add the AThreads unit (like Linux CThreads) to make any LCL application work, back in the days that was not needed. And it still works, I checked out the original source and I noticed that they added some kind of skin system (different graphics for the tiles) and also supplied some which looks much nicer than the original one. So I added that as well the the AROS system, it will be available on the next Version of AROS One or here on my page of course.
The other thing that changed since then, we can now compile for MorphOS and OS4 as well (and for Amiga68k, but it will be much to slow for that, I tried) and it also seems to work, not everything, the Buttons images are missing but as far as the game goes not too bad. So I created a Version for all 3 Platforms, AROS, MorphOS and AmigaOS4
A little bit stuff is happened in the last week, I want to report a bit about it.
The first very nice development is a bugfix in the 68k Free Pascal compiler, there was a long standing bug inside the PNG-loader. I noticed it with MUIMapparium, but it only showed on some computers, namely my Draco. Charlie tried to look into the issue long time ago, but not really found anything to fix.
But now he looked again into the issue and finally was able to track down the problem. The problem is not really fixed but there is a workaround included so now MUIMapparium works on my Draco, very nice.
MUIMapparium on Draco
MorphOS added an OpenSSL3 Amiga style library a while before, as soon that was available I started to try it to get it to work with Free Pascal on MorphOS. Sadly it did not work, always was crashing already when I tried to use even the simplest function, so I was lost. Charlie mentioned that there must be a change in our linker script of some sort to make it work and he will later care about it. But as often too much other stuff happened and this got delayed. Finally I started to implement the stuff via AmiSSL also on MorphOS. I implemented that for Amiga68k already so the switch to MorphOS is just not a big thing. But then Charlie said I should better use the openssl3.library instead and he will fix the problem with the linker script. And he did and it seemed there was even an easier solution for that and finally openssl3.library does work together with Free Pascal for MorphOS.
Get a webpage via HTTPS using the openssl3.library on MorphOS
Charlie tried MCAmiga on his „new“ build Amiga2000. It only has a 68030 with 25 MHz and he noticed that the load is rather high (around 30%) when the program is doing nothing just waiting for the key. That is the case because it is based on old DOS behavior, therefore the key events and so on must be polled and not fired via events as it is common today. But he showed me a special function in the keyboard unit called WaitForSystemEvent() which is only available for Amiga system to be able to really wait for events and not poll them. That reduces the load when the program waits for input (to under 10%) which is nice of course.
„Alex R“ found a AmiTube problem on Amiga OS4 and reported it to me. (some days before already) I tried to implement that AmiTube remembers the splitter position. Sadly I made a big error there resulting in a very small barely recognizable List on the left side of the window. I only tested it on m68k-Amiga where it did not happen, but after a bit of trying I found the culprit and fixed it.
Originally I planed to release that fix with the next version, but now I got some more bug reports about the exact same thing (hmm, nobody of the beta testers reported it). It seems that it is not only an OS4-problem but also happens on at least MorphOS and some 68 Amigas. Therefore I will release this new version now, with bugfixes only, no functional changes.
Sorry for the trouble, if you are affected by this bug.
Thanks to „Alex R“ for the report and the members of the AmiTube Discord channel and of course Amix for the constant support and feature ideas (even if I can’t implement them all)
Another wish for AmiTube was to have multiple movie directories for easier sorting of movies. I implemented a possibility to do that, now you can add MOVIEDIR1, MOVIEDIR2 and so on to the icon to have multiple movie directories. In the Project menu one can choose which movie directory should be used for next download or loading of local files.
