Shop Forum More Submit  Join Login
Part I of a seven 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 as Yahoo have withdrawn support 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 absent from his product for two years, is still supposedly being developed (version 1.96 just released!), 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 old widget was 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 Media Player Yahoo Konfabulator 1.0.13 R 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 a complete Ywidget already exists.
c). it documents the conversion process.
d). it teaches me how to convert widgets for the future.
e). it documents how some undocumented parts of Xwidget are expected to work.
f).  it helps to raise bugs/issues that Xwidget currently provides.
g). it gives the steampunk media player out to a wider audience of Xwidgeteers.
h). it might stimulate others to do the same (Jim King?)
i). the Xwidget media player API is very bad and it has to be replaced
j). I am a bit of a tosspot and I like doing stuff like this

The final big bonus from such a migration is that if I make any changes (or fix any bugs) then the same code changes apply to both widgets, each is equally easy to patch and the codebase remains more or less the same. By the time you read this I will have completed the migration and I can state now that 92-95% of the code is exactly the same and anyone with javascript skills could understand both widgets.

What this tutorial does prove is how difficult it would be to create a conversion tool that converted Yahoo widgets to Xwidgets automatically. You'll see that this guide turns to seven pages of description on how to convert just this one widget. I had originally determined to create such a tool but the scope would have to be broad and the logic would be complex. Instead the guide will serve as a process, when you have a widget to convert use the guide, go though it step by step and convert your widget on the fly. By the end of this guide there is a good chance you'll have a working widget. This guide does not cover all of the differences - it can't as its scope is limited to the conversion of just one media player widget, however what is in the guide will get you 85% of the way there. Good luck to you in your first conversion!

-oOo-

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 with a spade 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.

When you have zero documentation the problem is doubled as you don't know what the engine actually provides and you can end up assuming it does things it really doesn't.

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 all down 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 writes itself...  Others may find this conversion guide useful as there are many Yahoo widgets out there that need converting.

[ The XWidget under development ]
Steampunk media player Xwidget 2.0.1 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 still only 99% complete. There will be bugs.

-oOo-

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 the 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"
/>

It can also be expressed in one long line as follows:

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, for example: steampunk mediaplayer.kon

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.

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"/>

If the Yahoo widget XML is copied staright over it will be more or less correct in form if not exactly syntactically perfect. Xwidget will more or less 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.

However, this is doing it the hard way and it is not necessary. If you aren't a code slogger then you may prefer to use the Xwidget IDE and merge your code this way. 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 transpose directly to the YW engine as 'frames'. As long as the image 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.

PS. If you design your widgets in Photoshop you may want to have a look at this tool, it is a script for Photoshop that creates Xwidgets on the fly from your Photoshop design. If all the layers within the PSD file are named correctly it will do the graphic composition of your Xwidget for you automatically.

[ Link to the Photoshop script to create Xwidgets ]
1.0 Photoshop Xwidget creation script by yereverluvinuncleber

-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

Add a Comment:
 
:iconcompass-uk:
compass-uk Featured By Owner Apr 25, 2017  Hobbyist Artist
Ha! I hear you about the documentation aspect, or as you put it, lack thereof.
The code suggest function in the IDE makes tantalising suggestions of functionality, but just don't quite make it.

A couple of days ago, I did discover a widget engine called KLUDGET. Every widget is a package of XML, HTML, JS & CSS, with resources of course. It looks like it had potential, but the website indicates that it has been in a status of Hiatus for years now.

It would be interesting if someone was to pick up the Konfabulator/Yahoo widget engine again.
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner Edited Apr 26, 2017  Professional Interface Designer
The Xwidget inline hints tell of endless possibilities and combinations, none of which seem to help, none seem to work nor have anything to do with what you are currently typing. Also very helpful having the first letter of your command removed... or replaced with something completely random. I've never known a worse system. Microsoft has Intellisense, Xwidget has Intellibollox.

I've known about Kludgets for a few years now (well done finding that BTW) and was in touch then with the developer (Martin) when he released version 1.0. Strangely, he dropped it like a hot stone as soon as it was released and it is now abandonware. He was going to make it Yahoo widget compatible but then simply disappeared.

The code is on github I think and it is fully open source but there is no documentation, no guide, written in C++ and a one-man operation so unless you were a very good C++ coder I doubt that you'd make much headway. If it had a thriving community and good documentation, it would make sense to take it on but hardly anyone uses it due to its abandonware status. Xwidget would be worth taking on but it is held too tightly to Tony's sleeping chest...

The code for the YWE is owned by Yahoo and they currently use it in all the Samsung widget style TVs, Yahoo connected TV is what they call it. It runs on an IoT device running Ubuntu 13.0.n.  As such it will not be released on open source, ever. More's the pity.
Reply
:iconcompass-uk:
compass-uk Featured By Owner Apr 26, 2017  Hobbyist Artist
Interesting about what Yahoo are doing with the Widget engine. I thought it was acquisition that got abandoned as well.

But as for C++, my knowledge ends at knowing it is an application language. Sure, as a programmer, I could probably read the code and get the gist of what some of it was doing, but it is not a language that I have indulged in.

Maybe XWidget v2 will better, and address the script runtime element better.
… one can hope. There are things I would like to do, could never get to work.
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner Jun 5, 2017  Professional Interface Designer
I think Xwidget 2.0 is now delayed. I think there will be, instead, a Xwidget 1.94 fixing all the bugs in version 1.0 and adding an enhanced Pro version.
Reply
:iconcompass-uk:
compass-uk Featured By Owner Jun 7, 2017  Hobbyist Artist
Bug fixing sounds fine.
I've been missing the "!Eject" function on the drive core, assuming that gets fixed…

But "Enhanced Pro" version?
Well, it sounds interesting, but I'll be curious as to what it entails.
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner Jun 8, 2017  Professional Interface Designer
We are convincing Tony to fix bugs and to sort the editor, to abandon ver. 2.0 and to focus on usability issues. I am trying to push him in a direction - the idea is to provide a commercial-grade dev environment and a runtime for everyone else. Possibly, everyone else gets the buggy environment or the IDE with adverts. My suggestion is that the android users get the same. There will be a donation button too.
Reply
:iconcompass-uk:
compass-uk Featured By Owner Jun 8, 2017  Hobbyist Artist
Are you suggesting a split in the package, runtime and widget manager; and the IDE being separate using or including the runtime?

I guess adverts in the IDE wouldn't be too bad, so long as they weren't video with sound, they annoy me, and startle me when it is late and quiet, and sometimes my volume is not set to a late night discrete setting…
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner Jun 8, 2017  Professional Interface Designer
Something along those lines. In the end it is down to the dev. I've made my thoughts known, the idea is to monetise xwidget to give Tony some income and the first step is to fix it.

Then there are widgets that are free and a pro dev IDE that you pay for. Might be a few pounds/dollars and donate button on the menu for another small amount. I still don't know the advert thing might pan out.
Reply
(1 Reply)
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner Edited Apr 26, 2017  Professional Interface Designer
The YWE is being used more than it ever was, being installed in hundreds of thousands if not millions of Tellies by default. Whether it will continue to be so successful in the future is another thing entirely but it certainly isn't abandonware. I keep an eye out for it on occasion but that's all. The widgets there on connected TV are closed-shop and not for the casual developer.

If you know javascript it leads you into C++ but a brain that scripts in javascript and another that codes in C++ are two entirely different things. :)

In my opinion we really don't want xwidget 2.0. It will be late (very), full of lots of new bugs, GUI inconsistencies, incompatibilities, new and undocumented functionality and something fundamental will be broken. We simply need Xwidget 1.0 with all the bugs fixed before any attempt at Xwidget 2.0 is even looked at. Tony won't do it the 'proper' way though, it isn't his style sadly.

Nice to talk to you, please comment freely. What was it that you wanted to do in Xwidget but could never get to work? I am more positive about Xwidget now than I was having just successfully migrated quite a complex widget.
Reply
:iconcompass-uk:
compass-uk Featured By Owner Apr 26, 2017  Hobbyist Artist
That may depend upon the magnitude of rewrite between versions 1.x and 2.0 as to the degree of infestation of bugs.

I was actually trying to adjust the colour of a progress bar via scripting.
Code like;
  progressbar1.fore.color(255,0,0);
Ended up with a response like;
  Object doesn't support this property or method

The fore.color method worked well with the roundline object, so I thought it should work (idealistic I suppose).

A directory of objects and supported cores and methods would be a great help. But while the auto code completer offers, apparently, every method to any object, it gets a bit frustrating; sometimes.

It's been 2 years since I last created a widget, I am probably overdue to build another (LOL).
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner Apr 26, 2017  Professional Interface Designer
Experience of Tony's deliveries shows me the type of developer he is, very clever and interested in new technologies, techniques of achieving things. Not a finisher nor a do-it-right type of chap. In all these years no bug reporting system, not an acknowledgement of a bug nor any documentation for such a complex project. Xwidget is an impressive achievement and it deserved more attention from Tony.

Xwidget 2.0 is a complete rewrite, new technology. Therefore lots of bugs.

foreground.color should work but doesn't always. Perhaps it should have been progressbar1.foreground.solidColor.color="rgba(255,0,0,1)";

I have a text field that should show grey and it does so successfully, however all subsequent text fields show solid white even using the same code.

    playListText0.background.solidColor.enabled="true";
    playListText0.background.solidColor.color="rgba(255,255,255,0.06)"; // grey

    playListText1.background.solidColor.enabled="true";
    playListText1.background.solidColor.color="rgba(255,255,255,0.06)"; // white

I will add this inconsistency to the how-to when I have researched it correctly and I'm sure of the problem.
Reply
:iconcompass-uk:
compass-uk Featured By Owner Apr 26, 2017  Hobbyist Artist
I'd never seen 'foreground.solidcolor' before, but that's not surprising, unfortunately, XWidget wasn't too keen on it either;
    'progressbar1.foreground.solidcolor' is null or not an object

Well, thanks for the suggestion.

I did just think up another possible solution, and that would be to replicate the ProgressBar in the required colour and make it visible on demand. Yuck! What an *inefficient* solution. Especially when the plan was to employ 5 colours.

I'll need to ponder on a lateral solution for this problem I think.
Reply
:iconyereverluvinuncleber:
yereverluvinuncleber Featured By Owner Apr 26, 2017  Professional Interface Designer
That's the problem, one parameter that works on one element does not necessarily work on another. Try this variation:

progressbar1.foreground.solidColor = "rgba(128,128,128)";
Reply
(1 Reply)
Add a Comment:
 
×

:iconyereverluvinuncleber: More from yereverluvinuncleber



More from DeviantArt



Details

Submitted on
April 25, 2017
Link
Thumb

Stats

Views
4,235 (3 today)
Favourites
1 (who?)
Comments
62