In article <ds0u4s$12ad$1@digitaldaemon.com>, Sean Kelly says...
>
>Walter Bright wrote:
>> "Kyle Furlong" <kylefurlong@gmail.com> wrote in message news:ds0m2i$sus$1@digitaldaemon.com...
>>> As long as we are critiquing DWT...
>>>
>>> 1. No Ares support
>>> 2. Java-like coding style = YUCK!
>>>
>>> But as we all know it is a very useful tool, so maybe the PRACTICAL thing is to support it officially.
>> 
>> Personally, I don't like the java coding style either. But think of it like strapping a rocket engine on a chicken, once we get that sucker off the ground, we can build ourselves a nicer set of wings <g>.
>
>I'm really enjoying these chicken analogies.  Someone needs to create a D logo that has a picture of a chicken strapped to a rocket ;-)

How did I ever use the internet without google?

http://www.pioneerlocal.com/movies/graphics/pix/11-03-05-review.jpg http://www.chickenrocket.com/ http://www.users.bigpond.net.au/calleja/images/100_1493.JPG

The last one seems apt.


- Eric Anderton at yahoo

"pragma" <pragma_member@pathlink.com> wrote ...
> How did I ever use the internet without google?
>
> http://www.pioneerlocal.com/movies/graphics/pix/11-03-05-review.jpg http://www.chickenrocket.com/ http://www.users.bigpond.net.au/calleja/images/100_1493.JPG
>
> The last one seems apt.

Oh boy ... you sure are inviting trouble, Eric; for "reprinting" such insensitive images.


[ok; ok; I'll stop now]

"Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds10up$14av$1@digitaldaemon.com...
> Forget about STL and boost. There is no practical GUI  toolkit in the wild using them anyway.  (This fact speaks for itself)

I know. I have a suspicion that both are evolutionary dead ends. Your fact is evidence for that, as well as the failure of any other language to pick up those features.

Kyle Furlong 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.

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ds130o$15kh$1@digitaldaemon.com...
>
> "Andrew Fedoniouk" <news@terrainformatica.com> wrote in message news:ds10up$14av$1@digitaldaemon.com...
>> Forget about STL and boost. There is no practical GUI  toolkit in the
>> wild
>> using them anyway.  (This fact speaks for itself)
>
> I know. I have a suspicion that both are evolutionary dead ends. Your fact is evidence for that, as well as the failure of any other language to pick up those features.

I think this way too. I am monitoring couple of GUI projects trying to interbreed STL or even boost with GUI ... aesthetical disaster is what I can say at least.

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.

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

-----------
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?
Just in case.... as seems like you are in good mood :)

Andrew Fedoniouk.
http://terrainformatica.com

"Mark D" <theomnipotentqatmsn@msn.com> wrote in message news:ds0si9$11bk$1@digitaldaemon.com...
>> Take a look: all toolkits have classes like
>> Graphics with acompanying Font, Image and other drawing primitivies.
>> Can we make them as some standard package? Sure, I would say we must to.
>> Another candidate for standard library are Rect, Point, Polygon -
>> geometric primitives.
>
> I definitely would like to see something like this... but in the back of my head - with my limited knowledge - I'm wondering how exactly something like this would work.  For example, presumably we are drawing all of these things in a window, right?  So that sort of implies that even a default, simple and "primitive" graphics functionality also involves a standard cross-platform syntax to create and manipulate a window.  So what properties does a window need?  And I would guess that this is the point where things start to snowball out of control with issues like resolution, modality, fullscreen support, color depth, etc.
>

consider this:

typedef void* HANDLE;

class Graphics
{
  this(HANDLE h) {....}
}

This is neutral "one size fits all" declaration for the case when
Graphics used as standalone package.
So you can write simple WinProc and in WM_PAINT pass
construct Graphics with HDC handle.
Drawing and Event handling are loosely coupled things or at least
the can be implemented this way.

If some toolkit is using this Graphics package then it should
provide correspondent methods providing Graphics for different "surfaces"
For example in Harmona there are
three sources of Graphics (classes implementing ISurface) and
they all have methods/properties:

Graphics Window.graphics();
Graphics Image.graphics();
Graphics Printer.graphics();

Some other toolkit, for example http server side image package
will have only
Graphics Image.graphics();
to provide dynamic image drawing facilities.


> I remember fondly working with Borland's flavor of C++ in DOS, and using those most basic of functions to create classes to encapsulate the functionality I wanted (windows, buttons, etc).  But while I can understand easily how that works, it seems like we're now in a totally different world when it comes to creating a similar experience that is truly cross-platform with our current operating systems.  I would appreciate any enlightenment! ;)

I beleive you are speaking about BGI, right?
Nothing changed in principle here.
As I mentioned before there are two ways of how to design toolkit.
MinWin is thin layer wrapping underlying window primitives which is
extremely usefull if you need to write something native for e.g. Windows.
And Harmonia uses quite different approach similar to what you did in BGI -
it uses only topmost os windows - no child HWNDs inside - it draws
everything by itself (menus, buttons, checkboxes, etc).

Hope I've explained all this clear in my Eng++.
Sorry otherwise.


Andrew Fedoniouk.
http://terrainformatica.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.

C++ has 3 choices:

1) Do nothing and argue that a standard gui is a bad idea.
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.


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

In article <drupf1$24at$1@digitaldaemon.com>, Walter Bright says...
>
>
>"Dave" <Dave_member@pathlink.com> wrote in message news:druo2h$2366$1@digitaldaemon.com...
>> I looked at the EPL, but it seems predicated toward applications (like
>> Eclipse)
>> and not libraries (like S/DWT), so it wasn't clear to me what the EPL
>> means to
>> me as a potential 'closed source' developer who may use DWT to develop an
>> app.
>>
>> Can you (or anyone) enlighten me on this?
>
>Here's the FAQ on the EPL: http://www.eclipse.org/legal/eplfaq.php
>

I'm still stumped as to how exactly the EPL would apply to using D/SWT in proprietary projects, so I sent away to the Eclipse folks for an answer. Some of the answers in the FAQ seem potentially ambiguous to me - instead of summarizing what the license actually says on a matter, they refer back to the license! They do make it clear what you can and can't do with Eclipse and Plugin source code, but not with something like SWT.

If I ever get a solid reply from them I'll summarize it here.

- Dave

Walter Bright wrote:
> "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.
> 
> C++ has 3 choices:
> 
[snip]
> 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!! 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! 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!
Same for networking course .. as long as there are D bindings for things related to socket programming and everything else network related.
I know for sure that the Prof can use whatever language he likes for courses, one prof made us use Python for .. guess what? data structures!! Why? because he likes it!!

OK, I've gone OT ..

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.

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