Shop Mobile More Submit  Join Login
About Design & Interfaces / Professional yereverluvinuncleberMale/United Kingdom Groups :iconsteampunk-artists: Steampunk-Artists
Steampunk artists of deviantart:
Recent Activity
Deviant for 5 Years
Needs Core Membership
Statistics 759 Deviations 5,327 Comments 89,078 Pageviews
×

Newest Deviations

Atari ST Colonial Conquest Coconet USA Scenario by yereverluvinuncleber Atari ST Colonial Conquest Coconet USA Scenario :iconyereverluvinuncleber:yereverluvinuncleber 2 0 Steampunk media player Xwidget MKII RC by yereverluvinuncleber Steampunk media player Xwidget MKII RC :iconyereverluvinuncleber:yereverluvinuncleber 2 0 Steampunk CD in envelope by yereverluvinuncleber Steampunk CD in envelope :iconyereverluvinuncleber:yereverluvinuncleber 5 2 1930s Bicycle Lamp LED Restoration by yereverluvinuncleber 1930s Bicycle Lamp LED Restoration :iconyereverluvinuncleber:yereverluvinuncleber 1 2 1940s Policeman's lamp conversion to LED bike lamp by yereverluvinuncleber 1940s Policeman's lamp conversion to LED bike lamp :iconyereverluvinuncleber:yereverluvinuncleber 5 6 Airfix 1/32nd M3 Grant by yereverluvinuncleber Airfix 1/32nd M3 Grant :iconyereverluvinuncleber:yereverluvinuncleber 9 7 Music-folder by yereverluvinuncleber Music-folder :iconyereverluvinuncleber:yereverluvinuncleber 9 9 Steampunk MediaPlayer Ywidget 1.0.8 by yereverluvinuncleber Steampunk MediaPlayer Ywidget 1.0.8 :iconyereverluvinuncleber:yereverluvinuncleber 14 7 Steampunk 0 (zero) Open Envelope Icon by yereverluvinuncleber Steampunk 0 (zero) Open Envelope Icon :iconyereverluvinuncleber:yereverluvinuncleber 5 2 Steampunk Firefox 48 icon (XLVIII) by yereverluvinuncleber Steampunk Firefox 48 icon (XLVIII) :iconyereverluvinuncleber:yereverluvinuncleber 2 0 Ghostly Timekeeper 5.2.6 by yereverluvinuncleber Ghostly Timekeeper 5.2.6 :iconyereverluvinuncleber:yereverluvinuncleber 19 12 Ghostly Timekeeper Desktop by yereverluvinuncleber Ghostly Timekeeper Desktop :iconyereverluvinuncleber:yereverluvinuncleber 5 5 Steampunk XP desktop using widgets and rocketdock by yereverluvinuncleber Steampunk XP desktop using widgets and rocketdock :iconyereverluvinuncleber:yereverluvinuncleber 22 6 Steampunk Firefox 47 icon (XLVII) by yereverluvinuncleber Steampunk Firefox 47 icon (XLVII) :iconyereverluvinuncleber:yereverluvinuncleber 2 3 Steampunk Firefox 46 icon (XLVI) by yereverluvinuncleber Steampunk Firefox 46 icon (XLVI) :iconyereverluvinuncleber:yereverluvinuncleber 2 0 Steampunk Yahoo Widgets Icon by yereverluvinuncleber Steampunk Yahoo Widgets Icon :iconyereverluvinuncleber:yereverluvinuncleber 1 0

Favourites

Castle Sketch by stayinwonderland Castle Sketch :iconstayinwonderland:stayinwonderland 211 7 The Garage by AlexJJessup The Garage :iconalexjjessup:AlexJJessup 1,176 64 The Oberworc's ambition by wi-flip-ff The Oberworc's ambition :iconwi-flip-ff:wi-flip-ff 95 15 Robert De Niro Ballpoint Art by Rafik Emil H by rafikemil Robert De Niro Ballpoint Art by Rafik Emil H :iconrafikemil:rafikemil 2,270 584 Martian War Machine and House 2 by Lonesome--Crow Martian War Machine and House 2 :iconlonesome--crow:Lonesome--Crow 47 17 DeviantArt Steampunk Computer MK2, #1 by Wirecase DeviantArt Steampunk Computer MK2, #1 :iconwirecase:Wirecase 38 14 uge' friggen revolver by billking uge' friggen revolver :iconbillking:billking 15 5 Steampunk Spider in Glass Dome by CatherinetteRings Steampunk Spider in Glass Dome :iconcatherinetterings:CatherinetteRings 68 7 Le Paris (old sketch) by Radomski Le Paris (old sketch) :iconradomski:Radomski 44 3 Pink Paradise by stengchen Pink Paradise :iconstengchen:stengchen 122 21 Cheshire Cat by creaturesfromel Cheshire Cat :iconcreaturesfromel:creaturesfromel 14,928 720 Tortoise of Burden by creaturesfromel Tortoise of Burden :iconcreaturesfromel:creaturesfromel 5,679 174 A Mechanism of Character by creaturesfromel A Mechanism of Character :iconcreaturesfromel:creaturesfromel 1,551 50 Angler by creaturesfromel Angler :iconcreaturesfromel:creaturesfromel 630 22 Raccoon by creaturesfromel Raccoon :iconcreaturesfromel:creaturesfromel 658 11 Apothecary by AtriellMe Apothecary :iconatriellme:AtriellMe 47 17

Groups

deviantID

yereverluvinuncleber's Profile Picture
yereverluvinuncleber

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

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

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

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

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

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

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

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

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

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

This is my site where the widgets be...
Interests

Activity


Part VI of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part V which can be found here:

Guide to converting Yahoo Widgets to Xwidget Pt5Part V of the guide to converting a Yahoo widget to a Xwidget, this guide follow on from Part IV which can be found here:


Tooltips and Hints
Tooltips used to be supported in earlier versions of the Xwidget engine but Tony the developer, during the original development of xwidget 1.0 changed the tooltips to hints. Hints are massive bubble pop-ups that display the tooltip text in a large-ish font whereas tooltips are small discreet boxes using small fonts. The Yahoo widget engine only uses normal tooltips and as these sort of tooltips are not supported in the current version of the Xwidget engine,you cannot replicate this functionality.
The large hints can really get in the way and they are styled in such a way that the result is quite jarring. Hints also pop up immediately whereas tooltips tend to only pop up a few seconds after the mouse has hovered over an object. Tooltips are much nicer overall. If you are going to implement hints then I would


Preferences

The Yahoo widget engine has one particular advantage over the xwidget engine in that it provides a ready made structure for configuring user preferences. A right click on any widget gives you the menu preferences option that opens to display a number of panes where user-defined preferences can be stored and configured.

[ A typical preference window ]

media player - config pref

Each preference pane is created by simply adding a group definition to the preferences XML in the .KON file.

Code:
    <prefGroup name="general" order="1" icon="Resources/general-icon.png" title="Sounds"/>

Each preference field, checkbox, slider, text and drop down can be created by adding a single line in XML that describes the user preference. The configuration data it represents is stored in the system registry or locally in a configuration file. These configuration variables are saved and reused when the widget restarts. Those pretty icons at the top were provided by me and they add a touch of individuality to the widget's preference panes.

Code:
    <preference description="This widget makes additional sounds by default - you can enable or disable these sounds as you require." defaultValue="enabled" name="soundpref" title="Sound Control:" group="general" type="popup">
        <option>enabled</option>
        <optionValue>enabled</optionValue>
        <option>disabled</option>
        <optionValue>disable</optionValue>
    </preference>

Due to this intrinsic functionality Yahoo widget users expect to be able to configure everything and anything. Their widgets are controllable and configurable down to the smallest option. My media player widget has the following configuration panes: sounds, fonts, commands, configuration and folders.

[ The Yahoo widget media player preference panes x 5]

Ywidget prefs example

Xwidget does not have a default preferences function and no built-in method of storing configuration information. To replicate this functionality we have to build our own preference structures to store the data, display it in a useful fashion and allow easy modification just as a Yahoo widget preference panel does. This is not as easy as it sounds, as it means creating three or four additional programs complete with graphics dependant upon the number of panes the widget has.

So, how do we do this? Here is an example of a replicated preference pane that I have created for one of my other Xwidgets, the steampunk volume control. It is copied directly from a yahoo widget version in both form and functionality.

[ A typical preference pane from the xwidget volume control ]
Xwidget IDE prefs example

The colours have been inherited from a XP theme that I was running at the time I created the volume Xwidget. It is just steampunk enough whilst retaining some familiar windows features, so it is both familiar to Windows users and in keeping with the widget. You will have to create your own preference pane background and the graphical elements upon it using Xwidget buttons &c. I prefer to use my own as you can see from the above image...

I took a screenshot using ALT+prtscr and then massaged the image with photoshop. The pane itself is blank and all the controls are xwidget controls or image objects.

[ The xwidget preference panes after conversion ]

xwidget-multiple-prefs

For the media player widget that has five preference panes, replicating each of these panes may seem like overkill but for the process in hand, which is the conversion of a media player Yahoo Widget to an Xwidget, it must be done. Whether you choose to do so yourself when converting your widget is up to you.

Convert all preferences to equivalent text field variables

First step is to convert each preference value in the .KON file to an Xwidget text field and then use that instead to store the configuration data.

To do this create a separate layer called "showWidgetPreferences" - this will be the layer where we store the objects that will emulate the preferences screen - We drop in a suitable image background as shown above and then we drop a few editable text areas onto the layer. Name each with similar names to your old Konfabulator preferences:

eg. you may have a preference named SoundPref that is accessed using the preferences.SoundPref.value property, so you would create an equivalent text field called preferencesSoundPref and you would access the data via preferencesSoundPref.text. This means that the text conversion within your script is fairly easy, simply removing one full stop and changing .value to .text.

Code:
size = preferences.sizePref.value;

Code:
size = preferencesSizePref.text;

Then you can use the text values in the same way that you previously used the yahoo widget engine's built-in prefs.

In addition to these user-configurable data fields there will be hidden data fields that are not visible to the widget user but which are used to store configuration data. Each one of these data fields should be replicated as text data fields but stored within a hidden layer named "hiddenprefs". These hidden prefs do not need a graphical layer upon which to be displayed as they are not displayed at all. These data fields are easy to create, they just need to be named according to the naming convention specified above, a few changes to the code will be required to ensure the code refers to the new hidden text fields.

H. All of the preference text fields have to be defined in the GUI as text fields, not visible

[ A blank Xwidget control preference pane and one after placing the controls ]
xwidget-multiple-prefs01 

In addition to having a set of good looking preference panes you'll need to do some extra work in order to make all those configuration options work... All those buttons and sliders need to be given actions that change the values of the data in the configuration fields. You'll need to validate the entries on some of the fields and give each descriptive text. When you run the Xwidget and the Ywidget versions you'll see how close the two widgets match each other. All this configuration 'stuff' is extra overhead that needs to be taken into account if you are going to properly convert a Yahoo widget.

One of the things that you will need to is to save all these configuration preferences and re-open the preference configuration at loading time..

E. Add a SavePrefs function to emulate the creation of preference values and the writing of them from an ini file:

Code:
function SavePrefs()
{
    Setinivalue(widgetpath+"prefs.ini","prefs","preferencessizePrefvalue",preferencessizePrefvalue.percent);
    Setinivalue(widgetpath+"prefs.ini","prefs","preferencesLicenceHideValue",preferencesLicenceHideValue.text);
}

Your prefs.ini file will have something like the following inside it:

[prefs]
preferencessizePrefvalue=30
preferencesLicenceHideValue=1

F. Add a getPrefs function to emulate the creation of preference values and the writing of them from an ini file

Code:
function getPrefs(){
    preferencessizePrefvalue.percent =     Getinivalue(widgetpath+"prefs.ini","prefs","preferencessizePrefvalue",100);
    preferencesLicenceHideValue.text =     Getinivalue(widgetpath+"prefs.ini","prefs","preferencesLicenceHideValue",0);
}

When you have the defined and set the preferences you can then use them:

Code:
    if (preferencessoundprefvalue.text === "enabled") {
        soundbutton.src="bellpushed.png";         // this in place of a checkbutton which I could not get to work correctly
    } else {
        soundbutton.src="bell.png";
    }

Basically, each preference pane is a mini-widget in itself existing within its own layer, you will have to build each preference pane and add controls just as you would with any widget. The only functional difference between the yahoo widget preference pane and the one we have just created is that the xwidget pane cannot be moved independently.

Absence of some fundamental controls

The main problem you will encounter when converting a preference pane is that the xwidget engine provides no methods to easily select data. If you look at the components pane in the xwidget IDE in design mode you will notice that some of the standard controls are absent. Essential components are missing such as a drop down selection box. I still find it to hard to believe that an IDE for a high level language language can operate without such fundamental controls. I have never used a language/engine/IDE without a drop-down control.

[ yahoo widget showing a font drop down ]
font dialog

Without a dropdown control it is very difficult to create drop-down selection boxes to select items such as fonts. I would have to use the activeX filesystemObject to read the contents of the system fonts folder then manipulate that data to display those fonts in a hand-made DIY drop down. Creating this sort of functionality is beyond the scope of this conversion as it would require the creation of a complex function, a program in itself and that would take a lot more time than I have available. I may try to create it later and will post it here if I manage the task.  (OK I did it! The code for the above functionality is available here: bbs.xwidget.com/viewtopic.php?…)

The following code shows the Yahoo widget method of creating a drop down in XML.

Code:
<preference hidden="false" description="Enter the name of any of your installed fonts" name="popupPanelFont" group="fontGrp" title="Pop-up Font:" defaultValue="Courier New" type="font"/>

In the Xwidget I had to do a lot more than the above simple XML. As the first workaround I created a text box that contains the font name in simple text form. When the user changes the font name manually in the edit box, a button is available that will test for the existence of the font. If it is valid, it sets the font accordingly and displays it in the same text field.

As well as this, I attempted but failed to recreate the functionality of the Yahoo widget engine font drop down using just javascript to extract a list of font filenames from the system fonts folder and then present these to the user in a scrollable text list. However, knowing the font filename in Windows is not enough. You cannot set a font using only the filename. You have to know the actual font name and that unfortunately cannot necessarily be extrapolated from the file name nor the file contents.

The final solution was to use ActiveX to extract the list of fonts from the registry. This function is now called at startup.

Code:
function ShowFontList(){
    if (debugFlg == 1) {print ("%-I-INFO, ShowFontList")};
// Get an instance of the StdRegProv class...
var objService = GetObject("winmgmts:{impersonationLevel=impersonate}!\\\\.\\root\\default");
var objReg = objService.Get("StdRegProv");

// Prepare the EnumKey method...
var objMethod = objReg.Methods_.Item("EnumValues");
var objParamsIn = objMethod.InParameters.SpawnInstance_();
objParamsIn.hDefKey = HKLM;
objParamsIn.sSubKeyName = "SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Fonts\\";

// Execute the method and collect the output...
var objParamsOut = objReg.ExecMethod_(objMethod.Name, objParamsIn);

// If successful, iterate the subkeys...
if (objParamsOut.ReturnValue === 0) {
    if (objParamsOut.sNames != null) {
        fontArray = objParamsOut.sNames.toArray();
        for (var i = 0; i < fontArray.length; ++i) {
            fontArray[i] = trim(fontArray[i].substring(0,fontArray[i].lastIndexOf("(TrueType)")));
            print(fontArray[i]);
        }
    }
}
}

Now that the list of fonts is populated it can be manipulated. A mouse scroll event attached to an edit box allows the font to be displayed by scrolling the mousewheel up and down.

[ The Xwidget font selection from the new code ]

font selection

Code:
function preferencesPopupPanelFontOnMouseWheelUp(Sender)
{
       currentFontPos = currentFontPos - 1;
       if (currentFontPos <=0 ) {currentFontPos = 0};
       if (fontArray[currentFontPos] != null) {
          preferencesPopupPanelFont.text = fontArray[currentFontPos];
       }
}

The edit field is the location for this particular preference option so when the font is selected it will set it as the default font for the playlist.

-oOo-

Dragging and dropping files

The Xwidget has some fundamental differences to the Yahoo widget engine when dragging and dropping files onto a object. First of all, the Xwidget object needs to be enabled to allow it to accept a file drop. This performed in the Xwidget IDE in the object's main properties section under 'others'. This will modify the main.xul file with the following:

Code:
acceptFileDragDrop="true"

The next step is to define the function that will be called when the object event is called. Double clicking on the empty event box will provide a default function for the event or entering a function name manually in the onDragDrop field will trigger our chosen function.

