Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide4edu-dev] Conference Call Meeting Minutes

I'd like to take a few minutes to clear up what might be considered an inconsistent message...

I think that removing our use of internal code is an important consideration. However, it is secondary to writing functionality that will directly benefit our user community. Removing the use of internal code (and, by extension, the warnings) should occur naturally as we change the code based on new/shifted paradigms of interacting with the user.

We absolutely needed to redo the project creation and class creation wizards because we were ham-stringed by the current implementations: it was impossible/very difficult to make the changes we needed to make in functionality without an awful lot of "weirdness". I think our new solution is quite good.

Over time, more and more of the project will go this way. We will start by patching the forked code and move eventually to wholesale replacement. Some of this will be motivated by changes in those internal APIs as the JDT changes underneath our implementations. Ultimately, by using only public APIs, we will insulate ourselves from those changes and make our code more robust and resilient.

I think this feeds directly into the last thing I said on the call. I realize that I was being preachy, but it's important. Remember that you and those who follow you will spend far more time reading your code than you do writing it.

Wayne


Brenda Sadoway wrote:
I took meeting minutes of our call today as Wayne requested, so those not in the call can see what was brought up.

Friday, February 12, 2010 Conference Call Meeting Minutes

Attendance: Wayne, Cory, Miles and Brenda

Here’s what we discussed:
-        Internal code:  There’s a balance between deciding when to rewrite code so it doesn’t use internal code, and              when it’s practical to use it and accept the consequences.  For example, the project wizard was redone so that          it’s tailored to our project without using internal code, but there are many examples where this is not the case.
-        Wayne would prefer to focus on the fundamental level: committing code that will directly affect and benefit            the user, rather than rewriting to remove the use of internal code for the sake of increasing our comfort level.
-        Rather than suppressing warnings, Wayne suggested keeping them there because ensuring we don’t forget                about them may help in the long run.
-        Scheme interpreter NexJ: we should make sure it looks like it will work before pursuing the legal side of                   getting permission to use it, but it looks promising.
-        Scheme bugs in Bugzilla apply to the code that probably can’t be committed, although the UI side of it can             still be looked at.
-        Scheme debugging could/should be looked into at some point.
-        The concept of a Scheme Outline view: what would it look like and what would be in it?  Would it be useful?
-        Miles might look into simplifying menus and toolbars in Java Lite.
-        Cory might try making an RCP App to pull in menus and toolbars to see how effective this method is.
-        Brenda might look into the UI of the Scheme perspective to see what can be improved.

-Brenda
------------------------------------------------------------------------

_______________________________________________
ide4edu-dev mailing list
ide4edu-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ide4edu-dev

--
Wayne Beaton, The Eclipse Foundation
http://www.eclipse.org

I'm going to EclipseCon!
http://www.eclipsecon.org



Back to the top