[jmarshall]

I realise this is a little late in the piece, but we're prepping PR3451 for merge in the November window (i.e. it'll be merged around Nov 1).

This is quite a major change in control positioning, in that you now can use <left>, <right>, <centre>, <top> and <bottom> to align things, as well as percentages. As always, "r" does the "from right/bottom" as it was before. % does a percentage of the parent's size.

Everything should still work ™ with this, however, right aligned labels outside of itemlayout/focusedlayout will break, because I've taken the opportunity to also remove the hack that had the <posx> value for right aligned labels meaning the right of the label, rather than the left.

To alleviate some issues updating your skins, I've written an XSLT (xml style sheet transformation) to handle things for you. If you're on a *nix box (Mac, Ubuntu etc.), then you should have xsltproc available, so grab the shell script and XSLT here:

XSLT script to update your skin

The XSLT updates the appropriate <posx> with <right>. If you're on win32, I'm sure there's some XML editing thing that could handle this, but that's outside what I know.

In addition, you'll want to remove any <posx>, <posy>, <width> and <height> from the label in defaults.xml.

What this may not hit is includes for specifying <posx> that are outside the <control type="label"> tags. The xslt isn't smart enough for that...

Note that the xslt processing will also likely alter whitespace in your XMLs. Thus, I recommend using

Code:

git add -p

to check through and just add the fixes you want. (For confluence I added the whitespace changes in a separate commit).

Please let me know if there's any issues.

Builds are available here:

[url http://mirrors.xbmc.org/test-builds/win3....exe]Win32[/url]
[url http://mirrors.xbmc.org/test-builds/darw...os.deb]IOS[/url]
[url http://mirrors.xbmc.org/test-builds/osx/...64.dmg]OSX[/url]
[url http://mirrors.xbmc.org/test-builds/andr...pk]Android[/url]

Jonathan

[pecinko]

In addition, you'll want to remove any <posx>, <posy>, <width> and <height> from the label in defaults.xml.

May I ask why are <width> and <height> for labels in defaults.xml problematic?

[jmarshall]

Sure. Primarily due to if you constructed a control using <left> and <right> instead:

defaults.xml:

Code:

<control type="label">
  <width>100</width>
</control>

somewindow.xml

Code:

<control type="label">
  <left>50</left>
  <right>80</right>
</control>

When this is assembled we've got the inconsistent:

Code:

<control type="label">
  <left>50</left>
  <right>80</right>
  <width>100</width>
</control>

At least one of those fields is wrong

Jonathan

[jmarshall]

Note that after thinking about this for some time, I'm considering reinstating the interpretation of <posx> as to what it was in Frodo. <left> and <right> would do the Gotham-specific positioning.

That way you shouldn't have to alter your skin at all, unless ofcourse you want to use the new positioning. The advantage of doing it this way is that it's easier to maintain Frodo and Gotham versions of your skins, which I assume is wanted, at least in the short term.

Thoughts?

Cheers,
Jonathan

[pecinko]

Note that after thinking about this for some time, I'm considering reinstating the interpretation of <posx> as to what it was in Frodo. <left> and <right> would do the Gotham-specific positioning.

That way you shouldn't have to alter your skin at all, unless ofcourse you want to use the new positioning. The advantage of doing it this way is that it's easier to maintain Frodo and Gotham versions of your skins, which I assume is wanted, at least in the short term.

Thoughts?

+1000

My reasons

- All RPi users are on Gotham - this change would start support avalanche almost immediately
- To be completely honest - I have no use of this changes and thus little motivation to do skin changes
- Both skins would need fixing (in addition, context menu on Amber crashes XBMC for some reason, while it is working in Quartz)
- I have quite a few includes with positioning in Amber and depend on defaults.xml quite a bit

[ronie]

i for one would like to keep the right align fix.
positioning of right aligned labels have always been confusing and now would be a good time to fix that.

using one way in the old positioning method and another in the new positioning method will only add to the confusion imo.
things will even get more complicated if you start to mix 'old' and 'new' within a label control: <left> <top> <width> <height>
how will right alignment be interpreted is such cases?

personally i'm not worried about this breaking skins, as they are already broken due to the settings level changes
and the removal of some context menu items.
for me, it's just another change that has to be made to get a skin compatible with xbmc gotham.

i reckon it might take skinners some time to make the needed changes, largely depending on how their skin is coded.
with a little luck, they can just run the xslt script and be done within a few seconds.
for Transarency!, i decided to do it manually and it took me 30 mins. to fix up the 186 right aligned labels in my skin.

[pecinko]

I'm not sure what specifically you have in mind with "right alignment" problem but I find new system confusing, especially when mixed with old one.

I'm an old dog, I admit that, but I've just re-read PR for the 4th time and I'm still trying to think about all implications it could have.

Just an example, for me and probably newcomers, posx = position of the object on X axis but "left" is not so obvious. <posleft> Might be better? What about centered labels inside lists? They still have a different logic?

Have we consider a new tag in addon.xml - "usecanvas"=true for new only system? One could not mix posx and left in that case, though.

---

...and it is not really fair to compare context menu items removal (skin unrelated) and button addition in settings with this change.

[Martijn]

...and it is not really fair to compare context menu items removal (skin unrelated) and button addition in settings with this change.

maybe subtitles will also be moved to core so that's another big change.
i kinda agree with ronie that having them mixed feel wrong and adding a tag to addon.xml makes it over complicated.
i haven't tried the script but 30 minutes for a skin sounds like peanuts in the total development time.

[pecinko]

@jmarshall

Reason context menu crashed XBMC in Amber is because <posy> tag was missing for button ID=1000. Is that a bug or is it now mandatory to define both?
Note: I have posx=0 and posy=0 (as well as width and hight) defined in defaults.xml for most of the controls.

[jmarshall]

<left> means left edge. <right> means right edge. Same for top and bottom.

So the proposal is:

Frodo: <posx> means left edge EXCEPT in right-aligned labels outside of containers, where it means right. i.e.

<posx> The left edge of a control (with the exception of right aligned labels outside of containers, where it means the right edge.
<posy> The top edge of a control.
<width> The width.
<height> The height.

If you want to center a label 100 pixels wide at x=200, then you put <posx>150</posx>, <width>100</width>

Gotham: <posx> exactly the same as in Frodo. No changes required at all. If you don't like it, use <right> for right aligned labels and <left> for all left
<left> always left edge.
<right> always right edge.
<centerx> always the center in the x direction.
<top> always the top (equivalent to <posy>)
<bottom> always the bottom.
<centery> always the center in the y direction.
<posy> same as Frodo (equal to <top>)

If you want to center a label 100 pixels wide at x=200, then you can use <centerx>200</posx>, <width>100</width> if you want.

@pecinko: will try and repro the crash. We definitely don't want that

[Hitcher]

<left> always left edge.
<right> always right edge.
<centerx> always the center in the x direction.
<top> always the top (equivalent to <posy>)
<bottom> always the bottom.
<centery> always the center in the y direction.
<posy> same as Frodo (equal to <top>)

Although I'm no longer actively skinning this makes so much more sense.

I take it this doesn't affect textboxes but what about multiple wrap labels?

[pecinko]

Gotham: <posx> exactly the same as in Frodo. No changes required at all. If you don't like it, use <right> for right aligned labels and <left> for all left
<left> always left edge.
<right> always right edge.
<centerx> always the center in the x direction.
<top> always the top (equivalent to <posy>)
<bottom> always the bottom.
<centery> always the center in the y direction.
<posy> same as Frodo (equal to <top>)

If you want to center a label 100 pixels wide at x=200, then you can use <centerx>200</posx>, <width>100</width> if you want.

<centerx> = align? <centery> = aligny?

I guess what confuses me the most is that I'm not sure if we are defining control position OR setting up anchor coordinates.

What happens if you use <centerx>200</centerx>, <width>100</width>, <align>left</align>, <aligny>top</aligny> on the same label you mention above?

[jmarshall]

It would center the control (not the label!) at 200 with width 100. i.e. the label would start at 150 and go up to 100 if the label is that large.

[jmarshall]

@pecinko: Crash on amber is not due to no <posy> - rather it's due to a coding bug in XBMC (read of NULL ptr) which occurs when one of max or min is unspecified in an auto width/height control. Have fixed that.

Also re-implemented the old <posx> hacks and fixed a couple other issues.

Should be all good to go now (famous last words...)

J

[sialivi]

While positioning is being worked on I would like to post a reminder that there's a bug that messes up the positioning of rotated non-scrolling labels, http://forum.xbmc.org/showthread.php?tid=165334