PDA

View Full Version : Control centering?



Varsuuk
April 6th, 2018, 22:46
I've centered a label in an earlier part of the UI.

In addition, I created a 2 column area within a graphic frame where the controls were two columns the left being position offset from a center "anchor" I created with generic control. The right column being position to the anchor but to right.

I now wanted to do a slightly different but also involving centering thing.
I have a label centered in a frame.
Offset below that, I want a row of 4 numeric display boxes, two slightly smaller in the center two slightly larger outside. I'd like to center this row inside the frame or using the label or? Whatever gets it centered with least cost to the application.

Do I need to create a center anchor control? Or is there some combo without explicit "offset=" to force the indents on either edge?

See picture for what I with to center:
22895

Moon Wizard
April 6th, 2018, 23:15
I'd probably do something simple.



<numbercontrol name="farleft">
<anchored to="hpframe" width="30" height="30">
<top offset="35" />
<right anchor="center" offset="-45" />
</anchored>
</numbercontrol>
<numbercontrol name="left">
<anchored to="hpframe" width="30" height="20">
<top offset="45" />
<right anchor="center" offset="-5" />
</anchored>
</numbercontrol>
<numbercontrol name="right">
<anchored to="hpframe" width="30" height="20">
<top offset="45" />
<left anchor="center" offset="5" />
</anchored>
</numbercontrol>
<numbercontrol name="farright">
<anchored to="hpframe" width="30" height="30">
<top offset="35" />
<left anchor="center" offset="45" />
</anchored>
</numbercontrol>


Cheers,
JPG

Varsuuk
April 6th, 2018, 23:50
No, get OUT! There’s a “center” option for anchor?

I mean that is pretty great, I just didn’t see it on the page when I looked:
https://www.fantasygrounds.com/wiki/index.php/Developer_Guide_-_Rulesets_-_Interface

(It May well be there, I cannot doublecheck now via search/find cos don’t know how to do that on a iOS phone browser... I did eyeball scan it twice now looking for the obvious missed info)

I was looking for just such a simple option. Thanks JPG, you are a PNG*

—Varsuuk


*”Pretty Nice Guy”

:)

Moon Wizard
April 7th, 2018, 00:24
Yeah, I can't find it either. Not meant to be hidden, just never made it into the documentation after all this time.

If top/bottom anchor being defined, then anchor="center" will be vertical midpoint of parent (or window if no parent defined).
If left/right anchor being defined, then anchor="center" will be horizontal midpoint of parent (or window if no parent defined).

Regards,
JPG

Varsuuk
April 7th, 2018, 03:09
I was starting to test with your example before building it into my controls.
I immediately noticed an issue I posted about before but it was minor compered to the other problems and I dropped it since I "fixed it" by simply always adding more to the left to right indents ;)

But if you look at this picture:
22897

It appears that the label I added is centered (via <centered/> tag in the label) and the number control looks NEARLY centered but shoved a bit to left. Which is what I used to see, like in this picture I posted in another thread:
Shown in this in-progress pick, I removed the indent from the left on the label and as you see it "stuck out" to left. I first thought it might be a mistake on the bitmap offsets like I was warned but I soon found these were not modified by me.
22898


It is basically created via:



>> From CoreRPG:

<template name="frame_char">
<genericcontrol>
<frame name="groupbox" />
</genericcontrol>
</template>


<framedef name="groupbox">
<bitmap file="graphics/frames/groupbox.png" />
<offset>18,18,17,17</offset>
</framedef>




>> From my ruleset-to-be:
<frame_char name="hitpointsframe">
<anchored to="attributeframe" position="belowleft" width="310">
<bottom parent="" anchor="bottom" offset="-10" />
</anchored>
</frame_char>




<label name="hitpoints_label">
<anchored to="hitpointsframe" position="insidetop"
offset="15,7" height="20" />
<center />
<static textres="char_label_heading_hitpoints" />
<disabled />
</label>


>> From your example (removed the horizontal offset)
<numbercontrol name="farleft">
<anchored to="hitpointsframe" width="30" height="30">
<top offset="35" />
<right anchor="center"/>
</anchored>
</numbercontrol>


I say "basically" because I have a frame.xml override for "groupbox" to use the "groupbox" from Castle & Crusades instead due to wanting to use that shade (sizes and definition of template are identical)



EDIT: I went DOH, when looking at my code later and seeing the offset on the label thinking I probably added it to correctly center but no, I am guessing its left over from prior try since if I removed it it stayed in the exact spot (horizontally obviously the vertical changed) where the T was over the 0.

Varsuuk
April 11th, 2018, 02:22
Anyone have an idea if the appearance that the LEFT edge is off to the left of the Frame is something my simple reuse of controls is getting wrong or some invisible left side of the frame due to some indent?


Also - I've come to see I have a ton of wordy (XML) listings of controls in one xml page for char_main.xml - which is fine - I get that is how it will look since so many things to list. But, does this XML syntax lend itself to any "breaking up" via some sort of "include" or anything else that would let me for example, define all the controls in the "Attributes frame", "Bonuses Frame", "Hit Points Frame", etc which are all in the Main tab?

I suspect they all have to be DIRECTLY in same xml between the sheetdata tokens but figured I'd ask. I know I can break up the lua into different .lua files to support them.

Also - if you read this far, any clue on my question of last couple posts... the left edge? I know it isn't critical because I simply indent MORE towards right to compensate ;)

damned
April 11th, 2018, 04:01
Many of the frames have some transparency outside the visible frame. Eg that square frame does not always represent the actual edge of the element - it is only the edge of the visible element.
In most frames this is only a handful of pixels. On the D&D red/white theme the space beside the dragon heads is the most visible example of this.

Varsuuk
April 11th, 2018, 04:28
Many of the frames have some transparency outside the visible frame. Eg that square frame does not always represent the actual edge of the element - it is only the edge of the visible element.
In most frames this is only a handful of pixels. On the D&D red/white theme the space beside the dragon heads is the most visible example of this.

OK, so I loaded (Castle & Crusades version of) graphics/goupbox.png into GIMP to look at it and it does appear that the edges are different than the body and I never see these edges. At first thought maybe because they were transparent and hence the solution but then I bit and looked up framed as I should have long ago:


Here is the definition in my protoruleset (I copied and renamed C&C's groupbox):

<framedef name="groupbox">
<bitmap file="graphics/frames/cnc_groupbox.png" />
<offset>18,18,17,17</offset>
</framedef>

From the API pages:
<framedef ...
<offset > ... </offset> A comma separated list of four numbers specifying the left, top, right and bottom offsets to define the nine components of the frame.
...

SO, if I understand, the drawn frame starts at the coordinate (relative to the png) of 18,18 and is 17 pixels wide and 17 mixes high which is just tiles to create the end result for dimensions I give?

If so (and I have no idea if I am getting that...) it doesn't seem to use those oddly different looking edges?

I hate being so dense, but not seeing it.

damned
April 11th, 2018, 04:52
In this case varsuuk the left and top edges are using the first 18px of the frame and the right and bottom edges are using the corresponding 17px of the frame.
It is used only for drawing the frame. Nothing else. the rest of the source image tiles to fill "middle".

Varsuuk
April 11th, 2018, 06:05
Yeah - am looking at this after writing, I can't see anyone making sense without spoken back and forth... I suck at writing. Leaving it in case miraculously it can be followed...



In this case varsuuk the left and top edges are using the first 18px of the frame and the right and bottom edges are using the corresponding 17px of the frame.
It is used only for drawing the frame. Nothing else. the rest of the source image tiles to fill "middle".

OK - I THINK I am getting there (as an aside, I now understand how desktop.png is defined in CoreRPG from doc reading)

See:
22942

So if my frame is 400 x 200pixels (and the source png is 547x547)

(Partial guesses:)
The first 18 pixels on left (from top to bottom up to 200 pixels since the source 547 is taller than target 200) are taken and used as the first 18 pixels top to bottom on my target frame.

Next the top 18 pixels (starting from 0,0 or 19,0?) of the source is copied from left to right up to 400 pixels since source is 547 and target 400) is used as the top "border" of the resulting target frame?

Then the right 17 pixels of the source form the rightmost 17 pixels of my frame from top to bottom (again because source is taller than target)

Penultimately the bottom 17 pixels of the source is used to create the bottom 17 pixels of my frame all across (as source is wider than target is wider, no tiling needed)

Finally the center is created by taking the innermost square and tiling it (if necessary, here that target square is 547 - 35= 512x512 so still target than the remaining 400-35=365 x 165 (200-35)


No clue if I explained this ANYWHERE near clearly enough but if I did, not sure of overlap. Does it lay each strip in order I listed subsequent portions overlapping (overriding) earlier edges (ie bottom strip fully overlaps left and right edges(cornerS) in end)

Or does it take left edge top to bottom, then top from where left edge left off to the right edge then right edge from where top left off down to bottom and bottom from the bottom excluding where left AND right left off. Yeah, I am SURE this reads like nonsense. I know what I am trying to "say" (right or wrong) but don't think I am describing it. Wish I had a video of my pointing to a sample picture lol.


==== Below specific to what triggered me asking about this stuff are my findings- not important - the above part is the "question."
From trial and error and sticking my eye to screen, it shows me that if I create an underline control anchored to left side, I need to offset it +6 pixels for the line to draw to the left (shaded thin border) edge of the graphic and if anchored to right, I need to offset it -4 pixels to keep it to the edge of the (shaded thin with shadow) right edge.

----
So if I like 10pixel spacing between controls of same dimensions and I want it to appear as if the leftmost control is 10 pixels from the (visible) edge of the frame I would set the offset to frame on leftmost to 16 not 10.

So when something is "centered" horizontally inside that frame, it is really a slight bit too much (2 pixels only) to the left. I can live with that ;)

Varsuuk
April 11th, 2018, 06:14
PS as a gift for going blind? reading my posts:

Anyone who might wonder about how to do multiline labels under a control:
I found I could do it by just adding the multiline tag (I did trial and error to see for my font/height what spacing looked 'right') and defining my string with a "\n" between the two words since I wanted to center the words and without that the space from second word is considered part of second line and throws off centering - will post 2 pics to show what mean:

22943

22944



strings xml file:
<string name="char_label_armorclass">Armor\nClass</string>
<string name="char_label_savingthrow">Saving\nThrow</string>

template file:
<template name="labelbelow">
<label>
<anchored to="" position="below" offset="0,-5" />
<font>font_charsheet_labelbelow</font>
<static text="**MISSING LABEL**" />
</label>
</template>


sheet data:
<labelbelow name="savingthrow_label">
<anchored to="savingthrow" offset="0,3" height="25" />
<multilinespacing>12</multilinespacing>
<center />
<static textres="char_label_savingthrow" />
</labelbelow>

damned
April 11th, 2018, 06:33
The first 18 pixels on left (from top to bottom up to 200 pixels since the source 547 is taller than target 200) are taken and used as the first 18 pixels top to bottom on my target frame.

Next the top 18 pixels (starting from 0,0 or 19,0?) of the source is copied from left to right up to 400 pixels since source is 547 and target 400) is used as the top "border" of the resulting target frame?

Then the right 17 pixels of the source form the rightmost 17 pixels of my frame from top to bottom (again because source is taller than target)

Penultimately the bottom 17 pixels of the source is used to create the bottom 17 pixels of my frame all across (as source is wider than target is wider, no tiling needed)

Finally the center is created by taking the innermost square and tiling it (if necessary, here that target square is 547 - 35= 512x512 so still target than the remaining 400-35=365 x 165 (200-35)

topleft = 0,0,18,18
top=18,0,512,18
topright=530,0,17,18

left=0,18,18,512
middle=18,18,477,512
right=530,18,17,512

bottomleft=0,530,18,17
bottom=18,530,512,17
bottomright=530,530,17,17


top, right, tile horizontally
left, right tile vertically
middle tiles vertically and horizontally

so you can that writing it out 18,18,17,17 is a huge time saver!

Varsuuk
April 11th, 2018, 06:51
OMG - THAT'S what I should have asked you...

"could you translate the L,R,T,B format to the 'extended' format" - wow, I GET IT NOW :)

You rock (and as I said, I wish I had better skills at expressing what I am trying to ask.)

It is all clear!
Glad you are presenting the extension class. I bet you will help lots of folks with your class. I can't teach worth a damn myself. I did well with junior devs in prior jobs but that was more code-review notes and showing them examples to look at. Putting together a hoot point A through Z... not so much.

Hey, at least I have a diagnosis to explain me ;)
Thank you again.


EDIT: Welp, it is 1:52AM my time, so heading to bed (I only find time to work on FG/rulesets at weird hours when my son and wife are asleep or lunchtime or commute... but plugging away - can't wait until can do Lua primarily vs control setups ;) )


topleft = 0,0,18,18
top=18,0,512,18
topright=530,0,17,18

left=0,18,18,512
middle=18,18,477,512
right=530,18,17,512

bottomleft=0,530,18,17
bottom=18,530,512,17
bottomright=530,530,17,17


top, right, tile horizontally
left, right tile vertically
middle tiles vertically and horizontally

so you can that writing it out 18,18,17,17 is a huge time saver!