SWiK
» tagged pages
» logout
qooxdoo
Return to qooxdoo

qooxdoo news

(or Cancel)

(Editing anonymously: to be credited for your changes, login or register a new account)

other page actions:

Tags Applied to this Topic

1 person has tagged this page:
Tag this Topic | Tagging Details

qooxdoo Wiki Pages

Syndication Feed on http://feeds.feedburner.com/qooxdoo/news/content
Edit This

Saturday, August 16, 2008

The week in qooxdoo (2008-08-15)

We're gearing up for the final release of 0.8!

Releases

Plans are to have a first release candidate of qooxdoo 0.8 available during the week, with the final release to be shipped this August. As we are approaching those next milestones, we really appreciate your feedback. Please do not hesitate to file bug reports.

Framework

Image Handling

Working with images in 0.8 has arrived at a very powerful level. For instance, a new low-level class has been added to create images for decoration purposes that takes care of all the images combination (a.k.a image slices), alpha transparent PNGs, various new repeat modes like scale-x or scale-y, etc. Full support for alpha transparent PNGs in IE6 in decorators and icons is included. Images in qooxdoo can now be scaled to the size given explicitly. This auto-scaling is disabled by default, but can easily be enabled with the boolean property "scale".

Hints are being output during app development when using images which qualify as good candidates for being combined. This is another smart helper to support the developer in creating low-latency applications. What such a combined image could look like? See some combined radio buttons and check boxes (taken from the List demo).

Polishing

A permanent task towards the 0.8 release. A few highlights: A lot of decoration images of the "Modern" theme are now combined for better application performance and reduced latency at load time. Many widget demos have got a lot of love. Code should be more concise, functionality be fixed where needed. API documentation is more complete, particularly by adding a lot of new class descriptions which were missing previously. To mention a few widgets explicitly that improved during the week: SelectBox, ComboBox, GroupBox, Spinner, Splitpane

More improvements

  • Decorators are now fully compatible to both box models and therefore are independent of the doctype.
  • Added support for centering Atoms. For instance this is used by buttons that center the label when more space is available (e.g. typical "OK" buttons).
  • Property inheritance has been modified a bit to convert the "inherit" value automatically to "null". Previously, apply routines and getters may have received a string value "inherit", which caused some problems and made code more complex than needed in some cases.
  • Performance and memory usage tweaks for Widget and qx.html.Element, being core components of any qooxdoo GUI application.
  • Moved widget specific layout managers from qx.ui.layout to more specific namespaces (e.g. menu, splitpane, ...).
  • Refactored and cleaned up static resources of qooxdoo, now only including blank.gif and blank.html, which are theme-independent and used by more than one class.

Unit Testing

All framework test classes have been moved from their old name space under testrunner.test to the framework class hierarchy itself. They dwell now under qx.test.

Applications

Apiviewer and Testrunner have been revamped to include a smaller amount of application data (class documentation and test classes, respectively) in their local builds. This makes development of the apps easier. Application data for the Apiviewer now only encompasses the Apiviewer's own classes and the framework classes they inherit from. The Testrunner only loads a small demo unit test class, which is maintained locally. Formerly, both apps included larger amounts of data pertaining to the framework library. This data is now available under the framework itself (see further down).

Tool chain

Downloads

We reviewed our release deliverables and refactored the kits to include just one: an enhanced SDK.

The build kit which contained pre-build applications and the quickstart kit which essentially contained an all-encompassing qooxdoo framework library were seen as of little practical value. The applications are easily evaluated through their online versions, and the new build system can create custom libraries to anybody's content. A pre-built package of the low-level layer is expected for a future release, though, that will be an alternative to other DOM-oriented libraries like Prototype or jQuery.

The many download variants occasionally stirred confusion as to which kit to choose. The reduction to one makes it trivial to pick the right kit to download.

The new SDK mirrors the new repository structure and will include a pre-build version of the Apiviewer, including all the framework classes, so people have a reference immediately at hand. The other applications have to be built first, as usual. Apiviewer and Testrunner components have been stripped down to contain only limited application data for their local development. They previously used framework data and this data is now re-created running the api and test jobs in the framework directly. The ensuing SDK will be around 20MB download size which still seems feasible for an enhanced framework package.

Skeleton and Application Creation

A script has been added to our tool chain that will create a new application from the Skeleton for you. If you invoke tool/bin/create-application.py with a few parameters, a skeleton will be copied to the desired location with all settings already adapted. You can immediately create source and build versions of it, and expand it into your envisioned application.

To this end, the skeleton will be included as source tree in future SDK packages. It is not intended to be usable in place though, since many files are only templates and need expansion through the create-application script.

We hope this will ease the process of getting up to speed when creating custom applications.

Generator

The generic job target test has been implemented and can be used by Skeleton-based applications (with a source-oriented test-source shortly to follow). Running the test job in an application will create an application-specific Testrunner application in a local test folder, which allows you to run application-specific unit test classes. An example is the application of this job to the qooxdoo framework itself.

Locales processing has been revamped. An independent translate key will re-create your .po files at any time you invoke it. A locales key in the config controls which locales will be processed. New translation files are created on the fly, but old files pretaining to a locale not listed are left intact. The code generating jobs compile-source/compile-dist also evaluate a locales key, and the data is included in the generated code accordingly. The old localize config key has been removed.

Contributions

qooxdoo-contrib is the framework's infrastructure for contributions as well as experimental features. It allows for easy and convenient setup, development, maintenance and release management of contributed sub projects. It is constantly being improved, so you might want to check-out the currently available contributions.

Most of the contributions are not labeled "ready for 0.8", yet. Some of them are rather independent of the mostly GUI-related changes of 0.8, so they could rather easily be adjusted. Others, like additional widgets, will of course need to be migrated. Don't expect many authors and maintainers to start looking into migration before a final 0.8 is available and/or they actually start to migrate their custom applications that involve their contributions.

Given the recent and also the anticipated future improvements (including better integration with the framework and better outside visibility and promotion), qooxdoo-contrib is a key ingredient for an ongoing healthy and flexible growth of the project. If you consider adding a new contribution or improving an existing one, check out the preliminary documentation, and don't hesitate to get in touch if you have any questions or suggestions.

Outlook

Again a very productive week is over. Stay tuned for the upcoming first release candidate of qooxdoo 0.8. -)

posted at 06:07 PM. tags: .

Friday, August 08, 2008

The week in qooxdoo (2008-08-08)

Today (08-08-08) could have been the perfect target date for qooxdoo 0.8, right? ;-)

Releases

While this wasn't intended, we are getting closer to 0.8 final nevertheless. Last week a first beta was made available, and work now concentrates on the next pre-release. As you might have seen in the road map, and given the progress and scope of the current code base, we plan to have a first release candidate available soon. qooxdoo 0.8 final is planned to ship this August.

Repository re-organization

As we have briefly reported a repository re-organization has taken place earlier this week. All that is left to say is that things look fairly smooth again. The trunk seems to be in good shape, and the former backend part has been successfully migrated to the qooxdoo-contrib repository (thanks to Fabian who did all the tedious SVN juggling). It now dwells there in the form of several independent "Rpc*" projects (see next section).

RPC Servers

qooxdoo offers an advanced RPC mechanism for direct calls to server-side methods. It allows you to write true client/server applications without having to worry about the communication details.

The qooxdoo RPC is based on JSON-RPC as the serialization and method call protocol. All parameters and return values are automatically converted between JavaScript and the server-side language. qooxdoo provides such optional server backends for Java, PHP, Perl (and Python currently hosted externally).

Those existing RPC servers have been relocated in accordance with the backend contributors. The are now available in qooxdoo-contrib. Not only did it allow for a more concise qooxdoo frontend file structure, but now also an independent development process and own release management (e.g. for hotfixes) is possible.

Your favorite language is missing? Feel free to write your own qooxdoo RPC server, it is fairly easy. If you follow the rules of the Server Writer Guide, you should end up with a conformant implementation.

Ravelled-out Tool Chain

We have a new script in the working called createProject which simplifies the creation of new qooxdoo applications. You just will have to provide a name and optionally the top level namespace and the script will create the qooxdoo application into a new directory. The application is already configured and ready to build and run.

The private optimizer has got a little bug fix to also compress/rename privates created through a simple assignment.

Ruminative Framework

Shadow

We have added generic support for shadows on top level widgets like windows, menus or tool tips. The shadows can be styled by any decorator. Shadows are now used in both the classic and the modern theme.

Table

After the port of the table we fixed many small issues and a bunch of long open bugs reported against the 0.7 table. We have even backported most of the fixes into the legacy_0_7_x branch.

Theming

  • More work of polishing the Modern theme.
  • Minor changes at the feed reader application. Mainly changed the appearance of the windows to better adapt the look of the Modern theme.
  • Another improvement included icon themes. The current trunk contains a few more icons Tango and Oxygen have in common. Also some icon names were improved to make them more consistent.
  • Work to improve the performance and structure of the decoration themes have been started this week. Currently the trunk still has some issues introduced with the new code. The situation will hopefully improve during the first days of this week.
  • The ''Rounded'' border was removed for the moment. It is currently not recommended to use the VML/CSS3 based renderer because of a few display inconsistancies. There are good alternatives however like the ''Beveled'' or ''Grid'' decorator which are also used heavily by the ''Modern'' theme.
  • Several bugfixes.

Miscellaneous

  • Added support for context menus on widgets. These menus are automatically attached to the contextmenu event and are automatically placed to the mouse cursor.
  • Added support for cancelling the native context menu. By default this is enabled when using qooxdoo in an application like environment through the usage of qx.ui.root.Application.
  • Added ''getSortedSelection'' to all selection managers. This returns the selection sorted by the occourence in the list/tree instead of the sequence the items where sorted.
  • Imporved drag&drop support, now with full API documentation. Added support for getting the related (current drag or drop widget, depending on the context) and original target (the widget which is hovered) during drag&drop events.
  • The ''iconOpened'' property was removed from the Tree. It is now handled as in every other qooxdoo widget using a state together with the matching appearance theme.
  • The Tree has got full sub control support which means that the icons, labels etc. are now easily accessible inside the appearance theme for improved customization options.
  • Renamed alignment utility to PlaceUtil and methods from ''alignToXXX'' to ''placeToXXX'' after discussion with native speakers. Thank you for that type of feedback.
  • Fixed SelectBox and ComboBox to behave correctly during hovering items. The selection was decoupled between the list and the text field to allow a quick selection during mouse over. Thanks to the community for the feedback to this issue. Sometimes it is easy to miss these details.

That's it for this week's round up. Take care!

posted at 11:06 AM. tags: .

Tuesday, August 05, 2008

Repository re-org

Here is late-breaking news for those of you who keep in close touch with the qooxdoo repositories. There have been two major changes today:

  • The backend part has been removed from trunk. Latest development was done in the legacy_0_7_x branch, and future development will be done in the qooxdoo-contrib repository, so there was no need to retain it in trunk. We are currently working feverishly to extract the backend from legacy and import it to contrib, retaining history, so this change is close ahead too.
  • The directories beneath frontend were lifted up one level, obviating the 'frontend' folder. At the same time, the old application folder has been split into application (containing full-fledged, stand-alone applications) and component (containing projects that have a more complementary character).

