Custom Query (301 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (91 - 93 of 301)

Ticket Resolution Summary Owner Reporter
#78 fixed Make binary builds portable Dmitry A. Kuminov
Description

Currently, Qt binaries (in particular, qmake.exe and QtCore4*.dll) have hard-coded paths in them that refer to various locations (e.g. include directory or plugin directory). This makes it impossible to distribute the Qt library in the binary form (for example, in order to provide a fast-to-deploy development environment that uses the officially distributed Qt libraries, tools and DLLs which makes it possible to distribute Qt DLLs separately from each Qt application and at the same time avoid DLL hell).

In particular, qmake uses these hard-coded paths when generating the Makefiles so if the Qt library root is changed (moved, renamed) an attempt to build an application will fail because include and library files will still be searched at the old location (whose path is built into qmake.exe).

In case of QtCore4.dll and its hard-coded paths, the potential problem is locating the Qt plugins that are by default searched at the hard-coded location that points inside the 'plugins' subdirectory of the Qt library root.

#79 fixed Make sure single Alt key press is first handled by Qt Dmitry A. Kuminov
Description

The Alt key is intercepted by PM and used to activate the native PM window menu bar or the system menu if there is no native menu bar.

This steals the Alt key press from Qt and therefore prevents it from activating the Qt menu bar in Qt applications; the system menu is always activated instead. This doesn't make sense and needs to be fixed. For the system menu, there is a de-facto standard Alt+Space key combination which should also do the same in Qt applications but single Alt press should be normally passed to Qt which will cause the Qt menu bar activation if there is one.

#80 fixed Child widgets are sometimes not redrawn Dmitry A. Kuminov
Description

There is one more redraw problem I found. This problem may be seen if a top-level window that contains a combobox is dragged by holding the title bar with the left mouse button while the drop-down list of the combobox is open. The list will disappear after the mouse button press but the appearance of the combobox will remain as if the list is still open (in particular, the list button will remain sunken and the focus will not go back to the line editor).

If, while still holding the mouse button at the title one will move a part of the window containing the combobox partly offscreen and then move it back onscreen, he will see that the part of the combobox that was offscreen will be properly redrawn but not the rest.

Note: See TracQuery for help on using queries.