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