Version 1.31 and The Jucer v1.0!


#1

Ok, the Jucer has finally arrived! It’s part of the juce source tree, available in the new build I’ve just uploaded. Let me know if I’ve broken everything!

* First release of the Jucer! This is a component development tool that lets you design Juce components and produces c++ code. This initial release is functional but still a work-in-progress - it will be an ongoing project, adding more and more functionality and shortcuts for creating juce-based code. The Jucer source code lives inside the Juce tree, in the juce/jucer folder.
* new class: PositionedRectangle, which specifies a rectangle using either absolute or proportional co-ordinates, and giving flexible control over the anchor points used. Handy for positioning components.
* new set of classes: PropertyComponent, PropertyPanel and various basic subclasses of PropertyComponent. These allow you to quickly set up a properties panel for something, e.g. a selected object, which shows a list of named properties of various types, e.g. text, sliders, combo boxes, etc.
* added a method ApplicationCommandManager::setFirstCommandTarget() to make it easier to set up non-component command targets
* change to the FileBasedDocument load/save methods so that they can return an error message on failure
* new method: Graphics::fillCheckerBoard()
* added options to FileChooser and FileChooserDialogBox to prompt the user about overwriting files that already exist
* change to TabbedComponent, so that instead of using a virtual method to create the components for the tabs, you add components using the addTab method and the TabbedComponent looks after them for you.
* fixes to some focus issues, such as popup menus temporarily moving focus away from the main window
* new class: MultiDocumentPanel to hold multiple document windows as either floating DocumentWindows or in a TabbedComponent.

I’ve not had time to write anything about how to actually use the Jucer, or to sort out a compiled binary of it, but will do so soon. In the meantime, early adopters should feel free to have a go!


#2

Oh - I should mention that in juce/jucer/ there’s a To Do List text file, where I’ve kept a list of stuff I want to add to it. So before you all start shouting about what features that would be cool, check I’ve not already thought of them!


#3

very exciting! :slight_smile: thanks for the update, eagerly downloading it now (and haven’t even finished reading your post :hihi: )


#4

:shock: sincerely thanx for the jucer. it’s one of the more amazing piece of code i’ve ever seen lately. especially the vector graphics editing feature !


#5

Ta very much. I’m pretty chuffed with the way it’s turned out - not bad for a couple of weeks hacking!


#6

yes, it is indeed fantastic. kudos, credit, karma and coolness for you


#7

Ok, enough complements now, you’ll make me blush…


#8

ehehe :slight_smile: as i say, you are never fullfilled of compliments as you should, cause one step beyond all of us… i see what i can do till friday trying to inoculate scripts into that bearded piece of software!!! (btw. i’m having nightmares of a JUCERAD every night…) :roll:


#9

oh yes! congratulations on the beard, too. us bearded folk are far too few nowadays.

1 itty-bitty thing about the jucer- the class panel really needs a way of specifying constructor params like the generic component sub-component thing has. :wink:


#10

(Damn - just noticed that I mis-spelt “compliments”. Doh)

And ok, constructor params sound like a sensible thing to add.


#11

Absolutely brilliant, I can’t believe you did this in two weeks. :shock:


#12

very cool indeed!

It’d be nice if the shape tool treated the endpoints of a closed line as just a normal line. Currently you can change the line type between those points.

The anchor stuff is very neat.


#13

[quote=“valley”]very cool indeed!

It’d be nice if the shape tool treated the endpoints of a closed line as just a normal line. Currently you can change the line type between those points.

The anchor stuff is very neat.[/quote]

Ta. Do you mean to just remove the end-type option if the shape is closed? If so, I can’t do that because when I’ve added some sub-path controls, you’ll be able to have multiple sub-paths in the same shape, each of which may be open or closed.


#14

What a great piece of work Jules ! And nice picture in the about box. Did you really count your beard hairs ? :wink:


#15

Of course - and each hair’s length is proportional to the length of the line of code.


#16

[quote=“jules”][quote=“valley”]very cool indeed!

It’d be nice if the shape tool treated the endpoints of a closed line as just a normal line. Currently you can change the line type between those points.

The anchor stuff is very neat.[/quote]

Ta. Do you mean to just remove the end-type option if the shape is closed? If so, I can’t do that because when I’ve added some sub-path controls, you’ll be able to have multiple sub-paths in the same shape, each of which may be open or closed.[/quote]

Sorry, it was late, and I was trying to get my head around the new ApplicationCommand stuff (rather neat). I’ll try and make sense this time. :oops:

Let’s say I have a shape with just three points. Currently jucer treats points 0 - 1 as a line, and it treats point 1 - 2 as a line. If I turn on closed contour, points 2 - 0 are shown as a line, but that line cannot be edited in the way that other lines can. I.E. lines 0,1 and 1,2 can be set to quadratic, whereas the virtual line 2,0 is fixed linear.


#17

Yes, that’s just because everything maps onto the items in the Path object - so the closing line represents the final “closeSubPath” item, which can only be a line. You can of course move the end point to the same place at the starting point so you don’t see the line. That’s something that should probably be done automatically by a smarter UI.


#18

Seems I’m a bit late here, but I have to agree, the jucer is very cool 8). I can see it saving me a lot of time in the future…

  • Niall.

#19

jules, about 1.31 new TabPanel additions… i’ve found that if doing

[code]void TabbedComponent::removeTab (const int tabIndex)
{
Component* const c = contentComponents [tabIndex];

if (c != 0 && c->getComponentPropertyBool (T("deleteByTabComp_"), false, false))
{
    if (c == panelComponent)
        panelComponent = 0;
	delete c;
}

contentComponents.remove (tabIndex);

tabs->removeTab (tabIndex);

}[/code]

is not leaking in the case you are removing the selected tab (and also deleting its content component), cause when u fires up the changeCallback, and c == panelComponent, then panelComponent isn’t valid anymore…


#20

[quote=“kraken”]jules, about 1.31 new TabPanel additions… i’ve found that if doing

[code]void TabbedComponent::removeTab (const int tabIndex)
{
Component* const c = contentComponents [tabIndex];

if (c != 0 && c->getComponentPropertyBool (T("deleteByTabComp_"), false, false))
{
    if (c == panelComponent)
        panelComponent = 0;
	delete c;
}

contentComponents.remove (tabIndex);

tabs->removeTab (tabIndex);

}[/code]

is not leaking in the case you are removing the selected tab (and also deleting its content component), cause when u fires up the changeCallback, and c == panelComponent, then panelComponent isn’t valid anymore…[/quote]

Ah, yes - thanks kraken, that’s a good fix!