Jeffrey,
1) I am not sure what you mean by _supporting_ deprecated
methods.
SWT is not a language binding, so what happens in SWT PI is
internal
to SWT. We _use_ methods and objects in GTK. The plan is to
not
use any of the deprecated stuff. Right now you see them used,
just
because I had to start the 1.2->2.0 port somewhere, and
redoing
everything at once would be kind of too much. But eventually
they
will all be replaced.
I am going to post a short guide for SWT/GTK2 contributors
outlining
some very basic rules. In short, rule #1 is that all new code
going
into CVS is as close as possible to whatever we currently believe
is The Right Thing. That is, no temporary hacks that are known
to
be temporary hacks, and no new code doing things "the old way".
Rule #2 is that once you touch a piece of code, you get
(temporary)
ownership of that module, and your priority is to get that module
exactly right. E.g., if you try Eclipse and something fails
because
of a problem in List, you fix that problem in List and then go
into
full depth with the List, running little functional tests until List
is
done. This is in contrast to trying Eclipse again and then
saying
"look, now this piece here fails because of this bug in GC, so I
go fix it".
2) The best way to develop SWT is using Eclipse. When you
"Build Project", the build output is in the bin/ directory.
In
the case of SWT, it will contain the .class files, and also the
correctly arranged source for the library. You can even
C-compile it right in the bin/ directory.
You put the .so's somewhere on your java.library.path.
I use IBM JDK, where the JRE root has two subdirs, bin/ and
lib/. I just put the .so's in the bin/. This will be
different
for other JREs (I recall Sun being different).
The usual mechanism for running Eclipse in Eclipse (uncheck
SWT among "external plugins" and select "Run") seems
broken in the later builds on Linux. I personally use the
build dated Dec 06; it works. There is some new mechanism
to self-host, which works with the newest versions, but
I don't really understand how it works.
3) I am too tired do describe them right now. I'll
post my thoughts tomorrow. Basically I am trying to
convince myself that the OS resource called "Pango
Font Description", is the best underlying implementation
for SWT Font, even though it does not represent a
loaded font, and maps very nicely to our FontData;
but FontData don't have to be disposed of by the
application code, and therefore can not be represented
by OS resources. This provides for certain complications
when trying to get things that are specific to a real
font incarnation; in fact, with Pango one has to be
even more specific than what's available with SWT -
e.g. if you have a Font in SWT, you can ask it for its
metrics - which does not make sense in Pango before
you know the language (yes I know you can pass in
NULL). If you look at the current code for GC, you'll
see some other reasons why I am not happy with
the current state of the code. Of course it will get
resolved eventually, but I would really appreciate help
from someone who already has experience with Pango
(which I don't).
Boris
3)
_______________________________________________
platform-swt-dev mailing list platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev