Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

make skin controls positioning more flexible #1208

Closed
wants to merge 4 commits into from

5 participants

@pieh
Collaborator

This patches allow more flexible controls placement and sizing. Currently xbmc only allow using <posx>,<posy> to define top left corner of control (relative to its parent control) and <width>,<height> for its size.

This adds <right> and <bottom> tags (and <left>,<top> aliases to <posx>,<posy> for consistency with new tags). <right> and <bottom> tags specify how far right/bottom edge of the control should placed from right/bottom edge of parent. It allows to use combination of 2 from:

  • <left/posx>, <width>, <right> (for horizontal placement and sizing)
  • <top/posy>, <height>, <bottom> (for vertical placement and sizing) It also allow using percentage values instead of absolute values (concrete value will be calculated based on parent width or height).

Here are some examples what can be done with this (using just horizontal tags, I hope they are self-explanatory)

<control>
  <left>10%</left>
  <width>50%</width>
</control>

<control>
  <left>30</left>
  <right>30</right>
</control>

<control>
  <right>20</right>
  <width>50%</right>
</control>

Current usage of 'r' suffix for relative positioning is working (in fact with this it would be possible to use it in other tags than posx/posy), but I'd like to mark it as deprecated if this would be pulled.

pieh added some commits
@pieh pieh guicontrolfactory: factor out <posx/posy> parsing code dcc76ed
@pieh pieh guicontrolfactory: allow more flexible control placement and sizing -…
… allow skinner using combination of 2 from <posx/left>, <width> and <right>:

- using <posx/left> and <width> will remain unchanged (control is anchored to the left and have constant width)
- using <right> and <width> allow to anchor to the right edge - <right> value specify distance that right edge of control have to right edge of parent group/window
- using <posx/left> and <right> will allow to anchor both to left and right edge allowing automatic width calculation

similiar logic is present for vertical placement, <posy/top>, <height>, <bottom> are appropiate tags
3450f91
@pieh pieh guicontrolfactory: factor out position string parsing af91417
@pieh pieh guicontrolfactory: allow using percentage values for <posx/left>, <po…
…sy/top>, <width>, <height>, <right>, <bottom>

concrete value will be calculated based on parent group width or height
cbdf43f
@jmarshallnz
Owner

IMO to be fully useful you'd want to anchor the control in the middle rather than just left or right/top/bottom.

Combined with moving the scaling stuff to the group instead of the window this would give nice ways to handle different resolutions (consider a aspect ratio kept block of content centered on the screen regardless of 4:3 or 16:9).

@da-anda
Collaborator

Yes, some sort of "centered with fixed width" might come in handy as well. In CSS you usually do it with <width>300px</width><left>50%</left><margin-left>-150px</margin-left>, but I think there is no such thing then a negative offset/margin in our skinning engine. Thus some sort of "align middle" would also be of use like @jmarshallnz mentioned.

Thanks for your work on this pieh.

@jmarshallnz
Owner

The anchor is what fits in this commit. The sizing needs to be handled in other ways - essentially moving the scaling to the group rather than the window.

@JezzX
Collaborator

well the original statement here is flawed "Currently xbmc only allow using , to define top left corner of control (relative to its parent control)" that's simply not true and hasn't been for many years, you align can stuff from the opposite sides as well.

from the wiki http://wiki.xbmc.org/index.php?title=Default_Control_Tags
"
posx Specifies where the left edge of the control should be drawn, relative to it's parent's left edge. If an "r" is included (eg 180r) then the measurement is taken from the parent's right edge (in the left direction).
posy Specifies where the top edge of the control should be drawn, relative to it's parent's top edge. If an "r" is included (eg 180r) then the measurement is taken from the parent's bottom edge (in the up direction).
"

Now with that being said being able to auto center things would be a nice addition not too sure the % thing is but I would bet someone could make use of it

@JezzX
Collaborator

heh I didn't read the last line.
please don't depreciate the r I have used this is many many skins all over the place and it would literary take my weeks to find and remove all of the calls I have done confluence itself uses it 80 times in 24 files

@pieh
Collaborator

I'm not removing it ;) just try to discourage it's usage in favour of things I added here (in case it will be merged that is)

@JezzX
Collaborator

heh depreciating it means that it will work or 1 more version then after than we start removing it from the code base else what's the point of marking it as depreciated

@jmarshallnz
Owner

It seems to me that what we really want is an anchor point (inside the group) an offset from that anchor and a size.

