bugGNU Octave - Bugs: bug #66482, make fltk available on octave-cli

 
 

bug #66482: make fltk available on octave-cli

Submitter:  Dmitri A. Sergatskov <dasergatskov>
Submitted:  Mon 25 Nov 2024 03:58:50 AM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Release: 
Operating System:  * Mac OS Fixed Release:  9.3.0
Planned Release:  9.3.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 31 Mar 2025 08:33:29 PM UTC, comment #7: 

I guess a more "sophisticated" way of doing it is:

diff -r b72eef0cba9a libinterp/corefcn/cdisplay.c
--- a/libinterp/corefcn/cdisplay.c      Mon Mar 31 06:56:20 2025 -0700
+++ b/libinterp/corefcn/cdisplay.c      Mon Mar 31 16:30:06 2025 -0400
@@ -35,6 +35,8 @@
 #include <Carbon/Carbon.h>
 #elif defined (HAVE_X_WINDOWS)
 #include <X11/Xlib.h>
+#elif defined (HAVE_WAYLAND_CLIENT)
+#include <wayland-client.h>
 #endif

 #include "cdisplay.h"
@@ -161,6 +163,23 @@
     }
   else
     msg = "unable to open X11 DISPLAY";
+#elif defined (HAVE_WAYLAND_CLIENT)
+
+  // Check for Wayland display
+  struct wl_display *display = wl_display_connect(NULL);
+  if (display)
+    {
+      // Default to reasonable values for Wayland
+      *dp = 32;  // Most common color depth
+      *ht = 1080;  // Default to HD resolution for now
+      *wd = 1920;
+      *dpy_avail = 1;
+      // Clean up
+      wl_display_disconnect(display);
+    }
+  else
+    msg = "no Wayland display available";
+

 #else

