(SVN) Scrollbars always using default?

christianboutin.com

14-09-2009 12:59:06

I created a window type as follows :

Window usca_enhancedwindow
{
SkinReference hscrollbar
{
ClassName deliberaterandomnesssdfsdfsdHScrollBar
SkinType icanputwhateveriwanthereusca_vscrollbar
}

SkinReference vscrollbar
{
ClassName deliberaterandomnesssdfsdfsdVScrollBar
SkinType icanputwhateveriwanthereusca_vscrollbar
}

SkinReference titlebar
{
ClassName sdfsdfsdVScrollBar
SkinType icanputwhateveriwanthereusca_vscrollbar
}

SkinElement background
{
Border_Bottom 51
Border_Left 52
Border_Right 52
Border_Top 51
Texture uscagui.enhancedwindow.png
TileBackground true
TileBorders true
}

}


If you notice, ClassName and SkinTypes of the scrollbars and title bar are, well, random. That's intentional. It should crash, or raise an exception. If I change "SkinReference hscrollbar" to "SkanReference" or something like that, it raises an exception. But it seems the content of of the SkinReference is ignored, as no matter what I put in there I get the default scrollbars and title bar.

I did put a breakpoint in the serialize method of WidgetDesc and I never saw those elements go by. I will investigate further a little later today. Clues as to where to look are welcome. Thanks!

kungfoomasta

14-09-2009 18:49:35

I agree with you, we should have more error checking in here, to notify people when they're not using the correct Skin References.

At the top of every Widget's .cpp file, I have a static method that registers a SkinDefinition for the widget. For example, here is the HScrollBar's code:


const Ogre::String HScrollBar::BAR = "bar";
const Ogre::String HScrollBar::LEFT1 = "left1";
const Ogre::String HScrollBar::LEFT2 = "left2";
const Ogre::String HScrollBar::RIGHT1 = "right1";
const Ogre::String HScrollBar::RIGHT2 = "right2";
const Ogre::String HScrollBar::SLIDER = "slider";

void HScrollBar::registerSkinDefinition()
{
SkinDefinition* d = OGRE_NEW_T(SkinDefinition,Ogre::MEMCATEGORY_GENERAL)("HScrollBar");
d->defineSkinElement(BAR);
d->defineComponent(LEFT1);
d->defineComponent(LEFT2);
d->defineComponent(RIGHT1);
d->defineComponent(RIGHT2);
d->defineComponent(SLIDER);
d->definitionComplete();

SkinDefinitionManager::getSingleton().registerSkinDefinition("HScrollBar",d);
}


In the past I think the SkinReference was refered to as a Component. This should probably be updated to by more in sync with the script. Also, I should require not only the name of the SkinReference, but the Widget Class. Something like this:


...
d->defineSkinReference(LEFT1, "Button");
...


This will catch errors against ClassName deliberaterandomnesssdfsdfsdHScrollBar, but not SkinType icanputwhateveriwanthereusca_vscrollbar. While we could verify if there is a Button SkinType by the name of icanputwhateveriwanthereusca_vscrollbar, I think this check would enforce loading of skins in a particular order. (Meaning the Button SkinType would have to be registered before this HScrollBar, or an exception would be thrown) I'd not want to enforce this. I don't really know how you can do error checking against the SkinType name and not enforce defining Skins in a particular order.

I'm at work currently, but tonight I might get a chance to implement this.

kungfoomasta

15-09-2009 05:00:54

I've implemented this, its committed into SVN now.

This will not work:

SkinReference hscrollbar
{
ClassName deliberaterandomnesssdfsdfsdHScrollBar
SkinType icanputwhateveriwanthereusca_vscrollbar
}


This will work:

SkinReference hscrollbar
{
ClassName HScrollBar
SkinType icanputwhateveriwanthereusca_vscrollbar
}


At least if you try to apply the skin with this SkinReferece, there will most likely be an exception saying the HScrollBar SkinType with name icanputwhateveriwanthereusca_vscrollbar does not exist.

christianboutin.com

15-09-2009 15:55:32

Thanks, more error reporting is good. Got the new version. But I still have the same problem :I always get the default scrollbars (or an exception, now) no matter what I put in in skintype file.

I think I'm starting to figure out why. The declaration of my window, in the skinTypes file, looks like this :

