RFC: Software Driver #4811
RFC: Software Driver #4811
Conversation
app/app_software.go
Outdated
|
|
||
| // 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 { |
There was a problem hiding this comment.
Won't the painter always be the one we have in the software package?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
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. |
…move stuff around
chabad360
force-pushed
the
feature/software
branch
from
2c1642f
to
ae76493
Compare
chabad360
force-pushed
the
feature/software
branch
from
318f1c3
to
235b378
Compare
| @@ -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) | |||
|
|
|||
There was a problem hiding this comment.
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...
|
Cool and good work there, friend. Keep it up :) |
|
Sorry I did not get back to this sooner. 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. |
Np.
Yea, fair, but I'm curious if you can give me any particular reasons why. I wonder if maybe there's a happy middle?
I see that.
Yea, I would certainly need to.
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? |
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 thetestDriverand some choice bits from themobileDriver(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:
Where applicable: