DesktopX: External scripts

Preview of DesktopX 3.2

3.2 Preview Guide

Our story so far...

DesktopX was the first program (for PC or Mac) that enabled end-users to easily create desktop objects that could be combined together to form mini-programs commonly referred to as widgets (or gadgets) or used to design an entire desktop environment.

Over the past few years, widgets and gadgets have become very popular with Microsoft, Yahoo, Google, and others all getting into the act.  In power, no other platform can deliver what DesktopX can do.  With that power, however, comes complexity.  Stardock has continued to focus on ways to make it easier for developers and artists to fully harness the power of DesktopX.

Another important event is the coming of Microsoft gadgets.  Microsoft's gadget concept is very similar to what DesktopX can do.  Stardock's long-term goal is to enable users to export their DesktopX creations as Microsoft gadgets.  The powerful development tools and underlying DesktopX technology (called DirectGUI) will be able to be used to create Windows sidebar gadgets and more.

The first step in that path is DesktopX 3.2 which has two main new features:

  1. Windows Vista compatibility.  Content made with DesktopX 3.2 will work on Windows Vista.
  2. Scripts can now be externally located making it much easier for content makers to create their own library of scripts.

A new development environment

Most end users won't really notice the difference between 3.1 and 3.2.  What they will notice is an increased variety in the types of scripts and hopefully, more content from desktop, gadget, and widget creators since the process of creating "Stuff" is streamlined.

For this example, I am going to make a dictionary widget. Please note I am not an artist. I'm a software developer so the graphics in this will be painful.

Example: Dictionary widget

One of the advantages DesktopX has over other "widget" enablers is that it provides a GUI for most of the common, tedious work.  You don't, for instance, have to (though you can if you want) define images and objects using some text editor.  In DesktopX, it's all GUI driven.  Try to create a dictionary widget as easily in any other platform.

Step #1: Background window

From the DesktopX Helper toolbox, I press "Create object". Then I go to its properties and press the change appearance button which opens a dialog asking me to provide the image. I provide the image.

Step #2: Provide the text input box

The user has to have something to type their word they're looking up into. So I go through the same object creation procedure as before except for this:

I press "New" on script which opens up the script editor box. Then I choose ActiveX control. Then I choose DesktopX edit control. (I agree, we should have really common controls not require the user to go through this but this also exposes users to all the possibilities -- your computer is full of objects already. DesktopX lets you make use of them easily on your desktop).

Then just exit the dialog.  Now, HOLD DOWN THE CONTROL KEY when you click on that object and you can resize it. 

Step #3: Create the text output area

Now we need the area to output the definition. So go through the same object creation method as before (you can also create a new object from the DesktopX system tray item). One change though:

On the "States" page change the appearance from Image to Text.

Now, you can get pretty smug because you can visually change all the text settings from this GUI rather than mucking with it in some ASCII text editor.  Get it the color and size you want first.  And thinking ahead here, you will want to make sure it word wraps. So go to the summary page and set its width in pixels. I'm going to set it to 400.

Anyone who's made widgets or gadgets knows how annoying it can be to do this in script.  By contrast, the total time taken so far is about 30 seconds to create this widget (other than making the tutorial).  Did I mention our goal for Windows Vista is to allow creations to go onto the Windows Sidebar?

Step #4: Write the script

This is where we part ways with really casual users. If you're not a developer, this part may be confusing.

The first thing we need to do is give these objects some names so that they can talk to each other. On the summary page is the ObjectID. Name your objects something you can remember (like Dictionary_Text) on the object we just created.

I'm going to write two scripts. The first script is a tiny one that I'll attach to the edit field.

Here's my script:

Sub Control_OnKeyPress(AsciiValue)
 If AsciiValue = 13 Then
     DesktopX.ScriptObject("Dictionary_Text").LookItUp
 End If
End Sub

All I'm doing is looking for Ascii value 13 (which is the enter key basically) to be pressed and then  I'm going to call "LookItUp" in my text object which will grab the contents and send it to dictionary.com.  I am going to name the entry field object "Dictionary_EntryField" so that I can refer to it.

The second script is more complicated and here is where DesktopX 3.2 starts to shine -- dynamic scripts.  I'm going to write the script in Visual Studio.  Special thanks to Sranshaft who made a dictionary object that I could use as the basis of this.

The one annoying thing I ran into that we're trying to think of a more convenient solution is that when you change your script in Visual Studio, you have to go to the object that is using it, right click on it, and toggle "script enable" back and forth in order for it to update what's there.  If anyone has any preferences on how we essentially "reload" the script to be "recompiled" on the fly, let us know.

Anyway, so I took Sranshaft's dictionary script and modified it.  It's not very long. In fact, most of it is just replacing the junk in the response with blank characters (i.e. getting rid of the HTML characters).

Step #5: Connect the script to the object.

Now I need to go back to my text object and connect the script:

I wrote my script over in my "c:\projects\dxdev\scripts\dictionaryscript.vbs". 

So why do it this way? Why have your scripts be external to the object? In DesktopX 3.1, you couldn't. The idea was to have scripts be totally integrated into the object.  The problem with that is re-usability. It's a lot easier for developers to have a library of scripts that they make that they can then just refer to.  Over time, depending on feedback and interest, we can make this even easier to do.  The other reason to do this is to prevent catastrophic loss.  For instance, while I was modifying this script and testing the output, I got a huge overflow that brought down DesktopX.  No problem, I just restarted DesktopX and it remembered my last state. But there's a dialog that pops up asking if you want to erase everything (in the event you get yourself into an endless loop or something). If I had answered that incorrectly, I would have lost my work.  But with external scripts, I don't lose all my work, the scripts are still there on my hard drive, easy to find.

External scripts also benefit for users who use real-time data protection programs like KeepSafe which will create revisions of your creations so that if you really screw something up, you can go back to a previous version (and if you don't have KeepSafe already installed, quit reading this and go get it RIGHT NOW).

Step #6: Clean up and finish

Now it's just a matter of taking the 3 objects I created and putting them together.

This just means dragging the 3 objects around on screen until you've positioned them the way you want and then grouping them. Don't forget to hold the CTRL key down when you are moving the ActiveX control.

I just drag select the objects, right click and choose "group".

And then voila.

Step 7: Export it to a widget.

DesktopX 3.2 widgets are .EXEs. So as long as you have DesktopX installed, you can use them like any EXE.  Using Keyboard LaunchPad I then assign them a hot key so that when I need something like currency conversion or dictionary lookup or whatever, I just hit a hot key to bring it up.

To export as a widget just select all the objects, right click, and choose Export as widget which will take the user through the steps of assigning it an icon and the file name.

And voila.

We're still working out some of the kinks such as how to handle external scripts when it comes time to package them. Do we allow users who import widgets that use external scripts to see them? Could this be used as a way for people to protect their code? Hence, why DesktopX 3.2 is still in beta. But you can see where we're going.

DesktopX 3.2 is in beta. If you have Object Desktop, DesktopX is one of the programs that comes with it (along with WindowBlinds, IconPackager, Keyboard LaunchPad, etc.).

43,084 views 27 replies
Reply #1 Top
DesktopX 3.2 is in beta

When might this beta be available on SDC?
Reply #2 Top
For the script refreshing. I'd say, add an entry to the right-click menu that allows you to refresh the script. And also a button in the properties dialogbox.

One of the things I had hoped to use external scripts for was to create scriptable object completely from scratch via script. I had hoped to be able to create an object, set it states and appearance and then assign a script to it. But from what I gather you can only assign scripts to objects already assigned a script. Can this be addressed in any way?
I'm currently making a desktop theme with various "smart" shortcuts. And the way DX works now I'd have to make dummy objects for each of the various types of "smart" shortcuts and then clone it. I'd much rather prefer to be able to create it all from loading scripts into objects created by script. Also, another nice feature to compliment that would be to be able to define the appearance of an object with all it's states in, say a XML file so you could also have a library of predefined objects.

So in my Utopian scenario Id' have a script like this:

DesktopX.CreateObject("newObject")
DesktopX.Object("newObject").LoadXMLScheme("someScheme.xml")
DesktopX.Object("newObject").SetScript("someScript.js")

And voilà!


I think that widget scripts should be possible to read by anyone. For gadgets however I think it'd be good to have an option when you compile whether to make the scripts private or public.




hmm..... I just came to wonder if I got all this right. Does external scripts have to be defined in DesktopX Builder first before it can be used? I mean, can you make an object load an external script by letting the user provive the path to it?
Reply #3 Top
When might this beta be available on SDC?

About a week ago now.
Reply #4 Top
Hey hey, what a pleasant surprise. Haven't been to Wincustomize in some time and just happened to stumble upon this article. Great to hear some of the concerns regarding data loss is being addressed.

Cool to see that dictionary script getting some use as well. I expect some sort of royalties now Frogboy
Reply #5 Top
/me wants that widget...
Reply #6 Top
Do you have to have Visual Studio to make the scripts. Im confused about the external scripting I dont know ill jsut wait untill the guides and manual comes out(Hopefly with a little more detail for us noobs )
Reply #7 Top
My stardock central refuses to connect and I have no other way to get this!!!
The sad part is that, there is no reason other than something to do with YOUR server(s) causing issues!!

speedy
Reply #8 Top
One more question does it have to be script files? can it be txt or doc files?
Reply #9 Top
About a week ago now

WHAT.. I've been using this and didn't even realize...

Reply #10 Top
Mr jlaj1989, the scripts are text files, and commonly given a .vbs extension.

Because they are text files, you don't have to use Visual Studio to make them. Any text editor should work, in fact, ObjectEdit, included with Object Desktop, even has a "vbs syntax" and will color code and line number your scripts.
Reply #11 Top
Wow thats realy cool. I figured it out. Thanks rabidrobot
Reply #12 Top
Anytime!^^ ^^

I see scripts can be included, so to speak, and that is handy. But to create those scripts my first preference would be to use the script editor in DesktopX itself. It has the intellisense for DX namespace, etc., and is a good editor for the task. I would then find it useful to be able to save the script from the DX editor, as any filename, for use by whichever objects require.

As it stands the workflow will involve copying text from DX to clipboard then paste in other app to save as a library script.

Can't wait to hear more about Microsoft gadget compatability and what aspects of new tech in Vista DesktopX will utilise.
Reply #13 Top
My SDC is showing version 3.19a[b].003 at the moment? Is this the correct one? I do have the "Show pre-release versions" checked....
thanks in advance!
J
Reply #14 Top
Yup. the 3.19 is the 3.2 beta.


As for the DesktopX' script editor. There are a couple of imporvements I'd like to see. I wish that the intellisence worked when you typed DesktopX.Object("someObject").Whatever intead of just for the Object keywork.
It'd be nice to have a dropdown list or something where you could select a function/event for the Object or System namespace and it'd automaticly insert it into your code. As it it now I find my self often going back and forth to the decoumentation just to find the correct wording of the subs or functions. (And a dropdown list containing the sub/function currently in your script which you can use to quickly jump to would be nice as well. espesially when the scripts starts to grow to a few thousands lines)
And I support rabitrobot's suggestion of a save & load function withing the editor.
Reply #15 Top
I think there needs to be a "check" or something when making widgets to "hide external scripts" this way, if you have something scripted you don't want others to be able to "borrow" then you could protect that script. I have several scripts I really don't want the world to have, and I'm sure in the future it will grow.

I have a problem with this build, i have a desktop that i had been working on for a week or so, and DX was working with it just fine, i loaded this version and it just bombs every time i load that desktop now. I'm PRAYING that my scripts are still intact and DX didn't eat them like in past versions. My problem is I really would like to work on this desktop and i cant, it just bombs, any suggestions?

If we use the external scripts maybe this would be less of an issue, but we need something other then a crash window when DX bombs out. Something that gives us some idea of why it bombed, so we can try and correct it, or maybe allow us to do something to get these desktops back into DX. This has been a MAJOR issue with DX for as long as i have been using it, its why i stopped using it for about 2 months, and why i have attempted to save my desktops in increments, but this last one refuses to open any of them

DX is great but it needs some refining to allow us to fix these crashes and still not loose all our code. I know this has caused several people to stop using DX. And it has killed numerous widgets that were being developed.

I know the external script is a good start, but we need a way to edit these external scripts from inside DX, maybe a "launch external script editor" that we can config for whatever editor we want to use, or allow us to use the built in DX editor and save/open external scripts, this would make things a LOT easier to handle external scripts.

I also agree with thomassen:
I'd like to see. I wish that the intellisence worked when you typed DesktopX.Object("someObject").Whatever instead of just for the Object keywork.


As well as the need to be able to select the FUNCTIONS/SUBS that are part of DX without having to look them up in the docs.

The easier it is for "skinners" to program in DX the better the community will benefit.

One thing i have asked for in the past is a view panel for each STATE in an object.
If you have something that has multiple states ( mouse over, down, etc) or a weahter display object, the only way to know what each state looks like is to open the image in some other viewer, etc. It would be GREAT to be able to scroll thru the states and have a window that shows me the image as a move over it. Same thing with the drop down list of images that are already added into your project.

With Vista on the horizon, we need to have DX ready for the Widget/Gadget explosion, and a lot of the ideas/comments here would help do that.

Keep up the great work!!
Reply #16 Top
Another thing: I'd be nice if the Object Lister could expand/collapse the childobjects of an object. It's quite awkward to go through the list when the number of objects grow. But being able to collapse childobjects of object you don't work on would be great. So it'd be a treeview list instead.

I like the idea of a button to "launch external script editor" like RomanDA said.
Reply #17 Top
Thats a realy good idea thomassen, about the expandable treeview. That should be a new feature. That would make things a lot eaiser.

I like the idea of rabitrobot's saving/loading scripts in the Script editor, or maybe exporting them in different formats.

Also maybe a option of choosing the default script that it enters when you choose New Script(Sub Object_OnScriptEnter, Sub Object_OnScriptExit) Have a default vbs script you type and save. And when you choose New Script it inserts the vbs file you just typed as the default script. Kinda like the external scripting.
Reply #19 Top
I second jlaj1989's suggestion about default script. I'd also like to add the option of choosing default language as I prefer to script in JS.


Shadow Lord: It could be a server hickup. Or perhaps they wanted to keep the thread about DesktopX and not go offtopic. Or maybe you used too strong language?
Reply #20 Top
Well it showed up on my reload of the page originally, it was right on topic, and I don't know saying stardock does not include easily accessible change logs, sys req, and the sort sound to you liek strong language? I have never been able to go to the stardock web page and get info on their products that clearly states this is the latest version, this is what is fixed, this is the sys req, etc... The harshest thing I said was that windowblinds and IP were toys (which they are IMO)... Heck I even praised Multiplicity and KeepSafe... But this is nothing new w/ Stardock... And as I said one ofthe major reasons I don't buy their programs is the corporate attitude...
Reply #21 Top
Thanks Thomassen! I'm happy that got cleared up!
As for features, you all have made great comments on things that should be added, but I think the main issue, IMHO, (alongside the ones made above) , has always been then internal editor's interface! If that was tweaked to hold the suggestions stated above, as well as maybe the syntax colouring of objEdit, along with a more graphical "button" led user controls I don't think there would be the need to use an external editor.
Either that or just make it so that you can shoose your "default" editor to open when you click on the "new"/"edit" button in the properties dialogue with either a standard template similar to the one already given or the file you're editing?
PS. Roman, I feel your pain! It's one of the reason's I've stopped developing atm! That, and I'm moving again!
Reply #22 Top
Shadow Lord: no that doesn't sound hars. Dunno why it disappeared. Could have been a hickup.
As for the changelog: From SDC you get easy access to changelogs of all the apps. I reckon the reason why their website isn't updated with the latest version number is that SDC is the main method of obtaining the apps and it will always display the latest versions. That saves them from updating the website constantly.
Regarding "And as I said one of the major reasons I don't buy their programs is the corporate attitude."; who sells a product without a corporate attitude? I've found Stardock to be one of the most friendly corporation to deal with. You get to talk directly to the developers.


Back on topic:
I think that if the script editor got a facelift with the features mentioned in this post it'd benefit everyone, not just the developers. The easier it is to develop the more people will adopt it. That could encourage new creations which will lead to more people buying the client version of DX. DX got so much raw power which we've actually seen very few examples of being used. Clocks, weather, rss, calenders are piece of cake for DX. But making something more complex than that and the development tools in DX doesn't scale well when it comes to terms of usability. As mentioned, it's hard to locate that function or method in the thousands of lines. Same with the object lister, just a flat list of all the object which you have to scroll up and down to find just that object you are looking for. Then you have the script-eating problem which has haunted DX lately which really discourages people to undertake larger projects without following a strict backup-scheme.
DesktopX is one of my favorite apps. I've got loads of projects I've started and played around with, but unfortunately due to very time-consuming studies I haven't had time to get any of them to the point of completion. Now that I'm coming to the end of my studies I hope to get around to play around a little before job and real life calls again. I can resist new features of DX at the moment as it's quite extensive already. But I'd appreciate some refinements.
Reply #23 Top
An option to turn off/on all scripts. You could right click on dx icon in taskbar, select 'stop all scripts'
and also 'start all scripts' no conditions on it, if they are already started, restart them, if some are started and some not, still, start all, stop all. This would be useful I think.
Reply #24 Top
Will the 3.2 version of DesktopX Professional finally
make it possible to configure the About screen to match
the created application?

Sorry, but the DesktopX advertising gotta go from the About-popup
if people are expected to use it for professional creations.
Reply #25 Top
lilstarfish: you could make a script that catches the right-click menu and the sys-tray menu and provide your own which will point the About command to your own about screen.