I want to update a widget's value but in order to prevent infinite loops, I need to prevent calling the callback function of this widget's .valueChanged signal.
Following example works entirely as expected:
Qt = PySide
class MainWindow(Actor, Qt.QtGui.QMainWindow):
def __init__(self):
Qt.QtGui.QMainWindow.__init__(self)
Actor.__init__(self)
self.ui = Qt.loadUI('simulator.ui')
self.ui.horizontalSlider.valueChanged.connect(self.emit_weight_msg)
def emit_weight_msg(self, value):
self.send({'WeightMessage': {'val': value}})
def handle_WeightMessage(self, msg):
self.ui.horizontalSlider.valueChanged.disconnect(self.emit_weight_msg)
self.ui.horizontalSlider.setValue(msg["val"])
self.ui.horizontalSlider.valueChanged.connect(self.emit_weight_msg)
Since disconnecting and connecting back the valueChanged signals seems a bit like hack, I want to ask if there is a more elegant solution exists.
Full code is here: https://github.com/ceremcem/weighing-machine-testing
Edit
I'm looking for a method, like:
def setValueSilent(QtObject, value):
tmp_callback = QtObject.get_callback_functions_that_are_set_in_python_code()
QtObject.valueChanged.disconnect(tmp_callback)
QtObject.setValue(value)
QtObject.valueChanged.connect(tmp_callback)
I think if you use blocksignals then it should be fine.
def handle_WeightMessage(self, msg):
self.ui.horizontalSlider.blockSignals(True)
self.ui.horizontalSlider.setValue(msg["val"])
self.ui.horizontalSlider.blockSignals(False)
Related
I can't figure out how to handle an event loop such that I can run other code concurrently. I want to make it so when the handler receives data, it prints it without effecting anything else the program is doing.
I have tried wrapping trading_stream.run in an asyncio task, but this produces an error and isn't what I really want. It's like once I run the stream, my program is stuck inside the update_handler function.
from alpaca.trading.stream import TradingStream
trading_stream = TradingStream('api-key', 'secret-key', paper=True)
async def update_handler(data):
# trade updates will arrive in our async handler
print(data)
# subscribe to trade updates and supply the handler as a parameter
trading_stream.subscribe_trade_updates(update_handler)
# start our websocket streaming
trading_stream.run()
Premise: it would probably be best to understand what event loop is TradingStream using and, if possible, schedule tasks on that loop once retrieved, e.g.
trading_stream = TradingStream('api-key', 'secret-key', paper=True)
evt_loop = trading_stream.some_evt_loop_getter()
evt_loop.create_task(my_concurrent_task)
if TradingStream is using asyncio.get_event_loop() under the hood, then the following is also possible.
import asycio
trading_stream = TradingStream('api-key', 'secret-key', paper=True)
evt_loop = asyncio.get_event_loop()
evt_loop.create_task(my_concurrent_task)
Not being able to assess whether either of the above is the case, the following hack does solve your problem, but I would not resort to this unless the alternatives are not viable.
OTHER_LOGIC_FLAG = True
async def my_other_async_logic():
# Concurrent logic here
async def update_handler(data):
global OTHER_LOGIC_FLAG
if OTHER_LOGIC_FLAG:
asyncio.create_task(my_other_async_logic()
OTHER_LOGIC_FLAG = False
# trade updates will arrive in our async handler
print(data)
Again, do try to get a handle to the event loop first.
I'm trying to figure out if there's a way to return one attribute of a nested object when the attribute is addressed using the 'dot' notation, but to return different attributes of that object when subsequent attributes are requested.
ex)
class MyAttributeClass:
def __init__(self, value):
self.value = value
from datetime.datetime import now
self.timestamp = now()
class MyOuterClass:
def __init__(self, value):
self._value = MyAttributeClass(value)
test = MyOuterClass(5)
test.value (should return test._value.value)
test.value.timestamp (should return test._value.timestamp)
Is there any way to accomplish this? I imagine, if there is one, it involves defining the __getattr__ method of MyOuterClass, but I've been searching around and I haven't found any way to do this. Is it just impossible? It's not a big deal if it can't be done, but I've wanted to do this many times and I'd just like to know if there's a way.
It seems obvious now, but inheritance was the answer. Defining attributes as instances of a custom class which inherits from the datatype I wanted for ordinary attribute access (i.e. object.attr) and giving this subclass the desired attributes for subsequent attribute requests (i.e. object.attr.subattr).
I am trying to use QWizard::validateCurrentPage from PySide.
My wizard class is loaded from .ui file using PySide.QtUiTools.QUiLoader
I created a function that supposed to override build-in QWizard::validateCurrentPage:
def validateDataPage(self):
return False
Now I am trying to override build-in method like this:
self.wizard = uiloader.load("registrationwizard.ui")
f = types.MethodType(validateDataPage,
self.wizard,
QtGui.QWizard)
self.wizard.validateCurrentPage = f
I see in debugger that validateCurrentPage is replaced:
self.wizard.validateCurrentPage
<bound method QWizard.validateDataPage of <PySide.QtGui.QWizard object at 0x04CC31C0>>
I can call it from debugger, but it is not called when I click "next" page.
Am I doing something wrong of it is not possible to override virtual functions when object is already constructed?
I'm pretty sure it should work since your way is the canonical way for Adding a Method to an Existing Object in Python.
I made a small example and it seems to work for me.
import types
from PySide import QtGui
def overload(self):
print(self.validateCurrentPage)
return False
app = QtGui.QApplication([])
wizard = QtGui.QWizard()
wizard.validateCurrentPage = types.MethodType(overload, wizard)
wizard.addPage(QtGui.QWizardPage())
wizard.addPage(QtGui.QWizardPage())
wizard.show()
app.exec_()
prints
<bound method QWizard.overload of <PySide.QtGui.QWizard object at xx>>
I'm currently connecting the signal to a function like this:
dashboard.ui.start_button_r1.connect(:clicked, dashboard.ui.start_button_r1, :handler)
where start_button_r1 is a QPushButton
Now what I want is a reference to the sending widget within handler, since I will connect this signal to several widgets. Ideally I would like my handler function to receive a emitter argument I can play around with. I could put handlerwithin a class inheriting from Qt::Object (say HandlerContainer) and call sender(), but then how do I connect the signal to HandlerContainer's inner method? I tried instance.method(:handler), but connect doesn't receive slots in that way
I usually use this approach in PyQt, but can't figure out how to do it with Ruby. I feel like I'm doing something terribly wrong since there isn't much discussion on how to get the sender from within a slot using QtRuby. How is it usually done? I have read about QSignalMapper, but that seems awfully overkill for my use case.
You can do it with QObject::sender() function. As you've said inside handler slot, typecast sender() to the type, you expect, QPushButton in your case, and you,ve got a reference to sender object.
In c++ it could be done like this:
// inside handler method
QPushButton *tmpBtn= dynamic_cast<QPushButton*>(sender());
Edit:
A minimal example on how to do this in Ruby:
class SlotContainer < Qt::Object
slots "handler()"
def handler
puts "called by: " + sender().to_s
end
end
if $0 == __FILE__
app = Qt::Application.new(ARGV)
ui = Ui_MainWindow.new
container = SlotContainer.new
window = Qt::MainWindow.new
ui.setupUi(window)
Qt::Object.connect(ui.pushButton, SIGNAL("clicked()"), container, SLOT("handler()"))
window.show
app.exec
end
I'm pretty sure the answer to this question is obviously "NO", since Django mixins are supposed to
inherit "object"s, but I can't find an alternative solution to my problem :(
To make the question as simple as possible,,,
views.py
class JSONResponseMixin(object):
def render_to_response(self, context):
"Returns a JSON response containing 'context' as payload"
return self.get_json_response(self.convert_context_to_json(context))
def get_json_response(self, content, **httpresponse_kwargs):
"Construct an `HttpResponse` object."
return http.HttpResponse(content,
content_type='application/json',
**httpresponse_kwargs)
def convert_context_to_json(self, context):
"Convert the context dictionary into a JSON object"
# Note: This is *EXTREMELY* naive; in reality, you'll need
# to do much more complex handling to ensure that arbitrary
# objects -- such as Django model instances or querysets
# -- can be serialized as JSON.
return json.dumps(context)
class HandlingAJAXPostMixin(JSONResponseMixin):
def post(self, request, *args, **kwargs):
.....
data = {'somedata': somedata}
return JSONResponseMixin.render_json_response(data)
class UserDetailView(HandlingAJAXPostMixin, DetailView):
model = MyUser
.....
So the problem I have is that, for multiple Views, I want to respond to their "post" request with the same
JSON Response. That is why I defined the HandlingAJAXPostMixin so that I could reuse it for
other Views. Since the HandlingAJAXPostMixin returns a JSON response,
it requires a render_json_response method, which is defined in the JSONResponseMixin.
This is the reason why I am making my HandlingAJAXPostMixin inherit the JSONResponseMixin, but this obviously seems wrong :(..
Any suggestions..?
Thanks!!!
It's perfectly valid for a mixin to inherit from another mixin - in fact, this is how most of Django's more advanced mixins are made.
However, the idea of mixins is that they are reusable parts that, together with other classes, build a complete, usable class. Right now, your JSONResponseMixin might as well be a separate class that you don't inherit from, or the methods might just be module-wide methods. It definitely works, there's nothing wrong with it, but that's not the idea of a mixin.
If you look at Django's BaseDetailView, you see the following get() method:
def get(self, request, *args, **kwargs):
self.object = self.get_object()
context = self.get_context_data(object=self.object)
return self.render_to_response(context)
get_object() and get_context_data() are defined in the subclasses of BaseDetailView, but render_to_response() isn't. It's okay for mixins to rely on methods that it's superclasses don't define, this allows different classes that inherit from BaseDetailView to supply their own implementation of render_to_response(). Right now, in Django, there's only one subclass, though.
However, logic is delegated as much as possible to those small, reusable methods that the mixins supply. That's what you want to aim for. If/else logic is avoided as much as possible - the most advanced logic in Django's default views is:
if form.is_valid():
return self.form_valid(form)
else:
return self.form_invalid(form)
That's why very similar views, like CreateView and UpdateView are in fact two separate views, while they could easily be a single view with some additional if/else logic. The only difference is that CreateView does self.object = None, while UpdateView does self.object = self.get_object().
Right now you are using a DetailView that defines a get() method that returns the result of self.render_to_response(). However, you override render_to_response() to return a JSON response instead of a template-based HTML response. You're using a mixin that you don't what to use (SingleObjectTemplateResponseMixin) and then override it's behavior to do something that you don't want to do either, just to get the view doing what you want it to do. A better idea would be to write an alternative for DetailView who's only job is to supply a JSON response based on a single object. To do this, I would create a SingleObjectJSONResponseMixin, similar to the SingleObjectTemplateResponseMixin, and create a class JSONDetailView that combines all needed mixins into a single object:
class SingleObjectJSONResponseMixin(object):
def to_json(context):
return json.dumps(context)
def render_to_response(context, **httpresponse_kwargs):
return HttpResponse(self.to_json(context),
context_type='application/json',
**httpresponse_kwargs)
class BaseJSONDetailView(SingleObjectMixin, View):
# if you want to do the same for get, inherit just from BaseDetailView
def post(self, request, *args, **kwargs):
self.object = self.get_object()
context = self.get_context_data(object=self.object)
return render_to_response(context)
class JSONDetailView(SingleObjectJSONResponseMixin, BaseJSONDetailView):
"""
Return JSON detail data of a single object.
"""
Notice that this is almost exactly the same as the BaseDetailView and the SingleObjectTemplateResponseMixin provided by Django. The difference is that you define a post() method and that the rendering is much more simple with just a conversion to JSON of the context data, not a complete template rendering. However, logic is deliberately kept simple as much as possible, and methods that don't depend on each other are separated as much as possible. This way, SingleObjectJSONResponseMixin can e.g. be mixed with BaseUpdateView to easily create an AJAX/JSON-based UpdateView. Subclasses can easily override the different parts of the mixins, like overriding to_json() to supply a certain data structure. Rendering logic is where it belongs (in render_to_response()).
Now all you need to do to create a specific JSONDetailView is to subclass and define which model to use:
class UserJSONDetailView(JSONDetailView):
model = MyUser