www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.dwt - Imports in DWT

reply Frank Benoit <keinfarbton googlemail.com> writes:
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
Feb 26 2008
next sibling parent reply bobef <bobef abv-nospam.bg> writes:
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.
Feb 26 2008
next sibling parent reply Frank Benoit <keinfarbton googlemail.com> writes:
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?
Feb 26 2008
next sibling parent bobef <bobef abv-nospam.bg> writes:
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.
Feb 26 2008
prev sibling parent reply bobef <bobef abv-nospam.bg> writes:
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.
Mar 01 2008
next sibling parent reply Bjoern <nanali nospam-wanadoo.fr> writes:
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
Mar 01 2008
parent reply bobef <bobef abv-nospam.bg> writes:
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.
Mar 02 2008
parent Bjoern <nanali nospam-wanadoo.fr> writes:
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.
Mar 02 2008
prev sibling parent reply John Reimer <terminal.node gmail.com> writes:
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
Mar 01 2008
parent bobef <bobef abv-nospam.bg> writes:
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
Mar 02 2008
prev sibling next sibling parent BCS <BCS pathlink.com> writes:
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.
Mar 04 2008
prev sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
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)
Mar 04 2008
prev sibling next sibling parent torhu <no spam.invalid> writes:
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.
Feb 26 2008
prev sibling next sibling parent Jesse Phillips <jessekphillips gmail.com> writes:
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).
Feb 26 2008
prev sibling next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
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.
Feb 27 2008
prev sibling parent Ty Tower <tytower hotmail.com.au> writes:
Further wouldn't it make sense to have 
dwt.graphics.*
and the other normal wildcards such as   "?" and "[set]"
Mar 02 2008