Some thoughts on DesktopX 4 and beyond
Sunday, December 27, 2009 by Draginol | Discussion: Object Desktop blogs
As the new year approaches, we’re starting to look forward to the DesktopX 4 beta.
So what are the goals of it? Well, to be honest, the goals are pretty modest: Strip out the parts that are difficult to work with and build it back up.
Stripping it down
First off, DesktopX comes with several plugins that I have asked to be removed:
Any plug-in that doesn’t work on Windows 7 with UAC on would be removed. The existing DesktopX library would be renamed “DesktopX legacy” and only new creations would be supported.
The source code for our plugins would be made public so that the community could take over their development since, unfortunately, there just aren’t enough development resources available these days to work on such things.
If users wanted to use that code to make weather and other types of plugins to make it easier for people to create new gadgets, that would be great.
The Future: Building it up
Instead, what I would like to see would be Python to be adopted as the means to creating “plugins” that DesktopX could then read in. Essentially, DesktopX scripting would move to Python and away from JScript or VB Script.
You could still use other scripting languages as well but we would move away from VB Script being the default.
Clicking on the “New” Script would open up the user’s default editor associated with DesktopX (preferably a python editor).
For 4.0
But for 4.0, we’re looking to clean it up. Fix long-standing issues and get to a more solid foundation from which to build on with Windows 7 being the focus for future development.
Reply #2 Sunday, December 27, 2009 10:03 PM
Brad, you have made my new year! I don't know if I can learn Python, but I think it is installed on my PC. I look forward to the new DX and I truly hope that some of the coders here start making plugins! I would hate to lose DesktopX.
Reply #3 Sunday, December 27, 2009 10:13 PM
I'm just a user of the software but I agree with RedncekDude, DX helps fill out the dessktop by providing usefull information. The suites I make would not be the same with out DX. 
Reply #4 Sunday, December 27, 2009 10:32 PM
Brad...I think you need to give Littleboy a job. I could be wrong...but he seems to know his shit! 
Reply #5 Sunday, December 27, 2009 10:44 PM
And your spelling wouldn't be the same without Zubaz! 
Reply #6 Sunday, December 27, 2009 11:43 PM
LB: I have a feeling you're going to have a lot of influence over how we implement this.
Don't know what Python is but I'm gonna look it up.
Reply #8 Monday, December 28, 2009 12:40 AM
I think you all missed the part about there being no budget to work on DesktopX 
Thanks! 
I'm going to write some documentation on my script library and widget "compiler" so you can get some idea of what might be added to make script writers life easier (the library is only there to support one program at the moment and it's not yet ready for public release, althought that's the long term plan).
Reply #9 Thursday, December 31, 2009 7:18 AM
Reply #10 Thursday, December 31, 2009 5:29 PM
Reply #11 Thursday, December 31, 2009 7:39 PM
I'm curious. Will future DX Pro contiunue in it's same form? being able to make standalone exes?
Reply #13 Thursday, December 31, 2009 8:50 PM
Screenlets for the Gnome desktop are written in python. This site has some example code.
Python 2.6.x or 3.x
Reply #15 Friday, January 1, 2010 11:06 AM
After some time I started working on my skinnable gadget again that finally works with my Seven 64bit AND more RAM than 2 GB. Well, I would like to be able to test it as a gadget on another computer, bang, can't export an exe with my Pro. Hm...
On the other hand : If VBScript is going to die, is it worth it to go on now or just hold ? Or will it still be there as an option ?
Reply #16 Friday, January 1, 2010 6:14 PM
I don't think VBscript is going away.
Reply #17 Monday, January 4, 2010 10:29 PM
I have nothing useful to add regarding scripting.
Yet I can no longer resist the impulse to remark that every time I see this blog post topic, a small Tim Allen-esque voice in my head reads the last part as "and BEYOND!" in true Buzz Lightyear fashion.
Please login to comment and/or vote for this skin.
Welcome Guest! Please take the time to register with us.
There are many great features available to you once you register, including:
- Richer content, access to many features that are disabled for guests like commenting on the forums and downloading skins.
- Access to a great community, with a massive database of many, many areas of interest.
- Access to contests & subscription offers like exclusive emails.
- It's simple, and FREE!
Reply #1 Sunday, December 27, 2009 9:59 PM
Thanks for sharing this Brad!
Are you talking about using the python scripting engine with WSC components? You can use any registered scripting language to implement them. VBScript and JScript engines come with Windows, but you can install a lot of other scripting engines (there are perl, python, forth, etc. engines available).
I'm using them myself with JScript and VBScript code only (one example is available here), so I don't know how hard it would be to install and use the perl/python engines. I'm going to test it with python and upload a test object with a walkthrough. And if you end up going that route, I have a bunch of suggestions to make Windows Script Component much more usable.
Right now, you have to register them by hand, but if DX could simply load them directly, register them and bind events as well as expose the main DX objects globally, it would be much easier (I have written a small preprocessor in C# and a few base components that encapsulate the DX objects and this abstracts much of the complexity, but it's still a hack at best).
Edit: Turns out the ActiveState Python distribution does all the work and registers the engine, so it's very simple to have scripts components written in Python. Here is a quick example object.
As a side note, if you ever distribute a python engine with DX, you will have to patch it to return better parsing errors if possible (as of now, it only returns a laconic "unexpected indent" or "invalid syntax" with no line error information).