What sorts of features would you like to see in the 4.x series?


Comments (Page 3)
13 Pages1 2 3 4 5  Last
on Apr 25, 2009

Wow I must post in this EPIC thread

I've been at DX for about 4 years, last two were pretty intense. I am glad many bugs I noticed have already been reported here and I'm also glad that there are many great suggestions made.

Well I'd like to give my 2 cents so lemme begin:

- make DX not murder CPU as soon as something a bit larger or a group of objects has to be moved/resized/transparentized(i made that last one up but u catch my drift).

- please fix at least the problem of controls not showing until their parent is dragged

- improve script editor - maybe add tabs and other tools that other editors have (i love notepad++)

- maybe enable gadgets to wipe their data off the PC as soon as they're closed (for instance when running them from a memstick)

- it would be great if we could use blur and similar techniques to make our objects more attractive (windowblinds style), it would also be cool to be able to access windowblinds skin data easily and not have to be of Vad_M's caliber to do so

- make some more plugins for lets say: catching global keyboard keys imput, mouse movement (maybe ability to move mouse) and all mouse buttons as well as current mouse coursor's state.

- maybe enable already completed gadgets to communicate with eachother

 

(if any of those is utter nonsense I'd like to excuse myself as I am a total self-learner)

 

To addres this:

Night Train
IMHO.. resolution dependency has held back DX more than anything.

 

Well this is really more up to the author than DX because as someone said DX coders freestyle a lot so I would say it is impossible or way too hard to achieve. However if the whole idea with templates is adopted than maybe programmers with insufficient knowledge on how to make something resolution independant will be able to do so by using the appropriate template.

on Apr 25, 2009

improve script editor - maybe add tabs and other tools that other editors have

I concur. A central properties and script editor would be nice, so I don't have several windows open to work on different objects.

DX has functions to help make your theme rez-independent; take for example Quentin's resolution independent theme. More examples/templates wouldn't hurt, but it really is up to the author to do the work.

The key thing is that we have templates already. That is one of the key benefits of DX, in that you can load widgets and tweak them. These are our templates!

For example here is a perfectly functional calendar and here is the article explaining how to use it.
Whilst this is 5 years old it is still totally valid today.

Likewise, if you want weather then here is an equally old, but equally functional object.

What we need is an agreed standard for how we publish and utilise these within DesktopX.

That's what I'm talkin' about. It's one thing for users to upload a bunch of templates to the gallery, but each one has a different way it needs to be tweaked, and each user has a different level of experience which means they may or may not know how/what to tweak. A standardized set of templates would be essential and I propose Martin be put in charge of implementing it.   (Excellent suggestions overall, Martin!)

 

 

on Apr 25, 2009

I remembered one more important thing right now!

Imagine that you made CPU Speed Meter (just for example) and decided to save it as a widget (or gadget). Then you run it and minimize to the System Tray. What will happen in this case? Nothing! You just see its "dead" Icon in the Tray...

But now imagine that you have some scriptable DX plug-in which allow you show in the Tray a small frame with CPU Speed and Usage instead of "dead" Icon (current weather and temperature if you've made the weather widget, incoming mails, etc..., etc...)

I'm sure this little thing (and a few other) should move up DesktopX to the next, most higher level!

 

on Apr 25, 2009

IMHO.. resolution dependency has held back DX more than anything.

Currently, everything I make is resolution independent. This has been true for quite some time now. Of course, I have recently REUPPED a few of my older non res/ind. themes which I do plan to update as soon as my site redo is complete.  

on Apr 25, 2009

Well this is really more up to the author than DX because as someone said DX coders freestyle a lot so I would say it is impossible or way too hard to achieve

See reply #34.

on Apr 26, 2009

 IMHO.. resolution dependency has held back DX more than anything.

I disagree...

 Currently, everything I make is resolution independent. 

Yes. DesktopX has all that we need to make the resolution independed themes (just look at the DesktopX Scripting Guide):

System.ScreenWidth

System.ScreenHeight

System.VscreenLeft

System.VScreenTop

System.VScreenWidth

System.VScreenHeight

System.WorkareaLeft

System.WorkareaRight

System.WorkareaTop

System.WorkareaBottom

So the quality and usability of each DX Theme depends only of its author. He (or she) can make it for fixed resolution. Or work a bit longer and make a simple script which will get a few parameters listed above to use them during theme loading for auto moving all parts of this theme to the necessary positions inside the screen.

on Apr 27, 2009

Horizontal and vertical guidelines to help make things straighter. Or maybe a grid that we can turn on and off.   Just a thought.  

on Apr 27, 2009
First and foremost I concur with the comments regarding resolution independancy. This really is down to the authors as everything we need is there.

Horizontal and vertical guidelines to help make things straighter. Or maybe a grid that we can turn on and off.
Good idea. However, why don't we take this a step further and have "Global" scripts that interact with the development environment rather than being "local to an object/a theme.
Think of it as script plugins. e.g. it would be very easy to write a script to draw a grid on the desktop. It would be very easy to write a script to move any given (or in fact all) objects to snap to a grid. What if these scripts could just be run and implemented based on events occuring within the development environment. e.g. Development_OnStart (draw grid), Development_OnObjectMove (snap to grid) etc etc.

A standardized set of templates would be essential and I propose Martin be put in charge of implementing it.
Thanks sViz I think! . I've managed to find the draft document I did many a moon ago. Obviously it's not up to date but I think most would still be valid. You can see the article here.

As I say, this my be implementable without Stardock support, but I think we'd want to get some reassurances from Stardock about the direction of DX before anyone spends too much time on this, and we would also need help if we were to do anything relating to "templates".

Having said that, if necessary a standard template library could be managed ourselves, but it would be far better to get this built in.
on Apr 27, 2009

I've managed to find the draft document I did many a moon ago. Obviously it's not up to date but I think most would still be valid. You can see the article here.

I've never seen this article earlier. But now I can say that it is really cool and easy to understand!

Unfortunate that Stardock Developers Team so rarely hears and uses our ideas, wishes and proposals...

on Apr 27, 2009

As I say, this my be implementable without Stardock support, but I think we'd want to get some reassurances from Stardock about the direction of DX before anyone spends too much time on this

Oops, why did nobody told me about this ?   I have my own set of templates and helper code along with a custom parser/preprocessor to go with them (to get #define/#include, script merging and stuff like that - see reply #3), so this is indeed manageable externally. You have to be careful though to be able to handle different versions of the lib running at the same time.

If you want an example of how it works, you can have a look at the standalone version of the Animator component. Most of the main templates are unfortunately much more tightly coupled and not so easy to use independently.

While having a full blown standard template library in DX would be nice, I'd hope they'd rather use their limited resources to work on infrastructure & better support for components (already in the windows script runtime) and let the community handle the scripting side.

on Apr 27, 2009

While having a full blown standard template library in DX would be nice, I'd hope they'd rather use their limited resources to work on infrastructure & better support for components (already in the windows script runtime) and let the community handle the scripting side.

I absolutely support this idea- most of us would rather see new tools than the same old ones that have just been made more accessible.

Also the "template pack" could be created independently by some of our leading scripters (let them decide on "standards"), there really isn't much need for stardock to bother with this except to give the project a green light..

on Apr 27, 2009
most of us would rather see new tools than the same old ones that have just been made more accessible.
Most of us would rather see some new creativity within DesktopX, rather than a rehash of the same old objects as we've had (in the main) for the last 5 years. If it requires a more "simplistic" interface to bring some new blood and new ideas into the DesktopX community then I'm all for it.
Also the "template pack" could be created independently by some of our leading scripters (let them decide on "standards"), there really isn't much need for stardock to bother with this except to give the project a green light..
So are you suggesting that people do a lot of work on your behalf, in the hope that people will care enough to use what they spend a lot of time creating? We need support from Stardock, otherwise a future change could render all this work obsolete. We need positive involvement from all parties and a critical mass of users to adopt a "standard" otherwise there is no chance it will work. As per my previous post, suggesting such standards got positive feedback previously but despite the work put in, most people now are totally unaware of it. Now, maybe if this had Stardock support previously, then by now we wouldn't even be discussing this. I'm not saying that is definitely the case, but it would have had a better chance!
on Apr 28, 2009

Most of us would rather see some new creativity within DesktopX, rather than a rehash of the same old objects as we've had (in the main) for the last 5 years. If it requires a more "simplistic" interface to bring some new blood and new ideas into the DesktopX community then I'm all for it.

I agree, there has been so little major new features in the past 3+ years..

 

Also, fixing some of the main bitches should be #1, then New features.  There are multiple threads out there that have been around for a VERY long time that point out some of the major gripes.

 

I look so farward to V4 and hope that when you need input you email me (ZU!)

on Apr 28, 2009

Great to see some new input on DX. I agree with most of what was suggested here. I would still like to see some more plugins / updates to plugins for DX to make life easier. Fiddling with WMI is way too complicated IMHO. Sure, copy & paste, but up to now I still can't get the usual WMI code to work for a simple memory-meter above 2 GB RAM. It just stays there doing nothing. Same for the plugin btw.

And yes, 64bit support would be great. At least with Windows 7 coming, I personally won't use 32bit anymore. Yes, I am not very active uploading here anymore, but I still try to work with DX.

on Apr 28, 2009

Another slightly OT matter (IconX is a derivate of DX AFAIK) : I still miss IconX for Vista.

13 Pages1 2 3 4 5  Last