Giters

andlabs / libui

Simple and portable (but not inflexible) GUI library in C that uses the native GUI technologies of each platform it supports.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

uiNewLabel

rjopek opened this issue · comments

commented

Hi,

NewLabel is different between Linux and Windows

for example:

	uiBoxAppend(vbox,
		uiControl(uiNewLabel("This is a label\n . Right now, labels can only span one line." )),
		0);

A new line will be made in Linux
but in Windows not

commented

Correct; at present the behavior of newlines in labels is undefined. I plan on fixing that.

commented

Okay,

Thank You.

commented

Hi,

uiNewEditableCombobox() is different between Linux and Windows.

Here is an example screenshots: EditableCombobox

I wonder whether to report such differences?

commented

Yes, but there are two possible explanations for what you're seeing, depending on the code, which I'll check later.

commented

The code is identical for both versions.

I know that it can go away, but when designing applications, not everyone can know about it.
Sorry to pick up on such details.

commented

That's not quite what I meant. What you're looking at has to do with an actual difference in both Windows and GTK+, but I need to actually look at how you're building your form to make sure this isn't a bug in libui that's exposing that difference in behavior.

Comboboxes in Windows always have a fixed height. Traditionally you would use the height of the control to determine how tall the popped open list would be. This was because originally comboboxes were literally a text edit filed with an attached list, and both were visible at the same time. When they added the drop-down versions, they kept this arrangement. As this particular UI went out of fashion, people stopped knowing that they had to make the combobox tall even if it was a drop-down. Eventually Microsoft gave up and said "fine, we'll automatically determine the correct height for you". See also: https://devblogs.microsoft.com/oldnewthing/20060310-17/?p=31973

GTK+ just sizes every control to fit the space available to it, without any of these historical quirks. It looks awkward, but it makes rendering logic easier. (It also makes the list part a separate X11 window/Wayland surface/Windows window/etc. that is actually placed over the window the combobox is in, rather than part of it with a high drawing Z-order.)

However, this explanation would only suffice if you were adding the combobox as the child control of your tab controls/frames or as the only stretchy control of a box/grid that is itself stretchy. There are some strange bugs in the GTK+ implementation of boxes/grids that I haven't yet figured out but that makes single-control setups behave oddly, which may also be what you're seeing here, if you aren't making the combobox stretchy.

commented

uiWindowTitle() there is a problem too
suspends the program when exiting

commented

Please file that as a separate issue, but with a reproducing example.

Gonna leave this issue open for the other two comments.