Santaclaus wishlist for the Jucer

As you’re planning to re-build the Jucer this year, here’s my own, personal, wish list of features I’d like to see in the Jucer. If you guys think of anything else, please append this post.

[list]
[] Being able to specify members in the Jucer interface, with default, contructable value (currently, “constructor param” doesn’t work as soon as default values are used)[/]
[] Being able to specify the base classes/interfaces of the component. (So it can automatically implements the pure virtual method, the interface definition should be in a manually editable file too)[/]
[] Specify method in the Jucer too (with documentation ?)[/]
[] Add a documentation field in every component’s item[/]
[] Please, please move the constructor on the bottom of class declaration. I’m often declaring enums in the (userMethods) area, and because the constructor is on top of the class (above the enum), it doesn’t see the enum and breaks compilation[/]
[] Support for more juce’s component (I’m desesperately missing DrawableButtons, ListBox, for example)[/]
[] Global “percentage length” mode (it’s a pain to always select “Percentage of width/height” for any change). [/]
[] A better support (editable list) of our component’s colourID enum (after all, you’ve set up a common setColour/findColour interface, it’s a pain it’s not in the Jucer)[/]
[] A stack based double arrow for selecting component/graphics below / above the current selection (when component/graphic overlap, it’s not possible to select the one below, except by sending the front item to back)[/]
[] Editor in the last tab should save its content when getting hidden (and as such, shouldn’t loose any changes in it)[/]
[] Allow “x% - something” in the position. For example, if you want to draw a circle with 100% width, 100% height and a 10px outline, it’s not possible without hand editing the source (if you don’t half the outline fall outside the component clip area). The formula IN THIS CASE should be “proportionOfWidth(1.0f) - outlineWidth / 2”. An ideal world scenario, would be to allow text editing here so we can specify the variable to substract.[/]
[] Outline width / Text font should be switchable to proportional too. Come on, we aren’t doing pixel based graphics anymore. A font size is often dependant on the component height. (Most of my time is spent fixing pixel based size to proportion based size so the application looks the same whatever the screen size)[/]
[] When converting a text to path, it could be useful to keep the proportion’s in the conversion (and not fixed pixel size like it is currently) => global percentage checkbox?[/]
[] Path editing should allow creating a new path as a hole of the current path (boolean operations ?) I know this is a pain to implement in Juce, but the Jucer could use external LGPL based polygon intersection library [/]
[] A new tab for graphics in paintOverChildren (or at least, a check box in the graphic tab item’s properties)[/]
[] A check box in the component tab to enable “deleteAllChildren” instead of the multiple “deleteAndZero”[/]
[] Being able to specify a mouse cursor for the component[/]
[] Allow resource not to be included as binary dump, but as the smallest relative path (base path editable ?) to the resource file (if I want the update the resource picture, I will only replace the resource file, and not reload the jucer and loose all my manually edited work)[/]
[] Add caching for drawable as an option. The SVG file I throw to the Jucer takes milleniums to draw, but using a CachedImage computed in “resized” save this drawing time each repaint.[/]
[] Not really needed, but the zoom mode doesn’t work well, it would probably work better if everything was proportional in the jucer interface (and not using a hack).[/]
[] In an ideal world, the component I’m making in the Jucer would be added to the jucer’s component definition template file, so they are available as basic building blocks in the jucer (in the component tab). I don’t know the implication of this.[/][/list]

Thanks! Some good ideas there!

would also be good, let Juce run Linux applications that are on routes that include spaces.

Jules post gave me a solution, please add in the new Juce.

http://www.rawmaterialsoftware.com/viewtopic.php?f=5&t=4879

A few more wish list items:

  • Support for image based sliders/knobs/etc. Ability to point to the graphic file in the Jucer and preview things.

  • A second of the request for relative paths for resources, so we don’t have huge blocks of text for images and such.

If this is a total pie-in-the-sky wishlist:

  • Ability to create new Look-And-Feel for sliders, knobs, etc., by manipulation of graphics in Jucer. This would essentially replicate the functionality of Knobman, but instead of spitting out filmstrip images, it would spit out code for dynamically transforming geometric primitives, and wrap that into a LookAndFeel class.

  • A warehouse full of gold, such that you can have some gold to support yourself while implementing such things. I get some gold, as well. As long as we are wishing.

Sean Costello

Don’t worry, my cunning plans will let you do that kind of thing and more. Probably without even needing to write any code.

Yep, that was on my christmas list too, but santa failed to deliver. Maybe next year.

Todo list:

  1. Write an application that do what you want by simply telling it aloud.
  2. Conquer the world.
  3. Profits?

For all I know, this might be in there, but anyway:

  • Ability to save a layer as a bitmap, png, etc. This is mainly to avoid embedding fonts into the application/plugin that shouldn’t be publicly distributed.

Sean Costello

The graphics editor that I’m planning will let you add text, and will certainly let you convert text to a path, so that’d be a much better solution than saving as a bitmap!

Planning? But I want it NOWWWWW!

Here’s another wish: Guide lines, as in Illustrator. Trying to use grid design here, and having these user definable guide lines in the Jucer (separate from the square grid in the background) would allow me to place components with the accuracy I am looking for, so I can skip using Illustrator.

Thanks,

Sean Costello

Yes, guide lines are going to of major importance, because they’ll be what handles all the relative positioning of objects.

Cool! Another feature that would be nice is the ability to incorporate your own LookAndFeel classes without recompiling the Jucer. Although, if the new functionality allows you to create a LookAndFeel type feature without writing code (i.e. you can change things in the tool itself), that would be great as well.

I’m enjoying the current Jucer immensely. Last night, I replicated my Knobman filmstrip images as a LookAndFeel class modification to the existing Slider class, and recompiled the Jucer with my new LookAndFeel, so now I can have my knobs work in the Jucer, with arbitrary size/color, and no need to move back and forth between Windows and OSX.

Sean Costello

My plan is for the l+f to be dynamic, so you’ll be able to preview the designs in the jucer as you work on them.

DId someone ask for a way to link controls to data? Now we have the handy data watchable data classes, be nice to specify a link between a control and data.

Since the data probably won’t exist at the time (and the control should create it if it’s not found) there may need to be some sort of standardized ‘DataManager’ in the same way there’s a ‘CommandMananger’. That way we can code links to data in one place, and then access them from jucer controls by name/ID?

I’d probably personally prefer a more filled in scheme, where you specify a path to data within a tree held by the main doc, but I think a version where we can code a ‘look-up’ table much like getCommandInfo() - say getDataInfo() would be more consistent with juce on the whole. I don’t think the item in jucer needs to be much more than a string that indicates the data ID, and a toggle to set one way or two way linking. NamedValueSet is similar, right?

Bruce

I’ve not thought this through very deeply yet, but my vague plan was to connect things like sliders to their own Value object in the parent class. Then you could control the slider by setting the Value, or just call Value::referTo to connect it to some other data source or a custom one. I think that’ll probably cover most things you might want to do. And the parent class could be a listener for all its Values so you’d get told when they change.

Yeah, I like that. Will make it easier to have a selection set in the component and change data links.

But another thing occured to me - will there be some way to make a simple GUI from data only? It’s nice to able to give users the ability to do a simple GUI section of their own. Often that’s just a simple panel of buttons.

Bruce

It’s an interesting question - essentially there’s no reason a gui couldn’t be created dynamically from a jucer component file. After all, the jucer file contains all the xml data you need to construct it. The problem is that there’d be no way to add any custom code to control it, so all you’d have would be an opaque component, and you’d have to iterate its sub-components to find the ones you want to control and control them directly. For some purposes that might be enough though. Once I’ve got the basics working, it’ll be fun to experiment with ideas like this!

Anything planned for PropertyPanels? I saw that you refactored so the basic classes can be used, and that sounds like a good change - I made a lot of classes at one point, then made my own generics. But it’s still a bit of a grind to populate a panel, unless something else changed I missed.

Maybe create a propertypanel set of properties as a jucer component? Then the code can just load that set. Even better would be something more like a tab panel - acknowledge that PropPanels will need a variety of ‘sets’ of properties and allow them to be edited right in the jucer?

Bruce

I’m certainly thinking about that kind of thing, as I’m using propertypanels in the jucer at the moment, but haven’t got any concrete plans yet.

one good addition in the new jucer would be the ability to use the keyboard arrows to move and resize generated vector elements in graphics, not only components. this is very handy when you need to align paths and images to components.