I'm adding a toolbar to my application and currently I'm adding some toggle buttons to the toolbar. I don't like using the default JButton because it is big and clunky (even if I remove the margins). Are there any libraries for easy creation of toolbars and toolbar buttons that look more native? Particularly, I'd like the buttons to look flat unless the user rolls over them or they are selected (like in Eclipse).
thanks,
Jeff
Instead of adding the JButton directly to the toolbar, create an Action and add the action instead.
The toolbar will create an appropriate JButton that looks correct.
Additionally, set toolbar.setRollover(true), which will make all the buttons flat, except when the mouse is over it.
Oh, and if you don't want it to be floatable, set toolbar.setFloatable(true).
Those three things, and with a correct L&F, the toolbar usually looks very professional
Generally speaking, we shouldn't be mucking around with button margins ourselves unless we're trying to do something extremely custom.
Related
I feel like I'm missing something obvious. I have an application which uses the 'IsSelected' property of GridViewItem to indicate that an item has been selected. When I'm using the application on a desktop computer (no touch devices) and I right-click on the item, it becomes selected. Take the same program and put it on a Surface and I can find no gestures that will select it. Swipe-down, press-and-hold; nothing seems to do the work that the Right-Click does on the desktop.
Anyone have any ideas what might be missing?
OK, got the answer and it's not pretty. In my code, I had attempted to subclass the GridView with my own control called ContentView. In XAML there is no subclassing of standard controls (you can't use the 'BasedOn' to pick up the style of built in controls) so my ContentView was not picking up the styling of a standard GridView. However, after pulling apart the standard style I've discovered the two critical features are:
IsSwipeEnabled - Must be set to true for swiping to work on the item.
ScrollViewer.VerticalScrollMode - Must be disabled so the scroll viewer doesn't try to interpret the swipe motion as a command to scroll downward.
After that, swiping to Right-Click works easy as pie.
I get what you are asking. It seems counterintuitive, huh? In this situation, my preference is to enable item clicking and use item clicking to set the selected item. If find this to be the most intuitive for users. Start with this XAML:
<GridView IsItemClickEnabled="True" ItemClick="GridView_ItemClick" />
And then simply do this:
private void GridView_ItemClick(object sender, ItemClickEventArgs e)
{
var grid = sender as GridView;
if (grid.SelectedItems.Contains(e.ClickedItem))
grid.SelectedItems.Remove(e.ClickedItem);
else
grid.SelectedItems.Add(e.ClickedItem);
}
It should work for SelectionMode Single and Multiple just fine.
Does that make sense?
// Jerry
I am porting a Desktop WPF application to WinRT and I'm facing a little issue.
I had a ItemsControl and I had a context menu on every item to delete / edit the item.
I have been told that PopupMenu are not good in WinRT and I should use a AppBar.
I think I'm doing something wrong or I misunderstood that.
I thought that I could put that options on a AppBar and when I select an element, popup the bar and click where I need.
The problem is that the AppBar will show up when I right click on any part of my app, so that buttons will show up with an item selected.
So can I change the layout of the AppBar on different contexts (because it seems that Microsoft wants us to use AppBar as context menu without context capabilities) or only show it when I want via code?
Would be good to have a TopAppBar with some App-wide options and a BottomAppBar just for ListView's item context menu.
Or maybe I'm doing all this stuff wrong and I have to use another approach to put extra options on the Listview's items.
You are thinking about this correctly. AppBar is the place where you should put all your non-essential and selection based commands.
The guidelines here and here suggest that they should be arranged as follows:
Navigation commands should be in TopAppBar
Commands related to selection should on the left side of BottomAppBar
The rest of page specific commands should be on the right side of BottomAppBar
Contextual commands should only be shown when a relevant item to that command is selected. For that purpose you should set Visibility of these commands accordingly. Also AppBar should open automatically when an item with contextual commands in it is selected. You can do that programmatically by setting its IsOpen property. You should also set it to sticky mode by via IsSticky property.
If you're using MVVM you can bind your viewmodel properties to all Button and AppBar properties mentioned above.
There's a CustomAppBar control available in WinRT XAML Toolkit. I haven't used it myself yet but it has a couple of extra features that might prove useful in your case.
I am trying to use monodevelop. Just at the beginning I came across an issue:
I was following a tutorial on building a Gtk application (http://monodevelop.com/Stetic_GUI_Designer). I was trying to drag a button from the Widgets Palette. Nothing happened. I'd been trying quite a few times without any luck.
After a break I launched monodevelop again and I simply placed a button on the window of the application. After that I removed it, dragged VBox container, and placed menu bar on the window, according to the tutorial instructions. I was pleasantly surprised.
By the second try the same problem occurred - I was not able to drag any widgets. Dragging was beginning, there was a “+” sign at the cursor and then - nothing was happening. I cannot figure out what happened by the first time, what the difference was. Have anyone had a similar problem? Monodevelop looks promising, but I can't go on with it. (I tried placing 'Fixed' container on the window, with no result - I could not drag it.)
(monodevelop v. 2.4, ubuntu 11.04, Polish language.
I did look for an answer to my problem, without much luck, that is why I post this question. The problem is described quite precisely. There is a probability that others encountered the same issue.)
You need to drag a container on the form first before you can add widgets to it. The VBox container is an example of a place where you can put your widgets.
If you want to place widgets where ever you want you can use the Fixed container. If you want things to align you can use the VBox, HBox or Table containers. Placing in a widget in one of the fields will automatically adjust the size of this field to fit the widget you have dragged into it.
So basically,
Create a form
Drag a container on the form
Drag a widget inside the container.
These widgets are not to be confused with the custom made widgets (in your Solution browser, right click the folder User Interfaces and click Add Widget...). These are like forms. I use these to create GUI's in advance so I can call these while the program is running.
FYI: if you want to create code for a widget (like a button) you can't just double click it like in Visual Studio. You need to select it, the go to the properties pane, and change the tab from Properties to Signals. You can then double click the "signal" to create the event for which you want to create code. For a button this is usually the Clicked event (somewhere at the bottom of the list, you'll need to open the Button Signals)
You can always visit the IRC channel of Monodevelop on irc://irc.gimp.org/monodevelop (IRC.Gimp.org #monodevelop)
I also sit in this channel and can help with smaller problems and I also still use Monodevelop 2.4.
I am trying to accomplish an "imagemap" in flash where you click on different areas in the image and when you click on it, a popup (within flash) comes up showing more information about the object that was clicked on. The popup has a close button that can will then close the popup.
My biggest trouble is the way I have my code right now is when you click on a region of the map, it creates a popup on the fly, and then I use addChild(_myPopup) to add it to the display list. The problem with this approach for me, is that the Popup is now a Child of the button I just pressed, but this object organization doesn't really make sense to me. I'd like to have the popup not be a child of the button and it be on it's own layer or a child of the stage directly.
What is a good approach and code architecture for building such an organization of objects? I'm fairly new to AS3 and I've built some small applications but my knowledge is limited.
Thanks
UPDATE
ok looks like calling stage.addChild(myPopup) from inside the button works pretty well. Is this good practice?
Assuming you have a hierarchy that looks something like this:
stage
Main class
Image class
Button
It's good practice to never call upwards in the displaylist, every object only deals with it's children. Events however, are a nice way of communicating upwards. Have the Button dispatch an event, preferrably a custom one, then handle that using a listener in the main class that then deals with creating a popup on top of everything.
An often encountered practise to organize the layers of the visible application is:
stage
main class with all children
popup container
tooltip container
mouse cursor container (apparently not longer necessary since player 10 supports custom cursors)
So you create your popups always in the popup container above the main class. If you would have tooltips, they should go into the tooltip container. This approach guarantees that popups are always visible above the main app and tooltips are always visible on top of everything.
Basically, what I want to do is put some buttons before the tabs in a gtk.Notebook. I tried making my own notebook type widget and it worked well, but it would have required lots more work to make it as flexible as I would like, also it wasn't as efficient.
Here is a mock-up of what I'm trying to achieve: http://imagebin.ca/view/84SC0d.html
Any ideas would be much appreciated, thanks.
Ben.
You might be interested to know that this functionality has been added in GTK 2.20, see "Changes in GtkNotebook" in the following announcement: http://mail.gnome.org/archives/gtk-devel-list/2010-March/msg00132.html
It's a hack, but you can put your widgets on a separate tab, and then prevent the tab from being clicked by registering the following switch-page event for the notebook:
def onTabsSwitchPage(self, notebook, page_notUsableInPython, pageNumber):
# Don't allow to switch to the dummy tab containing widgets
if pageNumber == <put correct tab number here>:
notebook.stop_emission("switch-page")
Note that this doesn't look good with all GTK themes, but it works...
I don't think there's any way to do it without making your own notebook widget. There are a couple of hacks. One was posted by AndiDog. Another is to hide the tabs altogether (notebook.set_show_tabs(False)) and make a toolbar with buttons above the widget, with your buttons on the left, plus one button for each tab in the notebook that switches to that page.
Instead of making your own notebook-type widget from scratch, you could inherit from gtk.Notebook, overriding some of the methods like expose_event, size_request, and size_allocate, in order to deal with two types of container children: pages and buttons. I don't know how to do this in PyGTK though, only in C.
You might also consider whether the buttons in the tab space are really what you want. What if the user resizes your notebook small enough that some of the tabs disappear? Where do the previous tab/next tab arrows go? What happens to the buttons?