qooxdoo / qooxdoo

qooxdoo - Universal JavaScript Framework

Qooxdoo JavaScript Framework

qooxdoo is a universal JavaScript framework that enables you to create applications for a wide range of platforms. With its object-oriented programming model you build rich, interactive applications (RIAs), native-like apps for mobile devices, light-weight traditional web applications or even applications to run outside the browser.

You leverage its integrated tool chain to develop and deploy applications of any scale, while taking advantage of modern web technologies like HTML5 and CSS3, its comprehensive feature set and a state-of-the-art GUI toolkit. qooxdoo is open source under liberal licenses, led by a dedicated developer team, with a vibrant community.

For more information please see http://qooxdoo.org .

License

qooxdoo may be used under the terms of the MIT License.

Quick start

It is easy to get started with qooxdoo. For detailed information please see our Get Started Guide.

Documentation

• released version: https://qooxdoo.org/documentation/

API Ref

• released version: https://qooxdoo.org/qxl.apiviewer/

Development

If you develop with qooxdoo, you would normally use a stable NPM release, which, since v6.0.0, contains the compiler and the CLI called with with npx qx <command>.

In contrast, if you want to be hacking qooxdoo itself, please refer to our documentation.

Contributing

There are many ways you can contribute to qooxdoo, ranging from providing feedback, making translations, providing a custom library to full-blown patches to the code. Please check our web site for details. Mind that for every patch to the repository we require an open bug in our issue tracker, and that commits to the repository will fall under qooxdoo's license terms.

Qooxdoo source code is hosted on github/qooxdoo and we use the standard Issue Tracker and Pull Requests feature.

Community

Online chat is available via Gitter at https://gitter.im/qooxdoo/qooxdoo (or using one of the Gitter desktop or mobile clients) - the core team hang out there, as do other developers who use Qooxdoo.

Learn more

• Documentation

  • http://qooxdoo.org/documentation (latest stable)
  • http://qooxdoo.org/qooxdoo (current master)

• Online Demos http://qooxdoo.org/demos

• API Documentation http://qooxdoo.org/api

qooxdoo's Issues

