v1.30


#1

Ok, this release has taken longer than usual because I had trouble designing the new “app commands” feature in it, but after quite a few re-designs and much head-scratching, here it is… Changes are:

* major set of new classes to introduce "application commands". This is a powerful mechanism for despatching commands to command targets. It allows commands to be bound to keystrokes and easily triggered by menus, buttons, etc. New classes to support this include ApplicationCommandManager, ApplicationCommandTarget, ApplicationCommandInfo. I've rewritten the Juce demo to use commands to control its menu system, and added key-shortcuts to select the various demos.
* the new app command stuff replaces a lot of the functionality that was in KeyPressMappingSet, so this class has been slimmed down with some functionality moving into the new classes. I've renamed the createXml() and restoreFromXml() methods to draw attention to the slight difference in the way they're used, (and to make the names more consistent with other code)
* new class SettableTooltipClient, and made a lot of the existing widgets inherit from this, to make it easy to set tooltips for them
* new flag in the Justification class - horizontallyJustified, which spreads text out to align both its left and right margins
* tidied up the Uuid class and got rid of any platform-dependent libraries it was using
* the constructor for the Thread class now takes a name, and on windows this gets passed to the debugger to make it easy to see which thread is which. (Haven't got mac or linux implementations for this yet)
* some UI fixes for running under KDE on Linux
* added a File::areFileNamesCaseSensitive() method
* added a method to the MidiInputCallback class to handle incoming sections of a long sysex message. (This is only currently supported on the mac)
* the XML parser now loads extended UTF-8 characters correctly

There’s quite a lot of other minor bug-fixes in here too that I’ve not listed here.

The new app command stuff will probably require some re-writing of your code if you currently use KeyMappingSet to invoke commands, but the new design is much more powerful and opens up possibilities that weren’t there before. Give me a shout if anyone has any difficulties with it or needs more explanation than is available in the comments and demo code.


#2

Excellent stuff jules. Having just moved into ‘writing a full app’ territory, I’ve just spent a little while organising app-level commands, so I can immediately see the usefulness in this update.

Keep up the good work! :slight_smile:


#3

Yes - it’s all stuff that I need for the Jucer - so now I can get back to working on that and hopefully have something you guys can play with in a couple of weeks…


#4

whau, the ApplicationCommands are really really useful, nice one!
i think only that the perform callback is a bit trivial, since in getCommandInfo one should be able to attach to a command a callback function, and get rid of the perform switch dispatch:
i have my functions that performs big computations, i can’t put in perform switch, cause the code will be unmaintainable, i leave in external methods, but then i have a perform switch that do nothing more than calling the methods, and that’s a bit repetitive tasks, cause if i add a new command, i have to register it, making its info, and adding a dispatch in perform to its real execute function… why not only register it, fill out the command info with also specifying a callback method to be executed (and so not to worry about perform) ?
just throwing ideas in… not to criticize your extremely gr8 work.


#5

[quote=“kraken”]whau, the ApplicationCommands are really really useful, nice one!
i think only that the perform callback is a bit trivial, since in getCommandInfo one should be able to attach to a command a callback function, and get rid of the perform switch dispatch:
i have my functions that performs big computations, i can’t put in perform switch, cause the code will be unmaintainable, i leave in external methods, but then i have a perform switch that do nothing more than calling the methods, and that’s a bit repetitive tasks, cause if i add a new command, i have to register it, making its info, and adding a dispatch in perform to its real execute function… why not only register it, fill out the command info with also specifying a callback method to be executed (and so not to worry about perform) ?
just throwing ideas in… not to criticize your extremely gr8 work.[/quote]

I re-designed the whole thing about 4 times before I chose the current plan. Callbacks sound nice, but in practice were a lot messier.

For example if you have 10 commands, each of which should call a method on an object, then with callbacks you have to write 10 callback functions, each of which needs to find a pointer to the object and call a method - so every callback function has to contain the same block of code to find the object - very long-winded and messy, and you end up with 20 functions. Using a switch statement, you find a pointer to your object once at the start of the switch, and each case just calls a method on it, so you end up with just 11 functions, and far less code.


#6

yeah gr8 :wink:


#7

boost::function is infinitally useful for such things, and boost::signals is even better. You can use just those parts and include them in your app. I made a system that allows anything to make an event, anything to register to any event, events to call other events by linking them, all are many-to-many relationships, and all key’s and mouse movement/buttons are registered as basic types that anything can link/listen from. All with very little code. Can even pass data using boost::any.


#8

Thanks!


#9

There is a bug in the XmlDocument class.

Ln 147 should be:

if (data.getSize() >= 2 && ((data[0] == (char)-2 && data[1] == (char)-1) || (data[0] == (char)-1 && data[1] == (char)-2)))

#10

Ah - quite right! Thanks, that’s definitely worth checking!


#11

edit: never mind


#12

Is there any plan to to allow shortcuts to differentiate between the numbers on the number pad and the number above the letters?


#13

No plans at the moment. I’ve a feeling it’d be quite tricky, and don’t know how it’d differentiate the types of numbers when the key shortcuts are stored as strings.


#14

Dont’ know how it is on other OS’s, but the enumerations that come with windows for low-level keys are things like KEY_# (where # is the number) for the numbers at the top row, and NUMPAD_# (where # is the number) for the numbers on the keypad. Of course, if you are using standard windows messages and not listening for the low level messages (albeit, NT based systems only, not 9x), then it can be difficult.


#15