Topic: Improvement of the station detail dialog

[Ranran]

Ranran tried to reform the Station detail window. This is one of the "More graphical symbols! Project" that Ranran is promoting.
However, because of my immaturity, it was not completed. (´・ω・｀)Sigh, really sigh. はあまじはあ
I hope somebody can help this.   

I tried to separate the information into three tabs so that the player could check the information in more detail.
Added class information and added graphical symbols and made the window slim to make it easy to understand the information. I also added information that seems useful.
The new window is a graphical dialog, not a notepad style dialog.
It will help the player by organizing the information.

But I could not make the button work. It does not respond to clicks. (´・ω・｀)

I tried some methods with reference to the code of other windows, but it did not solve after all.
So now this is just like a design proposal. Currently I have placed a dummy button.


You can check the mock-up. This is from the demo.sve of Britain-Ex. 

Tab1:


Tab2:


Tab3:



The waiting bar fluctuates in real time like this.



The github branch is here.
You can test this ruined dialog.
As I interrupted my work, I did not adjust the details. There may still be meaningless variables for placing the button.
  You need new symbol.pak for the new GUI. A stopwatch, a time schedule, an hourglass and a walking symbol have been added. You can download it from this post.
These symbols are intended to be used with the help text clearly indicating that the unit is minutes. It will reduce unnecessary text and save space.

Issues are in halt_detail.cc and halt_detail.h.
Maybe there is a mistake with my configuration. 
It may take some time to check this in detail and correct mistakes. So I think it might be easier for me to make a framework and rearrange parts based on that.
I do not know which solution is good, but I would like to thank you very much for your help.

This is not expected to be completed at the moment, so the explanation is omitted. (However, I think that the design is easy to understand without explanation.)
It may be useful as a design proposal.
The connection display for each class is not a finished design but a temporary display for confirmation. I interrupted my work, but I thought that it was better to display at the leftmost and use color coding and symbols.

[jamespetts]

Thank you for your work on this: this does look good. Sorry that you are having trouble.

May I ask to which button that you are referring that is not working?

[Ranran]

May I ask to which button that you are referring that is not working?

All buttons:
- Line schedule open button
- to move to the station location button
- to move to the factory location button

It was not possible to display the button with the previous code after separating the tabs, so I arranged the button by imitating code such as factory list dialog, but I could not make it work.
So I think my approach is wrong. I do not know the correct passing method of the button from tabs.

[Matthew]

Ranran, this looks great!  Thank you for your efforts.

Although you may feel frustrated that it is not quite finished  sharing your incomplete code with the community is a helpful way forward.

[jamespetts]

I believe that Ranran has done so at the link to the Github branch here.

I have not had a chance to look over the code at this stage, and doing so would take some considerable time, as I am not very familiar with the GUI code, since I have tended to make only minimal changes to the GUI. From what I understand, the problem is that the little black on white arrow buttons are not working. Am I right in understanding that you have changed the dialogue type? There may be an issue as to the compatibility of this type of button with this type of dialogue in the not entirely well organised Simutrans GUI code. Alternatively, there may be an issue as to how the dialogue detects that there has been a press of this button.

I do not know how much that you have had a chance to look into this, but what I suggest that you do next is analyse in more detail how these buttons work when they do work (if you have not done this already), and use a debugger to follow the execution path of the code when a player clicks on one of these buttons (the "action_triggered" method is usually important in this context, so you will need to see whether the code gets this far with your buttons or not). You should then be able to analyse at what stage of this process that this fails in the case of the buttons that you have added. This is the process that I should have to go through if I were to assist with this, since, as written above, I am really not very familiar with the GUI code in any depth.

I hope that this is of at least some help.

[Ves]

Wow, this is simply amazing!!  This is how a proper detailed window should look like IMO!

I tried to compile the code, but it fails with a bunch of errors in the halt_detail.cc. Alot of the errors looks like some functions have been modified to take more calls than original, and it also looks like you have added some new parameters to haltestelle_t, but forgot to commit all those changes.

Code: [Select]

'get_transferring_goods_sum_by_class': is not a member of 'haltestelle_t'
'get_ware_summe_by_class': is not a member of 'haltestelle_t'
'haltestelle_t::get_connexions: function does not take 3 arguments'
etc...

As to the problem with the buttons, I solved a similar case in the "vehicle_class_manager.cc" and "line_class_manager.cc". It is another approach than in the industry supplier list, but it seems to work as it should and no one have pointed it out yet. Those windows (especially the vehicle_class_manager) are initially created by duplicating the "convoy_detail.cc" and altering everything to become the window it is now.
In that window, instead of buttons, it is comboboxes, but the principle should be the same.

I have some suggestions! 

Tab1:
In the summary, instead of "242/ 130" make it "242 (max: 130)"

Tab2:
In the second section, it looks very "busy" when the different good category color squares are not aligned vertically. Either you could start by meassuring which factory entry would be the longest, and them put them all so no one would interfere with the entry, alternatively you could put the color squares before the name

Tab3:
A) In the upper section, I have always missed sorting by waytype in this section, with proper icons. It could be something like:

[Airplane icon]
Airplane line 1
Airplane line 2
Airplane line 3
 
[Train icon]
Train line 1
Train line 2

Also, as below, might look "busy" with the frequency times etc not lining up vertically, although not as much I think as the next point:

B) Lower section. The same as within the second tab. It can look a bit "busy" when the times and distances doesnt line up vertically. You could consider having the distance before the name, since that is something that probably would never change. Additionally, the entries could sort by distance in each category as well instead of the current kind of random order.


But I do really think the window looks really amazing already, thank you for coding it!!

[ACarlotti]

Code: [Select]

'haltestelle_t::get_connexions: function does not take 3 arguments'


That will be a merge conflict with my recent changes - get_connexions previously needed to be passed 'max_classes' as a consequence of it exposing implementation details directly. It looks like it has been present throughout several of Ranran's commits.

Ranran: Did you actually try building that code? In general, you should always check that your code builds before commiting (or if you forget, then you can do it immediately afterwards and amend your commit if you made a mistake). This includes merge commits - in this case the merge might appear to run cleanly because the conflicting changes are in different parts of the code base.
(If you did successfully build and run the code, then I'm confused about how it managed to run.)

Tab2:
In the second section, it looks very "busy" when the different good category color squares are not aligned vertically. Either you could start by meassuring which factory entry would be the longest, and them put them all so no one would interfere with the entry, alternatively you could put the color squares before the name

Also, as below, might look "busy" with the frequency times etc not lining up vertically, although not as much I think as the next point:

B) Lower section. The same as within the second tab. It can look a bit "busy" when the times and distances doesnt line up vertically.

This alignment stuff might be made easier when the recent gui changes in Standard make it into Extended.

[Ranran]

Thank you for your feedback. 

I tried to compile the code, but it fails with a bunch of errors in the halt_detail.cc. Alot of the errors looks like some functions have been modified to take more calls than original, and it also looks like you have added some new parameters to haltestelle_t, but forgot to commit all those changes.

Oh, I'm sorry. Unfortunately for some reason the upload failed and it seems that I have accidentally overwritten the file and lost what I changed. (´・ω・｀)
I rewrote the lost function but I do not know whether it was the same before. And I also changed the transferring bar. Now you can test it. The problem with the button has not been solved yet.

Tab1:
In the summary, instead of "242/ 130" make it "242 (max: 130)"

I wonder if "max" is correct as it can be crowded beyond this number.

Tab3:
A) In the upper section, I have always missed sorting by waytype in this section, with proper icons. It could be something like:

[Airplane icon]
Airplane line 1
Airplane line 2
Airplane line 3
 
[Train icon]
Train line 1
Train line 2

I originally planned to put the icon on the left edge, but I canceled it because the icon size was large. Since grouping seems wise, I implemented it. However, I am hesitant about how to handle lineless convoy.

Also, as below, might look "busy" with the frequency times etc not lining up vertically, although not as much I think as the next point:

