I inherited from QGraphicsItemGroup and made a class that keeps a pointer to its contained items so that I can later refer to them and change properties. It has an ellipse item and a line item and I want only the ellipse to be clickable. I need that press event of the ellipse to propagate to the QGraphicsView so that I can send a signal to some surrounding widgets.
So far I tried inheriting also from QGraphicsObject to have signals available but got stuck with ambigous base error when trying to use scene->addItem. I tried casting to QGraphicsItemGroup but I still get the error. I also tried inheriting from QObject with no success.
I'm new to QGraphics and I know the QGraphics framework has a lot of tools for user interaction and even interaction between GraphicsItems but this is really kicking my butt.
What would be the proper way to get this behavior?
Create a separate "emitter" class
To allow your subclass of QGraphicsItemGroup to emit signals, you can create a separate "emitter" class that inherits from QObject. Then, you can add an instance of this emitter class within your subclass of QGraphicsItemGroup. The emitter object can then emit signals for your subclass as needed.
QGraphicsItemGroup is treated as a single item
Unfortunately, an instance of QGraphicsItemGroup is treated as a single item, so each mousePressEvent will belong to the entire group rather than one of the members of that group (i.e., the ellipse item or the line item). If you want the mousePressEvent to behave differently depending on which item is clicked, they will need to be separate items, or you could try using line->setParentItem(ellipse) to link up the 2 items without using QGraphicsItemGroup.
Related
In PyQt, I have a dialog that spawns another dialog (when you click a button to do so in the first dialog). I want to maintain a strong parent-child relationship, for garbage collection purposes, and to make the .findChild and .findChildren functions usable.
The root of the question may be: how do you use .setParent() but still have the object in question be shown as a separate window, rather than shown within the parent widget?
The 'parent' dialog (actually a container widget within a tab within a dialog) is 'newEntryWidget'. It spawns 'clueDialog' when a signal (not shown here) calls newEntryWidget.quickTextClueAction as a slot. Visually, clueDialog should be a "top level window" with its own banner, its own window attributes (I want to keep it on top of everything else), etc.
class newEntryWidget(QWidget,Ui_newEntryWidget):
def __init__(self,parent,sec=0,formattedLocString='',fleet='',dev='',origLocString='',amendFlag=False,amendRow=None):
QDialog.__init__(self)
self.parent=parent # just an attribute; not the same as setParent
...
...
def quickTextClueAction(self):
self.newClueDialog=clueDialog(self,self.ui.timeField.text(),self.ui.teamField.text(),self.ui.radioLocField.text(),lastClueNumber+1)
self.newClueDialog.show()
class clueDialog(QDialog,Ui_clueDialog):
def __init__(self,parent,t,callsign,radioLoc,newClueNumber):
QDialog.__init__(self)
self.parent=parent # just an attribute; not the same as setParent
...
...
Right now, since I am using self.parent=parent, which is just an attribute and not true "parent/child relationship" in Qt terms, clueDialog does display as a top level window, which is what I want:
But, if I add 'self.setParent(parent)' in the clueDialog init function, I get this:
How can I preserve the top-level-window behavior, and have the real-honest-parent-child-relationship so that .findChild(clueDialog) will work from within the newEntryWidget object?
Ultimately, I want to enforce that the newEntryWidget object should not be closed if it still has and 'child' clueDialogs open.
Instead of calling .setParent, call QDialog.__init__(self, parent) which constructs the clue dialog with a parent from the beginning. Setting it this way allows Qt establishes the parent-child relationship at the beginning of clueDialog's lifetime.
I believe this will fix both your issues: 1) the clue window frame, caption, etc. will be painted, 2) you will be able to iterate for proper children of newEntry.
Below are two questions on the same component:
Which signal is triggered when the mouse passes over a Gio.MenuItem?
How to implement a tooltip for Gio.MenuItem?
Gio.MenuItem is a direct descendent from GObject.GObject (See https://lazka.github.io/pgi-docs/Gio-2.0/classes/MenuItem.html). It does not have any signals itself, and only receives a notify signal via its descent from GObject.
As Gio.MenuItem is not a widget, it does not receive any signals from the GUI. It only represents data (opaque data at that).
I suspect you want Gtk.MenuItem, which is the visual component.
EDIT It seems the widget you are after is Gtk.PopoverMenu. Just to be clear, Gio.MenuItem is not a visible item, which is why I replied as above. Gtk.PopoverMenu is a widget (widget = a visible item).
PopoverMenu is the visible widget, and you can see how it fits together with other widgets. It inherits from Popover, which inherits from Gtk.Bin, Gtk.Container and finally from Gtk.Widget.
So, you have all the signals from those widgets, but those are for the 'complete' Gtk.PopoverMenu, not for the individual items.
According to this definition, the individual items are Gtk.ModelButtons, so you might be able to access them that way.
The solution to get this was much further than I thought. I always suspected that the Devhelp's menu could not be built using GtkPopoverMenu because my OS uses gtk 3.14. The solution involves a totally new concept of running an application, proposed by Gtk.Application interface and the Gtk.Action features. These "new" concepts can be studied in the following places.
http://python-gtk-3-tutorial.readthedocs.io/en/latest/application.html?highlight=Gtk.Application
https://wiki.gnome.org/HowDoI/GtkApplication
https://github.com/Programmica/python-gtk3-tutorial/blob/master/_examples/application.py
Apparently tooltip features are not available for this menu type.
I am trying to pass a simple core data objects info from a tabBarController to its subviews so that they each reference a different attribute of that object. As a newbie, I'm not sure even where to start. It doesn't seem to be as simple as passing the data from one tableView to another...
Thank you for any help.
If you are sharing the same object between (most of the) the view controllers of your tab bar controller, maybe the best architecture for this would be to have one central data object.
A typical pattern is a singleton, some kind of data manager that provides the object, but maybe that is overkill. Another is to keep references to all view controllers and update them one by one when something changes - also not very elegant.
What you really want is something like a global variable. You could (ab)use your app delegate (just give it a property that points to the object) or if you prefer even your tab bar controller (make a subclass, give it a property). In the latter case, every view controller could then get the object like this:
NSManagedObject *object = [(MyCustomTabBarController*)self.tabBarController object];
For example, you can check for changes and refresh your views in viewWillAppear.
A UITabBarController should be handling other view controllers, not handling data objects. How does the tab bar controller get the object reference in the first place? And what is the object you're sharing?
Let each of your subordinate VC's keep a pointer to the object, and then they can each follow the appropriate keypath to get to the entities they're designed to handle.
Tim Roadley's book Learning Core Data for iOS, in chapters 5 and 6, shows how to pass an object from one view controller (a table view) to a detail view. It doesn't sound like that's what you're asking, but just in case...
In response to comment:
I'm looking at a tableview, tap a cell, and then a tab bar controller slides in? That's not the usual visual metaphor for a tab bar; it's meant for changing modes for the entire program. See the Music app for a typical example: songs, playlists, artists.
But if you really need to do it that way, try this (I'm assuming you're using storyboards):
In prepareForSegue: in your tableview controller, tell the destination (tab bar controller) what object it's working with.
In the tab bar controller's -viewWillAppear, tell each of its tabs about the attribute: self.frobisherViewController.frobisher = self.myWidget.frobisher.
You could instead tell each of the component tabs about the top level object: self.frobisherViewController.widget = self.myWidget. But I like the first approach better because there is less linkage. The frobisherViewController now would need to know about both widgets and frobishers.
This ended up being very simple. I was trying to call the object in the child views initWithNibName which doesn't work. I ended up creating a setObject function and calling the properties I wanted in viewWillAppear.
Hope this helps someone.
i am new to GWT and GWTP and the question sounds stupid.. Can I make an abstract PresenterWidget or similiar?
Like in normal Java extending the "class" and reuse / extend the logic. But not only the class, the whole thing of View and Presenter. I try to explain my initial situation and maybe you have another idea.
The image hopefully helps to explain it. The "Main-Tab" and every other tab consists of a collection of views which have the same base structure and the same logic.
the base structure consists of
border around EVERYTHING
an image (the wwitch)
a title
a textarea
a PresenterWidget which is added to a contentSlot of the parent (the menu left)
and below the base are view specific components like buttons, text or any other widget. So a main part of the view with logic is repeading. If the switch is "toggled" the view is hidden (the textarea and any childs / view specific components) like the lowest view in the picture. Furthermore the PresenterWidget left changes the color.
The logic is working, but now I am searching a proper way to solve this without repeading code and the possibility to add child elements which are hidden as well by toggling the switch. Can I add to a PresenterWidget child widgets and define where there should be added? like: Even if this is possible, it feels a bit inconvenient.
Thanks in advance.
I just want to post the solution:
I have now a simple Composite (KPICommonView) for the switch, title and the description. It got another FlowPanel below the description, where the specific components will be added later. For this the Composite implements "HasWidgets" and overrides the "add(Widget w)"-method which is called by UiBinder if the Widget is added and has child elements.
<own:KPICommonView title="First Header" description="I am a happy description :)" anchorToken="{nameAnchors.getFirst}">
<g:Label>child component</g:Label>
</own:KPICommonView>
I am not sure if I do a PresenterWidget for every segment and every PresenterWidget has one of the KPICommonView added, or if I do one normal Presenter which adds more than one of the CommonViews.
The CommonView furhter creates the PresenterWidget for the menu item on the side. It gets the attributes from the constructor (anchorToken, title) and adds it to the slot (which happens ugly, because the View has hard coded the parent saved to call "addInSlot()". The repeading code for the switch is handled by the KPICommonView.
I have a question regarding coded ui UIMap.
Every time I record an action on the same application, coded ui generates a new object for the same window in the application.
It looks like:
UIAdminWindow
UIAdminWindow1
UIAdminWindow2
and so on...
every window class holds different buttons, even though it's the same window.
Thus it's very hard to keep code maintenance.
What i would like is that every time i perform actions and records on a window, even if not at the same time, the already generated class for this window, will be updated with the new controls.
any suggestions to why it happens?
Thanks a lot!
You can clean up your UIMaps by doing two things:
Use the UIMap Toolbox (from codeplex) to move controls within the UIMap so they are all under one control tree.
When you have duplicate UI controls, go to the properties for the action that references the duplicate control and change the UI Control property to point to the original control in the UIMap.
The duplicate trees should now be unreferenced and you can delete it from your map, keeping things clean.
And yes, it's a pain to do, but it's worth it for maintainability.
In UIMap.uitest you can change the action name and the control name for better maintenance.
For example: you can set UIAdminWindow as FirstAcessWindow or other name that will express comfortably the control or the action.
What I can guess is that there is some randomly generated content or element identification data such as class or title that may be causing it. This may be caused by different username for example. Also you can update the element from UI map element tree.