When a group of files or a folder is dropped onto an object in the yahoo widget engine a system event that occurs which can be interrogated for information. The data itself arrives in the system.event.data construct.

In this case I require to know the number of files that had been dragged. Reason for this is that the yahoo widget engine has a problem handling very large numbers of files so that knowing that the amount of files dragged/dropped is below this upper file limit  - is essential. In the case of the YWE I simply would have used the length property to determine the number of dragged files:

Code:
playListfileCount = system.event.data.length; //Yahoo widget code

//only read less than 10,000 individual files
if (playListfileCount >= fileCountLimit ) {
    alert('In this drag/drop operation there are more than "' + fileCountLimit + '" files. Please select a much smaller amount!');
    return;
} else {
  dropData =  system.event.data  // read in the data only if the filecount is acceptable
}

However, this system.event functionality does not exist in Xwidgets but we do have the data so instead we have to count it manually. We have to read in all the data and calculate the length of the data after it has been read. Not the best method but that is what we must do.As we already know, all Xwidget file operations seem to result in bar-delineated strings whereas all yahoo widget operations result in arrays. The Yahoo widget code will expect an array so we must first convert the returned string into an array.

Note: the incoming data comes through the construct 'Data'.

Code:
    // convert the filelist into an array - Xwidget code
    dropData = Data.split('|');
    playListfileCount = dropData.length;  //instead of system.event.data.length

    //report less than 10,000 individual files
    if (playListfileCount >= fileCountLimit ) {
       alert('In this drag/drop operation there are more than "' + fileCountLimit + '" files. Please select a much smaller amount!');
    return;
    }

Once the data has been read into an array, the string handling is more or less the same.

-oOo-

Colours

In the Xwidget engine Certain objects seem to have problems in setting colours using code. The yahoo widget methods are documented so you can look up the method required to change styling and apply it, it just works.

Code:
playListPage.style.backgroundColor = "rgba(255,255,255,0.06)";

However, in the Xwidget engine there is no documentation and you cannot trust the inline suggestion system (intellibollox) so you need to have a look inside the main.xul file and see how it does things, from this you will receive a pointer as how it should be done in code... It won't always be correct but it may help.

For example:

Changing the background of a graphical object is performed using the IDE by selecting the "fill color" properties tab. Choosing and enabling the background colour is acheived by pressing on the enabled button and selecting color from the pop-up dialog. Easy enough.

[ picture here of IDE and colour selection ]

xwidget-colour selection

When the widget is saved this results in the following XML code being written to the main.xul file.

Code:
<text name="playListText0" background.solidColor.enabled="true" background.solidColor.color="128,128,128,255" />

This is the functional equivalent of the following in code, where we can set the same object properties using:

Code:
playListText0.background.solidColor.enabled="true";
playListText0.background.solidColor.color="128,128,128,255"; //this does not function

Unfortunately, even though the code is functionally valid, the second command is not recognised by the Widget engine and an error is thrown regarding converting a string to an integer.

The intellibollox suggestion system is utterly useless when it comes to helping you determine the right method to colour a background but it seems to imply that the following code is more or less correct:

Code:
playListText0.background.solidColor="rgba(255,255,255,0.06)";
playListText0.background.solidColor="rgb(255,255,255)";

Although no error is generated, neither of these lines performs any useful function. I suggest that the widget engine has a bug in the configuration of background colours, it recognises the object's properties and makes an attempt to process a string containing RGB information but it does nothing with it.

There may well be other methods as suggested by the intellibollox, including colorize. I have tried various methods and combinations but the logical and obvious solutions do not work. With no documentation and no examples it is harder work to find a solution.

The end result is that it is not possible to style an Xwidget background colours using this method, ie. in code, styling the background colours in the IDE and switching them on and off again at will seems to be the only way, cumbersome and annoying though it may be.

This bug/limitation initially resulted in a change to the functionality in the Xwidget version of the media player when compared to the original Yahoo widget version. In the yahoo widget when a media track was clicked upon it was highlighted using a semi-opaque background. The Xwidget version cannot set a semi-opaque background using code alone. You can only define a pre-determined colour in the IDE at design time but you cannot change it at runtime.

In the end, the two widgets were made to operate in the same manner but using different methods. I now set the different selection colours using multiple layers that can be switched on and off as required, one for the underlying background, another for highlighting a selected track and then a final one for the track currently playing - it works but as I said, this is cumbersome, inelegant and just a bit rubbish.

Note: I can confirm that the Xwidget is bug-ridden when it comes to handling colours.

Code:
playListText0.font.fill.color="245,15,20,255" ;

Setting certain values in code causes the font colour to change but not to colour that matches what is set in the IDE nor what should be expected from a valid RGB selection. Setting other perfectly valid values causes a generic error that the engine cannot convert from a string to an integer. Fundamentally, setting colours in code is broken in Xwidget.

-oOo-

Configuration Errors

The Xwidget engine as delivered can place widgets on your screen that when dragged, are done so only in jerky, halting movements. This is due to the widget's magnetic border property being set. When you turn it off your widget movements are much smoother. Once set this configuration should be written within the engine's config.ini so that the following line should appear within:

Code:
    widget.MagneticBorders=0;

Unfortunately, the config file is completely ignored at startup. This is a known bug. To resolve that issue I have the above same line hard-coded in all my widgets during the widget.onLoad function.

-oOo-

Confirmation Dialogs

All confirmation dialogs statements need to be changed from alert to confirm functions. The yahoo engine alert boxes allow customisable button texts but the Xwidget only allows the basic OK or Cancel buttons:

Code:
    var answer = alert("This button opens a browser window and connects to the help page for this widget. Do you wish to proceed?", "Open Browser Window", "No Thanks");
    if (answer === 1) {
        openURL("lightquick.co.uk/instructions-…");
    }

Code:
          if (confirm2("This button opens a browser window and connects to the help page for this widget. Do you wish to proceed?"))
          {
              OpenURL("lightquick.co.uk/instructions-…");
          }

[ The two different alert boxes from the two engines ]
xwidget-alerts

-oOo-

About image

In just about every yahoo widget I have encountered there is a graphical 'about' pane, a simple (or complicated) about image that is called from the right click menu. The Yahoo widget 'About' menu option is always situated at the top of the menu options. These about images are easy to create, you simply create an image in photoshop or GIMP and then tell the .KON file to call that image in XML. The following example code does that and a bit more.

Code:
    <about-box>
    <image>Resources/mediaAboutYwidget.png</image>
    <about-version font="times" color="#000000" vOffset="59" hOffset="120" size="12">
    <shadow color="#ffffff" vOffset="1" hOffset="1"/>
    </about-version>
    <about-text font="times" color="#000000" vOffset="59" hOffset="70" url="www.lightquick.co.uk" data="Version " size="13">
    <shadow color="#ffffff" vOffset="1" hOffset="1"/>
    </about-text>
    <about-text font="times" color="#000000" vOffset="220" hOffset="25" url="lightquick.co.uk/instructions-…" data="       " size="90">
    <shadow color="#ffffff" vOffset="1" hOffset="1"/>
    </about-text>
    </about-box>  

The above code shows the following image, shows the current version number, adds a couple of textual links without text that correspond to particular parts of the about image so that when you click on parts of the image you will be taken to an appropriate web page.

[ picture here of one of my typical about boxes ]

about us image

The Xwidget has a much more conventional and boring about box that is the same for each and every widget. It is accessible via an About menu option situated at the bottom of all your menu options.

[ a typical Xwidget about box ]
about us image

As this is a conversion we will implement an about box that corresponds with the yahoo widget equivalent. Create a hidden layer and place all the about components within that layer. That will comprise an 'about' image, some links and an event or two. I then create a menu item that duplicates a menu item styled from the yahoo widget. When the menu item is selected the about image is displayed and when the 'about' image is clicked upon it fades away using the fadeto command on the whole layer.

Code:
    <menu>
    <item name="menuitem9" caption="About Steampunk Media Player" onClick="menuitem9OnClick"/>

The above is the menu item as described in the main.xul file. You don't have to go anywhere near the main.xul file, just create the menu option in the designer and create a menu option that calls the default function.

//==============================
// this function opens the about us image
//==============================
function menuitem9OnClick() {
         //print("here!");
         windowPos = widget.WindowZPosition;
         aboutUs.visible = true;
         widget.WindowZPosition=1;
}
//=====================
//End function
//=====================

The above code addresses a small issue where the about layer might be positioned below the main widget after an inadvertent click. Setting the window position sorts this.

None of this extra functionality has any effect on the Xwidget default about box which is discretely hidden away at the bottom - no-one ever clicks on it...

Menus
 
The Yahoo widget engine supports two types of menu items. The first are items on the standard right-click menu that add to the engine's default menu options.

[ Image of a typical right click Yahoo widget menu ]

menu yahoo

The majority of these menu items have been added by my code.

The second type are context menus that can be attached to individual image objects on the widget itself. This means that different menus can be assigned to different parts of your widget.

[ Image of a typical right context related menu ]
menu context

The above image shows a context menu on another widget, my CPU/GPU thermometer widget.

As these type of context-type menus cannot be re-created using in-built functionality from Xwidget, to replicate this functionality you will need to create your own menu structures or simply create hidden graphical objects that look like menus which are only made visible as and when required.

[ Image of a manually created context menu in Xwidget ]

menu xwidget

In the current widget we are converting ie. the media player, it does not use context menus attached to any object. That is good for us as this time we don't actually have to re-create this functionality.

So that leaves us with just migrating the main menu.

The standard menu in the YWE can be created in two ways, within the .KON file or in .js script. The following is an example of how it is done in script:

