Comments (11)
Agree. I slowly port Remi to better practices and more PEP8 compliant as I change the code. There is much work to do, and I will accept patches for this.
from remi.
Awesome, sounds great! I'll see about possibly contributing patches in the future :).
from remi.
What setters / getters do you refer to specifically? the problem with set_onclick_listener
and friends are not that they are setters per se, but rather that it feels foreign in gui frameworks, which would use a connect or bind verb widget.connect('onclick',function)
.
Are you referring to the widget.attributes dict?
If you can provide some more examples I can advise on which I feel are a the worst offenders.
btw: this is why it is not ready for pypi yet
from remi.
I agree that the methods that register listeners should definitely stay methods -- possibly renaming them to add_listener would make sense, since set_listener feel very singular, as if it's only possible to register a single listener, i.e. overwriting possibly previously registered listeners.
As for an example where it would make sense to use properties, check out the Button.set_text method, wouldn't it be just as easy to access Button.text? Same goes for TextInput, Label, etc.
Using set_value for the ListView widget on the other hand, makes of course sense -- since you are actually setting the selected value. The name might be a bit ambiguous, but I've always been very bad at naming things well. Maybe set_selected_value or select_value? I'm not sure, I like it the way it is currently.
from remi.
Personally I think property setters in python feel too immediate and opaque to me. Most code I admire does not use them a lot. Take the case of (html) attributes and text on a widget. They are very different things in terms of implementation and of immediacy of API contract. I think having both appear as properties is misleading as it gives them an appearance of similarity. For the defining characteristic of the widget (Button text, Label text) etc I think it is fine to have that an explicit function call.
from remi.
By opaque you mean that simply setting an attribute on the object might make the API less easily understandable, because it's not immediately clear that doing so will have an effect on the widget's state (as displayed on the website)? I suppose that's possible, and nothing one couldn't change easily if you ever decide otherwise.
I admit that I don't have much experience in API design in general and I'm not sure how convenient using Python's property decorator might be in the long run, I just figured it would make sense to use them, since this would certainly be an opportunity. But I think I get what you mean when you say it makes the code more opaque: possibly more divorced from the functionality and more "magicky" than it has to be? Unless I am misunderstanding?
from remi.
Nope, you understand my point. The most common application of property getters and setters I see is to fix previously public attributes.
I am wary of using them.
from remi.
Alright, I would have to agree then.
For something completely different then, regarding the naming of identifiers: You are using underscores in some methods, e.g. set_on_focus_listener but then some of your other methods are simply named onfocus -- what's the rationale behind that? (This is just nitpicking at this point, since most of my points have been ruthlessly shut down :P). Also since these methods are just used as internal callbacks that propagate the event to the registered listener, wouldn't it make sense to prefix these with underscores to make them "private", indicating to users that these methods are usually only used internally? I don't see an immediate reason why exposing these methods to the user would make sense.
from remi.
All the things you point out are on my TODO list and I disagree with none of them.
There is a lot of public API leaking here. I will take patches fixing any of them!
from remi.
It's good to hear that I'm not only making moot points. As I said previously, I'll try to see if I can possibly contribute patches in the future as well. Thanks for your quick replies!
from remi.
Hi, I would only say this. Some methods like onfocus have to be as they comes because they are managed with event automation easly, reflecting javascript event names. Take care about that. But however there are a lot of methods and attributes having names improperly defined (because of my mistake) that have to be changed.
from remi.
Related Issues (20)
- got an unexpected keyword argument 'websocket_port HOT 1
- Blank window on standalone_app.py HOT 2
- Labels do not display the correct number of whitespace HOT 1
- [QUESTION] any example of long-polling implementation in remi? HOT 1
- Get selected text from TextInput HOT 6
- automatic scroll down in text widget (write only) HOT 9
- highlight of table cells in front end. HOT 1
- GenericDialog confirm by Enter key pressing HOT 1
- 2 bugs remain for python 3.10 HOT 1
- How to add a radiobox or radiogroup in remi? HOT 1
- How to insert custom HTML
- Javascript gets unloaded after remi reloads with "handshake complete" HOT 3
- Add a button that opens a link HOT 2
- Feature request: Allow setting button labels on GenericDialog
- Editor: export do not work correctlly HOT 1
- Termux Version?
- Offline Plotly HTML Integration HOT 1
- Editor directory conflicts with other packages
- [Question] How can I find all the local partitions when working with gui.FileSelectionDialog widget? HOT 3
- Race condition when building single instance App gui
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from remi.