A bitmask type for the parametertree, e.g. enum.IntFlag#1120
A bitmask type for the parametertree, e.g. enum.IntFlag#1120erik-mansson wants to merge 1 commit intopyqtgraph:developfrom
Conversation
An example of usage is provided in examples/parametertree_bitmask.py.
|
Hello, thank you for the PR! I apologize it's taken so long for someone to respond. I like this PR, but we're going to have to put this on ice a bit. The version we're about to release (0.11) still supports python2, and some ancient versions of python3, so this code won't work for anything < 3.6. Good news here is that once we release 0.11, pyqtgraph will be adopting NEP-29 which establishes a timeline for supported versions of libraries relative to the date of release. In practical purposes that means the next version of pyqtgraph will be python 3.6+ / numpy 1.15+ (or potentially python 3.7+ depending on when we release the next next version). I'd like to leave this PR open, and we'll review it after we get 0.11 out the door. Thanks again! |
|
Hi @erik-mansson, I believe you should now be able to utilize the |
From Python 3.6 there is a nice class called enum.IntFlag https://docs.python.org/3/library/enum.html#enum.IntFlag for managing bitmasks. I wanted to use it in a parametertree (which is a great utility, by the way!) and made a BitmaskParameter that shows a boolean sub-Parameter (i.e. checkbox in the GUI tree) for each bit of the bitmask. Examples of usage are provided in examples/parametertree_bitmask.py.
Although I didn't show such an example, the BitmaskParameter can be used also for plain integer values without IntFlag, e.g. defined with
'value': 1|2, 'values': {'x': 1, 'y': 2, 'z': 4}. If the import-statement and isinstance-check would be changed to something more dynamic or version-dependent it should thus be possible to make it usable on older Python versions too.I modified
parametertree.__init__to load this module and get the 'bitmask' type registered, but maybe you want to put the code in the big file with all simple parameters or maybe not automatically register it at all? I didn't find test cases covering other parameter types so I didn't bother learning how to add something for this. Some of my usage example is duplicated in the docstring for the class, which maybe is redundant?This is my first pull request ever, so let me know if I should have done something differently ;) I did get warnings about lines longer than 79 characters when running the
python setup.py style. But since also existing code goes beyond that in several cases (and thinking that for indented python code within docstrings, 79 is a too low limit considering today's widescreens), I didn't correct all of them. Except for the example, the code should be within 100 characters now.