Shop Forum More Submit  Join Login
About Design & Interfaces / Professional yereverluvinuncleberMale/United Kingdom Groups :icondesign-addicts: Design-Addicts
design, art, customisation
Recent Activity
Deviant for 6 Years
Needs Core Membership
Statistics 880 Deviations 7,360 Comments 120,343 Pageviews

Newest Deviations

Airfix Hawker Hound + JU885 late 1990s box style by yereverluvinuncleber Airfix Hawker Hound + JU885 late 1990s box style :iconyereverluvinuncleber:yereverluvinuncleber 2 7 Airfix Hawker Hound + JU885 late 2000s box style by yereverluvinuncleber Airfix Hawker Hound + JU885 late 2000s box style :iconyereverluvinuncleber:yereverluvinuncleber 1 13 Airfix Hawker Hound + JU885 late 1960s box style by yereverluvinuncleber Airfix Hawker Hound + JU885 late 1960s box style :iconyereverluvinuncleber:yereverluvinuncleber 3 13 Airfix Hawker Hound + JU885 late 1970s box style by yereverluvinuncleber Airfix Hawker Hound + JU885 late 1970s box style :iconyereverluvinuncleber:yereverluvinuncleber 1 5 Airfix Hawker Hound + JU885 early 1980s box style by yereverluvinuncleber Airfix Hawker Hound + JU885 early 1980s box style :iconyereverluvinuncleber:yereverluvinuncleber 1 2 Hawker Hound and JU885-Z Airfix Dogfight Doubles by yereverluvinuncleber Hawker Hound and JU885-Z Airfix Dogfight Doubles :iconyereverluvinuncleber:yereverluvinuncleber 4 9 Cycling to Cthulhu by yereverluvinuncleber Cycling to Cthulhu :iconyereverluvinuncleber:yereverluvinuncleber 3 12 Steampunk Hole Desktop Tidy Tool showing Help by yereverluvinuncleber Steampunk Hole Desktop Tidy Tool showing Help :iconyereverluvinuncleber:yereverluvinuncleber 2 2 Dieselpunk Calendar Desktop by yereverluvinuncleber Dieselpunk Calendar Desktop :iconyereverluvinuncleber:yereverluvinuncleber 4 2 Dieselpunk Panzer Calendar Gauge Trial by yereverluvinuncleber Dieselpunk Panzer Calendar Gauge Trial :iconyereverluvinuncleber:yereverluvinuncleber 6 3 Steampunk Icon for Process Explorer by yereverluvinuncleber Steampunk Icon for Process Explorer :iconyereverluvinuncleber:yereverluvinuncleber 4 5 A damn fine steam engine making power... by yereverluvinuncleber A damn fine steam engine making power... :iconyereverluvinuncleber:yereverluvinuncleber 6 13 XWIDGET Version 1.0.0 Dieselpunk Volume XWidget by yereverluvinuncleber XWIDGET Version 1.0.0 Dieselpunk Volume XWidget :iconyereverluvinuncleber:yereverluvinuncleber 5 0 The Police Station that never caught JAck? by yereverluvinuncleber The Police Station that never caught JAck? :iconyereverluvinuncleber:yereverluvinuncleber 8 12 Kings Cross St. Pancras carved capitals by yereverluvinuncleber Kings Cross St. Pancras carved capitals :iconyereverluvinuncleber:yereverluvinuncleber 3 24 A temple to JAck? by yereverluvinuncleber A temple to JAck? :iconyereverluvinuncleber:yereverluvinuncleber 9 4


Churchill by NeedAssistance Churchill :iconneedassistance:NeedAssistance 52 4 Arista  by HipHopium Arista :iconhiphopium:HipHopium 38 17 Bell tower live wallpaper by ice-wind-wolf Bell tower live wallpaper :iconice-wind-wolf:ice-wind-wolf 1 0 Retro Sci Fi II by stayinwonderland Retro Sci Fi II :iconstayinwonderland:stayinwonderland 527 25 Panerai Watch for xwidget by Jimking Panerai Watch for xwidget :iconjimking:Jimking 3 0 004-1 by tec192 004-1 :icontec192:tec192 13 2 CopperState models Nieuport XVII Box Art by rOEN911 CopperState models Nieuport XVII Box Art :iconroen911:rOEN911 163 13 SP (steampunk) Widgets Pack for xwidget (FIXED) by Jimking SP (steampunk) Widgets Pack for xwidget (FIXED) :iconjimking:Jimking 18 26 The land warfare museum by Small-Brown-Dog The land warfare museum :iconsmall-brown-dog:Small-Brown-Dog 75 49 Military - uniform US soldiers WW2 USMC camo by MazUsKarL Military - uniform US soldiers WW2 USMC camo :iconmazuskarl:MazUsKarL 19 1 Surprise Visitor by Small-Brown-Dog Surprise Visitor :iconsmall-brown-dog:Small-Brown-Dog 84 53 ERLKING Ki-2 Tengu (Eng) by PCFayard ERLKING Ki-2 Tengu (Eng) :iconpcfayard:PCFayard 42 2 Wartime poster reproduction by Small-Brown-Dog Wartime poster reproduction :iconsmall-brown-dog:Small-Brown-Dog 24 10 Hanger Hound by Small-Brown-Dog Hanger Hound :iconsmall-brown-dog:Small-Brown-Dog 61 63 Summer Colors by kuzy62 Summer Colors :iconkuzy62:kuzy62 63 18 Paper Aeroplane by Small-Brown-Dog Paper Aeroplane :iconsmall-brown-dog:Small-Brown-Dog 89 23



yereverluvinuncleber's Profile Picture

Artist | Professional | Design & Interfaces
United Kingdom
My alter ego is yereverluvinunclebert. You'll find me around the web. Where you find steampunk design I won't be far away.

I focus on Steampunk Design, why do I do it?

Well, I can't bear the look and feel of current desktop computing being so locked into a 1980s 'modern' paradigm. Current GUIs deriving mostly from Microsoft's efforts have a basis in the GUIs from the late 80s and early 90s and despite the regular changes they still haven't moved on much. Do you run XP, Vista, Win 7, 8 or 10? Well, if you do, that means under the skin you are still running NT5 or 6, all basically the same fundamental o/s. The only real differentiator is the GUI that MS foists upon you. Now, a GUI is a GUI and should not be confused with the underlying operating system. You should be able to decide which style of GUI you want to run.

A GUI should be independent of the o/s or at the very least the o/s ought to be very easy to theme and to customise as you wish. This just isn't the case with any Microsoft operating system as the default 'look and feel' provided with the os is really the only thing that really sets it apart from the previous version.

You'll see a massive example of this with Metro or Material Design, the UI that comes with Windows 8 & 10. The underlying os is still good old NT6 and operates much in the same way that Win7 does. However, the whole user interface has been modified to try to get you to use live tiles on the desktop as you would on a Windows phone, to make you use 'apps' rather than programs as you would on the desktop. This schizophrenic approach to a desktop o/s is hoisted upon you as Microsoft has no decent tablet-centric o/s and instead are trying to squish Windows onto tablets - it isn't working, look at the death of windows phone and even more recently, the death of Windows on tablets. They are trying to get you to adopt a new GUI so that you conform to the business plan they have in mind for Windows. That business plan is now a failed model but you, the consumer is still suffering for it.

My aim is to help you break out of this corporate mindset and to think of desktop customisation as a natural thing to do, much in the same way that you decorate and design your home, make the desktop your place to live, to work and operate.

So, with this in mind, I set out to create a series of wallpapers, widgets and icons for an o/s interface that meets the aims and needs of a small but thoroughly dedicated group of chaps and ladies known as steampunkers.

I have set out my steampunk design skills in this way to demonstrate what I can do.

Whether or not you are a steampunker yourself, with these widgets and icons you can thoroughly steampunk your desktop.

You may use any of my images in any of your own creations but commercially only with my permission. In all cases I require a credit using my name or pseudonym - and in addition a link to my DA account or my own site.


I like thinking about engines, I have a straight six 3.8 and a 1.4 litre carburetter aspirated 4-pot as well as a cooking-2.0 litre turbo diesel. In my time I have owned a 4.0 litre V8, a 3.1 litre V6 and 2.5 V6 twin turbo Maserati as well as a 2.0 four-pot turbo Rover. Hundreds of horsepower, all fun.


Unfortunately, I am not thinking about that sort of engine. Instead thinking about the engines that underpin the creations that I build. I chose to build in QuickBasic (QB4.5) a long time ago, then abandoned it when I found severe limitations in the amount of memory that I could access.


Next came VBDOS that provided a lot more memory saving, in that the controls were built into the language which could be implemented more efficiently than my home-grown examples. Soon though, it was clear that VB or DOS was going to become obsolete and that Windows was the new thing (there was a time when that was not clear, amazingly).


Then there was visual basic for Windows, at first just VB then it became VB2, VB3 &c until the final incarnation VB6. I programmed a lot in VB6, migrating code, creating new code and became proficient, if not expert. Then came the time when MS pulled the plug on this too. This time they made the migration path so difficult (to VB.NET), changing the IDE so much and adding so much complexity to the language that a large proportion of its users simply jumped ship and abandoned VB altogether. I was one of them and I stopped coding altogether for years for the PC, feeling bloody annoyed at Microsoft for making all my skills obsolete. Never trusted them since. I tried but it felt like a bloated version of the Titanic in comparison to the speedboat that was VB6.


Turned my efforts to the web learning HTML, just a mark up language, CSS to style (appallingly backward) and javascript/PHP to provide the client/server logic. No IDEs worth using, the fragmented web, incompatible browsers, standards defined and then broken by Microsoft, hard to test, not a pleasant place to code. In the end I abandoned it as well adopting turnkey CMS solutions to create bespoke websites, still some coding to be done but more javascript/PHP focussed.

I switched entirely to javascript when I discovered the Yahoo widget engine. That engine promised a lot, your program could run on more than one operating system, both Windows and Mac os/x using industry standard javascript extended by APIs to access operating system resources. Portable code for Windows, the Mac and possibly even the web with a bit of tweaking. Great, wonderful in fact. A graphical interface for your program that freed you from the square windows paradigm that MS, Apple et al foist upon you. Superb. One let-down being the lack of an IDE but the intelligent use of Photoshop, a conversion script, the built-in Yahoo widget debugger and the adoption of an advanced text editor soon made the absence of an IDE acceptable.

 Yahoo debugger and Context Editor

Then Yahoo bought the engine with the idea of making money from it, they failed completely (along with everything else) and they shut the engine development down taking the gallery, forum and all with it. The useless, pathetic swines. Yahoo attempted to take their development of the engine for the Linux platform and turn it into a commercial tool for putting widgets on televisions. Many of you still have those televisions running Yahoo widgets, Samung, LG &c, your 'Visio' telly brand still has them today. Millions of them were sold putting widgets into millions of homes. Not for me though, I like a telly with knobs on. The Yahoo Widget Connected TV was a closed environment for invited TV developers only.  Not a place to code for the likes of you and me.

 Yahoo Connected TV widgets

A few other engines came and went, none of which I was exposed to, most died after a brief flourishing. Then Xwidget arrived from the Chinese developer I  know only as 'Tony'. At first it seemed a suitable replacement for Yahoo widgets being based upon Jscript, Microsoft's own version of javascript. It had an advanced graphical GUI and although it was buggy and undocumented it seemed to have a lot of promise, though it only ran on Windows or with a lot of reductions in functionality on Android too. I created a few of these Xwidgets as I expected the engine to grow, having an active developer. Soon though, I realised that Xwidget was going nowhere, the developer abandoned Xwidget and the widget developer community, starting small, never really grew, diminishing year on year until there was only one person active, and that was not me. At several points I abandoned Xwidgets only to pick it up again when it appeared to have some new life. I was wrong each time.

 Xwidget Designer

I briefly explored Kludgets when the developer promised some compatibility with Yahoo widgets but the developer moved on and abandoned his undocumented code to the web. It still sits there open-sourced but with no knowledge on how to build it or how it is structured, it is rather useless and so no-one is picking it up.

Working with the pure javascript to migrate the widgets to the web was an interesting idea I toyed with, however it can only ever be a sideline as pure javascript via a browser can never access the desktop resources required to make a useful widget. Javascript is specifically designed to keep you away from what the desktop has to offer. Widgets can be modified to work with a framework like node.js that provides a server through which desktop functionality can be accessed - but packaging all that up and expecting users to install/configure it all just to run a widget? The idea is a non-starter. You can run widgets within a browser as long as it is only clocks or similar web-based interaction that your widget requires. Each widget takes up a whole tab on your browser and does not show on the desktop, so only really good for web development.

Then we have RainWidgets, based upon HTML5 and Chrome's implementation of javascript. It might really be the potential future as long as we can keep the developer interested and focussed.  If he (Tony) open-sourced his code it would help to obtain more developers to assist with the task and it might also help to keep the project moving. Knowing the way that Tony managed the Xwidget project, I seriously doubt this will be the  approach. If Tony's methodologies are retained it will remain closed-source with zero forum involvement. Here's hoping though that things are better this time.

So, why am I thinking about engines? Well, a few recent developments have got me thinking about the future of the four engines I have some interest in:

Firstly, QB64 has a new GUI designer called Inform that allows you to create windows-based GUI programs in our old dependable BASIC language, the same QB that I started out with in DOS all that time ago. Quite amazing. Here's hoping that Fellippe, the developer, extends his GUI to become the default GUI for QB so it can in turn become the accessible 'go-to' RAD language for all computers... QB64 has that simple language at its heart, it also runs on Windows, Linux and Mac OS/X and is a 64bit application. These are serious advantages that could propel it into uncharted but profitable waters. Do you remember going to any computer back in the 80s and filling the screen with "hello world" or any other drivel you chose to type in?  Well QB64 has the potential to be that BASIC replacement. Keeping my eyes open but my expectations low, to avoid disappointment.

Inform GUI IDE for QB64

Secondly, the Yahoo widget engine has finally had the plug pulled. You may have thought that it died years ago but no, it has been soldiering on as the Yahoo Connected TV engine for years now. In fact, support was only pulled for the legacy Yahoo widget engine in March of this year. I missed the announcement, not that it affects me in any way but it does say "the end is nigh" even louder and even clearer. It won't stop me creating my Yahoo widgets using it, once a thing is obsolete it is obsolete, it doesn't get more obsolete as time goes on. It still works, is stable and dependable, it is efficient, fully documented, uses industry standard tools (XML and javascript), is multi o/s (just), bugfixed and easy to install/operate. There is nothing as good as the old Yahoo widget engine - still in 2018 this is true. In this case obsolete only means that there will be no more versions in the future and in any case, if you want my diesel/steampunk widgets there is no alternative, you have to run it.


Thirdly, I am beginning to glean that Microsoft want to pull the remnants of Internet explorer from Windows 10. They are preparing businesses for this mini -apocalypse (many business apps depend upon IE). This may have a nasty side-effect on the Xwidget engine. It may stop working altogether at this point. I am unsure as to how Xwidgets does its stuff, whether it links the Internet Explorer dlls (vbscript.dll, jscript.dll) at runtime to provide the ability to place widgets on the desktop combined with access to jscript and vbscript to provide the ability to interpret the widget's logic.  If this is the case, then Xwidget will die when the last remnants of IE are removed. If the Xwidget engine has the IE components linked in at build time then it comes with these essential components embedded within its own binary. In the latter case it may survive the purging of IE from Windows. In the former case, prepare for evacuation, as Xwidgets could be a dead engine, an X-engine - quite soon. I suspect the former is true and that is why Xwidgets is dying and why RainWidgets has come to take its place.

That brings is finally to the arrival of RainWidgets. I am keeping an eye on this new engine and hoping for the best. It came unexpectedly and in a form that surprised me. I am positive about its technical direction.  However, I always worry about leaving my crown jewels in the hands of one lone, closed-source developer, that is why I am not rushing out to build widgets using the new desktop engine. I will wait to see how it matures before I dive in.

[Rainwidgets image here]

That's it. I 'engineered' some references to car engines just to get your attention but hopefully the rest of the article wasn't too boring. After all, these engines are how I create my 'art', if it wasn't for these engines they would just be decorative images on a gallery somewhere.

[Links, image descriptions and a couple of new images yet to come...]
Airfix Hawker Hound + JU885 late 1990s box style
I dislike this design of Airfix box art, 90s junk, nevertheless, an accurate reproduction.

