Building flwm against fltk-1.4

[gutmensch tinycorelinux]

I'm trying to build flwm against fltk-1.4.1, but the build fails with:

```

Rotated.C: In function 'void setrotfont(int)':
Rotated.C:364:31: error: 'fl_X_core_font' was not declared in this scope
  364 |     if ((font->xfontstruct == fl_X_core_font()) && (font->dir == dir)) return;
      |                               ^~~~~~~~~~~~~~
Rotated.C:367:35: error: 'fl_X_core_font' was not declared in this scope
  367 |   font = XRotLoadFont(fl_display, fl_X_core_font(), dir);
      |                                   ^~~~~~~~~~~~~~

```

Does anybody know how to fix this?

Using flwm from here: https://github.com/tinycorelinux/flwm

The same error occurred when building against fltk-1.3.3, but was fixed by this patch in fltk-1.3.4 http://www.tinycorelinux.net/7.x/x86/tcz/src/fltk/fl_x_core_font.patch

[imm]

It's not clear to me, from what you've said, whether you have the patch for 1.3.4 applied to your 1.4 build of flwm or not.

FWIW, the patch looks sensible to me, so I think you would need it.

That said, even 1.3.4 is pretty old, so there's quite a gap from there to 1.4.

We've done our best to preserve the fltk API intact, but flwm is a difficult case because it does make use of some tricky internal parts... Making a window manager isn't quite the same task as making a X11 app. in the end.

Is your flwm patched? 

I'm assuming the issue is the font rotation code for the sidebars which - if I recall correctly - renders the labels into a buffer then flips that for rendering? (I may be wrong, miss remembering here... It's a long time since I looked at the code.)

If so, might be worth digging around in there to see if it's dependent on any "legacy features" that aren't exposed in the fltk API now - we did clean up a lot of internals that were exposed that should not have been and a WM might conceivably be making use of that...!

As a last resort, at some point in the past I had a port of flwm to nano-X that just rendered the sidebar labels with a column of (not rotated) text, and that "worked" so might do as a fallback...

--
Ian
From my Fairphone FP3
 

[gutmensch tinycorelinux]

Sorry for the confusion.

The patch appears in fltk up until fltk-1.3.11.

flwm builds without problem against fltk-1.3.11.

The patch will not apply to fltk-1.4.1 as the structure has changed, for example, FL/x.H is depreciated.

I'm assuming that as flwm only wants to use the x11 part of the fltk-1.4.1 x11/wayland libs there must be a higher level call to do this?

[Manolo]

The attached patch should apply to FLTK 1.4.x and restore access to function fl_X_core_font().

[Albrecht Schlosser]

On 2/12/25 11:27 gutmensch tinycorelinux wrote:

The patch appears in fltk up until fltk-1.3.11.

flwm builds without problem against fltk-1.3.11.

OK, but we should make clear that this is talking about the flwm sources included in TinyCore.

According to your email I assume you're a TinyCore developer, is this correct? If yes, then the following info is for you.

I'd like to add some background info and suggestions. flwm was obviously written by Bill Spitzak in the early days of FLTK, i.e. very likely for FLTK 1.0 or 1.1.

The patch will not apply to fltk-1.4.1 as the structure has changed, for example, FL/x.H is depreciated.

The latter shouldn't be a problem. You can replace 'x.H' with 'platform.H' (as documented) which should work with all FLTK versions since FLTK 1.3.5. We are keeping 'FL/x.H' in 1.4.x for backwards compatibility but it will be removed in a later version (1.5.0 or 1.6.0, whatever the future version numbers will be, maybe 4.0).

BTW, you mentioned a patch in an earlier post. I investigated branch-1.3 and I believe there's no patch necessary in FLTK 1.3 (current versions). The function 'fl_X_core_font()' seems to exist up to 1.3.11 and also seems to be "exported" which the linked patch seems to fix. Maybe the patch in TinyCore was only for 1.3.4 and fixed something that was added to FLTK 1.3.5 or a later version, but I could be wrong. I won't verify this, it's moot, and it doesn't help anyway, just FYI.

I'm assuming that as flwm only wants to use the x11 part of the fltk-1.4.1 x11/wayland libs there must be a higher level call to do this?

Well, probably yes. See the following text for details.

The method `fl_X_core_font()` has obviously been removed in FLTK 1.4. AFAICT it accessed an internal structure which is now hidden. Manolo's patch would "export" the accessor to this hidden struct again. If this works for you it could be a temporary step to make flwm work with FLTK 1.4.

If this is needed to draw the text of the window labels rotated by 90° (as it is done in flwm by default and IIRC in TinyCore), then there would indeed be a higher level method to achieve this. FLTK supports drawing "rotated text" since FLTK 1.3.0 (released in June 2011). This could probably be used in this case, see 'test/rotated_text.cxx' [1][2].

Using FLTK's rotated text feature in the label drawing procedure would likely need very little more effort but could supposedly simplify the code in flwm and would be future-proof w/o having to patch FLTK in newer versions.

Hence my suggestion would be to implement rotated text drawing in flwm to get rid of an unnecessary patch.

That said, please note that I can't investigate the required code changed in flwm and didn't look at the existing code at all (sorry, lack of time). I hope these infos may help to improve (and simplify the build of) TinyCore Linux.

[1] https://github.com/fltk/fltk/blob/81a5736006d64d749f9694268dd180ae80ec3d9d/test/rotated_text.cxx#L65
[2] https://www.fltk.org/doc-1.4/group__fl__drawings.html#ga99532fa855df077cc7b9413c99ab59fe

[gutmensch tinycorelinux]

I applied the attached patch to restore access to function fl_X_core_font() to fltk-1.4.1, rebuilt it and built flwm against the re-built fltk-1.4.1, but it fails with:

```

Building flwm...
/usr/local/bin/ld: /tmp/ccueWJcu.ltrans0.ltrans.o: in function `draw_rotated(char const*, int, int, int, int)':
<artificial>:(.text._Z12draw_rotatedPKciiii+0x79): undefined reference to `fl_X_core_font()'
/usr/local/bin/ld: <artificial>:(.text._Z12draw_rotatedPKciiii+0xd2): undefined reference to `fl_X_core_font()'

```

Note that I am speaking of the flwm source from here: http://git.tinycorelinux.net/flwm and yes, I am one of the tinycorelinux development team, but I am not familiar with c++ coding.

Thanks for the feedback on rotated text.

[gutmensch tinycorelinux]

Note also, I went back and checked that flwm builds cleanly without patches against fltk-1.3.11.

On Wednesday, February 12, 2025 at 2:20:14 PM UTC Albrecht-S wrote:

[Ian MacArthur]

On Thursday, 13 February 2025 at 10:54:20 UTC tces... wrote:

Note that I am speaking of the flwm source from here: http://git.tinycorelinux.net/flwm and yes, I am one of the tinycorelinux development team, but I am not familiar with c++ coding.

FWIW, that link didn't work for me, I had to use instead:

https://github.com/tinycorelinux/flwm

 

Thanks for the feedback on rotated text.

More recent versions of fltk should be able to do rotated text directly, so should not need the tricks that flwm did to render rotated labels for the sidebars...

I think flwm was written for fltk-1.0 or maybe 1.1, so things have changed a bit in the meantime!

[Ian MacArthur]

So, lunchbreak here...

I took a quick peek at the flwm sources as linked before (it's been a long time since I looked at flwm...) and this might be "trivial" to "fix" - IF tinycore has XFT support...

So all the tricky stuff is in the file Rotated.C, but TBH flwm doesn't use all of that (some is #ifdef'd out for flwm builds, for example, and not all the stuff that is in, is used) - the only exposed function that flwm actually calls directly is "draw_rotated90()", I think.

Now, IF tinycore has XFT, then most of Rotated.C can be deleted except the function "draw_rotated90()" and it can be converted into a wrapper for the "angle" version of fl_draw, e.g. 

      void fl_draw(int angle, const char *str, int x, int y);

With "angle" hard coded as 90 (or it might be 270 I suppose! Can't test right now..)

And that should most likely work, just about!

IF tinycore DOES NOT support XFT then all the XFontStruct business in Rotated.C would still be needed, and that's pretty much the bit that isn't playing nice right now.

[Ian MacArthur]

OK - didn't look closely enough the first time!

I'm guessing that tinycore DOES NOT have XFT enabled then, because looking at the file Frame.C (which seems to be the only place the rotated text is needed) I see there is (in two places) code of the form:

#ifndef HAVE_XFT
      draw_rotated90(label(), 1, label_y+3, left-1, label_h-3,
       Fl_Align(FL_ALIGN_TOP|FL_ALIGN_CLIP));
#else
    fl_draw(90, label(), (left + fl_height() + 1)/2 - fl_descent(),
  label_y + +3 + fl_width(label()));
#endif

So it looks to me, if HAVE_XFT is set when flwm is compiled, then we could just leave Rotated.C out of the build entirely and it should Just Work.

Actually - that might be worth a shot anyway; it looks from the compilation script in that repo that it compiles and links ALL the flwm source files whether they are actually used or not, so that might be an issue.

It may be linking in Rotated.C even though it is not needed, and then triggering an error that could perhaps be avoided simply by not linking in Rotated.C.

So, give that a shot - just make a clean folder of the flwm source files, delete the file Rotataed.C and run that "compileit" script and see if that plays any nicer. 

If XFT is enabled in the tinycore build, then you don't need Rotated.C at all and that should be fine.

[Albrecht Schlosser]

Well, I tried to change the sources (before you posted this) and I managed to make it compile and build on my own Linux box.

Regarding XFT: on my system the (maybe slightly adjusted) build procedure finds XFT and uses it, as shown below. The question is really if TinyCore has (allows to use) XFT.
FYI, from my build log:

CPPFLAGS=-DHAVE_XFT
CXXFLAGS=-flto -fuse-linker-plugin -mtune=generic -Os -pipe -fno-exceptions -fno-rtti -I/path/to/fltk/1.3/include -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -Wall -ffunction-sections -fdata-sections -Wno-strict-aliasing
LDFLAGS=-Wl,-O1 -L/path/to/fltk/1.3/lib -lfltk_images -ljpeg -lpng -lz -lfltk -lm -lX11 -lXext -lpthread -lXinerama -lXfixes -lXcursor -lXft -lXrender -lm -lfontconfig -ldl -Wl,-gc-sections

Building flwm...
Building flwm_topside...

The log from building with 1.4 is similar, just using another "/path/to/fltk/1.4/".

I'll post my patch in another reply.

[Albrecht Schlosser]

On 2/13/25 11:25 gutmensch tinycorelinux wrote:

I applied the attached patch to restore access to function fl_X_core_font() to fltk-1.4.1, rebuilt it and built flwm against the re-built fltk-1.4.1, but it fails with:

```

Building flwm...
/usr/local/bin/ld: /tmp/ccueWJcu.ltrans0.ltrans.o: in function `draw_rotated(char const*, int, int, int, int)':
<artificial>:(.text._Z12draw_rotatedPKciiii+0x79): undefined reference to `fl_X_core_font()'
/usr/local/bin/ld: <artificial>:(.text._Z12draw_rotatedPKciiii+0xd2): undefined reference to `fl_X_core_font()'

```

Note that I am speaking of the flwm source from here: http://git.tinycorelinux.net/flwm and yes, I am one of the tinycorelinux development team, but I am not familiar with c++ coding.

Thanks for the feedback on rotated text.

Welcome.

Rather than investigating why the suggested patch with fl_X_core_font() fails I worked on an IMHO better patch which uses the native FLTK rotated text drawing. As Ian wrote in his reply the essential change is basically only one line of code although my patch is much longer and changes another line than Ian suggested.

As Ian also wrote, there is already a lot of stuff in Rotated.C that is not used by flwm which is probably left to keep the original source intact as much as possible. The question is how much the TinyCore team want do preserve this "keep everything" approach. My


That said, my mods introduce yet another conditional compilation branch rather than deleting the unused portions of the source file which would be *A LOT* !

I tested my patch with FLTK 1.3.10 or higher (my local installation) and FLTK 1.4.1, both build fine. Unfortunately I can't test it right now because I don't want to replace my own WM (Gnome/Wayland) with flwm.

The attached patch is pretty small, basically just defining a condition and using it to disable unneeded code to avoid compiler warnings (unused functions).

The essential part of the patch is this:

#if (FLTK_ROTATED_TEXT)

void draw_rotated(const char* text, int x, int y, int angle) {

if (!text || !*text) return;

fl_draw(angle, text, strlen(text), x, y);

}

#elif !defined(FLWM) || FL_MAJOR_VERSION>=2

void draw_rotated(const char* text, int x, int y, int angle) {

if (!text || !*text) return;

draw_rotated(text, strlen(text), x, y, angle);

}

#endif

For clarity I replaced the entire function rather than only the line that calls 'draw_rotated()'.

Note that the internal logic (untouched) also uses `FL_MAJOR_VERSION>=2` which was obviously added to build flwm with FLTK 2.0. This logic would fail in the future if we ever used a higher version number for our version, e.g. 4.0.0 or something like that...

@OP: can you please test my attached patch and report if it builds and works for you?

As a next step it would be possible that you (or anybody else) remove all the unused code which would make this version of flwm source code dependent on FLTK 1.3.0 or higher. YMMV

[gutmensch tinycorelinux]

Ah - it looks like we've been working in parallel...

I discovered that the fltk-1.4.1 autotools build does not link against libXft, but the cmake build does.

In addition when building flwm, fltk-config reports a dep on gtk3 even though there isn't one.

After sorting the above out and removing some lines from Rotate.H (see below) flwm compiles and works :)

Thanks for your posts/patches above - I'll be busy for a day or so, then I'll take a look at them.

```

--- Rotated.C.orig 2025-02-13 14:47:55.636935163 +0000
+++ Rotated.C 2025-02-13 14:48:08.296935459 +0000
@@ -353,26 +353,6 @@
 
 // the public functions use the fltk global variables for font & gc:
 
-static XRotFontStruct* font;
-
-static void setrotfont(int angle) {
-  /* make angle positive ... */
-  if (angle < 0) do angle += 360; while (angle < 0);
-  /* get nearest vertical or horizontal direction ... */
-  int dir = ((angle+45)/90)%4;
-  if (font) {
-    if ((font->xfontstruct == fl_X_core_font()) && (font->dir == dir)) return;
-    XRotUnloadFont(fl_display, font);
-  }
-  font = XRotLoadFont(fl_display, fl_X_core_font(), dir);
-}
-
-void draw_rotated(const char* text, int n, int x, int y, int angle) {
-  if (!text || !*text) return;
-  setrotfont(angle);
-  XRotDrawString(fl_display, font, fl_window, fl_gc, x, y, text, n);
-}
-
 #if !defined(FLWM) || FL_MAJOR_VERSION>=2

 void draw_rotated(const char* text, int x, int y, int angle) {
   if (!text || !*text) return;

```

[Ian MacArthur]

FWIW, If I read the sources right (in particular Frame.C)  then IF tinylinux does have XFT available then I think that flwm does not need to compile Rotated.C at all - it looks like there's conditional code already in Frame.C to do the Right Thing using the later fltk text rotation API directly.

So I really think the easy option, rather than trying to "fix" Rotated.C is simply to bin it, and then it'll Just Work.

Maybe... I haven't tried to compile anything yet!

[Albrecht Schlosser]

AFACT it depends on what you want or need. The included build script uses wildcards ('*.C') which obviously compiles "everything" to be able to use the rotated window labels. I didn't check if using Xft needs more or less of these files but my (so far unchanged) build file (`compileit`) looks like this for building 'flwm'.

echo Building flwm...

g++ -o flwm *.C $CXXFLAGS $LDFLAGS $CPPFLAGS

sstrip flwm

However, when building 'flwm_topside' Rotated.C is not needed which I changed in my local version (using only 6 of 7 C files):

echo Building flwm_topside...

g++ -o flwm_topside -DTOPSIDE \

Desktop.C Frame.C FrameWindow.C Hotkeys.C main.C Menu.C \

$CXXFLAGS $LDFLAGS $CPPFLAGS

sstrip flwm_topside

In my build Xft is used, but as you say, Ian, there may be other simplifications depending on having Xft or not ...

[imm]

On Thu, 13 Feb 2025, 17:44 'Albrecht Schlosser'  wrote:

AFACT it depends on what you want or need. The included build script uses wildcards ('*.C') which obviously compiles "everything" to be able to use the rotated window labels. I didn't check if using Xft needs more or less of these files but my (so far unchanged) build file (`compileit`) looks like this for building 'flwm'.

echo Building flwm...

g++ -o flwm *.C $CXXFLAGS $LDFLAGS $CPPFLAGS

sstrip flwm

However, when building 'flwm_topside' Rotated.C is not needed which I changed in my local version (using only 6 of 7 C files):

echo Building flwm_topside...

g++ -o flwm_topside -DTOPSIDE \

Desktop.C Frame.C FrameWindow.C Hotkeys.C main.C Menu.C \

$CXXFLAGS $LDFLAGS $CPPFLAGS

sstrip flwm_topside

In my build Xft is used, but as you say, Ian, there may be other simplifications depending on having Xft or not ...

On the basis of NOT having actually tried this, I'm pretty sure that nothing in Rotated.C is used if XFT is available at compile time.

So I really think just removing it before running the "compileit" script will work.

[Albrecht Schlosser]

You are correct, thanks for checking this. I can build both versions of flwm w/o Rotated.C if Xft is used (i.e. built into FLTK).

