User:Zeljan

From Lazarus wiki
Jump to navigationJump to search

This is my page ? ;) Hi I'm Zeljan Rikalo (everybody calls me Zeljko), currently developing and maintaning qt4/qt5 interfaces for lazarus. Any feedback about qt-lcl/qt5-lcl from linux,win32 or mac is welcome (patches also). All about Qt interface you can find at


NEWS (dd.MM.yyyy)

  • 30.12.2016 - Qt5 widgetset is commited into lazarus trunk. Minimum required Qt lib version is 5.6.0
  • 11.03.2016 - This one and it's relatives https://bugreports.qt.io/browse/QTBUG-21371 are problem with real form bounds on qt.Seem that minimum valid version of qt is 4.8.6 and workarounds for lower.
  • 09.03.2016 - Real form bounds works fine under all KWin versions (KDE 3,4,5), also Xfce and Gnome 2 (metacity). There are still issues with Cinnamon and Gnome Shell compositors which changes titlebar height in dependency of window kind (normal window, window with min/max constraints, modal window).MSWindows part is fixed today and works like a charm.
  • 08.03.2016 - See Real Form bounds under X11 below. It already works, still adressing some problems with some compositing window managers.
  • 06.03.2016 - Started implementation of real form bounds under Qt x11. Related to the issue http://bugs.freepascal.org/view.php?id=20952
  • 13.05.2014 - Unfortunately printing does not work (crashes) under 64bit MacOSX due to qt bug https://bugreports.qt-project.org/browse/QTBUG-21576
  • 04.05.2014 - Added QTCOCOA define, lazarus now works under 64bit macosx with qt libs - tested on 10.6.8 intel mac with Qt-4.8.6 libs.All you have to do is download Qt-4.8.6 binary libs, install it and rebuild libQt4Pas bindings against it (64bit).Building lazarus from terminal (used fpc-2.6.2): make bigide CPU_TARGET=x86_64 OS_TARGET=darwin LCL_PLATFORM=qt, when rebuilding from ide you should add -Px86_64 -Tdarwin in ide build config dialog.For some unknown reason to me yet (possible Makefile or fpmake bug) it is impossible to rebuild ide from ide just like that, so first build from terminal and later you can rebuild from ide.If you build from ide without building from terminal first, when compiling tools and linking make passes i386 as platform, so impossible to finish build or linking stage.
  • 23.06.2013 - I've commited first version of gtk3 widgetset. It happened during Lazarus developers meeting in Dubrovnik, Croatia (20-25th Jun 2013).
  • 02.06.2013 - still working on advanced skeleton for gtk3 widgetset (advanced skeleton = most TWinControl components will be useable with first alpha commit).Because of really ugly gtk3 bugs minimum requirements will be: gtk3-3.6.4 and glib2-2.34. Currently I'm working with gtk3-3.4 but there are really ugly bugs like this one https://bugzilla.gnome.org/show_bug.cgi?id=690099.
  • 18.12.2011 - finnaly built qt 64bit (cocoa) lazarus on MacOSX, detailed explanation is here http://wiki.lazarus.freepascal.org/Qt_Interface_Mac
  • 05.11.2011 - MDI support is added to laz trunk ... qt mdi is fully implemented.
  • 21.11.2010 there are known problems with qt-4.7.XX (lazarus and qt based apps crashes).Seem that our bindings need -mstackrealign.
  • 29.09.2009 as of lazarus r 21913 qt-4.5.XX is default , minimum bindings version is 1.72. No more USE_QT_XX defines
  • 18.09.2008 Trolltech released qt-4.4.2. Changes: http://trolltech.com/developer/notes/changes/changes-4.4.2/ 
Fixed many bugs & regressions.
  • 31.08.2008 I'm testing 4.4.X for about two weeks (4.4.2 snapshots currently - 4.4.1 have some nasty bugs).
It looks much better than 4.3.XX - no flickering, faster, fixed some ugly QPainter bugs, fixed event queue bug 
(now I reverted QEventFocusIn & QEventFocusOut into my local svn copy (svn r. 14361)). 
Lazarus IDE feels much better with 4.4.X than with 4.3.X.
There's no special changes for 4.4, only r.14361 is out of game.

Fixes for QCoreApplication events, QComboBox crash fixed ...

QPainter supports justified text in overloaded QPainter::drawText() 
Fixes for QMainWindow, QMdiArea, QMdiSubWindow.
Fixes QPixmap bug with scaling & shifting by half a pixel.
Fixes for QFileDialog, QListView, QTreeView etc ....
Looks like a nice update.

My TODO list

  • Try to write an MDI "emulator" at LCL site based on TScrollView and TForm (mdiChild is real form embedded into TScrollView and custom painted title bar).With this emulator we'll get mdi support for all ws.

Current status: Trivial MDI Emulator works fine on all widgetsets I can test: gtk2, carbon, win32, qt.

Working features:

  • MDI viewport (TScrollBox)
  • MDI window.
  • Minimize, Restore, Maximize, Move works.
  • Tab order inside each MDI window belongs to itself.
  • Reordering of minimized MDI children when minimized MDI child is closed.

Missing features to implement:

  • resizing of MDI window by mouse (in progress).
  • when many MDI's minimized, and one of them restored, maximized or closed, reorder other minimized mdi's (in progress).
  • cascade, tile ops.
  • add missing code to TCustomForm (mainly reparent to MDI viewport when form created) and to interfaces.
  • implement win32 native MDI's

Later:

  • add MDI menu (when MDI window maximized).
  • fix bugs ? ;)

Screenshoots:


KNOWN BUGS IN QT-4.5.3 - (visible in LCLQt)

  1. Plastique,Cleanlooks style - combobox, checkbox doesn't show focus rect when focused by pressing ENTER and SelectNext(ActiveControl, True, True) from another control (TAB KEY WORKS OK) - have patch for Qt. fixed as of qt-4.6.0
  2. WindowsXP style - checkbox doesn't show focus rect for same reason as Plastique checkbox. - have patch for Qt.
  3. QStatusBar - size grip & last item isn't visible (if we have few items) if our main window started as wsMaximized. Issue submitted to Qt http://bugreports.qt.nokia.com/browse/QTBUG-4334 fixed with qt >= 4.6.2.

TODO FOR NEXT QT BINDINGS RELEASE - BASED ON MINIMUM Qt-4.6 (reminder for Den Jean)

  • Add next classes: QDesktopServices (Felipe asked), QTextBlock, QTextBlockFormat, QTextFormat, QTextLayout, QTextLine, QShortcut, QGesture, QGestureEvent, QGestureRecognizer, QPanGesture, QPinchGesture, QTapAndHoldGesture, QTapGesture, QSwipeGesture, QTouchEvent, QStylePainter (have some convinience functions for styled painting, also QStylePainter is initialized from widget).
  • Maybe add OpenGL (QGLxxxx classes), but only if it can be separated in different unit and different C bindings, so loaded only on demand (for lazarus TOpenGLControl). See http://bugs.freepascal.org/view.php?id=15589 .
  • Maemo bindings - support for Maemo platform.
  • QGraphics*** - check what's missing for complete painting and use of QGraphicsItems.


Painting of qt controls with HasPaint=FALSE inside qtlcl

  • procedure SlotPaint() should be function SlotPaint() with Result from paint message eg. Result := Msg.Result <> 0;

That says that qt will not paint that control (event filter resulted with True result).This works as expected, but not sure about impact on qt or bindings when setting result to true in such way - must test it.

  • This is example of overrided TQtLineEdit.EventFilter.Don't forget to change SlotPaint() into function

and add Result := Msg.Result <> 0; after you process paint event. 

