Shop Forum More Submit  Join Login
×


Douglas Rain - just had the last of his memory banks pulled. That voice will never be forgotten.
350 years ago at the very start of technology, before the five wars that nearly wiped humanity from the face of the world, a fragment of a moving 2D visual from three centuries ago has been recovered from the platter of a magneto-optical device. It isn't known who she was but she seems to be protesting against the oncoming outbreak of an impending war (was it the second or third?) using a style of music that hasn't been heard by the human ear in centuries.



Was she a goddess or was she a political oracle? She sits at a pedestal whilst her image surrounds her. We will never know for sure. One thing is for certain, she was genetically untainted by the radiation or neurological toxins that taint us all now - the proof that humanity was originally biologically pure is now proven - by that face!
We have computer that is no slouch, a quad core 3.0ghz Dell Optiplex 390 with 8gb RAM and an Nvidia Geforce GT640 with a terabyte of SATA 3 drive storage - it should really fly, especially as we aren't using it for power-user programs.

However, it just doesn't.

This Dell desktop is slower than my old 2.5ghz core2duo laptop with boot times tripled and with a less-than-snappy response from Windows. Each click on a setting pane results in 4-5 seconds of waiting whilst it displays a stationary, non-turning cog wheel before it eventually does anything.

The machine is in general disappointing in use, feeling clunky, slow and ready for the junkyard. That was, of course, a machine running the latest version of Windows 10.

This lack of power was noticed after a recent-ish update to Windows 10, everything seemed to be having a bit of a go-slow. We decided to see whether it actually was caused by Win10 or whether perhaps we had just filled the registry with so much crap that the machine was beginning to creak at the seams.

This lack of power was intrinsic to the system until we improved it by downgrading to Windows 7. The installation of Win7 was performed onto a completely separate hard disc, retaining Windows 10 just in case we need it in the future. The installation of Windows 7 went without a hitch, lots of updates, a few reboots, driver updates which cumulatively took a few hours on a relatively slow internet connection.

I've installed the majority of the tools and software I need so that the software configuration matches that of Win 10.

The result? A machine that flies in comparison, Windows 7 feels like a hardware turbo-boost. The boot times are less than a minute whereas Win10 was struggling with 2.5 minutes. The control panel screens are instantly responsive just as they should be and everything is snappy and tight. Everything is in the right place and the UIX is familiar and intuitive. My thirteen year old son, who has only known Windows 10 for the last few years thought I had installed a BRAND NEW version of Windows, he was SO impressed by it. He was able to navigate the system with ease and stated that everything was so much easier to find...

His downgrade was an upgrade. That is how it felt to me too, we were always struggling with Win10, trying to make it load the software we wanted, trying to add a local admin user is a 5-10 minute struggle in Win10, in Win7 it is a 1-minute doddle.

To be blunt Windows 10 is appalling. It has taken our fast desktop system, disabled its built-in GPU, installed all its bloat and has ended up running our system at approximately 50% of expected speed, especially during boot up. The Windows 7 downgrade has made the system usable, it looks much better on the desktop (crisp and clean and uncluttered) and it runs 50% quicker.

Windows 10 is an appalling travesty of an o/s that we have to downgrade to Win 7 to make a powerful machine usable again.



1978 Bill Withers next I suppose... needs to be a lovely day for that.

www.youtube.com/watch?v=Fo6aKn…
Read on all artists that use a computer to create their art. If you use Windows 10 then you have a potential problem that could cause you to LOSE ALL YOUR ART.

ALERT: Windows 10 October Update (1809) BUG - synchronisation issue causes deletion of ALL your data within the user profile structure (MY DOCUMENTS &c). Affects Windows 10 HOME and PRO versions.

UPDATE: - Microsoft have removed the update after many users have had ALL their files deleted. By the way, Microsoft knew that Windows was deleting files, they had known for months that it was doing this and they still rolled out the update.

UPDATE: - The update will now become the NOVEMBER UPDATE and it will be tested thoroughly - we hope. Regardless, the advice below is still recommended

Do not upgrade your PC, turn off Windows auto-update or if you don't know what you are doing do not turn on your PC (to avoid the auto-update) and only turn it on in a few days when you know Microsoft have sorted the problem.

The problem appears to be related to an obscure setting which allows Windows to delete old user profiles. It may have some connection with ONEDRIVE and is mooted to be a synchronisation issue. According to sources, Windows has been deleting all files in the users "my documents" folder that are not linked to ONEDRIVE.

This is a seriously big mistake that makes using the Windows profile utterly unreliable (but I knew that anyway).

My suggestion is that you manually take all of your data (NOW) and remove it from the Windows profile structure immediately. Instead of storing all your data in MY_documents and MY_videos &c, you place all of your data in another location outside of the Windows user profile area. Those profile locations are typically mapped below c:\users\username ...

Instead create your own set of folders, for example:

c:\videos
c:\music
c:\stuff
c:\letters
c:\downloads

Perhaps a set of folders under your own name and located on another drive/partition:

d:\beelzebub\videos
d:\beelzebub\music
d:\beelzebub\stuff
d:\beelzebub\letters
d:\beelzebub\downloads

(Change Beelzebub for your own name!).

Move your files, data and all to these alternate locations and keep them there forever. AVOID using the Windows profile area for any storage of any important data at all. Profile loss caused by the incompetence of Microsoft is just the latest in a series of potential issues that can affect a profile. Profile corruption is a regular if infrequent occurrence and you don't want it to happen to you.

Please take great care when moving your data, it is times like this when user errors occur that can compound with another problem and thence cause a disaster...

Top tip No.1: From this point onward, never place any important data within a Windows profile, complete data loss will result - eventually. Profile corruption is the worst to be feared. As I have always stated, never place your data within a Windows profile structure - as sooner or later you will lose everything to the Demon God Microsoft.

IF you have backed up your data as I suggested here: www.deviantart.com/yereverluvi… then at least you have a safety net. If you haven't backed up your data and you have auto-updates enabled by default (almost everyone does as it practically impossible to turn auto-update off these days) and you have Onedrive installed and running (practically all windows 10 users do) then there is a good chance you will lose your data.

Final advice. Find out how to remove/uninstall ONEDRIVE, there are better solutions, avoid it, dropbox is my recommendation and there is Google backup  (slow and inefficient, used to be called Google Drive) but Onedrive has been removed from every Windows 10 PC in my control.

Links:

1. How to turn off Windows updates in two steps:
www.thewindowsclub.com/turn-of…
www.thewindowsclub.com/windows…

2. How to remove Onedrive
lifehacker.com/how-to-complete…

3. How to install Dropbox
www.dropbox.com/help/desktop-w…

4. How to backup your PC easily -
www.deviantart.com/yereverluvi…

5. Useful utility to restore your files
www.aumha.org/downloads/restor…
Potential new widget - Some graphic changes to existing help, about and gauge faces, some copying of the code from the Panzer Flip Calendar allows me to create a flip clock. Largely complete, I am now just adding the sound, need to find the appropriate subtle sound that works and does not annoy at the same time.


Fig01. The flip-flop clock on a portion of my desktop.


Fig02. The help screen


Fig03. The about screen


Fig04. The right-click menu


Fig05. Just the clock gauges

Not just a straight copy. It required a lot of changes to the code as each flip flop needs to have its own action. The old calendar flip flop did not require this as it flipped in groups. The code change from group to single fipflop was not simple as each gauge is an object and was quite complex to change.

Harry Whitfield, my partner in crime when it comes to widget-making has converted this widget to a pure HTML and javascript widget. This means that we have a RainWidget version of the Panzer FlipClock that should run well under RainWidgets. All tested and working. Needs some tender love and care and tweaking before release. I feel I need to know RainWidgets before I just dump a widget out there.

You can see it as a web widget here: g6auc.me.uk/PanzerFlipClock/  

This version incorporates a countdown timer. Note this is our trial version and functionality may change without notice
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. (Testing has shown that Xwidget does install on a Windows compatible o/s without IE and its components installed, it does not yet function fully on that o/s so it is still unclear how it operates.).

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.


Modern Rainwidgets on the Windows desktop.

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 2. 28th September 2018

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.

To obtain system-level information, instead of using cores as in Xwidget, RainWidget uses "Measures" (originally called DataSources in the first version). Xwidgets cores were APIs designed to be implemented at the GUI level and stored within the XML and as a result were largely inaccessible to the javascript 'glue' layer. It was often impossible to derive data from an Xwidget core in code.  Measures seem to be better designed giving the javascript direct access to the derived data.  

Only a few measures have been implemented so far: weather, datetime, shortcuts &c. So far, we see very 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 measures in the fullness of time. The developer is drip-feeding new measures weekly, probably as soon as he has cut the code, so keep an eye out for new functionality.

(Battery, CPU, RAM measures added in 1.22 and 1.3)

An image or element is bound to a measure 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 most basic 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