Shop Forum More Submit  Join Login
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.


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

Rocketdock will still be available from their main site 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.

(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:………
FAR: Lone Sails…
So, it is confirmed that Xwidget is officially dead, I have just been told by the developer that the older product, ie. the Xwidget 1.0 designer and engine, has been declared officially dead, ie. that there will be no new bugfixes on the product and no new features. That is despite asking the community to test Xwidget 1.0 for problems and create a comprehensive buglist which the developer promised would be addressed. The community duly created that list but unfortunately that list will now be ignored, no bug fixes will be forthcoming, that community work will be chucked in the bin. Disappointing to say the least...

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. Tony is really good at making something work to a 95% complete standard, all the really hard work is done and the result is truly admirable. Unfortunately the last 5% is where all the bugs reside. That 5% of effort that is required to complete is where Tony's core weaknesses lie. He cannot commit to fixing anything as his interest wanes and he moves onto pastures new. That 5% of missing, broken functionality is not just in the occasional feature, it is present across the board in almost every feature he has implemented. Any product he creates will all be so riddled with bugs as to be almost unworkable/unusable.

Tony just can't get his head round completing things. It isn't one of his strengths.

In addition Tony's skills do not lend themselves to any sort of documentation. The documentation for the Yahoo widget engine is 374 comprehensive pages. The documentation for Xwidgets currently consists of three or four community-created, very empty wiki pages that are incomplete, lacking any detail and in case they have been offline now for over a year. The in-built help is simply atrocious, misleading and unusable. It is more of an un-helpful feature...


Assistance has been offered in this area for years by many parties but it has been rejected many times by a complete lack of response from Tony.

Tony just can't get his head round documentation. It just isn't one of his strengths.

The infrastructure for Tony's offerings is an interesting cobbling together of technologies, a small site with a download page, a forum, gallery and a server for the online weather data, however it cannot really be relied upon to work correctly. The Xwidget and Xlauncher downloads were infected from the very start with malware and PUPs that took an enormous amount of vociferous work from the community to remove. The product and therefore the domain names were always ambiguous and the choice of name for the products was a mistake given that xwidget name was already used  in technology elsewhere. A poor choice of name that has actually led him to rebrand Xwidgets as Cwidgets... but you'll not really notice as it has only been partially carried out. The site is utterly static which as anyone with web experience knows, that says a lot about a product, no product information, no release information, no site updates, implies the product is dead.

The weather server is a bit of a kludge. The weather source requires each user to have an API key but to get round this limitation, Tony has a 'master' API key and he gets the weather information and puts it onto his own server, then every Xwidget/Android weather widget in the world polls that data from Tony's server instead. That means that if Tony's server ever breaks down or has a go-slow or Tony goes on an extended holiday then all weather Xwidgets are dead - possibly forever.


To make matters worse the forum, gallery and weather server were all on the same server and they competed with each other for resources, the forum and gallery going offline when weather requests were at their peak.

The gallery has always been a bit naff. Searching by type, categories of widgets, no - none. Until recently the widgets were all lumped into one big carrier bag with no decent ability to sort the wheat from the chaff. creators of widgets cannot even submit their widgets to the gallery! The most recent innovation was to make the gallery a commercial offering with no viable alternative gallery for the non-commercial user-generated widgets. Limiting the one main resource that Xwidgets has, the wealth of widgets, to paying customers only? How daft is that? Cutting off your nose to spite your face...

Tony just can't get his head round Infrastructure. It just isn't one of his strengths.

The forum was a component that Tony implemented early on, a place to submit your queries and frustrations. It turned out to be a place where only frustrations were submitted.  In all these years the forum has been run by one man, Jim King. Jim was given control of the forum without all the admin privileges required to do so and with none of the access to the underlying tools that help to keep the forum alive. Jim played the part of the developer trying to help in Tony's absence but Jim has no product knowledge other than that he has picked up during widget creation - and no programming knowledge whatsoever, so he can't help on any of the scripting issues. None of this being Jim's fault, he could not be expected to replace the developer on the developer's own forum. I always felt sorry for Jim, abused as he continues to be.

Tony's complete absence from the community that he had created, a complete failure to engage with the community, a total absence from the forum from inception until today marked Tony's idea of community involvement. The only time Tony ever responded was when the community was forced to 'go nuclear' and was screaming at Tony to respond. In five years I have seen Tony respond perhaps once or twice and only to the really critical issues. It is the same with email, Tony will not respond to email in the normal way of things, he only responds when you give him an ultimatum.


Tony just can't get his head round support and communication. It just isn't one of his strengths.

So, back to reality. I have been really badgering the developer to make him take some assistance, help with the forum, help with the documentation, help with bug-fixing - anything at all. My suggestion that he make Xwidgets open source was rejected as Tony would rather leave Xwidget to wither on the vine than let his 'baby' go into the hands of others that might make it productive and usable. Tony's idea of reality is skewed from our own, asking us instead to work on documentation (that is permanently offline) or to wait for his new Xwidget 2.0 product (or is it Cwidget?) that has been brewing for years...


I finally put it to the developer that unless he makes the Xwidget 1.0 source code available, so that I and the community could help with real bug-fixing, that I would withdraw any offer of help and assistance. His response was that he is busy on Xwidget 2.0 and that we should all wait on that. Well, the sad truth is that I cannot ever suggest to anyone that we should wait for one of Tony's products. They are shoddy, badly implemented, full of bugs, completely undocumented, are typically underpinned by flaky infrastructure, are completely unsupported, lacking any feedback to or from the developer, user requests are completely ignored, the developer has a historical propensity to include potentially unwanted programs in his downloads, he has no staying-power to see the thing through and will be distracted by new technologies before Xwidget 2.0 ever reaches stability. In addition to that, the new product is likely to have functionality that no-one even wants as he never, ever asks the community what functionality it would like the new product to have.


Tony just can't get his head round reality. It just isn't one of his strengths.

Tony has just told me that the focus is now on Xwidget 2.0, that Xwidget 1.0 is no longer the priority. Therefore, Xwidget 1.0 is dead. The upgrade path?  I do not expect that there will be any compatibility between Xwidget 1.0 and 2.0 and given Tony's track record even if it is implemented it will be broken in some key respect and bug-fixing will not be forthcoming.

I would never trust any product that Tony creates. All his products show a trace of genius, a spark of something truly great that only someone inspired could create. However, that genius comes with a price, the product is always incomplete and unusable in some key respect. Support and documentation will be missing completely and the product will be abandoned just as you get to grips with it. Your involvement with it will be completely frustrating.

Tony needs one thing to complete the picture and that is help and assistance from others.  He has to let go of the things he does badly and allow others to take over.

Unfortunately, Tony just can't get his head round his own limitations. Self-realisation just isn't one of his strengths.

PS. Follows an old post which was redacted after a discussion with Jim and Tony is now more pertinent than ever:

"Is a project dead when the developer refuses to fix any of the bugs in his code? Is a project dead when no new substantive changes are made to an application for 5 years? Is a project dead when the only new code the developer introduces is a new splash screen and a partially functioning but buggy sound visualiser? Is a project dead when the developer refuses to fix his flawed and buggy IDE? Is a project dead when the developer ignores almost all 99.9% of requests for his help? Is a project dead when the developer works only on the things that interest him (on other projects on other platforms) ? Is a project dead when the developer refuses to appear on the support forums he himself has set up ? Is a project dead when the developer gives no roadmap for the project? Is a project dead when the infrastructure for the project keeps failing on a regular basis (forum, documentation, gallery &c)? Is a project dead when the developer refuses to provide any documentation? Is a project dead when the developer refuses to acknowledge repeated offers of help from its community? Is a project dead when the developer fails to acknowledge that he is the sole reason why the project is dying?

I think so.

For example: This is the link for the documentation: - A dead link, the server/domain is down and has been down for ages now.

Xwidget has been on life-support for years, kept alive solely from infusions from the Android version and from the direct feed pumping blood from the body of JimKing. I tried to do my bit to revitalise Xwidget from time to time, documentation, code samples, migration tutorials, advice on malware, advice on how to monetise Xwidget, bug raising and finding work-arounds. In the beginning I even created a few widgets. Not any more.

Xwidgets is dead and the person holding its head permanently under the water is Tony, the developer. It is time to pull the plug on Xwidgets to declare it dead. Then hopefully Tony will abandon it, make it open source and someone else can pick it up and run with it.

Xwidget is dead, Xwidget has passed on. Xwidget is no more. It has ceased to be. Xwidget has expired and gone to meet his maker. Xwidget is a stiff, bereft of life, it rests in peace. If Tony hadn't nailed it to the perch it'd be pushing up the daisies. Xwidget's metabolic processes are now history. Xwidget is off the twig. It's kicked the bucket, Xwidget has shuffled off its mortal coil, run down the curtain and joined the choir invisible.


 Dead Parrot

PS. My anger has now been thoroughly vented, I was caught up in my frustration to the blank responses from the Developer over the last few years. The last straw was the rejection of my final offer of assistance. When you can see everything going wrong and there is no way of averting disaster (having tried so often to help) and your final offer of aid is rejected, I think you can see why my pot boiled over.
I have created a series of desktop gauges using javascript, not quite multi-o/s but the same code for Windows and Mac o/s.


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

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

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

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

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

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


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


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

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

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

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

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

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


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

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

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

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


Once again a gauge designed for two separate javascript engines.

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


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


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

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


Low quality GIFs. Apologies.

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

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



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

Anyhow, that's the idea.

Panzer Weather Gauges

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

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

Fig 1. First cut.

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

Making good progress on the weather gauges:

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

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

Making progress with the gauges - slow but sure.

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

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

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

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

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

Day 4.

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

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

Day 5.

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

Fig. 6 Wind direction to the anemometer.

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

Day 6.

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

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

Fig. 7 Help image for the anemometer.

Fig. 8 Help image for the barometer.

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

Day 7.

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

Day 8 and 9.

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

Fig. 9 Help image for the thermometer.

Fig. 10 Help image for the humidity gauge.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


Recent changes include:

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

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

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


Fig. 19 New Weather Icon gauge showing the current weather.
This is the only download location at the moment (limited beta release):…
I say chaps, this Iron Harvest thing looks rather beastly. The narrator keeps using the word 'guys' which makes me think he is American but he turns out to be British. Rather rum chap.

Regardless, what he's babbling on about is some sort of a game where the German are still fighting after 1918? A rather rum do.  What's all that about?

An article on a code editor on DeviantArt? Well, a lot of art is done digitally these days. Some of it is animated and supported by code. The graphically animated portions of the web are defined using code and so it makes sense to use the best tools for the job. This article is about a particular tool that is new to the market and my search to find it.


I've been searching for an code editor that suits my needs for quite a long time now, years it would be. I had previously been directed down a route of professional editors and IDEs for scripting and coding and the experience of all these has made me value an environment that can be made to suit my needs. I've spent a lot of work and a lot of time trialling various editors on Windows, Linux, Unix or even VMS. My career has caused me to use a variety of tools to edit code starting off using EDT and TPU keypad editors on VMS to create complex DCL scripts, QEDIT to code in QB4.5, that awful but fun IDE that comes with Visual Basic for MSDOS, the competent and productive IDE for VB6. Then I migrated to Microsoft Frontpage for Web design and HTML (plus other HTML editors) finally reverting back to a thoroughly decent advanced editor with code support, called Context where I have been scripting ever since using javascript, PHP, HTML, XML, some C++ and latterly jscript/Vbscript.

 Various Editors/IDEs from the past
Fig 1. Various Editors/IDEs from the past

I love an IDE where all the tools required to build an application are provided from the graphical compositor to the code editor but I also realised early-on that a lightweight editor is a tool that I will always need and is often superior to an IDE for serious work.

My favoured editor for the last ten years has been the code editor 'Context', one of many advanced editors that have sprung up and the one I just happened to come across that immediately met my needs. It was quick to fire up, had no lags during operation, opens multiple files in tabs, it had language awareness, allowed key and colour customisation for language and the editor itself, the search utility was second to none, allowing searching through multiple files, it had an on-screen column ruler, allowed a search from the top of a document, search history and context retained across files, line number display, a single click on line number selecting a line, a pop-up search, full macro capabilities, project workspaces and file handling, text case handling, a file and search results window, auto-indent and file comparison and time-stamping, undo and redo history and much more. It was also freeware.

Written by a Delphi programmer, Eden Kirin, Context was a professional but lightweight tool and I was productive with it, soon it became my preferred editor of choice even when development of the editor stopped and the forum began to fill with spam. Despite this setback I carried on with the increasingly obsolete tool and grew to love it even more. I don't change editor easily, my choice of working environment is one that I am loathe to tinker with unless it brings real improvements in productivity. No Windows 10 GUI interfaces for me...

 Context Editor
Fig 2. Context Editor

I downloaded the source code for Context and researched using Lazarus and the Free Pascal compiler and migrating the code to the new environment so that I could build/support the editor myself there. However, I soon realised that the job was beyond me, a new IDE, a new language with a totally different programming approach to the scripting languages I am familiar with, and a totally new build environment with unknown issues and bugs. This was clearly not a viable solution for me so I carried on working with the unsupported Context editor. I soon realised that working with a dead and unsupported editor is an increasingly futile thing to do as time goes on. I would have to find an editor that was living.

My search for a decent editor replacement began again in earnest. I tried every freeware and commercial trialware Windows editor that would suit my mainly-scripting needs, from full-blown multi-language IDEs through dedicated language editors down to emulated keypad editors from my early scripting days. Each was downloaded and installed and used for a period of days or weeks. I won't list them all here as there were many (sublime text, notepad++, ultra edit, Kate &c &c), each was easily and quickly dismissed through lacking what I would consider to be any one of the basic functionalities as listed earlier. I finally determined to adopt an editor from an alien environment, that editor was the default editor for the KDE environment on Linux or Kubuntu, known as Kate.

 KDE's Kate Editor on Windows with graphical scrollbar
Fig 3. KDE's Kate Editor on Windows with graphical scrollbar.

Kate was in many ways a revolution for me, first of all being a non-Windows application running natively on Windows through some special trickery and as a result having a Linux approach to menus, options and development. It had some functionality that I had never seen before, the graphical scrollbar was one that astounded me, in addition Kate did so much more than my old editor. However, the search functionality was inadequate for an advanced code editor, some configurability was absent and the resistance to change from the developers led me to realise that Kate is just not yet ready for productive use on Windows. The main things that deterred me from using Kate were the lack of a pop-up search, preferring to bottom-load the search on the base of the editor window, poor search history and an inability to search multiple files and no ruler!. Search is the fundamental basis for code debugging and a poor search leads to poor productivity. So Kate was abandoned with reluctance and my search carried on, leaving me surprised that it was so hard to find an editor that matched my seemingly quite basic requirements.

I stopped looking for an editor entirely but then out of nowhere came RjTextEd. Not quite sure how I found it but as soon as I saw it, I downloaded it and gave it a try. It was immediately apparent that the editor matched all of my needs without a single mis-match, it was quick to run, quick to operate, had full documentation and was free to use. It was written in Delphi and matched my previous Context editor so closely in functionality that I initially felt it was modelled on that older editor. I may be completely wrong in this assumption but it matches it my requirements so closely that it feels it has almost been written specifically for me.

 RjTextEd Editor on Windows
Fig 4. RjTextEd Editor on Windows.

RjTextEd is not just a direct replacement for Context, it has turned out to be so much more than that. It provides so much more functionality and it feels as if it is the product that Context would have been, if development had continued over the last eight or so years. I cannot currently list the functionality that RjTextEd has as I am still researching and identifying what it provides. It seems to at least match what Kate provides and surpasses it in various important ways (columnar editing, tab indent implemented well). I have to say that I am incredibly impressed that this is the creation of just one man. The end result is a really impressive editor that even Microsoft would be proud of.

Why am I enthusing so much about what some would say is merely an editor? Well your favourite editor is like your favourite pair of old shoes, you don't want to change them as you don't go through the pain of wearing them in. You want to run and be productive, not hobbled by a slow pair of shoes. I tried IDEs from Microsoft that were slow to start, slow to run and were black in colour. Not my pair of running shoes.

I keep my old shoes just as I keep my old editors and even now I still sometimes use EDT+, a keypad editor for VMS (that now runs on Windows) - but not often.

RjTextEd has replaced Context as my daily editor of choice for the work I am doing at the moment, that is javascript and XML scripting. I use it in conjunction with Photoshop as my graphical compositor to create a working environment that matches a lot of what a dedicated language IDE could provide. I still retain Context as a replacement editor for simple file editing as it is really quick to start - but I am really only using it as a replacement for notepad on those few occasions when I open a text file, RjTextEd is overkill for that.

RjTextEd is my main development tool now. Thanks to Rickard for developing RjTextEd, I hope to push the editor to other developers and hope that its popularity will increase. I am convinced it will.

Charming, absolutely charming.
A thriving group that I have been a member of - for years now. The usual occurred, it stopped triaging submissions for a while. Then it suddenly resurfaced and for a brief time the admin was calling for submissions, three weeks later it has evaporated in a puff of condensed art.

All-Deviantarts-Art seems to be going the same way, 37,000 members but not triaging, folders all full and no new folders created for months, admins unobtainable. The group is dying, the impression of decline is undeniable. These daft admins, why don't they just let the reins go to the next person with some enthusiasm? There must be some out there? Just put a "For Sale" sign up on the group page and let the most dynamic group-member take the group over?

Feel free to add your thoughts on any groups you have been a member of that appear to be dying, have died.…
Just a word of warning regarding bottom cleanliness:

media player images

Courtesy of Viz Magazine
How to make a perfect Valentine gift...

for your loved one.…
I have two media players, one for Xwidgets and the other for the Yahoo Widget Engine (konfabulator). They are on my desktop all the time, even while I work, providing me with music all day. I use them by default as they allow me to reach several music folders immediately and select my current track whilst preparing my next - all through a thoroughly steampunk interface.

media player images

The Xwidget is the one with the BlackAdder font.

I am revamping the menus, improving the interface, adding support for full drag and drop, internal and external, ctrl/c+ ctrl/v, making the code much more efficient and adding access to an external player allowing video to be shown too. Both will handle industry standard playlist formats.

Not only this but it will work on Windows and Mac OS/X operating systems. It will also run under the two separate desktop widget engines on Windows.

My next aim is to create a medieval version of the same widget, iron, steel, gold and brass in differing proportions with a drop down play list on a cloth tapestry backing and revitalise my design for a dieselpunk volume widget.

Dieselpunk volume control trial image by yereverluvinuncleber

The following changes have been made to the Yahoo widget version and then I need to apply the same to the Xwidget.

o  physical switch for external video player
o  restored connection between the Macintosh external player volume state, the widget tracks it
o  remove the play video in remote player switch for Macintosh only
o  removed run command in background triggered by a double click
o  add a page number section on the playlist - makes the page number clearer
o  change all foreach loops to for loopsfor compatibility with Xwidget - abandoned as Xwidgets is crippled,
o      does not allow functions to be assigned to objects in code
o      does not allow an array to alias an existing object of the same name
o  allow the scrolling text to be turned off to save CPU as per xwidget  - done
o  move the glass playlist down a few pixels - done
o  remove javascript code from .kon file to .js - done
o  add confirm dialog on delete
o  playing videos in external player sometimes happens inadvertently - check logic
o  key fade bug seems to require a widget restart
o  key fade to be applied to new lower switch mounting
o  menus - sort them to sub-menus
o  automatic play and the autoplay lug, when it is switched off the automatic play should stop
o  add the clear playlist functionality via a physical switch
o  add some pipes/cables to the play list to connect the player
[Whole post redacted]

Yes it is dead - see this journal entry:…