I have some buttons on a tabwidget. These buttons need to have some icon on top of them.
I am aware of QPixmap that will allow me to put an image on top of a button, but I see that these constructors take a filepath as a parameter. I want to avoid dragging icons around in a file after I build. I would like to embed these icons in the executeable somehow, so as to reduce the baggage that I need to lug around in order to make it work.
How can I accomplish this?
I am interested in hearing ways to accomplish my goal of not needing to drag icon files around with the executable; please focus on this aspect if you are confused about some terminology I may have used, as I am still learning Qt.
Of course you can embed icons, images and all other custom resources into your application.
Please read The Qt 4's Resource System (or click here for Qt 5)
You will have a resource file named something like ProjectName.qrc and these list the icons (usually PNGs). With Qt Creator it already starts out with a blank QRC file for you. When specifying the "file" you use the syntax in the manner of ":/Images/MyCrazyIcon.png" and the icon is loaded from the resource that is embedded into your executable. Note that Qt does not manage resources in the very most perfect way, which is to have them loadable upon demand but not always hogging up system memory; they ALWAYS hog up system memory, which really is not such a big deal if they are small. For the big graphics you want flushed out later, just specify a real file name (e.g., "MyBigFile.png" instead of ":/MyBigFile.png", which the latter points to a resource within the executable).
With the resource syntax the power is in the colon character ":", so you could even have ":MyFile.png", providing the QRC file is located in the same directory as the resources. That is how I am doing it, and so far see no downside of this syntax. I hate including ".../Images/..." in the syntax, so my resource names are addressed with ":MyPic.png" without the longer ":/Images/MyPic.png" and all works fine.
The Qt documentation states that AT THIS TIME they do not support true resource handling that Windows and Mac supports, but that things could change in the future. Remember, "true resource support" refers to that nice thing where you can place multi-megabyte graphics and sounds within your executable and never worry about them loading into memory until the magic time you request them. The QRC resources are loaded into memory when the executable is loaded up. The skinning by loadable file support more than makes up for this weakness. Qt is improving rapidly and one day they could very well support both the Windows and Mac resource systems. I am getting redundant and must go. Ta ta. Everybody mod me up, I need the points.
Maybe you should try this:
add a single line to your .pro project file:
RC_ICONS = myappico.ico
More Information: Setting the Application Icon
Related
The Title says everything. I'm pretty new to qt and don't really like the editor it provides.
vim form1.ui.h doesn't work.
Most likely you mean header file generated from your .ui file. Well, since it's generated - editing it is not very good idea, because it will be regenerated from .ui each time you build you program.
But you obviously can:
Edit .ui file with any xml/text editor. Though it's really strange and wouldn't win much over using designer itself.
Do not use .ui files at all - encapsulate creation of desired interfaces in your own classes containing simple C++/Qt code. That way actually is not that bad if you're experienced with Qt layout/widget system and know what you wish to achieve. Because there's no any kind of pixel hunting needs to be done in designer and placing things in appropriate way may actually be done even in more structured manner in code than in form creation. Though as I said it's not the way for everyone and you have to be accurate, also it's better separate interface code from other functionality.
Well i have a project in which gets pics and videos from folders and also i can view them it it and when i view them i want to also see those tags kinda like the camera which took it, dimensions , the ISO, the exposure time and others for pics and camera model framerate and dimensions...
Thanks in advance
I've never seen anything like this in Qt. Anyway, Qt is a C++ framework, you can use whatever library you want to use. QImageMetaData and QMeta are very near Qt style, but can only be used for images (never tried those).
Anyway, I would use the XMP toolkit. You also mentioned videos, so in that case XMP can handle both. It is very simple to use, well documented and fast (license is BSD). It is written in C++, so you can port it on whatever platform you want.
I think Qt itself does not provide a way to extract exif data (which is what I guess you're trying to extract). You could perhaps try QMeta. I have not used this myself, so no guarantees.
I have a Flex application that seems larger than it should be. There is a lot of code in it, but not a lot of assets and it just seems large, but I'm not sure how to go about figuring out where the space is going.
I know about the –link-report option, but it only gives the sizes of externally linked library classes. I'm very interested in seeing a report of the sizes of all the classes and resources in my application and it would be a huge bonus if I could also view their dependencies. Not knowing how the code is compiled I'm not sure if this is even possible, but it seems like it should since the compiler can give me the sizes of individual classes linked from other libraries.
I did some searching around, but couldn't find anything helpful. Everything points to the optimization techniques of modularizing and externally linking libraries, which I understand and will implement, but I would really love some more detailed reports of what my compiled application looks like.
To be clear, I'm not really interested in tips on how to reduce the file size, just a report on what is used for and which classes are referencing what.
Anybody have any ideas?
CORRECTION - The link report does show all classes. My particular project in Flex Builder had several CSS files set to compile to swfs. My link report for the main app was being overwritten by these css compiles!
The link report actually contains all compiled classes and not just the ones in external libraries (at least with the Flex 4 SDK). There is an xsl available that will generate an html file of the link report so it is easier to read.
Check this post: http://blog.iconara.net/2007/02/25/visualizing-mxmlcs-link-report/
There is a command-line utility called flash.swf.tools.SwfxPrinter in swfkit.jar, which comes with Flex Builder (or the plug-in or the SDK) and which you can use to analyze information about class sizes. Joe Berkovitz wrote some good instructions on how to make use of it in his blog, and he was working on an AIR-based GUI tool that leverages it, but I'm not sure if he ever published the tool. Still, you can use his instructions to leverage the utility directly from the JAR.
I found a handy little AIR app that really helps organize the link report info.
http://www.kahunaburger.com/2008/03/08/air-link-report-visualizer/
It's old but still works very well.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm working on a project which stores single images and text files in one place, like a time capsule. Now, most every project can be saved as one file, like DOC, PPT, and ODF. But complete web pages can't -- they're saved as a separate HTML file and data folder. I want to save a web page in a single archive, and while there are several solutions, there's no "standard". Which is the best format for HTML archives?
Microsoft has MHTML -- basically a file encoded exactly as a MIME HTML email message. It's already based on an existing standard, and MHTML as its own was proposed as rfc2557. This is a great idea and it's been around forever, except it's been a "proposed standard" since 1999. Plus, implementations other than IE's are just cumbersome. IE and Opera support it; Firefox and Safari with a cumbersome extension.
Mozilla has Mozilla Archive Format -- basically a ZIP file with the markup and images, with metadata saved as RDF. It's an awesome idea -- Winamp does this for skins, and ODF and OOXML for their embedded images. I love this, except, 1. Nobody else except Mozilla uses it, 2. The only extension supporting it wasn't updated since Firefox 1.5.
Data URIs are becoming more popular. Instead of referencing an external location a la MHTML or MAF, you encode the file straight into the HTML markup as base64. Depending on your view, it's streamlined since the files are right where the markup is. However, support is still somewhat weak. Firefox, Opera, and Safari support it without gaffes; IE, the market leader, only started supporting it at IE8, and even then with limits.
Then of course, there's "Save complete webpage" where the HTML markup is saved as "savedpage.html" and the files in a separate "savedpage_files" folder. Afaik, everyone does this. It's well supported. But having to handle two separate elements is not simple and streamlined at all. My project needs to have them in a single archive.
Keeping in mind browser support and ease of editing the page, what do you think's the best way to save web pages in a single archive? What would be best as a "standard"? Or should I just buckle down and deal with the HTML file and separate folder? For the sake of my project, I could support that, but I'd best avoid it.
My favourite is the ZIP format. Because:
It is very well sutied for the purpose
It is well documented
There a a lot of implementations available for creating or reading them
A user can easily extract single files, change them and put them back in the archive
Almost every major Operating System (Windows, Mac and most linux) have a ZIP program built in
The alternatives all have some flaw:
With MHTMl, you can not easily edit.
With data URI's, I don't know how difficult the implementation would be. (With ZIP, even I could do it in PHP, 3 years ago...)
The option to store things as seperate files just has far too many things that could go wrong and mess up your archive.
It is not only question of file format. Another crucial question is what exactly you want to store? Is it:
store whole page as it is with all referenced resources - images,
CSS and javascript?
to capture page as it was rendered at some point in time; a static
image of some rendered state of web page DOM?
Most current "save page as" functionality in browser, be it to MAF or MHTML or file+dir, attempts the first way. This is ultimately flawed approach.
Don't forget web pages there days are rather local applications then a static document you can easily store. Potential issues:
one page is in fact several pages build dynamically by JS, user interaction is needed
to get it to desired state
AJAX applications can do remote communication with remote service rendering it
unusable for offline view.
Hidden links in javascript code. Such resource is then not part of stored page.
Even parsing JS code may not discover them. You need to run the code.
Even position of basic html elements may be recomputed may be computed dynamically by
JS and it is not always possible/easy to recreate it locally.
You would need some sort of JS memory dump and load this to get page to desired state
you hoped to store
And many many more issues...
Check Chrome SingleFile extension. It stores a web page to one html file with images inlined using already mentioned data URIs. I haven't tested it much so I cannot say how well it handles "volatile" ajax pages.
PDFs are supported on nearly all browsers on nearly all platforms and store content and images in a single file. They can be edited with the right tools. This is almost definitely not ideal, but it's an option to consider.
Use a zip file.
You could always make a program/script that extracts the zip file to a temp directory and loads the index.html file in your browser. You could even use an index.ini/txt file to specify the file that should be loaded when extracting.
Basically, you want something like the Mozilla Archive format, but without the unnecessary rdf crap just to specify what file to load.
MHT files are good, but they usually use base64 to embed files, which will make the file size bigger than it should be (data URIs are the same way). You can add attachments as binary, but you'll have to manually do that with a hex editor or create a tool and support for it by clients might not be as good.
Of course, if you want to use what browsers generate, MHT (Opera and IE at least) might be better.
i see no excuse to use anything other than a zipfile
Well, if browser support and ease of editing are the biggest concerns I think you are stuck with the file+directory approach unless you are willing to provide an editor for the single file format and live with not very good support in browsers.
You can create a single file by compressing the contents. You can also create a parent directory to ease handling.
The problem is that html is bottoms up not top down. Look at your file name which saved on my box as "What's the best "file format" for saving complete web pages (images, etc.) in a single archive? - Stack Overflow.html"
Just add a '|' and one has trouble doing copy and paste backups to a spare drive. In the end you end up. chopping the file name in order to save it. Dozens/ perhaps hundreds of identical index.html or index.php are cluttering my drives.
The partial solution is to write you own CMS and use scripts to map all relevant files to a flat file database - then use fileName, size, mtime and md5 to get a unique Id for each file. Create a flat file index permitting 100k or 1000k records. The goal is to write once and use many times. So you need a real CMS you need a unique id based on content (eg index8765432.html) that goes in your files_archive. Ditto for the others. Then you can non-destructively symlink from the saved original html to the files_archive and just recreate the file using a php or alternative script if need be. Don't know if it will work as I'm at the same point you're at - maybe in a week will know for sure. The more useful approach is to have a top down structure based on your business or personal wants and related tasks. So your files might be organized top down but external ones bottom up to preserve the original content. My interest is in Web 3.0 services and the closer you get to machine to machine interaction the greater the need to structure the information. Maybe time to rethink the idea of bundling everything into a single file. So you have hundreds of main.css why bundle when a top down solution might let you modify one file instead of hundreds.
I have a requirement to be able to provide a flex component in English and several asian languages. I have looked at the flex documentation and it seems that I have to build several swf's, which feels wrong.
Does anyone know of a straightforward and practical way of bundling string resources in different languages and handling the fonts?
I guess you know the basics of how to localize a Flex application, but if you would like to know more there's a good and thorough description here: Runtime Localization.
In Flex 3 you have three options on how to solve your problem:
compile all languages into the SWF and switch language at runtime
compile a separate SWF for each language
compile no, or a default, language into the SWF and load additional languages at runtime
The first option is probably the most common, the least complex and doesn't have many drawbacks. The other two can be used if you have special needs, like having to keep down the size of the SWF at all cost, or need to load all strings from a database at runtime.
To implement the first option you create a resource bundle for each language (basically a number of .properties files that lives in a directory named after the locale, for example en_US for US English or sv_SE for Swedish). In the code you refer to strings by calling the resource manager:
<Label text="{resourceManager.getString('mybundle', 'mystring")'}/>
That will retrieve a string called "mystring" in the resource bundle compiled from "mybundle.properties" in the current locale.
To make sure each locale is actually compiled into the application you add -locale=en_US,sv_SE to the compiler flags (but change the en_US,sv_SE part to the languages you have resource bundles for). You also need to add the location of the directories to the source path: -source-path+=locale/{locale} (the "{locale}" part will automatically be replaced by the values of the -locale flag).
Now you have compiled all your languages into the SWF and can change languages at runtime. The way to do that is to modify the localeChain property of the resource manager:
resourceManager.localeChain = ["sv_SE", "en_US"];
With the settings shown above the resource manager will first look in the Swedish resource bundle, and secondly in the one for US English. You can set another order at any time, and doing so will change all texts in the application then and there.
I encourage you to read the description I referred to above, it explains this in greater detail, and most likely in a more understandable way. It also explains how to do some preparations you need to do before you can compile applications with locales other than en_US.
The other problem you have is with fonts. That one is trickier. The best thing would be to have a font that had the full Unicode range of characters, that way you would only need to embed that and any text could be displayed. However, that means that your options are a bit more limited. I know that there is at least one version of Aria in Windows that has an enourmous number of characters, and on the Mac there is a Helvetica (I think, or it might be Lucida Grande, or both) that also has most of the ones you need to display many asian languages.
Embedding all languages into the same SWF usually does very little to increase the file size, because text is very lightweight, but fonts are definitely not. Embedding a the whole Unicode version of Arial can increase the file size of a SWF by several megabyte, which kind of sucks for web applications. Depending on the situation you may have to compile one SWF per language, just because the font data would otherwise make the SWF unwieldy.
Beware of fonts. System fonts aren't the prettiest but Asian fonts are too large to embed. We resorted to embedding Latin fonts for English and switching to system fonts for Chinese.
Be careful about rotating system fonts - your text will disappear. I think Flash 10 might have fixed this.
Also, be very careful with the font string you specify for Chinese.
Most OSes have nifty fall-back logic - if you specify Trebuchet and try to render a Chinese character, your OS might decide to use some Asian font instead. Flash seems to mess up this fall-back logic and switch between two or more Asian fonts dynamically. We had cases where mousing over a text block would switch the font.
To fix this, specify a font which includes all the characters you need (without falling back to some other font). You will need to test this across OSes, etc.
We use Flex for the client part of our application and support I18N via ResourceBundles.
In Flex 2.01 the language has to be built into the SWF - you can't change it at runtime. In Flex 3 you can switch language at runtime.
http://labs.adobe.com/wiki/index.php/Flex_3:Feature_Introductions:_Runtime_Localization
An important step left out above is to run the command:
copylocale.exe en_US sv_SE
from the bin folder of the sdk. This is in the article though.