On 03/02/2013 21:27, Stephan Witt wrote:
Am 03.02.2013 um 20:40 schrieb Abdelrazak Younes <you...@lyx.org>:
On 02/02/2013 23:07, Stephan Witt wrote:
Am 02.02.2013 um 09:10 schrieb Abdelrazak Younes <you...@lyx.org>:
On 31/01/2013 21:44, Stephan Witt wrote:
Am 28.01.2013 um 10:02 schrieb LyX Ticket Tracker <t...@lyx.org>:
#8250: OS X with retina display
-------------------------+-------------------------
Changes (by spitz):
Does it make a difference if "Use pixmap cache" in Tools > Preferences >
Look & Feel > Screen Fonts is unchecked? (Note that this might decrease
performance). It would surprise me if Stephan wouldn't have tested this
already, but let's make sure.
Generally, this bug report is relevant:
https://bugreports.qt-project.org/browse/QTBUG-23870
Seems that some general support for HIGH_DPI is planned for Qt 5.0. In any
case, the report has some instructive background information.
Thank you, Jürgen, for the pointer to the Qt bug report.
I studied it and came to the conclusion to give LyX+Qt5 a try. The attached
patch is a result of this effort.
Instead of push it to git I want to present it here to get some feedback. If
the changes are ok I want to commit the patch.
Looks good after a quick parsing of it. It would be better if we minimize the
number of #ifdef... maybe via some small inline wrappers?
Thank you for having a look at it.
Most of the #ifdef's are needed for Qt's change of QAbstractItemView
setResizeMode to setSectionResizeMode.
I can place a wrapper in qt_helpers.h/qt_helpers.cpp like in the attached
patch. But I failed to make it inline.
Would you prefer this anyway?
Yes, looks better, thanks.
Another comment... I see this:
+++ b/src/support/FileName.cpp
@@ -746,7 +746,11 @@ docstring FileName::fileContents(string const & encoding)
const
if (encoding.empty() || encoding == "UTF-8")
s = QString::fromUtf8(contents.data());
else if (encoding == "ascii")
+#if (QT_VERSION < 0x050000)
s = QString::fromAscii(contents.data());
+#else
+ s = QString::fromLatin1(contents.data());
+#endif
This doesn't look correct. Latin1 is not ascii. I can see that the Qt5 doc says
that QString::fromAscii() and toAscii are deprecated because their give wrong
results, that is latin1, not ASCII. Still, this is not clean.
Yes, this is one thing I don't understand either.
1) The doc say it's deprecated but I got:
src/support/FileName.cpp: In member function ‘lyx::docstring
lyx::support::FileName::fileContents(const std::string&) const’:
src/support/FileName.cpp:750: error: ‘fromAscii’ is not a member of ‘QString’
Maybe your version of Qt was compiled without support for deprecated stuff.
2) Why isn't it possible to provide a correct fromAscii implementation then?
Maybe because it involves some content checking... Basically anything
greater than 7 bit ASCII must be discarded. But I am astonished that Qt
doesn't provide this kind of sanity check for ASCII. We could do it by
ourselves quite easily or maybe use some iconv function.
So, I had no good idea for Qt5 for a fromAscii() implementation. What do you
propose?
I read from Qt4 doc that fromAscii() is the same as as fromLatin1() if
no codec is installed. In Qt5 they just removed the ambiguity of 8 bits
ASCII by just choosing Latin1. So I would just remove the #ifdef and
just use fromLatin1() also fro Qt4. I would also add a FIXME explaining
the issue of course.
Sorry, I didn't want to commit the whole thing. It just happens while I tried
to build a master branch with non-controversial stuff and to commit that.
Igittigit…
No PB.
Cheers,
Abdel.
