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.

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