I was browsing around in the old sources of WRP, how it was in older Releases, and I found an interesting point, in the beginning they tried the same as me. To gather all the links on the page with their position and sent it back as map to the client. So they gave me a handy example source how to achieve that with the headless chrome. so I build a routine which takes coordinates and sends back the URL if the coordinates are on a link. And I put that into AmiFox. But for that of course I need a Version detection because older versions or the official WRP can’t do that.
Now this works rather nicely, still thinking if I should do that always and out in the original answer html, but then it will be huge for most webpages. Atm I like this more dynamic way more, I also cache them in AmiFox so if it knows already once the position it will not ask again for these positions.
To use that besides the little text in the status bar I added a Context menu with „Download Link“ and that it no looks that empty also a „save image“ function, which just copies the temp image to an other location. Little demonstration, as usual.
Some days before I made a Video how AmiFox and AmiTube/MUIMapparium will work together in the next AmiFox version. But that would not work for AROS, simply because the AROS MUI, named Zune does not support an AREXX Port as MUI does. But when I thought about, it should be not too hard to create an AREXX port yourself, in principle what you need to do:
Create an Message port (CreateMsgPort)
Name that Message port for example „AmiTube.1“, MUI/Zune already supplies such a name in the Base property of the application class (ln_Name)
Register that named Message port to the system (AddPort)
Read Messages from the port (GetMsg)
check if that message is a commando (RXCOMM)
Handle that Message (RexxMsg)
Reply the message to the sender (ReplyMsg)
Thats all, (of course in destroy you need to remove the msgport from the system and destroy it). But overall very simple. I tried it for i386 AROS and it works very nicely I can send AREXX messages from AmiFox to AmiTube as in Amiga. Now I really think why they did not implement that in Zune, if it’s that simple, maybe I forget something.
I got a new AmiSSL Library for AROS i386 ABIv0 and this time it works smoothly. The httpstest worked without a problem.
So I created a new Version of AmiFox for AROS with SSL enabled and it also worked. That went almost a bit too smoothly. noticed already that the images (logo and lock icon) looks wrong in AROS, it seems the TImage does not work properly, the lock is only shifted a bit, but the logo is completely destroyed. What to do about it, I want at least the lock look right, that the user can see if they are on a secure connection. So the easiest way it to bring in the images as iff and load them with Datatypes. The difficult part here is that you cannot load files from memory before Datatypes library V44. So I never do that for m68k Amiga, I always put a file to HD or RAM and load that one. But, here on AROS there must be a datatypes v44+, easy. And yes the datatypes library is v45 so it should work, spoiler, it does not, it does not even give a error message. The object is nil and the error code is 0, nice, a little bit grepping in the AROS code revealed, it seems it is still not implemented. Ok back to field one, I implement that save to T: as file and load that, not nice but it works, and for AROS it’s not too bad to put some stuff into Ram disk, it had enough RAM. But so finally it works, SSL with AmiFox on AROS ABIv0 makes a nice secure connection to the server, visible by the little lock in the lower right corner.
Don’t ask me… AmiFox is a nice workaround for Amiga, even it’s slow.. but for a highend computer as AROS (Intel/AMD CPUs)? Why would you ever use it? Especially when there is OWB which can show the webpages in real without the image server in between. And even OWB is not up to date it still shows most of the pages without problems.
But still I got „some“ (2 actually 😉 ) requests for AmiFox for AROS, maybe thats just… hey Amiga has a new Program, we also need it, if it is useful or not is not important. *sigh*
So I compiled it for AROS i386 and AROS 64bit ABIv11 but it has some strange effects… first of course AmiSSL is still missing so no SSL downloads, no SSL connection to Server. 2nd the images are quite disturbed, seems AROS has some problems with real Amiga bitplanes… I mean the lock looks somewhat right… just shiftet? But the logo? not even recognizable. 3rd The Scrollbar in AROS Zune seems really does not like to be hidden/shown in runtime.. it makes crazy stuff, so now it’s visible the whole time on AROS. Join Discord to get the beta.
I made a little instructional video about the Size and color settings in AmiFox. The size settings is exactly like that in AmiFox 0.2 already. The IFF-ILBM Setting is new for AmiTube 0.3 (join the discord to try a beta version of it) but some of the color settings already exist when you choose GIF, but of course IFF-ILBM will be much better because it is basically the native format for Amiga (images saved as bitplanes)
I worked a bit on AmiTube, I guess soon we can make a new release. For the next release I improved the handling of shorts and lists. Added a special window where one can paste a youtube URL into and it extracts the IDs from it.
A big problem with shorts is that they are saved in portrait mode means the height is much bigger than the width. until now I always only scaled by the width. I worked nicely for the small sizes, OCS and AGA but failed spectacular for AGA+. So now I read out the sizes from the move and scale differently when there is a portrait video. On that I notice that the agablaster has a curious restriction, the CDXL movie must be at least 128 pixels wide. is that a general restriction in CDXL or just for agablaster? I’m not sure.
Also the VCD-MPEG1 showed some strange effects because it tried to scale it, resulting in fat faces, no I added a padding.
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.
Finally after 4 alpha version and 6 beta versions we (McDope, Amix and me) think AmiFox, a new browser for classic Amiga, is ready for it’s first release. This is Version 0.2 so one can see it’s still in development and many things to improve but I guess many people want to try how it works. And we can test how the server behave under heavier load than in the beta tests.
There is a special page for AmiFox where you can download the program.
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.
