Monday, September 29, 2008
SWT and jogl
Having inspired by the abilities of openGL, I went about exploring its capabilities and links to swt. See some examples at jogl website to believe for yourself. Also, don't forget to google for Snippet209. Looks like, heavy applications can now be designed with ease. The flight simulator that handles 300MB of data is one example.
Friday, September 26, 2008
eSWT for S60
Today, I came across some flavors of SWT that help the mobile application developers. See http://blogs.forum.nokia.com/blog/hartti-suomelas-forum-nokia-blog/2007/10/09/eswt-plug-in-for-s60-3rd-ed-fp2-sdk
The site "http://www.javalobby.org/java/forums/t102370.html" says:
This adds yet another UI toolkit to the already overly fragmented mobile UI toolkit panorama. There are now over a dozen UI toolkits available to mobile users. Most of the toolkits are very basic, and this is where eSWT intends to make a difference. The eSWT toolkit provides advanced features that will enable an easier transition to the mobile space by those familiar with SWT. AGUI is supposed to compete in the advanced mobile UI toolkit war, but its future is now uncertain (the AGUI JSR was approved over a year now. However, adoption by vendors is yet missing). Sun is pushing JavaFX Mobile very strongly and some of the AGUI people moved over to the JavaFX Mobile team. The outcome of the Savaje acquisition is still unclear. Savaje was one of the few vendors that supported AGUI. eSWT is not a JSR, I find it always a bit strange, when corporation that participate on the JCP/JSR process, go outside of the standardization process and roll out their own proprietary/costume solutions. IBM does this, and so does Nokia. It makes one wonder - Why do they bother to participate on the standardization process in first place? Nonetheless, the embedded Eclipse community appears to be doing a very good job catching up with NetBeans, and the eRCP is worthy of a deeper investigation. Competition is always good. It is however unfortunate that one of the competitors is totally standardized and open, while the other is just open.
The site "http://www.javalobby.org/java/forums/t102370.html" says:
This adds yet another UI toolkit to the already overly fragmented mobile UI toolkit panorama. There are now over a dozen UI toolkits available to mobile users. Most of the toolkits are very basic, and this is where eSWT intends to make a difference. The eSWT toolkit provides advanced features that will enable an easier transition to the mobile space by those familiar with SWT. AGUI is supposed to compete in the advanced mobile UI toolkit war, but its future is now uncertain (the AGUI JSR was approved over a year now. However, adoption by vendors is yet missing). Sun is pushing JavaFX Mobile very strongly and some of the AGUI people moved over to the JavaFX Mobile team. The outcome of the Savaje acquisition is still unclear. Savaje was one of the few vendors that supported AGUI. eSWT is not a JSR, I find it always a bit strange, when corporation that participate on the JCP/JSR process, go outside of the standardization process and roll out their own proprietary/costume solutions. IBM does this, and so does Nokia. It makes one wonder - Why do they bother to participate on the standardization process in first place? Nonetheless, the embedded Eclipse community appears to be doing a very good job catching up with NetBeans, and the eRCP is worthy of a deeper investigation. Competition is always good. It is however unfortunate that one of the competitors is totally standardized and open, while the other is just open.
Wednesday, September 24, 2008
The Display Class
Here are some findings from my today's search on Display class:
Display is at the top of the hierarchy with respect to SWT class tree usage. We need to create a display instance and then put a shell on it to start. Display, Shell, and Widgets are basic building blocks of an SWT application. Displays are responsible from managing event loops and controlling communication between the UI thread and other threads. Shell is the window in an application managed by the OS window manager. Every SWT application requires at least one Display and one or more Shell instances.
If an application uses multiple threads, each thread uses its own instance of a Display object. You can get the current active instance of a Display object by using the static Display.getCurent() method.
For readers familiar with the X Windows system, an SWT Display is equivalent to an X Windows Display.
jDocs say about Display as:
Instances of this class are responsible for managing the connection between SWT and the underlying operating system. Their most important function is to implement the SWT event loop in terms of the platform event model. They also provide various methods for accessing information about the operating system, and have overall control over the operating system resources which SWT allocates.
Applications which are built with SWT will almost always require only a single display. In particular, some platforms which SWT supports will not allow more than one active display. In other words, some platforms do not support creating a new display if one already exists that has not been sent the dispose() message.
In SWT, the thread which creates a Display instance is distinguished as the user-interface thread for that display. The user-interface thread for a particular display has the following special attributes:
The event loop for that display must be run from the thread.
Some SWT API methods (notably, most of the public methods in Widget and its subclasses), may only be called from the thread. (To support multi-threaded user-interface applications, class Display provides inter-thread communication methods which allow threads other than the user-interface thread to request that it perform operations on their behalf.)
The thread is not allowed to construct other Displays until that display has been disposed. (Note that, this is in addition to the restriction mentioned above concerning platform support for multiple displays. Thus, the only way to have multiple simultaneously active displays, even on platforms which support it, is to have multiple threads.) Enforcing these attributes allows SWT to be implemented directly on the underlying operating system's event model. This has numerous benefits including smaller footprint, better use of resources, safer memory management, clearer program logic, better performance, and fewer overall operating system threads required. The down side however, is that care must be taken (only) when constructing multi-threaded applications to use the inter-thread communication mechanisms which this class provides when required.
All SWT API methods which may only be called from the user-interface thread are distinguished in their documentation by indicating that they throw the "ERROR_THREAD_INVALID_ACCESS" SWT exception.
You can read the same from http://www.jdocs.com/swt/3.2/org/eclipse/swt/widgets/Display.html.
Display is at the top of the hierarchy with respect to SWT class tree usage. We need to create a display instance and then put a shell on it to start. Display, Shell, and Widgets are basic building blocks of an SWT application. Displays are responsible from managing event loops and controlling communication between the UI thread and other threads. Shell is the window in an application managed by the OS window manager. Every SWT application requires at least one Display and one or more Shell instances.
If an application uses multiple threads, each thread uses its own instance of a Display object. You can get the current active instance of a Display object by using the static Display.getCurent() method.
For readers familiar with the X Windows system, an SWT Display is equivalent to an X Windows Display.
jDocs say about Display as:
Instances of this class are responsible for managing the connection between SWT and the underlying operating system. Their most important function is to implement the SWT event loop in terms of the platform event model. They also provide various methods for accessing information about the operating system, and have overall control over the operating system resources which SWT allocates.
Applications which are built with SWT will almost always require only a single display. In particular, some platforms which SWT supports will not allow more than one active display. In other words, some platforms do not support creating a new display if one already exists that has not been sent the dispose() message.
In SWT, the thread which creates a Display instance is distinguished as the user-interface thread for that display. The user-interface thread for a particular display has the following special attributes:
The event loop for that display must be run from the thread.
Some SWT API methods (notably, most of the public methods in Widget and its subclasses), may only be called from the thread. (To support multi-threaded user-interface applications, class Display provides inter-thread communication methods which allow threads other than the user-interface thread to request that it perform operations on their behalf.)
The thread is not allowed to construct other Displays until that display has been disposed. (Note that, this is in addition to the restriction mentioned above concerning platform support for multiple displays. Thus, the only way to have multiple simultaneously active displays, even on platforms which support it, is to have multiple threads.) Enforcing these attributes allows SWT to be implemented directly on the underlying operating system's event model. This has numerous benefits including smaller footprint, better use of resources, safer memory management, clearer program logic, better performance, and fewer overall operating system threads required. The down side however, is that care must be taken (only) when constructing multi-threaded applications to use the inter-thread communication mechanisms which this class provides when required.
All SWT API methods which may only be called from the user-interface thread are distinguished in their documentation by indicating that they throw the "ERROR_THREAD_INVALID_ACCESS" SWT exception.
You can read the same from http://www.jdocs.com/swt/3.2/org/eclipse/swt/widgets/Display.html.
How to learn SWT
Today, I was looking for some good resources to learn SWT in a structured way. Here are the findings:
The book titled "SWT: The Standard Widget Toolkit" seems to be a great place to start. This is available for free online reading at http://safari.informit.com/0321256638. Once you skim through this book, you should see that the following understanding is essential to proceed to be an expert:
The book titled "SWT: The Standard Widget Toolkit" seems to be a great place to start. This is available for free online reading at http://safari.informit.com/0321256638. Once you skim through this book, you should see that the following understanding is essential to proceed to be an expert:
- Fundamentals - Why we need? What is it? How is it different? What is the scope?
- SWT Concepts - Overall architecture
- SWT Widgets - Nuances to get working. Quick reading and a handy reference book /web access should do.
- SWT Sample Applications - Keep them handy for a speedy start.
Tuesday, September 23, 2008
SWT Extensions
Java developers are probably second to none! I read about SWT extensions today. Please visit http://www.swtui.cn. They have a cool bunch of features including registry handling and file system utilities there.
Monday, September 22, 2008
The Standard Widget Toolkit
There are several UI libraries (Swint, AWT, etc). Let's wonder why we should even talk about SWT. There seems to be two key words that sell SWT:
- Portability
- Efficiency
With several OS remaining popular across different user (developers, designers, end users, etc) communities, portability has always been even Java's concern. But then, we would expect all java libraries to be portable. So, what differentiates these technologies from portability and efficiency perspective? Let's explore. There are multiple opportunities like the following:
- Develop a fully native library for each platform: This must be the fastest option. Also, we may ensure complete utilization of platform capabilities if such a library is possible. AWT is exactly this! Look and feel of widgets match perfectly with the underlying OS.
- Develop a fully java library: Something like a common denominator. We only have those options here that are available in all supported platform. There are additional layers of method calls to native OS. Hence, poor performance. Swing falls here.
- Develop a partly native and partly java library: Use native calls wherever possible and have java implementation elsewhere. This sounds like best of both worlds.
SWT is mostly native and partly java (as mentioned in the third bullet). Eclipse FAQ (http://wiki.eclipse.org/FAQ_What_is_SWT%3F) gives more details.
So, let's compile our thoughts. We need to answer the following questions to be able to make the choice:
- Is emulation of native OS widgets acceptable or do we want a perfect reproduction?
- How significant is Hardware accelaration?
- What platforms need to be supported?
- How important in cross platform similarity in look and feel?
- Ease of development
- Complexity of UI
At the end of the day, I have not seen a better source for this discussion than http://www-128.ibm.com/developerworks/opensource/library/os-swingswt/. See how many "N/A" exist for AWT. AWT is still probably the least preferred of the three. However, each technical alternative has its own merits and demerits.
Into the world of SWT
I dedicate this blog on SWT to my wife Bhargavi for her continuous support and motivation.
This is an attempt to learn and share my learnings.
This is an attempt to learn and share my learnings.
Subscribe to:
Comments (Atom)
