The closest documentation I could find was about WindowGroup. I came across this when I was looking at how to convert a View into a bitmap.
The documentation on what is being represented here UIApplication.shared.windows[0].rootViewController.view is pretty scarce which I believe is because they weren't expecting people to access it. Could someone give me a breakdown of what windows are? How is it different from views?
Think about a PC or a Mac
A window consists of a frame area and body area that lets the user view and interact with content in an app. A window can appear onscreen alongside other windows, or it can fill the entire screen.
https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/window-anatomy/
https://developer.apple.com/documentation/swiftui/windowgroup
Imagine 2 Safari windows or 2 Xcode windows.
A Window contains Views such as buttons, menus, lists, images, etc.
UIApplication.shared.windows[0].rootViewController.view
Is UIKit based code not SwiftUI, you won't find any documentation on it with the SwiftUI Framework documentation but there are plenty of "old" references that break down what it is.
https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/TheViewControllerHierarchy.html
Related
I have lots of views - sub classes (UILabel, UIVIew, UIButton etc) using core graphics (within drawrect).
These show fine within normal interface builder.
However they do not show in the preview assistant editor for the storyboard (where you can see how views should look on actual devices).
I've been doing some research and found posts suggesting prepareForInterfaceBuilder should be used. However this doesn't show in preview for me.
I asked this question some years ago, IB_DESIGNABLE, having views show in preview? however I can't reproduce this, I'm not convinced it did work back then either.
I'm still following the same approach, with a framework and that link shows my implementation.
I know that prepareForInterfaceBuilder should be used to do something different, to show something basic. Therefore I believe that core graphics won't work.
However, I can't even get a simple change in background color to work in the preview, although it does work in normal interface builder.
I would like to know if this is a bug (that core graphics can not be used in preview) or still a limitation in xcode?
At the very least I'd like to do something simple (like a change in background color). I have a lot of views and an impossible task to make auto layout changes.
Previously I was producing lots of screen shots, different devices, languages etc (via automation) just so I could see my auto layout changes, which is really slow way to work.
I can verify this is a long standing bug. Apple doesn't care. Custom view be damned. All those dollars spent for more broken Xcode functionality.
Android?
Daniel
This is the first time I have really attempted a Project using Firemonkey, with the Target Platform been Android.
I am finding it difficult trying to understand the workflow with the use of views been somewhat trivial, I just can't seem to grasp the concept at the moment.
I have successfully managed to get the Delphi IDE to recognise my device (Xperia Z2) so when building and running the Project I can see the app on my phone (although so far I am not too impressed, long black screens before anything showing and sometimes the app wont show at all, not to mention slow compilation and linking time).
The first problem I ran into is that controls dont appear on the Android device in the correct places. I added Android 5" Phone as a view as that would be the closest thing to my device, the controls on the Form Designer are aligned to how I want them, for simple testing I just dropped a couple of buttons that are centered in the middle of the form horizontally. When running and viewing the app on my phone however, the buttons are wider than the visible area of the phone, I tried the same with other views such as Android 4" Phone and it's the same. The controls appear lined up correctly on the Delphi Form Designer, but when running and viewing them on my phone they are not lined up at all, it feels like I need to guess where the controls should appear making views seem pointless, after all I cannot test on a multitude of devices and therefore if they don't appear on my phone as they do on the Delphi Form Designer what hope do we have? I expected that how the controls appeared in the view window is exactly how it should appear on my Android deivce but this does not seem the case.
The other view related question is, what is the purpose of the Master View? From my vague understanding you need views to design the layout for each Android device, does this mean then for each device view we have to constantly reposition and move controls independantly for each view? What purpose does the master view have, other than from what I can tell you can only delete controls from the master view and from each view use the Revert to Inherited context menu.
It feels like I need to guess where the controls should appear, the device view at Design Time seems rather inaccurate, surely how you look at the device view on the Form Designer is exactly how it should appear on your Android device?
I need your suggestions how to organize and make a nice, graphical user interface.
Now I have something like this:
There is a tree view (it takes a big space...) as a menu with assigned frames to each item. All frames have control buttons (a tool bar) and something from this list: list views, string grids, progress bars, memos, rich edits, web browser, color pickers, list boxes, labels, edits etc.
I don't have enough experience to create a good, easy and graphical UI, and I do not have any ideas what to make.
The most hard thing for me is I need to create a nice SDI, but the present UI is similar to a MDI (frames with lots controls are instead of windows).
So I'm trying to copy an UI from other soft: http://www.addictivetips.com/windows-tips/150-best-windows-applications-of-year-2010-editors-pick/ + SCREEN SHOTS. But I cannot find something appropriate for me :(
Added:
I have an idea to use a glass effect (a "menu" instead of a tree view on the left), but it looks complicatedly: buttons on a glass and buttons below (a tool bar).
Another version:
Please, advice me what to do or give me a direction. Thanks!
Consider that most monitors are now 16/10 or 16/9, i.e. not in 4/3 aspect ratio any more.
Therefore, it's not a loss of space to put a tree on the left, or even the commands toolbar on the left side instead of the top of the window. Your first screenshot was not the worse, in this aspect. I just write a log viewer with this design: the log events has the full application height.
Office 2007/2010 ribbon for instance is nice looking, but takes too much vertical space IMHO on daily use. Some users (among me) are frustrated by this ribbon. For instance, I don't find it very usable in a notebook. Greatest user interfaces gives full space to content, not commands. Chrome is a good example of this. And mobile applications tend to maximize the available space use.
Just my 2 cents.
Personally speaking, about your first screen shot, the toolbar buttons are too big. They are much too strong a presence, even at second glance.
I would reduce their size. Or, when this program targets children or touching devices, the other controls and font sizes should be enlarged.
You are trying to create a tabbed application, So I'd suggest using some sort of tab-control.
Even the Delphi default one allows you to add pictures to the tabs.
Something like this:
A few considerations:
How often is the app used?
If the app will be used very daily by your users, try to maximize usable space, i.e. make the controls as small as need be.
If the app is used rarely by your users, make the controls big and bright, label every button so things are clear, and time figuring out where is what is minimized, this also means using familiar user interface elements.
Are you targeting elephants or mice?
If you audience is computer savvy (mice), you can get away with more experiments and bling; if you are dealing with perpetual beginners you will need to stick to basic stuff.
Remember, the user interface is a contract
Make sure the controls behave as advertised. If something looks like a button make it behave like a button. Don't disguise a menu to look like a listbox/treeview.
A menu does an action (it's a hidden button), a listbox selects one item that can be acted upon.
My opinion
I dislike your initial screenshot because it tries to force a tabsheet/pagecontrol into the format of a treeview, whilst naming the items menus. This makes for a clumsy interface.
I've never seen a menu be used to switch between views, and the treeview makes for a mighty small target to hid. On top of that it allows for multiple nesting.
The tree is a concept that every programmer understands, but very few people outside that group grok, IMHO, don't use a tree in your application! and avoid the treeview.
It's a poor control to work with because:
It allows nesting > 2 a NONO in my book;
It is too small to hit with a mouse, even worse with a touchpad;
What's up with the [>] sign in front, why would I want to collapse a tree with just 1 level of nesting and when I do and the [+] is visible in front of "main menu" where on earth have my submenu items gone?
I love your last version, but
It needs text labels for every button;
Make the vertical pagecontrol, look like some sort of tabbed sheet, this will make your intent instantly clear;
I would love to see a statusbar;
Glass may look cool, but having the junk from screens below shine through your app sure makes everything look busy, not a good thing if you're trying to focus on this particular app;
Make sure to put splitters between all panels, and make sure to visually highlight the splitter by setting beveled:= true and width/height:= 5 so you can actually hit that splitter
The info panel has its own caption, a huge waste of space. It's bad enough that every window has a title bar that does almost nothing, don't multiply non-interactive space.
Finally
Do as David says and buy a copy of about face, it's the best book on UI design I've seen by far. http://www.cooper.com/#about:books
First picture is the best version for standard desktops with mouse.
Third picture will be good for tablets with their touch screens. But it needs some improvements. Currently I can't see on which page I am now, even more: there are no signs that those buttons actually switch pages. I think, you need some sort of tabcontrol here.
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.