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

Decouple the Clipboard API from fyne.Window #5121

Open
wants to merge 10 commits into
base: develop
Choose a base branch
from

Conversation

pierrec
Copy link

@pierrec pierrec commented Sep 8, 2024

Description:

This PR implements the changes for #4418 by:

  • updating the fyne.App, fyne.Driver and fyne.Window interfaces
  • migrating tests and cmd programs using the clipboard to the new interface

Fixes #4418

Checklist:

  • Tests included.
    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.
  • Lint and formatter run with no errors.
  • Tests all pass.
    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:

  • Public APIs match existing style and have Since: line.
  • Any breaking changes have a deprecation path or have been discussed.
  • Check for binary size increases when importing new modules.
    (no new module imported)

@Jacalz Jacalz changed the base branch from master to develop September 8, 2024 10:34
Copy link
Member

@Jacalz Jacalz left a 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) :)

cmd/fyne_demo/main.go Outdated Show resolved Hide resolved
driver.go Outdated Show resolved Hide resolved
@@ -237,7 +237,7 @@ func (w *window) ShowAndRun() {

// Clipboard returns the system clipboard
func (w *window) Clipboard() fyne.Clipboard {
return &clipboard{}
Copy link
Contributor

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?

@dweymouth dweymouth changed the title Issue4418 Decouple the Clipboard API from fyne.Window Sep 9, 2024
@Jacalz
Copy link
Member

Jacalz commented Sep 9, 2024

@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.

@pierrec
Copy link
Author

pierrec commented Sep 9, 2024

@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.

@pierrec
Copy link
Author

pierrec commented Sep 9, 2024

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!):
what to do with the TestWindow_Clipboard and TestWindow_ClipboardCopy_DisabledEntry tests in internal/driver/glfw/window_test.go? Should they be moved to app/app_test.go?

internal/driver/mobile/driver.go Outdated Show resolved Hide resolved
internal/driver/glfw/driver.go Outdated Show resolved Hide resolved
app/app_test.go Outdated Show resolved Hide resolved
@andydotxyz
Copy link
Member

I think there may have been a confusion about word usage here - so I want to ensure we are on the same page.

Rather than allocating a new clipboard, should we just return the singleton instance from the app here?

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.

@Jacalz
Copy link
Member

Jacalz commented Sep 13, 2024

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.

@coveralls
Copy link

Coverage Status

coverage: 66.037% (-0.02%) from 66.058%
when pulling a26d502 on pierrec:issue4418
into 6ea393e on fyne-io:develop.

@Jacalz
Copy link
Member

Jacalz commented Sep 16, 2024

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.

@pierrec
Copy link
Author

pierrec commented Sep 17, 2024

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 :).

Copy link
Member

@Jacalz Jacalz left a 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 :)

@@ -100,6 +100,10 @@ func (d *driver) currentWindow() *window {
return last
}

func (d *driver) Clipboard() fyne.Clipboard {
return &mobileClipboard{}
Copy link
Member

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?

Copy link
Author

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.

@Jacalz
Copy link
Member

Jacalz commented Sep 25, 2024

The static analysis test failure seemed a bit strange. Kicked it to see if it is temporary.

@pierrec
Copy link
Author

pierrec commented Sep 25, 2024

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:

app/icon_cache_file.go:11:5: var once is unused (U1000)
app/icon_cache_file.go:13:19: func (*fyneApp).cachedIconPath is unused (U1000)
app/icon_cache_file.go:30:6: func rootCacheDir is unused (U1000)
app/icon_cache_file.go:35:19: func (*fyneApp).saveIconToCache is unused (U1000)
cmd/fyne/internal/mobile/binres/binres_test.go:249:10: printf-style function with dynamic format string and no further arguments should use print-style function instead (SA1006)
internal/driver/glfw/driver_desktop.go:25:7: const desktopDefaultDoubleTapDelay is unused (U1000)
internal/driver/mobile/app/app.go:164:15: func (*app).registerGLViewportFilter is unused (U1000)
widget/check_group.go:185:5: should omit nil check; len() for []*fyne.io/fyne/v2/widget.Check is defined as zero (S1009)
widget/list.go:172:5: should omit nil check; len() for map[fyne.io/fyne/v2/widget.ListItemID]float32 is defined as zero (S1009)
widget/list.go:371:5: should omit nil check; len() for map[fyne.io/fyne/v2/widget.ListItemID]float32 is defined as zero (S1009)
widget/radio_group.go:159:5: should omit nil check; len() for []fyne.io/fyne/v2.CanvasObject is defined as zero (S1009)

@Jacalz
Copy link
Member

Jacalz commented Sep 28, 2024

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 :)

@pierrec
Copy link
Author

pierrec commented Sep 28, 2024

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!

@andydotxyz
Copy link
Member

Perhaps there was a merge and an out-of-order run. kicked it to try again.

@Jacalz
Copy link
Member

Jacalz commented Sep 30, 2024

Same error strangely enough. I've opened #5175 for now to hopefully get the ball rolling again :)

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

Successfully merging this pull request may close these issues.

Decouple clipboard from fyne.Window
5 participants