Topic: [need help] Improved experiment of Station detail window

[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.