| General Question: Suitability of SWT (within RCP) for canvas work.. [message #465668] |
Sat, 17 December 2005 01:34  |
Eclipse User |
|
|
|
Originally posted by: mrhatken.mac.com
Hello All,
I have a general question regarding SWT. I have read about how SWT
compares to Swing etc, and the question doesn't related specifically to
that.
What I want to know is the suitability of SWT for complex use of
"canvases" (i.e. drawing and reacting to user-initiated events whilst
working within the canvas).
For example (and just for example), would it be appropriate to use SWT for
GUI controls if one also wants to do something like CAD drawing in a
canvas.
Of course, the canvas would need to be able to respond to events - I
believe the event model for SWT is different to that of Swing etc?
I'm guessing either they have very different suitabilities (SWT vs Swing)
or SWT just uses the same basic drawing and interaction API as Swing does
within a canvas?
Eclipse itself seems to have complex editors (textual and graphical).
What API do they use to interact with the canvas? Is this limited
compared to Swing or the same?
I hope that makes sense. Any pointers or comments would be most
appreciated.
Cheers,
Ashley.
--
Ashley Aitken
Perth, Western Australia
mrhatken at mac dot com
|
|
|
|
|
| Re: General Question: Suitability of SWT (within RCP) for canvas work.. [message #465679 is a reply to message #465668] |
Mon, 19 December 2005 02:44  |
| Eclipse User |
|
|
|
Originally posted by: mrhatken.mac.com
Thank you both for your pointers.
I was aware that you could do drawing with SWT (e.g. the plugins you
mentioned). However, I also believe these will miss out on the hardware
acceleratin etc that Swing Java2D would get.
If the *main* functionality of my app is going to be WYSIWYG word
processing (multiple fonts) and drawing would SWT and the Eclipse RCP
still be the way to go? Again, just using this for an example.
I understand SWT may be the best for native controls etc but I worry about
more "general" interfaces components (e.g. for word processing and
drawing) that I will be implementing.
If it is the core of my application I don't want to compromise (cf Swing
for example).
Thanks again.
Cheers,
Ashley.
|
|
|
|
| Re: General Question: Suitability of SWT (within RCP) for canvas work.. [message #465685 is a reply to message #465683] |
Mon, 19 December 2005 15:02 |
 Alex Blewitt
Messages: 946
Registered: July 2009 |
Senior Member |
|
|
My opinions differ from yours. I run stuff on a Mac, and (in general) Metal-based and other LAF-based applications are horrible when compared with other native-based apps. The ones that do look professional tend to be ones like Azureus which is written in SWT and thus has extensive feel of a Mac application, despite the fact that it's a platform-neutral codebase.
There's good reasons why extending SWT is forbidden; not so much because you *can't*, but because you *shouldn't*. Specifically, there's no love lost if an update to SWT breaks your code; on the other hand, no-one's forcing you to update your SWT unless you want to.
Being able to be flexible (whether you're moving from Java/Swing to Java/SWT or Java/Swing to .Net/C#) is one of the key abilities of a good computer developer. There's different ways of doing many things; you can consult the history of where SWT came from and experiences with other windowing models that resulted in the choices that were made. The fact that you have to specify a parent at run-time is largely down to compatibility (it's an issue on some platforms, such as handhelds) as well as managing resources (disposal of parents/children). Plus, as can be seen from projects like XSWT it's not that dynamic content is an issue; you just need to think in a way that will allow you to go with the flow, rather than against it.
In any case, there's other ways of doing things (as in everything in life). If you want better 2D support (esp. for hardware-accelerated programming) then looking at the OpenGL work might be worthwhile. That's probably better than the Graphics2D stuff that comes with Swing, and it's portable to other (.Net/C#) systems as well.
One man's bug is another man's feature ...
Alex.
http://www.eclipse.org/articles/Article-Writing%20Your%20Own %20Widget/Writing%20Your%20Own%20Widget.htm
|
|
|
| Re: General Question: Suitability of SWT (within RCP) for canvas work.. [message #465688 is a reply to message #465679] |
Mon, 19 December 2005 15:49 |
Jeremy Dowdall
Messages: 48
Registered: July 2009 |
Member |
|
|
SWT is really good at giving your application the little details in a
native way - buttons, scrollbars, etc. When drawing becomes too
difficult and you move on to draw2D and GEF then you have more
flexibility, but any sub-widgets (scrollbars for example) are still native.
The stuff in the middle is still difficult, though they're working on it
(keep in mind that SWT is newer than Swing). Take a look at the
proposed eclipse project "Nebula" (which comes from www.swtplus.com).
Also keep in mind that you can embed Swing components onto a SWT canvas.
perhaps the best solution would be to use SWT (for the little native
details), Swing (for components that don't have a native equivalent
anyway), and RCP (to manage the whole thing).
As for me, I'm finishing up a Calendar component that is mix of SWT and
draw2D / GEF - the controls, such as toolbars, buttons, menus, etc are
all SWT and match the user's theme, whereas the "drawing" portion of the
calendar (where tasks are drawn on the grid of days) is done with draw2D
/ GEF.
Ricky mentioned Nero and Media Player and I think he's absolutely right
- there may be no need to go to the trouble. But there may be - our
application needs to sit comfortably next to other "office" type
applications so we chose SWT.
I know you said "example", but if WYSIWYG word processing is something
you're serious about, perhaps embedding OpenOffice.org would help you out:
http://ubion.ion.ag/plonesoftwarecenter/003officeintegration editor
(google translators will help if you don't speak german)
hardware acceleration - I don't really know, but since SWT uses native
widgets (and draw2D uses SWT) it seems that you'd be getting whatever
support the OS has for this... and for advanced graphics (alphas and
such) on Windows SWT gets into GDI+ and on Linux it's Cairo... anybody
know better?
Ashley Aitken wrote:
>
> Thank you both for your pointers.
>
> I was aware that you could do drawing with SWT (e.g. the plugins you
> mentioned). However, I also believe these will miss out on the hardware
> acceleratin etc that Swing Java2D would get.
> If the *main* functionality of my app is going to be WYSIWYG word
> processing (multiple fonts) and drawing would SWT and the Eclipse RCP
> still be the way to go? Again, just using this for an example.
>
> I understand SWT may be the best for native controls etc but I worry
> about more "general" interfaces components (e.g. for word processing and
> drawing) that I will be implementing.
>
> If it is the core of my application I don't want to compromise (cf Swing
> for example).
>
> Thanks again.
>
> Cheers,
> Ashley.
>
>
>
|
|
|
| Re: General Question: Suitability of SWT (within RCP) for canvas work.. [message #465689 is a reply to message #465685] |
Mon, 19 December 2005 16:00 |
Ricky
Messages: 204
Registered: July 2009 |
Senior Member |
|
|
Its sad that I have to say this but I am sure we both dont see this as a
flamewar. I am sure others would.
> My opinions differ from yours. I run stuff on a Mac, and (in general)
> Metal-based and other LAF-based applications are horrible when compared
> with other native-based apps. The ones that do look professional tend to
> be ones like Azureus which is written in SWT and thus has extensive
> feel of a Mac application, despite the fact that it's a platform-neutral
> codebase.
The mac is the best argument for swing as the default aqua look is
delicous and integrates seamlessly with the rest of the desktop. And you
are absolutly right that metal is ugly as hell. But the cool thing is you
can change it with one line of code.
The more important point for me is that usability is not all about look.
Beeing red or grey is one part, arrangement and interactive flow control
is more important. And you can mess that up as easily in SWT as in Swing.
> There's good reasons why extending SWT is forbidden; not so much because
> you *can't*, but because you *shouldn't*. Specifically, there's no love
> lost if an update to SWT breaks your code; on the other hand, no-one's
> forcing you to update your SWT unless you want to.
All I know is that I wanted a customized Group with my own error
indicators and I could not subclass Group. This would be handy as I could
use my widget via polymorphism everywhere a Group is allowed but instead I
needed composition. Breaking code is an issue but this is also possible if
some methods become deprecated and vanish at some point. Evolution is
always present and according to Darvin the one who does not change will
not make it in the long run.
> Being able to be flexible (whether you're moving from Java/Swing to
> Java/SWT or Java/Swing to .Net/C#) is one of the key abilities of a good
> computer developer.
ACK.
> There's different ways of doing many things; you can consult the history
> of where SWT came from and experiences with other windowing models that
> resulted in the choices that were made. The fact that you have to
> specify a parent at run-time is largely down to compatibility (it's an
> issue on some platforms, such as handhelds) as well as managing
> resources (disposal of parents/children). Plus, as can be seen from
> projects like XSWT it's not that dynamic content is an issue; you just
> need to think in a way that will allow you to go with the flow, rather
> than against it.
This is the point. There are reasons for everything that happens and there
is always a way to get things done
> In any case, there's other ways of doing things (as in everything in
> life). If you want better 2D support (esp. for hardware-accelerated
> programming) then looking at the OpenGL work might be worthwhile. That's
> probably better than the Graphics2D stuff that comes with Swing, and
> it's portable to other (.Net/C#) systems as well.
>
> One man's bug is another man's feature ...
>
> Alex.
>
> http://www.eclipse.org/articles/Article-Writing%20Your%20Own %20Widget/Writing%20Your%20Own%20Widget.htm
|
|
|
|
Powered by
FUDForum. Page generated in 0.03803 seconds
] 
Search
Help
Register
Login
Home
