Sean Kelly wrote:
> Hasan Aljudy wrote:
> 
>> Anyway, why don't they (the C++ committee) ask a bunch of developers/copmpanies/whatever to develope a standard gui for C++? Did they consider doing this? Kind of combines the best of points (2) and (3) I think.
> 
> Such a library would still have to be evaluated by the committee before being accepted, and that's a few years worth of meetings all by itself.  I think the project is simply too large for those involved to consider it worthwhile.  After all, C++ is lacking a lot more basic things that need to be sorted out first.  Perhaps we'll see one in the 2020 iteration of the standard.

I forgot to mention... another big issue is support.  It's far easier to add things to the standard than it is to remove them, and with the rate that UIs are changing, the committee would have be considering any submission in the light that it should be meaningful 20 years from now.  Also, there has been historic resistance to anything that isn't perceived as common to all platforms using C++, or that is difficult to present in a manner that would be applicable to all such platforms (though this is changing a bit now).  And in this case "all platforms" can mean 15 year old embedded processors with 6 bit bytes.  Fortunately, D isn't hobbled by such restrictions.


Sean

That's probably the most concise and accurate illustration of C++ issues that I've seen, Sean.



Sean Kelly wrote:
> Hasan Aljudy wrote:
> 
>> Walter Bright wrote:
>>
>>> 2) Design by committee a new gui from scratch. Odds of this turning out something useful are zilch.
>>
>>
>> Do they admit this? because IMO, they should admit that their Design of C++ just sucks!!
> 
> 
> In this case, the problem has more to do with the committee aspect than the language design.
> 
>> I returned to C++ few days ago because some of my courses now require it .. and I discovered that C++ really sucks!! like .. really really sucks! specially for doing object oriented programming! 
> 
> 
> C++ turned out nearly as well as it could given historic issues and design constraints.  The committee aspect also hobbled things a bit--a good chunk of the original standard library proposal was simply scrapped for lack of time to evaluate it.  In my opinion, there are two primary problems with C+:
> 
> * The language supports so many different programming techniques that coordinating team development to produce a consistent code-level design is very difficult.
> 
> * The desire to implement as much functionality as possible in library code has made code interoperability difficult to achieve, and the language facilities required to support this have hurt code readability.
> 
> Baically, there are simply too many corner cases and odd exceptions in how C++ code behaves for the language to be well understood without a significant amount of study.  That isn't to say it's impossible to write elegant, fast, maintainable code in C++ however, only that the language doesn't encourage it.
> 
>> Ofcourse they choose C++ for effeciency .. man I wish I could that assignment in D! It'd be awesome!! Hmm, come to think of it, maybe I can tell my prof about D .. if he likes it, he might use it for the next semister .. or something! Can someone write a short paragraph/essay to convince a University professor that D is more suitable for graphics programming than C++?! Seriously, all these profs care about (I think/hope) is performance, they would probably use Java, if it wasn't so slow and didn't run in a VM!
> 
> 
> For D to be taught in a university course I think it probably needs a book about it.  School is weird that way.  However, D has a lot of selling points that should make it attractive for academic use.  A few of the more obvious ones are its floating-point support, garbage collection of UDTs, and its ability to get to the bare metal via pointers and inline assembly code.  This would allow a teacher to focus on algorithms without worrying about memory allocation and the like (which is why Java has become so popular in academics), to do accurate number-crunching for engineering classes with a simple straightforward syntax, and to also allow low-level issues to be explored *all in the same language*.  I can't think of any other programming language that can make such a claim.  The only drawback at the moment is the lack of solid debugger support, as I think debuggers can be a useful tool for learning how code executes.
> 
>> Anyway, why don't they (the C++ committee) ask a bunch of developers/copmpanies/whatever to develope a standard gui for C++? Did they consider doing this? Kind of combines the best of points (2) and (3) I think.
> 
> 
> Such a library would still have to be evaluated by the committee before being accepted, and that's a few years worth of meetings all by itself.  I think the project is simply too large for those involved to consider it worthwhile.  After all, C++ is lacking a lot more basic things that need to be sorted out first.  Perhaps we'll see one in the 2020 iteration of the standard.
> 
> 
> Sean

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds18ci$18rm$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds16ar$17fh$1@digitaldaemon.com...
>> Sidenote: on RSDN forum one person was asking about
>> some tool for C++ sources obfuscation (purpose is unknown to me),
>> and practical advice-answer was to write code using boost.
>
> I find boost impractical to use as well. It's just--too--complicated.
>
>> -----------
>> BTW, generally speaking C++ has no "official GUI toolkit" too.
>> Seems like only persons who are not satisfied with this situation are
>> Bjarne Stroustrup, Michael Rasmussen and John Medema
>> according to http://lafstern.org/matt/wishlist.html section "GUI"
>
> Bjarne is right.

