What is the best way (in terms of performance) to resize a text proportionally to the size of its parent ? I want to make a undecorated window in which the text (which can span several lines) always use all the available size.
Well, I don't know if it is the best way but using scale is working fine.
You just have to listen changes to the heightProperty and widthProperty of the parents in order to compute a scale factor and apply it to the component (Here a Text or a Label). This can be done with JavaFx magic binding too :)
So, there is no need to dynamically change the Font or something like that (and I think this would be a lot more slow than scale computation).
Related
Main Question
What is the "right" way to give your widgets default sizes and make sure they contract, expand, or remain fixed if there is additional or not enough space to accommodate them?
How I Think Qt Works
After reading the Qt documentation it seems like the sizing algorithm goes something like this...the layout begins by asking its children for their ideal size via the QWidget::sizeHint method. If the layout has additional space or not enough space then it'll determine which widgets to resize based on each widget's sizing policy (QWidget::sizePolicy), minimum size (QWidget::minimumSize), and maximum size (QWidget::maximumSize).
Why isn't there a QWidget::setSizeHint method?
If my understanding is close to being accurate then it would seem all you'd have to do is set the sizeHint, sizePolicy, maximumSize, and minimumSize on each widget and everything would just work. So why isn't there a setSizeHint method?!?!??!! Sure, every time you use a widget that provides all of the functionality you need (QTableView, QComboBox, etc) you could extend it and override a single method but that sounds absolutely ridiculous.
One of the sizing issues I'm fighting with.
I've got a QMainWindow with a QDockWidget on the left hand side. The QDockWidget has a QTableView. I'd like to have the QDockWidget/QTableView take up a "reasonable" amount of space on start up and then the user can resize it however small or large they'd like.
Unfortunately, when the application starts up it gives the QDockWidget/QTableView so little space that it requires a horizontal scroll bar. The only way I've found to force it to give it a reasonable amount of width is to set the QDockWidget's minimum width but then it prevents the user from resizing it as small as they might like to.
Why isn't there a QWidget::setSizeHint method?
In my opinion it is much better for a widget to compute its preferred size based on its content (or rules) instead of allowing the coder to set a sizeHint probably hardcoded or at least prone to errors.
I almost never had to set a size on a widget, playing with the QSizePolicy was enough. And when I needed some specific constraints, playing with minimum/maximum sizes was enough. So that Qt layouts were always able to adapt the widget.
If you want to set up yourself some percentages on the sizes etc, you can play with the stretch parameter. You can also add spacers when you need empty spaces.
Extending a QWidget to override the QWidget::sizeHint method does not sound ridiculous to me, as you change the widget behaviour by changing its preferred size and that fits the polymorphism spirit of OOD.
How to properly size Qt widgets? is a vague question and depends on the use cases. Most of the time choosing the good layouts and size-policy lets you achieve very adaptative GUI. Qt Designer can help to do this right, even if the layout management is not always intuitive (you need to place your widgets first and then set them in layouts from the inner to the outer layout).
About your specific issue, it's hard to tell why your QDockWidget gets too small without knowing the details of the layout(s) you have around your two widgets in the window. Maybe it is a specific issue with QDockWidget : see related questions :
QDockWidget starting size
Qt 5.7 QDockWidget default size
Prevent QDockWidget autosizing behaviour
I want to create a flexible layout, where the User can resize Widgets, but still give a good default layout. I'm using the Qt Designer for everything.
As a minimal example I used a simple Windows with a Widget and a plainTextEdit. The later one seems to cause the problems, which is why I choose it. At first I built it without the Splitter which worked just fine. The Stretching factors are 1:1 by the way.
Now I put both widgets in a Splitter (by breaking the main layout, putting both widgets in a Splitter and setting a new layout to the main widget). Resizing still works but the stretching factors behave weird:
The PlainTextEdit seems to take up far to much space. The Stretching Factors are still at 1:1. I found a workaournd, by changing the stretching of the upper widget to a much higher value (in this case 9:1), which looks good again:
So my question is: Why do the stretching factors begin to behave weird when I put the images in a Splitter? And how can I solve this without using arbitrary guessed stretching factors?
QSplitter::setSizes() can be used to set relative sizes. According to the documentation, "any additional/missing space is distributed amongst the widgets according to the relative weight of the sizes".
In this case, it is a bit ugly, since you have to add this in your code rather than editing your layout in QDesigner (normally, you would want to define your layout only at one place), but still it is quick and works:
MyWindow::MyWindow(QWidget* parent):
QWidget(parent)
{
m_Ui.setupUi(this);
m_Ui.splitter->setSizes({2000, 1000, 1000});
However, I had to use big numbers (instead of {2, 1, 1}), maybe because at this point, the window is not completely set up yet (apparently, Qt is not a big fan of RAII...). Also, this kind of notation works probably only with a recent C++ version, otherwise you can also define the QList in some extra lines.
I'm trying to create a QTableView that can be zoomed in and out like in Excel.
A similar question was asked here: Zooming function on a QWidget
However, I'm subclassing the QTableView in PyQt and not C so reimplementing the entire PaintEvent method is a bit evolved. The source code for that is a bit complex: https://qt.gitorious.org/qt/tiittane-qt/source/bdd4a9149789f60974603e1f7621d51378f0a108:src/gui/itemviews/qtableview.cpp#L1282
I'm looking to see if there are any other viable options to have a zoom able TableView. My first attempt was by setting the font size then realized each column and row widths would have to scale as well which can become slow. Then realized changing the font would change the print. It didn't seems like an elegant solution. Changing the scale of the painter before painting seems like the more elegant solution but would have to re-implement and translate quite a bit of code to python to do so. I'm wondering if there are any other hooks to get this done.
Thanks
If you can use QTableWidget instead then you can create a QGraphicsScene and add it to that. Then you easily control the scale of the widget within.
If you want vertical and horizontal headers always visible I think you will have to turn off the table's scrollbars (which would end up zoomed, probably not what you want anyways) and have the scrollbars part of the panel that contains the graphics scene (probably panel would be a QAbstractScrollArea with 4 cells in layout: one cell for scene, one for horiz scrollbar, one for vert scrollbar, and one for the corner maybe empty), and connect them to the table's scroll behavior.
There is no built-in method to zoom on a view.
The simplest way to separate the size of the font on the screen, versus the size of the font saved or printed, is to basically have two fonts. One to be displayed on the screen you can call 'zoom', versus the other to be saved/printed and call that 'font size'.
Note this answer is cut and pasted from the same question:
Zooming a view in PyQt?
Whenever you resize a datagrid by hand (not via code), the last column seems to retain most of the width. What's worse, whenever you extend it and shrink it to a large degree, the other columns can get smushed. Here's a perfect example:
The ideal solution would distribute width equally or in proportion to the length of the text. In addition, if would avoid covering text when it's not necessary. Now, setting the width to 0.5 in the example above does seem to alleviate the issue, but not prevent it entirely.
What I'd also like to know if there are any well polished, custom datagrids out there that solve this. From trying to find a solution, I suspect the only solutions available are more ad-hoc.
I know two ways to avoid this problem.
1) Use List with special item renderer, which simulates columns (say HBox separated with rules), and header, which repeats the layout of item renderer. It's not very elegant solutions, but the resize is quite predictable. Also you can easily add sorting feature (by adding buttons to header), but I'm not sure if column resize is possible to implement here.
2) Use spark s:DataGrid from SDK 4.x. It hasn't got such resize problems AFAIK.
I have a textarea where I measure the textWidth and textHeight to make sure the user cannot enter more text than can fit in the text area. I also extended the textArea with a textHeightNow and textWidthNow that measure the textField's dimensions since they update w/out requiring validation. Now this works great for 90% of the embedded fonts I'm using but any fonts that have giant serifs are not measured properly, for instance look at the 'f's in this text area:
alt text http://img.skitch.com/20091101-xhm5jguma1qgukg6fxrymrwr3u.jpg
You can see they get cut off on both sides because textWidth and textWidthNow both return an incorrect size not taking into account the massive serifs. The font size, coords and dimensions of the text area are all integers so thats not the problem, any other suggestions? I looked to see if textArea has a clipContent argument but it doesn't (that would have been nice).
Thanks
I've run into this problem before and as far as I can tell you have two options, none of them very nice:
Use the new flash.text.engine in
Flash Player 10... its very hard to use but
I think it will measure such fonts
(and ligatures) properly.
Draw the textfield into a bitmapdata
and use getColorBoundsRect to
determine its real dimensions.
I ended up using the latter as changing the whole app to the new engine would have been much much harder. You will need to tweak margins and use a larger textfield (inside some container) to be able to draw it properly, but it should work.