I'm sure there will still be rough edges. We were working today to get the trunk back to speed. There is more and more authoritative information to come. Stay tuned.

posted at 11:07 AM. tags: .

Friday, August 01, 2008

The week in qooxdoo (2008-08-01)

The cherry on this week's icing is to have released:

qooxdoo 0.8-beta1

As has been planned a first beta release of qooxdoo 0.8 was made available today. Just three (but busy) weeks after alpha2 now most of the widgets and most of the applications have been ported to 0.8. See the release notes of qooxdoo 0.8-beta1 for more details.

Table bug hunting day

Wednesday we declared as official "table bug hunting day". After the port of the 0.7 table to the 0.8 widget system was feature-complete, we wanted to make sure that everything still worked as before. Since the table has a really large code base with at least ten different contributors we asked the community to help us find the remaining bugs. The response we got was really amazing. We got more reports than we could fix in just one day, including some really obscure issues we would have probably missed otherwise. Most of the reported issues are fixed in today's 0.8-beta1 release. The few still open issues are filed in bugzilla and will be fixed before 0.8 final. Big "thanks!" to everyone who has reported table bugs. The virtual "bug hunter of the day" award goes to Dietrich Streifert, who filed not less than 5 bugs with clear descriptions and nice screenshots.

Check out the various demos of the new 0.8 table in the demo browser.

Subscribe

As a reminder on the various options to stay up-to-date with the project, in addition to the regular mailing list: You can subscribe to feeds either directly by your feed reader (which is what most people do nowadays), or alternatively by email (if you prefer a more traditional workflow).

Social Networks

Social networks certainly are a matter of taste. If you are into virtual networking and connecting yourself to people that share your interests, you can now also subscribe to "qooxdoo" groups that are available (at least) at the following services: LinkedIn, facebook, Xing, ShortView

Subversion

SourceForge.net is the world's largest Open Source software development web site. As you all know, qooxdoo's code repositories are hosted there as well. They recently started a large-scale data center migration that affects basically all their services. Hope is all of them benefit significantly from the new hardware/infrastructure as well as software upgrades. After migration of SVN, they noticed a couple of severe performance issues (despite that SourceForge's SVN access could never really be called "fast"). Anyway, they focused in resolving the issues, which included a few (planned and announced) outages. Of course, that did slow down our development activities a bit. Sorry for any qooxdoo SVN troubles you might have encountered yourself recently.

Generator

The generator saw mainly internal consolidation this week. Relative path handling has been improved, and the documentation has been aligned to be consistent with it. "frontend/framework/tool/data/config/example.json" is an extended configuration file that can serve as a sample for config file writers and if you need to dig deeper than what the Skeleton config file offers.

Demobrowser

Some effort has gone into the Demobrowser. We wanted it to offer each demo application styled in both the "Classic" and the "Modern" theme, and let the user switch between them. To that end all demos are generated in theme-dependent variants, and the demobrowser GUI has an additional drop-down to support the switching. Check it out.

Outlook

Next week we will consolidate bugs and todos, preparing for the development of a first release candidate of 0.8. Still a lot of work ahead. The better your support (bug reporting, fixing, cheering), the better progress and result. Thanks in advance, we really appreciate it!

posted at 12:06 PM. tags: .

Friday, August 01, 2008

Beta release of qooxdoo 0.8

This is good news, so why only announce it in the recent weekly status update? Exactly, so check out the release notes of qooxdoo 0.8-beta1, try the online demos and make yourself more familiar with all the cool new stuff of 0.8.

posted at 12:06 PM. tags: .

Friday, July 25, 2008

The week in qooxdoo (2008-07-25)

Time for another weekly status report:

qooxdoo 0.8 development

Menu

Menu implementation is complete. The algorithms were greatly improved to have a very well working menu placement. The timeout infrastructure was improved as well. It now uses only two timers for all menu instances instead of two for each menu. Key handling and mouse handling features are also leaps ahead of the old implementation. The code got a lot leaner and cleaner.

The qx.ui.menu.CheckBox implements the IFormElement interface. The qx.ui.menu.RadioButton implements the IRadioItem interface. This means that both are now compatible to all the other form elements in qooxdoo and can be easily connected to them.

A MenuButton class was added to qx.ui.form to make it easy to add menus to normal standalone form buttons without requiring a toolbar.

SplitButton

A SplitButton was implemented to be used either in toolbars or standalone in simple forms. A SplitButton combines a normal button with a menu button in one visual component. This type of widgets is typically seen for history buttons in browsers, where a down arrow opens a popup menu that lists the previously visited sites. To be consistent, the SplitButton also implements the IFormElement interface.

Generic alignment

Menus, like the popups and tooltips, make use of the new alignment API to align widgets relative to each, to mouse event coordinates or to DOM elements. This generic API also supports a smart fallback handling to find the best available solution if the initial side has not got enough space to show the entire menu. By using this new API we were able to replace all widget-specific code previously implemented for popups, tooltips, select boxes, etc. This reduced the overall code size and complexity significantly. API names may not been totally consistent just yet, we'll iron that out shortly.

The alignment API may also be used in the low-level DOM layer, because the algorithms itself are implemented in a widget- and layout-agnostic qx.util.AlignUtil. It is independent from the high-level GUI toolkit. This means that this API may be used for websites and portals as well to facilitate the placement of widgets/elements relative to each other.

Active widgets

The qooxdoo Widget class now supports a new property keepActive, which prevents other widgets from getting activated (i.e. becoming responsive to key events), when the user clicks on them. This feature was required primarily for menus, but may be useful for other areas as well.

In the low-level layer major improvements for the fallback handling (when no active element was found) lead to more stability in the core framework.

Table

This week porting the Table widget to 0.8 continued after it had been started end of last week. qooxdoo's Table is one of the most comprehensive virtual grids out there. Nevertheless, migrating the widget is coming along nicely. Given the complexity and amount of code, one needs to repeatedly be reluctant to changing code while doing the fundamental migration itself. Progress looks good so far, so stay tuned for a reasonably stabilized Table next week.

Miscellaneous

A small issue was fixed for the last transition in the theme system were the old decorator was not correctly resolved.
The display of key shortcuts was corrected (adopted from Windows), it now uses a plus sign instead of a minus sign, e.g. "Ctrl+C".
The ToolBar class now supports a method addSeparator for convenience.
Some issues of last week's first basic implementation of a text selection API have been resolved.
Port of the widget-level drag and drop implementation just started.

Generator

The dependency to the external wget command, used for downloading contributions from the qooxdoo-contrib repository, has been resolved and the functionality is now available in a pure Python/PSL implementation. Unfortunately, due to the ViewVC service of Sourceforge being offline, the revision check had to be disabled. This means that if you include a contribution in your config, you will be downloading the same contrib over and over again with every new source or build generation. A work-around is to do an initial download with a 'contrib://' specification for the manifest key, and then change the key to point to the contrib in your local download cache, so the build process will use the local copy for further runs. We hope to re-enable the check soon, once SourceForge turns back on ViewVC service reliably.

As a consequence, the cache key has been modified to accommodate a new subkey, downloads, a path to the contribution downloads. The path key, denoting the path to the compile cache, has been renamed to compile accordingly, and some background information was added regarding this key. This is an incompatible change, so if you are working with the trunk version of the tool chain you have to adapt your config files!

Say Goodbye to Makefiles!

Probably the biggest perceivable change in the build environment is the demise of application-level Makefiles (well, most of them ;-) ). After thinning out the functionality provided by proper make targets over the last couple of weeks, now also the frontend is gone. That means, up to recently you could still invoke 'make source' in an application, and the call was immediately routed to a generator invocation. The following just hit the trunk as a replacement (we will further investigate if that is to be a long-term solution). Anyway, as of now you invoke a local 'generate.py' command instead, which is available in each application and the framework. It uses the same arguments as the generator (e.g. a 'generate.py source' will generate the source version of the application). This applies to most applications in the trunk (exception is still the buildtool) including the Skeleton, so if you are used to fetching fresh skeletons from the trunk for your own development, this applies to you as well.

While some might find the current switch in trunk from 'make' to 'generate.py' tedious (well, which change isn't?!), it also offers some immediate benefits, like you can easily add the '-v' command line switch to your generator invocations to get debugging output. The story behind all of that is much more exciting: we are eventually getting rid of the 'make' build system all together, only requiring a standard Python installation. This is trivial on most OS, including Windows, were you eventually won't even need a Cygwin installation any longer. We have a couple of ideas in the pipeline about how to make the interface to generator's functionality easy and comfortable (borrowing ideas from buildtool). As you noticed there's currently still much work being done in consolidating the low-level stuff. If you have any good suggestions in regard of a user-friendly build process, don't hold back!

API Viewer

As one of the first applications qooxdoo's API Viewer has been ported to 0.8. Johnny was up to the challenge, and besides the migration work he had also to become familiar with the code base. Nonetheless, it only took him a couple of days applying the changes described in the preliminary UI migration guide. The first change one notices is the modern appearance which came "for free" without changing a single line of code.
We will use the experience we got form the actual porting work and put together an application migration guide. Please note that the search function in the migrated API Viewer is still deactivated, since the ListView widget is deprecated and has been moved to qooxdoo-contrib. The Table widget will be used to display the search results, once its port has been finished. There are still some tweaks to make in the ported API Viewer, so it will be made available within the next few days. As a preview see the following screenshot (click!):


qooxdoo-contrib

The place for adding, maintaining and collaborating on new features to qooxdoo saw a bit of spring-cleaning. It was made more consistent, but work on it continues, not only anticipating the adjustments for the 0.8 tooling, but also the reorganization of the existing qooxdoo RPC servers (Java, PHP, Perl, Python). They are to become regular contributions and will benefit from their new incarnation inside qooxdoo-contrib. Among other advantages, this allows for an individual release management without being dependent on the framework or one another.

Community

Here comes the user-submitted "Real-life example of the Week":

di-lemmata is a new project targeted at scholars of German literature. It combines linguistic concepts with modern programming techniques in order to enhance and support research in the field of literary studies. di-lemmata's library application has been completely implemented in qooxdoo (0.7.3) and currently covers the lyrical works of 11 German speaking poets. Although the HTML pages of the project (i.e. the lyrical works themselves) are in German, of course, the GUI of the qooxdoo application is also available in English and Russian.

Outlook

Next week will see an ongoing migration of applications to 0.8, e.g. demobrowser. Also porting the remaining widgets will continue (DateChooser, ColorSelector, ...), and finally Table is to expected to stabilize as mentioned above. If progress permits and scope is appropriate, we plan on a first beta release end of next week. Stay tuned. ;-)

posted at 01:48 PM. tags: .

Monday, July 21, 2008

Working with text selection

Last week I started to implement a (still basic) low-level Text Selection API which especially the high-level form widgets like TextField and TextArea can make use of.

As some of you might already know working with the native Selection and Range / TextRange objects is not one of the things a developer dreams of -)

However, looking at the basic implementation one thing is quite amazing. Besides a little tweak for Opera three (Gecko, Safari and Opera) of the four major browsers share the same implementation.
Sure there will be some more differences to encounter when the development of this low-level layer moves on, but the start looks quite promising.

posted at 07:49 AM. tags: .

Friday, July 18, 2008

The week in qooxdoo (2008-07-18)

Greetings, qooxdooers, for another weekly wrap-up of the state of affairs in qooxdoo!

General

qooxdoo 0.8-alpha2 has been released just a week ago, thanks for all of your feedback. In the following days, major parts of the Sourceforge.net service platform (which also hosts qooxdoo) were moved both physically (from California to Illinois), as well as concerning software versions. We don't know about you, but we felt major impacts of this migration, even after its official completion. Among other things the statistics features of Sourceforge will remain dormant until next month, so we don't even have download figures for our latest release -( .

But "after release is before release", and we are already in full gear for qooxdoo 0.8-beta1, planning its scope and dispatching tasks. More details will be available soon at this space.

With keen interest we followed the recent release of Jython 2.5a1, a Python implementation in Java. As our tool chain is increasingly built on Python this is an interesting extension of available runtime environments for this code, and will most likely be warmly welcomed by developers at home in a pure Java environment. Initial tests with our generator done by Fabian were indeed promising, and we are looking forward to full support of our build tools by Jython.

Applications

The initial phase of basing our build chain on the new generator is drawing to an end. Nearly all targets available under the make-based system are now available with the new generator as well, the notable exceptions being 'make test' and 'make buildtool' which will be supplied later. Invocations of the 'make' command are now just a wafer-thin wrapper around the generator invocations which becomes apparent with some of our standard applications like the Feedreader. The Apiviewer is self-hosting again, i.e. you can generate the API documentation of the Apiviewer itself.

The documentation of generator configuration got much love from Thomas, and is now split into a main page, a page with in-depth articles about important concepts, and a reference listing of the configuration keys.

And finally, the Showcase application which showed its age has been removed, at least for the time being until it can be re-surrected with new shine and glory -) .

Framework

A first basic implementation of a low level text selection API has been added. Currently this API allows to get the current selection as string and the current selection length as well as to set a selection on elements, text nodes and of course form elements (input and textarea). This API is available for all four major browsers Gecko, IE, Webkit and Opera.

Without further a-do, here is what else happened in the framework:

  • Most bugs reported for alpha2 were fixed - thanks to all the submitters.
    • A listener was added for draggesture events, to block gecko's native drag and drop when resizing/dragging qooxdoo widgets around.
    • Window resizes now keep the correct cursor.
    • Support was added to minimize/maximize windows.
    • Flickering on initial click on a widget has been removed.
  • Support for line height property in fonts has been added.
  • More Window refactoring:
    • support for modal windows
    • extracted MMovable mixin
    • refactored MResizeable
    • added possibility to block interaction with the window contents; needed for advanced modality support
  • Port of Menu has been started
  • Port of the Table has been started
  • TabView has been polished
  • Work has been done on a modern TabView appearance

Community

This week another qooxdoo real-life example surfaced. Zed Builds & Bugs Management is an application targeted at software development teams and combines the following components:

1. Automated Software Build Management
2. Task, Bug, Feature, Assignment, etc. Management
3. Discussion Forums for team dialogs
4. Wiki for documentation, team group design, document storage, personal pages, etc.
5. General server administration

The power of the application is in it’s pure web (qooxdoo!) interface, and the database which is shared among all facets of the application. Meaning your Wiki pages can query the task database, and your automated builds can update tasks as well.

If you created a qooxdoo application (or any software that leverages qooxdoo), please let people know about it. It is an excellent way to give back to this open source project. Just go to the real-life examples and add a section for your app, maybe including a screenshot, and add a link to an online demo if available. Thanks!

posted at 10:49 AM. tags: .

Wednesday, July 16, 2008

Essence vs. Ceremony

At the past Dynamic Languages 08 conference, Neil Ford of ThoughtWorks Inc. gave a keynote presentation entitled "Ceremony & Essence", which took the case of programming languages to reflect on two fundamental approaches to any given problem: The "ceremonious" approach that builds libraries over libraries, creates patterns and protocols to eventually solve the initial problem with a huge flagship of infrastructure; and the other that creates infrastructure that remains light and compact and tries to get out of the way, allowing you to focus on the issue at hand.

Excessive ceremony is a dangerous trap, and not only for software itself but also for all the collateral efforts like documentation, configuration and release management. Here is a story of a personal encounter I had recently.

When I came across a broken link on the Python documentation web site, I would have ignored it since I knew how to get at the information anyway. But since Python is besides Javascript the other intrinsic language for qooxdoo, I thought "be a good citizen, save the world and report this broken link". After some looking around I was directed to a feedback page that offered a couple of choices. One of them was that if I had spotted a concrete problem with the web site I should be so kind and open a bug for it in Python's issue tracking system.

Now filing bugs is not the most pleasurable activity, especially if you need an account in the first place. But eventually I had filed my first Python documentation bug in two lines of text, which was really a no-brainer saying this is the page, this is the broken link on it, and here is it where it should actually point to. I felt like a good boy.

You might be surprise to hear about the feedback I got a few days later. The link had been fixed in the development system. Hmm. The (offline) development system was fixed but the (online) production system not?! I asked back and learned that the documentation was treated like released software. The current presence has been released (2 years ago) and will not be fixed but superseded by its successor which is expected to come out in a couple of months. So you accept your users running into a dead end for more than 2 years?! And the policies and procedures do not allow this trivial issue to be fixed?! - Thank you, ceremony!

posted at 03:47 AM. tags: .

Friday, July 11, 2008

The week in qooxdoo (2008-07-11)

Keeping up with our tradition of Friday's weekly reports, here is another, albeit very brief one.

