Re: [Python-Dev] Running GUI and "GObject.mainloop.run()" together?
Thanks Simon.
Thanks for the extensive info; however it needs some hours (if not days :P)
to be digested.
On Tue, Dec 25, 2012 at 9:24 PM, Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:
> On 24/12/12 08:26, Ajay Garg wrote:
> > For a recap of the brief history, I have a parent process, that is
> > spawning a child process via "subprocess".
> > Currently, the child-process is a GUI process; however, I intend to
> > "behave" it as a dbus-service as well.
>
> In general that is something that can work, but it's necessary to
> understand a bit about how main loops work, and how the modules of your
> process deal with a main loop.
>
> Just saying "GUI" is not very informative: there are dozens of GUI
> frameworks that you might be using, each with their own requirements and
> oddities. If you say Gtk, or Qt, or Tk, or Windows MFC, or whatever
> specific GUI framework you're using, then it becomes possible to say
> something concrete about your situation.
>
> Based on later mails in the thread you seem to be using Gtk.
>
> I should note here that you seem to be using PyGtk (the "traditional"
> Gtk 2 Python binding), which is deprecated. The modern version is to use
> PyGI, the Python GObject-Introspection binding, and Gtk 3.
>
> When using PyGI, you have a choice of two D-Bus implementations: either
> GDBus (part of gi.repository.GIO), or dbus-python ("import dbus"). I
> would recommend GDBus, since dbus-python is constrained by backwards
> compatibility with some flawed design decisions.
>
> However, assuming you're stuck with dbus-python:
>
> > I then used composition, wherein another class, "RemoteListener"
> > deriving from "dbus.service.Object" was made an attribute of the "main"
> > class. That worked.
> > However, when I do
> >
> >dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
> >GObject.mainloop.run()
> >
> > in the "RemoteListener"'s __init__ method, the GUI of the "main" class
> > fails to load (apparently, because the "mainloop.run()" causes the
> > singular, main-thread to go into busy-wait).
>
> Almost; it's not a busy-wait. GObject.mainloop.run() is the equivalent
> of this pseudocode:
>
> def run(self):
> while not global_default_main_context.someone_has_called_quit:
> if global_default_main_context.has_more_events():
> global_default_main_context.process_next_event()
> else:
> global_default_main_context.wait_for_an_event()
>
> so it will loop until someone calls GObject.mainloop.quit() or
> equivalent, or forever if that never happens - but as long as nothing
> "interesting" happens, it will block on a poll() or select() syscall in
> what my pseudocode calls wait_for_an_event(), which is the right thing
> to do in event-driven programming like GLib/Gtk.
>
> (If you replace the last line of my pseudocode with "continue", that
> would be a busy-wait.)
>
> > I tried option b), but now instantiating "RemoteListener" in a separate
> > thread
>
> It is unclear whether the dbus-glib main loop glue (as set up by
> DBusGMainLoop) is thread-safe or not. The safest assumption is always
> "if you don't know whether foo is thread-safe, it probably isn't". In
> any case, if it *is* thread-safe, the subset of it that's exposed
> through dbus-python isn't enough to use it in multiple threads.
>
> GDBus, as made available via PyGI (specifically, gi.repository.GIO), is
> known to be thread-safe.
>
> > Is there a way to run GUI and a dbus-service together?
>
> The general answer: only if either the GUI and the D-Bus code
> run in different threads, or if they run in the same thread and can be
> made to share a main context.
>
> The specific answer for Gtk: yes, they can easily share a main context.
>
> This:
>
> > dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
>
> sets up dbus-python's mainloop integration to integrate with the global
> default main-context in GLib (implementation detail: it currently uses
> dbus-glib to do that). What that means is that whenever a D-Bus
> connection started by dbus-python wants to listen for events on a
> socket, or wait for a timeout, it will ask GLib to add those to the
> global default main context as event sources.
>
> This:
>
> > GObject.mainloop.run()
>
> iterates GLib's global default main context, analogous to the pseudocode
> I mentioned before. Any "interesting" events that happen will cause your
> code to be executed.
>
> A typical GUI application also needs to run the main loop to
> wait for events. In PyGtk, you'd typically do that with:
>
> > Gtk.main()
>
> Gtk also uses GLib's global default main context, so this is pretty
> similar to GObject.mainloop.run() - if you just remove the call to
> GObject.mainloop.run() and use Gtk.main() instead, everything should be
> fine.
>
> > As per http://www.pygtk.org/pygtk2reference/class-
> > gobjectmainloop.html, it seems that we must be able to add event
> > sources to gobject.mainloop
>
> Yes. Fo
Re: [Python-Dev] Running GUI and "GObject.mainloop.run()" together?
Also, I think I am now starting to get a hang of things; however, one
doubt solved raises another doubt :D
The reason I began looking out for the two-threads-approach, is because
when trying to use the GUI (Gtk) application as a dbus-service, I was
getting the error "This connection was not provided by any of .service
files".
I now see that the reason of it was :: I wasn't using
"dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)" prior to the
statement "Gtk.main()".
Now, by your helpful guidance, wherein you stated that "Gtk.main()" has the
same effect as "GObject.MainLoop.run()", I added the statement
"dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)" before
"Gtk.main()", and voila.. now I could get a proxy object, and invoke
methods remotely. Thus, two threads are now not needed.
However, it now raises a new doubt : in my second approach, wherein I used
"add_to_signal_receiver" (at the server side), and dbus-send (at the client
side), how come things worked now, since I did not add
"dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)" in this approach at
all? I presume that even in this case, dbus would need to know that the GUI
application is ok to listen to dbus-signals?
Are the different requirements in these two approaches expected? Or is it
an inconsistency with dbus-python?
On Tue, Dec 25, 2012 at 10:04 PM, Ajay Garg wrote:
> Thanks Simon.
>
> Thanks for the extensive info; however it needs some hours (if not days
> :P) to be digested.
>
> On Tue, Dec 25, 2012 at 9:24 PM, Simon McVittie <
> simon.mcvit...@collabora.co.uk> wrote:
>
>> On 24/12/12 08:26, Ajay Garg wrote:
>> > For a recap of the brief history, I have a parent process, that is
>> > spawning a child process via "subprocess".
>> > Currently, the child-process is a GUI process; however, I intend to
>> > "behave" it as a dbus-service as well.
>>
>> In general that is something that can work, but it's necessary to
>> understand a bit about how main loops work, and how the modules of your
>> process deal with a main loop.
>>
>> Just saying "GUI" is not very informative: there are dozens of GUI
>> frameworks that you might be using, each with their own requirements and
>> oddities. If you say Gtk, or Qt, or Tk, or Windows MFC, or whatever
>> specific GUI framework you're using, then it becomes possible to say
>> something concrete about your situation.
>>
>> Based on later mails in the thread you seem to be using Gtk.
>>
>> I should note here that you seem to be using PyGtk (the "traditional"
>> Gtk 2 Python binding), which is deprecated. The modern version is to use
>> PyGI, the Python GObject-Introspection binding, and Gtk 3.
>>
>> When using PyGI, you have a choice of two D-Bus implementations: either
>> GDBus (part of gi.repository.GIO), or dbus-python ("import dbus"). I
>> would recommend GDBus, since dbus-python is constrained by backwards
>> compatibility with some flawed design decisions.
>>
>> However, assuming you're stuck with dbus-python:
>>
>> > I then used composition, wherein another class, "RemoteListener"
>> > deriving from "dbus.service.Object" was made an attribute of the "main"
>> > class. That worked.
>> > However, when I do
>> >
>> >dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
>> >GObject.mainloop.run()
>> >
>> > in the "RemoteListener"'s __init__ method, the GUI of the "main" class
>> > fails to load (apparently, because the "mainloop.run()" causes the
>> > singular, main-thread to go into busy-wait).
>>
>> Almost; it's not a busy-wait. GObject.mainloop.run() is the equivalent
>> of this pseudocode:
>>
>> def run(self):
>> while not global_default_main_context.someone_has_called_quit:
>> if global_default_main_context.has_more_events():
>> global_default_main_context.process_next_event()
>> else:
>> global_default_main_context.wait_for_an_event()
>>
>> so it will loop until someone calls GObject.mainloop.quit() or
>> equivalent, or forever if that never happens - but as long as nothing
>> "interesting" happens, it will block on a poll() or select() syscall in
>> what my pseudocode calls wait_for_an_event(), which is the right thing
>> to do in event-driven programming like GLib/Gtk.
>>
>> (If you replace the last line of my pseudocode with "continue", that
>> would be a busy-wait.)
>>
>> > I tried option b), but now instantiating "RemoteListener" in a separate
>> > thread
>>
>> It is unclear whether the dbus-glib main loop glue (as set up by
>> DBusGMainLoop) is thread-safe or not. The safest assumption is always
>> "if you don't know whether foo is thread-safe, it probably isn't". In
>> any case, if it *is* thread-safe, the subset of it that's exposed
>> through dbus-python isn't enough to use it in multiple threads.
>>
>> GDBus, as made available via PyGI (specifically, gi.repository.GIO), is
>> known to be thread-safe.
>>
>> > Is there a way to run GUI and a dbus-service together?
>>
>>
Re: [Python-Dev] PEP 3145 (With Contents)
On Dec 24, 2012 11:44 PM, "Brian Curtin" wrote: > > On Mon, Dec 24, 2012 at 7:42 AM, anatoly techtonik wrote: > > What should I do in case Eric lost interest after his GSoC project for PSF > > appeared as useless for python-dev community? Should I rewrite the proposal > > from scratch? > > Before you attempt that, start by trying to have a better attitude > towards people's contributions around here. Ignoring the extremely negative and counter-productive attitude (which if not changed could quite easily lead to no PEP editors wanting to work with you, Anatoly, and thus blocking your changes from being accepted), you are also ignoring the two other authors on that PEP, who also need to agree to adding you to the PEP as an author and your general direction/approach. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Raising OSError concrete classes from errno code
Currently we have exception tree of classes inherited from OSError When we use C API we can call PyErr_SetFromErrno and PyErr_SetFromErrnoWithFilename[Object] functions. This ones raise concrete exception class (FileNotFoundError for example) looking on implicit errno value. I cannot see the way to do it from python. Maybe adding builtin like exception_from_errno(errno, filename=None) make some value? Function returns exception instance, concrete class depends of errno value For example if I've got EPOLLERR from poller call I can get error code via s.getsockopt(SOL_SOCKET, SO_ERROR) but I cannot raise concrete exception from given errno code. -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising OSError concrete classes from errno code
2012/12/25 Andrew Svetlov : > Currently we have exception tree of classes inherited from OSError > When we use C API we can call PyErr_SetFromErrno and > PyErr_SetFromErrnoWithFilename[Object] functions. > This ones raise concrete exception class (FileNotFoundError for > example) looking on implicit errno value. > I cannot see the way to do it from python. > > Maybe adding builtin like exception_from_errno(errno, filename=None) > make some value? > Function returns exception instance, concrete class depends of errno value I think a static method on OSError like .from_errno would be good. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Raising OSError concrete classes from errno code
static method is better than new builtin function, agree. On Wed, Dec 26, 2012 at 12:03 AM, Benjamin Peterson wrote: > 2012/12/25 Andrew Svetlov : >> Currently we have exception tree of classes inherited from OSError >> When we use C API we can call PyErr_SetFromErrno and >> PyErr_SetFromErrnoWithFilename[Object] functions. >> This ones raise concrete exception class (FileNotFoundError for >> example) looking on implicit errno value. >> I cannot see the way to do it from python. >> >> Maybe adding builtin like exception_from_errno(errno, filename=None) >> make some value? >> Function returns exception instance, concrete class depends of errno value > > I think a static method on OSError like .from_errno would be good. > > > -- > Regards, > Benjamin -- Thanks, Andrew Svetlov ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
