The Projucers.. :)


#1

This looks awesome Jules! Kudos! We saw it running on a Mac, I assume it’s Windowsable (and Linux?) as well? As well, I assume once one is done, they then target compilation to the desired compiler? or, is Clang a front end to the compiler?


#2

Thanks! Yeah, I’ve only been using a Mac so far. People are definitely using Clang/LLVM on Windows, so I’m assuming that there won’t be any insurmountable obstacles in getting it to work, but I’ve not tried it yet.


#3

(oh, and Linux will definitely be easy to port it to)


#4

Well then my question would be, does this need external LLVM/Clang binaries to get the full functionality, do you link to shared libraries of LLVM/Clang, what’s the interaction mechanism.

Do you think that a method like you used could be used as a replacement for a production application that uses LUA scripting at the moment.


#5

[quote=“atom”]Well then my question would be, does this need external LLVM/Clang binaries to get the full functionality, do you link to shared libraries of LLVM/Clang, what’s the interaction mechanism.

Do you think that a method like you used could be used as a replacement for a production application that uses LUA scripting at the moment.[/quote]

No, I’ve linked LLVM statically.

At runtime, the app actually forks into a parent process that runs the Introjucer interface, and a child process that does the compilation and run the JIT engine, so that when your code crashes, the parent can just spin up a new instance of the JIT process and carry on. (But there’s only a single binary that does all this)

And yes, you could certainly use LLVM like a scripting engine, but I have to say there’s a steep learning curve - writing code to compile, load and run some C++ code is not easy! And a crash in the code will kill your app. Oh, and it’ll open huge security holes, of course.


#6

Brilliant, as expected! That’s what I hoped you end up with.

I can see some cool new ways to use this - (watch out Processing!), but I’m curious about fitting it into a full workflow.

So:

Is the compilation going to be a complete app? Do we still need to go over to Xcode/VS/C::B? I notice the demo showed Components, but not the whole JuceDemo app running.

Is the Drawables thing, and create from XML/ValueTree etc. all redundant now? We will just work right in the C++, no intermediate layer at all?

Do you expect restrictions on non-juce code in an app, or should that all work too? I mean - can we run a full app in the system, then browse to the right source file and edit controls?

Also - when you edit a control in the Component Editor, does it select the relevant code for you?

Bruce


#7

Where is this??


#8

Good questions, Bruce!

Not sure.

I think the most likely answer is: Yes, it’ll be able to run your app inside the JIT. That’s easy, I can add that functionality with just a few lines of code to call main(). But to actually generate an exe file… Hmm. That might be something I should leave to the normal IDEs. Maybe somewhere down the line in the future I could add such a feature, but initially I want to focus on the stuff that nobody else can do.

A couple of years ago I began work on what was going to be the Projucer, and designed all the hugely complicated Drawables/ComponentBuilder classes as part of that, but now I think that was a dead-end, and will probably end up clearing out those classes to avoid cluttering up the library. ValueTrees will certainly stay because they’re hugely useful for lots of things, and I’ll keep Drawables, but may change them back to not being Components. Not sure, but it’s something I’ll think about later.

What I would like to do will be to add some new classes for more automated layouts, e.g. grid layouts, etc, which can be used in the resized() method. The projucer could recognise these and provide UI tools to handle them. (Or the layout classes themselves could even provide their own self-editing tools that the Projucer could just call, so that you could write your own layout classes that seamlessly integrate into the GUI editor… That’s the kind of cool stuff that’s possible when you can load c++ code dynamically).

Yep. Any project that you can currently create in the introjucer should work.

Yes… I didn’t really show that in the demo, but there are menus to let you jump to the code for various items, e.g. highlight a child component’s “setBounds” method, declaration, etc. That stuff is all quite easy because the compiler can pull out the location of all these bits of syntax.


#9

http://rawmaterialsoftware.com/viewtopic.php?f=12&t=9793


#10

Fantastic work Jules! I was building myself a realtime UI tool over the summer (similar approach to Drawables and ComponentBuilder) and then saw your mentioning of working on this so I put my efforts on hold. Glad I did! Very much looking forward to the alpha! Cheers!


#11

http://rawmaterialsoftware.com/viewtopic.php?f=12&t=9793[/quote]

Countdown to the ‘ProJucer required for development?’ voting thread starting now…


#12

Not sure.

I think the most likely answer is: Yes, it’ll be able to run your app inside the JIT. That’s easy, I can add that functionality with just a few lines of code to call main(). But to actually generate an exe file… Hmm. That might be something I should leave to the normal IDEs. Maybe somewhere down the line in the future I could add such a feature, but initially I want to focus on the stuff that nobody else can do.[/quote]