If I disable { Wayland, Cairo graphics, Pango, Xft } (the former three items must be disabled to disable the latter (Xft), then the build fails w/o Rotated.C -- as was to be expected.

[gutmensch tinycorelinux]

Thanks for all of the feedback - in fact flwm works with both the patched Rotated.C and with Rotated.C deleted.

There is however some strange behavior, see attached

If a window is enlarged sideways then border disappears on the new portion of the window.

If I use the mouse wheel to scroll in the left hand side of a two pane window, the right hand side scrolls as well.

[Ian MacArthur]

On Friday, 14 February 2025 at 16:36:03 UTC tces... wrote:

Thanks for all of the feedback - in fact flwm works with both the patched Rotated.C and with Rotated.C deleted.

If a window is enlarged sideways then border disappears on the new portion of the window.

If I use the mouse wheel to scroll in the left hand side of a two pane window, the right hand side scrolls as well.

So, two things: 

- For the "enlarged sideways" observation, I assume that is the portion of black (rather than grey) border seen on the foreground window (and the console window behind it)?

Since flwm is the WM, it is responsible for rendering the window borders, so this must be something to do with how flwm handles border redraws, or maybe clipping.

TBH I'm not aware that we changed anything in that area, in fltk, but a WM has to do some "odd" things to "step outside" the app domain, so there may be some bounds checking thing that is "upset" now. I don't recall how flwm actually manages the borders though, so can't say what. I have a vague recollection of how it was done, but nothing immediate occurs to me now...

- The "mouse wheel scroll" problem sounds like something to do with event delivery. 

I don't think we have changed that, though. 

The behaviour you describe sounds exactly like what happens if an app contains a widget that consumes a scroll event but then (from it's handle method) returns 0 to say that it didn't use the event. The event then propagates to the next widget, which also scrolls...

Does this app behave in this fashion when run under a different WM? Is the behaviour peculiar to flwm environment?

Can you produce a minimal compile-able, stand-alone, example that exhibits this behaviour that we can take a look at?

[gutmensch tinycorelinux]

- For the "enlarged sideways" observation, I assume that is the portion of black (rather than grey) border seen on the foreground window (and the console window behind it)

That is correct  - it only happens with x11/flwm/fltk applets and not with wayland/weston/fltk applets.

Does this app behave in this fashion when run under a different WM? Is the behaviour peculiar to flwm environment?

It behaves in the same fashion with wayland/weston

 

Can you produce a minimal compile-able, stand-alone, example that exhibits this behaviour that we can take a look at?

See https://github.com/tinycorelinux/fltk_projects - the apps fltk applet

 

[gutmensch tinycorelinux]

Just to add to the above:

The lack of window border redraw on enlargement only happens with x11/flwm and not with x11/jwm, wayand/weston or wayland/labwc

The scrolling in both LF and RH panes happens with all of the above.

[Ian MacArthur]

On Wednesday, 19 February 2025 at 15:48:43 UTC tinycorelinux  wrote:

Just to add to the above:

The lack of window border redraw on enlargement only happens with x11/flwm and not with x11/jwm, wayand/weston or wayland/labwc

OK - so that sounds like something in flwm then - it is responsible for border drawing, so there must be something it is "not doing", or "not doing correctly" that causes this.

Does it work correctly if you build flwm with fltk-1.3.11 or fltk-1.3.10 or do they also exhibit this effect?

In any case, I suspect it means *someone* will have to dive into the flwm sources and figure out how it handles border redraws... (And by *someone* I mainly mean "not me!" here...)

 

The scrolling in both LF and RH panes happens with all of the above.

So the weird scrolling happens regardless of WM?

That does sound an awful lot like a problem in the application code itself, then, as I had earlier thought it might be.

Does (did) that application exhibit this misbehaviour when linked against fltk-1.3.10? 

Or is this a new app? 

Or new misbehaviour?

[gutmensch tinycorelinux]

The lack of window border redraw on enlargement only happens with x11/flwm and not with x11/jwm, wayand/weston or wayland/labwc

OK - so that sounds like something in flwm then - it is responsible for border drawing, so there must be something it is "not doing", or "not doing correctly" that causes this.

Does it work correctly if you build flwm with fltk-1.3.11 or fltk-1.3.10 or do they also exhibit this effect?

In any case, I suspect it means *someone* will have to dive into the flwm sources and figure out how it handles border redraws... (And by *someone* I mainly mean "not me!" here...)

Things work correctly when flwm is compiled against fltk-1.3.11

 

 

The scrolling in both LF and RH panes happens with all of the above.

So the weird scrolling happens regardless of WM?

That does sound an awful lot like a problem in the application code itself, then, as I had earlier thought it might be.

Does (did) that application exhibit this misbehaviour when linked against fltk-1.3.10? 

Or is this a new app? 

Or new misbehaviour?

The problem does not occur when the app is compiled against fltk-1.3.11

 

[Manolo]

Could you, please, post here what are the settings with which the flwm app is built? 

Namely, is it built as a wayland client (I guess not).

Does it use option FLTK_GRAPHICS_CAIRO? option FLTK_USE_PANGO?

This part of the output of the cmake command used when building FLTK 1.4 would be helpful:

Use Wayland                    No (X11 is used)
All drawing uses Cairo   Yes
Use Pango                        Yes

[gutmensch tinycorelinux]

flwm is built with a simple script - see here: https://github.com/tinycorelinux/flwm/blob/master/compileit

After deleting Rotate.H, I made one change to the script:

x86_64) 

CXXFLAGS="-flto -mtune=generic -Os -pipe -fno-exceptions -fno-rtti" 

LDFLAGS="-Wl,-O1 -Wl,-T/usr/local/lib/ldscripts/elf_x86_64.xbn" 

;;

Then ./compileit

flwm is built as an x11 window manager only.

At the time flwm was written, the version of fltk used in TinyCoreLinux did not use pango or cairo (or wayland).

fltk-1.4.1 was built like this:

cmake -LAH -DCMAKE_C_FLAGS_RELEASE="-flto -mtune=generic -Os -pipe -Wl,-T/usr/local/lib/ldscripts/elf_x86_64.xbn" -DCMAKE_CXX_FLAGS_RELEASE="-flto -mtune=generic -Os -pipe -fno-exceptions -fno-rtti -Wl,-T/usr/local/lib/ldscripts/elf_x86_64.xbn" -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release -DCMAKE_VERBOSE_MAKEFILE=TRUE -DFLTK_BUILD_SHARED_LIBS=ON -DFLTK_BUILD_GL=OFF -DFLTK_BUILD_TEST=OFF -DFLTK_OPTION_PRINT_SUPPORT=OFF ../

..which gave:

-- Use Wayland Yes (can also run as X11 client)

-- All drawing uses Cairo Yes

-- Use Pango Yes

-- Fl_Cairo_Window support No

-- Use std:: No

See: http://tinycorelinux.net/16.x/x86_64/tcz/src/fltk-1.4/compile_fltk-1.4

[Manolo]

Le jeudi 20 février 2025 à 13:48:01 UTC+1, tces...@gmail.com a écrit :

fltk-1.4.1 was built like this:

cmake -LAH -DCMAKE_C_FLAGS_RELEASE="-flto -mtune=generic -Os -pipe -Wl,-T/usr/local/lib/ldscripts/elf_x86_64.xbn" -DCMAKE_CXX_FLAGS_RELEASE="-flto -mtune=generic -Os -pipe -fno-exceptions -fno-rtti -Wl,-T/usr/local/lib/ldscripts/elf_x86_64.xbn" -DCMAKE_INSTALL_PREFIX="/usr/local" -DCMAKE_BUILD_TYPE=Release -DCMAKE_VERBOSE_MAKEFILE=TRUE -DFLTK_BUILD_SHARED_LIBS=ON -DFLTK_BUILD_GL=OFF -DFLTK_BUILD_TEST=OFF -DFLTK_OPTION_PRINT_SUPPORT=OFF ../

..which gave:

-- Use Wayland Yes (can also run as X11 client)

-- All drawing uses Cairo Yes

-- Use Pango Yes

-- Fl_Cairo_Window support No

-- Use std:: No

Great. Thank you for this information.

Could you, please, add these 2 arguments 

  -DFLTK_BACKEND_WAYLAND=0   -DFLTK_GRAPHICS_CAIRO=0

to the cmake command above, and rebuild again FLTK 1.4.1 completely.

You should obtain this:

-- Use Wayland              No (X11 is used)
-- All drawing uses Cairo   No
-- Use Pango                Yes

Then, rebuild flwm with the new FLTK and report if you see a difference in the update of window borders.

 TIA

[gutmensch tinycorelinux]

I needed to use this:

-DFLTK_BUILD_GL=OFF -DFLTK_BUILD_TEST=OFF -DFLTK_OPTION_PRINT_SUPPORT=OFF -DFLTK_BACKEND_WAYLAND=OFF -DFLTK_GRAPHICS_CAIRO=OFF -DFLTK_USE_PANGO=ON

to get this:

-- Use Wayland              No (X11 is used)
-- All drawing uses Cairo   No
-- Use Pango                Yes

..but then, yes, the window borders redraw properly.

So the problem is with using cairo?

[Manolo]

Le jeudi 20 février 2025 à 15:55:35 UTC+1, tces...@gmail.com a écrit :

I needed to use this:

-DFLTK_BUILD_GL=OFF -DFLTK_BUILD_TEST=OFF -DFLTK_OPTION_PRINT_SUPPORT=OFF -DFLTK_BACKEND_WAYLAND=OFF -DFLTK_GRAPHICS_CAIRO=OFF -DFLTK_USE_PANGO=ON

to get this:

-- Use Wayland              No (X11 is used)
-- All drawing uses Cairo   No
-- Use Pango                Yes

..but then, yes, the window borders redraw properly.

So the problem is with using cairo?

Yes, that's what it strongly seems.

The intention is that the replacement of the X11 drawing API by Cairo is invisible for an FLTK client app.

It should be good to look for why that's not so with flwm.

What about the other issue about scrolling?

You may want to keep building FLTK with -DFLTK_BACKEND_WAYLAND=OFF -DFLTK_GRAPHICS_CAIRO=OFF -DFLTK_USE_PANGO=ON

to build flwm.

Then FLTK may be built with default options for FLTK-based client apps of the flwm manager.

In the interest of keeping flwm small, you may also remove Pango use ( -DFLTK_USE_PANGO=OFF).

But the text that flwm draws (window titlebar text, presumably) won't support things such as Arabic and

requires to change what font is used as a function of what text is drawn. Pango is much more

convenient by avoiding that.

[imm]

On Thu, 20 Feb 2025, 17:36 Manolo wrote:

The intention is that the replacement of the X11 drawing API by Cairo is invisible for an FLTK client app.

It should be good to look for why that's not so with flwm.

I do wonder if that's the key point though; flwm is not a "client" app, it's a WM and it deliberately contrives to draw "outside" the app's nominal window area.

So I just wonder if the clip (or something...) is not quite right now, since we're outside the window, and that's causing issues? Just a guess...

[Bill Spitzak]

Looks like Cairo is still clipping to the previous size of the window. Maybe there is some way to tell Cairo to update the drawing area.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/CAGFM6dapQRZqJ5_%3DgJr5cpkNjpmOiWtNs%2BUF0W0cTL3XdPPYEA%40mail.gmail.com.

[gutmensch tinycorelinux]

>> What about the other issue about scrolling?

Ah, sorry, I forgot about that - the issue is still there.

[gutmensch tinycorelinux]

>> You may want to keep building FLTK with -DFLTK_BACKEND_WAYLAND=OFF -DFLTK_GRAPHICS_CAIRO=OFF -DFLTK_USE_PANGO=ON

>> to build flwm.

>> Then FLTK may be built with default options for FLTK-based client apps of the flwm manager.

I tried the version of flwm compiled against the x11-only version of fltk with the full x11/wayland version of fltk, but the window border problem is still there.

[Manolo]

Le jeudi 20 février 2025 à 19:52:48 UTC+1, tces...@gmail.com a écrit :

>> You may want to keep building FLTK with -DFLTK_BACKEND_WAYLAND=OFF -DFLTK_GRAPHICS_CAIRO=OFF -DFLTK_USE_PANGO=ON

>> to build flwm.

>> Then FLTK may be built with default options for FLTK-based client apps of the flwm manager.

I tried the version of flwm compiled against the x11-only version of fltk with the full x11/wayland version of fltk, but the window border problem is still there.

I'm not sure to understand what that means exactly.

I'd like to make sure you built flwm with a static version of the FLTK libraries. If it's

dynamically linked to libfltk.so, it would link to the Cairo-based version of FLTK

when running any FLTK client app.

[Manolo]

Le jeudi 20 février 2025 à 19:36:00 UTC+1, spitzak a écrit :

Looks like Cairo is still clipping to the previous size of the window. Maybe there is some way to tell Cairo to update the drawing area.

I don't think it's a clipping problem, but a resize problem.

Cairo uses an object called a cairo_surface that's sized as the X11 window where Cairo draws and that's

mapped to the display. This surface needs being resized when a window is resized.
The cairo surface resize operation is done in function Fl_Window::resize() which does nothing else.

I see in the source code of flwm that virtual member function Frame::resize() is

void Frame::resize(int, int, int, int) {}
Thus, when the Frame is resized, Fl_Window::resize() is not called, and the cairo surface keeps its old size.

I suggest to modify member function Frame::resize() at line 1350 of file Frame.C of the flwm source code  as follows

void Frame::resize(int X, int Y, int W, int H) {

  Fl_Window::resize(X, Y, W, H);

}

Could you try that and report here if flwm-created borders become correctly drawn when a window is resized and FLTK uses Cairo?

[Manolo]

It might be safer to rewrite function Frame::resize(int X, int Y, int W, int H)

as follows. That's compatible with both FLTK 1.3 and 1.4 and with or without 

Cairo graphics.

#include <FL/Enumerations.H>
#if FL_API_VERSION >= 10400
#  include <FL/platform.H>
#endif

void Frame::resize(int X, int Y, int W, int H) {

#if FL_API_VERSION >= 10400
#  if FLTK_USE_CAIRO
  if (shown() && fl_cairo_gc()) {
    cairo_xlib_surface_set_size(cairo_get_target(fl_cairo_gc()),
      (W>0 ? W : 1), (H>0 ? H : 1));
    pWindow->redraw();
  }
#  endif
#endif
}

[Manolo]

Corrigendum: this is the correct way to get a compilable Frame::resize function:

#include <cairo/cairo-xlib.h>

void Frame::resize(int X, int Y, int W, int H) {

#if FL_API_VERSION >= 10400
#  if FLTK_USE_CAIRO
  if (shown() && fl_cairo_gc()) {
    cairo_xlib_surface_set_size(cairo_get_target(fl_cairo_gc()),
      (W>0 ? W : 1), (H>0 ? H : 1));

    redraw();
  }
#  endif
#endif
}

[gutmensch tinycorelinux]

> I'd like to make sure you built flwm with a static version of the FLTK libraries. If it's

> dynamically linked to libfltk.so, it would link to the Cairo-based version of FLTK

> when running any FLTK client app.

Oops, it was late and I still had -DFLTK_BUILD_SHARED_LIBS=ON so flwm linked against the shared libs.

[gutmensch tinycorelinux]

> Corrigendum: this is the correct way to get a compilable Frame::resize function:

I applied this patch:

```

--- Frame.C.orig        2025-02-21 11:52:53.159953883 +0000
+++ Frame.C     2025-02-21 11:48:34.363290435 +0000
@@ -17,6 +17,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <FL/fl_draw.H>
+#include <cairo/cairo-xlib.h>
 
 #ifndef HAVE_XFT
 #include "Rotated.H" // text rotation code; not supported by non-Xft FLTK 1.3.x
@@ -1347,7 +1348,17 @@
 #endif
 
 // make sure fltk does not try to set the window size:
-void Frame::resize(int, int, int, int) {}
+void Frame::resize(int X, int Y, int W, int H) {
+#if FL_API_VERSION >= 10400
+#  if FLTK_USE_CAIRO
+  if (shown() && fl_cairo_gc()) {
+    cairo_xlib_surface_set_size(cairo_get_target(fl_cairo_gc()),
+      (W>0 ? W : 1), (H>0 ? H : 1));
+    redraw();
+  }
+#  endif
+#endif
+}
 // For fltk2.0:
 void Frame::layout() {
 }

```

..but it doesn't fix things properly - if I enlarge a window, the border redraws properly, but if this window overlaps another window and I switch the focus to that window its border is not drawn properly. Clicking on the second window or moving it redraws the border properly.

[Manolo]

Le vendredi 21 février 2025 à 12:04:38 UTC+1, tces...@gmail.com a écrit :

..but it doesn't fix things properly - if I enlarge a window, the border redraws properly, but if this window overlaps another window and I switch the focus to that window its border is not drawn properly. Clicking on the second window or moving it redraws the border properly.

Yes. I've managed to build and run flwm here and I see that the border redrawing is fixed 

when the window is enlarged with the mouse

but that the border is not always redrawn properly when playing with several apps.

More generally, FLTK 1.4 is guaranteed to be compatible with FLTK 1.3 for pure FLTK clients.

But flwm is not a pure FLTK client app. It's a window manager that uses extensively the X11 API

in addition to the FLTK API. Consequently, what it does is susceptible to be affected by the

internal differences between FLTK 1.4 and 1.3. The code needs to be reviewed by someone

who understands all its use of the X11 API. Few changes are probably necessary, but one

has to find them.

Until that is done, it might be possible to build flwm with FLTK 1.4 statically linked (that's essential)

without Cairo and to use it to decorate Cairo- and Pango-using FLTK 1.4 client apps. I will try this here.

[gutmensch tinycorelinux]

> Until that is done, it might be possible to build flwm with FLTK 1.4 statically linked (that's essential)

> without Cairo and to use it to decorate Cairo- and Pango-using FLTK 1.4 client apps

I tried that and it works :)

The only problem is that the flwm executable is 10x bigger :(

[Greg Ercolano]

On 2/21/25 07:07, gutmensch tinycorelinux wrote:

> Until that is done, it might be possible to build flwm with FLTK 1.4 statically linked (that's essential)

> without Cairo and to use it to decorate Cairo- and Pango-using FLTK 1.4 client apps

I tried that and it works :)

The only problem is that the flwm executable is 10x bigger :(

    Hmm, I must've missed something skim reading this thread, but what's the reason for ensuring static linking?

    Given Tinycorelinux's goal is to keep executable binaries small by leveraging dynamic libs, curious what problem is avoided by static linking flwm? I assume it's more than the usual runtime "missing lib" issues, as I'm sure tinycorelinux can pre-package the "correct" fltk libs for its flwm installation)

    Is it because fltk tries to pre-load dynamic libs unless statically built that is causing issues with flwm?
    (That's all I could think of)

<flwm digression>

    FWIW, I used to regularly use a hotrodded version of flwm as my window manager for at least a decade or so, and loved it for /just/ being a simple, clean window manager.

    The hotrodding was to remove the rotated text and sideways window borders (which I never liked, sorry Bill :D), and made the window borders/colors/hotkeys more IRIX/SGI-like, and made some changes to the right-click menu to make it easy to run common applications I needed like Thunderbird, Firefox, Gvim, Folder browsers, Terminals, Gimp, clocks, calculator, flruler etc.

    I also had to make some tweaks to support the newer window manager protocols because it caused problems for some applications. I remember having to dive deep into the common linux desktop design documents to figure that stuff out, I think it was related to iconization or resizing, window titling, or some such. (shrug)

    But somewhere along the line about 6 or so years ago, I had trouble getting flwm to build/run, and found that to assist my software customers, it helped if I used the default window managers instead of flwm.

    I also noticed the newer window managers seem to have solved the many pesky issues that made me move to flwm, specifically default window manager background "support daemons" that would randomly go bananas and use 100% cpu or swap out the machine overnight due to memory leaks. That drove me crazy every time I'd try a new linux distro/release, and pressured me to keep using flwm.

    But when using flwm, I did notice without those support daemons, many large applications would whine and moan about the support daemons not being present. Something about clipboards, sound, and other weird things would cause the gnome folder browsers and large word processors/spreadsheets to spew warnings and misbehave in odd ways. Minor issues I was able to workaround, but annoying. In some cases I figured out how to start those daemons when needed, but then they'd go crazy and I'd have to kill them to restore sanity.

    It's possible one of the issues that caused me to move from flwm back to default window managers was I couldn't get it to build against fltk 1.4.

[Bill Spitzak]

I think flwm was overriding resize() to avoid the redraw() call, possibly to avoid the display blinking (which is irrelevant for Cairo as it is double-buffered).

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/fltkgeneral/39698c57-963a-4f06-9773-38d18a396769%40seriss.com.

[Manolo]

Le vendredi 21 février 2025 à 17:16:46 UTC+1, er...@seriss.com a écrit :

On 2/21/25 07:07, gutmensch tinycorelinux wrote:

> Until that is done, it might be possible to build flwm with FLTK 1.4 statically linked (that's essential)

> without Cairo and to use it to decorate Cairo- and Pango-using FLTK 1.4 client apps

I tried that and it works :)

The only problem is that the flwm executable is 10x bigger :(

    Hmm, I must've missed something skim reading this thread, but what's the reason for ensuring static linking?

FLTK 1.4 under X11 can be run in 2 ways, with or without FLTK_GRAPHICS_CAIRO. This option brings fully scalable,

antialiased graphics which is an improvement. But flwm has (small I'd say) window border redraw issues when run with

FLTK_GRAPHICS_CAIRO. These issues don't occur with FLTK_GRAPHICS_CAIRO=0. Furthermore, what

flwm draws is not significantly improved by FLTK_GRAPHICS_CAIRO. So, using flwm linked to a version of FLTK 1.4

with FLTK_GRAPHICS_CAIRO=0 gives a good result.

In contrast, FLTK client apps of flwm do benefit of scalable, antialiased graphics. Linking them to a version

of FLTK 1.4 with FLTK_GRAPHICS_CAIRO=1 is preferable. 

A simple way to get both of these things is to statically link flwm to its custom-built version of FLTK,

and to dynamically link client FLTK apps to an installed FLTK with default (FLTK_GRAPHICS_CAIRO=1) settings.

[Manolo]

Le vendredi 21 février 2025 à 17:50:43 UTC+1, spitzak a écrit :

I think flwm was overriding resize() to avoid the redraw() call, possibly to avoid the display blinking (which is irrelevant for Cairo as it is double-buffered).

As I wrote above, one issue is that a Cairo-using X11 window must resize its Cairo surface with function cairo_xlib_surface_set_size()

each time the window is resized. So, a call to that function must be placed somewhere in the source code of flwm appropriately.

I suggested to place it in function Frame::resize() and this proved to work. Window borders are now correctly drawn

when an flw-decorated window is resized with the mouse.

But, a few small window border redraw issues remain.

[imm]

On Fri, 21 Feb 2025, 16:16 Greg Ercolano wrote:

Hmm, I must've missed something skim reading this thread, but what's the reason for ensuring static linking?

I think it's to prevent flwm loading the cairo-enabled fltk .SO libs, such that flwm is "pure X11" and thus ducking the border redraw issue.

But flwm client apps can still linked to the .SO libs and use Cairo etc...

Something like that!

[imm]

On Fri, 21 Feb 2025, 15:00 tinycorelinux wrote:

> Until that is done, it might be possible to build flwm with FLTK 1.4 statically linked (that's essential)

> without Cairo and to use it to decorate Cairo- and Pango-using FLTK 1.4 client apps

I tried that and it works :)

The only problem is that the flwm executable is 10x bigger :(

I'm surprised it's that big a difference - what sizes are you getting?

The "pure X11" build shouldn't have that much extra stuff in it, so I'd expect it to be reasonably small, if perhaps a little bigger than the dynamic linked version.

Is the static build version fully stripped? 

Since it's static linked it can (should!) be, but I don't think the "compileit" script strips the final binary, does it?

If, after the build, you do a "strip flwm", does that reduce the size much?

[gutmensch tinycorelinux]

The staticly linked flwm is 553k, the dynamically linked flwm is 51kb, both sstripped

[Ian MacArthur]

On Friday, 21 February 2025 at 18:53:30 UTC tces... wrote:

The staticly linked flwm is 553k, the dynamically linked flwm is 51kb, both sstripped

Yup - I'm truly surprised; my recollection (though it'd be a few years...) was that the static linked build was much smaller than that.

But I've tried a few things and I'm struggling to get much below 560k.

Oh well.

 

[gutmensch tinycorelinux]

> More generally, FLTK 1.4 is guaranteed to be compatible with FLTK 1.3 for pure FLTK clients.

> But flwm is not a pure FLTK client app. It's a window manager that uses extensively the X11 API

> in addition to the FLTK API. Consequently, what it does is susceptible to be affected by the

> internal differences between FLTK 1.4 and 1.3. The code needs to be reviewed by someone

> who understands all its use of the X11 API. Few changes are probably necessary, but one

> has to find them.

Would you have any pointers for finding the few changes necessary?

[Manolo]

Le samedi 22 février 2025 à 14:21:55 UTC+1, tces...@gmail.com a écrit :

> More generally, FLTK 1.4 is guaranteed to be compatible with FLTK 1.3 for pure FLTK clients.

> But flwm is not a pure FLTK client app. It's a window manager that uses extensively the X11 API

> in addition to the FLTK API. Consequently, what it does is susceptible to be affected by the

> internal differences between FLTK 1.4 and 1.3. The code needs to be reviewed by someone

> who understands all its use of the X11 API. Few changes are probably necessary, but one

> has to find them.

Would you have any pointers for finding the few changes necessary?

Yes. I believe I've the solution.

Make these 2 changes to Frame.C :

1) add #include <cairo/cairo-xlib.h> at the beginning

2) in function Frame::set_size(), after the call to XMoveResizeXWindow() add this

#if FL_API_VERSION >= 10400
#  if FLTK_USE_CAIRO

  make_current();
  if (fl_cairo_gc()) cairo_xlib_surface_set_size(cairo_get_target(fl_cairo_gc()), nw, nh);
#  endif
#endif

My previous suggestion to change Frame::resize() was not good. Restore that function to its

previous state.

With this, in my hands, flwm seems to work OK with CairoGraphics and Pango.

[Manolo]

One more detail, to keep compatibility with FLTK 1.3.x you can sandwich 

the #include directive as follows:

#if FL_API_VERSION >= 10400
#  if FLTK_USE_CAIRO

  #include <cairo/cairo-xlib.h>
#  endif
#endif

[gutmensch tinycorelinux]

The patch below seems to fix things - thanks very much :)

--- Frame.C.orig 2025-02-22 15:37:57.279938585 +0000
+++ Frame.C 2025-02-22 15:44:28.096600677 +0000
@@ -17,6 +17,11 @@

 #include <stdio.h>
 #include <stdlib.h>
 #include <FL/fl_draw.H>

+#if FL_API_VERSION >= 10400
+#  if FLTK_USE_CAIRO

+  #include <cairo/cairo-xlib.h>
+#  endif
+#endif

 
 #ifndef HAVE_XFT
 #include "Rotated.H" // text rotation code; not supported by non-Xft FLTK 1.3.x

@@ -1116,6 +1121,12 @@
   // for configure request, move the cursor first
   if (warp == 2 && active() && !Fl::pushed()) warp_pointer();
   XMoveResizeWindow(fl_display, fl_xid(this), nx, ny, nw, nh);

+#if FL_API_VERSION >= 10400
+#  if FLTK_USE_CAIRO

+  make_current();
+  if (fl_cairo_gc()) cairo_xlib_surface_set_size(cairo_get_target(fl_cairo_gc()), nw, nh);
+#  endif
+#endif
   if (nw <= dwidth) {
     if (unmap) {
       set_state_flag(IGNORE_UNMAP);

[Mike Lockmoore]

Hi FLTK people.  I'm the fellow who customized FLWM for TinyCore Linux back around 2009/2010 to allow "topside" titlebars.  After many years away, I'm picking up on the recent work here to build FLWM on FLTK 1.4.x and make work well with the high DPI capabilities, which I think are great!

So here's my goal: I would like to update the window frame decoration to use the scaling factor implied by .Xdefaults Xft.dpi (as the ratio with 96.0) or the environment variable appropriately.  As it is built now, FLWM when launched with FTLK_SCALING_FACTOR=1.0 (or Xft.dpi=96.0), the title bars look ok and the window management buttons to iconize, resize, and close the window are placed correctly.  And when the scaling change is made by a user with the hotkeys, the window content and overall shape scales beautifully (well done, devs!), but the title bar stays the same thickness, which would be fine except for the following issue...

When FLWM is started with FTLK_SCALING_FACTOR > 1.0 (or Xft.dpi > 96.0), the title font scales up, but the bar thickness does not scale up.  This causes the title characters to be clipped.  Even worse, the window management buttons disappear, at least for most typical-sized windows.  TinyCore has a few apps with very small windows and you can sometimes see one or a few of the four buttons, depending on the current scaling factor, but usually not.  I assume the frame window scaling is such that the buttons are moving to a pixel coordinate outside the real window's clipping boundary.  The title bar thickness is currently defined by some hard-coded constants, which I can try to make a function of the scaling factor, but I've lost the buttons. 

Conversely, when FLWM is started with FTLK_SCALING_FACTOR < 1.0, the title font is scaled down as expected, but the window management buttons are not placed in the corner but some distance away (again, I assume it's somehow proportional to the scaling factor). The title bar's color rectangle does not stretch to the full extent of the window, so the gap to the edge appears black.  In the "topside" variant build, this means the buttons are not quite in the upper right corner and the extra black area is in the upper right corner.  There is a little bit of black window border on the left edge at the bottom.  I've not tested the standard title-on-left build, but it probably has similar behavior.

I've tried several things to get the scaling to work in the window frame decoration, but not successful so far.  Is there something different about how the scale factor works for the top-level window frames created by the WM?  Or some command I can use to control this better for the frame so I can put the buttons in a well-defined (non-clipped) area?  Do you have any advice for a method of getting the size and placement of the window frame decoration elements?  I don't necessarily want these to keep changing in title font scale as the window contents are rescaled, but it would be great if the title font scaling would be the proper % from the Xft.dpi setting and could stay at that scale even if the user uses scaling hot-keys to grow or shrink the window contents. 

Thanks for any suggestions, pointers to more info, or examples to handle the scaling better!
__
Mike "Lockmoore"

[Manolo]

Le dimanche 2 mars 2025 à 05:07:31 UTC+1, mlock...@gmail.com a écrit :

So here's my goal: I would like to update the window frame decoration to use the scaling factor implied by .Xdefaults Xft.dpi (as the ratio with 96.0) or the environment variable appropriately.  As it is built now, FLWM when launched with FTLK_SCALING_FACTOR=1.0 (or Xft.dpi=96.0), the title bars look ok and the window management buttons to iconize, resize, and close the window are placed correctly.  And when the scaling change is made by a user with the hotkeys, the window content and overall shape scales beautifully (well done, devs!), but the title bar stays the same thickness, which would be fine except for the following issue...

When FLWM is started with FTLK_SCALING_FACTOR > 1.0 (or Xft.dpi > 96.0), the title font scales up, but the bar thickness does not scale up.  This causes the title characters to be clipped.  Even worse, the window management buttons disappear, at least for most typical-sized windows. 

I've run here flwm with Xft.dpi = 200 and can see the titlebar width is twice too small (see attached).

What you have to do in flwm is to multiple all graphical quantities by the current scale factor value when such

quantity is transmitted to an X11 function call. That's what FLTK does internally but cannot do if a client app, flwm,

uses X11 calls. Conversely, a graphical quantity received by flwm from an X11 function is to be

divided by the scale factor. The scale factor value is given by

  float s = Fl::screen_scale(0);

(assuming there's only one screen).

[imm]

Mike,

On top of what Manolo said, I have a vague idea that the borders are drawn using hard-coded values in the source (I may be mis-remembering that) so you need to hunt them all down and scale them accordingly.

Also bear in mind that fltk works to scale the app area; the border is the responsibility of the WM.

When the WM is also drawn using fltk, I'm not quite sure what happens!

But I guess the WM will need to rescale the border tabs explicitly, from what Manolo's screenshot shows.

[Mike Lockmoore]

Thanks Manolo and Ian.  Right, it's the WM's responsiblity, which is why I am working on updating the lightly-modded version of the FLWM code to work better with fractional scaling.  

Ian, yes there are hard-coded values to space things appropriately on the title bar.  I may be able to use them as-is if I adjust things passed into various calls with the current scale factor.  

Manolo, what you say  makes some sense in terms of passing things into or taking them out of X11 calls, which FLWM does in a few spots.  As a first step,  I changed the code to put the buttons in the upper left corner (so the coordinates are small and won't scale off the visible area), and it is basically working!  However, this is not the location for buttons that people are used to, if they've been using our "topside" variant of FLWM.  At a minimum, I need to further tweak things to line up more precisely, if not get the buttons back to the right-hand side.

Thanks again for your info!    -Mike

[Manolo]

Here is a simple approach to give flwm support of HighRes displays:

1) double the values of LEFT, RIGHT, TOP, BOTTOM, and TITLE_FONT_SIZE in config.h;

2) double the width of lines used to draw titlebar buttons;

3) have flwm ignore the value of the xft.dpi resource by forcing its scaling factor to 1;

4) all FLTK client programs remain unchanged. They read and use the value of the xft.dpi resource to adapt

at startup time to the HighDPI display.

This is in the attached patch relatively to the git repo version of flwm.

This produces an flwm that's adequate for HighDPI displays.

To produce a version of flwm able to run both on HighDPI and lowDPI

displays, it would be necessary for you, Mike, to do some more work :

1) remove from config.h the doubling done at item 1) above

2) transform compile-time constants LEFT, RIGHT, TOP, BOTTOM, and TITLE_FONT_SIZE

**and** other constants derived from them into variables used by the flwm

source code;

3) in main(), right after the fl_open_display() call, memorize in global variable

  float flwm_scale;

the value of Fl::screen_scale(0). Multiply the initial values of compile-time constants 

derived from config.h by flwm_scale and have the source code of flwm use these variable values 

and **completely** stop using compile-time constants. After this, call

  Fl::screen_scale(0,1);

to set the window manager's scaling factor to 1, whatever the current Xft.dpi resource.

4) replace in Frame.C the doubling of button line widths by multiplication

by int(flwm_scale).

[Mike Lockmoore]

Manolo: Thanks for taking the time to outline a good approach to making the WM more adaptive.  Even before I saw this, I was doing several of these steps  already, but you gave me a few more things to think about.   I have fairly reasonable window frame appearance now, including button layout, but the window resizing and positioning functions are working very poorly right now because I'm not yet "unscaling" some key parameters passed into certain X Windows calls.
--

Mike

[Manolo]

Le vendredi 7 mars 2025 à 03:12:35 UTC+1, mlock...@gmail.com a écrit :

Manolo: Thanks for taking the time to outline a good approach to making the WM more adaptive.  Even before I saw this, I was doing several of these steps  already, but you gave me a few more things to think about.   I have fairly reasonable window frame appearance now, including button layout, but the window resizing and positioning functions are working very poorly right now because I'm not yet "unscaling" some key parameters passed into certain X Windows calls.
--

Mike

The approach outlined above should remove all need to unscale or scale parameters of X11 calls

because flwm works with a scaling factor of 1 whatever the value of Xft.dpi.

[Mike Lockmoore]

OK, I can try that out.  Maybe the TinyCore core team would be happy with a version that is more limited but predictable as you suggest for their base window manager, but can offer a high DPI version in the repo for users like me that want a bit more control & customization ability.  Here's a screen shot of my WIP for the "more work" approach.

