Re: [boost] Java style GUI in C++
John Torjo wrote:
Hi Reece,
Just a few thoughts:
I am currently designing a GUI framework in C++ (initially targeting the Windows platform) that uses a model similar to that which Java uses in
Take a deep breath if you want to make it cross-platform ;) I think that's Windows work x 10 or so. Maybe more ;) ...
I was thinking about having a compatibility layer, e.g.: namespace windows { class window { public: inline handle_type create( const string_type title, ... ); inline void set_size( long, long ); // ... }; } namespace linux{ class window{ ... }; } Then engineer the library on top of that. This would simplify x-platform development... the problem is working out the right abstraction.
it's AWT and Swing libraries. Specifically:
[1] Being able to use constructors to create the windows/components. This means there is no need to explicitly call a Create method like in the MFC framework.
win32gui does that ;)
:) I am having a look at all the links to the various libraries, so it may take a while to process them all. (Thanks for everyone who compiled the links).
[2] The use of layout managers. I like the various layout managers in Java and how easy it is to construct complex GUI interfaces.
I like the idea of layout managers. Still, it seems (to me) in real-life they kind of fail. You'll always want that special case where you need to hide control X and show control Y, etc.
So why not have that ability in the framework? That is the reason I posted this, to get ideas. It should not be that difficult to be able to change the layouts at run-time... once the layout managers have been written, that is.
So far, I've created splitters on dialogs at design time (still beta ;)). If you use them correctly, you can specify a lot ot design time. Also, you can easily hide/show the left/right panes.
cool.
[3] The support for events via "listeners". This will most likely be geared towards key/mouse events and "action" events (e.g. when the user presses on a button).
I'm not a big fan of listeners. You need to do a lot of coding manually to set them, etc. I've implemented them totally different - using event handler classes.
My idea was something along the lines of: class MouseEvent { public: static const int LeftButton = 0; static const int MiddleButton = 1; static const int RightButton = 2; private: int button; unsigned int vkeys; win::api::point pt; public: inline MouseEvent( int, WPARAM, LPARAM ); }; MouseEvent::MouseEvent( int btn, WPARAM wp, LPARAM lp ): button( btn ), vkey( wp ), pt( lp ) { } class MouseListener { public: virtual void mouseMove( const MouseEvent & ); virtual void mouseButtonDown( const MouseEvent & ); virtual void mouseButtonUp( const MouseEvent & ); virtual void mouseButtonDoubleClick( const MouseEvent & ); public: virtual ~MouseButtonListener(); }; With a common listener interface for GUI object actions, e.g. pressing a mouse button, selecting an item in a listbox, editing text, etc.
At the moment, I have a basic working version that allows you to write the following:
int PASCAL WinMain( HINSTANCE, HINSTANCE, LPSTR, int sw ) { swing::JFrame frame( L"Swing JFrame!" ); frame.setPane( new swing::JPanel()); frame.setSize( 500, 500 ); frame.show( sw );
MessageLoop msg; return( msg.Execute()); }
can you break the message loop? That is, specify when a message loop should end (when a certain signal is received).
You can call ::PostQuitMessage( 0 ), but that is Windows specific. At the moment the message loop doesn't do anything fancy (accelerator/dialog box message processing), but it is on the list of things to work on.
This creates two windows: the main frame and a panel that is a child of that frame. The JFrame is created in the constructor, but is not displayed until show is called. Likewise, the JPanel is created inside its constructor and the JFrame.setPane method makes that window a child of the frame.
I would appreciate comments and ideas as to what people would like out of a GUI framework, especially one that will be multi-platform.
I'm all for it, but again, I think it's so much work...
But it will be fun! :D Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger
Reece Dunn wrote:
John Torjo wrote:
Hi Reece,
[3] The support for events via "listeners". This will most likely be geared towards key/mouse events and "action" events (e.g. when the user presses on a button).
I'm not a big fan of listeners. You need to do a lot of coding manually to set them, etc. I've implemented them totally different - using event handler classes.
My idea was something along the lines of:
class MouseEvent { public: static const int LeftButton = 0; static const int MiddleButton = 1; static const int RightButton = 2; private: int button; unsigned int vkeys; win::api::point pt; public: inline MouseEvent( int, WPARAM, LPARAM ); };
MouseEvent::MouseEvent( int btn, WPARAM wp, LPARAM lp ): button( btn ), vkey( wp ), pt( lp ) { }
class MouseListener { public: virtual void mouseMove( const MouseEvent & ); virtual void mouseButtonDown( const MouseEvent & ); virtual void mouseButtonUp( const MouseEvent & ); virtual void mouseButtonDoubleClick( const MouseEvent & ); public: virtual ~MouseButtonListener(); };
With a common listener interface for GUI object actions, e.g. pressing a mouse button, selecting an item in a listbox, editing text, etc.
Why not use boost::signals for your event interface. It is much better than hand-coded actions and listeners, since any type of function can handle an event. The technology is already in Boost so why re-invent the wheel.
Then engineer the library on top of that. This would simplify x-platform development... the problem is working out the right abstraction.
Exactly! But is there any ;) ? One interesting point is: in Windows, once you create a window on a thread, you'll only receive messages in that thread. I have no idea how this happens on Mac/Unix.
I like the idea of layout managers. Still, it seems (to me) in real-life they kind of fail. You'll always want that special case where you need to hide control X and show control Y, etc.
So why not have that ability in the framework? That is the reason I posted this, to get ideas. It should not be that difficult to be able to change the layouts at run-time... once the layout managers have been written, that is.
I you create the right layout manager, definitely ;)
[3] The support for events via "listeners". This will most likely be geared towards key/mouse events and "action" events (e.g. when the user presses on a button).
I'm not a big fan of listeners. You need to do a lot of coding manually to set them, etc. I've implemented them totally different - using event handler classes.
My idea was something along the lines of:
class MouseEvent { public: static const int LeftButton = 0; static const int MiddleButton = 1; static const int RightButton = 2; private: int button; unsigned int vkeys; win::api::point pt; public: inline MouseEvent( int, WPARAM, LPARAM ); };
MouseEvent::MouseEvent( int btn, WPARAM wp, LPARAM lp ): button( btn ), vkey( wp ), pt( lp ) { }
class MouseListener { public: virtual void mouseMove( const MouseEvent & ); virtual void mouseButtonDown( const MouseEvent & ); virtual void mouseButtonUp( const MouseEvent & ); virtual void mouseButtonDoubleClick( const MouseEvent & ); public: virtual ~MouseButtonListener(); };
Good luck. I'm not a big fan of this. Mostly, because there are just so many events out there. You'll need to create a certain class for each. And what about custom events and such? What about commands/ notifications (Win32 only)? As a side-note, how are these implemented on Unix/MAC? Is there similarity between them and Win32?
I'm all for it, but again, I think it's so much work...
But it will be fun! :D
Great! Just keep us posted! Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
"John Torjo" <john.lists@torjo.com> wrote in message news:412445C5.3060007@torjo.com...
Then engineer the library on top of that. This would simplify x-platform development... the problem is working out the right abstraction.
Exactly! But is there any ;) ? One interesting point is: in Windows, once you create a window on a thread, you'll only receive messages in that thread.
Unless you use 'AttachThreadInput' (ref MSDN docs). // Johan
Johan Nilsson wrote:
"John Torjo" <john.lists@torjo.com> wrote in message news:412445C5.3060007@torjo.com...
Then engineer the library on top of that. This would simplify x-platform development... the problem is working out the right abstraction.
Exactly! But is there any ;) ? One interesting point is: in Windows, once you create a window on a thread, you'll only receive messages in that thread.
Unless you use 'AttachThreadInput' (ref MSDN docs).
Of course ;) But IMO that complicates things - usually unnecessary. I have yet to see a compeling example (reason) for doing such a thing. Best, John -- John Torjo Freelancer -- john@torjo.com Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/ -- v1.3beta released - check out splitter/simple_viewer, a File Explorer/Viewer all in about 200 lines of code! Professional Logging Solution for FREE -- http://www.torjo.com/code/logging.zip (logging - C++) -- http://www.torjo.com/logview/ (viewing/filtering - Win32) -- http://www.torjo.com/logbreak/ (debugging - Win32)
participants (2)
-
Edward Diener -
Johan Nilsson -
John Torjo -
Reece Dunn