#Include in Processing

Henri

There is anything similar in processing/java to an #include function?

Basically what it should do is to load a .PDE file and treat like it was inserted at the line in wich #include appeared.

from the C++ Reference

Tells the preprocessor to treat the contents of a specified file as if they appear in the source
program at the point where the directive appears.

I'm working on a very big project, with about 100 Classes, so i really need something like that, otherwise my tabs would be way too messy.

GoToLoop

• Processing's IDE (PDE) already comes bundled w/ a pre-processor.
• However, devs deliberately refused any requests to include C directives like #include & #ifdef.
• Clearly a very narrow-minded standoff I daresay!
• If you wanna try out your luck and voice your request there go to this link:
  https://GitHub.com/processing/processing/issues

TfGuy44

All your processing code - no matter which tab it's in - is at the same "level". There's no need to include other pde files so long as they are in the same directory as the main sketch's pde. If you've added the next tabs via the Processing editor, they should be in the right place.

You can't splice code from one file into the middle of another one. Sorry.

Henri

Thanks for your answer, guys.

@GoToLoop that is really worrying! I've filled an issue explaining everything in detail. (link) It might be of your interest to post there telling that you also need #include!

@TfGuy44 i'm aware of that, but as you can see in the issue i filled, the problem is that i need many tabs. I really need them. And for something to work on your sketch, it must be in the same folder. If it is in the same folder, it will be loaded in a tab. If you delete that tab you delete the file.

GoToLoop

• #include is equivalent to import in Java:
  https://Processing.org/reference/import.html
• What you can do is compile some of your classes as 1 library.
• You can also classify them as 1 group of classes via package too.
• Once compiled they can be placed inside subfolder "code/" I guess.
• Unfortunately my experience w/ compiling is almost none.

Henri

Sadly import is only for libraries. #include as far as i remember simply "places" one file on the #include line. It can be any kind of text. I don't have that experience also. I never wrote a library and having to 1) learn how to make libraries and 2) in fact create a library everytime i want to #include is simply not practical :s We're really missing that #include. Or at least we should get that folder idea i've mentione on the issue. You put the stuff you don't want to be opened in a tab in a special folder. Should be easier to implement

GoToLoop

• The way PDE works is get all ".pde" files in the folder and merge them as 1 ".java" file.
• Problem is we don't have a way to hide a ".pde" tab (or any other tab) in the PDE.
• And either request the PDE to look for ".pde" files from another path.
• The PDE was not supposed to manage so many tabs. Just for small projects.
• So you really need to compile your other tabs separately as a library as not to show up in the PDE.

Henri

from my issue post:

Henri: I really don't want to change to eclipse (specially because i've never used and i have one week to finish this work. And i still have some of more 40 totally different Classes to make). Also that would defeat the purpose of having a cozy awesome IDE with debugging, tweaking that you can simply extract and start coding.

Plus, as explained in this tutorial about using Processing with eclipse, it adds extra work and headache when working with multiple classes due to nested classes. And proclipsing haven't been updated in a while and won't solve the classes complications.

benfry: Use Eclipse or another IDE. If you have that many classes, Processing is not the right tool.

Yep, you're right. They don't care. I can't even answer - the issue is closed.

I know processing is for "sketching" but that indeed is very narrow-minded! Don't get me wrong, i really love the work they're doing. But why limit it? Processing is so powerfull in what it can do, why limit it to small projects?? It's the main language aimed at visual arts. Having to learn C# with tons of libraries fpr graphics just because there is a tab limit is just discouraging :s

Yeah, but you're right anyway. If i want to stick with Processing i will probably have to learn how to make libraries. But that's a really workflow-killer, specially because i have less than one week left. Until then i will try having three text editors working on different files. But i already predict this will cause some problems. I can already pinpoint one:

But the problem is that when you modify some file externally processing forces you to relead immediately (if you click no in the "reload??" popup it simple appears again). If somehow i forget to save my modifications on processing IDE and change anything externaly i will loose that modifications.

Well, i'm just writing about this problem. I think it is very likely that other people go through it. Maybe we can share our solutions.

quark

Are all your classes in .pde tabs or are they .java tabs?

Henri

They are in .pde tabs

quark

That means all your classes are inner classes and can be distributed anyway you want across the tabs I suggest that you group similar classes together in a single tab thereby reducing the number of tabs needed.

Only top level classes need one tab per class and that would be a .java tab

colouredmirrorball

Only top level classes need one tab per class and that would be a .java tab

Once you start using top-level .java classes, it's probably best to code them in an external editor like Eclipse or IntelliJ and compile them as a library. It's actually easier than you think. I mean, I could do it...

You can persuade the external code editor to produce a .jar in the code folder of your sketch every time you compile it.

Henri

@quark Thanks for you answer! As i explained on the issue #3962 most of those classes have arround 200 to 300 lines of code, so having multiple of them together would be reeeally messy. Since the issue got closed so blazingly fast and i couldn't even answer, i've mentioned it on another issue that i was posting. The idea is simple, just make the tab list scrollable. Wouldn't be as good as a nice tab manager, but hey, it works.

@colouredmirrorball Thanks for you feedback. I don't intend to write .java classes. Currently i don't have any reason to do that and i simply can't spend that much time learning how to make libraries. I barely got the time i need to be deliver on the deadline haha

Right now the best bet i have is to use an external editor just to edit the texts. But in fact i'm still using processing IDE. If i change something in notepad++, for example, processing IDE imediately gives me a message "something changed externally on the file. Do you want to reload?" then i click yes. And on the external editor (notepad++, for ex.) i can better organize my tabs and even have two code panels. Probably the best bet for now, i guess.

GoToLoop

Since the issue got closed so blazingly fast and I couldn't even answer,...

We can still continue posting to closed issues & PRs.
Only catch is that it won't be visible for the "Open" section.
But stored in the "Closed" section for those who wish to go there.
That is, it loses visibility and needs more clicks to go there.

