Hi,
I was thinking about what could be in the next JUCE version. So, why don’t we create a specific thread for this ?
If Jules is okay, we could create a thread for each new version.
Please post here your most important modifications (patches) that should be included in the next version.
Regards,
Cyril
i wouldn’t be at all, you seem to know exactly what you’re doing mr jules. big congratulations on the T2 release btw 
:!: :!: 8)
i’ll throw out a couple ideas…
it would be nice if the combobox would accept up/down arrow keys to select next/previous items from the list. given that the text is possibly editable, you’d have to figure some way to select the box and not the text, so perhaps the menu icon (the up/down symbol on the right) would stay selected and could also be added to the tab order and perhaps the mouse-wheel could function here as well.
this would be nice for something like say a font selection from a large list. you’ve got some text you want to see in different styles, so simply hitting “down arrow” while your font menu is selected goes to the next selection as though you picked it with the mouse. (not to be confused with the font demo portion of the demo app that doesn’t use a combobox for the font selection).
[edit: looks like this functionality actually exists, but it’s difficult to identify when a combobox has the keyboard focus w/o some sort of visual indication.]
for a texteditor (particularly single-line texteditors) it would be nice to have some simple means of editing in a larger window. like an additional entry in the right-mouse popup would be “edit” which would open a new text editor a la the source view editor in the demo app. you would edit, then quit and the edited text would end up in your small texteditor window.
also a triple-click “select line” is sorta semi-standard these days for text editing.
for sliders, an additional option could be editable min/max which would allow the end user to adjust the min/max range with simple text-entry (like the value text-entry). [value] [min] -----v------ [max]
yes, one of the things I mean to do in future is add more obvious feedback about what’s focused.
I’m nearly ready with a new release actually - the big new feature will be all the crypotgraphy classes.
Good point about triple-click - I might extend the mouse events to give a count of the total number of double/triple clicks.
i’m just trying to figure out how the library works, so i’m puttering around with a few different things… also, i don’t actually know c++ (been programming c for a while, tho) so i’m also just sorta of figuring that angle out…
i did add keyboard functions for the drop down menus, tho. probably there’s a toggle somewhere to do this (a la setMouseMoveSelectsRows()) but i didn’t see anything in the docs about it. so hard coded the following in juice_combobox.cpp:
//==============================================================================
class DDPopupComponent : public Component,
private SimpleListBoxModel,
private Timer
{
public:
DDPopupComponent (ComboBox& owner_)
: owner (owner_),
dismissNow (false)
{
...
(code changed below)
void keyPressed (const KeyPress& key)
{
if (key.getKeyCode() == KeyPress::spaceKey || key.getKeyCode() == KeyPress::returnKey)
owner.setSelectedItemIndex (list->getSelectedRow());
else if (key.getKeyCode() == KeyPress::escapeKey)
dismiss();
else if (key.getKeyCode() == KeyPress::upKey)
list->selectRow(jmax(0,list->getSelectedRow()-1),false,true);
else if (key.getKeyCode() == KeyPress::downKey)
list->selectRow(jmin(owner.getNumItems()-1,list->getSelectedRow()+1),false,true);
}there are probably some variables regarding which row is selected and how many rows there are, but the function calls worked, so i’m happy.
i’ve been trying to add some feedback to the combobox, but it’s a bit difficult cuz the real feedback should happen in the texteditor box… took me a while to realize it was a seperate component. i did a simple color toggle when the combobox item was focused, but it didn’t seem that tabbing thru those items would force a repaint, tho maybe i’m mistaken…
maybe it’s the way you’ve done things, but this is the first time i’m feeling like i actually “get” c++.
oh, one thing that seems missing in the demo app is a maximize button – or minimize, for that matter.
I’ve tested this patch, and it is working. This was very annoying not to be able to correctly use my 2 monitors under Linux, but this patch from bodisiw corrected it
http://www.adbe.org/juceforum/viewtopic.php?t=205
Maybe the linux OpenGL patch could be included too.
http://www.adbe.org/juceforum/viewtopic.php?t=200
As far as I remember, Jules, you said that you’re going to reorganize the OpenGL code so that platform specific code goes in platform specific files.
I would also like to have a DialogWindow::setBackgroundColor (so the dialog editor will not require ugly memory hacks). Maybe this could even be done in Component or refactored. I think the current LookAndFeel behavior is very “strange”, because many component are not using L&F.
For example, the TextEditor is using its own setColours, the ArrowButton is not exporting its color after construction (could this be done too ?).
I think you should add a getOutlineColour / getDefaultBackground on the L&F class and let the TextEditor/ComboBox/etc… rely on the value there so it is really easier to change the whole application look and feel (we will only have to overload the getOutlineColour / getDB methods), instead of having to tweak each component.
Even better, the getDefaultBackground could be a template method taking a Component * argument (as default template argument). So if you want to have a, let’s say “blue” background for your dialog window, you will specialize the template definition of getDefaultBackground for DialogWindow *, but the default template will return a “lavender” background (so TextEditor will still be visually different).
This will only require 2 lines of code (can it be done better ?) like this:
[In LookAndFeel]
template <T = Component *>
const Colour & getDefaultBackground(T) { return Colours::lavender; }
template <>
const Colour & getDefaultBackground(DialogWindow *) { return Colours::blue; }
[In the any component paint class]
g.fillAll(getLookAndFeel().getDefaultBackground(this));
A similar approach could be done for home made drawing by simply adding a “bool isOverridden(T, Graphics & g)” method to L&F that returns false for default template argument (Component *).
Then in each component paint method, you should call the L&F isOverridden(this, g) method, and depending on the results (false means drawing like it is done now, true means don’t draw, it is done in the override), so that each component’s drawing could easily be changed.
That’s the idea.
I hope it helps, feel free to mail me if you want me to give a try to this.
Yeah - nice ideas there. I’m going to check out the linux changes before I do the next release.
Don’t spend too much time worrying about the L+F stuff yet, as I am going to re-do it soon, and probably modernise the whole look, too. It’s an interesting problem to try to balance what goes in the L+F and what goes in the components themselves - background colour’s a good example of that, and I’m not sure what the best place for it is.
Cute idea about the templated colours, BTW.
[quote=“X-Ryl669”]Ok,
Can you tell me what are your plan for L&F changes ?
Faithfully,
Cyril[/quote]
no, I’ve not decided yet!
I’m not sure if this exists now or not, but it would be nice to set a global custom L&F and have all subsequently instantiated components automaticaly use it.
Sorry, but if you’re going to change the standard look, can I ask that you retain the current look (as an option, maybe)? I like the way it looks at the moment…
ahem…
(meaning all subsequentlly instatiated components automatically use it…)