In a wxPython application I'm developing I need a lot of input fields for numbers (integers and floats), so I tried using wx.lib.masked.NumCtrl, but my users now tell me that it's quite uncomfortable to use (and I agree with them).
Is there an alternative widget implementation I can use, or should I just roll my own, starting from a bare TextCtrl?
(wxPython 2.8.9.1)
Edit
For completeness, here's an example of "uncomfortableness":
given a NumCtrl with selectOnEntry and fractionWidth > 0, when you switch to the decimal part of the field, it gets correctly selected, but pressing numbers doesn't do anything, you have to delete the contents of the field first.
In the usual wxPython distribution there's IntCtrl, and then a few other GUI controls like Slider, Spin, FloatSpin, and KnobCtrl.
There's also the Enthought Traits approach, and the GUI part of this seems to have put a fair amount of focus on numerical entry and display, such as logarithmic sliders, float array editors, etc. Looking at their designs might give some inspiration even if you don't take this path.
Also, it's not really clear why you don't like the masked NumCtrl, but it's very easy to write your own, so if there's some specific thing you want, that's probably the way to go.
Related
I am writing a kicad plugin, and I need to create a GUI for this plugin. Because kicad uses wxpython, that is what I am using.
I have already figured out that placing my ui items using the layout sizers just isn't gonna give me the control I need to create the window I want. I know I can set the position of elements, and have been using that to create the ui I need.
The problem however, is that my window gets bigger than what would be reasonable (in some situations). Therefore I want to make it scrollable.
I have been playing around with wxformbuilder, and I found the wxScrolledWindow. That got me this far:
This is roughly what I want, except, when you want to place stuff within the scrolledWindow, you have to place one of the "sizers" in it (as far as I can tell at least), in which you place your buttons. The problem with that is, that, to my knowledge, setting the position of buttons in any of the sizers just has no effect at all.
So, my question is: how do I achieve this effect? and, is this even possible?
edit:
As an example of what I am trying to put within the scrolledwindow, this is a rough version of the ui I want to create (and want to be scrollable). (I want to eventually have, probably an icon button above each of the checkbox columns to indicate what they are for).
The final result would need to look something like this (the white squares being small images / buttons, also, in reality being not on the window bar,but in its own not scrolling section):
An example of something I wasn't able to achieve using sizers is, getting those checkboxes so close together, without making them appear off center. Different widgets seem to have different sizes, and checkboxes without border are especially small, so they end up appearing off center, example:
Also, those images above each column of checkboxes, which don't scroll, need to line up with the X coordinates of those scrolling checkboxes, which also seems very non trivial. Though also really hard to get right if I could give everything exact coords, so I might need to give up on that specific idea of making those not scrollable.
In qt-designer, is it possible to create a list of values(float)?So that I can choose from there any and, let's say, substituted in the formula?
doubleSpinBpx values work fine:
I can enter from manually using:
razmerbloka = self.doubleSpinBox_6.value()
but I would like to choose from a list of numbers.
And in qt-designer, I found only a list of strings (Combo Box). That's not what I'd want
Values such as numbers are always rendered as a text. How you interact with this text depends on how the application's logic interprets the string and the actions it offers you to view, copy etc. it.
In your case I would go for a combo box if your values are not following a specific order (for example an increment step of a specific magnitude). A spin box requires a specific step and a range of values. Any other behaviour would only create confusion since this behaviour of this UI component in particular has been out there for a long time and users expect a specific way of interaction with it. This doesn't mean it's not possible to do it. It just requires creating a highly custom version of a spin box.
A combo box on the other hand offers a neat representation of all the values that a user can choose from. You can mix number formats, standard strings, dates etc. (not recommended since keeping things consistent is something any UI should strive for).
For Qt 5.6 users report this way of adding items. Qt 5.5 and earlier apparently don't support this feature through the designer (cannot confirm, I have Qt 5.9, where the designer works the same as described for 5.6).
If your data (in this case floating point numbers) comes from some external source (e.g. CSV file), I recommend filling the combo box's list of values in your code by using addItem().
I'm writing a graphical interface for with Traits UI in python, and I wonder if there is a simple way to make a RangeEditor behave logarithmically, i.e. to make it's "internal" scale logarithmic, but still set the actual value of the trait. I can get closer by using the editor for an auxiliary trait v, and use 10**v as the real value in the calculations, but this has the inconvenience that the text box shows the auxiliary trait and not the actual one.
If this is not possible out of the box and someone can help me designing a custom editor, I'd appreciate.
EDIT: There is actually an undocumented mode='logslider' option for RangeEditor, it seems to do what I need.
I'm interested in using python to make diagrams representing the size of values based on the size of squares (and optionally their colour). Basically I'm looking for a way to make overviews of a bunch of values like the good old program windirstat does with hard-drive usage (it basically makes a big square representing your harddrive and then smaller squares making up the area inside of it representing different programs, the bigger the square the larger the file, colour indicates the type of file). I'm fairly familiar with matplotlib, and I don't think it's possible to do something like this with it. Is there any other python package that would help? Any suggestions for something more low level if it's not? I guess I could do it manually if I could find a way to draw the boxes programatically (I don't really care about the format, but the option to export SVG as well as PNG would be nice).
Ultimately, it would be nice to have it be interactive like windirstat is, where if you were to hover over a particular square you get more information on it, and if you clicked on it maybe you'd go in and see the makeup of that particular square. I'm only familiar with wxpython for GUI stuff, not sure if it could be used for something like this. For now I'd be happy with just outputting them though.
Thanks a lot!
Alex
Edit:
Thanks guys, both your answers helped a lot.
You're looking for Treemapping algorithms. Once implemented, you can transform the output (which should be rectangles) into plotting commands to anything that can draw layered rectangles.
Edit:
More links and information:
If you don't mind reading papers, the browser-based d3 library provides for 'squarified' treemaps (js implementation). They reference this paper by Bruls, Huizing, and van Wijk. (This is also citation 3 on the wikipedia article)
I'd search on the algorithms listed on the linked Wikipedia article. For instance, they also link to this article, which describes an algorithm for "mixed treemaps". The paper also includes some interesting portions at the end describing transformations into other-than-rectangular shapes.
Squarified certainly appears to be the most common variety around. The above links should give you enough to work towards a solution or, even, directly port the d3 implementation. However, the cost of grokking d3's model (which is something like a declarative form of jQuery) may be somewhat high. At first glance, though, the implementation appears relatively straightforward.
Squaremap does this. I haven't used it (I only know it from RunSnakeRun) and its documentation is severely lacking, but it seems to work.
Are there any best practice tips regarding when one should use pack vs. grid for their layouts?
From what I've been reading via google, the concencus seems to be that grid can handle any pack scenario but not vice-versa.
To start the conversation, it appears that one use case that favors grid vs. pack is when one wants to show/hide widgets.
Neither is intrinsically better than the other. Each have strengths and weaknesses. Learn what those are and the choice of which to use becomes obvious.
grid is considerably easier to use if you need to lay things out in a grid. pack is generally easier to use if all you need to do is put some widgets in a single row or single column. There's a whole lot of gray area in-between where neither is necessarily better than the other.
The other thing to consider is what you said in your question: if you want to show and hide widgets at run-time, grid is probably the best choice because of the grid_remove method which remembers the values of all of the configured attributes in case you want to re-add the widget.
Personally, my first choice is always to use pack because I first learned Tk back when there was no grid command. If I can't do it easily in pack, or if I'm very clearly laying things out in a grid, I'll use grid.
I always recommend grid over pack for polished applications. There are only a few edge cases where pack is easier and fits the bill (everything in one row or col). grid has better "composability" (e.g. megawidgets or gridding elements of gridded elements). The reasons to prefer grid are the extra fine-tuning options that it provides. The use of weight (which effects growing and shrinking btw), minsize and maxsize, as well as convenience features like enforcing uniform rows/columns.
A fully gridded app of any size will use (significantly) fewer frames than an equivalent packed app, and have better shrink/expand control over inner elements.
BTW, both pack and grid can show/hide sub-elements, though the syntax differs slightly between the two. Grid is just slightly better because 'remove' (rather than 'forget') will remember the grid options on the slave widget.
I personally just think grid is a lot easier to work with, so I would use that. Of course, you've probably read the one thing you should never do is try to use both at the same time in the same container. Thank you Bryan Oakley for making that distinction.