PDA

View Full Version : Zoom a view?



neuronet
9th June 2015, 21:26
I have a QTreeView of some text, displayed in a QMainWindow, and I want the user to be able to zoom on the view without having to change the font size in the view. Is this possible? Or would I have to embed the tree view in a QGraphicsScene?

A post from Trolltech in 2007 (https://blog.qt.io/blog/2007/03/09/qgraphicsview-widgets-on-the-canvas/) said:

Widgets cannot be scaled or rotated, but graphics items can.
Is this still the case?

Note this is a slightly edited version of a question I asked at Stack Overflow:
http://stackoverflow.com/questions/30601123/zooming-a-view-in-pyqt

Someone asked a similar question earlier:
http://www.qtcentre.org/threads/35450-how-to-zoom-in-zoom-out-tableview-in-QT-programming

wysota
10th June 2015, 10:04
I want the user to be able to zoom on the view without having to change the font size in the view

Hmm... how exactly would this "zooming" work? Should all the text remain the same size ("not changing font size") or should the text grow with its quality worsened (one pixel of each glyph gets scaled to e.g. 4 pixels). Could you provide a mockup image of what you want?

neuronet
10th June 2015, 18:52
Hmm... how exactly would this "zooming" work? Should all the text remain the same size ("not changing font size") or should the text grow with its quality worsened (one pixel of each glyph gets scaled to e.g. 4 pixels). Could you provide a mockup image of what you want?

I want the underlying font size to stay the same for printing or saving to PDF, but I want its appearance on the screen to change with some kind of interaction, such as a spinbox. I want high quality at higher magnification (so not like zooming an image where things get pixellated). Kind of like the following (except the one that appears bigger magnification should read 120%):

11201

Open Office and MS Word both have this capacity. That is, there is a scrollbar at the bottom right that scales the appearance of the text (its size on the screen), but the underlying font size (point size) stays the same (e.g., for printing or saving the document). The quality is fine at high magnification. I was hoping for something like that with my tree view.

wysota
10th June 2015, 23:35
I want the underlying font size to stay the same for printing or saving to PDF
You want to print a widget? That's unusual.


I want high quality at higher magnification (so not like zooming an image where things get pixellated).
That's impossible to achieve without changing the size of the font :)


Open Office and MS Word both have this capacity.
No, they don't. The fact they tell you a particular font is set to 10pt doesn't mean they render it at 10pt. You can do exactly the same.

neuronet
11th June 2015, 02:40
No, they don't. The fact they tell you a particular font is set to 10pt doesn't mean they render it at 10pt. You can do exactly the same.

Word and Office do exactly what I want. :rolleyes: Whether they are doing it a certain way, or my terminology was perfect, is another question, but my question is how can I get my treeview to behave like that?

You also wrote "You can do exactly the same." Yes, that's my question. Given the docs I've looked at and mentioned above, I am still not sure how, unless I somehow wrap my whole widget into a QGraphicsScene, which seems like overkill. Or unless the old trolltech doc I quoted is wrong.

wysota
11th June 2015, 08:14
Word and Office do exactly what I want. :rolleyes: Whether they are doing it a certain way, or my terminology was perfect, is another question, but my question is how can I get my treeview to behave like that?
Adjust the font.


unless I somehow wrap my whole widget into a QGraphicsScene
This will not change a thing. You would not get the effect you wanted. While the font might look ok, all bitmaps will be upscaled.


#include <QApplication>
#include <QTreeView>
#include <QFileSystemModel>
#include <QGraphicsView>
#include <QGraphicsScene>
#include <QGraphicsProxyWidget>

int main(int argc, char **argv) {
QApplication app(argc, argv);
QGraphicsScene scene;
QGraphicsView view;
view.setScene(&scene);

QTreeView lv;
QFileSystemModel model;
model.setRootPath("/usr/share/icons");
lv.setModel(&model);
QGraphicsProxyWidget *w = scene.addWidget(&lv);
w->setScale(4);
view.show();

return app.exec();
}

11202

If you want to have zoomable UI then indeed the simplest thing is to wrap it in graphics view but the result will be far different from text processor zoom functionality.

neuronet
11th June 2015, 16:50
Wysota: Your example is very helpful, I will convert to PySide and play with it, thank you.


Adjust the font.

That is not what word/open office are doing. The font can remain 10pt in the doc, but you can zoom it so it appears different on the screen. So at some level the underlying font size and the size on the screen are independently manipulated. Again, I apologize if my jargon is not perfect here (maybe there are two different font sizes or something so to discuss an "underlying font size" as if there is just one is inaccurate), but it is not some obscure esoteric thing I am after!

wysota
11th June 2015, 17:01
That is not what word/open office are doing. The font can remain 10pt in the doc, but you can zoom it so it appears different on the screen. So at some level the underlying font size and the size on the screen are independently manipulated.
You seem to be missing the point. If you scale the document 10 times and you have formatting telling you the font is 10pt, maybe I will ruin your view on the world, but I have to tell you Word does not render that text with 10pt font but rather with 100pt one. And the cheater still tells you it is 10pt :) You should do the same, at 100% scale render with 10pt, at 200% render with 20pt and so on. That's what Qt does in my Graphics View example as well. It cannot do that with bitmaps though, that's why you get aliasing.

neuronet
11th June 2015, 17:39
You seem to be missing the point. If you scale the document 10 times and you have formatting telling you the font is 10pt, maybe I will ruin your view on the world, but I have to tell you Word does not render that text with 10pt font but rather with 100pt one. And the cheater still tells you it is 10pt :) You should do the same, at 100% scale render with 10pt, at 200% render with 20pt and so on. That's what Qt does in my Graphics View example as well. It cannot do that with bitmaps though, that's why you get aliasing.

OK, I assume you are right on that front, but it will print as 10 point. So there are still two things that can be independently manipulated. That's what I'm after. I guess the thing to do is have two font spinboxes: one for appearance on screen, one for appearance on printer. The former I will call "zoom" and the latter I will call "font size". :)

From what you've said, it seems that's what Word/Office are doing.

wysota
11th June 2015, 18:16
OK, I assume you are right on that front, but it will print as 10 point. So there are still two things that can be independently manipulated. That's what I'm after. I guess the thing to do is have two font spinboxes: one for appearance on screen, one for appearance on printer. The former I will call "zoom" and the latter I will call "font size". :)

Printing does not happen magically. Qt prints whatever you tell it to print. If you tell it to draw text with 10pt font, it will do just that. If you tell it to draw with 20pt font, it will do that too. If you tell it to draw on the screen with 24pt font and print on paper with 12pt font it will do that as well. It is you who decides what gets printed.

Just look that Word does not send the exact copy of what you see on the screen to the printer. If you tell it to show unprintable characters, you will get them on screen but not on print. Printing "widgets" really does not make much sense, you should have a view on your data that looks good on a screen and a different "view" that will be sent to the printer. You will not get good output using the same view for both, even if only because of a resolution difference between the screen (usually less than 100dpi) and the printer (usually 600dpi or more). The same "widget" printed on such printer will be six times smaller than when rendered on your display. I don't think I would ever want to see a tree view (with borders, scrollbars and stuff) printed as a document.

neuronet
11th June 2015, 18:22
I don't think I would ever want to see a tree view (with borders, scrollbars and stuff) printed as a document.

It's ugly, to be sure, but it works for my purposes right now. :o

d_stranz
11th June 2015, 19:32
Then just flip-flop fonts when you print:



// In your print method

QFont screenFont = myTree->font();
QFont printFont = screenFont;
printFont.setPointSize( 10 );
myTree->setFont( printFont );

// Print it

myTree->setFont( screenFont );


You might have to force an update before you print, dunno.

neuronet
12th June 2015, 19:08
Then just flip-flop fonts when you print:



// In your print method

QFont screenFont = myTree->font();
QFont printFont = screenFont;
printFont.setPointSize( 10 );
myTree->setFont( printFont );

// Print it

myTree->setFont( screenFont );


You might have to force an update before you print, dunno.

That seems exactly right.