I am developing an application in Qt5. when I deployed it on the machine on which it is developed it looks fine. But when I deployed it on laptop with higher resolution, the size of components like QPushButtons etc,reduces.Please help me, I have no idea why it is happening.
I'm not sure how are you specifying the size but, maybe you are using fixed sizes? If so, when deploying on a higher resolution display the interface is apparently smaller but in fact has the same size than in the smaller resolution display.
Try using relative sizes or at list show how you are setting the size right now
Related
I have an application that uses Qt 5.6 for various purposes and that runs on an embedded device. Currently I have it rendering via eglfs to a Linux frame buffer on an attached display but I also want to be able to grab the data and send it to a single-color LED display unit (a device will either have that unit or a full video device, never both at the same time).
Based on what I've found on the net so far, the best approach is to:
turn off anti-aliasing;
set Qt up for 1 bit/pixel display device;
select a 1bpp font, no grey-scale allowed; and
somehow capture the graphics scene that Qt produces so I can transfer it to the display unit.
It's just that last one I'm having issues with. I suspect I need to create a surface of some description and inject that into the Qt display "stack", but I cannot find any good examples on how to do this.
How does one do this and, assuming I have it right, is there a synchronisation method used to ensure I'm only getting complete buffers from the surface (i.e., no tearing)?
I'm new to UWP (windows 10), working on an app for windows phone, I wanted to know what is the difference between:
Using multiple frames and navigate from one to other.
Using a single xaml with no frames but with multiple grids (or other patterns), and instead of navigate- just change visibility so only the desired grid will be visible.
which option is better? and why?
The system keeps track of the Page you are currently on. So even when your App exists and even if it's removed from memory the OS can tell the App to reopen on that page.
Similarily when your App provides other Apps with the capability of calling into it to open certain file types of to perform certain actions (e.g. start navigation, etc.) pages will be used.
Lastly if you put everything on a single page and just manipulate visibility this will increase memory consumption of your App (as everything needs to be loaded even if it's not visible) and it also might increase load times.
Of course how much that impacts you is up to the type of App you are building. In general however I'd advice you to start building using separate pages in case your App grows. Also you get a lot of stuff out of the box if you do so (e.g. animated transitions, etc.)
I have developed Windows 8 application. and when I try to run it , to test it on another laptop ; the design got worst and everything appear in bad way.(Fonts, images, ..)
Is that related to the resolution ? If yes How I can solve it ?
How was your app developed? Is this a xaml/cs app or html/js app for windows 8 store apps? Is it in the store yet or only testing? Are multiple resolutions supported?
You'll want to test out various resolutions to see how your app handles them. Two links to test out here with your application:
Windows Store app Development Snack: Simulator tips & tricks
Scaling to different screensre
Another area to check is pixel density. Follow the guidelines for scaling to pixel density to ensure your app looks great when scaled.
Hi I am developing a Windows 8 C# / Xaml Metro application. I have taken grid template project and customized to my design requirement.
When I am testing the application in Windows 8 simulator it works fine, but when I run the application in Windows 8 desktop using VS2012 local machine option I am facing many problems.
If I am using standard resolution of 1366 * 768 it works fine.
If I am using a low resolution like 1280 * 720 etc (low end resolutions), the screen shrinking in many cases and it causes many problem, including irregular and inconsistent look.
My doubt is:
As per my knowledge is that Metro unique feature is to scale/render in different resolutions in same way, then why is it not able to achieve it properly?
Am I missing anything very important regarding Windows 8 Metro screen resolution?
How to make the Metro app work in different resolutions of desktop in same way and give a consistent look?
Please let me know.
Thanks in advance.
This MSDN article is an excellent source on how to scale your app:
Scaling To Different Screens
Points from the article that may be relavent to you:
The minimum screen resolution for an app is 1024 x 768. Your resolution above (1280 x 720) does not meet this minimum.
For the grid graphics - it may help if you provide the suggested sizes of (100%, 140%, and 180%). For example, for the standard grid size (250 x 250), you should provide images of the sizes of 250 x 250 (100%), 350 x 350 (140%), and 450 x 450 (180%). You have to use one of the two naming schemes (file name scheme, or folder name scheme) for your app to automatically select the size. For example, if your graphic in the xaml is named "mygraphic.jpg", then you can provide the scaled images named "mygraphic.scale-100.jpg", "mygraphic.scale-140.jpg", and "mygraphic.scale-180.jpg".
Since you are not very specific in indicating what is wrong, it is hard to suggest other things. Definitely take a look at the article.
Wrap your content panel in a Viewbox. It will scale the content to fill the available space.
i have 2 issues.
my app has a high quality images, and i enabled the retina display(using cocos2d), so every png has the hd : image-hd.png .
my first question is, if want it to fit also iphones under 4 (3gs) i must have all my images again in the 320x480 without the -hd ?
i have sooo many images, and this way seems strange to me, cause it doubles the app size!
another thing. my app size on disk is BIG, but i have discovered that there is a folder init that called: build, which is 136Mb ! it has simulator and debug files that are not mine.
how would i get ride of this folder that is so big ?? my app is 30mb only !
thanks a lot
i must have all my images again in the 320x480 without the -hd ?
Yes. If you want your game to work with non-Retina devices, then for each xxxx-hd.png you must provide a corresponding xxxx.png file.
this way seems strange to me, cause it doubles the app size!
It doesn't double it. It depends a little on the type of files (PNG, JPG) and how well the images can be compressed. Uncompressed, an SD image is a quarter of the size of an HD image. So you're more likely looking at an increase of app size by 25%. If your HD assets weigh in at 100 MB, your SD assets will add roughly around 25 MB to the app size.
my app size on disk is BIG, but i have discovered that there is a
folder init that called: build, which is 136Mb ! it has simulator and
debug files that are not mine.
These are temporary build files created by Xcode. Don't delete them because Xcode will recreate the files anyway.
The size of your .app is the only file size you should be considering. Furthermore, you should ignore the size of your .app in debug builds, which is what you've been looking at. The only app size from which you can determine (or guesstimate) the final app size on the App Store is the app created by an Archive build.
Run Product -> Archive with a iOS device selected as your current configuration (otherwise Archive is grayed out). When it's done, the Xcode Organizer will open and highlight the newly created archive. Right click it and select "Show in Finder". There may be several .xcarchive files in this folder, select the latest one and right click it, then select "Show Package Contents". Navigate to Product/Applications which will show your .app and its size. This is the only size of your app you should ever give any consideration.
However, this is not the final size of your app on the App Store, since the .app bundle will be compressed (making it smaller) and at the same time the executable will be crypted (making it impossible to compress). I once wrote an article about how to determine your app's final App Store size that I think still holds true today. In essence, you copy the .app bundle, remove the executable from the bundle, compress the bundle, then add the size of the compressed bundle and the size of the executable and the result is a good approximation of your app's size on the App Store.
You need to give a name for HD image with prefix #2x, for example image#2x.png. Leave normal name for images in order to support lower versions of iOS - image.png. In code or Interface Builder you have to use only normal named images (all another things will be executed automatically).
The short answer to the 'images' part of the question is YES , you should include the normal sized files. The artwork is probably different with the two resolutions (I am not a graphics expert, but i suspect there is a lot more to it than resizing the image). The whole point of implementing the "-hd" suffix was to have the ability to deploy a single bundle that works seamlessly for Retina and non Retina displays. I just had a requirements change to go from SD to SD+HD on one of my products ... errr ... now both the artists and the softies are in a mad rush to do just that : create the artwork and make certain all is well (ie no missing resources). Best of luck with your own requirements change.