Boost's position/work on a Standard GUI Library for C++0x
In his article "The Design of C++0x", published in C/C++ Users Journal, May 2005, the author of C++ Bjarne Stroustrup wrote, "The most commonly requested new feature for C++ is a standard GUI". I am new to Boost and will appreciate if some folks here would give me a summary of Boost organization's standing on such a standard GUI library. If and how was it addressed and pointers to work on the subject if such has been done. I just want to clarify, that when I say "standard", I mean that as long as my application source code adheres to that standard, if I take it and walk into any machine that has a C++ compiler (at least one that deserves that title), compilation would at least not fail for syntax reasons, w/o me changing a single character in the source (not even changing the case of a character), no matter how complex and/or large that source is. I don't know how to avoid a sea of answers with this mailing list arrangement (not that I think that my 2.6GB gmail box would soon fill up...), may be the few answers can be posted on the newsgroup forum? Thanks in advance for the education, David
David Wehite wrote:
In his article "The Design of C++0x", published in C/C++ Users Journal, May 2005, the author of C++ Bjarne Stroustrup wrote, "The most commonly requested new feature for C++ is a standard GUI".
And the most debated as to how it would work ;)
I am new to Boost and will appreciate if some folks here would give me a summary of Boost organization's standing on such a standard GUI library. If and how was it addressed and pointers to work on the subject if such has been done.
I have, as well as many others, have made attempts into this brave new world ;). I suggest getting the framework right first to allow the support for the GUI/Graphics libraries to be build on top of them. (1) Platform -- detection for what GUI library is being used; native (GTK?, PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.) or cross-platform (wxWidgets, Qt, etc.) and the platform being used for that cross-platform GUI. This could be an extension to Boost.Config with platform/win32.hpp, platform/wxwidgets.hpp, etc. (2) String Library -- helpers to interact with native string types (e.g. wxString and ATL::CString) and C++ strings std::[w]string; native version of std::[w]string for platforms that use wide character strings; conversion routines and other helpers. (3) Colour Library -- there is a discussion of a colour library elsewhere on this list. This is one step to a standard GUI library, but must implicitly (by default?) support the platform being targetted. (4) Coordinates Library -- holding coordinate primitives: point (with its alias size) and rect are a minimum here; matrix and other transforms? what about interactions with other Boost libraries? 2D/3D support (e.g. the Windows GDI verses DirectX)? mixing different compatible systems? I would like to do something like: boost::coord::point2d pos; ::GetCursorPos( pos.native()); // handle POINT <==> point2d conversions Advanced Libraries -- (5) Graphics -- Mixing different graphical systems (e.g. Win32 GDI, GDI+ and DirectDraw/Direct3D).
I just want to clarify, that when I say "standard", I mean that as long as my application source code adheres to that standard, if I take it and walk into any machine that has a C++ compiler (at least one that deserves that title), compilation would at least not fail for syntax reasons, w/o me changing a single character in the source (not even changing the case of a character), no matter how complex and/or large that source is.
This should be one of the goals. It should also be possible to hook into the native code (GTK, wxWidgets, WTL, Win32, PalmOS API, etc.) when/if you want to. - Reece
Thanks for the feedback. Being "The most commonly requested new feature for C++ ", I am very surprise that I got only one response (yours). Something doesn't add up. "Most debated" or not, inability to reach conclusions is, by itself, an inherent problem. See more down here. "Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY101-F230B3798C7C19BD9D8274AA08A0@phx.gbl...
David Wehite wrote:
In his article "The Design of C++0x", published in C/C++ Users Journal, May 2005, the author of C++ Bjarne Stroustrup wrote, "The most commonly requested new feature for C++ is a standard GUI".
And the most debated as to how it would work ;)
I am new to Boost and will appreciate if some folks here would give me a summary of Boost organization's standing on such a standard GUI library. If and how was it addressed and pointers to work on the subject if such has been done.
I have, as well as many others, have made attempts into this brave new world ;).
I suggest getting the framework right first to allow the support for the GUI/Graphics libraries to be build on top of them.
(1) Platform -- detection for what GUI library is being used; native (GTK?, PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.) or cross-platform (wxWidgets, Qt, etc.) and the platform being used for that cross-platform GUI. This could be an extension to Boost.Config with platform/win32.hpp, platform/wxwidgets.hpp, etc.
I don't understand why you even mention the word "platform". C/C++ were born to be (very) portable languages. You would not bring it up with regard to the entity called 'int' right? Now, when I say "I don't understand", this is of course not accurate because... (I think at least) I do. Granted that the scale of a type GUI is not anywere near the scale of 'int'. This does not mean that we should give up on it, just because "its hard work"... :-). And we should strive to make it platform independent like any other part of the language. You don't do any "detection" when you use any other library.
(2) String Library -- helpers to interact with native string types (e.g. wxString and ATL::CString) and C++ strings std::[w]string; native version
std::[w]string for platforms that use wide character strings; conversion routines and other helpers.
(3) Colour Library -- there is a discussion of a colour library elsewhere on this list. This is one step to a standard GUI library, but must implicitly (by default?) support the platform being targetted.
(4) Coordinates Library -- holding coordinate primitives: point (with its alias size) and rect are a minimum here; matrix and other transforms? what about interactions with other Boost libraries? 2D/3D support (e.g. the Windows GDI verses DirectX)? mixing different compatible systems?
I would like to do something like:
boost::coord::point2d pos; ::GetCursorPos( pos.native()); // handle POINT <==> point2d conversions
Advanced Libraries --
(5) Graphics -- Mixing different graphical systems (e.g. Win32 GDI, GDI+ and DirectDraw/Direct3D).
I just want to clarify, that when I say "standard", I mean that as long as my application source code adheres to that standard, if I take it and walk into any machine that has a C++ compiler (at least one that deserves that title), compilation would at least not fail for syntax reasons, w/o me changing a single character in the source (not even changing the case of a character), no matter how complex and/or large that source is.
This should be one of the goals. It should also be possible to hook into
of the
native code (GTK, wxWidgets, WTL, Win32, PalmOS API, etc.) when/if you want to.
- Reece
It makes perhapse sense to have all (or some) of those above mentioned libraries "first" (as you wrote) and indeed, a GUI library might be the culmination or superset of all or some of these libraries plus perhaps other ones, or just other ones altogether. That would depend on a top view of that GUI library. That is why the architects of such a library, should FIRST discuss what is the overall architecture of such a library, THEN decide what will be the sub-components of it, and so on. Like when you architect, design and build any other thing. But more important then all those things mentioned above, it does not make sense to me, that one (individual) or entire organization, will deal with a gazillion bunch of things, ---------------------------------------------------------------------------- ----------- many of which are small change or infinitesimally irrelevat, less important for developers, ---------------------------------------------------------------------------- ----------- before dealing with the most burning subject for the C/C++ developers comunity - a standard GUI library. Even if "it is hard work" (and excuse me if I can't stop from loughing when I recall that expression...). That is of course, if Bjorne's statement that I quoted is true. I personally strongly beleive it is. But is fair to debate that claim too. David David
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(1) Platform -- detection for what GUI library is being used; native (GTK?, PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.) or cross-platform (wxWidgets, Qt, etc.) and the platform being used for that cross-platform GUI. This could be an extension to Boost.Config with platform/win32.hpp, platform/wxwidgets.hpp, etc.
I don't understand why you even mention the word "platform". C/C++ were born to be (very) portable languages. You would not bring it up with regard to the entity called 'int' right?
Actually, I suspect somebody *did*, when the C language was first being designed and standardized, because the behavior of the 'int' type is dependent on the support of the platform (the hardware, in this case) for integer operations, and the int type had to be defined in a way that was flexible enough to take advantage of that capability on almost any hardware. That's why int doesn't have a specified number of bits- so that it can adapt to the platform. That's one reason C/C++ code isn't as portable as one might like. The same applies to a standard GUI library, but raised to the Nth power. Such a library would have to adapt itself to the GUI capabilities provided by the host platform. This doesn't mean comitting the library to a single platform, but it does mean enabling the library to take advantage of whatever capabilities are present.
Geoffrey Romer wrote:
(1) Platform -- detection for what GUI library is being used [snip] I don't understand why you even mention the word "platform". C/C++ were born to be (very) portable languages. You would not bring it up with regard to the entity called 'int' right?
Actually, I suspect somebody *did*, when the C language was first being designed and standardized, because the behavior of the 'int' type is dependent on the support of the platform (the hardware, in this case) for integer operations, and the int type had to be defined in a way that was flexible enough to take advantage of that capability on almost any hardware. That's why int doesn't have a specified number of bits- so that it can adapt to the platform. That's one reason C/C++ code isn't as portable as one might like.
Also, enumeration values, endian issues, floating point sizes and so on.
The same applies to a standard GUI library, but raised to the Nth power. Such a library would have to adapt itself to the GUI capabilities provided by the host platform. This doesn't mean comitting the library to a single platform, but it does mean enabling the library to take advantage of whatever capabilities are present.
This is where the idea of a platform layer comes in. The /platform/ is the Operating System (Win32, Linux, etc.), base API (Win32 API, GDK, PalmOS API, etc.) and (optional) C++ abstraction library (wxWidgets, WTL, MFC, etc.). The platform layer would configure the various capabilities of the target platform just like Boost.Configure checks what C++ facilities are available (e.g. does the compiler support long long? two-phase name lookup?) That is not to say that the other layers don't need specialist code, but it would allow you to do something like: #include BOOST_PLATFORM(boost/gui/graphics,canvas.hpp) and this would resolve to "boost/gui/graphics/wx/canvas.hpp" if you target wxWidgets, for example. I attempted something like this in the sandbox (boost/gui), however I would most likely rewrite several parts of this, keeping some of the tricks like the platform detection/delegation logic. The main reason for the platform layer is to allow mapping from native types to a platform neutral type. However, it may be more feasible to move most of the implementation into the platform specific area: // boost/geometry/win32/point2d.hpp namespace boost::geometry { struct point2d: public POINT { ... }; }} // boost/geometry/cocoa/point2d.hpp namespace boost::geometry { struct point2d: public NSPoint { ... }; }} // boost/geometry/palmos/point2d.hpp namespace boost::geometry { struct point2d: public PointType { ... }; }} These can then use the platform-specific names (e.g. size.cx vs size.width) and layouts (Windows uses area{ top, left, bottom, right }; verses palmos area{ topLeft, extent /*i.e. size*/ }; and cocoa (Mac) area{ origin, size }; NOTE: Mac uses mathematical orientations, so (0, 0) is bottom left whereas Windows has (0, 0) as top left. This knowledge is platform dependant, so should we map to a neutral orientation? There was discussions previously on this subject about using a HTML/CSS style specification and being able to specify values like: point2d pos( 2 * em, 3 * em ); This would interact with Andy Little's unit library. Thus, a GUI library would not be the "all encompassing" GUI library, but a collection of libraries. Indeed, several "GUI" libraries offer other things like thread and filesystem support. These are already a part of Boost and are not really part of the GUI. - Reece
David W wrote:
Thanks for the feedback. Being "The most commonly requested new feature for C++ ", I am very surprise that I got only one response (yours). Something doesn't add up.
"Most debated" or not, inability to reach conclusions is, by itself, an inherent problem.
See more down here.
"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:BAY101-F230B3798C7C19BD9D8274AA08A0@phx.gbl...
David Wehite wrote:
In his article "The Design of C++0x", published in C/C++ Users Journal,
May
2005, the author of C++ Bjarne Stroustrup wrote, "The most commonly requested new feature for C++ is a standard GUI".
And the most debated as to how it would work ;)
I am new to Boost and will appreciate if some folks here would give me a summary of Boost organization's standing on such a standard GUI library.
If
and how was it addressed and pointers to work on the subject if such has been done.
I have, as well as many others, have made attempts into this brave new
world
;).
I suggest getting the framework right first to allow the support for the GUI/Graphics libraries to be build on top of them.
(1) Platform -- detection for what GUI library is being used; native
(GTK?,
PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.)
or
cross-platform (wxWidgets, Qt, etc.) and the platform being used for that cross-platform GUI. This could be an extension to Boost.Config with platform/win32.hpp, platform/wxwidgets.hpp, etc.
I don't understand why you even mention the word "platform". C/C++ were born to be (very) portable languages. You would not bring it up with regard to the entity called 'int' right?
As noted elsewhere...*I* would, even if Reece wouldn't. And there are serious reasons to consider platforms in regard to GUIs.
Now, when I say "I don't understand", this is of course not accurate because... (I think at least) I do. Granted that the scale of a type GUI is not anywere near the scale of 'int'. This does not mean that we should give up on it, just because "its hard work"... :-). And we should strive to make it platform independent like any other part of the language. You don't do any "detection" when you use any other library.
I really don't think we want standard C++ to have a "builtin" GUI that "simply works" on all systems. That makes me think of the Java GUI, which works on all systems with a VM, but unfortunately looks like a Java app regardless. The Windows GUI behaves slightly different than GNOME, and there are quite large differences to OSX from either. I don't think we want a GUI system where people will say, "Hey look at this app; it's obviously written in C++, judging by the UI!" -- /Brian Riis
Brian Riis wrote
I really don't think we want standard C++ to have a "builtin" GUI that "simply works" on all systems.
Sorry . have I misread this ? A C++ GUI that "simply works" is exactly what I want. Its got to be simple for beginning programmes to pick up, generic, have an intuitive model, and have a non-platform dependent interface.
That makes me think of the Java GUI, which works on all systems with a VM, but unfortunately looks like a Java app regardless.
The builtin GUI is a major reason for Java's Success. And notice that it works on the internet where "platform" is not applicable. Personally I think the Java model is well worth looking at for ideas about a C++ GUI. The Windows GUI behaves slightly different than
GNOME, and there are quite large differences to OSX from either.
Thats interesting and useful stuff. Would it be possible to enumerate some of the differences? Personally I would like to have a uniform behaviour of a C++ GUI across platforms if possible.
I don't think we want a GUI system where people will say, "Hey look at this app; it's obviously written in C++, judging by the UI!"
I think you are limiting the possibilities here. Maybe a C++ GUI should be 3D. Maybe we should default to a round window. You cant have true platform independence if by default you need to simulate a particular platforms look and feel. IOW then you cant have one default interface. Being able to put on a platform dependent skin is an often requested feature, but is trivial to achieve IMO. The number one feature is simplicity and ease of use which means platform independence... "simply works") regards Andy Little
Andy Little wrote:
Brian Riis wrote <snip>
I don't think we want a GUI system where people will say, "Hey look at this app; it's obviously written in C++, judging by the UI!"
I think you are limiting the possibilities here. Maybe a C++ GUI should be 3D. Maybe we should default to a round window. You cant have true platform independence if by default you need to simulate a particular platforms look and feel. IOW then you cant have one default interface. Being able to put on a platform dependent skin is an often requested feature, but is trivial to achieve IMO. The number one feature is simplicity and ease of use which means platform independence... "simply works")
regards Andy Little
Could it least not be as ugly as Java's UI? :D More seriously, UI consistancy with the local platform is rather important. On X systems, every time you double-click the title it collapses into it, while on Windows it maximises! The GUI should by default behave the same as the rest of the user's programs. Think of it as localising to the users UI locale.
"Simon Buchan" <simon@hand-multimedia.co.nz> wrote [cut]
More seriously, UI consistancy with the local platform is rather important. On X systems, every time you double-click the title it collapses into it, while on Windows it maximises! The GUI should by default behave the same as the rest of the user's programs. Think of it as localising to the users UI locale.
Thats a good point, but is that not convention only? Its not required behaviour. Suppose I am on an XWindows system and I want MSWindows behaviour. That point about locale is a good one. A sequence of user actions must map to a state-machine that finally maps the sequence of clicks into a particular function such as Maximise, Minimise, etc. Maybe its possible to load the map from some sort of resource. "Windows Actions file" States: Maximised, Minimised, UserSize; Actions: TitleDoubleclick Maximised -> UserSize Minimised -> UserSize UserSize -> Maximised "XWindows Actions File" States: Maximised, Minimised, UserSize; Actions: TitleDoubleclick Maximised -> UserSize Minimised -> UserSize UserSize -> Minimised maybe XML would be a good way to store resources. regards Andy Little
Andy Little wrote:
"Simon Buchan" <simon@hand-multimedia.co.nz> wrote
[cut]
More seriously, UI consistancy with the local platform is rather important. On X systems, every time you double-click the title it collapses into it, while on Windows it maximises! The GUI should by default behave the same as the rest of the user's programs. Think of it as localising to the users UI locale.
Thats a good point, but is that not convention only? Its not required behaviour. Suppose I am on an XWindows system and I want MSWindows behaviour. That point
I think you're thinking like a programmer here :) (and not like a user). A user expects your program to follow a standard (the OS's standard)
about locale is a good one. A sequence of user actions must map to a state-machine that finally maps the sequence of clicks into a particular function such as Maximise, Minimise, etc. Maybe its possible to load the map from some sort of resource.
-- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
"John Torjo" <john.lists@torjo.com> wrote in message news:43425B29.9020502@torjo.com...
Andy Little wrote:
"Simon Buchan" <simon@hand-multimedia.co.nz> wrote
[cut]
More seriously, UI consistancy with the local platform is rather important. On X systems, every time you double-click the title it collapses into it, while on Windows it maximises! The GUI should by default behave the same as the rest of the user's programs. Think of it as localising to the users UI locale.
Thats a good point, but is that not convention only? Its not required behaviour. Suppose I am on an XWindows system and I want MSWindows behaviour. That point
I think you're thinking like a programmer here :) (and not like a user). A user expects your program to follow a standard (the OS's standard)
But maybe I'm developing a Unix app on Windows. (which in my case is actually plausible. I prefer developing on Windows to Linux for instance). Anyway FWIW replicating Look is easy and maybe not as important to get exact, but replicating feeel is more complicated and more important. Meanwhile I'm glad you showed up! I have been looking at various GUI systems including win32gui. There are a lot of things I like in win32gui, for instance use of units.. if only for scripts. However despite the platform independent events section in the documentation, from looking through the source the library seems to be clinging very tightly to Win32 API. As such I dont see how it can be made platform independent without breaking the current interface. What are your comments on that? BTW it looks like it is possible to do XWindows development using Cygwin. Has anyone had any experience of that? regards Andy Little regards Andy little
Andy Little wrote: <snip>
BTW it looks like it is possible to do XWindows development using Cygwin. Has anyone had any experience of that?
AFAIK, Cygwin would like for you to pretend that it /is/ a Linux system, but try using the default DDD package to see how expensive the system is. (No, it *isn't* frozen, it just takes that long to start up GDB!) I havn't tried actually writing XWindows apps, though, either in Cygwin or Linux propper. However, I still find the extra Linux apps (including XWindows apps) quite usefull for development in general (I actually prefer DDD to MSVC .NET's debugger, even with a 2min startup!). Your system may differ, of course, It's been a while since I got CygWin updated (it's quite hard to download at work, copy to disk, install at home, due to package tools)
"Jonathan Benedicto" <jomitec@sympatico.ca> wrote
BTW it looks like it is possible to do XWindows development using Cygwin. Has anyone had any experience of that?
Yes, I've been able to build XWindow apps in Cygwin.
Great. Thanks for the reply. I've heard that it is not as easy as developing for Windows. I staht so? regards Andy Little
"Jonathan Benedicto" <jomitec@sympatico.ca> wrote
BTW it looks like it is possible to do XWindows development using Cygwin. Has anyone had any experience of that?
Yes, I've been able to build XWindow apps in Cygwin.
Great. Thanks for the reply. I've heard that it is not as easy as developing for Windows. I staht so? regards Andy Little
From: "Andy Little" <andy@servocomm.freeserve.co.uk>
Great. Thanks for the reply. I've heard that it is not as easy as developing for Windows. I staht so?
Well, I don't really know. I think that the Win32API has much more capability, and is easier to learn, but that is just my opinion. I use the KDE port for cygwin, and then compile and test my XWindow apps inside KDE. Jonathan
I think you're thinking like a programmer here :) (and not like a user). A user expects your program to follow a standard (the OS's standard)
But maybe I'm developing a Unix app on Windows. (which in my case is actually plausible. I prefer developing on Windows to Linux for instance). Anyway FWIW replicating Look is easy and maybe not as important to get exact, but replicating feeel is more complicated and more important.
Yup, I *feel* you ;)
Meanwhile I'm glad you showed up! I have been looking at various GUI systems including win32gui. There are a lot of things I like in win32gui, for instance use of units.. if only for scripts. However despite the platform independent events section in the documentation, from looking through the source the library seems to be clinging very tightly to Win32 API. As such I dont see how it can be made platform independent without breaking the current interface. What are your comments on that?
Again, I think it's possible -- I'll need to split the platform-dependent and platform-independent parts, to make it more clear - which is quite some work, but I should have some time for it in the next couple of months. Then, you'll see what needs to be ported. As for events, I'm for using what the underlying OS has. In the CUJ article for Jan 06, I'll delve deeper into events. I think I can even provide means to emulate an event, if your platform doesn't have it -- but it's too soon to be certain. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
John Torjo wrote:
More seriously, UI consistancy with the local platform is rather important. On X systems, every time you double-click the title it collapses into it, while on Windows it maximises! The GUI should by default behave the same as the rest of the user's programs. Think of it as localising to the users UI locale.
Thats a good point, but is that not convention only? Its not required behaviour. Suppose I am on an XWindows system and I want MSWindows behaviour. That point
I think you're thinking like a programmer here :) (and not like a user). A user expects your program to follow a standard (the OS's standard)
Well, some OSes don't have any GUI standard, unfortunately. I do believe localization is a good concept. Of course, the default locale would be 'native', so everybody should ba happy, right ? Regards, Stefan
Simon Birchen said:
Andy Little wrote:
Could it least not be as ugly as Java's UI? :D More seriously, UI consistancy with the local platform is rather important. On X systems, every time you double-click the title it collapses into it, while on Windows it maximises! The GUI should by default behave the same as the rest of the user's programs. Think of it as localising to the users UI locale.
localizing and locale, interesting... TrollTech call it Style ;-) http://doc.trolltech.com/4.0/qstyle.html Just to show that this can be done, in case anybody was thinking otherwise. It actually works flawlessly, under the hood they hide details all details. Some times you actually have to be on the real OS platform to get all details to look native, as it adapts to higher level drawing primitives in the its platform when detected to do some of the drawing. Again, it actually works. Bjørn
Andy Little wrote:
Brian Riis wrote
I really don't think we want standard C++ to have a "builtin" GUI that "simply works" on all systems.
Sorry . have I misread this ? A C++ GUI that "simply works" is exactly what I want. Its got to be simple for beginning programmes to pick up, generic, have an intuitive model, and have a non-platform dependent interface.
I'm not contesting this. I'm contesting that it should produce identical windows on all platforms.
That makes me think of the Java GUI, which works on all systems with a VM, but unfortunately looks like a Java app regardless.
The builtin GUI is a major reason for Java's Success. And notice that it works on the internet where "platform" is not applicable. Personally I think the Java model is well worth looking at for ideas about a C++ GUI.
Well, "platform" *is* applicable to a Java program. The thing is, though, that a JVM *is* the platform. Java really drags its platform around with it.
The Windows GUI behaves slightly different than
GNOME, and there are quite large differences to OSX from either.
Thats interesting and useful stuff. Would it be possible to enumerate some of the differences? Personally I would like to have a uniform behaviour of a C++ GUI across platforms if possible.
I wouldn't. If I am on a Windows box, I want the look-n-feel of a program to be that of any other Windows program. The normal layout of a window should apply, and the Windows shortcuts should work, e.g. being able to start editing any textcontrol by pressing F2. On GNOME I would expect an app to behave like other GNOME programs. OSX differs from the other platforms in many ways, because Apple's Style Guide suggests different layouts. As a simple example, consider a message dialog box with a message the user should consider and then choose Yes, No, or Cancel. On Windows the three buttons would be centered and come in the order mentioned above. On GNOME the buttons would be right-aligned and be ordered "No", "Yes", and "Cancel". On OSX the "No" button would be left-aligned along the message text, while "Cancel", and "Yes" - in that order - would be right-aligned. And so far it's just layout issues. My point is, basically, that the different platforms *feel* different, and users will expect a program to feel like the platform they're on. Java apps feel like Java apps all over. This is great for web-based applications (my NetBanking wouldn't be right without it), but not so great for desktop applications.
I don't think we want a GUI system where people will say, "Hey look at this app; it's obviously written in C++, judging by the UI!"
I think you are limiting the possibilities here. Maybe a C++ GUI should be 3D. Maybe we should default to a round window. You cant have true platform independence if by default you need to simulate a particular platforms look and feel. IOW then you cant have one default interface. Being able to put on a platform dependent skin is an often requested feature, but is trivial to achieve IMO. The number one feature is simplicity and ease of use which means platform independence... "simply works")
My point is that it shouldn't be a "skin". You can change the look that way, but rarely the feel of an application.
regards Andy Little
-- /Brian Riis
On Thu, Sep 29, 2005 at 11:37:15AM +0200, Brian Ravnsgaard Riis <brian@riis.as> wrote:
The Windows GUI behaves slightly different than
GNOME, and there are quite large differences to OSX from either.
Thats interesting and useful stuff. Would it be possible to enumerate some of the differences? Personally I would like to have a uniform behaviour of a C++ GUI across platforms if possible.
I wouldn't. If I am on a Windows box, I want the look-n-feel of a program to be that of any other Windows program. The normal layout of a window should apply, and the Windows shortcuts should work, e.g. being able to start editing any textcontrol by pressing F2. On GNOME I would expect an app to behave like other GNOME programs. OSX differs from the other platforms in many ways, because Apple's Style Guide suggests different layouts.
Then you have to use a different library for each plattform. I claim that it is impossible to write a library which is able to refactor your layouts keybindings and more. You also forgot to mention that each plattform has a different set of widgets, or similar widgets with different features. Either you hide features that arent available on every plattform, or you reimplement missing ones, which might be impossible. You can look at wxWidgets for some examples. Maybe your library is implementable on a much higher level, as a sort of code generation tool that manages the applications data model and provides plattform dependent views on the data. I think that we should drop the wrapper idea for now. There are many applications on Windows, OSX and linux, that do not follow the native look and feel, if something like that exists at all. All devs not happy with that situation should work on and with wxWidgets, until that library is really portable and useable on all plattforms it claims to support. Regards Andreas Pokorny
"Brian Ravnsgaard Riis" <brian@riis.as> wrote [cut]
As a simple example, consider a message dialog box with a message the user should consider and then choose Yes, No, or Cancel. On Windows the three buttons would be centered and come in the order mentioned above. On GNOME the buttons would be right-aligned and be ordered "No", "Yes", and "Cancel". On OSX the "No" button would be left-aligned along the message text, while "Cancel", and "Yes" - in that order - would be right-aligned. And so far it's just layout issues.
For this you would provide a default platform-dependent layout. More interesting is that the message dialog box functionality is very similar on each platform !
My point is, basically, that the different platforms *feel* different, and users will expect a program to feel like the platform they're on. Java apps feel like Java apps all over. This is great for web-based applications (my NetBanking wouldn't be right without it), but not so great for desktop applications.
[cut]
My point is that it shouldn't be a "skin". You can change the look that way, but rarely the feel of an application.
This is really about the ability to customize the feel of the GUI. Maybe it should be designed with this capability ;-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
This is really about the ability to customize the feel of the GUI. Maybe it should be designed with this capability ;-)
Is the only essential difference between a GUI application and a command-line application, that the GUI application 'feels' state of the users input pointer? Just a thought... regards Andy Little
Obviously we have here some who want to UI to be identical on all platforms (count me here) and some who want it to be identical with actual plaform. I personly think that this shoul;d be done by appling "lokk & feel" (like in Java). You would have then choice if you want identical UI on all paltforms (and choice of how would this look like) or "platform native" look, or even on plaform look on any other... Adam Badura "Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:dhg8k0$gr4$1@sea.gmane.org...
Brian Riis wrote
I really don't think we want standard C++ to have a "builtin" GUI that "simply works" on all systems.
Sorry . have I misread this ? A C++ GUI that "simply works" is exactly what I want. Its got to be simple for beginning programmes to pick up, generic, have an intuitive model, and have a non-platform dependent interface.
That makes me think of the Java GUI, which works on all systems with a VM, but unfortunately looks like a Java app regardless.
The builtin GUI is a major reason for Java's Success. And notice that it works on the internet where "platform" is not applicable. Personally I think the Java model is well worth looking at for ideas about a C++ GUI.
The Windows GUI behaves slightly different than
GNOME, and there are quite large differences to OSX from either.
Thats interesting and useful stuff. Would it be possible to enumerate some of the differences? Personally I would like to have a uniform behaviour of a C++ GUI across platforms if possible.
I don't think we want a GUI system where people will say, "Hey look at this app; it's obviously written in C++, judging by the UI!"
I think you are limiting the possibilities here. Maybe a C++ GUI should be 3D. Maybe we should default to a round window. You cant have true platform independence if by default you need to simulate a particular platforms look and feel. IOW then you cant have one default interface. Being able to put on a platform dependent skin is an often requested feature, but is trivial to achieve IMO. The number one feature is simplicity and ease of use which means platform independence... "simply works")
regards Andy Little
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Adam Badura" <abadura@o2.pl> skrev i meddelandet news:dhgg2j$84h$1@sea.gmane.org...
Obviously we have here some who want to UI to be identical on all platforms (count me here) and some who want it to be identical with actual plaform.
Why do you want that? When I run several programs on Windows, I want them to behave like Windows programs, not like C++ programs. Why would I want the interfaces to depend on the language the programs are written in? Bo Persson
Bo Persson wrote:
"Adam Badura" <abadura@o2.pl> skrev i meddelandet news:dhgg2j$84h$1@sea.gmane.org...
Obviously we have here some who want to UI to be identical on all platforms (count me here) and some who want it to be identical with actual plaform.
Why do you want that?
When I run several programs on Windows, I want them to behave like Windows programs, not like C++ programs. Why would I want the interfaces to depend on the language the programs are written in?
As far as I understand the question is not how to give the GUI a typical 'C++' brand (or 'boost' for that matter), but to be uniform across all platforms. In other words, the power to style the application should be given to the application developer, not the underlaying OS. (As some have noted it is even better if that styling power can be shifted even closer to the user as is done e.g. with Qt, but not relying on any 'native' style is certainly a first step.) Regards, Stefan
Stefan Seefeld wrote:
(As some have noted it is even better if that styling power can be shifted even closer to the user as is done e.g. with Qt, but not relying on any 'native' style is certainly a first step.)
Which I think should be avoided. But I think I made my point clear earlier, so I'll not elaborate here...
Regards, Stefan
-- /Brian Riis
"Stefan Seefeld" <seefeld@sympatico.ca> skrev i meddelandet news:433C2117.7090405@sympatico.ca...
Bo Persson wrote:
"Adam Badura" <abadura@o2.pl> skrev i meddelandet news:dhgg2j$84h$1@sea.gmane.org...
Obviously we have here some who want to UI to be identical on all platforms (count me here) and some who want it to be identical with actual plaform.
Why do you want that?
When I run several programs on Windows, I want them to behave like Windows programs, not like C++ programs. Why would I want the interfaces to depend on the language the programs are written in?
As far as I understand the question is not how to give the GUI a typical 'C++' brand (or 'boost' for that matter), but to be uniform across all platforms.
Ok, but what if I want the interface to be uniform across several applications on my platform? Are you talking about the API or the way it looks for the users?
In other words, the power to style the application should be given to the application developer, not the underlaying OS.
(As some have noted it is even better if that styling power can be shifted even closer to the user as is done e.g. with Qt, but not relying on any 'native' style is certainly a first step.)
IMO, having an application look native is absolutely highest priority. :-) Bo Persson
Bo Persson wrote:
"Stefan Seefeld" <seefeld@sympatico.ca> skrev i meddelandet news:433C2117.7090405@sympatico.ca...
As far as I understand the question is not how to give the GUI a typical 'C++' brand (or 'boost' for that matter), but to be uniform across all platforms.
Ok, but what if I want the interface to be uniform across several applications on my platform?
That's an excellent question, and certainly one argument leading the Qt developers to putting the choice of style into the hands of the users.
Are you talking about the API or the way it looks for the users?
I'm talking about the graphical interface. Regards, Stefan
Bo Persson wrote:
"Stefan Seefeld" <seefeld@sympatico.ca> skrev i meddelandet news:433C2117.7090405@sympatico.ca...
IMO, having an application look native is absolutely highest priority. :-)
Why? I look at the Windows Media Player and it doesn't look native at all. That's even before I add skins. Yet, no matter how I tweak it, my 7 year old daughter still manages to play her favorite songs without any problems. Also, I hear no one complaining that almost all games have their own unique interfaces. Kids manage. So can adults. This "everyone must wear black" is simply nonesense! Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Joel de Guzman" <joel@boost-consulting.com> wrote
Kids manage. So can adults.
Hmmm, I am in the arguing mood today, can't do anything about it ;-) My 6 year old son managed to achieve perfect English after having used the language for only two years. I've been using it for ten years, and I am still not comfortable. Will definitely stay like this for the rest of my life :-( Now, guess who decides which language we use at home... Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote
Kids manage. So can adults.
Hmmm, I am in the arguing mood today, can't do anything about it ;-)
My 6 year old son managed to achieve perfect English after having used the language for only two years. I've been using it for ten years, and I am still not comfortable. Will definitely stay like this for the rest of my life :-(
Now, guess who decides which language we use at home...
Haha! Good point. Nevertheless, if you look at it in that perspective. It more or less reinforces my point. Sometime in the future; and I am looking forward, these kids who grew up on *cool* GUIs will dictate the future trend. Then, old bland UIs will be a relic of the past, like old model Ts. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman <joel@boost-consulting.com> writes:
Arkadiy Vertleyb wrote:
"Joel de Guzman" <joel@boost-consulting.com> wrote
Kids manage. So can adults.
Hmmm, I am in the arguing mood today, can't do anything about it ;-)
My 6 year old son managed to achieve perfect English after having used the language for only two years. I've been using it for ten years, and I am still not comfortable. Will definitely stay like this for the rest of my life :-(
Now, guess who decides which language we use at home...
Haha! Good point. Nevertheless, if you look at it in that perspective. It more or less reinforces my point. Sometime in the future; and I am looking forward, these kids who grew up on *cool* GUIs will dictate the future trend. Then, old bland UIs will be a relic of the past, like old model Ts.
Or else those ex-kids will be too old to think of anything *cool*. :) -- Dave Abrahams Boost Consulting www.boost-consulting.com
In article <dhk066$su6$1@sea.gmane.org>, Joel de Guzman <joel@boost-consulting.com> wrote:
Bo Persson wrote:
"Stefan Seefeld" <seefeld@sympatico.ca> skrev i meddelandet news:433C2117.7090405@sympatico.ca...
IMO, having an application look native is absolutely highest priority. :-)
Why? I look at the Windows Media Player and it doesn't look native at all. That's even before I add skins. Yet, no matter how I tweak it, my 7 year old daughter still manages to play her favorite songs without any problems. Also, I hear no one complaining that almost all games have their own unique interfaces. Kids manage. So can adults.
This "everyone must wear black" is simply nonesense!
Let's leave the question of what the app looks like alone for a sec. The important question is whether it *behaves* consistently with the rest of the OS. First of all, the reason why behavior consistency is important is so that when you switch from one application to another you do not have to switch mental models. Any time two applications do the same thing slightly differently you create a usability barrier for the user. The reason why this is not as pertinent to games as it is to other apps is twofold: - You almost never go back and forth between a game and other applications; more often, you play the game for an extended period of time, then you stop and go back to using multiple applications. If you consider games which do use side-by-side with other applications, you will see that those games often *do* use standard UI elements. This is not an accident. - Games often require UI beyond what other applications use anyway -- there is no standard 3D motion controller, for example -- so they already have to get into the business of substantially extending standard behaviors; from there it's a smaller leap to reinventing the entire UI. The reason that WMP works for your daughter is that it behaves similarly to other apps, even though it looks differently. Now, when you consider the behaviors of OS-provided elements, there is a tremendous amount of subtle detail involved. If you have an application with minimal UI (such as WMP), then it's not difficult to come close to emulating the relatively small set of behaviors in your custom UI. However, as your application grows, the set of behaviors that you need to emulate expands until it incorporates pretty much everything that the OS provides. So you end up having to emulate everything the OS provides *and* you have to maintain this as the OS is updated and the behaviors sometimes slightly change. This generally results in: 1. a tremendous effort committed to keeping up with the OS-provided behaviors or 2. an application that constantly behaves subtly differently from majority of other applications Arguably the former option is a colossal waste of time. Without any doubt the latter option is what leaves the users with an impression of a sub-par application. This is *especially* true on Mac OS X, where users are much more sensitized to subtle behavior differences, and developer and users care a lot more about this type of polish than they do on other platforms. (I don't want to get into a discussion here about why this is the case or whether it's a good thing.) I absolutely do not have faith in the ability of any group of developers to maintain a system which correctly emulates OS-provided behaviors, and continues to do so over time, and does so across more than one operating system. Therefore, I conjecture that any system designed under that premise eventually falls away from option 1 and adopts option 2. As a developer, especially as a Mac developer, I find option 2 wholly unacceptable. That option makes the usability of the system as a whole degrade, because the interface behaviors do not scale beyond a subset of applications I might have installed on my system. It is because of this conclusion (namely, that reimplementing OS-provided behaviors leads to an overall degradation in the usability of the system as a whole) that I find this option unacceptable. Ben -- I changed my name: <http://periodic-kingdom.org/People/NameChange.php>
[...] As a developer, especially as a Mac developer, I find option 2 wholly unacceptable. That option makes the usability of the system as a whole degrade, because the interface behaviors do not scale beyond a subset of applications I might have installed on my system.
It is because of this conclusion (namely, that reimplementing OS-provided behaviors leads to an overall degradation in the usability of the system as a whole) that I find this option unacceptable.
Couldn't agree more! That's why I invented surfaces (http://www.torjo.com/win32gui/surfaces.html) -- so that you can customize the UI, while *maintaining* the behaviour of the underlying OS Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
Why? I look at the Windows Media Player and it doesn't look native at all. That's even before I add skins. Yet, no matter how I tweak it, my 7 year old daughter still manages to play her favorite songs without any problems. Also, I hear no one complaining that almost all games have their own unique interfaces. Kids manage. So can adults.
This "everyone must wear black" is simply nonesense!
I think it really depends on the application, and how/how much it interacts with users. So, Windows Media Player might not be the best example: a few "Play", "Pause", etc buttons are just too easy for users to use. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
Adam Badura wrote:
Obviously we have here some who want to UI to be identical on all platforms (count me here) and some who want it to be identical with actual plaform. I personly think that this shoul;d be done by appling "lokk & feel" (like in Java). You would have then choice if you want identical UI on all paltforms (and choice of how would this look like) or "platform native" look, or even on plaform look on any other...
I guess this could also be implemented using surfaces (http://www.torjo.com/win32gui/surfaces.html), assuming we'll be able to port win32gui to other platforms. Using surfaces, you could use the platform's look-and-feel, or choose your own, or use a mixture. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
The builtin GUI is a major reason for Java's Success.
I think the major reason for Java's (commersial) success is that it has _commersial_ forces behind it. As opposed to C++, that is mainly moved forward by academics and enthusiasts. If we were to make C++ commersially successfull, we would now be developing threads, all kinds of networking, and database access, like crazy. But since we are here mostly to have fun, gain an experience, write articles, etc., we are busy with MPL and PP, lambdas and binders, parsers and regular expressions, foreach and typeof, etc., etc., etc. Things that are cool, and useful for language development, but hardly ever considered when somebody has to decide in which language to implement a distributed concurrent system. (I hope nobody gets offended. The above libraries are provided for example only, and without any hint to their relative importance) As for GUI, the last time I saw a portable one, it sucked. Yes, I admit, it was 5 years ago, and it was AWT, so maybe thins changed drammatically? Are modern GUI libraries really able to produce _decent_ cross-platform GUI? Regards, Arkadiy
Arkadiy Vertleyb wrote:
As for GUI, the last time I saw a portable one, it sucked. Yes, I admit, it was 5 years ago, and it was AWT, so maybe thins changed drammatically? Are modern GUI libraries really able to produce _decent_ cross-platform GUI?
Take a look at: * the Mozilla GUI; * OpenOffice.org (I believe htey use an inhouse cross-platform GUI, but I may be wrong); * Perforce's p4v (this uses wxWidgets, I believe); * WINE :) (yes, I know this isn't really a cross-platform GUI); * applications written with Qt. - Reece
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote
As for GUI, the last time I saw a portable one, it sucked. Yes, I admit, it was 5 years ago, and it was AWT, so maybe thins changed drammatically? Are modern GUI libraries really able to produce _decent_ cross-platform GUI?
I believe AWT has been superceded by Swing: http://java.sun.com/j2se/1.5.0/docs/guide/swing/ regards Andy Little
Some reason that we don't just copy Java for a standad C++ GUI? Or is there anyone who thinks they can improve on Swing? Joel Eidsath Andy Little wrote:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote
As for GUI, the last time I saw a portable one, it sucked. Yes, I admit, it was 5 years ago, and it was AWT, so maybe thins changed drammatically? Are modern GUI libraries really able to produce _decent_ cross-platform GUI?
I believe AWT has been superceded by Swing:
http://java.sun.com/j2se/1.5.0/docs/guide/swing/
regards Andy Little
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 9/29/05, Joel Eidsath <jeidsath@gmail.com> wrote:
Some reason that we don't just copy Java for a standad C++ GUI? Or is there anyone who thinks they can improve on Swing?
I dont know if they can improve. But I think _we_ can improve its design a lot with the power that C++ has that Java lacks. And, IMO, there are other concerns about GUI that Sun overlooked, like the GUI feel on various platforms. IMO, for Java applications to have the same feel running in different OS is something acceptable, since Java *is* a platform, but it isnt acceptable as requirement in C++. -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
"Felipe Magno de Almeida" wrote
On 9/29/05, Joel Eidsath wrote:
Some reason that we don't just copy Java for a standad C++ GUI? Or is there anyone who thinks they can improve on Swing?
I dont know if they can improve. But I think _we_ can improve its design a lot with the power that C++ has that Java lacks. And, IMO, there are other concerns about GUI that Sun overlooked, like the GUI feel on various platforms. IMO, for Java applications to have the same feel running in different OS is something acceptable, since Java *is* a platform, but it isnt acceptable as requirement in C++.
On the contrary ...according to the Swing site " The pluggable look and feel (...of Swing...) lets you design a single set of GUI components that can automatically have the look and feel of any OS platform (Microsoft Windows, SolarisTM, Macintosh) " Java users must have complained ;-) Apparently this is achieved by Swing modularising each widget using Model -View- Controller architecture. ( I presume the View is customised per platform) regards Andy Little
On 9/29/05, Andy Little <andy@servocomm.freeserve.co.uk> wrote:
On the contrary ...according to the Swing site " The pluggable look and feel (...of Swing...) lets you design a single set of GUI components that can automatically have the look and feel of any OS platform (Microsoft Windows, SolarisTM, Macintosh) " Java users must have complained ;-)
I maybe a little outdated, but I think that the only thing that looks more like the native thing, are the widgets. But the layout isnt flexible enough to make the whole application have the look and feel of a windows application. And, AFAIK, this pluggable look and feel already existed since AWT. [snip]
regards Andy Little
best regards, -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
"Felipe Magno de Almeida" wrote
On 9/29/05, Andy Little wrote:
On the contrary ...according to the Swing site " The pluggable look and feel (...of Swing...) lets you design a single set of GUI components that can automatically have the look and feel of any OS platform (Microsoft Windows, SolarisTM, Macintosh) " Java users must have complained ;-)
I maybe a little outdated, but I think that the only thing that looks more like the native thing, are the widgets. But the layout isnt flexible enough to make the whole application have the look and feel of a windows application. And, AFAIK, this pluggable look and feel already existed since AWT.
Hmm Maybe your right!. Heres a message in comp.lang.java. http://tinyurl.com/8a7un regards Andy little
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Joel Eidsath Sent: Thursday, September 29, 2005 1:02 PM To: boost@lists.boost.org Subject: Re: [boost] Reason for Java's Success
Some reason that we don't just copy Java for a standad C++ GUI? Or is there anyone who thinks they can improve on Swing?
IMHO, when talking about UI, we should consider Windows UI. Majority of the UI users are used to Windows look and feel and providing something like it would definitely appeal to most of the UI developers, including myself. Java AWT and Swing are not good examples to consider for UI design. Sun made a deliberate effort not follow the standards set by Microsoft and they haven't done a good job in providing an alternative. --Suman
Joel Eidsath
Andy Little wrote:
"Arkadiy Vertleyb" <vertleyb@hotmail.com> wrote
As for GUI, the last time I saw a portable one, it sucked. Yes, I admit, it was 5 years ago, and it was AWT, so maybe thins changed drammatically? Are modern GUI libraries really able to produce _decent_ cross-platform GUI?
I believe AWT has been superceded by Swing:
http://java.sun.com/j2se/1.5.0/docs/guide/swing/
regards Andy Little
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Suman Cherukuri wrote:
IMHO, when talking about UI, we should consider Windows UI. Majority of the UI users are used to Windows look and feel and providing something like it would definitely appeal to most of the UI developers, including myself.
Java AWT and Swing are not good examples to consider for UI design. Sun made a deliberate effort not follow the standards set by Microsoft and they haven't done a good job in providing an alternative.
Then let's go down that route all the way and use MFC, too ! (speaking of 'following the standards set by Microsoft'...) Resistance is futile... Sarcastically your's Stefan PS: Sorry, couldn't resist.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: Thursday, September 29, 2005 1:41 PM To: boost@lists.boost.org Subject: Re: [boost] Reason for Java's Success
Suman Cherukuri wrote:
IMHO, when talking about UI, we should consider Windows UI. Majority of the UI users are used to Windows look and feel and providing something like it would definitely appeal to most of the UI developers, including myself.
Java AWT and Swing are not good examples to consider for UI design. Sun made a deliberate effort not follow the standards set by Microsoft and they haven't done a good job in providing an alternative.
Then let's go down that route all the way and use MFC, too ! (speaking of 'following the standards set by Microsoft'...)
Resistance is futile...
Sarcastically your's
Stefan
PS: Sorry, couldn't resist.
No offence taken. Whether we like it or not, it's the reality that the majority of the UI users are comfortable with the existing "standards". One can be bold and come up with a whole new design, but as a commercial developer, I'd be really hesitant to change the face of my software just because it's new (and may be better). --Suman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Suman Cherukuri wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stefan Seefeld Sent: Thursday, September 29, 2005 1:41 PM To: boost@lists.boost.org Subject: Re: [boost] Reason for Java's Success
Suman Cherukuri wrote:
IMHO, when talking about UI, we should consider Windows UI. Majority of
the
UI users are used to Windows look and feel and providing something like
it
would definitely appeal to most of the UI developers, including myself.
Java AWT and Swing are not good examples to consider for UI design. Sun made a deliberate effort not follow the standards set by Microsoft and
they
haven't done a good job in providing an alternative.
Then let's go down that route all the way and use MFC, too ! (speaking of 'following the standards set by Microsoft'...)
Resistance is futile...
Sarcastically your's
Stefan
PS: Sorry, couldn't resist.
No offence taken. Whether we like it or not, it's the reality that the majority of the UI users are comfortable with the existing "standards". One can be bold and come up with a whole new design, but as a commercial developer, I'd be really hesitant to change the face of my software just because it's new (and may be better).
This is total nonsense. Even MS switched the L&F when it switched from Win3.x to Win95/98 to WinXP. No one complains. Are you saying that *only* MS has the right to change L&F? Or to be more general, is it the sole right of OS vendors to dictate the L&F? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman <joel@boost-consulting.com> writes:
Suman Cherukuri wrote:
No offence taken. Whether we like it or not, it's the reality that the majority of the UI users are comfortable with the existing "standards". One can be bold and come up with a whole new design, but as a commercial developer, I'd be really hesitant to change the face of my software just because it's new (and may be better).
This is total nonsense. Even MS switched the L&F when it switched from Win3.x to Win95/98 to WinXP. No one complains. Are you saying that *only* MS has the right to change L&F? Or to be more general, is it the sole right of OS vendors to dictate the L&F?
That may be true as a practical matter. I believe Suman was talking about what users will accept, rather than what anyone has "a right" to do. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Suman Cherukuri wrote:
No offence taken. Whether we like it or not, it's the reality that the majority of the UI users are comfortable with the existing "standards". One can be bold and come up with a whole new design, but as a commercial developer, I'd be really hesitant to change the face of my software just because it's new (and may be better).
This is total nonsense. Even MS switched the L&F when it switched from Win3.x to Win95/98 to WinXP. No one complains. Are you saying that *only* MS has the right to change L&F? Or to be more general, is it the sole right of OS vendors to dictate the L&F?
That may be true as a practical matter. I believe Suman was talking about what users will accept, rather than what anyone has "a right" to do.
Understood. I apologize for my tone. Still, I simply do not buy this "comfortable with the existing standards" thing. OS vendors, including MS, change the L&F all the time. People adjust quickly unless the L&F is too alien. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman <joel@boost-consulting.com> writes:
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
That may be true as a practical matter. I believe Suman was talking about what users will accept, rather than what anyone has "a right" to do.
Understood. I apologize for my tone. Still, I simply do not buy this "comfortable with the existing standards" thing. OS vendors, including MS, change the L&F all the time. People adjust quickly unless the L&F is too alien.
It's one thing when all your apps change at once. When they're all different, it may be quite another. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Joel de Guzman" <joel@boost-consulting.com> skrev i meddelandet news:dhjj0q$fq2$1@sea.gmane.org...
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Suman Cherukuri wrote:
No offence taken. Whether we like it or not, it's the reality that the majority of the UI users are comfortable with the existing "standards". One can be bold and come up with a whole new design, but as a commercial developer, I'd be really hesitant to change the face of my software just because it's new (and may be better).
This is total nonsense. Even MS switched the L&F when it switched from Win3.x to Win95/98 to WinXP. No one complains. Are you saying that *only* MS has the right to change L&F? Or to be more general, is it the sole right of OS vendors to dictate the L&F?
That may be true as a practical matter. I believe Suman was talking about what users will accept, rather than what anyone has "a right" to do.
Understood. I apologize for my tone. Still, I simply do not buy this "comfortable with the existing standards" thing. OS vendors, including MS, change the L&F all the time. People adjust quickly unless the L&F is too alien.
No. When I moved from win 95 to XP, I expected the applications to look like XP applications. Those that had the old look-and-feel felt really old and were soon replaced. For people using only one platform, there is no requirement what so ever to have an application look the same on Windows, Linux, OSX, and Palm OS. There is a requirement that all programs look and behave similar to each other, for the specific platform. Bo Persson
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Bo Persson Sent: Friday, September 30, 2005 10:59 AM To: boost@lists.boost.org Subject: Re: [boost] Reason for Java's Success
"Joel de Guzman" <joel@boost-consulting.com> skrev i meddelandet news:dhjj0q$fq2$1@sea.gmane.org...
David Abrahams wrote: [snip]
Understood. I apologize for my tone. Still, I simply do not buy this "comfortable with the existing standards" thing. OS vendors, including MS, change the L&F all the time. People adjust quickly unless the L&F is too alien.
No. When I moved from win 95 to XP, I expected the applications to look like XP applications. Those that had the old look-and-feel felt really old and were soon replaced.
For people using only one platform, there is no requirement what so ever to have an application look the same on Windows, Linux, OSX, and Palm OS. There is a requirement that all programs look and behave similar to each other, for the specific platform.
Bo Persson
I agree with Bo. In my experience, the majority of complaints I got from my customers about Java UI is its "different" look on Windows. Java UI looks the same on all platforms and it's acceptable by a VERY few people, mostly in the IT department where they maintain different platforms. But for an average user of the application, they are comfortable with the L&F of the machine they use daily and needless to say, most of them are Windows boxes. If Boost UI can adapt to the native L&F it'd be more useful and will be widely accepted. If we decide on one UI for any and all the platforms, we may face a lot of challenges in acceptance. --Suman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Suman Cherukuri wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Bo Persson Sent: Friday, September 30, 2005 10:59 AM To: boost@lists.boost.org Subject: Re: [boost] Reason for Java's Success
"Joel de Guzman" <joel@boost-consulting.com> skrev i meddelandet news:dhjj0q$fq2$1@sea.gmane.org...
David Abrahams wrote:
[snip]
Understood. I apologize for my tone. Still, I simply do not buy this "comfortable with the existing standards" thing. OS vendors, including MS, change the L&F all the time. People adjust quickly unless the L&F is too alien.
No. When I moved from win 95 to XP, I expected the applications to look like XP applications. Those that had the old look-and-feel felt really old and were soon replaced.
For people using only one platform, there is no requirement what so ever to have an application look the same on Windows, Linux, OSX, and Palm OS. There is a requirement that all programs look and behave similar to each other, for the specific platform.
Bo Persson
I agree with Bo. In my experience, the majority of complaints I got from my customers about Java UI is its "different" look on Windows. Java UI looks the same on all platforms and it's acceptable by a VERY few people, mostly in the IT department where they maintain different platforms. But for an average user of the application, they are comfortable with the L&F of the machine they use daily and needless to say, most of them are Windows boxes.
If Boost UI can adapt to the native L&F it'd be more useful and will be widely accepted. If we decide on one UI for any and all the platforms, we may face a lot of challenges in acceptance.
Coming from a Mac background, I used to believe that. Now, I dare say that that way of thinking is passe. Sure, one can opt for consistency. But DON'T force it! There are those who do not agree with the thinking that "you can have any color as long as it is black" anymore. That's the model T way of thinking IMHO. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
From: Joel de Guzman <joel@boost-consulting.com>
Suman Cherukuri wrote:
If Boost UI can adapt to the native L&F it'd be more useful and will be widely accepted. If we decide on one UI for any and all the platforms, we may face a lot of challenges in acceptance.
Coming from a Mac background, I used to believe that. Now, I dare say that that way of thinking is passe. Sure, one can opt for consistency. But DON'T force it! There are those who do not agree with the thinking that "you can have any color as long as it is black" anymore. That's the model T way of thinking IMHO.
Hmmm. Both sides make reasonable points. Gratuitous differences are asking for trouble. Ugly and bland interfaces give the sense of low quality; that's often what I think when I see a Java app. You cited games and WMP in another post. Neither category is ugly or bland (at least when considering modern, high quality games). Still, gratuitous differences cause problems. Some games require one click to select something and another to choose what was selected. Some only respond to the keyboard when choosing an option or making selections, despite supporting the mouse for other things. Those differences are jarring. WMP is highly specialized, so it might be forgiven for looking and acting differently, but when things are not in their usual places, the user must hunt for them, which increases frustration. Some apps don't use the same keyboard shortcuts for the same things. That's frustrating. When they are common things like cut, copy, and paste, the differences can be maddening. My point, then, is that choosing the non-native route must be done carefully or it *will* turn off users. Still, an alternative L&F isn't *necessarily* a turn-off. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart wrote:
My point, then, is that choosing the non-native route must be done carefully or it *will* turn off users. Still, an alternative L&F isn't *necessarily* a turn-off.
Agreed. I don't think anybody actually advocated to do things differently compared to any particular GUI. The question simply was about who will be in control of the decision. In the past developers chose a particular API (*) not only because of its merits in terms of API design, but also because of the visual appeal (or lack thereof) of the GUI itself. It would be great if they could choose boost's GUI for the same reason they would choose other boost libraries, and not getting turned away because they like the 'boost GUI L&F' no matter what that will turn out to be. Other GUI toolkits have shown how to get this right. Regards, Stefan (*) assuming that they did have a choice at all
Rob Stewart wrote:
From: Joel de Guzman <joel@boost-consulting.com>
Suman Cherukuri wrote:
If Boost UI can adapt to the native L&F it'd be more useful and will be widely accepted. If we decide on one UI for any and all the platforms, we may face a lot of challenges in acceptance.
Coming from a Mac background, I used to believe that. Now, I dare say that that way of thinking is passe. Sure, one can opt for consistency. But DON'T force it! There are those who do not agree with the thinking that "you can have any color as long as it is black" anymore. That's the model T way of thinking IMHO.
Hmmm. Both sides make reasonable points. Gratuitous differences are asking for trouble. Ugly and bland interfaces give the sense of low quality; that's often what I think when I see a Java app. You cited games and WMP in another post. Neither category is ugly or bland (at least when considering modern, high quality games). Still, gratuitous differences cause problems.
Yes! My point is that it is not really about following a strict style. The bottomline is usability. Certainly, if I put the vertical scroll bar horizontally, there will be chaos in the streets.
Some games require one click to select something and another to choose what was selected. Some only respond to the keyboard when choosing an option or making selections, despite supporting the mouse for other things. Those differences are jarring.
Agree. Again usability. But then even an app like, say Photoshop, does things differently from one version to the next. The same thing happens when you buy a new car. You spend some time to get used to it.
WMP is highly specialized, so it might be forgiven for looking and acting differently, but when things are not in their usual places, the user must hunt for them, which increases frustration. Some apps don't use the same keyboard shortcuts for the same things. That's frustrating. When they are common things like cut, copy, and paste, the differences can be maddening.
Again agree.
My point, then, is that choosing the non-native route must be done carefully or it *will* turn off users. Still, an alternative L&F isn't *necessarily* a turn-off.
Yes! And that is also my point. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Bo Persson wrote:
"Joel de Guzman" <joel@boost-consulting.com> skrev i meddelandet news:dhjj0q$fq2$1@sea.gmane.org...
David Abrahams wrote:
Joel de Guzman <joel@boost-consulting.com> writes:
Suman Cherukuri wrote:
No offence taken. Whether we like it or not, it's the reality that the majority of the UI users are comfortable with the existing "standards". One can be bold and come up with a whole new design, but as a commercial developer, I'd be really hesitant to change the face of my software just because it's new (and may be better).
This is total nonsense. Even MS switched the L&F when it switched
from Win3.x to Win95/98 to WinXP. No one complains. Are you saying
that *only* MS has the right to change L&F? Or to be more general, is it the sole right of OS vendors to dictate the L&F?
That may be true as a practical matter. I believe Suman was talking about what users will accept, rather than what anyone has "a right" to do.
Understood. I apologize for my tone. Still, I simply do not buy this "comfortable with the existing standards" thing. OS vendors, including MS, change the L&F all the time. People adjust quickly unless the L&F is too alien.
No. When I moved from win 95 to XP, I expected the applications to look like XP applications. Those that had the old look-and-feel felt really old and were soon replaced.
Maybe you haven't played games or used the media player? Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Sorry, I had to reply to this! Arkadiy Vertleyb wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
The builtin GUI is a major reason for Java's Success.
I think the major reason for Java's (commersial) success is that it has _commersial_ forces behind it. As opposed to C++, that is mainly moved forward by academics and enthusiasts.
(I think you mean commercial) You forgot pretty much every industry that needs to have programs that _work_, and quickly, ie. every telephone system in the world has some C++, normally a /LOT/ of it, controlling routing, etc... A large sector of the commercial software industry uses C++ (all of Adobe's programs, for example). If you've played a computer game in the last 5 years, it *was* written in C++. C++ is almost always at or near the top of the list of languages that are being considered to implement a new project. I would die of old age before I could list everyone who uses C++. I'm sure Stroustrup is kicking himself for not making C++ "commercial". Why, he could have 700,000 programmers using C++ *right now*, just like Java (claims)! As opposed to the 1.5 million he currently has.
If we were to make C++ commersially successfull, we would now be developing threads, all kinds of networking, and database access, like crazy. But since we are here mostly to have fun, gain an experience, write articles, etc., we are busy with MPL and PP, lambdas and binders, parsers and regular expressions, foreach and typeof, etc., etc., etc. Things that are cool, and useful for language development, but hardly ever considered when somebody has to decide in which language to implement a distributed concurrent system.
Oh yes, it's nearly /impossible/ to get a database, networking or threading library for C++. And I'm sure no one will ever find a use for parsers or regular expressions. And gosh! MPL! What a waste of time to let the compiler do all the work for you! OK, enough sarcasm. (Don't take it too seriously)
(I hope nobody gets offended. The above libraries are provided for example only, and without any hint to their relative importance)
As for GUI, the last time I saw a portable one, it sucked. Yes, I admit, it was 5 years ago, and it was AWT, so maybe thins changed drammatically? Are modern GUI libraries really able to produce _decent_ cross-platform GUI?
Yep. See other posts here for details. The /real/ reason Java is successful is because they have a pretty good marketing team. They don't try to sell Java to programmers (the last thing we need is yet another language based on C++, but proprietary). Oh no, they sell Java to managers. Having a lot of money to sell it with helps as well. Don't take this the wrong way. All I mean is just because you don't see full page ads for how C++ will help your business in every industry newsletter, doesn't mean it's not doing well. (Although you won't be hard pressed to find PR guys to tell you it's a "legacy" language. I wonder who they work for?) No, I don't make money on C++, apart from programming in the language ;-)
On Fri, 30 Sep 2005 11:53:23 +1200, Simon Buchan wrote
Sorry, I had to reply to this!
Friendly moderation reminder... This list is for discussing Boost libraries -- not C++ versus JAVA. So let's either bring this back on topic or move it elsewhere. Thx, Jeff
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Friendly moderation reminder...
This list is for discussing Boost libraries -- not C++ versus JAVA. So let's either bring this back on topic or move it elsewhere.
Yes, sorry. Regards, Arkadiy
Arkadiy Vertleyb wrote:
"Jeff Garland" <jeff@crystalclearsoftware.com> wrote
Friendly moderation reminder...
This list is for discussing Boost libraries -- not C++ versus JAVA. So let's either bring this back on topic or move it elsewhere.
Yes, sorry.
Same here! (but it was more my fault)
"Simon Buchan" <simon@hand-multimedia.co.nz> wrote
Sorry, I had to reply to this!
No reason to be sorry, really :)
Arkadiy Vertleyb wrote:
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
The builtin GUI is a major reason for Java's Success.
I think the major reason for Java's (commersial) success is that it has _commersial_ forces behind it. As opposed to C++, that is mainly moved forward by academics and enthusiasts.
(I think you mean commercial)
Yes, thanks for correcting me.
You forgot pretty much every industry that needs to have programs that _work_, and quickly, ie. every telephone system in the world has some C++, normally a /LOT/ of it, controlling routing, etc... A large sector of the commercial software industry uses C++ (all of Adobe's programs, for example). If you've played a computer game in the last 5 years, it *was* written in C++. C++ is almost always at or near the top of the list of languages that are being considered to implement a new project. I would die of old age before I could list everyone who uses C++.
I'm sure Stroustrup is kicking himself for not making C++ "commercial". Why, he could have 700,000 programmers using C++ *right now*, just like Java (claims)! As opposed to the 1.5 million he currently has.
If we were to make C++ commersially successfull, we would now be developing threads, all kinds of networking, and database access, like crazy. But since we are here mostly to have fun, gain an experience, write
Right, I didn't "forget" about this. articles,
etc., we are busy with MPL and PP, lambdas and binders, parsers and regular expressions, foreach and typeof, etc., etc., etc. Things that are cool, and useful for language development, but hardly ever considered when somebody has to decide in which language to implement a distributed concurrent system.
Oh yes, it's nearly /impossible/ to get a database, networking or threading library for C++. And I'm sure no one will ever find a use for parsers or regular expressions. And gosh! MPL! What a waste of time to let the compiler do all the work for you!
No, it won't do _all_ the work ;-) Who said anything about "no one will ever find a use" or "waste of time"? All I said was C++ and Java have _fundamentally_ different forces behind them. And, as a result, they move forward in fundamentally different ways. It's great that we have all those libraries I mentioned, and I am honored to be a co-author of one of them. But I also find somewhat disturbing the fact that we still don't have sockets. And we still can't parse URL. And the company I work for uses it's propriatory library for the database access. And etc., etc., etc.
OK, enough sarcasm. (Don't take it too seriously)
(I hope nobody gets offended. The above libraries are provided for example only, and without any hint to their relative importance)
As for GUI, the last time I saw a portable one, it sucked. Yes, I admit, it was 5 years ago, and it was AWT, so maybe thins changed drammatically? Are modern GUI libraries really able to produce _decent_ cross-platform GUI?
Yep. See other posts here for details.
The /real/ reason Java is successful is because they have a pretty good marketing team. They don't try to sell Java to programmers (the last thing we need is yet another language based on C++, but proprietary). Oh no, they sell Java to managers. Having a lot of money to sell it with helps as well.
See, that's exactly what I am talking about. They are businessmen, so they sell what sells and to whom they can sell it. And by doing this they achieve the commercial success. And as a result replace many C++ jobs with Java jobs :-(
Don't take this the wrong way. All I mean is just because you don't see full page ads for how C++ will help your business in every industry newsletter, doesn't mean it's not doing well. (Although you won't be hard pressed to find PR guys to tell you it's a "legacy" language. I wonder who they work for?) No, I don't make money on C++, apart from programming in the language ;-)
And neither do I. Regards, Arkadiy
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
The builtin GUI is a major reason for Java's Success.
I think the major reason for Java's (commersial) success is that it has _commersial_ forces behind it. As opposed to C++, that is mainly moved forward by academics and enthusiasts. Well, commercial people are happy with something that works and has lower cost. It was windows, Java and now may be C#, Linux . So I disagree with u here.
If we were to make C++ commersially successfull, we would now be developing threads, all kinds of networking, and database access, like crazy. But since we are here mostly to have fun, gain an experience, write articles, etc., we are busy with MPL and PP, lambdas and binders, parsers and regular expressions, foreach and typeof, etc., etc., etc. Things that are cool, and useful for language development, but hardly ever considered when somebody has to decide in which language to implement a distributed concurrent system. I completely agree with u here. Its completeness of Java that I like the most. Its really awkward to write half project in C++ and half project
On Thu, 2005-09-29 at 20:06, Arkadiy Vertleyb wrote: that is not supported by lib in C. But may be u are right. Its also the kind of community. GUI can be made in C++, but before that, required thing is to write components. Components which are neither great nor very difficult to write, but are useful in day to day business.
(I hope nobody gets offended. The above libraries are provided for example only, and without any hint to their relative importance)
As for GUI, the last time I saw a portable one, it sucked. Yes, I admit, it was 5 years ago, and it was AWT, so maybe thins changed drammatically? Are modern GUI libraries really able to produce _decent_ cross-platform GUI?
Regards, Arkadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Regards, Tushar -------------------- It's not a problem, it's an opportunity for improvement. Lets improve.
Tushar <tushar@mwti.net> writes: <snip>
has to decide in which language to implement a distributed concurrent system. I completely agree with u here. Its completeness of Java that I like the most. Its really awkward to write half project in C++ and half project
<snip> Please read and abide by http://www.boost.org/more/discussion_policy.htm, particularly http://www.boost.org/more/discussion_policy.htm#quoting and http://www.boost.org/more/discussion_policy.htm#culture Thank you, -- Dave Abrahams Boost Moderator
"David Abrahams" <dave@boost-consulting.com> wrote
"Arkadiy Vertleyb" <vertleyb@hotmail.com> writes:
If we were to make C++ commersially successfull ^^^^
C++ is already quite commercially successful, thank you.
Commercial success is not something done once and for all. My recent visit to monster.com resulted in 50% more links to Java jobs than to C++ jobs. It's dynamics that I hate the most. Consider that a big part of C++ jobs are related to maintanance of huge legacy codebase, and the picture is far from perfect. Since the whole conversation started from Andy's statement that GUI is an important factor of Java's success, I just specified a few other areas where C++ and Boost, IMO, are far behind Java, the areas I consider far more important than GUI. I also couldn't resist to supply my understanding of _why_ the things are in such state. If I did this in inappropriately emotional way, I am sorry. I did not mean to offend anybody, and if I still did, I appologize once again. Regards, Arkadiy
Arkadiy wrote:
Since the whole conversation started from Andy's statement that GUI is an important factor of Java's success, I just specified a few other areas where C++ and Boost, IMO, are far behind Java, the areas I consider far more important than GUI. I also couldn't resist to supply my understanding of _why_ the things are in such state. If I did this in inappropriately emotional way, I am sorry. I did not mean to offend anybody, and if I still did, I appologize once again.
I happen to agree with you, Arkadiy, and share what I think is your idea that C++ in itself is a much better tool for solving problems than bare bone Java. The problem is that Java does not come bare bone. So, what can Boost do in order to create, or encourage the creation of, a "Java-like" library for C++, perhaps without the GUI part, since that is intrinsically hard to make cross-platform, and is not needed for a lot of applications? The C++ Standard will probably never explode into Javaeqsque proportions. But remember that the Java library actually consists of a lot of interfaces as well, where it is up to vendors to implement them - this is especially true with Java 2 Enterprise Edition, obviously. Perhaps the C++ Standard, or at least Boost, could define such API's, but leave the implementation to others? I would definitely love to see proper interfaces for 1. XML Parsing & Output - and perhaps "sample" implementation based on Xerces? 2. Network - yep, it is scary that a language does not come with a proper TCP/IP implementation these days. Even toy languages like Lua do, with a total footprint of 300 kB... 3. Serialization - we have a quite good candidate "in-house", although it is a bit trickier without proper reflection in the language ;-) 4. Regular Expressions - also a good candidate "in-house" 5. Database Access - I personally like the style of DTL So, the Standard (be it C++ Standard or Boost) should define these interfaces, but skip implementations. Boost should, and could, become the Sun of C++ ;-) Some 15 years ago, I was excited to see the abstract streams of C++ and hoped they would provide for the foundation of a lot of "data transfer" applications, such as serialization and SGML. I.e., a realization of Abelson and Sussman's ubiquitous streams. That never came to be. Now we have even more abstract streams and without the type-coupling. Hopefully, we could do better this time. /David
"David W" <David.White.7@gmail.com> writes:
Thanks for the feedback. Being "The most commonly requested new feature for C++ ", I am very surprise that I got only one response (yours). Something doesn't add up.
<snip>lots of quoting Please limit the amount of quoted text, per http://www.boost.org/more/discussion_policy.htm Thank you, -- Dave Abrahams Boost Moderator
Did you intend to respond to me? David "David Abrahams" <dave@boost-consulting.com> wrote in message news:umzlubtcd.fsf_-_@boost-consulting.com...
"David W" <David.White.7@gmail.com> writes:
Thanks for the feedback. Being "The most commonly requested new feature for C++ ", I am very surprise that I got only one response (yours). Something doesn't add up.
<snip>lots of quoting
Please limit the amount of quoted text, per http://www.boost.org/more/discussion_policy.htm
Thank you, -- Dave Abrahams Boost Moderator
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Reece Dunn" <msclrhd@hotmail.com> wrote
I have, as well as many others, have made attempts into this brave new world ;).
I suggest getting the framework right first to allow the support for the GUI/Graphics libraries to be build on top of them.
(1) Platform -- detection for what GUI library is being used; native (GTK?, PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.) or cross-platform (wxWidgets, Qt, etc.) and the platform being used for that cross-platform GUI. This could be an extension to Boost.Config with platform/win32.hpp, platform/wxwidgets.hpp, etc.
(Are all these libraries equivalent? Arent QT and WxWidgets at a higher level than Win32 Api?. Should we also include XWindows in the set of low level libraries. BTW My thoughts on C++ GUI was to implement in parallel on Win32 API and XWindows initially) I'm not at all keen on this approach because it is hugely platform dependent, like wrapping yourself up in sticky mud. Code is never going to be portable. Remember that the ultimate goal is standardisation. There is no standard library that is a wrapper for / or has dependencies on an outside commercial library. I believe that would be unacceptable. The approach I would take is to require a common interface across platforms. Design of a GUI should start from abstract concepts not implementation needs.
(2) String Library -- helpers to interact with native string types (e.g. wxString and ATL::CString) and C++ strings std::[w]string; native version of std::[w]string for platforms that use wide character strings; conversion routines and other helpers.
I would just use std::string. I dont understand why this "native conversion" thing is so important. I dont think it would be acceptable either to standards committes.
This should be one of the goals. It should also be possible to hook into the native code (GTK, wxWidgets, WTL, Win32, PalmOS API, etc.) when/if you want.
This would be easy to do from any given implementation but would just represent a failure of the GUI library to provide the required functionality. regards Andy Little
Andy Little wrote:
I have, as well as many others, have made attempts into this brave new world ;).
I suggest getting the framework right first to allow the support for the GUI/Graphics libraries to be build on top of them.
(1) Platform -- detection for what GUI library is being used; native (GTK?, PalmOS API, Win32 API, etc.), native extension (ATL/WTL, MFC, GDK+, etc.) or cross-platform (wxWidgets, Qt, etc.) and the platform being used for
"Reece Dunn" <msclrhd@hotmail.com> wrote that
cross-platform GUI. This could be an extension to Boost.Config with platform/win32.hpp, platform/wxwidgets.hpp, etc.
(Are all these libraries equivalent? Arent QT and WxWidgets at a higher level than Win32 Api?. Should we also include XWindows in the set of low level libraries. BTW My thoughts on C++ GUI was to implement in parallel on Win32 API and XWindows initially)
I'm not at all keen on this approach because it is hugely platform dependent, like wrapping yourself up in sticky mud. Code is never going to be portable. Remember that the ultimate goal is standardisation. There is no standard library that is a wrapper for / or has dependencies on an outside commercial library. I believe that would be unacceptable. The approach I would take is to require a common interface across platforms. Design of a GUI should start from abstract concepts not implementation needs.
Ok. At the very least it should hook into the platform's low-level API and be able to interact with (if not targetted for) other libraries such as Qt and WTL. I agree that the library should be designed on the abstract level, but it should also be possible to pass a rectangle object to GetClientRect (or the equivalent in Mac, PalmOS, etc.) without having to write a lot of platform-dependant code yourself. This could either be via an extension, or define something like: class geometry::rect { public: /implementation defined/ native(); }; native() -- returns a type that is compatible with the platforms rectangle representation that does native <--> geometry::rect conversions. [--example geometry::rect area; GetClientRect( window.native(), area.native()); std::cout << "window area = " << area << std::endl; --end example] That is, I want it to be easy to interact with Win32, XWindows or Mac code /in a way that is simple for the user/. I would also like the option of using native control/component types (or at least in terms of L&F and usability) as well as a cross platform L&F that Java can produce. Skinnable components at compile time (allowing a run-time skin option). This would allow you to hook into drawing the component type (push button, radio button, tree view), sub-element (expand/collapse on the tree view) and state (hot tracked (mouse over), pressed, inactive/disabled, normal, selected, other). Thus, you could have: template< typename Skin > class button { void draw( canvas & c ) { Skin::draw_item( c, ui::radio, ui::selected, ui::pressed ); } };
(2) String Library -- helpers to interact with native string types (e.g. wxString and ATL::CString) and C++ strings std::[w]string; native version of std::[w]string for platforms that use wide character strings; conversion routines and other helpers.
I would just use std::string. I dont understand why this "native conversion" thing is so important. I dont think it would be acceptable either to standards committes.
The Win32 API can use either wide character or narrow versions. Using the narrow versions on WinNT and above can cause performance issues with the narrow -> wide -> narrow string conversions done by the OS. Therefore, it would be useful to have something like a gui::string that is std::string on narrow character platforms (Win32 built with *A API variants, XWindows, etc.) and std::wstring on wide character platforms (Win32 built with *W API variants). This also has an impact on platform Unicode support. The "native conversion" I was referring to was that you cannot do: std::wstring str( "foo" ); at the moment. std::basic_string< native-character-type > should be the string type of preference.
This should be one of the goals. It should also be possible to hook into the native code (GTK, wxWidgets, WTL, Win32, PalmOS API, etc.) when/if you want.
This would be easy to do from any given implementation but would just represent a failure of the GUI library to provide the required functionality.
Ok. If each type had a native() method (see above), I'd be happy.
"Reece Dunn" <msclrhd@hotmail.com> wrote
Andy Little wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote
I have, as well as many others, have made attempts into this brave new world ;).
I have been looking through your Boost.GUI library , (but only using VC7.1 ... I should delve into X...whatever) I am aware of the problem that windows applications use winMain as a program-entry-point. However in VC7.1 it possible to change this in the Linker > advanced > entry point box. If you use the entry point mainCRTStartup then main will be used as a program entry point. (Then you can change winMain to main in code. I'm not too sure about the way arguments are handled yet but it would be easy to preprocess these before main of course) This solves one problem! I discovered this while reading the VFC documentation. It works fine. FWIW I am thinking of working on your Boost.Gui. One essential difference I would like to make is to try to use the same types on each platform, so for example window sizes would all be in either integers or floats. Ideally they should be templated on each type. What do you thinlk? I might go further and add units (maybe defaulting to pixels) typedef gui::rect<px,int> rect 1; typedef gui::rect<pc,double> rect 2; typedef gui:rect<mm,int> rect 3; IMO from experience this is very powerful and makes coding much easier. Alternatively / as well it might be good to set the transform ( units and ,Wheres (0,0), is +Y up or down, etc ) per window. BTW On the issue of size and point ; The problem with operations specified is that assuming: point p1,p2,p3 operations such as: point result_point = (p1 +p2 +p3)/3; are legal mathematical constructs ( whereas (p1+p2)/3 isnt of course). Thats why Id prefer to go with an entity called vect which stands in for both size and point. (You could make point safe with some runtime overhead I guess) [cut]
I agree that the library should be designed on the abstract level, but it should also be possible to pass a rectangle object to GetClientRect (or the equivalent in Mac, PalmOS, etc.) without having to write a lot of platform-dependant code yourself.
Ok but because you will inevitably be using the platform specific API , this will usually be easy to achieve.
That is, I want it to be easy to interact with Win32, XWindows or Mac code /in a way that is simple for the user/.
Maybe as a plugin.?
I would also like the option of using native control/component types (or at least in terms of L&F and usability) as well as a cross platform L&F that Java can produce. Skinnable components at compile time (allowing a run-time skin option).
[cut] custom L&F is obviously essential. Model-view-controller,Java AWT/ Swing and VFC( mentioned in docs but not read by me yet) are worth looking at regarding L&F. As far as compile time entities is concerned I think they could be very useful e.g : namespace gui{ namespace meta{ ? // colors defaut param for eg num valid bits typedef rgb_color_c<int,255,0,0> red; // taken from SVG struct in; struct mm; struct cm; struct px; struct pt; struct pc; // or vect ;-) template<typename X, typename Y, typename Units> struct point; template <typename TLpoint, typename BRpoint, typename Units> struct rect; // resource handles: template < typename ResourceTag,typename ResourceInfo> struct handle; typedef handle<menu,MyMenu> my_menu; }} //gui::mpl Might even be possible to use this for resource scripts...
The Win32 API can use either wide character or narrow versions. Using the narrow versions on WinNT and above can cause performance issues with the narrow -> wide -> narrow string conversions done by the OS. Therefore, it would be useful to have something like a gui::string that is std::string on narrow character platforms (Win32 built with *A API variants, XWindows, etc.) and std::wstring on wide character platforms (Win32 built with *W API variants).
OK, but even in a word-processing application the amount of text on screen at a time cannot be that big. Is conversion speed that critical?
This also has an impact on platform Unicode support. The "native conversion" I was referring to was that you cannot do:
std::wstring str( "foo" );
Yes thats a problem! Ideally think there should be a Unicode string rather than wstring (VFC, and Java have this!) , meanwhile basic_string<char> is fairly portable. Because there is no console output characteristics defined for wchar one could say that non cahracter output is actually part of the graphics module . The graphics module should be seen as a module with few dependencies so various modules acn be plugged in.
at the moment. std::basic_string< native-character-type > should be the string type of preference.
As you may guess by now I would want the ability to have the same semantics for a type for every platform defined. It is easy then for the user to define native_character_type as a typedef. regards Andy Little
Andy Little wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote
Andy Little wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote
I have, as well as many others, have made attempts into this brave new world ;).
I have been looking through your Boost.GUI library , (but only using VC7.1 ... I should delve into X...whatever) I am aware of the problem that windows applications use winMain as a program-entry-point. However in VC7.1 it possible to change this in the Linker > advanced > entry point box. If you use the entry point mainCRTStartup then main will be used as a program entry point. (Then you can change winMain to main in code. I'm not too sure about the way arguments are handled yet but it would be easy to preprocess these before main of course) This solves one problem! I discovered this while reading the VFC documentation. It works fine.
I am aware of this, but was wondering several things: * main() will create a console window as well as the GUI window :( * is there a simple way to do this without messing with the entry point in all the projects that use Boost.GUI? * you can override the entry point (like is done with the minimum CRT for ATL applications), but will this work with Boost.GUI + normal CRT?
FWIW I am thinking of working on your Boost.Gui. One essential difference I would like to make is to try to use the same types on each platform, so for example window sizes would all be in either integers or floats. Ideally they should be templated on each type. What do you thinlk?
Feel free to modify it as you want :) I have been very busy with work and other things, and working on Boost.GUI isn't a high priority for me at the moment.
I might go further and add units (maybe defaulting to pixels)
typedef gui::rect<px,int> rect 1; typedef gui::rect<pc,double> rect 2; typedef gui:rect<mm,int> rect 3;
That looks great :)!
IMO from experience this is very powerful and makes coding much easier.
Alternatively / as well it might be good to set the transform ( units and ,Wheres (0,0), is +Y up or down, etc ) per window.
Interesting. You could have a windows transform and a mac transform, aliasing that to OS transform.
BTW On the issue of size and point ; The problem with operations specified is that assuming: point p1,p2,p3 operations such as: point result_point = (p1 +p2 +p3)/3; are legal mathematical constructs ( whereas (p1+p2)/3 isnt of course). Thats why Id prefer to go with an entity called vect which stands in for both size and point. (You could make point safe with some runtime overhead I guess)
I would prefer vector over an abbreviation.
I agree that the library should be designed on the abstract level, but it should also be possible to pass a rectangle object to GetClientRect (or the equivalent in Mac, PalmOS, etc.) without having to write a lot of platform-dependant code yourself.
Ok but because you will inevitably be using the platform specific API , this will usually be easy to achieve.
That is, I want it to be easy to interact with Win32, XWindows or Mac code /in a way that is simple for the user/.
Maybe as a plugin.?
What I don't want to do is: gui::vector pt; NSPoint ptNative; CallSomePointFunction( &ptNative ); pt = convert_vector( ptNative ); but: gui::vector pt; CallSomePointFunction( pt.native()); I suppose I could write my own extension to allow: gui::vector pt; CallSomePointFunction( native_point( pt ));
I would also like the option of using native control/component types (or at least in terms of L&F and usability) as well as a cross platform L&F that Java can produce. Skinnable components at compile time (allowing a run-time skin option).
custom L&F is obviously essential. Model-view-controller,Java AWT/ Swing and VFC( mentioned in docs but not read by me yet) are worth looking at regarding L&F.
Indeed.
As far as compile time entities is concerned I think they could be very useful [snip] Might even be possible to use this for resource scripts...
These look great.
The Win32 API can use either wide character or narrow versions. Using the narrow versions on WinNT and above can cause performance issues with the narrow -> wide -> narrow string conversions done by the OS. Therefore, it would be useful to have something like a gui::string that is std::string on narrow character platforms (Win32 built with *A API variants, XWindows, etc.) and std::wstring on wide character platforms (Win32 built with *W API variants).
OK, but even in a word-processing application the amount of text on screen at a time cannot be that big. Is conversion speed that critical?
I am willing to bet that most commercial applications that target WinNT and above are built using the Unicode versions of the API. Saying that they must use the ansi variants instead would make some, if not most, of the companies reluctant to switch to Boost.GUI or the standard C++ GUI. Also, applications that interact with COM will send and receive BSTR strings that are always wide. These applications will most likely be built in Unicode to allow the BSTR strings to be passed to the Win32 API without conversions.
This also has an impact on platform Unicode support. The "native conversion" I was referring to was that you cannot do:
std::wstring str( "foo" );
Yes thats a problem! Ideally think there should be a Unicode string rather than wstring (VFC, and Java have this!) , meanwhile basic_string<char> is fairly portable. Because there is no console output characteristics defined for wchar one could say that non cahracter output is actually part of the graphics module . The graphics module should be seen as a module with few dependencies so various modules acn be plugged in.
Having the string rendering as part of the graphics module is interesting (indeed, the Windows GDI and I assume XWindows et. al. have this as part of the graphics sub-system). There should be the concept of a font. At least it should specify font face (e.g. "Courier New") and size (e.g. font_size< pt >( 12 )).
at the moment. std::basic_string< native-character-type > should be the string type of preference.
As you may guess by now I would want the ability to have the same semantics for a type for every platform defined. It is easy then for the user to define native_character_type as a typedef.
Or an easier option would be to use templates like are dome with the string types: template< typename CharT > struct basic_window { void set_title( const std::basic_string< CharT > & title ); }; Thus, you won't need to use a specific string representation and you get the same semantics on every platform defined that you like :) - Reece
"Reece Dunn" <msclrhd@hotmail.com> wrote in message news:dhove2$jj9$1@sea.gmane.org...
Andy Little wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote
Andy Little wrote:
"Reece Dunn" <msclrhd@hotmail.com> wrote
discovered this while reading the VFC documentation. It works fine.
I am aware of this, but was wondering several things: * main() will create a console window as well as the GUI window :(
If you use the linker flag /SUBSYSTEM:WINDOWS instead of /SUBSYSTEM:console , it doesnt put up a console window. FWIW with these settings args in: int main(int argc,char* argv[]) are valid :-) [cut] FWIW Heres my linker settings /OUT:"Debug/ReeceGui.exe" /INCREMENTAL /NOLOGO /LIBPATH:"XXX\boost_1_33_0\bin\boost\libs\signals\build\libboost_signals.lib\vc-7_1\debug\runtime-link-static" /DEBUG /PDB:"Debug/ReeceGui.pdb" /SUBSYSTEM:WINDOWS /ENTRY:"mainCRTStartup" /MACHINE:X86 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib [cut]
FWIW I am thinking of working on your Boost.Gui. One essential difference I would like to make is to try to use the same types on each platform, so for example window sizes would all be in either integers or floats. Ideally they should be templated on each type. What do you thinlk?
Feel free to modify it as you want :) I have been very busy with work and other things, and working on Boost.GUI isn't a high priority for me at the moment.
Shame I dont think I'll get much done in the near future either:-( .. What I really need is to get it running on Linux/Unix and Mac I guess...
I might go further and add units (maybe defaulting to pixels)
typedef gui::rect<px,int> rect 1; typedef gui::rect<pc,double> rect 2; typedef gui:rect<mm,int> rect 3;
That looks great :)!
I'd better get own with it then... ;-)
IMO from experience this is very powerful and makes coding much easier.
Alternatively / as well it might be good to set the transform ( units and ,Wheres (0,0), is +Y up or down, etc ) per window.
Interesting. You could have a windows transform and a mac transform, aliasing that to OS transform.
Thats it! so it defaults to the same settings on each platform. Up is always up etc.. and you can set a Text (y goes down etc) or Graphics mode.
BTW On the issue of size and point ; The problem with operations specified is that assuming: point p1,p2,p3 operations such as: point result_point = (p1 +p2 +p3)/3; are legal mathematical constructs ( whereas (p1+p2)/3 isnt of course). Thats why Id prefer to go with an entity called vect which stands in for both size and point. (You could make point safe with some runtime overhead I guess)
I would prefer vector over an abbreviation.
hmm .. Ok, I guess users can change it if they wish. Anyway you seem to approve in principle ? I currently use a namespace called two_d e.g two_d::vector<..> .
I agree that the library should be designed on the abstract level, but it should also be possible to pass a rectangle object to GetClientRect (or the equivalent in Mac, PalmOS, etc.) without having to write a lot of platform-dependant code yourself.
Ok but because you will inevitably be using the platform specific API , this will usually be easy to achieve.
That is, I want it to be easy to interact with Win32, XWindows or Mac code /in a way that is simple for the user/.
Maybe as a plugin.?
What I don't want to do is:
gui::vector pt; NSPoint ptNative; CallSomePointFunction( &ptNative ); pt = convert_vector( ptNative );
but:
gui::vector pt; CallSomePointFunction( pt.native());
I suppose I could write my own extension to allow:
gui::vector pt; CallSomePointFunction( native_point( pt ));
Ok.. I guess the idea is that it should work with existing code?(See below about incorporating it into C++ standard) [cut]
As far as compile time entities is concerned I think they could be very useful [snip] Might even be possible to use this for resource scripts...
These look great.
Thanks! [cut]
I am willing to bet that most commercial applications that target WinNT and above are built using the Unicode versions of the API. Saying that they must use the ansi variants instead would make some, if not most, of the companies reluctant to switch to Boost.GUI or the standard C++ GUI.
I'm looking in terms of overtaking the competition...erhh ..hmm gradually ;-) My first target audience for this would be C++ newcomers.
Also, applications that interact with COM will send and receive BSTR strings that are always wide. These applications will most likely be built in Unicode to allow the BSTR strings to be passed to the Win32 API without conversions.
Ok... but is this actually the GUIs responsibility? Cant system calls be used without a GUI .? (Ok They are generally bundled in). However the standard doesnt understand the concept of interprocess communication( or does it?) . If possible I would like to keep the thing as lightweight as possible The goal is a minmal GUI that can be incorporated in the standard for "basic GUI functionality". Providing a rigorous specification for even that would be a huge amount of work. I guess this is why I'm not getting too worried about os specifics except to hide them.. I think they would be 'implementation defined" in the standard. [cut]
Having the string rendering as part of the graphics module is interesting (indeed, the Windows GDI and I assume XWindows et. al. have this as part of the graphics sub-system). There should be the concept of a font. At least it should specify font face (e.g. "Courier New") and size (e.g. font_size< pt >( 12 )).
Yes. There are a large range of fonts about to take inspiration from! Anyway this would be part of the graphics sub-system (Though default font is bound up with L&F of course). [cut]
Or an easier option would be to use templates like are dome with the string types:
template< typename CharT > struct basic_window { void set_title( const std::basic_string< CharT > & title ); };
Thus, you won't need to use a specific string representation and you get the same semantics on every platform defined that you like :)
Thats sounds good. Thats whad I like ! regards Andy Little
Reece Dunn <msclrhd@hotmail.com> writes:
I might go further and add units (maybe defaulting to pixels)
typedef gui::rect<px,int> rect 1; typedef gui::rect<pc,double> rect 2; typedef gui:rect<mm,int> rect 3;
That looks great :)!
Am I insane or is that not legal C++ code? Or both? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Reece Dunn <msclrhd@hotmail.com> writes:
I might go further and add units (maybe defaulting to pixels)
typedef gui::rect<px,int> rect 1; typedef gui::rect<pc,double> rect 2; typedef gui:rect<mm,int> rect 3;
That looks great :)!
Am I insane or is that not legal C++ code? Or both?
I was assuming Andy meant typedef gui::rect< px, int > rect1; not typedef gui::rect< px, int > rect 1; The former is legal C++, but the latter isn't. I was commenting on the intent, i.e. the gui::rect< pc, float > part. As to whether or not you are insane, I am not qualified to judge ;). - Reece
I might go further and add units (maybe defaulting to pixels)
typedef gui::rect<px,int> rect 1; typedef gui::rect<pc,double> rect 2; typedef gui:rect<mm,int> rect 3;
That looks great :)!
I disagree. I think you should stick to only one type (probably float for now, and eventually allow overriding it -- but, use this consistently throughout the app). Just think of the many places you'll need to deal with geometry (rectangle/point/size), and converting from one type of unit (px to cm, cm to in, etc) to another. And, about usability in code. Why would I want in my program, both: gui::rect<pc,double> and gui::rect<pc,int> ? This IMHO would confuse users of the library. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
John Torjo wrote:
And, about usability in code. Why would I want in my program, both: gui::rect<pc,double> and gui::rect<pc,int> ? This IMHO would confuse users of the library.
I would think that floats make the most sense for percentage based rectangles, while ints make the most sense for absolute pixel position based rectangles. So perhaps something like the following might be appropriate? struct px { typedef int pos_type; }; struct pc { typedef float pos_type; }; gui::rect < px > rect1; gui::rect < pc > rect2; -Jason
"John Torjo" <john.lists@torjo.com> wrote in message news:43426645.30304@torjo.com...
I might go further and add units (maybe defaulting to pixels)
typedef gui::rect<px,int> rect 1; typedef gui::rect<pc,double> rect 2; typedef gui:rect<mm,int> rect 3;
That looks great :)!
I disagree. I think you should stick to only one type (probably float for now, and eventually allow overriding it -- but, use this consistently throughout the app).
With all due respect users wont like having one style forced on them. Making the value_type a template is trivial.
Just think of the many places you'll need to deal with geometry (rectangle/point/size), and converting from one type of unit (px to cm, cm to in, etc) to another.
It seems like you are suggesting that users will go mad and use arbitrary units all over the place just for the fun of it. I would guess that most developers will use one unit that they are comfortable with. Conversion is common where units are chosen by the application user . Most conversions would be to - from pixels. Typically its the Americans ask to work in inches. Its actually trivial to convert anyway. I dont really see what the fuss is about.
And, about usability in code. Why would I want in my program, both: gui::rect<pc,double> and gui::rect<pc,int> ? This IMHO would confuse users of the library.
If you work in percent then usually you are happy with the granularity as an integer between 0 and 100. Why use a float.? Actually I would also like to have another unit which normalised the window dimensions to x= 1. and y =1. Floats would make perfect sense then. regards Andy Little
John Torjo wrote:
I might go further and add units (maybe defaulting to pixels)
typedef gui::rect<px,int> rect 1; typedef gui::rect<pc,double> rect 2; typedef gui:rect<mm,int> rect 3;
That looks great :)!
I disagree. I think you should stick to only one type (probably float for now, and eventually allow overriding it -- but, use this consistently throughout the app).
Just think of the many places you'll need to deal with geometry (rectangle/point/size), and converting from one type of unit (px to cm, cm to in, etc) to another.
I agree. In particular, I'd strongly suggest to draw a clear distinction between physical dimension and resolution. Most current GUIs did get that wrong, I believe in that they conditioned us all to think of size when talking about number of pixels. The consequence is similar to the Y2K bug: applications won't easily adapt to displays with different resolutions (well, may be within a narrow range), and so a lot of efford is needed on a high (application) level to compensate for that lack of abstraction. Let's hope that in the not-so-distant future 'pixel' will be an artefact of graphic / video card drivers and not be exposed to an API at all. Regards, Stefan
Stefan Seefeld wrote:
Just think of the many places you'll need to deal with geometry (rectangle/point/size), and converting from one type of unit (px to cm, cm to in, etc) to another.
I agree. In particular, I'd strongly suggest to draw a clear distinction between physical dimension and resolution. Most current GUIs did get that wrong, I believe in that they conditioned us all to think of size when talking about number of pixels.
The consequence is similar to the Y2K bug: applications won't easily adapt to displays with different resolutions (well, may be within a narrow range), and so a lot of efford is needed on a high (application) level to compensate for that lack of abstraction.
Can you elaborate on this? For explicit 2D graphics "pixel" is already just a convention, since you can scale that as you like. And for window layout, well, you should not do manual window layout at all. GUI library should select font size and other things, and everything will be laid out. What problems do you have in mind? - Volodya
Vladimir Prus wrote:
I agree. In particular, I'd strongly suggest to draw a clear distinction between physical dimension and resolution. Most current GUIs did get that wrong, I believe in that they conditioned us all to think of size when talking about number of pixels.
The consequence is similar to the Y2K bug: applications won't easily adapt to displays with different resolutions (well, may be within a narrow range), and so a lot of efford is needed on a high (application) level to compensate for that lack of abstraction.
Can you elaborate on this? For explicit 2D graphics "pixel" is already just a convention, since you can scale that as you like. And for window layout, well, you should not do manual window layout at all. GUI library should select font size and other things, and everything will be laid out. What problems do you have in mind?
Sizes are usually given in resolution-dependent coordinates (i.e. pixels). If you change resolution, you typically don't do that to expose more detail, but to make your desktop 'bigger' (by making text, widgets, etc. smaller). If 'pixel' is only a convention that isn't related to device coordinates, great. Still, 'pixels' have a physical size of their own that varies between devices. I think it would be best to remove this degree of freedom, or at least, be explicit about when the user (GUI developer) is operating in device coordinates and when he is not. Regards, Stefan
Stefan Seefeld wrote:
Can you elaborate on this? For explicit 2D graphics "pixel" is already just a convention, since you can scale that as you like. And for window layout, well, you should not do manual window layout at all. GUI library should select font size and other things, and everything will be laid out. What problems do you have in mind?
Sizes are usually given in resolution-dependent coordinates (i.e. pixels). If you change resolution, you typically don't do that to expose more detail, but to make your desktop 'bigger' (by making text, widgets, etc. smaller).
If 'pixel' is only a convention that isn't related to device coordinates, great. Still, 'pixels' have a physical size of their own that varies between devices. I think it would be best to remove this degree of freedom, or at least, be explicit about when the user (GUI developer) is operating in device coordinates and when he is not.
Let me try from a different angle. There's some settings made by user, like font size, or toolbar icon size. The unit does not matter there. I believe that in a good GUI library, you should not ever need to use any dimensions for windows dimensions, but just allow the layout code in the library to take care of this. And since you don't have to specify dimensions, it does not matter if they are in pixels or not. So, it looks like the only place where coordinate unit choice makes a difference makes difference is explicit 2D graphics (drawing lines, circles and the like). Do we agree so far? I'm just trying to narrow down the scope of discussion. It just don't not make sense, IMO, to have a choice of coordinate unit for mouse press event. - Volodya
Vladimir Prus wrote:
Let me try from a different angle. There's some settings made by user, like font size, or toolbar icon size. The unit does not matter there.
I'm not sure I understand what you mean by 'unit' here. Imagine you want to print a portion of the screen. Do you expect dimensions to be preserved on paper or not ? I do.
I believe that in a good GUI library, you should not ever need to use any dimensions for windows dimensions, but just allow the layout code in the library to take care of this. And since you don't have to specify dimensions, it does not matter if they are in pixels or not.
What you describe is true for 'non-terminals' in the tree only. All leaf nodes (glyphs, icons, but also some part of the widgets themselves, such as bevels, slider and scrollbar handles, etc., etc.) do need their own size.
So, it looks like the only place where coordinate unit choice makes a difference makes difference is explicit 2D graphics (drawing lines, circles and the like).
Ok, if you read 'only' appropriately. :-)
Do we agree so far? I'm just trying to narrow down the scope of discussion. It just don't not make sense, IMO, to have a choice of coordinate unit for mouse press event.
I think we are in violent agreement. Mouse events are reported in the coordinate system of the target region (window, widget, surface, whatever you name it). All I'm saying is that this coordinate system should reflect physical size, i.e. be independent from device-space coordinates. Unfortunately, traditionally GUIs are tied to a particular device and thus it is custom to express coordinates in the device's own coordinate system. Regards, Stefan
Stefan Seefeld wrote:
Vladimir Prus wrote:
Let me try from a different angle. There's some settings made by user, like font size, or toolbar icon size. The unit does not matter there.
I'm not sure I understand what you mean by 'unit' here. Imagine you want to print a portion of the screen. Do you expect dimensions to be preserved on paper or not ? I do.
Physical dimenstions? In millimeters? Then I don't expect this. Say the program shows a chart in a window. It's natural to print that chart to occupy full size of A4 paper (if A4 is the current paper size), or have page layout customizable.
I believe that in a good GUI library, you should not ever need to use any dimensions for windows dimensions, but just allow the layout code in the library to take care of this. And since you don't have to specify dimensions, it does not matter if they are in pixels or not.
What you describe is true for 'non-terminals' in the tree only. All leaf nodes (glyphs, icons, but also some part of the widgets themselves, such as bevels, slider and scrollbar handles, etc., etc.) do need their own size.
Right, but those sizes should be configurable by user and never tweaked by developer. The logic in the library to determine slider width, for example, might be complicated, but it should be inside library. Do you ever needed to explicitly set scrollbar width?
So, it looks like the only place where coordinate unit choice makes a difference makes difference is explicit 2D graphics (drawing lines, circles and the like).
Ok, if you read 'only' appropriately. :-)
Do we agree so far? I'm just trying to narrow down the scope of discussion. It just don't not make sense, IMO, to have a choice of coordinate unit for mouse press event.
I think we are in violent agreement. Mouse events are reported in the coordinate system of the target region (window, widget, surface, whatever you name it). All I'm saying is that this coordinate system should reflect physical size, i.e. be independent from device-space coordinates. Unfortunately, traditionally GUIs are tied to a particular device and thus it is custom to express coordinates in the device's own coordinate system.
But this does not cause any problems I know about. If you know about any problems, please tell! Say mouse events coordinates are mostly usefull for testing which object mouse is over, or for positioning popup menu, or something like that. In those cases, using device coordinates are OK. - Volodya
Vladimir Prus wrote:
Stefan Seefeld wrote:
Vladimir Prus wrote:
Let me try from a different angle. There's some settings made by user, like font size, or toolbar icon size. The unit does not matter there.
I'm not sure I understand what you mean by 'unit' here. Imagine you want to print a portion of the screen. Do you expect dimensions to be preserved on paper or not ? I do.
Physical dimenstions? In millimeters? Then I don't expect this. Say the program shows a chart in a window. It's natural to print that chart to occupy full size of A4 paper (if A4 is the current paper size), or have page layout customizable.
I don't quite understand what you are saying. There are certainly graphical objects without an intrinsic (physical) size that can scale to whatever region is available.
I believe that in a good GUI library, you should not ever need to use any dimensions for windows dimensions, but just allow the layout code in the library to take care of this. And since you don't have to specify dimensions, it does not matter if they are in pixels or not.
What you describe is true for 'non-terminals' in the tree only. All leaf nodes (glyphs, icons, but also some part of the widgets themselves, such as bevels, slider and scrollbar handles, etc., etc.) do need their own size.
Right, but those sizes should be configurable by user and never tweaked by developer. The logic in the library to determine slider width, for example, might be complicated, but it should be inside library. Do you ever needed to explicitly set scrollbar width?
These sizes are typically determined by the GUI designer. They may or may not be configurable by users. My point is that don't want 'screen resolution' to interfer with them either. Users may scale ('zoom') the whole GUI to adjust it to their eyes.
I think we are in violent agreement. Mouse events are reported in the coordinate system of the target region (window, widget, surface, whatever you name it). All I'm saying is that this coordinate system should reflect physical size, i.e. be independent from device-space coordinates. Unfortunately, traditionally GUIs are tied to a particular device and thus it is custom to express coordinates in the device's own coordinate system.
But this does not cause any problems I know about. If you know about any problems, please tell! Say mouse events coordinates are mostly usefull for testing which object mouse is over, or for positioning popup menu, or something like that. In those cases, using device coordinates are OK.
Device coordinates are not ok to determine object size, because that means that objects have differing sizes on different output devices (multiple screens, printers, etc.) and so users wrongly tweak resolution to get back their wanted object sizes. Regards, Stefan
Stefan Seefeld wrote:
I'm not sure I understand what you mean by 'unit' here. Imagine you want to print a portion of the screen. Do you expect dimensions to be preserved on paper or not ? I do.
Physical dimenstions? In millimeters? Then I don't expect this. Say the program shows a chart in a window. It's natural to print that chart to occupy full size of A4 paper (if A4 is the current paper size), or have page layout customizable.
I don't quite understand what you are saying. There are certainly graphical objects without an intrinsic (physical) size that can scale to whatever region is available.
Then I don't understand what you said before. You said you expect that printing of portion of screen should preserve dimenstions. Do you mean dimensions in millmeters or in what unit? And why do you expect for them to be preserved on paper?
What you describe is true for 'non-terminals' in the tree only. All leaf nodes (glyphs, icons, but also some part of the widgets themselves, such as bevels, slider and scrollbar handles, etc., etc.) do need their own size.
Right, but those sizes should be configurable by user and never tweaked by developer. The logic in the library to determine slider width, for example, might be complicated, but it should be inside library. Do you ever needed to explicitly set scrollbar width?
These sizes are typically determined by the GUI designer.
Who is, or what is "GUI designer". A human designing program, and human writing library, or a tool for designing GUIs? In which OS, or GUI library, the width of scrollbar is easily configurable?
They may or may not be configurable by users. My point is that don't want 'screen resolution' to interfer with them either. Users may scale ('zoom') the whole GUI to adjust it to their eyes.
Maybe we look from different angles. I think that application writers should not care about this. The GUI library sets the size of main windows, and the size may in any unit it likes. The application will then adjust all child windows in due *proportion* to the main window size and draw content. The display on monitor is done by GUI library, so it scales content as it likes. The model only breaks with bitmap images, but well, that's not fixable.
I think we are in violent agreement. Mouse events are reported in the coordinate system of the target region (window, widget, surface, whatever you name it). All I'm saying is that this coordinate system should reflect physical size, i.e. be independent from device-space coordinates. Unfortunately, traditionally GUIs are tied to a particular device and thus it is custom to express coordinates in the device's own coordinate system.
But this does not cause any problems I know about. If you know about any problems, please tell! Say mouse events coordinates are mostly usefull for testing which object mouse is over, or for positioning popup menu, or something like that. In those cases, using device coordinates are OK.
Device coordinates are not ok to determine object size, because that means that objects have differing sizes on different output devices (multiple screens, printers, etc.) and so users wrongly tweak resolution to get back their wanted object sizes.
You should never specify object size at all. The size of main window should be set the GUI library, or set as proportion of screen size. The child windows should be laid out by GUI or resizes as proportion of main windows size. So, you don't care what unit is used, since you never specify absolute sizes. So, I believe that the ideal coordinate system unit is nothing more that "int". - Volodya
Vladimir Prus wrote:
Stefan Seefeld wrote:
Device coordinates are not ok to determine object size, because that means that objects have differing sizes on different output devices (multiple screens, printers, etc.) and so users wrongly tweak resolution to get back their wanted object sizes.
You should never specify object size at all. The size of main window should be set the GUI library, or set as proportion of screen size. The child windows should be laid out by GUI or resizes as proportion of main windows size. So, you don't care what unit is used, since you never specify absolute sizes.
I think you are mising each other by miles. Volodya, as much as I want to and tried to, I can't understand what you are trying to say.
So, I believe that the ideal coordinate system unit is nothing more that "int".
For vector graphics, that would be float/double (or fixed-point). Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Vladimir Prus wrote:
Stefan Seefeld wrote:
Device coordinates are not ok to determine object size, because that means that objects have differing sizes on different output devices (multiple screens, printers, etc.) and so users wrongly tweak resolution to get back their wanted object sizes.
You should never specify object size at all. The size of main window should be set the GUI library, or set as proportion of screen size. The child windows should be laid out by GUI or resizes as proportion of main windows size. So, you don't care what unit is used, since you never specify absolute sizes.
I think you are mising each other by miles. Volodya, as much as I want to and tried to, I can't understand what you are trying to say.
I'm trying to say that the choice of coordinate unit -- pixel, millimeter, inch, whatever, is only important if you need to write: window.setWidth(10cm); and in a proper GUI library you should never set width to absolute value like that. Instead, you should do: window.setWidth(screen_width()*some_constant); In that case "screen_width()" can return SomeVeryOpaqueType that you can multiply by float, but can't convert to pixel, or to to inch, or to anything else.
So, I believe that the ideal coordinate system unit is nothing more that "int".
For vector graphics, that would be float/double (or fixed-point).
Well, for SVG it's already float, and we can't change that part. Still I'm not sure why float is a good idea for drawing operations in a GUI library. - Volodya
Vladimir Prus wrote:
I'm trying to say that the choice of coordinate unit -- pixel, millimeter, inch, whatever, is only important if you need to write:
window.setWidth(10cm);
and in a proper GUI library you should never set width to absolute value like that. Instead, you should do:
window.setWidth(screen_width()*some_constant);
In that case "screen_width()" can return SomeVeryOpaqueType that you can multiply by float, but can't convert to pixel, or to to inch, or to anything else.
I don't quite agree. From an ergonomic point of view it doesn't make sense to preserve the screen content no matter how large the screen is. At least, if the application's GUI is to scale, it is the *user* who should do that explicitely, not the developer. I agree though that absolute sizes are mostly used in leaf nodes in the 'scene graph', and all composites adjust to their children (using various layout algorithms to gain flexibility). Regards, Stefan
Stefan Seefeld wrote:
Vladimir Prus wrote:
I'm trying to say that the choice of coordinate unit -- pixel, millimeter, inch, whatever, is only important if you need to write:
window.setWidth(10cm);
and in a proper GUI library you should never set width to absolute value like that. Instead, you should do:
window.setWidth(screen_width()*some_constant);
In that case "screen_width()" can return SomeVeryOpaqueType that you can multiply by float, but can't convert to pixel, or to to inch, or to anything else.
I don't quite agree. From an ergonomic point of view it doesn't make sense to preserve the screen content no matter how large the screen is.
Well, at least there are application that have no use for extra size (say, instant messaging), and some which can use all the space you give them (say, IDE). It would be good if size of top-level windows were laid out using an algorithm similar to the one that lays out children. Then you won't have to set even relative width/height of top-level windows.
At least, if the application's GUI is to scale, it is the *user* who should do that explicitely, not the developer.
In most cases, yes.
I agree though that absolute sizes are mostly used in leaf nodes in the 'scene graph', and all composites adjust to their children (using various layout algorithms to gain flexibility).
There's bidirectional adjustment, generally. But that's a detail. - Volodya
Vladimir Prus wrote:
I'm trying to say that the choice of coordinate unit -- pixel, millimeter, inch, whatever, is only important if you need to write:
window.setWidth(10cm);
and in a proper GUI library you should never set width to absolute value like that. Instead, you should do:
window.setWidth(screen_width()*some_constant);
In that case "screen_width()" can return SomeVeryOpaqueType that you can multiply by float, but can't convert to pixel, or to to inch, or to anything else.
Hmmmm.... I'm not sure about this. Say for example that I am writing a WYSIWYG CAD application and I'd like to draw vertical and horizontal rulers. At 100% page view, I'd like the ruler to be a 1:1 with the actual screen at the designated resolution (say 72 DPI). How would I draw my ruler if the coordinates are abstracted in terms of percentage? (Aside: I'd want my app to remain consistent when in the future we get 200 DPI screens, BTW). IMO, we should choose one representation and one unit. In my mind, that would be float and millimeter (in addition to percentages). Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Joel de Guzman wrote:
Vladimir Prus wrote:
I'm trying to say that the choice of coordinate unit -- pixel, millimeter, inch, whatever, is only important if you need to write:
window.setWidth(10cm);
and in a proper GUI library you should never set width to absolute value like that. Instead, you should do:
window.setWidth(screen_width()*some_constant);
In that case "screen_width()" can return SomeVeryOpaqueType that you can multiply by float, but can't convert to pixel, or to to inch, or to anything else.
Hmmmm....
I'm not sure about this. Say for example that I am writing a WYSIWYG CAD application and I'd like to draw vertical and horizontal rulers. At 100% page view, I'd like the ruler to be a 1:1 with the actual screen at the designated resolution (say 72 DPI). How would I draw my ruler if the coordinates are abstracted in terms of percentage?
You mean the the rule has millimeters as the unit an at 1:1 zoom you want 1 millimeter of the ruler to be 1 millimeter on the screen? Then yes, you'll need some way to convert millimetres to units used on screen. Though I don't understand why you want such strict equality. You won't measure distances on the screen with a physical ruler anyway, right? - Volodya
Vladimir Prus wrote:
Joel de Guzman wrote:
I'm not sure about this. Say for example that I am writing a WYSIWYG CAD application and I'd like to draw vertical and horizontal rulers. At 100% page view, I'd like the ruler to be a 1:1 with the actual screen at the designated resolution (say 72 DPI). How would I draw my ruler if the coordinates are abstracted in terms of percentage?
You mean the the rule has millimeters as the unit an at 1:1 zoom you want 1 millimeter of the ruler to be 1 millimeter on the screen? Then yes, you'll need some way to convert millimetres to units used on screen. Though I don't understand why you want such strict equality. You won't measure distances on the screen with a physical ruler anyway, right?
Yes ! I think that's exactly the point. If the user doesn't *explicitely* set a different scale, an object's physical size expresses how it wants to be rendered on the output device. Why should users ever have to think about 'device coordinates' ? Regards, Stefan
Vladimir Prus wrote:
Joel de Guzman wrote:
Vladimir Prus wrote:
I'm trying to say that the choice of coordinate unit -- pixel, millimeter, inch, whatever, is only important if you need to write:
window.setWidth(10cm);
and in a proper GUI library you should never set width to absolute value like that. Instead, you should do:
window.setWidth(screen_width()*some_constant);
In that case "screen_width()" can return SomeVeryOpaqueType that you can multiply by float, but can't convert to pixel, or to to inch, or to anything else.
Hmmmm....
I'm not sure about this. Say for example that I am writing a WYSIWYG CAD application and I'd like to draw vertical and horizontal rulers. At 100% page view, I'd like the ruler to be a 1:1 with the actual screen at the designated resolution (say 72 DPI). How would I draw my ruler if the coordinates are abstracted in terms of percentage?
You mean the the rule has millimeters as the unit an at 1:1 zoom you want 1 millimeter of the ruler to be 1 millimeter on the screen? Then yes, you'll need some way to convert millimetres to units used on screen. Though I don't understand why you want such strict equality. You won't measure distances on the screen with a physical ruler anyway, right?
Why not ;-) ? Replace "screen" with "paper" and you'll want to have accurate 1:1 layouts. This is the very essence of device independence. If, say, I want to print a PCB (printed circuit board) on a 300DPI laser printer, I'd want absolute accuracy, otherwise, my components will not fit the holes. Device independence means that both "screen" and "paper" should behave identically. If I want 10cm on paper how can I create such a thing in an abstracted relative coordinate system? Bottom line: you'll want both absolute and relative dimensions. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
"Joel" == Joel de Guzman <joel@boost-consulting.com> writes: > Why not ;-) ? Replace "screen" with "paper" and you'll want to > have accurate 1:1 layouts. This is the very essence of device > independence. If, say, I want to print a PCB (printed circuit > board) on a 300DPI laser printer, I'd want absolute accuracy, > otherwise, my components will not fit the holes. Device > independence means that both "screen" and "paper" should behave > identically. If I want 10cm on paper how can I create such a > thing in an abstracted relative coordinate system?
But you aren't going to draw a PCB on screen with boost.GUI widgets. Neither is it very likely that someone needs to print a copy of some on-screen dialog, in WYSIWYG manner. So yes, the underlying (vector) graphic library should handle a whole collection of units and transformations. But widgets and the layout engine generally don't care about units. In the rare cases that they do, (e.g. you want a ruler widget exactly 10cm long) you can always use the graphic library to transform among units. Regards, Jin
Liu Jin wrote:
But you aren't going to draw a PCB on screen with boost.GUI widgets.
Why shouldn't a good GUI library be prepared for that use case? m Send instant messages to your online friends http://au.messenger.yahoo.com
"Liu Jin" <cpp@vip.163.com> wrote
But you aren't going to draw a PCB on screen with boost.GUI widgets.
FWIW I have used my pc to design and print uv masks for pcbs on to film via a laser printer. It works fine and is very accurate for prototyping.
Neither is it very likely that someone needs to print a copy of some on-screen dialog, in WYSIWYG manner.
Its quite common to use screenshots of dialogs in help files. FWIW a help system is an integral part of the GUI which hasnt been discussed. I would guess it should use html. regards Andy Little
Liu Jin wrote:
"Joel" == Joel de Guzman <joel@boost-consulting.com> writes:
> Why not ;-) ? Replace "screen" with "paper" and you'll want to > have accurate 1:1 layouts. This is the very essence of device > independence. If, say, I want to print a PCB (printed circuit > board) on a 300DPI laser printer, I'd want absolute accuracy, > otherwise, my components will not fit the holes. Device > independence means that both "screen" and "paper" should behave > identically. If I want 10cm on paper how can I create such a > thing in an abstracted relative coordinate system?
But you aren't going to draw a PCB on screen with boost.GUI widgets. Neither is it very likely that someone needs to print a copy of some on-screen dialog, in WYSIWYG manner.
So yes, the underlying (vector) graphic library should handle a whole collection of units and transformations. But widgets and the layout engine generally don't care about units. In the rare cases that they do, (e.g. you want a ruler widget exactly 10cm long) you can always use the graphic library to transform among units.
Have you read the Fresco doc that Stefan gave a link to? The point is that life would be sooo much better if there is no distinction between a "widget" and a "graphic". Think abstraction and genericity! Here's the relevant quote: ''' Conventional windowing environments provide separate classes of objects for user interface components, or “widgets,” and graphical objects. Widgets negotiate layout and can be resized as rectangles, while graphics may be shared (not just strictly hierarchical) transformed, transparent, and overlaid. This presents a major obstacle to applications like user interface builders and compound document editors where the manipulated objects need to behave both like graphics and widgets. Fresco[1] blends graphics and widgets into a single class of objects. We have an implementation of Fresco and an editor called Fdraw that allows graphical objects to be composed like widgets and widgets to be transformed and shared like graphics. Performance measurements of Fdraw show that sharing reduces memory usage without slowing down redisplay. ''' Back in the mid 90s, I wrote a GUI framework inspired by Fresco. As a proof of concept, I used the layouting capabilities to render HTML (images, text flows, tables, lists, buttons, etc). An html page is a hierarchical composition of active objects. The result was awesome! Because of genericity, sharing and reuse, the rendering engine's application footprint was constant. I never had to write any special classes and instead relied solely on object composition to compose a complex graphical entity. The only thing I had to write was the HTML parser with semantic actions that composed the page (ahh yes.. and that's how spirit came to be...) Now imagine... what if the same facility can be reused to create your toolbars, menus, dialogs, etc. Imagine for instance--- creaing a dialog using an XML script. Creating a whole application, for that matter, from XML. Then... attaching the "semantic actions" to your business code. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On Thursday 06 October 2005 02:07, Joel de Guzman wrote:
Now imagine... what if the same facility can be reused to create your toolbars, menus, dialogs, etc. Imagine for instance--- creaing a dialog using an XML script. Creating a whole application, for that matter, from XML. Then... attaching the "semantic actions" to your business code.
If I'm not mistaken, this is at least part of the idea behind Mozilla XUL. --- regards Bjørn Roald
Have you read the Fresco doc that Stefan gave a link to? The point is that life would be sooo much better if there is no distinction between a "widget" and a "graphic". Think abstraction and genericity! Here's the relevant quote:
Yes, this sounds very cool! I do think, however, that there should be a distinction between widget and graphic -- that is, the widget contains the logic, while the graphic(s) draw the UI. This is how I've implemented surfaces. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
John Torjo wrote:
Have you read the Fresco doc that Stefan gave a link to? The point is that life would be sooo much better if there is no distinction between a "widget" and a "graphic". Think abstraction and genericity! Here's the relevant quote:
Yes, this sounds very cool!
I do think, however, that there should be a distinction between widget and graphic -- that is, the widget contains the logic, while the graphic(s) draw the UI. This is how I've implemented surfaces.
What about a model-view-controller alike separation ? In Fresco you'd create a widget through a 'WidgetKit', passing it a model to bind to, and would obtain a compound graphic that is a nice citizen of the scene graph. Regards, Stefan
Joel de Guzman wrote:
I'm not sure about this. Say for example that I am writing a WYSIWYG CAD application and I'd like to draw vertical and horizontal rulers. At 100% page view, I'd like the ruler to be a 1:1 with the actual screen at the designated resolution (say 72 DPI). How would I draw my ruler if the coordinates are abstracted in terms of percentage?
You mean the the rule has millimeters as the unit an at 1:1 zoom you want 1 millimeter of the ruler to be 1 millimeter on the screen? Then yes, you'll need some way to convert millimetres to units used on screen. Though I don't understand why you want such strict equality. You won't measure distances on the screen with a physical ruler anyway, right?
Why not ;-) ?
You're likely to leave pretty bad looking fingertips on monitor surface ;-)
Replace "screen" with "paper" and you'll want to have accurate 1:1 layouts. This is the very essence of device independence. If, say, I want to print a PCB (printed circuit board) on a 300DPI laser printer, I'd want absolute accuracy, otherwise, my components will not fit the holes. Device independence means that both "screen" and "paper" should behave identically. If I want 10cm on paper how can I create such a thing in an abstracted relative coordinate system?
You query printer DPI and paper size and use that information to convert from millimeters that your CAD application uses to store position of holes to pixels that the printer use. For printer with fixed DPI and paper size you can get accurate positioning. For screen -- well, no. First, you need to know screen size. And on CRT, the screen size is different from image size because you can stretch the image using analog controls. And now imagine projector device. Do you really expect GUI buttons to have the same size on your monitor and on projector?
Bottom line: you'll want both absolute and relative dimensions.
That's for sure, but absolute dimensions might be needed only in specialized applications, like CAD. And maybe can be implemented outside of GUI. - Volodya
You mean the the rule has millimeters as the unit an at 1:1 zoom you want 1 millimeter of the ruler to be 1 millimeter on the screen? Then yes, you'll need some way to convert millimetres to units used on screen. Though I don't understand why you want such strict equality. You won't measure distances on the screen with a physical ruler anyway, right?
I guess a simple example would be "Word". When you print the doc, it shuld look like on the screen, right? Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
John Torjo wrote:
You mean the the rule has millimeters as the unit an at 1:1 zoom you want 1 millimeter of the ruler to be 1 millimeter on the screen? Then yes, you'll need some way to convert millimetres to units used on screen. Though I don't understand why you want such strict equality. You won't measure distances on the screen with a physical ruler anyway, right?
I guess a simple example would be "Word". When you print the doc, it shuld look like on the screen, right?
While for applications such as 'Word' it's just a nice-to-have feature, there are applications such as 'Illustrator' where it is imperative. Regards, Stefan
From: John Torjo <john.lists@torjo.com>
You mean the the rule has millimeters as the unit an at 1:1 zoom you want 1 millimeter of the ruler to be 1 millimeter on the screen? Then yes, you'll need some way to convert millimetres to units used on screen. Though I don't understand why you want such strict equality. You won't measure distances on the screen with a physical ruler anyway, right?
I guess a simple example would be "Word". When you print the doc, it shuld look like on the screen, right?
That doesn't mean that you should be able to hold the printed page to the monitor and see an exact match. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Vladimir Prus wrote:
Joel de Guzman wrote:
So, I believe that the ideal coordinate system unit is nothing more that "int".
For vector graphics, that would be float/double (or fixed-point).
Well, for SVG it's already float, and we can't change that part. Still I'm not sure why float is a good idea for drawing operations in a GUI library.
The point I am trying to make is that there should be no real distinction between a graphic (e.g. an SVG), structured graphic (composed) and the GUI elements. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Vladimir Prus wrote:
Stefan Seefeld wrote:
I'm not sure I understand what you mean by 'unit' here. Imagine you want to print a portion of the screen. Do you expect dimensions to be preserved on paper or not ? I do.
Physical dimenstions? In millimeters? Then I don't expect this. Say the program shows a chart in a window. It's natural to print that chart to occupy full size of A4 paper (if A4 is the current paper size), or have page layout customizable.
I don't quite understand what you are saying. There are certainly graphical objects without an intrinsic (physical) size that can scale to whatever region is available.
Then I don't understand what you said before. You said you expect that printing of portion of screen should preserve dimenstions. Do you mean dimensions in millmeters or in what unit? And why do you expect for them to be preserved on paper?
Yes, I'm talking about physical dimensions (millimeters, whatever). Why should I *not* expect it to preserve its size ?
What you describe is true for 'non-terminals' in the tree only. All leaf nodes (glyphs, icons, but also some part of the widgets themselves, such as bevels, slider and scrollbar handles, etc., etc.) do need their own size.
Right, but those sizes should be configurable by user and never tweaked by developer. The logic in the library to determine slider width, for example, might be complicated, but it should be inside library. Do you ever needed to explicitly set scrollbar width?
These sizes are typically determined by the GUI designer.
Who is, or what is "GUI designer". A human designing program, and human writing library, or a tool for designing GUIs? In which OS, or GUI library, the width of scrollbar is easily configurable?
The person designing a new GUI ('toolkit') is the one who sets 'style' attributes such as this one. I'v never said that it is (or should be) easily configurable.
They may or may not be configurable by users. My point is that don't want 'screen resolution' to interfer with them either. Users may scale ('zoom') the whole GUI to adjust it to their eyes.
Maybe we look from different angles. I think that application writers should not care about this.
I fully agree.
The GUI library sets the size of main windows, and the size may in any unit it likes. The application will then adjust all child windows in due *proportion* to the main window size and draw content. The display on monitor is done by GUI library, so it scales content as it likes.
Let me rephrase that a bit: the application asks the display server for a region of suitable size, such that all it wants to draw will fit in. This size requirement will be a fuction of the size of the graphical elements they lay inside (and, I reiterate, which generally should have physical dimensions). So, it's not that the content will be scaled 'in due proportion' to fit into the main window, but the main window will get a size suitable for the content. Thus, scaling isn't done implicitely to fit content to a main window (or screen). While there may be graphics that don't have an intrinsic size, and thus are easily scalable, most will not.
Device coordinates are not ok to determine object size, because that means that objects have differing sizes on different output devices (multiple screens, printers, etc.) and so users wrongly tweak resolution to get back their wanted object sizes.
You should never specify object size at all. The size of main window should be set the GUI library, or set as proportion of screen size.
The size of a composite graphic should be determined by negotiating the required size (range) necessary to draw the content with the size the screen (or generally, parent graphic) provides. See http://fresco.org/docs/papers/blending.pdf for a description of this process. I believe that scaling a text viewer such as in a pdf viewer when you resize the main window is the exception, not the rule. It is much more common to reflow the text, or to restrict the possible size of the main window. Regards, Stefan
Stefan Seefeld wrote:
Vladimir Prus wrote:
You should never specify object size at all. The size of main window should be set the GUI library, or set as proportion of screen size.
The size of a composite graphic should be determined by negotiating the required size (range) necessary to draw the content with the size the screen (or generally, parent graphic) provides. See http://fresco.org/docs/papers/blending.pdf for a description of this process.
The answer is of course you need both... I have a widget, its an 'OK' Button - I don't care how big it is or what you measure it with, it may or may not need to scale as the pixel count of the screen is increased... If I buy a big screen I normally want to be able to put more stuff on it... but not so that the text becomes impossible to read for instance. Size is determined by font size, etc. I have another widget, its purpose is to display my streaming HD video ... it had better be exactly XxY pixels else I won't be able to control the scaling correctly. Size in this case is controlled by content which is measured in pixels. Is this a special case ... maybe, can this be done with '3D' floating point co-ordinates ... yes if you get your transforms correct, this requires knowing the viewport and a bunch of other stuff but it is do-able. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
Kevin Wheatley wrote:
I have another widget, its purpose is to display my streaming HD video ... it had better be exactly XxY pixels else I won't be able to control the scaling correctly. Size in this case is controlled by content which is measured in pixels.
I don't understand your point. Where does scaling come into play, and why does it require pixel information ? Doesn't the fact that you want to control 'correct scaling' hint at your input having an intrinsic ('physical') size ? I think the point here is that both, the source, as well as the target device, are not vector-oriented but operate with rasters. But that doesn't mean that there is only a direct mapping from pixel to pixel. While this may be useful information to a) speed up the display ('bitblit') and b) provide superior display quality (since no anti-aliasing is required) I'd hope this can be figured out by the implementation. Regards, Stefan
Stefan Seefeld wrote:
I don't understand your point. Where does scaling come into play, and why does it require pixel information ? Doesn't the fact that
[snip]
b) provide superior display quality (since no anti-aliasing is required)
This was my point exactly :-) The amount of damage done to carefully crafted content by bad filtering is quite remarkable, plus artists want to know exactly what they are seeing in order to make such judgements, they want the raw pictures as much as possible without something (beyond their control) translating for them where its not needed. Kevin "Where's the 1:1 button on this thing?" -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
Kevin Wheatley wrote:
plus artists want to know exactly what they are seeing in order to make such judgements, they want the raw pictures as much as possible without something (beyond their control) translating for them where its not needed.
It is this attitude that leads to websites labeled "optimized for FooBrowser at bar resolution". I'm quite against using pixel coordinates in general. However, I agree that one should be able to integrate external sources that for whatever reasons impose constraints on scaling or do not offer scaling at all. However, this should in no way encourage people to use bitmap images. Otherwise, we'd be on our way back to what we have now. Regards, m PS: I'd love to be able to shrink uninteresting content or a whole window just by using the mouse wheel. Send instant messages to your online friends http://au.messenger.yahoo.com
Martin Wille wrote:
Kevin Wheatley wrote:
want to know exactly what they are seeing in order to make such judgements, they want the raw pictures as much as possible without something (beyond their control) translating for them where its not needed.
It is this attitude that leads to websites labeled "optimized for FooBrowser at bar resolution".
I should of course explain that the company I work for deals with images... to us image is everything, so our most important widget is the canvas/opengl widget, everything else should be as small and un-obtrusive as possible, like invisible until a hot key is pressed, placing a frame around an image affects the perception of the image, so we play with the colour schemes of almost all applications to make them fit with the images. We have rejected software that costs tens of thousands of pounds on the grounds that it could not display an image 1:1 pixel for pixel - for us it is not a trivial concern. I also think (agree) that every other widget in the world can be specified, layed out etc with no reference to the pixel count, here they should be vectors, with some form of sub-pixel precision where pixels are in the 0-10,000 range (very common) we'd naturally need at least 16 bits of precision to specify the images, never mind oversampling, etc, so a float (32 bit IEEE style) is quite OK for us. But ley the contained object and the containers work out exactly how big they need to be, rescalable widgets interactively sounds good to me. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself |
I think we agree that there are good reasons to want to access device coordinates sometimes. So, whatever we do to enable device independence, I think it mustn't completely hide device-specific information. Another question is that of compatibility. I don't think the goal of boost::gui can be to develop a new GUI framework, but rather, to define a modern API that is open for both, a new and modern implementation, as well as existing 'native' GUI wrappers. Thus, the challenge is to find a way that allows us to develop new GUIs in the spirit of Fresco, as well as wrap well established GUIs, and have both be accessible through the same API. Of course this isn't possible if the API is monolithic and rich. This is the reason I suggested to modularize it such that different implementations could adhere to the various sub-APIs to various degrees, as application programmers would be free to only use a subset of the APIs, with the result of either making the application more portable to platforms using very differing boost::gui implementations, or to have very fine-grained control over its display. One clearly can't have both. Regards, Stefan
"Stefan Seefeld" <seefeld@sympatico.ca> wrote
Thus, the challenge is to find a way that allows us to develop new GUIs in the spirit of Fresco, as well as wrap well established GUIs, and have both be accessible through the same API.
A low-level platform-independent API is a primary requirement. Whether it is possible to move beyond the wxWidgets and GTK API's is another matter. I guess you'd agree that it would be difficult to realise anything like Fresco in a platform independent way? For instance I believe that a top level glyph in Fresco can have an arbitrary shape, whereas in Windows you are limited to a "Region" made of rectangles and ellipses. IOW in Fresco you have the luxury of owning the screen. BTW "Glyph" might be a good name for the project! regards Andy Little
Andy Little wrote:
"Stefan Seefeld" <seefeld@sympatico.ca> wrote
Thus, the challenge is to find a way that allows us to develop new GUIs in the spirit of Fresco, as well as wrap well established GUIs, and have both be accessible through the same API.
A low-level platform-independent API is a primary requirement. Whether it is possible to move beyond the wxWidgets and GTK API's is another matter.
I guess you'd agree that it would be difficult to realise anything like Fresco in a platform independent way? For instance I believe that a top level glyph in Fresco can have an arbitrary shape, whereas in Windows you are limited to a "Region" made of rectangles and ellipses. IOW in Fresco you have the luxury of owning the screen.
The original Fresco project was a research efford that clearly aimed for a new display server architecture. However, the released packages provided a toolkit to construct GUIs within existing GUI environments, simply by allocating top-level windows from the 'system' and then doing all the rendering inside (i.e. widgets and other graphics) by itself. So yes, technically it would be possible. We then moved forward by putting the actual display server into its own server process, potentially distributing the 'scene graph' across processes (using CORBA). The idea was to provide an API that abstracted away the details, such that the user didn't need to be aware whether it helt an actual widget or just a proxy. While the particular choice of CORBA (and location-transparency) were probably unfortunate (at least at such a fine-grained level) I believe that the key to a flexible GUI API is still the same: provide abstract factories that construct a GUI and return high-level handles to it. That can be raw widget pointers, proxy objects, or what not. For example, a 'button' is simply an object that you can click on, and which emits a 'clicked message'. At this level it doesn't provide access to rendering routines or anything else that lets you fine-tune the button's look & feel. Doing this provides sufficient flexibility to the factory to either choose a native toolkit backend, or let Joel reimplement it on top of antigrain. Now, those applications that do require access to lower level rendering APIs then need access to a different 'kit'. (Fresco provided 'FigureKit', 'TextKit', 'LayoutKit', etc.) With that, an actual GUI is a compound of various 'kits' (i.e. APIs in terms of development, or libraries in terms of runtime environment) which may or may not be available on a particular platform. Thus the degree to which an application is portable depends on how many such kits it depends on. Again, the central point is to find clever key abstractions that all such kits (at present and in the future) can agree on, to provide sufficient flexibility for developers to implement it and let it evolve. Regards, Stefan
Stefan Seefeld wrote:
The original Fresco project was a research efford that clearly aimed for a new display server architecture. However, the released packages provided a toolkit to construct GUIs within existing GUI environments, simply by allocating top-level windows from the 'system' and then doing all the rendering inside (i.e. widgets and other graphics) by itself. So yes, technically it would be possible. We then moved forward by putting the actual display server into its own server process, potentially distributing the 'scene graph' across processes (using CORBA). The idea was to provide an API that abstracted away the details, such that the user didn't need to be aware whether it helt an actual widget or just a proxy.
Which IMO is the right thing to do.
While the particular choice of CORBA (and location-transparency) were probably unfortunate (at least at such a fine-grained level) I believe that the key to a flexible GUI API is still the same: provide abstract factories that construct a GUI and return high-level handles to it. That can be raw widget pointers, proxy objects, or what not. For example, a 'button' is simply an object that you can click on, and which emits a 'clicked message'. At this level it doesn't provide access to rendering routines or anything else that lets you fine-tune the button's look & feel. Doing this provides sufficient flexibility to the factory to either choose a native toolkit backend, or let Joel reimplement it on top of antigrain.
Yay! for Antigrain - but seriously ... the underlying mechanics of it all should be hidden, and I think we all agree that the holistic goal here is to sort out an API that would suit all, and remain sufficiently extensible. I concur here with you that abstract factories are just the way to go ... but how many here need convincing of that? I would only say that care should be taken to not make such a project too top-heavy (re: ambitious design), which is what I think Fresco in part suffered from; but I think the Fresco experience has much therein which can be drawn upon, not to mention the success/failures of other GUIs since. (Secretly), I'd like to see some kind of Fresco re-birth through a Boost-GUI, but then maybe I'm still dreaming.
Again, the central point is to find clever key abstractions that all such kits (at present and in the future) can agree on, to provide sufficient flexibility for developers to implement it and let it evolve.
You have my vote, anyone else ? Boosteres, it'd be nice to move on to something tangible, wouldn't it ... ? Cheers, -- Manfred MetOcean Engineers www.metoceanengineers.com
Manfred Doudar <manfred.doudar@metoceanengineers.com>:
(Secretly), I'd like to see some kind of Fresco re-birth through a Boost-GUI, but then maybe I'm still dreaming.
One of my "perhaps-hobby-to-be-should-I-get-any-free-time" ideas I've been playing with in my mind, have been to find the latest, and newest version of Fresco's predecessor InterViews (I'd start with ivtools) and then apply the "grandfather's knife principle"(*) to it. Ie. change it piece by piece to use standard C++ constructs where applicable, and boost constructs where they are applicable. But do the change gradually so that I've always have some compilable, working code. It's a neat design. The latest incarnations of InterViews are Fresco without the CORBA (...well, and parts are non-glyph-based stuff that is interesting as well, such as Unidraw). - Steinar (with no free time) (*) Behold my grandfather's knife! I've changed the handle, and I've changed the blade. Good as new!
Steinar Bang wrote:
One of my "perhaps-hobby-to-be-should-I-get-any-free-time" ideas I've been playing with in my mind, have been to find the latest, and newest version of Fresco's predecessor InterViews (I'd start with ivtools) and then apply the "grandfather's knife principle"(*) to it.
Ie. change it piece by piece to use standard C++ constructs where applicable, and boost constructs where they are applicable. But do the change gradually so that I've always have some compilable, working code.
It's a neat design. The latest incarnations of InterViews are Fresco without the CORBA (...well, and parts are non-glyph-based stuff that is interesting as well, such as Unidraw).
I find ivtools quite messy in many respects. It looks like a repository of multiple branches, all partially merged together. And Unidraw (in that incarnation at least) uses an ad-hoc type system which makes it hard to evolve into something clean. At least that was my impression when I tried to rewrite Unidraw in the context of the second generation of Fresco. It was really a rewrite based on Vlissides' thesis, as opposed to ivtools. I'm thus not sure whether it is really a good idea to provide incremental enhancement to that code. Anyways, the code is all still available, so if anybody wants to get his hands dirty, let me know ! :-) But seriously, I'm glad that I'm not the only one who feels a bit nostalgic at the sound of those names. There is a great many things to be learned from those experiments and it would be fun to resume, from a healthy distance, and with modern tools. Regards, Stefan
Stefan Seefeld wrote:
Then I don't understand what you said before. You said you expect that printing of portion of screen should preserve dimenstions. Do you mean dimensions in millmeters or in what unit? And why do you expect for them to be preserved on paper?
Yes, I'm talking about physical dimensions (millimeters, whatever). Why should I *not* expect it to preserve its size ?
Whenever I print a web page, the width of paper is different from the browser window width.
These sizes are typically determined by the GUI designer.
Who is, or what is "GUI designer". A human designing program, and human writing library, or a tool for designing GUIs? In which OS, or GUI library, the width of scrollbar is easily configurable?
The person designing a new GUI ('toolkit') is the one who sets 'style' attributes such as this one. I'v never said that it is (or should be) easily configurable.
Ok, agreed.
The GUI library sets the size of main windows, and the size may in any unit it likes. The application will then adjust all child windows in due *proportion* to the main window size and draw content. The display on monitor is done by GUI library, so it scales content as it likes.
Let me rephrase that a bit: the application asks the display server for a region of suitable size, such that all it wants to draw will fit in. This size requirement will be a fuction of the size of the graphical elements they lay inside (and, I reiterate, which generally should have physical dimensions).
Say, scrollbar is 5mm on my screen. Will that be good on a handheld computer? I doubt that. And how do you determine preferred physical size of scrollbar? Should it be 10cm or 5mm? You can't answer this question without knows the size of the drawing surface, so maybe scrollbar width should drawing_surface_width*some_fraction
Device coordinates are not ok to determine object size, because that means that objects have differing sizes on different output devices (multiple screens, printers, etc.) and so users wrongly tweak resolution to get back their wanted object sizes.
You should never specify object size at all. The size of main window should be set the GUI library, or set as proportion of screen size.
The size of a composite graphic should be determined by negotiating the required size (range) necessary to draw the content with the size the screen (or generally, parent graphic) provides.
Yes, that's how layout works in Qt.
See http://fresco.org/docs/papers/blending.pdf for a description of this process.
I'll read this paper.
I believe that scaling a text viewer such as in a pdf viewer when you resize the main window is the exception, not the rule. It is much more common to reflow the text, or to restrict the possible size of the main window.
Yes, but what does that prove? The preferred size of text is set by the user, who certainly cares only about physical size, but on a specific monitor. If he buys a different monitor with different size and resolution, it's not at all clear he'll want to retain the same physical size of the text. He might want to make it large, or smaller, depending on preferences. Going back to scrollbar -- I think it's width should also be customisable by the user vis some config tool. And if user hasn't specified anything, percentage of screen width looks better to me than any "natural" 5mm. Any constant you'll hardcode will be just that -- hardcoded constant. - Volodya
Vladimir Prus wrote:
Stefan Seefeld wrote:
Then I don't understand what you said before. You said you expect that printing of portion of screen should preserve dimenstions. Do you mean dimensions in millmeters or in what unit? And why do you expect for them to be preserved on paper?
Yes, I'm talking about physical dimensions (millimeters, whatever). Why should I *not* expect it to preserve its size ?
Whenever I print a web page, the width of paper is different from the browser window width.
Indeed, which makes designing web sites particularly challenging. However, web sites typically contain a lot of text, which can be reflown to fit on different media, so here, too, the solution is to use layout, not scale.
Let me rephrase that a bit: the application asks the display server for a region of suitable size, such that all it wants to draw will fit in. This size requirement will be a fuction of the size of the graphical elements they lay inside (and, I reiterate, which generally should have physical dimensions).
Say, scrollbar is 5mm on my screen. Will that be good on a handheld computer? I doubt that. And how do you determine preferred physical size of scrollbar? Should it be 10cm or 5mm? You can't answer this question without knows the size of the drawing surface, so maybe scrollbar width should drawing_surface_width*some_fraction
You raise interesting questions. I think it is an error to try to solve the challenge to design a GUI for different output media (devices) in terms of scale. It is not because you scale your widgets down that you make a graphical application usable on a PDA. Rather, the GUI 'style' should be adapted to the output device in that case. This is another argument for applications not to rely on a particular GUI style, at least not if they are meant to be portable across devices. High-resolution devices could use a GUI with much more detail than low-resolution devices. I'd even go further and try to abstract away much of the widgetry into high-level 'tasklets' that can be implemented specifically for particular output- (and input-, i.e. mouse, pen, keyboard, glove, etc.) devices. If a user's GUI can be described semantically in terms of 'tasks', its GUI can be much more flexibly replaced to adjust to particular hardware. But that gets us into quite a different discussion.
Yes, but what does that prove? The preferred size of text is set by the user, who certainly cares only about physical size, but on a specific monitor. If he buys a different monitor with different size and resolution, it's not at all clear he'll want to retain the same physical size of the text. He might want to make it large, or smaller, depending on preferences.
Quite right. Yet, it is the user, and he would rather think about size, not resolution. :-)
Going back to scrollbar -- I think it's width should also be customisable by the user vis some config tool. And if user hasn't specified anything, percentage of screen width looks better to me than any "natural" 5mm. Any constant you'll hardcode will be just that -- hardcoded constant.
Well, it's a constant in the context of a GUI style. You can still a) replace / modify the style b) scale a graphic to zoom in / out Regards, Stefan
Vladimir Prus wrote:
Stefan Seefeld wrote:
See http://fresco.org/docs/papers/blending.pdf for a description of this process.
I'll read this paper.
A must read for anyone interested in GUI development. There was a series of articles by John Vlissides in C++ Report in the 90s regarding Fresco. It is one of the most elegant GUI design that I know of. Alas, it was too ambitious (IMO). Stefan maintains Berlin which is a Fresco derivative. I also wrote a GUI framework based on Fresco in the 90s, where Spirit evolved from. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
Andy Little wrote:
"Vladimir Prus" <ghost@cs.msu.su> wrote
Let me try from a different angle.
Just provide alternative unit systems. Then we can all choose the ones we want, when we want.
Hows that? :-)
template<class CoordinateUnit> class Widget {}; ? Well, over my dead body ;-) And even without templates, the simpler the model, the better. - Volodya
"Vladimir Prus" <ghost@cs.msu.su> wrote
Andy Little wrote:
Just provide alternative unit systems. Then we can all choose the ones we want, when we want.
Hows that? :-)
template<class CoordinateUnit> class Widget {};
? Well, over my dead body ;-)
The cleanest way to deal with units would be as a world to device transform which is applied to the window at runtime as has been mentioned before. So it would be: Transform t; Widget w(t); ... code dealing with coordinates needs only use floats or ints , Now you can change the transform to whatever unit you wish. and your code will be units independent. Of course the default could be pixels so that "old timers" such as yourself who may be slightly frightened of units dont ever have to see them. ;-) regards Andy Little
Andy Little wrote:
"Vladimir Prus" <ghost@cs.msu.su> wrote
Andy Little wrote:
Just provide alternative unit systems. Then we can all choose the ones we want, when we want.
Hows that? :-)
template<class CoordinateUnit> class Widget {};
? Well, over my dead body ;-)
The cleanest way to deal with units would be as a world to device transform which is applied to the window at runtime as has been mentioned before. So it would be:
Transform t; Widget w(t);
... code dealing with coordinates needs only use floats or ints ,
Now you can change the transform to whatever unit you wish. and your code will be units independent. Of course the default could be pixels so that "old timers" such as yourself who may be slightly frightened of units dont ever have to see them. ;-)
Good. In fact, that's why I meant by "2D graphics can be scaled as you like". Specifically, take a look at: QPainter::setWindow http://doc.trolltech.com/4.0/qpainter.html#setWindow-2 that establish logical coordinates for drawing, and QPainter::setMatrix http://doc.trolltech.com/4.0/qpainter.html#setMatrix that establish translate/scale transformations. Is that what you're after? - Volodya
Just provide alternative unit systems. Then we can all choose the ones we want, when we want.
Hows that? :-)
template<class CoordinateUnit> class Widget {};
? Well, over my dead body ;-)
And even without templates, the simpler the model, the better.
Take a look at win32::gui::draw::length It isn't templated, and it allows you to specify the unit both in code, and in script. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
John Torjo wrote:
Well, over my dead body ;-)
And even without templates, the simpler the model, the better.
Take a look at win32::gui::draw::length
It isn't templated, and it allows you to specify the unit both in code, and in script.
Hi John, I'm sorry, but can you provide a direct URL to docs? As it stands, I don't know where to downloaded your library, and which header in which directory to open, or where to look at the docs. - Volodya
Vladimir Prus wrote:
John Torjo wrote:
Well, over my dead body ;-)
And even without templates, the simpler the model, the better.
Take a look at win32::gui::draw::length
It isn't templated, and it allows you to specify the unit both in code, and in script.
Hi John, I'm sorry, but can you provide a direct URL to docs? As it stands, I don't know where to downloaded your library, and which header in which directory to open, or where to look at the docs.
Sorry 'bout that : (download) http://sourceforge.net/project/showfiles.php?group_id=110720&package_id=139052 After downloading, take a look at: DOWNLOAD-DIR\win32gui\draw\surfaces\detail\geometry.hpp Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
Let me try from a different angle. There's some settings made by user, like font size, or toolbar icon size. The unit does not matter there.
I believe that in a good GUI library, you should not ever need to use any dimensions for windows dimensions, but just allow the layout code in the library to take care of this. And since you don't have to specify dimensions, it does not matter if they are in pixels or not.
I do think that every now and then, you do need to specify dimensions. For instance, when specifying a button's width (in case you want it fixed). Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
John Torjo wrote:
Let me try from a different angle. There's some settings made by user, like font size, or toolbar icon size. The unit does not matter there.
I believe that in a good GUI library, you should not ever need to use any dimensions for windows dimensions, but just allow the layout code in the library to take care of this. And since you don't have to specify dimensions, it does not matter if they are in pixels or not.
I do think that every now and then, you do need to specify dimensions. For instance, when specifying a button's width (in case you want it fixed).
Why would you want to have it fixed to absolute values? Say, in Qt if you want buttons to not grow when you resize dialog you set its "size policy" to either "Fixed" or "Maximum". You don't need to specify absolute values. - Volodya
I do think that every now and then, you do need to specify dimensions. For instance, when specifying a button's width (in case you want it fixed).
Why would you want to have it fixed to absolute values? Say, in Qt if you want buttons to not grow when you resize dialog you set its "size policy" to either "Fixed" or "Maximum". You don't need to specify absolute values.
I'm not sure I understand: once you set a "size policy" to "fixed", it seems that you would need to set a fixed size (for a button, for instance). Or, if you set it as percentage of the original dialog size, still, the dialog would need to have an original fixed size, which is about the same thing. Or, am I missing something? (question aside: can you choose the "size policy" for each dimension like, left,top,width,height, or for the whole widget?) Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
John Torjo wrote:
I do think that every now and then, you do need to specify dimensions. For instance, when specifying a button's width (in case you want it fixed).
Why would you want to have it fixed to absolute values? Say, in Qt if you want buttons to not grow when you resize dialog you set its "size policy" to either "Fixed" or "Maximum". You don't need to specify absolute values.
I'm not sure I understand: once you set a "size policy" to "fixed", it seems that you would need to set a fixed size (for a button, for instance).
"you would need" -- that's the key, "you" don't need to compute the size, Qt will do it itself. Each widget has sizeHint method that return preferred size. For button, that's that length of the text plus some extra space. If you set size policy to "fixed", Qt won't ever try to resize the widget above it's sizeHint. Works pretty nice.
(question aside: can you choose the "size policy" for each dimension like, left,top,width,height, or for the whole widget?)
There's separate size policy for width and height. As for left/top -- that's outside of widget control and in control of its parent. Of course the parent typically use the layout classes to control that, and does not set absolute positions. In fact, absolute positions are almost always wrong. Imagine you set a button width to fixed value, and day later I translate the text on button to Russian, possibly increasing its length twofold. That's why automatic layout is not just nice to have, but a requirement. - Volodya
Just think of the many places you'll need to deal with geometry (rectangle/point/size), and converting from one type of unit (px to cm, cm to in, etc) to another.
I agree. In particular, I'd strongly suggest to draw a clear distinction between physical dimension and resolution. Most current GUIs did get that wrong, I believe in that they conditioned us all to think of size when talking about number of pixels.
True... When I've developed surfaces, I allow the user to specify any of: px, pt, in, cm, mm In script, lengths can be specified like 12.3cm, 2.2in, 42px Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
David Wehite wrote:
In his article "The Design of C++0x", published in C/C++ Users Journal, May 2005, the author of C++ Bjarne Stroustrup wrote, "The most commonly requested new feature for C++ is a standard GUI".
I am new to Boost and will appreciate if some folks here would give me a summary of Boost organization's standing on such a standard GUI library. If and how was it addressed and pointers to work on the subject if such has been done.
This topic has occurred regularly and this time I think I can't help expressing my view. They are going to be somewhat rush, but don't take it too personally. I think that Boost as organisation can't and shouldn't produce a working GUI library. 1. Effort Let's take a look at existing library -- Qt. 10 years of development, done by a company with 100 employers. Compare that to Boost. Yes, it started by 2 people, but still took 10 years. Say we want to "just" wrap Qt. Take each class, strip "Q" prefix from the name, add "boost::", create Qt object in constructor, and make each method forward to Qt object. This can be automated, in fact. Now assume one has to think for 5 mins about each wrapped method -- does it use ideal name, ideal order of parameters, and so on. The task no longer can be automated and will take month(s). Now assume one wants to actually design new interface, even if it will call to Qt objects. The task will likely to take years. This is only workable if the initial design becomes so attractive that 1000 people will start contributing. To give another example, there's vector graphics library Cairo, that does antialised 2D on many platforms. I don't have hard numbers but it's being in development for quite some time, and just recently hit 1.0. And that's just vector graphics library. 2. Design It's not all clear that anybody here can design the right interface right away. All design suggestions that floated around were centered at clever use of C++ features, like nice DSL for describing windows. Sure, that will look cool, but is really not important. FWIW, most of my problems with Qt were causes by some non-standard use-cases, like, "make this lineedit wide enough for exactly 8 characters". Any fresh design will surely have troubles with much larger number of corner use cases. 3. Purpose Long time ago, there was project to reimplement all Qt from scratch, under pure GPL license. That project did not produce anything viable, to the best of my knowledge. Now, Qt is GPL on Linux and Windows, so what's the purpose of any new library? The possibility for commercial companies to have free-for-any-use GUI library? Failing that, anybody has any killer idea for GUI development that warrants new library? Why don't add Qt to the C++ standard? - Volodya
"Vladimir Prus" <ghost@cs.msu.su> wrote
Failing that, anybody has any killer idea for GUI development that warrants new library? Why don't add Qt to the C++ standard?
http://www.trolltech.com/products/qt/pricing.html regards Andy Little
Andy Little said:
"Vladimir Prus" <ghost@cs.msu.su> wrote
Failing that, anybody has any killer idea for GUI development that warrants new library? Why don't add Qt to the C++ standard?
No doubt, TrollTech has to make the money they deserve some way. They also give the stuff away to everybody that can accept GPL like terms. What I wonder is if anybody with contacts in the standard process and/or to the compiler vendors have ever considered Vladimirs suggestion, and approached the Trolls about it? Maybe there is a business case in that for TrollTech. They could be the prime provider of a larger part of the standard library to a number of compilers. I believe the main problem is that some of the compiler vendors have their own none-portable GUI libraries - are they willing to give these up, or make them portable and give them away? That is why this would not work - so don't blame the pricing of commercial licenses of Qt. -- Bjørn
Bjørn Roald wrote:
Andy Little said:
"Vladimir Prus" <ghost@cs.msu.su> wrote
Failing that, anybody has any killer idea for GUI development that warrants new library? Why don't add Qt to the C++ standard?
No doubt, TrollTech has to make the money they deserve some way. They also give the stuff away to everybody that can accept GPL like terms.
What I wonder is if anybody with contacts in the standard process and/or to the compiler vendors have ever considered Vladimirs suggestion, and approached the Trolls about it? Maybe there is a business case in that for TrollTech. They could be the prime provider of a larger part of the standard library to a number of compilers.
This would be the right way to go about producing a standard GUI library. As Volodya has noted, writing a GUI library suffers from several problems: * the task is monumentally large; * everyone has a different idea on what should go into the library (just see the native vs generic look brought up in this round of GUI library discussions!); * the library would vastly increase the size of Boost (if Boost would be used to host the GUI).
I believe the main problem is that some of the compiler vendors have their own none-portable GUI libraries - are they willing to give these up, or make them portable and give them away? That is why this would not work - so don't blame the pricing of commercial licenses of Qt.
Having Qt standardised does not mean that people will stop using wxWidgets, WTL, MFC or another GUI library, just like having std::basic_string<> hasn't stopped ATL/MFC, wx and others providing their own string classes. - Reece
Reece Dunn wrote:
* the library would vastly increase the size of Boost (if Boost would be used to host the GUI).
To expand on this, I don't see how GUI library can be reviewed. It looks like many libraries draw too few reviewers, and for large library, the review can be very problematic. Further, if lot of work went into GUI library, and it's rejected, it will be hard to address review concerns. Reviewing components one-by-one can miss the whole picture. For example, we have a signal library already, which was reviewed and I think it's fine. But for GUI designer, you need to get list of signals in an object, and boost::signals does not allow that. - Volodya
Failing that, anybody has any killer idea for GUI development that warrants new library? Why don't add Qt to the C++ standard?
No doubt, TrollTech has to make the money they deserve some way. They also give the stuff away to everybody that can accept GPL like terms.
What I wonder is if anybody with contacts in the standard process and/or to the compiler vendors have ever considered Vladimirs suggestion, and approached the Trolls about it? Maybe there is a business case in that for TrollTech. They could be the prime provider of a larger part of the standard library to a number of compilers.
Sorry, I'm not sure I understand. Are you suggesting that TrollTech could somehow be persuaded to make Qt available for free under a Boost-like license, or are you suggesting that it would be acceptable to make Qt a C++ standard under its current licensing scheme?
Geoffrey Romer said:
Failing that, anybody has any killer idea for GUI development that warrants new library? Why don't add Qt to the C++ standard?
No doubt, TrollTech has to make the money they deserve some way. They also give the stuff away to everybody that can accept GPL like terms.
What I wonder is if anybody with contacts in the standard process and/or to the compiler vendors have ever considered Vladimirs suggestion, and approached the Trolls about it? Maybe there is a business case in that for TrollTech. They could be the prime provider of a larger part of the standard library to a number of compilers.
Sorry, I'm not sure I understand. Are you suggesting that TrollTech could somehow be persuaded to make Qt available for free under a Boost-like license, or are you suggesting that it would be acceptable to make Qt a C++ standard under its current licensing scheme?
No, neighter. The challenge is really to define the syntax and semantics of a standard library. If this is somehow based on TrollTech's experience and the API of Qt, then TrollTech would find themselves in a strong position for providing commercial licensed libraries to those standard library providers selling commercially licensed C++ standard libraries. Also, the standard committee would have a working implementation to build their confidence in the design. That does not prevent anybody else from implementing a competing solution which they may give away for free or sell. So, TrollTech would have to accept that the API spec are in the public domain, hence it could be copied by anybody, even Bill Gates - for any purpose. Whether they are interested in that is impossible to say, but an approach from the standard committee would be taken seriously, I bet on that anyway. Not only for the possible business, but also since I know the Trolls wish for a strong future of the language they have committed themselves to. -- Bjørn
Andy Little wrote:
"Vladimir Prus" <ghost@cs.msu.su> wrote
Failing that, anybody has any killer idea for GUI development that warrants new library? Why don't add Qt to the C++ standard?
That's not really relevant in two areas: For developers: 1. For open-source applications, there's GPL version, costing exactly $0 2. Do you really want to write a new GUI library just to help commercial companies? For standartisation: That's price of Qt *library*, for commercial use. But: - Standard specifies only interface, and does not mandate specific source code or vendor. - Why do you think any implementation of standard library should be free of charge? - Volodya
"Vladimir Prus" wrote
Andy Little wrote:
"Vladimir Prus" wrote
Failing that, anybody has any killer idea for GUI development that warrants new library? Why don't add Qt to the C++ standard?
That's not really relevant in two areas:
For developers: 1. For open-source applications, there's GPL version, costing exactly $0 2. Do you really want to write a new GUI library just to help commercial companies?
I dont know whether I want to contribute to writing such a library, but I am looking into it. It wouldnt be 'just' for commercial puposes. Also it is a difficult challenge. like climbing a mountain. It could potentially profit the developers in form of books and teaching, though it would be a long term project and there is no guarantee!. [snip]
- Why do you think any implementation of standard library should be free of charge?
The competition - Java GUI is effectively free of charge. regards Andy Little
"Andy Little" wrote:
2. Do you really want to write a new GUI library just to help commercial companies?
I dont know whether I want to contribute to writing such a library, but I am looking into it. It wouldnt be 'just' for commercial puposes. Also it is a difficult challenge. like climbing a mountain.
If anything you may join existing "modern C++" GUI library like John Torjo's win32gui, SmartWindows++, perhaps VCF or Ultima++. Every one of these libraries could use help of many, many people, should they only get organized together. /Pavel
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote
If anything you may join existing "modern C++" GUI library like John Torjo's win32gui,
Is win32gui ever seriously going to target anything other than Windows?
SmartWindows++,
SmartWindows looks like it follows the Windows API slavishly
perhaps VCF or Ultima++.
Ultima++ has little or no documentation unfortunately VCF certainly looks quite interesting and I hope to look further at it, though they seem from an initial glance to be duplicating a lot of functionality eg streams, strings and their own date-time library. Nevertheless it looks like it is seriously trying to be cross-platform and so it looks the most promising one to me. OTOH I also find the workings of the Java GUI libraries interesting. regards Andy Little
"Andy Little" wrote:
If anything you may join existing "modern C++" GUI library like John Torjo's win32gui,
Is win32gui ever seriously going to target anything other than Windows?
AFAIK yes. John started preparations for GTK support though he "would welcome other's help".
SmartWindows++,
SmartWindows looks like it follows the Windows API slavishly
Yes. My personal opinion is that win32gui is more abstract.
Ultima++ has little or no documentation
Well, it is work of two guys who also created their own STL, full featured IDE, scripting language and other things. I am amazed how much they did
unfortunately VCF certainly looks quite interesting and I hope to look further at it, though they seem from an initial glance to be duplicating a lot of functionality eg streams, strings and their own date-time library.
Having own string class looks as mandatory for GUI lib writers ;-) I guess you see NIH syndrom and attempt to completely control code base. Quite typical for projects with few people. /Pavel
Pavel Vozenilek wrote:
"Andy Little" wrote:
If anything you may join existing "modern C++" GUI library like John Torjo's win32gui,
Is win32gui ever seriously going to target anything other than Windows?
AFAIK yes. John started preparations for GTK support though he "would welcome other's help".
SmartWindows++,
SmartWindows looks like it follows the Windows API slavishly
Yes. My personal opinion is that win32gui is more abstract.
Ultima++ has little or no documentation
Well, it is work of two guys who also created their own STL, full featured IDE, scripting language and other things. I am amazed how much they did
Hmm. I got the same feeling using it that I get if I use MFC, that the IDE knows more about whats going on than I do, and the whole vertical stack thing is normally considered to be quite bad, isn't it?
unfortunately VCF certainly looks quite interesting and I hope to look further at it, though they seem from an initial glance to be duplicating a lot of functionality eg streams, strings and their own date-time library.
Having own string class looks as mandatory for GUI lib writers ;-)
I guess you see NIH syndrom and attempt to completely control code base. Quite typical for projects with few people.
/Pavel
For those who have no idea what NIH is: http://en.wikipedia.org/wiki/Not_Invented_Here
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote in message news:dhi15d$cj3$1@sea.gmane.org...
"Andy Little" wrote:
If anything you may join existing "modern C++" GUI library like John Torjo's win32gui,
Is win32gui ever seriously going to target anything other than Windows?
AFAIK yes. John started preparations for GTK support though he "would welcome other's help".
(Sincerely to John Torjo - I have only skimmed the surface in win32gui. I may have a lot wrong. There may be a lot I have missed.) There is a lot of mention of Windows stuff in the implementation. There is even sdi_frame(CFrameWnd), mdi_frame(CMDIFrameWnd), WM_SIZE (et al) message etc. (IIRC using FrameWnd it was difficult to try to make switchable views). Anyway, in win32gui that I have looked at there is very little abstraction away from Win32 API. For example in win32gui/examples program entry is: int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR lpCmdLine, int nCmdShow) AFAIK the common view on this list is not to subvert main. (VCF scores again It uses main for GUI on Windows. Despite templates win32gui seems to use much of the *patterns* in MFC like GDI , though even Microsoft has moved on with eg GDI+. There are alternatives to DeviceContext approach too but are they explored here? IMO To make win32gui cross-platform will require a higher level of abstraction than is there currently. For instance repeatedly the look and feel issue has come up on this list. win32gui looks to be similar to Java.awt in that it is a thin wrapper over the underlying API. However Java have now rejected that model with Swing, which does much more low level work. It would be interesting to find out why the java designers felt they needed to change and made this choice. Maybe it is even possible to have both ways On the plus side win32gui has various units for length which is commendable! I like that! In my experience units seriously do give device independence! What I want of a C++ GUI : 1 The goal is a GUI as part of the C++ standard. Java has not one but 2. Moral - Even if the first C++ standard GUI is not very good its worth doing for the experience gained. So far in all the C++ GUI libraries cited I have not seen any with this as a primary goal. 2 Platform independence. Obvious! In practise means a philosophical abstraction is required. A "top down" design. To facilitate this design and construction of such a library should be carried out on several operating systems simultaneously. ( Boost is good at that ! ) 3 Reuse of standard (and boost :-) ) libraries even if there are some problems. Seems obvious from here but GUI libraries cited seem to spend a lot of effort to roll their own. There may be a reason - thread safety? However even if this is a problem it is worthwhile trying to use the standard library in order to improve it. 4 The look and feel issue is major for potential users. It is important that the GUI should have the capability to have the "look and feel" of an operating system (Ideally Whether that is the one its working on or not) 5 Must use main as an entry point. Seems trivial but affects how lightweight a GUI application is. Lightweight is good! regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote
5 Must use main as an entry point. Seems trivial but affects how lightweight a GUI application is. Lightweight is good!
Separation of the GUI from main may be reminscent of model-view-controller architecture. Here main represents model. GUI represents view-controller. Just a thought. regards Andy Little
(Sincerely to John Torjo - I have only skimmed the surface in win32gui. I may have a lot wrong. There may be a lot I have missed.)
There is a lot of mention of Windows stuff in the implementation. There is even
Right, on the *implementation* ;)
sdi_frame(CFrameWnd), mdi_frame(CMDIFrameWnd), WM_SIZE (et al) message etc.
The thing is that until I could provide for platform-independent events, I had to use existing windows events. If you take a look at event_ex class, you'll see that you can say things like: event_ex<wm::size>() (which can map to the underlying OS's SIZE event)
(IIRC using FrameWnd it was difficult to try to make switchable views). Anyway, in win32gui that I have looked at there is very little abstraction away from Win32 API. For example in win32gui/examples program entry is: int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR lpCmdLine, int nCmdShow)
Is that so important? It's quite easy to abstract away, IMO.
AFAIK the common view on this list is not to subvert main. (VCF scores again It uses main for GUI on Windows. Despite templates win32gui seems to use much of the *patterns* in MFC like GDI , though even Microsoft has moved on with eg GDI+. There are alternatives to DeviceContext approach too but are they explored here?
I guess that's why I invented surfaces. They're in alpha-stage, but I think they're quire the way to go.
IMO To make win32gui cross-platform will require a higher level of abstraction than is there currently. For instance repeatedly the look and feel issue has come up on this list. win32gui looks to be similar to Java.awt in that it is a thin wrapper over the underlying API. However Java have now rejected that model with Swing, which does much more low level work. It would be interesting to find
Again, take a short look at surfaces. Also, we can discuss things privately, if you have more questions :)
out why the java designers felt they needed to change and made this choice. Maybe it is even possible to have both ways
On the plus side win32gui has various units for length which is commendable! I like that! In my experience units seriously do give device independence!
:) that's for surfaces
5 Must use main as an entry point. Seems trivial but affects how lightweight a GUI application is. Lightweight is good!
Again, I think that's not so complex to implement IMO. A lot of concepts I've developed for win32gui can be platform-independent. That's why I want to port this to other platforms. But I need your help. Volunteers needed :) Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
"John Torjo" <john.lists@torjo.com> wrote in message news:43426DC8.5030904@torjo.com...
Again, I think that's not so complex to implement IMO. A lot of concepts I've developed for win32gui can be platform-independent. That's why I want to port this to other platforms. But I need your help. Volunteers needed :)
Maybe the ideal would be to start another project using the experience learned on win32gui but designed from the ground up to be cross-platform. It might also be useful to do the actual development on another platform for obvious reasons. What do you think? regards Andy little
Andy Little wrote:
"John Torjo" <john.lists@torjo.com> wrote in message news:43426DC8.5030904@torjo.com...
Again, I think that's not so complex to implement IMO. A lot of concepts I've developed for win32gui can be platform-independent. That's why I want to port this to other platforms. But I need your help. Volunteers needed :)
Maybe the ideal would be to start another project using the experience learned on win32gui but designed from the ground up to be cross-platform. It might also be useful to do the actual development on another platform for obvious reasons.
What do you think?
Too many projects for me ;) It is an interesting idea though. I'm not sure I'll have the time for coding, but I could definitely help with the design/concepts and such. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
John Torjo <john.lists@torjo.com> writes:
AFAIK the common view on this list is not to subvert main. (VCF scores again It uses main for GUI on Windows. Despite templates win32gui seems to use much of the *patterns* in MFC like GDI , though even Microsoft has moved on with eg GDI+. There are alternatives to DeviceContext approach too but are they explored here?
I guess that's why I invented surfaces. They're in alpha-stage, but I think they're quire the way to go.
I went to your Win32GUI page to look for an explanation of surfaces, but IIRC couldn't find any kind of summary, at least not one I could understand. Could you write a few sentences explaining what this is all about? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
John Torjo <john.lists@torjo.com> writes:
AFAIK the common view on this list is not to subvert main. (VCF scores again It uses main for GUI on Windows. Despite templates win32gui seems to use much of the *patterns* in MFC like GDI , though even Microsoft has moved on with eg GDI+. There are alternatives to DeviceContext approach too but are they explored here?
I guess that's why I invented surfaces. They're in alpha-stage, but I think they're quire the way to go.
I went to your Win32GUI page to look for an explanation of surfaces, but IIRC couldn't find any kind of summary, at least not one I could understand. Could you write a few sentences explaining what this is all about?
Sorry 'bout that. I will do this soon. Very busy at the moment -- but it's defninitely on my todo list. Until then, maybe you could take a look at the articles on CUJ? Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
Andy Little wrote:
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> wrote
If anything you may join existing "modern C++" GUI library like John Torjo's win32gui,
Is win32gui ever seriously going to target anything other than Windows?
Yes, help provided, definitely. Best, John -- John Torjo, Contributing editor, C/C++ Users Journal -- "Win32 GUI Generics" -- generics & GUI do mix, after all -- http://www.torjo.com/win32gui/surfaces.html - Sky's the limit! -- http://www.torjo.com/cb/ - Click, Build, Run!
Vladimir Prus <ghost@cs.msu.su> writes:
Long time ago, there was project to reimplement all Qt from scratch, under pure GPL license. That project did not produce anything viable, to the best of my knowledge.
Have you seen http://www.nedprod.com/TnFOX/ ?? Scroll down the page to see the "completedness table." He's using Boost.Python, which is part of the reason I know about it. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Vladimir Prus <ghost@cs.msu.su> writes:
Long time ago, there was project to reimplement all Qt from scratch, under pure GPL license. That project did not produce anything viable, to the best of my knowledge.
Have you seen http://www.nedprod.com/TnFOX/ ??
No, until now.
Scroll down the page to see the "completedness table."
Sorry, *that table* does not contain any class names that sound like having to do anything with GUI. The documentation further says: "We have stuff like QThread, QString etc. replacements but nothing GUI-like!". So, no, it's not Qt interface with free license. - Volodya
"Vladimir Prus" wrote
Sorry, *that table* does not contain any class names that sound like having to do anything with GUI.
The documentation further says: "We have stuff like QThread, QString etc. replacements but nothing GUI-like!". So, no, it's not Qt interface with free license.
See: http://tnfox.sourceforge.net/TnFOX/html/group__guiclasses.html regards Andy Little
Andy Little wrote:
"Vladimir Prus" wrote
Sorry, *that table* does not contain any class names that sound like having to do anything with GUI.
The documentation further says: "We have stuff like QThread, QString etc. replacements but nothing GUI-like!". So, no, it's not Qt interface with free license.
See:
http://tnfox.sourceforge.net/TnFOX/html/group__guiclasses.html
I did look there and the interface of the classes is quite different from Qt's. Maybe some misunderstanding. Dave's reply quoted this my sentence:
Long time ago, there was project to reimplement all Qt from scratch, under pure GPL license. That project did not produce anything viable, to the best of my knowledge.
As I understood him, he though that TnFox is such reimplementation, which it does not appear to be. - Volodya
Vladimir Prus <ghost@cs.msu.su> writes:
Andy Little wrote:
"Vladimir Prus" wrote
Sorry, *that table* does not contain any class names that sound like having to do anything with GUI.
The documentation further says: "We have stuff like QThread, QString etc. replacements but nothing GUI-like!". So, no, it's not Qt interface with free license.
See:
http://tnfox.sourceforge.net/TnFOX/html/group__guiclasses.html
I did look there and the interface of the classes is quite different from Qt's.
Maybe some misunderstanding. Dave's reply quoted this my sentence:
Long time ago, there was project to reimplement all Qt from scratch, under pure GPL license. That project did not produce anything viable, to the best of my knowledge.
As I understood him, he though that TnFox is such reimplementation, which it does not appear to be.
It appears to claim that it is a Qt reimplementation, FWIW. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (33)
-
Adam Badura -
Andreas Pokorny -
Andy Little -
Arkadiy Vertleyb -
Ben Artin -
Bjørn Roald -
Bo Persson -
Brian Ravnsgaard Riis -
David Abrahams -
David Bergman -
David W -
David Wehite
-
Felipe Magno de Almeida -
Geoffrey Romer -
Jason Hise -
Jeff Garland -
Joel de Guzman -
Joel Eidsath -
John Torjo -
Jonathan Benedicto -
Kevin Wheatley -
Liu Jin -
Manfred Doudar -
Martin Wille -
Pavel Vozenilek -
Reece Dunn -
Rob Stewart -
Simon Buchan -
Stefan Seefeld -
Steinar Bang -
Suman Cherukuri -
Tushar -
Vladimir Prus