Published on October 8, 2004 By _Martin_ In WinCustomize News
The proposed standards have been updated based on feedback and the proposal for Additional Object Information (AOI) storage has been outlined.

You can get the draft document here: DesktopX Standards

You can get a sample CUI file here: Sample CUI File

You can get a sample AOI file here: Sample AOI File

You can get a dxpack showing the basics of interaction here: Sample CUI access using DesktopX

Note that the samples assume that the dxCUI.xml file is in your DesktopX directory.
on Oct 08, 2004
This seems like its working ok, The good thing would be to have a popup widget showup when your app loads (if it looks for CUI or AOI info) and prompt for info and create this file. I think that made no sense. I mean when you first load your app, it would look to see if the CUI and AOI exist, and if they dont, it would open a window where you can enter the basic info into, and then it would create the XML files.

And also some sort of common app that would allot you to edit this info at any time.

Make more sense?
Thanks for this, I think this is a great idea!!
on Oct 08, 2004
Central place, easy accessed for developers to obtain the latest standards. Othervise it's just end up beeing confusing to what the latest standard really is.
Might be useful to keep record of old versions as well. That way developers can know how far back their objects are compatible.

section would be much more useful if DesktopX had a Colorize function. With a colorsize function developers could simply create grayscale images that would be colorized. But no such thing exist yet in DX. Think we should suggest this to the dev team of DX. Perhaps make a section for a sort of future perparation if this sort of function would appear.

Propose AOI tag be changed to
as people might not want to publish their email address to the entire world without any control of who get hold of it. I have a page on my site where I direct people to contact me the first time. I then can deside if I want to reply to that person and give them my email address.
on Oct 08, 2004
the italic text in the last post is a result of me writing . Didnt know HTML formatting was on.

This whole project makes things a little easier for me as I had plans to make a theme that would be easily configurable by the user. It will probably make heavy, if not total, usage of the features written down in these proposal.
on Oct 08, 2004

As part of the sample there is a script that checks for the presence of the CUI file. It even prompt the user that the developer wants to use it. I think from that it will be obvious that this is the direction we are moving in especially when the widget for entering the CUI is developed in time.

I don't propose to create a default for the user. The CUI is something that should be optional but makes sense to use, and it also makes no sense to have to lump a default CUI and method for configuring it with every object. I propose that we simply point the user to where they can get it and open the appropriate page. It just opens the desktopx homepage now as an example of what would happen.

It is down to the developer to decide how they want to have their object react if the user doesn't have a CUI. In most cases it would just involve setting a variable and applying some default values.
on Oct 08, 2004
I think this is a great idea but I can already see this place being infested with spammers harvesting e-mails from the contacts the user has provided. I think there is no value added in the contacts node of this information xml and should be removed. There is no need to open up such doors to exploitation.
on Oct 08, 2004

Agree that we need a central place. You will note that we have a place where you can download these files from centrally and this will continue. I plan to add version control once we reach a point where the concept is a bit more fleshed out. Initially I expect and hope it will be too dynamic to justify this.

Colorize is a valid concept but not necessarily for these standards. The reason being is that if every image was based upon a greyscale image then the whole of that image would be colorized to say blue or green. What it you wanted a greyscale image with a hint of color. Consider Brewman's excellent DogmaX work. That is fundamentally greyscale with blue highlights.

Now, with hue changing we can change that emphasis to red or green, but colorizing it would risk it all becoming blue, green, red etc.

Whilst I think there is still validity in the concept of a colorize option, I don't plan to put anything in the standards that isn't existing functionality. Where new functionality is added I have no issue in then adding it to the standards.

Sort of lost the statement about the AOI, but with regard to email, I state clearly that this is optional (as are all other fields). If the user doesn't wish to give it they don't have to. I also state clearly that this information should be used sensibly.

Any hint of abuse of these files will result in the offending data being stripped from the standards.
on Oct 08, 2004

As per the above post - this is optional and will be made clear that it is optional. If there is serious issue with it then it will be removed, but let's see how it goes.
on Oct 08, 2004
Cool. We definitely need an appointment dates/reason/etc standards, however.

Once we have that, and I get my laptop back.. I will update my ApptLinearCalendar and my brother's ApptColorCalendar. That one needs to be updated anyway, with better color changer.
on Oct 08, 2004
I suggested in the 0.1 proposal that the "dxinfo" (now changed to "dxAOI" and "dxCUI") part of the path string ("dxinfo\information\weather") ,to access the DOM three, would be optional. I still think it would be reasonable to do so. Because these are root elements of the XML file, they would allways be required to be there anyway. Unless the user want to obtain an array with all the settings of the setting file I see no reason why the root element should be required.
I'd much rather use "information\weather" instead of "dxCUI\information\weather" to get the weather settings.

Imagine a code obtaining various setting information
var weather = getSetting("dxCUI\information\weather") // returns array of weather
var shortcuts = getSetting("dxCUI\shortcuts") // returns array of shortcuts
var hue = getSetting("dxCUI\enviroment\visual\hue") // returns the hue value
Instead of requiring to include the root element in the path, make the XML parser require the root element to be either dxCUI or dxAOI.
var weather = getSetting("information\weather") // returns array of weather settings
var shortcuts = getSetting("shortcuts") // returns array of shortcuts
var hue = getSetting("enviroment\visual\hue") // returns the hue value
If I wanted to get an array of all the setting I'd simply write
var settings = getSetting("dxCUI") // returns an array of all the settings
on Oct 09, 2004

If you try out the samples you will see that this prefix isn't needed at all. In fact it never has been. You just need something like "personal/name/forename".

I will be adding functionality to populate arrays from the CUI or AOI as well as just single values.
on Oct 10, 2004
As a developer, would the AOI be used instead of PersistantStorage?
on Oct 12, 2004
ExodusCrow: I would argue this would be a better solution as it has more portability.