Fix:gui/internal:Handling resize/rotation

[lains]

This change allows dynamically resizing windows using the internal GUI.
Initially, I guess this GUI was targeted for embedded touchscreen devices, but it is also used for Android (probably until the Qt5 GUI is available).
The issue with the internal GUI is that it does not really handle resizing when navigating inside menus and submenus, it merely moves back to the main menu each time there is a resize (and rotation on Android implies resize which is annoying).
Issue #433 has been open to track this.
This PR aims to solve this resize problem, allowing to continue wherever the user is (inside the menus/submenus) in the menu after a resize/rotation.

[lains]

Resize/rotate is now working on HTML menus and on widget-constructed menus as well (these are handled differently).
It still needs work on virtual keyboard resizing (and this is maybe only due to the fact tables resizing is not implemented yet).

[hoehnp]

Will it also be possible to get a signal about the rotation for use in changes of the osd layouts?

[lains]

@hoehnp: yes, we should be able to get a generic notification about resize (thus also handling rotation for fixed-size displays).
From the test I made, map view resize can also be catched by gui_internal_resize() but I think there should be a better place (not related to internal GUI code).
Do you have another example of a signal that is send to OSD items from other events?
How do you catch such signals in OSD items?

[hoehnp]

I think gui_internal_resize is a bit ambiguous. So far to my knowledge it was not possible to catch it and use it for rescaling of osd elements. My idea would be to do it similarly like the click event, which calls a separate function, e.g.

navit/navit/osd/core/osd_core.c

Line 943 in c094186

static void osd_odometer_click(struct osd_priv_common *opc, struct navit *nav, int pressed, int button,

. Then I guess we had to add an additional callback from osd side. Honestly, I never have gone so deeply in the details. Will figure out next week.

[lains]

Yes, definitely, if there is a hook to implement, it should be outside of internal GUI, because the way the map is displayed (and thus OSD items on top of it), is really separate from the GUI implemented in my opinion.

[lains]

I still have some work to do on handling table and box resize properly, this is impacting virtual keyboard that is currently not rescaled properly.

[lains]

I'm almost there but the code around widget packing is quite complex.
However, I am getting small deltas between an initially small rendered window resized to fullscreen, and an originally fullscreen rendered one...
Is there any internal GUI expert that could help out?

[pgrandin]

I'm not an expert, but if you share code/screenshots maybe we can figure it out.

[lains]

I had to actually write some code to debug the internal GUI boxes (highlight them in red).
If this is of interest, I can share this very small patch to the code or add a preprocessor define to make this accessible to others.
Once I highlight boxes using a red border, and if I initially display the keyboard, then maximize the window, the last (bottom) line of the virtual keyboard was cut as per the screenshot below:

I wrote "was" because, in the meantime, I have made progress on this, and it now seems solved by my last commit 91e6a05 (now resizing while displaying the virtual keyboard seems to work).

However, I think handling resize properly would actually need to be developped on a per-GUI menu basis. And it seems to me that I could extend the issue with virtual keyboard to all cases where a box is not aligned to the top left (which was the case for the virtual keyboard that is aligned with the bottom of the window).

Fortunately, this may be caught properly by the resize handler I wrote (for box widgets), because this handler actually recursively repacks all children of a widget.
I have written no handler for tables though, so the result is uncertain.
... and to be honest, I have no good control about the side effects of the code I have added so testers are welcome...

[lains]

In any case, it seems that the code in this PR is actually working as expected and solves the issue initially targetted (resize/rotation).
I will give it a try on Android to check how well it performs...
Please let me know what you think about this fix.

[hoehnp]

nice work. I think for OSD designers the code with the red lines is for sure a useful patch.

[lains]

I'll submit the debugging patch (red lines) in a separate request but this is only active on menus (drawn by the internal GUI), not for OSD items on the map.

[lains]

I have tested on Android, and it is actually fixing the rotation also (you don't return to the main menu, or loose anything that you might start typing).
There is one bug that I have identified: if you start in a menu with a given size or orientation, then enter a submenu, then change size or orientation, and finally go back to the previous menu, it is not drawn properly (it has not completely applied the orientation change itself).
I know where it comes from, I will submit a patch when I have some spare time.

[pgrandin]

Nice work @lains ! This rotation issue was quite annoying. I also agree with @hoehnp the patch to highlight items would definitely be useful.

[lains]

@hoehnp and @pgrandin, no problem, I will submit another PR to allow for visually debugging the internal GUI.

[lains]

I still need to do some testing on table widget resizing and this PR should then be ready.
Now going back menus is working even after a rotation (has been fixed in 081fa13)

[lains]

Development is finsihed for this PR. Please test and tell me if there are corner cases of menus in the internal GUI.
Virtual keyboard, top menu bar and standard HTML-like menus should resize/rotate without issues.
The risky parts are the content zone of other menus, for example layout lists, GPS coords input.
Testing can be done directly under Linux by using the internal GUI and resizing the window while on a menu.

I also agree with @hoehnp the patch to highlight items would definitely be useful.

I have submitted the visual debugging in PR #715

[lains]

This patch should handle the issue covered by trac ticket 1149:
http://trac.navit-project.org/ticket/1149

[metalstrolch]

Is this ready to be merged? Would be cool if so, because this fixes something really annoying.

[lains]

@metalstrolch, tes, it should be ready, I have tested this on Android and Linux builds.
You can already build this code and test it either on the desktop version (resizing the window will show you the result), or by installing it on android which uses the internal GUI. You should get rotation and resize working even while typing some search text for countries, towns or streets.

Please let me know if this works correctly for you.

[metalstrolch]

It's OK for me, tested this under sailfish/et5 on desktop as well. Unfortunately it triggers an old bug in graphics_qt5 that sometimes does not redraw the screen after rotation. But that's clearly NOT an issue of this task. So I think we can merge this.

[metalstrolch]

Thank you, good work.

[metalstrolch]

Unfortunately I cannot close the trac ticket, as I don't know how and don't have credentials.