[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-tm-dev] RE: Request for API change: systemType icon properties
|
Thanks Kushal.
As a matter of fact, the fallback to <property> comes at
no cost so I'd rather leave it in there. It's clearly
documented.
I agree with the decorator idea. For now, both icon and
iconLive properties are optional:
- If no icon is given, use the default icon
- If no iconLive is given,
- use the icon if it is given (no decorator!)
- otherwise use the default iconLive
For me this looks like good enough for now.
Thanks,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: Kushal Munir [mailto:kmunir@xxxxxxxxxx]
> Sent: Thursday, August 24, 2006 7:13 PM
> To: Oberhuber, Martin
> Cc: David McKnight; David Dykstal; Target Management
> developer discussions
> Subject: Re: Request for API change: systemType icon properties
>
> Hi Martin,
>
> I think I had changed the implementation to use the
> <property> markup. I
> was looking at icons and other attributes as "properties" of
> the system,
> hence the change. However, I do agree with the disadvantages you have
> pointed out, especially the fact we have an implicit
> assumption that all
> system types should have an icon. It makes sense to move this
> attribute
> back to the systemType markup.
>
> We also require plugin providers to specify the icon to be
> shown when the
> connection is "live", i.e. connected. In the future, this "iconLive"
> property, in my opinion, should not be a required attribute,
> but optional.
> What would be good is to use some kind of a decorator to differentiate
> between connected and non-connected, and any other state the
> connection may
> be in. I think this will require changes to our view label providers.
> Anyway, this is something to keep in mind for the future...
>
> We don't need to support falling back on the <property> tag
> to read the
> icon and iconLive attributes.
>
> Cheers,
>
> Kushal Munir
> Websphere Development Studio Client for iSeries
> IBM Toronto Lab, 8200 Warden Ave., Markham, ON
> Phone: (905) 413-3118 Tie-Line: 969-3118
> Email: kmunir@xxxxxxxxxx
>
>
>
>
>
> "Oberhuber,
>
> Martin"
>
> <Martin.Oberhuber
> To
> @windriver.com> "David Dykstal"
>
>
> <david_dykstal@xxxxxxxxxx>, David
> 08/24/2006 11:42
> McKnight/Toronto/IBM@IBMCA, Kushal
> AM
> Munir/Toronto/IBM@IBMCA
>
> cc
> "Target Management
> developer
> discussions"
>
>
> <dsdp-tm-dev@xxxxxxxxxxx>
>
> Subject
> Request for API
> change: systemType
> icon properties
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Dear committers,
>
> I would like to request an API change in the systemTypes
> extension point:
>
> In RSE 7 and before, the icon of a systemType was specified
> as a String property. For openRSE, this has been changed to
> put the icon references into a <property> markup.
>
> The disadvantages of this are, that
> * It is not obvious that icons are required by the code
> * PDE cannot be used to browse for the icon resource
> in the extension point schema editor
> * PDE cannot display the icon in the plugin.xml editor
> * The extension point looks more complex than necessary
> * There is unnecessary extra migration effort from RSE7
>
> I would therefore like to revert to the original structure,
> and pass "icon" and "iconLive" in as attributes. I would
> like to keep the <property> markup there, in order to
> support custom extensions later on.
>
> If you want, the code could also make a fallback to reading
> the icon from <property> if it is not available in the "icon"
> attribute; but I don't think this is necessary since there is
> no released version of this right now.
>
> Any comments on the request?
> Can we please vote on this request?
>
> Thanks,
> --
> Martin Oberhuber
> Wind River Systems, Inc.
> Target Management Project Lead, DSDP PMC Member
> http://www.eclipse.org/dsdp/tm
>
>
>
