I am working on a macOS app and I programmatically adding NSToolbarItems following Apple's documentation and I am adding the new NSTrackingSeparatorToolbarItem to support the new macOS 11 toolbar look and feel.
The tracking separator seems to work fine as long as I don't resize the split view below a certain width, then the separator breaks out and just looks out of place.
The tracking separator working as expected
And the separator breaking out when the split view size is below a certain width.
Is there a way to avoid this?? I know that I can set a minimum size for the split view, but is there a way to keep them synchronized (I don't want to hard code a minimum width)?? Especially if the user adds toolbar items dynamically.
Thanks in advance.
Ok I think I figured it out...
I noticed a interesting behavior when playing around with the Mail app, which when the preview pane is showing the NSTrackingSeparatorToolbarItem follow the resizing of the split views but the moment the preview is collapsed the toolbar changes appearance and becomes like a static toolbar. Furthermore the NSTrackingSeparatorToolbarItem stays in place and looks just like a normal toolbar separator (like you might find on other OS's).
So I played around in IB with my toolbar and discovered my error, my NSWindow had the titlebar set to transparent!!
I unchecked the option and voila I could replicate the look and feel of the Mail app, all automatically.
this property has to be set to false in NSWindow
#available(macOS 10.10, *)
open var titlebarAppearsTransparent: Bool
And of course the toolbar style should be set to unified
#available(macOS 11.0, *)
public enum ToolbarStyle : Int {
// The default value. The style will be determined by the window's given configuration
case automatic = 0
// The toolbar will appear below the window title
case expanded = 1
// The toolbar will appear below the window title and the items in the toolbar will attempt to have equal widths when possible
case preference = 2
// The window title will appear inline with the toolbar when visible
case unified = 3
// Same as NSWindowToolbarStyleUnified, but with reduced margins in the toolbar allowing more focus to be on the contents of the window
case unifiedCompact = 4
}
Please note that the break out behavior still occurs but when this happens the toolbar changes look and feel and you don't see any ugly split view divider line like I had experienced. Hope this helps anyone else who might run into this issue.
In IB I have quite a few views that are shown. Many of them are hidden when the app loads, but are shown later when buttons are pressed. This is all fine, but when building this layout in IB it is extremely difficult to layout anything because there are so many overlapping views, some of which are partially transparent (ones that are set to hidden) and other are completely overlapping and covering others. This makes layout very hard.
What is the best method when laying out lots of views like this? Is there another way to break things up? Or better yet, can I hide a a view completely (like in photoshop) so that I can edit the ones underneath, then turn that layer back on?
Another option when trying to select a view that is obscured by another is the shortcut:
'ctrl' + 'shift' and click
It displays a list of all the views under the cursor.
I'm not aware of any way to hide objects in the canvas, but a useful trick for complex layouts is to double-click an item in the document tree to the left - this selects the item and puts focus on the canvas, you can the use the cursor keys to nudge it about.
This doesnt solve the problem of not being able to see things because there are, for example, five or six labels occupying the same space, but if that is the situation it may be a better idea to have a single label and change its contents in code.
I ran into this issue for an app I'm building that has an arial-view image of a park with clickable hotspots. When a hotspot is clicked a popup UIview is displayed with information about that spot in the park. I use the same VC/XIB for three parks. This makes the XIB really busy and hard to work with (i.e the same issue that you have) The detail UIViews make it hard to work with the views underneath. My workaround was to pick each detailed UIView that was hiding the part of the XIB I wanted to work on, and add 1000 to the UIView origin.x in the size inspector. This moved those UIViews enough out of the way for me to do what I needed to with the XIB. Then when I was done, I moved them back by x 1000. (I just needed to move them out horizontally to do what I needed to)
I know its clunky but given that XCode does not have a convenient way to hide portions of an XIB - it was the quickest approach I could think of!
One approach to handling overlapping items in IB is:
Ensure the groups of items that you want to hide are grouped into Views.
Give these Views names: e.g. ViewOptionA, ViewOptionB and ViewOptionC.
Can do this by clicking on name of view in the tree while it is selected and then typing new name.
When you want to hide one of those groups of items:
a) Select the View by either:
i) Clicking on it in the tree at the left or
ii) Ctrl-Shift Clicking in the layout editor and then select the view from the list.
b) In the Attributes Inspector set Alpha to 0.
When you want to unhide one of those groups of items:
As for 2) but set Alpha back to 1
[You do need to remember to unhide all views before you publish!
If you are forgetful like me then perhaps you could subclass UIView and set Alpha to 1. I haven't tried this subclassing idea yet.]
Just getting started on iPhone dev today and have run through Apple's HelloWorld tutorial:
http://developer.apple.com/iphone/library/documentation/iPhone/Conceptual/iPhone101/Articles/02_CreatingProject.html#//apple_ref/doc/uid/TP40007514-CH3-SW3
Couple of easy questions for you folks (sorry so long-winded but I'm hunting around in the dark here):
1) So I made MyViewController the delegate for the text field, in order to receive a message when the return key is pressed (textFieldShouldReturn). This seems inelegant because the method has to check which control sent the message. But to handle the touch event on the button the technique is different -- a custom message (changeGreeting) gets sent which could be associated with one or several buttons in Interface Builder, and I could create different messages for different buttons.
That seems much better and avoids the need to test in code which control sent the event. Why these two different approaches in the sample, is it just to demonstrate the two? Would it be possible to rewrite the sample only using the latter approach, or is there something fundamentally different between the text field's textFieldShouldReturn and the button's 'Touch Up' that mandates making the view controller a delegate for the text field?
2) When I position the text field near the top of the view, if it's a certain vertical displacement away from the grey status bar with the battery status symbol then it locks into place and you can see the vertical blue dashed line indicating the lock. In this mode, when I run the app the text field is too high, hard up against the status bar. I can resolve this by moving the text field very slightly so that the vertical dashed blue line no longer appears. Then the positioning seems relative to whatever's above the text field, as I can select a larger Top Bar in the Simulated UI Elements and it moves down nicely.
I'd expect to see some explicit property in the Attributes Inspector that says whether the layout is relative or absolute, but I can't find anything that changes between the two scenarios. Surely this is made more explicit somewhere in the Interface Builder UI?
Hope these Q's represent some easy points for someone...
1) You can connect the UITextField "Did End On Exit" event to an IBAction, similar to the Buttons "Touch Up".
The benefit of using the delegate is that you get a higher level of interaction for free with the UITextfield, without having to assign every event to an IBAction in interface builder.
2) In the Interface Builder Inspector, on the size tab (the little ruler icon) there are a set of controls which allow you to set the automatic positioning of a subview. I believe you are interested in the "Autosizing" section.
I am using UISearchDisplayController to implement the search feature on a table view. My table view cell uses custom background image.
When you first type a letter into the search textfield, the search results start appearing. However, when I click cancel at this point, the screen flashes white. This is not as noticeable if everything uses the standard white, but since my table view cell uses custom background, the white flashing is quite noticeable.
Where is this flashing coming from? Is there anything I can do to remove this flashing? (You can see this flashing on standard Apple apps too but it may not be very obvious if the table view uses white background)
Another SO post mentioned this very problem too - Customize UISearchDisplayController (search for the word "Flash")
Found a good work around for this here at Apple's Dev Forums.
Basically, the flash is by design and there isn't any way to customize/disable it. However, the poster in the link came up with a simple work around -- remove the search display table view all together (removeFromSuperView). Works absolutely fine for me.
Does anyone have any examples or resources where i might find information on scrolling text which is too long to display in a button control? I'm thinking something along these lines.
Display as much text will fit within the current rect with a '...' at the end to signify overflow.
Pause for say 1 second then slowly scroll the text to the right edge displaying the right part of the string.
Display as much text will fit within the current rect with a '...' at the beginning to signify overflow.
Start the whole thing over in reverse.
Is there an easy way to do this using the "core" or built in "animation" frameworks on a certain mobile device?
[edit]
Iwanted to add some more details as i think people are more focused on wether or not what i'm trying to accomplish is appropriate. The button is for the answers on a trivia game. It does not perform any speciffic UI function but is for displaying the answer. Apple themselves is doing this in their iQuiz trivia game on the iPod Nano and i think its a pretty elegant solution to answers that are longer than the width of my button.
In case its the '...' that is the difficult part of this. Lets say i removed this requirement. Could i have the label for the button be full sized but clipped to the client rect of the button and use some animation methods to scroll it within the clipping rect? This would give me almost the same effect minus the ellipses.
Here's an idea: instead of ellipses (...), use a gradient on each side, so the extra text fades away into the background color. Then you could do this with three CALayers: one for the text and two for fade effect.
The fade masks would just be rectangles with a gradient that goes from transparent to the background color. They should be positioned above the text layer. The text would be drawn on the text layer, and then you just animate it sliding back and forth in the manner you describe. You can create a CGPath object describing the path and add it to a CAKeyframeAnimation object which you add to the text layer.
As for whether you think this is "easy" depends on how well you know Core Animation, but I think once you learn the API you'll find this isn't too bad and would be worth the trouble.
Without wishing to be obtuse, maybe you should rethink your problem. A button should have a clear and predictable function. It's not a place to store and display text. Perhaps you could have a description show on screen with a nice standard button below?
Update with source code example:
Here is some ready to use source code example (actually a full zipped Xcode project with image and nib files and some source code), not for the iPhone, not using Core Animation, just using a couple of simple NSImages and a NSImageView. It is just a cheap hack, it does not implement the full functionality you requested (sorry, but I don't feel like writing your source code for you :-P), horrible code layout (hey, I just hacked this together within a couple of minutes, so you can't expect any better ;-)) and it's just a demonstration how this can be done. It can be done with Core Animation, too, but this approach is simpler. Composing the button animation into a NSImageView is not as nice as subclassing a NSView and directly paint to its context, but it's much simpler (I just wanted to hack together the simplest solution possible). It will also not scroll back once it scrolled all the way to the right. Therefor you just need another method to scroll back and start another NSTimer that fires 2 seconds after you drew the dots to the left.
Just open the project in Xcode and hit run, that's all there is to do. Then have a look at the source code. It's really not that complicated (however, you may have to reformat it first, the layout sucks).
Update because of comment to my answer:
If you don't use Apple UI elements at all, I fail to see the problem. In that case your button is not even a button, it's just a clickable View (NSView if you use Cocoa). You can just sub-class NSView as MyAnswerView and overwrite the paint method to paint into the view whatever you wish. Multiline text, scrolling text, 3D text animated, it's completely up to your imagination.
Here's an example, showing how someone subclassed NSView to create a complete custom control that does not exist by default. The control looks like this:
See the funny thing in the upper left corner? That is a control. Here's how it works:
I hate to say that, as it is no answer to your question, but "Don't do that!". Apple has guidelines how to implement a user interface. While you are free to ignore them, Apple users are used to have UIs following these guidelines and not following them will create applications that Apple users find ugly and little appealing.
Here are Apple's Human Interface Guidelines
Let me quote from there
Push Button Contents and Labeling
A push button always contains text, it
does not contain an image. If you need
to display an icon or other image on a
button, use instead a bevel button,
described in “Bevel Buttons.”
The label on a push button should be a
verb or verb phrase that describes the
action it performs—Save, Close, Print,
Delete, Change Password, and so on. If
a push button acts on a single
setting, label the button as
specifically as possible; “Choose
Picture…,” for example, is more
helpful than “Choose…” Because buttons
initiate an immediate action, it
shouldn’t be necessary to use “now”
(Scan Now, for example) in the label.
Push button labels should have
title-style capitalization, as
described in “Capitalization of
Interface Element Labels and Text.” If
the push button immediately opens
another window, dialog, or application
to perform its action, you can use an
ellipsis in the label. For example,
Mail preferences displays a push
button that includes an ellipsis
because it opens .Mac system
preferences, as shown in Figure 15-8.
Buttons should contain a single verb or a verb phrase, not answers to trivia game! If you have between 2 and 5 answers, you should use Radio Buttons to have the user select the answer and an OK button to have the user accept the answer. For more than 5 answers, you should consider a Pop-up Selector instead according to guidelines, though I guess that would be rather ugly in this case.
You could consider using a table with just one column, one row per answer and each cell being multiline if the answer is very long and needs to break. So the user selects a table row by clicking on it, which highlights the table cell and then clicks on an OK button to finish. Alternatively, you can directly continue, as soon as the user selects any table cell (but that way you take the user any chance to correct an accidental click). On the other hand, tables with multiline cells are rather rare on MacOS X. The iPhone uses some, but usually with very little text (at most two lines).
Pretty sure you can't do that using the standard API, certainly not with UILineBreakMode. In addition, the style guide says that an ellipsis indicates that the button when pressed will ask you for more information -for example Open File... will ask for the name of a file. Your proposed use of ellipsis violates this guideline.
You'd need some custom logic to implement the behaviour you describe, but I don't think it's the way to go anyway.
This is not a very good UI practice, but if you still want to do it, your best bet is to do so via a clickable div styled to look like a button.
Set the width of the div to an explicit value, and its overflow to hidden, then use a script executing on an interval to adjust the scrollLeft property of this div.