i was thinking about that is the end of the 2k06, and asking myself what kind of extremely kicking ass ideas there will be in the forthcoming JUCE release for 2k07?
i’ve got a bunch, but i don’t tell until the lord has first spoken !
I haven’t got a big plan right now, but after I’ve got a couple of other projects finished in january, I think it’ll be a good time to have a serious think about this…
Happy new year all!
ok, i’m throwing in… (EDIT) i’m collecting all the ideas the people would like to throw in the bin (not the thrash bin!)…
Containers:
- HashTable, treated like the Array classes, with diversification OwnedHash, VoidHash for every specific use case
- more containers like the Stacks, Lists, CirculaBuffers all in the same style of the whole containers classes… (i lack a lot a container in the form of Map<int,String> or Map<String,Object*>, the PropertySet can’t take pointers…)
- iterators for all containers (ala Path::Iterator)
- the Variant class
Graphics:
- ability to draw things onto Graphics with overlay mode: xor, colour burn, darken, brighten, something like what Photoshop could do
- ability to use tiled Paths as brushes for dynamically settable fill patterns
Audio:
- classes to transform audio stream from time domain to frequency domain and ability to work with FilterClasses for spectrum.
- MP3 audio format support
- inclusion of libsndfile for multiple sample format support ? - a ParameterManager in the juce filter plugin, with a lightweight setup where to define Parameters in the filter, and attach them to components
Components:
- basic html component for visualize basic html pages (support for font modifiers, divs, background colours and such), something like the current TextEditor but with the possibility to set its text in html code directly
- calendar component with interchangeable header and possibility to select multiple date ranges
- a more complex dockable component for making UIS from windows that can be docked in the main component (ala visual studio). if this component is present as parent component, all childs will be dockable, otherwise they’ll remain at fixed position as usual.
- make the Toolbar dockable
- add some more look and feels that mimics the feel of some platform (winXP, gtk / qt clearlooks, …). Eventually think a way to make look and feel external libraries loadable and interchangeable at runtime.
OpenGL:
- OpenGL low level graphic context to let game developers finally have a decent in-game gui system (huge developer community ahead).
- Better OpenGL thread support (with TimeSliceThread per opengl context) for 3D applications development
- OpenGL context pixel formats, extensions, multi platform pbuffers support…
Distribution / Packaging:
- Multi platform install, deinstall and update system for final applications
- Multi platform Crash Agent framework for reporting unhandled errors - Multi platform build system - CMake is great !
- SVN server, at least for easier diffing between versions
- Multi platform DynamicLibraryLoader
Linux Specific:
- finish and clean socket support
- completing XDND support
- full JACK support as audio output (and also as juce audio plugin streamer)
- freedesktop tray icon area support [i’ve started doing it and something will be ready next days]
- Linux distribution using packages - this way Juce could be far more spread to linux community
Jucer:
- SVG export and import
- XML import and export, and move the serialisation and instanciation code inside Juce so that it can be used to dynamically create Components from a Jucer-made “skin”
- Ability to add/remove custom properties that you can get back with getComponentProperty on any components - this lets you do a quick command mapping for instance, or many other usages.
i’ll continue to update this later, if people would like to contribute.
after we can make something like a poll, for see which ideas got the best votes ! (and hoping jules will hear us!)
yes, some good ideas there - keep 'em coming!
apart from the audio stuff, these ideas are coming along with a project i’m developing, is a sort of client-server map engine, focused on my town. it supports a variety of spatial vector formats (thanx to the server side) and georaster ones, it implements independent layer rtree indexing for working with thousands of points, it uses parallel threads for fetching data while still working on the components (non blocking). and it’s 100% extensible with nothing hardcoded… means you need to load another vector format or to attach to another server page that streams you something to display ? just write your driver and register it with the engine. and you can also write your driver dynamically, or control the map with the embedded scripting engine… and all is fluidificated with juce…
cool eh ?
Sounds good!
+1 for dockable stuff !!
If it is time for a gift list, then let’s go :
OpenGL:
OpenGL low level graphic context to let game developers finally have a decent in-game gui system (huge developer community ahead).
Better OpenGL thread support (with TimeSliceThread per opengl context) for 3D applications development
OpenGL context pixel formats, extensions, multi platform pbuffers support…
Audio:
MP3 audio format
Distribution / packaging:
Multi platform install, deinstall and update system for final applications
Multi platform Crash Agent framework for reporting unhandled errors
Multi platform build system - CMake is great !
Linux distribution using packages - this way Juce could be far more spread to linux community
SVN server, at least for easier diffing between versions
Jucer:
SVG export and import
XML import and export, and move the serialisation and instanciation code inside Juce so that it can be used to dynamically create Components from a Jucer-made “skin” …
Happy 2007 !
I have a pretty obvious wish (obvious for those who read my rants in the mac-section):
The ability to avoid the HI-stuff in mac specific juce, and draw directly to windows, like in the (good?) old days. I don’t know how this could be done, but maybe by doing a certain #define… If it can be included without too much work, then Juce will still be future-proof, but without leaving the G4 users with their *sses in the water-crust (as we say in Denmark - anywhere else?).
That would be neat 
-
Happy newyear!
-
A
[quote=“amygdala”]
The ability to avoid the HI-stuff in mac specific juce, and draw directly to windows, like in the (good?) old days. I don’t know how this could be done, but maybe by doing a certain #define… If it can be included without too much work, then Juce will still be future-proof, but without leaving the G4 users with their *sses in the water-crust (as we say in Denmark - anywhere else?).[/quote]
I did this, it is pretty easy. Go back to old juce (1.34 i think), grab the MacWinowPeer class, move it into MacWindowing.cpp
then change the createComponentPeer class to create HiViewComponentPeer on Intel machines and MacWindowPeer on PPC
one more thing for the Jucer (this could be really cool !) :
- Ability to add/remove custom properties that you can get back with getComponentProperty on any components - this lets you do a quick command mapping for instance, or many other usages.
[quote=“thomas”]one more thing for the Jucer (this could be really cool !) :
- Ability to add/remove custom properties that you can get back with getComponentProperty on any components - this lets you do a quick command mapping for instance, or many other usages.[/quote]
Interesting idea - I’ll note it down.