RE: [boost] Re: Java style GUI in C++
Miro Jurisic wrote:
I also believe this community is capable of producing such a framework, but I think that it's telling that the title of this thread is "Java style GUI in C++"; a Java style GUI typically implies making user experience sacrifices on every platform, and therefore I believe that a "Java style GUI in C++" is likely to be driven by misguided goals.
What I meant by "Java style GUI" is not in terms of L&F, but in terms of programming the framework. I understand how important having a native L&F is to the particular OS you are using (implemented using OS components for native feel): this is one of the goals I am aiming for. Thus, in Java Swing-style C++, you can do something like: boost::gui::frame * main = new boost::gui::frame( "My GUI App" ); frame -> set_pane( new boost::gui::button( "PUSH" )); frame -> set_size( 500, 400 ); frame -> show(); boost::gui::message_loop msg; return msg.execute(); And this will work, creating a window with a button in it's "client" area. That is, allow the user to: [1] create components/widgets using constructors instead of Create functions (like MFC); [2] allow "native" components (buttons, etc.) and windowless components (for performance); [3] provide a set of "layout managers" that are windowless components allowing you to specify scrolling panes, splitter panes, grid layouts, flow layouts, fixed/stretchy layouts and so on -- I personally find using layout managers easy to produce interfaces rapidly; [4] avoid message maps if possible -- I personally don't like message maps and feel there is a better way to implement event handling. From the discussions here boost::signal seems to be the way to go, but some effort needs to be taken to produce a flexible, portable way of handling messages that can both write generic handlers and OS-specific handlers; That is what I mean by a Java-style C++ GUI framework. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/
--- Reece Dunn <msclrhd@hotmail.com> wrote:
Thus, in Java Swing-style C++, you can do something like:
boost::gui::frame * main = new boost::gui::frame( "My GUI App" ); frame -> set_pane( new boost::gui::button( "PUSH" )); frame -> set_size( 500, 400 ); frame -> show();
boost::gui::message_loop msg; return msg.execute();
How does main get deallocated here? I am very surprised to see "new" and raw pointers in a library designed from scratch. Manual lifetime management is going to lead to a lot of clutter, memory leaks, and is incompatible with exception handling. A system based on smart pointers like boost::shared_ptr and reference-counted container types is essential IMO. Ralf __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail
Thus, in Java Swing-style C++, you can do something like:
boost::gui::frame * main = new boost::gui::frame( "My GUI App" ); frame -> set_pane( new boost::gui::button( "PUSH" )); frame -> set_size( 500, 400 ); frame -> show();
boost::gui::message_loop msg; return msg.execute();
How does main get deallocated here? I am very surprised to see "new" and raw pointers in a library designed from scratch. Manual lifetime management is going to lead to a lot of clutter, memory leaks, and is incompatible with exception handling. A system based on smart pointers like boost::shared_ptr and reference-counted container types is essential IMO.
not necessarily - take the snippet of code above, to become: boost::gui::frame frame( "My GUI App" ); frame . set_pane( new boost::gui::button( "PUSH" )); frame . set_size( 500, 400 ); frame . show(); boost::gui::message_loop msg; return msg.execute(); 'frame' deletes all of its children when it goes out of scope (due to window heirachy property - as mentioned in other emails). Only frame needed now be new'ed. Mathew
Reece Dunn wrote: [...]
What I meant by "Java style GUI" is not in terms of L&F, but in terms of programming the framework. I understand how important having a native L&F is to the particular OS you are using (implemented using OS components for native feel): this is one of the goals I am aiming for.
Thus, in Java Swing-style C++, you can do something like:
boost::gui::frame * main = new boost::gui::frame( "My GUI App" ); frame -> set_pane( new boost::gui::button( "PUSH" )); frame -> set_size( 500, 400 ); frame -> show();
boost::gui::message_loop msg; return msg.execute();
And this will work, creating a window with a button in it's "client" area. That is, allow the user to: [1] create components/widgets using constructors instead of Create functions (like MFC);
[2] allow "native" components (buttons, etc.) and windowless components (for performance);
[3] provide a set of "layout managers" that are windowless components allowing you to specify scrolling panes, splitter panes, grid layouts, flow layouts, fixed/stretchy layouts and so on -- I personally find using layout managers easy to produce interfaces rapidly;
[4] avoid message maps if possible -- I personally don't like message maps and feel there is a better way to implement event handling. From the discussions here boost::signal seems to be the way to go, but some effort needs to be taken to produce a flexible, portable way of handling messages that can both write generic handlers and OS-specific handlers;
All what you say here already exists in C++. For instance, you can have a look at QT. It does not use boost::signal (for portability reasons in the beginning, I suppose, and because boost::signal did not exist at that time), but also works with a mechanism of signals and slots that requires some small preprocessing of files.. -- Loïc
[snip]
All what you say here already exists in C++. For instance, you can have a look at QT.
It does not use boost::signal (for portability reasons in the beginning, I suppose, and because boost::signal did not exist at that time), but also works with a mechanism of signals and slots that requires some small preprocessing of files..
Does anyone here think that requiring a pre-compiler is a reasonable thing to require? Mathew
Mathew Robertson wrote:
[snip]
All what you say here already exists in C++. For instance, you can have a look at QT.
It does not use boost::signal (for portability reasons in the beginning, I suppose, and because boost::signal did not exist at that time), but also works with a mechanism of signals and slots that requires some small preprocessing of files..
Does anyone here think that requiring a pre-compiler is a reasonable thing to require?
It is much neater not needing preprocessing of files, and that not needing anything but a C++ standard compiler which is what boost::signal<> provides. Having worked with implementations which required C++ extensions in order to do design time programming, I can say that I would have preferred that such extensions were not needed, but they were worth it because C++ does not provide the mechanisms to make that sort of environment work as flawlessly as it did in those environments. Needless to say, everything one could do at design time, one was able to do at run-time also and that made those environments particularly enjoyable. If, however, mechanisms exist in standard C++ to do something which some preprocessor or C++ extension provides with the exact same functionality and ease of use, naturally I would always prefer standard C++. But I am not a purist. I still intuit that a complete run-time reflection mechanism will be needed to make design-time RAD programming possible in standard C++. But of course many C++ programmers do not see the need for such an environment, often having used one, so they will not see the need for run-time reflection.
Mathew Robertson wrote:
[snip]
All what you say here already exists in C++. For instance, you can have a look at QT.
It does not use boost::signal (for portability reasons in the beginning, I suppose, and because boost::signal did not exist at that time), but also works with a mechanism of signals and slots that requires some small preprocessing of files..
Does anyone here think that requiring a pre-compiler is a reasonable thing to require?
Not me. It's one of the things that bothers me the most about Qt. Bob
Mathew Robertson wrote:
[snip]
All what you say here already exists in C++. For instance, you can have a look at QT.
It does not use boost::signal (for portability reasons in the beginning, I suppose, and because boost::signal did not exist at that time), but also works with a mechanism of signals and slots that requires some small preprocessing of files..
Does anyone here think that requiring a pre-compiler is a reasonable thing to require?
I do not like it either, even more so that it can be implemented in pure C++. But I am not religious on this subjet. However, my point was not on the way this was implemented, it was that at least one system with some sort of signal/event was implemented in C++. Even if it is not perfect, it can be used to get ideas from it (both for do and for don't) and to see what real users make out of it. -- Loïc
participants (2)
-
Edward Diener -
Loïc Joly -
Mathew Robertson -
Miro Jurisic -
Ralf W. Grosse-Kunstleve -
Reece Dunn -
Robert Bell