Created in co-operation with small brown dog, using his Hawker Hound and JU885z images. The box-tops were recreated in Photoshop CS from scratch using suitable artwork, stock and fonts as well as the Airfix logo.…
Airfix Hawker Hound + JU885 late 2000s box style
Created in co-operation with small brown dog, using his Hawker Hound and JU885z images. The box-tops were recreated in Photoshop CS from scratch using suitable artwork, stock and fonts as well as the Airfix logo.…
Airfix Hawker Hound + JU885 late 1960s box style
Created in co-operation with small brown dog, using his Hawker Hound and JU885z images. The box-tops were recreated in Photoshop CS from scratch using suitable artwork, stock and fonts as well as the Airfix logo.…
Airfix Hawker Hound + JU885 late 1970s box style
Created in co-operation with small brown dog, using his Hawker Hound and JU885z images. The box-tops were recreated in Photoshop CS from scratch using suitable artwork, stock and fonts as well as the Airfix logo.…
Airfix Hawker Hound + JU885 early 1980s box style
Created in co-operation with small brown dog, using his Hawker Hound and JU885z images. The box-tops were recreated in Photoshop CS from scratch using suitable artwork, stock and fonts as well as the Airfix logo.…
Hawker Hound and JU885-Z Airfix Dogfight Doubles
You'd be almost right to think of these examples of fine Airfix box art as being from the hands of Roy Cross that famous artist that drew the wonderful box-top art for Airfix in the 1960s and 70s. In fact, these fine digital paintings were from the hand of an equally competent aero-visualiser known only by the pseudonym of "small brown dog". The original piece of art used in these Airfix box-tops can be seen here:…

Click on the image above to see the box art in large form, the JPEG is a large one.

In the montage above we see the lower box style as it was sold in the 1970s whilst the upper box is that from the late 2000s and is in fact still on sale today. The original Hawker Hound MK IVB kit was created in 1969 from an example still extant in the Imperial War Museum's collection. The model itself has undergone various improvements in its lifetime but is still, in essence, an early 1970s quality model and as a result some additional work is required to make a model that matches the quality of similar offerings from other manufacturers. The Junkers 885 included in the kit dates from an 1980s re-mastering and as a result captures the look of a late model JU885 very well indeed even if some of the fine detail is a little overdone. Both kits are still sought after by kit-makers and kit-collectors alike as strangely no other manufacturer has ever created kits of this dynamic duo in battle.

...and if you believe that then you'll believe anything.

Created in co-operation with small brown dog, using his Hawker Hound and JU885z images. The box-tops were recreated in Photoshop CS from scratch using suitable artwork, stock and fonts as well as the Airfix logo. Now corrected the font on the earliest box, the "Airfix-72" needed the Corinthian font which was a little hard to identify. On the newest box-art, "model kit" text in many languages is now displaying using some of those many languages. The correct mini-images of the Hound and JU885 (as supplied by SBD) are now being displayed rather than a Hurricane and a JU88. Added some bullet holes to the "Dogfight Doubles" text and added some lower case text to the description. Also added the tabs on the paint pots. On the 70s box art I have added an increase to the curved corners to the main image.

All rights for all original Airfix imagery belong to Airfix of course, this recreation of some fictitious box art is a mere homage to the real thing and not meant to represent Airfix in any way. All hail to Airfix for being the stimulus for many of us to become modellers and artists in the first place. All hail to Airfix, all hail to Haldane Place!

Please visit this link and purchase a model!

PS. I keep smiling whenever I look at these box-tops.
Whether Repord (sic) this Fivesday the fourteenth of Septoomba. Coolish with the gentlest of breezes, lovely weather for a night-time stroll on the beach. Clear skies with bats rising and moonbeams falling.


Takes me there.
I am working just a little on this widget...


Just giving it a gentle overhaul to ensure it has all the other options that my other apps have.



There isn't another program quite like it. It sits underneath all other widgets and other desktop items exposing the inner workings of your broken screen.


If you drop any desktop item (shortcuts, files, documents &c) it will automatically place those into the appropriate folder, for example .doc files will be moved to the my documents folder. If it fails to recognise a specific file type then you can manually add that extension to the list and it will deal with them from that point on. It works on Windows XP, 7, 8 and 10, Vista and Mac OS/X High Sierra.

It was created using Photoshop and  my old default editor Context. I am updating it now using RJTe and adding a few small functions.
Steampunk Hole Desktop Tidy Tool showing Help
This widget is a hole in your screen (burnt by the Martians) that can be moved around the desktop and placed where you like. It sits underneath all other widgets and other desktop items exposing the inner workings of your broken screen.

I'd forgotten how good the help screen is...

The widget is here:…


This widget was created with the serious coding skills of Harry Whitfield. I supplied the graphics, the original code, the concept and idea and steered the widget toward its final goal. I also tested the widget, added extra functionality and fettled the code for release. Harry built the core functionality to my spec. but just did it far better than I would ever have done!

You may use any of my own images in your own creations but commercially only with my permission. In all other non-commercial cases I require a credit to the original artists using their/my name or pseudonym and a link to their/my sites. With regard to the commercial use of incorporated images from other artists, permission would need to be obtained from the original

New Dieselpunk Panzer Calendar Gauge using the same graphics adapted. Widget being built as of now. Just a trial image for the moment.


Code will be created using RJtextEd and that is in progress now. This is the working widget on my desktop, a work-in-progress.

Dieselpunk Calendar Desktop
This is just a trial image of a widget I am creating now. It is a variation on one of my Dieselpunk Panzer gauges for displaying the current date. There might be one for the date, another for the time &c. As yet undecided.

Just a trial image of the working widget on my desktop, a work-in-progress. The widget is yet to come.

You may use any of my own images in your own creations but commercially only with my permission. In all other non-commercial cases I require a credit to the original artists using their/my name or pseudonym and a link to their/my sites. With regard to the commercial use of incorporated images from other artists, permission would need to be obtained from the original
Dieselpunk Panzer Calendar Gauge Trial
This is just a trial image of a widget I intend to create. It is one of the Dieselpunk Panzer gauges for displaying the current date. There might be one for the day, another for the month &c. As yet undecided.

Just a trial image, a work-in-progress. The widget is yet to come.

You may use any of my own images in your own creations but commercially only with my permission. In all other non-commercial cases I require a credit to the original artists using their/my name or pseudonym and a link to their/my sites. With regard to the commercial use of incorporated images from other artists, permission would need to be obtained from the original owner.
RainWallpaper is just a wallpaper tool, nothing more, nothing less. You can select an animated wallpaper from the default list or take a wallpaper from the online gallery. It displays an animated wallpaper image on your system background, on the main monitor or the second.

So, on to two installations to test the product, first of all the bad review and then the much more positive review. I give you my reactions in the order I tested.

The installation was easy and simple though the download was quite large and took a while to complete. When installed it is easy to run and places a small RainWallpaper icon (a raindrop) in your systray for access to configuration options.

This was the point at which I started to worry - using the Wallpaper functionality on my base system (a quick enough 2.5ghz core2duo laptop with 4gb or RAM and a fast hybrid drive) it consumed 65-85% of system resources to place an animated background image with moving snow or steam or smoke...  My immediate reaction has been to uninstall it immediately with the feeling that I did not know what this tool was for. My thought was that if this is a tool for high-end systems to allow them to run an animated wallpaper then that's fine, it does its job but if you are a low power users it is just going to consume vast amounts of carefully husbanded cpu/graphic resources and it won't be for you. However, if you have a more powerful system, you may perceive things differently.

To focus on the performance aspect of RainWallpaper alone I have two laptops on which to test the software. The first is a core2duo laptop that has a built-in Intel GMA45 600mhz graphics card and 2.5ghz dual core CPU. For comparison it can run Medieval Total War at medium settings with armies of 4,000 independently rendered men with smoke effects &c on a 3 mile wide battlefield. It does this smoothly with no hesitation. It runs photoshop and can process large multi-layer images converting them into usable resources in a matter of seconds. It can run 30-40 widgets simultaneously, each using CPU and its own resources, it does this using a mere 10-15% of CPU. It is running two engines at the same time with no CPU issues. It runs my coding environment and I can code two/three projects simultaneously (with the widgets running in the background) whilst supporting 30-40 tabs in the latest version of firefox for me to use simultaneously. It can run World of tanks in low quality mode, one of the most demanding graphic games currently out there.

Yet RainWallpaper uses 60-85% of the CPU on this core2duo? Initially it did not seem to add up. It was wallpaper and it was animated, it ought not be that inefficient. I can create a full screen widget with animation effects that would use a maximum of 30% of the CPU. Something was wrong with the code or they'd used some advanced functionality that required hardware functionality that a reasonably top-end card requires. My first thought was really, a wallpaper that requires a powerful GPU?

When I read the minimum requirement specifications I soon found that the  recommended GPU to support RainWallpaper is : NVIDIA GeForce GTX 660, AMD HD7870, 2 GB VRAM or above though a Intel HD 4000 will do. The GPU in my core2duo, although capable for older games, clearly lacks some specific hardware capability that RailWallpaper requires.

My second test was performed in a 2.5hz Quad core HP pavilion with an 800mhz AMD Radeon R5 graphics card. Initially, the system cpu usage rose during installation, the same during the first run of the program and usage of the gallery to select a wallaper. From that point with the wallpaper selected, the cpu utilisation settled down to a mere 2-3% of CPU. The graphics card of the second laptop was clearly able to support the hardware functionality that RainWallpaper requires whereas the first laptop just could not. The result on the HP Pavilion was a very nice animated wallpaper that taxed the system with very little CPU demand. One of the wallpapers on display in the RainWallpaper video is a really rather nice rain-dripping-down-a-window effect. I imagine that users of RainWallpaper will be delighted with the tool but they will be those with higher-end systems. If you are not a power user then be aware that RainWallpaper is not for low power GPUs.


I will report the results of memory usage here shortly.


One the bad side RainWallpaper put a manga-girl's face on my desktop by default  - and if you know me, you'll know that is a serious mistake :) . On the good side, the software works, is fairly elegant in operation. My system reports no viruses, no obvious malware (Avast and Malwarebytes) and it was easy to install/uninstall (though after one test it did leave a gallery.exe process consuming a lot of cpu that I had to shutdown manually using task manager, this could have been a left over from an a/v analysis by Avast). RainWallpaper also restarted on the next test boot when I thought had explicitly told it not to do so - that could have been my mistake.

Note that regardless of any bugs found RainWallpaper is in beta which means that it will have bugs that remain to be corrected by the developer. RainWallpaper is not yet the finished article so hold your criticism until the final version is out.
Update 1. 6th September.

The first alpha/beta of the RainWidget engine has just been released. What is RainWidgets? - I hear you ask. Well, RainWidgets is the spiritual successor to Xwidgets - though before you rush out to try to download and install it - hold on! RainWidgets is NOT Xwidget 2.0. Firstly, there is no upgrade path from Xwidgets, second, there is no IDE and finally, there is no simple and easy way to create widgets using a few cores and some .js glue.

Rainwidgets is a pure widget engine and that's it, no IDE, no prettiness, no padding, just an engine for HTML based widgets. So, before you get upset and feel depressed and annoyed that Xwidgets has taken the wrong direction be placated by the fact I am fairly sure that RainWidgets has actually taken the correct direction. So far it has the feeling that it might just be the tool that a lot of desktop customisers and web developers have been looking for. A really rather good tool for putting HTML based widgets on the desktop.

RainWidget engine
Fig. 01 RainWidget Alpha Release with some yet-unreleased widgets.

This is exactly what Xwidgets probably should have been and what it almost became. Xwidget 1.0 was attempting to emulate Yahoo widgets, ie. a javascript engine with o/s APIs that allows web technologies to access the desktop. Xwidgets did it rather badly integrating a half-decent GUI IDE but unfortunately not extending API support to the underlying language, javascript. RainWidgets is not following this approach and instead is using the power of the latest browser engine so it can use stock technologies (with its own o/s extensions) to place HTML/CSS and javascript straight onto the desktop. This is a good approach as it lends itself to anything from simple widget creation as well as having the power to potentially put any complex web application straight on the desktop. This really could be the killer app that everyone has wanted for years...

Tony(?) and his team (I think there was once another chap that worked with him called qiancang) have become quite used to me pouring scorn on their offerings, the bugs in Xwidgets, the failure to fix them, the failing infrastructure, the lack of documentation &c &c but this time they really ought to take a pat on the back. RainWidgets as the spiritual successor to Xwidgets is really spot-on and they should be congratulated.

Some brief technical stuff that I have just guessed from just looking at the thing: Chrome is the browser core, the javascript engine is Chrome's V8, RainWidgets incorporates the vue.js framework to do some of the javascript heavy lifting. For those that have unpicked a typical widget, the RainWidget equivalent to Xwidget's widget.xul file is the widget.json (the equivalent is the .KON XML file in the yahoo widget engine). Image or text elements are typically defined there, such items as width, height, names, data sources used &c. The good thing is that nothing is set in stone. You can build a widget anyway you like. In fact, you should be able to port any existing web widget and with a bit of tweaking it should just work (testing this now).

The core of a RainWidget is an HTML page where you define the location of the CSS, create any required divs and then call your javascript logic. The RainWidget team have provided a few examples of running widgets, one of them a quite complex web widget using jquery. None of them should be copied slavishly as examples of how to create widgets, instead you should consider them as examples of the engine's capability to use any style and method of widget creation.

Jquery and other web technologies are supported but are not required. If your widget is already designed to use vue.js then there might be an implication as the engine itself uses vue.js (a javascript framework that does the javascript heavy-lifting for the engine). In this case it might just require you to remove the line that initialises vue.js in your own script to avoid duplication or conflict - unknown and untested.

Element styling is achieved in CSS using an embedded .css file that is included into the HTML or as an element within the HTML itself using the style tag. Styling can even be achieved in javascript. Basically, the rule is - do it yourself, however you choose. You are not limited.

Instead of cores as in Xwidget, RainWidget uses DataSources, only a few data sources have been implemented so far: weather, datetime, shortcuts &c. So far, we see few operating system APIs to the filesystem or other useful operating system functions (the drive API is the only one so far) but after all, this is only an Alpha grade release so we ought to lower our expectations and await new cores in the fullness of time. The developer is drip-feeding new data sources weekly, probably as soon as he has cut the code so keep an eye out for new functionality.

An image or element is bound to a data source using the vue.js framework's v-bind directive. The usual events should be supported, eg. the onClick event (v-bind : onclick = "") as well as all the other usual events (untested). Some events are currently implemented differently, for example: onkeydown/onkeypress - some drag/drop functions are not working as expected, perhaps he hasn't implemented them properly yet, "doKeyDown" being some sort of a workaround for a non-working keypress - more on this soon.

The javascript engine is Chrome's V8. A good choice of javascript that comes bundled with the embedded Chrome engine that RainWidgets uses to place the HTML widgets on your desktop. Previously, Xwidget used Jscript, Microsoft's own version of javascript that had some pecularities and features other javascript engines did not have. For example, easy and direct access to the operating system through ActiveX/COM and extras such as the enumerate function will no longer work. As a result, some existing widgets' javascript code will not easily migrate to RainWidgets and any widget developers will have to depend upon any new cores that Tony writes to provide this missing functionality. It was mooted previously by Tony that in Xwidget 2.0 the APIs would be made available for user-modification or that the new engine would have the capability to run custom 'cores'. We shall have to see if that functionality ever actually materialises in RainWidgets. I feel slightly unsure as to whether this promised functionality will ever arrive in RainWidgets as it may not be in the devs' best interests to allow creation of custom cores in the new engine. It would rather detract from the developer's contribution allowing others to customise and take control of his engine. So, we'll just have to wait and see. Personally, I would love to have this functionality, given that the creation of new cores was one of Tony's previous worst failings. I personally created polyfills in Xwidget's javascript to replace missing functionality, I'd like to do be able to do the same in RainWidgets using an 'official' method.

The set of widgets that are currently bundled with the engine are a little unimaginative graphically but they demonstrate that the engine works and they do show the rather impressive capabilities of the engine itself. I have yet to fully build or migrate any one of my steampunk widgets but work is at hand testing and creating. Watch this space!

Some other features:

When you add a new widget instead of displaying a gallery that points to the software's main site (as did Xwidget), it does basically the same thing but instead it takes its feed directly from a specific Deviantart gallery - which is quite a sensible choice. It also has an option to open any local widgets on the appdata/widgets folder. For me, the gallery is a little intrusive on my desktop being so large on my 15" screen that it fills the screen, it can also seem a little unresponsive, especially when attempting to install a widget. I feel it needs more feedback to the user in order to tell him what is actually going on - I would prefer a more positive install button on each widget image and a progress bar during download and installation. Note that the Xwidget dock functionality has not been carried over to the new engine, in fact the new gallery acts as both a download location and a replacement for the dock.

The widget's settings pages are a significant improvement over Xwidgets (in that they exist at all - a good copy of Yahoo widgets prefs functionality) and each settings page is automatically generated according to the contents of the widget's  .JSON file. Very useful indeed.

A negative point is that the settings screens are very large, in fact far too large and clunky being based on Microsoft's preferred 'modern'-type themes. The resulting configuration windows are significantly over-sized for a windows desktop. It would be very useful if there was a RainWidget configuration option, a simple switch to reduce the settings font sizes and resulting window size so it suits the desktop. It is great having a settings screen optimised for those tablet-style systems out there but we also need an option which also provides a useful size for desktops. At the moment the settings screens are big and quite ugly. Experience from other engines proves that the widget configuration screens need to be compact and not overly-large especially when we take into account migration of existing widgets from other systems with complex configuration and plenty of options.

Fig. 02 A typical large RainWidget settings page compared to a similar but compact one from another engine.

The current RainWidget right-click menus are quite good, anyone familiar with Xwidgets will notice how similar they are in layout and operation. Unlike their settings counterparts they are easy on the eye taking their layout from Windows default theme. I'd recommend leaving the menus to adopt their size from the current windows theme rather than forcing a particular look-and-feel such as that encountered in the menus of the sister product RainWallpaper.

Fig. 03 The RainWidget Menus conforming to the Windows theme as set by the user...the centurion font used.

The engine by itself uses no discernible CPU when running no widgets. The widgets themselves are quite efficient, they simply use as much or as little cpu as your program requires. If you have a simple clock widget then it will use very little in the way of cpu resource. If you have a complex widget that does a lot of animation then expect it to use a lot more cpu. We have already migrated a few of our widgets to web widgets (this being the same technology used by RainWidgets) and the different browsers (Firefox, chrome, Edge, Safari) handle animation differently, some more efficiently than others. RainWidget's embedded browser engine Chrome should be quite efficient at handling javascript animation in our experience but it has yet to be determined how well the engine runs complex animation in code - as this is untested. When running a complex animation in a web widget on the Chrome browser (some while ago) the animation was a little choppy at times. We shall have to see how this operates through the engine though I suspect it will be similar. Machines with faster CPUs will have smoother animation as a lot of javascript animation may be accomplished using mathematics and/or canvas manipulation. As RainWidget is using the latest Chrome technology it should benefit from the improvements to javascript optimisation that future versions of Chrome brings (webAssembly &c)

Each RainWidget exists within its own process context, this is a good feature as it means one crashing widget will not bring down the whole engine and all the other widgets with it. This is the same safe method used by the old Yahoo widgets engine but not by Xwidget. In Xwidget one nasty bug could have an adverse impact on all the running Xwidgets and made Xwidget an unstable product. RainWidgets is much better designed from the outset. This is probably more due to the way that Chrome implements each page as a separate process rather than a feature of the engine itself. Nevertheless, it is a significant improvement over the Xwidget way of doing things.

As yet, the documentation is sparse. Do not depend upon it, the widget is still being built, things will change. In any case lower your expectations regarding documentation, the documents from this particular stable have always been a bit lacking. The good thing is that the documentation you need to write your widgets will simply be the standard documentation for javascript, CSS and HTML which is available everywhere on the web.

With regard to the missing IDE. If this is a product from the Xwidget stable then any existing users wishing to migrate will expect an IDE. I think those people will be quite disappointed. I don't think the developers will create an IDE at all, focussing instead all their energies on the engine itself. Why do I say this? Well, the IDE is a massive task on its own, imagine creating a completely new widget engine, then a graphical compositor and in addition developing and maintaining a decent code editor? That is huge amount of work and in any case, the engine needs a lot of time to complete, probably six months work or more. Having said that, I have seen the prototype ofTony's next generation IDE and I'll drop a picture here when I get time (see below) so it is possible that the graphical compositor may see the light of day - one morning perhaps - but for now consign the idea of a fully-fledged IDE to the dustbin.

Tony's XWidget 2.0 IDE
Fig. 04 Tony's XWidget 2.0 prototype IDE that has NOT been shipped with RainWidgets

Note that the above IDE was shipped with the precursor to RainWallpaper - the prototype XDesktop which was designed to be a combination of RainWallpaper and RainWidgets. The two eventually split into separate tools but the XDesigner shows what the developers had in mind for their next generation IDE.

The use of the Rain... name? I know that some Rainmeter devotees will be annoyed with the developer's choice of name. It does imply that the product is from the same stable. If it helps, the developer did moot compatibility with LUA and Rainmeter skins for Xwidget 2.0 but if that is an aim for RainWidgets I'd be surprised, given RainWidgets current direction. Product naming is not of the developer's strengths, the Xwidget name itself was ambiguous given that it was already used by other similar web-related products.

That's it, that's all I have to say so far. RainWidget is not a simple tool for beginners and that will put off a lot of Xwidgeteers that will be wondering where to go from here. I'd say to them, stay put and keep creating Xwidgets but seriously brush up your HTML, CSS and javascript skills, you'll need them. In any case RainWidgets is still a tool in an alpha state, ie. being heavily developed now and not for serious use. It is missing almost all the most useful cores except the weather so my recommendation is to leave it for a while until both you and the product matures.

To everyone else, the serious web-coders, I'd say download the alpha version and give it a go. Some proper coding will be required especially as there is no IDE and no coding environment provided at all. You just need to use the tools you are already familiar with for web development. If you are a frustrated Xwidgeteer and you need some help from another long-suffering widgeteer regarding the cross-over tools that might be required, just ask and I''ll be pleased to help or make some recommendations.

You can obtain RainWidgets here at Rainysoft:

With regard to support, the product is in alpha so don't depend upon it and don't ask the developer any questions, just leave him to get on with the coding. In any case there is currently nowhere to ask him any questions as there is no forum. You can now submit your new widgets to the new group on DA, as it has just opened to normal members.

That's my initial review with one update to reflect reality, if I've made any mistakes please feel free to correct me. I had only been experimenting for a few hours when I wrote the article so forgive  any typos and other technical mistakes.

Congratulations to the Xwidget team, sorry, the RainWidget team for creating such an amazing (alpha) tool! I have high hopes for this product.
I am busy finishing the Panzer Weather Widget set of gauges and whilst I have been busy it always appeals to me to work on something else, just to keep the brain from being bored.

Started out like this:

Fig 1. Initial image cut with the basic idea in mind but done some time ago.

Then this:

Fig 2. Some changes to make it suit the current code.

Fig 3. An Interim image, with most of the buttons and locations in place.

it has ended up like this:

Fig 4. Finalised image, reduced screen - looking more 'real'

This was initially just a first cut of an image for which I have some code already developed and ready to go. It has been amended to fit my new skeumorphic Steampunk design but that has been carried out by good friend Harry Whitfield. I had intended to adapt the code myself but Harry has been knocking the code together as I bash together the images.

Fig 4. Help for the new startup manager. Right click and view image to see in detail.

Sometimes creating the help page for a program/app in advance of the code helps you determine what it will actually do. I think it is often a better method than creating a requirements document. Initially it was some sort of program manager but now it is a tool to manage the delayed startup of widget-based apps.

The design is now 95% done. 90% of the code exists already. With the design process over then comes the coding with RJTe. Even with Harry cutting the fundamental code I will soon take a copy of his code and start inserting menus and giving the widget the 'life' (animation, sounds &c) that it needs to become a truly skeumorphic creation. That is achieved with a combination of sounds, graphics and code.

The new widget app is a manager for widgets that delays their startup for a discrete period of time and then initialises each widget on a delayed timer. It also allows you to close all the widgets and restart them at any time, a useful function in low memory conditions.  This particular program is more useful for low power systems (core2duo/Atom &c) that can encounter refresh issues when redrawing the background. Each of these widgets is a separate program and each is responsible for redrawing its own background. When the CPU is overloaded, a bug in the engine (or in Windows) occasionally and rarely causes a failure to redraw, leaving a small white background.  Starting the widgets one after the other in turn reduces CPU overhead reduces the possibility of this occurring. That was the concept behind the widget but it now does a lot more.

Fig 5. This is the startup manager operating on my desktop at this moment for testing/debugging

The startup manager exists in two forms, maximised shows the control button base and the screen above, minimised shows just the control button base.

Fig 6. This is the startup manager in minimised form.

Not happy with the design, not yet, still working on it.
* See recent changes at the end. *

I have created a series of desktop gauges using javascript, not quite multi-o/s but the same code for Windows and Mac o/s.


