Re: [PyQt] SVG Glyphs in PyQt
Kyle Covington wrote: Anyway, my solution is providing a good workaround for the problem, I just wanted to give the code out in case someone else was having the same issue. If pyqt would like an example of a cairo svg from R that didn't render I can send one if you would like to tackle the problem. It's probably worth submitting this as a qt bug, as it's likely to be a problem in qt itself. If you can write a quick testcase that is. Jeremy -- http://www.jeremysanders.net/ ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Howto use the Qt documentation successfully - Was: Re: Access to lines of text on textEdit.
On Wednesday 15 September 2010, 01:25:39 Peter Milliken wrote: On Wed, Sep 15, 2010 at 9:05 AM, Hans-Peter Jansen h...@urpla.net wrote: Come on, Peter, that's not fair. Phil decided to not provide the bulky docs in an otherwise pretty complete package for Windows users: please respect that. He has to pay for your downloads in some ways (and is doing a lot of work for generating those packages beforehand). It was an attempt at constructive criticism, I have only admiration for the job Phil is doing. But perhaps some hints as to what is missing, why and where you can go to fill in the blanks would be appropriate? You do WANT people to take up PyQt don't you? Please take my comments in the vein of making you aware of where improvements may be possible. I do after all come from that unique standpoint of being completely new to PyQt and Qt :-) Didn't I mentioned this in the following paragraph that you omitted? You get what you deserve. It's *your* decision after all. Pete True :-) After reviewing and reflecting on my experiences with PyQt over the last two weeks and also considering the implications of some of your comments here which relate to a depth of knowledge that isn't immediately obvious to a newbie such as myself, I think I will abandon my migration to PyQt and Qt for the foreseeable future. I think you all do a sterling job in promoting and supporting PyQt but at this point of time I think I deserve something that requires a little less work :-). I'm sorry to hear that. Getting used to of something that big is taking a while, and you tackled already some of the advanced aspects that doesn't help in this respect either (threads, composites, py2 to py3 transition). Unfortunately, you never reached a state, where you solely enjoyed the power of it: using tables with a million rows without any noticeable delay (even if they originate from some database server), redesigning complex UIs within minutes, using self created composites within designer, full unicode and i18n support, complete documentation, great books, support, etc... Then you start to realize, how simple it is to add your own C++ modules, that these objects are pure compiled code (ultra thin C/C++ interface layer, no python trampolines at all), and even huge class hierarchies load instantly (due to delayed lookup). I will stop here.. I've done projects with tkinter, pmw, wxpython and always regretted it at some point: painfully slow startup and runtime, convoluted code and concepts, missing features, non deterministic behavior changes across platforms, to name a few. Ever tried to track problems down to its bones through all the layers: I did, and it was a nightmare. Qt on the other hand is comprehensible in most aspects as well as sound in most concepts, and it is just _one_ layer away from your python code (the thin, mostly boring, sip layer code in between). If there ever will be usable python apps on mobile devices (they will) with complex UIs, that not always let the user remember the interpreted python penalty, those will be from our camp. I have enjoyed my journey and I don't regret the time I have spent bouncing around in the PyQt world - perhaps one day I might dust off my books and notes and revisit. Thanks for the efforts You're still welcome ;-) Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] SVG Glyphs in PyQt
On 15 Sep 2010, at 09:57, Jeremy Sanders wrote: Kyle Covington wrote: Anyway, my solution is providing a good workaround for the problem, I just wanted to give the code out in case someone else was having the same issue. If pyqt would like an example of a cairo svg from R that didn't render I can send one if you would like to tackle the problem. It's probably worth submitting this as a qt bug, as it's likely to be a problem in qt itself. If you can write a quick testcase that is. Off-list Kyle provided me with a quite large example file. I have cut it down to the attached test case. On my platform (Mac OS X 10.6.4, PyQt-mac-gpl-4.7.6 and Qt 4.6.3) Safari, Firefox and Gimp display it as a rectangle with a letter L in the middle of it. The Qt and PyQt versions of the svgviewer demo both display only the rectangle. I'll leave it to Kyle to report the bug since he discovered it. -- Colin inline: test-2.svg___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Howto use the Qt documentation successfully - Was: Re: Access to lines of text on textEdit.
On Wed, Sep 15, 2010 at 1:25 AM, Peter Milliken peter.milli...@gmail.com wrote: After reviewing and reflecting on my experiences with PyQt over the last two weeks and also considering the implications of some of your comments here which relate to a depth of knowledge that isn't immediately obvious to a newbie such as myself, I think I will abandon my migration to PyQt and Qt for the foreseeable future. I think you all do a sterling job in promoting and supporting PyQt but at this point of time I think I deserve something that requires a little less work :-). I have enjoyed my journey and I don't regret the time I have spent bouncing around in the PyQt world - perhaps one day I might dust off my books and notes and revisit. Thanks for the efforts Again, that is your choice and yours alone. However, as a fellow newbie, I suggest you might perhaps reconsider and not stop at the first bump(s) in the road. Sticking with what you know can be both a short-term gain and a long-term loss. A (very) amateur programmer myself, I have made such a fundamental choice many, many years ago in (slowly) learning Python and using it exclusively, never looking back. I consider that choice a good one, because Python is one of those rare opportunities of short-term *and* long-term gain. Choosing a toolkit to build GUI apps in Python, however, was very far from such a clear-cut process. Over the years I have tried my hand at quite a few such frameworks, some mainstream, some obscure : wxPython (and the nice but orphaned PyCard), PyGTK, pyGame and whatnot (with the notable exception of TkInter). I was never able to quite wrap my mind around any of them, either because of their own limitations or mine, lack of proper documentation and support tools, etc. (Py)Qt is the last one I tried (mostly due to the Nokia happenings), and it is also the first one that started to make sense to me after a while. Over the last 12 months it has enabled me to achieve non-trivial stuff I had previously thought out of my reach. Yes, it definitely is a huge mouthful at first, it certainly has its warts too, but it is the most coherent and complete tool I have seen to date, with comprehensive (if dense :-) documentation, a deep mine of information on the Web, good support tools, a helpful community, and enough heavyweights behind it to ensure it will keep evolving for the foreseeable future. The main hassle, at the very start, is realizing over and over again that you have written too much complicated code because you didn't look well enough first to find the one single line that does what you need. But that fades away after a while, leaving just the deep enjoyment (as others have already said) of reading the C++ docs, then appreciating how much easier it is once translated to Python :-) Good luck, fp ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Howto use the Qt documentation successfully - Was: Re: Access to lines of text on textEdit.
On Wed, Sep 15, 2010 at 12:06 PM, Hans-Peter Jansen h...@urpla.net wrote: You're still welcome ;-) Oooops, I took too long to write that message, and Hans-Peter beat me to the punch, with almost the same arguments :-) ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Howto use the Qt documentation successfully - Was: Re: Access to lines of text on textEdit.
On Wed, Sep 15, 2010 at 12:06 PM, Hans-Peter Jansen h...@urpla.net wrote: If there ever will be usable python apps on mobile devices (they will) with complex UIs, that not always let the user remember the interpreted python penalty, those will be from our camp. Actually there are a lot of those already, thanks to Nokia's Maemo5 Linux platform and the N900 device. Although originally in GTK, the Maemo UI is evolving to Qt in the next revision, and further on with the Nokia/Intel MeeGo venture. Meanwhile, Qt, Python and PyQt are officially supported on the N900, and a large fraction of the interesting third-party apps provided by the community rely on those. I'm finishing one myself currently :-) ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] dip model types, properties, and syntax
class ExampleModel(Model): name = Str() @name.getter def name(self): return self._name I have an additional suggestion to follow up on this syntax. If a model type's __call__ method were changed to call its getter method, rather than return the default value, I think it would be possible to do: class Test(Model): foo = Str() @Str() def bar(self): return self._bar That seems like a natural extension of the syntax to me, very similar to using python's property built-in as a decorator. As things currently stand, I thought we should already be able to do: class Test(Model): foo = Str() @Str().getter def bar(self): return self._bar but for reasons I don't understand, that raises a SyntaxError. Darren ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] timers from mainwindow
Of course thats it, thanks :) On 09/14/2010 08:01 PM, Doug Bell wrote: Sebastian Elsner wrote: I would like to start a QTimer from a mainwindow's menu, creating a new instance of a custom class. See the example below. All works except the timer's callback is never called. Asking if the timer is active returns True. I ran out of ideas. Maybe I misunderstand how timers work?! Any help appreciated. def doit(self): Timers() You're not keeping a reference to your Timers instance. It's getting garbage collected before the timer fires. Doug ___ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Howto use the Qt documentation successfully
I'd like to second Peter Milliken's sentiments. The PyQt documentation that's available is (in my opinion) pretty poor. Finding a way to do something that you haven't done before by browsing the documentation is nearly impossible. Or at least it's so frustrating and time-consuming that I often give up before finding what I need. The only way I've successfully implemented something is by starting with a working example I find by googling or in Mark Summerfield's book and vary it to suit my needs. That's not an ok method for serious programming. To be more concrete, I think there are at least two main shortcomings. 1) good meta-documentation isn't available. (Or, if it is available, I haven't found it.) One part of the meta-documentation would guide you to the classes, procedures, etc. you should read based on the tasks you want to accomplish, and say which classes go together. It would contain indexed annotations on the existing pages so, for example, if I want to program a way to edit fields in a database I could look in its index under fields or database or edit and I would be taken to a listing of all the relevant classes (not just the ones with those words on their pages) with annotations about what each does. Or if I want to control an external device I would find an annotated listing of the classes that might be applicable. This would have to be written by hand, not generated by a program. 2) The existing documentation itself, while extensive and obviously the result of a huge effort, is still not good enough. For one thing it assumes knowledge of C++. That is lame because a key advantage of PyQt is that you can be productive without knowing C++. Also, many of the pages have missing information, such as the list of arguments for a class, and/or have missing or broken links, or the explanations refer to arguments by name and the names don't match the names in the class heading. All of these taken together, along with other shortcomings I'm not mentioning, add up to a major barrier to learning. I guess if you already know a lot of PyQt the documentation seems good because it lets you look up some detail you didn't memorize. But it isn't very helpful to potential users who don't know a lot yet. I hope nobody takes these comments as personal criticisms because they aren't meant as such. I am in awe at the talents, dedication, and hard work by the Qt and PyQt developers and the gurus on this list who are putting so much time into supporting PyQt users and learners. I'm trying to be constructive by giving feedback from a typical learner, and possibly spark a new effort to improve the documentation. I want to learn to use PyQt and I'm willing to put a lot of time into it, but the state of the documentation makes it unnecessarily hard. I haven't given up yet but I'm pretty discouraged. If I'm wrong about what is lacking, which I may be, I hope someone will (tactfully) enlighten me. However, even if I'm wrong my frustration is an indication that everything isn't what it should be. -- Robert Lummis ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Weird problem with QSystemTrayIcon
I looked at the example with PyQt for system tray icons and tried to use it in my application. I couldn't get it to work. I couldn't find what the example was doing that I wasn't doing. I even did the stuff in the same order. I wound up taking the example and in-lining a bunch of functions then bit by bit removing things until I got a minimalistic system tray icon program. In the end, I wound up with a small sample application where for some reason I need to call QtGui.QGroupBox() with some string or I'll never see the system tray icon. Below is example code. If you remove the line ... self.WHY_DO_I_NEED_TO_DO_THIS = QtGui.QGroupBox(A) ... then I don't see any system tray icon. Can anyone else verify this? I'm on Linux 64 bit with Python 2.6.5 and PyQt 4.7.2. Thanks, ~Eric #!/usr/bin/env python from PyQt4 import QtCore, QtGui class Window(QtGui.QDialog): def __init__(self): super(Window, self).__init__() self.WHY_DO_I_NEED_TO_DO_THIS = QtGui.QGroupBox(A) self.restoreAction = QtGui.QAction(Restore, self, triggered=self.showNormal) self.quitAction = QtGui.QAction(Quit, self, triggered=QtGui.qApp.quit) self.trayIconMenu = QtGui.QMenu(self) self.trayIconMenu.addAction(self.restoreAction) self.trayIconMenu.addSeparator() self.trayIconMenu.addAction(self.quitAction) self.trayIcon = QtGui.QSystemTrayIcon(self) self.trayIcon.setContextMenu(self.trayIconMenu) self.trayIcon.setIcon(QtGui.QIcon(./logo.png)) mainLayout = QtGui.QVBoxLayout() mainLayout.addWidget(QtGui.QPushButton(Help Please)) self.setLayout(mainLayout) self.trayIcon.show() self.setWindowTitle(Systray) self.resize(400, 300) if __name__ == '__main__': import sys app = QtGui.QApplication(sys.argv) if not QtGui.QSystemTrayIcon.isSystemTrayAvailable(): QtGui.QMessageBox.critical(None, Systray, I couldn't detect any system tray on this system.) sys.exit(1) #QtGui.QApplication.setQuitOnLastWindowClosed(False) window = Window() window.show() sys.exit(app.exec_()) ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Weird problem with QSystemTrayIcon
On Wednesday 15 September 2010, 20:34:12 Eric Frederich wrote: In the end, I wound up with a small sample application where for some reason I need to call QtGui.QGroupBox() with some string or I'll never see the system tray icon. Below is example code. If you remove the line ... self.WHY_DO_I_NEED_TO_DO_THIS = QtGui.QGroupBox(A) ... then I don't see any system tray icon. Can anyone else verify this? I'm on Linux 64 bit with Python 2.6.5 and PyQt 4.7.2. I cannot confirm this with Python version: 2.6 sip version: 4.10.5 Qt4 version: 4.6.3 PyQt4 version: 4.7.4 on openSUSE 11.1/i586 with KDE3 window manager. and the code looks fine without your voodoo speel. I cannot imagine, why this should make any difference. Mind you checking the Qt4 example? (If it's not compiled already, a qmake make should do) Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Howto use the Qt documentation successfully
On Wednesday 15 September 2010, 19:50:11 Robert Lummis wrote: I'd like to second Peter Milliken's sentiments. The PyQt documentation that's available is (in my opinion) pretty poor. Finding a way to do something that you haven't done before by browsing the documentation is nearly impossible. Or at least it's so frustrating and time-consuming that I often give up before finding what I need. The only way I've successfully implemented something is by starting with a working example I find by googling or in Mark Summerfield's book and vary it to suit my needs. That's not an ok method for serious programming. To be more concrete, I think there are at least two main shortcomings. 1) good meta-documentation isn't available. (Or, if it is available, I haven't found it.) One part of the meta-documentation would guide you to the classes, procedures, etc. you should read based on the tasks you want to accomplish, and say which classes go together. It would contain indexed annotations on the existing pages so, for example, if I want to program a way to edit fields in a database I could look in its index under fields or database or edit and I would be taken to a listing of all the relevant classes (not just the ones with those words on their pages) with annotations about what each does. Or if I want to control an external device I would find an annotated listing of the classes that might be applicable. This would have to be written by hand, not generated by a program. While I understand your needs, I never came across a project, that provided a considerable amount of such meta documentation. All GUI programming books/manuals do this by example. Assistant comes close, since it has groupings of classes (e.g. Database classes), and topic overviews (e.g. The Qt 4 Database GUI Layer). 2) The existing documentation itself, while extensive and obviously the result of a huge effort, is still not good enough. For one thing it assumes knowledge of C++. That is lame because a key advantage of PyQt is that you can be productive without knowing C++. I beg to disagree: what you need to learn is what parts of C++ism's you can ignore completely, and what parts need be be transformed. Maybe, we should put a mini C++ survival guide into the PyQt wiki, that explains the basics.. Also, many of the pages have missing information, such as the list of arguments for a class, and/or have missing or broken links, or the explanations refer to arguments by name and the names don't match the names in the class heading. All of these taken together, along with other shortcomings I'm not mentioning, add up to a major barrier to learning. I guess if you already know a lot of PyQt the documentation seems good because it lets you look up some detail you didn't memorize. But it isn't very helpful to potential users who don't know a lot yet. I'm so used to assistant, that I only occasionly lookup things in the PyQt documentation (apart from pyqt4ref.html of course). If I find a deviation from Qt in PyQt, I go straight into the sip files, since they contain both: a description of that, and the method signatures, I'm usually after. I hope nobody takes these comments as personal criticisms because they aren't meant as such. I am in awe at the talents, dedication, and hard work by the Qt and PyQt developers and the gurus on this list who are putting so much time into supporting PyQt users and learners. I'm trying to be constructive by giving feedback from a typical learner, and possibly spark a new effort to improve the documentation. I want to learn to use PyQt and I'm willing to put a lot of time into it, but the state of the documentation makes it unnecessarily hard. I haven't given up yet but I'm pretty discouraged. If I'm wrong about what is lacking, which I may be, I hope someone will (tactfully) enlighten me. However, even if I'm wrong my frustration is an indication that everything isn't what it should be. Please try to find your way through assistant, and call back with the issues you have. I'm sure, that you won't miss much after a while. C++ is bitchy, if you need to program with it, but happily, we can ignore all those ugly and black voodoo parts completely. With the raise of Python 3 and the declination of QString and QVariant, programming with PyQt has a even brighter future to offer. Pete ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
