Bjoern Wrote:

> bobef schrieb:
> > Frank Benoit Wrote:
> > 
> >> bobef schrieb:
> >>
> >> BTW, did it work with bud?
> > 
> > Tango is fixed. Bud works flawlessly. Here is what I did. Much shorter than the installation guide :)
> > 
> > bud all.d -clean -lib -full -allobj -O -release -inline
> > 
> > ...takes some time.. rename all.lib to dwt.lib, put the import libraries in dmd/lib, remove duplicates from dm/lib (they are older)
> > 
> > dmd myfle.d dwt.lib kernel32.lib gdi32.lib ole32.lib advapi32.lib shell32. lib user32.lib msimg32.lib gdiplus.lib comctl32.lib comdlg32.lib oleaut32.lib olepro32.lib usp10.lib oleacc.lib
> > 
> > ... compiles kind of slow and the exe is 1.8mb for hello world but it is loading pretty fast, so I guess it is OK.
> 
> Hi bobef,
> Just browsed the BUD sources, seems that Derek is going to offer us
> BUD 3.5 pre release... :)
> 
> Do you allready use DWT-Win for HTMLLayout instead of DFL ? regards bjoern

Not yet, but this is to come soon (read few days). But I will make an announcement, because I also updated the HTMLayout wrapper to the latest version that supports drag and drop and some other nice stuff.

bobef schrieb:
> Not yet, but this is to come soon (read few days). But I will make an announcement, because I also updated the HTMLayout wrapper to the latest version that supports drag and drop and some other nice stuff.
> 
That's fantastic! Thanks.

John Reimer Wrote:

> bobef wrote:
> 
> > Frank Benoit Wrote:
> > 
> >> bobef schrieb:
> >> 
> >> BTW, did it work with bud?
> > 
> > Tango is fixed. Bud works flawlessly. Here is what I did. Much shorter than the installation guide :)
> > 
> > bud all.d -clean -lib -full -allobj -O -release -inline
> > 
> > ...takes some time.. rename all.lib to dwt.lib, put the import libraries in dmd/lib, remove duplicates from dm/lib (they are older)
> > 
> > dmd myfle.d dwt.lib kernel32.lib gdi32.lib ole32.lib advapi32.lib shell32. lib user32.lib msimg32.lib gdiplus.lib comctl32.lib comdlg32.lib oleaut32.lib olepro32.lib usp10.lib oleacc.lib
> > 
> > ... compiles kind of slow and the exe is 1.8mb for hello world but it is loading pretty fast, so I guess it is OK.
> 
> 
> That's great to know.
> 
> I'm surprised, though, that you have to add all the implibs to the command line.  DWT.d declares a version(build) section with the necessary pragma(link, ...) directives for these libraries.  Does this not work with bud?  I guess the dsss pragma must be incompatible with bud's.
> 

I use bud only to build dwt.lib (6.6mb) and then use plain dmd to build the program, that's why I add all the libs. But maybe this pragma-s should remain not only for version(build), but for DMD also. It is pragma(lib,...) I think though.

> 1.8 mb is about average, I think.  I can't remember what the dsss size is, but I know that if you do a dsss build (creating a dwt library) and dsss install and then build the sample project, you get a smaller executable than if you used dsss directly to build all necessary dwt modules at once.
> 
> I'm thinking, though, that there is a lot of redundant information in this dwt port still.  I'm hoping we can shrink the size more.  We can get rid of the const declarations for one and use enum constants instead.
> 
> Another thing that makes dwt somewhat bloated is it's intrinsic platform
> detection.  It has many code sections to test whether it is on win98, NT,
> XP, Vista, and Win CE, and then does platform specific calls in those
> sections.  This is unfortunate bloat (wish these didn't use different API
> calls)... but it seems to add flexibility. Frank and I have already removed
> many of the Win CE code sections merely by making the "if" sections
> into "static if", but this does not solve many other situations that deal
> with Vista and earlier versions.  I guess those may as well be left in as a
> bonus because it makes the executables runnable across windows versions.
> 

Why don't you add versions? Like -version(xp) or something. At least I don't care for win98. I am not sure if this is a common case though.

> Some of the code has not been D'ized either, so there's much room for improvement there too.  But for now, porting is still the priority. :)
> 
> -JJR
> 
> 

Further wouldn't it make sense to have
dwt.graphics.*
and the other normal wildcards such as   "?" and "[set]"

Ty Tower wrote:
> Was it java that had
> 
> import dwt.graphics.*;
> and
> import dwt.graphics.Colour,Font,Cursor;
> 
> this saved a lot of typing. Can it not be done here? 

it has been proposed, discussed and not implemented. I didn't follow the thread in much detail so I don't known the details. But I don't think it's going to happen.

Ty Tower escribió:
> Was it java that had
> 
> import dwt.graphics.*;
> and
> import dwt.graphics.Colour,Font,Cursor;
> 
> this saved a lot of typing. Can it not be done here? 

My guess is that it is not allowed in D for performance reason. In Java, say you have:

---
package some.package;

import foo.*;

class SomeClass {
  Bar b;
}
---

Now, to find Bar, you have to look for a file Bar.java in the directory foo in the classpath, or in the current package. If neither of these exist (very rare), then the compiler has to search in each java file in the current package for a top-level class named Bar (there can be only one top-level public class in a java file, and the name must be the same as the class). You can see how fast lookups are in Java because of the way it is designed.

In D, if you have

import foo.*;

Bar b;

the compiler will have to parse each file in the foo package, searching in each of them for a public symbol called Bar. Not only that, but it has to performe semantic analysis in each of them to resolve compile-time stuff and see if Bar is actually being generated in compile-time. So... a huge compilation performance impact.

(BTW, that's the reason why I hate "all" imports)