-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Decouple the Clipboard API from fyne.Window #5121
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work. I changed the base branch to develop and that made the changes look a lot more sensible. Just added a small comment about that we perhaps should consider changing a function signature (if you agree with me there) :)
@@ -237,7 +237,7 @@ func (w *window) ShowAndRun() { | |||
|
|||
// Clipboard returns the system clipboard | |||
func (w *window) Clipboard() fyne.Clipboard { | |||
return &clipboard{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than allocating a new clipboard, should we just return the singleton instance from the app here?
@pierrec Please don't force push your changes very time. Descriptive commits with are lot better as we more easily can see what has changed and GitHub also has a tendency to sometimes lose track of old review comments. We'll squash on merge if needed. |
OK, so sorry, will just push next time. |
Question while working through the CI failures (a lot of them due to my lack of knowledge of the Fyne codebase and all the build flags!): |
I think there may have been a confusion about word usage here - so I want to ensure we are on the same page.
I think that @dweymouth was suggesting that the clipboard exist inside the app instance instead of inside the window where it was before. That is neither a true singleton, but exists only once per application. It will be much more efficient than the current implementation which seems to allocate a new clipboard for every situation where it may be used. |
I'm really not sure that it is a correct assumption. All of our clipboard structs are zero size as I can remember and don't actually contain any information so allocating extra size for the interface is unnecessary? We can probably just avoid returning a pointer to the struct and help it not allocate that way. I don't think it is worth making the app struct larger just for an arbitrary optimisation that we don't if it is worth it or not. Getting the clipboard is likely not a hot path in any application and if anyone cares, they can just save it to a variable themselves and be happy there. |
Sorry for the long turnaround time for me reviewing this. I've had quite a busy first weeks with the first weeks of my masters program. I'll try to have a look one of the coming days. |
Thank you for the update, there is no rush :). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the very long wait. Just one minor change needed and we're golden :)
internal/driver/mobile/driver.go
Outdated
@@ -100,6 +100,10 @@ func (d *driver) currentWindow() *window { | |||
return last | |||
} | |||
|
|||
func (d *driver) Clipboard() fyne.Clipboard { | |||
return &mobileClipboard{} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should return a value and not a pointer for consistency? Maybe even use the NewClipboard()
function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one slipped through. Will do.
The static analysis test failure seemed a bit strange. Kicked it to see if it is temporary. |
I had a look but I dont even have that statement on line 406 of the file; grepping doesnt return any instance of it either. Ad running it locally returns errors but not that one:
|
Hmm, interesting. I've never really seen any flukes before there; Staticcheck is about a solid as it gets in static analysis tools for Go. I'll have a look locally when I get back after a short weekend-holiday here and see what the problem can be :) |
Enjoy your break! |
Perhaps there was a merge and an out-of-order run. kicked it to try again. |
Same error strangely enough. I've opened #5175 for now to hopefully get the ball rolling again :) |
Description:
This PR implements the changes for #4418 by:
Fixes #4418
Checklist:
I dont see any automated tests for this but maybe I missed them. I did test manually and ctrl-c, ctrl-v and ctrl-x work as expected on the desktop.
I get quite a few errors on my system, some related to the locale (labels are emitted in French while tests expect English), others to something else which I dont know about.
They all seem unrelated to this change though.
Where applicable:
(no new module imported)