function TQtLineEdit.EventFilter(Sender: QObjectH; Event: QEventH): Boolean; cdecl;
begin
  Result := False;
  if LCLObject = nil then
    exit;
  // TQtLineEdit have HasPaint := False, so only qt draws it
  // but we can do whatever here
  if (QEvent_type(Event) = QEventPaint) then
  begin
    BeginEventProcessing;
    // eg. this makes default qt paint of our control
    // after this call we can do something more inside our SlotPaint
    // and set result to true.
    // As a result we have native control on screen with eg.small red triangle in
    // controls corner which we painted after control was painted by qt.
    // If we don't set Result to true in this case, our control will be
    // repainted by qt again ,and we wan't see small red triangle in corner
    // of our control.
    // if SomeFlagOnOurControl then
    // begin
    //   QObject_event(Widget, Event);
    //   SlotPaint(Sender, Event)
    //   Result := True;
    // end else
    // begin
    // In this case: if result of SlotPaint is false - qt draws control, otherwise
    // we already done that.
    Result := SlotPaint(Sender, Event);
    QEvent_setAccepted(Event, not Result);
    EndEventProcessing;
    // end
  end else
    Result:=inherited EventFilter(Sender, Event);
end;

Real form bounds under X11

  • Goal is to reach full delphi compatibility with TCustomForm Width/Height = full width of form including decoration frame and title, ClientWidth/ClientHeight (ClientRect) which is available as container for child controls and painting.Qt's QWidget::width() & QWidget::height() is

size of widget without any decorations on all platforms. QWidget::frameSize() is size of decorated window.

  • Currently there's problem with X11 since window is decorated at any time after showing. Basically, it use to be so at first paint event.At this page you can find pretty nice explanation of what happens under X11 http://doc.qt.io/qt-4.8/application-windows.html#window-geometry
  • Another problem comes from compositing window managers. KWin is pretty fair about specs, but eg Cinnamon/Gnome3 compositor makes a lot of troubles even without X11 problems. eg. calling _NET_FRAME_EXTENTS returns frame of window, for example 2,25,2,2, but compositor adds extra pixels as shadow around window so our real Width & Height isn't accurate at all.
  • For testing current implementation under Qt x11 you must enable define QtUseAccurateFrame. Workaround for X11 is based on TQtWidgetSet.WSFrameMargins inside qtint.pp. As soon as it's called it creates dummy window and waits until it's mapped and realized and there we take frame margins. Each TQtMainWindow fills it's FrameMargins TRect property when handle is created, unless it's undecorated (BorderStyle = bsNone or it's splash screen).

Testing needs lazarus trunk r >= 51853 and -dQtUseAccurateFrame.

Status

  • Now we have 100% accurate sizes on all tested wm's without compositing enabled (tested kwin,metacity,cinnamon,xfce,openbox and blackbox).Blackbox is pretty buggy, since it does not respond on _NET_REQUEST_FRAME_EXTENTS, and gives 0,0,0,0 on _NET_FRAME_EXTENTS, so we wait until Qt's getFrameSize<>getSize.Besides that some wm's responds to _NET_FRAME_EXTENTS with valid results, but actual title bar size is taken from GetX11WindowGeometry (Gnome Shell). All of such combinations must be taken into account so our getFrameGeometry musth return valid position and real size of form at any time.
  • Compositing works ok, but with bugs since additional shadow is applied at first paint or when form is activated. KWin provides _KDE_NET_WM_SHADOW, so we can easy get extra size, but cinnamon's compositor provide exactly nothing (at least on Fedora 23 / March,2016), so there's no way to get decoration size for widget until it's shown and painted/activated for the first time.
  • Yet another problem is that querying XWindow handle for position, by calling XTranslateCoordinates() does not return real x/y when such shadow is applied.
  • Using XGetWindowAttributes() gives shadow size (at least on Cinnamon and Gnome 3 compositing wm). Shadow size is in x,y of TXWindowAttributes structure.This statement is still under investigation, especially for gnome shell. Seem that Qt is pretty buggy here since it takes _NET_FRAME_EXTENTS eg. 3,27,3,3 , but Gnome Shell uses XGetWindowGeometry which says that x,y are 10,35 , so we have offset of x=7,y=8 in this case which isn't taken into account by Qt.
  • TODO: Wayland support
  • Qt < 4.8 bug with frameSize when win is maximized and then restored. Size is ok but frameSize returns maximized sizes
Retrieved from "https://wiki.freepascal.org/index.php?title=User:Zeljan&oldid=151765"