kivy: App resizing is broken in win11 with kivy 2.2, python 3.11
Software Versions
- Python: 3.11
- OS: win 11
- Kivy: 2.2
- Kivy installation method: pip
Describe the bug I have an application that allows the user to change the application size. In the application build(), I have the following:
def build(self):
...
self.root = root = AppRoo()
...
if Window:
Window.bind(on_resize=self.on_resize)
I also have the following to save the size when the user resizes the application:
def on_resize(self, instance, width, height):
"""Window resize callback."""
logger.debug(f'Saving new window size: {width=}, {height=}')
kivy.config.Config.set('graphics', 'width', width)
kivy.config.Config.set('graphics', 'height', height)
kivy.config.Config.write()
The above worked before kivy 2.2. After upgrading to kivy 2.2, the application starts with the sizes all wrong (much larger). @Cheaterman on Discord kindly pointed me to change the Windows 11 screen scale which I had set to 125%.
If I set the scale to 100% all works ok, and the application resizes correctly. If the scale is anything other than 100% the application resize is off.
Expected behavior If the user changes the application size and the application is restarted, the size should be maintained.
To Reproduce All you have to do is set the scale in your windows to other than 100%.
[INFO ] [Kivy ] v2.2.0
[INFO ] [Kivy ] Installed at "C:\Users\abed\miniconda3\envs\alant\Lib\site-packages\kivy\__init__.py"
[INFO ] [Python ] v3.11.3 | packaged by conda-forge | (main, Apr 6 2023, 08:50:54) [MSC v.1934 64 bit (AMD64)]
[INFO ] [Python ] Interpreter at "C:\Users\abed\miniconda3\envs\alant\python.exe"
[INFO ] [Logger ] Purge log fired. Processing...
[INFO ] [Logger ] Purge finished!
[INFO ] [Factory ] 190 symbols loaded
[INFO ] [Image ] Providers: img_tex, img_dds, img_sdl2, img_pil (img_ffpyplayer ignored)
[INFO ] [Window ] Provider: sdl2
[INFO ] [GL ] Using the "OpenGL" graphics system
[INFO ] [GL ] GLEW initialization succeeded
[INFO ] [GL ] Backend used <glew>
[INFO ] [GL ] OpenGL version <b'4.6.0 - Build 27.20.100.9621'>
[INFO ] [GL ] OpenGL vendor <b'Intel'>
[INFO ] [GL ] OpenGL renderer <b'Intel(R) Iris(R) Xe Graphics'>
[INFO ] [GL ] OpenGL parsed version: 4, 6
[INFO ] [GL ] Shading version <b'4.60 - Build 27.20.100.9621'>
[INFO ] [GL ] Texture max size <16384>
[INFO ] [GL ] Texture max units <32>
[INFO ] [Window ] auto add sdl2 input provider
[INFO ] [Window ] virtual keyboard not allowed, single mode, not docked
[INFO ] [Clipboard ] Provider: winctypes
[INFO ] [Text ] Provider: sdl2
[DEBUG ] Not in REPL -> leaving logger event level as is.
Additional context I have consistently used dp() and sp() throughout my code. So going back to just using pixels is not an option for me.
About this issue
- Original URL
- State: closed
- Created a year ago
- Comments: 23 (11 by maintainers)
Just my 2¢ but I personally second PR’ing your hover behavior to kivy, it’s sufficiently commonly needed IMHO and I really like that your implementation is fairly performance-minded!
I tried the hover package. Thanks, @DexerBR, good work. I hope it will be integrated into the kivy native code. I am continuing the discussion on the Discord channel.
That is a great project @pythonic64!
Do you think it could be integrated into the native kivy source code? Along with existing related behaviors like
FocusBehavior
andButtonBehavior
?There is no action required here. Closing.
Let us know if you think this is in error.
@abedhammoud Add
hover_mode='all'
toRootWidget
inbuild
method.@abedhammoud You can use hover events if you want to dispatch mouse indicator position throughout widget tree instead of binding directly on
Window.mouse_pos
and doing position scaling yourself. Widgets likeRelativeLayout
orScrollView
will transform hover events in the same way as they transform touch events so event position will be correct for those cases too.Take a look at https://github.com/pythonic64/hover for hover manager and behavior. In a few weeks I’ll add the missing docs and move the repo to kivy garden, but right now the code is working without issues.
thanks @kuzeyron
It was just a suggestion because the percentage would give you the same position/height on any kind of monitors. In the code I’m doing the translation between the client and server and they do not have the same size. So by finding out the percent you are able to be as precise as possible.
I had forgotten that I do have a older code that is easier to read:
Try this out and then you probably can add its own section in the config
with the changes above, it seems to be working now on windows and linux. Thanks @DexerBR