Again, thanks for the info and suggestions!  -Mike

[Manolo]

Le samedi 8 mars 2025 à 01:09:13 UTC+1, mlock...@gmail.com a écrit :

OK, I can try that out.  Maybe the TinyCore core team would be happy with a version that is more limited but predictable as you suggest for their base window manager, but can offer a high DPI version in the repo for users like me that want a bit more control & customization ability.  Here's a screen shot of my WIP for the "more work" approach.

Great. Your WIP seems to be very advanced and to work very well.

In my view, but I may overlook something, my suggestion should not deserve to be considered "more limited".

What I imagine is a version of flwm that reads the value of Xft.dpi when it starts, divides this value by 96,

obtains  thus a factor that gets multiplied to LEFT, RIGHT, TOP, BOTTOM, and TITLE_FONT_SIZE.

This should produce a window border and border buttons of a size adequate to the dpi.

Once these border and button sizes are defined, flwm runs entirely with a GUI scaling factor of 1.

Thus, none of the calls to X11 functions it makes needs unit conversion.

Client apps of this flwm, in turn, read the value of Xft.dpi and obtain a factor that becomes their GUI scaling factor

which makes them usable with any dpi value without source code change. That's normal FLTK 1.4 behaviour.

[Mike Lockmoore]

Yes, your suggestion is working very well indeed!  I've found I can just read the scale before fl_open_display( ) and set the scale to 1.0 after it:

  ...

  sf = Fl::screen_scale(0);

  TitleFontSz = (int) ((float)TITLE_FONT_SIZE * sf);
  TitleSz     = (int) ((float)(TITLE_FONT_SIZE + 4) * sf);
  ButtonSz    = TitleSz;
  LftSz = (int) ((float)LEFT   * sf);
  RgtSz = (int) ((float)RIGHT  * sf);
  TopSz = (int) ((float)TOP    * sf);
  BtmSz = (int) ((float)BOTTOM * sf);

  fl_open_display();
  Fl::screen_scale(0, 1);
  .. .


Now the features to handle grabbing window borders for resizing, and the maximize buttons and so forth are all working as before, but with the benefit that the user can adjust the scaling of the window content with the hotkeys.  Even the sideways "rollerblind" (minimum width) effect is working:


I've needed to play with some of the code to place the buttons and manage the window title label size, etc., but it's getting close for other users to be able to test out.  Thanks for your good ideas!   -Mike

[Mike Lockmoore]

Manolo and all: Things are working well overall, but when I click on the "minimize" (windowblind rollup effect resize) on non-FLTK applications, I'm not getting them to resize to just the minimal titlebar.  Firefox is taller than the screen (by a little), but narrow.  Geany (a GTK+ IDE) is resizing the same way (overly tall and narrow), but is not repainted, with old image buffer data ("garbage") visible.  I know that there are calls to unmap( ) the swallowed application window, but I'm not seeing the frame paint the minimimal titlebar state as it does for the FLTK apps successfully.  Firefox just seems to mostly ingore the unmap call.  Rough screenshot below.

Any suggestions how I can better manage the non-FLTK application windows inside the FLWM frames? Thanks in advance if you again consider my questions and issues!

- Mike

[Manolo]

> I've found I can just read the scale before fl_open_display( ) and set the scale to 1.0 after it

The reading of Xft.dpi and its division by 96 is done inside fl_open_display(). It turns out that

