Has JUCE lost its way?

General JUCE discussion
41

Jules, I think you should try to use the latest HTML5/CSS3 libraries, and more specifically, jquery (with Firebug).
It would take you probably half a day of your time, but you’d see how “obvious” the interface/development become with such tools.
As you know, I’ve spent a lot of time doing web development in parallel to C++ dev for giving 2 interfaces to the same features on a product we’ve talked about, and I can say that HTML/CSS/jquery development is a joy to use compared to C++.
I’ve wondered why, and I’ve come to the conclusion that development in HTML/CSS/jquery is easy because its “instantaneous” result. You see something wrong, you can click on the wrong item, change other 2 or 3 CSS styles, it changes instantaneously, and once you’re happy with it, you copy the CSS back to your source/webserver’s filesystem.

With projucer, you’re adding this magical feature back to C++. That’s great, but for a good infrastructure/architecture, you must have a way to change the L&F dynamically out of the code. I’m not speaking of “do it yourself” method, since that would results in tens of implementation depending on the developer, but I think a change in Juce’s itself would be better so everyone’s good.
While you’re preparing a new release, I wonder if you could delay it a bit more to add a CSS like feature to the Component class, by reworking the animation stuff to support easing & transforms, by reading the properties out of an XML (or better a CSS) file, to remove the look and feel completely (or at least have a new CSSLookAndFeel class).
If you do that, and add a tab on the projucer to edit these properties, you’ll have made the BEST development tool downthere.

42

Yeah, not so much.

Other than compile/link time I’m not sure I see the difference between the two to be honest.

JQuery’s animation model is extremely nice. It follows the ‘easy things should easy, hard things should be possible’ maxim very well. This is already possible with JUCE though. If the ComponentAnimator class was given a callback insert that could also provide extra processing beyond that which comes free, you’d be able to do pretty much everything that JQuery can do in terms of animation with little extra work.

[quote]
While you’re preparing a new release, I wonder if you could delay it a bit more to add a CSS like feature to the Component class, by reworking the animation stuff to support easing & transforms, by reading the properties out of an XML (or better a CSS) file, to remove the look and feel completely (or at least have a new CSSLookAndFeel class).
If you do that, and add a tab on the projucer to edit these properties, you’ll have made the BEST development tool downthere.[/quote]

CSS alike support would be nice, but expensive since every colour lookup would require a tree inspection. You can alleviate that problem by using multiple LAFs at different levels of your UI hierarchy, but then if you’re going there you’ve somewhat obviated the need to CSS. Or are you thinking strictly of dimensions?

43

No, I disagree with this. Basically jquery animation is cool because it’s done right, not through a callback where “everything is possible”, but because the most useful animation features are already “built-in”. I am not a animation ninja, and I can’t write the typical elastic easing’s equation by heart.
Jquery animation system is based on an object called a “queue” where you chain your animation actions (you typically don’t see it, since the defaults schemes covers 99% of the users needs). There is not a single queue, if you need specific animation needs, etc… The design here is good because it’s simple, yet powerful enough.

I think you can simply cache the tree inspection.

Basically an object with the colour + a atomic counter, would be enough for fast, yet powerful CSS like look and feel.
When the tree is updated, the counter would be reset to 0, and all classes using that object would compare with their previous counter value, and know that they should traverse the tree.
Once they have traversed the tree, they increment the counter again, and save the counter value internally. If their internal counter is <= to the object’s counter, they can use the object directly, with no lookup anymore.
Obviously, if the CSS file is modified, the tree is modified, and everything should be repaint, starting from the top level component.

CSS box model is nice (a bit difficult to grasp at first, but now it’s the “standard”, it’s well documented), and could be done by adding a “virtual resizedBoxModel” method that would call the actual resized() method if no rule is defined for the component. That way, you don’t break the existing code, yet, you can still use the external CSS’s rules.
Again, you can cache the computation so you only compute the size & dimensions once.

Similarly, the paint() method would have to be wrapped in a “virtual paintBoxModel()” for handling CSS’s box model (like background color/image/border etc…) that would defaults to the real paint() method when no rules is found.

44

I’m glad to see a robust discussion regarding the future of JUCE, finally!!!

45

No, I disagree with this. Basically jquery animation is cool because it’s done right, not through a callback where “everything is possible”, but because the most useful animation features are already “built-in”. I am not a animation ninja, and I can’t write the typical elastic easing’s equation by heart.[/quote]

Quite right, but a callback doesn’t preclude use of a pipelined animation system. One would be free to do whatever one wants there, so entirely custom, obscure treatments are possible, as is supplying a process pipeline as the callback.

I think you can simply cache the tree inspection.
[/quote]

I’m assuming a fair degree of on the fly changes to style-sheets. I guess that depends on how one approaches dynamic display properties, but in most cases where I’m modifying styles dynamically, a lot of sub-tree recalculation is needed. To me CSS just seems awfully overkill for straight apply this style to that component operations, so unless one is making full use of the cascading nature of styles, it seems like the application of a very large hammer to a rather small nut.

[quote]
CSS box model is nice (a bit difficult to grasp at first, but now it’s the “standard”, it’s well documented), and could be done by adding a “virtual resizedBoxModel” method that would call the actual resized() method if no rule is defined for the component. That way, you don’t break the existing code, yet, you can still use the external CSS’s rules.[/quote]

Box model? Why would you want to emulate that? It’s fine for a legacy friendly layout hinting system. I want far more concrete control over layout in a desktop app. I have no interest in dealing with column height hacks for floating divs in my C++ code. I spend enough hours being thoroughly cross about that kind of thing as it is. Sure, take a sub-set of the box model (basically the bits that relate to absolute positioning) and allow them to be expressed outside of code, but then we’re doing nothing that Borland and many others haven’t done many times before.

46

I should note, I’m kvetching without any better ideas of my own right now. The changes I’d most like to see I can’t think of a way of implementing without massive breakage to existing code.

47

Personally, something that I’ve always fancied investigating is the idea of a UI description that’s even more high-level than HTML/CSS. i.e. you just have a data structure that defines a bunch of information that you want to present to the user, and a description of what you want the user to tell you, but it’s all just expressed semantically, with absolutely no attempt to define layouts, widgets, or anything visual. Then there’d be a (hugely complicated) algorithm that figures out the best way to represent this graphically, choose buttons, lists, combo boxes, etc, and lays them out automatically.

I’ve always thought that the HTML/CSS/javascript is a bit of a messy middle ground between two extremes. For some bits of your app, you do need total control over every pixel (and I think the way juce works is great for that), and for other bits, you want to do something straightforward like showing the user a list of things and letting them choose one, which is something that should be possible automatically. HTML doesn’t really handle either one very well.

Anyway, this is an interesting discussion, but can I humbly ask that we continue on its own thread, rather than meandering any further on this one :slight_smile:

48

Fix the text

49

Fix your trolling behaviour

50

Bram pointed me to this very interesting thread!

At SampleSumo, we are glad to be paying for a Juce license too, and I must say that the framework gives very good value for its price!
We were doubting between Qt and Juce some two years ago, but mainly due to the focus of Juce on audio, and especially the audio plugin stuff, we chose Juce instead of rolling our own (I must say we are only now really getting on speed with Juce, it’s not as if we already released 5 big applications with it).

The things that we are looking for in Juce, and thus consider very important and valuable:

  • support for audio plugin formats (VST, AU, RTAS, AAX) from one code base (core and GUI)
  • support for mobile devices, in addition to the desktop platforms (also Windows8!)
  • having a cross-platform application building framework with anything one needs for multimedia applications

What would be nice, is a bit more in depth guidance on how to structure a full-fledged application that uses undo/redo, commands, and for plugins parameter communication between processing and GUI threads, … these kinds of architectural things.
We know the building blocks are there, but more practical info on which components (not in the GUI sense) to use where and for what would be good to have.

Also, the practical handling of feature requests/bugs could be done using some kind of tracking system. I know: this introduces some administration, and some bugs/features are fixed/implemented almost immediately (which is great), but other linger around in forum threads, and there is no way to get notified if something got fixed, and if other people join in the effort, you really can’t live without something to manage this a bit better. Github has an issue tracker built-in, so why not use it to keep an overview of things and increase the communication about these things back to users?

Something we would VERY much like (and be willing to pay for!) is some kind of skinning system that allows us to build an application and then have a designer “skin” the GUI of the application.
Also, at some point in the past I built a parameter system and a set of VSTGUI components that could be linked to these parameters so that parameter changes trigger GUI updates and vice versa, and that would be an additional extra that helps build things faster. Although I realize people might prefer their own parameters system, so it should be interchangeable then… which complicates things…

About code style: keep at it! We like the Jules style, and the interfaces are nice!

I agree that it may be time to structure things just a little better and get other people involved. If money is an issue, I think we could live with some changes in the licensing :wink:

Keep up the good work, and good luck with the NAMM thingie!

My 2 cents,

Koen

51

I think you’ve pretty much nailed why Jules needs some help. I totally agree on the documentation. I’ve been using JUCE a while, and I’m still not sure if I’m using the Command Manager system in the properly prescribed way.

The demo is great for seeing how to get something up and running, but doesn’t provide much guidance on how best to approach a large application. That kind of stuff is horribly time consuming though, and with a fast moving library, could get stale very quickly.

A community effort could help, but I think the only good approach would be an actual community project. A living breathing open source application that people derive some benefit from extending would be the best place for newcomers to look for practical examples of application layout, messaging, etc.

I guess the juce/introjucer could have fit that roll, but with Jules off changing the world, I’m not sure what their long-term viability is.

52

Personally I am very puzzled by the fact that compatibility with the Mac App Store has never been considered a priority.
Like everyone, I really appreciate the quality of the work of Jules. I did not think it possible that a single person could accomplish so much. However, I would be much happier to see his talent directed to targets less sophisticated but more needed than Projucer.

53

Um… That’s because there’s nothing that needs doing for that. AFAIK the only detail that was missing was the “recent files” menu, but that’s done now.

54

Jules have you considered hireing somebody to do the Windows 8 backend, maybe even Native Client, and new audio plugin standards?

I’d think that lack of Win8 in particular is something that hits most jucers right now, but it should be possible to delegate out work with a minimum of communication, and without impact on the overall design. Is there any reason that it has to be your precious time doing that?

55

Jules grips his source code so tightly that if you inserted a piece of coal to one of the files in a few days it would become a diamond.

56

This is not true. As I have repeatedly pointed out in the appropriate thread, the menu “Open recent” is not properly constructed. In addition, using a sandboxed application as required by the Mac App Store, you are not able to reopen the files that were opened in previous sessions.

57

Well, so what about the follwoing financing model: crowd funding.

Jules, you could start a crowd funding site and we all could donate.
For example you could set up a specific goal like: I want to raise 100,000 Euros in order to hire a decent programmer, who can implement Windows 8 support.

What do you think?

58

With all the talk of a ProJuicer mini-IDE , anyone here use REALStudio ?

I have to say that I find using REALStudio to work on my ideas so much more productive and enjoyable than when I am forced to work in C++. Admittedly i use only XCode at the moment, and maybe Visual Studio
is not a “hair-puller” any more - dunno.

I put together a subset of “mock” JUCE classes inside REALbasic - which emulates the functionality of the core JUCE audio classes of interest to me.

I would always prefer an environment/IDE that doesnt constantly make me think back to headers, text files, #includes and the like…

PS - crowdfunding sounds like an excellent idea.

59

REALStudio …hmm… I have never heard of this IDE! Cool name…sounds promising. I will go look at it right now!

60

Only thing it cant do YET… is create dynamic libraries. hence no use for developing plugins.

But their move to LLVM is going to enable that.