Topic: UI questions

Single line textareas

They can be either layouted or fixed. In layouted mode, the default width is always equal to the text width, and your custom width is ignored completely. If you specify a fixed_width, then the textarea is forced to that width, regardless of the text's size. In both cases, the Box may add extra width if applicable.

The w property doesn't really make sense for the regular single line textarea. It is there only for cornercases, since it affects the very first time a textarea is layouted (before it computes its required size). In a few very exotic situations setting this to a high or low value can make a difference.

Spinbox

How regular width and unit_w interact, and how to get the buttons part and the label part to show up as intended, is forever confusing to me in C++ as well

This widget is an absolute nightmare to layout properly. Play around with many combinations of w and unit_w until it looks sort of good. That's how every spinbox I ever added to the Widelands UI is layouted

Multiline textarea and richtext

If you use any richtext markup (the <rt> tag), then the font property is completely ignored. The richtext defines its own style. If you do not use a <font ...> tag then a default style is applied.

The ML text area's style only applies if you don't use any richtext markup at all.

If you use p() without rt(), then you do not get WLRichtext, p() only adds a <p> tag but no <rt> tag, so it is not valid richtext and the text is rendered verbatim.

Examples:

-- Valid richtext, renders "Hello World" with a default font
text = [[ <rt><p>Hello World</p></rt> ]]  

-- Valid richtext, renders "Hello World" with a custom font
text = [[ <rt><p><font face="serif" color=007fbf bold=1 italic=1>Hello World</font></p></rt> ]]  

-- Not richtext, renders "Hello World" in the mltextarea's font
text = [[ Hello World ]]  

-- Not richtext, renders verbatim "<p>Hello World</p>" in the textarea's font
text = [[ <p>Hello World</p> ]]  

However, by comparing your examples (which actually should work but here don't) with my own sample code (which does work), I noticed that in the current state of the branch the style was only applied if the text was afterwards set via widget.text = "..." but not applied to the initial text due to some intransparent implementation detail of MultilineEditbox. I pushed a commit with a fix for this bug, please check again.

Top

Quote

Ok, thank you very much!

Spinbox

Funnily i have no problems so far with this widget, except the label. But this can be circumvented by applying just no label and make an extra textarea widget which act as a label.

Multilinetextarea and richtext

The explanation of Nordfriese was exactly how i understood this. So my issue was just a bug, leading to confusion. Thanks for fixing!

Another thing i am fighting with:

Fighting with width's, aka positioning of widgets

Normally all widgets should be shown centered. But in a two columns layout this doesn't work if one widget's width is smaller than the wanted columns width. In the screenshot the row with the editbox (value 10,25) consist of a multilinetextarea (column1, width 200) and an editbox (column2, width 200) both wrapped in an horizontal box. All fine here. But for my taste the editbox is too wide.

The row below of this consists also of multilientextarea (column1, width 200) but the editbox has a width of 100. As a result the sum of both widgets width's is used for centering the whole row.

Now my idea was to put the multilientextarea and the editbox each in it's own box with orientation vertical and give the boxes the wanted width of 200 to make them shown centered. But the result is the same.

The only solution i found is to add some space widgets around the edit box, so that the overall width of column2 is 200 (space 50 + widget width 100 + space 50). Is there another way to have widgets centered in a two columns layout?

---

Attachment:

Top

Quote

Nordfriese wrote:

If I understand correctly, you want the right column entry to consist of a fixed-width editbox with empty padding of 50px each to the left and right, in which case two space widgets would indeed be the correct way to go.

Yes, that's the answer i want to hear.

P.S. The text in your example has some ugly linebreaks, consider using   for spaces where no line wrapping should take place.

Yes, the next thing i want to fix, thanks for the hint!

Top

Quote

kaputtnik wrote:

P.S. The text in your example has some ugly linebreaks, consider using   for spaces where no line wrapping should take place.

Don't know if this a bug or normal: This does only work if i wrap the text within richtext, eg. rt(p(" Text with no space")). Without richtext ` is shown instead of a space.

That's normal. As I said above, without an <rt> tag everything is rendered verbatim, and   is only interpreted as a non-breaking space when used within richtext.

Btw, the website is having a bit of trouble with   even when put in markdown code styling

Top

Quote

If you have single-threaded execution you might want to use wl.ui.show_messagebox which does not require callbacks at all:

function action()
    local fields = gather_fields()
    if #fields > 5000 and not wl.ui.show_messagebox(_("Warning"), _("Are you sure?"), true) then return end
    for i,f in ipairs(fields) do
        print("Processing field " .. f.x .. "," .. f.y)
    end
end

If you don't want to use show_messagebox (e.g. because you want a custom window), then you have two options. Either make fields global. But be sure to choose a good, unique name in this case, global variables are bad style. Or, more work but cleaner and safer, stringify it and pass it as a function parameter that you then decode (or just as a parameter pack):

local fields_as_str = ""
for i,f in ipairs(fields) do fields_as_str = fields_as_str .. ",{x=" .. f.x .. ",y=" .. f.y .. "}" end

on_clicked = "do_something(" .. fields_as_str:sub(2) .. ")"

function do_something(...)
    for i,c in ipairs({...}) do
        print("Processing coordinates " .. c.x .. "," .. c.y)
    end
end

Top

Quote