Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Frustrated!!
|
| Re: Frustrated!! [message #441426 is a reply to message #441414] |
Sun, 15 August 2004 20:42   |
 Daniel Spiewak
Messages: 263
Registered: July 2009 |
Senior Member |
|
|
Hey, you'll but quite happy to learn that you aren't alone. I struggled
with the same issues when I learned SWT. However, do remember that
several studies have indicated that SWT is actually /more/ intuitive
than Swing. VB's pretty intuitive, but a) it's not Java, and b) no
layout managers.
To me, it makes more sense to create a widget and pass the parent right
away. With Swing, you can add a component to two different parents and
it won't be caught until runtime. SWT supports compile time checking to
make sure that you haven't added the widget twice.
Constructor overloading isn't supported (except in a very few instances,
like MenuItem(Composite, int, int)) because it just makes for messy,
inconsistent APIs. When I learn a new widget in the SWT library, I know
with almost complete certainty that the constructor will be
<widget-name>(Composite, int) The style constants used will be
described in the javadoc for the constructor, and it's all very clean
and consistent. Also, you don't have to worry about remember that
JButton has a gazillion constructors that all do pretty much the same
thing. Button has one visible constructor. All widget properties are
/always/ set as, well, JavaBean properties.
The 'set' and 'get' conventions are followed (save with methods like
setFocus()). The result is that the code becomes much more intuitive,
once you get over the initial learning step. It took me three months to
get a feel for SWT initially. I dropped it for a month, and then came
back to it. When I came back, it felt very easy to pick it up and learn
as I went. I literally learned as I coded (the tool-tip javadoc in
Eclipse really helps btw).
One final thing to remember: Swing has a decent support of MVC in it's
API. SWT didn't even try to do that. It leaves more work for the
developer, but better flexibility and more hack room. If you really
want the MVC with SWT, try JFace.
Daniel
P.S. If you really, /really/ don't want to learn a new API, try SwingWT
(http://swingwt.sourceforge.net). It gives you the Swing API structure,
but the results of SWT.
James Carroll wrote:
>I'm learning SWT and I hafta admit that I am very frustrated. There are
>two main reasons:
>
>1. The "semantics" of GUI creation. To me it makes sense to create a
>Parent (shell, composite) and ADD children (widgets) to it. This passing
>the Parent to the child as a constrictor parameter is very "off putting".
>
>2. The widget constructors should be overloaded so that complete
>initialization can be done with one call. Having to write a second line
>JUST to set text of a button (or its icon or even listener) when it could
>be passed in the constructor is a source of constant irritation.
>
>I solace myself with the sage words of Bjarne (The C++ Programming
>Language, 3rd ed):
>
>"Thoughtlessly applying techniques effective in one language to another
>typically leads to awkward, poorly performing, and had-to-maintain code.
>Such code is also most frustrating to write because every lion of code and
>every compiler error message reminds the programmer that the language
>differs from the "old language".
>
>Sorry, if this seems like more of a rant the a question. But this VB/Java
>Swing programmer is tired of learning new "paradigms" GUI coding.
>
>At least its Friday.
>
>Take care all.
>
>
>
>
>
>
>
|
|
|
| Re: Frustrated!! [message #441430 is a reply to message #441426] |
Mon, 16 August 2004 02:16 |
James Carroll
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
Thank you very much for the kind words and encouragement. I definately
won't give up on SWT, I like the RCP too much. And I'm sure in a year or
two when I'm a SWT pro, they'll come out with something new and I'll learn
(and bemoan) that to. But that's what learning is all about.
Thanks again and best wishes.
Daniel Spiewak wrote:
> Hey, you'll but quite happy to learn that you aren't alone. I struggled
> with the same issues when I learned SWT. However, do remember that
> several studies have indicated that SWT is actually /more/ intuitive
> than Swing. VB's pretty intuitive, but a) it's not Java, and b) no
> layout managers.
> To me, it makes more sense to create a widget and pass the parent right
> away. With Swing, you can add a component to two different parents and
> it won't be caught until runtime. SWT supports compile time checking to
> make sure that you haven't added the widget twice.
> Constructor overloading isn't supported (except in a very few instances,
> like MenuItem(Composite, int, int)) because it just makes for messy,
> inconsistent APIs. When I learn a new widget in the SWT library, I know
> with almost complete certainty that the constructor will be
> <widget-name>(Composite, int) The style constants used will be
> described in the javadoc for the constructor, and it's all very clean
> and consistent. Also, you don't have to worry about remember that
> JButton has a gazillion constructors that all do pretty much the same
> thing. Button has one visible constructor. All widget properties are
> /always/ set as, well, JavaBean properties.
> The 'set' and 'get' conventions are followed (save with methods like
> setFocus()). The result is that the code becomes much more intuitive,
> once you get over the initial learning step. It took me three months to
> get a feel for SWT initially. I dropped it for a month, and then came
> back to it. When I came back, it felt very easy to pick it up and learn
> as I went. I literally learned as I coded (the tool-tip javadoc in
> Eclipse really helps btw).
> One final thing to remember: Swing has a decent support of MVC in it's
> API. SWT didn't even try to do that. It leaves more work for the
> developer, but better flexibility and more hack room. If you really
> want the MVC with SWT, try JFace.
> Daniel
> P.S. If you really, /really/ don't want to learn a new API, try SwingWT
> (http://swingwt.sourceforge.net). It gives you the Swing API structure,
> but the results of SWT.
> James Carroll wrote:
> >I'm learning SWT and I hafta admit that I am very frustrated. There are
> >two main reasons:
> >
> >1. The "semantics" of GUI creation. To me it makes sense to create a
> >Parent (shell, composite) and ADD children (widgets) to it. This passing
> >the Parent to the child as a constrictor parameter is very "off putting".
> >
> >2. The widget constructors should be overloaded so that complete
> >initialization can be done with one call. Having to write a second line
> >JUST to set text of a button (or its icon or even listener) when it could
> >be passed in the constructor is a source of constant irritation.
> >
> >I solace myself with the sage words of Bjarne (The C++ Programming
> >Language, 3rd ed):
> >
> >"Thoughtlessly applying techniques effective in one language to another
> >typically leads to awkward, poorly performing, and had-to-maintain code.
> >Such code is also most frustrating to write because every lion of code and
> >every compiler error message reminds the programmer that the language
> >differs from the "old language".
> >
> >Sorry, if this seems like more of a rant the a question. But this VB/Java
> >Swing programmer is tired of learning new "paradigms" GUI coding.
> >
> >At least its Friday.
> >
> >Take care all.
> >
> >
> >
> >
> >
> >
> >
|
|
|
| Re: Frustrated!! [message #441446 is a reply to message #441414] |
Mon, 16 August 2004 14:10 |
Simone Gianni
Messages: 29
Registered: July 2009 |
Junior Member |
|
|
I felt the same when I migrated from Swing to SWT. I felt that it was
HORRIBLE to have an int style passed in the costructor to obtain a
border or a scrollbar, and that all the "public static final int"'s
where in a omniglobal SWT class with no specification of what is
supported and what is not if not the javadoc.
Also, i suffered the threading model a lot. I thought it was stupid not
to have SWT run the thread itself, as AWT does, and have to manually
code an endless loop for every SWT thread you need (usually one, since
in GTK it does not support multiple displays yet).
Not to say, that the better thing JAVA has is a garbage collector, and
having to call dispose() methods pushed my life ten years back.
Also, all the use of int fields to distinguish between events ... why
not use subclassing and instanceof?
After using it for a while, i found it ok, but i still suffer quite a
lot while i code. I think that the design was dictated by the following
facts :
- SWT is java 1.1 compliant, so no collections, no maps, "stupid"
garbage collector.
- SWT is designed to be fast, as opposite to swing, so the single thread
and the int fields in events are a good way to make java fast.
- SWT has the commercial appeal of an answer to all those people that
got nauseated looking all swing interfaces, classes, methods,
constructors etc... and want to go straight to the point, not caring too
much about perfect object design.
- SWT has been designed not with java, but with c++ in mind. Everything
is extremely "c++ish", and if you ever coded with a c++ graphic toolkit
you'll see many relations between the two.
Anyway, also if all this arguments are good explanations of the design
decisions, I still feel that SWT is a hack, and also if MVC and extreme
subclassing of swing are not necessary for a toolkit, it would be
enought to have SWT look like a java library :
- No dispose : call dispose in finalize, make a singleton class holding
all the references to SWT objects and call dispose() when needed
(WeakReferences?) and addShutdownHook to cleanup when closing.
- Better style variables : if button supports LEFT and RIGHT, i expect
Button b = new Button(parent, Button.LEFT); (also because if it's true
that SWT have compile time checks for stuff like parents, it has only
SILENT runtime checks on styles .. look how many mails there are in this
newsgroup with answers like "use SWT.RIGHT in the style").
- Better multithread support : why cannot another thread even READ
values??????
SwingWT is a great idea and is also very very well coded, but puts you
back in the swing paranoia. JFace adds MVC support for some common objects.
Maybe we're missing an intermediate solution, a layer over SWT that
makes it a bit more java-like but still just a gui toolkit.
Ciao,
Simone Gianni
James Carroll wrote:
> I'm learning SWT and I hafta admit that I am very frustrated. There are
> two main reasons:
>
> 1. The "semantics" of GUI creation. To me it makes sense to create a
> Parent (shell, composite) and ADD children (widgets) to it. This passing
> the Parent to the child as a constrictor parameter is very "off putting".
>
> 2. The widget constructors should be overloaded so that complete
> initialization can be done with one call. Having to write a second line
> JUST to set text of a button (or its icon or even listener) when it could
> be passed in the constructor is a source of constant irritation.
>
> I solace myself with the sage words of Bjarne (The C++ Programming
> Language, 3rd ed):
>
> "Thoughtlessly applying techniques effective in one language to another
> typically leads to awkward, poorly performing, and had-to-maintain code.
> Such code is also most frustrating to write because every lion of code and
> every compiler error message reminds the programmer that the language
> differs from the "old language".
>
> Sorry, if this seems like more of a rant the a question. But this VB/Java
> Swing programmer is tired of learning new "paradigms" GUI coding.
>
> At least its Friday.
>
> Take care all.
>
>
>
>
>
|
|
|
| Re: Frustrated!! [message #441527 is a reply to message #441446] |
Mon, 16 August 2004 20:30 |
Carolyn MacLeod
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
For the story behind why we did not use "finalize", see this article:
http://www.eclipse.org/articles/swt-design-2/swt-design-2.ht ml
For the story behind SWT, read the History section of this book:
http://www.amazon.com/exec/obidos/ASIN/0321256638/qid%3D1092 610159/sr%3D2-1/ref%3Dsr%5F2%5F1/102-4141515-1386563
Carolyn
"Simone Gianni" <s.gianni@thebug.it> wrote in message
news:cfqf42$tp0$1@eclipse.org...
> I felt the same when I migrated from Swing to SWT. I felt that it was
> HORRIBLE to have an int style passed in the costructor to obtain a
> border or a scrollbar, and that all the "public static final int"'s
> where in a omniglobal SWT class with no specification of what is
> supported and what is not if not the javadoc.
>
> Also, i suffered the threading model a lot. I thought it was stupid not
> to have SWT run the thread itself, as AWT does, and have to manually
> code an endless loop for every SWT thread you need (usually one, since
> in GTK it does not support multiple displays yet).
>
> Not to say, that the better thing JAVA has is a garbage collector, and
> having to call dispose() methods pushed my life ten years back.
>
> Also, all the use of int fields to distinguish between events ... why
> not use subclassing and instanceof?
>
> After using it for a while, i found it ok, but i still suffer quite a
> lot while i code. I think that the design was dictated by the following
> facts :
>
> - SWT is java 1.1 compliant, so no collections, no maps, "stupid"
> garbage collector.
> - SWT is designed to be fast, as opposite to swing, so the single thread
> and the int fields in events are a good way to make java fast.
> - SWT has the commercial appeal of an answer to all those people that
> got nauseated looking all swing interfaces, classes, methods,
> constructors etc... and want to go straight to the point, not caring too
> much about perfect object design.
> - SWT has been designed not with java, but with c++ in mind. Everything
> is extremely "c++ish", and if you ever coded with a c++ graphic toolkit
> you'll see many relations between the two.
>
> Anyway, also if all this arguments are good explanations of the design
> decisions, I still feel that SWT is a hack, and also if MVC and extreme
> subclassing of swing are not necessary for a toolkit, it would be
> enought to have SWT look like a java library :
> - No dispose : call dispose in finalize, make a singleton class holding
> all the references to SWT objects and call dispose() when needed
> (WeakReferences?) and addShutdownHook to cleanup when closing.
> - Better style variables : if button supports LEFT and RIGHT, i expect
> Button b = new Button(parent, Button.LEFT); (also because if it's true
> that SWT have compile time checks for stuff like parents, it has only
> SILENT runtime checks on styles .. look how many mails there are in this
> newsgroup with answers like "use SWT.RIGHT in the style").
> - Better multithread support : why cannot another thread even READ
> values??????
>
> SwingWT is a great idea and is also very very well coded, but puts you
> back in the swing paranoia. JFace adds MVC support for some common
objects.
>
> Maybe we're missing an intermediate solution, a layer over SWT that
> makes it a bit more java-like but still just a gui toolkit.
>
> Ciao,
> Simone Gianni
>
>
> James Carroll wrote:
> > I'm learning SWT and I hafta admit that I am very frustrated. There are
> > two main reasons:
> >
> > 1. The "semantics" of GUI creation. To me it makes sense to create a
> > Parent (shell, composite) and ADD children (widgets) to it. This passing
> > the Parent to the child as a constrictor parameter is very "off
putting".
> >
> > 2. The widget constructors should be overloaded so that complete
> > initialization can be done with one call. Having to write a second line
> > JUST to set text of a button (or its icon or even listener) when it
could
> > be passed in the constructor is a source of constant irritation.
> >
> > I solace myself with the sage words of Bjarne (The C++ Programming
> > Language, 3rd ed):
> >
> > "Thoughtlessly applying techniques effective in one language to another
> > typically leads to awkward, poorly performing, and had-to-maintain code.
> > Such code is also most frustrating to write because every lion of code
and
> > every compiler error message reminds the programmer that the language
> > differs from the "old language".
> >
> > Sorry, if this seems like more of a rant the a question. But this
VB/Java
> > Swing programmer is tired of learning new "paradigms" GUI coding.
> >
> > At least its Friday.
> >
> > Take care all.
> >
> >
> >
> >
> >
|
|
|
| Re: Frustrated!! [message #441569 is a reply to message #441446] |
Tue, 17 August 2004 11:33 |
Ivan Markov
Messages: 61
Registered: July 2009 |
Member |
|
|
Simone,
Please, find my comments below.
> I felt the same when I migrated from Swing to SWT. I felt that it was
> HORRIBLE to have an int style passed in the costructor to obtain a
> border or a scrollbar, and that all the "public static final int"'s
> where in a omniglobal SWT class with no specification of what is
> supported and what is not if not the javadoc.
I agree this is one of the few design points I don't like in SWT.
Style constants should have been isolated directly in the corresponding
control (Label, Button, etc. instead of in the single SWT class).
> Also, i suffered the threading model a lot. I thought it was stupid not
> to have SWT run the thread itself, as AWT does, and have to manually
> code an endless loop for every SWT thread you need (usually one, since
> in GTK it does not support multiple displays yet).
1) The loop is not "endless".
2) All toolkits EXCEPT AWTSwing DO have explicit event loop. Here AWTSwing
is the exception, not SWT.
Granted, some of the toolkits spin event loop with a single call, ala:
App::runEventLoop() or something, which could have been a better idea for
SWT too, because mapping SWT verbose message loop to native toolkit's event
loop is currently real PITA.
> Not to say, that the better thing JAVA has is a garbage collector, and
> having to call dispose() methods pushed my life ten years back.
Garbage collection is intended for automatical reclaim of memory resource
only.
It is not suitable for reclaiming other OS resources, especially scarce ones
like graphics contexts, images, db connections etc. The fact that AWTSwing
tries to reclaim these automatically for you does not mean that you should
100% rely on that, as this leads to hard to find errors. Besides, both
AWTSwing & .NET WinForms have explicit dispose() calls for resources (.NET
even has the IDisposable notion all through its API) and you are actually
encouraged to use dispose() instsead of relying on finalizers.
> Also, all the use of int fields to distinguish between events ... why
> not use subclassing and instanceof?
??
> - SWT is java 1.1 compliant, so no collections, no maps, "stupid"
Why do you need maps and collections in UI toolkit API??
The lack of maps & collections should only bother the UI toolkit
implementors, not the toolkit users.
> - SWT is designed to be fast, as opposite to swing, so the single thread
> and the int fields in events are a good way to make java fast.
> - SWT has the commercial appeal of an answer to all those people that
> got nauseated looking all swing interfaces, classes, methods,
> constructors etc... and want to go straight to the point, not caring too
> much about perfect object design.
> - SWT has been designed not with java, but with c++ in mind. Everything
> is extremely "c++ish", and if you ever coded with a c++ graphic toolkit
> you'll see many relations between the two.
Could you be more specific here? I can't say I see many "C++-ish" things in
SWT. I do see many "UI Toolkitish" things though. :)
> - No dispose : call dispose in finalize, make a singleton class holding
> all the references to SWT objects and call dispose() when needed
> (WeakReferences?) and addShutdownHook to cleanup when closing.
This could only be optional, and as I said - this leads to hard to find
errors.
> - Better style variables : if button supports LEFT and RIGHT, i expect
> Button b = new Button(parent, Button.LEFT); (also because if it's true
> that SWT have compile time checks for stuff like parents, it has only
> SILENT runtime checks on styles .. look how many mails there are in this
> newsgroup with answers like "use SWT.RIGHT in the style").
Agreed.
> - Better multithread support : why cannot another thread even READ
> values??????
Isn't it obvious?
Most of the getters in SWT do not return the value of Java variable, but
instead call into the OS native layer.
Here's an example:
Control.getSize().
This innocent call, on Win32 resolves to OS.GetWindowPos() or something,
which shouldn't be called from a non-UI thread (well, not exactly true for
Win32, but definitely the truth for GTK+, Fox etc.).
Do you think it is worth caching all these values inside the Java Control
class, just to satisfy 0.1% of the users that need to only read from a
worker thread..?
Regards,
Ivan
|
|
| |
| Re: Frustrated!! [message #441619 is a reply to message #441569] |
Tue, 17 August 2004 15:23 |
Carolyn MacLeod
Messages: 149
Registered: July 2009 |
Senior Member |
|
|
Hi folks,
It *is* possible to read/write to the gui from another thread in swt... you
just have to put the code in a runnable and call display.syncExec or
asyncExec (ok, the code actually runs in the ui thread, but since you code
it in your other thread, it isn't really too different from just making the
call directly... <g>)
Here's an example snippet that updates a progress bar from a background
thread:
http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/platform -swt-home/snippits/snippet56.html
I'm sure you guys already knew this, but I wanted to mention it just in case
someone else reading this post might not realize it...
Carolyn
"Ivan Markov" <ivan.markov@wizcom.bg> wrote in message
news:cfsqae$c3n$1@eclipse.org...
> Simone,
>
> Please, find my comments below.
>
> > I felt the same when I migrated from Swing to SWT. I felt that it was
> > HORRIBLE to have an int style passed in the costructor to obtain a
> > border or a scrollbar, and that all the "public static final int"'s
> > where in a omniglobal SWT class with no specification of what is
> > supported and what is not if not the javadoc.
>
> I agree this is one of the few design points I don't like in SWT.
> Style constants should have been isolated directly in the corresponding
> control (Label, Button, etc. instead of in the single SWT class).
>
> > Also, i suffered the threading model a lot. I thought it was stupid not
> > to have SWT run the thread itself, as AWT does, and have to manually
> > code an endless loop for every SWT thread you need (usually one, since
> > in GTK it does not support multiple displays yet).
>
> 1) The loop is not "endless".
> 2) All toolkits EXCEPT AWTSwing DO have explicit event loop. Here AWTSwing
> is the exception, not SWT.
> Granted, some of the toolkits spin event loop with a single call, ala:
> App::runEventLoop() or something, which could have been a better idea for
> SWT too, because mapping SWT verbose message loop to native toolkit's
event
> loop is currently real PITA.
>
> > Not to say, that the better thing JAVA has is a garbage collector, and
> > having to call dispose() methods pushed my life ten years back.
>
> Garbage collection is intended for automatical reclaim of memory resource
> only.
> It is not suitable for reclaiming other OS resources, especially scarce
ones
> like graphics contexts, images, db connections etc. The fact that AWTSwing
> tries to reclaim these automatically for you does not mean that you should
> 100% rely on that, as this leads to hard to find errors. Besides, both
> AWTSwing & .NET WinForms have explicit dispose() calls for resources (.NET
> even has the IDisposable notion all through its API) and you are actually
> encouraged to use dispose() instsead of relying on finalizers.
>
> > Also, all the use of int fields to distinguish between events ... why
> > not use subclassing and instanceof?
>
> ??
>
> > - SWT is java 1.1 compliant, so no collections, no maps, "stupid"
>
> Why do you need maps and collections in UI toolkit API??
> The lack of maps & collections should only bother the UI toolkit
> implementors, not the toolkit users.
>
> > - SWT is designed to be fast, as opposite to swing, so the single thread
> > and the int fields in events are a good way to make java fast.
> > - SWT has the commercial appeal of an answer to all those people that
> > got nauseated looking all swing interfaces, classes, methods,
> > constructors etc... and want to go straight to the point, not caring too
> > much about perfect object design.
>
> > - SWT has been designed not with java, but with c++ in mind. Everything
> > is extremely "c++ish", and if you ever coded with a c++ graphic toolkit
> > you'll see many relations between the two.
>
> Could you be more specific here? I can't say I see many "C++-ish" things
in
> SWT. I do see many "UI Toolkitish" things though. :)
>
> > - No dispose : call dispose in finalize, make a singleton class holding
> > all the references to SWT objects and call dispose() when needed
> > (WeakReferences?) and addShutdownHook to cleanup when closing.
>
> This could only be optional, and as I said - this leads to hard to find
> errors.
>
> > - Better style variables : if button supports LEFT and RIGHT, i expect
> > Button b = new Button(parent, Button.LEFT); (also because if it's true
> > that SWT have compile time checks for stuff like parents, it has only
> > SILENT runtime checks on styles .. look how many mails there are in this
> > newsgroup with answers like "use SWT.RIGHT in the style").
>
> Agreed.
>
> > - Better multithread support : why cannot another thread even READ
> > values??????
>
> Isn't it obvious?
> Most of the getters in SWT do not return the value of Java variable, but
> instead call into the OS native layer.
> Here's an example:
> Control.getSize().
> This innocent call, on Win32 resolves to OS.GetWindowPos() or something,
> which shouldn't be called from a non-UI thread (well, not exactly true for
> Win32, but definitely the truth for GTK+, Fox etc.).
> Do you think it is worth caching all these values inside the Java Control
> class, just to satisfy 0.1% of the users that need to only read from a
> worker thread..?
>
> Regards,
> Ivan
>
>
|
|
|
Goto Forum:
Current Time: Fri Apr 19 02:34:27 GMT 2024
Powered by FUDForum. Page generated in 0.01933 seconds |
] 
Search
Help
Register
Login
Home