I don't see why that anchor point couldn't be arbitrary, perhaps with a few niceties included so that the anchor could be automatically set to the 4 corners or the 4 centers on each edge of the center of the parent. The percentage stuff gets you this. The problem is we shouldn't at this point assume that that point is fixed within the group - if you define it as a percentage then it should remain computed as a percentage - if the group width changes, then the anchor point should also move. Currently we don't support this - but should we?

The use of an offset allows for the control to be aligned within the parent should its width or height alter. eg you could anchor a auto-width label in the center of a group and it would remain centered regardless of width. The only way to achieve that atm is by making the width large and centering the label within that - it works fine for labels, but what if we had auto-width buttons as well? Again, this needs to be either fixed or dynamic.

Storing the anchor and offset (and whether or not each are relative) in the child seems the most arbitrary way of handling positioning.

@pieh
Collaborator

To make it clear: (using just horizontal stuff as example) anchor could have one value of left, center or right. Offset would define how far child's anchor point is from parent's anchor point (children left/right edge or center is "moved" by offset of parent left/right edge or center)? Size seems pretty straight forward.

If I got it right then propably with it we couldn't anchor both to left and right with some margins on both sides which would be usefull to define container size working well in different aspect ratios (like here http://i46.tinypic.com/2ppar7d.jpg). So maybe add margins too?

As for dynamic calculating: storing anchor, offset and size (and maybe margins) in seperate members and calculating m_posX, m_posY, m_width, m_height in CGUIControl::Process should be enough?

@pieh
Collaborator

Also, for skinning I think that allowing to define positioning and sizing like I proposed in PR description should be allowed in .xml and we would translate it internally to anchors and offsets to make it easy to use, but still allow more sophisticated positioning using anchors and friends directly in .xml if needed?

@JezzX
Collaborator

Can I make a suggestion on layout so as to keep backwards compatibly and for what I see was making more sense

<posx offset="left">100</posyx> = start drawing 100pixels from the left side also the default if no offset 
<posx offset="right">100</posyx> = 100 pixels from the right edge of the screen or group
<posx offset="center">100</posyx> = 100 pixels from the center 

eg: a control that's 200 wide would be centered on the screen if you used 
<posx offset="center">-100</posyx>

maybe offset could be changed for "align"

@JezzX
Collaborator

forgot to add that my way you can use constants and variables in the offset="" to have those obituary anchors

@jmarshallnz
Owner

Yes - you basically have a point inside the rect of the parent (the anchor) and a point inside the rect of the child (the offset). You can define each point either relatively (in percent) or absolutely (in pixels) - center is just 50% relative.

The existing m_posX, m_posY of the child would then be computed so that the two points coincide. I don't know if it's advantageous to have these stored or not, but certainly initially that would make sense. The child will need to know the parent's size for this in the case of the anchor being relative - currently they don't know this.

As for margins, I'm not sure what's best - effectively what you're doing with margins is determining width of child based on fixed separate anchors of left and right, or alternatively restricting the width to parent_width-margins (or alternatively restricting the parent_width to width+margins!) It depends which bit is controlling the dynamic sizing. I think it tends to be the parent that is in control, as that's the only logical way to handle things (else all the grandparents need to be dynamic as well).

@jmarshallnz
Owner

@Jezz_X: What that doesn't allow is center this child inside this parent in the case where the child is dynamically sized, as your posx offset is absolute, not relative. The bar inside the <posx offset="foo">bar</posx> would need to be relative if we want that as well. I don't have a problem with the basic idea otherwise (the offset is specifying the anchor and you could use offset="25%" for a relative point).

@jmarshallnz
Owner

Also, it's not clear which direction the posx takes. In your example, a posx of 100 from the right was a positive value, whereas it should be a negative?

@JezzX
Collaborator

can I assume by "parent" you actually mean groups and grouplists ? because isn't that as simple as taking the width/height of the group instead of the main window.
But I guess I'm not thinking of dynamically sized as well as location I think size is basically already handled by the built in window resize stuff anyway but I was always thinking being able to do maths inside xmls and fetch anything with an id's values would of been good
eg: <posx>$CALC[control(id).posx + control(id).width]</posx>
or <width>$CALC[control(2).posx - (control(1).posx + control(1).width)]</width> witch would give you gap between control 1 and 2 and you could make that your width

@da-anda
Collaborator

may I propose to have a look at how HTML/CSS is working? There, by default each blockelement/container not having anything defined is rendered relative to it's parent and uses same width (minus a padding that might be defined on the container). All sizes defined (like width:60%) are calculated based on the parent container.
The only exception are elements with the property "position:absolute" defined, which means that they are not bound to the parent containers dimensions, but to the nearest container in the node hirarchy that is defined to act as positioning reference (this is again defined by the position attribute and a value of either "relative" or "absolute"). By default this falls back to the browser window itself.
Maybe we could also have two different positioning modes - a relative one (based on the parents dimension) and a absolute (base on window or closest "positioning reference").

@JezzX
Collaborator

I really think the whole HTML/CSS idea is barking up the wrong tree we are talking about completely different concepts here XBMC is not meant to be dynamically resizeable and nor should it be, it designed to be run full screen at a set aspect 100% of the time

Web sites on the other hand are meant to be dynamic and are most just text and the irony of it all is that most websites (ours included) limit your ability to resize it and have a fixed width because they end up looking crap unless they are basically text and minimal graphic assets something xbmc is the opposite off

In a perfect world the GUI would be completely stripped out from everything elase so we could actually use native UI elements on platforms that have them like iOS and Android while still being full xbmc underneath

But I get off topic :)

@da-anda
Collaborator

Ofc XBMC is not beeing scaled all the time - but I think that the flexibility from HTML/CSS would help in creating skins that can better adapt to different screen resolutions without having to provide XML files for every apsect ratio or getting stretched/squeezed controls and images.

@pieh
Collaborator

@Jezz_X: by parent I mean "spot" that control is directly placed in - it could actually mean group, grouplist or window (f.e. for label in "list" container, parent would mean item/focusedlayout, for button in grouplist it would mean grouplist, and for fanart image control it would mean window (if it's placed directly in <controls> section of window))

Using <posx>$CALC[control(id).posx + control(id).width]</posx> is different approach than what we tried to discuss so far. I guess we went too far with "how to do this" before actually discussing "what to do". Now, I have no strong preference with what direction we should take (and even if I did, it's not me who will be using it). I just hope we will forge solution that isn't too much complicated and yet allow flexibility we definitely currently missing.


Here's my view on it (not something I want to force here, just what's currently on my mind - possibly it will change as brainstorming will continue :) )

I think that $CALC approach would allow most flexibility (from all propositions so far) and it actually fit the way we tend to process dynamic stuff in skins (in line with $INFO, $VAR, etc). It will allow "simulating" anchors, it will allow anchoring to both left and right, it will allow setting background image auto-sizing for grouplists (f.e. in contextmenudialog we have it hardcoded currently - but it could be nice if skinner could do it himself there and elsewhere: like here (options popup) http://desmond.imageshack.us/Himg35/scaled.php?server=35&filename=screenshot018w.png&res=landing)

Given that $CALC would allow most flexibility, but its syntax for most common stuff might be cumbersome I think it wouldn't be hard to allow easier/faster syntax with anchors, offsets or stuff I proposed in pr description that would be internally translated to $CALC.

@jmarshallnz
Owner

IMO the syntax parser for $CALC (which shouldn't be $CALC at all - rather just a direct arithmetic expression) unnecessarily complicates things at this point. Yes, you could under the hood do that sort of thing - after all, you at the very least need to replace the existing floats with float + bool anyway (for relative positioning), so replacing them with a class that then evaluates isn't all that much of a step away from that. You'd first need some routines to grab the values out of controls - this isn't particularly efficient in the case where we really only want the parents dimensions (as they're only a pointer away in the actual control, but in the variable they're a map lookup away) - but is what is needed should more general stuff be wanted.

One thing to keep in mind with calculation ability is it could lead to odd results, where the result of a computation is fed into the result of another one which is then fed back either directly or indirectly - ofcourse, this might actually lead to some nifty (if non-intuitive) ways of doing animation...

Further, should variables be used for this sort of thing, then one could have an animation on the transistion which could lead to some nifty effects (eg addition of a control to a grouplist slides the others along while fading the new one in).

@pieh
Collaborator

@jmarshallnz: if You don't mind at this stage I'd like to avoid discussing possible inner workings to keep Jezz_X, da-anda and whoever else might join in here - maybe we should move this discussion to forum until we agree on what we actually want to be able to do and how to do it (from skinner perspective that is).

Animations (controls sliding, fluid control resizing and possibly more) is also stuff I was thinking about, but didn't want to go too far, because ideas here change so quickly :)

As for control lookup vs just parent pointer, possibly odd behavomg stuff caused by circural dependency, etc. - I have some ideas for that, but don't want to drag it here - will wait for the moment when everyone is happy with direction we are taking (or at least if no-one oppose it, heh)

@phil65
Collaborator

@JezzX i could extend my skinning tool to convert those position tags < posx/y > to < right > / < bottom > if they include the "r".

@jmarshallnz
Owner

Sure. In that case I generally approve of the idea of:

  1. Allowing relative values in posx/width.
  2. Allowing some alignment information in posx.
  3. Allowing (if needed) some calculation ability.

Number 1 and 2 would allow simpler placement of controls, so that's a good thing. Number 3 would give additional control. My guess is that number 1 and 2 are primarily for layout of chunks of controls, rather than layout for single controls - e.g. you could imagine 3 groups vertically (header/content/footer) for the case of 16x9 vs 16x10 where the header and footer are anchored to top and bottom and may or may not scale (If they scale it's already doable), and the content anchored in the middle vertically and not scaled. Similarly, you could imagine some horizontal layout potential, where a content group is expanded due to more room on 16x9 vs 4x3. This would require a different control (different width), or an auto-width/variable width panel.

The way Jezz_X specified <posx> has some merit, though I'm not sure exactly how to specify the offsetting. The way he had it, the offset attribute defined the anchor, with the <posx> value being the offset from that anchor. I suspect that treating the value in <posx> as the anchor might be more descriptive.

<posx align="-100">200</posx>   <!-- position 100 from the left of parent -->
<posx align="30">20%</posx>   <!-- position 30 pixels to the right of 20% of the parent -->
<posx align="50%">50%</posx>   <!-- center the control at 50% of the parent -->
<posx align="100%">300</posx>   <!-- place the control so the right edge is at 300 from the left of the parent -->
<posx align="right">right</posx>    <!-- align control to the right edge of the parent -->

In fact, it may well be that all we require for the align parameter is left/center/right. I doubt you'll really want to align the 20% point of the child with the 60% point in the parent for example. The only one that would be useful I think is right aligning a control 100 pixels from the right edge of the parent (like we do currently with <posx>(100+width)r</posx>)

Margins might be a property of the parent I think if we want that later on - they make sense only on a group.

@pieh
Collaborator

I think that posx examples are way too confusing (it really took me moment to understand them). And for me they miss somekind of offsetting to allow <posx>(100+width)r</posx>. Imo this <posx align="right" offset="-100">right</posx> is starting to look ridiculous. I would actually made it more like this <posx anchor="right" [parentanchor="same_value_as_anchor_by_default"]>-100</posx> (I'd think that most of the times anchor on control and anchor on parent would be actually the same so we could just allow skipping one of it in that case)

But this doesn't solve (or I don't see how) problem with auto-sizing that content panel in Your 4x3 vs 16x9 example. To do this we need either to anchor both left and right edges to parent's left and right edges (omitting width which would be automaticly calculated) or we need to allow calculations (which I'd prefer because this would also allow "anchoring" to other controls than parents) (sorry that I keep going back to same example in almost all of my comments - I started this PR almost exclusively to allow that and I don't want to end up with not making it possible)

Margins were meant as way to allow saying "width=100% but cut 20px from left and 50px from right" - no other use for them I guess I think, any of above will do better than margins imo.

@jmarshallnz
Owner

I don't think it matters either way whether the left or right edges are specified or whether the position + width/height are specified, or both, as they're all calculable. I do think that left+right (or right+width) specified in some cases is easier to understand from reading the XML (after all, this is what the 180r stuff is for) than left+width, so wouldn't have a problem supporting that.

Agreed regarding the anchors in parent + child likely being the same in most cases, but I can see some useful cases where they might not be, such as aligning two labels either side of the center of the parent, and aligning in any way from an absolute position in the parent.

Perhaps what we actually need here is a general position tag with both alignment, position (within parent) and size? I think you'd only need "left", "right", "center" and "width" where percentages or absolutes can be specified for each, and you need only 2 of them defined. All measures given are respect to the parent - you could use the r to denote measured from the right:

<posx left="5" width="100" />
<posx center="40" width="50" />
<posx left="10" right="95"/>
<posx right="95r" width="500"/>
@pieh
Collaborator

This seems like what's already in commits but in slightly different form + "center" attribute added (and should be dynamic not static like i've done it). It works for me.

This could be not in scope of our discussion, but how would You see (if at all that is) auto-sizing of background image for grouplists/labels? (this is last place where I see that calculations might be useful)

@jmarshallnz
Owner

Yeah, exactly. I think starting with static seems the easiest way to go (i.e. extending this with a center attribute). The nice thing about the attributes is it indicates that they're all equal and are all used when figuring out where to place things, but you could do it with tags instead as you've done. Not sure what skinners would prefer. @Jezz_X ?

As for background images, for labels it seems the obvious thing to do is use a (disabled if necessary) button for it and hookup autowidth for that. For auto-width grouplists with a background image, a variable setup would be the way to go, though this is a prime case where processing order is important and may give odd results - we process in render order, so the image is processed before the grouplist, so the image will be the wrong size for 1 frame. I dunno if this would be noticeable though (and I suspect skins might already do the same thing via conditional images/animations anyway?)

@pieh pieh closed this
@jmarshallnz jmarshallnz referenced this pull request
Merged

Control positioning #3451

@tru tru referenced this pull request from a commit in plexinc/plex-home-theater-public
@tru tru Fix so that unwatched filter is respected att all places.
Fixes #1208
a4e5acf
@tru tru referenced this pull request from a commit in RasPlex/plex-home-theatre
@tru tru Fix so that unwatched filter is respected att all places.
Fixes #1208
d38eaf2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Jul 23, 2012
  1. @pieh
  2. @pieh

    guicontrolfactory: allow more flexible control placement and sizing -…

    pieh authored
    … allow skinner using combination of 2 from <posx/left>, <width> and <right>:
    
    - using <posx/left> and <width> will remain unchanged (control is anchored to the left and have constant width)
    - using <right> and <width> allow to anchor to the right edge - <right> value specify distance that right edge of control have to right edge of parent group/window
    - using <posx/left> and <right> will allow to anchor both to left and right edge allowing automatic width calculation
    
    similiar logic is present for vertical placement, <posy/top>, <height>, <bottom> are appropiate tags
  3. @pieh
  4. @pieh

    guicontrolfactory: allow using percentage values for <posx/left>, <po…

    pieh authored
    …sy/top>, <width>, <height>, <right>, <bottom>
    
    concrete value will be calculated based on parent group width or height
This page is out of date. Refresh to see the latest.
Showing with 81 additions and 18 deletions.
  1. +78 −17 xbmc/guilib/GUIControlFactory.cpp
  2. +3 −1 xbmc/guilib/GUIControlFactory.h
View
95 xbmc/guilib/GUIControlFactory.cpp
@@ -174,18 +174,41 @@ bool CGUIControlFactory::GetFloatRange(const TiXmlNode* pRootNode, const char* s
return true;
}
-bool CGUIControlFactory::GetDimension(const TiXmlNode *pRootNode, const char* strTag, float &value, float &min)
+float CGUIControlFactory::ParsePosition(const char* pos, float parentSize)
+{
+ char* end;
+ float value = (float)strtod(pos, &end);
+ if (end)
+ {
+ if (*end == 'r')
+ value = parentSize - value;
+ else if (*end == '%')
+ value = value * parentSize / 100.0f;
+ }
+ return value;
+}
+
+bool CGUIControlFactory::GetPosition(const TiXmlElement *pControlNode, const char* strTag, float& value, float parentSize)
+{
+ const TiXmlElement* pNode = pControlNode->FirstChildElement(strTag);
+ if (!pNode || !pNode->FirstChild()) return false;
+
+ value = ParsePosition(pNode->FirstChild()->Value(), parentSize);
+ return true;
+}
+
+bool CGUIControlFactory::GetDimension(const TiXmlNode *pRootNode, const char* strTag, float &value, float &min, float parentSize)
{
const TiXmlElement* pNode = pRootNode->FirstChildElement(strTag);
if (!pNode || !pNode->FirstChild()) return false;
if (0 == strnicmp("auto", pNode->FirstChild()->Value(), 4))
{ // auto-width - at least min must be set
- pNode->QueryFloatAttribute("max", &value);
- pNode->QueryFloatAttribute("min", &min);
+ value = ParsePosition(pNode->Attribute("max"), parentSize);
+ min = ParsePosition(pNode->Attribute("min"), parentSize);
if (!min) min = 1;
return true;
}
- value = (float)atof(pNode->FirstChild()->Value());
+ value = ParsePosition(pNode->FirstChild()->Value(), parentSize);
return true;
}
@@ -691,19 +714,57 @@ CGUIControl* CGUIControlFactory::Create(int parentID, const CRect &rect, TiXmlEl
// TODO: Perhaps we should check here whether id is valid for focusable controls
// such as buttons etc. For labels/fadelabels/images it does not matter
- XMLUtils::GetFloat(pControlNode, "posx", posX);
- XMLUtils::GetFloat(pControlNode, "posy", posY);
- // Convert these from relative coords
- CStdString pos;
- XMLUtils::GetString(pControlNode, "posx", pos);
- if (pos.Right(1) == "r")
- posX = rect.Width() - posX;
- XMLUtils::GetString(pControlNode, "posy", pos);
- if (pos.Right(1) == "r")
- posY = rect.Height() - posY;
-
- GetDimension(pControlNode, "width", width, minWidth);
- GetDimension(pControlNode, "height", height, minHeight);
+ {
+ // determine position and size of control
+ // horizontal
+ bool hasLeft = false;
+ bool hasWidth = false;
+
+ if (GetPosition(pControlNode, "left", posX, rect.Width()) ||
+ GetPosition(pControlNode, "posx", posX, rect.Width()))
+ hasLeft = true;
+
+ if (GetDimension(pControlNode, "width", width, minWidth, rect.Width()))
+ hasWidth = true;
+
+ if (hasLeft != hasWidth) // poor man xor, we have to have at least 1 to continue
+ {
+ // if we have just one of <posx>, <width> we search for <right>
+ float right;
+ if (GetPosition(pControlNode, "right", right, rect.Width()))
+ {
+ if (hasLeft)
+ width = (rect.Width() - right) - posX;
+ else // if (hasWidth)
+ posX = (rect.Width() - right) - width;
+ }
+ }
+
+ // vertical
+ bool hasTop = false;
+ bool hasHeight = false;
+
+ if (GetPosition(pControlNode, "top", posY, rect.Height()) ||
+ GetPosition(pControlNode, "posy", posY, rect.Height()))
+ hasTop = true;
+
+ if (GetDimension(pControlNode, "height", height, minHeight, rect.Height()))
+ hasHeight = true;
+
+ if (hasTop != hasHeight) // poor man xor, we have to have at least 1 to continue
+ {
+ // if we have just one of <posy>, <height> we search for <bottom>
+ float bottom;
+ if (GetPosition(pControlNode, "bottom", bottom, rect.Height()))
+ {
+ if (hasTop)
+ height = (rect.Height() - bottom) - posY;
+ else // if (hasHeight)
+ posY = (rect.Height() - bottom) - height;
+ }
+ }
+ }
+
XMLUtils::GetFloat(pControlNode, "offsetx", offset.x);
XMLUtils::GetFloat(pControlNode, "offsety", offset.y);
View
4 xbmc/guilib/GUIControlFactory.h
@@ -72,7 +72,7 @@ class CGUIControlFactory
\param min minimum value - set != 0 if auto is used.
\return true if we found and read the tag.
*/
- static bool GetDimension(const TiXmlNode* pRootNode, const char* strTag, float &value, float &min);
+ static bool GetDimension(const TiXmlNode* pRootNode, const char* strTag, float &value, float &min, float parentSize);
static bool GetAspectRatio(const TiXmlNode* pRootNode, const char* strTag, CAspectRatio &aspectRatio);
static bool GetInfoTexture(const TiXmlNode* pRootNode, const char* strTag, CTextureInfo &image, CGUIInfoLabel &info, int parentID);
static bool GetTexture(const TiXmlNode* pRootNode, const char* strTag, CTextureInfo &image);
@@ -102,6 +102,8 @@ class CGUIControlFactory
static bool GetHitRect(const TiXmlNode* pRootNode, CRect &rect);
static bool GetScroller(const TiXmlNode *pControlNode, const CStdString &scrollerTag, CScroller& scroller);
private:
+ static float ParsePosition(const char* pos, float parentSize);
+ static bool GetPosition(const TiXmlElement *pControlNode, const char* strTag, float& value, float parentSize);
static CStdString GetType(const TiXmlElement *pControlNode);
static bool GetConditionalVisibility(const TiXmlNode* control, CStdString &condition, CStdString &allowHiddenFocus);
bool GetString(const TiXmlNode* pRootNode, const char* strTag, CStdString& strString);
Something went wrong with that request. Please try again.