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

Choose one style of interacting with GTK+ widget instance attributes and refactor code accordingly #190

Open
elbenfreund opened this issue Jun 30, 2017 · 2 comments

Comments

@elbenfreund
Copy link
Collaborator

GTK+ allows for various ways to interact with instance attributes. We should pick one for consistency and refactor the codebase accordingly. This should also be added to the docs and styleguide.

The GTK+ project does not seem to have a recomendation about which style to use.
The following is from #gnome-hackers @ freenode (2017-06-30)

(14:41:29) elbenfreund: there :) I am a bit unsure about current GTK+ best practices interacting with widget instance attributes. I know about *.props.ATTRIBUTE as well as the corresponding setter methods (see also https://stackoverflow.com/questions/15180320/editing-gtkwidget-attributes-properties)
(14:41:35) muelli hat den Raum verlassen (quit: Ping timeout: 182 seconds).
(14:42:32) elbenfreund: what I am not clear about is what is the recommended thing to use when both are present.
(14:42:48) ebassi: elbenfreund: Whichever makes more sense in the code base you're working on
(14:43:17) ebassi: props.foo will call g_object_set_property(), which will likely cally set_foo()
(14:43:42) ebassi: Which one you use is entirely up to your taste
(14:43:53) elbenfreund: my usecase is a fresh codebase that has the luxury of trying to establish best practices from the get go :)
(14:44:13) ebassi: Then you get to pick one :-)

@elbenfreund
Copy link
Collaborator Author

My personal preference would be to use the WIDGET.props.ATTRIBUTE interface as the most pythonic way to do this.

@jtojnar
Copy link
Member

jtojnar commented Jun 30, 2017

Sounds good. Maybe it could be also enforced automatically by pylint custom checkers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants