Is there a way to use actual iOS controls inside a Qt application? As one specific example, there is a switch control in iOS that has a very specific look that is quite different from the look of the Qml switch and I don't there is a QWidget that does quite the same thing (QCheckBox is probably the closest).
Creating my own control where I build all the UI pieces so it looks like the actual iOS control is not an option, as one of the requirements I've been given is that the resulting program should match the control style of whichever iOS version it's installed on (within reason of course).
Some ideas:
Find out if there's a way for iOS to render a control off-screen to a buffer. Then use that as an image for your control.
Make a proxy for the native control, and overlay it on top of your UI. The proxy should relay the position from QML to native, and the size and state from native to QML.
Have a short lived (could be just one frame) screen that renders the controls you wish, in the states you need, then capture that. This only makes sense if you can't render the controls off-screen.
Related
According to this page, https://docs.unity3d.com/Manual/iphone-basic.html, too many UnityGUI elements is considered bad, but what is too many if my game runs entirely on the canvas? At the moment, my UI will contain about 100 objects, most are buttons and 80 of the objects, use full or portions of 3 textures to display the objects.
Does this mean that uGUI cannot or should not be used for iOS games?
That post is talking about something totally different and you are confusing yourself with uGUI and UnityGUI/IMGUI.
UnityGUI/IMGUI is an old UI System. That's what the article is talking about. Don't use it. I've been warning new users about that too due and they use it due to old tutorials they are following.
The only time you should use this is when you are writing an Editor script to test your game in the Editor but this should never be deployed to your mobile device or used as a standalone build.
How to know when you are using UnityGUI/IMGUI or which tutorials to avoid? When you see OnGUI() anywhere in the code, then stop.
The latest UI System in Unity is simply called uGUI. I don't know if the name has changed but this was the original name when it came out. It is only available from Unity 4.6 and above. You can find this from the UnityEngine.UI; namespace.
This is the link you should be reading for the new UI and here for UI tutorials.
Does this mean that uGUI cannot or should not be used for iOS games?
uGUI should be used for all your UI work.Again, I am not talking about the UI from the article. I am talking about the UI from the UnityEngine.UI; namespace.
my UI will contain about 100 objects, most are buttons and 80 of the
objects
uGUI uses Canvas to drive the UI and they are parent GameObject of UI components.. You may want to separate them into different Canvas. For example, MainMenu Canvas, PauseMenu Canvas, GamePlay Canvas.... Under each Canvas, you can then have your components such as Buttons and Texts.
When you are on the main menu, you enable the MainMenu Canvas and disable the rest. You can do this for your other Canvas in your scene depending on the mode of your game. I can't think of any scenario where you need 80 UI components at the-same time, on the scene. You must separate them.
I want to build a mobile application in Delphi, but I can't seem to figure out how to handle multiple screen sizes. AndroidStudio has a nice relative layout for this, but I can't find anything alike for delphi. Am I supposed to build a multiple form designs for each screen size?
I'm using XE6, I am requoired to use Delphi as the programming language.
I have already figured it out, you have to use the Align property on every single control you add to the form.
Using trigger.io, is there a way of specifying a web view for the header area?
I currently have a rather complex header that utilises media queries and includes an input box depending on the current screen width. This extends far beyond what the trigger.io's native topbar implementation is capable of so I was wondering if this is possible or is potentially planned?
At the moment I'm utilizing position fixed for devices that are known to support it, but it would be nice to have full support on all devices (mainly Android 2.3>*).
What commonly expected user-visible design idioms need to change from an iPad app to a Mac app for an app, that is to provide basically identical functionality, to seem at least reasonably Mac OS X native?
Some of these changes, commonly expected by users, might include:
Move the Settings button and Info button to Menu selections for Preferences... and About...
Move the Settings view and Info view or popover to their own independent Preferences and About windows instead of being views in the main window.
Add some menu items and menu keys for commonly used buttons (like the forward and back buttons in a browser).
Support arrow keys for scrolling any custom view items.
Support mouse-over for help popups or dynamic menus.
If the app supports "documents", allow more than one document to be open at a time, each in their own windows.
What else? What's the minimum change required for a simple generic 2D game?
Added clarifications:
Note that I do not consider re-coding similar UI classes to NS classes (for instance UIButtons to NSButtons), with similar look, positions and behaviors, to be a significant change. Those changes are pretty much invisible to the user.
The goal is to change as little as possible so that a user who purchased app X to do Y on an iPad might purchase app X to do Y on their Mac, as a Mac application, but with as close to zero learning curve as possible. But it seems that some changes need to be made, or the app would not seem to be a Mac app (for instance, a missing About... menu item would seem a bit strange.)
to provide basically identical
functionality, to seem at least
reasonably Mac OS X native?
You've gone off the rails right there. Consider adding this to your list:
Forget everything you know about how your iPad app works. Step back and consider that a user's interaction with and expectation of a desktop application are very different from those of a tablet. Re-think what you're able to do and what the user will want to do with a faster processor, more power, significantly more available storage, less mobility, much faster text entry, and a different user interface model.
We are in the same boat and faced the same question.
Our conclusion is to start with a "fresh" real application for Mac and make it look similar, i.e. using the same or similar UI components and graphics. The app should be otherwise developed as if there was no iPad version.
First, there will be many users that don't have the iPad version. Those users expect a full-blown Mac application and it doesn't make sense to make it feel iPad in any way.
Second, users coming from the iPad version will feel ripped of if the Mac app is just a pure clone of the iPad version with no added value. Think of the first transitions from iPhone to iPad - paying again for nothing but pure upscales is frustrating and might harm your business in the long run.
Starting out designing a fresh streamlined UI and then think of what you can reuse and make similar. Functionality may differ in one direction or the other. Your model code should work in all places anyway.
Not exactly an answer to your question, but take a look at Chameleon. It's essentially a port of UIKit to the Mac. It was created by The Icon Factory to make it easy for developers to port their iOS apps to the Mac. IIRC Twitterific was ported to the Mac using Chameleon.
So here's what I did to create a Mac app from an iPad app, and have it accepted into the Mac App store.
Ignored the suggestions to completely redesign the app (users reasonably liked the iPad design).
Create a Mac app project and include a branch of all the iOS source code.
Manually recode all the UI elements with their corresponding NS elements. Resize them to Mac UI guideline sizes. Check that they all show up in some reasonable place when the main window is resized. Deleted iPad only delegates, such as rotation handlers, etc. This resulted in completely new view controller code, but almost all the code was just a parallel translation of the other paradigm.
Set the view coordinates to flipped so the Y coordinates won't have to be recalculated for any Core Graphics drawing routines. (The Model and CG drawing code pretty much ported straight over without change, except for scale factors for window size, and such.)
Remove settings and help views from the main window view controller(s). Implement a Preferences window xib and a Help window xib, and put all the settings and pref views and controls there. Add one more top level controller to show/hide the 3 windows.
Add some menu selections with hotkeys for equivalent UIButton actions that a user might want to hit without reaching for the mouse/trackpad.
Add a credits.html file.
Add an outline shape and transparency masks to the icon design, and stuff into an .icns file.
Pad the one window screen shot out to the much larger required size.
For accessibility purposes, I need to make the scrollbars for all scrollable controls (lists, list views) wider and the scrollbar arrows bigger.
How to get the scrollbars (handles) from a scrollable control (ex: TListView) ?
How to make the scrollbar and the arrows wider/bigger ?
10x for any hints and code...
Accessibility is something that does not concern a single application, but the whole system. That's why there is no API defined to adjust things like border widths, scrollbar size and similar properties of the native controls only for your program. You can however adjust these settings globally in Windows, either by using the Accessibility Wizard, or by adjusting fonts, colours, border sizes and scrollbar sizes in the Display Properties applet.
For more information you should check out the Microsoft Accessibility page and follow the various links.
Edit: Changing the global settings (as the accepted answer suggests) for the benefit of your own program is rude in the extreme. Please keep in mind that this interferes with all other running programs. It is maybe excusable for a system with a touch screen, where controls need to be large to be usable at all - but on such a system the control sizes would probably already be set correctly.
I'm not sure that you can - You have to change it (and restore back) for whole Windows.
http://www.greatis.com/delphicb/tips/lib/system-captionfont.html
Setting and reading property TNonClientMetrics.iScrollWidth
Edit: I know that this solution is rude, but in common cases is the best that you CAN do. If you have specialized TabletPC application then you usually use only that application at one time, not others. But - almost all Windows applications are not designed to work with so big scroolbars. So when you need to use OS dialogs and other applications then you have to switch it back.
There is no better solution than "while is my touchscreen application running set Window scroolbars big, then return it back". We have exactly this application in real world so I know what I'm talking about.
Of course you can write your own grid control (if you have so much time) or use some thirdparty controls (if you have money and time), but that was not question.