Re: [PyKDE] OT QT4 GPL query.
Have your company buy a commercial license for Qt (and PyQT). Then there's no worry. --gilbert On 8/7/06, dave s <[EMAIL PROTECTED]> wrote: At work we use Widows software to download data from remote controllers & hold it in a database. I have been asked to write an app to analyze this data and flag inconsistencies in a GUI. I feel confident to write the code but am concerned about licenses. QT4 is GPL. Am I right in thinking that if my code is python GPL my company can use it legally without having to pay any license fees ? - or should I look at wxPython ? Any advice greatfully received Dave ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] QString in PyQt4 - Request for Comments
On 10/21/05, Phil Thompson <[EMAIL PROTECTED]> wrote: > I'm totally unsympathetic to the idea of a *separate* Pythonic API to Qt. > The Python GUI toolkit "market" is fragmented enough as it is - this would > only add more confusion for (relatively) little benefit. > > People come to PyQt either as existing Python programmers looking for a > decent toolkit, or Qt/KDE programmers looking for a decent programming > language. I think the former is a larger group than the latter and this > difference will only become more pronounced with the Windows GPL version. > > I'm completely open to making the existing API more Pythonic - this is the > time to do it. For example, I did casually float the idea of not using C++ > types in signal signatures in a previous post - but nobody bit. > > Phil > For me, one of the strong points of Qt is that the documentation for it is great. Although the documention is for C++, it's still a handy reference for PyQT programmers because the mapping from Qt/C++ to PyQt is almost always straightforward. I'd like to keep the non-straight-forward mappings in the documentation to a minimum, because no one is going to do as good of a job as writing documentation for an API that is very different from Qt's. --gilbert ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] Creating constructor code for python+designer3 project
I leave the pyuic-generated code alone, and write my own main form class which inherits from *that*. For example, my MainWindow.py file, which has *my* code, starts like this: from main_window import main_window_form class MainWindow(main_window_form): def __init__(self): main_window_form.__init__(self,None,None,0) # my own code here. --gilbert On 10/3/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello everyone, > I am fairly new to writing software for the python interpreter and > hence I have run into some issues. Maybe someone can give me some > good advice. > > What I wish to do is to keep all of the code relating to the main > application form, in the same project as the actual UI, meaning; > inside QT-designer. Designer tells me to create functions called > init() and destroy(), and within those functions write the code i > wish to execute at creation and deletion of the main form object. > > I have done this but to no avail. A quick guesse is that pyuic dont > know what to do with my additional functions and because of this, > just leaves them be. I have also tried to implement my own > constructor for the main form class. I may have done it wrong, I am > not sure. All I know is it did not work as I expected it to. When I > run the code I still can not get my init code to execute. In fact > there is no trace of the code in the generated code that comes out > of pyuic. > > If anyone knows how to solve this (seemingly simple problem) please > do let me know on gash (at) hush.ai > > Thank you and best regards, > Peter > -BEGIN PGP SIGNATURE- > Note: This signature can be verified at https://www.hushtools.com/verify > Version: Hush 2.4 > > wkYEARECAAYFAkNA5qsACgkQN7khALeDuw1vdACghicZrhkiGmwoXit8fP1pUeTDMC0A > nj1Yp2L2YMbFCYUms2zJTd1o6sXj > =8lO5 > -END PGP SIGNATURE- > > > > > Concerned about your privacy? Follow this link to get > secure FREE email: http://www.hushmail.com/?l=2 > > Free, ultra-private instant messaging with Hush Messenger > http://www.hushmail.com/services-messenger?l=434 > > Promote security and make money with the Hushmail Affiliate Program: > http://www.hushmail.com/about-affiliate?l=427 > > ___ > PyKDE mailing listPyKDE@mats.imk.fraunhofer.de > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde > > ___ PyKDE mailing listPyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] The tablet event, it works not!
On Thursday 14 October 2004 07:51, Sundance wrote: > Thanks. > I'm beginning to suspect a Qt bug. I ported my example to C++, and it > doesn't work either. I re-re-rechecked my Qt compilation log and tablet > support is definitely turned on. > > Could it be that Qt didn't compile tablet support even though the > configure script claims it did? If so, how can I check? I once tried to get PyQT and a Wacom tablet working together, and failed, I didn't work on it much, but I did find this code in src/kernel/qapplication_x11.cpp of the qt-x11 source code: #if defined (QT_TABLET_SUPPORT) .. #if !defined(Q_OS_IRIX) // XFree86 divides a stylus and eraser into 2 devices, so we must do for both... const QString XFREENAMESTYLUS = "stylus"; const QString XFREENAMEPEN = "pen"; const QString XFREENAMEERASER = "eraser"; #endif It's as if your xinput devices must be named "stylus", "pen", and "eraser". However, when I changed the name of my xinput devices in my XF86Config-4 file, it still didn't help. --gilbert ___ PyKDE mailing list[EMAIL PROTECTED] http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
Re: [PyKDE] PyQt-x11-gpl-snapshot-20040719 for qte-embedded-multithreaded
On Monday 02 August 2004 10:23, Phil Thompson wrote:
> On Monday 02 August 2004 3:56 pm, Gilbert Ramirez wrote:
> > A few days ago I posted a patch to build sip-4.0.1 with support for
> > qte-mt. Now I have an update for the PyQT snapshot (20040719) that I
> > pulled down.
> >
> > I have included it here inline because I want to explain the problems I
> > had; the patch is not intended to be applied directly to the source
> > because I'm not sure what the proper changes should be. I just hacked it
> > up to work on my system.
>
> [snip]
>
> The short answer is that PyQt does not support Qt/E v3 - never has done.
> The existing Qt/E support was for the Zaurus - based on Qt/E v2 - because
> Sharp were kind enough to give me one. The main reason I no longer support
> PyQt on the Zaurus myself is that I don't use it.
>
> I'm happy to accept patches, or I'm happy to accept payment to add the
> support.
Fair enough. I've been using PyQT with Qt/E v3 for over a year now on a home
project --- a little Linux jukebox, video player, and karaoke machine that I
put together. The only reason I'm using Qt-Embedded is because I wanted to
use the framebuffer device instead of X11; the issue of resource usage hasn't
come up because the box has plenty of resources.
Attached is a better patch for PyQt-x11-gpl-snapshot-20040719 to build with
libqte-mt. The changes to configure.py and build.py were straightforward. I
made changes to 2 sip files, trying to do it cleanly to support QWS and
non-QWS platforms. Please let me know if the style of those changes in
unacceptable.
I have similar patches to enable support for qte-mt for PyQt-x11-gpl-3.5 and
sip-x11-gpl-3.5, which I had been using until recently. Are you interested
in patches for those versions of PyQT and sip?
--gilbert
diff -ur orig/PyQt-x11-gpl-snapshot-20040719/build.py PyQt-x11-gpl-snapshot-20040719/build.py
--- orig/PyQt-x11-gpl-snapshot-20040719/build.py 2004-07-19 21:30:22.0 -0500
+++ PyQt-x11-gpl-snapshot-20040719/build.py 2004-08-04 13:26:22.0 -0500
@@ -597,7 +597,7 @@
# Work out the platform and Qt version tags to pass to SIP to generate the
# code we need.
-if config.qt_lib == "qte":
+if config.qt_lib == "qte" or config.qt_lib == "qte-mt":
plattag = "WS_QWS"
elif sys.platform == "win32":
plattag = "WS_WIN"
diff -ur orig/PyQt-x11-gpl-snapshot-20040719/configure.py PyQt-x11-gpl-snapshot-20040719/configure.py
--- orig/PyQt-x11-gpl-snapshot-20040719/configure.py 2004-07-19 21:30:22.0 -0500
+++ PyQt-x11-gpl-snapshot-20040719/configure.py 2004-08-04 09:27:43.0 -0500
@@ -462,7 +462,7 @@
qt_sip_flags.extend(get_feature_flags())
# Handle the platform tag.
-if opt_qtpetag:
+if opt_qtpetag or sipcfg.qt_lib == "qte" or sipcfg.qt_lib == "qte-mt":
plattag = "WS_QWS"
elif sys.platform == "win32":
plattag = "WS_WIN"
diff -ur orig/PyQt-x11-gpl-snapshot-20040719/sip/qt/qfont.sip PyQt-x11-gpl-snapshot-20040719/sip/qt/qfont.sip
--- orig/PyQt-x11-gpl-snapshot-20040719/sip/qt/qfont.sip 2004-07-19 21:30:28.0 -0500
+++ PyQt-x11-gpl-snapshot-20040719/sip/qt/qfont.sip 2004-08-04 10:06:41.0 -0500
@@ -340,7 +340,9 @@
static void initialize();
static void cleanup();
+%If (!WS_QWS)
static void cacheStatistics();
+%End
%If (Qt_3_0_0 -)
enum Script {
diff -ur orig/PyQt-x11-gpl-snapshot-20040719/sip/qt/qthread.sip PyQt-x11-gpl-snapshot-20040719/sip/qt/qthread.sip
--- orig/PyQt-x11-gpl-snapshot-20040719/sip/qt/qthread.sip 2004-07-19 21:30:28.0 -0500
+++ PyQt-x11-gpl-snapshot-20040719/sip/qt/qthread.sip 2004-08-04 10:07:15.0 -0500
@@ -43,8 +43,13 @@
static HANDLE currentThread();
%End
%If (Qt_3_0_0 -)
+%If (WS_QWS)
+ static HANDLE currentThread();
+%End
+%If (!WS_QWS)
static Qt::HANDLE currentThread();
%End
+%End
static void postEvent(QObject *,QEvent * /Transfer/);
%If (Qt_3_0_0 -)
static void initialize();
[PyKDE] PyQt-x11-gpl-snapshot-20040719 for qte-embedded-multithreaded
A few days ago I posted a patch to build sip-4.0.1 with support for qte-mt.
Now I have an update for the PyQT snapshot (20040719) that I pulled down.
I have included it here inline because I want to explain the problems I had;
the patch is not intended to be applied directly to the source because I'm
not sure what the proper changes should be. I just hacked it up to work on my
system.
I had to make 3 changes.
1) The plattag for qte (or in my case, qte-mt) should be WS_QWS, not WS_X11
diff -ur
PyQt-x11-gpl-snapshot-20040719/configure.py
../PyQt-x11-gpl-snapshot-20040719/configure.py
--- PyQt-x11-gpl-snapshot-20040719/configure.py 2004-07-19 21:30:22.0
-0500
+++ ../PyQt-x11-gpl-snapshot-20040719/configure.py 2004-07-28
23:12:45.0 -0500
@@ -469,7 +469,8 @@
elif sys.platform == "darwin":
plattag = "WS_MACX"
else:
-plattag = "WS_X11"
+#plattag = "WS_X11"
+plattag = "WS_QWS"
qt_sip_flags.append("-t")
qt_sip_flags.append(plattag)
2) qt-embedded-free-3.3.2 did not have 'cacheStatistics'. I don't know if
that's the general case, or just in my build.
diff -ur
PyQt-x11-gpl-snapshot-20040719/sip/qt/qfont.sip
../PyQt-x11-gpl-snapshot-20040719/sip/qt/qfont.sip
--- PyQt-x11-gpl-snapshot-20040719/sip/qt/qfont.sip 2004-07-19
21:30:28.0 -0500
+++ ../PyQt-x11-gpl-snapshot-20040719/sip/qt/qfont.sip 2004-07-28
23:36:45.0 -0500
@@ -340,7 +340,7 @@
static void initialize();
static void cleanup();
- static void cacheStatistics();
+// static void cacheStatistics();
%If (Qt_3_0_0 -)
enum Script {
3) qt-embedded-free-3.3.2 did not have Qt::HANDLE, but did have HANDLE
diff -ur
PyQt-x11-gpl-snapshot-20040719/sip/qt/qthread.sip
../PyQt-x11-gpl-snapshot-20040719/sip/qt/qthread.sip
--- PyQt-x11-gpl-snapshot-20040719/sip/qt/qthread.sip 2004-07-19
21:30:28.0 -0500
+++ ../PyQt-x11-gpl-snapshot-20040719/sip/qt/qthread.sip2004-07-28
23:14:13.0 -0500
@@ -43,7 +43,8 @@
static HANDLE currentThread();
%End
%If (Qt_3_0_0 -)
- static Qt::HANDLE currentThread();
+ //static Qt::HANDLE currentThread();
+ static HANDLE currentThread();
%End
static void postEvent(QObject *,QEvent * /Transfer/);
%If (Qt_3_0_0 -)
--gilbert
___
PyKDE mailing list[EMAIL PROTECTED]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[PyKDE] sip-4.0.1 support for qt-embedded-multithreaded
On Linux I've built my qt-embedded-free-3.3.2 library with the -threaded
option. My qt library gets installed as libqte-mt:
$ ls libqt*
libqte-mt.la libqte-mt.solibqte-mt.so.3.3
libqte-mt.prl libqte-mt.so.3 libqte-mt.so.3.3.2
sip-4.0.1 doesn't recognize this configuration. Attached is a diff to teach it
about "qte-mt".
--gilbert
--- configure.py.orig 2004-07-28 22:14:31.0 -0500
+++ configure.py 2004-07-28 22:16:15.0 -0500
@@ -103,7 +103,7 @@
print "-d dir where the SIP module will be installed [default %s]" % opt_sipmoddir
print "-e dir where the SIP header file will be installed [default %s]" % opt_sipincdir
print "-k build the SIP module as a static library"
-print "-l Qt-library explicitly specify the type of Qt library, either qt, qt-mt, qte or qtmt"
+print "-l Qt-library explicitly specify the type of Qt library, either qt, qt-mt, qte-mt, qte or qtmt"
print "-p platformthe platform/compiler configuration [default the Qt configuration if enabled or %s]" % default_platform
print "-u build with debugging symbols"
print "-v dir where .sip files are normally installed [default %s]" % opt_sipsipdir
@@ -395,6 +395,7 @@
edlib = is_qt_library(generator, "qt-mtedu")
evlib = is_qt_library(generator, "qt-mteval")
emlib = is_qt_library(generator, "qte")
+etlib = is_qt_library(generator, "qte-mt")
# Borland likes to be a little different.
bmtlib = is_qt_library(generator, "qtmt")
@@ -423,6 +424,10 @@
opt_qtlib = "qte"
names.append(opt_qtlib)
+if etlib:
+opt_qtlib = "qte-mt"
+names.append(opt_qtlib)
+
if bmtlib:
opt_qtlib = "qtmt"
names.append(opt_qtlib)
@@ -442,7 +447,7 @@
siputils.error("These Qt libraries were found: %s. Use the -l argument to explicitly specify which you want to use." % string.join(names))
# See if Qt has thread support.
-if opt_qtlib in ("qt-mt", "qt-mtedu", "qt-mteval", "qtmt", "qtmtedu", "qtmteval"):
+if opt_qtlib in ("qt-mt", "qte-mt", "qt-mtedu", "qt-mteval", "qtmt", "qtmtedu", "qtmteval"):
global qt_threaded
qt_threaded = 1
@@ -775,7 +780,7 @@
elif opt == "-k":
opt_static = 1
elif opt == "-l":
-if arg in ("qt", "qt-mt", "qt-mtedu", "qt-mteval", "qte", "qtmt", "qtmtedu"):
+if arg in ("qt", "qt-mt", "qte-mt", "qt-mtedu", "qt-mteval", "qte", "qtmt", "qtmtedu"):
opt_qtlib = arg
else:
usage()
