I wonder what is the best import strategy for DWT. Well, i know there is no single "right way". So what are your thoughts?

1. import everything explicitely

2. have a dwt.all module that imports really all

3. have groups import modules aka tango

4. publically import all types used in the API of a widget.
   So dwt.Button would publically import:
    - dwt.DWT
    - dwt.widget.Control
    - dwt.widget.Composite
    - dwt.events.SelectionListener
    - dwt.graphics.Point
    - dwt.graphics.Image


5. publically import API types, but only manually picked ones
   dwt.layout.GridLayout:
    - dwt.layout.GridData
   dwt.Button:
    - dwt.DWT
    - dwt.events.SelectionListener

Have both dwt.all and dwt.group.stuff and let the user choose what to use. I tried to compile DWT into a lib today with bud, so here is a little contribution.

bobef schrieb:
> Have both dwt.all and dwt.group.stuff and let the user choose what to use. I tried to compile DWT into a lib today with bud, so here is a little contribution.

What groups do make sense for you?

dwt.widgets.all ?

Does it make sense to import all widgets but not the related events?

BTW, did it work with bud?

Frank Benoit wrote:
> I wonder what is the best import strategy for DWT. Well, i know there is no single "right way". So what are your thoughts?
> 
> 1. import everything explicitely
> 
> 2. have a dwt.all module that imports really all
> 
> 3. have groups import modules aka tango
> 
> 4. publically import all types used in the API of a widget.
>     So dwt.Button would publically import:
>      - dwt.DWT
>      - dwt.widget.Control
>      - dwt.widget.Composite
>      - dwt.events.SelectionListener
>      - dwt.graphics.Point
>      - dwt.graphics.Image
> 
> 
> 5. publically import API types, but only manually picked ones
>     dwt.layout.GridLayout:
>      - dwt.layout.GridData
>     dwt.Button:
>      - dwt.DWT
>      - dwt.events.SelectionListener

Personally I'm not very keen on importing more than I really need.  My app's already big enough.  So I guess I would prefer alternative 4 or 5, or just leave it the way it is.

The problem with using dwt.all is that if you use bud or rebuild, they can't see the difference between modules you import and use, and modules you import but don't use.  If you import a module, but don't use it, it'll still get compiled and linked.  So you're back to a more manual (makefiles, etc) build process if you want to avoid bloating your executable.

dwt.all is handy, but people should probably be aware the effect it has if they use it.

I tried building importing bobef's dwt.all into controlexample.d, and building it with bud.  The resultant exe was 3.0 MB.  Without dwt.all, it was 2.1 MB.  I got the same numbers for my own app, which is odd since it uses a lot less dwt modules than controlexample does.

Of course, not everyone cares whether their app is 2 or 3 MB.

On Tue, 26 Feb 2008 15:10:57 +0100, Frank Benoit wrote:

> I wonder what is the best import strategy for DWT. Well, i know there is no single "right way". So what are your thoughts?
> 
> 1. import everything explicitely
> 
> 2. have a dwt.all module that imports really all
> 
> 3. have groups import modules aka tango
> 
> 4. publically import all types used in the API of a widget.
>     So dwt.Button would publically import:
>      - dwt.DWT
>      - dwt.widget.Control
>      - dwt.widget.Composite
>      - dwt.events.SelectionListener
>      - dwt.graphics.Point
>      - dwt.graphics.Image
> 
> 
> 5. publically import API types, but only manually picked ones
>     dwt.layout.GridLayout:
>      - dwt.layout.GridData
>     dwt.Button:
>      - dwt.DWT
>      - dwt.events.SelectionListener

I like the idea of option 5. The reason for this is when you import a module there are things that are most likely going to imply another import to use it. Where if you do 4 there are things that may or may not be used. Mixing this with groups might also be good. I think the all option might be just a little too much (then again it would make translating those * easier).

Frank Benoit Wrote:

> bobef schrieb:
> > Have both dwt.all and dwt.group.stuff and let the user choose what to use. I tried to compile DWT into a lib today with bud, so here is a little contribution.
> 
> What groups do make sense for you?
> 
> dwt.widgets.all ?

Yes, I think the most common ones. widgets.all, events.all, graphics.all, etc. But just as an option...

> 
> Does it make sense to import all widgets but not the related events?
> 

As much as importing a single widget without the related events.

> BTW, did it work with bud?

No, but because I am using old version of Tango. I can't swtich to new one because the ftp client is broken there. Otherwise I am sure it works.

I'm fine with point 1. Public imports make it hard to see where are the classes coming from and they bloat up the executable size, as torthu mentioned.

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.

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

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.

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.

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