#Qupzilla footprint software#
#Qupzilla footprint code#

A more RISC OS QupZilla, albeit via a separate app. However, with a clearer understanding of PackMan’s mechanisms for installing packages, it all works quite well. That said, that may have been more of a misunderstanding of the instructions on my part. The only problem, early on, was that it seemed that some aspects of the SharedLibs were available from PackMan and some from a site linked on the ROOL forum, which felt incredibly messy.īetter use of PackMan tidies this up considerably, but initially it was complicated. With all this in place, the app worked nicely. All automatically, but with an option to force a specific swap-state.

#Qupzilla footprint software#

Rob used some platform-detection software to allow ZillaRAM to detect the board that it is running on, and sets the colour swap accordingly. There was also the issue of colour swapping – on some machines, red and blue are swapped to be in line with “industry standards” rather than “RISC OS standards” and in vanilla QupZilla, this requires a change to the !Run file.

So combining these things should create a usable, automated app – but I still wanted an iconbar icon! I had used AddTinyDir to create one for my application sandwich, but obviously it was on the wrong side of the iconbar.

#Qupzilla footprint code#

Rob said he thought he could code to check for a RAMDisc and, if not present, set one up or resize it if necessary from an app. QupZilla and Otter-Browser will ONLY work in 16m colour modes. But often the window failed to materialise (what I didn’t realise at the time was that this was due to not being in a 16m colour mode.

I’d used !Liquidise from Liquid Silicon to create a banner before running the necessary files so I knew that something was happening. However, the pause while it loaded often looked like the computer had crashed because it was a good few seconds of nothing happening.

Killing QupZilla on closing, thank’s to Steve Fryatt’s TaskKillĪnd, to my mind (though not “scientifically” proven), there was a worthwhile difference in loading speed.

Run !QupZilla, using the support files in the RAMDisc.

Using my application sandwich, if a RAMDisc was previously set up (even from Configure on Boot), I had just about managed to: What I had struggled to do with my complicated version was do some of the automation: My colleague, Rob, suggested that one streamlining possibility was to leave !Qupzilla outside of our !ZillaRAM app – as long as it had been seen by the filer, it would load fairly quickly anyway. This was then copied to a RAMDisc on the machine (the amount of memory available these days means RAMDiscs are easy to utilise) along with the supporting files that are needed.Īfter a bit of experimentation, I realised that the browser itself didn’t need to be run from the RAM Disc to achieve a noticeable speed increase, as long as the Unix support files were located there. One of the things I’d done was to embed !Qupzilla deep in my application sandwich. In discussions online with another RISC OS user who had infinitely better coding skills than me, we thought that he could make some streamlined changes to the multi-layered way I’d originally achieved what I’d wanted for myself – but also a useful RISC OS browser for configuring Wispy V. And it might have been a good start for someone to take a hold of it, modify it and make it so much better! This “application sandwich” was primarily due to a distinct lack of coding skills. It wasn’t neat, tidy, or clever, but it was functional. QupZilla, as ported to RISC OS by Chris Gransden, is a nice browser for RISC OS, but it lacks a few of the basics that RISC OS users have come to expect: an iconbar icon some indicator of it doing something during the long pause when loading and a little bit more speed! Even as is, it still feels faster than Otter.īeing frustrated by many of these shortfalls, it wasn’t impossible, even for me, to cludge something together that manages all this.