Features requests


#1

Ok, I’ll post here my two pet feature requests, just in case Jules feels he has too much free time :slight_smile:

  • a TextEditor that is able to receive keystrokes events with non cooperative plugin hosts . For now I use something inspired by the “ModalTextEditor” of http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=1662&postdays=0&postorder=asc&start=30 but that is not a good solution, there are too many issues involved with focus.

  • a MagnifierComponent that sends correct mouse events so that is it possible to use an entire interface that is zoomed in/out ( http://www.rawmaterialsoftware.com/juceforum/viewtopic.php?t=3324 )
    That would be really neat, I think.

  • a sort of basic cross-platform accessibility layer. I don’t really know how these things do work, but I’ve been getting numerous requests from blind people. Audio plugins and hosts are for sure some of the least accessible softwares.


#2

I’ve got another.

I’m trying to subclass DrawableButton to make the images in the button larger, but I can’t override paintButton() even though it’s public, because I can’t access private members of DrawableButton in the subclass, like style, edgeIndent or even images.

Could the drawing of the Image in a drawable be moved to a LookAnd Feel function?


#3

And another:

Could TextEditor::getTotalNumChars() be made public so I could call it with a TextEditor object? This would allow me to quickly be able to tell the TextEditor to select all, by passing this value as one of the parameters to setHighlightedRegion().

Another alternative would be some TextEditor constants, like TextEditor::endOfText, which could be passed in lieu of an actual count.


#4

…what’s wrong with getText().length()?


#5

getText().length() does the job, but is pretty inefficient. I can easily make getTotalNumChars public.


#6

Ah, getLength(), thanks, I hadn’t even thought about that.

To figure out what I wanted to do, I was trolling through the TextEditor code, and whenever that code needs to find the length, it calls getTotalNumChars. The comments in the header made me think that getTotalNumChars was intended to be public, not protected.

Thanks for the work-around.


#7

Another request…

I just spent a couple hours trying to figure out why all the keyboard shortcuts for my menu items weren’t working, but the menu items were. It was a complete mystery until I happened across the very helpful comments at the top of KeyPressMappingSet.h Thanks for those!

Would it be difficult to have the ApplicationCommandManager automatically set itself up as a key listener, so novice programmers wouldn’t have to go through this? If I’ve set a command’s ApplicationCommandInfo to include a default key press in a ApplicationCommandTarget::getCommandInfo() routine, could the ApplicationCommandManager automatically listen for those keypresses?


#8

But what would it register itself with? Your top-level windows might come and go over the course of the run…


#9

OK, I haven’t thought this out completely, so I may ramble…

I’d like my main menu (on the mac) to be persistent, even if all windows are closed, so I’ve put my ApplicationCommandManager at the application, not window level.

My issue wasn’t with what components are key listeners, but rather that I had a menu bar that was responding to commands when selected, but not responding to keyboard shortcuts. I hadn’t realized that simply adding a keyboard shortcut in getCommandInfo() wasn’t sufficient.

So then I thought, well, the ApplicationCommandManager is persistant, and knows how to execute the commands in my menu bar, so why couldn’t it also be a key listener? If that were the case, then I wouldn’t have to register windows or other components to be key listeners for menu bar items.

If the ApplicatonCommandManager can know that a menu item should be active based on the CommandTarget heirarchy, then it should know how to respond to a default keypress that corresponds to each menu item. If the item is disabled because the CommandTarget that handles it isn’t in the chain, then the keypress can be ignored.

There’s probably some fatal flaw in my logic, but it might also be that the addition of the ability to put the menubar in the mac menu bar rather than in a window (thank you!) has opened up some new issues.