v1.29


#1

Jules, what will be in the next version ? (1.29)
In a more general thread, can you upload your schedule for the next-features for each release (if you have one) ?

It’s just that if anybody (like me) would like to help on Juce, it is easier not to work on the same thing to avoid duplicating and trashing the efforts…


#2

You just beat me to it… V1.29’s up there now…

* moved the Juce demo app into the main Juce tree, to make it all easier to download
* added classes for FLAC and Ogg-Vorbis audio formats
* added support for native window title bars and borders
* moved the window style flag enum out of Component and into ComponentPeer, adding lots of new flags.
* changed some of the methods in ComponentBoundsConstrainer so it'd work with the new windowing stuff
* couple of minor fixes to named pipes on windows
* some Quicktime component fixes and optimisations
* changed the AudioFormat class to allow multiple file extensions, and added a method AudioFormatManager::getWildcardForAllFormats() to make it easy to show browsers for audio files
* on OSX, added a juce.xcconfig file to the XCode build, to make it easier to select whether to build for gcc3 or 4
* made the TabBarButton class public to allow customised tab bar components
* changed the default font on OSX from Verdana to Lucida Grande, as Verdana isn't actually guaranteed to be installed on all systems

And my plans for the next few things to do are (in no particular order):

  • toolbars
  • printing (my current plan is to write a graphics context that generates Postscript)
  • custom shaped windows (using a path rather than transparency)
  • RTAS support for the audio plugin stuff
  • better application command model (linking menus, buttons, toolbars, key shortcuts, etc with command objects)
  • carry on with the Jucer component designer, which I started, but which is on hold until I’ve done the better app command model

#3

thanks again! well done! :slight_smile:


#4

Awesome!

Are you still considering adding Tooltips to the other pre-defined JUCE controls… or, even better, to the Component class?


#5

Jules, I’m currently writing a PDF reader along with a document component.

Maybe we could merge our effort to produce a PDF reader and writer (if it is what you mean by Postscript [postscript is a programming language by itself]).

Email me if you want to tell me what is your current design.
BTW, once again you are still quicklier than me.


#6

[quote=“Randy”]Awesome!

Are you still considering adding Tooltips to the other pre-defined JUCE controls… or, even better, to the Component class?[/quote]

ah, I’d forgotten about that one - thanks for reminding me!

well maybe - all I was planning on doing was writing a LowLevelGraphicsContext that turns drawing commands into a postscript file, and then that can go to the printer. I had a quick look at some postscript and it looks fairly easy. Don’t know anything about pdf though.


#7

Jules, what this about a JUCE Component Designer? Can we have bit more info on that? As a side note/question, Would I be right in saying that you’re no longer involved in the development of tracktion?


#8

Yes, I’m working on a component designer that churns out c++ code. Should be pretty cool, but only half-written at the moment, and needs some other stuff writing before I can finish it. Will be able to do things like incorporate sections of user code, and maybe draw stuff with graphics primitives as well as just positioning sub-components.

And no, I’m not really doing much for tracktion these days. The guys at mackie have got it pretty well covered.


#9

[quote=“jules”]

And no, I’m not really doing much for tracktion these days. The guys at mackie have got it pretty well covered.[/quote]

But let me just say that Tracktion is still built on Juce and all the cool new stuff that Jules has doen with Juce has benefited Tracktion imensely. Hopefully everyone will see this before too long.

Ben


#10

Sweet - I’ve wanted native window support for a while.

Also, thanks for changing the default Mac font. One less thing to worry about.

Matt


#11

I have two feature requests:

If you have a AudioIODevice*, there should be someway to get the type name or the AudioIODeviceType pointer.

There doesn’t seem to be anyway to set if an ASIO device uses a thread anymore.


#12

[quote=“G-Mon”]I have two feature requests:

If you have a AudioIODevice*, there should be someway to get the type name or the AudioIODeviceType pointer.

There doesn’t seem to be anyway to set if an ASIO device uses a thread anymore.[/quote]

yes, fair enough. I can add that.

Nobody else seems to bother use ASIO with a thread though, so I think that bit’s pretty outdated now. The code’s still all there, so you could hack in some methods to turn it on if you need it for some reason.


#13

so going back to my previous question, beno has tracktion kept up with the current version of JUCE in using it as part it’s development framework? I can see the benefit in doing since it would essentially simply cross-plaftorm support.


#14

Tracktion 2.x was not up to date with Juce. The next major release is built on the latest and greatest Juce and subsequent releases after that will continue to use what ever is the most recent Juce at the time of development. At least, that is the plan.
Ben


#15

thanks for the heads up beno.


#16