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

From: Powell, Gary (powellg_at_[hidden])
Date: 2006-04-13 14:29:30

> 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-