This week was really a finish towards the 0.8-alpha2 release which we pushed out of the door this morning. Hope you're all hanging out with it -) . Most of the activities went straight to the release notes, so please check there for latest changes (although the release notes cover everything that happened since alpha1, so you might have to wade a bit through the details).

One other thing worth mentioning was a lively thread on the mailing list, about code assist files for IDEs (Eclipse, Aptana, ....) entitled "jseclipse". Discussion gravitated around generating code assist files from API documentation output from the generator. People interested in that should also look at the - unfortunatley somewhat outdated - wiki page about qooxdoo and Aptana. There were some interesting ideas floating around, so maybe we can build up on that. If there is code starting to accumulate around this topic we could set up a qooxdoo-contrib project.

That's it for this week - we're going to post-release-climactic chill -) . Be in touch next time.

posted at 10:46 AM. tags: .

Friday, July 11, 2008

Second alpha release of qooxdoo 0.8

Today another pre-release qooxdoo 0.8-alpha2 was made available. This milestone completes and stabilizes many of the exciting feature improvements and additions of 0.8. To get an idea of the sophisticated GUI toolkit, you may want to browse through the online demos.

Being an alpha release don't expect it to be complete in terms of features or API just yet. But if you read the comprehensive release notes, you'll see how this second release is an amazing improvement over alpha1. Even if it is not meant for production use, you should start to make yourself more familiar with the new stuff of the upcoming version 0.8.

Download this alpha release as a regular SDK or in form of other packages. Take the time to play with it and maybe try to prototype some new apps. It would be great to get your feedback. If you find any issues, please don't hesitate to post bug reports.

posted at 03:46 AM. tags: .

Tuesday, July 08, 2008

Java Forum Stuttgart 2008

Last week we attended the Java Forum in Stuttgart/Germany, which is organized by the local Java User Group Stuttgart (JUGS). Even for us rather JavaScript-oriented guys this was really a good conference. With more than 1000 attendees it was larger than expected. Just the conference track itself with 42 presentations was worth the car ride on the painfully congested A8 highway to Stuttgart. Initially we just expected to attend some of the presentations, but as 1&1 also had a booth at the exhibition floor, we were asked to support our colleagues during session breaks. At least we had made sure they brought some of the qooxdoo give-aways (flyer, ball pens, highlighters and, of course, the little candy boxes).

Once we were putting the give-aways onto the table people started asking what this qooxdoo thingy is all about. Some of them had already heard of the project and many of the Java crowd associated it right away with Eclipse RAP . Luckily Andreas brought his laptop with him, so we were able to do live demonstrations. The feedback was very positive. Most of the visitors were professional software developers and almost everyone had to deal with some kind of web application anyway. Many feel the pressure from their customers, who no longer want to deal with those old-fashioned,  form-based web applications. There certainly is a huge demand for rich internet applications (RIA), even among rather conservative, business-oriented customers.

One talk we simply could not miss was the talk by Stefan Röck and Frank Appel about their project experience with Eclipse RAP. Frank Appel is the technical lead of the RAP team at Innoopract and Stefan is a software developer at CAS Software AG, who works on a brand new RAP-based CRM application. They gave a live demo of teamCRM and explained how they were able to build it using Eclipse RAP. teamCRM is probably the most advanced RAP application to date and people were really impressed.

We enjoyed the conference. Thanks to the organizers and all the people that we had really interesting discussions with. Wanna join 1&1? Anyway, we'll definitely come back next year.

posted at 09:48 AM. tags: .

Monday, July 07, 2008

Let there be color in the browser

I always wanted to play with the browser's canvas element but never really found the right toy project. Then I read Ariya Hidayat's blog post "Let there be color". He has implemented the HSL color pie using Qt's 2D drawing canvas. How hard would it be to put something like this into the browser? I decided to try the port of his code to JavaScript and render the pie using only canvas. If this worked out maybe I could embed it into nice little qooxdoo windows.

HSV Pie

Once I figured out how to realize "putPixel" and "getPixel" functions in canvas the port was merely a copy and paste with some minor changes. Right now I use the canvas methods "getImageData" and "putImageData" to obtain and render a pixel buffer. Unfortunately these methods are only available in Firefox. I'm still looking for an alternative for Opera and Safari. The last missing part was the conversion from HSV to RGB but luckily I could drop in a modified version of qooxdoo's hsbToRgb method.

Now the port could start. What really intrigued me was that the main algorithm was nearly the same as the C++ code. Just take this code fragment from the original code:

for (int i = 0; i < radius; i++) {
  qreal hue = 1 - init;
  qreal sat = 1 - qreal(i) / radius;
  for (int d = 0; d < depth; d++) {
    qreal value = 1 - qreal(d) / depth;
    QColor color = QColor::fromHsvF(hue, sat, value);
    img-&gt;setPixel(width / 2 - radius + i + 1, center + d, color.rgb());
  }
}

and compare it to the ported JavaScript:

for (var i = 0; i < radius; i++) {
  var hue = 1 - init;
  var sat = 1 - i / radius;
  for (var d = 0; d < depth; d++) {
    var value = 1 - d / depth;
    var color = hsbToRgb(hue, sat, value);
    setPixel(img, width / 2 - radius + i + 1, center + d, color);
  }
}

Basically only the variable declaration is different. The same is true for almost all of the relevant code. My first version was an all in one HTML file with the JavaScript code embedded. I used no framework, just plain JavaScript.

Of course I wanted to use some qooxdoo, so the next iteration was to put this into a qooxdoo application. Up to now qooxdoo had no support for embedding canvas elements into a qooxdoo widget. I used much of the new 0.8 widget infrastructure to create a canvas embedding widget. With this widget I could take the code from my first version and embed it into a qooxdoo window. You can see this application life or download the sources. This code is based on the latest qooxdoo 0.8 trunk.

Have fun!

posted at 01:45 PM. tags: .

Friday, July 04, 2008

The week in qooxdoo (2008-07-04)

German Java Forum 2008

Andreas and Fabian joined the Java Forum 2008 (german web site) on Thursday in Stuttgart, Germany. There will be a dedicated post about this one, but among various interesting presentations there seemed to have been a surprising amount of interest in qooxdoo. Stay tuned...

Generator

The Generator basically saw the addition of some missing targets from the Makefile world, like 'clean', 'pretty' or 'lint'. That means the new Generator is nearing feature completeness as far as the driving of project-level targets/jobs is concerned. Also, the module structure has been improved.

Dynamic switching of locales and themes

A major issue of concern during the last few weeks was the cost and benefit of supporting locale and theme switching at runtime in the next version of our framework. To that end, Fabian started a general poll on the mailing list to find out how important these features were for our users. In his summary of the ensuing discussion, he expressed surprise about the amount of support in favour of locale switching. Fortunately, there was also a solution found that promises both the availability of locale runtime switching but at a reasonable cost on the implementation side.

The envisioned solution will implement locales as being static during runtime as the default, which will result in some memory/performance gains. But it will also offer a dedicated setting to turn dynamic switching on for an application, and then the runtime costs will be about the same as they are in the current version. So this feature will continue to be available for those who wish to use it. On the implementation side, the relevant point was to bypass the (costly) LocalizedString class and use built-in Javascript strings to handle necessary meta information.

Runtime switching for themes is still an open topic. There were fewer postings speaking in favour of it, but still some interesting technical suggestions how to continue it in a more feasible way. This will be sorted out in the near future.

Framework

Here are a few more ramblings about recent changes in the qooxdoo framework.

  • The 'Modern' theme is making advances, and we expect to have a working version during this week.
  • A major refactoring of the focus system now leads to unique support for complex cascaded widgets like the Spinner or the ComboBox. The outer widgets always receives the focus event etc., and still the caret is visible when jumping from field to field when using the keyboard. Widgets also now have the possibility to differentiate between tab focus and normal focus.
  • All qooxdoo widgets use the new subcontrol support now. This means that features built on this like the new appearance theme handling are now much more widely used. More details on this feature and the changes to the appearance themes needed will follow in the coming weeks.
  • Support for aliases has been added to reduce the size of themes. Aliases also make the new sub control support a lot more usable. It greatly reduces the overhead introduced with the sub control handling in the last week.
  • State inheritance to sub controls is now supported. This means that every child control like e.g. the up-button of the Spinner can be informed about specific state changes, such as "focused". This is especially useful or even required for better looking themes. You can see the new feature live in the improved Spinner and ComboBox widgets.
  • Greatly improved performance of the appearance system through an improved caching algorithm. Instead of dynamically sorting an array and concat'ing it to a unique identifier the new implementation is based on a simple arithmetic loop. There were some other improvements as well. Especially the new alias support, as mentioned above, results into a few performance improvements as well.

Some minor improvements include:

  • Fixed PageUp/PageDown support in all ScrollArea based widgets like the List.
  • More API docs were fixed or extended. Especially in qx.html.* and qx.ui.core.*
  • The TabView widget was improved to make better use of the SlideBar widget.
  • The GroupBox widget was fixed and now correctly handles all legend types e.g. Atom, RadioButton or CheckBox.
  • Added some new methods to the lower level classes in qx.html.*, to give a better API for focus related features of the widget system.
  • Fixed appearance queueing for dynamic widgets like the Atom. Sometimes the states were not correctly displayed after initial rendering.
  • Improved Splitter demo. The code was structured into separate methods.

That's it from this week's qooxdoo - enjoy your time!

posted at 10:45 AM. tags: .

Thursday, July 03, 2008

Object disposal and the ‘destruct’ section

Recently, there was a lively thread on the mailing list concerning object disposal and the 'destruct' section of classes. While the corresponding wiki page gives most of the answers, it might be worthwhile to summarize and highlight a few aspects:

  • Generally, qooxdoo's runtime will take care of most of the issues around object disposal, so you don't have to be too anxious if you get those 'missing destruct declaration' messages from a verbose disposer run.
  • You can look at the dispose behaviour of your app if you set the disposer into a verbose mode and then invoke it deliberately while your app is running. This will usually render your app unusable, but you will get all those messages hinting you at object properties that might need to be looked after. How-To instructions can be found here. But mind that the disposer output are really hints, nothing more.
  • _disposeFields() is always a safe choice to use in the 'destruct' section of your class. And it prevents all DOM leaks which is the most important thing to do.
  • _disposeObjects() is appropriate when you want to dispose an attached qooxdoo object your class is in charge of. Whether this hold true depends on the application where objects might be shared between other class instances, so make sure you are not destroying an object some other class might want to continue to use -) .
  • _disposeObjectDeep() is rather arcane, and you can safely ignore it in most cases. qooxdoo 0.8 will replace this method with two others, _disposeArray() and _disposeMap(), which are more straight-forward and just relieve you from using loops around iterable data structures for the dispose calls.

Hope this sheds some more light on the issue.

posted at 07:45 AM. tags: .

Friday, June 27, 2008

The week in qooxdoo (2008-06-27)

Portal - A Low-level DOM Demo

With Portal a new application has entered the qooxdoo trunk. This small demo shows some cool features of the new low-level layer, which will be a subset of the upcoming qooxdoo 0.8 release. This layer does not use any of the high-level qooxdoo widgets. Instead, it is a lightweight, DOM-oriented solution that provides an alternative to other popular libraries like Prototype or jQuery. Of course, it is fully cross-browser and allows for very sophisticated coding by offering all the well-known OO features of qooxdoo. A comprehensive API documentation - even for such a low-level app - can easily be generated. Be sure to check it out!

Eclipse Ganymed

Probably you have already heard about the release of Eclipse 3.4 (called "Ganymed"), which was made available about two days ago. They stick to an annual release cycle, so the new version includes a lot of fixes and improvements. If you are an Eclipse guy, you probably have the IDE (which is only one but the most prominent part of the entire Eclipse ecosystem) installed and running already. If not, this is a good opportunity to give the Eclipse IDE a try. While it may not be perfect (well, what editor or IDE is?), it is an excellent solution. Best of it, it's open source! Of course, we had to celebrate the new Ganymed release at one of the DemoCamp events.

Generator

A major part of this past week went into carving out the Config and Job classes that are responsible for providing the information from the config files to the rest of the Generator. They handle all the including of configs and expanding of jobs, returning a fully expanded job that has all the information and is ready to be run. The code is now clearer, better organized and reflects much better the "theory" behind it. I really started loving it. -)

On the feature level, these are the news:

  • Name space-less includes
    As mentioned in a previous post, jobs from external configs are added to the local job list (they are "lifted"). Previously, these imported jobs were renamed to include a prefix that acted as some kind of name space, and thus could prevent name clashes. This has been disabled by default, so external jobs will now be added to the list of runnable jobs with their original names. This puts the burden of avoiding name clashes on the importing config, but now you can run e.g. a 'source' job without even defining one. -)
    On the other hand, you can still define optional name spaces for the job names from those imports. To support this, the syntax for the top-level include key has been changed; it is now an array holding a map for each imported external config. The mandatory entry in those maps is a 'path' key that points to the file location. If you wish to import the jobs namespaced, add the optional 'as' key in the respective map. The format for referencing those jobs slightly shifted to use '::' as a name space separator (rather than '/'), so if you used

      "include" : [ { "path" : "../my/other/config.json", "as" : "otherConfig" }  ]

    you could refer to a job from that config e.g. in an 'extend' section like this

    "extend" : [ "otherConfig::<jobname>" ]

    and external jobs will also be listed in this form on the command line with '?' as the jobs argument.

  • 'export' lists
    Configs can now list the jobs they want to get exported when another config includes it. This is just a selection from the entire list of this config's job keys, and helps to limit name space pollution in the importing config. The syntax is a straight-forward top-level entry like this:

    "export" : [ "jobA", "jobB", "jobC" ]
  • Top-level macros
    You can now add a 'let' section on the top-level. Macros defined therein will be added to every job automatically and without explicit reference, so be aware of side effects. If a job already defines a 'let' map, the global map will be merged into the local in the usual way, only adding new keys and their values. This is done before any extend is resolved, so keys from the global let take precedence over all jobs from the extend section. - The rational behind it is that most standard configs can be reduced to just including the 'application.json' default config, and adding some macros. The experimental 'defaults' job that had similar qualities is gone.

The full documentation for all these config settings is available here.

If you look at the current config.json files of our standard applications (Apiviewer, Feedreader, etc.) they are on various levels of making use of configuration features. Some rely on the settings from the central application.json, others make their settings explicit, doing it more "by hand". Expect to see more features moving into these config files while the config file feature set stabilizes.

Widgets

Subcontrol support

Subwidgeting and child widget handling was a major theme this week. Subcontrol support was added to a lot more widgets thanks to Jonathan's and Sebastian's work. This new widget managment is used for lazy creation and automatic disposal of widgets, but also for the new appearance theme features. Every subcontrol is seen as a child in the appearance as well. The previously flat structure flag keys became somewhat structured resembling XPath expressions, e.g. "spinner-up-button" became "spinner/upbutton". Here are some more facts:

  • These widgets now use child controls:
    SplitPane, ComboBox, SelectBox, Spinner, Toolbar, TabView
  • These widgets use remote children handling now:
    ComboBox, SelectBox, Toolbar
  • ComboBox and SelectBox have gotten a nice "Modern" theme.
  • All appearance names have been consolidated (e.g. it is now "textfield" instead of "text-field")

Spinner

The Spinner is completely themable with all internal children by changing the (public) appearance property. All internal widgets get updated automatically. The minimum/maximum handling of the Spinner was improved. The new version does not accept a value anymore which is out of the currently configured range. The old version did some implicit normalization which is not regarded as a good idea anymore.

ScrollArea

Some remaining issues in the ScrollArea were fixed. The scroll-into-view feature is now available on every widget and is automatically scheduled using the queue managment when the widget or the child to scroll is not rendered at the moment. Gecko and Safari lost the current scroll position when a DOM node gets invisible or temporarly removed. This is an issue for us, especially in the new Selectbox and Combobox widgets because they should re-open the popup in the state they were closed. The scroll area now takes care of these issues and recovers the last known state on every open of the popup.

Miscellaneous

The Element event handler was fixed. After some rework of the event system some weeks ago this handler got a few issues. Events like "scroll" or "load" etc. should now work again.

The Selectbox and Combobox widgets have gotten another bunch of love. They are now regarded as nearly feature complete and appear to be quite solid already.

The Splitpane widget has got a lot of fixes to improve the rendering in some edge cases. The issue where the splitter was moved some pixels away from the cursor on the mouse up event was fixed as well. There are no known rendering issues anymore in the splitpane. Please try it yourself.

Global cursor support was re-introduced in the trunk. As this was a performance issue in IE all the time and never worked 100% OK, the