FAQ
Cover
This is the archive Discourse for the Processing (ALPHA) software.
Please visit the new Processing forum for current information.

   Processing 1.0 _ALPHA_
   Suggestions
   Software Suggestions
(Moderator: fry)
   eclipse as editor
« Previous topic | Next topic »

Pages: 1 
   Author  Topic: eclipse as editor  (Read 1018 times)
vanwoods

Email
eclipse as editor
« on: Jun 25th, 2003, 9:44pm »

I fully appreciate the purpose of the simplified editor, but I am wondering if there has been any consideration for integration with something like Eclipse.
 
http://www.eclipse.org
http://www.eclipse.org/whitepapers/eclipse-overview.pdf
 
 
arielm

WWW
Re: eclipse as editor
« Reply #1 on: Jun 27th, 2003, 1:42pm »

i'm working with it also, something fantastic!
 
before that, i tried to work with sun's "forte / one" ide and it was so bad that i postponed my beginnings with java to never (well, after that i discovered p5 and i finally started!)
 
a quick comparision between p5 environment and eclipse (in term of working with Bagel a.k.a BApplet & co):
 
 
P5 ENV. PROS
1) minimalistic, just the required functions are present
 
2) easy to start coding and experimenting, more adapted than eclipse for fast "sketch and "run" stuff...
 
3) sketchbook metaphor
 
4) specific color syntaxing + goodies, like color(#rrggbb), etc...
 
 
ECLIPSE PROS
1) all the possible tools to enable easy java coding:
- outline (a tree showing all the classes, the fields, and the methods in your code and enables you to jump directly to them)
- refactoring (e.g. select a variable or method name and rename it then all the source will be updated automatically)
- finding reference of a variable or anything else in the code in one click
- code auto completion (while you type, eclipse is proposing you some options to complete your line, depending on the context)
- method signature hinting (if you rollover a method in your code, eclipse is showing you the possible "declaration patterns" of the method)
- lot more stuff...
 
2) real time compilation and hinting (while you type): it means that you catch 90% of the problems before pressing the "run button" (really an incredible feature)
 
3) "open" and fully configurable, both using xml files (e.g. for custom syntax highliting) and java coding (e.g for more complex customizing, like creating a Bagel "perspective" within eclipe):
 
 
ECLIPSE CONS
1) zillions of (unrelated) options, everywhere
 
2) before starting to play with Bagel, you have to configure some stuff...
 
3) running your code is a bit more painful than with p5 env.
 
4) forget about goodies like color(#rrggbb), or not putting "f" after floats, etc.
 
 
P5 ENV. CONS
1) not friendly for java beginners (eclipse real-time hinting is like a java teacher sitting next to you)
 
2) no "outline" (you spend a lot of time scrolling up and down!)
 
3) personally, i spend most of my time typing code, then pressing run and see compilation errors, most of them related to the java language (in eclipse, these errors are catched while i type!)
 
 
but to be honest, i may feel easy within eclipse now because i started before with p5 env.
 
 
finally, i think that some serious java developers could in the future develop a customized "eclipse Processing perspective" for the best of the two worlds!
« Last Edit: Jun 27th, 2003, 2:03pm by arielm »  

Ariel Malka | www.chronotext.org
fry


WWW
Re: eclipse as editor
« Reply #2 on: Jul 8th, 2003, 2:51am »

we've given it some thought.. in general our plan is to focus on having a functional internal editor which is oriented for the intro to programming/beginner/workshop set, and then support more advanced IDEs via some other interface (currently just the 'use external editor' option).  
 
there are lots of nice things in eclipse (like those that ariel mentioned) which we'd like to get more of into p5, but for now we're erring on the side of sparseness over confusion of a full ide--the environment is intentionally anti-ide, unfortunately at this time it's also so underfeatured that it becomes less useful.
 
it would be nice to pick another editor, such as eclipse, for which we provide more explicit support, as a sort of "advanced editor of choice" to use with p5's api and perhaps even syntax.
 
vanwoods

Email
Re: eclipse as editor
« Reply #3 on: Jul 11th, 2003, 11:08am »

i find the value of lowering the barrier to entry to be a point that a lot of programmers don't think of enough and i commend you guys on this major point.
 
some thoughts:
 
- a problem that is always difficult to grapple with is given limited resources (your time...) how to best focus on the core value added; my point is that you are not in the ide business, and time spent developing one is time away from the core IF there is some existing framework that you can use that will suffice.
 
- with that said, my thinking is that eclipse is a solidly designed and robust framework for ide creation, with a strong community backing.  this obviously couldn't happen immediately as you are already invested in the existing implementation...but...if an advanced ide would be developed using eclipse, it stands to reason (i assume...) that building an entry-level stripped down version would be a simple subset of the robust one.  
 
- to respond to arielm, i should have been more specific, i wasn't really suggesting eclipse integration as loose integration, i was essentially suggesting the development of a Bagel perspective as you mentioned at the end; development of a Bagel perspective would be the equivalent of creating a new programming language, basically p5 as a programming language; not sure having not analyzed Bagel, but eclipse's approach might provide a robust parser approach and other language implementation level benefits
 
- one possible hangup is SWT vs java2d, but i just found the following the other day which might be of value to this endeavor: http://www.holongate.org/
 
obviously longer term issues here, but seeds for thought none the less.
 
 
arielm

WWW
Re: eclipse as editor
« Reply #4 on: Jul 11th, 2003, 1:55pm »

on Jul 11th, 2003, 11:08am, vanwoods wrote:
to respond to arielm, i should have been more specific, i wasn't really suggesting eclipse integration as loose integration, i was essentially suggesting the development of a Bagel perspective as you mentioned at the end

actually, i had this speech of mine on eclipse in mind for a while, and it was the occasion to formulate and post it!
 
and the following paradox is worth to mention, again and again:
 
the great achievement of eclipse is that _ passing the hassles of finding a starting point among the multitude of features _ it really enable programming beginners to jump the "java language barrier".
 
now to the great achievement of processing: it enables programming beginners to start with "computer graphics & interactive programming" in seconds, but after a short-time, i guess problems related to the "java language barrier" start to show-up!
 

Ariel Malka | www.chronotext.org
benelek

35160983516098 WWW Email
Re: eclipse as editor
« Reply #5 on: Jul 11th, 2003, 2:53pm »

mm, "problems related to the "java language barrier" start to show-up! "
 
i for one would really benefit from some full-java examples, just to expose the subtleties of the full-blown syntax.
 
vanwoods

Email
Re: eclipse as editor
« Reply #6 on: Jul 11th, 2003, 11:31pm »

"the hassles of finding a starting point among the multitude of features" is not an inherent aspect of eclipse but rather the default delivered configuration.  i agree it is unwieldy mostly i think due to the abstraction level they chose for their interface terminology which i believe that chose to stick with in order to avoid being branded as just another java ide.  a processing specific version of eclipse would not have to (and i hope wouldn't) include all of the extraneous stuff and be more processing specific.  from what i understand, it was designed such that everything is entirely configurable, all of the menus, features, behaviors, etc.
 
you mentioned:  
"now to the great achievement of processing: it enables programming beginners to start with "computer graphics & interactive programming" in seconds, but after a short-time, i guess problems related to the "java language barrier" start to show-up! "
 
i guess i am trying to say these are not mutually exclusive objectives (robust editor and accessibility to beginners) if you don't look as eclipse as it is now but rather as a configurable editor component for building languages and language editing tools.  
 
chao, and have a great weekend!
 
arielm

WWW
Re: eclipse as editor
« Reply #7 on: Jul 12th, 2003, 12:25pm »

yeah, i can easily imagine how the ideal processing-eclipse-perspective would look like actually, definitely with a minimalistic set of options...
 
but even today, taking processing and eclipse as they are: if i would have to teach beginners, i think i would start with the processing environment and after sometimes, switch to eclipse fed with the Bagel classes...
 
benelek, i tried hard but i don't get your question if there is one?
 
anyway, a propos jumping the "java language barrier": take a look at the real-time compiling + hinting feature of eclipse!
« Last Edit: Jul 12th, 2003, 12:26pm by arielm »  

Ariel Malka | www.chronotext.org
benelek

35160983516098 WWW Email
Re: eclipse as editor
« Reply #8 on: Jul 13th, 2003, 5:12am »

question? what question? *looks over shoulder, etc*
 
it's just that there seem to be a lot of examples in the Learning section for using Processing in simple or "medium" mode, but not much in "full" java mode. as someone who jumped to p5 from an even more simplistic language (javascript), i'm finding it hard to understand the nuances of full-java syntax ("public... static... void... bla bla bla").
 
arielm

WWW
Re: eclipse as editor
« Reply #9 on: Jul 14th, 2003, 9:16pm »

on Jul 13th, 2003, 5:12am, benelek wrote:
i'm finding it hard to understand the nuances of full-java syntax ("public... static... void... bla bla bla").

well, i won't worry too much for that, afterall you're already an advanced user, and i guess the more complex stuff you code, the more you'll get into the nuances of "static", "implements", "throws", "synchronized", and co... (concerning "public" and "void", they're definitely not a mystery for you, no)
 
 
and now, a second thought on all what's been said before about eclipse and processing, in the perspective of attracting new users (with a profile of java beginners _ not necessarly new to programming or computer-graphics) to processing first, and to java in general:
 
1) currently, the minimal installer for eclipse is around 62M, in comparison to the 5.5M of processing!
 
all this, provided that you already have a JRE installed (a few more megs too)...
 
first "barrier": we already have a percentage of our audience that just don't buy the eclipse deal...
 
2) personally, if i hadn't found first the processing environment, i wouldn't have later switched so easily to eclipse: ide's (with all their complexity) are in general another "barrier" that stop new potential user to start playing with java...
 
3) about the "java api barrier": it's clear that without the friendly enveloppe that processing is giving, dealing with "Runnable", "Thread", "Graphics" etc. just to animate a few things on screen is another serious "barrier"... (okay, it's not directly related to eclipse, but i mean that without processing, java stays in the "pet shop database" arena for most of us...)
 
4) now to the "java language barrier": okay, at this stage, processing is not giving a decent solution while eclipse does, but instead of thinking about a custom-bagel-perspective within eclipse, it could be wise to "simply" add a few keys features to the processing environment, borrowed from eclipse!
 
now, after playing for a while with eclipse, and if i had to take only 3 features with me to a desert island, i would choose, by order of preference:
 
- real-time compiling / hinting (my personal java teacher!)
- code outline (avoids scrolling up and down all the time, looking for stuff)
- refactoring (for renaming fields, classes, etc. on the fly... well, a goodie, nothing more)
 
any thoughts
 
 
p.s: more about this "java language barrier" i'm mentioning all the time...
 
well, i didn't personally suffered from it, but i guess it's because i was not a programming beginner when i started with java, but i assume (maybe i'm just wrong) that for absolute beginners, java (as a language) is tougher than BASIC, lingo, javascript and co.
 
so tough, that it could simply discourage a beginner to go further!
 

Ariel Malka | www.chronotext.org
gll

WWW Email
Re: eclipse as editor
« Reply #10 on: Jun 19th, 2004, 6:09pm »

on Jun 27th, 2003, 1:42pm, arielm wrote:
4) forget about goodies like color(#rrggbb), or not putting "f" after floats, etc.

 
I made a home made class for "colors" objects to use inside eclipse. Unfortunatly, it is not well suited for compatibility.
 
Arielm, how did you bypassed this problem It may be great to share a common (standard) way to do it.
 

guillaume LaBelle
arielm

WWW
Re: eclipse as editor
« Reply #11 on: Jun 19th, 2004, 11:05pm »

well, i didn't really bypass such problems: i'm simply working with eclipse the standard java way and whenever i need, i just plug the bagel classes in.
 
feeding fill() or stroke() with a int containing rgb data works okay (as long as you populate the 8 leftmost bits to "full-alpha"...)
 
this one can do the job too:
 
int c = color(r, g, b)
 
all in all, i can't say i'm missing the "color" construct, and neither the "f" trick!
 

Ariel Malka | www.chronotext.org
Pages: 1 

« Previous topic | Next topic »