QMessageBox Icon Issue and How to add a dir to Qt Resources File

Hi All,

I m using Qt 4.2.2 on my Intel Mac.
I have two Issue.

1. I m using the following code to Display a message

QMessageBox::information (
this, MSG_TITLE,MSG_Str,QMessageBox::No,QMessageBox::Yes
);

It is Showing the Message but it is not showing the Information Icon only showing my application Icon.
It is showing the Icon only when I used QMessageBox::critical.
Why it is not showing the Icon in Other case.



2. My 2nd Issue is related to the resource File.

I m writing the line RC_FILE = app.icns
to add the Icon file in the .app file into the Resource folder.

But I want to add a Dir in the .app file Resources Dir but when i write
RC_FILE = HELP

where HELP is Dir name it is giving the Error that HELP is a Dir and can not be Added.

So If there is another way ofadding a Dir as resource.

If any body knows then plz help me.

Thanks.

Quote:

---

Originally Posted by vishal.chauhan

It is Showing the Message but it is not showing the Information Icon only showing my application Icon.
It is showing the Icon only when I used QMessageBox::critical.
Why it is not showing the Icon in Other case.

---

What icon are you referring to? Can we see a screenshot?

Quote:

---

I m writing the line RC_FILE = app.icns
to add the Icon file in the .app file into the Resource folder.

But I want to add a Dir in the .app file Resources Dir but when i write
RC_FILE = HELP

where HELP is Dir name it is giving the Error that HELP is a Dir and can not be Added.

So If there is another way ofadding a Dir as resource.

---

Why would you want to add a directory to a resource file? If you want to add its contents, then you have to do it file by file.

Are you sure you really want to change the "RC_FILE" variable? Maybe you're after "RESOURCES"?

I want to use the Icon of QMessageBox as shown in Attachment.

Also I want to use Dir because I want to add a Dir of Help Manual to be added in the Resources.

But "RC_FILE" is not a variable that is related to Qt resources! You should use RESOURCES for that. And you can't add a directory just like that. Instead add a prefix in your resource file and add all files from the directory under that prefix.

As for the screenshot - I meant what you have and not what you want to have :)

Thanks for Reply.

Actually when I write QMessageBox::information it shows only the Application Icon as in information.png

and when I write QmessageBox::critical it shows the Application Icon with the Other Icon as in Second Attachment.

Maybe this is the way it works on MacOS? You can try to construct your own message box by using the non-static methods of QMessageBox.

Quote:

---

Maybe this is the way it works on MacOS?

---

If this is the case, I think it can be regarded as Qt bug (on Mac), thus reported to the trolls.

Having said that, I think the the icons look cool (the mix of the standard message box icon and the applications) :)
You might promote it as a feature "its not a bug, its afeture"! ;)

Quote:

---

Originally Posted by high_flyer

If this is the case, I think it can be regarded as Qt bug (on Mac), thus reported to the trolls.

---

No, I meant that maybe this is a platform policy on MacOS.

Quote:

---

No, I meant that maybe this is a platform policy on MacOS.

---

I know what you meant, but since Qt is a crossplatform lib, the mac version should take it in consideration and either use the mac policy or supply is own custom dialogs.
But having both icons on one another is not good.

Quote:

---

Originally Posted by high_flyer

But having both icons on one another is not good.

---

I think it is meant to be that way. I don't have time now to look for it, but it's possible that the "info" message box on MacOS should display the application icon whereas the "warning" and "critical" display a combined icon.

Edit: Could you please check how does the message box look if you start your application with a "-style Plastique" parameter?

Quote:

---

Originally Posted by wysota

Edit: Could you please check how does the message box look if you start your application with a "-style Plastique" parameter?

---

Can u Plz tell me how can I start my app with -style Plastique.

Quote:

---

Originally Posted by wysota

Why would you want to add a directory to a resource file? If you want to add its contents, then you have to do it file by file.

---

Actually adding a dir to a resource file would be a cool thing. Suppose you could have a directory, where you could just dump stuff into and when your project is rebuild, the content is automatically added to the binary.

Inside your code you could use something like QDir(":/includedDir")
as if it was a normal dir in your filesystem.

Quote:

---

Originally Posted by vishal.chauhan

Can u Plz tell me how can I start my app with -style Plastique.

---

Run your application from the commandline and after the application name add the text I suggested. I think on Mac you need to use the "open" command, but I'm not sure.

Quote:

---

Originally Posted by Kumosan

Actually adding a dir to a resource file would be a cool thing. Suppose you could have a directory, where you could just dump stuff into and when your project is rebuild, the content is automatically added to the binary.

Inside your code you could use something like QDir(":/includedDir")
as if it was a normal dir in your filesystem.

---

The problem is that all rcc does is that it transforms a binary file into a C byte array and a directory doesn't have a "byte" representation. If you need to add a "directory", just add a new prefix and put all the files you want under the prefix.

Quote:

---

Originally Posted by wysota

The problem is that all rcc does is that it transforms a binary file into a C byte array and a directory doesn't have a "byte" representation. If you need to add a "directory", just add a new prefix and put all the files you want under the prefix.

---

All true, but this makes it still not impossible. It could be a shortcut for adding each file individually into the .qrc file. The qmake program could handle it automatically when it finds a directory in the .qrc file.
Instead of writing:

Code:

---

<qresource>
   <file>DocsHTML/basic01.html</file>
   <file>DocsHTML/basic02.html</file>
   <file>DocsHTML/basic03.html</file>
    <file>DocsHTML/basic04.html</file>
</qresource>

---

The following:

Code:

---

<qresource>
   <file>DocsHTML/</file>
</qresource>

---

could be equivalent. All basic*.html files would be automatically added to the resource.

Of course there are other problems. The above syntax enhancement would be nice and easy to implement, it but would not yet allow the use of QDir. If this was a requirement, it would have to store somewhere the tree structure of the resource dir to be able to traverse it with a QDir like syntax.

And if there is a QDir like syntax, the next questions would be how to add new files and dirs to the resources, which would be way beyond the original scope of the resource system.

But this would be cool too. A portable ram disk for all Qt applications. :D

I think you don't understand one thing... There is no such thing as a "directory" inside a qrc file. The file consists of key-value pairs where the key is the complete path to a resource and value is the binary representation of the object as a byte array. There is no hierarchy inside a qrc file - only a flat set of arrays.

Quote:

---

Originally Posted by wysota

I think you don't understand one thing... There is no such thing as a "directory" inside a qrc file. The file consists of key-value pairs where the key is the complete path to a resource and value is the binary representation of the object as a byte array. There is no hierarchy inside a qrc file - only a flat set of arrays.

---

You seem not to understand what I want to say. I know how the resource thing works. I just think how to improve it.

Especially the first step introducing directories is easy. Instead of adding each file manually to the .qrc file, qmake could do some of the work automatically. When the element in the <file></file> tags is a directory than qmake could automatically add all files in this dir to the resources. This would be a convenience solution and could be added with a few lines of code. No change to the currently existing code at all.

The second step would be much more complex. The tree layout of the directory is stored within the program and it could be used like a read only pseudo files system. Yes, I know, it does not exist. Never said it does. I said it would be cool to have something like that. This still would not be too hard to implement, but probably too expensive for a minor upgrade.

The third step would be to get not only a read only pseudo file system, but a read/write one based on a ram disk.

The resource file would be used to populate the ram disk with the files in the .qrc file, but it would also allow to write in it, too.

This would not have much to do with the current resource system, but could totally replace it. It would even be 100% compatible with old code.

Quote:

---

Originally Posted by Kumosan

Especially the first step introducing directories is easy. Instead of adding each file manually to the .qrc file, qmake could do some of the work automatically. When the element in the <file></file> tags is a directory than qmake could automatically add all files in this dir to the resources. This would be a convenience solution and could be added with a few lines of code. No change to the currently existing code at all.

---

Actually qmake doesn't have anything to do with it, it's rcc that handles resource contents, but I agree that this is easy to do.

Quote:

---

The second step would be much more complex. The tree layout of the directory is stored within the program and it could be used like a read only pseudo files system. Yes, I know, it does not exist. Never said it does. I said it would be cool to have something like that. This still would not be too hard to implement, but probably too expensive for a minor upgrade.

---

It would be hell slow.

Quote:

---

The third step would be to get not only a read only pseudo file system, but a read/write one based on a ram disk.

---

I doubt this is something for the resource system :) If you want that, implement your own QAbstractFileEngine.

Quote:

---

This would not have much to do with the current resource system, but could totally replace it. It would even be 100% compatible with old code.

---

Replace it? I don't think this would be a good idea. But, as I said, you can implement a "virtual directory" though a QAbstractFileEngine subclass.

Quote:

---

Originally Posted by wysota

Actually qmake doesn't have anything to do with it, it's rcc that handles resource contents, but I agree that this is easy to do.

---

Correct but unimportant detail. It is called by qmake anyways when the .pro file contains a RESOURCE statement. Never used rcc directly.

Quote:

---

Originally Posted by wysota

It would be hell slow.

---

I don't think it would be slow. But if it was, it should not matter that much. The reason why I would want it is because it would make sense with automatically added resource files. With the current system you know exactly what you have added to your binary. If a file xx was added using "<file>bla/xx</file>" in the .qrc file you can access it by ":/bla/xx" in the program. If you add files indirectly by naming their parent directory this is not so obvious.

I would like it to have a dir where I can just dump stuff in and can find out during runtime, what I actually added to my resources.

Would be great for help files. Whenever I write a new help file I could drop it into the dir, do a qmake <project>.pro and recompile. The code itself could be written flexible that it finds out what resources it has, and shows automatically the right help file in the right context.

This would allow to apply the open/closed principle to resources. I would not need to know during compile time what resources the program will contain later. New resources could be added without the need to change the program code.

It probably could be implemented that if you access a resource directly as it is done now, you would not have a speed penalty at all.

Quote:

---

Originally Posted by wysota

I doubt this is something for the resource system :) If you want that, implement your own QAbstractFileEngine.

---

Probably not for the resource system, right. But it could use exactly the same syntax.

Quote:

---

Originally Posted by wysota

Replace it? I don't think this would be a good idea. But, as I said, you can implement a "virtual directory" though a QAbstractFileEngine subclass.

---

I can do many things, but I am lazy. So if TT could provide something like that.... :p

Quote:

---

Originally Posted by Kumosan

I don't think it would be slow. But if it was, it should not matter that much.

---

I'd say it would matter very much. The resource system uses a kind of index to find files by name. I don't know how it works, but it's probably optimised for exact name matching (for example using qHash()). If you wanted to use it as a directory, you'd have to be able to find all files from within this or that "directory". You'd have to either completely change the indexing method so that it works like a database index (which would make resources slower) or provide a second index only to use it for pattern searches (which would in turn it up more memory). One way or the other you'd slow down the whole system. It's just not optimised for things you'd want it to do. If you need, you may use QDir with the resource system - just pass it a path beginning with a colon and a slash, I think it might just work as the resource system is implemented as a QAbstractFileEngine subclass. I assure you it would be quite slow though (compared to real file system access).

Quote:

---

The reason why I would want it is because it would make sense with automatically added resource files. With the current system you know exactly what you have added to your binary. If a file xx was added using "<file>bla/xx</file>" in the .qrc file you can access it by ":/bla/xx" in the program. If you add files indirectly by naming their parent directory this is not so obvious.

---

I don't quite follow... So is it good or bad that it's not obvious? A qrc file is really an xml, so there should be really nothing stopping you from making your own xml writing application that creates a completely custom filesystem using the resource system.

Quote:

---

I would like it to have a dir where I can just dump stuff in and can find out during runtime, what I actually added to my resources.

---

Ok, but what for?

Quote:

---

Would be great for help files. Whenever I write a new help file I could drop it into the dir, do a qmake <project>.pro and recompile. The code itself could be written flexible that it finds out what resources it has, and shows automatically the right help file in the right context.

---

Have you actually tried that? Because, you know, it already works that way.

Quote:

---

It probably could be implemented that if you access a resource directly as it is done now, you would not have a speed penalty at all.

---

Could you explain what you mean here?

Quote:

---

Probably not for the resource system, right. But it could use exactly the same syntax.

---

Please take a look at QAbstractFileEngine docs :)

Quote:

---

I can do many things, but I am lazy. So if TT could provide something like that.... :p

---

They already did.

Ahh, forget it. I am using the resource system for quite some time. Usually to initialise some QIcons or to read various other data using QFile. But I never even tried to use it with QDir. Must have been a bit blockheaded just to assume this cannot work and not to check the documentation more thoroughly.

Still, with the ability to traverse the resource tree with QDir an auto add feature for files in a resource directory would be even more usefull. Or does this happen, too?


And just forget the writing part of this discussion, this won't happen anyways. So no need to delve into this matter any further. QAbstractFileEngine might be usefull to build something like this, agreed, but is by far not a the complete solution or easy enough to just do the things I meant.