Get size of icon constructed via QIcon(QString &)
-
Is there a way to find the size of an icon created via the QIcon constructor variant taking a filename as input? I mean, the dimensions of the original image and/or "unscaled" pixmaps created from it.
I find that QIcon::availableSizes() will return an empty list for all combinations of Mode and State for such an icon - unlike, for instance, one created via QIcon::fromTheme().
- Toralf
-
[quote author="mcosta" date="1363959373"]Hi,
a QIcon is a object that store many Pixmap depending the mode, size and state.
For example you could use different "unscaled" pixmap for Size; so there isn't single Image.Regards[/quote]
Maybe I wasn't very clear in my orignal post, but the question wasn't supposed to be how to get one single image size, but rather, how to find any size at all with certain setups.Yes, there may be different pixmaps depending on mode, size and state. If the icon is created via the theme engine, I can get size information on each and every one of those via availableSizes(). However, if I create an icon from a single PNG file, this method simply doesn't return anything - although surely, there is at least one well-known "unscaled" size - i.e. the dimensions of the input image.
-
Sorry,
can you post your code?
I tried this
@void Widget::on_loadImage_clicked()
{
QString fileName = QFileDialog::getOpenFileName(this,
tr ("open Image"),
".",
tr ("PNG Files (*.png)"));if (!fileName.isEmpty()) {
QIcon icon (fileName);qDebug() << "Available sizes for" << fileName << ":" << icon.availableSizes();
}
}
@and it works fine
OUTPUT
@Available sizes for "C:/Users/xxxxxx/Pictures/pdc.png" : (QSize(542, 306) )@I'm working with Qt5.0.1 on Windows7
Regards
-
I'm using Qt 4.8 under Linux. Simplified version of the actual code used, wrapped up as a stand-alone application:
@#include <QApplication>
#include <QIcon>
#include <QPushButton>static void checkIcon(const QIcon &i1)
{
qDebug("Size lists for icon "%s":", qPrintable(i1.name()));for(int modeNo=0; modeNo<=QIcon::Selected; modeNo++) {
QIcon::Mode mode=(QIcon::Mode )modeNo;for(int stateNo=0; stateNo<=QIcon::On; stateNo++) { QIcon::State state=(QIcon::State )stateNo; QList<QSize> sizes=i1.availableSizes(mode, state); qDebug("%d sizes for %d %d", sizes.size(), mode, state); }
}
}int main(int argc, char **argv)
{
QApplication app(argc, argv);
QIcon fileIcon("/usr/share/icons/gnome/32x32/actions/document-open.png");
QIcon themeIcon(QIcon::fromTheme("document-open"));
QPushButton b1(fileIcon, "file"), b2(themeIcon, "theme");checkIcon(fileIcon);
checkIcon(themeIcon);b1.show();
b2.show();app.exec();
return 0;
}
@
Notice how a "themed" icon is also included for comparison purposes. The buttons are just a way to verify that the icons are valid. Output:
@Size lists for icon "":
0 sizes for 0 0
0 sizes for 1 0
0 sizes for 2 0
0 sizes for 3 0
Size lists for icon "document-open":
5 sizes for 0 0
5 sizes for 1 0
5 sizes for 2 0
5 sizes for 3 0
@Both icons are displayed correctly.
-
Yeah, I suppose it looks like that. Maybe the functionality just was never properly implemented in the past?
BTW, a minor error somehow managed to slip into the code I posted; line 12 should actually read
@for(int stateNo=0; stateNo<=QIcon::Off; stateNo++)@
This doesn't make a whole lot of difference, though. The original code wouldn't really check all mode/state combinations, but the size lists are also empty for the ones that were left out (in the "file" case.)
-
Well, I feel a bit embarrased now, because when testing again, I find that there is in fact one valid image size. Which I'm assuming was the case all along, although I've done a minor Qt update since posting the question, so there is a small chance that real problems existed in the past.
The situation is this:
When using the filename based constructor, a valid image and size is set up for exactly one mode/state combination - QIcon::Normal/QIcon::Off.
My original application as well as the first version of my simplified example would really only check state QIcon::On, due to an incorrect loop setup - as mentioned earlier. Now, I don't think a loop on enum values is very neat anyhow, but can't think of a better alternative.
I somehow managed to overlook the fact that one size was in fact returned for one of the 8 different combinations listed, after correcting the loop in the test program.
Sorry, folks.
It still looks like there is no icon name, though...