B) Lower section. The same as within the second tab. It can look a bit "busy" when the times and distances doesnt line up vertically. You could consider having the distance before the name, since that is something that probably would never change.

This issue is somewhat complicated. The names of routes, stations, and convoys have a large difference between long and short ones. If the margins are large, blank spaces will be noticeable and the width of the window will be wide.
And the big issue is the language difference. Japanese and Chinese tend to have a small number of characters, which can create very wasteful margins. It is the most difficult problem in the layout of the table. Symbolize can reduce this difference.
As ACarlotti mentioned, I think that it will be solved easily if html table like GUI is imported from standard and a fluid table can be made.

Additionally, the entries could sort by distance in each category as well instead of the current kind of random order.

I think this is the order of registration. I wanted to sort it by distance, but I do not know how to sort this.

[Ves]

Thank you for your feedback. 
Oh, I'm sorry. Unfortunately for some reason the upload failed and it seems that I have accidentally overwritten the file and lost what I changed. (´・ω・｀)
I rewrote the lost function but I do not know whether it was the same before. And I also changed the transferring bar. Now you can test it. The problem with the button has not been solved yet.

Thanks it works now!

I wonder if "max" is correct as it can be crowded beyond this number.

Other places it states that the capacity of a station is this and this, for instance in the station window and also in the icon tooltips. IMO, "max" in this sense is just a synonym for "maximum capacity", but I am not english speaker so I might be wrong. In any way, spelling it out I think looks better.

I originally planned to put the icon on the left edge, but I canceled it because the icon size was large. Since grouping seems wise, I implemented it. However, I am hesitant about how to handle lineless convoy.

THANK YOU!
I tend never to use lineless convoys, and on the bridgewater brunel game, I have only seen the odd lineless convoy. One way to do it could be to add within each waytype section textline "lineless convoys:" and then list the convoys benieth.

Something like:
[Airplane icon]
Airplane line 1
Airplane line 2
Airplane line 3
 
(Lineless convoys:)
Airplane 1
Airplane 2
 
[Train icon]
Train line 1
Train line 2
Train line 3
 
(Lineless convoys:)
Train 1
Train 2

I dont know if it would look better to have it not in brackets or in brackets as in my example. I think I would prefer having them sorted by the waytype instead of having them separate below all the line lists.

I think this is the order of registration. I wanted to sort it by distance, but I do not know how to sort this.

I tried to do it, but I failed due to my lack of knowledge of handling "static" things in the code.
What I did was that I put all halts for the given good categories in a vector_tpl. Then I sent it via the std::sort function to be sorted in a "compare_halt" which I also created.
The "compare_halt" looks like this:

Code: [Select]

bool halt_detail_line_t::compare_halt(halthandle_t halt1, halthandle_t halt2)
{
sint32 result = 0;
const uint32 tiles_to_halt1 = shortest_distance(halt->get_next_pos(halt1->get_basis_pos()), halt1->get_next_pos(halt->get_basis_pos()));
const uint32 tiles_to_halt2 = shortest_distance(halt->get_next_pos(halt2->get_basis_pos()), halt2->get_next_pos(halt->get_basis_pos()));
if (tiles_to_halt1 != tiles_to_halt2) // Distances are different, sort by distance
{
result = tiles_to_halt2 - tiles_to_halt1;
}
else // Distances are same, sort by name
{
result = strcmp(translator::translate(halt1->get_name()), translator::translate(halt2->get_name()));
}
return result < 0;
}
but the "halt" values gets a red underscore with the error:
"a nonstatic member reference must be relative to a specific object"

[ACarlotti]

I tried to do it, but I failed due to my lack of knowledge of handling "static" things in the code.
What I did was that I put all halts for the given good categories in a vector_tpl. Then I sent it via the std::sort function to be sorted in a "compare_halt" which I also created.
The "compare_halt" looks like this:

Code: [Select]

bool halt_detail_line_t::compare_halt(halthandle_t halt1, halthandle_t halt2)
{
sint32 result = 0;
const uint32 tiles_to_halt1 = shortest_distance(halt->get_next_pos(halt1->get_basis_pos()), halt1->get_next_pos(halt->get_basis_pos()));
const uint32 tiles_to_halt2 = shortest_distance(halt->get_next_pos(halt2->get_basis_pos()), halt2->get_next_pos(halt->get_basis_pos()));
if (tiles_to_halt1 != tiles_to_halt2) // Distances are different, sort by distance
{
result = tiles_to_halt2 - tiles_to_halt1;
}
else // Distances are same, sort by name
{
result = strcmp(translator::translate(halt1->get_name()), translator::translate(halt2->get_name()));
}
return result < 0;
}
but the "halt" values gets a red underscore with the error:
"a nonstatic member reference must be relative to a specific object"

Where is halt defined? It looks to me as though you might be trying to call methods of the halt object you are currently inside a method of, in which case you would probably need to e.g. get_next_pos instead of halt->get_next_pos. However, I'm not totally sure whether you can use object methods as comparators in std::sort.

There are also a couple of other minor issue with this approach. Firstly, this code will result in the distance to each halt being computed a number of times (probably logN times where N is the number of halts you're sorting). I don't think this is likely to be an issue, but it's probably better to compute all the distances before doing any sorting (perhaps creating a temporary struct of distance and halt reference for each halt), especially as computing distance to nearest points could be quite computationally expensive.

Secondly, there are probably cases where this will overestimate the shortest distance to another halt (imagine two long parallel halts with basis_pos at opposite ends. I don't know how bad it would be to use potentially inconsistent distances in these circumstances.

[Matthew]

I believe that Ranran has done so at the link to the Github branch here.

I meant to praise Ranran for contributing his imperfect code to the community. Apologies to both of you, as I obviously failed to communicate that.

[jamespetts]

Thank you for your work on this. I have tried the version 2 of this: it does look good, although there is some overlapping text in the first tab. I notice that you have not been able to get the arrow buttons working still; I am afraid that, as explained above, I am not likely to know anything more than you about how to get these working, as I have never looked into the GUI in this sort of detail.

As to the design, this is definitely a good improvement; I do like your work on the GUI generally: it has much improved Simutrans-Extended. I think that we perhaps need some more clarity as to the waiting times and the classes: perhaps a menu to choose which class's waiting time to display? The same should also apply to the journey time.

In any event, thank you again for your work on this: this is appreciated.

[Matthew]

Ranran, you have already made great contributions to Extended and this project would definitely improve the game a lot.

Now it seems that you are stuck because you can't make the arrow buttons work.

But nobody here can help you, because Extended devs don't know the GUI code (and people like me don't know any code).

Maybe you could ask a specific question about the arrow buttons in Standard's Patches & Projects forum? I think the GUI code is the same in both Standard and Extended (except themes), so I guess some of the Standard devs must know the GUI code well.

Though I guess prissy may be on a plane back from Tokyo this week? 

[jamespetts]

I notice that this has stalled for over 6 months because of the issue with the jump to location arrow buttons. It would be a shame for all this work to go to waste, I think. Can I ask for people's views on whether this patch would still be worthwhile if those buttons were omitted entirely (perhaps commented out until somebody can find a fix for them)?

Ranran, would you be able to disable the non-working buttons and deal with the more minor issues (e.g. the overlapping text) in this so that it can be incorporated? This is a very nice improvement on the current windows even without the jump to location buttons, I think.

[prissi]

The GUI is now totally different to allow scalable buttons everywhere and easier use on a tablet. Also a lot of functionality was repaired. I think the GUI is one of the major differences between experimental and standard now too.

[Matthew]

I notice that this has stalled for over 6 months because of the issue with the jump to location arrow buttons. It would be a shame for all this work to go to waste, I think. Can I ask for people's views on whether this patch would still be worthwhile if those buttons were omitted entirely (perhaps commented out until somebody can find a fix for them)?

Ranran, would you be able to disable the non-working buttons and deal with the more minor issues (e.g. the overlapping text) in this so that it can be incorporated? This is a very nice improvement on the current windows even without the jump to location buttons, I think.

This is a great patch even without the buttons. 100% support incorporating it with buttons commented out.

[Freahk]

Absolutely! it would be a shame to scrape it for this little issue.

Nevertheless, as prissi mentioned, it is indeed kind of sad that extended-gui will also neccessarily diverge from standard now, as the improvements are based on the old GUI "framework", so it can't be backported to standard.
Merging the GUI changes from standard to extended will require a lot more effort now, however, as work at the improved station UI seems to be nearly finished, scraping it for that reason now would be a shame.

Before starting any further GUI improvement projects, we should try to merge in the new GUI framework from standard, being aware that it would now also include a near rewrite of the station and convoy window.

Edit: Note that the non-working arrow buttons may or may not have been your fault. It seems sometimes they don't work on time history window and current station detail window either.

[jamespetts]

Ideally, it would be excellent to merge the GUI changes from Standard, as those seem to be a real improvement. However, if there are not dedicated coders willing to do this, then it is best not to hold up other UI projects (such as this one) on account of that. The most important thing is to enhance the functionality of the game.

And I am very much of the view that this feature would be worthwhile even if we have to cancel the idea of having jump to location buttons as originally intended.

[Phystam]

I think that Ranran or Ves who are working on the GUI improvements can incorporate the Standard GUI changes.
Furthermore, it is very excellent if you can incorporate the Font support and skin selector at the same time.

[Ranran]

Thank you for your feedback. I reviewed the button placement code again, but it didn't work. (´・ω・｀)
I think that the standard's gui_aligned_container_t class can do this easily, so I plan to make this work after the standard GUI improvements are incorporated.

[Ranran]

I proceeded with the work left over and put it into a usable form for the time being. This time the button is sane. You can test it now.
Some implementations have been omitted. But I think it has evolved from the existing ones. This is the first step in enhancing this UI.

The github branch is here.
https://github.com/Ranran-the-JuicyPork/simutrans-extended/tree/tabbed_halt_detail

[jamespetts]

Excellent - I am testing this now: this looks very interesting.

One or two queries at this stage, if I may. First of all, can I ask for clarification on the meaning of the small dark grey bar underneath the larger bars representing the different colours of freight types in the "freight" tab?

Secondly, I notice that your mockups show a number of additional symbols under the "services" tab which do not appear in my version, and this tab looks just like the equivalent part of the halt detail dialogue in the current master branch. Is this intentional, is it an error in the code, or do I need to merge in some additional symbols in the pakset in order for this to work? I should note that I do see these symbols in industry dialogues, so they are not missing entirely.

[Ranran]

Thank you for testing.

can I ask for clarification on the meaning of the small dark grey bar underneath the larger bars representing the different colours of freight types in the "freight" tab?

There are two types of transhipment: inward and outward.
In other words, the difference between heading to the station and heading to the destination from the station.
Transfers heading to the station will join the waiting bar over time. So it's gray and sticks to the waiting bar.
On the other hand, the transfer from the station to the destination disappears when it arrives at the destination.
This difference is expressed not only in cargo but also in passenger and mail.
In the case of passengers, this external transfer may show passengers walking from station to station by foot movement. This is not strictly a station user.
On the other hand, in the case of freight, it seems that outward transfer is also used to judge the overcrowding of the station as judged from the code.
For the above reasons I decided to use such a representation to distinguish them.

I notice that your mockups show a number of additional symbols under the "services" tab which do not appear in my version

Some implementations have been omitted.

That's what I said I omitted the implementation.

this tab looks just like the equivalent part of the halt detail dialogue in the current master branch.

Therefore its appearance is the correct form currently implemented. But then I made further changes to organize the line list by waytype.

Is this intentional, is it an error in the code, or do I need to merge in some additional symbols in the pakset in order for this to work?

This is intended. Currently, no additional symbols are needed.

This time the main purpose was to match this UI to the changes in the UI of the factory list.
However, since it is a problem that the button does not work properly, I prioritized not losing the function of the button.

Currently the line list is made to draw two layers of text and button (and label) at the same position.
It turns out that the buttons are turned on and off by the owner, so it takes a lot of work to function properly in a mockup-like design.


Next, regarding route information:
I know from experience with big games on servers that this needs improvement. However, this requires adding information for each class, and is a major change in work, so it will be proceeded as a separate project. (The class display in the mockup didn't look very good either. )

[jamespetts]

Splendid, thank you for this: now incorporated. I have also updated the help file. I notice that there is also a "tabbed halt detail plus" branch, but I have not incorporated this since I assume that this is not ready at this stage, not having had any information about it yet.

[Freahk]

After some time of using the new detail window, I do really like it.

However, the topmost information in that window is rather a general brief information.
As such, I'd rather expect it in the main station window.
It would also be nice to have a visual indication of "over capacity", though that's not too important eye candy.


Is there any particular reason why the very first line (amount of lines of a specific type plus company) was not added to stops main window?

The lines below (capacity + in station + in transit) is less detailled than the passenger list either.
That given, I'd slightly reorganise the order of the passenger/main/goods list in stations main window and add the bars there.
Something like


Passengers: |___|__|___| 115+40 / 599
  In station:
  50 > King's cross
  48 > Waterloo
  ...

  Transit in:
  13 > Queens's cross
  7 > Waterloo

  Transit out:
  42 > whatever

Mail: |_________> 5634 / 10

[Ranran]

This patch implements only the first step and the rest are pending.

Is there any particular reason why the very first line (amount of lines of a specific type plus company) was not added to stops main window?

I've always been aware that there are two station dialogs, and I've been thinking about restructuring.
But this is due to the View issue I sometimes mention. In the main window, there is a dialog layout destructive god "View".
This view is very confusing to the GUI layout as it varies in size depending on the pakset size.
I designed the top of this dialog (station capacity display) to be compact and useful for monitoring, and to be minimized to display just that.
You can keep a lot of such compact dialogs open and monitor the situation, especially in simulation games where I find the GUI design to be good.

For example you know that my company on bridgewater server made some mail terminals. Keep the dialog for monitoring such terminals open at all times. Then use the shortcut keys to open and close the tabs to operate the tabs.


This will be used in conjunction with the locking feature proposed in another thread. The translucent bar reduces annoyance.
(Shortcut keys for tab operations once became the current specifications due to conflicts. This needs to be adjusted again.) It's not difficult to add a window minimization shortcut key, so I plan to add it.

Ideally we may still be able to hide the transfer time display.

In another example, it can also be used when you want to monitor the newly created cargo network so that it does not overflow or accumulate cargo.

Initially, there was no indication of the number of service lines, but without it, some said it inconvenient because there was not enough information to show the characteristics of those stations. So it was added there. (But for some reason it's broken after the GUI overhaul. It was repaired once but seems to be broken again. (´・ω・｀))

However, this direction may differ from what standard is aiming for.

Also, when thinking about reconstruction from another point of view, I think the main view has a chart and a rating bar in the foreground, which means it has a "statistics" -specific element. On the other hand, the time table and the number of waits are real-time information.
I'm sure these two dialogs are somewhat confusing as such.
The standard combined those dialogs into tabs and finally merged them into one dialog.
But I don't think it's suitable for Extended. Extended is a lot of information, and I think that both statistical information and real-time information need more accuracy and more information.
Therefore, these dialogs are not integrated in branches that are being more incorporated from the standard.

The currently pending patch will add more new tabs and station area information. It may be necessary to organize them comprehensively.

And unfortunate news. The halt_info dialog has a big difference between standard and extended, and the GUI overhaul patch cannot be merged. This is not due to the changes I made to the GUI, but to the time table code. I'm not familiar with this code. So it can't be merged and is on hold.

EDIT:
Now that the keys 1-9 have been released, they may be used for tab operations, etc.

[Freahk]

That seems quite reasonable and the improvement is relly great already.
I am not sure anymore if anything in the detail window should better be moved to the basic station window. Imho, their distinction is not static vs statistical data, but the level of detail shown.
The detail window should show all the details, whils tthe basic station window should show the most frequently used informations as well as further informations in a minimalistic way, which can clearly indicate "you might want to have a look into the details", if there might be something wrong.

I just took some time to write down my thoughts about the basic station window, which came up when reviewing the station detail window due to these being closely tied to each other.
Some thoughts are related to the detail window, but most of those are specific to the basic station window, so I opened a new thread:
https://forum.simutrans.com/index.php/topic,20471.0.html

[Freahk]

*dig*
I just noticed that waiting times in the station details have a related "waiting speed". This is weird and feels quite wrong to me.

[Ranran]

I'm not an English speaker, but I find "waiting speed" a very strange expression. I don't think I use such expressions. Judging from that, I think you do not understand the meaning of that display correctly.
Please refer to some examples in the game to understand the meaning.
I'm not confident in English expressions, but can they be communicated at Expected movement speed?
That's an important value, at least in light of the extended spec. For example, if it is slower than walking speed, you are offering a very poor service and people will travel on foot without using your service.

[Freahk]

No, a waiting speed is actually nonsense. That's the point.
As can be seen in the attached image, there are two times related to a "direct route" in the "Group by destination" tab.
The pointer watch and the hourglass, both stating a time and a speed.
From my understanding, the pointer watch is the icon of the the journey time, whilst the horglass is the icon of the waiting time with a "waiting speeed" in braces.

[Ranran]

I'm sorry, I don't understand your claim.
Can you understand what it means by adding a "+" sign in front of the hourglass?

[Freahk]

You mean the total time is travel time plus waiting time?
Well people should know this but it's a fair addition to explicitly point this out in the UI.

Anyways, it's not the point I'm describing.
It feels weird to have a speed assigned to waiting as in
2:36 (41 km/h), especially as this speed cannot be compared against walking time due to the fact that total time is wait + travel

[Matthew]

Three thoughts.

Firstly, Ranran, the building and station info displays are GREAT! Increased prettiness and graphics with no drawbacks.

Secondly, Freahk, if you don't like the 'waiting speed' you can always just use "Group by category" and forget "Group by destination" exists!  This is actually what I did. It took me ten minutes to realize what this conversation was about.

Thirdly and more seriously, I agree that the 'waiting speed' display is a little confusing. Two ideas. Firstly, we could just explain in the help file, which is now badly outdated anyway. Secondly, maybe don't show the 'waiting speed'. Instead compare the 'waiting speed' with walking speed for Passengers only. If 'waiting speed' =< walking speed, add a warning icon (like the yellow triangle with !) and a tooltip to warn players that passengers will prefer walking.

[Ranran]

The walking time example is just one example. I don't know if it will affect the use of private cars. However, it is used for comparison with competitors. If you are providing poor service, other players will take passengers from you. Players can refer to it because it is actually used for that index. Unfortunately, which player and which route offers the best service is only displayed in debug mode.

Again, it's not "waiting speed". Without it, if the player wants to know it, he will be forced to calculate the distance and estimated travel time in his head, making things hard to grasp. Group by category has less display space, so it only appears in debug mode.
Note that the one on the left is the rating of convoy and the one on the right is the rating of line. speed is an important indicator in both cases.

In any case, it is recommended to use the helpfile as it exists for such cases.
Simutrans has used a lot of hard-to-understand displays, such as numbers in a blanket of factory information, which the help file has explained.

It may be possible to improve the display like the + display in the precedent.

[Vladki]

Well, I think that it would be enough to explain what the numbers in the screenshot from Freahk mean?
Can anyone correct and complete my guesses?

Direct routes / Group by destinations

[stopwatch icon] time1 (speed1) - that is (I guess) the travel time and average speed for given destination and cargo
[hourglass icon] time2 (speed2) - that is (I guess) the waiting time - but what is the speed? Is it average speed including the wait time?  I.e. speed1 = distance/time1, while speed2 = distance/(time1+time2) ?