There were two flags for read-only with different capitalization:
readonly and readOnly. This was probably a mistake.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit 9c5ea5617a)
mightStartDrag might have been used uninitialized when moving mouse with
pressed mouse button into window.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit 2b1c78cb53)
Improve TQFont cleanup making sure that all instances of TQFont are
destroyed before TQApplication (or specifically before disconnect from
X11). This gets reed of several valgrind complains about leaks deep
inside fontconfig.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit 1b951e5229)
Improve TQFont cleanup making sure that all instances of TQFont are
destroyed before TQApplication (or specifically before disconnect from
X11). This gets reed of several valgrind complains about leaks deep
inside fontconfig.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit ffbaaf0e1c)
Otherwise it results in small memmory leakage on exit of Xlib data.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit fb0d62eec8)
- rename fontsetRefCount -> fontsetCacheRefCount
- move fontsetCacheRefCount to constructor as setHolderWidget() could be
called more than once
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit e1bb179fde)
As derivative from it e.g. TQPrinterUnixPrivate are getting deleted (e.g
in unix TQPrinter implementation) by a reference to base class.
Also added missing include to the header.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit 5920542e9e)
valgrind was complaining about access to uninitialized data because
unused elements in client_message.data.l array weren't set o any value.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit 8a13d9aef4)
Before that the allocations of TQThreadStorage objects from the main
thread were never destroyed and memory associated with them were never
freed. The second one isn't a huge problem as at that point program is
terminating anyway (but it still makes valgrind complain). The first one
is the bigger issue as destructors might contain some essential external
cleanups like removing temporary files.
Also make `TQApplication::guiThread()` return `0` when the thread is
destroyed (may happen on the program exiting during destruction of
statics).
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit b1e6f38464)
Also rearrange code a bit so it would be obvious that the function
doesn't return a dangling reference.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit bcda401191)
TQXIMInputContext::setHolderWidget() function may be (and actually is)
called more than once. This results in multiple instances of the same
object being added to ximContextList. But the destructor removes only
one instance, which effectively results in leak of several bytes
whenever a window is opened.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit 1278ed0dad)
As for now here are two sets of inputmethod options:
- -enable-inputmethod/disable-inputmethod - which seems to supposed to
control whether build the 'inputmethod' module or not
- -inputmethod/-no-inputmethod - which seems to supposed to
enable/disable inputmethod support without changing the ABI.
Before the patch both -disable-inputmethod and -no-inputmethod were just
breaking the build: -no-inputmethod were disabling some code with
support for the module, but didn't disabled the module build itself nor
build of plugins. -disable-inputmethod were disabling build of plugins
and module, but didn't disabled code depending upon it.
It seems the inputmethod support were still WIP when the last release of
Qt3 came to be, hence the mess.
This patch fixes the build if both -disable-inputmethod AND
-no-inputmethod are supplied. Disabling only one is not enough due to
tqmake/configure have problems handling two different options of the
same name. Later the -inputmethod/-no-inputmethod should be probably
removed entirely.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit fad4acbe08)
The analogue of XkbKeycodeToKeysym() used to be XKeycodeToKeysym(), but
it was deprecated in favour of XGetKeyboardMapping() method.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit beb37238fa)
On modern compilers placement new requires inclusion of <new>
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit 2f15a471f9)
Also use "On The Spot" as the default when the setting in the config is
incorrect.
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit 34587584ab)
Fix FTBFS when sqlite3 sql driver is being built into the library
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
(cherry picked from commit 3cba79c7f5)
This is the first part of the replacement process.
Usage of Q_WS_* has been replaced with the equivalent TQ_WS_*.
Definition of Q_WS_* has been mirrored into TQ_WS_* defines, to allow
TDE code to continue building till replacement is carried over to all
other modules.
Once that is completed, the original Q_WS_* defines will
be removed.
Signed-off-by: Michele Calgaro <michele.calgaro@yahoo.it>
(cherry picked from commit 67bff2edca)
A new README with markdown format, updated information on TQt, contributor section and translations status.
The old README has been preserved as README.Qt3 for historical reasons.
Signed-off-by: Mavridis Philippe <mavridisf@gmail.com>
(cherry picked from commit fd6c582f15)
Commit b167d09c was functionally incorrect and is causing issues on
selected distributions.
This reverts commit b167d09c43.
This resolves issue TDE/tde#128.
(cherry picked from commit fb1f3d6445)
When using the pthreads recursive mutex, the level method was only able
to return either zero or one, but a recursive mutex can be locked more
than once.
Additionally, the way this detected if the mutex was already locked was
to test whether it can be locked again. If testing from the thread that
is currently holding the lock, this locking attempt always succeeds, and
therefore determines that the lock is _not_ held at all. This is
especially bad, as this operation only makes sense to perform from the
thread that holds the lock -- if any thread not holding the lock queries
the number of times the lock is held, that answer can change before the
thread can used it.
Signed-off-by: Bobby Bingham <koorogi@koorogi.info>
(cherry picked from commit 999cebcb5d)
Michele Calgaro
Slávek Banko
Alexander Golubev
Mavridis Philippe
Denis Kozadaev
Bobby Bingham