[Widget: Warp] - license attribute
All, Reviewing the spec there is no access to the License attribute. Shouldn¹t it be added in the liste of the accessible attributes? Best Regards, Benoit Benoit Suzanne Orange Widgets Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM benoit.suza...@orange-ftgroup.com image.pngimage.png
Re: [widgets] Further argument for making config.xml mandatory
I believe that when creating content, it is easier/clearer to have multiple files. There is less confusion and therfore less errors. Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 benoit.suza...@orange-ftgroup.com From: Marcos Caceres marc...@opera.com Reply-To: marc...@opera.com Date: Thu, 19 Mar 2009 17:06:31 +0100 To: Andrew Welch andrew.j.we...@gmail.com Cc: jere.kapy...@nokia.com, mark.priest...@vodafone.com, public-webapps@w3.org Subject: Re: [widgets] Further argument for making config.xml mandatory Resent-From: public-webapps@w3.org Resent-Date: Thu, 19 Mar 2009 16:07:10 + On Thu, Mar 19, 2009 at 4:52 PM, Andrew Welch andrew.j.we...@gmail.com wrote: That's exactly what I was talking about when I said even thought the XML i18n guidelines say it's bad practice,'. Ahh very sorry, I just saw the email after that containing the code sample, and gmail collapses the quoted parts my bad. However, Addison Phillips, the Chair of i18n core, said the following in the formal feedback representing the i18n WG's LC comments for the spec [1]: Section 7.4 (Widget) The various language bearing elements such as name, description, etc. are of the zero-or-one type. However, it is typically better to allow any number of these elements to occur, provided that none share the same xml:lang. This allows for localization (which is part of the point in allowing xml:lang on the element). So we have been blessed by them to do this... umm this somewhat questionable, yet problem solving thing :) [1] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0259.html That's interesting, because xml:lang seems pretty redundant otherwise! Alright, lets see a show of hands for this approach! Who supports us just having a single config.xml with a bunch of repeated elements, but with different xml:langs? Advantages here are: * we only need to make very small modifications to the parsing model. * no more searching for config docs in locale folders * no multiple parsing of config files Disadvantages: * large, and, if not careful, hard to maintain config files Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Screenshots and case sensitive file names
I also agree with this proposal Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 benoit.suza...@orange-ftgroup.com From: Arthur Barstow art.bars...@nokia.com Date: Fri, 13 Mar 2009 07:12:06 -0400 To: marc...@opera.com marc...@opera.com Cc: public-webapps public-webapps@w3.org Subject: Re: [widgets] Screenshots and case sensitive file names Resent-From: public-webapps@w3.org Resent-Date: Fri, 13 Mar 2009 11:13:33 + Marcos - I prefer your 2nd proposal. Unless contrary views are expressed in the next few days, I recommend adding your proposal to the ED. -Regards, Art Barstow On Mar 12, 2009, at 12:53 PM, ext Marcos Caceres wrote: Hi, I've decided that having the screenshots at the root of the widget (or at the root of localized folders) is just messy. Also, the naming convention will probably confuse authors, so I've created a screenshot element for consideration. [[ The screenshot Element A screenshot is a file inside the widget resource that graphically represents the widget in a running state. Context in which this element may be used: In the widget element. Occurrences: Zero or more. Expected children: none. Attributes src: Required. A valid path that points to a file inside the widget resource. Usage Example widget xmlns=http://www.w3.org/ns/widgets; screenshot src=/screenshots/mainscreen.jpg/ screenshot src=/screenshots/level1.jpg/ /widget ]] I considered adding a preferred attribute, but then decided that it's first declared is most preferred, and so on. This will be reflected in the order in which the screenshots are stored in the configuration defaults (i.e., I'll make it explicit that screenshots should be stored and presented in the order they appear in the document). WDYT? Kind regards, Marcos
[Widgets] Widget Gallery RSS like sharing format
All, Based on our last F2F, we have talked about an RSS like file format that would standardise the widget list for various needs. I do not consider the following as a formal format proposition but as an input to open the discussion as it should probably be written in atom instead of RSS. So here we go, here is an example of the xml format: rss version=2.0 xmlns:dc=http://purl.org/dc/elements/1.1/; xmlns:atom=http://www.w3.org/2005/Atom; channel titleDjinngo Widget Catalog on vista/title atom:link rel=self href=http://example.com/gallery// linkhttp://example.com/gallery//link description![CDATA[]]/description languageen/language item id3_LiveRadio/id title![CDATA[Orange LiveRadio]]/title platformvista/platform category4/category version1.4.0/version linkhttp://example.com/gallery/#widget=3_LiveRadio/link guid isPermaLink=true http://example.com/gallery/#widget=3_LiveRadio/guid language14/language description![CDATA[Orange LiveRadio gadget]]/description screenshothttp://example.com/GadgetFactory/widgets/screenshots/liveradio- fr.jpg/screenshot author_name![CDATA[Orange]]/author_name pubDate![CDATA[Fri, 12 Jan 2007 00:00:00 +0100]]/pubDate downloads0/downloads download_urlhttp://download.example.com/Orange-LiveRadio-FR-v2.gadget/do wnload_url rating0.0/rating /item item id3_OrangeSport/id title![CDATA[Orange Sport]]/title platformvista/platform category2/category version1.3.0/version linkhttp:// example.com/gallery/#widget=3_OrangeSport/link guid isPermaLink=true http://example.com/gallery/#widget=3_OrangeSport/guid language14/language description![CDATA[Suivez toute l'actualité sportive en direct.]]/description screenshothttp://example.com/widgets/screenshots/sport.jpg/screenshot author_name![CDATA[Orange]]/author_name pubDate![CDATA[Tue, 20 Nov 2007 00:00:00 +0100]]/pubDate downloads0/downloads download_urlhttp://download.example.com/Orange-Sport-FR.gadget/download_ url rating0.0/rating /item ... /channel /rss The idea is to describe the following elements: - title: is the widget¹s name - pubDate: is the date of the publication of the widget - guid: defines a unique identifier for the item - platform: is the widget¹s platform - category: is the number corresponding to a category item - version: the widget¹s version. - link: is the link toward the widget page on the Djinngo gallery. - language: is the number corresponding to a language, although here we should probably use the language format of the PC spec - description: the widget¹s description. - screenshot: is the direct link to a screenshot of the widget. - downloads: the number of downloads for the widget. - download_url: is the direct link to download the widget. - rating: the rating the widget on the gallery. Best Regards, Benoit Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 benoit.suza...@orange-ftgroup.com image.gifimage.gif
Re: Widget Packaging and configuration LC review
Marcos, I¹ve read through your feedback and agree on it for all the elements that I¹ve not included in this message. I guess now we¹re left with the discussion on the Mode apart from those last comments in red in the following exchange: Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM benoit.suza...@orange-ftgroup.com From: Marcos CACERES marcosscace...@gmail.com Date: Wed, 21 Jan 2009 09:21:07 +0100 To: Benoit SUZANNE benoit.suza...@orange-ftgroup.com, Web Applications Working Group WG public-webapps@w3.org Subject: Re: Widget Packaging and configuration LC review Hi Benoit, Inline comments below. For the sake of the LC disposition of comments, please be sure to indicate if you are satisfied with the changes I have made On 1/20/09 8:50 PM, SUZANNE Benoit RD-SIRP-ISS benoit.suza...@orange-ftgroup.com wrote: Hello All, Here are some comments on the Jan 17th draft: 1.5 Global Definitions There are some misplaced quotes that could be deleted and I propose the more generic formulation: The [Widgets-Landscape] defines a widget as an end-user's conceptualization of an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user's machine, mobile phone, or any Internet-enabled device. Because widgets are packaged, they can be liberally shared by users without relying on [HTTP] (i.e., users can share widgets over Bluetooth or through other distribution channels). Fixed. I find the wording: ³any Internet-enabled device² wider then the ³any Internet-enabled mobile device² A User Agent is the runtime environment in which a widget runs. It is also known as a widget engine. That definition of user agent is not broad enough to encompass conformance checkers. The definition you suggested is already covered by widget user agent. That¹s fine, but it needs to be referenced in this section even if it is to point to the right section, as thi section should list all the difinitions of this document. 6.7 Custom Icons and Default Icons An icon must be located either at the root of the widget or in the root of the language folder. Same distinction as in section 6 Fixed I still see this uncorrected in the 5.8 section, it should read if I¹m correct ³... Or at the root of the A default icon must be located either at the root of the widget or in the root of the language folder. Same distinction as in section 6 Fixed I still see this uncorrected in the 5.8 section image.gifimage.gif
[widgets] Widget modes
Hi all, about the widget windows modes, I wanted to share the following points: *** Wording *** In the wordings of the modes, I think that the wording used in some of the modes are too specific to existing platforms, therefore I propose the following names: * Icon: I¹m not sure this one is really a mode as it is already dealt with in the rest of the spec in the right manner with a static image format * Iconized: this mode will allow to define an icon that can be adapted to the content status, for example a weather icon will display the right cloud or sun based on the real time information. This is possible using the svg, but I believe this is one of the modes of displaying information in a widget. * Expanded: this is the reference to the existing floating mode in the spec or the undocked mode for vista * Minimized: this is the reference to the existing docked mode in the spec but is too restrictive in the wordings * Full screen: now for this one my worry is more the fact that there are other attributes that should be available for this mode as the display can be specific to the orientation (landscape or portrait) and to the size of the screen¹s device (vga, qvga, ...) * Hidden: I like the proposition from mark to allow a widget to run as a background task that can awaken an action, so you would probably need to add this as a mode as well. * Settings: I would also like to add the settings of the widget as a specific mode as this will largely simplify the coding of the widget where all the various screens to display will all be defined as modes. ***Context*** The way I see this implemented is that based on the platform actions (drag on a widget bar for example) the platform would switch from one view to the other. Or based on a code input in the hidden mode, a widget would be able to call it¹s Minimized mode through the code. In this context the one thing that needs to be included is how to pass parameters from one mode to the other, but that could be resolved using some kind of parametered declaration. ***Usage*** I do not see the mode as an element, but as an item of the content element, see examples below. ***Code example*** In the format to use the modes I propose the following as a bases for discussions: content src=miniview.html mode=²minimized²/ content src=index.html mode=²expanded² default=²true² flying=²true²/ content src=fullscreen-vga.html mode=²fullscreen² width=²640² height=²480²/ content src=fullscreen-wvga.html mode=²fullscreen² width=²854² height=²480² orientation=²landscape²/ content src=fullscreen-wvga.html mode=²fullscreen² width=²854² height=²480² orientation=²portrait²/ content src=minimumbackgroundaction.js mode=²idden²/ content src=settings.html mode=²settings²/ What do you think? Best Regards, Benoit Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 benoit.suza...@orange-ftgroup.com image.gifimage.gif
Re: [widgets] Packaging Configuration 1.0 pre-CfC comments
In vista sidebar also, the root folder is used without any specific intermediate folder name, and this can become very messy. For this reason I would advocate for the intermediate folder. I think we should push for the i18n naming as, even if it sounds a bit geeky, it is becoming a standard in the javascript frameworks, and using something else will introduce confusion. Benoit Suzanne benoit.suza...@orange-ftgroup.com From: Jere Kapyaho jere.kapy...@nokia.com Date: Mon, 15 Dec 2008 10:32:10 +0200 To: Marcos CACERES marcosscace...@gmail.com, public-webapps public-webapps@w3.org Subject: Re: [widgets] Packaging Configuration 1.0 pre-CfC comments Resent-From: public-webapps@w3.org Resent-Date: Mon, 15 Dec 2008 08:33:18 + Hi Marcos, On 12.12.2008 19.58, ext Marcos Caceres marcosscace...@gmail.com wrote: If people want to suggest a different name for the localized folder, I'm Ok with that. I'll codify this into the spec today. Seems that the z in the string 'localized' personally insults my fellow Australian countrymen and the whole of the British nation. To avoid further offense, I've used the string i18n as the name of the container of localized content instead. So now we get: i18n/en/, i18n/pt/, i18n/es-ar/ and so on... Hopefully this does not offend any other groups and defuses this international crisis:) I was going to point that out, but you beat me to it... Somehow I knew the 'z' was going to be a problem. :) Personally, however, I think 'i18n' is not so great, as it is just too clever, and makes people do a double take. You mentioned that Apple and Yahoo widgets use 'resources', although based on [1] I don't see that happening (in Dashboard widgets the language specific directories are at the root level; in Mac OS X native apps they are in 'Contents/Resources' inside the bundle). Anyway I don't see a big problem there, because these are files used by widgets after all, they're just organized in directories by language tag. If not 'resources', here are more suggestions: 'res', 'global', 'lang', 'languages', 'local', 'locales'. --Jere [1] http://developer.apple.com/documentation/appleapplications/conceptual/Dashbo ard_ProgTopics/Articles/Localization.html
Re: [Widgets] - Requirements Working Draft 23 June 2008 Review
I agree with you comments, and I¹ve just added a feedback to the R27 discussion Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 [EMAIL PROTECTED] On Thu, Jul 31, 2008 at 6:00 AM, Marcos Caceres [EMAIL PROTECTED] wrote: Hi Benoit, Thank you for taking the time to prepare a detailed review. I think I was able to address all your comments, except for the one about R27. Widget State Change Events. It would be great if you could help clarify what you want me to do there. Please see below for detailed description of the changes I made. Please let me know if you are satisfied with the responses I've have given below or if you would like any further clarification. On Wed, Jul 30, 2008 at 8:52 AM, SUZANNE Benoit RD-SIRP-ISS [EMAIL PROTECTED] wrote: Marcos, Here are my comments on the Requirements (W3C Working Draft 23 June 2008) 1. Introduction [...] This document does not address the requirements of web widgets, such as iGoogle Gadgets or Windows Live Gadgets. I Think we can add a wording at the end of the sentense to read: ..., although this version of the widget specification, the Working group will address the web widget in the next iteration of the widgets specifications. Although I personally agree, I don't think we have reached a resolution as a working group about what features should be included in future versions of the Widgets specification. I don't want to prematurely commit us to feature which we may not end up implementing in the future. If anything, this should go into a Widgets 2.0 Requirements document. It might be good to prepare such a document once this one reaches CR. 3. Design Goals Longevity: ... I think in this chapter we should talk about the versioning of a widget. I'm not sure it should be presented as a specific item, or if it can be added inside the logevity section in relation to the longevity of the content provided and related updates it will need over time. I see what you are saying, but I think mentioning versioning is better served in the Web and offline distribution section. I've added the following text: A conforming specification needs to deal with cases where an end-user acquires a widget resource over HTTP or via some other non HTTP-based (offline) means, such as a local file system, Bluetooth or a Multimedia Message Service. In addition, a conforming specification needs to provide a means by which widgets can be updated when a new or different version of a widget becomes available. It must be possible to perform updates from either an online or offline source. R7. Internationalization Guidelines Rationale: [...] (e.g. 'resources/en/' for all English content, 'resources/en-au/' for further localized Australian-English content, and so on). Insert an and in between the 2 english example to stress the need to allow both Done. R15 R16 Is there a reason why they should not be must instead of should? I've changed R15 to a must, as we have already spec'd the license element. We are still undecided about rendering dimensions (R16). R19. Iconic Representations Rationale: [...] For example, an a small graphic of a calendar may represent a calendar widget. an a should be corrected Fixed. But I propose to add the following after: And a small graphic of today's calendar page may also represent this same calendar widget I changed the text to read: For example, a small graphic of a calendar showing today's date may represent a calendar widget. This is to incorporate your suggested text and to imply that the graphic may change dynamically (in accordance with R34 - Icon API). R27. Widget State Change Events This requirement must be available both ways, you should be able to capture the change of state when it happens, but you should also be able as an author to force the state change as well. I propose the following text: A conforming specification must also allow the author to programmatically change the state of the widget to allow a change in the view of the instantiated widget. I'm not sure this is the right place for this. I think this should be in R24. Instantiated Widget API. However, I'm not sure that the proposed text covers the actual requirement. I wanted to put something like you suggested into R24: The API SHOULD also also allow authors to programmatically change the visual state of a widget, but I'm not sure what that means. Can you please provide an example or a use case? I agree that this technically, allowing a dev to change the widget state, falls under R24. But I wonder if this specific functionality should be stated. R28. Network State Change Events In the specific case of a network drop, the author will need to know when the network works again, in order to not have to code a checking loop, it is important to put together a mechanism whereby it's the widget engine that wakes
[Widgets] - Requirements Working Draft 23 June 2008 Review
Marcos, Here are my comments on the Requirements (W3C Working Draft 23 June 2008) 1. Introduction [...] This document does not address the requirements of web widgets, such as iGoogle Gadgets or Windows Live Gadgets. I Think we can add a wording at the end of the sentense to read: ³..., although this version of the widget specification, the Working group will address the web widget in the next iteration of the widgets specifications.² 3. Design Goals Longevity: ... I think in this chapter we should talk about the versioning of a widget. I¹m not sure it should be presented as a specific item, or if it can be added inside the logevity section in relation to the longevity of the content provided and related updates it will need over time. R7. Internationalization Guidelines Rationale: [...] (e.g. 'resources/en/' for all English content, 'resources/en-au/' for further localized Australian-English content, and so on). Insert an ³and² in between the 2 english example to stress the need to allow both R15 R16 Is there a reason why they should not be ³must² instead of ³should²? R19. Iconic Representations Rationale: [...] For example, an a small graphic of a calendar may represent a calendar widget. ³an a² should be corrected But I propose to add the following after: ³And a small graphic of today¹s calendar page may also represent this same calendar widget² R27. Widget State Change Events This requirement must be available both ways, you should be able to capture the change of state when it happens, but you should also be able as an author to force the state change as well. I propose the following text: ³A conforming specification must also allow the author to programmatically change the state of the widget to allow a change in the view of the instantiated widget.² R28. Network State Change Events In the specific case of a network drop, the author will need to know when the network works again, in order to not have to code a checking loop, it is important to put together a mechanisme whereby it¹s the widget engine that wakes up the widget when the network is back on. What do you think? R29. Modal Priority [...] (or any of its windows) should to categorize itself ³should to...² should be corrected 4.5 User Agents R39. End-user Declared Proxy A conforming specification should recommend that widget user agents allow end-users to explicitly input a proxy server through which all HTTP-based request are made. This requirement should include at the end ³, or in case of availability, that the system wide proxy is used.² This requirement should be a ³Must² R40. Automatic Updates This requirement should be a ³Must² R41. Persistent Storage of Preferences A conforming specification must recommend that a widget user agent implement a means to persistently store user preferences for each instantiated widget. The following should be added after the first sentence: ³This Storage mechanism must allow to keep the preferences after restart of the widget or on the restart of the user agent. Rationale: To allow widgets to be closed and re-instantiated without the end-user having reset the preferences for an instantiated widget. For example, when using a weather widget, the end-user will want to store the preferred location for weather information, and not be asked to input that information again every time the widget is re-instantiated. And again at the end of this sentence: ³The same would apply if the user has setup 2 instances of the same widget and would like to view 2 different cities. After closing the widgets, open 2 instances of this weather widget would automatically pick up the 2 pre-set cities. R41 and R42 I would switch them arround so that the notion of the multiple instance can be used in the Preference Storage Requirement. R44. Runtime Security Exceptions A conforming specification must specify runtime exceptions for when the API attempts to perform an action it it not authorized to perform. Correct ³it it² Best Regards, Benoit Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 [EMAIL PROTECTED] Benoit Suzanne Widget Factory Project Manager - Orange Labs - FT/RD/SIRP/SOL/SLAM t. +33 (0)145 298 198 - m. +33 (0)680 287 553 [EMAIL PROTECTED] image.gifimage.gifimage.gifimage.gif
