Climate filter in factory/citybuilding/curiosity/tree placing dialog

[Leartin]

Climate filter - Defaults to "All Climates"; when a climate is chosen, the list of factories/citybuildings/curiosities/trees is restricted to objects that can be placed in that climate. Water climate is only available for factories, since the other objects can't be placed there.

Includes named building rotations from the other thread ( https://forum.simutrans.com/index.php/topic,20656 ), but the translation string contains the number.

[Leartin]

I went on and added some more things.



No patch for this yet, but I wanted to show the screen and ask what you think? The idea is to have everything that affects the list above the list. In return, the Image preview moved to the right. If the image becomes so big the window has to resize, it only resizes the right half rather than both.

Bit more details:
"Available at custom date" allows the user to set a date and see everything that's available at that date, similar to 'use timeline'. Those two turn each other off, 'show obsolete' works with it.
For Sorting, I added "by object name" and "by translated name", which essentially replaces the sorting of the tabs. Additional sorting criteria are size (which also sorts by shape for buildings with the same area), pax_level and mail_level (I set pax-level as default sorting for citybuildings), introduction date and retirement date. All sortings use the object name if the chosen criteria is shared.
The tabs now no longer affect sorting, since there is an individual function for that. I consider replacing it by a button "show unique object names"
The individual dialogs can add additional buttons on either side, like the res/com/ind buttons you see here (btw - I'll fix the bug that ind is not ticked by default)

I know it's different and I wouldn't swap anything around if it didn't make any sense, but I think large paks need this anyway.

[Dwachs]

Looks good! This also rearranges the other map-editor windows?

[wlindley]

Shouldn't "Ignore Climate" go above/below  the climate dropdown?

[Leartin]

Looks good! This also rearranges the other map-editor windows?

Yes, it's mostly in extend_edit, though the individual edits need to be adapted, especially the sorting.

Shouldn't "Ignore Climate" go above/below  the climate dropdown?

It's a weird one, but no.
The climate dropdown affects the list. You can filter what appears there.
'Ignore climate' affects the building tool you get from the dialog. Just like the rotation or - in case of factories - the productivity. Since it doesn't affect the list, it shouldn't be above the list with the filter/sorting options.

Hypothetically, you could have buttons that sort/filter the list by number of rotations or productivity. Both would be above the list, seperated from the current rotation/productivity choices, for the same reason.

[prissi]

Putting the image to the right is certainly a good idea.

One objection to the version above is that it makes the list quite smalle, especially with larger fonts. This makes using the scrollbar even more difficult in pak128 with lots of objects. Also while some options are list and some are building specific, this distinction is mostly relevant to programmers. Most use will not immediatly think that ignore climates is fundamentally different in effect than ignore dates. As such I also feel the climates button could go to the climate selector.

Maybe rather something like left side list, right side options, details, image, translation?

[Leartin]

The big design challenge is to place the image in such a way that huge factories like in p192c find space, but it doesn't look silly if it's a small graphic.

In p64, this version might make the list smaller. In p192c, especially in the factory dialog, people are forcefully used to a very short, very wide lists, as the dialog becomes larger than a 1080p monitor can hold.
In p64, having one column for the list and one column for everything else could work. In p192c, the description would always be minimum size and with some factories outside the screen, as the dialog would be so high it can't be held on a 1080p monitor even in regular font size.
Truthfully, I don't think there is any solution that's completely satisfactory for all sizes. Perhaps three columns, with the description on the very right?

[Leartin]

Attached is the patch for all dialogs - factory, citybuilding, curiosity and trees (groundobj is a seperate patch)

The placements are as in the screenshot, but changing them is only a matter of changing few lines in extend_edit.cc if that's required. Personally, I still don't think it is.

Another thing to consider (that I wouldn't dare to just do): "Available at custom date:" will set itself to the current year and month. Technically, one could remove "use timeline start year" entirely, since that's the same thing - unless the player has the dialog open while a new month begins.
The year can currently be set between 1 and 2999. Instead, one could look through all the objects the dialog references and find the earliest build date/latest retire date. Though at least in p64 you'd still start at 1 for curiosities and urban buildings and 1400 for factories, so I don't think it matters much.

Code (New text strings for translation) Select Expand


[0] south-facing
[1] east-facing
[2] north-facing
[3] west-facing
[4] southeast corner
[5] northeast corner
[6] northwest corner
[7] southwest corner

All Climates

Sort by name
Sort by object name
Sort by pax level
Sort by mail level
Sort by introduction date
Sort by retirement date
Sort by size (area)
Sort by cost

Available at custom date:
Year
Month


[prissi]

The images on the right is certainly better. I think the image coudl be below the description.

About the strings, I would remove the "sort by" part, as a lot of these strings are already translated, like in the tab below even or used in list dialoges. That way less supported languages have already meaningful texts. Also instead of All climates, simply All would do

All Climates -> All
Sort by xxx => "Sort by" (which already exists as label) and the Combobox with
Translation
Object
Pax Level->new
Intro. date
Retire Date
Size (area)->new
Price

Since mail and pax level for city building are the connected and only factories have their special demand, I would just sort by level. However, it may make sense to sort factories by the number of "goods handled" or so.

About the year: I think one can add this for all kind of buildings (and cityvcars etc) but keeping the use timeline switch (as you did). Maybe there needs to be two variants for objects with intro date and for those without.

[Leartin]

About the strings, I would remove the "sort by" part, as a lot of these strings are already translated

That's in direct contradiction to makies statement in the other thread about keeping strings unique. That's why there is a colon at 'use timeline', since it's copied from the game start dialog where you input the start year.

It would be better to have seperate strings, but have the ability to feed the translator with new strings telling it to reuse old strings. Eg. If one of the 'use timeline' strings was changed, the new string would keep all the translations of the old so nothing changes, except now it can be translated. Speaking of that, I think the translator would even do that if you upload a compat.dat with old and new string? Makie?

I think the image coudl be below the description.

I just don't know how. All other elements are in their own container, but the description is the actual content of the thing.

[makie]

Speaking of that, I think the translator would even do that if you upload a compat.dat with old and new string? Makie?

If the old object is deleted or renamed then the compat.dat was used to put the translations to the new object.

About the strings, I would remove the "sort by" part, as a lot of these strings are already translated

Does it really mean the same in this different context, or is the description just coincidentally similar?

From my point of view it is easier to create a new object in the translator and to copy the translations of the other similar one.
To do this by hand takes only a few minutes.

Example:

Sort by xxx => "Sort by" (which already exists as label) and the Combobox with

in German:
Sort by xxx => sortiert nach xxx
Sort by (Combobox) => sortieren nach
sortieren nach Erscheinungsjahr (Fahrzeuge)
sortieren nach Errichtungsjahr (Gebäude)

If the string is unique the translator (volunteer) can find the exact translation for this position.
Else he change by accident the translation unnoticed some where else.

You can reuse strings, but you should be sure that it really means exactly the same thing.

my opinion

[Dwachs]

I like this layout. I still need to test it.

I just don't know how. All other elements are in their own container, but the description is the actual content of the thing.

The text is in the scrolly-component. Adding it before the building_image should do the trick. Maybe rename scrolly and buf to something more meaningful.

[Leartin]

The text is in the scrolly-component. Adding it before the building_image should do the trick. Maybe rename scrolly and buf to something more meaningful.

That works and looks even better.
Do you happen to know how I could make the left column to stay the minimum size it needs? I could put the description and the image in the scrolly-component together, which means no large images would force resize the dialog, but in that scenario, the player resizing manually should only affect the right column.

[Dwachs]

This needs some kind of hack: create child class of gui_aligend_container_t and force maxsize == minsize for this container. (No guarantee that this works ) I can do that afterwards, when you will have finished the patch.

[prissi]

I would suggest to finish without the hack.

Reusing strings is for the translations which see downloads but are not so actively maintained (Korean, both Chinese, Italian, ... ) Otherwise Simutrans would be even less translated in most languages. (Not a new problem, despite Simutranslator being around for a very long time.)

For my suggestion, the context of the reused strings are the same: The first two are taken from the tab that is already in the dialog on top of the lists. And the retire and intro dates are used as sort options in various vehicle dialogs, only for sorting.

[Leartin]

I think I'm done.

Changes from last version:
The translation/object tabs are gone, replaced by a "Show unique object names" button. (With all those other filters and sorters, having it as tabs made little sense)
Factories can sort by number of goods (it counts outputs first, then inputs). That's arbitrary, but just as good as only input, only output, or the sum; having several seemed to overdo it.
Since groundobj_edit was put into the game, it's now part of this patch.
Much cleaner extend_edit.cc - I seperated the layout from the content, so it should be easier to navigate and change the placement of things going forward.
Image is underneath description, and in the scrolly element. I 'hacked' the resizing by defining ten columns, then spanning the right container over 9 of them - the game tries to attribute space evenly to all 10.

An issue (which I hope Dwachs can fix): If the scrollbar appears, it will be there every other update even if nothing is cut off.

About translations... *sigh* I did the changes. First thing I see: "Sort by" was translated, in English, to "sort passenger/freight by"...
I don't want this translation issue to stop the patch from being added, so I added a patch reusing old strings, but also a version using new strings.

[prissi]

I hate when people retranslate translated strings ... Sort by is used in two places. Well, corrected on translator.

EDIT: First thank you very much for this vast improvement.

gui_fill_t(true/false,fals/true) takes care of extending the second column as much as possible.

However, I expected to see the internal name when ordering by object. It makes much more sense to me to connect these two. This would also remove a button from the crowded left side.

Also I wonder if showing the obsolete as extra option is needed, since switching off the timeline does almost the same. (Well, it also shows objects not intended to be included in new games. where the intro year is after the retire year.)

Here is my suggested edit of your patch for comments.

[makie]

I hate when people retranslate translated strings

Why re translate?
Just copy the similar translation when add a similar translation. Then there it is possible to adjust the translation if it does not fit exactly.

[prissi]

No, someone changed the English string to something they found better, even though the original was already English. Then about 30% of the languages followed. Maybe one should lock the base English translation.

[Leartin]

I created a new thread for the string translation discussion. I think it's important to get clarity, but I don't want my patch to suffer. --> https://forum.simutrans.com/index.php/topic,20691

I agree that switching to depicting objects rather than translations when choosing that filter makes sense, and removing a button is generally good. What I don't like is that when you change to another sorting method from there, neither switching back to translations nor keeping objects until one switches to sorting by translation makes entirely sense. In the first case, you disable any combination of sorting and using object names, so you reduce functionality. In the second case, what's depicted is no longer dependent solely on your setting, but also on previous settings - something I wanted to avoid (else I'd not sort by object name in all sorting schemes).
I simply don't care enough, so go ahead.

About the obsolete button: What I would want to do is set a date and build only buildings that could exist at that date. It's the map editor, I'm not placing NEW buildings here, I'm placing old buildings that have always been there. This is something you cannot do without the obsolete button. I'd rather remove the original timeline button as you can do everything it did with the setable timeline, if you are concerned with space.


I have not looked at your suggestion, mostly because I haven't done much with versioning and wouldn't quite know how to store what I did, apply your patch, run it, then revert back to 'my' things.  I guess if I had to, I would download the complete git repository again <<°
But your comment suggests it's details anyway, and I'm at the point where I have spent way too much time on "Oh, look, there is a bug with the rotation numbers" already.

[prissi]

Ok, I think I see your point about translation or not and the obsolete button. Also I noted that the factory fine locations (forest, river ... ) are not displayed as well. However, for the moment this goes in without in r9544. Thank you very much.

However, I am usure about the German translation of south-facing. Südfassade?

[Leartin]

Thank you!

Also I noted that the factory fine locations (forest, river ... ) are not displayed as well.

I did not touch any of the actual descriptions displayed, figuring those could be individual one-file-patches later on.

However, I am usure about the German translation of south-facing. Südfassade?

Südwärts would be my suggestion as most literal translation, simply "Süden" or "nach Süden" should do fine. Not sure if "Rotation" is used elsewhere, if it's unique, calling it "Ausrichtung" might be more clear (As Rotation implies movement)

[Vladki]

However, I am usure about the German translation of south-facing. Südfassade?

How about Fassade nach: [Sueden|Osten|..]