hi jules,
can you create an XPLookAndFeel class…
I like look and feels but i don’t know how to do it…
can you do it for me…
tnx 
or MacLookAndFeel even…
Personally I can’t stand XP’s look and feel (not that it even has a unified look-and-feel in the way that the mac has) so I don’t fancy spending a week or more emulating it!
Wouldn’t mind doing something a bit more like the mac, though not sure if Apple’s lawyers would take an interest…
What would be really great is a high level look-and-feel tutorial. Maybe a list of guidelines for graphic designers to follow, separate from the code. I’m sure a coder could implement a new one by reading the doxygen documentation, but I think this particular issue may be a good one to build some supporting tools (not sure if Jucer already offers some things?) and a step-by-step in plain English.
Anyway, you know that old ‘catch a man to fish’ expression…
[quote=“bodisiw”]What would be really great is a high level look-and-feel tutorial. Maybe a list of guidelines for graphic designers to follow, separate from the code. I’m sure a coder could implement a new one by reading the doxygen documentation, but I think this particular issue may be a good one to build some supporting tools (not sure if Jucer already offers some things?) and a step-by-step in plain English.
Anyway, you know that old ‘catch a man to fish’ expression…[/quote]
Yes, I should really improve the docs for look-and-feel, though it’s really still evolving, and sometimes needs tweaking to do something in particular.
Personally I would love it if you could use the Jucer to design LookAndFeels. I started one of my own, but I find it takes forever to get everything lined up right when you’re basically trying to draw in code (iirc, I spent 2 days on it and only managed to implement 3 controls :oops:). Seems to me the Jucer’s vector editing capabilities would make it ideal for this kind of thing.
I’ve got a feeling it would probably be a lot of work though… 
- Niall.
I totally agree with NiallM that LookAndFeel editing features in Jucer would be just spiffy. I also agree with Jules that the WinXP default theme is horrid and should not be duplicated. A Mac LookAndFeel would be mighty dandy, but it’s hard to tell whether Apple would have an issue with it.
In case anybody’s interested, here’s the latest in my development of a Shiny Black LookAndFeel sub-class. There’s a screenshot and the source following the link. It really is only a titlebar and titlebar button so far, but it’s here in case anybody might want to use the code or perhaps learn how to customize LookAndFeel. Please forgive the name. I had no idea what to name it.
Is there any chance that a LookAndFeel editor will ever make it into the Jucer Jules? It would be a killer feature, but it sounds like a lot of work.
I’ll certainly have a think about ways it could be done. I don’t think it’d be technically difficult, but it’d involve a lot of typing!
You know, if someone would fully write a proper Python binding around all of Juce, you could use the binding from the C++ side to automatically infer all attributes and handling of all the classes so the Jucer interface could build itself based on the information from the bindings, would mean a whole lot less typing overall…
sounds like a lot of typing too 
That link didn’t work for me, this opens something visible/readable
http://pyjuce.tuxfamily.org/templeet/
Oops, I changed the site layout lately and I hadn’t tested it under IE. :oops:
It should work on firefox anyway … I’ll fix that soon.
Ah, cool. Using pyplusplus I see. I prefer to wrap using boost::python directly/manually personally as I prefer to ‘pythonize’ things as I go along. Just directly doing a straight binding never feels like python and ends up where you are writing C++ as python to do the same things.
But yea, either way, a lot of typing. Been binding CEGUI into Python recently for a scripting backend to handle its theme’ing. Already over 600 lines and only done about a third of it… Only took an hour to do those 600 lines though. boost::python makes things wonderfully fast compared to any other api I’ve found to date for any language.
Once everything is fully wrapped into python, you can do detailed class lookups inside it and see everything a class has and is capable of doing, perfect introspection in other words. Makes writing editors for such things vastly easier and more powerful.
EDIT: Can’t help anyways, the subversion link does not work or is down.
I just started a WindowsLookAndFeel. I think it can be done until next week.
Jules, I found the LookAndFeel system a bit scattered through the codebase. For example is the default text- and backgroundcolor for a TextButton not controlled by the LookAndFeel, the default values are in the TextButton it self.
I would suggest to change this and add the following Colours to the LookAndFeel class:
textButtonBackgroundOff = Colour (0xffbbbbff);
textButtonbackgroundOn = Colour (0xff4444ff);
textButtonTextColour = Colour (0xff000000);
and change the TextButton constructor like this:
TextButton::TextButton (const String& name,
const String& toolTip)
: Button (name),
backgroundOff (LookAndFeel::getDefaultLookAndFeel().textButtonBackgroundOff),
backgroundOn (LookAndFeel::getDefaultLookAndFeel().textButtonBackgroundOn),
textColour (LookAndFeel::getDefaultLookAndFeel().textButtonTextColour)
{
setTooltip (toolTip);
}
The TextButton would also need a lookAndFeelChanged() to update it colours to the new defaults if they weren’t changed by setTextColour(…) or setBackgroundColours(…).
This way the default TextButton colours are controlled by the LookAndFeel but can’t still be overridden with custom colours by setTextColour(…) or setBackgroundColours(…).
Also I would like to have something like bool LookAndFeel::getWindowHasTitleBarDefault() and bool LookAndFeel::getwindowHasDropShadowDefault(), so the defaults for this are also controlled by the LookAndFeel.
Edit:
The changes for the TextButton are also needed for the DrawableButton.
Yes, I admit that the look and feel code could use a bit of tidying up - it kind of evolved rather than being designed properly.
There’s a few classes where there’s an issue to do with colours like this, so I really need some kind of neat mechanism for specifying colours in the look and feel that can be overridden by the component itself.
Some more stuff I noticed while looking through the code an working on the WindowsLookAndFeel:
- The dropshadow of the combobox-popup should be look-and-feel controllable.
- The ‘gapAroundList’ of the combobox-popup should be look-and-feel controllable too.
- If I let LookAndFeel::getAlertBoxWindowFlags() return ComponentPeer::windowHasTitleBar the application will freeze if you try to open an AlertWindow. I didn’t investigate why this happens yet.
Those are all good ideas - thanks, I’ll put them on my to-do list!
While we,re on the subject of specifying colours in the look and feel, could you enhance the Jucer so that in fields where you can define a colour that you can actually pick a variable? preferably one that is defined in the look and feel object because that is where we,ll be defining some global application colours.