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

Widgets not usable as Widgetter: FontButton and MenuButton #31

Closed
sqp opened this issue Aug 21, 2021 · 3 comments
Closed

Widgets not usable as Widgetter: FontButton and MenuButton #31

sqp opened this issue Aug 21, 2021 · 3 comments
Labels
blocking Issues awaiting replies question Further information is requested

Comments

@sqp
Copy link

sqp commented Aug 21, 2021

Hey, I'm working on a gallery example for the package and (so far only) found 2 widgets that weren't usable as Widgetter, so they can't be inserted into a GUI.
And a big "gg wp" for that lib, it almost feels like an old used one.

gtk.FontButton.FontMap is ambiguous
cannot use btn (type *gtk.FontButton) as type gtk.Widgetter in argument to toBox:
*gtk.FontButton does not implement gtk.Widgetter (missing FontMap method)

cannot use btn (type *gtk.MenuButton) as type gtk.Widgetter in argument to toBox:
*gtk.MenuButton does not implement gtk.Widgetter (wrong type for Direction method)
have Direction() gtk.ArrowType
want Direction() gtk.TextDirection

gtk4-gallery

@sqp sqp changed the title Widgets not usable as Widgetter Widgets not usable as Widgetter: FontButton and MenuButton Aug 21, 2021
@diamondburned
Copy link
Owner

For some widgets, you might need to explicitly reference the field, such as with
adw.Avatar:

box.Append(&adw.Widget)

There's not really a way around this other than to autogenerate more fields into
the class struct. In fact, this is already done with classes that potentially
yield ambiguous selectors for glib.Objector:

type Widget struct {
	externglib.InitiallyUnowned

	Accessible
	Buildable
	ConstraintTarget
	*externglib.Object // extra field
}

Having to do this for all possible interfaces is a lot of work and potentially a
lot of unnecessary overhead, though, so I've decided not to go all the way.

gopls should suggest you the right selector when you try to plug the widget
in.

@diamondburned diamondburned added blocking Issues awaiting replies question Further information is requested labels Aug 24, 2021
@sqp
Copy link
Author

sqp commented Aug 28, 2021

For the gtk.MenuButton the name conflict could be resolved by renaming :

  • Direction -> MenuDirection
  • SetDirection -> SetMenuDirection
    (or Arrow instead of Menu as the argument is an ArrowType but I think a MenuDirection method is fine for a MenuButton)

It would be easier to have the widget behave like the others and be usable directly as Widgetter.

Their documentation:

Direction returns the direction the popup will be pointing at when popped up.

SetDirection sets the direction in which the popup will be popped up.
If the button is automatically populated with an arrow icon, its direction will be changed to match.
If the does not fit in the available space in the given direction, GTK will its best to keep it inside the screen and fully visible.
If you pass GTK_ARROW_NONE for a direction, the popup will behave as if you passed GTK_ARROW_DOWN (although you won’t see any arrows).

@diamondburned
Copy link
Owner

Created issue #36 to trackthe
MenuButton changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocking Issues awaiting replies question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants