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

SearchEntry does not appear to implement Editable interface correctly #115

Closed
christian-schulze opened this issue Oct 18, 2023 · 3 comments

Comments

@christian-schulze
Copy link
Contributor

christian-schulze commented Oct 18, 2023

searchBar := gtk.NewSearchBar()
searchBar.SetVAlign(gtk.AlignStart)
searchBar.SetKeyCaptureWidget(window)
box.Append(searchBar)

searchEntry := gtk.NewSearchEntry()
searchEntry.SetHExpand(true)
searchBar.ConnectEntry(searchEntry)
box.Append(searchEntry)

On building I get the following error:

./main.go:41:25: cannot use searchEntry (variable of type *gtk.SearchEntry) as gtk.Editabler value in argument to searchBar.ConnectEntry: *gtk.SearchEntry does not implement gtk.Editabler (*gtk.SearchEntry.Editable is a field, not a method)

SearchEntry has an Editable field struct which has an Editable function, but that Editable function should exist on SearchEntry instead.

This looks like a name collision issue, Editable struct vs Editable function attached to Editable struct.

I'd love to have a go at fixing this myself but so far have been unable to figure out where to override this. I believe the fix should be to rename the Editable field on SearchEntry to something else.

Is there an example in the generation code where this kind of thing has been done before?

@diamondburned
Copy link
Owner

Is there an example in the generation code where this kind of thing has been done before?

Yes! gendata.go specifically contains a lot of the code to manually fix quirky errors like these.

Ideally, I would love to have the generator itself figure out rather than manually going through functions over time, but overriding it manually is probably the easiest way to do it.

@christian-schulze
Copy link
Contributor Author

Yes! gendata.go specifically contains a lot of the code to manually fix quirky errors like these.

Ideally, I would love to have the generator itself figure out rather than manually going through functions over time, but overriding it manually is probably the easiest way to do it.

Thanks for the tip @diamondburned, will give this a shot this evening.

@christian-schulze
Copy link
Contributor Author

#116 addresses this issue

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

2 participants