Running a Lazarus/LCL program on a secondary screen lazarus / 32-Linux ---------------------------------------------------------------------- MarkMLl · 2022-03-18 14:22 This bit is not strictly a Lazarus or FPC problem, but it might be that discussion here benefits somebody in the future. As a low-priority project, I'd like to run a program on a secondary screen attached to the VGA output of an ATI/AMD graphics card while the main desktop is attached to HDMI or DVI. OS is Debian Linux with KDE as the desktop environment. I believe that X11 is handling both screens using DISPLAY=:0, I don't know any way of enumerating subdevices but I note that X11's log file correctly identifies what devices are attached at startup. I can get KDE's System Settings -> Displays to position the lower resolution screen above, below or either side of the higher-resolution one or to (partially) overlay it, I've not yet investigated whether the LCL can see those as separate monitors with accessible size etc. I think that's usable, but can anybody with recent X11 hacking experience comment on whether it's still possible to have completely separate screens i.e. that aren't susceptible to having windows dragged elsewhere unexpectedly? I've tinkered with an explicit xorg.conf file created using  X -configure  which is something I've found useful in the past, but any attempt at that these days appears to have the effect of stopping X11 from starting (VT stuck at a text message, other VTs still operational). MarkMLl ---------------------------------------------------------------------- MarkMLl · 2022-03-24 11:17 If the desktop environment (in this case KDE) tiles multiple monitors, I can move a form around under program control: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i // This is experimental code to investigate form placement relative to multiple// tiled monitors.   case key and $ff of    $25: WDTestForm.Left := WDTestForm.Left - 256;    $27: WDTestForm.Left := WDTestForm.Left + 256  otherwise  end;  Write('Monitor: ', Screen.MonitorFromWindow(WDTestForm.Handle).MonitorNum, ', ');  Write('Left: ', WDTestForm.Left);  WriteLn;  If I want to place a form onto a particular monitor under program control (e.g. because it has found instructions regarding what device it's to appear on in a .ini file), is the correct way of doing it by looking through the monitor list and then setting the form's top, left etc. properties, or is there a more concise approved way? MarkMLl ---------------------------------------------------------------------- AlexTP · 2022-03-24 12:37 AFAIK it is the only way in LCL - reading Screen.Monitors and setting the window position like you need. In TForm.OnResize you cannot react to position change - I don't know how to get the event 'window moved'. ---------------------------------------------------------------------- AlexTP · 2022-03-24 12:45 TForm.OnChangeBounds must be handled to avoid moving to another monitor. ---------------------------------------------------------------------- MarkMLl · 2022-03-24 12:46 Thanks for that, position will be unchanging since this is a kiosk/embedded style application. Can anybody comment on whether TScreen.Upda]"]>Blockednitors has to be called if (the app believes) something's been moved (i.e. a "panic button" to reconfigure the GUI) or if this is done automatically? MarkMLl ---------------------------------------------------------------------- AlexTP · 2022-03-24 12:51 BTW I see problems with _restricting_ of window pos inside OnChangeBounds. - dragging of window still moves it! - after some seconds, app quits! and loses window shadow! first - shadow, then quits.. Ubuntu 20.x. ---------------------------------------------------------------------- MarkMLl · 2022-03-24 13:03 Hmm. The hack that somebody suggested in the thread at https://forum.l azarus.freepascal.org/index.php/topic,58738.msg437694.html#msg437694 (hook form-level) events) would work for stuff inside the window outline, but not (with the unix-style programming model) for interaction with the window manager which AIUI is what moves or resizes a window. OTOH I think I've seen previous discussion of removing the title bar from a window, which would definitely be applicable in this case. MarkMLl ---------------------------------------------------------------------- AlexTP · 2022-03-24 16:17 But not for Linux where I can use Alt+drag the window area... ---------------------------------------------------------------------- Thaddy · 2022-03-24 16:22 Quote from: AlexTP on March 24, 2022, 05:17:43 pmBut not for Linux where I can use Alt+drag the window area... Implement it? ---------------------------------------------------------------------- MarkMLl · 2022-03-24 17:50 Quote from: Thaddy on March 24, 2022, 05:22:13 pmQuote from: AlexTP on March 24, 2022, 05:17:43 pmBut not for Linux where I can use Alt+drag the window area... Implement it? It's not going to be /Linux/ as such but probably the window manager (AKA desktop environment), so even if it can't be intercepted in the app I'd expect settings somewhere that controlled it. In extremis I could disable that combination globally using mxk which hooks the kernel's (input) event API. Slightly later: KDE has a per-app "Ignore global shortcuts" setting, which I think confirms that this is a window manager thing. MarkMLl ---------------------------------------------------------------------- MarkMLl · 2022-03-31 15:30 Quote from: MarkMLl on March 24, 2022, 02:03:50 pmOTOH I think I've seen previous discussion of removing the title bar from a window, which would definitely be applicable in this case. Changing a main form's border style from bsSizeable to bsNone tidily removes the "furniture" if the widget set is Qt5, but hides the entire window in the case of gtk2. I attach the program in case somebody who knows what zhe's doing feels like playing with it. Needs to be started from a shell session since it has a simple text-based UI, z toggles the title bar etc. Debian x86_64 Linux with KDE as desktop, Lazarus 2.2.0, FPC 3.2.2. MarkMLl