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

RFC: Software Driver #4811

Draft
wants to merge 19 commits into
base: develop
Choose a base branch
from
Draft

Conversation

chabad360
Copy link
Contributor

Description:

This POC adds a new Driver that allows one to include their own event source and framebuffer (through an image.Image). It's based almost entirely on a combination of the testDriver and some choice bits from the mobileDriver (mainly the basic event loop and touch handling).

This is an incredibly rough draft, I'm putting it up so that it can be discussed. Moreover, the actual API surface and basic design hasn't really been discussed yet, so this couldn't be merged either way. But most importantly, it does work, which is a good start.

Checklist:

  • Tests included.
  • Lint and formatter run with no errors.
  • Tests all pass.

Where applicable:

  • Public APIs match existing style and have Since: line.
  • Any breaking changes have a deprecation path or have been discussed.

app/app_software.go Outdated Show resolved Hide resolved

// NewWithSoftwareDriver returns a new app instance using the Software (custom) driver.
// The ID string should be globally unique to this app.
func NewWithSoftwareDriver(id string, painter func(image.Image), events chan any) fyne.App {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Won't the painter always be the one we have in the software package?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH I didn't really look at the logic for how that worked, but I needed a way to add some extra params and wasn't sure a good way to do that with the existing interfaces.

Copy link
Member

@andydotxyz andydotxyz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some good work here - but I would hesitate from pulling so much internal API code into a public driver package.
The initial entry point should be all that is needed to change I would have thought - provide an event source and wire in the internal software painter by default?

@chabad360
Copy link
Contributor Author

chabad360 commented May 2, 2024

but I would hesitate from pulling so much internal API code into a public driver package.

Yea, you're right about that. It can pretty easily moved into an internal package, I just didn't put it there. I'll move things around once the code is in a more complete state.

Also, this is pretty much the exact code from the test driver (for the most part) so I'll probably have it replace the test painter once it's all said and done.

@chabad360 chabad360 changed the title Software Driver POC RFC: Software Driver May 9, 2024
@@ -90,7 +91,7 @@ func TestFormDialog_Hints(t *testing.T) {
test.NewApp()
defer test.NewApp()
test.ApplyTheme(t, internalTest.LightTheme(theme.DefaultTheme()))
w := test.NewWindow(nil)
w := software.NewWindow(nil)
w.SetFullScreen(true)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this test is broken and I have no clue how or why. pretty much every other test is fine, and this one the failure is visually identical. So I've no clue what's going wrong here...

@lostdusty
Copy link
Contributor

Cool and good work there, friend. Keep it up :)

@andydotxyz
Copy link
Member

Sorry I did not get back to this sooner.
I see you moved lots of the test code to use the software package - but really it should have stayed with the test usage.

Also there have been lots of test code changes to use new API as we headed to 2.5, so some of the conflicts are extensive.

I would be tempted to check out a new branch and cherry pick the work onto that - broadly skipping the commits that changed all the test code to use your new package.

I hope that helps.

@chabad360
Copy link
Contributor Author

chabad360 commented Jun 23, 2024

Sorry I did not get back to this sooner.

Np.

I see you moved lots of the test code to use the software package - but really it should have stayed with the test usage.

Yea, fair, but I'm curious if you can give me any particular reasons why. I wonder if maybe there's a happy middle?

Also there have been lots of test code changes to use new API as we headed to 2.5, so some of the conflicts are extensive.

I see that.

I would be tempted to check out a new branch and cherry pick the work onto that

Yea, I would certainly need to.

broadly skipping the commits that changed all the test code to use your new package.

So that's the question. A lot of the code stays the same, but some of it changes (like anything to do with caching, and the stuff needed to be an actual driver). And pulling that code across package boundaries will result in circular deps I think (iirc I had a few already). How would you want me to handle that?

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.

3 participants