This is a temperature gauge that extracts its information from Open Hardware Monitor and then animates the pointer and lamps, gives a working right click menu and full help. It is more of an app. in that it is a discrete package, probably 1,500 lines of standard ECMA javascript, a few lines of MS Jscript with a little XML.

There are nine of these gauges, all following the same design and each performing some sort of similar system monitoring function. They all run within their own process context and use a runtime engine to allow the javascript to style and access the graphic imagery. They run natively on Mac and Windows. The 'app' runs using minimal CPU <1%. It does consume about 6mb of RAM due to the high-res graphic imagery that needs to look good even when resized to full size (CTRL+mouse scrollwheel up/down).

This is the first chunk of javascript that I have overhauled using RjTextEd. It was used to allow me to get to know RjTextEd, my new text editor

Not my first of these, I have created many and as I put them through the mill of RjTextEd I'll post and image of each here.

The next is the Panzer clock gauge, once again built with Javascript, I forget to say on the previous OHM gauge I have a javascript version and a Jscript version for Xwidgets, the code more or less is the same, the difference is that each uses a different runtime engine to render the images and provide the APIs to the underlying o/s. For each of these gauges there are two versions and for some there is also a web version. Some gauges don't easily translate to the web as javascript apps cannot access machine specific information through the browser, clocks can work in any medium.

The following are two screen captures as GIFs that I hope will work on this forum showing what the gauge does.


This is the gauge shown in a large form, of course it can be shrunk in size. It is only shown this size for clarity. The next GIF shows the gauge being manipulated, the clock being resized and the buttons clicked upon.


All the gauges are open source and all my graphics are free to use non-commercially. The gauges can be cracked open (zipfiles) and the resources inside extracted easily. I'm happy with it if anyone else wants to create similar gauges for other platforms.

About 1,000 lines of .js code. All the graphics are created using Adobe Photoshop. The gauge comprises layers of PNGs with transparent backgrounds that are placed together using an XML definition. None of the gauges have a traditional border, no close buttons and no standard controls, all are bespoke.

There is no IDE for desktop javascript (at least none worth having) so I build using Photoshop and convert the design using a javascript converter that takes a PSD file and creates an XML definition from it. The runtime engine then works with that XML to pull the graphics into a whole and the javascript logic is hung from the various objects. The javascript converter creates code for two engines.

I use RjTextEd to edit the XML by hand and of course to craft the javascript logic. Each engine has a debug mode and so I test the logic there, view the results and make changes to the .js dynamically. It is almost a RAD environment as there is no need for compilation, binding &c, it is simply code and run.

Not much of a description needed for the next gauge, all built using the same technology as the previous. Uses in-built APIs from the engines to extract the information so the number of lines of code is reduced, this gauge is a new build based upon an older gauge that is functionally identical.

As you can see it is a self-contained resizable battery gauge.


Only a few more to go! As I overhaul each I'll post.

PS. I am using Licecap to capture the gauges as GIFs

Panzer Ram gauge. Takes the memory usage from the widget engine's API and uses the same code as in the previous gauges to display current RAM usage in analogue and digital form. These are primarily analogue gauges and they are designed to appeal to the sort of mind where a visual representation of data is more important. They also give the human mind the chance to take in a value at a glance.

A rather useful gauge on Windows, which has been designed with insufficient memory management allowing user processes to consume more memory than the system allows (no working set extents) in turn pushing system processes into heavy virtual memory usage, a situation from which Windows seldom recovers correctly and after which a reboot is almost always required.


Once again a gauge designed for two separate javascript engines.

Now the CPU gauge, yes - I have more of these...


Resizable using the mouse scroll wheel, the interval is configurable and the hand animation uses minimal cpu in itself.


The interval in the image above has been set to zero so that the CPU reading is continuous.

Drive storage gauge showing current space usage, each gauge can show a selected drive and the gauge can be spawned so that you can have one gauge per drive.


Low quality GIFs. Apologies.

There is a short delay on the above pointers after a drive was selected, not present in the final version.

My next gauge is incomplete, ie. I am still working on it as it inconsistently extracts data from WMI, sometimes triggering errors on one machine and not in another. The fundamental signal strength is good it is just the bandwidth data that is failing some of the time. Regardless the gauge is complete visually and it does the job. Very useful on a laptop with a router that may not be quite close enough to maintain a good signal..



All my creations are skeumorphic, ie they all look like their counterpart in real life. I see no reason why the human mind has to conform to visual representations that look nothing like the real devices we have come to know and understand. Computers should conform to us not the human conforming to the machine and certainly not to the idea of a theme from a computing corporate monolith like Microsoft. </rant>

Anyhow, that's the idea.

Panzer Weather Gauges

These are the gauges I worked upon last night, creating the images and scripting the creation of the gauge objects. This is just a taster, the barometer face is not yet complete and the gauges are clearly not polling for the weather, formatting the incoming XML data &c. However, the structure has been implemented within which the weather code will be placed. I already have some weather code written a long time ago which will need to be re-written and improved to match my current efforts.

The gauges are placed upon the desktop within the context of one process but they are individual gauges and can be placed/moved/controlled separately on the desktop but resized together. The reason for lumping them together is that it is expensive on resource to have three separate gauges each polling for weather, it would also triple the number of weather requests to the source - that might annoy the provider! So, instead I will have one process that polls the data and three gauges that use the data from that one single poll.

Fig 1. First cut.

It can be a bit of tedious job creating analogue gauges. I have to create a face displaying pressure in millibars, hPa and in/Hg, each of which are still relevant scales of measurement and still used today around the world. The most sensible method would be to use text elements to display the scales and calculate the values using code but if I use text elements on the gauge then the character of the gauges will be lost as Windows fonts are a bit limited meaning I can't use anything exotic. If I place the visually-correct graphic number images on the face in code then that is a fair bit of programming to get just right due to spacing issues &c. It is just a little more simple to create a unique face for each unit of measurement. I have already created the correct temperature face options in Celsius/Fahrenheit (not shown). On the barometer, one face is more or less complete, just two more to go...

Making good progress on the weather gauges:

Fig 2. Interim version of the gauges - code is in place, graphics 50% complete.

Shown with eight of the ten or so other gauges. The weather code is in place and polling the weather feed correctly. Just need to do all those little extras that make a working set of gauges and finish the gauge faces. creating the fahrenheit temperature gauge, then need to modify the centigrade face so that it starts with a minus scale and the two remaining pressure faces.

Making progress with the gauges - slow but sure.

Fig 3. Latest version of the gauges with functionality updates.
Right click and view image will show the gauges in a larger scale.

The digital displays are now operating as are the lamps. The barometer has a rotating slider that indicates previous pressure reading. The temperature gauge now has a low-temperature indicator lamp and the (moveable) clipboard displays the weather for today in an easily-readable text form. The gauges are individually resizable and there is an animated busy timer to indicate when the gauges are polling for data.

Fig 4. Latest version of the gauges with resizing updates.

The three gauges can now be resized separately and the size is now stored/remembered for each restart. The gauge colours are being revised to suit the operation of each gauge and the descriptive icons on each are being improved. Small changes in code to the menus, to allow the textual description of the weather to be copied to the system clipboard so that you can paste the weather into another program, email, text &c.

Next task is to finish off the scales on the faces, -30 to +50 on the centigrade scale, to match on the fahrenheit scales and then the alternative barometer faces.

Day 4.

Added first cut of the anemometer (wind speed gauge). It only shows speed in knots and not yet in direction - that is yet to come.

Feedback! Please - you don't have to like them, skeumorphism is not for everyone but feel free to comment.

Day 5.

Improvements to the anemometer to give wind direction, essential on any weather gauge.

Fig. 6 Wind direction to the anemometer.

The serif font and the sections on the scale give it a more classical look which may not be in keeping with the 30s look and feel of the other gauges so I may change that.

Day 6.

Just so that you know - I'm not spending the majority of my time on this, probably 2-3 hrs per day spent late in the evening when kids have gone to bed, working on graphics and code. Graphics in Photoshop, code in RjTextEd.

Currently adding help screens for each gauge, mostly a graphic task bu there is underlying code to trigger the correct image from the appropriate user interaction.

Fig. 7 Help image for the anemometer.

Fig. 8 Help image for the barometer.

These 'extras' are essential for making an application usable. The gauges themselves are not full programs but just desktop 'apps' that do one or two tasks. That functionality does not quite justify a full help document for each app so a help image will suffice. Callable from the right click menu or from a click on the correct screw/pin.

Day 7.

