DesktopX Standards 0.1

cool!!!!!

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).

Oh yeah what about calendar with appointments standards? Sometimes I would like to use another people's creations but they use different file.

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.

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, ...)

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 ?

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.

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.

Ahh so it uses a XML file?

Will there be a ready to use script for creating, changing or accessing this XML file?

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

Aww it messed up my post. For some odd reason, I can't edit it.

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.

Actually, my own is based on yours.

I modified it to use split functions.

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

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.

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?

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.

Corky_O,

Thanks very much - I appreciate this.

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.

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.

A little semantic addition.
for the section:
I belive

Thanks for these suggestions - this is all good stuff.

ver is version in 0.2

Not sure about versions for subcategories on the basis that once we hit 1.0 I really don't expect the structure to change.

Check out the samples in 0.2 and you'll see that data is extracted in just this way.

I want to ensure that nothing is optional as this will dilute the standard.

I agree on terminology - this is what we need concensus on.