Yesterday I put up a page for PyStump, a web-based announcements display system. I started PyStump as a pet project a couple years ago, but only in recent months have I put in the work to make it an actual usable piece of software. I thought it might be time to highlight it a little. (more…)
As of tonight, WCGBrowser is available from the Arch User repository! Arch Linux users can install “wcgbrowser-git” using their favorite AUR front-end, or by downloading the PKGBUILD directly from the AUR.
It’s been a snowy week like Tennessee hasn’t seen in decades, so with a couple of extra down-days on my hands I decided to work on a project that’s been on my docket for some time: porting WCGBrowser to a new web-rendering engine.
WCGBrowser has been my most popular open-source project by far, and between blog posts I’ve seen and emails I’ve received, it seems to be powering kiosks and signage from New England to the Netherlands, Germany, and Australia. I’ve found it quite useful within my own organization, but it’s Achille’s heel for many years has been QtWebKit.
QtWebKit is, basically, dead, and starting to stink a little. Its performance is slow, it’s buggy with some websites, and it tends to leak memory like a seive. The Qt community has been working for the last couple year to integrate Chrome/Chromium’s Blink browser engine into Qt, and recently with the release of 5.4 this new “QtWebEngine” library is now available for me to play with on Arch Linux.
So I’ve begun porting the browser to QtWebEngine. It became immediately obvious that this was going to break a lot of things in WCGBrowser, and I’ve been wanting to change the name for a while, so I decided to fork WCGBrowser and start a new project.
I give you ADMBrowser.
Yeah, I went full ego on the name. Mostly I just want to avoid a name collision with a commercial browser, since there is a new one being bankrolled by VC every five minutes.
So far ADMBrowser is a quick-n-dirty port of WCGBrowser to QtWebEngine, basically discarding any features that couldn’t be easily ported with a search-and-replace. Sadly, that’s a lot of important features so far:
- Plugin support
- External File (PDF, etc) support
- Privacy mode
- Proxy support
- Certificate handling
That’s just the quick core-features test findings. I haven’t tried all the more obscure features yet. Needless to say, don’t swap your production rig to ADMBrowser just yet.
Apart from the WebEngine move, I plan to clean up some of the redundant configuration options and maybe organize things a little better. I’ll also be dropping support for Python 2 (or at least not going far out of my way to support it).
Hopefully QtWebEngine will mature quickly, or workarounds will come to light. I can tell already that many rendering and performance bugs from the old WCGBrowser are tidied by by the new renderer.
If you’re Python & Qt coder who might be able to help me fix some of these things, please feel free to fork and submit pull requests.
Since uploading Omega Hymnal to Github ten days ago, I’ve made numerous improvements. It almost seems like it’s time to slap a version number on it and call it a release. Here’s a rundown of the features and fixes:
- The utility links (import/export/settings/etc) are all grouped under a “Tools” submenu
- I removed the default DB file from the source, so if you happen to use the default settings I won’t clobber your database when you “git pull”.
- Omega Hymnal can initialize a clean database if you don’t have one, or you can reinit your database if you want to start clean.
- I fixed a lot of nuttiness in the auto-text-sizer on the song screen. It’s more consistent now.
- I added the capability to manually insert pagebreaks in the lyrics using the [pagebreak] tag. This is an alternative to manually shuffling things between text boxes.
Not sure where to go next, hopefully I can convince some others to start using this and get some good ideas. I’d love to figure out a way that I can make lyrics + chord entry a lot easier and less geeky (the world apparently doesn’t share my love of markup languages), though my ideas so far either go beyond the limits of JS or just over-complicate the problem.
I’d like to announce the availability of a new program that I’ve been writing, Omega Hymnal. Omega Hymnal is a lyrics display program for informal worship settings.
Some time back, I wrote a little utility at work using CherryPy called EasyLIFT. The idea was to reduce the number of large files that were being sent as email attachments without having to resort to the tedium of setting up FTP accounts or a big complex CMS system.
EasyLIFT allowed users to login through their LDAP credentials, upload a file to a public-facing web server, and dispatch an email with the download location to recipients. The interface was minimal and quick to use, and was a real success at work.
Recently, I was looking for an open source project to keep my coding skills sharp, so I decided to do a clean re-implementation of the EasyLIFT idea using Flask instead of CherryPy. I dubbed the project LIFTS for “Large Internet File Transfer System”. No, we aren’t transferring “Large Internet Files”, or transferring Files over the “Large Internet”, but ILFTS is kind of goofy and not memorable, so there you have it.
The project is fairly young and not fully functional yet, but if you’re interested in pitching in or just checking it out, head on over to github and grab it from the repo: https://github.com/alandmoore/lifts.
More news to come, hopefully!
For users of WCGBrowser…
In the last few days I’ve added a few features:
- Firstly, proxy server settings. Several people requested this, though none wanted to sponsor development (I only asked $100 US). Turns out I needed it for something I was doing myself, so happy birthday everyone, you get this for free. Proxy settings can be set from the CLI, config file, or environment variables (common on many Linuxes).
- Secondly, stylesheets. Not that there’s much to style on WCGBrowser (the navigation bar, mostly), but you can now do it with QSS style sheets. A (really tasteless) example stylesheet is included.
Latest code can of course be downloaded from the wcgbrowser github page, or just do a “git pull” if you cloned it from there in the first place.
While I realize that wcgbrowser isn’t exactly the most exciting or groundbreaking piece of software ever created, I’ve been having fun improving it bit by bit over the last few months since I opened the source code. If I keep hacking away at this pace, I’ll easily have the most feature-packed kiosk browser around, for whatever that’s worth.
Here’s a quick rundown of new features, if you haven’t been watching the git logs closely:
I’ve been doing a lot of tinkering on my KiLauncher project over the last week or so, and it’s not only shaping up into a nice useful little application, but an educational opportunity as well
My goals for KiLauncher were to make it both theme-able, and configurable with plain-text files. The natural mechanism for this (for the theme, anyway) was CSS, a format with which any self-respecting UI designer is familiar. Fortunately, Qt supports a subset of CSS to style its GUI classes, sometimes referred to as QSS.
Last night i uploaded a new project to my github page, KiLauncher. It’s a fullscreen, static (as in not auto-updating) launcher menu aimed at kiosks, kids computers, corporate systems, and any other situation where an administrator wants to be able to both provide a simple interface and exercise some control over what applications are available to the user.
The software is still in the early stages, of course; I’m still working out the best way to structure the config file; yet it meets all its primary goals at this point and works just fine. It’s built in python and QT of course, and after my positive experience using YAML in wcgbrowser, I’m of course using it for KiLauncher too. Unlike wcgbrowser, I don’t have a real-world use for this software yet, but maybe someone who does can give me some feedback on it.