News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

[Gui] Problems with Network Filter

Started by Yona-TYT, July 29, 2017, 05:46:03 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Yona-TYT

The option selected with the cursor is not displayed.


DrSuperGood

#1
Are you referring to the tooltip for the wrong element being shown?

Yona-TYT

Quote from: DrSuperGood on July 30, 2017, 05:16:15 AM
Are you referring to the tooltip for the wrong element being shown?
If for example you click on "bulk", the value shown will be "all".

DrSuperGood

This might be a theme problem. Check that it does not happen in pak64.

Yona-TYT

This is the theme I use: http://files.simutrans.com/index.php/s/I0bBjz1VxYNAvc4

Quote from: DrSuperGood on July 31, 2017, 07:30:25 AM
This might be a theme problem. Check that it does not happen in pak64.
The same problem with the standard theme.





Another detail is that the list should be folded by clicking on the box.



An_dz

Quote from: DrSuperGood on July 31, 2017, 07:30:25 AM
This might be a theme problem. Check that it does not happen in pak64.
I fail to see why this would be a problem with the theme. Yona is using the touch version of the pak96.comic theme I've made and if there's any bug it must be with the code not being adapted to bigger buttons.

Ters

I have noticed that dragging the box in the scroll bar of such drop downs causes some random movements. Sometimes it jumps far back up. Maybe that is related. This is with the default theme.

DrSuperGood

The GUI system being used requires the component graph hierarchy to process events in Depth-first Post-order search, stopping the search if a component accepts the event. The way Simutrans implements this requires parents translate the event's coordinates from their own local coordinate space to the child component's coordinate space before forwarding the event for processing. A side effect of this implementation means that events must traverse the GUI component graph in Pre-order.

To improve usability by allowing keyboard commands to interact with the UI there is a concept of "component focus".
// holds the GUI component that has the focus in this window
gui_component_t *comp_focus;

This is implemented at a container component level, where the container will remember the focus. For focus to work correctly each container must track the direct child which is focused and this graph can then be iterated until the actual focused user control for processing appropriate keyboard events.

Someone accidently pushed up this focused component up the component graph hierarchy so that events can be passed to it from a higher up component directly. However doing this violates the pre-order visiting requirements of processing events. For keyboard events this is fine as they do not require coordinate space translation, however for mouse events it completely breaks as the user control component does not receive an event in a coordinate space appropriate for it.

So why is only the Map window broken? The Map window places the filter combo box user control components inside 2 tiers of container components for organization and layout purposes. Since focus causes one of these containers to be skipped when the event traverses the graph, it is not translated to the combo box component's local coordinate space. The result is the combo box thinks it was pressed at a completely different location from where the user actually pressed it. The capability for one to select any element from the list is down to coincidence that the skipped container mostly applied a small y axis translation. Most UI windows work fine probably because they do not contain nested containers.

Please check r8279 or newer when it hits nightly to confirm if this is fixed. It took 3 hours of sweat and blood...

Ters

It might have fixed http://forum.simutrans.com/index.php?topic=17263.0 as well.

My scrolling problems are apparently something else.

Yona-TYT

@DrSuperGood

It works well now.
Thank you very much, we appreciate your work very much.  ;D

Ters

I think the scrolling problem is because scrollbars do not consume events, if I understand the purpose of the return value correctly. Scrolled lists therefore keep processing drag events after first having forwarded it to the scrollbar, which includes passing it to the scrollbar a second time. change_drag_start is therefore called twice, which accumulates since it uses relative coordinates. The next event therefore thinks the mouse was further up or down previously than it really was.

DrSuperGood

If there is a problem with scroll bars not working properly please explain in detail how to reproduce this incorrect behaviour and I will look into it. However that would be better off in another bug report topic.

This one can probably be archived as solved now.

Ters

I haven't had much luck with getting attention to my bug reports recently, so once there is some attention, I will stick to it. The problem should be easily reproducible by dragging the box in any scroll bar at a steady speed.