[PATCH] LyX HiDPI support in OS X with Qt 5

[Marcelo Galvão Póvoa]

Hello,

LyX has been lacking HiDPI ("retina") support for a while now and I
decided to tackle this project. It has been listed as a GSoC 2013
potential project [1], so I assume there's enough interest in it.

I worked on a patch which adds basic 2x DPI drawing support for text
and graphics. Math formulas and inline images also work (except the
splash screen) but the UI icons would require creating higher res
versions.

Comparison (LyX 2.1.0 with Qt4 vs LyX git with Qt5):

https://dl.dropboxusercontent.com/u/20456192/standard.png
https://dl.dropboxusercontent.com/u/20456192/retina.png

Qt added HiDPI support in version 5 [2], but I think it's not yet
fully functional. I say this because I ran into a problem where
partial viewport updates (namely the cursor and preedit strings) are
rendered incorrectly. It seems that it wrongly uses non-scaled pixels
dimensions which displays viewport contents from half the requested
coordinates, but I'm not sure it is a Qt bug. To workaround this
(second patch) I used full viewport updates only, but this can
degrade performance. I would appreciate some help on this issue as I'm
not experienced with Qt.

I haven't tested this on Linux or Windows but to compile for Qt 5 on
OS X I used some additional steps from [3].

I am also new to LyX development and I am willing to improve this
patch, so any feedback will be welcome.

[1] http://wiki.lyx.org/Devel/SummerOfCode2013Ideas
[2] http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/
[3] http://permalink.gmane.org/gmane.editors.lyx.devel/148577

Thanks,
Marcelo

[Tommaso Cucinotta]

Hi Marcelo,

thanks a lot for your patch, I guess Mac users will love this!
Unfortunately, I'm a Linux user, so I cannot try it out, but
I'm quite sure some Mac devel from the list will reply you soon
(later, I can only double-check it doesn't break compilation on
Linux :-) if needed).

T.

On 14/07/14 21:44, Marcelo Galvão Póvoa wrote:
> Hello,
>
> LyX has been lacking HiDPI ("retina") support for a while now and I
> decided to tackle this project. It has been listed as a GSoC 2013
> potential project [1], so I assume there's enough interest in it.
>
> I worked on a patch which adds basic 2x DPI drawing support for text
> and graphics. Math formulas and inline images also work (except the
> splash screen) but the UI icons would require creating higher res
> versions.
>
> Comparison (LyX 2.1.0 with Qt4 vs LyX git with Qt5):
>
> https://dl.dropboxusercontent.com/u/20456192/standard.png
> https://dl.dropboxusercontent.com/u/20456192/retina.png
>
> Qt added HiDPI support in version 5 [2], but I think it's not yet
> fully functional. I say this because I ran into a problem where
> partial viewport updates (namely the cursor and preedit strings) are
> rendered incorrectly. It seems that it wrongly uses non-scaled pixels
> dimensions which displays viewport contents from half the requested
> coordinates, but I'm not sure it is a Qt bug. To workaround this
> (second patch) I used full viewport updates only, but this can
> degrade performance. I would appreciate some help on this issue as I'm
> not experienced with Qt.
>
> I haven't tested this on Linux or Windows but to compile for Qt 5 on
> OS X I used some additional steps from [3].
>
> I am also new to LyX development and I am willing to improve this
> patch, so any feedback will be welcome.
>
> [1] http://wiki.lyx.org/Devel/SummerOfCode2013Ideas
> [2] http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/
> [3] http://permalink.gmane.org/gmane.editors.lyx.devel/148577
>
> Thanks,
> Marcelo

[Marcelo Galvão Póvoa]

Hi Tommaso,

On Mon, Jul 14, 2014 at 7:44 PM, Tommaso Cucinotta <***@lyx.org> wrote:
> Hi Marcelo,
>
> thanks a lot for your patch, I guess Mac users will love this!
> Unfortunately, I'm a Linux user, so I cannot try it out, but
> I'm quite sure some Mac devel from the list will reply you soon
> (later, I can only double-check it doesn't break compilation on
> Linux :-) if needed).
>

According to that Qt blog post, HiDPI support is available for X11
too! I don't know the details of how to make it work because I haven't
tried myself.

> T.
>
> On 14/07/14 21:44, Marcelo Galvão Póvoa wrote:
>> Hello,
>>
>> LyX has been lacking HiDPI ("retina") support for a while now and I
>> decided to tackle this project. It has been listed as a GSoC 2013
>> potential project [1], so I assume there's enough interest in it.
>>
>> I worked on a patch which adds basic 2x DPI drawing support for text
>> and graphics. Math formulas and inline images also work (except the
>> splash screen) but the UI icons would require creating higher res
>> versions.
>>
>> Comparison (LyX 2.1.0 with Qt4 vs LyX git with Qt5):
>>
>> https://dl.dropboxusercontent.com/u/20456192/standard.png
>> https://dl.dropboxusercontent.com/u/20456192/retina.png
>>
>> Qt added HiDPI support in version 5 [2], but I think it's not yet
>> fully functional. I say this because I ran into a problem where
>> partial viewport updates (namely the cursor and preedit strings) are
>> rendered incorrectly. It seems that it wrongly uses non-scaled pixels
>> dimensions which displays viewport contents from half the requested
>> coordinates, but I'm not sure it is a Qt bug. To workaround this
>> (second patch) I used full viewport updates only, but this can
>> degrade performance. I would appreciate some help on this issue as I'm
>> not experienced with Qt.
>>
>> I haven't tested this on Linux or Windows but to compile for Qt 5 on
>> OS X I used some additional steps from [3].
>>
>> I am also new to LyX development and I am willing to improve this
>> patch, so any feedback will be welcome.
>>
>> [1] http://wiki.lyx.org/Devel/SummerOfCode2013Ideas
>> [2] http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/
>> [3] http://permalink.gmane.org/gmane.editors.lyx.devel/148577
>>
>> Thanks,
>> Marcelo
>

[Jean-Marc Lasgouttes]

Le 14/07/14 22:44, Marcelo Galvão Póvoa a écrit :
> Hello,
>
> LyX has been lacking HiDPI ("retina") support for a while now and I
> decided to tackle this project. It has been listed as a GSoC 2013
> potential project [1], so I assume there's enough interest in it.

Definitely! For reference, the corresponding bug report is:
http://www.lyx.org/trac/ticket/9130

> I worked on a patch which adds basic 2x DPI drawing support for text
> and graphics. Math formulas and inline images also work (except the
> splash screen) but the UI icons would require creating higher res
> versions.

This is excellent work. I am surprised that so many parts of the code
need to be changed, the way the blog entry is written made me think that
the changes could be smaller.

Do we really want to add a lyxrc variable for this, though? I would
think that Retina macs can automatically know that they need the x2
multiplier.

There seems to be some code related to that here:
http://stackoverflow.com/questions/16527971/detect-hidpi-mode

> Qt added HiDPI support in version 5 [2], but I think it's not yet
> fully functional.

I think that part of this is backported to recent 4.8 versions too. It
would be nice to see what 4.8 version can work correctly.

> I say this because I ran into a problem where
> partial viewport updates (namely the cursor and preedit strings) are
> rendered incorrectly. It seems that it wrongly uses non-scaled pixels
> dimensions which displays viewport contents from half the requested
> coordinates, but I'm not sure it is a Qt bug. To workaround this
> (second patch) I used full viewport updates only, but this can
> degrade performance. I would appreciate some help on this issue as I'm
> not experienced with Qt.

This part is also clearly beyond my knowledge [and moreover I do not own
a retina display].

Thanks for your work,
JMarc

[Marcelo Galvão Póvoa]

On Mon, Jul 14, 2014 at 8:01 PM, Jean-Marc Lasgouttes
<***@lyx.org> wrote:
> Le 14/07/14 22:44, Marcelo Galvão Póvoa a écrit :
>
>> I worked on a patch which adds basic 2x DPI drawing support for text
>> and graphics. Math formulas and inline images also work (except the
>> splash screen) but the UI icons would require creating higher res
>> versions.
>
>
> This is excellent work. I am surprised that so many parts of the code need
> to be changed, the way the blog entry is written made me think that the
> changes could be smaller.
>

Thanks. I tried to change the least amount of code but maybe someone
can suggest how to simplify my approach.

> Do we really want to add a lyxrc variable for this, though? I would think
> that Retina macs can automatically know that they need the x2 multiplier.
>
> There seems to be some code related to that here:
> http://stackoverflow.com/questions/16527971/detect-hidpi-mode
>

HiDPI detection is already automatic (that's why the variable is not
read from preferences file), but I need to have some global parameter
for easy access throughout the code.

>
>> Qt added HiDPI support in version 5 [2], but I think it's not yet
>> fully functional.
>
>
> I think that part of this is backported to recent 4.8 versions too. It would
> be nice to see what 4.8 version can work correctly.
>

Yes, I found a forked version of Qt 4 but I don't know if it's
reliable (they call it a hack):

https://github.com/msorvig/qt4-hidpi/

Marcelo

[Jean-Marc Lasgouttes]

Le 15/07/14 02:03, Marcelo Galvão Póvoa a écrit :
>> This is excellent work. I am surprised that so many parts of the code need
>> to be changed, the way the blog entry is written made me think that the
>> changes could be smaller.
>>
>
> Thanks. I tried to change the least amount of code but maybe someone
> can suggest how to simplify my approach.

OK, some remarks in no particuar order:

* adding a fake variable to lyxrc is bad :)

* is it really necessary to set devicePixelRatio for QImage objects? I
would think that they are set automatically.

* are you sure about the two different paths that depend on
is_transformed_ in QImage::width/height?

* In GuiPainter::image, you can get the devicePixelRatio from the QImage
to scale the dimensions.

* as discussed in the sections "Widgets and QPainter" of the blog entry
[2] in your post, some magic happens when using
qApp->setAttribute(Qt::AA_UseHighDpiPixmaps);
Is there a reason why you do not use it? They seems to say that
everything is (almost) automatic after that.

In general, this blog post gives a lot of interesting comments. I
suspect that you understand them better then I do and that life is less
easy than I would like but your code does not really look like the what
the post describes.

> Yes, I found a forked version of Qt 4 but I don't know if it's
> reliable (they call it a hack):
>
> https://github.com/msorvig/qt4-hidpi/

At the start of the blog post, the author points to a squashed backport
commit for Qt 4.8. If it works well enough, Stephan could try to use
this for the Qt binaries that we distribute.

Reagrds,
JMarc

[Stephan Witt]

Am 15.07.2014 um 23:23 schrieb Jean-Marc Lasgouttes <***@lyx.org>:

> Le 15/07/14 02:03, Marcelo Galvão Póvoa a écrit :
>>> This is excellent work. I am surprised that so many parts of the code need
>>> to be changed, the way the blog entry is written made me think that the
>>> changes could be smaller.
>>>
>>
>> Thanks. I tried to change the least amount of code but maybe someone
>> can suggest how to simplify my approach.
>
> OK, some remarks in no particuar order:
>
> * adding a fake variable to lyxrc is bad :)
>
> * is it really necessary to set devicePixelRatio for QImage objects? I would think that they are set automatically.
>
> * are you sure about the two different paths that depend on is_transformed_ in QImage::width/height?
>
> * In GuiPainter::image, you can get the devicePixelRatio from the QImage to scale the dimensions.
>
> * as discussed in the sections "Widgets and QPainter" of the blog entry [2] in your post, some magic happens when using
> qApp->setAttribute(Qt::AA_UseHighDpiPixmaps);
> Is there a reason why you do not use it? They seems to say that everything is (almost) automatic after that.
>
> In general, this blog post gives a lot of interesting comments. I suspect that you understand them better then I do and that life is less easy than I would like but your code does not really look like the what the post describes.
>
>> Yes, I found a forked version of Qt 4 but I don't know if it's
>> reliable (they call it a hack):
>>
>> https://github.com/msorvig/qt4-hidpi/

The latest commit is from March 2013.

>
> At the start of the blog post, the author points to a squashed backport commit for Qt 4.8. If it works well enough, Stephan could try to use this for the Qt binaries that we distribute.

I gave it a try and these are the facts I observed:

* LyX is not Qt5 ready - perhaps this should be changed first.
* I tried it with Qt4 and assigned 2.0 to lyxrc.pixel_ratio with ambivalent result.
- the text rendered on screen is crisp as it should
- the current changes to the code are not enough - see attachment
(work area size wrong, cursor size and positioning wrong, funny artefacts)
* I do not understand either why it's so difficult to get HiDPI scaled results.
* I found some articles on stackoverflow,
e.g. http://stackoverflow.com/questions/16527971/detect-hidpi-mode or
http://stackoverflow.com/questions/8594969/get-physical-screen-size-in-qt
- both are not very encouraging regarding Qt4.

Stephan

PS. Sorry for the attachment, I cannot make it smaller…

[Marcelo Galvão Póvoa]

On Tue, Jul 15, 2014 at 6:23 PM, Jean-Marc Lasgouttes
<***@lyx.org> wrote:
> Le 15/07/14 02:03, Marcelo Galvão Póvoa a écrit :
>
>>> This is excellent work. I am surprised that so many parts of the code
>>> need
>>> to be changed, the way the blog entry is written made me think that the
>>> changes could be smaller.
>>>
>>
>> Thanks. I tried to change the least amount of code but maybe someone
>> can suggest how to simplify my approach.
>
>
> OK, some remarks in no particuar order:
>
> * adding a fake variable to lyxrc is bad :)
>

Is there a better alternative? The variable can be made customizable
like the others but I don't know if it makes sense.

> * is it really necessary to set devicePixelRatio for QImage objects? I would
> think that they are set automatically.
>

AFAIK, yes. Otherwise it would understand as low resolution content
and stretch it.

> * are you sure about the two different paths that depend on is_transformed_
> in QImage::width/height?
>

What do you mean? If the original_ is always treated as HiDPI, I think
the transformed_ would be the same.

> * In GuiPainter::image, you can get the devicePixelRatio from the QImage to
> scale the dimensions.
>

Yes, I guess that would be nicer.

> * as discussed in the sections "Widgets and QPainter" of the blog entry [2]
> in your post, some magic happens when using
> qApp->setAttribute(Qt::AA_UseHighDpiPixmaps);
> Is there a reason why you do not use it? They seems to say that everything
> is (almost) automatic after that.
>

That flag only makes QIcon::pixmap() generate HiDPI pixmaps
automatically, but LyX pixmaps are not generated this way. So it
wouldn't make any difference here.

> In general, this blog post gives a lot of interesting comments. I suspect
> that you understand them better then I do and that life is less easy than I
> would like but your code does not really look like the what the post
> describes.
>

I think this extra work is needed because LyX's workarea is drawn as
raster graphics instead of using only Qt's native widgets. However,
it's my first attempt on implementing any "HiDPI support", so I am
open to suggestions.

Marcelo

[Jean-Marc Lasgouttes]

Le 16/07/14 20:41, Marcelo Galvão Póvoa a écrit :
>> * adding a fake variable to lyxrc is bad :)
>
> Is there a better alternative? The variable can be made customizable
> like the others but I don't know if it makes sense.

Why not use the value given by the current Window? Isn't it possible to
access it? You get it from a function, there is no need to store it in a
variable.

Note moreover that the documentation says

Use this function only when you don't know which window you are
targeting. If you do know the target window, use
QWindow::devicePixelRatio() instead.

[Think about a Retina MacBook plugged into a LowDPI external monitor.
One needs to know on what monitor the Window is]

Note that you can create a fake devicePixelRatio() method for Qt4.

>> * is it really necessary to set devicePixelRatio for QImage objects? I would
>> think that they are set automatically.
>
> AFAIK, yes. Otherwise it would understand as low resolution content
> and stretch it.

OK.

>> * are you sure about the two different paths that depend on is_transformed_
>> in QImage::width/height?
>
> What do you mean? If the original_ is always treated as HiDPI, I think
> the transformed_ would be the same.

Indeed. My mistake.

> That flag only makes QIcon::pixmap() generate HiDPI pixmaps
> automatically, but LyX pixmaps are not generated this way. So it
> wouldn't make any difference here.

OK.

> I think this extra work is needed because LyX's workarea is drawn as
> raster graphics instead of using only Qt's native widgets. However,
> it's my first attempt on implementing any "HiDPI support", so I am
> open to suggestions.

Anyway; the widgets manage to get things done without a global variable,
so we shall do the same :)

JMarc

[Marcelo Galvão Póvoa]

On Wed, Jul 16, 2014 at 4:32 PM, Jean-Marc Lasgouttes
<***@lyx.org> wrote:
> Le 16/07/14 20:41, Marcelo Galvão Póvoa a écrit :
>
>>> * adding a fake variable to lyxrc is bad :)
>>
>>
>> Is there a better alternative? The variable can be made customizable
>> like the others but I don't know if it makes sense.
>
>
> Why not use the value given by the current Window? Isn't it possible to
> access it? You get it from a function, there is no need to store it in a
> variable.
>
> Note moreover that the documentation says
>
> Use this function only when you don't know which window you are
> targeting. If you do know the target window, use
> QWindow::devicePixelRatio() instead.
>
> [Think about a Retina MacBook plugged into a LowDPI external monitor. One
> needs to know on what monitor the Window is]
>
> Note that you can create a fake devicePixelRatio() method for Qt4.
>

I'm not sure how to easily get a pointer to the window containing the
current workarea in every part of the code I need to use pixel_ratio.
I could use the globally available qApp->activeWindow() macro, but
what if the active window is a dialog window instead of the workarea?

Besides, I currently need the device_ratio in some parts outside the
Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
couldn't access the window from there.

Having multiple pixel ratios can indeed be an issue. For example, if a
GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
during initialization. But if the window is moved to a LowDPI screen
afterwards, the image ratio would need to be updated.

Marcelo

[Jean-Marc Lasgouttes]

Le 17/07/2014 23:24, Marcelo Galvão Póvoa a écrit :
> I'm not sure how to easily get a pointer to the window containing the
> current workarea in every part of the code I need to use pixel_ratio.
> I could use the globally available qApp->activeWindow() macro, but
> what if the active window is a dialog window instead of the workarea?

This is why there is a method to set it on a QImage/QPixmap. One only
needs to have the information when crating it.

> Besides, I currently need the device_ratio in some parts outside the
> Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
> couldn't access the window from there.

You could add a method to WorkArea that provides this information
(GuiWorkArea knows that). Would RenderImage be able to use it?

> Having multiple pixel ratios can indeed be an issue. For example, if a
> GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
> during initialization. But if the window is moved to a LowDPI screen
> afterwards, the image ratio would need to be updated.

Or a given LyX instance could have one window on one screen and another
window on another screen.

I suspect that "interesting" things will happen when a window with
previews moves from on screen to another. Except if we already check the
size of previews.

JMarc

[Stephan Witt]

Am 18.07.2014 um 10:26 schrieb Jean-Marc Lasgouttes <***@lyx.org>:

> Le 17/07/2014 23:24, Marcelo Galvão Póvoa a écrit :
>> I'm not sure how to easily get a pointer to the window containing the
>> current workarea in every part of the code I need to use pixel_ratio.
>> I could use the globally available qApp->activeWindow() macro, but
>> what if the active window is a dialog window instead of the workarea?
>
> This is why there is a method to set it on a QImage/QPixmap. One only needs to have the information when crating it.
>
>> Besides, I currently need the device_ratio in some parts outside the
>> Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
>> couldn't access the window from there.
>
> You could add a method to WorkArea that provides this information (GuiWorkArea knows that). Would RenderImage be able to use it?
>
>> Having multiple pixel ratios can indeed be an issue. For example, if a
>> GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
>> during initialization. But if the window is moved to a LowDPI screen
>> afterwards, the image ratio would need to be updated.
>
> Or a given LyX instance could have one window on one screen and another window on another screen.

Or you drag the LyX window from one screen with hi-res to another one with low-res.

E.g. from my laptop screen to the second screen on the TV.

Stephan

>
>
> I suspect that "interesting" things will happen when a window with previews moves from on screen to another. Except if we already check the size of previews.
>
> JMarc
>

[Stephan Witt]

Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:

>
> Am 18.07.2014 um 10:26 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>
>> Le 17/07/2014 23:24, Marcelo Galvão Póvoa a écrit :
>>> I'm not sure how to easily get a pointer to the window containing the
>>> current workarea in every part of the code I need to use pixel_ratio.
>>> I could use the globally available qApp->activeWindow() macro, but
>>> what if the active window is a dialog window instead of the workarea?
>>
>> This is why there is a method to set it on a QImage/QPixmap. One only needs to have the information when crating it.
>>
>>> Besides, I currently need the device_ratio in some parts outside the
>>> Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
>>> couldn't access the window from there.
>>
>> You could add a method to WorkArea that provides this information (GuiWorkArea knows that). Would RenderImage be able to use it?
>>
>>> Having multiple pixel ratios can indeed be an issue. For example, if a
>>> GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
>>> during initialization. But if the window is moved to a LowDPI screen
>>> afterwards, the image ratio would need to be updated.
>>
>> Or a given LyX instance could have one window on one screen and another window on another screen.
>
> Or you drag the LyX window from one screen with hi-res to another one with low-res.
>
> E.g. from my laptop screen to the second screen on the TV.
>
> Stephan
>
>>
>>
>> I suspect that "interesting" things will happen when a window with previews moves from on screen to another. Except if we already check the size of previews.
>>
>> JMarc

I gave it a try to make some progress regarding the HiDPI stuff.

First I've decided to split the task. I'd postpone the image scaling issues.
Not only because of the dynamic nature of the preview rendering. It's a slightly
more complex thing in general - we need to provide multiple image/icon sets for
different pixel ratios, IMHO.

My work is based on the first patch from Marcelo. I dropped the use of the global
LyXRC member variable and made an alternate solution without it.

See the attached patch. In principle it works. There is an issue with scrolling.
The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
it is drawn and the content of the region under at the left side of the main text
area is a duplicate of the middle of the text area on the stop of the scroll operation.
See the attached screen shot.

Stephan

[Stephan Witt]

Am 02.10.2014 um 13:14 schrieb Stephan Witt <***@gmx.net>:

> Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:
>
>>
>> Am 18.07.2014 um 10:26 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>>
>>> Le 17/07/2014 23:24, Marcelo Galvão Póvoa a écrit :
>>>> I'm not sure how to easily get a pointer to the window containing the
>>>> current workarea in every part of the code I need to use pixel_ratio.
>>>> I could use the globally available qApp->activeWindow() macro, but
>>>> what if the active window is a dialog window instead of the workarea?
>>>
>>> This is why there is a method to set it on a QImage/QPixmap. One only needs to have the information when crating it.
>>>
>>>> Besides, I currently need the device_ratio in some parts outside the
>>>> Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
>>>> couldn't access the window from there.
>>>
>>> You could add a method to WorkArea that provides this information (GuiWorkArea knows that). Would RenderImage be able to use it?
>>>
>>>> Having multiple pixel ratios can indeed be an issue. For example, if a
>>>> GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
>>>> during initialization. But if the window is moved to a LowDPI screen
>>>> afterwards, the image ratio would need to be updated.
>>>
>>> Or a given LyX instance could have one window on one screen and another window on another screen.
>>
>> Or you drag the LyX window from one screen with hi-res to another one with low-res.
>>
>> E.g. from my laptop screen to the second screen on the TV.
>>
>> Stephan
>>
>>>
>>>
>>> I suspect that "interesting" things will happen when a window with previews moves from on screen to another. Except if we already check the size of previews.
>>>
>>> JMarc
>
> I gave it a try to make some progress regarding the HiDPI stuff.
>
> First I've decided to split the task. I'd postpone the image scaling issues.
> Not only because of the dynamic nature of the preview rendering. It's a slightly
> more complex thing in general - we need to provide multiple image/icon sets for
> different pixel ratios, IMHO.
>
> My work is based on the first patch from Marcelo. I dropped the use of the global
> LyXRC member variable and made an alternate solution without it.
>
> See the attached patch. In principle it works. There is an issue with scrolling.
> The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
> it is drawn and the content of the region under at the left side of the main text
> area is a duplicate of the middle of the text area on the stop of the scroll operation.
> See the attached screen shot.
>
> Stephan
>
> <0003-Add-basic-qt5-HiDPI-rendering-support.patch>
> <Bildschirmfoto 2014-10-02 um 13.04.08.png>

Now I have an improved patch without the scrolling issue. I'd like to commit it.
Are there any thoughts about it?

Stephan

[Richard Heck]

On 10/05/2014 03:29 PM, Stephan Witt wrote:
> Am 02.10.2014 um 13:14 schrieb Stephan Witt <***@gmx.net>:
>
>> Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:
>>
>>> Am 18.07.2014 um 10:26 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>>>
>>>> Le 17/07/2014 23:24, Marcelo Galvão Póvoa a écrit :
>>>>> I'm not sure how to easily get a pointer to the window containing the
>>>>> current workarea in every part of the code I need to use pixel_ratio.
>>>>> I could use the globally available qApp->activeWindow() macro, but
>>>>> what if the active window is a dialog window instead of the workarea?
>>>> This is why there is a method to set it on a QImage/QPixmap. One only needs to have the information when crating it.
>>>>
>>>>> Besides, I currently need the device_ratio in some parts outside the
>>>>> Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
>>>>> couldn't access the window from there.
>>>> You could add a method to WorkArea that provides this information (GuiWorkArea knows that). Would RenderImage be able to use it?
>>>>
>>>>> Having multiple pixel ratios can indeed be an issue. For example, if a
>>>>> GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
>>>>> during initialization. But if the window is moved to a LowDPI screen
>>>>> afterwards, the image ratio would need to be updated.
>>>> Or a given LyX instance could have one window on one screen and another window on another screen.
>>> Or you drag the LyX window from one screen with hi-res to another one with low-res.
>>>
>>> E.g. from my laptop screen to the second screen on the TV.
>>>
>>> Stephan
>>>
>>>>
>>>> I suspect that "interesting" things will happen when a window with previews moves from on screen to another. Except if we already check the size of previews.
>>>>
>>>> JMarc
>> I gave it a try to make some progress regarding the HiDPI stuff.
>>
>> First I've decided to split the task. I'd postpone the image scaling issues.
>> Not only because of the dynamic nature of the preview rendering. It's a slightly
>> more complex thing in general - we need to provide multiple image/icon sets for
>> different pixel ratios, IMHO.
>>
>> My work is based on the first patch from Marcelo. I dropped the use of the global
>> LyXRC member variable and made an alternate solution without it.
>>
>> See the attached patch. In principle it works. There is an issue with scrolling.
>> The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
>> it is drawn and the content of the region under at the left side of the main text
>> area is a duplicate of the middle of the text area on the stop of the scroll operation.
>> See the attached screen shot.
>>
>> Stephan
>>
>> <0003-Add-basic-qt5-HiDPI-rendering-support.patch>
>> <Bildschirmfoto 2014-10-02 um 13.04.08.png>
> Now I have an improved patch without the scrolling issue. I'd like to commit it.
> Are there any thoughts about it?

I assume this would (should?) also work for non-OSX HiDPI monitors? Do
we know anything about this?

Richard

[Stephan Witt]

Am 06.10.2014 um 15:52 schrieb Richard Heck <***@lyx.org>:

> On 10/05/2014 03:29 PM, Stephan Witt wrote:
>> Am 02.10.2014 um 13:14 schrieb Stephan Witt <***@gmx.net>:
>>
>>> Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:
>>>
>>>> Am 18.07.2014 um 10:26 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>>>>
>>>>> Le 17/07/2014 23:24, Marcelo Galvão Póvoa a écrit :
>>>>>> I'm not sure how to easily get a pointer to the window containing the
>>>>>> current workarea in every part of the code I need to use pixel_ratio.
>>>>>> I could use the globally available qApp->activeWindow() macro, but
>>>>>> what if the active window is a dialog window instead of the workarea?
>>>>> This is why there is a method to set it on a QImage/QPixmap. One only needs to have the information when crating it.
>>>>>
>>>>>> Besides, I currently need the device_ratio in some parts outside the
>>>>>> Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
>>>>>> couldn't access the window from there.
>>>>> You could add a method to WorkArea that provides this information (GuiWorkArea knows that). Would RenderImage be able to use it?
>>>>>
>>>>>> Having multiple pixel ratios can indeed be an issue. For example, if a
>>>>>> GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
>>>>>> during initialization. But if the window is moved to a LowDPI screen
>>>>>> afterwards, the image ratio would need to be updated.
>>>>> Or a given LyX instance could have one window on one screen and another window on another screen.
>>>> Or you drag the LyX window from one screen with hi-res to another one with low-res.
>>>>
>>>> E.g. from my laptop screen to the second screen on the TV.
>>>>
>>>> Stephan
>>>>
>>>>>
>>>>> I suspect that "interesting" things will happen when a window with previews moves from on screen to another. Except if we already check the size of previews.
>>>>>
>>>>> JMarc
>>> I gave it a try to make some progress regarding the HiDPI stuff.
>>>
>>> First I've decided to split the task. I'd postpone the image scaling issues.
>>> Not only because of the dynamic nature of the preview rendering. It's a slightly
>>> more complex thing in general - we need to provide multiple image/icon sets for
>>> different pixel ratios, IMHO.
>>>
>>> My work is based on the first patch from Marcelo. I dropped the use of the global
>>> LyXRC member variable and made an alternate solution without it.
>>>
>>> See the attached patch. In principle it works. There is an issue with scrolling.
>>> The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
>>> it is drawn and the content of the region under at the left side of the main text
>>> area is a duplicate of the middle of the text area on the stop of the scroll operation.
>>> See the attached screen shot.
>>>
>>> Stephan
>>>
>>> <0003-Add-basic-qt5-HiDPI-rendering-support.patch>
>>> <Bildschirmfoto 2014-10-02 um 13.04.08.png>
>> Now I have an improved patch without the scrolling issue. I'd like to commit it.
>> Are there any thoughts about it?

To answer myself:
The patch should introduce the pixelRatio() methods instead of pixel_ratio()
to follow the camelCase method naming rule. I'll adjust the patch accordingly.

>
> I assume this would (should?) also work for non-OSX HiDPI monitors? Do we know anything about this?

Yes, it should work were Qt supports this.

This is the list of files containing the string setDevicePixelRatio:

$ mdfind -onlyin qt-everywhere-opensource-src-5.3.2/qtbase setDevicePixelRatio
src/gui/image/qimage.cpp
src/plugins/platforms/cocoa/qcocoabackingstore.mm
src/plugins/platforms/ios/qiosbackingstore.mm
src/plugins/platforms/direct2d/qwindowsdirect2dplatformpixmap.h
src/plugins/platforms/direct2d/qwindowsdirect2dplatformpixmap.cpp
src/gui/image/qpixmap_raster_p.h
src/gui/image/qicon.cpp
src/gui/image/qimage.h
src/gui/image/qpixmap.cpp
src/gui/image/qpixmap_blitter.cpp
src/gui/image/qpixmap.h
src/gui/image/qpixmap_raster.cpp
src/gui/image/qimagereader.cpp
src/gui/image/qicon_p.h
src/gui/image/qplatformpixmap.h
src/gui/image/qpixmap_blitter_p.h
src/gui/opengl/qopenglpaintdevice.cpp
src/gui/opengl/qopenglpaintdevice.h

This is from the Qt5 documentation:

* qreal QWindow::devicePixelRatio() const
Returns the ratio between physical pixels and device-independent pixels for the window. This value is dependent on the screen the window is on, and may change when the window is moved.
Common values are 1.0 on normal displays and 2.0 on Apple "retina" displays.

I'd conclude it may work on iOS, Mac OS with Cocoa and perhaps on MS-Windows.
For Linux I cannot see any hint that it should work.

Stephan

[Marcelo Galvão Póvoa]

On Sun, Oct 5, 2014 at 4:29 PM, Stephan Witt <***@gmx.net> wrote:
> Am 02.10.2014 um 13:14 schrieb Stephan Witt <***@gmx.net>:
>
>> Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:
>>
>>>
>>> Am 18.07.2014 um 10:26 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>>>
>>>> Le 17/07/2014 23:24, Marcelo Galvão Póvoa a écrit :
>>>>> I'm not sure how to easily get a pointer to the window containing the
>>>>> current workarea in every part of the code I need to use pixel_ratio.
>>>>> I could use the globally available qApp->activeWindow() macro, but
>>>>> what if the active window is a dialog window instead of the workarea?
>>>>
>>>> This is why there is a method to set it on a QImage/QPixmap. One only needs to have the information when crating it.
>>>>
>>>>> Besides, I currently need the device_ratio in some parts outside the
>>>>> Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
>>>>> couldn't access the window from there.
>>>>
>>>> You could add a method to WorkArea that provides this information (GuiWorkArea knows that). Would RenderImage be able to use it?
>>>>
>>>>> Having multiple pixel ratios can indeed be an issue. For example, if a
>>>>> GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
>>>>> during initialization. But if the window is moved to a LowDPI screen
>>>>> afterwards, the image ratio would need to be updated.
>>>>
>>>> Or a given LyX instance could have one window on one screen and another window on another screen.
>>>
>>> Or you drag the LyX window from one screen with hi-res to another one with low-res.
>>>
>>> E.g. from my laptop screen to the second screen on the TV.
>>>
>>> Stephan
>>>
>>>>
>>>>
>>>> I suspect that "interesting" things will happen when a window with previews moves from on screen to another. Except if we already check the size of previews.
>>>>
>>>> JMarc
>>
>> I gave it a try to make some progress regarding the HiDPI stuff.
>>
>> First I've decided to split the task. I'd postpone the image scaling issues.
>> Not only because of the dynamic nature of the preview rendering. It's a slightly
>> more complex thing in general - we need to provide multiple image/icon sets for
>> different pixel ratios, IMHO.
>>
>> My work is based on the first patch from Marcelo. I dropped the use of the global
>> LyXRC member variable and made an alternate solution without it.
>>
>> See the attached patch. In principle it works. There is an issue with scrolling.
>> The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
>> it is drawn and the content of the region under at the left side of the main text
>> area is a duplicate of the middle of the text area on the stop of the scroll operation.
>> See the attached screen shot.
>>
>> Stephan
>>
>> <0003-Add-basic-qt5-HiDPI-rendering-support.patch>
>> <Bildschirmfoto 2014-10-02 um 13.04.08.png>
>
> Now I have an improved patch without the scrolling issue. I'd like to commit it.
> Are there any thoughts about it?
>
> Stephan
>

I tested your patch a little and I found some of the quirks I've been
having when I worked with this:

- Redrawing the cursor sometimes causes some drawing errors around
characters. If I hold left/right arrow key to move the cursor across
text, I get something like the attached screenshot. As I mentioned, my
patch avoids partial viewport updates to workaround this, but it is
not a decent solution.

- Instant Preview of math formulas is not rendered in HiDPI. My patch
does this but has an ugly dependency on LyxRC.

- Dynamically changing window DPI (i.e, moving it between different
screens) makes the text blurry. I haven't tested this much, but maybe
it is related to some unflushed drawing cache?

Marcelo

[Stephan Witt]

Am 06.10.2014 um 22:05 schrieb Marcelo Galvão Póvoa <***@gmail.com>:

> On Sun, Oct 5, 2014 at 4:29 PM, Stephan Witt <***@gmx.net> wrote:
>> Am 02.10.2014 um 13:14 schrieb Stephan Witt <***@gmx.net>:
>>
>>> Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:
>>>
>>>>
>>>> Am 18.07.2014 um 10:26 schrieb Jean-Marc Lasgouttes <***@lyx.org>:
>>>>
>>>>> Le 17/07/2014 23:24, Marcelo Galvão Póvoa a écrit :
>>>>>> I'm not sure how to easily get a pointer to the window containing the
>>>>>> current workarea in every part of the code I need to use pixel_ratio.
>>>>>> I could use the globally available qApp->activeWindow() macro, but
>>>>>> what if the active window is a dialog window instead of the workarea?
>>>>>
>>>>> This is why there is a method to set it on a QImage/QPixmap. One only needs to have the information when crating it.
>>>>>
>>>>>> Besides, I currently need the device_ratio in some parts outside the
>>>>>> Qt frontend (for example, in src/insets/RenderGraphic.cpp), so I
>>>>>> couldn't access the window from there.
>>>>>
>>>>> You could add a method to WorkArea that provides this information (GuiWorkArea knows that). Would RenderImage be able to use it?
>>>>>
>>>>>> Having multiple pixel ratios can indeed be an issue. For example, if a
>>>>>> GuiImage is created in a HiDPI screen, it would be assigned a 2x ratio
>>>>>> during initialization. But if the window is moved to a LowDPI screen
>>>>>> afterwards, the image ratio would need to be updated.
>>>>>
>>>>> Or a given LyX instance could have one window on one screen and another window on another screen.
>>>>
>>>> Or you drag the LyX window from one screen with hi-res to another one with low-res.
>>>>
>>>> E.g. from my laptop screen to the second screen on the TV.
>>>>
>>>> Stephan
>>>>
>>>>>
>>>>>
>>>>> I suspect that "interesting" things will happen when a window with previews moves from on screen to another. Except if we already check the size of previews.
>>>>>
>>>>> JMarc
>>>
>>> I gave it a try to make some progress regarding the HiDPI stuff.
>>>
>>> First I've decided to split the task. I'd postpone the image scaling issues.
>>> Not only because of the dynamic nature of the preview rendering. It's a slightly
>>> more complex thing in general - we need to provide multiple image/icon sets for
>>> different pixel ratios, IMHO.
>>>
>>> My work is based on the first patch from Marcelo. I dropped the use of the global
>>> LyXRC member variable and made an alternate solution without it.
>>>
>>> See the attached patch. In principle it works. There is an issue with scrolling.
>>> The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
>>> it is drawn and the content of the region under at the left side of the main text
>>> area is a duplicate of the middle of the text area on the stop of the scroll operation.
>>> See the attached screen shot.
>>>
>>> Stephan
>>>
>>> <0003-Add-basic-qt5-HiDPI-rendering-support.patch>
>>> <Bildschirmfoto 2014-10-02 um 13.04.08.png>
>>
>> Now I have an improved patch without the scrolling issue. I'd like to commit it.
>> Are there any thoughts about it?
>>
>> Stephan
>>
>
> I tested your patch a little and I found some of the quirks I've been
> having when I worked with this:
>
> - Redrawing the cursor sometimes causes some drawing errors around
> characters. If I hold left/right arrow key to move the cursor across
> text, I get something like the attached screenshot. As I mentioned, my
> patch avoids partial viewport updates to workaround this, but it is
> not a decent solution.
>
> - Instant Preview of math formulas is not rendered in HiDPI. My patch
> does this but has an ugly dependency on LyxRC.

Yes, I know. I said I'll split the task into pieces. I'm working on
an improved patch to get HiDPI preview already.

Do you have a proposal how to get HiDPI icons?

> - Dynamically changing window DPI (i.e, moving it between different
> screens) makes the text blurry. I haven't tested this much, but maybe
> it is related to some unflushed drawing cache?

I've tested this too and didn't see it. But after that I changed the code.
I'll investigate again. Thanks.

Stephan

[Cyrille Artho]

>
> Do you have a proposal how to get HiDPI icons?
>
This could be a task for "Google Code In" (GCI), where high school students
work on small tasks for $100 per task. I think we would have to come up
with several types of work packages but things like
documentation/translation would already fill up two more categories.

I've never participated in GCI but I've heard that some people were very
happy about the results. We could definitely get a bunch of relatively
easy, clearly defined work done that way.
--
Regards,
Cyrille Artho - http://artho.com/
Good judgment comes from experience. Experience comes from bad judgment.
-- Jim Horning

[Stephan Witt]

Am 07.10.2014 um 01:38 schrieb Cyrille Artho <***@aist.go.jp>:

>> Do you have a proposal how to get HiDPI icons?
>>
> This could be a task for "Google Code In" (GCI), where high school students work on small tasks for $100 per task. I think we would have to come up with several types of work packages but things like documentation/translation would already fill up two more categories.

What's the time line implication for CGI? I'd like to get HiDPI ready for use this year.
E.g. as a gift for christmas :)

The first task to get HiDPI icons is to have high resolution icon sets.
The 2nd step is to implement a solution to choose the correct icons
for the actual screen resolution.

So, we have some art work to do and then some coding.

Stephan

> I've never participated in GCI but I've heard that some people were very happy about the results. We could definitely get a bunch of relatively easy, clearly defined work done that way.
> --
> Regards,
> Cyrille Artho - http://artho.com/
> Good judgment comes from experience. Experience comes from bad judgment.
> -- Jim Horning

[Cyrille Artho]

Stephan Witt wrote:
> Am 07.10.2014 um 01:38 schrieb Cyrille Artho <***@aist.go.jp>:
>
>>> Do you have a proposal how to get HiDPI icons?
>>>
>> This could be a task for "Google Code In" (GCI), where high school students work on small tasks for $100 per task. I think we would have to come up with several types of work packages but things like documentation/translation would already fill up two more categories.
>
> What's the time line implication for CGI? I'd like to get HiDPI ready for use this year.
> E.g. as a gift for christmas :)
>
> The first task to get HiDPI icons is to have high resolution icon sets.
> The 2nd step is to implement a solution to choose the correct icons
> for the actual screen resolution.
>
> So, we have some art work to do and then some coding.
>
> Stephan
>
>> I've never participated in GCI but I've heard that some people were very happy about the results. We could definitely get a bunch of relatively easy, clearly defined work done that way.
>
We would have to register soon (registration of organizations begins on
Oct. 27 and ends on Nov. 12). It seems that the program now runs a contest
where participants can win T-shirts etc., but for us things probably have
not changed too much from earlier years.

For chosen organizations, the whole thing runs from Dec. 1 - Jan. 18. So
your Christmas present may materialize in time ;-) and it can also include
coding; the following tasks are eligible:

1. Code: Tasks related to writing or refactoring code
2. Documentation/Training: Tasks related to creating/editing documents
and helping others learn more
3. Outreach/Research Tasks related to community management,
outreach/marketing or studying problems and recommending solutions
4. Quality Assurance: Tasks related to testing and ensuring code is of
high quality
5. User Interface: Tasks related to user experience research or user
interface design and interaction

I'm not sure if it is still necessary to have tasks in each category to be
eligible. We can probably do that, although for (1) it is difficult to
break things down into very small tasks.

For (2), I'm sure there are plenty of places where the documentation needs
updates from time to time. Having more/newer animated videos/walkthroughs
of certain tasks would also be nice; the web page currently has quite a few
of them but they were made using LyX 1.6.

Regarding (3), maybe the web page could be broken down into smaller bits
(more/smaller pages, at least for the top page and introductory parts)? Or
other things such as a study on what high school students need when writing
their papers (could we get them to use LyX or should we target university
students and older people?).

Probably some amount of testing or test scripting would also be helpful
(4), and finally icon design (5), which was eligible in the past and I hope
it also eligible this time.
--
Regards,
Cyrille Artho - http://artho.com/
If someone had told me I would be Pope one day, I would have studied harder.
-- Pope John Paul I

[Jürgen Spitzmüller]

2014-10-07 8:57 GMT+02:00 Stephan Witt:

>
> The first task to get HiDPI icons is to have high resolution icon sets.
> The 2nd step is to implement a solution to choose the correct icons
> for the actual screen resolution.
>
> So, we have some art work to do and then some coding.
>

Switch to SVG?

I have SVG versions of some (although not all) of our own icons (I will
commit them eventually), and the icons taken from public sets should also
be available as SVG.

JÃŒrgen

[Jean-Marc Lasgouttes]

Le 07/10/14 10:13, Jürgen Spitzmüller a écrit :
> So, we have some art work to do and then some coding.
>
> Switch to SVG?
>
> I have SVG versions of some (although not all) of our own icons (I will
> commit them eventually), and the icons taken from public sets should
> also be available as SVG.

Yes, we should start to investigate this.

JMarc

[Jürgen Spitzmüller]

2014-10-07 10:20 GMT+02:00 Jean-Marc Lasgouttes:

> Yes, we should start to investigate this.
>

I commit what I have collected so far when I am back home (end of week).
This includes some of the oxygen icons (SVGs from the KDE set). Then people
can go ahead and try to complete the set(s).

JÃŒrgen


>
> JMarc
>
>

[Stephan Witt]

Am 07.10.2014 um 10:13 schrieb Jürgen Spitzmüller <***@lyx.org>:

> 2014-10-07 8:57 GMT+02:00 Stephan Witt:
>
> The first task to get HiDPI icons is to have high resolution icon sets.
> The 2nd step is to implement a solution to choose the correct icons
> for the actual screen resolution.
>
> So, we have some art work to do and then some coding.
>
> Switch to SVG?
>
> I have SVG versions of some (although not all) of our own icons (I will commit them eventually), and the icons taken from public sets should also be available as SVG.
>
> Jürgen

Please note that Qt is using the Apple @2x naming convention to detect HiDPI icons itself.
To adopt this for LyX is another possibility. I'm not sure what alternative ways exist,
e.g. how the Gnome desktop is doing these HiDPI things.

Stephan

[Jürgen Spitzmüller]

2014-10-07 12:37 GMT+02:00 Stephan Witt:

> Please note that Qt is using the Apple @2x naming convention to detect
> HiDPI icons itself.
> To adopt this for LyX is another possibility. I'm not sure what
> alternative ways exist,
> e.g. how the Gnome desktop is doing these HiDPI things.
>

In that case, we could probably set up a script that generates those @2x
icons (as well as icons of diverse size) from the SVG. This could also be
used in order to generate bigger icons for other purposes (think tablet UI).

JÃŒrgen


>
> Stephan

[Jean-Marc Lasgouttes]

Le 07/10/2014 13:10, Jürgen Spitzmüller a écrit :
> In that case, we could probably set up a script that generates those @2x
> icons (as well as icons of diverse size) from the SVG. This could also
> be used in order to generate bigger icons for other purposes (think
> tablet UI).

Why not use directly the svg versions? Is it bad in terms of performance?

JMarc

[Jürgen Spitzmüller]

2014-10-07 15:44 GMT+02:00 Jean-Marc Lasgouttes:

> Le 07/10/2014 13:10, JÌrgen SpitzmÌller a écrit :
>
>> In that case, we could probably set up a script that generates those @2x
>> icons (as well as icons of diverse size) from the SVG. This could also
>> be used in order to generate bigger icons for other purposes (think
>> tablet UI).
>>
>
> Why not use directly the svg versions? Is it bad in terms of performance?
>

If this is possible with the Qt HDPI approach (i.e., if it does not
requires those @2x icon bitmap files). I have not checked that, but if I
understand this correctly, it should be possible:
http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/

Quote:

"As we have seen, raster content won’t look nice when scaled and
high-resolution content should be provided. As an app developer you have
two options: (ignoring the “do-nothing” option)

- Replace existing raster content with a high-resolution version
- Provide separate high-resolution content

The first option is convenient since there is only one version of each
resource. However, you may find (or your designer will tell you) that
resources like icons look best when created for a specific resolution. To
facilitate this, Qt as adopted the “@2x” convention for image filenames:"

SVG would be "first option", no?

JÃŒrgen



>
> JMarc
>
>

[Stephan Witt]

Am 07.10.2014 um 15:58 schrieb Jürgen Spitzmüller <***@lyx.org>:

> 2014-10-07 15:44 GMT+02:00 Jean-Marc Lasgouttes:
> Le 07/10/2014 13:10, Jürgen Spitzmüller a écrit :
> In that case, we could probably set up a script that generates those @2x
> icons (as well as icons of diverse size) from the SVG. This could also
> be used in order to generate bigger icons for other purposes (think
> tablet UI).
>
> Why not use directly the svg versions? Is it bad in terms of performance?
>
> If this is possible with the Qt HDPI approach (i.e., if it does not requires those @2x icon bitmap files). I have not checked that, but if I understand this correctly, it should be possible:
> http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/
>
> Quote:
>
> "As we have seen, raster content won’t look nice when scaled and high-resolution content should be provided. As an app developer you have two options: (ignoring the “do-nothing” option)
> • Replace existing raster content with a high-resolution version
> • Provide separate high-resolution content
> The first option is convenient since there is only one version of each resource. However, you may find (or your designer will tell you) that resources like icons look best when created for a specific resolution. To facilitate this, Qt as adopted the “@2x” convention for image filenames:"
>
> SVG would be "first option", no?

Yes, I think so.

The nice effect of using the “@2x” convention is the assignment of the correct
devicePixelRation to the images Qt creates that way.

Stephan

[Stephan Witt]

Am 08.10.2014 um 12:19 schrieb Stephan Witt <***@gmx.net>:

> Am 07.10.2014 um 15:58 schrieb Jürgen Spitzmüller <***@lyx.org>:
>
>> 2014-10-07 15:44 GMT+02:00 Jean-Marc Lasgouttes:
>> Le 07/10/2014 13:10, Jürgen Spitzmüller a écrit :
>> In that case, we could probably set up a script that generates those @2x
>> icons (as well as icons of diverse size) from the SVG. This could also
>> be used in order to generate bigger icons for other purposes (think
>> tablet UI).
>>
>> Why not use directly the svg versions? Is it bad in terms of performance?
>>
>> If this is possible with the Qt HDPI approach (i.e., if it does not requires those @2x icon bitmap files). I have not checked that, but if I understand this correctly, it should be possible:
>> http://blog.qt.digia.com/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/
>>
>> Quote:
>>
>> "As we have seen, raster content won’t look nice when scaled and high-resolution content should be provided. As an app developer you have two options: (ignoring the “do-nothing” option)
>> • Replace existing raster content with a high-resolution version
>> • Provide separate high-resolution content
>> The first option is convenient since there is only one version of each resource. However, you may find (or your designer will tell you) that resources like icons look best when created for a specific resolution. To facilitate this, Qt as adopted the “@2x” convention for image filenames:"
>>
>> SVG would be "first option", no?
>
> Yes, I think so.
>
> The nice effect of using the “@2x” convention is the assignment of the correct
> devicePixelRation to the images Qt creates that way.
>
> Stephan

Now I have an updated patch including hi-dpi preview and icons. It is really obfuscated now.
I don't want to commit it as this monster patch. I'll try to explain it for review therefore…

* Buffer::fontScalingFactor() demonstrates we have a problem with other LyXRC variables already
with preview snippets. Change of the zoom doesn't scale the preview snippets accordingly.
And I'm not sure the value of dpi is constant, too.

* The BufferParams.display_pixel_ratio member will be set to the magnification the app wants.
This happens when the buffer is assigned to the work area. Not as clean as I want but I couldn't
come up with a better solution.

* The file lookup is extended with a mode to search for hi-dpi versions of an image file.
In case we go the "SVG"-route this of course has to be changed. But I don't know how, ATM.

* GuiPainter::image method had used complete wrong parameters for Qt drawImage() call, IMHO.
It used to work because of source rect being of the same size as destination rect.

* The width and height of a GuiImage returns device independent "logical" values.
I'm not sure if this is the best solution. But it works now. If this changes one has to adapt
all callers of GuiImage::width or GuiImage::height.

BTW: Does anyone know how to find all callers of a C++ method? I'm used to have this at hand
when working with Eclipse and Java. I cannot find this feature neither in Eclipse for C++ nor
in XCode. Is there any IDE with this functionality? Refactoring of code would be much more easy
with this :(


Stephan

[Richard Heck]

On 10/08/2014 11:48 AM, Stephan Witt wrote:
> Now I have an updated patch including hi-dpi preview and icons. It is really obfuscated now. I don't want to commit it as this monster patch. I'll try to explain it for review therefore…

I don't have an HiDPI display so can't test this.

> * The BufferParams.display_pixel_ratio member will be set to the magnification the app wants. This happens when the buffer is assigned to the work area. Not as clean as I want but I couldn't come up with a better solution.

It seems to me that maybe this should be a member of BufferView. One
could in principle have the same buffer open in two windows on two
different monitors, no? I would suppose for the same reason that
Buffer::fontScalingFactor should be in BufferView, etc.

> BTW: Does anyone know how to find all callers of a C++ method? I'm used to have this at hand when working with Eclipse and Java. I cannot find this feature neither in Eclipse for C++ nor in XCode. Is there any IDE with this functionality? Refactoring of code would be much more easy with this :(

In QtCreator, if you go to any place the method is used or declared, you
can right click and then choose "Find Usages". That will give you what
you want.

Richard

[Stephan Witt]

Am 09.10.2014 um 00:25 schrieb Richard Heck <***@lyx.org>:

> On 10/08/2014 11:48 AM, Stephan Witt wrote:
>> Now I have an updated patch including hi-dpi preview and icons. It is really obfuscated now. I don't want to commit it as this monster patch. I'll try to explain it for review therefore…
>
> I don't have an HiDPI display so can't test this.

Thank you for reviewing it.

>> * The BufferParams.display_pixel_ratio member will be set to the magnification the app wants. This happens when the buffer is assigned to the work area. Not as clean as I want but I couldn't come up with a better solution.
>
> It seems to me that maybe this should be a member of BufferView. One could in principle have the same buffer open in two windows on two different monitors, no? I would suppose for the same reason that Buffer::fontScalingFactor should be in BufferView, etc.

I agree - but how can the PreviewLoader access the BufferView?
In case of more than one - what is the right one then?

The value in BufferParams.display_pixel_ratio has "application scope".
But this may change, I'm not sure.

>> BTW: Does anyone know how to find all callers of a C++ method? I'm used to have this at hand when working with Eclipse and Java. I cannot find this feature neither in Eclipse for C++ nor in XCode. Is there any IDE with this functionality? Refactoring of code would be much more easy with this :(
>
> In QtCreator, if you go to any place the method is used or declared, you can right click and then choose "Find Usages". That will give you what you want.

Ok, thanks. But now I found this feature in XCode too. It was somewhat hidden -
no menu entry and not in any context menu. It is changeable in the find area.

Stephan

[Richard Heck]

On 10/09/2014 03:25 AM, Stephan Witt wrote:
> Am 09.10.2014 um 00:25 schrieb Richard Heck <***@lyx.org>:
>>> * The BufferParams.display_pixel_ratio member will be set to the magnification the app wants. This happens when the buffer is assigned to the work area. Not as clean as I want but I couldn't come up with a better solution.
>> It seems to me that maybe this should be a member of BufferView. One could in principle have the same buffer open in two windows on two different monitors, no? I would suppose for the same reason that Buffer::fontScalingFactor should be in BufferView, etc.
> I agree - but how can the PreviewLoader access the BufferView?
> In case of more than one - what is the right one then?

Yes, I see the problem. Preview loading is at the moment per Buffer.
Long term, maybe that needs to be changed. For now, could we try to find
out what the maximum resolution we need is and do that? Scaling the
image down is presumably easier.

Richard

[Stephan Witt]

Am 09.10.2014 um 16:04 schrieb Richard Heck <***@lyx.org>:

> On 10/09/2014 03:25 AM, Stephan Witt wrote:
>> Am 09.10.2014 um 00:25 schrieb Richard Heck <***@lyx.org>:
>>>> * The BufferParams.display_pixel_ratio member will be set to the magnification the app wants. This happens when the buffer is assigned to the work area. Not as clean as I want but I couldn't come up with a better solution.
>>> It seems to me that maybe this should be a member of BufferView. One could in principle have the same buffer open in two windows on two different monitors, no? I would suppose for the same reason that Buffer::fontScalingFactor should be in BufferView, etc.
>> I agree - but how can the PreviewLoader access the BufferView?
>> In case of more than one - what is the right one then?
>
> Yes, I see the problem. Preview loading is at the moment per Buffer. Long term, maybe that needs to be changed. For now, could we try to find out what the maximum resolution we need is and do that? Scaling the image down is presumably easier.

This is exactly how it works with my patch. The maximum resolution is queried from the GuiApplication.
Later it fits for the current screen or will be scaled down for lower resolution.

Stephan

[Richard Heck]

On 10/09/2014 10:16 AM, Stephan Witt wrote:
> Am 09.10.2014 um 16:04 schrieb Richard Heck <***@lyx.org>:
>
>> On 10/09/2014 03:25 AM, Stephan Witt wrote:
>>> Am 09.10.2014 um 00:25 schrieb Richard Heck <***@lyx.org>:
>>>>> * The BufferParams.display_pixel_ratio member will be set to the magnification the app wants. This happens when the buffer is assigned to the work area. Not as clean as I want but I couldn't come up with a better solution.
>>>> It seems to me that maybe this should be a member of BufferView. One could in principle have the same buffer open in two windows on two different monitors, no? I would suppose for the same reason that Buffer::fontScalingFactor should be in BufferView, etc.
>>> I agree - but how can the PreviewLoader access the BufferView?
>>> In case of more than one - what is the right one then?
>> Yes, I see the problem. Preview loading is at the moment per Buffer. Long term, maybe that needs to be changed. For now, could we try to find out what the maximum resolution we need is and do that? Scaling the image down is presumably easier.
> This is exactly how it works with my patch. The maximum resolution is queried from the GuiApplication.
> Later it fits for the current screen or will be scaled down for lower resolution.

OK, that sounds reasonable. I suppose we can see how it works and if we
need to do something more we can do it then.

Richard

[Stephan Witt]

Am 09.10.2014 um 16:18 schrieb Richard Heck <***@lyx.org>:

> On 10/09/2014 10:16 AM, Stephan Witt wrote:
>> Am 09.10.2014 um 16:04 schrieb Richard Heck <***@lyx.org>:
>>
>>> On 10/09/2014 03:25 AM, Stephan Witt wrote:
>>>> Am 09.10.2014 um 00:25 schrieb Richard Heck <***@lyx.org>:
>>>>>> * The BufferParams.display_pixel_ratio member will be set to the magnification the app wants. This happens when the buffer is assigned to the work area. Not as clean as I want but I couldn't come up with a better solution.
>>>>> It seems to me that maybe this should be a member of BufferView. One could in principle have the same buffer open in two windows on two different monitors, no? I would suppose for the same reason that Buffer::fontScalingFactor should be in BufferView, etc.
>>>> I agree - but how can the PreviewLoader access the BufferView?
>>>> In case of more than one - what is the right one then?
>>> Yes, I see the problem. Preview loading is at the moment per Buffer. Long term, maybe that needs to be changed. For now, could we try to find out what the maximum resolution we need is and do that? Scaling the image down is presumably easier.
>> This is exactly how it works with my patch. The maximum resolution is queried from the GuiApplication.
>> Later it fits for the current screen or will be scaled down for lower resolution.
>
> OK, that sounds reasonable. I suppose we can see how it works and if we need to do something more we can do it then.

I'm trying to verify my changes on Linux.

Using Ubuntu 12.04 and a self compiled Qt5.3.2 I'm getting this error:

CXX docstring.o
In file included from /usr/local/Qt-5.3.2/include/QtCore/qiodevice.h:45:0,
from /usr/local/Qt-5.3.2/include/QtCore/qfiledevice.h:45,
from /usr/local/Qt-5.3.2/include/QtCore/qfile.h:45,
from /usr/local/Qt-5.3.2/include/QtCore/QFile:1,
from ../../../LyX-2.2-2.2.0dev/src/support/docstring.cpp:20:
/usr/local/Qt-5.3.2/include/QtCore/qglobal.h:1034:4: Fehler: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC or -fPIE."
make[5]: *** [docstring.o] Fehler 1

1. I'm missing the configure option for generating position independent code.
2. If I'm calling LyX configure with CPPFLAGS=-fPIC I can compile docstring.o
but later it's getting worse.

CXX lyxtime.o
In file included from /usr/include/c++/4.6/bits/concept_check.h:55:0,
from /usr/include/c++/4.6/bits/move.h:34,
from /usr/include/c++/4.6/bits/stl_pair.h:60,
from /usr/include/c++/4.6/bits/stl_algobase.h:65,
from /usr/include/c++/4.6/bits/char_traits.h:41,
from /usr/include/c++/4.6/string:42,
from ../../../LyX-2.2-2.2.0dev/src/support/../support/lyxtime.h:17,
from ../../../LyX-2.2-2.2.0dev/src/support/lyxtime.cpp:13:
/usr/include/c++/4.6/bits/boost_concept_check.h: In Elementfunktion »void __gnu_cxx::_RandomAccessIteratorConcept<_Tp>::__constraints() [with _Tp = QList<QVariant>::const_iterator]«:
/usr/include/c++/4.6/bits/boost_concept_check.h:60:50: instanziiert von »void __gnu_cxx::__function_requires() [with _Concept = __gnu_cxx::_RandomAccessIteratorConcept<QList<QVariant>::const_iterator>]«
/usr/include/c++/4.6/bits/stl_iterator_base_funcs.h:152:7: instanziiert von »void std::__advance(_RandomAccessIterator&, _Distance, std::random_access_iterator_tag) [with _RandomAccessIterator = QList<QVariant>::const_iterator, _Distance = int]«
/usr/include/c++/4.6/bits/stl_iterator_base_funcs.h:175:7: instanziiert von »void std::advance(_InputIterator&, _Distance) [with _InputIterator = QList<QVariant>::const_iterator, _Distance = int]«
/usr/local/Qt-5.3.2/include/QtCore/qmetatype.h:799:9: instanziiert von »static void QtMetaTypePrivate::IteratorOwner<const_iterator>::advance(void**, int) [with const_iterator = QList<QVariant>::const_iterator]«
/usr/local/Qt-5.3.2/include/QtCore/qmetatype.h:969:68: instanziiert von »QtMetaTypePrivate::QSequentialIterableImpl::QSequentialIterableImpl(const T*) [with T = QList<QVariant>]«
/usr/local/Qt-5.3.2/include/QtCore/qvariant.h:711:139: instanziiert von hier
/usr/include/c++/4.6/bits/boost_concept_check.h:535:24: Fehler: keine Übereinstimmung für »operator+« in »((__gnu_cxx::_RandomAccessIteratorConcept<QList<QVariant>::const_iterator>*)this)->__gnu_cxx::_RandomAccessIteratorConcept<QList<QVariant>::const_iterator>::__n + ((__gnu_cxx::_RandomAccessIteratorConcept<QList<QVariant>::const_iterator>*)this)->__gnu_cxx::_RandomAccessIteratorConcept<QList<QVariant>::const_iterator>::__i«
/usr/include/c++/4.6/bits/boost_concept_check.h:535:24: Anmerkung: Kandidaten sind:
/usr/include/c++/4.6/bits/stl_iterator.h:896:5: Anmerkung: template<class _Iterator, class _Container> __gnu_cxx::__normal_iterator<_Iterator, _Container> __gnu_cxx::operator+(typename __gnu_cxx::__normal_iterator<_Iterator, _Container>::difference_type, const __gnu_cxx::__normal_iterator<_Iterator, _Container>&)
=== snip ===

I'm lost now. Qt5 builds are compiled with -fPIC unconditionally. Is my Linux too old?

What are others doing to build LyX with Qt5 on Linux?

Stephan

[Scott Kostyshak]

On Mon, Oct 13, 2014 at 7:38 AM, Stephan Witt <***@gmx.net> wrote:

> I'm trying to verify my changes on Linux.

Thank you!

> What are others doing to build LyX with Qt5 on Linux?

You can see my build script here:

https://github.com/scottkosty/lyx-tester/blob/master/lyxbuild

If you want, you can have a completely automatic installation of
dependencies and building of LyX starting from a fresh Ubuntu
installation with one command:
https://github.com/scottkosty/lyx-tester
I only recommend that on a virtual box though. It has not been tested
except for me (although I use it regularly).
Note that the script will also run all the ctests, which takes a long
time (I can disable this for you if you want though). Thus, if you do
try this, you might want to leave it overnight.

I'd be happy to add support into the script of building Qt from source
if that would help.

I've been using 14.04 since it came out. I don't know if there's
anything that requires it, but let me know if you have problems and
I'll take a look.

Best,

Scott

[Rainer M Krug]

Let me chime in here as a non-lyx-programmer, but lyx user on a mac.

I am sure there is a lot of interest among mac users for this patch. I
also understand that it is not yet in a usable state, but when it is,
would it be possible to make an unofficial dmg for mac users, so that
this can be tested widely? As I understand, not many active developers
of lyx are mac users, so a dmg would enable a much wider audience to
test this. If it is only available as source, I don't thnik many mac
users would compile it, unless it is put on homebrew...

Cheers, and I am really looking forward to lyx on retina,

Rainer


Scott Kostyshak <***@lyx.org> writes:

> On Mon, Oct 13, 2014 at 7:38 AM, Stephan Witt <***@gmx.net> wrote:
>
>> I'm trying to verify my changes on Linux.
>
> Thank you!
>
>> What are others doing to build LyX with Qt5 on Linux?
>
> You can see my build script here:
>
> https://github.com/scottkosty/lyx-tester/blob/master/lyxbuild
>
> If you want, you can have a completely automatic installation of
> dependencies and building of LyX starting from a fresh Ubuntu
> installation with one command:
> https://github.com/scottkosty/lyx-tester
> I only recommend that on a virtual box though. It has not been tested
> except for me (although I use it regularly).
> Note that the script will also run all the ctests, which takes a long
> time (I can disable this for you if you want though). Thus, if you do
> try this, you might want to leave it overnight.
>
> I'd be happy to add support into the script of building Qt from source
> if that would help.
>
> I've been using 14.04 since it came out. I don't know if there's
> anything that requires it, but let me know if you have problems and
> I'll take a look.
>
> Best,
>
> Scott
>

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[Stephan Witt]

Am 14.10.2014 um 09:15 schrieb Rainer M Krug <***@krugs.de>:

> Let me chime in here as a non-lyx-programmer, but lyx user on a mac.
>
> I am sure there is a lot of interest among mac users for this patch. I
> also understand that it is not yet in a usable state, but when it is,
> would it be possible to make an unofficial dmg for mac users, so that
> this can be tested widely? As I understand, not many active developers
> of lyx are mac users, so a dmg would enable a much wider audience to
> test this. If it is only available as source, I don't thnik many mac
> users would compile it, unless it is put on homebrew…

Hi Rainer,

you're right. I thought I'll provide an unofficial disk image with retina
support until the release of a final retina ready version is done.
That was my plan already, but...

This feature requires Qt5 and LyX gets Qt5-support with 2.2.0. That's a
problem. Finally it's not only the question if retina-support is ready -
that's possible in reasonable time. The question is: when is it possible
to make a 2.2.0 release! Currently there isn't even a maintainer for it.

Therefore this disk image with retina support will be something like a
unofficial release - I'd guess many Mac users are tempted to try it out
and then they don't want to go back - not even for production!

> Scott Kostyshak <***@lyx.org> writes:
>
>> On Mon, Oct 13, 2014 at 7:38 AM, Stephan Witt <***@gmx.net> wrote:
>>
>>> I'm trying to verify my changes on Linux.
>>
>> Thank you!
>>
>>> What are others doing to build LyX with Qt5 on Linux?
>>
>> You can see my build script here:

Thank you for the pointers.

>>
>> https://github.com/scottkosty/lyx-tester/blob/master/lyxbuild
>>
>> If you want, you can have a completely automatic installation of
>> dependencies and building of LyX starting from a fresh Ubuntu
>> installation with one command:
>> https://github.com/scottkosty/lyx-tester
>> I only recommend that on a virtual box though. It has not been tested
>> except for me (although I use it regularly).
>> Note that the script will also run all the ctests, which takes a long
>> time (I can disable this for you if you want though). Thus, if you do
>> try this, you might want to leave it overnight.
>>
>> I'd be happy to add support into the script of building Qt from source
>> if that would help.
>>
>> I've been using 14.04 since it came out. I don't know if there's
>> anything that requires it, but let me know if you have problems and
>> I'll take a look.

I've updated my Ubuntu (running in a virtual machine) to 14.04 - but this
didn't solve my problem. With the Qt4 from Ubuntu it looks ok, though.

I cannot use your scripts to test my changes - they're not in git yet.
But I've studied the scripts and think I don't need the full blown TeX
environment to see the rendering of LyX file content on screen.

I cannot find a precompiled Qt5 for Ubuntu 14.04 - where should I look?

Stephan

[Kornel Benko]

Am Dienstag, 14. Oktober 2014 um 16:11:38, schrieb Stephan Witt <***@gmx.net>
>
> I cannot find a precompiled Qt5 for Ubuntu 14.04 - where should I look?
>

1.2 Cmake_test.kornel 17:02 > dpkg -l | egrep -i qt5
ii libqt5concurrent5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 concurrent module
ii libqt5core5a:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 core module
ii libqt5dbus5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 D-Bus module
ii libqt5gui5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 GUI module
ii libqt5network5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 network module
ii libqt5opengl5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 OpenGL module
ii libqt5opengl5-dev:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 OpenGL library development files
ii libqt5printsupport5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 print support module
ii libqt5sql5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 SQL module
ii libqt5sql5-sqlite:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 SQLite 3 database driver
ii libqt5test5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 test module
ii libqt5widgets5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 widgets module
ii libqt5x11extras5:amd64 5.2.1-1 amd64 Qt 5 X11 extras
ii libqt5x11extras5-dev 5.2.1-1 amd64 Qt 5 X11 extras development files
ii libqt5xml5:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 XML module
ii qt5-qmake:amd64 5.2.1+dfsg-1ubuntu14.2 amd64 Qt 5 qmake Makefile generator tool
1

Kornel

[Rainer M Krug]

Stephan Witt <***@gmx.net> writes:

> Am 14.10.2014 um 09:15 schrieb Rainer M Krug <***@krugs.de>:
>
>> Let me chime in here as a non-lyx-programmer, but lyx user on a mac.
>>
>> I am sure there is a lot of interest among mac users for this patch. I
>> also understand that it is not yet in a usable state, but when it is,
>> would it be possible to make an unofficial dmg for mac users, so that
>> this can be tested widely? As I understand, not many active developers
>> of lyx are mac users, so a dmg would enable a much wider audience to
>> test this. If it is only available as source, I don't thnik many mac
>> users would compile it, unless it is put on homebrew

>
> Hi Rainer,
>
> you're right. I thought I'll provide an unofficial disk image with retina
> support until the release of a final retina ready version is done.

Great - sounds good.

> That was my plan already, but...

There is always a *big but* in the end ...

>
> This feature requires Qt5 and LyX gets Qt5-support with 2.2.0. That's a
> problem. Finally it's not only the question if retina-support is ready -
> that's possible in reasonable time. The question is: when is it possible
> to make a 2.2.0 release! Currently there isn't even a maintainer for it.
>
> Therefore this disk image with retina support will be something like a
> unofficial release - I'd guess many Mac users are tempted to try it out
> and then they don't want to go back - not even for production!

This might be risky. To see if the retina support is ready, one option
would be to disable e.g. the save function and make it visible in the
running instance that it is for testing the display issues *only* and *not* for
production?

Cheers,

Rainer

>
>> Scott Kostyshak <***@lyx.org> writes:
>>
>>> On Mon, Oct 13, 2014 at 7:38 AM, Stephan Witt <***@gmx.net> wrote:
>>>
>>>> I'm trying to verify my changes on Linux.
>>>
>>> Thank you!
>>>
>>>> What are others doing to build LyX with Qt5 on Linux?
>>>
>>> You can see my build script here:
>
> Thank you for the pointers.
>
>>>
>>> https://github.com/scottkosty/lyx-tester/blob/master/lyxbuild
>>>
>>> If you want, you can have a completely automatic installation of
>>> dependencies and building of LyX starting from a fresh Ubuntu
>>> installation with one command:
>>> https://github.com/scottkosty/lyx-tester
>>> I only recommend that on a virtual box though. It has not been tested
>>> except for me (although I use it regularly).
>>> Note that the script will also run all the ctests, which takes a long
>>> time (I can disable this for you if you want though). Thus, if you do
>>> try this, you might want to leave it overnight.
>>>
>>> I'd be happy to add support into the script of building Qt from source
>>> if that would help.
>>>
>>> I've been using 14.04 since it came out. I don't know if there's
>>> anything that requires it, but let me know if you have problems and
>>> I'll take a look.
>
> I've updated my Ubuntu (running in a virtual machine) to 14.04 - but this
> didn't solve my problem. With the Qt4 from Ubuntu it looks ok, though.
>
> I cannot use your scripts to test my changes - they're not in git yet.
> But I've studied the scripts and think I don't need the full blown TeX
> environment to see the rendering of LyX file content on screen.
>
> I cannot find a precompiled Qt5 for Ubuntu 14.04 - where should I look?
>
> Stephan

--
Rainer M. Krug
email: Rainer<at>krugs<dot>de
PGP: 0x0F52F982

[Stephan Witt]

Am 15.10.2014 um 09:49 schrieb Rainer M Krug <***@krugs.de>:

> Stephan Witt <***@gmx.net> writes:
>
>> Am 14.10.2014 um 09:15 schrieb Rainer M Krug <***@krugs.de>:
>>
>>> Let me chime in here as a non-lyx-programmer, but lyx user on a mac.
>>>
>>> I am sure there is a lot of interest among mac users for this patch. I
>>> also understand that it is not yet in a usable state, but when it is,
>>> would it be possible to make an unofficial dmg for mac users, so that
>>> this can be tested widely? As I understand, not many active developers
>>> of lyx are mac users, so a dmg would enable a much wider audience to
>>> test this. If it is only available as source, I don't thnik many mac
>>> users would compile it, unless it is put on homebrew…
>>
>> Hi Rainer,
>>
>> you're right. I thought I'll provide an unofficial disk image with retina
>> support until the release of a final retina ready version is done.
>
> Great - sounds good.
>
>> That was my plan already, but...
>
> There is always a *big but* in the end ...
>
>>
>> This feature requires Qt5 and LyX gets Qt5-support with 2.2.0. That's a
>> problem. Finally it's not only the question if retina-support is ready -
>> that's possible in reasonable time. The question is: when is it possible
>> to make a 2.2.0 release! Currently there isn't even a maintainer for it.
>>
>> Therefore this disk image with retina support will be something like a
>> unofficial release - I'd guess many Mac users are tempted to try it out
>> and then they don't want to go back - not even for production!
>
> This might be risky. To see if the retina support is ready, one option
> would be to disable e.g. the save function and make it visible in the
> running instance that it is for testing the display issues *only* and *not* for
> production?

Hmm… I don't like this much.

IMO the better option is to present the feature early.

Stephan

Here is a first version for an evaluation of the feature:

https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-a09eaf44%2Bqt5-x86_64-cocoa.dmg
https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-a09eaf44%2Bqt5-x86_64-cocoa.dmg.sig

[Edwin Leuven]

On Oct 18, 2014, at 17:32 , Stephan Witt <***@gmx.net> wrote:
> Here is a first version for an evaluation of the feature:
>
> https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-a09eaf44%2Bqt5-x86_64-cocoa.dmg <https://dl.dropboxusercontent.com/u/27842660/LyX-2.2.0dev-a09eaf44+qt5-x86_64-cocoa.dmg>
looks great, but does not recognize my latex installation...

thanks for the effort!

edwin

[Marcus Kriele]

Stephan Witt <st.witt <at> gmx.net> writes:

>
> Here is a first version for an evaluation of the feature:
>
>
https://dl.dropboxusercontent.com/u/27842660/
LyX-2.2.0dev-a09eaf44%2Bqt5-x86_64-cocoa.dmg
>
https://dl.dropboxusercontent.com/u/27842660/
LyX-2.2.0dev-a09eaf44%2Bqt5-x86_64-cocoa.dmg.sig
>

Thanks for your great work! I just tried out your built and had the
following experience:

I opened a document pertaining to a book project and I got the following
error message for every file included in the project:

The selected document class
Book (Standard Class)
requires external files that are not available.
The document class can still be used, but the
document cannot be compiled until the following
prerequisites are installed:
book.cls
See section 3.1.2.2 (Class Availability) of the
User's Guide for more information.

I also got the following error message:

Changes will not be highlighted in LaTeX output, because neither
dvipost nor xcolor/ulem are installed.
Please install these packages or redefine \lyxadded and
\lyxdeleted in the LaTeX preamble.


Included pdf-graphics are not displayed in LyX
(Error converting to loadable format).

Nevertheless, I could edit my document and compiling the document worked
without a hitch, despite LyX complaining about book.cls.

My system is as follows:
OSX 10.10 Yosemite,
TexLive-2013

I also had installed some special layouts in my Library, and they did work
as well.

[Stephan Witt]

Am 20.10.2014 um 16:49 schrieb Marcus Kriele <***@me.com>:

> Stephan Witt <st.witt <at> gmx.net> writes:
>
>>
>> Here is a first version for an evaluation of the feature:
>>
>>
> https://dl.dropboxusercontent.com/u/27842660/
> LyX-2.2.0dev-a09eaf44%2Bqt5-x86_64-cocoa.dmg
>>
> https://dl.dropboxusercontent.com/u/27842660/
> LyX-2.2.0dev-a09eaf44%2Bqt5-x86_64-cocoa.dmg.sig
>>
>
> Thanks for your great work!

Thank you for the kudos.

Take care to use this piece of software for copies of your documents only!
In case you save your documents with this version they'll be unreadable for
the stable version LyX-2.1.x!

> I just tried out your built and had the
> following experience:
>
> I opened a document pertaining to a book project and I got the following
> error message for every file included in the project:
>
> The selected document class
> Book (Standard Class)
> requires external files that are not available.
> The document class can still be used, but the
> document cannot be compiled until the following
> prerequisites are installed:
> book.cls
> See section 3.1.2.2 (Class Availability) of the
> User's Guide for more information.
>
> I also got the following error message:
>
> Changes will not be highlighted in LaTeX output, because neither
> dvipost nor xcolor/ulem are installed.
> Please install these packages or redefine \lyxadded and
> \lyxdeleted in the LaTeX preamble.
>
>
> Included pdf-graphics are not displayed in LyX
> (Error converting to loadable format).
>
> Nevertheless, I could edit my document and compiling the document worked
> without a hitch, despite LyX complaining about book.cls.
>
> My system is as follows:
> OSX 10.10 Yosemite,
> TexLive-2013
>
> I also had installed some special layouts in my Library, and they did work
> as well.


There are some reports on the users list about LyX not finding standard classes.
AFAIK, all the users reporting this problem are Yosemite users.

There is some feedback that this is helpful:
http://tex.stackexchange.com/questions/203810/lyx-2-x-document-class-not-available-mac-os-x-10-10-yosemite-pb-3

Does this work for you?

Stephan

[Marcus Kriele]

> There are some reports on the users list about LyX not finding standard classes.
> AFAIK, all the users reporting this problem are Yosemite users.
>
> There is some feedback that this is helpful:
> http://tex.stackexchange.com/questions/203810/lyx-2-x-document-class-not-available-mac-os-x-10-10-yosemite-pb-3

Actually I do not have these problems with LyX 2.1.2. Even with Yosemite, LyX 2.1.2 fully works for me. The problems I mentioned before only appear with the new retina build. I am starting the retina version from the Desktop rather than the Application folder, but I would be surprised if this mattered. I should probably also note that I have an additional python installation (Python 2.7.6 via Anaconda 1.9.1) which is pointed to by the name “python” (set in my bash startup file).

[Scott Kostyshak]

I can't help with the specific errors you're seeing since I don't know
Qt at that technical of a level. But I can modify the lyx-tester
script to get you a LyX build that reproduces the problem. See below
for ways in which I can improve it to suit your needs. Are you using
Ubuntu in a virtual box? It makes it very easy to run something from a
fresh install of Ubuntu and you can experiment without fear.

On Tue, Oct 14, 2014 at 10:11 AM, Stephan Witt <***@gmx.net> wrote:

> I cannot use your scripts to test my changes - they're not in git yet.

I see. I just pushed a patch that allows you to put .patch files in
~/Downloads/lyxPatches that will be applied before building LyX. I can
make it more general if you'd be interested.

> But I've studied the scripts and think I don't need the full blown TeX
> environment to see the rendering of LyX file content on screen.

Indeed. I can add support for either a minimal TeX installation or no
TeX installation or system TeX installation (from apt). Let me know if
any of those options would be helpful for you.

I also added Kornel's Qt 5 building so we can test with the latest
stable release from Git. I just pushed this to the debug branch though
because I haven't tested it yet.

Scott

[Stephan Witt]

Am 20.10.2014 um 10:27 schrieb Scott Kostyshak <***@lyx.org>:

> I can't help with the specific errors you're seeing since I don't know
> Qt at that technical of a level. But I can modify the lyx-tester
> script to get you a LyX build that reproduces the problem. See below
> for ways in which I can improve it to suit your needs. Are you using
> Ubuntu in a virtual box? It makes it very easy to run something from a
> fresh install of Ubuntu and you can experiment without fear.
>
> On Tue, Oct 14, 2014 at 10:11 AM, Stephan Witt <***@gmx.net> wrote:
>
>> I cannot use your scripts to test my changes - they're not in git yet.
>
> I see. I just pushed a patch that allows you to put .patch files in
> ~/Downloads/lyxPatches that will be applied before building LyX. I can
> make it more general if you'd be interested.
>
>> But I've studied the scripts and think I don't need the full blown TeX
>> environment to see the rendering of LyX file content on screen.
>
> Indeed. I can add support for either a minimal TeX installation or no
> TeX installation or system TeX installation (from apt). Let me know if
> any of those options would be helpful for you.
>
> I also added Kornel's Qt 5 building so we can test with the latest
> stable release from Git. I just pushed this to the debug branch though
> because I haven't tested it yet.
>
> Scott

Thank you for your effort. As you saw, I solved the compile problems with
a modified configure command line. I couldn't believe it doesn't compile
out of the box with Qt5. Most of the time I want to understand the steps
I'm doing. That's why I didn't start over with a fresh install.

You may ask, why I didn't use cmake. First it was not installed and I had
to learn how package management on Ubuntu works. Later I couldn't git it
to compile LyX out-of-source. I don't understand it. I'm doing that:

$ mkdir lyx-2.2-cmake
$ cd lyx-2.2-cmake
$ cmake ../LyX-2.2-2.2.0dev
--
-- Building in-source
--
-- Using GCC version 4.8

fatal: Not a git repository (or any of the parent directories): .git
-- Found Qt-Version 4.8.6
...

Why this?

Stephan

BTW, perhaps you may add an option to choose QT4/QT5 to your lyx-build script.
ATM automake builds it with Qt4 and cmake uses Qt5.

[Scott Kostyshak]

On Tue, Oct 21, 2014 at 2:02 AM, Stephan Witt <***@gmx.net> wrote:

> Thank you for your effort. As you saw, I solved the compile problems with
> a modified configure command line. I couldn't believe it doesn't compile
> out of the box with Qt5. Most of the time I want to understand the steps
> I'm doing. That's why I didn't start over with a fresh install.

Makes sense.

> You may ask, why I didn't use cmake. First it was not installed and I had
> to learn how package management on Ubuntu works. Later I couldn't git it
> to compile LyX out-of-source. I don't understand it. I'm doing that:
>
> $ mkdir lyx-2.2-cmake
> $ cd lyx-2.2-cmake
> $ cmake ../LyX-2.2-2.2.0dev
> --
> -- Building in-source
> --
> -- Using GCC version 4.8
>
> fatal: Not a git repository (or any of the parent directories): .git
> -- Found Qt-Version 4.8.6
> ...
>
> Why this?

It is strange that it says "Building in-source". I cannot reproduce
this (I tried your same steps). Something weird is going on. For some
reason CMAKE_SOURCE_DIR is the same as CMAKE_BINARY_DIR, which should
not be the case.

> BTW, perhaps you may add an option to choose QT4/QT5 to your lyx-build script.
> ATM automake builds it with Qt4 and cmake uses Qt5.

Good idea. I should do that.

Scott

[Kornel Benko]

Am Dienstag, 21. Oktober 2014 um 02:21:11, schrieb Scott Kostyshak <***@lyx.org>
> On Tue, Oct 21, 2014 at 2:02 AM, Stephan Witt <***@gmx.net> wrote:
>
> > Thank you for your effort. As you saw, I solved the compile problems with
> > a modified configure command line. I couldn't believe it doesn't compile
> > out of the box with Qt5. Most of the time I want to understand the steps
> > I'm doing. That's why I didn't start over with a fresh install.
>
> Makes sense.
>
> > You may ask, why I didn't use cmake. First it was not installed and I had
> > to learn how package management on Ubuntu works. Later I couldn't git it
> > to compile LyX out-of-source. I don't understand it. I'm doing that:
> >
> > $ mkdir lyx-2.2-cmake
> > $ cd lyx-2.2-cmake
> > $ cmake ../LyX-2.2-2.2.0dev
> > --
> > -- Building in-source
> > --
> > -- Using GCC version 4.8
> >
> > fatal: Not a git repository (or any of the parent directories): .git
> > -- Found Qt-Version 4.8.6
> > ...
> >
> > Why this?
>
> It is strange that it says "Building in-source". I cannot reproduce
> this (I tried your same steps). Something weird is going on. For some
> reason CMAKE_SOURCE_DIR is the same as CMAKE_BINARY_DIR, which should
> not be the case.

It may be a leftover from previous cmake call inside source.

Please check the TOP source dir for files and directories not belonging to git like
CMakeCache.txt
*.cmake # except INSTALL.cmake
CMakeFiles/

> > BTW, perhaps you may add an option to choose QT4/QT5 to your lyx-build script.
> > ATM automake builds it with Qt4 and cmake uses Qt5.
>
> Good idea. I should do that.
>
> Scott

Kornel

[Stephan Witt]

Am 21.10.2014 um 11:01 schrieb Kornel Benko <***@lyx.org>:

> Am Dienstag, 21. Oktober 2014 um 02:21:11, schrieb Scott Kostyshak <***@lyx.org>
>> On Tue, Oct 21, 2014 at 2:02 AM, Stephan Witt <***@gmx.net> wrote:
>>
>>> Thank you for your effort. As you saw, I solved the compile problems with
>>> a modified configure command line. I couldn't believe it doesn't compile
>>> out of the box with Qt5. Most of the time I want to understand the steps
>>> I'm doing. That's why I didn't start over with a fresh install.
>>
>> Makes sense.
>>
>>> You may ask, why I didn't use cmake. First it was not installed and I had
>>> to learn how package management on Ubuntu works. Later I couldn't git it
>>> to compile LyX out-of-source. I don't understand it. I'm doing that:
>>>
>>> $ mkdir lyx-2.2-cmake
>>> $ cd lyx-2.2-cmake
>>> $ cmake ../LyX-2.2-2.2.0dev
>>> --
>>> -- Building in-source
>>> --
>>> -- Using GCC version 4.8
>>>
>>> fatal: Not a git repository (or any of the parent directories): .git
>>> -- Found Qt-Version 4.8.6
>>> ...
>>>
>>> Why this?
>>
>> It is strange that it says "Building in-source". I cannot reproduce
>> this (I tried your same steps). Something weird is going on. For some
>> reason CMAKE_SOURCE_DIR is the same as CMAKE_BINARY_DIR, which should
>> not be the case.
>
> It may be a leftover from previous cmake call inside source.

Yes...

> Please check the TOP source dir for files and directories not belonging to git like
> CMakeCache.txt
> *.cmake # except INSTALL.cmake
> CMakeFiles/

This was the cause for the trouble, thanks.

Stephan

[Stephan Witt]

Am 06.10.2014 um 22:05 schrieb Marcelo Galvão Póvoa <***@gmail.com>:

> On Sun, Oct 5, 2014 at 4:29 PM, Stephan Witt <***@gmx.net> wrote:
>> Am 02.10.2014 um 13:14 schrieb Stephan Witt <***@gmx.net>:
>>
>>> Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:
>>>
>>> I gave it a try to make some progress regarding the HiDPI stuff.
>>>
>>> First I've decided to split the task. I'd postpone the image scaling issues.
>>> Not only because of the dynamic nature of the preview rendering. It's a slightly
>>> more complex thing in general - we need to provide multiple image/icon sets for
>>> different pixel ratios, IMHO.
>>>
>>> My work is based on the first patch from Marcelo. I dropped the use of the global
>>> LyXRC member variable and made an alternate solution without it.
>>>
>>> See the attached patch. In principle it works. There is an issue with scrolling.
>>> The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
>>> it is drawn and the content of the region under at the left side of the main text
>>> area is a duplicate of the middle of the text area on the stop of the scroll operation.
>>> See the attached screen shot.
>>>
>>> Stephan
>>>
>>> <0003-Add-basic-qt5-HiDPI-rendering-support.patch>
>>> <Bildschirmfoto 2014-10-02 um 13.04.08.png>
>>
>> Now I have an improved patch without the scrolling issue. I'd like to commit it.
>> Are there any thoughts about it?
>>
>> Stephan
>>
>
> I tested your patch a little and I found some of the quirks I've been
> having when I worked with this:
>
> - Redrawing the cursor sometimes causes some drawing errors around
> characters. If I hold left/right arrow key to move the cursor across
> text, I get something like the attached screenshot. As I mentioned, my
> patch avoids partial viewport updates to workaround this, but it is
> not a decent solution.

Sorry, I cannot reproduce your problem. Or I do not understand it.
You're talking about text navigation with cursor up/down, right?
What's the partial viewport update you're talking about?

Stephan

> - Instant Preview of math formulas is not rendered in HiDPI. My patch
> does this but has an ugly dependency on LyxRC.

> - Dynamically changing window DPI (i.e, moving it between different
> screens) makes the text blurry. I haven't tested this much, but maybe
> it is related to some unflushed drawing cache?
>
> Marcelo
> <cursor.png>

[Marcelo Galvão Póvoa]

On Tue, Oct 7, 2014 at 4:58 AM, Stephan Witt <***@gmx.net> wrote:
> Am 06.10.2014 um 22:05 schrieb Marcelo Galvão Póvoa <***@gmail.com>:
>
>> On Sun, Oct 5, 2014 at 4:29 PM, Stephan Witt <***@gmx.net> wrote:
>>> Am 02.10.2014 um 13:14 schrieb Stephan Witt <***@gmx.net>:
>>>
>>>> Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:
>>>>
>>>> I gave it a try to make some progress regarding the HiDPI stuff.
>>>>
>>>> First I've decided to split the task. I'd postpone the image scaling issues.
>>>> Not only because of the dynamic nature of the preview rendering. It's a slightly
>>>> more complex thing in general - we need to provide multiple image/icon sets for
>>>> different pixel ratios, IMHO.
>>>>
>>>> My work is based on the first patch from Marcelo. I dropped the use of the global
>>>> LyXRC member variable and made an alternate solution without it.
>>>>
>>>> See the attached patch. In principle it works. There is an issue with scrolling.
>>>> The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
>>>> it is drawn and the content of the region under at the left side of the main text
>>>> area is a duplicate of the middle of the text area on the stop of the scroll operation.
>>>> See the attached screen shot.
>>>>
>>>> Stephan
>>>>
>>>> <0003-Add-basic-qt5-HiDPI-rendering-support.patch>
>>>> <Bildschirmfoto 2014-10-02 um 13.04.08.png>
>>>
>>> Now I have an improved patch without the scrolling issue. I'd like to commit it.
>>> Are there any thoughts about it?
>>>
>>> Stephan
>>>
>>
>> I tested your patch a little and I found some of the quirks I've been
>> having when I worked with this:
>>
>> - Redrawing the cursor sometimes causes some drawing errors around
>> characters. If I hold left/right arrow key to move the cursor across
>> text, I get something like the attached screenshot. As I mentioned, my
>> patch avoids partial viewport updates to workaround this, but it is
>> not a decent solution.
>
> Sorry, I cannot reproduce your problem. Or I do not understand it.
> You're talking about text navigation with cursor up/down, right?
> What's the partial viewport update you're talking about?
>

It mostly happens with cursor left/right. Please see this demo:

https://dl.dropboxusercontent.com/u/20456192/cursor.mov

To workaround this, my second patch essentially changes cursor drawing
behavior from partial updates to full updates, like so:

- p->viewport()->update(cursor_->rect());
+ update(0, 0, p->viewport()->width(), p->viewport()->height());

Let me know if you can reproduce this.

Marcelo

> Stephan
>
>> - Instant Preview of math formulas is not rendered in HiDPI. My patch
>> does this but has an ugly dependency on LyxRC.
>
>> - Dynamically changing window DPI (i.e, moving it between different
>> screens) makes the text blurry. I haven't tested this much, but maybe
>> it is related to some unflushed drawing cache?
>>
>> Marcelo
>> <cursor.png>
>

[Stephan Witt]

Am 07.10.2014 um 17:46 schrieb Marcelo Galvão Póvoa <***@gmail.com>:

> On Tue, Oct 7, 2014 at 4:58 AM, Stephan Witt <***@gmx.net> wrote:
>> Am 06.10.2014 um 22:05 schrieb Marcelo Galvão Póvoa <***@gmail.com>:
>>
>>> On Sun, Oct 5, 2014 at 4:29 PM, Stephan Witt <***@gmx.net> wrote:
>>>> Am 02.10.2014 um 13:14 schrieb Stephan Witt <***@gmx.net>:
>>>>
>>>>> Am 18.07.2014 um 10:39 schrieb Stephan Witt <***@gmx.net>:
>>>>>
>>>>> I gave it a try to make some progress regarding the HiDPI stuff.
>>>>>
>>>>> First I've decided to split the task. I'd postpone the image scaling issues.
>>>>> Not only because of the dynamic nature of the preview rendering. It's a slightly
>>>>> more complex thing in general - we need to provide multiple image/icon sets for
>>>>> different pixel ratios, IMHO.
>>>>>
>>>>> My work is based on the first patch from Marcelo. I dropped the use of the global
>>>>> LyXRC member variable and made an alternate solution without it.
>>>>>
>>>>> See the attached patch. In principle it works. There is an issue with scrolling.
>>>>> The vertical scroll bar on a Mac is not visible all the time. Only while scrolling
>>>>> it is drawn and the content of the region under at the left side of the main text
>>>>> area is a duplicate of the middle of the text area on the stop of the scroll operation.
>>>>> See the attached screen shot.
>>>>>
>>>>> Stephan
>>>>>
>>>>> <0003-Add-basic-qt5-HiDPI-rendering-support.patch>
>>>>> <Bildschirmfoto 2014-10-02 um 13.04.08.png>
>>>>
>>>> Now I have an improved patch without the scrolling issue. I'd like to commit it.
>>>> Are there any thoughts about it?
>>>>
>>>> Stephan
>>>>
>>>
>>> I tested your patch a little and I found some of the quirks I've been
>>> having when I worked with this:
>>>
>>> - Redrawing the cursor sometimes causes some drawing errors around
>>> characters. If I hold left/right arrow key to move the cursor across
>>> text, I get something like the attached screenshot. As I mentioned, my
>>> patch avoids partial viewport updates to workaround this, but it is
>>> not a decent solution.
>>
>> Sorry, I cannot reproduce your problem. Or I do not understand it.
>> You're talking about text navigation with cursor up/down, right?
>> What's the partial viewport update you're talking about?
>>
>
> It mostly happens with cursor left/right. Please see this demo:
>
> https://dl.dropboxusercontent.com/u/20456192/cursor.mov
>
> To workaround this, my second patch essentially changes cursor drawing
> behavior from partial updates to full updates, like so:
>
> - p->viewport()->update(cursor_->rect());
> + update(0, 0, p->viewport()->width(), p->viewport()->height());
>
> Let me know if you can reproduce this.


Unfortunately not. Do you have the same redrawing problem with my latest patch?

Stephan