Hmm. One problem I can see is the extra steps that tend to be needed on Mac and Win to accommodate bundled linked libraries. If you want to use LGPL libs, you have to dynamically link them. But people don’t want to install libraries, so the best approach is to package the libs with your app. I have an xcode build step that copies the libs in with binary. It can be clunky, since I have to link to the libs that don’t even exist before I’ve run a build, but the result is rock solid, LGPL compliant, and easy to update.

Don’t know how the ProJucer made app can do that linking, and where the libs would be. Maybe it can link to the temp files (the ones that the xcode step transfers into the app bundle)? Sheesh, the ultimate would be a libs folder similar to a BinaryData folder, and ProJucer makes the XCode steps!

Please consider that.

I’ll use it as an interface designer either way. Nice job.

Bruce


#13

Looks really cool, can’t wait to try it out!


#14

[quote]Hmm. One problem I can see is the extra steps that tend to be needed on Mac and Win to accommodate bundled linked libraries. If you want to use LGPL libs, you have to dynamically link them. But people don’t want to install libraries, so the best approach is to package the libs with your app. I have an xcode build step that copies the libs in with binary. It can be clunky, since I have to link to the libs that don’t even exist before I’ve run a build, but the result is rock solid, LGPL compliant, and easy to update.

Don’t know how the ProJucer made app can do that linking, and where the libs would be. Maybe it can link to the temp files (the ones that the xcode step transfers into the app bundle)? Sheesh, the ultimate would be a libs folder similar to a BinaryData folder, and ProJucer makes the XCode steps! [/quote]

Well, the JIT engine can load DLLs if you tell it which ones you need, but obviously there’ll always be crazy builds that it doesn’t stand a chance of running. Bear in mind that if you’re just using it to do some work on a few component classes but can’t build the whole project, you could set up a simple stub project that just contains the relevant component files and enough stub functionality to get them to load.


#15

A real game changer. I watched that lecture by Bret Victor and it really made an impact of how useful tools like this could be by reducing the amount of visualisation a programmer has to do and freeing them up to be creative with code. Just think about how much time this will save when designing look and feels etc.

From a teaching perspective this is also really useful, having real-time feedback of code changes without having to re-compile will save so much time in the labs and give students a real feel for how variables affect the end result. One of the main reasons we use software like MaxMSP is for this real-time editing, if we can do this in C++ the learning curve for text-based programming is massively reduced.

Great work Jules, can’t wait for the alpha.


#16

I’m also a fan of Bret Victors ideas. How about adding a kind of timeline that will loop and feed in examples of user inputs - could be midi, game-input, or even audio input?
Then the components can react to that example inputs. As the “Inventing on Principle” video shows that could really move things forward in the field of game-prototyping.


#17

Yes indeed. I’ve never consciously designed with beginners in mind, but it would be great as a platform for exploring the language.


#18

[quote=“OBO”]I’m also a fan of Bret Victors ideas. How about adding a kind of timeline that will loop and feed in examples of user inputs - could be midi, game-input, or even audio input?
Then the components can react to that example inputs. As the “Inventing of Principle” video shows that could really move things forward in the field of game-prototyping.[/quote]

I don’t know exactly what technique Bret Victor was using to do his timeline demo, but you could actually write something very similar that would run in the projucer without needing any changes. You’d just need to wrap your actual game component inside a cunningly designed component that captures the output of multiple calls to its paint routine and superimposes them… Then you could change some literal values inside the projucer and watch the output magically change just like in his demo. I’m sceptical about how useful that technique would be for real life programming, but it’s certainly a cute trick.


#19

[quote=“jules”][quote=“atom”]Well then my question would be, does this need external LLVM/Clang binaries to get the full functionality, do you link to shared libraries of LLVM/Clang, what’s the interaction mechanism.

Do you think that a method like you used could be used as a replacement for a production application that uses LUA scripting at the moment.[/quote]

No, I’ve linked LLVM statically.

At runtime, the app actually forks into a parent process that runs the Introjucer interface, and a child process that does the compilation and run the JIT engine, so that when your code crashes, the parent can just spin up a new instance of the JIT process and carry on. (But there’s only a single binary that does all this)

And yes, you could certainly use LLVM like a scripting engine, but I have to say there’s a steep learning curve - writing code to compile, load and run some C++ code is not easy! And a crash in the code will kill your app. Oh, and it’ll open huge security holes, of course.[/quote]

Security is not an issue i guess. But the learning curve might be,i already wrapped a lot of JUCE classes in LUA and was thinking of switching to LuaJIT, it looks like it needs almost no work on the code part, i’d just need to link my app to the LuaJIT engine instead of the original LUA. But now that you showed me this it makes me think if it’s a good way to go. Very cool stuff, congrats on that.


#20

I guess for those of us who like to use a custom look and feel, this could show us what our GUI really looks like. That’d be an extremely welcome feature!