Window usca_enhancedwindow
{
SkinReference hscrollbar
{
ClassName HScrollBar
SkinType usca.vscrollbar
}

SkinReference vscrollbar
{
ClassName VScrollBar
SkinType usca.vscrollbar
}

SkinReference titlebar
{
ClassName TitleBar
SkinType usca.vscrollbar
}

SkinElement background
{
Border_Bottom 52
Border_Left 51
Border_Right 52
Border_Top 51
Texture uscagui.enhancedwindow.png
TileBackground true
TileBorders true
}

}


( Using the same custom skin for horizontal, vertical and title bar temporarily, don't mind that :-) )

In code, what I do is this :

QuickGUI::WindowDesc* wd = QuickGUI::DescManager::getSingleton().getDefaultWindowDesc();
wd->widget_skinTypeName = "usca_enhancedwindow";


Watching the evolution of wd as I trace, setting widget_skinTypeName to "usca_enhancedwindow" only affects the skintype of the window but none of its component (understandable, it's just a variable affectation). So even though vscrollbar is set to usca.vscrollbar in the skintype file, I don't think it's taken into consideration once I get to "createWindow".

I think, perhaps, the desc manager should have a "getWindowDesc(string descName)" method, perhaps that could help. Or maybe there's a part of the puzzle I'm not seeing?

christianboutin.com

15-09-2009 16:35:16

More information :

Created two nearly identical entries in the skinTypes file, one for a panel, one for a window :

Window usca_blankwindow
{
SkinReference hscrollbar
{
ClassName HScrollBar
SkinType usca.hscrollbar
}

SkinReference vscrollbar
{
ClassName VScrollBar
SkinType usca.vscrollbar
}

SkinReference titlebar
{
ClassName TitleBar
SkinType default
}

SkinElement background
{
Border_Bottom 1
Border_Left 1
Border_Right 1
Border_Top 1
Texture uscagui.blank.png
}

}

Panel usca_blankpanel
{
SkinReference hscrollbar
{
ClassName HScrollBar
SkinType usca.hscrollbar
}

SkinReference vscrollbar
{
ClassName VScrollBar
SkinType usca.vscrollbar
}

SkinElement background
{
Border_Bottom 1
Border_Left 1
Border_Right 1
Border_Top 1
Texture uscagui.blank.png
}

}


This will give me my custom scrollbars :
QuickGUI::PanelDesc* missionPanelDesc = QuickGUI::DescManager::getSingleton().getDefaultPanelDesc();
missionPanelDesc->widget_skinTypeName = "usca_blankpanel";
QuickGUI::Panel* missionPanel = mGUIManager->getActiveSheet()->createPanel(missionPanelDesc);


This will not :

QuickGUI::WindowDesc* missionPanelDesc = QuickGUI::DescManager::getSingleton().getDefaultWindowDesc();
missionPanelDesc->widget_skinTypeName = "usca_blankwindow";
missionPanelDesc->window_titleBar = false; QuickGUI::Window* missionPanel = mGUIManager->getActiveSheet()->createWindow(missionPanelDesc);


So it seems the problem is with the WindowDesc only. Good news is : a panel is what I wanted all along, don't need windows functionalities. Hope that helps.

kungfoomasta

15-09-2009 18:58:35

At first I didn't believe it, but sure enough, I created a set of test skins and was able to repro. Luckily the fix was very simple. For one reason or another I overloaded the setSkin API for the Window class, and it forgot to update its component widgets (ScrollBars, TitleBar) skins. The overload was unecessary so I removed it altogether.

Regarding the use of Descs, especially the default provided ones, be sure to call "resetToDefault()", unless you want to use values that were previously set in the desc.

The design of QuickGUI uses Descs as a way to configure widgets prior to creation, and gives easy serialization. (The descs are mainly structs with string/numeric data, and a few functions) Each widget has its own internal Desc, and during initialization I make a deep copy of the provided Desc. The widget itself does not poll the desc for changes, so all property changes after creation of the Widget should happen via get/set APIs. Also giving access to the desc itself would be a security violation and cause unpredictable behavior. (get/set exposes what you can do, although all widgets will have things like position, ability to be dragged, etc.)

Sorry for such obvious errors! :oops: