Re: [boost] A GUI Library
On 2012/6/27 16:24, Klaim - Joël Lamotte wrote:
Hi,
On Wed, Jun 27, 2012 at 2:55 PM, jinhao<cnjinhao@hotmail.com> wrote:
Is there any interest in this library?
My current understanding is that both Boost and the Standard C++ commitee are interested in fully C++ library.
However, the subject is complex and no library until now gathered enough consensus to even get to the review stage of the boost process (from memory). You have to be ready for tons of feedback pointing problems.
Now, I just read the websites but I have some questions:
1. can you write somewhere a big comparison between your library and other popular GUI C++ libraries?
Nana library is written though standard C++, this is a big difference between other libraries, as the brief mentioned, C++ idioms should works with a C++ library, and this is why the other popular GUI C++ libraries are not really C++ style at all. Secondly, this library can be work with a thread pool, it reduces the difficulty for threadization.
2. if you want to submit your library to Boost, I think it would need to be compatible (or maybe just use) boost.thread instead of your own solution
I recognize that many ideas of my own solutions come from boost, not only boost.thread, there are boost.function, boost.any and so on, this is why I try to submit this library to boost and erase all my own solutions.
3. the STR macro is a big problem, I think it will be a big source of negative feedback. Now that we have boost.locale, would it be possible to work with it instead?
Somebody told me the problem before, I left the problem and searched a solution, I found many problem can be fixed by boost, and I rethink, can't keep on stealing ideas from boost. This is also why I try to submit this library to boost.
4. I understand how you can build a GUI application in a way that is mostly a list of statements. Does it means that you'd better organize your windows/forms "types" as constructor functions? (ok found this that partially answer my question: http://nanaproject.wordpress.com/2012/01/31/idioms-and-insights-for-a-good-d...) 5. It is said that Nana is cross-platform, but I don't see any demonstration of this (nevermind, I just found this: http://nanaproject.wordpress.com/2012/05/16/tutorial-of-release-0-2-3/ ) What are the target platforms?
Target platforms should be Windows, Linux and Mac OS X, but now, it only works under Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of mine asks for the support of framebuffer, so I leave the Mac OS X now.
6. Should it work in non-graphic contexts like command-line only display? (I'm thinking about GUI working in bash for example) Yes, like ncurses. But now it is not able to work in such environment.
7. Is it thought to be easily extendable? For example, can I write myself a new front-end implementation and plug it in?
The library provide a general method to implement a customer widget, and supports external image-processing algorithm implementation (http://nanaproject.wordpress.com/2012/04/17/an-introduction-to-the-image-pro...)
8. do you have an available example of complex application being built with this library?
Yes, but its language is Chinese, it is a stock software, a screenshot at http://sourceforge.net/projects/stdex The status of this library I give is alpha and the so library is not used widely. Best Regards! Jinhao
jinhao wrote:
Is there any interest in this library? Target platforms should be Windows, Linux and Mac OS X, but now, it only works under Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of mine asks for the support of framebuffer, so I leave the Mac OS X now.
Have you considered OpenGL (ES) as a platform? This has some great strengths i.e. performance and portability, but also some weaknesses. Regards, Phil.
On 2012/6/27 23:23, Phil Endecott wrote:
jinhao wrote:
Is there any interest in this library? Target platforms should be Windows, Linux and Mac OS X, but now, it only works under Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of mine asks for the support of framebuffer, so I leave the Mac OS X now.
Have you considered OpenGL (ES) as a platform?
This has some great strengths i.e. performance and portability, but also some weaknesses.
Yes, the plan is Windows(GDI)->Linux(X11)->Linux(framebuffer)-> Windows(OpenGL)->Linux(OpenGL)->Windows(DX)->Mac OS X. It is just a plan, it's a long long way to go. Regards Jinhao
Jinhao wrote:
On 2012/6/27 23:23, Phil Endecott wrote:
jinhao wrote:
Is there any interest in this library? Target platforms should be Windows, Linux and Mac OS X, but now, it only works under Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of mine asks for the support of framebuffer, so I leave the Mac OS X now.
Have you considered OpenGL (ES) as a platform?
This has some great strengths i.e. performance and portability, but also some weaknesses.
Yes, the plan is Windows(GDI)->Linux(X11)->Linux(framebuffer)-> Windows(OpenGL)->Linux(OpenGL)->Windows(DX)->Mac OS X. It is just a plan, it's a long long way to go.
Do you want to draw everything by yourself? Will it be possible to use system's native mechanisms? Please consider adding iPhone (Qt, wxWidgets supports it) and Android (Qt) implementation. I assume it would work in Windows Mobile/Phone. What is more, there should be some way to get native window handles to use it with some external library e.g. graphics engine like Ogre3d by initialization in an existing window. And in the case of using your GUI library with external graphic engine, OpenGL/DX version may interfere with it. Regards, Adam
On 2012/6/30 22:34, Adam Wulkiewicz wrote:
Jinhao wrote:
On 2012/6/27 23:23, Phil Endecott wrote:
jinhao wrote:
Is there any interest in this library? Target platforms should be Windows, Linux and Mac OS X, but now, it only works under Windows(GDI) and Linux(X11), the next is ready for Linux(framebuffer). A friend of mine asks for the support of framebuffer, so I leave the Mac OS X now.
Have you considered OpenGL (ES) as a platform?
This has some great strengths i.e. performance and portability, but also some weaknesses.
Yes, the plan is Windows(GDI)->Linux(X11)->Linux(framebuffer)-> Windows(OpenGL)->Linux(OpenGL)->Windows(DX)->Mac OS X. It is just a plan, it's a long long way to go.
Do you want to draw everything by yourself? Will it be possible to use system's native mechanisms?
Please consider adding iPhone (Qt, wxWidgets supports it) and Android (Qt) implementation. I assume it would work in Windows Mobile/Phone.
Yes, both are in planning, self-drawing would be firstly implemented, and the interface and capacity of a widget is being designed in this phase. And then the system's native mechanism will be employed for "native feel and look" and if a widget were not supported by the target system, the self-drawing implementation of the widget will be reused.
What is more, there should be some way to get native window handles to use it with some external library e.g. graphics engine like Ogre3d by initialization in an existing window. And in the case of using your GUI library with external graphic engine, OpenGL/DX version may interfere with it.
The frame widget can be used for this case, it returns a handle that type is native_window_type to represent a native window handle as a container, so it makes a possible to let external library/controls work with the library. Regards Jinhao
Hi,
Nana library is written though standard C++, this is a big difference between other libraries, as the brief mentioned, C++ idioms should works with a C++ library, and this is why the other popular GUI C++ libraries are not really C++ style at all.
Yes, that is the biggest weakness of Qt. Yet a GUI Libary needs many things that are not the interface and basic handling of the objects. Since Qt is widely used and very popular, especially for platform independent applications, I would recommend to look there for any solutions before trying to reinvent every wheel around. Even when looking at the interfaces, wherever there is no conflict with Standard C++, I think it is a good idea to make it as similar as possible to the stuff people already know and like, and that is mostly Qt. I can't tell if i would enjoy using nana, because I would have to have written an application with it before I know. I mostly do enjoy working with Qt and KDE, but I'd prefer to have them more standard C++ like. Sometimes that simply sucks.
Secondly, this library can be work with a thread pool, it reduces the difficulty for threadization.
That is a very good Idea. Also I like that you use RAII to manage widget lifetime.
2. if you want to submit your library to Boost, I think it would need to> be compatible (or maybe just use) boost.thread instead of your own solution
I recognize that many ideas of my own solutions come from boost, not only boost.thread, there are boost.function, boost.any and so on, this is why I try to submit this library to boost and erase all my own solutions.
That as well is a very good aproach. Have you tried to get rid of at least one or another of your selfmade solutions and replace it with boost solutions in order to see how it could work?
3. the STR macro is a big problem, I think it will be a big source of
negative feedback. Now that we have boost.locale, would it be possible to work with it instead?
Somebody told me the problem before, I left the problem and searched a solution, I found many problem can be fixed by boost, and I rethink, can't keep on stealing ideas from boost. This is also why I try to submit this library to boost.
Do you plan to make that library available for "old" C++ as well, or just for C++11? In the second case you could eventually resort to user defined literals. Christof -- okunah gmbh Software nach Maß Werner-Haas-Str. 8 www.okunah.de 86153 Augsburg cd@okunah.de Registergericht Augsburg Geschäftsführer Augsburg HRB 21896 Christof Donat UStID: DE 248 815 055
On 2012/6/28 0:20, Christof Donat wrote:
That as well is a very good aproach. Have you tried to get rid of at least one or another of your selfmade solutions and replace it with boost solutions in order to see how it could work?
Yes, I replaced the class functor with boost.function, the library works as it before.
Do you plan to make that library available for "old" C++ as well, or just for C++11? In the second case you could eventually resort to user defined literals.
Now, this library should be available for "old" C++. Additionally, C++11 should be targeted, there will be two versions of the library, one version for C++11, another for "old" C++. As time goes by, someday in the future the library for "old" C++ would be dropped. Regards Jinhao
participants (5)
-
Adam Wulkiewicz -
Christof Donat -
jinhao -
Jinhao
-
Phil Endecott