computing Fl::screen_scale(0) implicitly calls fl_open_display(). And display opening is done

only once, so that further calls to fl_open_display() are NOPs.

Thus, placing fl_open_display( ) after Fl::screen_scale(0) makes no harm but has no logical sense.

I'd rather do all this initialisation work after fl_open_display(). The crucial thing is to

do it before the first window show() call.

If flwm is expected to support multi-screen setups, you should set to 1. the scale factors

of all screens with this loop:

  for (int i = 0; i < Fl::screen_count(); i++) Fl::screen_scale(i, 1.);

[Manolo]

I try here to run firefox under the flwm WM with Xft.dpi set to 150.

What I see is that it's necessary to wait a relatively long time (about 1/2 minute) for firefox to become responsive

to user input. Before that, its responses to titlebar buttons are wrong. After that, everything (navigating

through pages, resize operations, titlebar button operations, scaling with ctrl/+/-/) seems normal.

The initial waiting period spits error messages about "failed to create proxy" and "org.freedesktop.portal.Desktop".

[Mike Lockmoore]

Thanks for the extra info and suggestions.  I've not attempted running on multiple screens yet. -Mike

[Mike Lockmoore]

I don't initialization time is the factor here.  I've let Firefox sit for ten minutes or more and the weird minimize behavior is still happening.  I don't see the "failed to create proxy" and "org.freedesktop.portal.Desktop" messages on my console when I start FF from the commandline.  However, starting on the commandline is showing me this pair of warning messages when I tried the window minimize button:

[Parent 8577, Main Thread] WARNING: Native Windows wider or taller than 32767 pixels are not supported: 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:201

(firefox:8577): Gdk-WARNING **: 14:12:51.579: Native Windows wider or taller than 32767 pixels are not supported

Maybe a negative value is getting created somehow and sent to the application main window?  I'll dig into this later today.

[Mike Lockmoore]

UPDATE: I seemed to solve the issue I noticed.  In the "topside" builds of FLWM, the minimize-window button event intends to make the window appear as the horizontal titlebar only (a horizontal strip), but the classic FLWM code is intended to only minimize windows into a vertical titlebar strip, therefore the code that decides whether to unmap the frame's client window was only looking for "is this now a thin vertical strip?" criteria. After I made it sensitive to resizing into either a vertical or horizontal strip, it will unmap the app client window, so it works.  I also check the values from computing what the overall new height/width should be in the minimized state, and reset them to a small positive value if any is negative. I'm not 100% certain I need to do this, but it prevents a warning from lower graphics libs and does not seem to harm anything as far as I've been able to see.

Example of classic FLWM style with a few minimized windows (Firefox, Geany, and a file manager named Fluff).

[Manolo]

Le lundi 10 mars 2025 à 03:48:03 UTC+1, mlock...@gmail.com a écrit :

UPDATE: I seemed to solve the issue I noticed.  In the "topside" builds of FLWM, the minimize-window button event intends to make the window appear as the horizontal titlebar only (a horizontal strip), but the classic FLWM code is intended to only minimize windows into a vertical titlebar strip, therefore the code that decides whether to unmap the frame's client window was only looking for "is this now a thin vertical strip?" criteria. After I made it sensitive to resizing into either a vertical or horizontal strip, it will unmap the app client window, so it works.  I also check the values from computing what the overall new height/width should be in the minimized state, and reset them to a small positive value if any is negative. I'm not 100% certain I need to do this, but it prevents a warning from lower graphics libs and does not seem to harm anything as far as I've been able to see.

Example of classic FLWM style with a few minimized windows (Firefox, Geany, and a file manager named Fluff)

……

 Beautiful!

 

Is the example above running on a HighDPI display?

[Mike Lockmoore]

Merci!  Yes, if you count 1920 by 1080 pixels on my laptop.  I'm not sure what DPI the previous screenshot was, but this one is set at 144 (150%). Some of the challenging windows are minimized, and a few others are in a normal, open state. - Mike