Starting my very first Win32 app in D, I wanted to ask Walter in private:

    "Could you please add

        HDC GetDC(HWND hWnd);

    to phobos/windows.d (around line 1184)?"

but I soon realized there are many other crucial omissions yet.

- What is the current best practical approach to develop
  Win32 stuff in D (preferably without learning extra
  frameworks like DIG)?

- What is the strategy of extending windows.d into a full
  Win32 interface? (Asking this because bugging Walter with
  "please add this and that" may not be a viable solution...)

Thanks,
Sz.
(If the above sounds ridiculously clueless it is because
I _am_ ridiculously clueless...)

"Luna Kid" <lunakid@neuropolis.org> wrote in message news:b9tob6$1jm7$1@digitaldaemon.com...
> Starting my very first Win32 app in D, I wanted to ask Walter in private:
>
>     "Could you please add
>
>         HDC GetDC(HWND hWnd);
>
>     to phobos/windows.d (around line 1184)?"

Ok.

> - What is the current best practical approach to develop
>   Win32 stuff in D (preferably without learning extra
>   frameworks like DIG)?

Do it just like you would in C++ or C (except don't use MFC).

> - What is the strategy of extending windows.d into a full
>   Win32 interface? (Asking this because bugging Walter with
>   "please add this and that" may not be a viable solution...)

Just add anything missing as needed.

In article <b9u0tu$1tv6$1@digitaldaemon.com>, Walter says...

>> - What is the strategy of extending windows.d into a full
>>   Win32 interface? (Asking this because bugging Walter with
>>   "please add this and that" may not be a viable solution...)
>
>Just add anything missing as needed.

I was wondering if we could use the wiki as a collaborative windows.d
editing project?  If everyone was conscientious about it every time
you added a delaration to your own local windows.d file you could check
the wiki and add it to the windows.d page if it did not exist.  Then you
could also periodically cut and paste the code to you own local file to
get everyone elses changes.

Hi.

I like the idea of a Wiki, although a SourceForge project might be better.  However, I'm not very excited about the thought of programming directly to the win32 api.  MFC is so much more productive, especially with ClassWizard.

OTOH, developing a good GUI interface library for D from scratch is an enourmous task.

Is there any other way?  Are there any good share-ware GUI libs out there we could write wrappers for?  That could help in porting GUIs to Linux, which is currently a nightmare.

We currently write our GUIs twice: once for Windows and once for Linux.  he MainSoft stuff for porting to Linux makes for bad Linux interfaces.  Running GTK+ on Windows isn't yet stable enough, and may make a bad Windows interface.  An alternative is Java, which is nice, but then we've got debugging and installation headaches.

Bill

Patrick Down wrote:
> In article <b9u0tu$1tv6$1@digitaldaemon.com>, Walter says...
> 
> 
>>>- What is the strategy of extending windows.d into a full
>>>  Win32 interface? (Asking this because bugging Walter with
>>>  "please add this and that" may not be a viable solution...)
>>
>>Just add anything missing as needed.
> 
> 
> I was wondering if we could use the wiki as a collaborative windows.d
> editing project?  If everyone was conscientious about it every time you added a delaration to your own local windows.d file you could check the wiki and add it to the windows.d page if it did not exist.  Then you could also periodically cut and paste the code to you own local file to get everyone elses changes.
> 
> 
> 

Patrick Down wrote:
> In article <b9u0tu$1tv6$1@digitaldaemon.com>, Walter says...
> 
> 
>>>- What is the strategy of extending windows.d into a full
>>>  Win32 interface? (Asking this because bugging Walter with
>>>  "please add this and that" may not be a viable solution...)
>>
>>Just add anything missing as needed.
> 
> 
> I was wondering if we could use the wiki as a collaborative windows.d
> editing project?  If everyone was conscientious about it every time you added a delaration to your own local windows.d file you could check the wiki and add it to the windows.d page if it did not exist.  Then you could also periodically cut and paste the code to you own local file to get everyone elses changes.

I've noticed that many useful Win32 constants, types, and prototypes aren't included in Phobos's windows.d.  Somehow I think we should have a unified effort to either add these to windows.d (if Walter is willing), or develop supplemental headers that work in friendly fashion with Phobos.  A wiki could be a good way to do a collaborative project.

I've come up with 3400+ lines of Win32 symbols that aren't in windows.d (maybe some of them should be).  If you want to use it, just add "import win.d;" in your import section.

You can download my file at:
http://www.geocities.com/jccalvarese/d/win.zip

I'm sure my header isn't perfect.  It's not particularly organized.  It may still include conflicts with Phobos.  (I've removed conflicts as I've found them, but they can be hidden.)  If you find any problems with it, let me know and I can try to fix it.

Justin

"Patrick Down" <Patrick_member@pathlink.com> wrote in message news:b9u622$23pe$1@digitaldaemon.com...
> I was wondering if we could use the wiki as a collaborative windows.d
> editing project?  If everyone was conscientious about it every time
> you added a delaration to your own local windows.d file you could check
> the wiki and add it to the windows.d page if it did not exist.  Then you
> could also periodically cut and paste the code to you own local file to
> get everyone elses changes.

Sounds like a good idea. Just be careful not to violate Microsoft's copyrights on it.

It would be really nice if this project was completed and included in the compiler distribution as soon as possible.  I myself have added hundreds if not more lines from windows.h and kin just to get small demos up and running.  Quite the PITA.  Plus the variants seem to be prolifigating.  It would be wise to nip this in the bud.

Not to mention recently introduced incompatibilities so that older ones like Pavel's have problems compiling with the newer DMD variants.  And Pavel is not around apparently to fix it, or no longer cares.

Sean

"J C Calvarese" <jcc7@cox.net> wrote in message news:b9ubk3$2a08$1@digitaldaemon.com...
> Patrick Down wrote:
> > In article <b9u0tu$1tv6$1@digitaldaemon.com>, Walter says...
> >
> >
> >>>- What is the strategy of extending windows.d into a full
> >>>  Win32 interface? (Asking this because bugging Walter with
> >>>  "please add this and that" may not be a viable solution...)
> >>
> >>Just add anything missing as needed.
> >
> >
> > I was wondering if we could use the wiki as a collaborative windows.d
> > editing project?  If everyone was conscientious about it every time
> > you added a delaration to your own local windows.d file you could check
> > the wiki and add it to the windows.d page if it did not exist.  Then you
> > could also periodically cut and paste the code to you own local file to
> > get everyone elses changes.
>
> I've noticed that many useful Win32 constants, types, and prototypes aren't included in Phobos's windows.d.  Somehow I think we should have a unified effort to either add these to windows.d (if Walter is willing), or develop supplemental headers that work in friendly fashion with Phobos.  A wiki could be a good way to do a collaborative project.
>
> I've come up with 3400+ lines of Win32 symbols that aren't in windows.d (maybe some of them should be).  If you want to use it, just add "import win.d;" in your import section.
>
> You can download my file at: http://www.geocities.com/jccalvarese/d/win.zip
>
> I'm sure my header isn't perfect.  It's not particularly organized.  It may still include conflicts with Phobos.  (I've removed conflicts as I've found them, but they can be hidden.)  If you find any problems with it, let me know and I can try to fix it.
>
> Justin

In article <3EC2ABA2.3060208@viasic.com>, Bill Cox says...
>
>Hi.
>
>I like the idea of a Wiki, although a SourceForge project might be better.  However, I'm not very excited about the thought of programming directly to the win32 api.  MFC is so much more productive, especially with ClassWizard.

A SourceForge project is PITA, because:
- it requieres everyone to have CVS clients installed;
- syncronisation is a problem, because one has to pray that noone has done a
post just before himself;
- there are people who have no experiance with CVS including myself. So please
correct me where appropriate.

>OTOH, developing a good GUI interface library for D from scratch is an enourmous task.

However, a full API translation would be desirable anyway, right? BTW, i have to actually start writing the damn tool. :>

>Is there any other way?  Are there any good share-ware GUI libs out there we could write wrappers for?  That could help in porting GUIs to Linux, which is currently a nightmare.
>
>We currently write our GUIs twice: once for Windows and once for Linux.
>  he MainSoft stuff for porting to Linux makes for bad Linux interfaces.
>  Running GTK+ on Windows isn't yet stable enough, and may make a bad
>Windows interface.  An alternative is Java, which is nice, but then we've got debugging and installation headaches.

There are following alternatives:

== GUI native wrappers ==

* TK (known as TCL/TK) - accesible from C. - good for simple interfaces.

* wxWindows - a C++ library, fairly powerful but somewhat inconsistent across platforms (Win32, GTK+, MacOS-X). I guess a C wrapper exists. The library relies on inheritance as opposed to callback functions. I'm not sure how well these things can be ported to D.

Another whole class are client-draw libraries - like FLTK, Qt, FOX, Amulet and others. They simply wrap OSes primitive drawing capabilities and use them to draw in a platform-independant manner. The ones named here are C++. It doesn't seem to make much sense to wrap these - apart from Qt on Unix only. However, some of these may be taken as a basis to write a clent-draw library for D. Amulet, e.g., shows some unique features.

I think a skinnable clientdraw library based on SDL (directdraw-like interface) might make sense. I was considering writing one like that in Sather. Skinnability would allow to adjust it to a specific platform's look and feel. There has already been a working application written this way - Pixel32, a Photoshop clone, done in FreePascal using LibSDL. And i guess OpenOffice and Mozilla use a kind of a similar concept.

http://pixel32.box.sk/

And finally, there are people who think that all this platform-independance is crap, and no wrapper may ever cover everything - and they may be right. The core of an application is platform-independant, and cooperates through a well-defined interface with a platform-dependant part. The overal result may be very impressive. Look at this and read their publications:

http://www.abisource.com/

-i.

"Walter" <walter@digitalmars.com> wrote in news:b9v4em$um$1 @digitaldaemon.com:

> 
> "Patrick Down" <Patrick_member@pathlink.com> wrote in message news:b9u622$23pe$1@digitaldaemon.com...
>> I was wondering if we could use the wiki as a collaborative windows.d
>> editing project?  If everyone was conscientious about it every time
>> you added a delaration to your own local windows.d file you could check
>> the wiki and add it to the windows.d page if it did not exist.  Then you
>> could also periodically cut and paste the code to you own local file to
>> get everyone elses changes.
> 
> Sounds like a good idea. Just be careful not to violate Microsoft's copyrights on it.

Yes this is one of the things I was worried about and I'm no expert on the legal issues.  Does any one know anything about this?

Hi, Ilya.

Ilya Minkov wrote:
> In article <3EC2ABA2.3060208@viasic.com>, Bill Cox says...
> 
>>Hi.
>>
>>I like the idea of a Wiki, although a SourceForge project might be better.  However, I'm not very excited about the thought of programming directly to the win32 api.  MFC is so much more productive, especially with ClassWizard.
> 
> 
> A SourceForge project is PITA, because:
> - it requieres everyone to have CVS clients installed;
> - syncronisation is a problem, because one has to pray that noone has done a
> post just before himself;
> - there are people who have no experiance with CVS including myself. So please
> correct me where appropriate.

CVS deals with the syncronisation problems mostly automatically.  It does a three-way merge, which means it knows what version you started with, what changes have been made since then by others, and what changes you've made.  It combines all changes that don't overlap.  It sounds scary, but it actually works really well.

I think I understand why many people haven't dealt with CVS: lots of programmers work alone.  CVS is mostly for teams of programmers.

I'd strongly recomend that anyone wanting to work with other programmers install and learn CVS.  It's well worth the effort.  There's a good Windows client that comes with the Cygwin install from RedHat.  I also recomend that programmers working on Windows install Cygwin.  It's a good productivity tool for most programmers who use it, and it's fairly easy to install.  Here's a link:

http://sources.redhat.com/cygwin/

>>OTOH, developing a good GUI interface library for D from scratch is an enourmous task.
> 
> 
> However, a full API translation would be desirable anyway, right?
> BTW, i have to actually start writing the damn tool. :>
> 
>>Is there any other way?  Are there any good share-ware GUI libs out there we could write wrappers for?  That could help in porting GUIs to Linux, which is currently a nightmare.
>>
>>We currently write our GUIs twice: once for Windows and once for Linux. 
>> he MainSoft stuff for porting to Linux makes for bad Linux interfaces. Running GTK+ on Windows isn't yet stable enough, and may make a bad 
>>Windows interface.  An alternative is Java, which is nice, but then we've got debugging and installation headaches.
> 
> 
> There are following alternatives:
> 
> == GUI native wrappers ==
> 
> * TK (known as TCL/TK) - accesible from C. - good for simple interfaces.
> 
> * wxWindows - a C++ library, fairly powerful but somewhat inconsistent across
> platforms (Win32, GTK+, MacOS-X). I guess a C wrapper exists. The library relies
> on inheritance as opposed to callback functions. I'm not sure how well these
> things can be ported to D.
> 
> Another whole class are client-draw libraries - like FLTK, Qt, FOX, Amulet and
> others. They simply wrap OSes primitive drawing capabilities and use them to
> draw in a platform-independant manner. The ones named here are C++. It doesn't
> seem to make much sense to wrap these - apart from Qt on Unix only. However,
> some of these may be taken as a basis to write a clent-draw library for D.
> Amulet, e.g., shows some unique features.
> 
> I think a skinnable clientdraw library based on SDL (directdraw-like interface)
> might make sense. I was considering writing one like that in Sather.
> Skinnability would allow to adjust it to a specific platform's look and feel.
> There has already been a working application written this way - Pixel32, a
> Photoshop clone, done in FreePascal using LibSDL. And i guess OpenOffice and
> Mozilla use a kind of a similar concept.
> 
> http://pixel32.box.sk/

A skinnable GUI sounds pretty cool...  it might have lots of uses like porting to multiple platforms, or having custom skins optimized for PDAs or cell phones.  The lack of built-in GUI in HTML has driven people to make custom bitmaps for their stuff, and it looks very cool.

> And finally, there are people who think that all this platform-independance is
> crap, and no wrapper may ever cover everything - and they may be right. The core
> of an application is platform-independant, and cooperates through a well-defined
> interface with a platform-dependant part. The overal result may be very
> impressive. Look at this and read their publications:
> 
> http://www.abisource.com/

This is basically what we do now.  We haven't set it up yet, but we plan to have our GUIs comunicate with our EDA tools through TCL commands, with no calls directly to the tools.  It's a nice way to go, but you wind up having to hire at least one GUI expert for each platform, and the GUIs are always somewhat out of sync.

I guess I'd prefer a skinnable GUI library, but frankly, I'm not a very good GUI programmer, so I doubt I'd do anyone much good by contributing to such an effort.

Bill