Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Window Resize event #224

Closed
pbarnum opened this issue Apr 12, 2019 · 18 comments
Closed

Window Resize event #224

pbarnum opened this issue Apr 12, 2019 · 18 comments

Comments

@pbarnum
Copy link
Contributor

pbarnum commented Apr 12, 2019

Would be nice to be able to capture a window's resize event. This would be useful for saving the size to a file so the next time the app is opened it can begin with that size.

@andydotxyz
Copy link
Member

Hmm. I wonder if perhaps the toolkit should do that for you? It’s a very specific requirement to expose another event.

If you need to do it in the meantime you could add a close handler and get the size of the canvas inside the window - that should work as you hoped?

@pbarnum
Copy link
Contributor Author

pbarnum commented Apr 12, 2019

Yeah that should handle my specific use case, thanks! I'll leave it to you to keep/close this issue.

@andydotxyz
Copy link
Member

Thanks. I think I will close this for now. If people want this feature we could open a new ticket for remembering window size when a window/ application is closed.

@mgoulish
Copy link

mgoulish commented Nov 21, 2019

I need a window resize event because my windows are viewports into a spatial data set. When the user resizes the window I need to notice that and update my application's idea of what should now be displayed in that window.

~ edit ~

No, never mind.
I already have this, effectively, because upon resize my NewRaster fn is called with the new window w and h.

@andydotxyz
Copy link
Member

I'm glad you figured it out @mgoulish - you are quite right the canvas objects and widgets should have all the info they need.
We are designing this so that each element is self-contained and callbacks on windows typically breaks this encapsulation.

@adrien3d
Copy link

Hi @andydotxyz, is it now possible to have a window resize event?

@andydotxyz
Copy link
Member

Not directly, but mostly the toolkit is dealing with the contents of a window. So container layouts and widgets all get appropriate resize events when their available space changes. This should lead to better encapsulation, but perhaps it misses a use-case?

@johnnewcombe
Copy link

I am building a Viewdata terminal which makes use of font based block graphics that need to sit closely next to each other. I have been using a text canvas sat on a rectangle within a grid (padding 0). When the window resizes the rectangle and text canvas resize as expected, however, the text size doesn't change and I end up with gaps between the block graphics. Being able to hook up to a resize event would help me here. Or perhaps I am missing something.

@andydotxyz
Copy link
Member

Your container will be resized to the available space - you can respond to this without needing new window events. Widgets should always make use of the space allocated and not need to hook into their containing window. This makes widgets more reusable.

@johnnewcombe
Copy link

This would be fine if the text did actually resize but it doesn't. The text canvas obviously does but not the text itself. I guess this is the behaviour you might want for a normal text display. However, for a system that builds graphics using a special characterset such as a Viewdata system, it means I have to either stick to a fixed size window or perform a manual changes when the window is resized.

The app in question is here https://glasstty.com/wp-content/uploads/2021/12/telstar-client-dist.zip should it be of any assistance.

@johnnewcombe
Copy link

What I should have made clear is that I am having to use a separate canvas for each text position with a rectangle behind it so that I can implement foreground and background colour and other attributes such as flash and hide etc.

@andydotxyz
Copy link
Member

If you are making custom text handling then you can expand as the space available increases.
You could look at the "bugs" example to see how we do it on those buttons.
https://github.com/fyne-io/examples/blob/develop/bugs/button.go

None of what you list above is need for a window resize event ;).

@johnnewcombe
Copy link

Thanks for the pointer to the example, I will take some time to study it, I am a newbie to fyne (as you will have guessed :).

@johnnewcombe
Copy link

One last question, the bugs example uses a grid layout which, if I understand correctly, uses the padding value from the theme. In order to get contiguous cells I need to set padding to 0. This wrecks all of my common dialogues etc. Am I missing something?

@andydotxyz
Copy link
Member

All the layouts use the standard theme padding - as do widgets etc. setting this to 0 in the theme will have significant ramifications. You’re probably looking for a custom layout that has no padding (it’s pretty easy - tutorial at https://developer.fyne.io/extend/custom-layout)

for more questions please one of our support forums instead of this issue tracker.

@blaize
Copy link
Contributor

blaize commented Aug 7, 2022

Hello, I'm writing an accounting app and I store window width and height in preferences on SetCloseIntercept() callback.
It work well but I also want to store if the window was in fullscreen.
Everytime I call window.FullScreen() in closeIntercept callback it return false but it get the width and height values of the fullscreen.
It result of a big window on startup that is not in fullscreen and go a bit outside the screen.
Why I can't get the correct FullScreen() value ?

@andydotxyz
Copy link
Member

This issue has been closed, for support requests please open a topic on the discussions tab or on one of our support channels https://fyne.io/support/

@andydotxyz
Copy link
Member

Why I can't get the correct FullScreen() value ?

If you feel the function is not working please open a bug.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants