A GUI Library

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

A GUI Library

jinhao

Hi, all
   I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods.
The project at http://stdex.sourceforge.net
A git repository at http://nanapro.codeplex.com
A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-library

Is there any interest in this library?

Regards
Jinhao
     

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

Klaim - Joël Lamotte
Hi,

On Wed, Jun 27, 2012 at 2:55 PM, jinhao <[hidden email]> 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?
 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
 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?
 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-design/)
 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?
 6. Should it work in non-graphic contexts like command-line only display?
 (I'm thinking about GUI working in bash for example)
 7. Is it thought to be easily extendable? For example, can I write myself
a new front-end implementation and plug it in?
 8. do you have an available example of complex application being built
with this library?

Joel Lamotte

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

mloskot
In reply to this post by jinhao
On 27 June 2012 06:55, jinhao <[hidden email]> wrote:
> I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods.
> [...]
> Is there any interest in this library?

I believe there is interest. GUI in Boost is frequently discussed:
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostDevelGuiThreads
http://lists.boost.org/Archives/boost/2005/10/index.php

There are a few prototypes in the Sandbox and around:
https://svn.boost.org/svn/boost/sandbox/guigl/
http://www.torjo.com/win32gui/

I'd suggest you to search through the list archives and learn
about Boost.GUI concepts, opinions and expectations.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
--
Mateusz Loskot, http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

Philip Bennefall
In reply to this post by jinhao

----- Original Message -----
From: "jinhao" <[hidden email]>
To: <[hidden email]>
Sent: Wednesday, June 27, 2012 7:55 AM
Subject: [boost] A GUI Library



Hi, all
I am developing a GUI library, it takes aim at easy-to-use and portable
library for modern C++ methods.
The project at http://stdex.sourceforge.net
A git repository at http://nanapro.codeplex.com
A brief at
http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-library

Is there any interest in this library?

Regards
Jinhao

I, for one, find this library very interesting. I have thought that there
should be a GUI library under the Boost banner for a long time. I have only
looked briefly at the library, but from what I see so far it is very
promising. Using templates to define event types and then using function
objects for the handler, is a clever idea.

Kind regards,

Philip Bennefall


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

Roger Martin
In reply to this post by jinhao
On 06/27/2012 01:55 AM, jinhao wrote:
> Hi, all
>     I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods.
> The project at http://stdex.sourceforge.net
> A git repository at http://nanapro.codeplex.com
> A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-library
>
> Is there any interest in this library?
Is it possible to compile/apply the linux port back on windows using
mingw64 and posix threads?  Since you are free of specialized compilers
this might be possible?
For example with http://code.google.com/p/mingw-w64-dgn/ which is gcc4.7
and now works with an updated pthreads-win32.

Thank you for starting this discussion

>
> Regards
> Jinhao
>    
>
> _______________________________________________
> Unsubscribe&  other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

jinhao
In reply to this post by jinhao

On 2012/6/27 16:24, Klaim - Joël Lamotte wrote:

> Hi,
>
> On Wed, Jun 27, 2012 at 2:55 PM, jinhao<[hidden email]>  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-design/)
>   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-processing-interfaces-from-release-of-0-2-2/)

>   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
     

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

Phil Endecott-48
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.




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

jinhao
In reply to this post by Roger Martin
On 2012/6/27 21:19, Roger Martin wrote:
> Is it possible to compile/apply the linux port back on windows using
> mingw64 and posix threads? Since you are free of specialized compilers
> this might be possible?
> For example with http://code.google.com/p/mingw-w64-dgn/ which is gcc4.7
> and now works with an updated pthreads-win32.

I tested it, it gets a few errors. I will fix it.
This library now is works with VC7.1/8/9/10, MinGW 3.4/4.4 and GCC4.5.

Regards
Jinhao


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

Christof Donat
In reply to this post by 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                                    [hidden email]

                                      Registergericht Augsburg
Geschäftsführer                             Augsburg HRB 21896
Christof Donat                           UStID: DE 248 815 055

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

jinhao
In reply to this post by Phil Endecott-48
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



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

jinhao
In reply to this post by Christof Donat
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

Felipe Magno de Almeida
In reply to this post by jinhao
On Wed, Jun 27, 2012 at 2:55 AM, jinhao <[hidden email]> wrote:
>
> Hi, all
>    I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods.
> The project at http://stdex.sourceforge.net
> A git repository at http://nanapro.codeplex.com
> A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-library
>
> Is there any interest in this library?

I'm interested in a GUI library which takes a more value-based
approach. By your preliminary study document, it seems to be this
direction, is that right? I believe that a deep analysis of salient
properties and copyability might permit a library interface that is
much more comfortable for C++, and more in-tune with boost.

> Regards
> Jinhao

[]'s
--
Felipe Magno de Almeida

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

jinhao
In reply to this post by mloskot
On 2012/6/27 16:29, Mateusz Loskot wrote:

> I believe there is interest. GUI in Boost is frequently discussed:
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostDevelGuiThreads
> http://lists.boost.org/Archives/boost/2005/10/index.php
>
> There are a few prototypes in the Sandbox and around:
> https://svn.boost.org/svn/boost/sandbox/guigl/
> http://www.torjo.com/win32gui/
>
> I'd suggest you to search through the list archives and learn
> about Boost.GUI concepts, opinions and expectations.

Basically, I think this library is conforming to the concepts, even
though it is flawed and defective in implementation. Thank you for your
suggestion, I will study these concepts to refine the library.

Regards
Jinhao



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

Adam Wulkiewicz
In reply to this post by 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










_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

jinhao
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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: A GUI Library

Boost - Dev mailing list
In reply to this post by jinhao
If your library is only dependent on boost, not any other library like nana
then it will be better in most of the beginner programmers. IF your library
is pre-compiled then it will catch popularity soon, because "allegro 5" is
popular for two reasons :-

1. It is very powerful and vast.
2. It is very very easy to deploy, than SDL and SFML.

The first choice of the beginner programmers is always SDL but they quickly
move to Allegro because of the availability of pre-built binaries.



--
Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost