Re: [PyQt] A dire warning message
On Fri, 8 Jul 2011 01:37:35 PM Baz Walter wrote: > On 08/07/11 02:36, Algis Kabaila wrote: > > On Fri, 8 Jul 2011 03:36:40 AM Baz Walter wrote: > > you would need to reboot for it to have an effect, as the plugin would > still be loaded in memory. > > in any case, it's not a real solution to your problem - just a possible > workaround if you don't want/need the functionality the plugin provides. > > really, i can't understand why kde chose to force this plugin on users. > i appreciate that many people want unified dialogs and so forth, but > it's pretty rude not to give users the option to disable something which > affects non-kde applications. Baz, Good point! After deleting the plugin and a reboot: ak@supremo:~/save$ ls -la /usr/lib/kde4/plugins/gui_platform/ total 8 drwxr-xr-x 2 root root 4096 2011-07-08 15:02 . drwxr-xr-x 9 root root 4096 2011-04-27 21:15 .. ak@supremo:~/save$ ak@supremo:~/save$ python3 save.py KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work ak@supremo:~/save$ I am leaving the libkde.so in my data partition, just in case.. Thanks for your help. OldAl. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] A dire warning message
On 08/07/11 02:36, Algis Kabaila wrote: On Fri, 8 Jul 2011 03:36:40 AM Baz Walter wrote: Hmm, at the first glance, this is a KDE problem, since KDE plugs its own file dialog into Qt, but fails to properly deal with locales there after due to them not being initialized correctly. This is going to produce issues, if you're calling QFileDialogs and expects them being localized correctly. It might be possible to circumvent these issues by instancing KApplication instead of QApplication (and doing the proper KDE4 setup sequence). yes, the problem is indirectly caused by a "compatibility" plugin that invokes the kde open-dialog instead of the one provided by qt. the offending plugin is usually installed here: /usr/lib/kde4/plugins/gui_platform/libkde.so personally, i always remove it whenever kde is updated. Baz, Being a careful (and easily rattled) old soul, I did not remove libke.so, but moved it to my data partition, so that I would have a chance to "reinstate" it if it was necessary. Have not noticed any harmful effects - Kmail continued to work, opening and saving files. Unfortunately, it did not have any effect on the "dire warning message", as the following dialog shows: ak@supremo:~/save$ python3 save.py KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work ak@supremo:~/save$ There is no change as far as the little test script shows. Perhaps I am too timid, but I copied back the libkde.so where it was, namely /usr/lib/kde4/plugins/gui_platform/libkde.so you would need to reboot for it to have an effect, as the plugin would still be loaded in memory. in any case, it's not a real solution to your problem - just a possible workaround if you don't want/need the functionality the plugin provides. really, i can't understand why kde chose to force this plugin on users. i appreciate that many people want unified dialogs and so forth, but it's pretty rude not to give users the option to disable something which affects non-kde applications. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] A dire warning message
On Fri, 8 Jul 2011 03:36:40 AM Baz Walter wrote: > On 07/07/11 13:00, Algis Kabaila wrote: > > On Thu, 7 Jul 2011 09:03:47 PM Hans-Peter Jansen wrote: > >>> On opening a file dialog, I get this warning: > >>> > >>> KGlobal::locale::Warning your global KLocale is being recreated with > >>> a valid main component instead of a fake component, this usually > >>> means you tried to call i18n related functions before your main > >>> component was created. You should not do that since it most likely > >>> will not work > >>> > >>> Search on the net seems to give some grim news: > >>> > >>> > >>> Re: VLC Hangs on Open File dialog > >>> Postby Rémi Denis-Courmont » Sat Jan 29, 2011 11:58 pm > >>> In the mean time, someone in KDE actually looked at the issue. > >>> It turns to be a longstanding known bug in the QProcess class from > >>> Qt4. That bug gets triggered by a new "feature" in KDE 4.6 relative > >>> to MIME types in the Open and Save dialogs, that happens to involve > >>> the QProcess class. > >>> > >>> In the end, VLC is blaming KDE, KDE is blaming Qt, and Qt is blaming > >>> the kernel. > >>> > >>> ''' > > according to that thread, the problem has been fixed in kde-4.6.1. are > you able to upgrade? > > >> Hmm, at the first glance, this is a KDE problem, since KDE plugs its own > >> file dialog into Qt, but fails to properly deal with locales there > >> after due to them not being initialized correctly. This is going to > >> produce issues, if you're calling QFileDialogs and expects them being > >> localized correctly. It might be possible to circumvent these issues by > >> instancing KApplication instead of QApplication (and doing the proper > >> KDE4 setup sequence). > > yes, the problem is indirectly caused by a "compatibility" plugin that > invokes the kde open-dialog instead of the one provided by qt. > > the offending plugin is usually installed here: > > /usr/lib/kde4/plugins/gui_platform/libkde.so > > personally, i always remove it whenever kde is updated. Baz, Being a careful (and easily rattled) old soul, I did not remove libke.so, but moved it to my data partition, so that I would have a chance to "reinstate" it if it was necessary. Have not noticed any harmful effects - Kmail continued to work, opening and saving files. Unfortunately, it did not have any effect on the "dire warning message", as the following dialog shows: ak@supremo:~/save$ python3 save.py KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work ak@supremo:~/save$ There is no change as far as the little test script shows. Perhaps I am too timid, but I copied back the libkde.so where it was, namely /usr/lib/kde4/plugins/gui_platform/libkde.so Thank you again for the interesting suggestion. OldAl. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] A dire warning message
On Fri, 8 Jul 2011 08:46:24 AM David Boddie wrote: > On Thu, 7 Jul 2011 16:04:29 +0200, Hans-Peter Jansen wrote: > > On Thursday 07 July 2011, 14:00:28 Algis Kabaila wrote: > > > The message does occur exactly the same way when the scripts are > > > fired from CLI. I should try it on a gnome desktop in order to avoid > > > PyKDE4. > > > > No, it's not a PyKDE4 issue. It's triggered deep under the covers > > somewhere between KDE4 and Qt4. We will have to wait for the respective > > people to have it fixed one day. > > Could it be a style issue? There's some interaction between Qt and KDE in > the style engine. > > David @Pete - I really do appreciate your helpful comments. It is people like you that keep me interested in software issues "at the sunset of my life" (as my even older sister says - "I don't mind dying, just not today - and not tomorrow"):) @Baz - yes, I've noticed that "find" in the message. Checked the "help" on my Konqueror. The "about KDE" indicates that KDE is 4.6.2. So one notch newer than the version where the problem has been fixed. The suggestion to remove the "compatibility" plugin is certainly worth trying. I will try it and report back the result. @ David - interesting suggestion, but it leaves me wondering how to make use of it. There is every likelihood that there is "some interaction". Thank you one and all. Greatly appreciated. OldAl. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] A dire warning message
On Thu, 7 Jul 2011 16:04:29 +0200, Hans-Peter Jansen wrote: > On Thursday 07 July 2011, 14:00:28 Algis Kabaila wrote: > > > The message does occur exactly the same way when the scripts are > > fired from CLI. I should try it on a gnome desktop in order to avoid > > PyKDE4. > > No, it's not a PyKDE4 issue. It's triggered deep under the covers > somewhere between KDE4 and Qt4. We will have to wait for the respective > people to have it fixed one day. Could it be a style issue? There's some interaction between Qt and KDE in the style engine. David ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] PyQt/SIP with no tp_mro
Oh, also, the event that was triggered was a DeferredDelete event, in
case it helps to know that.
On Thu, Jul 7, 2011 at 2:27 PM, Paul Bonser wrote:
> I'm running into an issue with SIP/PyQt where sip_api_is_py_method is
> getting called and it is segfaulting when it gets to this section:
>
>> cls = (PyObject *)Py_TYPE(sipSelf);
>> mro = ((PyTypeObject *)cls)->tp_mro;
>> assert(PyTuple_Check(mro));
>
> Because mro ends up being NULL.
>
> This is the backtrace:
>
> #0 0x7f880d00d8ef in sip_api_is_py_method (gil=0x7fff6a7b6d6c,
> pymc=0x587e7e9 "", sipSelf=0x4e21b90, cname=0x0, mname=0x7f880c81cf92
> "eventFilter") at siplib.c:7586
> #1 0x7f880c7e3cb0 in sipQObject::eventFilter (this=0x587e7d0,
> a0=0x57e6660, a1=0x5cde260) at sipQtCoreQObject.cpp:360
> #2 0x7f880c276627 in
> QCoreApplicationPrivate::sendThroughObjectEventFilters (this= optimized out>, receiver=0x57e6660, event=0x5cde260) at
> kernel/qcoreapplication.cpp:846
> #3 0x7f8809f549b1 in QApplicationPrivate::notify_helper
> (this=0x19e6820, receiver=0x57e6660, e=0x5cde260) at
> kernel/qapplication.cpp:4453
> #4 0x7f8809f593aa in QApplication::notify (this=0x1f8c960,
> receiver=0x57e6660, e=0x5cde260) at kernel/qapplication.cpp:3861
> #5 0x7f880b146d28 in sipQApplication::notify (this=0x1f8c960,
> a0=0x57e6660, a1=0x5cde260) at sipQtGuiQApplication.cpp:297
> #6 0x7f880c27649c in QCoreApplication::notifyInternal
> (this=0x1f8c960, receiver=0x57e6660, event=0x5cde260) at
> kernel/qcoreapplication.cpp:731
> #7 0x7f880c279c25 in sendEvent (receiver=0x0, event_type=0,
> data=0x1f8b4c0) at
> ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
> #8 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0,
> event_type=0, data=0x1f8b4c0) at kernel/qcoreapplication.cpp:1372
> #9 0x7f880c2a1253 in sendPostedEvents (s=0x1fa4560) at
> ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220
> #10 postEventSourceDispatch (s=0x1fa4560) at
> kernel/qeventdispatcher_glib.cpp:277
> #11 0x7f880ba61bcd in g_main_context_dispatch () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #12 0x7f880ba623a8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #13 0x7f880ba62639 in g_main_context_iteration () from
> /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #14 0x7f880c2a13ef in QEventDispatcherGlib::processEvents
> (this=0x1fa1be0, flags=) at
> kernel/qeventdispatcher_glib.cpp:422
> #15 0x7f8809ffbdfe in QKeyMapperPrivate::possibleKeysCore
> (this=0x7f880c279f9f, event=) at
> kernel/qkeymapper_x11.cpp:386
> #16 0x03a16030 in ?? ()
> #17 0x7fff05384200 in ?? ()
> #18 0x00220013 in ?? ()
> #19 0x0398ec34 in ?? ()
> #20 0x03979b40 in ?? ()
> #21 0x0398cd40 in ?? ()
> #22 0x03927f50 in ?? ()
> #23 0x in ?? ()
>
> Can anyone tell me in what situations tp_mro might end up being NULL?
> It seems like that should really only be the case during object
> initialization, right?
>
> Adding the following before the assert line seems to alleviate the issue:
>
>> if (mro == NULL)
>> {
>> #ifdef WITH_THREAD
>> PyGILState_Release(*gil);
>> #endif
>> return NULL;
>> }
>
> Is this a valid solution, or should the problem be tracked down to the
> source of tp_mro being NULL?
>
> --
> Paul Bonser | http://probablyprogramming.com | @pib
>
--
Paul Bonser | http://probablyprogramming.com | @pib
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] PyQt/SIP with no tp_mro
I'm running into an issue with SIP/PyQt where sip_api_is_py_method is
getting called and it is segfaulting when it gets to this section:
> cls = (PyObject *)Py_TYPE(sipSelf);
> mro = ((PyTypeObject *)cls)->tp_mro;
> assert(PyTuple_Check(mro));
Because mro ends up being NULL.
This is the backtrace:
#0 0x7f880d00d8ef in sip_api_is_py_method (gil=0x7fff6a7b6d6c,
pymc=0x587e7e9 "", sipSelf=0x4e21b90, cname=0x0, mname=0x7f880c81cf92
"eventFilter") at siplib.c:7586
#1 0x7f880c7e3cb0 in sipQObject::eventFilter (this=0x587e7d0,
a0=0x57e6660, a1=0x5cde260) at sipQtCoreQObject.cpp:360
#2 0x7f880c276627 in
QCoreApplicationPrivate::sendThroughObjectEventFilters (this=, receiver=0x57e6660, event=0x5cde260) at
kernel/qcoreapplication.cpp:846
#3 0x7f8809f549b1 in QApplicationPrivate::notify_helper
(this=0x19e6820, receiver=0x57e6660, e=0x5cde260) at
kernel/qapplication.cpp:4453
#4 0x7f8809f593aa in QApplication::notify (this=0x1f8c960,
receiver=0x57e6660, e=0x5cde260) at kernel/qapplication.cpp:3861
#5 0x7f880b146d28 in sipQApplication::notify (this=0x1f8c960,
a0=0x57e6660, a1=0x5cde260) at sipQtGuiQApplication.cpp:297
#6 0x7f880c27649c in QCoreApplication::notifyInternal
(this=0x1f8c960, receiver=0x57e6660, event=0x5cde260) at
kernel/qcoreapplication.cpp:731
#7 0x7f880c279c25 in sendEvent (receiver=0x0, event_type=0,
data=0x1f8b4c0) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:215
#8 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0,
event_type=0, data=0x1f8b4c0) at kernel/qcoreapplication.cpp:1372
#9 0x7f880c2a1253 in sendPostedEvents (s=0x1fa4560) at
../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:220
#10 postEventSourceDispatch (s=0x1fa4560) at
kernel/qeventdispatcher_glib.cpp:277
#11 0x7f880ba61bcd in g_main_context_dispatch () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x7f880ba623a8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7f880ba62639 in g_main_context_iteration () from
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x7f880c2a13ef in QEventDispatcherGlib::processEvents
(this=0x1fa1be0, flags=) at
kernel/qeventdispatcher_glib.cpp:422
#15 0x7f8809ffbdfe in QKeyMapperPrivate::possibleKeysCore
(this=0x7f880c279f9f, event=) at
kernel/qkeymapper_x11.cpp:386
#16 0x03a16030 in ?? ()
#17 0x7fff05384200 in ?? ()
#18 0x00220013 in ?? ()
#19 0x0398ec34 in ?? ()
#20 0x03979b40 in ?? ()
#21 0x0398cd40 in ?? ()
#22 0x03927f50 in ?? ()
#23 0x in ?? ()
Can anyone tell me in what situations tp_mro might end up being NULL?
It seems like that should really only be the case during object
initialization, right?
Adding the following before the assert line seems to alleviate the issue:
> if (mro == NULL)
> {
> #ifdef WITH_THREAD
> PyGILState_Release(*gil);
> #endif
> return NULL;
> }
Is this a valid solution, or should the problem be tracked down to the
source of tp_mro being NULL?
--
Paul Bonser | http://probablyprogramming.com | @pib
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] A dire warning message
On 07/07/11 13:00, Algis Kabaila wrote: On Thu, 7 Jul 2011 09:03:47 PM Hans-Peter Jansen wrote: On opening a file dialog, I get this warning: KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work Search on the net seems to give some grim news: Re: VLC Hangs on Open File dialog Postby Rémi Denis-Courmont » Sat Jan 29, 2011 11:58 pm In the mean time, someone in KDE actually looked at the issue. It turns to be a longstanding known bug in the QProcess class from Qt4. That bug gets triggered by a new "feature" in KDE 4.6 relative to MIME types in the Open and Save dialogs, that happens to involve the QProcess class. In the end, VLC is blaming KDE, KDE is blaming Qt, and Qt is blaming the kernel. ''' according to that thread, the problem has been fixed in kde-4.6.1. are you able to upgrade? Hmm, at the first glance, this is a KDE problem, since KDE plugs its own file dialog into Qt, but fails to properly deal with locales there after due to them not being initialized correctly. This is going to produce issues, if you're calling QFileDialogs and expects them being localized correctly. It might be possible to circumvent these issues by instancing KApplication instead of QApplication (and doing the proper KDE4 setup sequence). yes, the problem is indirectly caused by a "compatibility" plugin that invokes the kde open-dialog instead of the one provided by qt. the offending plugin is usually installed here: /usr/lib/kde4/plugins/gui_platform/libkde.so personally, i always remove it whenever kde is updated. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Help with Login Dialog / QThread issues
Hello,
I am trying to create a login dialog for my application.
Logging in can take a couple of seconds so I wanted to show a progress
bar during the login process.
I think that for my QProgressBar to animate during this time, I need
to log in on a different thread. Is this true?
So, below I have what I think is a working example.
Is there a better way to call QDialog's accept slot when the login
thread is finished than how I am doing it via functools.partial?
It seems a bit hacky.
from functools import partial
class LoginThread(QThread):
def __init__(self, username, password, parent=None):
super(LoginThread, self).__init__(parent)
self.username = username
self.password = password
def run(self):
LOGIN(
self.username,
self.password,
)
class LoginDialog(QDialog, Ui_LoginDialog):
def __init__(self, *args, **kwargs):
super(LoginDialog, self).__init__(*args, **kwargs)
self.setupUi(self)
self.progressbar.hide()
def accept(self):
self.progressbar.setMinimum(0)
self.progressbar.setMaximum(0)
self.progressbar.show()
self.lt = LoginThread(
str(self.username_edit.text()),
str(self.password_edit.text())
)
self.connect(self.lt, SIGNAL('finished()'),
partial(QDialog.accept, self))
self.lt.start()
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] A dire warning message
On Thursday 07 July 2011, 14:00:28 Algis Kabaila wrote: > On Thu, 7 Jul 2011 09:03:47 PM Hans-Peter Jansen wrote: > > Dear Al, > > > > On Thursday 07 July 2011, 11:22:34 Algis Kabaila wrote: > > > This bothersome warning message probably has nothing to do with > > > PyQt. However, it does occur whenever I use PyQt. No great harm > > > seems to occur and the programs function normally, except for > > > that message. Is there something wrong with my setup or should I > > > just forget all about it? > > > > > > I attach a little test program "open.py". It does not do anything > > > - and just tries to open a file dialog after a click on the > > > pushButton. That produces the error message. > > > > > > The "program" is mainly filled with the message itself and some > > > comments. I would think that this probably has been dealt with, > > > but I will not know if I do not ask... so thanks again for your > > > patience. OTH, may be other people will find this informative, > > > too - or am the only one being subjected to this warning? > > > > > > #!/usr/bin/env python3.2 > > > ''' > > > open.py - a sample program to show the dire warning it generates > > > and every other program that tries to use a file read dialog. > > > Platform - kubuntu 11.04 "natty" > > > Python 3.2 > > > Qt 4.7.2 (from "natty" binaries. > > > PyQt4 4.8.4 - bound to Python 3.2 whilst compiling > > > > > > On opening a file dialog, I get this warning: > > > > > > KGlobal::locale::Warning your global KLocale is being recreated > > > with a valid main component instead of a fake component, this > > > usually means you tried to call i18n related functions before > > > your main component was created. You should not do that since it > > > most likely will not work > > > > > > Search on the net seems to give some grim news: > > > > > > > > > Re: VLC Hangs on Open File dialog > > > Postby Rémi Denis-Courmont » Sat Jan 29, 2011 11:58 pm > > > In the mean time, someone in KDE actually looked at the issue. > > > It turns to be a longstanding known bug in the QProcess class > > > from Qt4. That bug gets triggered by a new "feature" in KDE 4.6 > > > relative to MIME types in the Open and Save dialogs, that happens > > > to involve the QProcess class. > > > > > > In the end, VLC is blaming KDE, KDE is blaming Qt, and Qt is > > > blaming the kernel. > > > > > > ''' > > > > Hmm, at the first glance, this is a KDE problem, since KDE plugs > > its own file dialog into Qt, but fails to properly deal with > > locales there after due to them not being initialized correctly. > > This is going to produce issues, if you're calling QFileDialogs and > > expects them being localized correctly. It might be possible to > > circumvent these issues by instancing KApplication instead of > > QApplication (and doing the proper KDE4 setup sequence). > > > > Detlev is doing a nice trick in eric4: it checks, if PyKDE4 is > > available, and uses it, otherwise it uses plain Qt4. > > > > How this could be related to QProcess escapes me but what do I > > know.. > > > > Pete > > Yes, I recall Detlev putting me right on other issues with PyKDE4 - > requires putting a tick on one of the configuration boxes of eric. I > am using eric5 (that's the python3 version). I will install the > newest version and look for the "box to tick" - Detlev is a very > helpful guy! Yes, and eric is awesome. But unfortunately, even eric (4.4.16 at least) using PyKDE4 code suffer from this, too. Hence I was wrong. > The message does occur exactly the same way when the scripts are > fired from CLI. I should try it on a gnome desktop in order to avoid > PyKDE4. No, it's not a PyKDE4 issue. It's triggered deep under the covers somewhere between KDE4 and Qt4. We will have to wait for the respective people to have it fixed one day. You will get rid of it, if you deinstall kdelibs4 and all dependencies, but probably, it's easier to wait and live with it. > IIRIC, PyKDE4 is not windows compatible. And that is a > problem if one wants to ensure compatibility with Windows - I do not > really care about that. Too late for me :). That was a red herring. See above. Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] A dire warning message
On Thu, 7 Jul 2011 09:03:47 PM Hans-Peter Jansen wrote: > Dear Al, > > On Thursday 07 July 2011, 11:22:34 Algis Kabaila wrote: > > This bothersome warning message probably has nothing to do with PyQt. > > However, it does occur whenever I use PyQt. No great harm seems to > > occur and the programs function normally, except for that message. > > Is there something wrong with my setup or should I just forget all > > about it? > > > > I attach a little test program "open.py". It does not do anything - > > and just tries to open a file dialog after a click on the > > pushButton. That produces the error message. > > > > The "program" is mainly filled with the message itself and some > > comments. I would think that this probably has been dealt with, but I > > will not know if I do not ask... so thanks again for your patience. > > OTH, may be other people will find this informative, too - or am the > > only one being subjected to this warning? > > > > #!/usr/bin/env python3.2 > > ''' > > open.py - a sample program to show the dire warning it generates > > and every other program that tries to use a file read dialog. > > Platform - kubuntu 11.04 "natty" > > Python 3.2 > > Qt 4.7.2 (from "natty" binaries. > > PyQt4 4.8.4 - bound to Python 3.2 whilst compiling > > > > On opening a file dialog, I get this warning: > > > > KGlobal::locale::Warning your global KLocale is being recreated with > > a valid main component instead of a fake component, this usually > > means you tried to call i18n related functions before your main > > component was created. You should not do that since it most likely > > will not work > > > > Search on the net seems to give some grim news: > > > > > > Re: VLC Hangs on Open File dialog > > Postby Rémi Denis-Courmont » Sat Jan 29, 2011 11:58 pm > > In the mean time, someone in KDE actually looked at the issue. > > It turns to be a longstanding known bug in the QProcess class from > > Qt4. That bug gets triggered by a new "feature" in KDE 4.6 relative > > to MIME types in the Open and Save dialogs, that happens to involve > > the QProcess class. > > > > In the end, VLC is blaming KDE, KDE is blaming Qt, and Qt is blaming > > the kernel. > > > > ''' > > Hmm, at the first glance, this is a KDE problem, since KDE plugs its own > file dialog into Qt, but fails to properly deal with locales there > after due to them not being initialized correctly. This is going to > produce issues, if you're calling QFileDialogs and expects them being > localized correctly. It might be possible to circumvent these issues by > instancing KApplication instead of QApplication (and doing the proper > KDE4 setup sequence). > > Detlev is doing a nice trick in eric4: it checks, if PyKDE4 is > available, and uses it, otherwise it uses plain Qt4. > > How this could be related to QProcess escapes me but what do I know.. > > Pete Yes, I recall Detlev putting me right on other issues with PyKDE4 - requires putting a tick on one of the configuration boxes of eric. I am using eric5 (that's the python3 version). I will install the newest version and look for the "box to tick" - Detlev is a very helpful guy! The message does occur exactly the same way when the scripts are fired from CLI. I should try it on a gnome desktop in order to avoid PyKDE4. IIRIC, PyKDE4 is not windows compatible. And that is a problem if one wants to ensure compatibility with Windows - I do not really care about that. Too late for me :). Thanks, Pete, Al. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] A dire warning message
Dear Al, On Thursday 07 July 2011, 11:22:34 Algis Kabaila wrote: > This bothersome warning message probably has nothing to do with PyQt. > However, it does occur whenever I use PyQt. No great harm seems to > occur and the programs function normally, except for that message. > Is there something wrong with my setup or should I just forget all > about it? > > I attach a little test program "open.py". It does not do anything - > and just tries to open a file dialog after a click on the > pushButton. That produces the error message. > > The "program" is mainly filled with the message itself and some > comments. I would think that this probably has been dealt with, but I > will not know if I do not ask... so thanks again for your patience. > OTH, may be other people will find this informative, too - or am the > only one being subjected to this warning? > > #!/usr/bin/env python3.2 > ''' > open.py - a sample program to show the dire warning it generates > and every other program that tries to use a file read dialog. > Platform - kubuntu 11.04 "natty" > Python 3.2 > Qt 4.7.2 (from "natty" binaries. > PyQt4 4.8.4 - bound to Python 3.2 whilst compiling > > On opening a file dialog, I get this warning: > > KGlobal::locale::Warning your global KLocale is being recreated with > a valid main component instead of a fake component, this usually > means you tried to call i18n related functions before your main > component was created. You should not do that since it most likely > will not work > > Search on the net seems to give some grim news: > > > Re: VLC Hangs on Open File dialog > Postby Rémi Denis-Courmont » Sat Jan 29, 2011 11:58 pm > In the mean time, someone in KDE actually looked at the issue. > It turns to be a longstanding known bug in the QProcess class from > Qt4. That bug gets triggered by a new "feature" in KDE 4.6 relative > to MIME types in the Open and Save dialogs, that happens to involve > the QProcess class. > > In the end, VLC is blaming KDE, KDE is blaming Qt, and Qt is blaming > the kernel. > > ''' Hmm, at the first glance, this is a KDE problem, since KDE plugs its own file dialog into Qt, but fails to properly deal with locales there after due to them not being initialized correctly. This is going to produce issues, if you're calling QFileDialogs and expects them being localized correctly. It might be possible to circumvent these issues by instancing KApplication instead of QApplication (and doing the proper KDE4 setup sequence). Detlev is doing a nice trick in eric4: it checks, if PyKDE4 is available, and uses it, otherwise it uses plain Qt4. How this could be related to QProcess escapes me but what do I know.. Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] A dire warning message
This bothersome warning message probably has nothing to do with PyQt. However, it does occur whenever I use PyQt. No great harm seems to occur and the programs function normally, except for that message. Is there something wrong with my setup or should I just forget all about it? I attach a little test program "open.py". It does not do anything - and just tries to open a file dialog after a click on the pushButton. That produces the error message. The "program" is mainly filled with the message itself and some comments. I would think that this probably has been dealt with, but I will not know if I do not ask... so thanks again for your patience. OTH, may be other people will find this informative, too - or am the only one being subjected to this warning? #!/usr/bin/env python3.2 ''' open.py - a sample program to show the dire warning it generates and every other program that tries to use a file read dialog. Platform - kubuntu 11.04 "natty" Python 3.2 Qt 4.7.2 (from "natty" binaries. PyQt4 4.8.4 - bound to Python 3.2 whilst compiling On opening a file dialog, I get this warning: KGlobal::locale::Warning your global KLocale is being recreated with a valid main component instead of a fake component, this usually means you tried to call i18n related functions before your main component was created. You should not do that since it most likely will not work Search on the net seems to give some grim news: Re: VLC Hangs on Open File dialog Postby Rémi Denis-Courmont » Sat Jan 29, 2011 11:58 pm In the mean time, someone in KDE actually looked at the issue. It turns to be a longstanding known bug in the QProcess class from Qt4. That bug gets triggered by a new "feature" in KDE 4.6 relative to MIME types in the Open and Save dialogs, that happens to involve the QProcess class. In the end, VLC is blaming KDE, KDE is blaming Qt, and Qt is blaming the kernel. ''' import sys from PyQt4.QtGui import QDialog, QFileDialog, QApplication from ui_open import Ui_Dialog class Dialog(QDialog, Ui_Dialog): def __init__(self, parent=None): super().__init__(parent) self.setupUi(self) self.pushButton.clicked.connect(self.open) def open(self): fname = QFileDialog.getOpenFileName(self, "Open File", '.', "Files (*.*)") # The following warning message is generated: # KGlobal::locale::Warning your global KLocale is being recreated with # a valid main component instead of a fake component, this usually # means you tried to call i18n related functions before your main # component was created. You should not do that since it most likely # will not work if __name__ == '__main__': app = QApplication(sys.argv) frame = Dialog() frame.show() app.exec_() open.ui Description: application/designer ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] SIP: newbie question 3
Thanks for all the help! Here is a 3rd and last question.
Once I have figured this one out, I will be done porting my project from
boost.python to SIP.
I need to translate C++ exceptions to Python exceptions.
I have a function that does that:
void translate(const std::exception& e)
{
if(dynamic_cast(&e))
PyErr_SetString(PyExc_IOError, e.what());
else if(dynamic_cast(&e))
PyErr_SetString(PyExc_EOFError, e.what());
...
}
Next I need to "apply" this function to all wrapped functions.
With boost.python I do that as follows:
boost::python::register_exception_translator(&translate);
With SWIG I do:
%exception {
try {
$action
} catch(const std::exception& e) {
translate(e);
return NULL;
}
}
How do I do that with SIP?
___
PyQt mailing listPyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
