I was just wondering if it is possible to create a drop down or popup menu with a hierarchy? The application I am currently working on tracks Assignments, Courses, and Subjects. When the user creates an Assignment they will need to be able to select a Course that it belongs to from a drop down but I also wan't the drop down to be organized a little bit by having headers so the user can easily see what Subject that Course belongs to.
Example:
Select Course: [drop down below]
- Life
--Chores
--Eating
--Vacations
- Math
--Algebra
--Calculus
Etc...
Not the best example but the entries "Life" and "Math" would be bold and unselectable and all of the others would be regular menu items. Does anyone have any suggestions? Let me know if you need more information on what I am trying to do.
Yes, if you build them manually in code or in Interface Builder. No, if you're using Bindings.
NSPopUpButton takes an NSMenu full of NSMenuItems.
Related
The NSTableView has a feature, called Type Selection, by which the user can type the first letters of a listed item and the view automatically selects the first hit and scrolls to it.
I like to have a similar functionality in a NSCollectionView, where I list images by name.
Before I start writing such code by myself, I wonder if there is an API that can help me with this.
I am especially worred about getting the timing right, as I want to have it use the same timing as the NSTableView does. I imagine that it even changes depending on the user's System Preferences for typing. Also, the NSTableView will select other items with the same typed prefix if waiting long enough. All this can get quite complicated if I want to get it right. I don't want to miss anything.
I am trying to build a form with a phone input that includes country codes. Essentially, I am trying to make something a lot like this:
I already found and cleaned a list of flags, countries, and their codes, and built the method that creates a DropdownMenuItem for an arbitrary index. I then construct a list of them and pass it to the DropdownButton widget. It's all very simple, so I don't think the code is necessary. However, because I have so many countries, and therefore menu items, the menu lags significantly when opening. So, I was wondering if drop down menus are capable of loading large numbers of widgets in a smarter fashion than it seems they do.
Can a drop down menu could load the first 10 or so widgets around the selected index and display them, as that is all that will be in view initially, and then load the rest of the widgets asynchronously? I suspect that this will require a custom drop down menu, but I am not very well versed in the implementation of Flutter's drop down menu, so I am unsure of how to proceed with this.
Any help is appreciated.
I don't think that "loading" is the actual problem here, more likely it's the rendering/building of the widgets. You can improve the situation by using something like a ListView.builder that builds items on demand.
It seems like the default dropdown system is not based on a ListView.
You can create your own version of the dropdown (like a complete customized copy of the classes), which will require quite quite a lot of work and research.
Or alternatively, use something like a SimpleDialog with an embedded ListView to display the list. Like this one for Android.
I'm relatively new to Cocoa and I would like to implement the ability to add or delete items from a pop-up menu in the same way that the OS X System Preferences/Network Location pop-up works. Selecting the 'Edit Locations...' option rolls down a window that provides the ability to add to, or delete from the existing Location list. My interest in doing things this way is as much about conforming to the relevant Human Interface Guidelines as having a way to dynamically change the menu content. (I have no real problem with the 'background' coding side of things, it's the user interface that's my primary issue at this stage.)
Is this a standard IB View?
On the surface, I can't see anything appropriate, but maybe that's just my inexperience. I'm assuming that, because this is not an uncommon sort of requirement, the task should be pretty straightforward and that Apple, or someone, would even have a relevant code sample to show how to define such a window.
Can anyone point me in the right direction?
Sorry for the late answer. I found this tutorial: http://cocoadevcentral.com/articles/000014.php
I have 5 NSTableView's instances that have the same contextual menu. When I get the message that the menu has been clicked I need to know which table sent it. I've checked the NSMenu documentation but I don't seem to find a way to check which of the tables opened the menu..
I'm thinking of subclassing NSTableView and send a message to the delegate on menuForEvent, would that be the best way?
UPDATE:
Thanks Joshua, I,am using 5 tables to display a 5 day week task planning. Each table represents a week day, and I added the contextual menu for adding and removing tasks. So when a user clicks "add task" on a week day I need to know which one. I've got it working by subclassing tableview and sending a message to the delegate when the menu is opened. In this manner my controller knows which of the tables was the last to call the menu.
But it doesn't seem to me like the best implementation to get this, maybe is like you said the problem lies on the UI, what do you think?
Jose.
I don't see a way to get this information. Menus aren't "attached" to anything; they're displayed in a location. Your -menuForEvent: override might work but it gives me the willies.
While this isn't an answer to your question, I confess my first reaction is "why do you have multiple tables with exactly the same menu?" This strikes me more as a UI issue. One would think a contextual menu would be pretty specific to the specific kind of thing (or view thereof) that it represents. That begs the question: why do you have 5 table views that all have exactly the same context? If all 5 tables represent things that are controlled in the same way by the (presumably) same controller, it's highly likely there's a better way to represent your "collection of things" than 5 separate tables.
I'm making a lot of assumptions, granted, but my curiosity is getting the best of me, I suppose. :-)
Doing some restructuring on the my applications menu bar. When looking at other applications, there seems to be two different ways of structure.
Either the "old school" most common way, the verb/command followed by the subject. I.e. what do you want to do and what do you want to do that on. Like so:
File
New
Foo
Bar
Open
Foo
Bar
Quit
Or the one that new applications sometimes try, probably since Microsoft introduced its ribbon structure. I.e. what do you want to work with and what operation do you want to execute on that. Like so:
File
Quit
Foo
New
Open
Bar
New
Open
Are these two paradigms established? Do they have a name? Would help me in referring to them and their differences.
Yes, menus at the top level may be organized by the class of object they act on (e.g., Foos or Bars), or the type of action they carry out (e.g., filing actions). As a general rule, the menu bar or Ribbon at the top of the window should be organized by action type in order to provide the user with an alternative way to find a command to the context (right-click) menus that are necessarily organized by object class.
That said, many menu hierarchies, including the “old school” one, would benefit from being “flattened” –from being made broader at each level and less deep. Deep hierarchies mean cascade menus, which are slow and awkward to use. Few options at the top level mean general vague labels that provide very little information scent (what does File really mean anyway?).
There are several ways to fix this while still organizing the menu bar by action type. First, there’s the simple flattening of the old school File menu, much like Firefox does:
File
New Foo
New Bar
Open Foo
Open Bar
Quit
The problem is that the traditional File menu was intended for “document” applications that operate on only one principal object class. For example word processors operate on papers, spreadsheet programs operate on worksheets, image editors work on pictures, and so on. File becomes unwieldy when there are multiple principal classes. Two classes isn’t a problem, but three or more is.
In some cases, it’s best to take the “suite” approach and make it look like you’ve a separate program for each object class. Take object class selection out of your menu bar and put it in the Start menu, where you’ve installed shortcuts corresponding to each object class that open a primary window for that class. Each of these “applications” only has New and Open acting on only its class:
File
New
Open
Quit
In a sense, you’ve made broader the menu above your menu bar in the hierarchy. This is entirely consistent with other desktop apps. It’s an attractive option if users tend to work with only one class for a session. Frequent trips to the Start menu gets old.
If you need to keep everything in your menu bar, you can spread the File menu out along the menu bar.
File
Save
Print
Quit
New
Foo
Bar
Open
Foo
Bar
Many apps with multiple principal classes are database apps where each window shows multiple objects (database records). What the user is “opening” is not a single file but a query result. Typically, the user almost never has use for a blank window. Even for data entry, it’s often helpful and rarely hurtful to show the results of a default query in order to provide some context (e.g., records entered last time). If the user wants to add a new record to those already shown, it’s an action under Edit, not File. So we can eliminate New.
Program
Foos
Bars
Quit
File
Query
Close
I suggest you take a cue from Mac OSX and have a Program menu for Quit (in OSX the name of the application is the menu caption). The Program menu has menu items labeled by their object class, but they’re actions –they open the Foo and Bar windows respectively. You either fill these windows with a default query result (which could be empty), or automatically show the query dialog for the user to select one. The Query menu item under File pops up this dialog to allow the user to change the query for the window at any time. This dialog may include an Empty option for edge cases where users need an empty window.
I think it's more personal preference. What do you think would go best? If you're not implementing the ribbon GUI into your app then there's no need to copy their structure.
Personally I'd go with the first option - "old school", I find it more straightforward and the most pragmatic approach toward the problem.