Re: [eclipse-dev] commentary on the 3.3 plan

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Hi Brannon,

Thanks for the feedback.  The relevant
people have likely heard your comments, but I think for commentary on specific
plan items your best bet is to add a comment directly into the plan item
bug report (linked from the plan document).  That will make sure your
comments reach the people who end up working on them, and that your comments
aren't lost in the shuffle.

Just to clarify, the statement "Java
1.4.2 platforms are used for most Eclipse development" means that
the committers building Eclipse itself are mostly using 1.4.x VMs - it
is not a statement about the Eclipse user community, many of which have
likely moved up to the latest VMs where available.

You may need to elaborate on what "tooltip"
bug you are referring to.  There may be 87 open bugs containing the
word "tooltip", but there are also 575 open bugs containing the
word "foo".  So, based on this criterion, it sounds like
we should forget about tooltips and focus on improving our "foo"
;)

John

"Brannon King" <brannonking@xxxxxxxxx>
Sent by: eclipse-dev-bounces@xxxxxxxxxxx

16/08/2006 06:52 PM

Please respond to
"General development mailing list of the Eclipse project." <eclipse-dev@xxxxxxxxxxx>

To	<eclipse-dev@xxxxxxxxxxx>
cc
Subject	[eclipse-dev] commentary on the 3.3 plan

First, I apologize for not being around to help create
the plan. Second, I
apologize for posting this on the platform newsgroup without realizing
it
should have been posted to this list instead. Third, this document is
probably offensive, but I mean it in the best way possible. If I were better
with words and feelings, I would change it. Anyway...

First critique: the items listed under "Components" are so general
that 
they're immeasurable. I'll assume that their description is filled out
in 
their associated bug listings.

I think you are right on the money with the enhancements for launching
support. The more we can clarify that, simplify that, expand that -- the
more we can easily create other development tools (and not to mention that
the thing is darn confusing for first-time users!)

Concerning the port of SWT to win64. That is going to be a beast. It's
bigger than anyone thinks because all over the place we have hard coded
pointer sizes. It's especially bad in OpenGL selection code and other custom

io buffer stuff like the nio (and all the uses of it). This is a must-do,
but it will be the cause of bugs for years to come. I think most projects
have been smart enough to store their win32 handles in "long",
but this will

certainly expose everyone else! The thing is: this issue is going to happen
all over again when we move to 128bit OS. We need to handle the sizeof
issue

right during this fix or we're toast next round.

I think JFace has more fundamental problems than not supporting the entire
SWT widget set. How about making JFace objects have similar APIs (to reduce
the learning curve)? Or making their API similar to the SWT widgets (to
reduce the learning curve)? Or giving reasonable access to the widgets
they 
contain?

"GTK Printing". Okay. We have serious issues with printing. This
is one area

where cross-platform things fall to pieces. This needs to be addressed
in a 
major way. We need cross platform printing APIs that provide a range of
options (collate, selection, quality, etc.) on all platforms. (They can
provide the superset if a particular option set is not available on a 
platform.) Bugs like this (basic daily use functionality) that are not
fully

supported should be first priority.

The other bug like the printing option support is that of tooltip support.
"tooltip" does not even show up in the plan, yet a bug search
on it shows 87

open bugs. There are some cross-platform issues here again. But 87 bugs!
Any

keyword with that many bugs ought to be on the 3.3 plan, don't you think?
The document in general tends to lead away from bug fixes in favor of new
features. I'm not real sure that is wise. It seems about time that we step
back and do a serious bug-fix round. 3.2 is getting wide usage; the bugs
are

piling up by the thousands.

"Provide access to more native controls" Uh, to be honest, I
think this is 
exactly the opposite of where we want to go. I thought we were working
for 
cross-platform execution, not the other way around. I would love a nice
2d 
table widget. Numerous other people would as well, but not at the cost
of 
losing cross-platform support. Nobody minds a custom-drawn table that looks
nice. The current 1d tables in SWT look great. We don't need MS's 
ComCtrl.dll (or whatever) for that.

"Performance Focus". I think performance is doing pretty darn
well. The only

time I notice significant delays is on creating contextual help or when
the 
reconciler runs. I think those issues are going to go away as we all get
dual-core processors. If you've got time to work on performance, I'd rather
have more MMX/SSE/2/3 support in the JVM. It seems to me that is the most
bang for the buck. Memory is not an issue unless you're an embedded system.
(And in that case, preferences to disable features are a better way to
reduce memory.) Heck, let's use more memory for the contextual help, for
the

reconciler, the code completion, file streams, etc., and make those faster.

And one more nitpic: From the document: "Java 1.4.2 platforms are
used for 
most Eclipse development". Bunk. The 1.5 is good and stable. It's
been 
around for a while now. It's on all the development machines in my office.
Now having said that, I think it's great that we keep things well tested
in 
1.4. However, I see no reason for new APIs to support 1.4. And I feel for
all those 
whose company IT nazis have yet to approve 1.5 ;-)

Thanks for the good work.
______________________________
Brannon King
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯


_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipse-dev