News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

gui_margin_t

Started by Ranran(retired), September 09, 2020, 10:46:50 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ranran(retired)

This is an intermediate concept between gui_empty_t and gui_fill_t. Put a fixed size empty cell.
I think this is necessary for fine tuning the layout.
I made it for extended but I think it can be applied to the standard as well.
Thank zou for your daily efforts. (´・ω・`)
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

prissi

Standard deliberately did no add this, since then the elements would not scale with different font sizes, string length, margin definition in gui_themses, or button sizes. etc. So I fail to see the purpose of this one. Because either you do full scalable or you don't. Moreover, any element has alsready a standard margin around, unless it is set to not have one.For which purpose you need this? Usually I can go fine with spanning elements more than one row or so if needed for hard tasks.

Ranran(retired)

I'm currently working on incorporating a standard auto alignment GUI system into extended.
This is very convenient because it simplifies the code and automatically supports scaling. I pay tribute to the great effort put into this implementation.

On the other hand, I think it is difficult to make fine adjustments.
The layout of some dialogs has changed significantly from existing dialogs, making it difficult to make fine adjustments, resulting in a lot of dead space and reduced readability.
While many components are automatically sized, there seem to be many that we cannot specify.
I wanted to inherit the good parts as they were (I didn't want to make bad points with this incorporating), so I'm trying to do a fine tune.



Quotesince then the elements would not scale with different font sizes, string length, margin definition in gui_themses, or button sizes. etc.
At least this can be scaled to the font or theme. Set the value that depends on them, not the magic number. D_V_SPACE and D_H_SPACE are set at the initialization stage.
For example, if you change this to LINESPACE, it will be scaled to fit the font size.


Quoteany element has alsready a standard margin around
Apparently this margin is fixed and cannot be changed. And the margin is very small. Especially for large fonts.


QuoteFor which purpose you need this? Usually I can go fine with spanning elements more than one row or so if needed for hard tasks.
It's like an HTML tag with options disabled. (´・ω・`)

I wanted to keep these margins in the old style.



In standard, it looks like this. The same was true for extended, which was just a merge of it.

By default the dialog is wide open with strange margins. Even if it was left justified, the margin width could not be changed. Therefore, it is fixed to a very small margin. I also tried setting the checkbox pos, but this also seems to be ignored.

I used gui_margin_t like this to set a margin for one checkbox on the left side.
The size of the checkbox is theme dependent and I think it makes sense for this GUI.
Alternatively, you could set a size that depends on the font size.
Horizontal adjustment may be possible by placing a space character in the cell. But if you do it vertically, it's equivalent to one line of LINESPACE.


I wanted to keep the old style margin in this example as well. As pointed out above, gui_empty_t only has a small fixed width and cannot be sized. You can put multiple of them side by side, but they are not scalable.
For example, D_V_SPACE and LINESPACE / n are values that change depending on the font size or theme setting.


About Convoy list,



I think such a margin is needed for readability.




In this example I wanted to place a minimum guaranteed margin on this part.




The issue with Simutrans's GUI layout is
(1) Font size cannot be used properly
     In other words, 10pt and 16pt fonts cannot be drawn at the same time.
(2) Bold and ordinary characters cannot be drawn at the same time.

We must strive to improve readability under this constraint.
One of them is to place the right margins. But with the new GUI it seems a bit annoying.
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

prissi

#3
I think of the new GUI like TeX versus word. You want to achieve a certain layout, but the new GUI just let you define the elements.

So the layout will work with different translations (having longer text like German) and themes. (For instance, you seem to use a very narrow button width setting, which will truncate most of the text in some languages.) I know it takes some time to get used to it, but fixed buttons width was a design idea, even if they seem too big for some dialogues.

Sorry, I did no see you oictures. Ok, one could use an label, but I see the purpose of the margin element to avoid the filling. Thank you.

Ranran(retired)

I would like to place small buttons for fewer characters rather than fixing the width, but in the case of roundbox it seems that they are all the same (minimum) size.
In the example of the three buttons in the filter frame dialog, I think it's too large. The result is a large dead space in the goods list below.

I made its size changeable, but I couldn't make it small and flexible...
ひめしという日本人が開発者達の助言を無視して自分好みの機能をextendedに"強引に"実装し、
コードをぐちゃぐちゃにしてメンテナンスを困難にし(とりわけ道路と建物関連)、
挙句にバグを大量に埋め込み、それを知らんぷりして放置し(隠居するなどと言って)別のところに逃げ隠れて自分のフォーク(OTRP)は開発を続けている
その事実と彼の無責任さに日本人プレイヤーは目を向けるべき。らんらんはそれでやる気をなくした(´・ω・`)
他人の振り見て我が振り直せ。ひめしのようにならないために、らんらんが生み出したバグや問題は自分で修正しなくちゃね(´・ω・`)

prissi

Several other buttons require a standard size or a tabular layout will look strange.

For the filter dialogue, using tabs is probably the better otption (together with two rows for goods)