Code:
function setmenu() {
    mainWindow.onContextMenu = function () {
        var items = [], mItem;
        mItem = new MenuItem();
        mItem.title = "Online Help";
        mItem.onSelect = function () {
            menuitem1OnClick();
        };
    items.push(mItem);
}

Xwidget does not seem to be able to create a menu item in code so if your Yahoo widget creates its menus in code then simply remove that code and transfer it to the menu creation portion of Xwidget's IDE. My code creation functionality resides in .js and within the setmenu function and as a result it is redundant now.

Code:
<menuItem name="menuitem1" title="Online Help" enabled="true" onSelect="menuitem1OnClick();"/>

O. Copy the menu code from main.xul :

    <menu>
        <item name="menuitem1" caption="Online Help" onClick="menuitem1OnClick"/>
    </menu>

P. Check the function assignments on each menu item to be sure they exist and function correctly.

[ Image of a Xwidget right click menu on one of my converted widgets ]
menu context

-oOo-

Processor Overhead

We are getting to the end now so we can divert away from the subject of conversion for a short while. One difference between the two engines that you can't code for is that all Xwidgets run under one process, whereas yahoo widgets each run in their own process. The Xwidget approach leads to less resources being consumed as all widgets are running from the same set of base functionality and data structures. The Yahoo widget may not be as resource-frugal having to duplicate all the widget structures within each and every widget. Having said that though, in my comparison of two identical widgets I find that the Yahoo widget engine version is much more efficient. Xwidget's home-grown text scrolling and the transfer of the onKeyDown event to the isKeyDown/timer method seems to use up a lot more cpu. The yahoo widget uses more efficient background methods for providing scrolling text and the key event capture works!  The yahoo widget as a result uses almost zero cpu whereas the Xwidget version will use up to 20% of a 2.5ghz core2duo when playing a media track. Due to this one fact I will have to add an extra option to turn off the trackname horizontal scrolling to reduce CPU usage on the Xwidget version. That should reduce the usage to 5% if we are lucky.

Xwidget has plenty of animation options but these animations are serious cpu users. When you create something like a gauge, you have the option of adding some lovely needle easing in/out effects that make the gauge come alive - however on a CPU gauge your widget may use 10-15% of the CPU while just showing you that the gauge itself is using the CPU. Just because these advanced feature are available to the Xwidget IDE does not mean it is sensible to use them especially when Xwidget is mainly used as a system metering product - the upshot is - use these special effects at your peril!

As all the Xwidgets run within the context of the same process, high cpu usage in one widget can cause a drastic slow-down in another. When the o/s dynamically lowers the priority of the xwidget process ( A normal thing to do in a time-sharing system), all the widgets will appear to pause/hang for a period until the CPU contention is resolved in the Xwidget process's favour.

Due to the architecture and the way each yahoo widget runs in its own process, the yahoo widget engine is much more stable and if a widget ever does crash, it doesn't take all the other widgets with it. If a widget consumes too much cpu, other widgets will only be affected in the way that all processes will be affected, they won't instantly freeze or appear to hang.

 If you have a powerful and modern PC with a decent processor and plenty of memory (most do these days) the amount of resources that these widgets consume is really quite trivial on a modern quad core 3+ghz system. The system I am using now is an old core2duo, 2.5ghz machine and the load of running the xwidget and yahoo widget engines simultaneously with 20 or so widgets is low if not negligible.

I find the stability of the Xwidget engine is questionable, especially when developing a new widget and running multiple other xwidgets simultaneously. When running highly animated gauges, the dock can become paralysed and sometimes your widgets refuse to initialise. Killing Xwidgets altogether seems to be the only solution. It is actually useful having a Yahoo widget that is designed (perhaps a big kill switch) to actually kill and restart Xwidgets and vice versa!

**************************************************************
The widget itself, the one I am working on now can be downloaded and trialled.
you'll find it here:

Steampunk media player Xwidget MKII RC by yereverluvinuncleber

Be aware that this widget is only 80-90% complete but the mere fact that it exists demonstrates that direct conversion from a complex Yahoo widget to an Xwidget is possible. By all means download it, run it and report any bugs here on DeviantArt.
**************************************************************
-oOo-

Conclusion

You may detect a strong feeling of bias against the Xwidget engine and its capabilities in what I have written here. Let me tell you now that it is NOT a bias. The Xwidget engine is a real technical tour-de-force for one man to have achieved, it is an impressive achievement. He has created two widget engines (Windows and Android) all by himself, attempted to create two IDEs for the different platforms and by sheer force of will keeps a complicated infrastructure together (site, forum, gallery, weather feed &c).

However, some of the implementation is shoddy, very incomplete and badly thought-out. Not of all it though. At the core of it all is the very sound and very stable jscript engine from Microsoft and that in itself makes it a suitable choice for javascript development. The fact that using javascript it can put an object on your desktop, a graphical object of any shape and size, animate it and give it logic and life - is enough to make it useful and justify its own existence. I say well done to Tony for creating Xwidget.

On the negative side, to have so comprehensively ignored the yahoo widget engine, to have re-implemented what it does already without retaining full compatibility, failing to improve on what it already does, failing to use the yahoo widget engine as a template for Xwidget design, (reimplementing the wheel, but making it a different shape!). If Tony had followed the Yahoo widget engine's standards and methods then all the documentation for that engine would have applied equally to Xwidget. No new documentation would have had to have been written for Xwidget but we are now left with zero documentation and we simply have to guess how a function works.

The Yahoo widget engine is so comprehensively well-implemented, so well-documented and the functionality it provides is always equal but more often it is superior to the Xwidget offering. Using Xwidget after the slick yahoo widget engine can be a frustration as it feels so shoddy... The only real advantage Xwidget offers is that IDE.

I have picked up and dropped Xwidget multiple times only to pick it up again, this time with the idea that it really is usable, as long as you do not depend too hard upon the extra functionality Tony has given you. Think of it as a usable desktop engine for jscript and activeX that happens to have a usable graphic designer, a runtime engine and an adequate program debugger. Lack of documentation can be overcome by using jscript documentation from the web and writing your own. Most useful though will be the disassembling of other developer's widgets to see how they achieve the fucntionality they provide. In reality though, falling back upon your own basic javascript skills is the real method you will need to get you through.

[ The Yahoo widget (right) and the Xwidget side by side ]

the two side by side

This conversion proves that it is entirely feasible to convert even the most complicated yahoo widget to the xwidget engine, you will have to decide whether it is sensible or not to do so. In my opinion the Yahoo widget engine is still the better solution, OK, it doesn't have an IDE but it uses photoshop instead, it is fully documented, everything works as expected, the implementation of the desktop and file system APIs are complete, the API interface is consistent and the few bugs that exist are related to cross-platform capability. The only real advantages that Xwidget has, are the IDE and the fact that it has not been officially abandoned by its developer, in addition it is accessible and potentially usable by a lot more end users that like the simple initial method of creating Xwidgets.

The work to convert a widget is not inconsiderable - this conversion took me a long time as I had to find solutions for all the incompatibilities and then I had to write this guide. If your source widget is simple (and you won't have a guide to write) then hopefully it won't take as long as mine.

The final two screenshots show my Linx 32 Windows tablet and my Windows desktop. These are all Yahoo widgets but six of them now have been converted to run on the Xwidget platform. Only six have been done because of the complexity of my widgets, the time it takes converting each  needs to be balanced by the need. All my Yahoo widgets run perfectly on Windows and in truth there is little need to convert them while they all still work perfectly. Regardless, you are welcome to convert any one of them you wish!

[ My Yahoo widgets on a Linx32 7" tablet ]


The above image shows my thermionic valve clock, weather widget, steampunk clock/calendar, email and planetary widgets and the widget vault.

[ My Yahoo widgets on my core2duo 2.5ghz Windows desktop ]



Now that's a busy desktop. It all works. Good luck converting!

In return for providing this conversion document, can I ask a couple of small favours?  Firstly, can you please leave a comment if you have found this informative or useful in any way. Secondly, if you have used any of the advice in a widget you are converting/creating then do let me know!


END OF DOCUMENT













What follows are come notes that will form the rest of the document as the notes pad out.



-oOo-

Controls

Checkboxes and buttons do not have default images but have to be assigned a user-created image in order to appear. I was initially surprised by this assuming that Xwidgets would provide a default set of checkbox images just as other engines do. The way Xwidget does it, gives flexibility but it is still a little surprising.



-oOo-

Commands

The ywidget engine has a runcommandinbg() command that allows the widget to create a detached process and then carry out a command line function without waiting for the command to complete. This means you can instruct the widget to carrry out any command line function without worrying about the result, the widget will not be adversely affected.

The Xwidget does not have this distinction and instead you just have run() command. You will have and replace each occurrence of runcommandinbg with the run command.

The run command will not operate with the same commands as the Ywidget, for example to initiate the time and date panel you simply add control  to the existing command

eg. control timedate.cpl instead of timedate.cpl

-oOo-

Closing ActiveX objects

  Obj = null;
  CollectGarbage();
  activexControl.Dispose();

-oOo-
Incompatibilities in .indexOf function and the handling of arrays

test xtn
test indexOf

Code:
if (validTypes.indexOf(xtn(path)) >= 0 ) {  // Ywidget
                PlayFile(dropData[0]);
                updatePlayList();
             } else {
               alert('"' + dropData[0] + '" is not a file the media player can use.');
             }
            
Code:
if (validate_filetype(dropData[0]) === true ) {  // Xwidget
                PlayFile(dropData[0]);
                updatePlayList();
             } else {
               alert('"' + dropData[0] + '" is not a file the media player can use.');
             }

function validate_filetype(fileName)
{
    var allowed_extensions = validTypes;
    var file_extension = fileName.split('.').pop(); // split function will split the filename by dot(.), and pop function will pop the last element from the array which will give you the extension as well. If there will be no extension then it will return the filename.
    print("file_extension "+ file_extension);
    for(var i = 0; i < allowed_extensions.length; i++)
    {
        print("allowed_extensions[i] "+ allowed_extensions[i]);
        if(allowed_extensions[i]==file_extension)
        {
            print("return true");
            return true; // valid file extension
        }
    }
                print("return false");
    return false;
}




Q. Remove the code within the YWidget makeimage function as you cannot (?) create NEW image( ) items within code

-oOo-

R. Remove the code within the YWidget FRM function as you cannot create new FRM ( ) forms within code

-oOo-

]]  Braindump ends
Steampunk media player Xwidget MKII RC

New version updated - please try it. Still debugging and posting new versions regularly, so if it does not work for you worry not - it will.

// fixing a bug about playing non-supported codecs now

// fixed a bug preventing the autoplay selection from working
// fixed a bug with next/previous play not working after a restart with autoplay disabled

I still have a bit more to do but it should work better now.

-oOo-

This is version 2.0.0 RC of the Steampunk Media Player XWidget - updated, allows dragging and dropping onto an existing playlist. This now adds to the playlist instead of replacing it.

// tooltips for all items
// checks for valid folder before playing
// when saving a playlist, checks it is an XML file.
// default music folder should be C:\Users\Public\Music
// selecting a CD from the folder menu works from the menu too.
// unknown file types such as .flv - if Windows will not play the filetype then pop up an error message.

// allows dragging and dropping onto an existing playlist.
// utilises the fonts read from the registry.
// all prefs save successfully
// all prefs opened successfully
// play list text highlighted correctly
// loads of smaller bugfixes.
// refresh after shuffle
// fixed the lack of keypress capture
// drag drop onto the playlist areas
// drag drop onto the pipes
// "Page No." needs a background to be readable
//  .MPG  capitalised suffixes handled
// write a .xml playlist
// dragging three files to the playlist, it excludes the last file
// bug when selecting the beyond the first chunk not found
// all the prefs need to be read when the widget is opened
// xml write/read bug with path  e:\music not setting correctly
// font issue resolved - now reads the fonts from the registry
// preference screens added

** You may download this version to run and us on your desktop **

WARNING: The conversion is 99% complete and it is now a working Xwidget. It should be largely bug-fixed now, the playlist functionality works and I intend to add some final new functionality later. It works for now, it does the job. It is steampunk and it plays your music! Please test it. Give me feedback on anything that breaks.

This is the conversion that you can see being undertaken here in this guide:

yereverluvinuncleber.deviantar…

NOTE: To make it look like the playlist above, you'll need the Centurion light SF font that you can get here: at Ufonts.

The following tasks are yet to complete in this version:

// test bad file types that will not play in Windows media player
// revisit the countDirContents to test the filecount and why it is different
// playlist - delete tracks

This is a Steampunk media player xwidget based on my original Yahoo Konfabulator Steampunk XWidget. A widget that will play your music but  take up only a tiny amount of your desktop. It is a lovely piece of eye-candy as well as being useful on your desktop.

Be aware that this widget is still in beta and there is a possibility that some small functions may not all work. Please report any errors back to me.

-oOo-

You can control the volume level of the media player by moving the slider or pause/play the track by clicking on the play button. Next and Previous buttons will select the next track to play. You may open a file, group of files or a folder for playing. It will play all media types that Windows media player supports. You can download codecs that will allow it to play any audio type.

The Steampunk Media Player XWidget is a moveable widget that you can move anywhere around the desktop as you require. The widget is usable on all versions of Windows.

It has been tested on Windows 7 Ultimate 64 bit and Windows 10 but it should work on all versions with no problems whatsoever.

You will,  of course, need the Xwidget engine for this widget to run. Link here www.xwidget.com/

All javascript widgets need an engine to function, in this case the widget uses the XWidget engine that supports jscript. The engine interprets the javascript and creates the widget according to the XML description and using the images you provide.

If you prefer an identical Yahoo widget then get it here: yereverluvinuncleber.deviantar…

You may use any of my own images in your own creations but commercially only with my permission. In all other non-commercial cases I require a credit to the original artists using their/my name or pseudonym and a link to their/my sites. With regard to the commercial use of incorporated images from other artists, permission would need to be obtained from the original owner.
Loading...
Part IV of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part III which can be found here:

Guide to converting Yahoo Widgets to Xwidget Pt3Part III of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part II which can be found here:


So, let's start.
We start by doing some simple bulk copy and pastes. First of all we change the object positioning. In Context editor with the Xwidget IDE shut down, we type Ctrl+R which displays the search and replace dialog.
[ The advanced search and replace dialog in the Context editor ]
In comparison with the Xwidget code kludger we have a lot more functionality. First of all we have search history, it remembers all your previous searches. Then we have advanced search options, allowing us to search for whole words, case sensitive text from the current cursor position or from the top of the program. Using the Xwidget IDE is like bashing your head against against a marble fireplace - it is so nice when you stop.
We need to change each occurrence as below:
1. Change all .voffset to .top
2. Change all .hoffset to .l



Functions - The Onload function

The widget needs a starting point from which to commence operation. Within the Yahoo widget the onload function is typically defined in XML code within the .KON file in the following manner:

Code:
    <action trigger="onload">
      <![CDATA[
          startup();
      ]]>
    </action>

This onload event calls a particular function, in this case startup();

To convert this to Xwidget the following needs to occur. In the Xwidget IDE in design mode, select the widget object tree on the left hand side. Click the top level WIDGET then select the function tab (blue box) and look for the onload event - select the routine to run onload. IF you double click on the empty function box Xwidget will select the widgetOnLoad function automatically.

[ Tthe object tree on the left hand side ]

object list

In the YWE code, search for the startup function and take the code within and insert it into the widgetOnLoad function. Example follows:

Code:
//===========================================
// this function runs on startup - yahoo widget version
//===========================================
function startup() {
    if (debugFlg == 1) {print ("%-I-INFO, startup")};
    startupFlg = 1;
    createLicence(mainWindow);     // create the licence window
    .
    .
    .
}
//=====================
//End function
//=====================

This is the same code in the Xwidget engine:

Code:
//===========================================
// this function runs on startup - Xwidget version
//===========================================
function widgetOnLoad() {
    if (debugFlg == 1) {print ("%-I-INFO, startup")};
    startupFlg = 1;
    createLicence();
    .
    .
    .
}
//=====================
//End function
//=====================

This is a big step in making the Yahoo widget code operate within the Xwidget framework. We are getting close to actually running the code. A few more changes required.

Code auto execution

Xwidget is simple with regard to what it will execute. Any code that is in the widgetOnLoad() function will execute. Any code that sits within other functions will execute when called upon to do so. The Yahoo widget engine is not so particular, code that sits outside a function may execute when an included .js file is accessed. For example, look at the variable declaration code that runs before widgetOnLoad, some code statements can co-exist there and will operate outside the scope of a function. Each included file may have a variable declaration section and some executing code. All that code needs to be brought into the scope of widgetOnLoad.

Finding that sort of code may not be easy to find but you need to trawl through the code to find any out-of-scope code and deal with it.

Basically, any included files that have code auto-executed outside of the startup code in YWidgets will not auto-execute in Xwidgets, that sort of code needs to be moved to the widgetOnLoadfunction in order to run.

-oOo-

Other Functions and where to find them

Functions to perform any sort of event associated with a graphical object are defined as follows in the Yahoo widget javascript code:

Code:
playListTitle.onMouseEnter= function () {
   playListTitle.scrolling = "left";
}

This corresponds to the standard javascript method of creating functions, however each function call needs to be changed to conform to Xwidget standards. Xwidget functions are definitely not defined according to javascript standards but to Tony's own peculiar methods (I assume this has been implemented so that event information can be passed to the function locally rather than globally). The intellibollox help system leads you to believe that standard javascript notation would operate just as well but if you leave your functions as shown above then the widget engine will generate an error during run time. The playListTitle.onMouseEnter event must be captured as follows:

Code:
function playListTitleOnMouseEnter(Sender,Button,Shift,X,Y) {
   playListTitle.enabledHorzScroll="true";
}

The parameters that are passed to the function change dependant upon the type of function call so it is not a matter of a simple bulk replace of all functions. Instead, open the Xwidget IDE in design mode and select the functions tab for each object and see the functions listed, eg. onClick, onMouseDown &c.

For each event where a function needs to be defined, double click on the named function and the code window will open at that function's code. You will need to insert the original Yahoo widget code manually into that new function. With my conversion the original XWidget media player already existed so had most of the events already defined, it was simply a matter of double clicking on any events that already had functions attached to them and inserting the code for each.

[ The XWidget IDE showing functions defined ]
function list

Basically, you need to replace each and every event that is defined in the yahoo widget code and if a function exists you need to replace it in this manner. You will have to sift the Yahoo widget javascript code going down the list and noting each event defined, you then seek the same object in the Xwidget IDE and recreate the event, capturing the logic.

A little tedious but necessary if you want a conversion. Bit by bit, event by event, you will see the code morph into Xwidget code,

We encounter the next stumbling block now.

Much of the Yahoo widget's functionality is defined in the method shown above by function calls in the javascript code that determine an object's response to an event. However, in addition to this you will find that much of that logic is also defined in the YWidgets .KON file. This is very similar to the Xwidget main.xul file, if you look in the .xul file you will find the function calls expressed and converted into XML, containing standard javascript notation, for example:

Code:
//xwidget XML
<image name="lockAreaLocked" onMouseDown="lockAreaOnMouseDown"/>

//Yahoo Widget XML
<image name="lockAreaLocked" onMouseDown="lockAreaOnMouseDown">

You'll see these are in fact identical across the engines being standard XML, defining standard javascript calls, so of course they will be identical. That's rather nice.

In addition, the YWE widget's .KON file can contain not just the function call definitions but some or even all of the javascript too. Anything that is denoted as being within a <![CDATA[  ]]> bracketed section is run-able javascript code that is attached to an event directly. In the yahoo widget engine there is actually no need to have a main .js file instead all the javascript logic can be contained in the .KON file. You will find that most of the older widgets are built in this way whilst the newer widgets and those created by advanced (better) programmers will eschew this approach and move all the logic to .js code files using standard javascript methods. The following is a typical example of javascript code embedded within a .KON file.

Code:
<image visible="true" vOffset="0" name="speaker" src="Resources/speaker.png" hOffset="247">
    <onMouseUp>
    <![CDATA[
         //javascript starts
  if (preferences.soundpref.value === "enabled") {
   play(winding, false);
  }
  chosenFolder = chooseFolder();     //YWE function
  path = chosenFolder;
  if (chosenFolder != null ) {
    playerState = "folder"; //this is to ensure that shuffle mode is respected
    ReadFolderRecursively(chosenFolder);
    saveFolder(chosenFolder);
   updatePlayList();
  }
  //javascript ends
    ]]>
    </onMouseUp>
</image>

After the conversion to Xwidget this would move the javscript code from the .KON file and into the Xwidget script.js file and would become:

Code:
function speakerOnMouseUp(Sender,Button,Shift,X,Y)
{
  if (preferencessoundprefvalue.text === "enabled") {
     PlaySound(winding);
  }
  chosenFolder = openFolderDialog("");     //XWE function
    path = chosenFolder;
    if (chosenFolder != "") {
       playerState = "folder"; //this is to ensure that shuffle mode is respected      
          ReadFolderRecursively(chosenFolder);
          saveFolder(chosenFolder);
          updatePlayList();
        } 
     }       
}

For each event in the .KON file where an event is defined, using the Xwidget IDE, double click on the appropriate function and the code window will open at that function's code. You will need to insert the Yahoo widget code manually into that new function. After saving this will result in an automatically created entry in the Xwidget's main.xul as follows:

Code:
<image name="speaker" onMouseUp="speakerOnMouseUp"/>

As you can see this is not so difficult and the resulting code is very similar across to the two engines. My Yahoo widgets tend to be a combination of the two approaches, I have most of my logic in the javascript .js files whilst retaining small chunks of logic in the .KON file. There are reasons for this which I won't go into here but the upshot is, you need to trawl the .KON file for XML event definitions and then replicate each within the Xwidget IDE just as you did for the javascript code, copying and pasteing the code into the new functions as you create them. I never said it would be easy... Actually it is easy, it is just a bit of solid work that needs to be done. The question is do you want to convert or not?

OnKeyDown Event

We now encounter a stumbling block that we have to be creative to overcome.

In the Yahoo widget engine you will regularly encounter code that captures keypress events. In the case of creating a media player widget I take my cue from Youtube. When using youtube to play videos, the spacebar, cursor and other keys can be used to control the video. These keypresses have become the standard for media players and allow the user to interact with the app using the keyboard if he wishes. Therefore any media player widget needs to respond to a defined set of keypresses.

Regardless of its function, in any Yahoo widget you may encounter the following code types that capture keypress events. In the javascript .js code file a function may be defined where a CTRL+mousewheel event is captured (or ignored in this case...)

