I have a very big Tcl/Tk application with a lot of widget. In order to allow easy access to modify widgets configurations without having to type it in the console per widget/configuration parameter I want to build a dialog for that.
To do so I need an option to easily select the widget to be configured.
I thought to write a function which lets the user to click any widget in the application (any dialog) and retrieves the widget path.
Any ides?
You can convert a global-coordinate (e.g., from a <Button-1> binding's %X and %Y) to a widget name using winfo containing:
bind . <Button-1> {
set w [winfo containing %X %Y]
puts "You clicked on $w"
}
Be aware that this can interact quite significantly with other bindings! You may need to investigate using a grab (carefully; global grabs can cause trouble!) and configuring the -cursor in order to tell users what is going on. It's quite do-able, but some thought may be necessary to make it work the way you want.
(Did you know that winfo containing is a scripted interface to the functionality at the core of most drag-and-drop handling? It uses exactly the system for mapping positions to windows…)
Related
I have a simple app that accepts dropping files from Finder.
I want to support 3 different dragging types:
move
copy
link (make alias)
When pressing Alt+Cmd while dragging, Finder usually creates an alias (link). However, in my app in draggingEntered: the flag NSDragOperationLink is not set in that case.
Below are the various flags for the different modifier key combinations:
move (no keys): Private, Delete, Copy, Generic, Link, Move, All_Obsolete, Every
copy (Alt) : Copy, All_Obsolete, Every
link (Alt+Cmd): Copy, Generic, All_Obsolete, Every
Note how in the last case the Link flag is not set. How could I tell in performDragOperation: that I need to create an alias?
Do I really have to check the modifier keys in the current event? I'd much rather have a clean solution via the source dragging operation mask...
Tested on 10.8.5 and 10.9.
You need to register first your dragged types in the code using
registerfordraggedtypes: api
Yes, I know it's a very old thread but it still comes up in search results.
For drag-and-drop operations that span applications you have to hold down Control to filter for the Link flag.
In the online documentation for NSDraggingInfo draggingSourceOperationMask there's a table showing how the modifier keys are handled but it's wrong (it seems to be describing how the Finder works). If you can dig up older documentation on the drag-and-drop API it shows a different filtering algorithm where Option filters for Copy, Command filters for Generic, and Control filters for Link. That's the filtering algorithm that the OS still applies to inter-application drag-and-drop.
Does anyone have an example of using a QWidget as an editor in a QAbstractTableModel?
I have a column which when edited should create a QCombobox with the list of choices.
The docs seem to suggest I need to write a QAbstractItemDelegate and a custom paint function but that seems overkill to simply pop-up a standard QCombobox in Qt::EditRole.
Note - the combo box contents are the same for every row and it only needs to be shown when somebody clicks in the cell.
I know this should be simple but I can't get it to work. It's easy for a QTableWidget based table - but I need it for a very large data table.
The docs seem to suggest I need to write a QAbstractItemDelegate and a custom paint function but that seems overkill to simply pop-up a standard QCombobox in Qt::EditRole.
You don't need to go that far. One way is to subclass QStyledItemDelegate and then override createEditor() so that it returns your prepopulated combo box. Its setEditorData and setModelData functions will probably already suffice if you`re using basic Qt value types.
If you need something more generic that works across many different models, you can create a QItemEditorFactory that associates your editor with the correct type. This also works well with custom types.
When indicated by your view's EditTrigger, your view will get the delegate specific to the cell on which the edit is being invoked and call delegate->createEditor(...) which can then size the combo box according to the options parameter as well as set the current entry to the value specified by the model, although most of this should be handled by the QStyledItemDelegate. Thus, you won't have to worry about the Qt::EditRole directly as the view will handle that.
Did you try and have a look at the following example from Qt :
Spin Box Delegate Example
Maybe it will give you a much clearer view on the subject !
Hope it helps a bit !
New to GWT here...
I'm using the UIBinder approach to layout an app, somewhat in the style of the GWT Mail sample. The app starts with a DockLayoutPanel added to RootLayoutPanel within the onModuleLoad() method. The DockLayoutPanel has a static North and a static South, using a custom center widget defined like:
public class BigLayoutWidget extends ResizeComposite {
...
}
This custom widget is laid out using BigLayoutWidget.ui.xml, which in turn consists of a TabLayoutPanel (3 tabs), the first of which contains a SplitLayoutPanel divided into WEST (Shortcuts.ui.xml) and CENTER (Workpanel.ui.xml). Shortcuts, in turn, consists of a StackLayoutPanel with 3 stacks, each defined in its own ui.xml file.
I want click events within one of Shortcuts' individual stacks to change the contents of Workpanel, but so far I've only been able to manipulate widgets within the same class. Using the simplest case, I can't get a button click w/in Shortcuts to clear the contents of Workpanel or make WorkPanel non-visible.
A few questions...
Is ResizeComposite the right type of class to extend for this? I'm following the approach from the Mail example for TopPanel, MailList, etc, so maybe not?
How can I make these clicks manipulate the contents of panels in which they do NOT reside?
Are listeners no longer recommended for handling events? I thought I saw somewhere during compilation that ClickHandlers are used these days, and the click listener "subscription" approach is being deprecated (I'm mostly using #UiHandler annotations)
Is there an easy way to get a handle to specific elements in my app/page? (Applying the "ID" field in the UI.XML file generates a deprecation warning). I'm looking for something like a document.getElementById() that get me a handle to specific elements. If that exists, how do I set the handle/ID on the element, and how can I then call that element by name/id?
Note that I have the layout itself pretty well nailed; it's the interaction from one ui.xml modularized panel to the next that I can't quite get.
Thanks in advance.
If you don't have a use for resizing events than just use Composite
What you want is what the GWT devs called message bus (implemented as HandlerManager). You can get a nice explanation in the widely discussed (for example, on the GWT Google Group, just search for 'mvp') presentation by Ray Ryan from Google I/O 2009 which can be found here. Basically, you "broadcast" an event on that message bus and then a Widget listening for that event gets the message and does its stuff.
Yep, *Handlers are the current way of handling events - the usage is basically the same so migration shouldn't be a problem (docs). They changed it so that they could introduce custom fields in the future, without breaking existing code.
If you've set an id for any DOM element (for Widgets I use someWidget.getElement().setId(id), usually in combination with DOM.createUniqueId()) you can get it via GWT.get(String id). You'll get then a RootPanel which you'll have to cast to the right Widget class - as you can see it can get a little 'hackish' (what if you change the type of the Widget by that id? Exceptions, or worse), so I'd recommend sticking with MVP (see the first point) and communicating via the message bus. Remember however, that sometimes it's also good to aggregate - not everything has to be handled via the message bus :)
Bottom line is I'd recommend embracing MVP (and History) as soon as possible - it makes GWT development much easier and less messy :) (I know from experience, that with time the code starts to look like a nightmare, if you don't divide it into presentation, view, etc.)
If I have a setting that is accessible via a menu item or configuration window that can change at runtime, for example "bold text on/off"; what are some good ways of ensuring that all applicable components are aware the value of this setting?
You didn't provide specifics of an implementation language, so the asnwer will be somewhat generic.
Assuming your GUI is in a language which supports even model (e.g. Java), simply have an event handler for any component which should be affected by settings and which gets triggered on an event "setting changed". Then call such event from the setting config window. Don't forget to redraw when all components are done updating (ore redraw as each component is updated).
An additional point is to hopefully have generic sub-components used.
As an example, if you are using label text with a certain font which is configurable, then use a common "label with configurable font" class which ensures you never need to assign the above event listener to every label you create.
If there will be a lot of setting I have implemented a sqlite DB to hold the changes for smaller amount of changes key value pair in a file is good enough. Then implement a observer design pattern so when any changes are done a list of gui classes are called to do the change.
I'm generating a MATLAB GUI using GUIDE, but I want to create fields when a user clicks on a button. Is there any way to dynamically add new GUI objects in the callbacks?
One way to accomplish this is to create the GUI objects at the start, but set their "Visibility" property to "off". Then, when the user clicks on a button, you set the "Visibility" property back to "on". This way, you won't be making new GUI objects while the GUI is running, you would simply be changing which parts of it are visible or not.
EDIT: If you don't know how many new GUI objects you need until run-time, this is how you would add the new GUI objects to the handles structure (where hFigure is a handle to the GUI figure):
p = uicontrol(hFigure,'Style','pushbutton','String','test',...
'Callback',#p_Callback); % Including callback, if needed
handles.test = p; % Add p to the "test" field of the handles structure
guidata(hFigure,handles); % Add the new handles structure to the figure
You would then of course have to write the callback function for the new GUI object (if it needs one), which might look something like this:
function p_Callback(hObject,eventdata)
handles = guidata(gcbf); % This gets the handles structure from the figure
...
(make whatever computations/changes to GUI are needed)
...
guidata(gcbf,handles); % This is needed if the handles structure is modified
Functions of interest that I used in the above code are: GUIDATA (for storing/retrieving data for a GUI) and GCBF (get handle of parent figure of the object whose callback is currently executing).
Using UICONTROL, you will be able to add 'fields' (called uicontrols or widgets).
You will want to specify the style to get edit boxes, buttons, etc...
You may actually want to have all the widgets already there in GUIDE and then just change the visibility or enabled property as needed.
You can find my video tutorials on GUI building in MATLAB here:
http://blogs.mathworks.com/videos/category/gui-or-guide/
This should cover this and many related topics in GUI building.