Re: [boost] Report from Berlin C++ Standards Committee meeting

From: Andy Little (andy_at_[hidden])
Date: 2006-04-13 22:18:04

"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