Code:
function sliderSetOnMouseWheel() {
    var delta = system.event.scrollDelta;
    if (!system.event.ctrlKey) {  //only if the user is not selecting the control key
             //do something
    }

In addition to this, in the .KON file, actions can be captured for the whole widget so that a keypress, whilst any object has focus, will still be valid. This particular code captures the F5 function key:

Code:
        <action trigger="onKeyDown">
              <![CDATA[
                if (system.event.keyCode==116) {
                    if (debugFlg === 1) {print("%KON-I-INFO, pressing F5 "+system.event.keyCode);};
                    reloadWidget();
                }
        </action>

Xwidget automatically captures the F5 key to refresh the widget (YWE has to catch and implement this in code) so we don't need to re-implement this YWE logic. However, Xwidget does not allow any other keyboard interaction due to a non-functioning implementation of the keydown event. Basically, the onKeyDown/onKeyUp does not work on any object that is not a text based field. Most objects have a onKeyDown event that you can assign and populate. The runtime engine simply ignores anything you have set.

The result is that you cannot easily capture keypress events when manipulating any object other than a text edit box or similar. This is a particular problem in this widget as a press of the CTRL key when the mouse is over the widget cannot be captured even though we have an onKeyDown event set up and code assigned. The event is simply ignored. In this instance I use this particular keyboard event for helping resize the widget.

Workaround

I tried various methods of getting round this, I tested a very large edit box at an opacity of 1% that can be set over the whole widget, this would have allowed a CTRL key to be captured. Unfortunately, mouse-through does not seem to work with edit boxes so all onMouse events for all other objects sitting below are negated when a large edit box is positioned directly above them.

There is however a isKeyDown() function that checks for a keydown event that actually works...

To capture a keydown event the isKeyDown() function has to be inserted into a place in your code, typically an event function. For example, during a onMouseDown event this code might be inserted:

Code:
if (isKeyDown(40)) {
     // right volume up
     if (debugFlg === 1) {print("%KON-I-INFO, pressing down the cursor UP key ");};
      sliderSet.left = sliderSet.left - 10 ;
      limitSliderSet();
}

However, this would only capture the keydown event when the mousekey was pressed simultaneously. So, we have to be inventive to ensure that the only trigger for the keypress is the keypress itself and as a result it needs to be inserted into something keyboard/mouse-neutral that occurs all the time... there aren't many of those - except for a timer event!

Create a timer called keyTimer and set the frequency to 50ms, insert the above code into the keytimerOnUpdate function. This will cause the timer to activate the function every 50ms and determine whether a valid keypress has been made. This is the workaround I was looking for, a bit over-complex for a simple key capture but in the absence of a working onKeyDown function it must suffice.

The isKeyDown(keyCode) function uses the standard javascript keyboard scan codes to determine which key is pressed. Find those here: keycode.info/

There is an unexpected side-effect, the key capture occurs all the time and not just when the widget has focus. The isKeyDown function works whether you are typing into a word processor or writing an email, if the widget is running on your dektop you will find the media player reacting seemingly randomly to your email keypresses. To get round this you simply need to turn off the timer when your mouse leaves the widget and then turn the timer back on when the mouse re-enters. In the IDE in design mode, select the WIDGET object and enable an event for both entering and leaving the widget, assigning the following code:

Code:

function widgetOnEnter()
{
      keyTimer.enabled=true;
}

function widgetOnLeave()
{
  keyTimer.enabled=false;
}

The regular frequency of the timer could be increased to 100ms interval to reduce the cpu overhead of such a frequently run timer. Unfortunately, the result would be that keypresses would seem 'halting' and jerky in their capture. The 50ms interval makes for smooth response while a 100ms interval feels unresponsive and 'wrong'. There is a cpu penalty for frequently running such a function and it is only necessary due to incomplete features in the Xwidget engine.

However, we have a workaround for the absence of the onKeyDown event and it means that we can now say that Xwidget does have the ability to capture a keyboard event.

Dock differences

Yahoo widget engine has a dock that you can interact with, you determine not just the image that is displayed in the dock but you can also add text. All these can be modified during runtime. For example: a weather widget can also display the temperature in the dock. Xwidget does not have a similar sort of dock and that runtime 'vitality' is missing. Some widgets will have code that modifies the dock and this code will simply have to be removed as it is now unnecessary. In almost all my widgets there is a javascript included file called vitality.js. All calls to this file and the function within it will need to be removed.

The Xwidget dock is buggy, difficult to raise (two double clicks are often required on the xwidget systray icon) and static in that it always occupies the screen bottom position. It also emulates the Mac Finder Dock in appearance which has always surprised me - I have always expected Apple to slap Tony down for misappropriating their imagery.

Widget Attributes.

For the Yahoo widget engine the widget attributes are stored in a file named widget.xml. All the pertinent data will need to be extracted from the widget.xml file and placed into the associated fields within the xwidget IDE, version nos, descriptions, author name &c

-oOo-

Part 5 is here
Guide to converting Yahoo Widgets to Xwidget Pt5Part V of the guide to converting a Yahoo widget to a Xwidget, this guide follow on from Part IV which can be found here:


Tooltips and Hints
Tooltips used to be supported in earlier versions of the Xwidget engine but Tony the developer, during the original development of xwidget 1.0 changed the tooltips to hints. Hints are massive bubble pop-ups that display the tooltip text in a large-ish font whereas tooltips are small discreet boxes using small fonts. The Yahoo widget engine only uses normal tooltips and as these sort of tooltips are not supported in the current version of the Xwidget engine,you cannot replicate this functionality.
The large hints can really get in the way and they are styled in such a way that the result is quite jarring. Hints also pop up immediately whereas tooltips tend to only pop up a few seconds after the mouse has hovered over an object. Tooltips are much nicer overall. If you are going to implement hints then I would
Atari ST Colonial Conquest Coconet USA Scenario
This is a rather strange submission to my gallery. This is a scenario file for an old retro game.

Before I describe it further - can I ask that just one person downloads the scenario and actually tries the game? So far no-one has, not one person.

The game was re-written by a friend of mine and he really needs your support to make the game more popular.  Try it! Download it!

 -oOo-

A while back (1985) I used to play a rather good game on a friend's Atari ST by the name of Colonial Conquest. The game was an enhancement of that old classic board game Risk with more complicated maps and an efficient and ruthless AI. The game was multiplayer so your friends could join in and it was quick and fun to play. I loved playing it. Many years passed, I grew up and computers moved onward and upward, compatibility wasn't the norm and so all those old games that used to give us so much pleasure became unwanted and obsolete. That was until 'puters became powerful enough to emulate older machines reliably and quickly in software, then the emulators had a chance to finally be useful. That meant that we have a wealth of old games available for us to play but the price of emulation can be heavy, resource intensive on the host, having to dive into a clunky and hard-to-use interface that can revive the experience in a way that could tend to put you off.

Another approach is to rewrite the game so it runs natively on the newer machine. The temptation then is to re-write the game, update the graphics and gameplay and release a brand new game to a newer audience with higher expections just retaining the original game name but nothing else. Why would you do it any other way if you want to make money?

Well, sometimes, someone comes along that isn't trying to sell us a brand new game at inflated prices but instead just wants to build the exact same old game, same old gameplay, same old obsolete graphics just for the sheer hell of it.
One such chap goes by the name of Kroah and he built a completely reverse-engineered version of Colonial Conquest for Windows. He did this because he had an itch that had to be scratched and so he built it without any of the original source code, re-implemented the original slightly clunky graphics and obsolete interface and recreated a game with the same look and feel - and the same gameplay as the original from 1985. The good thing was that this happened to be my favourite game of all time. Kroah named the new native PC version Coconet as it was Colonial Conquest for network play. The AI is enhanced, it allows you to play a choice of AI versions but the fundamental game is the same as it ever was.  Other games come and go, Rome Total War, World of tanks to name a few but every now and then I still feel the need to play a good game of Colonial Conquest. I just feel the need, no more explanation required... That might be the same itch that Kroah had all that time ago.

OK, I didn't have much of a hand in creating the game, though I helped Kroah along the way by giving him moral support on the forums - but I did create one scenario for the game, a fully featured and enhanced map extending the number of territories in the USA and Canada. This map alters the gameplay quite considerably giving the US a great advantage and the enhanced possibility of winning the game when played by either the AI or a human player.

I based my map on an already extant version called "nieuw standard" by a player known as Christine. She did all the legwork, I just added to it. Don't underestimate the work involved in customising a Coconet map, there is lots of XML to be mucked around with and the use of an overly complex and buggy scenario editor that can drive you mad!

Nevertheless, it works and is playable. Before you can use it you have to install the older game here.

Old version (2012-07-18): CoCoNet-1.0.2-Setup.exe

Then patch it here:

Latest version (2015-03-30): CoCoNet-1.2.0.7z

When installed download and move the new map zipfile into the custom maps folder. Then just play a custom map and select "USA enhanced". Hope you get the game working, hope you manage to get my scenario working, have fun and enjoy a bit or 1985 retro gaming at its finest.This is a rather strange submission to my gallery.
Loading...
Part V of the guide to converting a Yahoo widget to a Xwidget, this guide follow on from Part IV which can be found here:

Guide to converting Yahoo Widgets to Xwidget Pt4Part IV of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part III which can be found here:


Functions - The Onload function

The widget needs a starting point from which to commence operation. Within the Yahoo widget the onload function is typically defined in XML code within the .KON file in the following manner:
Code:
    <action trigger="onload">
      <![CDATA[
          startup();
      ]]>
    </action>
This onload event calls a particular function, in this case startup();
To convert this to Xwidget the following needs to occur. In the Xwidget IDE in design mode, select the widget object tree on the left hand side. Click the top level WIDGET then select the function tab (blue box) and look for the onload event - select the routine to run o


Tooltips and Hints

Tooltips used to be supported in earlier versions of the Xwidget engine but Tony the developer, during the original development of xwidget 1.0 changed the tooltips to hints. Hints are massive bubble pop-ups that display the tooltip text in a large-ish font whereas tooltips are small discreet boxes using small fonts. The Yahoo widget engine only uses normal tooltips and as these sort of tooltips are not supported in the current version of the Xwidget engine,you cannot replicate this functionality.

The large hints can really get in the way and they are styled in such a way that the result is quite jarring. Hints also pop up immediately whereas tooltips tend to only pop up a few seconds after the mouse has hovered over an object. Tooltips are much nicer overall. If you are going to implement hints then I would suggest adding some method of turning them off as they will quickly annoy any user.

Tony promised to revert hints back to tooltips - but development on version 1.0 of the xwidget engine stalled and that reversion to tooltips never actually occurred.

[ a massive Xwidget hint ]
hints in xwidget

[ a subtle Yahoo widget tooltip]
tooltips!

Change all tooltips to hints:

Code:
pipesRight.tooltip = "pulled out - shuffle is now enabled"; // YWE tooltip

Code:

pipesRight.hint = "pulled out - shuffle is now enabled";     // Xwidget hint

Another subtle difference in the hints is that they will appear regardless of whether your widget has focus. If you pass your mouse over the Xwidget they will appear. On the Yahoo widget the tooltips will only display when the widget itself has focus.

You could always implement your own tooltips in code but this might be fairly complex and so is beyond the scope of this document. I have some code that re-implements non-native tooltips on the Yahoo widget engine that I could look at porting to xwidgets but that is complicated work and I'm not even sure it would work in Xwidgets. I suggest that if you don't like the hints then you comment out them out for the moment and do without them if you can. If I manage to convert the tooltip code then I will post the solution here.

-oOo-

Filesystem and folder operations

The Yahoo widget filesystem.getDirectoryContents function is used to obtain a list of files and folders within a given location. It can provide a list of the specified files or search recursively listing all the files and folders. The Xwidget is a straight replacement with some improved features.

Code:
fs = filesystem.getDirectoryContents(path, false); // non-recursive search

Code:
fs = getFileList(path,validTypes,false); // non-recursive search

The first difference between the two functions is that the xwidget getfilelist returns a bar-separated list of files, whereas the YWE returns an array consisting of as many file/folder elements as it finds in that folder.

As a result the XW list can be handled using normal string functions but to convert existing YW code that expects the file list to be in an array you must first assign each string element to an element in an array. That is done using the .split function:

Code:
// YWE code that takes the file list contents and builds an array
FSarray = filesystem.getDirectoryContents(path, true); // recursive search

Code:
var validTypes = ["mpeg","mp4","m4a","mpg","flv","mp3","aac","wav","wma","aif","aiff","au","snd"];
//XWidget code that takes the file list contents and builds a bar-delineated list
fs = getFileList(path,validTypes,true); // recursive search
// convert the filelist into an array
FSarray = fs.split('|');

The main difference here between the Xwidget and Yahoo versions, is that there is no need to check the output results are valid file types as the list has already been filtered by the xwidget getfilelist function. The Xwidget version allows an input filter for filetypes. The YWE version does not take an input file filter and so the output needs to be filtered for valid types but only after it has been populated. The Xwidget function is superior in this respect. Any Yahoo widget that uses the filesystem.getDirectoryContents may have a filter of some sort on the output, this code can be safely removed as it is not required, as long as you use the Xwidget input filter function.

Code:
// YWE code that takes the file list contents and builds an array
FSarray = filesystem.getDirectoryContents(path, true); // recursive search

var validTypes = ["mpeg","mp4","m4a","mpg","flv","mp3","aac","wav","wma","aif","aiff","au","snd"];
    if (validTypes.indexOf(xtn(FSarray [i])) >= 0 ) {
      IsSong = true;
    } else {
      IsSong = false;
    }

Code:
     IsSong = true; //Xwidget code

This removal fixed two things, first of all it removed some unnecessary code, it also removed the call to the .indexOf function working on an array which doesn't seem to work in the same way as in Yahoo widgets - I'll document that later.

The Xwidget getFileList function has a minor difference in output to the YWidget version, on the XW version it always returns the full path, whereas the the Ywidget returns only the filename relative to the chosen folder. As as a result, when performing other functions on returned files, such as fileExists or folderExists, the Yahoo widget always has to build the full path manually. This results in unwanted extra folder paths in the logic that may confuse your Xwidget program.

eg. if the default folder is:
e:\music

instead of returning an element of FSarray and using it as:
e:\music\eighties\flock_of_seagulls.mp3

the Yahoo widget code may add extra path information to your Xwidget code and return it as:
e:\music\e:\music\eighties\flock_of_seagulls.mp3 - note the extra  e:\music

You'll need to look through your code for any extra path building and remove these extra unwanted additions.

Code:
    if (! filesystem.isDirectory(path + "\\" + FSarray[i])) // YWE version building using the relative path
       {
             //do something
       }

Code:
       if (! folderExists(FSarray[i]) ) //Xwidget version, path is already full
       {
             //do something
       }

The Xwidget getFileList function has a couple of real advantages over the Yahoo widget version. Firstly the input can be filtered as already shown, meaning that the resulting file list is much smaller to process. Secondly it is very, very fast to build a file list even when performed recursively on a large and well populated folder structure. It also seems to work well with with many thousands of files.

The yahoo widget version by comparison is slower to run building what must be a massive unfiltered array. It is resource-intensive requiring both memory and processor to complete. On a recursive search of a large folder the search can stall the yahoo widget completely, leaving a hung process and a white panel on your desktop where the widget used to be - stopping the process is the only way out. 

Even when a Yahoo widget engine recursive search is successful, any returned file list will be unfiltered and potentially containing many thousands of unwanted file types. The file list has then to be filtered to another array containing just the valid music files. All this is unnecessary overhead that the Xwidget engine simply does not encounter just because it allows you to filter the input file types. It uses less resources, is quicker and better all round.

To avoid the situation where a recursive file list is required from a potentially massive folder, the Yahoo Widget often has to perform a preceding recursive file search that is performed manually, folder by folder, step by step, counting the files as it goes, allowing it to stop before a pre-defined limit is reached. If a pre-determined file limit is reached then a warning message may be given or the process aborts altogether. If that predefined limit is not reached then the final recursive search is allowed to go ahead avoiding any chance of a 'hang'.

That sort of code is likely to exist in a well-written widget and I'm happy to say that this sort of code can be safely removed from your more efficient Xwidget as long as it is unlikely the end-user will ever select a folder containing tens of thousands of files. In my yahoo widget I had a function that counted the files in a folder but initially I commented it out as I thought it was unnecessary. Experimenting with the maximum number of files that the Xwidget engine can handle, I found that the Xwidget engine is indeed very good at handling large numbers of files but I decided to put the function back in place and convert it just to be on the safe side. Which brings me to the next issue. It appears to be a bug.

The Xwidget getFileList function works well in recursive mode listing all the folder contents in the folder tree. However, if you operate the getFileList function in non-recursive mode on a folder containing just sub-folders and no actual files it reports the folder contents as zero. This 'feels' incorrect as the folder clearly contains subfolders, each of which should be an entry in the list. I say it feels incorrect but it is possibly intended behaviour on the part of the developer. When compared to the yahoo widget engine we see a difference in operation, the equivalent YWE getDirectoryContents version can also be operated in non-recursive mode but it reports not just the files but also the folders. With the YWE version this means that you can take each subfolder and having identified it, perform a file search or any other operation. As the xwidget engine does not report sub-folders you cannot replicate this.

This causes a problem in my countDirContents function as it loops folder by subfolder and counts the files within each. Any subfolder it finds it then opens and continues until it reaches a file limit, then it stops. Converting this code proved to be a problem as Xwidget provides no way of listing and operating upon just folders.

To work around this I had to create an ActiveX function to perform a folder search. I used a combination of the native Xwidget getFileList function to count the files and the ActiveX function to identify a subfolder. A little more complicated but it works.

Code:
        // Yahoo widget function
    function getListing(path) {
    var paths;
    paths = filesystem.getDirectoryContents(path, false);
    paths.forEach(function (ele) {
    var fpath;

    if (limit <= 0) {
    throw new Error("Limit Exceeded!");
    }

    fpath = path + "/" + ele;
    if (filesystem.isDirectory(fpath)) {
    getListing(fpath); //calls itself again
    } else {
    result.push(fpath);
    limit -= 1;             // counts files found
    }
    });
    }

Code:
    // Xwidget function
  function getListing(path) {
            pathString = getFileList(path,validTypes,false); // get files only
            var paths = pathString.split('|'); // convert to array
            for(var i = 0; i < paths.length; i++)
            {
                var fpath = paths[i];
    if (limit <= 0) {
    throw new Error("Limit Exceeded!");
    }
    result.push(fpath);
    limit -= 1;             // counts files found
    };
            //in addition this extra code is required to get the sub-folder list
            pathString = showFolderList(path)  ; //get the sub-folder list
            paths = pathString.split('|'); // convert to array
            for(var i = 0; i < paths.length; i++)
            {
                   fpath = paths[i];
             if (folderExists(fpath)) {
                              getListing(fpath); //calls itself again
          }
    };
    }

In addition to the above changes a new function is required. This is the ActiveX function that lists folders only:

Code:

function ShowFolderList(folderspec){
var fso, f, fc, s;
    fso = new ActiveXObject("Scripting.FileSystemObject");
    f = fso.GetFolder(folderspec);
    colFiles  = f.SubFolders;
    fc = new Enumerator( colFiles );

    s = "";
    for (; !fc.length; fc.moveNext()) {
        if (fc.item() == null) {
           break;
        }
        s += fc.item();
        s += "|";
        }
    return s;
}

With the addition of the above ActiveX function you now have the capability of counting subfolders within otherwise empty folders. Lucky for Xwidget any missing functionality it has can be recreated in ActiveX.

For...each statements

Note that I changed the for...each statements to for...loops as xwidget baulked at the for...each statements, not sure why yet. I will test this code further and report the results later.

File dialog boxes

To select a file or folder both widget engines have file dialog functions that can make a file or folder selection from your filesystem. In this particular widget we need these to select media files to play. Dialog boxes for both engines  operate in a similar fashion:

Code:
fileName = chooseFile(validTypes); // Yahoo widget dialog

Code:
fileName = openFileDialog("");   //Xwidget dialog

The following is a real-life example:

Code:
ar validTypes = [".mpeg",".mp4",".m4a",".mpg",".flv",".mp3",".aac",".wav",".wma",".aif",".aiff",".au",".snd"];
fileName = chooseFile(validTypes); // Yahoo widget dialog
        if (fileName != null) {
          PlayFile(fileName);
        }

The Yahoo widget version is superior as it allows you to filter input file types by passing a input string to the choosefile function. That is shown above. In the above example it can play the chosen filename without checking it as the dialog box will only return valid media files.

[ picture here of a typical dialog box - the input filtered ]
widget folder filtered

Unfortunately and surprisingly, Xwidget does not allow you to filter input file types so you have to filter the file type after selecting the file with your own validate function.

Code:
var validTypes = [".mpeg",".mp4",".m4a",".mpg",".flv",".mp3",".aac",".wav",".wma",".aif",".aiff",".au",".snd"];

        fileName = openFileDialog("");

        if (fileName == "") {
          fileName = "";
          //alert("no file selected");
          return;
        }

        if (validate_fileupload(fileName) === true ) {
           PlayFile(fileName);
        } else {
          alert("incompatible file type");
        }

In addition to the above, the following validation function is required as the file dialog could return any selected file type and we only want to receive media files that the media player can open and run.

Code:
function validate_fileupload(fileName)
{
    var allowed_extensions = validTypes;
    var file_extension = fileName.split('.').pop();
// split function will split the filename by dot(.), and pop function will pop the last element from the array which will give you the extension as well. If there will be no extension then it will return the filename.

    print("file_extension "+ file_extension);
    for(var i = 0; i < allowed_extensions.length; i++)
    {
        print("allowed_extensions[i] "+ allowed_extensions[i]);
        if(allowed_extensions[i]==file_extension)
        {
            print("return true");
            return true; // valid file extension
        }
    }
                print("return false");
    return false;
}

You will need to replace all occurrences of chooseFile in your code and add file validation functions as above. There are other file and folder operations that the Yahoo widget engine has that have no direct replacement in the Xwidget environment. In this conversion I will only discuss the issues I have encountered and only provide alternatives to the filesystem functionality found in this particular widget. You may encounter other issues and will have to find your own personal solutions - remember, t'internet is your friend and almost everything that you want to do can be done in javascript.

Reading files

The function to read files from the file system is similar in format in both Ywidget and Xwidget.

Code:
filename = chooseFile(".xml");
var lines = filesystem.readFile(filename, true); // yahoo widget code

Code:
filename = openFileDialog("");
var linesStringRead = readFile(filename); // xwidget code - data read into intermediate ANSI string

The main difference is that xwidget reads files as a string rather than an array of elements so we have to convert the string into an array.

Code:
// we convert the string into a useful array using the xml > character as the delineator
var lines = linesStringRead.split('>');

This is easy to do if you have something in the file that you are reading that can act as a field delineator (separator) but not so easy if you do not. In this case I was lucky as I was able to use the ">" character that appears at the end of each XML string as the delineator to allow the preceding characters to be transformed into the string that would reside in the contents of each array position. I simply had to make some minor changes to my string handling code and the function that I was converting worked first time.

This conversion to an array had the unfortunate result of adding some preceding space characters and removing the ">" from the string. These changes would cause some string handling problems later so they had to be repaired. I resolved this whenever the code read a string from the array by simply adding a ">" to the end of the string and then trimming it in the process.

Code:
var lineString = trim(lines[i].concat(">"));

This rebuilding of the string meant that my exisiting logic could be retained and re-used. Instead of the concat function you could simply add the strings together using the '+' operator. Supposedly, the concat operator is less efficient.

Code:
var lineString = trim(lines[i] + ">");

If your file contents have no delineator then you will struggle to easily convert the data into an array. One suggestion would be - as you have easy access to the Yahoo widget engine and the YWE code to read a file into an array, you could easily adapt that code and use that to re-write the data in a form that the Xwidget engine could more easily handle, adding field separators to the data that the xwidget could then use to convert a string back into an array.

-oOo-

The Yahoo widget engine has a nice facility where it can provide volume information regarding the various drives your system has mounted. This Yahoo widget used the information to check the drive names and count the drive volumes. The volume objects are stored in an array allwoing you to inspect the object's properties.

Code:
function restrictRootFolder() {
    var vols = filesystem.volumes;
    var a, volscnt, nn;
    for (a in vols) {
        if (vols.hasOwnProperty(a)) {
            volscnt = Number(a);
            nn = filesystem.getDisplayName( vols[a].path ) ;
        .
        .
        }
    }
}

Xwidget does not have such a function so similar functionality has to be provided using ActiveX.

Code:
    var drives = driveList();       //var vols = filesystem.volumes;
    vols = drives.split("|");

Code:

function driveList() {
    var nobj, result, n, e, x;
    result = "";
    nobj = new ActiveXObject("Scripting.FileSystemObject");
    e = new Enumerator(nobj.Drives);
    for (; !e.atEnd(); e.moveNext()) {
        x = e.item();
        result = ''+result + x.DriveLetter+':';
        result += " - ";
        if (x.DriveType == 3) n = x.ShareName;
        else if (x.IsReady)
        n = x.VolumeName;
    else n = "(Not ready)"; result += n + "|";
  }
  return(result);
}

ActiveX is turning out to be essential in order to do nearly anything in Xwidget. A lot of the basic filesystem functions that you'd expect this widget engine to provide are missing. The hasOwnProperty() is there to check the validity of the volume and is a javascript function.

-oOo-

Writing files

Here is where I have my first "Ye Gods!" moment.

Ye Gods! Xwidget engine does not have any capability to write a standard ANSI file! It has the readfile function where it can read ANSI data from a selected file but it cannot write that data back again... What an utter and complete load of b0ll0x! The more you use the Xwidget engine the more you realise what an appalling state this engine is in, it is utterly buggy and unfinished! Version 1.0 it really isn't. More like ver 0.8.

The fact that it works so well despite these sorts of glaring issues is astonishing.

I had always assumed there was a writeFile function to act as the opposite to the readFile function but there isn't. I assumed this as every other engine has an equivalent function - in the Yahoo widget engine we would use:

Code:
filesystem.writeFile(XMLpath, head + body + tail);

This command writes the file located by XMLpath and then places the data represented by head, body and tail into the file. There is no direct replacement for this command. So this leaves us with the task of creating this function from scratch using ActiveX. Luckily Jscript provides ActiveX access to the FileSystemObject

Code:
WriteFile2(XMLpath, head + body + tail);

function WriteFile2(XMLpath,data)
{
   var fso  = new ActiveXObject("Scripting.FileSystemObject");
   var fh = fso.CreateTextFile(XMLpath, 2, true);
   fh.WriteLine(data);
   fh.Close();
}

This code successfully replicates Xwidget's missing writeFile functionality and allows Xwidget to write standard output just as any other widget engine can. Phew!

That is the end of my "Ye Gods!" moment...

Guide to converting Yahoo Widgets to Xwidget Pt6Part VI of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part V which can be found here:

Preferences
The Yahoo widget engine has one particular advantage over the xwidget engine in that it provides a ready made structure for configuring user preferences. A right click on any widget gives you the menu preferences option that opens to display a number of panes where user-defined preferences can be stored and configured.
[ A typical preference window ]
Each preference pane is created by simply adding a group definition to the preferences XML in the .KON file.
Code:
    <prefGroup name="general" order="1" icon="Resources/general-icon.png" title="Sounds"/>
Each preference field, checkbox, slider, text and drop down can be created by adding a single line in XML that describes the user preference. The configuration data it represents is stored in the system


Still typing part VI now...watch this space as I type and you'll see Part VI is regularly saved and updated.
Part III of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part II which can be found here:

Guide to converting Yahoo Widgets to Xwidget Pt2Part II of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part I which can be found here:


Next step was to pull the code from the Yahoo widget, that was easy enough to do. I use a coder's editor called Context which runs on all flavours of Windows, it is my favourite platform for coding and I have tried a few. Context is a powerful editor which just works with no complications. It doesn't try to be an IDE nor a word processor. During the conversion process I have the context editor open with multiple tabs showing all of my Yahoo widget code, while the Xwidget IDE is open in another adjacent window. It really helps if you have a big screen or even two screens side by side.
[ The Context editor opening files in tabs ]
Opening my media player widget code in context means opening three source files, the XML .KON file that describes the widget and two other .js javascript files that store the widget's logic. In


So, let's start.

We start by doing some simple bulk copy and pastes. First of all we change the object positioning. In Context editor with the Xwidget IDE shut down, we type Ctrl+R which displays the search and replace dialog.

[ The advanced search and replace dialog in the Context editor ]
search and replace

In comparison with the Xwidget code kludger we have a lot more functionality. First of all we have search history, it remembers all your previous searches. Then we have advanced search options, allowing us to search for whole words, case sensitive text from the current cursor position or from the top of the program. Using the Xwidget IDE is like bashing your head against against a marble fireplace - it is so nice when you stop.

We need to change each occurrence as below:

1. Change all .voffset to .top
2. Change all .hoffset to .left

Code:
cable.hOffset= sliderSet.hOffset+ sliderSet.width; //YWE code
chain.vOffset= chain.vOffset+ 20; //YWE code

Code:
cable.left= sliderSet.left+ sliderSet.width ;           //Xwidget code
chain.top= chain.top+ 20;    //Xwidget code

Note that the YWE properties voffset and hoffset are non-standard for javascript whereas the Xwidget engine complies with standard javascript notation.

Resizing

Resizing for a Yahoo widget is performed by manipulating the width and height properties for each and every image that comprises the widget as well as the hoffsets and voffsets. 

In my Ywidgets the initial values for each of these are stored and any resizing is performed in relation to these initial values. This requires a lot of variable declarations and then a large resizing routine to manipulate these variables, complicated and unwieldy but it works.

In an xwidget, the process is much easier. The scaleTo() function is applied to the layer that comprises the graphical object that you wish to resize. One line replaces all that code.

Code:
    // ywidget
    Scale = Number(preferences.maxWidthPref.value) / 100;   

    cableWheelSet.hoffset = cableWheelSethoffsetDefault * Scale;
    cableWheelSet.voffset = cableWheelSetvoffsetDefault * Scale;
    cableWheelSet.width = cableWheelSetwidthDefault * Scale;
    cableWheelSet.height = cableWheelSetheightDefault * Scale;

    cable.hoffset = cablehoffsetDefault * Scale;
    cable.voffset = cablevoffsetDefault * Scale;
    cable.width = cablewidthDefault * Scale;
    cable.height = cableheightDefault * Scale;
    .
    .
    .

Code:
   // xwidget
   var Scale = Number(preferencessizePrefvalue.percent+30) / 100;
   volumeDevice.scaleto(size/100,size/100,0.0000000001,"topleft");

The Yahoo widget does not have the concept of layers so that layers cannot be manipulated in the same manner as in the Xwidget engine. One layer in the xwidget can be changed by the scaleTo() function whilst the others can be left as they are. This means that the core widget itself can be resized while the about us and help images remain the same size on the desktop. When the scaleTo() function is implemented you must remove all the occurrences of  * Scale from your code, it is no longer required.

The scaleTo() function is a real boon to the xwidget's functionality and a great advantage over the yahoo widget.

Sounds

Let us start with the most basic sound a widget can make, a beep.
The beep command is different, the Yahoo widget engine just emits a beep whereas in the Xwidget engine the frequency and length of the beep can be determined.

Code:
beep();

Code:
beep(frequency,ms);

In addition to beeps all my widgets have real sounds. They have these to make the widget 'feel' alive. When you pull a lever or press a button a sound is played that sounds like that lever being pulled. Your widget may not have sounds but if it does, read on. To play sounds in code the Xwidget engine has a built-in function that does the same as the YWE version but it is differently named and takes a different number of parameters.

3. Convert all play statements to playsound.

Code:
play(zzzz,false);   //YWE code

Code:
playSound(zzzz);  //Xwidget code

Before a sound can be played it needs to be declared as a variable, most of mine are declared globally so that they can be used at any time in the widget's operation:

Code:
var buzzer = "resources/buzzer.mp3";   //YWE code
var zzzz = "resources/zzzz.mp3";
var tingingSound = "resources/ting.mp3";

Code:
var buzzer = "buzzer.wav";  //Xwidget code
var zzzz = "zzzz.wav";
var tingingSound = "ting.wav";

All references to MP3 files must be changed in the code in the XWidget variable declarations. You will need to change each declaration to match both the sound file location and name. In the YWE all the resources (images, sounds &c) are placed into the resources folder, I have had some issues with the xwidget engine and getting it to find relative folder locations so my solution was to place all the files in the same default widget folder. A bit messy but it works - and that's why my .wav files are no longer in the resources folder.

4. Convert all sound variable declaration statements.

Code:
var buzzer = "resources/buzzer.mp3";
var buzzer = "buzzer.wav";

Which brings us to the next small stumbling block...

For sounds the yahoo widget uses .mp3 files by default which are compact and quick to load. The Xwidget engine does not use .mp3s but uses the much larger and slower to load .wav files instead, this incompatibility means that all the YWidgets .mp3 sound files must be converted to .WAV format.

An easy way to achieve this is to download and install audacity. Audacity is a free and open source audio editor. Using audacity you simply import the .mp3 files and export them as .wav format. You can download audacity here: www.audacityteam.org/download/
Installation is easy and each .mp3 conversion takes a mere minute or two and is very easy indeed. Place your newly created .wav sound files in the correct location and the sounds will play as before.

[ Audacity being used to export an mp3 file ]

audacity

Note: There are some incompatibilities with regard to how to XW and YWE engines play sound. Most likely you won't encounter these but let us quickly state them. The YWE engine can play two or more sounds simultaneously but the Xwidget engine cannot. It can only play one sound at a time.

eg. Playing a sound and then following it with a second sound causes sound number 2 not to appear.

Code:
if (preferencessoundprefvalue.text != "disabled" ) {PlaySound(buzzer);};
if (preferencessoundprefvalue.text != "disabled" ) {PlaySound(ting);};

The buzzer loudly resounds but the 'ting' is never played.

Obviously, if you play one sound then follow it with another, either one sound should follow the other, if they are played in a serial fashion or they should be asynchronous and be able to run in parallel. This is a bug in Xwidgets or at best a real limitation. When you are using sounds in your widget you need to be aware of this limitation as the results may differ between engines.

Multi-platform support code removal

Now to something more exciting but also sound-related in that we are about to implement the code that actually plays the media files. Yahoo widgets has the capability to interface to the underlying o/s using native methods. In the case of Windows that is via ActiveX. However, Yahoo widgets was also able to run on Mac OS/X  - and as that functionality is not really relevant in the case of Xwidgets (Xwidget is Windows only) let us remove any Apple-specific code before we move on. That removal is normally achieved by looking for and removing all references to Macintosh and system.platform:

5. Find all Mac OS/X code and remove it:

Code:
          if (system.platform !== "macintosh") {
             text.font = "courier new" ;  //windows code
          } else {
             text.font = "american typewriter" ;
          }

Leaving just the Windows code in place.

Code:
          text.font = "courier new" ;  //windows code

The convertPathToPlatform function allows the YWE to handle folder paths for both Mac OS/X and Windows. The convertPathToPlatform function does not exist in Xwidget and in any case it is now superfluous as Xwidget is native to Windows only. XWidget will report all paths as windows paths so any function containing convertPathToPlatform is redundant and should have the related code removed.

Code:
var widgetFullPath = convertPathToPlatform(userWidgetsFolder + "/" + widgetName); // YWE code

becomes:

Code:
var widgetFullPath = userWidgetsFolder + "/" + widgetName; // XW code

-oOo-

ActiveX/COM - accessing the windows music player

Right, that's done, now we can get back to adding the code that allows Xwidget to interface via ActiveX to the windows media player. Be aware that interfacing to any other o/s component by COM will be very similar to this method but of course in this case we are accessing only the audio functionality provided by Windows through its embedded Windows Media Player.

6. Convert all ActiveX code to Xwidget standards, convert from this:

Code:

// creating a new instance of the windows media player in YWE
var WMPlayer = COM.createObject("wmplayer.ocx")
COM.connectObject(WMPlayer, "WMP_");

to this:

Code:
// creating a new instance of the windows media player in Xwidgets
var WMPlayer = new ActiveXObject("WMPlayer.ocx");
// the second COM.connect... line is not required

The following are example windows media player commands that are used throughout the Yahoo widget:

Code:
// commands that cause the WMP do this or that
WMPlayer.settings.setMode("loop", false);
WMPlayer.settings.autoStart = false;
WMPlayer.settings.mute = false;

// dialog box to open an audio media file for playing
fileName = OpenFileDialog("");

[ The file open dialog box as created by the Yahoo widget engine, note - it has an input filter ]

widget folder filtered

// use WMPlayer to play the file
WMPlayer.URL = fileName;
var counter = WMPlayer.currentPlaylist.count;
WMPlayer.controls.play();
.
.
//and other similar WMPlayer commands...

All of these WMPlayer commands work exactly as they did in the Yahoo widget, no changes required at all. We no longer have to make do with Tony's (slightly rubbish) media player core and can manipulate the audio tracks as we require. It just works.

The next section concerns look and feel

There are many minor incompatibilities between the two engines but most of them are trivial and can be resolved by a little bulk cutting and pasteing.

Code:
    // yahoo check for aspect ratio and determine whether it is in portrait or landscape mode
    if (screen.width > screen.height) {
        aspectRatio = "landscape";
    } else {
        aspectRatio = "portrait";
    }

Code:
    // Xwidget check for aspect ratio and determine whether it is in portrait or landscape mode
    if (screenwidth > screenheight ) {
        aspectRatio = "landscape";
    } else {
        aspectRatio = "portrait";
    }

Some of my widgets use the aspect ratio to position themselves actively on Windows tablet devices that orient themselves dynamically between landscape and portrait. Sometimes positioning a widget in a particular place in landscape mode is not suitable for portrait mode so I have a default position for each. You may encounter screen.width &c in your widget, change it as necessary.

Opacity

In the Xwidget IDE the opacity of an object can be expressed from 1-100 in percentage terms. That is all well and good. However, in the use of code there is an inconsistency, according to the intelligent auto-suggestion feature, the object's opacity can only be set at two boolean values, either 0 or 1. Transparent or opaque. That is a bug in the auto-suggestion feature (I won't trust that anymore). Typically, visibility is expressed as a boolean whilst opacity is a gradient from 1-100 or 0-255. Most other engines and languages will allow opacity to be expressed in values from 0-255, the yahoo widget engine does it this way so all your existing opacity settings will be from 0 to 255 and will require conversion.

[ The XWidget IDE showing a percentage opacity ]
IDE opacity

The Xwidget IDE having only a percentage opacity leads you to believe that the code values will be the same but bizaarely it is different from both the code and the YWE. In fact opacity in code is expressed as a value between 0 and 1, so 0.9 is a valid level of opacity. This turns out to be the industry standard method for expressing opacity in javascript so both the Yahoo widget engine and the Xwidget IDE are wrong in this respect.

7. Change all opacity levels.

Code:

background.opacity = 255; // YWE method of making an image solid
background.opacity = 127; // YWE method of making an image 50%

Code:
transparentbackground.opacity = 1; // Xwidget method of making an image solid
background.opacity = 0.5 ; // Xwidget method of making an image 50% transparent

You'll need to sift through your code and find if it uses opacity in any form and make changes accordingly.

In addition any opacity fade outs that you have in your code will be handled differently and you need to cater for the differences. In the Yahoo widget a layer can be made to fade from opaque to transparent and vice versa using the fade command or the FadeAnimation command:

Code:
aboutUsLayer.fade(0, 255, 1); // this is the old obsolete method fading a YWE object

Code:
var a = new FadeAnimation(aboutUsLayer, 255, 2000, animator.kEaseNone);
animator.start(a); // this is the current method of fading a YWE object

In Xwidget a layer is made to fade from opaque to transparent using the fadeto command and vice versa using the FadeToVisible command:

Code:
aboutUsLayer.FadeTo(0,2);
aboutUsLayer.FadeToVisible(255,2)  

You will need to replace the YWE fade function with the appropriate Xwidget version.

Next we encounter another small stumbling block with regard to opacity differences between the two engines. In the Yahoo widget engine any object that has zero opacity is functionally equivalent to:

Code:
aboutUsLayer.visible = false;

Meaning that any layer with an opacity of zero is no longer clickable. In this case, in the yahoo widget, the layer is not visible so you cannot interact with it.  However, in Xwidget, opacity has no effect on 'clickability', any links on the layer are still clickable and you can fully interact with an invisible layer, in fact it prevents you accessing the components underneath and causes confusion when you can click on something that isn't there but it still reacts...

In my opinion, the fadeto command is less logical in the way it operates on Xwidget allowing continued interaction with a layer that is invisible. Seems wrong.

To restore the YWE functionality you will have to change the layer visibility to false once the fadeT has accomplished its task. The xwidget method of doing this is to use a synchronised timeout function:

Code:
aboutUsLayer.FadeTo(0,2);  // xwidget code to fade the layer in two seconds
setTimeout("fadeDone",2000); //the timeout in milliseconds must match the fade measured in seconds.

//function that is called when the fadeout is completed
function fadeDone () {
aboutUsLayer.visible = false;
}

My widget has a fadeout of one particular object (lastChunk) onMouseExit but requires the object to stop fading and be solid when the mouse returns, onMouseEnter. In the yahoo widget it does that by setting the object opacity to 255 (solid). This does not have the desired effect in the xwidget engine causing a flashing effect instead as the mouse moves in and out of the object. In the Xwidget engine I added an extra line of code that causes any current fadeTo that is currently underway to reverse. This visually matches the Yahoo widget's method of operation.

Code:
 lastChunk.FadeTo(255,1);

That fadeTo does not actually do what it is designed to do as it is impossible to fade away to solid, instead it simply reverses any current fadeTo that is currently underway.

-oOo-

Opacity and clickability continues to be an incompatibility as the two engines differ in operation in yet another fundamental way. In the Yahoo widget engine, if a section of an image is 100% transparent then it is not clickable, ie. if your otherwise solid image has a couple of holes in it, when you click on the hole the click goes through to the underlying area beneath.  In Xwidget there are strange occasions when a transparent area is clickable, when you have transparent areas enclosed within other transparent areas, this is in fact a bug and a recognised one but it is still extant so we have to work around it. This bug will have no effect on most widgets but strange and irregular shaped objects with transparent areas contained within other transparent areas - can operate counter intuitively and therefore may be tricky to work with.

The bug is described here with demonstration widget showing the problem: bbs.xwidget.com/viewtopic.php?…

[ My media player demonstrating areas that should not be clickable ]
clickable links
With regard to clickability, the biggest impact is that you need to be aware of layer positioning much more in Xwidgets than in yahoo widgets. In xwidget the ordering of layers is important, which layer sits above which other layer must be taken into account during the design as a transparency on one layer above can prevent a layer below from being accessible and clickable.

One niggling issue is that manual ordering of layers in the Xwidget IDE is quite difficult, you can only "bring to front" or "send to back" but you can't order a layer exactly where you want to without shuffling all the other layers. If you find your particular ordering granularity difficult to achieve, simply open the main.xul file and find the layers there. Cutting and pasteing the relevant line  and changing the order in the XML will achieve the IDE ordering you require.

Scrolling Text Fields

Another obscure one but these incompatibilities are all about the obscure. The majority of stuff will just work. This part of the how-to shows how to make text in a text box scroll continuously. The YWE text fields scroll left or right at will, all you have to do is ask the engine to do it.

Code:
  trackNameText.scrolling="left";
  trackNameText.scrolling="right";
  trackNameText.scrolling="on";
  trackNameText.scrolling="off";

It can just be set to scroll, the direction can be determined and it can be turned on/off as above. In the Xwidget engine there also exists the capability to cause text boxes to scroll but only one way - left!

Code:
  trackNameText.enabledHorzScroll="true";
  trackNameText.enabledHorzScroll="false";

The text then scrolls but only if the text is longer than its container field. This is a limitation. The YWE engine allows the text to be scrolled regardless of its length. How does this effect the widget? Well, if you have ten or so text fields and you want each to scroll left as you hover the mouse over them, only the longest texts scroll, the others sit there doing nothing. It is inconsistent and it looks wrong. I could remove this functionality completely but the point of the exercise is to migrate an existing widget's functionality to a new engine.

In my widget, when a media player track is hovered over, the text scrolls so you can read the ful track name. To fulfil this functionality some code is needed to overcome XWE's inability to scroll text in a text field that is shorter than the containing field length.

The method I chose shortens the text field length dynamically so that it is slightly shorter than the text itself. Therefore any text that is placed into the field with scroll regardless of the initial length of the field or the text length.

Code:
  playListText0.constraints.maxWidth="206"
  // in addition to the following a constraint needs to be set on the field itself, setting the maxwidth in the
  // IDE because any changes to playListText0.text.length are dynamic.
  textLength = playListText0.text.length; // count track name length
  playListText0.width = textLength * 6.5; // set the text field length for the text itself
  playListText0.enabledHorzScroll="true"; //start the scrolling

A small problem is that any text field background styling displays a foreshortened field. The solution to this is to have a duplicated but empty text field below it that is full width which displays the same styling characteristics.

OK, this is a bit obscure but my widget had scrolling text to indicate the selected media track and a solution has to be found. This is a conversion...

PS. I could also have just lengthened the text with some blank spaces and in the end that's exactly what I did...

[ the playlist showing scrolling text in my widget ]
the XWidget IDE in code mode

Let us move onto some more simple search and replaces.

Text Field Contents

Text field contents are modified with the .data property in YWE but with the  .text property in XW, replace each occurrence:

Change this:

Code:
trackNameText.data="this is the contents of a YWE text field";

To this:

Code:
trackNameText.text="this is the contents of a Xwidget text field";

Part 4 is here

Guide to converting Yahoo Widgets to Xwidget Pt4Part IV of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part III which can be found here:


Functions - The Onload function

The widget needs a starting point from which to commence operation. Within the Yahoo widget the onload function is typically defined in XML code within the .KON file in the following manner:
Code:
    <action trigger="onload">
      <![CDATA[
          startup();
      ]]>
    </action>
This onload event calls a particular function, in this case startup();
To convert this to Xwidget the following needs to occur. In the Xwidget IDE in design mode, select the widget object tree on the left hand side. Click the top level WIDGET then select the function tab (blue box) and look for the onload event - select the routine to run o

Part II of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part I which can be found here:

Guide to converting Yahoo Widgets to Xwidget Pt1Part I of a six part series
So, a how-to for converting a working Yahoo widget to an Xwidget in order to obtain a functionally identical widget on an alternative platform. Why bother? That's a question... Well, Yahoo widgets are technically obsolete though none of the technologies they use are actually in danger of just stopping working, it is just that coding for an obsolete platform is a little depressing. It makes more sense to code for an environment that is technically still alive.
Xwidget, despite the one and only developer (Tony) being largely absent from his product, is still supposedly being developed, so it is certainly more alive than the old dependable Yahoo widget engine that is no longer supported by anyone (despite still being the best out there). So, if I was going to convert any of my old yahoo widgets it would be to convert it into an Xwidget. It really helps that both the Yahoo widget engine and the Xwidget engine use javascript at their core, they both use a


Next step was to pull the code from the Yahoo widget, that was easy enough to do. I use a coder's editor called Context which runs on all flavours of Windows, it is my favourite platform for coding and I have tried a few. Context is a powerful editor which just works with no complications. It doesn't try to be an IDE nor a word processor. During the conversion process I have the context editor open with multiple tabs showing all of my Yahoo widget code, while the Xwidget IDE is open in another adjacent window. It really helps if you have a big screen or even two screens side by side.

[ The Context editor opening files in tabs ]
context editor in tabs

Opening my media player widget code in context means opening three source files, the XML .KON file that describes the widget and two other .js javascript files that store the widget's logic. In this case it was steampunk mediaplayer ywidget.kon, mediaplayer.js and functions.js.

[ The relevant Yahoo Widget files highlighted]

widget files to open

The older Yahoo widget engine often appears to have more in-built functionality than the Xwidget engine, or at least it seems that way as it is all fully documented and therefore available. You never really know what Xwidget is capable of as there is nil (zero, ne rien, not any) documentation. One real advantage it has is that you can separate your code into functionally different groups and then store that code in distinct and separate files. At runtime you can then 'include' them just as you would with any other high level language using the Include command.

Code:
    <action trigger="onload">
    <![CDATA[
    include("vitality.js");
    include("mediaPlayer.js");
    include("functions.js");
    include("Resources/Licence/Licence.js");
    startup();
    ]]>
    </action>

Unfortunately, Xwidget does not have that capability and the include function is also not part of javascript's standard capabilities. This means that you need to lump all your code together into one big file, the default script.js that Xwidget uses for each and every widget. Not very elegant but that's how it is. You simply open your yahoo widget source and copy/paste all your YWE (Yahoo widget) code to the Xwidget designer in code mode and SAVE. You need to copy all your logic sources, so you need to do the same for each included .js file in your Yahoo widget. Some logic may well be retained in the Yahoo widget's .KON file but we will extract that later.

So, we now have an Xwidget with a lot of incompatible code that needs to be converted to Xwidget standards. However, what you have achieved is actually a good start as the code you now have is standard javascript. The JavaScript engine used by Konfabulator uses the Mozilla SpiderMonkey implementation, and conforms to the Mozilla JavaScript version 1.5 standards (equivalent to ECMAScript 262 edition 3, with Mozilla extensions). XWidget uses Microsoft script host and therefore uses the current version of jscript that is installed on your version of Windows. Depending upon the version of IE/Edge that you have installed on your system you will have a version of Jscript that matches the same specification or even a later ECMAScript version. However, they should all be completely compatible. What will concern us in the conversion is just the engine-specific code, that is what will cause us a problem. All the code that controls file system i/o, desktop object placement and function calls that are unique to Xwidget is that which needs to be replaced. Remember, that none of this extra desktop, filesystem stuff is part of the original javascript specification as the language was designed for client-side web applications. Xwidget has extended javascript's capabilities to the desktop.

An example of the differences between the two javascript desktop engines: In the Yahoo widget engine x,y placement of graphical objects on the desktop is achieved by the use of .hoffset and .voffset, the first being horizontal and the latter vertical. In the xwidget engine positioning is achieved by the use of .left and .top, so each occurrence of .voffset needs to be replaced by .top &c. It is these sort of simple changes (along with some more complex ones) that will be need to made throughout the new Xwidget code - and step by step the code will become more compatible with Xwidget's expectations.

[ The XWidget IDE in code mode ]
Xwidget IDE in code mode 

The conversion has now started but now we come across the first stumbling block. Xwidget's IDE is fundamentally rubbish for coding. I know the above image of the IDE makes it look quite attractive but trust me, it isn't. The image above shows the IDE in full screen mode. The code font is fixed and just far too big, the search and replace function simply does not work at all, the search function is practically unusable, code formatting is non-existent, the editor leaves unwanted artefacts all over the page when editing or switching between designer and code mode, especially when there are other widgets on the desktop. The editor feels as if it was actually designed to put you off coding with Xwidget, it is that bad. It would have been better if it had never been included in the package.

As the Xwidget IDE code editor is so fundamentally bad, none of the bulk search/replaces can be done within the Xwidget IDE. You'll need to use your own windows default editor (probably notepad) to make all the bulk changes. Instead, I strongly suggest downloading the context editor now as it will make things much easier for you - when some images finally make it into this article I will demonstrate each step using that editor so it will be useful if you are using the same editor. You can download it here - www.contexteditor.org/index.ph…. Download the portable version.

As the Xwidget IDE is so poor we will use it only for two things, firstly for graphical composition of the widget, secondly as a debugger, running the widget from time to time to see what bugs we have introduced. The IDE is really quite good when in design mode, as a debugger it is adequate. It is only in editing where it really falls short.

Next, you'll need to find your Xwidget source code in order to edit it externally using the context editor. To find your widget's source code, in the Xwidget IDE on the bottom left you will find a folder icon. Clicking on that will take you to the widget's default folder where you will see a number of files, amongst all that you will see a file named script.js, open that file in the context editor. There is another file you will want to have open and that is main.xul. This is the XML file where the xwidget's objects and properties are defined. The .xul file directly compares to the YWE .KON file in content and form, if you open them both you will note similarities, though the format and structure is slightly different. The .KON file will appear more structured whereas the .xul file has all the object properties lumped into one long line. Note that you won't make many changes to the .xul file, it is just useful to have it open for reference later.

In addition, you will want the source code of your original yahoo widget to be available so I keep the files open in another separate instance of the context editor. You can run multiple instances of the context editor or have all your files open in tabs. I choose a mix of the two, I have two instances of context open, the YWE files open in one instance in tabs, the Xwidget files open in the other. This avoids confusion and accidental changes to the wrong set of code (it is easily done).

Running Xwidget IDE in one window and context in another leads to our first stumbling block. Any changes you make in the context editor are not recognised by the xwidget IDE, unlike more advanced editors it does not notice any code changes performed externally, nor does it have a code refresh button. If you make even one small change in the Xwidget IDE and save it, it will completely overwrite all your recent bulk changes made in Context. For this reason, while you are performing the conversion the Xwidget IDE must be completely closed and shutdown. You only open the Xwidget IDE to test your recent changes or to look for new bugs, then you close it again straight away. By experience I find this is the best way to convert a widget. In general this is also how I develop Xwidgets, the code mode of the Xwidget IDE is so appalling that I regularly switch to a proper decent editor. I suggest you make the transition and do the same, as time spent coding in the Xwidget IDE is not time in your life well spent...

The final thing I always do is to have the original Yahoo widget running on my desktop. It is useful to have a working version of the widget that you are preparing to migrate so you can remind yourself how the Xwidget version should operate when complete. It acts as your working requirements document and test plan all wrapped up in one.

[ My desktop with all the elements running during conversion ]
xwidget-development-650

What you see above is the Xwidget IDE in design mode, the Yahoo widget media player running with its debug switched on, the debug window bottom left. My default editor (Context) with two files open, script.js from the Xwidget and mediaPlayer.js from the Yahoo widget.

-oOo-

Debugging

At all stages you will want to run the code to see what your latest changes have accomplished and to see what new errors have been generated. Don't expect the widget to start displaying and working until the majority of changes have been made. The incompatibilities between the two engines will start to generate errors immediately.

Red-flagged errors in the debug log cause the debug run to stop completely, the log provides a best guess as to where the error is occurring and is normally very accurate. However, when you have an error within a function that has a function embedded within itself, for example a recursive function, the engine will have a problem determining the line where the error occurs. Instead, you are more likely to encounter a generic error relating to an object and you'll have to use your noggin to find the actual line where the error occurs. Some errors will stop your widget from working altogether and no output is generated, closing and restarting the IDE is the only way forward in this case.

There is no compilation, all the widget code is interpreted and so errors are caught at runtime.

The debugger is reasonably useful in that it indicates the line number where the error occurs and an idea of what may have caused the error. It can be confused by an accidental deletion or insertion of a curly bracket or two so be very careful when pasteing in code as an extra curly bracket can be very hard to find. The debugger is limited to simply displaying an error, unfortunately double-clicking on the highlighted message does not take you straight to the offending line in the code - which is a real pity and a lost opportunity to streamline development.

Some simple errors, such as not declaring variables, are not caught until the unassigned variable is included in a calculation. In addition leaving lines of code unterminated (no semi-colon) does not generate an error.

In general though the debugger is usable and comparable in operation to the Yahoo widget debugger.  The IDE and debug window, when running, do use a fair amount of CPU and so you would be wise to close any other Xwidgets you are running so that you remove the possibility of any contention for CPU resources.

-oOo-

You'll have noticed that I make no reference to the Yahoo Widget Engine IDE. That is because there isn't one... Is it better to have no IDE or to have one that is a bit rubbish? I'm not sure.

Part 3 is here
Guide to converting Yahoo Widgets to Xwidget Pt3Part III of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part II which can be found here:


So, let's start.
We start by doing some simple bulk copy and pastes. First of all we change the object positioning. In Context editor with the Xwidget IDE shut down, we type Ctrl+R which displays the search and replace dialog.
[ The advanced search and replace dialog in the Context editor ]
In comparison with the Xwidget code kludger we have a lot more functionality. First of all we have search history, it remembers all your previous searches. Then we have advanced search options, allowing us to search for whole words, case sensitive text from the current cursor position or from the top of the program. Using the Xwidget IDE is like bashing your head against against a marble fireplace - it is so nice when you stop.
We need to change each occurrence as below:
1. Change all .voffset to .top
2. Change all .hoffset to .l
Part I of a six part series

So, a how-to for converting a working Yahoo widget to an Xwidget in order to obtain a functionally identical widget on an alternative platform. Why bother? That's a question... Well, Yahoo widgets are technically obsolete though none of the technologies they use are actually in danger of just stopping working, it is just that coding for an obsolete platform is a little depressing. It makes more sense to code for an environment that is technically still alive.

Xwidget, despite the one and only developer (Tony) being largely absent from his product, is still supposedly being developed, so it is certainly more alive than the old dependable Yahoo widget engine that is no longer supported by anyone (despite still being the best out there). So, if I was going to convert any of my old yahoo widgets it would be to convert it into an Xwidget. It really helps that both the Yahoo widget engine and the Xwidget engine use javascript at their core, they both use a version of javascript that is compatible with each other. However the APIs are different for each and how they define the widgets on the desktop is slightly different - but still similar enough to be almost compatible. This means that any conversion will be relatively simple.

[ The Steampunk Media Player XWidget ]

xwidget media player version 1
It also helped that I had previously created an Xwidget version of my media player widget that would form the basis of the conversion. My old Xwidget Media player is a fundamentally flawed widget in that it uses the in-built media player API (core) that Tony, the Xwidget developer created a few years ago now. That API is rubbish and the functionality it provides is flawed and unusable, it makes the widget unusable too. As a result I am a little bit embarassed by how bad the widget is but at the time there was no alternative.

[ The Yahoo Widget version of the Steampunk Media Player ]
the steampunk media player widget

The good side is that the Yahoo widget version - pictured above - is very functional indeed, works very well and looks the part. All that functionality has been achieved using standard javascript and ActiveX calls. It can act as a mine of code for duplicating a functional Xwidget media player.

So I have bitten the bullet and determined that my old Xwidget Steampunk Media Player Widget is the basis for the conversion and that I will dump my bastardised old Xwidget code into the bin and instead combine the graphic composition of the Xwidget with the obsolete but better-functioning code from the Yahoo widget shown above.

[ Link to the Yahoo Widget Version ]

Steampunk MediaPlayer Ywidget 1.0.8 by yereverluvinuncleber

In truth I would not have started this conversion if I didn't have a semi-working Xwidget already created, with most of the hard work already done in composing the widget graphically within the Xwidget's IDE. I already have a working Yahoo media player widget and it functions really well. By the way, I run both the Xwidget and Yahoo widget engines simultaneously on all my desktops and they run perfectly well together so I don't need to create an Xwidget version for my own needs, I am perfectly happy with the yahoo widget version on my desktop. In this case my reasons for the conversion are:

a). because the xwidget already partially exists.
b). because the ywidget already exists.
c). it documents the conversion process.
d). it teaches me how to convert widgets for the future.
e). it gives the steampunk media player out to a wider audience of Xwidgeteers.
f). it might stimulate others to do the same (Jim King?)
g). I am a bit of a tosspot and I like doing stuff like this

The first step was to overcome the problem of a lack of documentation. Xwidget has almost ZERO documentation, a lapse on the part of the developer that is really unforgiveable. The only way to determine how Xwidget does things is from hearsay, gossip, divination, prayer, some digging around and a bit of trial and error. The forum is of no use whatsoever as it is as dead as a doornail or a Dodo or something else that is equally dead.

However, led onward by a new understanding that Xwidget uses the Microsoft Scripting Host at its core allowing the user's logic to be defined in industry-standard Jscript, while the IDE and APIs are already well-known to me, it meant that any issues could be resolved by looking at the jscript documentation provided by Microsoft and others. It also mean that activeX/COM based technologies could be used to bypass Tony's rubbish media player core as Jscript was designed to support these activeX/COM technologies. Basically it means you can extend any functionality you need by using ActiveX/COM to extract what you need from Windows itself. This is very similar to the Yahoo widget engine that gave you access to ActiveX on Windows or alternatively Apple's actionscript to access core system functions on Mac os/x.

Why am I writing this in a DA journal? Well, it documents my thought processes and the steps I took to perform the conversion. I find that when I am writing something for others to read then the quality improves and the guide sort of writes itself...  Others may find this conversion guide useful. There are many Yahoo widgets out there that need converting.

[ The XWidget under development ]
Steampunk media player Xwidget MKII RC by yereverluvinuncleber
The above link will take you to the widget that I am converting now. It is incomplete but every now and then I will update it. By all means download it but lower your expectations as it is only 90% complete. There will be bugs.

