DesktopX Standards 0.1
Thursday, October 7, 2004 by _Martin_ | Discussion: WinCustomize News
In a drive to make DesktopX easier for both users and devlopers I am in the process of trying to develop some standards for DesktopX.These will only succeed with support and a critical mass of developers using them so I urge you to assist if you think this a a worth while cause.
This first draft details proposed Common User Information, and outlines other plans for the standard. Your feedback is welcome.
You can get the draft document here: www.desktopx.net/standards/DesktopX Standards.pdf
A sample of the Common User Information is here: www.desktopx.net/standards/dxinfo.xml
 |
|
Page 1 of 2 | |
|
|---|
XX
Reply #2 Thursday, October 7, 2004 9:25 AM
Reply #2 Thursday, October 7, 2004 9:25 AM
That is a great idea, but can't Desktopx be modified to allow easy editing of registry?
IE: Savesetting and Loadsetting (used in VB.NET but not in vbscript).
IE: Savesetting and Loadsetting (used in VB.NET but not in vbscript).
XX
Reply #3 Thursday, October 7, 2004 9:27 AM
Reply #3 Thursday, October 7, 2004 9:27 AM
Oh yeah what about calendar with appointments standards? Sometimes I would like to use another people's creations but they use different file.
_Martin_
Reply #4 Thursday, October 7, 2004 10:21 AM
Reply #4 Thursday, October 7, 2004 10:21 AM
XX - you can easily write to the registry now but that doesn't stop people writing all over the registry with no structure.
If you read the document then you'll realise that the standardisation of information is the issue, not whether it resides in the registry or XML. Registry access is also difficult at times due to the various security apps on computers.
If you read the document then you'll realise that the standardisation of information is the issue, not whether it resides in the registry or XML. Registry access is also difficult at times due to the various security apps on computers.
Fix
Reply #5 Thursday, October 7, 2004 10:34 AM
Reply #5 Thursday, October 7, 2004 10:34 AM
Very good work Martin. Thanx very much for it.
As far as the shortcuts are concerned, I'd rather «type» as being URL, application, folder, or special folder this way, we'd be able to easily script them : if it's a folder and you click on it for more than 2 seconds, then it opens the Browse folder dialog, so that you can change the folder target... Does this make sense ?
Then we should have a «type» info for each shortcut PLUS a «category» info (graphics, office, ...)
As far as the shortcuts are concerned, I'd rather «type» as being URL, application, folder, or special folder this way, we'd be able to easily script them : if it's a folder and you click on it for more than 2 seconds, then it opens the Browse folder dialog, so that you can change the folder target... Does this make sense ?
Then we should have a «type» info for each shortcut PLUS a «category» info (graphics, office, ...)
Fix
Reply #6 Thursday, October 7, 2004 10:41 AM
Reply #6 Thursday, October 7, 2004 10:41 AM
Hmmmmmm. I can't edit my message ("you're not authorized to view this page" 
)
Just one more thing : since there are online TVs available on the net, «radio» should be «radio OR TV», don't you think so ?
)Just one more thing : since there are online TVs available on the net, «radio» should be «radio OR TV», don't you think so ?
_Martin_
Reply #7 Thursday, October 7, 2004 11:03 AM
Reply #7 Thursday, October 7, 2004 11:03 AM
Thanks for the feedback. I can certainly add a "folder" type. This is a sensible idea.
There are two ways of looking at the need for "type" and "category".
1) You could argue that a folder will be distinct type that is different so you don't need categories
2) You may think a more sophisticated system is needed where you may want to group different types of URL (graphics, skinning etc). If this is the case, should we enforce a structure or allow the user to create their own. You could do the same for "Applications" - placing them into graphics, skinning categories etc.
This is the sort of debate we need - though I think we need a newsgroup to maintain some structure to these threads !!!
Special folders I plan to add to the common scripts as these can easily be extracted from the registry.
Let me know what you think.
There are two ways of looking at the need for "type" and "category".
1) You could argue that a folder will be distinct type that is different so you don't need categories
2) You may think a more sophisticated system is needed where you may want to group different types of URL (graphics, skinning etc). If this is the case, should we enforce a structure or allow the user to create their own. You could do the same for "Applications" - placing them into graphics, skinning categories etc.
This is the sort of debate we need - though I think we need a newsgroup to maintain some structure to these threads !!!
Special folders I plan to add to the common scripts as these can easily be extracted from the registry.
Let me know what you think.
_Martin_
Reply #8 Thursday, October 7, 2004 11:04 AM
Reply #8 Thursday, October 7, 2004 11:04 AM
oh and as for TV, this would probably be added as a distinct media, as there may be different properties for it in the long term. We'll see if the need for that arrives.
XX
Reply #9 Thursday, October 7, 2004 1:41 PM
Reply #9 Thursday, October 7, 2004 1:41 PM
Ahh so it uses a XML file?
Will there be a ready to use script for creating, changing or accessing this XML file?
Will there be a ready to use script for creating, changing or accessing this XML file?
XX
Reply #10 Thursday, October 7, 2004 1:51 PM
Reply #10 Thursday, October 7, 2004 1:51 PM
Oh yeah if you plan to create a calendear with appts standard, I would recommand using my format (just check out ApptLinearCalendear) so that way yu can use split function to simpify splitting up information.
But at the same time, You could split up all of the data, incuding day, month and year, time so this point would be moot.
It may go like this:
MM/DD/YY'format
2'this one tells how many appts there is.
'APPT then the number
20'day
1'month
2005'year
7:00
My 29th Birthday
'second appt.
20
1
2006
7:00
My 30th Birthday
Of course this format has some weaknesses. If appt 1 is removed it causes some problems. any solution? Hmm one possible: just use without any numbers and use SPLIT function?
But at the same time, You could split up all of the data, incuding day, month and year, time so this point would be moot.
It may go like this:
MM/DD/YY'format
20'day
1'month
2005'year
7:00
My 29th Birthday
20
1
2006
7:00
My 30th Birthday
Of course this format has some weaknesses. If appt 1 is removed it causes some problems. any solution? Hmm one possible: just use
XX
Reply #11 Thursday, October 7, 2004 1:53 PM
Reply #11 Thursday, October 7, 2004 1:53 PM
Aww it messed up my post. 
For some odd reason, I can't edit it.
For some odd reason, I can't edit it.
_Martin_
Reply #12 Thursday, October 7, 2004 2:22 PM
Reply #12 Thursday, October 7, 2004 2:22 PM
XX - If you actually read the document it might enlighten you as to the format, details etc.
I also created an appointment calendar a good while ago, so I have a fairly good format, but thanks.
I also created an appointment calendar a good while ago, so I have a fairly good format, but thanks.
XX
Reply #13 Thursday, October 7, 2004 5:12 PM
Reply #13 Thursday, October 7, 2004 5:12 PM
Actually, my own is based on yours. 
I modified it to use split functions.
I modified it to use split functions.
Will Rose
Reply #14 Thursday, October 7, 2004 6:33 PM
Reply #14 Thursday, October 7, 2004 6:33 PM
Martin,
This is a good start - you've obviously been working hard.
A lot of the most interesting stuff will come in the AOI section, so we'll still have to wait and see on that.
Two things that I immediately see are missing: 1)User's text color preference and 2)under weather, the user's hemisphere (northern or southern).
For the 99% of you wondering why #2, it's so the moon phase can be displayed accurately.
I also think it would be good if the units preference for weather was more specific, to accomodate different people's interests:
Temp: F,C
Wind Speed: mp/h,km/h,m/s,knots
Visibility: mi,km
Barometer: in,mm,hPa,kPa,mb
Precip:in,cm,mm
Cheers,
Will
This is a good start - you've obviously been working hard.
A lot of the most interesting stuff will come in the AOI section, so we'll still have to wait and see on that.
Two things that I immediately see are missing: 1)User's text color preference and 2)under weather, the user's hemisphere (northern or southern).
For the 99% of you wondering why #2, it's so the moon phase can be displayed accurately.
I also think it would be good if the units preference for weather was more specific, to accomodate different people's interests:
Temp: F,C
Wind Speed: mp/h,km/h,m/s,knots
Visibility: mi,km
Barometer: in,mm,hPa,kPa,mb
Precip:in,cm,mm
Cheers,
Will
Corky_O
Reply #15 Thursday, October 7, 2004 7:25 PM
Reply #15 Thursday, October 7, 2004 7:25 PM
Martin,
A small comment from someone who is just learning to script, but has alot of experience in Quality Control standards and documentation.
This is probably the best idea I have seen here at WC in the 6 months I have been a subscriber.
A great way to prevent loss of quality and a fantastic tool for anyone with an interest in creating highly compatible products.
Just 2 cents from a subscriber who cares.
A small comment from someone who is just learning to script, but has alot of experience in Quality Control standards and documentation.
This is probably the best idea I have seen here at WC in the 6 months I have been a subscriber.
A great way to prevent loss of quality and a fantastic tool for anyone with an interest in creating highly compatible products.
Just 2 cents from a subscriber who cares.
paxx
Reply #16 Thursday, October 7, 2004 8:55 PM
Reply #16 Thursday, October 7, 2004 8:55 PM
OK, I read it all, but I'm not sure I understand everything. How would specific docklets that use specific variables be tied in that? Or would it not be? For example, a widget that remembers its position on the screen. We would still use the registry for those specific purposes?
How would specific docklets that use specific variables be tied in that? Or would it not be? For example, a widget that remembers its position on the screen. We would still use the registry for those specific purposes?
_Martin_
Reply #17 Friday, October 8, 2004 3:20 AM
Reply #17 Friday, October 8, 2004 3:20 AM
Will,
Thanks some good thoughts there. Text color is a good one, I'll add that.
As for the hemisphere there is no need (assuming weather.com is used) as you can just use the latitude parameter for this. As for the other units I think I'll hold off on that for now. Given that the Metric/Imperial option caters for the majority of these I'd argue that if you want to add options for these that is the sort of thing to be performed as a separate calculation. If necessary this could be stored in the AOI though I would have concerns if people started overwriting defaults with their own custom choices. Of all the weather objects I've made, I can't say I've had anyone asking me if I could put windspeed in knots.
Thanks some good thoughts there. Text color is a good one, I'll add that.
As for the hemisphere there is no need (assuming weather.com is used) as you can just use the latitude parameter for this. As for the other units I think I'll hold off on that for now. Given that the Metric/Imperial option caters for the majority of these I'd argue that if you want to add options for these that is the sort of thing to be performed as a separate calculation. If necessary this could be stored in the AOI though I would have concerns if people started overwriting defaults with their own custom choices. Of all the weather objects I've made, I can't say I've had anyone asking me if I could put windspeed in knots.
_Martin_
Reply #19 Friday, October 8, 2004 3:28 AM
Reply #19 Friday, October 8, 2004 3:28 AM
paxx,
The Additional Object Information will handle this. There will not be much to this section beyond identifying the widget, it's author and the various parameters that are to be stored. The sole goal of this is to enforce a structure that controls the way this data is held rather than it being scattered across the registry, ini files, persiststorage etc.
This one file will be far more transferable that the current options.
The Additional Object Information will handle this. There will not be much to this section beyond identifying the widget, it's author and the various parameters that are to be stored. The sole goal of this is to enforce a structure that controls the way this data is held rather than it being scattered across the registry, ini files, persiststorage etc.
This one file will be far more transferable that the current options.
Thomas Thomassen
Reply #20 Friday, October 8, 2004 5:48 AM
Reply #20 Friday, October 8, 2004 5:48 AM
This is very good.
I got some proposal.
*
Change ver="0.1" to version="0.1" and to as it makes for easier reading. With too many shortened words it may end up confusing as the list of settings will grow.
*
Have version control for the sub categories as well. i.e. . I was thinking if only a sub-section where to be changed it would create less incompatibillity issues if only the version number for the subsection is increased as oppose to the entire setting file.
My thinking is mode modulebased.
*
As I said earlier I was working on a XML parser that would build a DOM tree. I had plans for a function that would let you access the info in the XML DOM tree in a path sort of way. i.e.: getSetting("dxinfo\information\weather") something that would return an array with the info contained under the weather section. Or getSetting("dxinfo\information\weather\units") to get the data for one spesific setting.
I propose the "dxinfo" part of the path to be optional as dxinfo is the root of the document.
getSetting might take an extra optional argument to return the array as either a VBS array or JScript array.
*
Some sort of forum to manage, propse and discuiss the standards.
I got some proposal.
*
Change ver="0.1" to version="0.1" and to as it makes for easier reading. With too many shortened words it may end up confusing as the list of settings will grow.
*
Have version control for the sub categories as well. i.e. . I was thinking if only a sub-section where to be changed it would create less incompatibillity issues if only the version number for the subsection is increased as oppose to the entire setting file.
My thinking is mode modulebased.
*
As I said earlier I was working on a XML parser that would build a DOM tree. I had plans for a function that would let you access the info in the XML DOM tree in a path sort of way. i.e.: getSetting("dxinfo\information\weather") something that would return an array with the info contained under the weather section. Or getSetting("dxinfo\information\weather\units") to get the data for one spesific setting.
I propose the "dxinfo" part of the path to be optional as dxinfo is the root of the document.
getSetting might take an extra optional argument to return the array as either a VBS array or JScript array.
*
Some sort of forum to manage, propse and discuiss the standards.
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!
|
|
Page 1 of 2 | |
|
|---|
Reply #1 Thursday, October 7, 2004 8:47 AM