Re: [boost] Report from Berlin C++ Standards Committee meeting
On Apr 13, 2006, at 3:20 AM, Andy Little wrote:
A major reason given by the committee AFAICS (in GUI case) was that the committee doesnt have enough time to deal with it.
This is not exactly correct. The committee does not have enough time to *design* a GUI library, nor any other library. Besides, you wouldn't want a library designed by committee, would you?
If someone steps up with a proposal for a GUI library, the committee will review it.
Having used at least 7 or 8 GUI, and written maybe 2 or 3 libraries for various employers I think I can safely say, its not a good canidate for a standard. Why? For production/shrink wrap software you generally need a very platform specific look and feel. And most companies which have a multiplatform product have either written their own, or bought one and therefore have too much money invested to switch. In addition, they have no desire to lower the bar to entry by providing what they perceive as a competative advantage to anyone else. In addition complier/platform vendors have no desire to help you move your product off their platform onto one of their competators. For one off type stuff you usually can just use the native GUI. Why bother with a platform independent tool when you can use the one that's provided by the OS? Thirdly, its a real bicycle shed issue. Everybody knows what the GUI should look like. Endless arguments of whether it should be pixel/character/some other unit based. Whether it needs a button with independent art, or supplied by?? What format that art should take, do you supply a 'facet' which tells the GUI how to understand the art. Whether the art should know its relationship to the window or should that be a property of the GUI object? What do you do with art that doesn't display well on the platform its trying to be rendered on. Do you need the almost infinite states for every button? (depressed, undepressed, highlighted pressed, highlighted undepressed, rollover depressed, rollever undepressed) and art for all of them? Should the GUI objects be in an 'absolute' position based on the window? Or should the whole thing reorganize itself based on shape and size of the window? It's a huge coding problem and if I ever wrote it (again), I'd probably want some monitary compensation for my time. After all everyone else in the GUI business is getting a piece of the pie, why not me? So if you want a "std" GUI, you need to define who your clients are, and what problems it solves. I think you'll find that one size fits no one. Yours, -Gary-
"Powell, Gary" wrote
Having used at least 7 or 8 GUI, and written maybe 2 or 3 libraries for various employers I think I can safely say, its not a good canidate for a standard.
Its difficult to know what you mean by a GUI in the above statement "Having used 7 or 8 GUI". Do you mean the Platform dependent API consisting of system calls or do you mean a GUI toolkit such as QT or MFC ... both or neither? In the statement "its not a good candidate for a standard.", what is "it" referring to. Is it the general concept of a GUI or those 7 or 8 GUI's you have used? (I think its quite important to distinguish the low level platform dependent API's from the toolkits. Any standard GUI would probably use the platform API's but would be competing with/ replacing the toolkits) I am trying to see the benefits of having to learn 7 or 8 libraries and not have a standardised one. If this is good policy for a GUI then why is it not a good policy for other libraries such as (say) a thread library? Surely the same principle should hold here too? I think you need to spell out what particularly applies to a GUI but not other areas, to clarify the point you are trying to make here.
Why? For production/shrink wrap software you generally need a very platform specific look and feel. And most companies which have a multiplatform product have either written their own, or bought one and therefore have too much money invested to switch. In addition, they have no desire to lower the bar to entry by providing what they perceive as a competative advantage to anyone else. In addition complier/platform vendors have no desire to help you move your product off their platform onto one of their competators.
As far as look and feel issue is concerned I am aware that its an important concern. I dont intend to deal with it here, but it should certainly be part of any GUI standardisation proposal. The point regarding companies being locked in to a particular library is slightly simplistic surely? A company may just as likely be using various toolkits in different locations and suffering every time it tries to mix those systems. That is the more usual problem AFAIK. In that case they would sure see the benefits of having a common standard to work to. As far as vendors locking you in. Are you really suggesting this is a good thing to perpetuate? Do the vendors clients feel happy about this? Is supporting vendor lock-in one of the aims of C++? Vendor lock-in is surely the antithesis of what C++ is about isnt it? The need to buy third party software for a C++ GUI certainly helps Java to recruit students at least.
For one off type stuff you usually can just use the native GUI. Why bother with a platform independent tool when you can use the one that's provided by the OS?
How would I go about writing a point'n' click installer for the boost libaries, or for that matter a graphical front end for any of the applications in the boost tools directory?
Thirdly, its a real bicycle shed issue. Everybody knows what the GUI should look like. Endless arguments of whether it should be pixel/character/some other unit based. Whether it needs a button with independent art, or supplied by?? What format that art should take, do you supply a 'facet' which tells the GUI how to understand the art. Whether the art should know its relationship to the window or should that be a property of the GUI object? What do you do with art that doesn't display well on the platform its trying to be rendered on. Do you need the almost infinite states for every button? (depressed, undepressed, highlighted pressed, highlighted undepressed, rollover depressed, rollever undepressed) and art for all of them? Should the GUI objects be in an 'absolute' position based on the window? Or should the whole thing reorganize itself based on shape and size of the window?
I don't really understand what point you are trying to make in the above paragraph. The questions here look to be of the same order as those one would ask when designing any library.
It's a huge coding problem and if I ever wrote it (again), I'd probably want some monitary compensation for my time. After all everyone else in the GUI business is getting a piece of the pie, why not me?
This is a practical issue. But this is rather a reason why a C++ standard GUI may not happen rather than why it shouldnt happen.
So if you want a "std" GUI, you need to define who your clients are, and what problems it solves.
Sure. Simply put, the first potential clients are anyone who currently writes command line applications, primarily because those are relatively portable, but would like to migrate to a GUI if the migration barrier was very low.
I think you'll find that one size fits no one.
QT and wxWidgets would seem to think otherwise ... regards Andy Little
participants (2)
-
Andy Little -
Powell, Gary