↑ ↓ ← → 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
Content-Type: text/plain
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
↑ ↓←→ 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?
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.
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.
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
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.
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
↑ ↓ ←→ 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
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
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.
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)
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).
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.
Home
| Search
| C & C++
| D
| DMDScript
| News Groups
| index
| prev
| next