Shop Forum More Submit  Join Login
×
I was doing a little programming for one of my graphical creations but my mind started to wander...  I like thinking about engines and that is what came to mind, 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.

 maserati
Fig 01. The engine in my Maserati (when I was rich).

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.

 QB4.5
Fig 02. The QB 4.5 IDE showing a text-based environment for coding BASIC.

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).

 VBDOS
Fig 03. The VBDOS IDE showing a TUI - a text-based graphical environment for coding event driven BASIC.

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 VB.net but it felt like a bloated version of the Titanic in comparison to the speedboat that was VB6.

 VB6
Fig 04. The VB6 IDE showing the advanced graphical GUI environment for coding event driven BASIC.

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
Fig 05. The Yahoo widget engine running a widget, my chosen text editor displaying javascript, the debug window on the right.

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
Fig 06. The Yahoo widget engine running on Embedded Ubuntu on a television.

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
Fig 07. The Xwidget engine showing the graphical composition of a widget, the text editor displaying its javascript below.

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
Fig 08. The Inform graphical GUI compositor for QB64, the output form displayed on the right.

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.

STEAMPUNK WIDGETS!
Fig 09. My widgets, each a separate program written in javascript and powered by the konfabulator engine.

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...]
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.

 Widget


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

 Widget

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

 Widget

 Widget

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.

 Widget

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.
The Calendar gauge is now complete - you can get it here:
www.deviantart.com/yereverluvi…

 Widget

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

 Widget

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

 Widget
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.

 Widget


I will report the results of memory usage here shortly.

-oOo-

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 = "shortcut1.run") 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.

 Widget
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.

 menu
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: rainysoft.cc/

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:
 Widget

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

Then this:
 Widget

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

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

it has ended up like this:

 Widget
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.

 Widget
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.

 Widget
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.

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

Not happy with the design, not yet, still working on it.
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 - www.deviantart.com/yereverluvi… 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: www.deviantart.com/rainysoft

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 www.deviantart.com/yereverluvi…  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?

-oOo-

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.

 Widget

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:
bbs.xwidget.com/viewtopic.php?… and here: pan.baidu.com/s/1qXHu0Qo
So you can try out Xdesktop yourself and make your own comparison.

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

Finally, both the product's websites Xwidget.com and rainysoft.cc 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...
"


-oOo-


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: www.deviantart.com/yereverluvi… (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: www.deviantart.com/yereverluvi…
or, "a Rifleman's first duty is to clean his rifle"



www.youtube.com/watch?v=5PaW6i…


This never fails to pick me up.
This is art in a game.

In my previous journal entry www.deviantart.com/yereverluvi… you'll see me rant about the death of Xwidget 1.0, the desktop widget tool that hasn't been updated nor supported for years now. Now we see one of the reasons why:

A recent change to the Xwidget site (xwidget.com/) shows that Tony has been working on other products/projects. I suggested as much in my blog entry stating that Tony never completes a product to 100% and that "he has no staying-power to see the thing through and will be distracted by new technologies":

"The designer has always shown a propensity for wanting to work on new features rather than fix bugs he has introduced. His development team consists of one man, Tony and he is inspired solely by new features and new technologies. That is entirely understandable on a personal basis but Tony's shifting focus does not help to create a stable product that actually functions"

So, what he has created this time is Xsprite and Xanimateclock, the first a way of placing animated images onto the android desktop. Wow how thrilling... That's just what I always wanted (hopefully you can note the sarcasm). The second is a cut-down version of Xwidget with only the timer cores and preset clock image downloads.

Tony was meant to be working on Xwidget 2.0, let us hope he is  - but as I said he tends to get diverted by any new thing that takes his fancy.

I know you all think I have a bit of a "downer" on Xwidgets and Tony in particular. Well, I suppose you are all quite right but it is difficult to maintain positivity over years of product failure and continuing disappointment. We know why Xwidgets 1.0 has had no focus, the developer was working on other things, loads of them.
A more realistic temperature from the UK, 24 degrees C or 75 degrees in old-fashioned money. Pressure rising, low humidity, no wind, dirty toes. Now back to Deviantart for more - stuff.

 Widget
The majority of art these days is created digitally. The old way of saving your art was to place it somewhere safe. The same goes for your digital art. I use this method and it has kept me secure throughout years of computer use/hard disc failures.

Buy a new drive. Use it to clone your hard drive yearly, place the newly bought drive in its stead and place the older drive in a secure box preferably in safety in another building. You will benefit from years of backups and the latest in drive technology space/speed and it will only cost £60-£70 or so per year. If you are ever in trouble you can take the backup drive and put it back in your system and it will boot immediately and you'll have access to all your old data in minutes. Your machine will often end up faster too as new drive technologies improve. If you have a laptop with a single drive this method will backup everything, the o/s, programs, data, everything - all safe.

 backups

In addition to this, buy some 32gb USB sticks and copy your data to one of these each and every month. Ensure the USB sticks have holes so they can hang from hooks somewhere useful, so you don't forget. Mark them month 1-12, don't re-use them until the year ends. 32gb is normally enough for the majority of computer users. You may be able to buy smaller, cheaper sticks depending upon what you do, how much data you have, possibly 8/16gb will do. They are so cheap nowadays. You obviously only need to backup your data and not your programs.

Buy four others, mark them 1-4 and do the same weekly.

If you are really keen on backups and you can be relied upon to take backups then you could do the same daily on sticks marked 1-7 but for most that would be overkill.

This next bit is important - Never trust Microsoft and never store anything under the windows profile (my documents &c) - as a profile corruption can occur just due to high usage - and you can lose the lot all in one go. Trust me - it happens and when it happens to you, you will be devastated. Instead, create a single folder in the root of your drive with your chosen name and put everything there. You can move your Firefox profile folder to your chosen location and the same for your email program (thunderbird &c) - in that way it will all be backed up.

I use dropbox to synchronise my most important folder where all the creative work I make goes. 5gb is the current free size and it is enough to give me a daily/hourly copy. Warning! It is a mere copy however and not a backup so it cannot be relied upon to resolve corruption/overwriting. Explanation: As Dropbox syncs continuously your online data is vulnerable to corruption or deletion. Ie. if you corrupt the version locally on your hard drive it moves the corrupted version up to the web corrupting that copy too. Most don't realise that having one or two copies synched to dropbox or google drive is basically useless as a backup for your valuable data.

Note: Google drive is incredibly slow so avoid it. Their software will over-consume CPU and slow your PC to a crawl. Onedrive is a Microsoft offering and cannot be relied upon - proven - they will change the Terms of service, reduce your capacity arbitrarily, scan your data for useful information. Amazon is more or less the same and on top of that the service will periodically go offline. Check the web for verification of these facts, don't ask me! Use cloud storage at your own risk and remember how often you are without a mobile signal... even in the UK.

Note: Don't put your photos on your hard drive, keep them on SDcards/ USB sticks separately. they are much more reliable than hard drives. Print the best professionally on 100 year ink/100 year paper and put them in an album. This last act is the only way to preserve your photos for future generations. All hard drives will fail and all family photos will be lost if stored this way - it is just a matter of time. You'd be amazed how many collections of family photos have been lost because they were stored on a drive. Personal experience - Gone forever.

 Photos

This is a relatively simple method of backing up your data. Recommended and taken up by many. Saved lots of data, many times. Best of luck.
The rocketdock gallery is closing, for me it is a really sad day as it is THE place to go for icons. My icons/widgets received a million or more downloads from Rocketdock over the last few years and a search on Google for that sort of thing will always have rocketdock at the top of any search. It is a blow for me as it has always been one of my "go-to" places on the web when I want a resource or inspiration for a new icon I am creating.

rocketdock

It is/was also a quick, easy and free place to upload resources, wallpapers, icons or even widgets. A sad day indeed. It was here:

rocketdock.com/user/107284/add…

Rocketdock, the software will still be available from their main site punklabs.com and so the product isn't going to die - it just isn't going to thrive anymore being laid out to pasture I suppose for a gradual death through lack of support and usage. > sighs <

Rocketdock contains some proprietary code so it won't be made open source either, hmmmm.

For those that don't know Rocketdock, it is a functional clone of the Mac dock for Windows, similar to Objectdock with which it was compatible. It allowed configuration via skinning of the dock and all its icons. It is a very useful tool and it added to all my machines by default.

rocketdock
(right click and view image to see in detail)

I find myself becoming increasingly obsolete in the tools that I use daily and depend upon. Never mind! Such is life.

Rocketdock - your gallery will be missed! Skunkie and all the others at Punklabs, thanks for creating Rocketdock, thanks for the gallery over these years, Rocketdock's presence on the web will be missed.
If you like glowing steampunk thyratron tubes, then you will like this video:



www.youtube.com/watch?v=WX74Go…

www.youtube.com/watch?v=E0m10m…

www.youtube.com/watch?v=iX4UTe…
FAR: Lone Sails


www.youtube.com/watch?v=nIV-6k…