forward references

Ant · Joined: 06 Mar 2004 Posts: 306 Location: Canada

I created this topic in the hope it can be forget soon.

I still don't know how the src tree is organized and how to
get the linux version and how to integrate the windows
and linux version (I'll get to that).

To try to understand the forward reference problem I tried
to compile the graphics package by it self - lots of
forward references, as expected.
So I moved the import declarations to the classes
bodies and the forward references seem to be gone.
(can't be cure of that because other erros surfaced...)

Many new errors appeared... :(
but I guess that's this project main job...

Ant

JJR · Joined: 22 Feb 2004 Posts: 1104

Hi Ant,

Nice to here you were able to get somewhere despite the obstacles. I'm still trying to get familiar with the subversion setup myself. And the way we have the directories and build system orgainized currently may not be the most intuitive.

The way I've been building the system is to run the makefile in the .\d\dwt\src directory...that's the one I've been working on. As it was arranged I was already able to get past the forward-reference problems in the graphics directory modules WITHOUT the intra-class imports (I had to arrange the files very carefully, though, to get it to work). I was also to the stage of various other errors stopping the compiles there.

The widget directory modules are where I'm currently stalled at for forward references (rearranging the compile process doesn't work there). I'd like to see if intra-class imports will fix that as you managed to do with the graphics modules (your's obviously is the better solution). If we can manage to fix that, which I'm sure is possible, the porting job does just become a huge hunt and fix the errors game as the compile process continues. That would be a good start since that's how we've been progressing through this in the first place.

Thanks for looking into this, Ant. Perhaps, when you get Subversion figured out, you can upload your changes to the server. As for the Linux version, none currently exists. I've just been working on a Linux makefile that I haven't actually submitted to subversion yet. It works basically in compiling as far as the Windows version, but there is no Linux port made yet.

Take care,

John

PS. What IDE are you using? What DMD version are you using?

Ant · Joined: 06 Mar 2004 Posts: 306 Location: Canada

brad · Posted: Mon Mar 08, 2004 11:01 am Post subject:

Ant,

We have only attempted a port of the Windows side of SWT. You'd probably want to put the Linux stuff that is different in the dwt/internal/??? folder. The main class to differ will probably be os.d.

This will require you doing version (linux) {} and version (Win32) {} blocks at the top of each module for imports. I hadn't given this much thought, but maybe the place to do it is in the os.d module itself. Then we don't have silly imports at the top of each module like:

Ant · Joined: 06 Mar 2004 Posts: 306 Location: Canada

brad · Posted: Mon Mar 08, 2004 4:45 pm Post subject:

What about:

dwt/internal/os.d that has versions that import dwt/internal/win32/os.d and dwt/internal/linux/os.d?

That way they're different files and yet the compiler version() {} still handles one piece of source code for all platforms.

I'm sure there are other files that will be different from platform to platform, but do you agree that we want to keep all of the code together in one big block for maintainability? We'd reuse heavily what we could.

BA
_________________
I really like the vest!

Ant · Joined: 06 Mar 2004 Posts: 306 Location: Canada

brad · Posted: Mon Mar 08, 2004 6:55 pm Post subject:

okay, I'll pull the Linux version and take a look.
_________________
I really like the vest!

JJR · Joined: 22 Feb 2004 Posts: 1104

There is actually no internal/linux package. If you download the linux port of SWT you'll see that for the Linux platform they create a package to interface to the gtk toolkit (ring any bells Wink

. That's in the internal/gtk directory.

The linux src is called:

swt-3.0M6-linux-gtk.zip

Within the package you'll find:

swt-pisrc.zip

which contains the "org\eclipse\swt\internal\gtk" package. This package maps the swt calls to gtk interface calls much like the win32 version thus allowing the use of a common high level interface. This was the whole benefit of swt, I thought.

If we follow the same structure, we should be able to integrate the linux and win32 source together since they don't reference the same directories. One uses internal/win32 and the other uses internal/gtk. The higher level interfaces seem to share the same code as long as the proper interface can be activated (with version control?). So I think it's still possible without making a whole separate linux version.

But maybe I'm over-simplifying it all. Ah back to my studies before I get to caught up in this....

Take care,

John

brad · Posted: Mon Mar 08, 2004 8:27 pm Post subject:

That's what I was talking about. We need to port dwt.internal.* to whatever platform we choose. If we don't want to bother with motif, then we can just call the version(linux) {} stuff dwt.internal.gtk. If there's another linux library to port to (I don't know what KDE uses), then maybe we don't have version(linux) but rather version(gtk). I don't think we're limited to the reserved win32 and linux, are we?

BA
_________________
I really like the vest!

brad · Posted: Sun Mar 14, 2004 11:02 pm Post subject:

From Andy Friesen, who reworked dwt.internal.win32 a bit recently. I will attempt to get that code into Subversion tonight...

JJR · Joined: 22 Feb 2004 Posts: 1104

This is good, I guess. So nobody was able to just use intra-class imports to fix the problem? I thought Ant had made some of it work by doing it the import way. If Andy's method fixes the problem thoroughly, I guess we should go with it. It will be intereseting to look over his changes. Good to see someone is able to some work on the project, nonetheless. I've been swamped too.

Concerning other interfaces on Linux, Qt is the one used on KDE. I doubt it would be easily portable since I believe the interface is mostly C++. GTK is actually a pretty safe bet for most Unix-like platforms. Someday someone may like to consider a direct port to Mac OS X, but I don't know how that would work. It's not important for now anyway.

By the way, why hasn't Andy signed up on this BBS? Smile

Later,

John

andy · Joined: 15 Mar 2004 Posts: 71

yo.

SWT doesn't work quite the same way as other toolkits of the same sort, as I understand it. The interface is consistent across platforms, but the implementation is not. IBM basically rewrote it for every platform.

Edit: Or not. Looks like Ant has already looked into this.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear

Ant · Joined: 06 Mar 2004 Posts: 306 Location: Canada

andy · Joined: 15 Mar 2004 Posts: 71

I think it's more important that the separate source trees actually work first. One problem at a time.

Once that's out of the way, though, consolidating the commonality does seem like the best approach. Duplicated code is rarely the Right Thing.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear