Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Why no widget Interfaces?
|
| Re: Why no widget Interfaces? [message #452020 is a reply to message #452017] |
Sat, 12 March 2005 23:41   |
Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Read the several articles at eclipse.org on the design of SWT.
One user to another: You can't add API to SWT. You'll have to think of
another way to do it. It's simple, for example, to create a validation
interface, implement it for the applicable SWT classes and map from SWT
class to implementation. That may not be "object-oriented" enough for
you, but experience has shown that griping about SWT's
object-orientedness or lack thereof yields exactly nothing. SWT is what
it is, and it's a pretty fine example of what it is.
Bob Foster
Brad Reynolds wrote:
> I've been messing around with SWT for a few months and I've enjoyed the
> experience so far. While looking around I've noticed that there aren't
> interfaces for widgets like Text, Button, etc. If I was tasked with
> creating a cross platform widget toolkit one of the first decisions I
> would have made was to create Interfaces so that across platforms I was
> guaranteed to have consistency. I'm assuming that there is testing that
> occurs to guarantee that the current widget interfaces remain consistent
> across platforms. So what was the reason for the design decision to not
> have these interfaces? Also I'm asking this from an education
> perspective as I know you guys have more experience in this field than I
> do. This question is by no means intended to be of a condescending nature.
>
> One thing I'd like to point out is that by not having interfaces I've
> feel like I've been limited in my ability to create true decorators of
> widgets. I work for a corporation and my job is to create a usable
> component toolkit that aligns with the needs of the company. We are
> utilizing Eclipse RCP and JFace on top of SWT. I have the need to add
> to the API of existing widgets. I'm not wanting to change any current
> API but merely to add to the existing widgets with either standard
> styling or methods for validation. Styling could be done by retrieving
> the component from a factory but the addition of API could not. I'm not
> looking to add a lot of API either. I guess I don't see common
> validation routines as something that should be above the API of my widget.
>
> The other concern that I have is that since I don't have an interface I
> can't utilize the existing widget tests in abbot if I was to create a
> decorator for a widget.
>
> Any input is greatly appreciated.
>
> Thanks,
> Brad
|
|
|
| Re: Why no widget Interfaces? [message #452087 is a reply to message #452020] |
Mon, 14 March 2005 13:30 |
 Brad Reynolds
Messages: 309
Registered: July 2009 |
Senior Member |
|
|
I've read the articles on eclipse.org multiple times and also read "SWT:
The Standard Widget Toolkit" cover to cover and haven't seen anything in
reference to interfaces. I understand the desire to limit extension and
I agree with it. I'm just not sure why an interface isn't exposed to
allow for proper wrapping of widgets. If there is a specific article
that you're referring to I'd appreciate it if you could point me to it.
On adding API if I understand what you're saying I've followed this
pattern as well. The problem is that I have consumers too and they
expect a simple easy to use toolkit. But because I can't implement a
widget interface I have to expose the widget that is being wrapped on
each control. This forces them to have to understand that there is my
API on the wrapping object and the SWT API on the wrapped object. I can
see how this can lead to confusion. Also from a design perspective I'm
still not a fan of exposing the SWT implementation of my objects. The
reason being that down the road if I need to know about an attribute
being set or method being called on a widget I don't have the
appropriate hooks to listen to this event. If I start implementing
these methods on my object I'll have to somehow communicate to my
consumers that they're to use my API and not the SWT API. I need to be
prepared and a proper wrapper would allow me to do that but at this
point in time I don't see how this can be accomplished.
Also the layers above SWT expect SWT implementations. Take the
TableViewer for instance. It expects a Table and won't accept anything
else. I want to use the TableViewer but I need to know when a TableItem
and TableColumn is added to my Table for styling purposes. Since I need
to know this I have to write a wrapping widget for the Table and I can't
implement the Table interface. So I have to write a new viewer as well
even though the behavior hasn't changed whatsoever.
I've tried to avoid attempting to extend the SWT API because of the
wishes of the SWT designers and I didn't want my consumers to cause
problems for themselves by then extending my class and forgetting to
dispose of resources. But I think with a wrapper I can mitigate this
risk. Is adding API thought of as a situation where it would be
acceptable for extension? It technically would still follow the "is a"
rule, it's just that it "is a" little more now.
Don't get me wrong, I believe SWT is well designed and implemented. My
concern is that a lot of the design seems to be geared toward keeping
the consumer from hanging themself. I think this is all well and good
but I'm curious if anyone believes that because of the growing
popularity of eclipse and SWT that maybe the requirements have changed.
Reuse isn't always all it's cracked up to be but in these scenarios I
don't see why I'm being limited.
Brad
Bob Foster wrote:
> Read the several articles at eclipse.org on the design of SWT.
>
> One user to another: You can't add API to SWT. You'll have to think of
> another way to do it. It's simple, for example, to create a validation
> interface, implement it for the applicable SWT classes and map from SWT
> class to implementation. That may not be "object-oriented" enough for
> you, but experience has shown that griping about SWT's
> object-orientedness or lack thereof yields exactly nothing. SWT is what
> it is, and it's a pretty fine example of what it is.
>
> Bob Foster
>
> Brad Reynolds wrote:
>
>> I've been messing around with SWT for a few months and I've enjoyed
>> the experience so far. While looking around I've noticed that there
>> aren't interfaces for widgets like Text, Button, etc. If I was tasked
>> with creating a cross platform widget toolkit one of the first
>> decisions I would have made was to create Interfaces so that across
>> platforms I was guaranteed to have consistency. I'm assuming that
>> there is testing that occurs to guarantee that the current widget
>> interfaces remain consistent across platforms. So what was the reason
>> for the design decision to not have these interfaces? Also I'm asking
>> this from an education perspective as I know you guys have more
>> experience in this field than I do. This question is by no means
>> intended to be of a condescending nature.
>>
>> One thing I'd like to point out is that by not having interfaces I've
>> feel like I've been limited in my ability to create true decorators of
>> widgets. I work for a corporation and my job is to create a usable
>> component toolkit that aligns with the needs of the company. We are
>> utilizing Eclipse RCP and JFace on top of SWT. I have the need to add
>> to the API of existing widgets. I'm not wanting to change any current
>> API but merely to add to the existing widgets with either standard
>> styling or methods for validation. Styling could be done by
>> retrieving the component from a factory but the addition of API could
>> not. I'm not looking to add a lot of API either. I guess I don't see
>> common validation routines as something that should be above the API
>> of my widget.
>>
>> The other concern that I have is that since I don't have an interface
>> I can't utilize the existing widget tests in abbot if I was to create
>> a decorator for a widget.
>>
>> Any input is greatly appreciated.
>>
>> Thanks,
>> Brad
|
|
|
| Re: Why no widget Interfaces? [message #452088 is a reply to message #452020] |
Mon, 14 March 2005 13:35 |
Brad Reynolds
Messages: 309
Registered: July 2009 |
Senior Member |
|
|
I've read the articles on eclipse.org multiple times and also read "SWT:
The Standard Widget Toolkit" cover to cover and haven't seen anything in
reference to interfaces. I understand the desire to limit extension and
I agree with it. I'm just not sure why an interface isn't exposed to
allow for proper wrapping of widgets. If there is a specific article
that you're referring to I'd appreciate it if you could point me to it.
On adding API if I understand what you're saying I've followed this
pattern as well. The problem is that I have consumers too and they
expect a simple easy to use toolkit. But because I can't implement a
widget interface I have to expose the widget that is being wrapped on
each control. This forces them to have to understand that there is my
API on the wrapping object and the SWT API on the wrapped object. I can
see how this can lead to confusion. Also from a design perspective I'm
still not a fan of exposing the SWT implementation of my objects. The
reason being that down the road if I need to know about an attribute
being set or method being called on a widget I don't have the
appropriate hooks to listen to this event. If I start implementing
these methods on my object I'll have to somehow communicate to my
consumers that they're to use my API and not the SWT API. I need to be
prepared and a proper wrapper would allow me to do that but at this
point in time I don't see how this can be accomplished.
Also the layers above SWT expect SWT implementations. Take the
TableViewer for instance. It expects a Table and won't accept anything
else. I want to use the TableViewer but I need to know when a TableItem
and TableColumn is added to my Table for styling purposes. Since I need
to know this I have to write a wrapping widget for the Table and I can't
implement the Table interface. So I have to write a new viewer as well
even though the behavior hasn't changed whatsoever.
I've tried to avoid attempting to extend the SWT API because of the
wishes of the SWT designers and I didn't want my consumers to cause
problems for themselves by then extending my class and forgetting to
dispose of resources. But I think with a wrapper I can mitigate this
risk. Is adding API thought of as a situation where it would be
acceptable for extension? It technically would still follow the "is a"
rule, it's just that it "is a" little more now.
Don't get me wrong, I believe SWT is well designed and implemented. My
concern is that a lot of the design seems to be geared toward keeping
the consumer from hanging themself. I think this is all well and good
but I'm curious if anyone believes that because of the growing
popularity of eclipse and SWT that maybe the requirements have changed.
Reuse isn't always all it's cracked up to be but in these scenarios I
don't see why I'm being limited.
Brad
Bob Foster wrote:
> Read the several articles at eclipse.org on the design of SWT.
>
> One user to another: You can't add API to SWT. You'll have to think of
> another way to do it. It's simple, for example, to create a validation
> interface, implement it for the applicable SWT classes and map from SWT
> class to implementation. That may not be "object-oriented" enough for
> you, but experience has shown that griping about SWT's
> object-orientedness or lack thereof yields exactly nothing. SWT is what
> it is, and it's a pretty fine example of what it is.
>
> Bob Foster
>
> Brad Reynolds wrote:
>
>> I've been messing around with SWT for a few months and I've enjoyed
>> the experience so far. While looking around I've noticed that there
>> aren't interfaces for widgets like Text, Button, etc. If I was tasked
>> with creating a cross platform widget toolkit one of the first
>> decisions I would have made was to create Interfaces so that across
>> platforms I was guaranteed to have consistency. I'm assuming that
>> there is testing that occurs to guarantee that the current widget
>> interfaces remain consistent across platforms. So what was the reason
>> for the design decision to not have these interfaces? Also I'm asking
>> this from an education perspective as I know you guys have more
>> experience in this field than I do. This question is by no means
>> intended to be of a condescending nature.
>>
>> One thing I'd like to point out is that by not having interfaces I've
>> feel like I've been limited in my ability to create true decorators of
>> widgets. I work for a corporation and my job is to create a usable
>> component toolkit that aligns with the needs of the company. We are
>> utilizing Eclipse RCP and JFace on top of SWT. I have the need to add
>> to the API of existing widgets. I'm not wanting to change any current
>> API but merely to add to the existing widgets with either standard
>> styling or methods for validation. Styling could be done by
>> retrieving the component from a factory but the addition of API could
>> not. I'm not looking to add a lot of API either. I guess I don't see
>> common validation routines as something that should be above the API
>> of my widget.
>>
>> The other concern that I have is that since I don't have an interface
>> I can't utilize the existing widget tests in abbot if I was to create
>> a decorator for a widget.
>>
>> Any input is greatly appreciated.
>>
>> Thanks,
>> Brad
|
|
|
| Re: Why no widget Interfaces? [message #452167 is a reply to message #452087] |
Mon, 14 March 2005 21:35 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
I never have any luck telling people they are falling into a rathole.
Probably I should just let it go. But... ;-}
AFAIK there isn't anywhere it is written "no interfaces". This falls
under the general rule: no "extra" lines of code. Interfaces don't do
anything, but they require maintenance, add overhead, the entire API
would have to be redone in terms of interfaces, etc. Fat chance. As for
wrapper classes, overhead overhead overhead.
I can see from your point of view how it makes sense to flog this dead
horse, and I hope you can see the other point of view. ;-}
Bob
Brad Reynolds wrote:
> I've read the articles on eclipse.org multiple times and also read "SWT:
> The Standard Widget Toolkit" cover to cover and haven't seen anything in
> reference to interfaces. I understand the desire to limit extension and
> I agree with it. I'm just not sure why an interface isn't exposed to
> allow for proper wrapping of widgets. If there is a specific article
> that you're referring to I'd appreciate it if you could point me to it.
>
> On adding API if I understand what you're saying I've followed this
> pattern as well. The problem is that I have consumers too and they
> expect a simple easy to use toolkit. But because I can't implement a
> widget interface I have to expose the widget that is being wrapped on
> each control. This forces them to have to understand that there is my
> API on the wrapping object and the SWT API on the wrapped object. I can
> see how this can lead to confusion. Also from a design perspective I'm
> still not a fan of exposing the SWT implementation of my objects. The
> reason being that down the road if I need to know about an attribute
> being set or method being called on a widget I don't have the
> appropriate hooks to listen to this event. If I start implementing
> these methods on my object I'll have to somehow communicate to my
> consumers that they're to use my API and not the SWT API. I need to be
> prepared and a proper wrapper would allow me to do that but at this
> point in time I don't see how this can be accomplished.
>
> Also the layers above SWT expect SWT implementations. Take the
> TableViewer for instance. It expects a Table and won't accept anything
> else. I want to use the TableViewer but I need to know when a TableItem
> and TableColumn is added to my Table for styling purposes. Since I need
> to know this I have to write a wrapping widget for the Table and I can't
> implement the Table interface. So I have to write a new viewer as well
> even though the behavior hasn't changed whatsoever.
>
> I've tried to avoid attempting to extend the SWT API because of the
> wishes of the SWT designers and I didn't want my consumers to cause
> problems for themselves by then extending my class and forgetting to
> dispose of resources. But I think with a wrapper I can mitigate this
> risk. Is adding API thought of as a situation where it would be
> acceptable for extension? It technically would still follow the "is a"
> rule, it's just that it "is a" little more now.
>
> Don't get me wrong, I believe SWT is well designed and implemented. My
> concern is that a lot of the design seems to be geared toward keeping
> the consumer from hanging themself. I think this is all well and good
> but I'm curious if anyone believes that because of the growing
> popularity of eclipse and SWT that maybe the requirements have changed.
> Reuse isn't always all it's cracked up to be but in these scenarios I
> don't see why I'm being limited.
>
> Brad
>
> Bob Foster wrote:
>
>> Read the several articles at eclipse.org on the design of SWT.
>>
>> One user to another: You can't add API to SWT. You'll have to think of
>> another way to do it. It's simple, for example, to create a validation
>> interface, implement it for the applicable SWT classes and map from
>> SWT class to implementation. That may not be "object-oriented" enough
>> for you, but experience has shown that griping about SWT's
>> object-orientedness or lack thereof yields exactly nothing. SWT is
>> what it is, and it's a pretty fine example of what it is.
>>
>> Bob Foster
>>
>> Brad Reynolds wrote:
>>
>>> I've been messing around with SWT for a few months and I've enjoyed
>>> the experience so far. While looking around I've noticed that there
>>> aren't interfaces for widgets like Text, Button, etc. If I was
>>> tasked with creating a cross platform widget toolkit one of the first
>>> decisions I would have made was to create Interfaces so that across
>>> platforms I was guaranteed to have consistency. I'm assuming that
>>> there is testing that occurs to guarantee that the current widget
>>> interfaces remain consistent across platforms. So what was the
>>> reason for the design decision to not have these interfaces? Also
>>> I'm asking this from an education perspective as I know you guys have
>>> more experience in this field than I do. This question is by no
>>> means intended to be of a condescending nature.
>>>
>>> One thing I'd like to point out is that by not having interfaces I've
>>> feel like I've been limited in my ability to create true decorators
>>> of widgets. I work for a corporation and my job is to create a
>>> usable component toolkit that aligns with the needs of the company.
>>> We are utilizing Eclipse RCP and JFace on top of SWT. I have the
>>> need to add to the API of existing widgets. I'm not wanting to
>>> change any current API but merely to add to the existing widgets with
>>> either standard styling or methods for validation. Styling could be
>>> done by retrieving the component from a factory but the addition of
>>> API could not. I'm not looking to add a lot of API either. I guess
>>> I don't see common validation routines as something that should be
>>> above the API of my widget.
>>>
>>> The other concern that I have is that since I don't have an interface
>>> I can't utilize the existing widget tests in abbot if I was to create
>>> a decorator for a widget.
>>>
>>> Any input is greatly appreciated.
>>>
>>> Thanks,
>>> Brad
|
|
|
| Re: Why no widget Interfaces? [message #452211 is a reply to message #452167] |
Tue, 15 March 2005 13:24 |
Brad Reynolds
Messages: 309
Registered: July 2009 |
Senior Member |
|
|
An interface doesn't inherently DO anything. Agreed. But it does
provide the ability so that any SWT consumer can add to a widget's API
with their own implementation. This is a big deal and would end these
conversations for good. Also I wouldn't expect SWT to provide any
wrapper classes. That would be up to the consumer to provide and they'd
be able to do it if interfaces were provided. It would be a lot of work
by the consumer but at least it would be a tool available to the
consumer when at this moment in time we have none.
I do see the SWT point of view in that it needs to be as lean and mean
as possible but I also don't think it's the job of SWT to govern what
can be done with the toolkit. Just because there are developers out
there who will misuse it doesn't mean we should limit everyone.
It would take a lot of work to create interfaces because of existing
code but software has to evolve in order to survive.
Just because I can I might log a bug in bugzilla with at least my
request. It will have one lonely vote and will be laughed at by all the
other bugs but I at least need to do my part.
Bob Foster wrote:
> I never have any luck telling people they are falling into a rathole.
> Probably I should just let it go. But... ;-}
>
> AFAIK there isn't anywhere it is written "no interfaces". This falls
> under the general rule: no "extra" lines of code. Interfaces don't do
> anything, but they require maintenance, add overhead, the entire API
> would have to be redone in terms of interfaces, etc. Fat chance. As for
> wrapper classes, overhead overhead overhead.
>
> I can see from your point of view how it makes sense to flog this dead
> horse, and I hope you can see the other point of view. ;-}
>
> Bob
>
> Brad Reynolds wrote:
>
>> I've read the articles on eclipse.org multiple times and also read
>> "SWT: The Standard Widget Toolkit" cover to cover and haven't seen
>> anything in reference to interfaces. I understand the desire to limit
>> extension and I agree with it. I'm just not sure why an interface
>> isn't exposed to allow for proper wrapping of widgets. If there is a
>> specific article that you're referring to I'd appreciate it if you
>> could point me to it.
>>
>> On adding API if I understand what you're saying I've followed this
>> pattern as well. The problem is that I have consumers too and they
>> expect a simple easy to use toolkit. But because I can't implement a
>> widget interface I have to expose the widget that is being wrapped on
>> each control. This forces them to have to understand that there is my
>> API on the wrapping object and the SWT API on the wrapped object. I
>> can see how this can lead to confusion. Also from a design
>> perspective I'm still not a fan of exposing the SWT implementation of
>> my objects. The reason being that down the road if I need to know
>> about an attribute being set or method being called on a widget I
>> don't have the appropriate hooks to listen to this event. If I start
>> implementing these methods on my object I'll have to somehow
>> communicate to my consumers that they're to use my API and not the SWT
>> API. I need to be prepared and a proper wrapper would allow me to do
>> that but at this point in time I don't see how this can be accomplished.
>>
>> Also the layers above SWT expect SWT implementations. Take the
>> TableViewer for instance. It expects a Table and won't accept
>> anything else. I want to use the TableViewer but I need to know when
>> a TableItem and TableColumn is added to my Table for styling
>> purposes. Since I need to know this I have to write a wrapping widget
>> for the Table and I can't implement the Table interface. So I have to
>> write a new viewer as well even though the behavior hasn't changed
>> whatsoever.
>>
>> I've tried to avoid attempting to extend the SWT API because of the
>> wishes of the SWT designers and I didn't want my consumers to cause
>> problems for themselves by then extending my class and forgetting to
>> dispose of resources. But I think with a wrapper I can mitigate this
>> risk. Is adding API thought of as a situation where it would be
>> acceptable for extension? It technically would still follow the "is
>> a" rule, it's just that it "is a" little more now.
>>
>> Don't get me wrong, I believe SWT is well designed and implemented.
>> My concern is that a lot of the design seems to be geared toward
>> keeping the consumer from hanging themself. I think this is all well
>> and good but I'm curious if anyone believes that because of the
>> growing popularity of eclipse and SWT that maybe the requirements have
>> changed. Reuse isn't always all it's cracked up to be but in these
>> scenarios I don't see why I'm being limited.
>>
>> Brad
>>
>> Bob Foster wrote:
>>
>>> Read the several articles at eclipse.org on the design of SWT.
>>>
>>> One user to another: You can't add API to SWT. You'll have to think
>>> of another way to do it. It's simple, for example, to create a
>>> validation interface, implement it for the applicable SWT classes and
>>> map from SWT class to implementation. That may not be
>>> "object-oriented" enough for you, but experience has shown that
>>> griping about SWT's object-orientedness or lack thereof yields
>>> exactly nothing. SWT is what it is, and it's a pretty fine example of
>>> what it is.
>>>
>>> Bob Foster
>>>
>>> Brad Reynolds wrote:
>>>
>>>> I've been messing around with SWT for a few months and I've enjoyed
>>>> the experience so far. While looking around I've noticed that there
>>>> aren't interfaces for widgets like Text, Button, etc. If I was
>>>> tasked with creating a cross platform widget toolkit one of the
>>>> first decisions I would have made was to create Interfaces so that
>>>> across platforms I was guaranteed to have consistency. I'm assuming
>>>> that there is testing that occurs to guarantee that the current
>>>> widget interfaces remain consistent across platforms. So what was
>>>> the reason for the design decision to not have these interfaces?
>>>> Also I'm asking this from an education perspective as I know you
>>>> guys have more experience in this field than I do. This question is
>>>> by no means intended to be of a condescending nature.
>>>>
>>>> One thing I'd like to point out is that by not having interfaces
>>>> I've feel like I've been limited in my ability to create true
>>>> decorators of widgets. I work for a corporation and my job is to
>>>> create a usable component toolkit that aligns with the needs of the
>>>> company. We are utilizing Eclipse RCP and JFace on top of SWT. I
>>>> have the need to add to the API of existing widgets. I'm not
>>>> wanting to change any current API but merely to add to the existing
>>>> widgets with either standard styling or methods for validation.
>>>> Styling could be done by retrieving the component from a factory but
>>>> the addition of API could not. I'm not looking to add a lot of API
>>>> either. I guess I don't see common validation routines as something
>>>> that should be above the API of my widget.
>>>>
>>>> The other concern that I have is that since I don't have an
>>>> interface I can't utilize the existing widget tests in abbot if I
>>>> was to create a decorator for a widget.
>>>>
>>>> Any input is greatly appreciated.
>>>>
>>>> Thanks,
>>>> Brad
|
|
|
| Re: Why no widget Interfaces? [message #452250 is a reply to message #452088] |
Tue, 15 March 2005 22:10 |
ted stockwell
Messages: 123
Registered: July 2009 |
Senior Member |
|
|
Brad Reynolds wrote:
> I've read the articles on eclipse.org multiple times and also read "SWT:
> The Standard Widget Toolkit" cover to cover and haven't seen anything in
> reference to interfaces. I understand the desire to limit extension and
> I agree with it. I'm just not sure why an interface isn't exposed to
> allow for proper wrapping of widgets. If there is a specific article
> that you're referring to I'd appreciate it if you could point me to it.
>
Hi Brad,
I have a suggestion that you may like (or hate).
(the following information is actually relevant to my proposal...)
I have recently rewritten Remote SWT, http://rswt.sf.net (the new implementation has not been released yet).
RSWT is a thin-client UI toolkit similar in concept to other thin-client technologies like ULC, http://www.canoo.com/ulc/.
With RSWT you create a SWT application that runs on top of the Eclipse runtime platform.
Then, if you specify '-ws rswt' on the command line when you start your application your SWT application will automagically run
as a server-application that can be accessed by an RSWT client.
-ws is an Eclipse command line option that specifies the 'window system' to use, basically it is used to explicitly set the SWT
implementation to run with.
Like you, I would have appreciated a more OO-based toolkit design. In RSWT every server-side UI change must be communicated to
the client-side UI. This is kinda difficult for some SWT objects, like a GridData object where the properties are simply
publically accessable fields. If GridData encapsulated its properties in setter/getter methods then it would be a simple matter
for RSWT's SWT implementation to detect property changes and communicate them to the client.
Anyway, I have found a satisfying way around SWT's design; AspectWerkz, http://aspectwerkz.codehaus.org/.
With AspectWerks I can 'hook' into GridData field assignments and do the right thing.
If you use AspectWerkz in conjunction with SWT then you can add interfaces to SWT classes in a maintainable way that does not
require buy in from the SWT comitters (AspectWerkz calls them 'mixins').
You can also hook into constructors (like TableItem and TableCoukn constructors) and all kinds of 'join points'.
Developers that choose to use your 'extended' version of SWT could cast SWT widgets to your interfaces.
Developers that choose to use your 'extended' version of SWT would specify your toolkit name on the command line when running
thier application, -ws myToolkit.
Of course, this proposal is also possible without using the Eclipse runtime platform, it's just that I write everything to run
on top of Eclipse ;-).
|
|
|
| Re: Why no widget Interfaces? [message #452258 is a reply to message #452211] |
Wed, 16 March 2005 05:56 |
| Eclipse User |
|
|
|
Originally posted by: bob.objfac.com
Brad Reynolds wrote:
> Just because I can I might log a bug in bugzilla with at least my
> request. It will have one lonely vote and will be laughed at by all the
> other bugs but I at least need to do my part.
There is nothing wrong with your POV. By all means assert it, log a bug
or feature request, and tell others on this list the bug/feature # so
they can add their votes and comment.
I think the showstopper in your idea, all philosophy aside, is that it
would break the current API. But don't let anybody, especially me, deter
you from pursuing it.
Bob
|
|
| |
| Re: Why no widget Interfaces? [message #452266 is a reply to message #452250] |
Wed, 16 March 2005 13:25 |
Brad Reynolds
Messages: 309
Registered: July 2009 |
Senior Member |
|
|
There are not many times when I can say I never thought of that in one
way or another but I never would have thought of use AOP for this. I'll
definitely consider it. A while back I looked into RSWT. I think it
was on the first release but at the time deadlines were tight for me and
I had labeled it as experimental. But I like the concept and when I can
get some time I'll look into it again because it does address some of
our concerns. Whenever I get that time I might be looking you up. :)
Thanks for the information.
ted stockwell wrote:
> Brad Reynolds wrote:
>
>> I've read the articles on eclipse.org multiple times and also read "SWT:
>> The Standard Widget Toolkit" cover to cover and haven't seen anything in
>> reference to interfaces. I understand the desire to limit extension and
>> I agree with it. I'm just not sure why an interface isn't exposed to
>> allow for proper wrapping of widgets. If there is a specific article
>> that you're referring to I'd appreciate it if you could point me to it.
>>
>
> Hi Brad,
>
> I have a suggestion that you may like (or hate).
>
> (the following information is actually relevant to my proposal...)
> I have recently rewritten Remote SWT, http://rswt.sf.net (the new
> implementation has not been released yet).
> RSWT is a thin-client UI toolkit similar in concept to other thin-client
> technologies like ULC, http://www.canoo.com/ulc/.
> With RSWT you create a SWT application that runs on top of the Eclipse
> runtime platform.
> Then, if you specify '-ws rswt' on the command line when you start your
> application your SWT application will automagically run
> as a server-application that can be accessed by an RSWT client.
> -ws is an Eclipse command line option that specifies the 'window system'
> to use, basically it is used to explicitly set the SWT
> implementation to run with.
>
> Like you, I would have appreciated a more OO-based toolkit design. In
> RSWT every server-side UI change must be communicated to
> the client-side UI. This is kinda difficult for some SWT objects, like
> a GridData object where the properties are simply
> publically accessable fields. If GridData encapsulated its properties
> in setter/getter methods then it would be a simple matter
> for RSWT's SWT implementation to detect property changes and communicate
> them to the client.
>
> Anyway, I have found a satisfying way around SWT's design; AspectWerkz,
> http://aspectwerkz.codehaus.org/.
> With AspectWerks I can 'hook' into GridData field assignments and do the
> right thing.
>
> If you use AspectWerkz in conjunction with SWT then you can add
> interfaces to SWT classes in a maintainable way that does not
> require buy in from the SWT comitters (AspectWerkz calls them 'mixins').
> You can also hook into constructors (like TableItem and TableCoukn
> constructors) and all kinds of 'join points'.
> Developers that choose to use your 'extended' version of SWT could cast
> SWT widgets to your interfaces.
> Developers that choose to use your 'extended' version of SWT would
> specify your toolkit name on the command line when running
> thier application, -ws myToolkit.
>
> Of course, this proposal is also possible without using the Eclipse
> runtime platform, it's just that I write everything to run
> on top of Eclipse ;-).
>
>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 16:29:45 GMT 2024
Powered by FUDForum. Page generated in 0.05125 seconds |
] 
Search
Help
Register
Login
Home
