LookAndFeel requests

ah sorry I didn’t see getKeyPosition(), thanks

I’d appreciate some color ids for table header

Jules, a while back you extended the AlertWindow class so you can now change the button height and text font. The button height works fine, but still cannot set change the font. If I’m not mistaken, it works only for named texteditor and combo components. So:

  • please make font change fwork for message and title
  • or better yet, make the title and message string accessible (getTitle, getMessage) for flexible painting

While at the subject, would it be possible to add a setFont method to all the components with text? GroupComponent, TextEditor, etc. Perhaps even a font member and a Component::setFont just in case the comp wants to write something.

Thanks,
LB

There’s a LookAndFeel::getAlertWindowFont() method that you should be using for this. It’s really a design decision that things like fonts belong in the l+f, and shouldn’t be a property of the individual components.

I know, but it doesn’t work for me. Will doublecheck it though.

Yes, it’s two different concepts, but I thought a couple of extra public functions don’t hurt. Use them, or rely on the defaults.

I know, but it doesn’t work for me. Will doublecheck it though.

Yes, it’s two different concepts, but I thought a couple of extra public functions don’t hurt. Use them, or rely on the defaults.[/quote]

Well, let me rephrase that. The real reason is to be able to put components of the same class on a window and give them different emphasis or set some of them to monospaced etc. So this is a real life thing, not just l’art pour l’art. But I can certainly live without it, so I hereby surrender :slight_smile:

Well, you don’t have to live without it - just give each component a different l+f.

Since you are probably always creating subclasses of Component, why can’t you do this yourself? You could pass in the id value into your component during the constructor or with setter/getter methods.

Or, if you wanted to have all your components aware of each other, automatically setting unique ids for each of them, you could create a subclass of component with a static data member that increments each time the constructor is called – then you make subclasses of this subclass, each sharing the static id, setting their own internal id number to the current id in their own constructors.

[quote=“amcleran”]
Or, if you wanted to have all your components aware of each other, automatically setting unique ids for each of them, you could create a subclass of component with a static data member that increments each time the constructor is called – then you make subclasses of this subclass, each sharing the static id, setting their own internal id number to the current id in their own constructors.[/quote]

Better yet, you could make a simple class whose entire function is keep track of a class-wide static data member, then just inherit from it (since we can do multiple inheritance in C++) whenever you want a particular object (or component) to have a unique ID.

I’d like the DocumentWindow::getBorderSize () method to be a protected virtual method instead of a private one. That way, I may decide to have a border size of choiche for my subclasses of DocumentWindow.

I think you should probably be using getBorderThickness() instead. getBorderSize() is just an internal method, not meant to be overloaded.

I’d like to customize the look of my application’s windows, but I found it impossible by just subclassing the LookAndFeel: I’d like to paint a Drawable object as the background of the window, but I see that the paint() methods for both ResizableWindow and DocumentWindow do the actual painting of the background with a fillAll of a single color.

This way, even having a gradient as the background of the window would require reimplementing its paint method.

What about a paintResizableWindowBackground(…) method, taking the same parameters of the already existing drawResizableWindowBorder(…) method?

Its default implementation should be the current body of the ResizableWindow::paint() function.

That paint() funcion, in turn, should just be changed to actually calling paintResizableWindowBackground(…) on the window’s look and feel…

Seems like a very sensible request! I’ll add that…

I’ve noticed that TextButtons have a background colour ID for each toggle status (buttonColourId and buttonOnColourId), but only one textColourId… to me, it makes sense to have a textOnColourId as well…

I have white buttons that toggle to red when switched on, but their black text only contrasts well when they are white. When red, a white text would be better in my opinion, but it’s not available at the moment

Yes, that’s true…

[quote=“yfede”]I’ve noticed that TextButtons have a background colour ID for each toggle status (buttonColourId and buttonOnColourId), but only one textColourId… to me, it makes sense to have a textOnColourId as well…

I have white buttons that toggle to red when switched on, but their black text only contrasts well when they are white. When red, a white text would be better in my opinion, but it’s not available at the moment[/quote]

Aehm… any news about the implementation of this?

Sorry, haven’t had time. Next week, probably.

While you are at it, why not adding a getFontForLabel method to the LookAndFeel class, with the same meaning of getFontForTextButton but for Labels?

I’ve done it myself, but I think it could be useful to others… can’t you sneak this little change into the tip in a minute?

add this code to the ColourIds of TextButton:

        textOnColourId                  = 0x1000103

And change the code in LookAndFeel::drawButtonText for retreiving the text colour this way:

    g.setColour (button.findColour (button.getToggleState() ? TextButton::textOnColourId : TextButton::textColourId)
                       .withMultipliedAlpha (button.isEnabled() ? 1.0f : 0.5f));

Of course, a good default for this colour could be the standard black, so a new entry should be added in the constructor of LookAndFeel, where the array of defalult colours is created:

        TextButton::textOnColourId,                 0xff000000,

Hoping that this will find its way into the tip…

…yes… the only problem would be for people who’ve used a custom text colour in a toggle button - in that case, unless they knew about this change and updated their code, their button colours would break.