The Jucer is Old-School

#1

Hey Jules,

Although not a big deal, I was wondering if you were planning on updating The Jucer?

For example, it’s still using ye olde “juce_UseDebuggingNewOperator” and adding “L” in front of string-literals, and it’s not even making use of the “JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR()”. Let alone the horrific the idea of “create pointers and kill them off with deleteAndZero()” instead of using “ScopedPointer<>” and “= nullptr”…

It could probably use a few features to make its usability even more friendly, too. (ie: Mouse middle-click to close already opened file tabs; rather than having to go through each tab, click File, click Close)

#2

Yes, it’s very old-school.

For a while now, I’ve had a half-written replacement tool, which would be very much slicker and will eventually be integrated into the introjucer… but it’s not ready for the public yet. But that’s why I’ve not bothered updating the old one!

#3

Well, in that case, I can’t wait!

#4

Hi everyone Any update for the Jucer?

#5

Excellent question… any update ?

#6

Ok, here’s a summary of my UI tool status:

  • The old Jucer isn’t going to be updated
  • Over the last couple of years, I had been developing a replacement Jucer 2.0, as I mentioned in this thread 6 months ago. That was chugging along slowly, but was a huge and complex project… Then, about 3 months ago, I had a sudden brainwave for a completely new way to approach the problem, and totally changed my plans: I scrapped all of the old stuff, and began frenetically working on what I think will be a killer UI design tool.
  • The new one will pull some stunts that nobody has been attempted in C++ before, and should raise quite a few eyebrows… I’ve been making great progress with it, and although it’ll take quite a bit of fine-tuning before it’s ready for the public, I’m hoping to put together a screencast to show off the concept pretty soon - probably within a few weeks if I can get it working!

If you’re hungry for more clues about what this new mystery tool will do, some hints are “Bret Victor”, and “LLVM JIT”. And note that I’ve been doing a lot of work on the Introjucer recently. I’m sure you can figure it out from that :wink:

#7

is this going to make my JUCE Layer Effects obsolete??!

#8

is this going to make my JUCE Layer Effects obsolete??![/quote]

No - in fact the reverse is true. It’ll make it a lot easier and more fun to explore things like layer effects!

#9

I have just discovered the work of Bret Victor, thanks Jules for that ! I’m really curious to see how all that stuff has inspired the new Jucer :mrgreen:

#10

Sounds great, very curious =)

#11

I hope that the repository for JUCE does not grow significantly since Im using git-subtree to add it to my projects.

#12

Strange thing to worry about in these days of cheap storage… but no, this won’t make any significant difference.

#13

It’s not the storage but the bandwidth…doing a “git subtree pull” on JUCE can take a minute.

#14

Never mind the size of the repo…!

Any ETA? :slight_smile:

  • bram
#15

I’m hoping to be able to do a screen-cast to demonstrate it within a few weeks, and then an alpha shortly after that. Depends how it all goes really, there’s some fiendishly complicated stuff involved!

#16

I hope that in the rush to implement globally conscious artificial intelligence and autonomous UI-creating agents, we don’t lose sight of the usefulness of more mundane work, like:

  • IntroJucer support for 3rd party modules
  • Bug fixes
  • Useful features (native menu bar, native widgets on iOS, various other things)