Add a Splashscreen widget (BZ#9)

Sebastian Werner (@swernerx) wrote:

qooxdoo should support Slashscreens to indicate application loading. There should be an easy method to customize the loading screen of qooxdoo, if added sometimes.

Support for Internationalisation (BZ#15)

Sebastian Werner (@swernerx) wrote:

• Add ''Bundle'' support
• Dynamic runtime switching support
• Add handling to objects which interact with internationalized string information.

Support image clipping/concatenation (BZ#31)

Sebastian Werner (@swernerx) wrote:

Support for multiple images in one image source (clipping) (see ActiveWidgets)

This would allow faster switching for hover, active etc. effects on typical image based widgets.

assigned to Thomas Herchenroeder (@thron7)

Optimize caching of Border- and FontObject (BZ#38)

Sebastian Werner (@swernerx) wrote:

BorderObject and FontObject caching is implemented inside the Cache methods which is the better way. But this makes direct creation of BorderObject or FontObject inefficient as then each identical border or font creates its own object.

assigned to Sebastian Werner (@swernerx)

Add instance pooling feature to core (BZ#40)

Sebastian Werner (@swernerx) wrote:

This could be used for reuseable instances. Maybe this is possible for things like XMLHttpTransport, etc.

assigned to Martin Wittemann (@wittemann)

Improve debug console (BZ#46)

Sebastian Werner (@swernerx) wrote:

• Add dynamically generated debug console (which does not need a "div" inside the document)
• Make debug console work in Opera again

Support for more named/themed colors should be added (BZ#41)

Sebastian Werner (@swernerx) wrote:

qooxdoo comes already with themed colors like "buttontext" or "threedface". It would be nice to add more of these, or to remove unused ones to add support for coloring tabs and other currently missing parts.

Add support for font-themes (BZ#44)

Sebastian Werner (@swernerx) wrote:

Font themes would be a nice addon, instead of the need to define them inside the appearance. This maybe require more work in other font-handling areas like binding, etc.

Add support for tooltiptext (BZ#26)

Sebastian Werner (@swernerx) wrote:

Add a new property tooltiptext (could be HTML or text) which will be used, if configured, for a shared tooltip between all widgets. This would reduce the amount of tooltips needed to create.

Maybe this is also possible for icons inside tooltips? Or other complex things.

assigned to Fabian Jakobs (@fjakobs)

Improve data and parameter handling for transport API (BZ#17)

Sebastian Werner (@swernerx) wrote:

Parameters are currently always added to the query string and will be used for a GET-like request, even if the user want POST requests.

IframeTransport should create hidden fields instead of using the query string to transfer parameters.

Transport API should also support file uploads.

There is no Object Registry (BZ#51)

Sebastian Werner (@swernerx) wrote:

qooxdoo should provide an easy to use object registry system to manage application instances other than in the global namespace.

Make contextmenu usage easier (BZ#27)

Sebastian Werner (@swernerx) wrote:

Optimize integration and usage of contextmenus would be great. There is already a contextmenu property but it isn't used currently.

Checkbox and Radiobutton should be image based (BZ#32)

Sebastian Werner (@swernerx) wrote:

To allow further theming through widget themes, RadioButton and CheckBox should use image instead of form elements for visual representation of the input field.

Speed-up toggling (tree, tabView) without re-layouting of children (BZ#22)

Sebastian Werner (@swernerx) wrote:

The performance of re-open a tree folder isn't optimal and should be improved.

assigned to Sebastian Werner (@swernerx)

Reimplement color preset popup (BZ#13)

Sebastian Werner (@swernerx) wrote:

This was seen in older versions of qooxdoo (0.1.x) Generally this should be reimplemented in a more common way, so it's also useful for general needs. This means this should just be a simple popup with some colors, and a button to open a "real" color selector.

Improve keyboard support (BZ#50)

Sebastian Werner (@swernerx) wrote:

like defined here:
http://ecmanaut.blogspot.com/2006/02/javascript-libraries-handling-keyboard.html

Add a Hidden-Field widget (BZ#10)

Sebastian Werner (@swernerx) wrote:

qooxdoo should also support hidden fields i.e. <input type="hidden"/> to allow to use qooxdoo to fill an underlaying form with data fields.

SelectionManager should support automatic function binding (BZ#29)

Sebastian Werner (@swernerx) wrote:

Generally the most widgets which use the selection manager route some self-registered events to this manager. Maybe this could be automated using some "function binding".

Rounded corners support (BZ#28)

Sebastian Werner (@swernerx) wrote:

qooxdoo should support rounded corners. The built-ins are already nice, but not rounded. To enhance visual presentation of tooltips and maybe other stuff, rounded corners would be nice.

assigned to Fabian Jakobs (@fjakobs)

Add a Font-Selector widget (BZ#12)

Sebastian Werner (@swernerx) wrote:

qooxdoo should include a Illustrator-like font-selector. Something more detailed than typically found in toolbars. Including line-heights, word- and letter-spacing.

Reimplement layout engine (BZ#20)

Sebastian Werner (@swernerx) wrote:

The layout engine is sometimes problematic. One case is for widgets which depends on their own computed dimensions. They currently compute the dimensions while rendering and interrupting the layouter this way. This is currently true for QxListView and the new table implementation.

The requirements for the new engine:

• Allow access to computed values at any time.
• Remove spacing and margins from inner width/height of each ''Parent'' to calculate percents. (Mail: Stanislav Ievlev, 08.02.2006, 13:18 Uhr)
• Optimize unit detection and unit handling and storage for dimension and location properties. Try to remove all these boolean flags.
• Try to only have one queue for layouts and jobs
• Omit caching on setting of the value.
• Try to reduce caching stuff (sometimes the cache is probably slower than the (re-)calculation)
• Discuss if it is useful to also cache hasPercentX, hasAutoX, ...
• Reimplement cached properties so that the invaliation will not set the old value to null, but set a isInvalid flag which will define that the next get must re-evaluate the value first.
• Add depth property to widgets. Sort job queue according to depth before flush.
• Add overflow fallback handling to layouts (e.g. show a menu at the end when the toolbar is to small)
• Support overflow 'auto' with 'auto' width or(/and?) height
• Support splitted overflow properties "overflow-x/y" in gecko-1.8 (split overflow properties for this?)

Nice to have:

• Think about additionally supporting dimensions like '100%-10' as in RelativeLayers
• Move all layout depending properties from widgets to the used layout implementation like in Qt or SWT.

assigned to Sebastian Werner (@swernerx)

Add a Progressbar widget (BZ#8)

Sebastian Werner (@swernerx) wrote:

To allow users to get informations of the progress of some action, qooxdoo should support progressbars.

assigned to Adrian Olaru (adrian.olaru)

Support image features for background images, too. (BZ#34)

Sebastian Werner (@swernerx) wrote:

Some features like image bindings to themes etc. are not available for background images. This should be enhanced.

Support Safari, Konqueror and Opera completely (BZ#14)

Sebastian Werner (@swernerx) wrote:

qooxdoo should support the other 3-percent browsers like Safari and Opera, too.

Add a Slider widget (BZ#7)

Sebastian Werner (@swernerx) wrote:

qooxdoo should support a slider widget to allow users to easily select numeric values.

assigned to Sebastian Werner (@swernerx)

Add more themes (esp. appearance and color themes) (BZ#45)

Sebastian Werner (@swernerx) wrote:

Nice would be a Mac OS theme and some themes which are not that OS-related.

Implement data binding (BZ#19)

Sebastian Werner (@swernerx) wrote:

To implement data binding for widgets to (remote) resources is generally a good idea. We should find a way, like in Bindows for example, to solve this in a common way and not only for one or two widgets.

assigned to Martin Wittemann (@wittemann)

Browser's default tab-support doesn't work (BZ#2)

Steve Brendtro (Steven.L.Brendtro) wrote:

Once the qooxdoo javascript is added to a webpage, the user is unable to tab between HTML form elements. To reproduce this error simply add a form to a webpage that has qooxdoo.js on it, then try to tab between the form input boxes.

The URL on this ticket is another example of this behavior.

This may be functioning as designed, however I would like to know how to shut it off.

assigned to Sebastian Werner (@swernerx)

Encoding/Decoding MD5, blowfish, SHA (BZ#47)

Sebastian Werner (@swernerx) wrote:

Support for different encoders/decoders would be nice. Maybe we could use some parts from other libraries like dojo as well.

Add support for recursive enabling/disabling of widgets (BZ#43)

Sebastian Werner (@swernerx) wrote:

Recursive Enabling/Disabling of Widgets (Related to property rework, property inheritance (maybe we could inform us how to implement inheritance generally)) (user defined vs. appearance defined vs. inheritance defined)

assigned to Sebastian Werner (@swernerx)

Support for forced image refreshes (BZ#35)

Sebastian Werner (@swernerx) wrote:

qooxdoo should comes with a built-in support for requested image refreshes. This could maybe implemented using random query strings which will be automatically added to the url. The question is in which part of qooxdoo this should be implemented.

Rethought global dispose solution (BZ#39)

Sebastian Werner (@swernerx) wrote:

Experiment with Object disposing (array slicing, etc.)

Array slicing to remove data also reduces memory usage of Internet Explorer. When disposing objects and not leaving the page the IE will not collect garbage, so that even disposed objects are not freed from memory. For a long-time running application this would mean an increase of memory over the runtime. This is not directly a memory leak, as the browser will freed memory after leaving the page completely.

assigned to Sebastian Werner (@swernerx)

Window: Support maximize, minimize, and close events (BZ#30)

Sebastian Werner (@swernerx) wrote:

Dedicated events in Window handling ("maximize", etc.). This makes it more logical for the application developer. Even if originally implemented in another way internally.

assigned to Fabian Jakobs (@fjakobs)

Add an Accordion-Widget (BZ#11)

Sebastian Werner (@swernerx) wrote:

For outlook-like bars qooxdoo should also support (animated?) Accordion-Widgets like seen in OpenRico.

Map scrollLeft and scrollTop from iframe node (BZ#24)

Sebastian Werner (@swernerx) wrote:

For easier access and user handling, scrollLeft and scrollTop getters/setter of Iframe should be mapped to the iframe node.

URL-Handling (BZ#48)

Sebastian Werner (@swernerx) wrote:

URL Handling should be better integrated with qooxdoo. This could mean something like a automatic path detection to the remaining qooxdoo modules/resources i.e. images. etc.

=> dojo has already some autodetection like this integrated in bootstrap*.js
=> also take a look at contributions/urlhandling_vegetti

ListView is wrong layouted (BZ#21)

Sebastian Werner (@swernerx) wrote:

ListView is problematic inside complex layout parents like DockLayout or inside a BoxLayout if the height is defined as a flex (1*) value.

assigned to Sebastian Werner (@swernerx)

Accelerator support for Atom (BZ#25)

Sebastian Werner (@swernerx) wrote:

The Atom widget should support accelerator keys.

Fixing Appearance Issues with dynamic changes of theme and state (BZ#42)

Sebastian Werner (@swernerx) wrote:

Appearance (problems in run-time switching, most visible in dimension changes, padding/margin). Related to current property system that does not account for user-supplied values, i.e. does not support priorities.

assigned to Sebastian Werner (@swernerx)

Convert mouse and keyevents to singletons (BZ#36)

Sebastian Werner (@swernerx) wrote:

To improve performance, events like MouseEvent and KeyEvent which could also occour once at time should be converted to singletons to reduce the number of created objects.

assigned to Sebastian Werner (@swernerx)

Implement data provider (BZ#18)

Sebastian Werner (@swernerx) wrote:

qooxdoo should support common data formats i.e. the encoding and decoding of formats like:

• json
• xml
• SOAP
• YAML
• AHAH (http://microformats.org/wiki/rest/ahah)

assigned to Martin Wittemann (@wittemann)

Optimize caching inside ColorObject (BZ#37)

Sebastian Werner (@swernerx) wrote:

ColorObject has a seperate caching algorithm inside the constructor, which is a bit inefficient as it returns from the constructor call (like the old singletons did).

assigned to Sebastian Werner (@swernerx)

Integrate better form handling (BZ#52)

Sebastian Werner (@swernerx) wrote:

Like dojo qooxdoo should integrate a form handling which allows to easily transform existing form elements to AJAX calls.

assigned to Martin Wittemann (@wittemann)

Add a Splitpane widget (BZ#6)

Sebastian Werner (@swernerx) wrote:

qooxdoo should support a splitpane widget which allows user-interactive resizing of layout-parts.

assigned to Volker Pauli (vpauli)

Extract client support stuff to separate class (BZ#23)

Sebastian Werner (@swernerx) wrote:

It would be nice to separate the main logic of the layout system to something like QxClientSupport, which contains informations such a browser supports stretching (left<->right, top<->bottom, min- and max-sizes, box-sizing, ...)

ClientSide storage should be integrated with qooxdoo (BZ#49)

Sebastian Werner (@swernerx) wrote:

It would be nice if qooxdoo has also support for client-side IO. And this would mean more than just cookies. Dojo has some client side storage based on Flash with an API for different "backends". Firefox 2 supports client side storage like defined by the WHATWG.

assigned to Martin Wittemann (@wittemann)

Support focus groups (BZ#33)

Sebastian Werner (@swernerx) wrote:

In Windows XP for example all members of a radio group a focus able as a group and not separated. It would be nice if qooxdoo could support something comparable.

This would reduce the number of focus able widgets. We should find a way how to change this behaviour somewhere in the widget stuff. Maybe not that easy, because these radio-managers are no real widgets.

assigned to Sebastian Werner (@swernerx)

Add a Scrollbar widget (BZ#5)

Sebastian Werner (@swernerx) wrote:

qooxdoo should support a own scrollbar widget which supports qooxdoo methods for styling.

Reimplement properties (BZ#16)

Sebastian Werner (@swernerx) wrote:

• Use creation on demand for setter/getter types
• Using "new Function" to create these functions
• Remove layout centric parts from property implementation
• Real property default values: Call modifier for default values, too
• Dramatic optimization for performance
• Support toggling features for boolean values
• Support multiple values with priority (discuss, to support recursive enabling, appearance etc.)

assigned to Sebastian Werner (@swernerx)

Field validation should be supported by form fields (BZ#53)

Sebastian Werner (@swernerx) wrote:

qooxdoo should support field validation. This could be done with simple regexp presets or even function which checks the value and return an information. This should be integrated in typical form elements like QxTextField.

assigned to Martin Wittemann (@wittemann)