It's amazing how most of GitHub developers don't even think about how rude & hurtful it is to reply & close an issue at the same time. [-(
The ideal is to await at least 1 week for the OP to close the issue for him/herself. 8-|

But don't bother that much. You're not the only 1 who's got "fried" there.
I've got "fried" a bunch when PRing there! :|

colouredmirrorball

most of those classes have arround 200 to 300 lines of code

Lol I have a tab of 10 000 lines

Henri

@GoToLoop Oh, i didn't knew i could post there. Glad to know! I'm new to GitHub That makes the situation a little easier, since before i've understood the closing as an "shut up". But indeed it's still something rude. Well, i guess they have too much issues already and can't spare that much time to look into everything into detail. Closing might help them keep organized. But they could still wait for at least one answer before closing. I doubt they read closed stuff.

@colouredmirrorball then i hope you're using an external editor with code folding. Otherwise, please consider doing so, for your health's sake haha

I've been testing using an external editor + reload in Processing IDE and it's been working fine so far.

They could mention in the documentation that the IDE checks for changes and offers a reload instantly. Whenever they mention eclipse they've only talk about using it as a final IDE for processing, with exporting processing core and stuff. But it could be used as an simple text editor. An idea so simple that i don't know why it hasn't occurred to me before.

KevinWorkman

include is equivalent to import in Java

This is absolutely false.

An import statement doesn't actually do anything. It doesn't give you access to any code that you didn't already have access to. The only thing it does is save you the trouble of using fully qualified names of code that you could already use.

For example, we could use the Robot class by using its fully qualified name:

void setup(){
   java.awt.Robot robot = new java.awt.Robot();
   robot.mouseMove(100, 100);
}

However, that can get annoying, so we can use an import statement to save ourselves the trouble:

import java.awt.Robot;

void setup(){
   Robot robot = new Robot();
   robot.mouseMove(100, 100);
}

Java doesn't have a notion of an include statement, so neither does Processing.

But I'm not sure what great benefit you're expecting to get out of it anyway. Just use classes and tabs like they're intended.

koogs

the benefit is being able to use source code stored elsewhere, not having to copy the #included file into the project area in order to use the code within it.

C, for instance, has header files containing useful constants and actual code and you could just

#include <constants.h>

to get access to them, where constants.h could live anywhere in a system defined path or in a location you define at compile time (similar to classpath but with source, not objects)

(last place i worked abused this in a crazy way. ALL the code was in .h files, like classes, and the top level (package) file was nothing but a list of #includes... the associated cc line was pages and pages long)

KevinWorkman

You don't have to copy the file into the project area, you just have to include it on the classpath.

The problem is that Processing (rightfully) hides all of that from the user, so if you want to do this, just use "normal" Java from the command line or from an IDE like eclipse.

koogs

but #include works with source code, not compiled code.

KevinWorkman

So does eclipse and the command-line java compiler. :p

koogs

(ok, difference there is kinda subtle. there are times where it's useful)

a "normal" javac command won't do the processing pre-processing though. people just want to hit ctrl-r to run stuff.

that said, i agree it shouldn't be part of processing.

GoToLoop

• Since Processing's IDE (PDE) already relies on a pre-processor, it should take advantage of it!
• I don't think it'd be that hard of an effort to add some very useful C-type directives like #define, #include, #ifdef.
• Those above are pretty enough to make PDE extremely more powerful & flexible w/o any need to add GUI features to it.
• Besides, Processing isn't just Java but multi-language & multi-platform.
• W/ C-type directives we can write code in a way that can be cross-mode by defining blocks which should only be compiled for some particular Processing's version or mode.
• For example, Processing 3 uses surface instead of frame. That's easily solvable w/ directives!
• As mentioned, some folks already tried to ask for pre-compile directives there.
• But they were replied that such smart features were "anti-Java". As if Processing = Java only!

KevinWorkman

It's not about how much effort it would be to add these features. It's about whether they'd actually make most Processing developer's lives easier. The Processing team seems to think that they would only complicate most code, and I agree with them.

quark

I see no problem with requesting a PDE enhancement to improve handling a large number of tabs e.g. scrolling tab list. Then its up to the Processing developers whether they wish to implement it or not.

The fact that the PDE does not handle hundreds of tabs is NOT an issue, since Processing was never designed to create huge complex software projects. I don't always agree with Ben Fry but in this instance I think he has a point. I must admit that I sometimes find the tone of replies to raised issues on GitHub unpleasant.

I don't agree with including C++ directives in Processing, there is no need and just adds another layer of complexity and Processing is about removing complexity.

GoToLoop

• C/C++ programmers already enjoy pre-compiling directives for "half a century" now! $-)
• Since it's a very ancient "technology", looking for instructions of how to use it is pretty straight forward.
• Processing 3 already screwed up its compatibility now!
• Like adding breaking changes as preload(), fullscreen(), surface, etc.
• Using directives we could easily write code which would work for both Processing 2 & 3.
• We could use size(600, 400, FX2D); if it's being compiled for Processing 3; otherwise size(600, 400, P2D); or size(600, 400, JAVA2D);.
• Or like @Henri wished he had now: #include source code from somewhere else w/o littering PDE's w/ unmanageable tabs!
• Alas, it's an eternal tug o' war between "conservatives" & "progressives"! >:)

KevinWorkman

I don't know what you want us to tell you. The Processing developers disagree with you. If you really want this feature, implement it yourself in your own branch.

Breaking backwards compatibility but still keeping with the same language is very different from adding in crap from other languages.

Keep in mind that the target audience for Processing are not expert developers. They don't want a ton of options and features. They want the ability to write simple code that does cool-looking stuff. Adding in features from other languages does not help them do that.

If you want advanced features, then use a more advanced IDE.

quark

Alas, it's an eternal tug o' war between what is realistic and what is unrealistic for a small number of developers and limited funds to create and maintain.

GoToLoop

... is very different from adding in crap from other languages.

So pre-compiling directives are crap from "foreign" languages now?!
I wonder why PDE already got such "heresy" as a pre-compiler for craps like color primitive "type"? ;;)

Adding in features from other languages does not help them do that.

No 1 is obliged to use directives any much as any other feature! :-\"

... and what is unrealistic for a small number of developers and limited funds to create and maintain.

Well, they had just spent a buncha time re-creating Applet after removing it! 8-}
And who knows how many releases will be necessary to reach a real "stable" version.
Looking at Processing 2's history, about 2 years or so! :-&

