"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkaipi$a1i$2@digitaldaemon.com...
> > For those concerned about the libraries - sure, D's libraries are
woefully
> > inadequate right now. But don't worry about writing library code that is less than perfect, just write it. Evolve it over time into perfection.
> Look
> > at how C++ libraries changed over time. How many times has iostream been re-engineered from scratch? <g>
> There should only ever have been one reworking of the iostreams, and I
think
> you know what that would have been ...

There have been at least three reengineerings of it. That's why DMC++ has <iostream>, <iostream.h>, <iosold\iostream.h> and <oldstr\iostream.h>.

In article <bkac7h$6c$2@digitaldaemon.com>, Walter says...
>Frankly, the best way I believe to do a GUI library for D is to take the best C++ one and simply translate it to D. (Assuming of course the license to it allows that.) It won't achieve perfection that way, but it should get closer to it than starting over from 0.

I agree 100%.

Personally, I think somebody should be working on rewriting wxWindows in D. The object hierarchy has already been fleshed out. They've already mapped out workable parallelism between win32 and gtk and mac os x. There are already visual desginers for it. It's a mature project, and we could translate it into D. Yes, it's a huge project. And, yes it would take lots of work. But it will take _even_more_work_ to design and build an entire GUI library from scratch to replace it.

--Benji

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkakce$cb8$1@digitaldaemon.com...
> Any chance of you updating the SynSoft link to mention the Performance, String Tokenisation and Registry libraries? :)

Write me a brief text, and I'll update it with that text. And that goes for all! I try to keep up with the dlinks, but if the descriptions fall short, need updating, or are missing, please provide the text for me and I'll fix it.

> Also, have you had a look at the reg stuff yet? I started work on some reg-writing code (porting a set of C++ utility fns of my own, that have served almost all my needs over the last 5 yrs) last night - when I should be writing my article; deadline today!! - and that all went really easily.
I
> plan to implement a synsoft.win32.regutil module, on which the synsoft.win32.reg will be implemented. That way, if the class-based
registry
> stuff falls short in some esoteric way, the user can get whatever they
want
> from the free function API, rather than trying to write the catch-all API.

I looked at the reg stuff. It needs write capability, and after looking at it, it really does need properties to look its best!

> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkaipi$a1i$2@digitaldaemon.com...
> > > For those concerned about the libraries - sure, D's libraries are
> woefully
> > > inadequate right now. But don't worry about writing library code that
is
> > > less than perfect, just write it. Evolve it over time into perfection.
> > Look
> > > at how C++ libraries changed over time. How many times has iostream
been
> > > re-engineered from scratch? <g>
> > There should only ever have been one reworking of the iostreams, and I
> think
> > you know what that would have been ...
>
> There have been at least three reengineerings of it. That's why DMC++ has <iostream>, <iostream.h>, <iosold\iostream.h> and <oldstr\iostream.h>.

The iostream include I would be looking for would involve no characters at all ...

Well, that'll teach me! I thought I was writing an email.

Good job I didn't say anything rude!! <blush>

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bkakce$cb8$1@digitaldaemon.com...
> > Anyhow, D has already been a dramatic success. That's easy to see given
> the
> > activity in the D newsgroup and the high quality of discussion here and
> the
> > high quality of code apparent on www.digitalmars.com/d/dlinks.html. Even
a
> > rubber axe can chop down an oak tree if you keep on swinging, and that
is
> > certainly what I intend to do. The language is steadilly improving, it's just received a foreach, I'm working on fleshing out the operator overloading, and I have several ideas and suggestions from you guys for improving templates percolating around. We'll keep plugging away, and
> things
> > will only get better.
>
> Any chance of you updating the SynSoft link to mention the Performance, String Tokenisation and Registry libraries? :)
>
> Also, have you had a look at the reg stuff yet? I started work on some reg-writing code (porting a set of C++ utility fns of my own, that have served almost all my needs over the last 5 yrs) last night - when I should be writing my article; deadline today!! - and that all went really easily.
I
> plan to implement a synsoft.win32.regutil module, on which the synsoft.win32.reg will be implemented. That way, if the class-based
registry
> stuff falls short in some esoteric way, the user can get whatever they
want
> from the free function API, rather than trying to write the catch-all API.
>
>
>

"Walter" <walter@digitalmars.com> escreveu na mensagem news:bkac7h$6c$1@digitaldaemon.com...

> Even a rubber axe can chop down an oak tree if you keep on swinging, and that is certainly what I intend to do.

But can you do it... with... a herring?


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003

In article <bkanum$hcq$1@digitaldaemon.com>, Benji Smith says...
>
>In article <bkac7h$6c$2@digitaldaemon.com>, Walter says...
>>Frankly, the best way I believe to do a GUI library for D is to take the best C++ one and simply translate it to D. (Assuming of course the license to it allows that.) It won't achieve perfection that way, but it should get closer to it than starting over from 0.
>
>I agree 100%.
>
>Personally, I think somebody should be working on rewriting wxWindows in D. The object hierarchy has already been fleshed out. They've already mapped out workable parallelism between win32 and gtk and mac os x. There are already visual desginers for it. It's a mature project, and we could translate it into D. Yes, it's a huge project. And, yes it would take lots of work. But it will take _even_more_work_ to design and build an entire GUI library from scratch to replace it.
>
>--Benji
>
>

Maybe it's time to make a conversion tool.
It would help a lot on this project and be very usefull
for others.

wxWindows GTK only has 194301 lines in .cpp files alone
(DUI and tests is now with 43000 in .d files).
I don't advice any single person to look at 200000 lines of code.

I saw at some page from the D links a description of an .h to .d processor, but I didn't see any download link...

Did any one start such a tool?
That looks like a one person project.
(hey, don't look at me, I have 2 other projects to finish)

I did made a small .h to .d to convert the OpenGL headers
(quick and dirty)
but they use just a small set of c and pre-processor directives.

Ant

"Daniel Yokomiso" <daniel_yokomiso@yahoo.com.br> wrote in message news:bkaqbj$kpl$1@digitaldaemon.com...
> "Walter" <walter@digitalmars.com> escreveu na mensagem news:bkac7h$6c$1@digitaldaemon.com...
>
> > Even a rubber axe can chop down an oak tree if you keep on swinging, and that is certainly what I intend to do.
>
> But can you do it... with... a herring?

Monty Python?

Hi,

I do not remember this topic's thread very well, but I think the title is very interesting. So, to bring the discussion back where it belongs, what about component programming?

Could somebody put some ActiveX programmed controls, by example? I think is the widest spreaded component interface. I know it is possible to program ActiveX controls/forms in D but I found no real example. As a beginner, I would need that.


Further, I know that D classes are compatible with this kind of components (even ActiveX). But, there is a real internal support for that? I mean, are the classes conceived as components? Are they really supporting (internally) events, properties and methods? I do not like very much to imagine first the entire application's class tree and to implement each class afterward as an extention of the (same) ancestor. Reusing components, aggregating and connecting them is simpler, I think. You can easily change the message trajectories at the run-time, by example. Anyway, just an opinion.

Please be kind with me....

"Ant" <Ant_member@pathlink.com> wrote in message news:bkaqhf$l6t$1@digitaldaemon.com...
> Maybe it's time to make a conversion tool.
> It would help a lot on this project and be very usefull
> for others.
>
> wxWindows GTK only has 194301 lines in .cpp files alone
> (DUI and tests is now with 43000 in .d files).
> I don't advice any single person to look at 200000 lines of code.

I wonder if it all needs to be converted for a first pass. After all, D can easilly interface to C code. Can much of wxWindows be wrapped in C?

Is there a usable subset of wxWindows?

> I saw at some page from the D links a description of an .h to .d processor, but I didn't see any download link...
>
> Did any one start such a tool?
> That looks like a one person project.
> (hey, don't look at me, I have 2 other projects to finish)

Doing C headers to D is one thing, but doing C++ is another.

> I did made a small .h to .d to convert the OpenGL headers
> (quick and dirty)
> but they use just a small set of c and pre-processor directives.
>
> Ant
>
>