Is there a way to show/hide multiple layers # the same time?
For example, I have layers 1, 2, 3, 4, 5, ...
Assume there is a button if you press. layer 2, 4 & 5 are visible. The others are hidden.
If you wonder why, I have a complex drawing of a machine. The technician might not want to show all the components in that drawing before he prints the drawings. So I want to give him a quick method to accomplish that. One click will show & hide bunch of layers (Edit: instead of selecting one by one. He will not know which layer is which).
Related
I'm new to flutter and I'm looking for a way to implement a simple feature. A draggable container.
I have two groups of UI elements wrapped in a Container widget. I want to be able to go from one group to another by dragging or swiping in different directions.
How would I go about doing this?
Here are sample images of my UI design to help you understand what I want to achieve:
Image #1
Image #2
As you can see, Image #1 and Image #2 are only different in the bottom part of my design. I have already created all the necessary UI elements and wrapped them in the Container widget. Now the only thing I need is the ability to go from one group to another. It would also be nice if there was a callback method that could update the buttons above upon transitioning from one group to another.
Thanks in advance!
There are many possibilities to achieve this, depends on your exact wishes, here are 3 ideas:
Using a TabBarView to swipe the entire screen, Tab1 will be the first screen you showed, and Tab2 will be second screen - only the contents. (you probably did not want that, but just putting it out there).
Dividing the container into 2 pieces (vertically), and placing the TabBarView on the bottom part, having 2 tabs: 1 with the Today part and one with the Weekly part. (there are a few examples out there, for instance: divide screen into two equal parts in flutter).
You can also customize the build method to change anything (for example the top indicator) based on the current tab index (as asked and answered here: How to get current tab index in Flutter)
For a more custom solution you can use:
GestureDetector wrapped around your container, and handle OnHorizontalDragX (where X is Start, End etc.) to do any custom stuff - maybe changing the state and trigger a rebuild with the new image
What type of control is this? Some sort of Segment control but without borders? It works like a menu in that you can mouse down and drag... it will highlight as you drag and pick the one you release on.
How can I do something similar?
The big difference I need is to allow multiple selection which will show different sets of details in the area below it. I can do this with a series of NSButtons, but don't get the drag-over "menu" effect.
Ideas?
In the past, I have come across two example of implementation of Xcode-like inspector views:
https://github.com/malcommac/DMTabBar
https://github.com/smic/InspectorTabBar
Some time has passed, so they seem to me more the style of Xcode 4, but they should be ready to adapt to the new appearance.
I'm trying to have a feature to allow users choose two different methods of cost calculation: either they can enter a yearly cost breakdown on a datasheet (2010: $10,000, 2011: $12,000, etc) or they can enter a flat yearly cost multiplied by the number of years they select.
If I were developing another kind of web application, I'd have radio buttons to select two different options. One option would display the datasheet, and the other option would display two text fields to enter values into. However, I understand that you can't have radio buttons in Access 2010 web databases. Also, is it possible to make elements appear and disappear based on a combo box selection?
If not, perhaps I could have two different combo box options: "enter yearly cost breakdown"
or "enter flat yearly cost," which open the correct respective forms as pop-ups.
So, 1) can I have Ajax-like appearing and disappearing elements as triggered by a combo box (or ideally, radio buttons), and 2) if not, can anyone think of another clever way of doing it?
Sure, you get a nice effect by using a tab control. You can place controls and even a sub form on that tab control.
So, you build a screen like this:
Then, simple set the visible property of the second tab = No. This will hide the tab (don't change this until you built the page since it will hide it! (use property sheet to hide/un-hide during development).
Now, add some code to the after update event of the list box. Like this:
In the above, I have named the tabs PYear and PFlat.
The result is this (this is a animated gif I inserted):
Of course, you really probably could just dump the whole "list box" selection, and use a screen like this with the tabs (tabs are good UI, and users tend to grasp them quick):
So, you can hide a "set" of controls, and it really far less work and hassle then writing a bunch of JaveScript anyway. As noted, the "set" of controls you drop into each of the tabs can be sub forms, and also that of continues forms. So, the "hiding" as a set does work well in this case. I did have some format issues and found that I had to "start out" with the 2nd tab dispaled first (the first one being hidden). As noted, the listbox selecting is nice, but one could likly just go with using tabs in the first place.
I have a table column where each row has one of three states, and the purpose of the row is to offer manipulation AND display of this property with three states.
My current development view is to have three tightly packed radio buttons with labels at the head of the columns (and every 50 rows or so) and onClick they send an AJAX request and thar she blows.
This is fugly.
Is there a standard idiom for a control like this? I'm currently mocking up something similar to the iPhone on/off toggle, but with a "middle" state.
Any input would be welcome.
EDIT
A bit more clarification: I have a tool for confirming events. Each event is either "proposed", "cancelled", or "confirmed". They all default to "proposed" until someone explicitly confirms or cancels them. This is a thin front-end for a SQL table.
I've seen this handled with image buttons that remain "depressed" when you click while popping the other two out. They act like radio buttons except that the label and the state are merged. If your names are too lengthy to fit in a button, you can abbreviate them and provide a key. I'd also give each one a distinct color. For implementation just pop the value in a hidden form field on click.
These are called "Toggle Buttons" in some other UI's:
http://java.sun.com/products/jlf/ed2/book/HIG.Controls2.html
http://msdn.microsoft.com/en-us/library/dd940509%28VS.85%29.aspx
http://developer.gnome.org/projects/gup/hig/2.0/controls-toggle-buttons.html
The standard mechanization for things like this in military avionics, where screen space is always at a premium,and so are buttons, is a "rotary". Each time you click it, it steps to the next value in sequence, wrapping around.
As an example, a device with a cryogenic cooler might have three states: OFF, WARM, and COOL. Initially, the device is OFF: no power applied. Click it, and it switches to WARM, meaning power is applied, but no cooling. Click it again, and it starts the cooler. (Since cooling in this kind of thing is usually supplied by a gas bottle with a strictly limited capacity, you don't want to cool the device until you are getting ready to party.) Click it again, and it shuts the device OFF.
You could also do this with buttons or hyperlinks. In a big table, hyperlinks will probably look best.
In the Proposed state, your cell could look something like this (with underlined links, but the editor won't let me):
Proposed Confirm Cancel
In the Confirmed state:
Confirmed Undo
In the Cancelled state:
Cancelled Undo
This will take two clicks to get from Confirmed to Cancelled and vice versa, but I assume that this operation is rarer than switching between Proposed and one of the other two.
Perhaps display arrows on either side to change the state:
(Cancelled) <| Proposed |> (Confirmed)
These may or may not 'wrap' depending on how well that suits the values and how important it is to saving a click when transitioning from value 1 to value 3 (or vice-versa).
As an alternative to you radio buttons, you could consider a drop-down list with three options. The disadvantage is, of course, that two clicks are needed to change the value.
Maybe use a slider with three states? (It really depends on the exact situation!)
Consider a fixed-position slider with three positions, such as offered by jQueryUI: http://jqueryui.com/demos/slider/#steps
I am reminded of the permissions button in SQL - it has multiple states; green check, red x, no setting, and clicking on them cycles through the three states. Its ok but annoying if you want to change a bunch to the state reached second, and if you click too many times you have to go through it all again. Left click - cycle forward; right click - cycle backward might work but certainly has no basis in UI expectations.
Idiomatically, I would say a Stop Light (red/yellow/green). They could behave like radio buttons; darker toned for 'off' and lighter tones for 'on', and since the color gives a cue you can move the description to a mouseover label. Of course, it isn't RG Colorblind kosher, so depending on your application that may be a deal breaker. (also, it may be confusing on Mac where the minimize/close etc buttons are the same color scheme).
Why not use three boxes that look like the "Questions", "Tags", "Users", ... boxes on this page (could be implemented as links, buttons or whatever)?
I've found many answers, here or inside MS' UI guidelines, regarding button positioning, but none about how to position (in which order) buttons when you have three actions to do, New, Edit and Delete.
I have a simple UI, in the upper part I placed a grid listing some data. Beneath, these three buttons. Following what I see around, I have to place them in this order:
New - Edit - Delete
But it seems to me that the delete button is more prevalent and easier to reach and click than the others (it falls on the lower-right corner of my window).
Any suggestion?
I think the order you cite (New - Edit - Delete) is most common because you would logically tab order from left to right when using the keyboard. New would arguably be the most used button (possibly edit depending on the application, but rarely delete) and therefore you wold want the fewest tabs to get to the New button.
Column layouts are always good for these kind of buttons, as one has to move the cursor into the button area, which is horizontally slight and therefore less likely to be accidentally clicked.
Also it provides a perceived division from the main GUI widgets, instead of spanning their length, which tends to create less of a perceived division in the user's mind.
But if you do not wish to change the overall layout, I would say that your current layout is good. Maybe add a delete confirmation box if one is not already present.