Methinks rather than embarking in such a long quest of removing Applet's dependency from PApplet, and thus repeating the wheel by re-writing it again to put it back, they should think more about how to improve Processing's deployment level! b-(

Rather than abandoning our Java-to-the-Web Processing.js (pjs), they should be thinking about what was its road block for not working right.

Another 1: fix the pre-compiler so we can write Processing w/ full Java 8+ syntax.
PDE is the only IDE I know of which is still stuck w/ half Java 5 syntax! @-)

colouredmirrorball

Another 1: fix the pre-compiler so we can write Processing w/ full Java 8+ syntax. PDE is the only IDE I know of which is still stuck w/ half Java 5 syntax!

https://github.com/processing/processing/issues/3055

... it needs a lot of testing and a committed maintainer...

You could be our hero!

then i hope you're using an external editor with code folding.

Hahaha! ... no... ctrl+f is my friend!

But don't worry about my mental health: studying physics has already taken care of that.

Henri

Indeed #include is not equilavent to import.

@KevinWorkman But I'm not sure what great benefit you're expecting to get out of it anyway. Just use classes and tabs like they're intended.

Like i explained, i really don't want to have to group tabs that are 200~300 lines. 20 classes would be 4000~6000 lines long. Of course that won't make your code stop working. But it does give you a lot of unnecessary headache. Breaks your workflow when you can't find your stuff.

@koogs the benefit is being able to use source code stored elsewhere, not having to copy the #included file into the project area in order to use the code within it.

This is what i'm talking about.

You don't have to copy the file into the project area, you just have to include it on the classpath.

@KevinWorkman The problem is that Processing (rightfully) hides all of that from the user, so if you want to do this, just use "normal" Java from the command line or from an IDE like eclipse.

That is exactly one thing that i want to avoid. Unecessary work of using normal java or other IDE just because Processing tabs won't appear on the screen.

@koogs but #include works with source code, not compiled code.

@KevinWorkman So does eclipse and the command-line java compiler.

@koogs (ok, difference there is kinda subtle. there are times where it's useful). A "normal" javac command won't do the processing pre-processing though. people just want to hit ctrl-r to run stuff. That said, i agree it shouldn't be part of processing.

That's the part where i don't understand anything you're talking. See? Anyone can understand what #include does. Now we can't expect people to understand those more complex ways to work with processing. Aren't we talking that Processing users are normally amateurs without extensive programming skills? So why know we should blame them for just want to ctrl-r ?

I'm talking about what happens when you write a lot of code: You run out of tabs and you must use veeeery long tabs. Now we must be aware of the fallacy:

Well, if your code is that long, you're an advanced programmer. So you can and should do the advanced alternatives.

I'm not an advanced programmer at all. Length is not complexity. You can write very long simple code. I need too many lines because my artistic goal is ambitious in the sense i want my sketch to respond to a lot of different inputs (from a keyboard) differently. The way it responds is very simple! But since there are much different things to draw, i need one class for each one. (They're way to different for using extended classes)

@GoToLop Since Processing's IDE (PDE) already relies on a pre-processor, it should take advantage of it!

Those above are pretty enough to make PDE extremely more powerful & flexible w/o any need to add GUI features to it.

Besides, Processing isn't just Java but multi-language & multi-platform.

That said, and considering that, like i said, understanding and using #include is very simple, i think that it is an idea to at least be taken in consideration. Ok, let's see how much work it would need and how much benefit it would bring us. I'm okay if they decide it's not worth the work, but i don't think it is a idea to be discarded that fast.

@KevinWorkman It's about whether they'd actually make most Processing developer's lives easier. The Processing team seems to think that they would only complicate most code, and I agree with them.

I don't see it that way. Since it can take some code that is already ready out of your way, you could focus on the stuff that still needs working. Is it that hard to write #include myFunctions.pde