Can I ask each reader a favour? If you think I have any of the following documentation incorrectly stated in any way then please give me some feedback. With programming there are always alternatives to doing anything and I'd be more than happy to hear your suggestions. I have encountered various stumbling blocks but for each I have found a workaround. For those where I have failed you may have a solution - please provide.

-oOo-

Unpacking the Yahoo widget

What you need to do first is to view click to get this widgetthe source Yahoo widget so you can see how it is constructed. Each widget's code is implemented uniquely accorsing to the whim of the original developer and as you know, in any language there are many methods to obtain the same result. The conversion therefore will be a lesson in understanding the original developer's code and not just a straight conversion. In order to have a look in your chosen Yahoo widget you will need to open it using the widget converter.

Most widgets you will find come packaged up, zipped, so you have to unzip them before you can open them and see the contents. The widget converter that converts widgets back and forth between zip and folder formats is available here:
www.softpedia.com/get/Windows-…

When you have the widget converter installed and running on your desktop, you simply drag and drop your chosen widget to the widget converter above. It will then decompress and unpackage it for you. Assuming you have decompressed and opened your widget you'll have a widget folder and a few files within.

[ The Yahoo Widget files unpackaged ]

widget files to open
Composing the XWidget graphically

This will be a conversion of an existing Xwidget and as a result some steps will be missed, namely the creation and composition of the graphical widget within the IDE. Normally an Xwidget is created using the graphical components, images, text boxes, buttons, progress bars &c that can be styled within the IDE using the advanced effects provided by Xwidget. This is one of the main advantages of using the Xwidget engine. However, prior to Xwidget coming on the scene there was no dedicated IDE available for creating widgets of any type at all. All widgets were hand-crafted using any available art tool and then the widgets were composed by hand, each object that comprised the widget being described using hand-coded XML. Therefore there is no easy conversion method that simply takes the graphical layout of an existing yahoo widget and turns it automatically into an Xwidget.

