News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

Sort Vehicles in Depot Window

Started by HyperSim, October 15, 2017, 05:14:37 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ters

Without having looked at the code, I thought that was in already. What else could the cost in the diagram from 14 November be? Was it removed later?

Leartin

Running cost, yes. Running cost per unit, a combination of running cost and capacity, no. Would make sense though.

Ters

I thought he meant running cost per unit of distance, which is the only running cost number I've ever seen in the game.

HyperSim

Quote from: Dwachs on November 24, 2017, 06:12:07 PM
Here is a modification of the patch: I moved the sort-button to the last line of the depot window: it made more sense to me. In this way, the 'show all', 'show obsolete' buttons and the filter are on the same line, which is consistent. Also used std::sort directly to sort a vector_tpl of pointers. If there are no objections, I would like to submit the patch.

I checked your code and it works.
I didn't know well about vector_tpl, so this modification helps me a lot.  However, there are some problem.
The right-bottom corner of depot window is the space for "Resale Value." (see the 2nd image attached)
And in my opinion, saparated filter section and sort section is a bit difficult to use. (I want to hear other opinions)

Dwachs

Did not know about this resale value. What about moving the 'Sort by' button below the filter-related stuff, and then moving the text block one line down?
Parsley, sage, rosemary, and maggikraut.

Dwachs

Here is an update: fixes the layout problem: the sort button is now below the filter buttons. Also adds running cost per transported unit as sort option.
Parsley, sage, rosemary, and maggikraut.

HyperSim

Quote from: Dwachs on December 01, 2017, 11:46:07 AM
Here is an update: fixes the layout problem: the sort button is now below the filter buttons. Also adds running cost per transported unit as sort option.

I checked it and I now understand what "cost per unit" mean.
It seems nice feature but this patch sorts vehicle in decending order.
And I think the space below "Show all" button is wasteful.
So, I merged your code with mine and make the window simple.

.diff file (based on r8342) is in attachment.
exe file(Win only) : https://drive.google.com/open?id=1dJD0-9qcY82sbSbUO2pf6X4uSQdOt-qc
git : https://github.com/HyperSimu/simutrans/tree/SortInDepot

Leartin

Let me get in on the action :D

Can't provide a patch, just a mockup. The first is just a rearrangement, as I suggested earlier in this thread.
I like the second one even more, though: By getting rid of the line "X vehicles in this depot", there would be room for a divider, which is very pleasing to my eye. Instead of that line, show the number of vehicles in the tabs. Would be more convenient to find those vehicles in the depot, too.

What do you think?

Dwachs

I like the idea of adding a horizontal divider and the Label 'Search'. Also 'X vehicles in deport' seems not to be necessary. However, the order of buttons, filter stuff, and 'append' button is without any logic in your mockups.
Parsley, sage, rosemary, and maggikraut.

Leartin

Quote from: Dwachs on December 04, 2017, 06:06:15 PM
However, the order of buttons, filter stuff, and 'append' button is without any logic in your mockups.

Could you explain how the current/suggested solutions are actually logical? Seems to me as if they are pretty random, basically ordered by date of implementation.

To me, the most important thing is to place the "Show all"-checkmark right next to the append-button. This is to give it some context - "show all" is not a terribly descriptive name, it does not actually show all - it shows "vehicles other than those clickable based on the current state of the append-button". As such, placing button and checkmark next to each other, and relatively isolated from others, is quite important. As it is, they are pretty much as far from each other as they can be. I also don't like how it interacts with "show obsolete" - it always made me think that "show all" would somehow remove the timeline and allow me to see future vehicles, just like "show obsolete" reveals past vehicles.
For the rest, I just put filter, obsolete and searchbar in one line because they are technically all filters, leaving sorting for the top-right corner.

Maybe you disagree with my priorities, but there is definitelly logic.

Ters

I like Leartin's Depot2.png, but search and filter should be next to each other, "show all" and "show obsolete" should be the closest to those two and aligned. These four are all kind of filters. That leaves the append button and sort. The number on the tabs could be useful to me, but I am worried that their meaning isn't clear. It could be number of stored vehicle parts (useful to me), or it could be number of vehicles types listed on each tab (possibly the most likely interpretation for new users).

HyperSim

I also like the horizontal line and "Search:" label.
But, I don't like the layout because it seems untidy to me.
I think "X vehicles stored here." are needed because I sometimes use that notification,
but if I delete that label and place "Append" button left side of filter, the window will become simple.
However, I don't think this window is useful because it's too cramped.

By the way, what do you think rearranging the vehicle information bottom of the window?

Leartin

At least append and show all are close to each other, even if they are not in the same line. Can live with that.

Dwachs

I committed the patch in r8344. Please feel free to work on design changes. I will happily submit more patches to modify the layout.
Parsley, sage, rosemary, and maggikraut.

Leartin

Should probably be it's own thread, but could we get a similar functionality in the build-citybuilding-dialog?

Dwachs

Please do this in an own thread. What should be the sorting criteria?
Parsley, sage, rosemary, and maggikraut.

HyperSim

Quote from: Dwachs on December 09, 2017, 05:19:59 PM
I committed the patch in r8344. Please feel free to work on design changes. I will happily submit more patches to modify the layout.

Thank you for integration!
Here's an update patch to modify the layout I posted before. (I attach the image again.)

I think reducing lines for vehicle information is needed because there's too many line for the info.
I united "Power:" and "Gear:" lines and "Intro. date:" and "Retire date:" lines. (So, I reduced 1 line.)
I want to know what do you think about it.

DrSuperGood

"Active date" sounds bad English I think. Something like "Available" sounds better.

Leartin

#53
Quote from: DrSuperGood on December 10, 2017, 09:05:15 AM
"Active date" sounds bad English I think. Something like "Available" sounds better.
That would be a translateable string anyways. For the backend, "active date" is a bit clearer even though it's awkward, put the string in Simutranslator and it can be "Available" in the frontend.
I wonder if the way the date is written is translateable too, at least the months. If it is switched (01/1948 instead of 1948/01), the string "01/" could be translated as "Jan. " or "January " instead, in languages or paksets that have the space. Note that paksets can use their own translations for strings, so it should be possible to keep "active date:" empty and replace it have the line written as "January 1948 - January 1968" - you don't usually have to explain dates. Look up any famous person on Wikipedia, chances are the article starts "Name (Date-Date)". The date in the statusbar does not say "Current Date:" either...

Ters

I'm not sure the meaning of the two dates in Simutrans are as obvious as the two dates for a person on Wikipedia. For persons, there are only two dates that are relevant without a context: birth and death. For vehicles, it is arguably three: introduced, last produced, retired. Simutrans doesn't have a concept for the middle one, but new players will not know that.

HyperSim

Quote from: DrSuperGood on December 10, 2017, 09:05:15 AM
"Active date" sounds bad English I think. Something like "Available" sounds better.

I'm not good at English and I didn't come up with exact word.
However, translate file will solve this problem as Leartin mentioned.

Quote from: Leartin on December 10, 2017, 10:14:07 AM
I wonder if the way the date is written is translateable too, at least the months. If it is switched (01/1948 instead of 1948/01), the string "01/" could be translated as "Jan. " or "January " instead, in languages or paksets that have the space.

I once planed using the same format displayed in the status bar. (which is defined as "show_month" in simuconf.tab)
If it is ideal, I will start working on.
But, I'm against for omitting "active date:" because I think the window without the index is not clean.

Dwachs

I would vote for leaving the text block as it is and just applying the patch to rearrange the buttons and to add the divider line.
Parsley, sage, rosemary, and maggikraut.

HyperSim

I updated the patch and suggest two layouts.
Please check the picture attached.

update

  • Use the same format as the status bar to show intro. date and retire date. (depending on show_month in simuconf.tab)
  • Restore the text block.

.diff file for both design are in the attachement.

HyperSim

Is there any opinions for this modifying?

The former layout is smaller but I removed the information to show how many vehicles in the depot.
The latter one is the layout based on the current layout.
In my opinion, the latter is better.

I restored the text block for now, but I think that block should be modified.
Vehicles without engines (ex. carriages and freight cars) do not have "Power:", "Gear:" information, so these space are useless. (Figure1)
And the same for vehicles without "Retire Date". (Figure2)

Dwachs

I do not understand, why you want to change the layout of the intro/retire dates. Why not leaving the text block as it is?

Also I like the layout of buttons in the picture depot_layout_01_Other_style.png .

Parsley, sage, rosemary, and maggikraut.

prissi

I would just show the text of how manz vehicles stored, if there is no convoi is show in the top row. Otherwise this information is not needed. And the design with the separator indeed looks nice.

Leartin

Quote from: Dwachs on December 18, 2017, 08:55:21 PM
I do not understand, why you want to change the layout of the intro/retire dates. Why not leaving the text block as it is?
Because, quote "Vertical window height is also already at max for those running lower resolution displays. i.e. This dialog be full!" ~ TurfIt
Going by that, you'd need to reduce a line in the text block in order to add an additional line for sorting and the search box. The changes made seem to be the most logical to achieve this - "Gear" as well as "Power" are both meaningless without their counterpart,  they only give useful information together. Introduction and Retirement are both dates, so they go well together as well.
As HyperSim pointed out, these informations don't exist for each vehicle, often leaving holes - especially gear. In a dialog that's "full", holes are a waste of precious space (if not used intentionally, like with the seperator or not having information to the right of the vehicles name)

So it pretty much comes down to the question whether the dialog is indeed full and as big as it can be, which means you'd need to reduce it on one end to add something new, or it can just be expanded.

HyperSim

Leartin said what I want to say.

There are two reasons why the text block should be changed.

The one reason is the size of the dialog.
The depot window height is about 500px now if you play pak128, (If you play pak64, it is about 400px.)
and the height of some laptop pc monitor is 768px. (WXGA)
If you play simutrans on these laptops, the screen looks like this.
https://photos.app.goo.gl/31S7a39IgiPNdxf52 (Link to Google photo)
So, we should discuss whether this dialog is too big or not.

The second reason is that the current dialog does not looks good.
When you see carriage (or freight car) info, there's a empty line in the middle of text block,
because that vehicle do not have power and gear info.
I think it is a dead space and there should be a better design.

HyperSim

Happy new year!

This topic has been stopping for 2 weeks, but there are some issue to discuss.
So, let's start the discussion again.

prissi

I had a few tweaks of the dialoge (due to pre-release work) and changing that text will not happen, as it will break the text with the translations. And those are central to the game. Also, there are frei DMU, which use all the lines, as well as passegner EMU too. I do not see how you can save a line here.

HyperSim

Quote from: prissi on January 07, 2018, 12:50:25 PM
I had a few tweaks of the dialoge (due to pre-release work) and changing that text will not happen, as it will break the text with the translations. And those are central to the game. Also, there are frei DMU, which use all the lines, as well as passegner EMU too. I do not see how you can save a line here.

Whether the text block are changed or not, we have to edit translate file because there are no translation for "Vehicle Name", "Cost per unit" or "Vehicle Power" in text/XX.tab file.
Therefore, I think we don't have to worry about breaking translations, just add and fix it.
I attached the text block mock-up which uses all the lines.
I merged "Power" and "Gear" into one line, and "Intro. date" and "Retire date" into one line, so we saved one line.

DrSuperGood

Gear can probably be removed and replaced with "Effective Power", which is {Power * Gear}, and then swapped places with Power. Power is meant to be semi-realistic but in order for the convoys to work mechanically well gear is used to adjust the in game power. Hence players are much more concerned about the effective power and not the realistic "lore" power of a convoy/component. Gear currently is just some obtuse mechanic to confuse new players as to why a high powered convoy is under performing or a low powered convoy over performs.

prissi

Dates like that are problematic, since the month/year order and separators are different among cultures (e.g. Japan year/month versus Germany month.year). Thus there was one central routine to take care of dates.
Also it needsto deal with missing intro or retirement dates.

My suggestion to convert power and gear would be rather a multiplier shown to get the effective power.
Power: 88 kW (x2.0)

And to missing translations: There is a file base.tab, which must be altered, whenever a new text is introduced to simutrans. Not all patches does this, but any translation needed there will end up in text files, if the translation is different from the original. (I am currently try to synchronise this file with reality to prepare for a release.)

But knowing how difficult it is to get new translations and complete translations, I am not easily pushing these concerns to the side.

Leartin

Quote from: prissi on January 09, 2018, 07:05:40 AM
Dates like that are problematic, since the month/year order and separators are different among cultures (e.g. Japan year/month versus Germany month.year). Thus there was one central routine to take care of dates.
Also it needsto deal with missing intro or retirement dates.

Are nested translations possible? Could you have the string "$1 $2" in the game to represent the date, but languages could translate it as "$2/$1", effectively changing the order of variables, which then get replaced by the internal months and the year, where the months again get translated? I know variables can be in the translation strings (eg. for the record announcements), but they don't seem to allow switching the variable positions.

Either way - while most people wouldn't tackle a large translation project, this here is about a few strings. Since it's unlikely to get into the current prepared release anyway, how about we use this thread to find out how it should change if it changes, and once that's settled, before it is put in the actual code, we publically ask for translations in the forums (for the few strings needed). Only if they are all provided, it is put in the code. This would make sure the game would not be without that crucial translation even for a moment, but also remind people of the translator who might not even know about it.

prissi

It is probably worthwhile to have a short date routine too, also for other places. Still, a japanese data may be wider in characters,
2999年12月
compare with
12.2999
So there is some extra free space needed. Also it needs consideration of things never expiring or never being introduced (intro year=0 the latter certainly more rare and mostly buildings).

And since there is a recent overhaul of translations needed before the next release (which I am doing right now), chnaging translation is probably not a bad time. The only problem is that with many langugaes (finnish, korea) we do not have translators or members, but still quite some downloads. So waiting for these translations will not happen quickly, if ever ...