@quark I see no problem with requesting a PDE enhancement to improve handling a large number of tabs e.g. scrolling tab list. Then its up to the Processing developers whether they wish to implement it or not.

That's what i concluded, as i wrote on my second issue. Should be way easier than implementing #include and would provide an solution to the tab problem.

Maybe my fault was not thinking about that on the first place. I've get a feeling that when they read #include they thought "ok, that subject is over". Maybe if i only posted the sugestion for the scrolling tabs they would consider it right away.

@quark The fact that the PDE does not handle hundreds of tabs is NOT an issue, since Processing was never designed to create huge complex software projects.

@KevingWorkman Keep in mind that the target audience for Processing are not expert developers. They don't want a ton of options and features. They want the ability to write simple code that does cool-looking stuff. Adding in features from other languages does not help them do that. If you want advanced features, then use a more advanced IDE.

A giant project is programming Fallout 4. You can bet they have waaaaaay more than 36 tabs (which is by the way, the maximum number of tabs i can see on my notebook, which have a lower resolution). I would say that 40 files are small size, and that 4 tab projects like the idea of "sketches" are tiny. And i don't think that processing being aimed at those tiny sketches is a bad thing. It is indeed very nice to just be able realize an idea in 5 minutos! But despite it being Processing's speciality it doesn't mean it must be processing only use!

Also, like i said before, length is not complexity. Simple projects can be many lines long.

@quark I don't agree with including C++ directives in Processing, there is no need and just adds another layer of complexity and Processing is about removing complexity.

Now i don't know many C directives. But like i said before #include does simplify your code. Okay, that class is ready. I don't want to see it in my tabs anymore, take it out of my way.

@colouredmirrorball Hahaha! ... no... ctrl+f is my friend! But don't worry about my mental health: studying physics has already taken care of that.

i know that feel. i've had my shares of mathematics haha

Thanks for all your answers. I really appreciate your time and patience.

my conclusion :

• include is an idea to be taken in consideration, but it is understandable if they decide not to implement it. I've just suggested #include as an solution to a tab-limit problem.

• But, implementing a scrolling tab menu should be way simpler and maybe would solve the problem. Not elegantly or fully functional as an tab manager, but it is an solution simple enough. Scrolling with your mouse wheel through a tab menu is way quicker than using ctrl+f on a 4000 lines code. Especially if you've got lots of variables with the same name and other words that can appears many times.

• Using an external text editor without integrating it with processing is very reasonable. You keep Processing IDE open and use for ex notepad++ to write your code and then save it. Processing IDE automatically detects a file was changed and asks for reloading. You click yes, then press alt+r. Voilá.

• Nonetheless, a scrolling tab menu would still be useful, especially for those working on smaller notebooks.

clankill3r

If you have like 100 classes I suggest moving to another IDE like eclipse or IntelliJ. I moved from Eclipse to IntelliJ and it's one of the best programs I ever used.

colouredmirrorball

I agree that a better tab/class manager would be a logical step. But:

I moved from Eclipse to IntelliJ and it's one of the best programs I ever used.

This.

There are already great java IDEs out there. Why should Processing, with its limited resources, reinvent the wheel? Since Processing is java, you don't loose any functionality when switching to another IDE, rather you gain a lot. Moving existing projects is a pain though. For your current project you just have to carry along...

GoToLoop

Processing 3's PDE already added in many advanced features like debug + breakpoint, code completion, continuous error checking, etc. But they can't even add scrollable menus!

I had a sketchfolder w/ many sketches in it. But I had to split it b/c I couldn't choose 1 by clicking at the "Open" button and then scroll to pick 1 to load.

But now it's much easier: they've simply removed the "Open" button!
Along w/ "New", "Save", "Export", etc. We are too dumb to concentrate w/ all of those buttons littering the GUI, right? Now we've only got "Run", "Stop" and "Butterfly"! :P

Real changes for the API, pre-processor and deployment they're not interested at all! =(

bilmor

Last year a fellow hacked up an #include mechanism for Processing:

http://forum.processing.org/two/discussion/6431/adding-additional-options-for-code-reuse

@mikechambers , are you still out there? What's the state of your fork?

GoToLoop

