| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
| |
When configuring Qt to be in a namespace then the Mac specific Qt
classes should be namespaced as well to prevent any duplicated class
names when a non namespaced version of Qt is used in conjunction.
Reviewed-by: Richard
|
|
|
|
|
|
|
|
|
|
| |
The reason is the way we leave modality in the font dialog. When we
do, we need to close the non-native qfontdialog as well, but doing
so will issue callbacks (like set_visible_sys(false)), that will
cause problems. This patch makes sure we wait with such callbacks
until the native modal event loop has finished executing
Reviewed-by: cduclos
|
|
|
|
|
|
|
|
|
|
| |
This was never implemented, and as it stands, just creating a
QFontDialog and calling show on it will not show anything. This
patch makes sure that show works, and that one can have more than
one font dialog showing at the same time (but only the first one will
be native)
Reviewed-by: cduclos
|
|
|
|
|
|
|
|
| |
The native font dialog on mac did not set the font specified in the
non-native font dialog upon exec, but rather qApp->font(). This oneliner
sets the correct font, and makes the autotest pass.
Reviewed-by: cduclos
|
|
|
|
|
|
|
|
| |
It turns out the the code implemented two different ways of entering
modality, and mixed the two when it came to exit modality. This patch
just uses the nsapp runmodalforwindow approach.
Reviewed-by: cduclos
|
|
|
|
|
|
|
|
|
|
|
|
| |
This bug is visible if the static funtions are used before
calling qApp->exec().
The reason is that the static functions still use the old
code path, rather than the new one (that will end up creating
a QFontDialog and call exec on it). Just using the new style
will fix the problem.
Task-number: QTBUG-7371
Reviewed-by: cduclos
|
|
|
|
|
|
|
|
|
| |
The problem is the fact that this dialog is never meant to be used this
way. Instead it should be called through the static function ::getFont(...).
I reimplemented this code path and made sure that this works.
Task-number: QTBUG-7769
Reviewed-by: Richard Moe Gustavsen
|
|
|
|
| |
Reviewed-by: Trust Me
|
|\
| |
| |
| |
| | |
Conflicts:
mkspecs/macx-g++40/qplatformdefs.h
|
| |
| |
| |
| |
| |
| | |
[NSFontManager setTarget] is not available on 10.4.
Rev-by: Richard Moe Gustavsen
|
| |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If you passed in a QFont with a family name that did not resolve to
QFontDialog::getFont(), it would not select any font in the panel,
and it would always return the default font, regardless of what you
actually selected in the dialog. This was because it would try to
resolve the requested family name, rather than the actual family name
of the initial font. That in turn caused the NSFont* returned by the
system to be null, which, when set on the font manager, caused the
manager to always return 0 for selectedFont.
Task-number: QTBUG-6071
Reviewed-by: Trond
|
| |
| |
| |
| |
| |
| |
| | |
The font size was not respected because it is taken from the
request which could only contains the pixel size.
Reviewed-by: Richard
|
|/
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
| |
After discussing with some of the Objective-C
people I have finally got a fair number of the
warnings to disappear in both 10.5 and 10.6. I
also took the opportunity to remove a bunch of
other warnings.
Reviewed by: Morten Sørvig
|
|
|
|
| |
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
| |
Seems like no code was written to handle other font engines than
CoreText. Unfortunatly the engine on Carbon is ATSUI. This patch
adds general code for converting a QFont to an NSFont so the dialog
can support other engines than CoreText
Task-number: 251957
Reviewed-by: Trenton Schulz
|
|
|
|
|
|
|
|
|
|
| |
If creating a native QFontDialog and delete it, the native dialog
will still show. And worse, it will call the deleted QDialog
counterpart. This fix will clean up (and close the native dialog)
when the QDialog is deleted.
Task-number: 254397
Reviewed-by: Trenton Schulz
|
|
|
|
|
|
|
|
|
|
| |
It seems that running the font dialog modal means that the "fontChanged"
action is not fired. Which means our font is never changed. Thankfully,
since it's an app modal case, we can re-sync when the OK button is
clicked.
Task-number: 252000
Reviewed-by: Morten Sørvig
|
|
|
|
|
|
|
|
|
| |
Cocoa's font manager uses "first responder" which is a great idea, but
breaks as soon as we change windows. Thankfully we can just set the
target and we are OK. An upshot is that we don't need the delegate, but
I'm not going to push my luck on that.
Reviewed-by: Richard Moe Gustavsen
|
|
|