Having said that, the XML that defines the Yahoo widget is more or less compatible with Xwidget, here is an example of the yahoo widget XML and the Xwidget XML following after:

Code:
<image
      src    = "playlistArea.png"
      name    = "playlistArea"
      hOffset    = "50"
      vOffset    = "100"
      visible         = "true"
  onMouseEnter  = "playlistAreaOnMouseEnter"
      onMouseLeave = "playlistAreaOnMouseLeave"
    onMouseDrag  = "catchFileDrop"
/>

The above code for each Yahoo widget resides in a .KON file that sits in the widget's root. It will have the same name as the widget itself.

Code:
<image name="playlistArea" width="340" height="468" src="playlistArea.png" top="100" left="50" locked="true" onMouseEnter="playlistAreaOnMouseEnter" onMouseLeave="playlistAreaOnMouseLeave" onDragDrop="catchFileDrop" acceptFileDragDrop="true"/>

The Xwidget XML always resides within main.xml and is less structured being dumped into one long line, the Yahoo widget XML is typically easier to read but as you can see, the yahoo widget XML could be inserted into the Xwidget's main.xul file with a fair certainty that it will be 90% compatible. It will be more or less correct in form if not exactly syntactically perfect. Xwidget will accept Yahoo widget XML pasted directly in structured form with no problem. Some property names will need to be changed and some incompatible code will need to be removed - but do note: one syntax error will stop the Xwidget IDE loading at all. If you are happy with coding XML and using text editors then it can be done this way but it might be a hard slog if your widget is complex.

Reading the rest of this conversion guide will show you what needs to be changed within the Yahoo widget XML file in order to shoehorn your yahoo widget into the Xwidget IDE. I suspect however that very few Xwidgeteers will want to do the conversion this way. If you are unhappy with hand-crafting XML I imagine that you will simply use the Xwidget IDE in design mode to re-compose the widget using the original Yahoo widget's parts merely as the new Xwidget's components. Assuming that you will be composing your Xwidget in this manner means that both you and I will be starting out from the same point. Let's assume we have an Xwidget composed graphically composed within the IDE.

[ The XWidget IDE in Design mode showing the widget already composed]
Xwidget IDE in design mode

One thing to note is that all the components must have exactly the same names as the yahoo widget version, uppercase and lowercase elements must be identical in all respects. This will make life much easier later. Also, make sure that Xwidget positioning and sizing is identical, look at the hoffsets and voffsets in the Yahoo widget XML to be certain of this. Some characteristics may be undefined in the Yahoo widget version, such as width and height, they are assumed and by default they are the image's actual size.

Something to note: Most of the Yahoo widget images will reside in the Resources folder, simply grab them from there and paste them into your own Xwidget project folder. You may feel the need to group your objects into 'layers' - that is fine. Layers as a concept don't exist in the YW engine so this is one area where the Xwidget engine is superior in implementation. As long as the objects retain exactly the same names then the conversion will not be affected.

Note - when you move objects to a layer, make sure the layer is sized correctly first as your image objects will all be bunched together on an incorrectly sized layer.

-oOo-

Stripping out the old XWidget

So, the conversion started.

You won't need to do any of this next bit in a straight Yahoo to Xwidget conversion but I'll  document it here as it is part of the particular conversion that I was undertaking. I'm taking parts from two widgets to make one new one.

First of all I took my old media player Xwidget and using the Xwidget IDE in code mode, I stripped out all the old code. Easily done by selecting the code window and CTRL+A then delete! Gone.

You might think that this strips all functionality from the widget but you'd be wrong. In Xwidget most of the functionality is in the embedded API cores, in an Xwidget the javascript code is meant to act merely as the logic glue between the graphical IDE, the user's graphical objects and the API cores.

The next task was then to remove the nasty media player core from the widget. As you build widgets, if you require additional functionality you drop ready-made cores onto your widget, each giving you access to certain system functions. Conversely, to remove an unwanted core you simply open the IDE in design mode, find the cores at the bottom, right click on each core you want to remove, in this case the media player core - and remove it from your widget. 

A multitude of controls will be bound to that now-missing core. You need to look at each image object in turn, and look to see which are bound to the core, each will have to be unbound by assigning no core and removing any tags that operated the core. Both fields should be empty. When done, the widget will have no logic and exist purely as a graphical entity that can run - but do nothing at all.

[ The XWidget binding core dropdown ]
the XWidget binding core dropdown

Now, the code. I said earlier that Xwidget just uses javascript merely as the 'glue' to join extra bits of user logic to the cores and the graphics. However, Jscript is much, much, much more than that. It is fully functional javascript, Microsoft's reverse-engineering of javascript. Jscript is so flexible and powerful that you do not need to use any of Tony's cores and if you want you can code the whole logic of any program in Jscript and activeX - or so I bravely told myself...

Part 2 is here
  Guide to converting Yahoo Widgets to Xwidget Pt2Part II of the guide to converting a Yahoo widget to a Xwidget, this guide follows on from Part I which can be found here:


Next step was to pull the code from the Yahoo widget, that was easy enough to do. I use a coder's editor called Context which runs on all flavours of Windows, it is my favourite platform for coding and I have tried a few. Context is a powerful editor which just works with no complications. It doesn't try to be an IDE nor a word processor. During the conversion process I have the context editor open with multiple tabs showing all of my Yahoo widget code, while the Xwidget IDE is open in another adjacent window. It really helps if you have a big screen or even two screens side by side.
[ The Context editor opening files in tabs ]
Opening my media player widget code in context means opening three source files, the XML .KON file that describes the widget and two other .js javascript files that store the widget's logic. In

Xwidget is almost a delightful environment in which to design and code, however it has several limitations that make it a real pain in the behind to actually use. One of the limitations is that we are limited to the basic controls that the developer Tony provides. He codes the interface to certain windows core functions and then us poor widget creators have to use the few APIs/cores that Tony provides. If they exist at all and are any good then the Xwidget designers have an easy time as all the heavy-lifting is done by each 'core'. All the complex code is built-in, as it were.

However, this is only useful for the very few cores that Tony has designed. Some of those existing cores are out-of-date and some aren't very good (ie. the mediaplayer core), even worse than that though, is that some essential cores are completely missing. If you want a core to do such things as allowing automated and easy access to VLC player or Open Hardware Monitor then that core does not exist. You are stuck with having to write your own code.

We have access to very little documentation but there does exist documentation and methodology from other sources that allows us to create our own methods in code but that is sparse, hard to find and not directly related to xwidget. However, if you search for jscript, COM and activeXobject the internet will provide some examples on how to integrate ActiveX objects into your own code.

As an example, it is relatively straightforward to extend the Xwidget engine's javascript to allow it to interface via COM to Windows object control extensions (ocx). In this manner you can extend javascript functionality to allow access to other Windows components such as Windows Media Player's API without requiring a 'core' at all. You do it all in code instead.

eg.
// creating a new instance of the windows media player
var WMPlayer = new ActiveXObject("WMPlayer.OCX.7");

// commands that cause the WMP do this or that
WMPlayer.settings.setMode("loop", false);
WMPlayer.settings.autoStart = false;
WMPlayer.settings.mute = false;

// dialog box to open an audio media file for playing
fileName = OpenFileDialog("");

// use WMPlayer to play the file
WMPlayer.URL = fileName;
var counter = WMPlayer.currentPlaylist.count;
WMPlayer.controls.play();
.
.
//and other similar WMPlayer commands...

We no longer have to make do with Tony's (slightly rubbish) media player core and can manipulate the audio tracks as we require.

I already have a fully working Yahoo widget with all the necessary ActiveX/javascript code ready created to interface /control Windows media player and as Xwidget has full ActiveX COM integration and javascript, all that logic is transferable and I so am able to migrate the code to Xwidget to allow a widget to control the Windows Media Player via activeX within Xwidget too. That conversion for this is actually underway.

Downside: As we have created our own new instance of the WMPlayer object you have to disassociate (unbind) all your controls that are currently bound to Tony's media player core. Using Tony's media player core in your widget creates its own instance of the WMPlayer object which will play/control another track of its choosing simultaneously. You won't be able to interact with it manually with code using the above methods, it would be like having two media players within one widget!

Basically, you have to use your own code or Tony's core exclusively but that is no real problem as Tony's media player core is just a little bit rubbish (have I said that before?).

As an example I am converting my original Xwidget media player, stripping out the bits that require Tony's core and then migrating my Yahoo widget activeX code, lock, stock and barrel to the Xwidget engine. It'll work.

player
See addendum with regard to price.

There is a new entry into the desktop widget/customisation world and that goes by the name of PlexyDesk. PlexyDesk was originally an open source Ubuntu-based application designed to provide desktop widgets and multiple workspaces (desktops) on version 16.04 of that environment. PlexyDesk has been around for a while on Ubuntu but has recently grown in capability so that it now provides the identical desktop/widget functionality not only on Ubuntu but now Windows and Mac OSX. PlexyDesk's main competitors are Xwidget, Rainmeter and the Yahoo Widget Engine all of which have been extant for some years now. You'd have thought this was tough competition for a new widget engine but all of these competitors are deficient in some way, the Yahoo widget engine is a dead-end being unsupported abandonware, the Xwidget engine has a developer but he is uncommunicative and seldom available, updates have been thin in the ground for years now. Rainmeter has limitations with regard to the ability to perform complex animations efficiently, it just isn't designed for that.

So, in comparison to the others there is still a real need for a true multi-platform widget engine that is scriptable, supports transparencies, handles animation, that can create odd-shaped programs that do not conform to the old fashioned square window paradigm.

The current version of Plexydesk is still beta but provides multiple desktops (workspaces), background image management and a default set of widgets which includes:

    Note pad
    Clock
    Timer
    Calendar
    Task pad



As you can see, some quite uninspiring widgets running on an Ubuntu desktop. Not the most graphically exciting of widgets in comparison to my own steampunk monstrosities but it shows the default set in operation.

Supposedly there is 3rd party developer support that allows you to write your own widgets using QML and HTML but information is thin on the ground at the moment and I have not yet shelled out the required $0.99 which is required to download the beta version of the software. The use of QML indirectly implies that javascript will be supported to allow the logic of the program to be controlled (QML traditionally uses javascript for its imperative logic). This bodes well for existing developers of other javascript based widget engines such as the Yahoo widget engine (and Xwidget users that may be familiar with javascript to a lesser extent) as there exists the possibility that some Yahoo/Xwidgets could be ported to run on Linux/Mac platforms.

ADDENDUM:

I have been in touch with the developers and the high $9.99 price indicated on their website was a simple mistake during technical testing! Plexydesk actually costs just less than a dollar which makes the software much more accessible than initially thought.

-oOo-

The product is new so we can't expect much at the moment, some bugs perhaps but if the developers really manage to create a true multi-platform engine that allows widgeteers to create thin client apps in QML/javascript with full access to the OS via well-coded APIs  - all this sounds very nice indeed. Possibly a fitting replacement for the no-longer-supported yahoo widget engine and an alternative/complement to Xwidget?

At the moment the documentation is sparse, there is no designer GUI (which will put off the Xwidget community) and there is a small price to pay. I don't expect everyone to dive in and start using it immediately, given that it is in beta too. However, I would keep an eye out for it here at their website: plexydesk.org/

Read through the site, it is quite new and as a result it is choc-full of typos, grammar mistakes and chopped text but be positive and hope that it will all mature soon enough.

:iconyahoowidgeteers:
NOTE: this journal was re-created from the original at yahoowidgeteers as group-specific journal entries cannot be submitted to other groups.

ADDENDUM: I've submitted this to a few groups that are interested in customisation of the Windows/Linux and MacOSX desktop, as I feel it is of interest to all such groups - however, if you feel that you don't want to accept a journal then that's fine by me - I won't be hurt!
The weekend's recent site changes seem to have resulted in a very slow DeviantART. Submitting journal entries was almost impossible yesterday, the site response being SO slow... Timeouts caused duplication when creating journals, editing and correcting my journal was painful. Clicking from one group to another was mind-bogglingly slow. The DeviantART main page has always been one of the slowest of all sites that I visit but recently the extra grind has been quite off-putting. I know DA has built a lot of functionality built into each and every page but perhaps it is over the top, possibly the servers are under-spec'ed? Anyway the latest changes seem to have brought it all to a head.

Has anyone else noticed the slowdown or is it just me?
I have a new version of the weather widget on my laptop. The changes include a new metal surround that gives the wind direction in pictorial form, an arrow pointing toward a scale in degrees incorporating compass directions. It also has the beginning of a TAF (forecast) weather display for the next few days and some new metar weather icons for the more exotic weather types (smoke, volcano, twister &c). These last few weren't on my priority list, given that we don't experience much of these latter weather types in the UK...

When I have the new widget finished I will post it here.
weather widget mkIII

Every now and then one needs a little diversion, something different from your own personal norm. Hopefully these two upstanding and fine

dee-plume-140.jpg

sue-denim-140.jpg young ladies will provide a little diversion for you with this little musical piece, composed especially with you in mind...

 

Who are Robots in Disguise?  - Robots in Disguise are an English electropunk band composed of Dee Plume (vocals and guitar), Sue Denim (vocals and bass) and a changing line-up of backing musicians. The group, formed in 2000, have released four studio albums and are currently based in Berlin and London. Despite the classification as Electropunk their music is harder to categorise than you would expect. If you listen to any of their main tracks you will find that each is very different from the last. Do not expect any of their other tracks to be drawn from the same mould as they certainly are not.


 
 

The wonder of the mighty Boosh! May the Hitcher never leave us... "Elements of the past and the future combining - to make something not quite as good as either".

hitcher-300.jpgIf you don't really understand - don't let that worry you, just keep watching and you might just "get it". If you don't get it don't worry, it is not that important, just watch the video below and you might get a flavour of the ripper-type character from the Mighty Boosh.

The Mighty Boosh is a British comedy troupe featuring comedians Julian Barratt and Noel Fielding. Developed from 3 stage shows and a 6-episode radio series, it has since spawned a total of 20 television episodes for BBC Three and 2 live tours of the UK, as well as 2 live shows in the United States. 

Noel Fielding has become a little bit of a cult figure amongst a certain type of young-ish person here in the UK. He's a little bit 'this' and a little bit 'that' and the result is that he is quite appealling. Julian Barrats eems to play second fiddle to Noel acting as his 'straight man' as it were, but he is the actual genius behind the duo. Watch a few of their songs and be aware they come from Julian's brain and you'll begin to understand there is a more complex character than demonstrated in his character of Howard Moon.

The pictures you see here are modifications of originals featuring a Jack the Ripper type of person, this is a very close match to one of Julian's creations the Cockney Hitcher. Do enjoy the video and the images. 

 

 

hitcher-in-london-600.jpg




A brief note to let you know of another Steampunk kinematographical creation that is coming your way in the fullness of time. Terry Jones of the Monty Python team has used his full and rather starnge imagination to come up with the idea of the British empire conquering the moon in 1884... his idea? I thought it had already happened. How strange. Anyhow, here it is,  '1884' Terry Gilliam presents '1884 Yesterdays Future'.





 

 The website for 1884 Yesterday's future can be found here:

 daily-empire-500.jpg

www.1884yesterdaysfuture.com/h…

This one's been around for a while (2006) but it does not diminish the slickness, the comedy and the professionalism as well as the sheer fun embodied in this creative steampunk masterpiece. This steampunk duel between an animated Englishman and his comedy French counterpart over a delightfully well-endowed female is fought out using weapons from a deeply-steampunk creative mind. Blur Studios were a small player in the CGI field but recently have been growing apace having created all the space sequences in James Cameron's 2009 blockbuster film Avatar.

Enjoy the full animated film now, very entertaining indeed. Have fun!


Ladies and Gentleman, we present a complete steampunk makeover for your PC windows 7 system. Some of it will also apply to Mac OS/X, at least the Yahoo widget bit will. the end result is probably the bsusiest desktop you've ever seen. Enjoy the video created by Christophe Maanebarth.

 

If you enjoy the video do please open it on youtube and 'like' it.


Some more War of the worlds imagery, a render that was not shown here before: The Thunderchild prior to battle. Complete with music. Officionados of Jeff Wayne's War of the worlds music will appreciate this.

I don't think I ever managed to post this version here before, a reinterpretation of HG Wells/Jeff Wayne's thunderchild. Just a render of a scene with some animation tools used to make the scene come to life. No real animation yet of the Tripods nor the ship but some nicely performed music added to give the scene some depth and emotional appeal.

An image will do as a taster:

thunderchild-600.jpg

The video was a germ of an idea, a low res short period-shot movie based on 2D and 3D models. Note the low quality period-film effect is deliberate, there are a few errors, long range smoke visibility and the prow of the steam packet but please ignore these.

 

 

We were originally thinking about a kickstarter to get it off the ground. A very short film sequence, a couple of minutes long, Pathe-news style, sound effects, moody music, somewhat similar to the more moody bits in this Jeff Wayne reinterpretation. What do you think?

Whether or not it will develop is all down to time (and money) It is quite difficult to make progress on a project unofficially unless it is all done by one man and that simply takes a lot of time. If it was real project with defined goals, cash to spend &c it could be done relatively much quicker.

The idea was that it would start on a sailor's desktop with orders requiring his immediate return to ship for sailing, the scene would then zoom into the photo on the desktop and then it would come alive and open to the scene of the Thunderchild in action against the Martians.



The date was to be 1921-25, the time of the second Martian invasion where they come equipped with the same technology (realising the overwhelming superiority of their machinery) but fitted with bacteriological filters allowing them to survive in Earth's germ-laden atmosphere. This time they come in fewer numbers having almost exhausted their resources in the first invasion and of course, this time the human defences are better-prepared. In this timeline we get to see Thunderchild II in action. Anyhow, that was the vague idea.

We also had an idea of an old stamp album showing this stamp with the following description:

steampunk_martian_stamp_ico.png"This is a stamp created by Eric Gill in 1924 for the British Empire Exhibition with the emergency overprint "under martian rule" for a set of stamps which were produced in that portion of the British Isles still allowed to function - whilst operating under the yoke of the Martian Empire subsequent to the second Martian invasion in 1925.

Not many items survive from this period and this is reflected in the condition of the stamp. The bottom right hand corner is severely burnt as the stamp was recovered from the remains of Plymouth Post Office destroyed during the battle for the Tamar Bridge at Saltash. Approximate value £26 guineas."
If you are even slightly into the genre known as Steampunk then Iron Sky is definitely a film for you. This video has almost everything you need, steampunk, almost gothic technology, airships in space, Nazis in full uniform being very very nasty, hauntingly beautiful music. What's not to like?

Journal History

Critiques

by acg3fly

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

Comments


Add a Comment:
 
:iconjackfork86:
JACKFORK86 Featured By Owner May 7, 2017  New Deviant Hobbyist
Hello. Love your work! Amazing detail
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner May 8, 2017  Professional Interface Designer
Thankyou.
Reply
:iconmattannat:
Mattannat Featured By Owner May 6, 2017  New Deviant
;) (Wink) Hi everyone,
I have an old (large) motorhome which I'm rebuilding with my teenage son. He'd love to use a steam-punk theme on the exterior, so we're looking for stuff which would blow up to a decent size. So far we love the designs made by yereverlovincleber. Any ideas where we could get permitted images to be included?
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner May 7, 2017  Professional Interface Designer
You'd have to expand the images yourself but they should stand scrutiny enlarged as long as you aren't looking too close. You have my permission to use the images as long as they aren't for commercial gain... I created them so I can give permission.
Reply
:iconmattannat:
Mattannat Featured By Owner May 11, 2017  New Deviant
Hi, Many thanks for that (I just got both of your replies together). I have a mate who is going to help, so he'll download in the next few days and see what he can do. And, of course, I'll both credit you somewhere on the finished artwork and send you a copy if you wish. 
PS, can I ask if you have artwork showing a simple kit of 3D pipework bits: bends, tee pieces and crossovers, which would connect all of your widgets together?
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner May 11, 2017  Professional Interface Designer
I don't have that much in the way of pipes and connectors. Do look up two characters here on DA, the first is resobrain and the other is mordasius, they will both have what you need to fill in the blanks.
Reply
:iconabelmvada:
AbelMvada Featured By Owner May 3, 2017   Digital Artist
Hi, there - welcome to :iconatariforce:!
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner May 4, 2017  Professional Interface Designer
ta!
Reply
:iconbillking:
billking Featured By Owner Apr 3, 2017
Hey, thanks for the fave. ;)
Reply
:iconwirecase:
Wirecase Featured By Owner Mar 27, 2017  Hobbyist Artisan Crafter
Thanks for the :+fav:!
Reply
Add a Comment: