IKImageBrowserView, collapse group will lose selection - cocoa

I asked a question before: How to use IKImagebrowserView's group dispaly?
And now I am got the group style view very well, like this
when I select some photos(not all of them) from group yazi,
and then click the small triangle to collapse it, and click again to expand it, the selection is lost. I think it's the default action of IKImageBrowserView.
Anyone knows what function will be called when I do the collapse/expand function.

Related

UI guidelines - should a control get focus when changed?

I have a window which shows a table on the left half. On the right half I display properties of the item which is selected in the table. The user can now change these properties.
The properties are represented by different kinds of controls: textFields, sliders, numberSteppers and popUpButtons.
The user can - besides using the mouse - use the tab key to navigate through the UI Elements. When the table has the focus tab will select the first editable item on the right side, then tab walks through the items and after the last item will go to the table again.
When the table has focus and I change the value of a popUpButton or move a sliderthe default behaviour of the API (Apple's Cocoa) is to change the value but keep the focus on the table.
My intuition would tell me that after changing a control element it should have the focus (i.e. become firstResponder). But I checked some of macOS' preference panes and they behave similarly.
In Apple's Human Interface Guidelines I do not find mention of that specific topic.
So my question is:
Is there a guideline or at least best practice an app should follow regarding if a control element like a popUpButton or slidershould get the focus when clicked or edited?

What are some good UX web designs for selecting multiple items and performing an action

I'm working on redesigning a web interface to provide the same functionality it has currently but with easier use via good UX design. Currently, here is what the design looks like:
I'm less worried about the tofu look and feel, that can come later, I want to nail the UX functionality first. The idea here in this tab is the user can select the items via a checkbox and perform the actions in the "I Want To" drop down (which opens different modal dialogs depending on the action). The 3 dot ellipsis on the right of the items in the list allow the user to perform the same actions via another drop down control, with the idea that they use the top drop down to perform the actions on multiple items, the ellipsis three dot menu for one item.
The obnoxious part of this control is that the list could contain hundreds of items, and the check box takes too much precision to check quickly. The user would select which items they would like to perform the actions on sequentially, then have to scroll up to the top of the page to select the action. This could be 5 seconds of scrolling, which I find obnoxious. I want to develop a good UX pattern to provide the same functionality in less clicks, scrolling, and frustration.
My inital idea was to provide a floating action button. The user could then * somehow * (I haven't thought of an idea yet, at minimum at least a bigger check box) select multiple items then pick what they want to do via the floating action button which is always within the bounds of the screen instead of the horrible scroll back to the top (I don't think a "scroll to top" button is a good solution for this either).
So I need some recommendations on a UX pattern or some general suggestions on how to make this process less frustrating for users. I'm a fan of material design right now, but I'm open to any suggestions, material design guides don't seem to have any paradigms for something like this.
I think the UX steps are in a good track: first select them, then set the action.
Instead of it being only a checkbox to click, the whole top part of each line could be clickable to select the item. This would make it much easier for the user, and less frustrating not being able to hit the checkbox.
Fixing the header on top would be usefull for adding a "Select/Unselect all" option and having the actions always available. Adding a searchbox to filter could be as well a good option if you are thinking of long lists. Combining the search box and the "Select all" option should help the user in their tasks.
If that is the most important action to be done in that screen, making the "What to do" button stand out a bit more would be a good idea to differenciate the primary from the secondary options for the user to do.
I see two simple things you can do to make this more usable with very little effort.
Remove the checkbox and make the entire row tappable, highlighting those selected. Each row would essentially become the checkbox's label, and the checkbox itself would be hidden from view.
Fix the header to the top of the browser window when the user scrolls down.

Scroll SlickGrid only one line, when using keyboard navigation

I have implemented a slickgrid and activated keyboard navigation.
When the users is scrolling down using the down-arrow key and reaches the last of the currently visible rows, the grid loads a whole new section of rows and places the selection at the top.
My user tests have all included a complaint about this behaviour as they all find the jump jarring.
I would like to implement behaviour, so the grid scrolls just one line at a time, when I press the down arrow while the last visible row is selected.
I was wondering if there might be some setting, I have overlooked, or if anyone has some suggestions for how to approach the task of adding this behaviour.
(the "problem" is the same, when you scroll upwards - only reversed of course)
This is controlled by the doPaging argument in scrollRowIntoView(row, doPaging) (https://github.com/mleibman/SlickGrid/blob/master/slick.grid.js#L2662). There's no setting to control that behavior, but you could easily add one.
It was initially written this way to make keyboard navigation faster since continuously navigating down doesn't have to do as much work as it would have if we were updating the grid on every 'row down'.

Windows Menu: MF_HILITE flag does not cleared

I have CMenu instance on which I add multiple items. For one of the items I added in it, I set the MF_HILITE flag.
When I show the menu, the appropriate item get hi-lighted correctly, as requested. The problem is that it stays hi-lighted until I move the mouse over it and leave. I only want one item to be hi-lighted at the time. It seems that Windows does not un-light it when another item is hi-lighed.
How could I force it to be un-lighted as soon as another item get the hi-light? I could not find any mouse-over callback or message for the menu, and I could not find a invalidate either.
You're using MF_HILITE in a weird way. The item isn't actually highlighted, it's just drawn like it is. If the user presss enter, the "highlighted" item won't be selected.
You're probably looking for MF_DEFAULT.
It does not appear to be possible.
The internal state for the currently selected item in the menu can't be set. Using the MF_HILITE or HiliteMenuItem does not set the currently selected item, it only sets the visual style.
As a work-around, I have used a popup ListBox instead, which has all the features I need.

How force NSMenuItem to redraw?

I'm implementing a custom status bar menu, which has a custom view with NSSearchField. I'm updating number of menu items according to search results. The number of menu items is changed as user types in the NSSearchField. I've noticed, that if number of results stays the same, items titles are not updated (redrawn). How do I force them to redraw?
In the function, that rebuilds the menu I remove first all items and then create new items according to the search results.
Thanks,
Nava
I could achieve it by following approach: When the number of search results is the same, i don't recreate them, just change the title and call itemChanged:. When the count is different I recreate menu items. This works anyway. But I was advised anyway to get back from using menu for this purposes.
on the menu set menuChangedMessagesEnabled to YES when you want to update the menu:
[menu setMenuChangedMessagesEnabled:NO];
// change the menu
[menu setMenuChangedMessagesEnabled:YES];
The second invocation causes the menu to apply changes. The first one is so that you can batch a group of changes together.
That said, Apple guidelines discourages changing menus while they're open as users are not used to this and can be confusing. If it's feasible try to redesign your app so you can use something else, say a table or matrix, instead of a menu.

Resources