Phil Thompson schrieb:
Phil Thompson schrieb:
I plan to release new versions of SIP, PyQt and QScintilla some time next
week. The current snapshots can be treated as release candidates.
There have been a number of subtle changes under the covers - now would
be
a good time to test with your favorite apps.
QScintilla translations need updating again for the new batch file lexer
-
blame Detlev ;)
Phil
I have a minor wish for the final release (if it's not too late).
PyQt's configure.py script sets opt_qsciincdir to the default value
sipcfg.qt_inc_dir (this is normally $QTDIR/include). This is the
directory, where configure.py looks for the qscintilla header files. I
don't like to pollute Qt's include directory with a number of non-Qt
header files, so I always put them into a subdirectory named "Qext" in
$QTDIR/include and use the -n flag when running configure.py. I do the
same for the qwt header files ("Qwt") and for the header files of my own
widget library ("Qds").
Phil, what do you think about changing the default value of
opt_qsciincdir to os.path.join(sipcfg.qt_inc_dir, "Qext")?
What do other people think about it?
I don't like it - unless the default QScintilla installation directories
are changed as you suggest below.
Maybe I was a little bit imprecise. I meant to change the QScintilla
installation directories. Changing PyQt's configure script is only the
logical consequence. But changing the installation directory of the
QScintilla header files means at the moment just a change in the README
file, because the header files are not installed by the build process.
You have to copy them manually. This is the same for the translation
files and the documentation files.
If you append the following lines to qscintilla.pro, you can just say
"(n)make install" and everything gets installed in the appropriate places:
-----
header.path = $(QTDIR)/include/Qext
header.files = qextscintilla*.h
doc1.path = $(QTDIR)/doc/Qext/QScintilla
doc1.files = ../doc/html/*
doc2.path = $(QTDIR)/doc/Qext/Scintilla
doc2.files = ../doc/Scintilla/*
trans.path = $(QTDIR)/translations
trans.files = qscintilla_*.qm
INSTALLS += header doc1 doc2 trans
-----
The only problem is, that the files in doc/Scintilla have the executable
bit set, and qmake tries to strip every file that is executable, but it
shouldn't be a problem to remove the executable flag from the Scintilla
doc files.
This approach follows Trolltech's naming guidelines
(http://www.trolltech.com/documentation/naming.html). The guidelines
recommend to put the header files into a subdirectory named qxxx where
xxx is the prefix of the extension (the guidelines recommend lowercase
filenames).
Another pure cosmetic point (and not for the next release) is the name
"qext" for the module containing the bindings for qscintilla. I think
this name is inappropriate. At least for me, this name implies "a
collection of (Py)Qt related extensions", but in fact it contains only
the qscintilla classes. Wouldn't it be better to rename this to "qsci"
(and "Qsci" for the include directory) in a future release? What are
your opinions?
The use of qext in PyQt can easily be changed - for PyQt4 anyway.
It reflects the use of Qext as a prefix for the C++ classes. This follows
Trolltech's guidelines and I adopted it to be a good citizen. I soon
realised that nobody else was following it. I also realised that the
reason nobody else was following it was that it was a dumb idea.
I wish I'd used Qsci instead of QextScintilla, but it's more difficult to
change - particularly as I expect the same QScintilla source to support
both Qt3 and Qt4. I suppose I could provide old-prefix and new-prefix
versions of the source - given my internal build systems this wouldn't be
a maintenance overhead.
Again, I meant changing the prefix of the QScintilla extension from
[Qq]ext to [Qq]sci. Changing the name of the PyQt extension module
would be the logical consequence. The resulting library (libqscintilla)
contains only the QScintilla classes and my opinion is that a prefix
'sci' would match better.
As I said before, all this is pure cosmetic and has nothing to do with
the functionality, I have no problems if you decide not to change anything.
Sorry for being a little bit imprecise.
Ulli
_______________________________________________
PyKDE mailing list [email protected]
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
