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 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. [2] The use of layout managers. I like the various layout managers in Java and how easy it is to construct complex GUI interfaces. [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). [4] Support for windowed and windowless components. Windowed components will use the native controls where possible, allowing a natural look and feel. Windowless controls will be lightweight components that do not use a native component (a Window handle on the Windows platform); these will be useful for writing the layout managers. 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()); } 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. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger
In message <BAY24-F2lxwjKgwJWC10003ae20@hotmail.com>, Reece Dunn <msclrhd@hotmail.com> writes
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 it's AWT and Swing libraries. Specifically:
What are the main distinguishing features from wxWidgets? At: www.wxWidgets.org. -- Alec Ross
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 ;) ...
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 ;)
[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 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.
[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.
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).
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... 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)
"Reece Dunn" <msclrhd@hotmail.com> wrote
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 it's AWT and Swing libraries. Specifically:
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 am currently looking into GUI but from the point of view of drawing whats in a window. One major issue with Windows SDK is spending a lot of time figuring out whether device or logical units are required. It seems a natural application for my physical quantities library. So instead of saying: DeviceContext dc; int x,y; dc.move(x,y); One could say: DeviceContext dc; length::mm x,y; dc.move(x,y); Although I am more keen on an object approach as below, more like windows metafile. Another issue is the local coordinate system, so I am trying to look at how to make that more user friendly too: // A container for the drawing Drawing drawing<Rectangle>; // set drawing to "graphics" direction drawing.set_direction(x_increasing_right(), y_increasing_up()); drawing.set_scale(1,1); drawing.set_origin(point(length::mm(0),length::mm(0))); printer printer = GetPrinter(); // synchronise printers way of looking at things with drawing printer.set_direction(drawing.direction); printer.set_scale(drawing.scale); printer.set_origin(drawing.origin); //ok should get sane values //get paper size for printing Rectangle<length::mm> paper_size = printer.get_paper_size(); drawing.rectangle = paper_size; GraphicLayer border_layer; // a layer representing border for drawing // sync border_layer direction with drawing border.set_direction(drawing.direction); border.set_scale(drawing.scale); border.set_origin(drawing.origin); length::mm left_border(10); length::mm right_border = left_border; typedef length height; // easy reading height::mm top_border(10); height::mm bottom_border(15); //points representing the border point<length::mm> first(left_border, bottom_border); point<length::mm> second(paper_size.width - right_border, bottom_border); point<length::mm> third(paper_size.width - right_border, paper_size.height - top_border); point<length::mm> fourth(left_border, paper_size.height - top_border); typedef length width; Pen pen(width::mm(0.2),color(BLACK),style(continuous)); border_layer << line(first,second,pen) << line(second,third,pen) << line(third,fourth,pen) << line(fourth,first,pen); // add the layer to the drawing drawing << border_layer; TextLayer text_layer; // sync text layer with drawing solely for purposes // of getting correct origin offset in drawing text_layer.set_direction(drawing.direction); text_layer.set_scale(drawing.scale); Font font ("Times New Roman",height::mm(7),width::mm(0)); text_layer.set_origin(left_border,-(paper_size.height - top_border- font.height))); // now set direction to text mode text_layer.set_direction(x_increasing_right(), y_increasing_down()); //... play text into text layer point(left_border,font.height) start_text; Text text(start_text,font,"Hello World",color(BLACK),increasing_right(),increasing_up(),of_angle::deg(0) ); drawing << text; text.x += text.length ; /*...*/ drawing >> printer; Or something like that, then of course theres time and velocity for moving things about in real time :-) regards Andy Little
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 it's AWT and Swing libraries. Specifically:
[snip]
I would appreciate comments and ideas as to what people would like out of a GUI framework, especially one that will be multi-platform.
Boost-style C++ GUI library utilizing boost::signals and with a nice way of handling message loops: http://cxxgui.sf.net/ Regards David Turner
"David Turner" <dkturner@telkomsa.net> wrote in message news:006501c48612$748df450$6300000a@onyx... | Boost-style C++ GUI library utilizing boost::signals and with a nice way | of handling message loops: Looks nice an simple :-) One thing I don't like about the interface is the use of char*. Why not use std::string? br Thorsten
Hi Reece,
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 it's AWT and Swing libraries. Specifically:
[snip] It seems that what you're at is a full-blown standalone C++ GUI library. Maybe, it's good goal, but there a lot of toolkits already. I think it's not likely that just a new library will find a lot of users. If somebody has Qt or GTK application, he won't rewrite it just because your library is cleaner or better in some other way. But I think it's possible to create something with some chance for success. It's portable GUI library which *integrates* with existing toolkits. So that, you can create a widget using new library and plug that widget into existing application. For example, you want to visualise a graph. You code the algorithm using boost::gui and then the resulting boost::graph::layout library should be usable in all toolkits supported by boost::gui. If that's the case, than using boost::gui becomes very attractive. The specific interface is not important. Just for example: boost::gui::widget w = canvas_view(300, 300); make_qt_widget(w, parent); Thoughts? - Volodya
Hi Please excuse me coming into this discussion halfway. I wasn't on this list until last week when someone told me this discussion was happening and I joined as this is something I am very interested in.
It seems that what you're at is a full-blown standalone C++ GUI library. Maybe, it's good goal, but there a lot of toolkits already. I think it's not likely that just a new library will find a lot of users. If somebody has Qt or GTK application, he won't rewrite it just because your library is cleaner or better in some other way.
My experience, mostly from reading the documentation, is that there are no GOOD cross-platform C++ GUI libraries out there. The likes of WxWindows and GTKMM (the C++ GTK for those who haven't come across if before) suffer, IMO from lack of modern C++ techniques (not even namespaces in WxWindows' case), and unnecessary reinvention of the wheel for things like strings, and neither are exception safe. Which, in my mind, doesn't really make them C++ libraries. Also, they try and do more than be a GUI library, for example by supporting threading and database access. I can't comment on Qt's exception safety, but I'm put off that because it's no longer free to Windows users. I believe it also does some wheel reinvention and database and threading stuff. I didn't like the extra compile stage for the messaging mechanism either. Anyway, so what's my point? My point is that I believe the C++ community is crying out for a good real C++ solution. I for one would very much like to see a C++ GUI library as part of boost. GUI use often does tie people into a particular library. Not many people seem to separate their backend logic from the GUI code, so it would be difficult for a lot of people to _change_. However, what about people like me who often start new projects or who do separate (I believe) correctly. Rant over. Comments? Regards Paul Paul Grenyer email: paul@paulgrenyer.co.uk web: http://www.paulgrenyer.co.uk There's someone in my head, but it's not me.
In article <006201c4892d$65d6dc10$2321100a@myopwv.com>, "Paul Grenyer" <paul@paulgrenyer.co.uk> wrote:
My experience, mostly from reading the documentation, is that there are no GOOD cross-platform C++ GUI libraries out there.
I agree. You point out two major failing of most C++ frameworks: lack of modern C++ use and lack of exception safety. I see the rest of this thread talking a lot about C++ techniques, but there seems to be one major component that everyone is overlooking: producing a good user experience. Perhaps as a Mac developer I am more aware to the importance of a good user experience; one of the major failings of every cross-platform C++ framework on Mac OS is a poor user experience -- usually due to reinventing OS-provided UI wheels, and thus often making the UI subtly inconsistent with the rest of the OS. This kind of subtle (or less subtle) inconsistency is what makes users (entirely justifiably) bitch and moan and shoddy ports, and give bad product reviews. meeroh
My experience, mostly from reading the documentation, is that there are no GOOD cross-platform C++ GUI libraries out there.
I agree. You point out two major failing of most C++ frameworks: lack of modern C++ use and lack of exception safety. I see the rest of this thread talking a lot about C++ techniques, but there seems to be one major component that everyone is overlooking: producing a good user experience.
Perhaps as a Mac developer I am more aware to the importance of a good user experience; one of the major failings of every cross-platform C++ framework on Mac OS is a poor user experience -- usually due to reinventing OS-provided UI wheels, and thus often making the UI subtly inconsistent with the rest of the OS. This kind of subtle (or less subtle) inconsistency is what makes users (entirely justifiably) bitch and moan and shoddy ports, and give bad product reviews.
umm... which part of "cross-platform" and "use native functionality" is more important? If you have some functionality provided by one OS, while another doesn't provide it... what do you do? MacOS is a hard creature to make apps portable to - as its UI is significantly different to most other OS's, that making a cross-platform library which appears to work as a native OSX app is hard, real hard. Take Mozilla/Firefox/OpenOffice - each of these suffers the "not quite OS integrated, compared with native apps", even though these apps are propably some of the highest profile cross-platform applications. Mathew
In article <079f01c48a2e$3e02b4f0$a901000a@mat>, "Mathew Robertson" <mathew.robertson@redsheriff.com> wrote:
I agree. You point out two major failing of most C++ frameworks: lack of modern C++ use and lack of exception safety. I see the rest of this thread talking a lot about C++ techniques, but there seems to be one major component that everyone is overlooking: producing a good user experience.
Perhaps as a Mac developer I am more aware to the importance of a good user experience; one of the major failings of every cross-platform C++ framework on Mac OS is a poor user experience -- usually due to reinventing OS-provided UI wheels, and thus often making the UI subtly inconsistent with the rest of the OS. This kind of subtle (or less subtle) inconsistency is what makes users (entirely justifiably) bitch and moan and shoddy ports, and give bad product reviews.
umm... which part of "cross-platform" and "use native functionality" is more important?
You are falsely presenting them as mutually exclusive choices.
If you have some functionality provided by one OS, while another doesn't provide it... what do you do?
That case is actually almost completely irrelevant to my point. My point has to do with "reinventing OS-provided wheels", which is completely different from providing additional functionality on a particular OS.
MacOS is a hard creature to make apps portable to - as its UI is significantly different to most other OS's, that making a cross-platform library which appears to work as a native OSX app is hard, real hard.
I don't know where you got the idea that the Mac OS X UI is significantly different from most other OSes. It is more alike than it is different, and I think you are misinformed (or, more likely, that your information is out of date). If you can provide some specific examples, I will be happy to try to correct you; However, I don't think that discussion belongs here. That said, I think that your argument here is really that if you start by designing a framework without understanding how Mac OS X differs from other OSes, your framework will have trouble porting to Mac OS X. This is hardly a surprise. You can argue that way for any platform -- it's hard to port to a platform you don't understand.
Take Mozilla/Firefox/OpenOffice - each of these suffers the "not quite OS integrated, compared with native apps", even though these apps are propably some of the highest profile cross-platform applications.
The quality of the user interface of all of those applications is something that I, as a professional Mac developer, would be ashamed to ship. (They are not all equally bad, though.) I firmly believe that the problem of producing a cross-platform framework that is able to accommodate the user experience demands of several platforms is difficult and tractable. 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. meeroh
I agree. You point out two major failing of most C++ frameworks: lack of modern C++ use and lack of exception safety. I see the rest of this thread talking a lot about C++ techniques, but there seems to be one major component that everyone is overlooking: producing a good user experience.
Perhaps as a Mac developer I am more aware to the importance of a good user experience; one of the major failings of every cross-platform C++ framework on Mac OS is a poor user experience -- usually due to reinventing OS-provided UI wheels, and thus often making the UI subtly inconsistent with the rest of the OS. This kind of subtle (or less subtle) inconsistency is what makes users (entirely justifiably) bitch and moan and shoddy ports, and give bad product reviews.
umm... which part of "cross-platform" and "use native functionality" is more important?
You are falsely presenting them as mutually exclusive choices.
If you have some functionality provided by one OS, while another doesn't provide it... what do you do?
That case is actually almost completely irrelevant to my point. My point has to do with "reinventing OS-provided wheels", which is completely different from providing additional functionality on a particular OS.
case in point: FreeBSD doesn't provide the "lround()" C99 function - yet Linux does. If I need to round a double to a long, what function do I call that will be portable? The only real choice I have is to re-implement the lround() function so that at minimum, it gets enabled on FreeBSD. Given that I have had to implement a non-OS based version of a function, I then ask myself, "Why bother #ifdef'ing around the custom function - why dont I just use the one that I am providing?" Getting back to what was origonally said - if one platform implements something that another platform doesn't, how can a cross platform library not re-invent the the wheel for that crummy platform? In fact, Boost already does this - at configure/compile time bjam detects the available platform functionality - any missing bits are often provided by supplemental code. Yes I am presenting them as mutually exclusive - and I do realise that the world shouldn't be that way - but in reality, it is. Mathew
In article <084c01c48a6f$b9043480$a901000a@mat>, "Mathew Robertson" <mathew.robertson@redsheriff.com> wrote:
Getting back to what was origonally said - if one platform implements something that another platform doesn't, how can a cross platform library not re-invent the the wheel for that crummy platform?
In that case you are not reinventing an OS-provided wheel. Your case in point has nothing to do with my point. I am talking about the case where a cross-platform library uses non-native implementation of facilities that exist natively, and does so in a way that is not compatible (in terms of user experience) with the native facility. Case in point: text edit fields in Mozilla do not behave the same as text edit fields in every other Mac app. meeroh
Getting back to what was origonally said - if one platform implements something that another platform doesn't, how can a cross platform library not re-invent the the wheel for that crummy platform?
In that case you are not reinventing an OS-provided wheel. Your case in point has nothing to do with my point.
I am talking about the case where a cross-platform library uses non-native implementation of facilities that exist natively, and does so in a way that is not compatible (in terms of user experience) with the native facility. Case in point: text edit fields in Mozilla do not behave the same as text edit fields in every other Mac app.
good example - text fields in Mozilla work the same way as Win32 edit fields, and mostly the same way as edit fields on most Linux libraries. So do the Mozilla coders choose to implement different functionality for a different platform, or do they make the application interface consistant across all platforms? If the answer is OS consistancy (rather than application consistancy), then we are back to square one of ont having a truely cross-platform library. Mathew
In article <087d01c48af5$e99a9860$a901000a@mat>, "Mathew Robertson" <mathew.robertson@redsheriff.com> wrote:
good example - text fields in Mozilla work the same way as Win32 edit fields, and mostly the same way as edit fields on most Linux libraries.
So do the Mozilla coders choose to implement different functionality for a different platform, or do they make the application interface consistant across all platforms? If the answer is OS consistancy (rather than application consistancy), then we are back to square one of ont having a truely cross-platform library.
I don't know why you believe that "truely" cross-platform implies a uniform user experience on all platforms. Uniform user experience on all platforms tends to mean wrong user experience on all but possibly one, and users (at least Mac users, because they tends to have high expectations of their applications) reject this. Put simply, in professional Mac development, developer convenience is secondary to user experience, and the market has shown time and again that Mac users are willing to pay for products that respect them. If you are designing a cross-platform framework, you have to understand this. To answer your other question, I believe that a boost C++ GUI framework would gain adoption on Mac OS X _if_ it is designed with users, not developers, in mind -- which is precisely what I am trying to explain here. meeroh
good example - text fields in Mozilla work the same way as Win32 edit fields, and mostly the same way as edit fields on most Linux libraries.
So do the Mozilla coders choose to implement different functionality for a different platform, or do they make the application interface consistant across all platforms? If the answer is OS consistancy (rather than application consistancy), then we are back to square one of ont having a truely cross-platform library.
I don't know why you believe that "truely" cross-platform implies a uniform user experience on all platforms. Uniform user experience on all platforms tends to mean wrong user experience on all but possibly one, and users (at least Mac users, because they tends to have high expectations of their applications) reject this.
Put simply, in professional Mac development, developer convenience is secondary to user experience, and the market has shown time and again that Mac users are willing to pay for products that respect them. If you are designing a cross-platform framework, you have to understand this.
I do - which is why I say that a cross-platofrm GUI is extremely hard.
To answer your other question, I believe that a boost C++ GUI framework would gain adoption on Mac OS X _if_ it is designed with users, not developers, in mind -- which is precisely what I am trying to explain here.
If it is not designed primarly for developers, why would an OSX developer choose a C++ library over the more conventional C/O-C library? There would be no real incentive to switch to C++... And yes I do agree that it should be designed based around the user experience, and not necessarily around the developer... I'm trying to say is that for Win32 / Unix, you can get away with using C++ for developing GUI's, as this is the norm. For Mac, its not the norm, so why would a developer switch to C++, from say O-C... Mathew
In article <097d01c48b04$f7d380e0$a901000a@mat>, "Mathew Robertson" <mathew.robertson@redsheriff.com> wrote:
And yes I do agree that it should be designed based around the user experience, and not necessarily around the developer... I'm trying to say is that for Win32 / Unix, you can get away with using C++ for developing GUI's, as this is the norm. For Mac, its not the norm, so why would a developer switch to C++, from say O-C...
I don't know why you believe this is not the norm. I have no numbers, but I am pretty sure that C++ and Obj-C are the two main languages used by Mac developers today, and they both have significant market share. Just because most (if not all) cross-platform frameworks are inadequate for professional Mac development (primarily due to lack of focus on user experience) doesn't mean there aren't Mac-only C++ frameworks in use today. meeroh
From: "Mathew Robertson" <mathew.robertson@redsheriff.com>
case in point:
FreeBSD doesn't provide the "lround()" C99 function - yet Linux does.
If I need to round a double to a long, what function do I call that will be portable?
The only real choice I have is to re-implement the lround() function so that at minimum, it gets enabled on FreeBSD.
Given that I have had to implement a non-OS based version of a function, I then ask myself, "Why bother #ifdef'ing around the custom function - why dont I just use the one that I am providing?"
A good reason to revert to the platform functionality is to avoid code bloat. Your framework can be lighter on those platforms that already provide what you need. Another reason is so that, in the future, if a piece of emulated functionality is available on all platforms, you can defer to the platform implementation in all cases and eliminate the emulation code altogether. To make that work, of course, your library must provide its own interface to the functionality which can be directed to the emulation or platform specific implementation. You could use a "platform abstraction layer" upon which to build everything else. Once the PAL was implemented for a given platform, everything else in the library and in client code would just work.
Getting back to what was origonally said - if one platform implements something that another platform doesn't, how can a cross platform library not re-invent the the wheel for that crummy platform?
That's not reinventing the wheel for that "crummy platform," it's implementing it. What's reinvention is ignoring the existing implementation on the other platforms. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Getting back to what was origonally said - if one platform implements something that another platform doesn't, how can a cross platform library not re-invent the the wheel for that crummy platform?
That's not reinventing the wheel for that "crummy platform," it's implementing it. What's reinvention is ignoring the existing implementation on the other platforms.
I do agree mostly, except that Boost is meant to be cross-platform, which means shipping the Boost source code with the platform abstraction layer. And shipping the resultant library to conatin that code as well - think win32 running on win98 vs win32 running on win2k. There would need to be runtime detection of the available functionaly (for only some functions - but the problem does exist). ASIDE: So far during this thread, it may appear that I am saying dont bother... which is crap. It has been mentioned that there is no cross-platform GUI library. All I have tried to do is point out that there are other corss-platform libraries - and they are working hard at solving these vcry problems. Quite a few of them are open source, as such they tend to want to fix design flaws. The point being that they solved most of the problems discussed so far, yet they are still "not excellent" wrt. each point mentioned. Mathew
In article <08b601c48afa$eb621fb0$a901000a@mat>, "Mathew Robertson" <mathew.robertson@redsheriff.com> wrote:
So far during this thread, it may appear that I am saying dont bother... which is crap. It has been mentioned that there is no cross-platform GUI library. All I have tried to do is point out that there are other corss-platform libraries - and they are working hard at solving these vcry problems. Quite a few of them are open source, as such they tend to want to fix design flaws. The point being that they solved most of the problems discussed so far, yet they are still "not excellent" wrt. each point mentioned.
Every major C++ cross-platform library I am aware of has major issues wrt backwards compatibility and legacy C++ code (e.g., poor STL integration, poor user of namespaces, poor use of exceptions) even if you ignore the question of how well its user experience fares on non-Windows platforms. I don't know how hard they are working on it, but I have been waiting for years and I don't know of a single one that's adequate yet -- most of them are not even good enough as a starting point for what I would consider adequate. Also, I don't think that sprinkling open source pixie dust on them magically imbues them with special extraordinary ability or desire to fix design flaws :-) meeroh
From: "Mathew Robertson" <mathew.robertson@redsheriff.com>
Getting back to what was origonally said - if one platform implements something that another platform doesn't, how can a cross platform library not re-invent the the wheel for that crummy platform?
That's not reinventing the wheel for that "crummy platform," it's implementing it. What's reinvention is ignoring the existing implementation on the other platforms.
I do agree mostly, except that Boost is meant to be cross-platform, which means shipping the Boost source code with the platform abstraction layer.
Sure.
And shipping the resultant library to conatin that code as well - think win32 running on win98 vs win32 running on win2k.
The extra code would be part of the sources, sure, but it only needs to be compiled into the executable when needed.
There would need to be runtime detection of the available functionaly (for only some functions - but the problem does exist).
Runtime? Surely we can get the required information as to the available feature set from a compile-time version number, can't we? In the worst case, I could imagine a discovery tool run by Boost Build that computes the available feature set and generates a configuration header that the rest of the library relies upon. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Getting back to what was origonally said - if one platform implements something that another platform doesn't, how can a cross platform library not re-invent the the wheel for that crummy platform?
That's not reinventing the wheel for that "crummy platform," it's implementing it. What's reinvention is ignoring the existing implementation on the other platforms.
I do agree mostly, except that Boost is meant to be cross-platform, which means shipping the Boost source code with the platform abstraction layer.
Sure.
And shipping the resultant library to conatin that code as well - think win32 running on win98 vs win32 running on win2k.
The extra code would be part of the sources, sure, but it only needs to be compiled into the executable when needed.
There would need to be runtime detection of the available functionaly (for only some functions - but the problem does exist).
Runtime? Surely we can get the required information as to the available feature set from a compile-time version number, can't we? In the worst case, I could imagine a discovery tool run by Boost Build that computes the available feature set and generates a configuration header that the rest of the library relies upon.
Not on win32 - actually you are correct that you _could do that_. However, your executable would then not be portable between various flavours of win32 - which in itself is no different from most Unix's - but is not really want you want to do for win32. Mathew
MacOS is a hard creature to make apps portable to - as its UI is significantly different to most other OS's, that making a cross-platform library which appears to work as a native OSX app is hard, real hard.
I don't know where you got the idea that the Mac OS X UI is significantly different from most other OSes. It is more alike than it is different, and I think you are misinformed (or, more likely, that your information is out of date). If you can provide some specific examples, I will be happy to try to correct you; However, I don't think that discussion belongs here.
[ The discussion certainly belongs here - this discussion is about cross-platform GUI toolkits, which is a subset of cross-platform toolkits in general, which is very much a Boost topic. ]
That said, I think that your argument here is really that if you start by designing a framework without understanding how Mac OS X differs from other OSes, your framework will have trouble porting to Mac OS X. This is hardly a surprise. You can argue that way for any platform -- it's hard to port to a platform you don't understand.
Unless I missed completely missed something about OSX, you would preferably code it in Objective-C (which is a fantastic language for creating GUI's). In which case, GUI's for most other platforms are coded in C, C++, Delphi, VB, etc. wouldn't have a place on OSX. Is the prefered language to program GUI's on OSX, C++?
Take Mozilla/Firefox/OpenOffice - each of these suffers the "not quite OS integrated, compared with native apps", even though these apps are propably some of the highest profile cross-platform applications.
The quality of the user interface of all of those applications is something that I, as a professional Mac developer, would be ashamed to ship. (They are not all equally bad, though.)
you highlighted my point exactly - they are bad, compared to native applications, because it is _really hard_ to make a cross-platform GUI library. They are good, particularily considering this fact.
I firmly believe that the problem of producing a cross-platform framework that is able to accommodate the user experience demands of several platforms is difficult and tractable.
tractable => "Easily managed or controlled; governable" (dictionary.com) is the problem "difficult" or "easy"? (my guess that you have miss-type the last bit of the sentence - although I'm not sure which way it was meant...) Mathew
In article <085201c48a75$c161b7f0$a901000a@mat>, "Mathew Robertson" <mathew.robertson@redsheriff.com> wrote:
Unless I missed completely missed something about OSX, you would preferably code it in Objective-C (which is a fantastic language for creating GUI's). In which case, GUI's for most other platforms are coded in C, C++, Delphi, VB, etc. wouldn't have a place on OSX.
Apple has two first-class APIs to the OS. One is C, one is Objective-C. The C APIs can (obviously) be directly called from C++.
Is the prefered language to program GUI's on OSX, C++?
No. C or Objective-C. The C APIs and the Objective-C APIs are approximately equipotent.
The quality of the user interface of all of those applications is something that I, as a professional Mac developer, would be ashamed to ship. (They are not all equally bad, though.)
you highlighted my point exactly - they are bad, compared to native applications, because it is _really hard_ to make a cross-platform GUI library. They are good, particularily considering this fact.
Really hard, yes. Really important, too, if you want to ship a product that doesn't suck.
I firmly believe that the problem of producing a cross-platform framework that is able to accommodate the user experience demands of several platforms is difficult and tractable.
tractable => "Easily managed or controlled; governable" (dictionary.com)
is the problem "difficult" or "easy"? (my guess that you have miss-type the last bit of the sentence - although I'm not sure which way it was meant...)
Ah, it would appear that I was not using "tractable" properly. Thanks for the correction. What I meant it "possible to solve given a sufficiently capable and motivated group of engineers". I believe the problem is hard, but not without a solution. I also think that there's a partial solution that is considerably simpler, and that's what people seem to be shipping today. meeroh
Unless I missed completely missed something about OSX, you would preferably code it in Objective-C (which is a fantastic language for creating GUI's). In which case, GUI's for most other platforms are coded in C, C++, Delphi, VB, etc. wouldn't have a place on OSX.
Apple has two first-class APIs to the OS. One is C, one is Objective-C. The C APIs can (obviously) be directly called from C++.
Is the prefered language to program GUI's on OSX, C++?
No. C or Objective-C. The C APIs and the Objective-C APIs are approximately equipotent.
Most moder GUI development for Unicies, uses C++; for Win32 it is either C, C++, VB, or Delphi. So the question then... would a Boost GUI library (which is C++) be unlikely to be used on OSX?
The quality of the user interface of all of those applications is something that I, as a professional Mac developer, would be ashamed to ship. (They are not all equally bad, though.)
you highlighted my point exactly - they are bad, compared to native applications, because it is _really hard_ to make a cross-platform GUI library. They are good, particularily considering this fact.
Really hard, yes. Really important, too, if you want to ship a product that doesn't suck.
I firmly believe that the problem of producing a cross-platform framework that is able to accommodate the user experience demands of several platforms is difficult and tractable.
tractable => "Easily managed or controlled; governable" (dictionary.com)
is the problem "difficult" or "easy"? (my guess that you have miss-type the last bit of the sentence - although I'm not sure which way it was meant...)
Ah, it would appear that I was not using "tractable" properly. Thanks for the correction. What I meant it "possible to solve given a sufficiently capable and motivated group of engineers". I believe the problem is hard, but not without a solution. I also think that there's a partial solution that is considerably simpler, and that's what people seem to be shipping today.
I agree completely - and is why this "Java style GUI..." is a good discussion topic. Mathew
My experience, mostly from reading the documentation, is that
GOOD cross-platform C++ GUI libraries out there.
I agree. You point out two major failing of most C++ frameworks: lack of modern C++ use and lack of exception safety. I see the rest of this thread talking a lot about C++ techniques, but there seems to be one major component
everyone is overlooking: producing a good user experience.
Perhaps as a Mac developer I am more aware to the importance of a good user experience; one of the major failings of every cross-platform C++
Mac OS is a poor user experience -- usually due to reinventing OS-provided UI wheels, and thus often making the UI subtly inconsistent with the rest of the OS. This kind of subtle (or less subtle) inconsistency is what makes users (entirely justifiably) bitch and moan and shoddy ports, and give bad
"Mathew Robertson" <mathew.robertson@redsheriff.com> skrev i meddelandet news:079f01c48a2e$3e02b4f0$a901000a@mat... there are no that framework on product
reviews.
umm... which part of "cross-platform" and "use native functionality" is more important?
For the developer or for the users of the application? As a user, there is no advantage of "looks equaly crappy on Windows, Linux, and OS X". If I use the application in my environment, it should look native.
If you have some functionality provided by one OS, while another
doesn't provide it... what do you do? You have to either emulate it, map it to similar functionality, or not provide it at all. Probably a little of each! Bo Persson
umm... which part of "cross-platform" and "use native functionality" is more important?
For the developer or for the users of the application?
As a user, there is no advantage of "looks equaly crappy on Windows, Linux, and OS X". If I use the application in my environment, it should look native.
Both. As a developer of a program which is meant to be cross platform - I need to rely on the fact that when I call a function/method/etc, that is works as advertised, without the need for #ifdef's As a user, If I am using OSX, then I want alpha blended goodness, etc.
If you have some functionality provided by one OS, while another doesn't provide it... what do you do?
You have to either emulate it, map it to similar functionality, or not provide it at all. Probably a little of each!
yep - so what would be suitable for Boost? Mathew
It seems that what you're at is a full-blown standalone C++ GUI library. Maybe, it's good goal, but there a lot of toolkits already. I think it's not likely that just a new library will find a lot of users. If somebody has Qt or GTK application, he won't rewrite it just because your library is cleaner or better in some other way.
My experience, mostly from reading the documentation, is that there are no GOOD cross-platform C++ GUI libraries out there.
The likes of WxWindows and GTKMM (the C++ GTK for those who haven't come across if before) suffer, IMO from lack of modern C++ techniques (not even namespaces in WxWindows' case), and unnecessary reinvention of the wheel for things like strings, and neither are exception safe. Which, in my mind, doesn't really make them C++ libraries.
There is no way to say this other than... "Have you used std::string vs any GUI library version of string?" std::string is lame. --> that is why most GUI libraries re-invent their own string class - to overcome the shortcomings of std::string. Also, define what "exception safe" means... in the context of: you left-double-click on an item in a treelist. What do you do to handle this event? Normally your event handler generates: 1. LeftMouseDown event 2. LeftMouseUp event 3. LeftMouseDown + LeftMouseUp + MouseMove < 4 pixels, is detected. This generates a LeftClick 4. Repeat steps 1-3 5 LeftClick + LeftClick + MouseMove < 4 pixels, is detected. This generates a LeftDoubleClick Interposed with each of these events, is the possibility for the application to handle the event by doing some work, eg highlight the clicked treeitem, by handling the LeftClick event. By the very fact of highlighting, you have now modified some state within the treelist widget. Since you have modified state, it becomes extremely hard to rollback your selection (to the previous selection) if an exception is thrown in your LeftDoubleClick handler. So the question should not be "is a GUI library exception safe" but rather "can you throw exceptions 'through' the GUI library and expect the semantics of the exception to be valid".
From my experience, most modern GUI libraries allow exceptions to be thrown through them, although they generally dont throw exceptions themselves, as this tends to break the event handling mechanisms.
Also, they try and do more than be a GUI library, for example by supporting threading and database access.
... why wouldn't a GUI library contain a database browse widget? ... are you suggesting that a worker thread would never want to update some onscreen value?
I can't comment on Qt's exception safety, but I'm put off that because it's no longer free to Windows users. I believe it also does some wheel reinvention and database and threading stuff. I didn't like the extra compile stage for the messaging mechanism either.
Anyway, so what's my point? My point is that I believe the C++ community is crying out for a good real C++ solution.
Good C++ solutions exist. Its the definition of "good" that needs to be defined.
GUI use often does tie people into a particular library.
How could it not? Each library implements a set of API's... thats the reason for wanting a cross-platform library.
Not many people seem to separate their backend logic from the GUI code, so it would be difficult for a lot of people to _change_. However, what about people like me who often start new projects or who do separate (I believe) correctly.
Thats because it is extremenly hard work to seperate event handling, from executing a backend task - I'd say its next to impossible - how would you know what backend work you want to execute without putting the current backend state-logic within the context of your event handlers? Mathew
participants (12)
-
Alec Ross -
Andy Little -
Bo Persson -
David Turner -
John Torjo -
Mathew Robertson -
Miro Jurisic -
Paul Grenyer -
Reece Dunn -
Rob Stewart -
Thorsten Ottosen -
Vladimir Prus