I don't think so :)

>
> C++ has 3 choices:
>
> 1) Do nothing and argue that a standard gui is a bad idea.

Exactly! I don't even know what "standard gui" means.
Each application (or group of applications) has its own requirement set
here.
"standard" of what for the byte sake?

> 2) Design by committee a new gui from scratch. Odds of this turning out
> something useful are zilch.
> 3) Endorse one of the existing C++ guis. One vendor gets rich and the rest
> are mad as h*ll. Not going to happen.
>
> This is why (1) is where C++ is going, despite it being the wrong choice. I figure we need to fix the problem with D before we get trapped by (2) and (3) as well.

I don't understand where this "standard GUI" bright idea comes from. Even Java has no single toolkit: AWT and Swing, SWT plus 3 or 4 more.

Sidenote: Recently we did UI for some online application
(70,000 subscribers so far) - client side GUI is just one
big Java applet.
Swing is basicly not moving and SWT just does not work in browser
so we've ended up with our own toolkit  based on low level AWT
primitives with architecture very close to what Harmonia uses.

The point here - even in Java with its "official
toolkit" (two of them, btw) in real life you will be forced to use your own
at the end.
(I've never seen real application using Swing, btw)
In .NET situation is similar: Microsoft is dropping WinForms in favour
of Avalon foundation now. At the meantime people are doing their
own stuff even redesigning basic GDI+ primitives.
Example: GUI of http://www.creativedocs.net/ Pierre Arnaud
.NET application with AGG (http://antigrain.com/) engine and
completely custom GUI toolkit.

So the question - what is this "standard GUI" for?

Again, solution could be in building "standard GUI" pyramid
from reusable blocks like Graphics Package, etc.
Such blocks will have more chance to be a) accepted widely
b) to be not thrown away if something will go wrong.

Accepting this D will demonstrate maturity in its
design principles. Joke.

If you wish we can establish sort of working group
on creation of such D GUI foundation,
Graphics Package, etc.
I am short on time a bit now but will try to do something here
if we need to.

>
>
>> -----------
>> Walter, as you are here...  any news from
>> "immutability aka const aka readonly" front?
>> And one more: external aka outer methods for primitive types,
>> especially arrays... No?
>
> Haven't time to deal with those issues at the moment, and I don't think there'll be any movement on them until after 1.0.

(Sigh) , too pity...

I think I don't need to ask about this "too universal" 'auto' keyword too.

For me everything seems perfect except these three:
'readonly' (string!), 'outer methods' (string!) (are they still work for
arrays,btw?)
and the 'auto' mess introduced recently.

Andrew Fedoniouk.
http://terrainformatica.com

"Sean Kelly" <sean@f4.ca> wrote in message news:ds1c2c$1apm$1@digitaldaemon.com...
> Hasan Aljudy wrote:
>> Walter Bright wrote:
>>
>>> 2) Design by committee a new gui from scratch. Odds of this turning out something useful are zilch.
>>
>> Do they admit this? because IMO, they should admit that their Design of C++ just sucks!!
>
> In this case, the problem has more to do with the committee aspect than the language design.

That's what I meant. The people on the C++ committee are excellent programmers. But the problems of design by committee are human nature.

"Sean Kelly" <sean@f4.ca> wrote in message news:ds1cka$1bas$1@digitaldaemon.com...
> I forgot to mention... another big issue is support.  It's far easier to add things to the standard than it is to remove them, and with the rate that UIs are changing, the committee would have be considering any submission in the light that it should be meaningful 20 years from now.

Nobody has any idea what will happen in 20 years, so that's a hopeless condition.

>  Also, there has been historic resistance to anything that isn't perceived
> as common to all platforms using C++, or that is difficult to present in a
> manner that would be applicable to all such platforms (though this is
> changing a bit now).  And in this case "all platforms" can mean 15 year
> old embedded processors with 6 bit bytes.  Fortunately, D isn't hobbled by
> such restrictions.

Reminds me of an anecdote. Back in the 80's at a conference, I was on a discussion panel with representatives from Microsoft, Borland, Watcom, etc. The question was asked "do you have a version of your compiler for floppy disk only machines?" Each vendor by turn gave a detailed explanation of how you could user their compiler on a floppy only machine. Then it got to me. I said: "Sure we have a floppy version. It costs $200 extra and comes with a hard disk." That got a big laugh, and it was the end of that discussion. Not only that, nobody *ever* even brought up the subject again. It was just a dead issue.

And that's how I feel about D on 16 bit machines. Sometimes it's just time to move on.

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds1g3o$1d63$1@digitaldaemon.com...
>> 1) Do nothing and argue that a standard gui is a bad idea.
> Exactly! I don't even know what "standard gui" means.
> Each application (or group of applications) has its own requirement set
> here.
> "standard" of what for the byte sake?

All standard means is there are is a gui library as part of the D standard, it wouldn't be a separate add-on.


> I don't understand where this "standard GUI" bright idea comes from. Even Java has no single toolkit: AWT and Swing, SWT plus 3 or 4 more.

Java started out with just AWT. Without AWT, Java would have gotten nowhere. The other gui libraries came along later as the user base expanded. AWT was Java's proverbial "chicken" to bootstrap the process. We need one, too. It isn't like DWT will be the only gui toolkit ever.

> The point here - even in Java with its "official
> toolkit" (two of them, btw) in real life you will be forced to use your
> own at the end.

I'm not a bit surprised. Nobody has figured out the last word in gui toolkits.

> So the question - what is this "standard GUI" for?

If you like, think of having a standard gui like DWT as useful for marketing. It *is* a big win for marketing the language. Quite a lot of people think it is necessary before even considering D, therefore it is necessary.

> Again, solution could be in building "standard GUI" pyramid
> from reusable blocks like Graphics Package, etc.
> Such blocks will have more chance to be a) accepted widely
> b) to be not thrown away if something will go wrong.
> If you wish we can establish sort of working group
> on creation of such D GUI foundation,
> Graphics Package, etc.
> I am short on time a bit now but will try to do something here
> if we need to.

I think you're probably right, and this would be a better long term solution than DWT is, so I encourage you to work on it. But we need something now.

> For me everything seems perfect except these three:
> 'readonly' (string!), 'outer methods' (string!) (are they still work for
> arrays,btw?)

Yes.

Mike Parker wrote:

>> This is GREAT news. Cross platform gaming anyone?
> 
> Cross-platform game tools, perhaps. wxWidgets for games (or DWT for that matter) falls into the realm of overkill.

Again, that depends on how you define what a game really *is* ?

For making something like an arcade game, you're probably right.


But I would think that this program in the wx "demos" fits:

http://www.wxwidgets.org/apps/forty/forty.htm

--anders

Ben Hinkle wrote:

> The approach I was taking with MinWin was to make the native type available (and encouraged) for direct manipulation. That's why it was very important to have as minimal a layer as possible between the MinWin D code and the underlying OS types and routines. One should be able to easily take a MinWin window (or graphics or whatever) and do to it whatever the native system supports (within reason). Most cross-platform GUI toolkits try as hard as possible to hide the implementation details (as OOP methodology traditionally encourages) but I think for GUI toolkits that just results in a frustratingly limited toolkit. For example there should be no extra state stored in the D objects so that there's no risk of getting the D view of the widget out of sync with the OS view.

One of the problems* on the Mac OS X platform, when I tried to port MinWin, was that the two native system libraries/frameworks were not easily accessible from D. So there D itself definitely was a problem.

One is written in C/C++ (Carbon) and has a *lot* of old header files that needs to be ported over first. The other framework is written in Objective-C/Java (Cocoa) and is not easily accessible from D either.


When writing the interface code in C++ or Objective-C++, it is simple
to export the needed functions with a "C" interface for use with D...
(simple, because one can just use the system frameworks as they are)

And this is the approach that wxD uses, so I scrapped my Carbon hacks.
(the Carbon version is in wxMac, and the Cocoa version is in wxCocoa)
GTK+ is unfortunately still very behind the times, on the Mac platform.


So I chose wxD. Even with the "weird mix" of C++ and C#, that it has.
--anders


*
If anyone cares, the other reason was that MinWin wasn't copyrighted.
I like the "wxWidgets license" better than releasing as Public Domain.
And licensing was also one of my reasons for not choosing Qt instead...

On Sat, 04 Feb 2006 17:58:09 +1100, Walter Bright <newshound@digitalmars.com> wrote:

[snip]

> I think you're probably right, and this would be a better long term solution
> than DWT is, so I encourage you to work on it. But we need something now.

I think I'm in general agreement with both Andrew and Walter.

I have written a GUI library for Windows in the Euphoria language. Most people who use it like it very much. So I figure I better start porting it to D. Maybe be later on, some one can add support for other windowing systems (eg. Motif) if they want to.

It could bootstap ideas and other libraries.

-- 
Derek Parnell
Melbourne, Australia

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds1ksm$1fo6$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds1g3o$1d63$1@digitaldaemon.com...
>>> 1) Do nothing and argue that a standard gui is a bad idea.
>> Exactly! I don't even know what "standard gui" means.
>> Each application (or group of applications) has its own requirement set
>> here.
>> "standard" of what for the byte sake?
>
> All standard means is there are is a gui library as part of the D standard, it wouldn't be a separate add-on.
>

Again, if marketing people
think that it will benefit D significantly then I will
vote by two hands too.

>
>> I don't understand where this "standard GUI" bright idea comes from. Even Java has no single toolkit: AWT and Swing, SWT plus 3 or 4 more.
>
> Java started out with just AWT. Without AWT, Java would have gotten nowhere. The other gui libraries came along later as the user base expanded. AWT was Java's proverbial "chicken" to bootstrap the process. We need one, too. It isn't like DWT will be the only gui toolkit ever.

AWT is a minimal window toolkit. And abstract.
Abstract is a synonym of the egg here I beleive.
And MinWin by its feature set is close to AWT more than
anything else.

It has minimal Application framework allowing beginers
to easily start from something.
I would strip from there Graphics with some its redesign
aimed to generalization and with Standard D Graphics in mind.
And would declare it and  SDG as D GUI Foundation.

Generally speaking design of "Standard D GUI" as a task
is quite different from what authors of DWT/SWT, DFL
and myself had in their minds.

Design goal of "Standard D GUI" at the first place
should be to create foundation (bootstrap and not a complete
 widget set) - to define only  set of basic classes like
Application (winmain encapsulation),
generic Window and generic event handling.
This is what all toolkits have in common anyway and may use.

And this is exactly the purpose AWT serves in Java world.
Swing and SWT were built on top of AWT.
AWT is really the egg.

Conseptually AWT is very good thing - it is classical in "GUI science". But its practical implementation....

I beleive that compact version of AWT implemented in
D with all its power and compactness is what D needs now.
Simple and clean. AWT supported by all OS vendors
and there a lot of its implementations where OS specific code
can be borrowed.

Again, main goal is not in creation of particular widget set (e.g. for creation of some IDE like Eclipse) but to be a common denominator different types of applications (frameworks, toolkits) can use as a basis.

Andrew Fedoniouk.
http://terrainformatica.com