I'm currently prototyping a potential app where the user would be managing a primary list. What I would like is for the ability of an alternate list to slide out so both lists would appear side by side. This would allow the user to transfer items between the two via drag and drop. Since the main workflow would be on the primary list most of the time, it seems like it would be cleaner if most of the time, the alternate list is hidden.
To me, it seems like using NSDrawer would be a good fit. However it's deprecated. And I'm assuming it's impossible to build an app which has an 'L' shape or inverted 'T' shape.
So I was thinking of potential alternatives which I could try out.
Some ones I though of were
Expanding the window width to accommodate a split view. And shrink when done
Create a new NSWindow but find a way to always pin it to the side. So if either window were moved, the other would move with it.
Just use another NSWindow and don't care about the pinning. In theory I could always open it next to the other window and let the user worry about managing any movement.
Has anyone had any success in replicating an NSDrawer type of alternative?
Related
I am developing a testing algorithm for our iOS apps using Appium. To fully implement this algorithm i need to identify wither i have moved onto different screen or am still on the same screen after performing some action. I need to know, what makes every screen unique/different from other in terms of Appium?
Going through the pageSource of every screen, i found that most screens have xpath attribute in window element. Can i use value of xpath of window element to mark the screen as unique from others, or do i need to do a trivial string comparison between screen's pageSources to mark them different? Or is there any other better solution?
Not sure if xpath would be the best solution for this. Normally the UIAWindow would remain the same, and developers might use different containers within this UIAWindow to render different screens.
So to verify different screens, you might need to figure out what this container is and see if the container's properties change when you move to a new screen (ie a new container)
If you app user a different header for every new screen, then you can use this header to see if the screen is changed. Example: in WhatsApp, you would see a different persons at the top. So in this case, the person's name can be assumed as the header.
If this doesn't work then you can verify some of the other controls, or say list of all the UIAStaticText on the screen. During screen change the entire list of UIAStaticText might change. So this can indicate a screen change.
For our automation suite at work I've implemented a series of screen check steps. Every time we switch screens I do a find_element command for an element on that screen that is unique to that screen. That way if a button or option takes me to a new screen that is incorrect my test will fail as expected. If it does find the element we're expecting it adds minimal time to the test suite.
Anish Pillai made a good suggestion of using the header text if there is any. Otherwise a particular tab, menu text, resource_id, or whatever is unique about the page would suffice. All you would need to do is a find_element call and a failure message if it fails.
For mouse I'm using:
ourEvent = CGEventCreate(None);
currentpos = CGEventGetLocation(ourEvent);
What can I use for the caret?
First the bad news.
Not every app is Cocoa-based, and those that are neither Cocoa nor Carbon nor a straight mix of the two—i.e., those based on wxWidgets, Qt, or some other cross-platform framework—typically reimplement the entire GUI stack on top of raw event and drawing primitives.
That means that there is typically no way to get this information from those applications (unless they're scriptable and expose it that way).
The good news is, Cocoa apps and some Carbon apps may expose this via Accessibility.
The user will need to have assistive devices turned on in System Preferences. Once that condition is met, you can use the Accessibility framework to get the frontmost application, get its focused window, get its focused view, and get its selection ranges.
A text view with an insertion point has exactly one selection range, and that range is empty (length=0). The location is where the insertion point is.
Of course, those are character indexes, not on-screen bounds.
That's where parameterized attributes come in. There's one for converting ranges to bounds. That's the one you want.
Theoretically (I haven't tried this), you should be able to convert the empty range of the insertion point to an empty or nearly-empty rectangle whose location is somewhere within the vertical line of the insertion point.
Make sure you test this with text views that are in scroll views, particularly when the insertion point is scrolled partially or completely out of view.
You'll want to use the Accessibility Inspector to see for yourself where your application will need to look, and to test individual applications and investigate reported failures.
You can get it from the Developer Downloads page, in the “Accessibility Tools” disk image.
If you want to focus a window, forging a mouse event to click on it is a bad idea—anything can happen if you click on the wrong thing. Send the window an kAXRaiseAction action instead.
If you want to set a text view's insertion point (and are looking to find where you need to forge a mouse event to click to set it in the desired position), again, that's a bad way to do it. Set the view's kAXSelectedTextRangesAttribute attribute instead. Again, an insertion point is a single empty range.
Did you try like this below?
NSPoint p=[[NSApp currentEvent]locationInWindow];
CGFloat X=p.x;
CGFloat Y=p.y;
NSLog(#"%f %f",X,Y);
I need to implement a threaded view of sorts in an old VB6 app. It should look similar to this:
So, it's like a TreeView of sorts but there are buttons on the right (for each row) that could be pressed. The view does not need to collapse - it always stays in the expanded mode. The users should be able to respond to each node (via the comment button on the far right). And, of course, users should be able to scroll through the entries.
What are some of the ways I could implement this? I am open to 3rd party controls, paid or not.
VSFlexGrid has an outline mode. You can set the indent per row via the RowOutlineLevel property. It supports word wrap, images, etc within its cells/columns so you should be able to get pretty close to what you want. It also supports owner-drawn which lets you fully customize the cell painting (for example, to get those rounded corners).
I'm sure there are other controls out there as well...
I'm new to developing on the Mac and am looking to implement an interface similar to Spotlight's - the main part which seems to be an expanding table/grid view.
I was wondering if there is a component Apple provides for creating something like this or is available open source else where.
Of course if not I'll just try and work something out myself but it's always worth checking!
Thanks for your help in advance.
New Answer (December, 2015)
These days I'd go with a vertical stack view ( NSStackView ).
You can use its hiding priorities to guarantee the number of results you show will fit (it'll hide those it can't). Note, it doesn't reuse views like a table view reuses cell views, so it's only appropriate for a limited number of "results" in your case, especially since it doesn't make sense to add a bunch of subviews that'll never appear. I'd go so far as to say outright you shouldn't use it for lists of things you intend to scroll (in this case, go with a table view).
The priority setting can be used to make sure your assumption of what should be "enough" results doesn't cause ugly layout issues by letting the stack view "sacrifice" the last few.
You can even emulate Spotlight's "Spotlight Preferences" entry (or a "show all" option) by adding it last and setting its priority to required (1000) so it always stays put even if result entries above it are hidden due to lack of space.
Lately all my UI designs for 10.11 (and beyond) have been making heavy use of them. I keep finding new ways to simplify my layouts with them. Given how lightweight they are, they should be your go-to solution first unless you need something more complex (Apple engineers stated in WWDC videos they're intended to be used in this way).
Old 2011 Answer
This is private Apple API. I don't know of any open-source initiatives that mimic it off-hand.
Were I trying to do it, I might use an NSTableView with no enclosing scroll view, no headers, two columns, right-justified lighter-colored text in the left column, the easily-googled image/text cell in the right column, with vertical grid lines turned on. The container view would observe the table view for frame changes and resize/reposition accordingly.
Adding: It might be a good idea also to see if the right/left justified text (or even the position of the columns) is different in languages with different sweep paths. Example: Arabic and Hebrew are read right-to-left. Better to adapt than to say "who cares" (he says flippantly while knowing full well his own apps have problems with this sort of thing :-)). You can test this by making sure such languages are installed on your computer, then switching between them and testing out Spotlight. Changing languages shouldn't pose an issue since the language switching UI doesn't rely on reading a foreign language. :-)
How would I go about implementing something along the lines of "scrubby sliders", like in Photoshop and quite a few other image-processing applications?
They are slightly hard to describe.. basically you have a regular numeric input-box, but you can click-and-hold the mouse button, and it functions like a slider (until you release). If you click in the box, you can select text, edit/paste/etc as usual.
The Photoshop docs describe it, and I put together a quick example video (an example of the sliders in Shake)
Another similar implementation would be the jog-wheel in Final Cut Pro, which functions similarly, without the numeric readout being underneath.
I can't seem to find any mention of implementing these, although there is probably alternative names for this. It is for a OS X 10.5 Cocoa application.
It is for a colour-grading application, where a user might need to make tiny adjustments (0.001, for example), to huge adjustments (say, -100 +100) on the same control. A regular slider isn't accurate enough over that range of value.
Copy-and-pasting values into the box would be a secondary concern to scrubbing the values, and the Photoshop/Shake setup really well. The unobviousness of the control is also of a low concern, as it's not a "regular desktop application"
I've encountered those. They suck, because they prevent the user from dragging to select the text of the number.
A better idea would be a miniature slider beneath the field that expands to a full-size slider when the user holds down the mouse button on it and collapses back to its miniature size when the user releases the mouse button. This way, the selection behavior is still available, but you also provide the slider—and in a more obvious way.
There's no built-in class in Cocoa for either one. You'll have to implement your own.
I doubt that this exists in Cocoa framework. As far as I remember it is not mentioned in the Apple Human Interface Guidelines.
You can develop one yourself by using a custom view and tracking mouse events (-mouseDown:, mouseUp:, -mouseDragged:).