Posts Tagged ‘ria’

Using Layouts In Qooxdoo – Part 2: VBox Layout

Wednesday, February 4th, 2009

This is the second part of a tutorial series about layout managers, container objects and object hierarchies in Qooxdoo. Read the first part here.

qx.ui.layout.VBox is a basic layout manager that places child widgets on top of each other.

VBox Layout

VBox Layout

Let’s see how VBox lays out components on a simple application1. All the necessary code is below:

   1 /*
   2 #asset(vbox/*)
   3 */
   4 qx.Class.define("vbox.Application",
   5 {
   6     extend: qx.application.Standalone,
   7     members: {
   8         main: function(){
   9             this.base(arguments);
  10 
  11             var main_container = new qx.ui.container.Composite();
  12 
  13             var layout_manager = new qx.ui.layout.VBox();
  14             main_container.setLayout(layout_manager);
  15 
  16             main_container.add(new qx.ui.form.Button("Child Widget 1"));
  17             main_container.add(new qx.ui.form.Button("Child Widget 2"));
  18             main_container.add(new qx.ui.form.Button("Child Widget 3"));
  19 
  20             var application_root = this.getRoot();
  21             application_root.add(main_container);
  22         }
  23     }
  24 });
VBox Example 1

VBox Example 1

I told you VBox is basic; child widgets are stacked vertically in order they have added. We haven’t set any preferences (constraints), so it’s all defaults. Buttons get an optimal width depending on the length of their label. The container main_container applies this width to itself, it conforms its children’s dimensions.

Try giving one of the buttons a longer label. Now the modified button is wider, that was expected. But the others are widened as well. That is because they have conformed (flexed) their container’s width. We will see how this works in detail.

Let’s set the container’s size same as the viewport’s:

   1 /*
   2 #asset(vbox/*)
   3 */
   4 qx.Class.define("vbox.Application",
   5 {
   6     extend: qx.application.Standalone,
   7     members: {
   8         main: function(){
   9             this.base(arguments);
  10 
  11             var main_container = new qx.ui.container.Composite();
  12             main_container.setWidth(qx.bom.Viewport.getWidth());
  13             main_container.setHeight(qx.bom.Viewport.getHeight());
  14 
  15 
  16             var layout_manager = new qx.ui.layout.VBox();
  17             main_container.setLayout(layout_manager);
  18 
  19             main_container.add(new qx.ui.form.Button("Child Widget 1"));
  20             main_container.add(new qx.ui.form.Button("Child Widget 2"));
  21             main_container.add(new qx.ui.form.Button("Child Widget 3"));
  22 
  23             var application_root = this.getRoot();
  24             application_root.add(main_container);
  25         }
  26     }
  27 });
VBox Example 2

VBox Example 2

Notice that only width seems to be adjusted, even though we have set both dimensions. Actually, it worked as we intended to; main_container now fills the entire viewport. But by default VBox won’t flex child widgets vertically. We will start overriding this behaviour in a minute.

Try setting alignY property to “center” or “bottom” on the layout manager:

layout_manager.setAlignY("bottom");

So far we have set properties (constraints) on containers (main_container.width & main_container.height) and on layout managers (layout_manager.alignY). In the next example we will set properties on child widgets:

   1 /*
   2 #asset(vbox/*)
   3 */
   4 qx.Class.define("vbox.Application",
   5 {
   6     extend: qx.application.Standalone,
   7     members: {
   8         main: function(){
   9             this.base(arguments);
  10 
  11             var main_container = new qx.ui.container.Composite();
  12             main_container.setWidth(qx.bom.Viewport.getWidth());
  13             main_container.setHeight(qx.bom.Viewport.getHeight());
  14 
  15             var layout_manager = new qx.ui.layout.VBox();
  16             main_container.setLayout(layout_manager);
  17 
  18             main_container.add(new qx.ui.form.Button("Child Widget 1"), {flex: 1});
  19             main_container.add(new qx.ui.form.Button("Child Widget 2"), {flex: 1});
  20             main_container.add(new qx.ui.form.Button("Child Widget 3"), {flex: 1});
  21 
  22             var application_root = this.getRoot();
  23             application_root.add(main_container);
  24         }
  25     }
  26 });
VBox Example 3

VBox Example 3

We have added a second parameter to the add method of layout manager. This JavaScript object literal is used to set widget specific properties on the layout manager.

Flex property determines how the extra space2 is distributed between children. By default it is set to 0, which means that the widget will not grow vertically. Any other (integer) value for flex will cause growing to occupy the extra space. Growing is proportional to flex value. Try different flex values for different widgets and see the changes.

NEXT PART: HBox Layout


1: If you haven’t created a qx application before, it is explained in detail in the tutorial.

2: Remaining space after initial dimensions of children are computed.

Bookmark and Share

Using Layouts In Qooxdoo – Part 1

Friday, January 30th, 2009

This is the first part of a tutorial series about layout managers, container objects and object hierarchies in Qooxdoo (qx for short from here on). Its target audience is mostly qx programmers coming from an (X)HTML/CSS/DOM background who have possibly used JavaScript libraries such as JQuery or prototype before. Qx is different, it is a JavaScript RIA Framework. If you have used a GUI toolkit such as Swing (Java), wxWidgets or GTK+ you should have no difficulty following this tutorial. In fact you will probably find it boring1. On the other hand if you are still trying to find out how you can attach your <div /> in an existing qx layout; you are in the right place.

The answer is “No”, to the question above. You don’t create DOM elements with qx (unless you are doing something really exotic). Actually you don’t need to concern yourself with the DOM at all. GUI is abstracted to a set of intuitive classes that you should be familiar from today’s desktop operating systems. This abstraction brings two big advantages:

  • Developers using qx don’t need to concern themselves with cross-browser issues.
  • Theming is easy and uniform.

Widgets Are The Building Blocks

A qx user interface is constructed using widgets. A widget is a class that encapsulates appereance, data and behaviour. For instance a TextField would render itself as a box and a caret, make the text you enter inside accessible programmatically and allow you to be notified whenever a the text data is changed. Widgets are customizable, subclassable and of course themable.

But a GUI hardly ever consists of a single widget. Instead there is a hierarchy of widgets. A container is a special kind of widget that has child widgets. A container widget ususally doesn’t have any visual parts itself and just render its children in its screen space. How child widgets are positioned within their container is decided by the container’s layout manager. Having a layout manager means the abstraction of layout strategy for maximum flexibility.

So how do containers, child widgets and layout managers work together? First of all qx positions everything with absolute coordinates (Yes; position:absolute) internally. But that doesn’t mean you need to position anything absolutely on the API level. Speaking in terms of JavaScript libraries; you can take advantage of floating/auto-sizing/liquid layouts. Position and size of all widgets are negotiated through this hierarchy. Theoretically everyone has a say. This means that you can set some constraints on parents and then some others on child widgets and they all work together. The resulting layout is then converted to absolute coordinates for rendering. (Examples in the next part)

Recap

  1. Qx GUI’s are hierarchically constructed from widgets.
  2. Each application has a root container.
  3. Each container has a layout manager and one or more child widgets2.
  4. A child of a container can be either:
    1. Another container.
    2. Or a control widget (such as a form widget).

NEXT PART: VBox Layout


1: You might want to see Qooxdoo – API documentation instead.

2: Although it is possible that a container may have no children, it is not sensible.

Bookmark and Share

V For Volatile

Tuesday, September 30th, 2008

Let’s assume we are buying a business software that will meet some business needs for our business. It is a multi user enviroment, so we opt for a product with a Client/Server architecture. What to ask for, other than the obvious requirements for the task?

I would, first of all, ask for ease of deployment. What good is a software if you can’t run it? Ease of deployment for both the clients and the server. But clients here are more important for two reasons; they will be many, and they will be installed on desktop computers in the wild. As opposed to one server, which is (hopefully) maintained by professionals. So I would like my new software to be easily installed, uninstalled and upgraded on any computer connected to my network.

I would also like to be able to access the software through any client connected. It is a bad bad security model to rely on authentication against a client installation. Each and every client should be identical and the authentication should be done against some form of credentials1.

As a user I would also like to know that the client software will not mess with the rest of my system. Software breaking2 other software, or the entire operating system is useless, no matter how much utility it has otherwise.

I guess you have realized by now where I am going with this. The system I have described above is unlikely a big over-burdened application that radiates seriousness from your screen and clings itself into the bowels of your Operating System. I am actually talking about a volatile client and server architecture. Where the client almost doesn’t exist. It exists of course. It resides on the server until you connect with your browser3, then get downloaded and run. This model is called Rich Internet Application, RIA for short.

The key characteristics of RIA are;

  • No install or uninstall4.
  • Automatic remote upgrades.
  • [Sandboxed](http://en.wikipedia.org/wiki/Sandbox(computersecurity))

Rich Internet Applications are powerful and considerably easier to deploy. They do have one drawback; the platform (HTML+CSS+JavaScript) they run on is not designed for applications from the beginning. It is initially designed for documents and then extended to support for applications. The main practical problem is that the JavaScript implementations are not as fast and reliable (on high loads) as native code or other popular interpreted languages. But we have started to see a new breed of browsers specifically built for applications. I am sure JavaScript virtual machines will be improved significantly in the near future.

On the other hand benchmarking and measuring performance by actually using and application typically yields different results. In our example, business applications do not involve heavy operations that require a lot of processing power. Non-linear video editing does, image synthesis does, desktop publishing does, business applications doesn’t. So the RIA would still be my first choice even with the possible performance problems mentioned above.

More on this later.

Bookmark and Share