Adding notes to class pages?
-
I have some behavior info -- sadly missing from the docs -- WRT QImage.save (4.7). I joined so I could add a note to the QImage class page; but there appears to be no such option, although there is one note already there.
What am I missing?
-
Open the page: http://qt-project.org/doc/qt-4.7/qimage.html
you will find a "Add Note" button at the bottom of the Documention .
-
-
That's odd. You are viewing the docs page while you're logged in, correct? (I assume so, since you're posting. But it could conceivably be in another browser instance or an old window before you logged in or something.)
-
Yes, I'm logged in, show my picture on teh right side and everything.
It says I have "10 points" which I presume are related to my two posts. Is there a points limit at which the feature appears, sort of like stack overflow works?
-
Well, according to "this page":http://qt-project.org/ranks, an "Ant Farmer" should be able to add doc notes.
Edit: Ah, but you're not an Ant Farmer yet! You'll need 180 points before you can add doc notes, apparently.
-
I see. So I have to post, in order to post. I suppose it keeps the noise level down.
I see there are other ways to get points. Tagging, and so forth. I'll get after some of that.
-
It keeps spamming down also. it's just a matter of establishing a little bit of history (and, consequently, credibility) before being allowed more options. However, it doesn't take that long to hit 180 points. You've already got 20 so far from this thread alone.
Filling out your profile is another way to gain more, though I see you've already figured that out too.
So welcome to the forums, by the way! It's nice to have you here. :-)
-
Thanks. I hope I can contribute more than my two piddly little insights (thus far.)
I spend about half my time being amazed at Qt, and the other half wondering "What must they have been thinking???" There are these gaping holes in the APIs where I, at least, think someone should be held against a wall and thrashed with a wet noodle, and then there are these fiddly little adjustments almost no one will need to make. Mind boggling. :)
For instance, I can't stop a spinbox from autorepeating; I can't push off saving images to another thread (8 cores, and I have to QImage::save() on my main thread... oooog); I can't append to an image, I can't tell a widget that it MUST NOT go below the minimum sizes I set (that's a killer, right there), I have to jump through the most amazing hoops to create a semblance of user color properties in a stylesheet by embedding them in an unrelated widget... these things give me the ol' eye-twich. [please visualize -- the management thanks you]
-
A few thoughts..
I'd argue that the autorepeating nature of a spin box is the "expected behavior" of the widget, and thusly is why it's hard to change. (Although, I suppose one could subclass QSpinBox, capture mousePress and mouseRelease events, and prevent the updating after the first click.)
If you use a QImage, you should be able to save it from a different thread. QPixmaps etc., not so much.
"setMinimumSize":/doc/qt-4.8/qwidget.html#minimumSize-prop should prevent a widget from going below a certain size.
While Qt does have its quirks (what toolkit doesn't?), I'd say that overall it's pretty thorough and well-designed. I've found that if there are odd behaviors or problems that seem difficult to solve, there's a whole lot of people around here who can help point you in the right direction, offer a creative (or little-known) solution, or (worst case) plead with you to reconsider your design. :)
-
o The problem with the autorepeat of the spinbox is that it doesn't come to me with its problems. For instance, I have one that changes range (and suffix-designator) from Hz to kHz, and step size from 1 Hz to 100 Hz to 1 kHz to 10 kHz. Works perfectly if you single click it. But if you autospin it, holding the thing down, I don't get all the messages and consequently the steps get messed up. Would have been easily solvable if I could stop the autorepeat, but as is, I can't fix it, or at least, I haven't figured out how yet.
o QImage. Yeah, you should. So the docs say. But I narrowed it down to nothing but the image.save() in the thread, and it blows up instantly. Send a signal to a procedure in the main thread with exactly the same call, works fine.
@
if(!pParent->imageB.save(multifn,"PNG"))
{
error...
}
@o setMinimumSize either doesn't work, or I don't understand how to use it:
@
setMinimumHeight(384); // doesn't work
setMinimumWidth(1280);
QSizePolicy policy( QSizePolicy::Expanding, QSizePolicy::MinimumExpanding );
setSizePolicy(policy);
setMinimumHeight(384); // try again? ... nope, still doesn't work
setMinimumWidth(1280);
@o Quirks.... yeah, I'm still using it. :) Quirks indeed.
-
What platform are you on?
This works for me (it prevents my window from being manually resized down to < 320x200):
main.cpp:
@#include <QtGui/QApplication>
#include "mainwindow.h"int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
@mainwindow.h:
@#ifndef MAINWINDOW_H
#define MAINWINDOW_H#include <QWidget>
class MainWindow : public QWidget
{
Q_OBJECT
public:
MainWindow(QWidget *parent = 0): QWidget(parent) {
setMinimumWidth(320);
setMinimumHeight(200);
}
};
#endif // MAINWINDOW_H
@ -
Env: Qt 4.7, OS X 10.6.8, 8 cores, 8 gb, 3 GHz, Macpro, three PCI display cards, six monitors. Behavior is the same on my laptop, though, which is pretty different other than OS.
I have:
@
CPlotter::CPlotter(QWidget *parent) :
QFrame(parent)
{
setMinimumHeight(384);
setMinimumWidth(1280);
QSizePolicy policy( QSizePolicy::Expanding, QSizePolicy::MinimumExpanding );
setSizePolicy(policy);
setMinimumHeight(384);
setMinimumWidth(1280);
etc...
@...and...
@
class CPlotter : public QFrame
{
Q_OBJECT
public:
explicit CPlotter(QWidget *parent = 0);
~CPlotter();
...etc
@