As always @mikechambers' proposal got "fried" too: X(
https://GitHub.com/processing/processing/issues/2788

KevinWorkman

We're talking about a few different things here:

Thing 1: Should include be included in Processing? The answer from the Processing devs is no. I absolutely agree with them. You (mostly talking to GoToLoop here) can bicker with me all you want, but the decision has already been made, and you're on the wrong side of it. (Just like I was on the wrong side when I wanted them to put more work into making applet deployment work.) Processing is designed with novices in mind, and while include might be obvious to you and me, it is not obvious to everybody. I mean, GoToLoop is an expert, and he didn't fully understand import statements! :p

Thing 2: Should projects with many tabs work better in Processing? Absolutely. It sounds like the ability to close a tab but have it still be a part of the project would solve 95% of your concerns, without having to change the language at all. Consider opening a feature request or even implementing it yourself.

Thing 3: Even with thing 2, would you benefit from switching over to an IDE like eclipse? You sure would. You lose some of the convenience of Processing, but if your sketch is really 20 tabs, you really shouldn't be using Processing anymore. It sounds like you're very resistant to the idea, but consider this: which would be easier, you to switch which editor you're using, or the Processing developers to implement an entirely new feature?

erkosone

I also need to include in processing, I have a book java language itself and will update daily .. at the end I have several projects each with a different file of the same library .. a big problem. it is necessary to include a source file .pde indicating the route.

The problem is that the creators of processing see processing as a toy and not as something serious, and when someone wants to do something serious with processing simply answered: heeeyy !!! do not try to complicate my toy!

KevinWorkman

The Processing IDE is meant to be simple. The Processing library is meant to be something "serious" that can be used by more advanced users.

If you want to use Processing in a more advanced way, then just use the Processing library with a more advanced editor.

Instead of viewing it as the developers saying not to complicate their toy, view it as people refusing to graduate to a more advanced editor when they're ready. You don't complain that the bike you had when you were a kid is too small for you. You get a bigger bike.

GoToLoop

Point of fact: Processing devs have ALREADY complicated their/our "toy":
Processing 3 now got debug, breakpoints, code completion, continuous error checking, etc.

Things that should only be expected in advanced IDEs like Eclipse, IntelliJ, etc.
For sure, adding in those features into the PDE have been taken about 2 years or so I guess.

But asking for something as simple to implement as to add an ancient C feature enjoyed by lotsa programmers throughout decades is considered too "advanced" for the PDE!

Rather than take full advantage of PDE's pre-compiler, narrow-minded folks like you prefer the mediocrity of leaving the pre-processor for sugary syntax tasks only! >:P

KevinWorkman

I'll repeat myself: I don't know what you want us to tell you. The Processing developers disagree with you. If you really want this feature, and it's really as simple as you say, then implement it yourself in your own branch.

Something that seems simple to you might not seem simple to most users of Processing, and they wouldn't have a use for it. Almost all of your complaints would be solved by simply having a better tab manager.

Rather than take full advantaged of PDE's pre-compiler, narrow-minded folks like you prefer the mediocrity of leaving the pre-processor for sugary syntaxes only!

I don't appreciate being called narrow-minded. I disagree with almost every point you've tried to make, but I've refrained from personally insulting you.

quark

Almost all of your complaints would be solved by simply having a better tab manager.

I agree with that 100%, it would certainly solve the OPs original problem which was

...otherwise my tabs would be way too messy.

Bird

You seem very motivated to have Processing modified to suit your needs, but that would require someone else's efforts. In the last three days a new IDE could have been learned and a nice library written.

Also, like i said before, length is not complexity.

I totally disagree, but if that is actually true, then refactoring some code is in order.

If you don't have the time to learn what you need to learn, such as writing a library, then I don't see how expecting someone else to take the time to modify Processing is warranted.

It seems to me that the TabManager tool would be a help here.

mikechambers

Just an fyi, but I have a fork of processing that I use for my personal projects (based on processing 2 build) that adds #include directives.

You can find more info here: https://github.com/processing/processing/issues/2788

I might look at updating it to add support for processing 3 this week.