GUI lib (you can do it Poco!!)

[alex]

I'm not entirely sure about this, but it seems I need to code C++/Poco binding to dbus anyway. If you can provide some pointers, I could construct the project in a way it might be useful for other Poco users and contribute it.

See How to Contribute. Getting Sourceforge SVN write access is as easy as emailing Guenter or me. SVN sandbox is where the new/experimental code starts its life.

[jive]

thanks. I see if I can cook up something useful for you.

[francisr]

For what it's worth, I've been working on my own native implementation of Mozilla XUL (see here). It's designed as a Windows only implementation, but the code is generic enough to make it cross-platform with some refactoring. That said, this project is probably not useful for Poco. But the idea of implementing a GUI based on a declarative language is a good one I think. Maybe something to consider?

[Iskander]

May be very quality Anti Grain Geometry Library? I do think that this is the best choice.

[zerozorro]

The IUP's minimalistic approach + native ui is very tempting.
And the good news is that the GTK version already supports Unicode. Also, the Mac version is in development.

When / if there be a full Win/GTK/Cocoa Unicode combo, it'd probably be the best ui toolkit around.

[axilmar]

Hello all.

A GUI is certainly missing from the otherwise excellent POCO library.

I am willing to contribute to the GUI module, as long as I have the time, of course .

I will carefully read the 'how to contribute' section and get back with a basic design for the GUI library in this thread as soon as I can.

[axilmar]

The attached document contains a PDF with an overview of a possible POCO-based GUI. Please let me know what you think.

[guenter]

Great proposal! The only thing I was missing is a Canvas element for drawing into windows - similar to the way drawing works in Cocoa or WPF.
Maybe we can find a way to merge the slot features into the current event mechanism, so we don't have two different mechanisms that are very similar, which could be a bit confusing for some users.

[chinistan]

There some stuff in chromium source related to UI. but it is based on chromium's base,if the UI code can be reused in this project, that will save much time,please refer to : http://src.chromium.org/viewvc/chrome/trunk/src/ui/ .

[codecandy2k]

I would be interested in contributing to this.

I would disagree that the GUI library should be restricted to native widgets, though. There is a reason that Qt is the defacto standard when it comes to cross-platform GUI development, and the reason a lot of high-end GUI applications use it.

The style system isn't just a toy for viewing applications in Motif style on Windows, there are many practical uses for it. It allows you to create a custom and consistent look-and-feel for an entire application or suite of applications, in as fine-grained a manner as needed, without having to intersperse a bunch of look-and-feel rendering code throughout all of your widgets. Consider an application like Autodesk Maya, and imagine how tedious it would be to create all of those little widgets and custom list/tree controls in a consistent manner across platforms by using native controls.

For example, if the GUI library uses only native controls, and you want to create a list or table control that varies significantly from the native list-view controls, you would essentially need to recreate all of the logic for a list-view control yourself, as well as all of the rendering. If you want to make some similar changes to a tree control, you would have to do the same thing for tree controls. Whereas with Qt's style system, you could just go into the style class and modify the code that draws the scroll bar, or the header elements in a multi-column table, and that same code will work on all platforms, and it will work for all similar controls that use that style.

There are also lots of strange quirks and bugs in different native GUI systems that make advanced cross-platform GUI development with native widgets a monstrosity. Try supporting some advanced behavior with the Windows ListView control sometime and see if your head doesn't explode
---

This is not to say that a library shouldn't use native widgets. Ideally I think you would want something like a basic GUI system that uses native controls for simple applications with simple GUI requirements, and an advanced GUI system that uses a system of custom rendering for most/all common controls. This would allow for applications that have simple GUI requirements to avoid the overhead of an advanced GUI system, but also allow a more productive way to develop advanced GUI systems.