Created two new help screens for the thermometer and humidity gauges, enabled resizing for the clipboard and added configuration options to allow the clipboard text font to be configured to a chosen font. I won't add any new images for the moment as they are just help screens as per the above.

Day 8 and 9.

Option added to allow gauges to be resized using scrollwheel with/without CTRL. Added text areas for Macintosh os/x instead of text fields as Mac prefers text areas. Fixed a few minor bugs and tested. Not much to show. Will add images of new faces soon.

Fig. 9 Help image for the thermometer.

Fig. 10 Help image for the humidity gauge.

Using ScreentoGif recorder I've captured the gauges on my desktop. Not much occurs, the gauges simply obtain the weather from the weather feed and display the various values using the pointers. The gauges can be resized to the smallest size or to take up as much of the screen as you want. The tooltip gives you the text version of the weather, just hovering over any widget shows the text format. Clicking on a help lug pops up a context-sensitive help image.

Some of the clarity is reduced during the recording process but it gives you an idea. Not yet shown is the clipboard, the right click menus and the location selector. Soon to come.

Fig. 11 The gauges on my desktop. Right click and view to see in full size.

Not made any changes in a while, you can get a little over-gauged when working only on the one program, so I have paused on development for a short period. Today however have made some progress:

1. The barometer storm lamp is now lit when it detects a barometric pressure drop of 1 millibar per hour or more.  

2. Each gauge now repositions itself back on screen if any gauge is accidentally moved off screen for any reason.

3. Tested the translations - The whole program can be automatically translated into any other language using a user-supplied language file. I have supplied one localisation - Romanian, that is 90% complete. Translations supplied by Google translate. Then choice of alternative language is eclectic I know.

4. Implemented the pressure memory indicator, the indicating object now retains the last pressure setting allowing the user to see how much the pressure has dropped over a period of time. When clicked upon it rotates to the current pressure reading ready to start again.

5. Also implemented the code that places the gauges in specific positions when a monitor is in landscape or portrait modes. This is not very important for most window users but for those that have windows tablets that can be rotated automatically according to how users hold the device, the positioning of the gauges can be manually configured so that they position correctly in each mode. I originally wrote this code when there was a chance that Windows tablets might actually take off...

6. Added a small clock object that displays the time of the last poll for weather data. Just placed it on the clipboard for now with no visible means of restraint. I may add a cord to bind it to the clipboard.

Fig. 12 New polling time clock on the clipboard. Right click and view to see in full size.

I know I have slowed down - that's just reflects reality. However, I have created the new screen for taking locations or icao codes to determine the forecast area.

Fig. 13 The ICAO input window started out like this - Right click and view to see in full size.

Fig. 14 New ICAO input window current look and feel - Right click and view to see in full size.

The differences may look small but they take all the time: new cables; rust layers and holes; grab handles; cables; exit and entry points; refractions on the glass; new tape layer; buttons have been remodelled; new indicating lamps; screws resized; new dymo tape shading and generally ageing.

Still unfinished, unhappy with the punched holes in the paper recording tape. The big buttons still displease me but we need something big for people to push...

This of course all done with Photoshop and not pure code but there is code behind all this and I am working on that simultaneously... As a button receives a press the event needs to be captured, an alternative button press image needs to be shown, then the logic for handling a weather location (city search) or an ICAO code (check code is valid and poll) then an XML request is sent and the resulting DOM tree is parsed and the relevant data is extracted. The data is then formatted and passed to the gauges.

Fig. 15 New help file for the clipboard - Right click and view to see in full size.

In addition I have added support for the storm warning lamp. If the pressure drops by 1 millibar and is also a recent reading then it will light the lamp red. A storm system's pressure typically falls at a rate of more than 1 hectopascals/millibars per hour. If the air pressure falls 24 mb (or more) in 24 hours, the system is called a bomb cyclone. The code accounts for an hourly drop of 1mb by storing a previous pressure value, compares the system time by translating the unix system time to seconds and doing a simple comparison to a stored value of the last poll time. This also caters for the computer waking up from a sleep or a restart where the last poll time will be old and out-of-date.


I find handling unix system times in seconds to be a little bit of a pain but I suppose it makes sense doing it that way in javascript.

As well as the above I have added a new menu item to get the icao code download from there too.

The temperature gauge has been modified to show temperatures as low as -30 degrees centigrade and now shows the equivalent temperatures in fahrenheit too.


Recent changes include:

o percentage placement according to landscape orientation
o test the placement in portrait mode using ctrl+alt+cursor keys
o photoshop new temperature face -30 to +50 (as above)
o fahrenheit temperature percentage calculation for fahrenheit face especially the black window reading
o each individual gauge receives focus as the mouse enters enabling the pop-up weather box to function on all gauges
o added useful comments on polling to busy counter

Fig. 18 New Pressure gauge measuring in inches of mercury.

The gauges are working now, despite missing one final gauge, the weather icon gauge that I am working on at this moment.


Fig. 19 New Weather Icon gauge showing the current weather.
This is the only download location at the moment (limited beta release):…

21st July 2018 - No new major visual changes.
Fig. 20 Weather gauge configuration screen also showing shadowed weather icons

Recent changes include:
// photoshop new pressure face = inches of mercury
// photoshop new pressure face = hPa (hectoPascals)
// add a clunk when changing faces
// fixed a variable declaration bug in checkIcaoFile
// gave shadows to all daylight weather icons
// fixed poll return count so that when the airport provides no METAR data, is handled gracefully, it also quashes an error.
// removed some obsolete code
// face for mm/Hg
// added green/red lamp functionality showing validity of the feed
// barometer history pointer initial rotation set on restart
// added barometer face selection on restart
// gave shadows to all nighttime weather icons
// add improved moon images to the nighttime icons
// replaced the wind icons with coloured wind sock icons
// some new preference/configuration options

I have used my trial editor RJTextEd to create these gauges from beginning to end. I think the only way to evaluate a product is to use it in anger for a period of time. RJTextEd is getting better and better all the time and my bug reports/feature requests could not be made without getting to know the product in detail.

In the old days I would use VB6 as a forms designer and the code editor to give the logic. The interpreter and debugger to check my code and the in-built compiler to create an executable. These days I use Photoshop as my forms designer, each object in a layer. Some javascript converts the design to an XML object description and individual graphical PNGs. I use RJTextEd as the code editor to craft the javascript that provides the logic. The XML, the logic and the PNGs are picked up by the runtime engine to interpret and pull together the running gauges, it also provides a debugger. There is no compiler, no executables, everything is interpreted, everything is open.

// implemented new face for mm/Hg
// added green/red lamp functionality showing validity of the feed
// barometer history pointer initial rotation set on restart
// added barometer face selection on restart
// gave shadows to all nighttime weather icons
// add improved moon images to the nighttime icons
// replaced the wind icons with a coloured wind sock
// some new preference/configuration options
// time to next poll indicator now rotates
// time to next poll indicator tooltip

// after a sleep it ought to try to poll
// after a sleep the error message should be suppressed
// the error message should only appear after 'n' defined attempts at polling


// anemometer face for wind speed in m/sec


Added a face able to show temperatures in Kelvin as well as Fahrenheit and Celsius.

We all know about the unhappy decline and fall of Xwidget, that potentially very useful javascript based widget engine that the developer largely abandoned over a period of many years. Well in a previous post I raised a rant about Xwidget being just a little dead -… and stated the reasons being that xwidget was abandoned was the developer's interests lie in developing new software rather than fixing the myriad bugs in his existing offerings. I listed Xsprite and Xanimateclock as two new products that had taken his attention and now a third emerges and that is RainWallpaper.  You can see it here:

A nice new name and a lovely look-and-feel but just so that you know - RainWallpaper and the the forthcoming RainWidget might really be Xwidget 2.0, the early versions of which we were asked to test. The reason I say this is that the development versions of Xwidget 2.0 we saw were identical to RainWallpaper and focussed on full screen image generation using themes rather than individual widgets as was the original xwidget 1.0. In fact, that was one of my earlier complaints about it, that it was deviating from its original concept of the single widget just too much.

Well it seems that my complaint over the direction of Xwidgets 2.0 was ignored and it seems that the intention of the developer was to position Xwidget 2.0 (or as it may become rainWidget) as a series of customisation tools for the whole desktop from background-up. This seems to be the new direction. OK, a wallpaper themeing tool as a start is a nice enough concept and that that's fine but it certainly does seem to consign widget generation to a second place if this is the flagship product. In addition, it has yet to be tested as to whether the older widgets will still function in the new forthcoming tool (rainWidget) - see below.

