DesktopX Standards 0.2
Friday, October 8, 2004 by _Martin_ | Discussion: 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.
Thomas Thomassen
Reply #2 Friday, October 8, 2004 9:40 AM
Reply #2 Friday, October 8, 2004 9:40 AM
*
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.
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.
Thomas Thomassen
Reply #3 Friday, October 8, 2004 9:47 AM
Reply #3 Friday, October 8, 2004 9:47 AM
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.
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.
_Martin_
Reply #4 Friday, October 8, 2004 10:08 AM
Reply #4 Friday, October 8, 2004 10:08 AM
RomanDA,
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.
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.
Tombala
Reply #5 Friday, October 8, 2004 10:14 AM
Reply #5 Friday, October 8, 2004 10:14 AM
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.
_Martin_
Reply #6 Friday, October 8, 2004 10:16 AM
Reply #6 Friday, October 8, 2004 10:16 AM
thomassen,
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.
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.
_Martin_
Reply #7 Friday, October 8, 2004 10:21 AM
Reply #7 Friday, October 8, 2004 10:21 AM
Tombola,
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.
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.
XX
Reply #8 Friday, October 8, 2004 12:00 PM
Reply #8 Friday, October 8, 2004 12:00 PM
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.
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.
Thomas Thomassen
Reply #9 Friday, October 8, 2004 1:44 PM
Reply #9 Friday, October 8, 2004 1:44 PM
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
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
_Martin_
Reply #10 Saturday, October 9, 2004 3:54 AM
Reply #10 Saturday, October 9, 2004 3:54 AM
thomassen,
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.
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.
ExodusCrow
Reply #11 Sunday, October 10, 2004 7:03 PM
Reply #11 Sunday, October 10, 2004 7:03 PM
As a developer, would the AOI be used instead of PersistantStorage?
_Martin_
Reply #12 Tuesday, October 12, 2004 7:05 AM
Reply #12 Tuesday, October 12, 2004 7:05 AM
ExodusCrow: I would argue this would be a better solution as it has more portability.
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 Friday, October 8, 2004 8:46 AM
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!!