Forum Home | Login

_Martin_

Join Date 03/2001

+37

DesktopX Standards 0.2

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.

Locked Post

Advanced Search

Watch this post

Do not email me updates for this post Email me updates for this post

Successfully updated karma reason!

RomanDA

Join Date 12/2003

+147

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!!

Successfully updated karma reason!

Thomas Thomassen

Join Date 01/2003

+10

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

Successfully updated karma reason!

Thomas Thomassen

Join Date 01/2003

+10

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.

Successfully updated karma reason!

Sign Up or Login and this ad disappears!
There are many great features available to you once you register. Sign Up for a free account and browse the forums without ads.

_Martin_

Join Date 03/2001

+37

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.

Successfully updated karma reason!

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.

Successfully updated karma reason!

_Martin_

Join Date 03/2001

+37

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.

Successfully updated karma reason!

_Martin_

Join Date 03/2001

+37

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.

Successfully updated karma reason!

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.

Successfully updated karma reason!

Thomas Thomassen

Join Date 01/2003

+10

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

Successfully updated karma reason!

_Martin_

Join Date 03/2001

+37

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.

Successfully updated karma reason!

As a developer, would the AOI be used instead of PersistantStorage?

Successfully updated karma reason!

_Martin_

Join Date 03/2001

+37

ExodusCrow: I would argue this would be a better solution as it has more portability.

Successfully updated karma reason!

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 and posting on the forums.
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!

View all recent posts

Mark all posts as read Delete cookies created by the forum Return to Top

Stardock Forums v Server Load Time: Page Render Time: