GUI lib (you can do it Poco!!)

[chinistan]

>

Not quite sure about Qt. It indeed looks good on the outside. Code is pretty tidy, too. However, it has non-standard nature in its core. Licensing would definitely be a problem as well. In addition to that, adding another layer of C++ interface o top of a full-blown C++ framework would not make much sense. We should aim for a really thin layer on top of native GUIs that works out-of-the-box on a given platform. There should be a unified front-end, with platform back-ends - much like Data library and connectors are designed. You start with one back-end (probably Win32 first) and add others later.

Alex

Qt will add LGPL from 4.5 release,Qt is attractive,Qt has Qtcore,which is the base of QtGUI,QtCore has function which POCO has,if POCO does have GUI part, then I prefer POCO than Qt,if using both POCO and QtCore,they are competitive,I do want to only choose one, I think people who knows POCO would like it very much,like me.
so lack of GUI is the only pity of POCO.

[jive]

instead of inventing the wheel again, provide us with proper dbus binding. I don't want another widget or desktop framework, I want deeply embeddable and portable low level library, on top of which I can create my own applications.

If someone needs GUI, one can choose either KDE(Qt), Gnome or X11 to connect from through the dbus. There are couple of efforts listed in this post:

http://lists.freedesktop.org/archives/d ... 06982.html

but none which are really viable to build software on. I try to create a separation between GUI(Qt) applications and low level services building upon Poco and it seems I'm currently forced to use the libdbus C-API or hack into dbus-c++. None of those alternatives sounds very cost effective ...

[alex]

instead of inventing the wheel again, provide us with proper dbus binding. ... None of those alternatives sounds very cost effective ...

We are not against having an IPC library. In fact, someone proposed it few months ago and even created a directory in the SVN sandbox for it. Recently, I tinkered a bit with local sockets. That, however, is IPC, not GUI. It would still be nice to have a GUI and I agree we should not re-invent the wheel - that's why I'm in favor of wrapping IUP.

[chinistan]

I agree IUP。

[jive]

well, strictly speaking the dbus is not just an IPC system. The introspection format of the interface description allows dynamic allocation and release of communication interfaces or networked resources. Amid the focus of dbus is to abstract the functions traditionally performed through IPC, but the language and binding independent way the communication is defined is nothing to sneeze at.

I think the efforts are better spent with bindings to a standard solutions like dbus instead of wasting it to yet another widget set, with the burden to support the development environment. I think nobody will agree to hand code the GUI with widgets only anymore. You need tools like Glade or Qt designer to gain support among the sw developers.

If you wish to implement gui like features, I would prefer some ajax like scripting functionality through a rendering engine of the browsers preferably one from http://webkit.org/.

[alex]

I think the efforts are better spent with bindings to a standard solutions like dbus instead of wasting it to yet another widget set, with the burden to support the development environment.

Well, so far the effort was tossing ideas back and forth. The bottom line is - when we find a sponsor or a contributor willing to dedicate it sufficient time, it will be done, one way or the other. So far we haven't.

I think nobody will agree to hand code the GUI with widgets only anymore. You need tools like Glade or Qt designer to gain support among the sw developers.

I agree. And I see no reason why we could not support, e.g., glade or Qt designer layout files.

If you wish to implement gui like features, I would prefer some ajax like scripting functionality through a rendering engine of the browsers preferably one from http://webkit.org/.

We do have AJAX library that does the job - it just has not been officially released yet. As for implementing GUI through webkit, it is an interesting idea and AFAIK Applied Informatics has done some commercial work along those lines, but I don't think it falls into the same category with native GUIs.

The reasons for IUP are summarized here. The only inaccuracy is that Qt has changed licensing in the meantime to LGPL. It would really not be such a big effort to wrap IUP (in fact, there is a C++ wrapper already and we could probably POCO-ify it), we just need someone to step up and do it.

[chinistan]

IUP does not have a wide localization feature, it only includes support for messages in English and Portuguese. And it does not have support for Unicode characters.

this can be a trouble.

[guenter]

IUP also lacks Mac OS X support, which is a major issue for me. While I would like to have a POCO-based cross-platform GUI framework that, um, shows the Qt folks how to really write a GUI library ), the economics of writing a full-blown GUI library make it very unlikely that this will happen anytime soon/at all.
Now that we have the WebWidgets library, we should instead focus our attention to Browser-based user interfaces. For example, I have recently stumbled across Appcelerator Titanium, which looks like an interesting alternative for Adobe AIR (and they are even using POCO).
I even see a trend towards WebKit based user interfaces in the embedded space. While having a WebKit based browser takes another 20 - 30 MB of RAM, the big advantage is that you automatically have a user interface that, in addition to the device's display, can also be used over the network, from any device running a browser. This is a killer argument for many projects and products, and having a Linux-based device with 128 MB or more does not add that much cost anyway over something with less memory.

[alex]

IUP also lacks Mac OS X support, which is a major issue for me.

They have plans for Carbon. And Unicode is definitely a concern. I do agree that, given the current constellation, POCO GUI is not likely to happen soon. But if someone out there has a burning desire to contribute, I would certainly not discourage it.

Now that we have the WebWidgets library, we should instead focus our attention to Browser-based user interfaces. For example, I have recently stumbled across Appcelerator Titanium, which looks like an interesting alternative for Adobe AIR (and they are even using POCO).

It is interesting. Well, you've just got a couple of sites to add to the "Who Uses POCO" page

I even see a trend towards WebKit based user interfaces in the embedded space. While having a WebKit based browser takes another 20 - 30 MB of RAM, the big advantage is that you automatically have a user interface that, in addition to the device's display, can also be used over the network, from any device running a browser. This is a killer argument for many projects and products, and having a Linux-based device with 128 MB or more does not add that much cost anyway over something with less memory.

I'll have to look more closely into the Appcelerator. As for WebWidgets, a couple of things I have with it is that (1) there's no layout designer (using glade files or something of sorts would be fine) and (2) I don't think rendering necessarily has to 100% originate from POCO code (for one thing it requires a lot of work wrapping/mapping all the widgets into C++). I would be fine with rendering pages from layout files and having to code ony handlers on the server side. That said, the server-side Javascript is an excellent idea

[jive]

While having a WebKit based browser takes another 20 - 30 MB of RAM, the big advantage is that you automatically have a user interface that, in addition to the device's display, can also be used over the network, from any device running a browser. This is a killer argument for many projects and products, and having a Linux-based device with 128 MB or more does not add that much cost anyway over something with less memory.

I think you nail it here. Couple of other positive attributes are the possibility to use client side localisation, applets, language(gui framework) independent structure, well XML is a language sort of, but I think you get the point, just to name few. We would like to have a system like this, as the GUI is distributed over multiple access stations which can operate in master or monitor mode. System documentation and user/service manuals are trivial to make available through browser based gui. Qt only however is not an option as we need to be able to port our system easily to platforms not directly supported by the Qt. We now use the Poco as a base for the control software and Qt as the Gui framework and link those two different world through dbus.

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. I'm not sure about the schedule as the temporary solution was to use low level glib bindings, and we haven't yet decided when/if we need to replace it with something more usable and less Gnome related stuff.