[kepler-dev] Proposed Future Kepler Configuration System

[Christopher Brooks]

Hi David,

Sorry to respond to my own email, but perhaps we should look
at extracting what is necessary to embed the Vergil graph
viewer in any system, be it Eclipse or Netbeans or
anything else.

This is one of the goals of Triquetrum.  We had some
success embedding Vergil in Eclipse using the AWT/SWT
bridge.  Looking at what it would take to add extension
points to the graph viewer would be very valuable.

I believe the issue is that the graph viewer really wants
to be in a top level window.  Being able to embed it
in a JPanel or JFrame would help.

Edward and I considered using a more generic Eclipse
graph displayer, but realized that the problem was that
the solution would be very generic and lacking the
tight interaction that we have now.  In terms of usability
and user experience, we would basically be going back to
Ptolemy 0.2.  This points to reusing the Vergil graph
viewer and dialogs.

Also, Thomas Feng has developed some code that makes it easier
to embed drop down entry boxes in the toolbar, which
makes it easier to add new user functionality.

_Christopher

Christopher Brooks wrote:
> Hi David,
> You are reinventing the wheel here.  Configuration of
> systems have been written time and time again.  I'm not saying
> necessarily saying use Netbeans or Eclipse, but you would
> be wise to review them and survey other systems.  Defining
> your requirements as you have done in the forum is an excellent
> first step.
> 
> BTW - The reason the Ptolemy uses such an arcane system was because we
> wanted to try to push the Ptolemy notion of hierarchy and MoML and
> "eat our own dog food".  While this was a successful experiment,
> the result has been confusing for users other than the
> initial developers.  Also, the Java developers really dropped
> the ball with the UI.  Tcl had a much better UI and a
> previous effort that we developed called Tycho was much
> easier to configure.
> 
> Kepler has a simple configuration system in place already with
> the bundles and the uiMenuMappings_en_US.properties files.
> Maybe you need to make a stronger case as to why those
> are not sufficient?
> 
> Also, the ISO codes are the way to go for internationalization.
> Applying a different naming system will cause problems later.
> Sticking with best internationalization practices is a win.
> 
> I think a configuration system is a good idea, but reinventing
> one is not.
> 
> _Christopher
> 
> 
> 
> David Welker wrote:
>> Hi Christopher,
>>
>> Thanks for your suggestion. A couple of thoughts on your ideas 
>> regarding closely integrating with Eclipse or Netbeans.
>>
>> 1) The scope of your suggestion is much greater than the incremental 
>> configuration project I had in mind. It goes quite a way beyond mere 
>> configuration and perhaps has implications for distribution, 
>> integration with other tools, how modules are defined and interact, 
>> how we build, and how developers work. It is not clear to me to what 
>> extent one can choose to just buy into these platforms incrementally, 
>> without more or less converging onto the Netbeans or Eclipse way of 
>> doing things. This would be a rather large, rather than small, effort. 
>> It would be a major decision.
>>
>> 2) To really integrate with Netbeans or Eclipse would involve very 
>> significant refactoring of the GUI. (There will, of course, be some 
>> refactoring of how the GUI is configured with the project I am 
>> contemplating, but probably on a smaller scale.) My question is 
>> Ptolemy in doing that sort of work? I could imagine a scenario (after 
>> careful evaluation of costs and benefits) where Ptolemy and Kepler 
>> work towards a common standard based on either Eclipse or Netbeans. 
>> But I think the costs for Kepler are much higher if we were to try to 
>> go it alone (because so many changes are implied in Vergil by such a 
>> move).
>>
>> 3) I can definitely imagine benefits to closely integrating Kepler 
>> with Eclipse or Netbeans. For example, allowing users to modify actor 
>> code by right-clicking on it from inside of Kepler. It could also 
>> define a more convenient distribution model, allowing us to more 
>> seamlessly provide updates to users. I can also imagine costs 
>> associated with the complexity of integrating Kepler into either of 
>> these ecosystems.
>>
>> 4) If the goal is to simplify configuration, then integration with 
>> Eclipse or Netbeans likely contradicts that goal. Configuration would 
>> be more complicated, because both Netbeans and Eclipse have fairly 
>> complex configuration systems in place. I could roll out a custom 
>> configuration system that is simpler and easier to use much faster 
>> than we could integrate with either the Eclipse or Netbeans ecosystem. 
>> So, any decision to integrate with these ecosystems should be based on 
>> concrete benefits provided by integrating with the tool sets available 
>> in these platforms, not any illusions that this would simplify 
>> configuration.
>>
>> 5) If we use either Netbeans or Eclipse as a platform, why we would 
>> not be officially "blessing" one IDE over another, we would in fact be 
>> favoring one over another. The best tools for making Netbeans plugins 
>> and modules for Netbeans is Netbeans itself. The same is true of 
>> Eclipse. We should realize that if we do decide to integrate with a 
>> particular IDE, we are making one IDE much easier to use than others, 
>> even while not officially preventing the use of other tools.
>>
>> Overall, after an initial examination, I am somewhat skeptical that we 
>> should be integrating with either Eclipse or Netbeans. I think it 
>> would be a fairly large amount of work, would make configuration more 
>> complex and not simpler, and would in a de facto way tie us to a 
>> particular IDE. Right not, I am not entirely convinced that the 
>> concrete benefits I see (mainly having to do with distribution of new 
>> modules and perhaps integrating the code development capabilities of 
>> Eclipse or Netbeans with Kepler/Ptolemy) are worth the work and added 
>> complexity. But, I am definitely open and am willing to be convinced.
>>
>> David
>>
>>
>>
>>> Hi David,
>>>
>>> Thanks for summing up the current configuration details.
>>>
>>> I suggest reviewing how Eclipse and Netbeans do platform rich client
>>> platforms (RCP).  Is it necessary to invent yet another system?
>>> You may want to compare and contrast your design with prior art as
>>> they have addressed similar issues.
>>>
>>> _Christopher
>>>
>>> David Welker wrote:
>>>> Hello everyone,
>>>>
>>>> I have done a basic review of the current Kepler Configuration 
>>>> System and have developed a proposal for a new Kepler Configuration 
>>>> System.
>>>>
>>>> Please see my proposal here:
>>>>
>>>> https://dev.kepler-project.org/developers/teams/framework/kepler-configuration/proposed-future-kepler-configuration-system/ 
>>>>
>>>>
>>>> Also, I have briefly documented a subset of the existing 
>>>> configuration files. If anyone wants to add to or elaborate on that 
>>>> documentation, they should feel free to do so. That basic 
>>>> documentation is available here:
>>>>
>>>> https://dev.kepler-project.org/developers/teams/framework/kepler-configuration/current-kepler-configuration/ 
>>>>
>>>>
>>>> Anyway, I am moving forward with a prototype that implements my 
>>>> proposal. However, in parallel, I would like to have a discussion 
>>>> about how people feel about the proposal and any additional 
>>>> configuration-related features that they would like to see.
>>>>
>>>> Thanks!
>>>>
>>>> David Welker
>>>> _______________________________________________
>>>> Kepler-dev mailing list
>>>> Kepler-dev at kepler-project.org
>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>
>>
>>
> 

-- 
Christopher Brooks (cxh at eecs berkeley edu) University of California
CHESS Executive Director                      US Mail: 337 Cory Hall
Programmer/Analyst CHESS/Ptolemy/Trust        Berkeley, CA 94720-1774
ph: 510.643.9841 fax:510.642.2718	      (Office: 545Q Cory)
home: (F-Tu) 707.665.0131 (W-F) 510.655.5480