1. Rui
  2. vim-qt
  3. Issues
Issue #56 new

Port vim-Qt to Qt5

repo owner created an issue

Qt5 is around the corner, and an Alpha was released last week. Some quick testing in building vim-Qt against Qt5 succeeded with minor hickups.

In a nutshell:

Added the Qt "widgets" module in configure.in

Replace some #includes from <QtGui> to <QtWidgets>

There were some minor issues involving compiler flags, where I had to forcefully pass "-fPIE", this might actually be a bug in our current Qt detection code in autoconf.

No widget styling was applied, but this is probably normal, I assume Qt5 was not using my system style settings.

Keyboard input was slightly broken - some keys did work ("ç", C-t)

Comments (7)

  1. Rui reporter

    Merged Qt5 fixes into the master branch in 9f9f73b. The input issue is still there, but we can now build against Qt5 using --with-qt-qmake=..qmake-qt5

  2. Peter Mattern

    If e1ebbe8 gets compiled against Qt 5.5.0 and launched as qvim :version isn't displaying the usual information but just line "Press ENTER or ..." .
    No problem if the same binary gets launched as vim or if the same commit gets compiled against Qt 4.8.7, no matter which way it is launched.

    All findings on Arch Linux x86_64.

  3. Harry Summer

    Hi, Peter Mattern. I got exactly the same problem as yours. Besides this, it would also have rendering problem when scrolling the buffer with C-E/C-Y, or WheelUp/WheelDown. After digging for a while, I got the solution below:

    --- a/src/qt/qvimshell.cpp
    +++ b/src/qt/qvimshell.cpp
    @@ -401,7 +401,10 @@ void QVimShell::paintEvent ( QPaintEvent *ev )
    +                       this->setAttribute(Qt::WA_OpaquePaintEvent);
    +                       this->setAttribute(Qt::WA_WState_InPaintEvent, false);
                            this->scroll(op.pos.x(), op.pos.y(), op.rect);
    +                       this->setAttribute(Qt::WA_WState_InPaintEvent);
  4. Rui reporter

    Peter Mattern yup I see it too.

    Harry Summer confirmed it works. We don't really need the first setAttribute though since its already set. WA_WState_InPaintEvent seems to be internal to Qt, and I cant a find any docs about it, any idea how safe this is?

  5. Harry Summer

    Rui Yes. I find out later that WA_OpaquePaintEvent has already been set in QVimShell::QVimShell. It's unnecessary. For WA_WState_InPaintEvent, I agree that it's indeed an internal attribute which should be avoided using and may change in future version of Qt. However, to achieve both scrolling the content and repainting exposed background using synchronous method, the only solution I can think of is dumping the canvas into a QPixmap, editing and painting back. This seems to be too much overhead. For the safety consideration, I have not idea though. I guess only the main thread uses that attribute, and it should not have side effect when the main thread is processing painting event.

    Peter Mattern Yeah. I mean it.

  6. Log in to comment