But then we need to change configure to add
WAYLAND_CLIENT_LIBS for cdisplay.
I do not know how to do this properly,
I can build it with `make  LIBS="-lwayland-client"

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 31 Mar 2025 06:41:31 PM UTC, comment #6: 

Well, i had a fresh look at what I was doing and apparently my mistake was checking for "HAVE_WAYLAND" instead of "HAVE_WAYLAND_CLIENT". With that and the change to "cdisplay.c"

diff -r 027c713792d1 libinterp/corefcn/cdisplay.c
--- a/libinterp/corefcn/cdisplay.c      Sun Mar 30 19:47:01 2025 +0200
+++ b/libinterp/corefcn/cdisplay.c      Mon Mar 31 14:38:43 2025 -0400
@@ -27,6 +27,9 @@
 #  include "config.h"
 #endif

+#include <string.h>
+#include <stdio.h>
+
 #include <stdlib.h>

 #if defined (OCTAVE_USE_WINDOWS_API)
@@ -161,6 +164,19 @@
     }
   else
     msg = "unable to open X11 DISPLAY";
+#elif defined (HAVE_WAYLAND_CLIENT)
+
+  // Check for Wayland display
+  const char *wayland_display = getenv ("WAYLAND_DISPLAY");
+  if (wayland_display && strlen(wayland_display) > 0)
+    {
+      // Default to reasonable values for Wayland
+      *dp = 32;  // Most common color depth
+      *ht = 1080;
+      *wd = 1920;
+      *dpy_avail = 1;
+    }
+

 #else

It is all seems to work. The values are fake and different from the actual values, but I guess "fltk" the same as "qt" could obtain the real values on its own.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 31 Mar 2025 05:23:44 PM UTC, comment #5: 

By "--without-x" I mean configuring octave as "./configure --without-x"

If I could identify unexpected response from fltk, I would file
an issue with them.

 "have_window_system ()" returns "0" but that does not stop Qt to run and operate more-or-less normally.

It looks to me it is octave initialization procedure being too restrictive somewhere.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 31 Mar 2025 11:45:35 AM UTC, comment #4: 

Re comment #3: ISTR that there is an open bug report about implementing support for Wayland. (I guess that is what you mean with "compiled "--without-x"".)

Maybe, drop a comment there that one of the functions that guard registering the FLTK toolkit returns the wrong result. Maybe, that's "have_window_system ()"?

Markus Mützel <mmuetzel>
Group administrator
Fri 21 Mar 2025 08:13:42 PM UTC, comment #3: 

Similarly, on linux with wayland, fltk should be available when compiled "--without-x". And In fact i see configure returns:

config.status:"_LDFLAGS QRUPDATE_CPPFLAGS AMCOND_INSTALL_INTERNAL_FONT_FILES_FALSE AMCOND_INSTALL_INTERNAL_FONT_FILES_TRUE GL2PS_LIBS FLTK_LIBS FLTK_LDFLAGS FLTK_C"\
config.status:"PPFLAGS FLTK_CONFIG DEFAULT_TERMINAL_FONT_SIZE DEFAULT_TERMINAL_FONT WIN32_TERMINAL_FALSE WIN32_TERMINAL_TRUE AMCOND_HAVE_QSCINTILLA_FALSE AMCOND_HA"\
config.status:S["FLTK_LIBS"]="-lfltk_gl -lfltk"
config.status:S["FLTK_LDFLAGS"]=""
config.status:S["FLTK_CPPFLAGS"]=""
config.status:S["FLTK_CONFIG"]="/usr/bin/fltk-config"
config.status:D["HAVE_FLTK"]=" 1"


And it is being buit:

$ find ./ -name *fltk*
./libinterp/dldfcn/__fltk_uigetfile__.la
./libinterp/dldfcn/__init_fltk__.la
./libinterp/dldfcn/__fltk_uigetfile__.cc-tst
./libinterp/dldfcn/.libs/__fltk_uigetfile__.la
./libinterp/dldfcn/.libs/__init_fltk__.la
./libinterp/dldfcn/.libs/__init_fltk__.lai
./libinterp/dldfcn/.libs/__fltk_uigetfile__.so
./libinterp/dldfcn/.libs/__init_fltk__.so
./libinterp/dldfcn/.libs/__fltk_uigetfile__.lai
./libinterp/dldfcn/.libs/__init_fltk___la-__init_fltk__.o
./libinterp/dldfcn/.libs/__fltk_uigetfile___la-__fltk_uigetfile__.o
./libinterp/dldfcn/__init_fltk__.oct
./libinterp/dldfcn/.deps/__init_fltk___la-__init_fltk__.Plo
./libinterp/dldfcn/.deps/__fltk_uigetfile___la-__fltk_uigetfile__.Plo
./libinterp/dldfcn/__init_fltk__.cc-tst
./libinterp/dldfcn/__fltk_uigetfile___la-__fltk_uigetfile__.lo
./libinterp/dldfcn/__fltk_uigetfile__.oct
./libinterp/dldfcn/__init_fltk___la-__init_fltk__.lo


Yet it does not show up in

octave:1> available_graphics_toolkits
ans =
{
  [1,1] = gnuplot
  [1,2] = qt
}


Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 01 Dec 2024 03:48:22 AM UTC, comment #2: 

I think this is good enough for now.  Maybe, as proposed at the last developer's meeting, FLTK becomes a package that can be loaded.  This is good enough for now.  Marking as Fixed and closing report.

Rik <rik5>
Group administrator
Tue 26 Nov 2024 03:16:14 PM UTC, comment #1: 

I added a commit message to the patch from that Discourse thread and - like proposed by Rik - I pushed it to the stable branch:
https://hg.savannah.gnu.org/hgweb/octave/rev/6c405f3f7e52

Marking as ready for test.

Markus Mützel <mmuetzel>
Group administrator
Mon 25 Nov 2024 03:58:50 AM UTC, original submission:  

fltk is currently disabled on MacOS, because it crashes when it is
interacts with qt threads. But it warks fine in a single-threaded execution (like when it is enabled in octave-cli).
See discussion at:
 https://octave.discourse.group/t/fltk-errors-on-macos-15-1-homebrew/6007/9

Please enable building fltk backend as proposed in this discourse thread.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by mmuetzel (Posted a comment)
  • -email is unavailable- added by dasergatskov (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-12-01 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
        Fixed ReleaseNone 9.3.0
    2024-11-26 mmuetzel StatusNone Ready For Test
        Planned ReleaseNone 9.3.0

    Back to the top

    Powered by Savane 3.15-e6e5.
    Corresponding source code