That new tool with the new name has consigned the old Xwidget name to the dustbin, which is probably a good choice given that the Xwidget name has been thoroughly tarnished by years of abandonment, malware inclusion and the absence of the developer from any support forums. The new umbrella group name as you will have guessed already, starts with Rain... and the first from that stable is RainWallpaper, the next would be RainWidget. The Rain... name has been rather cleverly chosen to entice users into believing this is a tool from the Rainmeter stable. It leads you to suggest in your own mind that rainmeter skins also function within one of the Rain... series of tools. If that IS the case - and I had previously heard that this was one of Tony's aims, then I will be very impressed.

I will do my best to test the new product(s) to see its shortcomings and the new functionality that it offers. My hope is that RainWidget provides integration with RainMeter and extends this with the facility that a javascript engine provides. This would be my hope.

[I've rather burnt my bridges with regard to the relationship between myself, Tony the developer and Dimitri who runs all Tony's forums and who creates the majority of the Xwidgets that you will see about the place. I have complained so loud and so consistently about what the two of them create that the relationship has really been rather tainted (I seldom hold back when I don't like something), so my expectation of being able to review early releases is minimal. I'll only be able to test what I can download just like everyone else but I promise that I will provide a good and thorough review as soon as I am able. As a result, most of what I say here is conjecture but based upon prior experience.]

Note one rather negative point to start with though. I had previously raised my fears about the worry of malware bundling due to the devs (Tony) failure to provide the source code for Xwidget for peer review. I received a comment from RainySoft (the official DA promotion account used by the supposedly-new creators of RainWallpaper) on this thread…  stating:

"Tony had send the XWidget 1.x source code to us,this is very helpful , we had readed and checked all the source code and Make sure there is no malicious code inside."

Well, isn't that nice? I am fairly sure that the developer of Xwidgets and the developer of RainWidget are working together - so that negates any code review as being rather self-serving.  I am sorry but this sort of blather is the wrong way to start a relationship with your new users, clients and customers. Remember RainWallpaper may well be a commercial product (just as Xwidget is) so don't start lying to your customers from the very beginning!

FACT: The source code for Xwidget has never been given to anyone for independent review.
FACT: The original Xwidget installer was bundled with malware and PUPs (more recently this was fixed after I screamed very loud).

I have to say I don't think the comment was from Tony the developer (at least I hope it wasn't) I imagine it is from his pal Dimitri who also goes by the alter-ego of JIMKING on DA. He is the sort of person who comes up with this sort of blather from time to time. It could also be another developer, one who worked closely with Tony at the very beginning of Xwidget 1.0 development.
So, whoever you are, this message is to you :

"Don't screw us around, don't pretend that the source code is fine just because you say you've reviewed it yourself. If you are JimKing then you don't know one end of a piece of code from another. Jim, you have never been a coder, never written a complex program in your life and could review some complex Delphi/C++ as easily as I could raise the Titanic using tweezers and some string..."

If you ARE Tony or if there is now a 3rd party developer involved then I'd suggest that he let people know the real situation so we know exactly what is happening. PLEASE NOTE: I am awaiting confirmation that the developer of RainWallpaper is not Tony and not connected to Xwidgets in any way. If this confirmation arrives and is proven then I will rewrite some of the above article. I don't think I will need to. If I AM right in my assumptions it begs the question - Why do they feel the need to lie?


Q. How did I arrive at the conclusion that RainWallpaper was a partial successor to XWidget?

"First of all I was told that Tony was working on a successor to Xwidgets, it was to be Xwidgets 2.0 with a new IDE and a new approach, compatibility with LUA and rainmeter skins was suggested. Tony gave me what he said was the very early Alpha version of Xwidgets 2.0 to test and it confirmed some of this approach, instead of a widget engine it was a full screen wallpaper customisation tool allowing creation of animated themes appearing to relegate widgets to a second place if they were there at all. Instead of the current xwidget IDE there was a 'modern' full screen grey style interface that Microsoft et al seem to like at the moment.

The similarities between RainWallpaper and what I saw bundled with Xwidgets 2.0 was remarkable, they are in fact identical in all respects so you can see why I am assuming they are from the same stable even if they have new names... Xwidgets 2.0 as provided by Tony had a themeing tool called Xdesktop which is more or less identical to RainWallPaper in ALL respects even down to the filenaming and folder structure. The menus and back end are identical in functionality. Some of the resources, translation files are exactly the same style. They are both built by the same person using the same technologies. The only significant difference is the absence of the prototype IDE.


Also, Tony has always been very guarded with his code refusing to give it out to anyone and the fact that he supposedly gave the code to someone else to view and to base the new engine upon is remarkable too. It is so uncharacteristic of him that I suspect he is working with the new chap (if it even is a new chap) to create the new widget engine together.

Tony had stated the xwidget 1.0 engine was based upon Delphi and I suspect it is quite an old version, perhaps even a Borland version. Developers seem to be leaving the original Delphi in droves and Tony himself said that the technology in Xwidget 1.0 is too old to develop further and that new technology need to be adapted to take it further. That is exactly what we see here.

In the very beginning of Xwidgets we saw more than one developer, not just Tony, I am fairly sure of it. My supposition (I may be wrong) is that this is the chap that did most to the legwork on xwidget 1.0. It also explains why there has been so little development over the years if this chap was absent.

Some information for you to make your own decision:

The mooted Xwidget 2.0 discussion (and download) can be found here:… and here:
So you can try out Xdesktop yourself and make your own comparison.

Here is Xdesktop's Deviantart page -… - never released vapourware, the page was created by Tony but the product was  never released.

Finally, both the product's websites and are registered with Godaddy and hosted on the same webserver at Bluehost. I think I can fairly confidently state that both products are created by the same person/team.

That is how I arrived at the conclusion that RainWallpaper was a partial successor to XWidget...


My worries for the future of Xwidgets are that if the new tool is from the Xwidget stable it will be full of bugs, be incompatible with Xwidgets and that the developer will lose interest before it is complete. I really do hope not but prior experience may well prove me right. I have a strong feeling of deja vu...

ADDENDUM: Disassembly of one the new widgets by DeviantArt user compass_UK and myself does seem to confirm that the old widgets will NOT be compatible with the new engine being based upon different technology (not XML but JSON and using standard HTML and CSS). The widgets run in a browser context and use some in-built functions to achieve o/s interaction as does Xwidget but otherwise there is little similarity to Xwidget. My RainXwidget review will come in a separate article later.  See below.

Let us look on the bright side - there is a new version of Xwidgets emerging, albeit with a different name, a different aim and an entirely different approach, possibly even a different developer. Let's give it a positive reception and give it a try. My review is here:… (and it is very positive).

Now, my final worry, all of us who have paid for Xwidgets 1.0 licence with the promise that Xwidgets 2.0 would be ours soon. Does that mean that our licence to Xwidgets automatically transfers to RainWallaper/RainWidgets when they become commercial offerings or because the developers have changed the name, we have to pay again? Let's hope not.

PS. My review is now out for RainWallpaper. You can see that here:…

Journal History


by acg3fly

I really like it. The icons are clearly the work of a professional. However, I don't see the over-arching 'theme'. They are all individ...


Add a Comment:
HipHopium Featured By Owner 2 days ago
Thanks for the +fav;) (Wink) Nod  
tec192 Featured By Owner Sep 6, 2018  Hobbyist Artisan Crafter
Thank you very much for fave!)
yereverluvinuncleber Featured By Owner Sep 6, 2018  Professional Interface Designer
It was nice work. Feel free to submit to my groups.
tec192 Featured By Owner Sep 7, 2018  Hobbyist Artisan Crafter
yereverluvinuncleber Featured By Owner Sep 7, 2018  Professional Interface Designer
The tank designs to design-addicts.
(1 Reply)
CinnamonDevil Featured By Owner Jul 19, 2018
Thanks for the watch, I really appreciate it :)
PCFayard Featured By Owner Jul 9, 2018  New Deviant
Thank you for the fave! Thank you for assisting my take-off attempt...
yereverluvinuncleber Featured By Owner Jul 9, 2018  Professional Interface Designer
Do submit your art to my groups whenever you want.
PCFayard Featured By Owner Jul 10, 2018  New Deviant
Thank you for this!
Jolliu Featured By Owner May 28, 2018
Nice to have you on board.
Add a Comment: