iup-users Mailing List for IUP

Hey, just an update. The Cocoa GLCanvas has been rewritten not to use the
GL control, but only context and plain NSView, and is fully functional now;
I tested it in the VM, and it correctly falls back to the "Apple Software
Renderer".

I added new drivers. Qt driver (for both Qt5 and Qt6). This was really
smooth. Qt is very nice to work with. I already had experience, but not
with some lower-level things.
I added a GTK4 driver; this had to be a completely new driver. A lot of
things now work completely differently; the old GTK2/GTK3 could not be
reused in any way. Only some components could be reused. It is still a
little rough, but it works correctly so far (for everything I was able to
test it with so far).

The EGL driver for GLCanvas now natively supports Wayland for GTK3, GTK4,
and Qt6. All toolkits have functions to get the Wayland wl_surface (Qt
needs private headers). So, I create a subsurface that can be positioned
relative to the main wl_surface and create an EGL window with that. It is
tested in Gnome Mutter and KDE KWin, and there it works correctly. It
cannot be resized on the compositor I use (Labwc). Not sure if I am doing
something wrong or if there will be similar issues with all the different
compositors out there.

There are still a few small issues, like the Cocoa window is, for some
reason, still a little bigger than it should be. Or there are still some
places with hard-coded dimensions in new drivers, but they can be
calculated with a temp widget or something similar. The plan is to fix all
these and to fine-tune everything.
I added a custom drawn toggle SWITCH support for Qt (there is no native
control) and for Win32. Win32 is drawn according to the XML specs from the
WinUI framework; it looks very similar to a native modern control that can
be seen in Windows 10/11.

And finally, I added a new drawing functions for ALL drivers now. I added
support for Bezier curves, rounded rectangles, and gradients (there is also
IupDrawSetClipRoundedRect ). They do not change the old API in any way,
just complement existing functions. For the WDL Win32 backend, Direct2D is
now the default (it can fall back to GDI anyway), and there, new "dummy"
functions are added, so there are no allocations, just direct draw calls.
Attached is a screenshot from the new `draw` showcase example I added, from
the Qt driver. Looks really nice, I think. Those new features could be used
to beautify some custom controls.

Of course, no pressure, I would appreciate if you could take a look. I
think I have a good understanding so far of how everything is connected,
but I am not sure. Maybe I did something weird, or I don't know. I also
have a lot of AI-generated code. I reviewed it carefully, of course,
function by function. Some driver functions have also been rewritten
manually, actually, more than some. But there could still be something that
was missed or plainly wrong.



On Wed, Oct 29, 2025 at 1:19 PM Antonio Scuri <ant...@gm...>
wrote:

> Hi,
>
> Very interesting. Yes, I will definitely take a look at this. The problem
> is when. But I will keep you posted.
>
> Thanks for the contribution!
>
> Em ter., 28 de out. de 2025 às 21:02, Milan Nikolic <gen...@gm...>
> escreveu:
>
>> Hello,
>>
>> I have been working on this for some time now for my Go bindings here
>> https://github.com/gen2brain/iup-go, and I do not see any issue with
>> Cocoa anymore.
>> There are 60+ examples in the repo, and they all now work correctly.
>> There is no need for an .app bundle anymore; the .xib files are compiled to
>> .nib and included in the generated file (there is a shell script for that).
>> Those .xib files were previously designed in Xcode; there may be a way to
>> recreate them programmatically, but then again, it could also make it
>> easier to design future controls.
>> The menu is now dynamically generated, and the default macOS menu will be
>> shown even if started from the terminal. Also, the app will properly start
>> in the foreground even when started from the terminal.
>> I tested the examples on macOS 14, 15, and 26, as well as on old 10.15.
>> 10.15 is the minimum requirement. Go 1.21 is the last version with support
>> for macOS 10.15, and also, `brew` can be made to work on 10.15. I don't
>> think any effort to support older versions makes sense.
>> I spent a lot of time trying to use the native Tab controls, the new API,
>> and the old API; everything was minimal and unusable. Finally, the
>> custom-drawn tabs implementation is now used. I started with ENTabView
>> (MIT-licensed), and now it is just based on that; it doesn't have any
>> similarities, but I left a note that it is based on that. Tabs now look
>> nice, follow the native theme colors, and support all available features,
>> including some new ones (TABDRAGGABLE).
>> There are also some Cocoa-specific attributes, like TOLERANCE for
>> IupTimer, so you can save the user's battery if precision is not that
>> important; then CONTEXTMENU, which macOS has everywhere - we can use them
>> or disable them with NULL (sometimes they get in the way).
>> There is also support for `NSOpenGL` for the GL backend, but I could not
>> test it in the VM. I do not have real hardware, nor does anyone around me
>> have Apple hw to test. I would appreciate it if anyone could test and let
>> me know what is happening. There are just a few steps:
>>
>>     brew install go
>>     git clone https://github.com/gen2brain/iup-go
>>     cd iup-go/examples/glmodern
>>     go build -tags gl
>>
>> Only GL examples need `-tags gl`, for all others, plain `go build` is
>> enough (WebBrowser examples need `-tags web`). You can also install GTK
>> with:
>>
>>     brew install gtk+3 pkgconf
>>
>> Then you can build with `go build -tags gtk` to compare the GTK and Cocoa
>> implementations. Everything works, but there may be some issues with some
>> dynamically updated attributes or some edge cases. It really needs a fresh
>> look from someone else.
>>
>> There are more changes:
>>
>>  - GTK now also uses runtime checks for proper backend detection (X11 and
>> Wayland on Linux). There is a new EGL backend, and I am using it for both
>> X11 and Wayland. The old GLX backend is now fixed as well; it was not very
>> usable. I was getting only a black screen with my glmodern example, but now
>> it is fixed. I use the GLX backend now only for Motif and GTK2.
>>
>> - The annoying Wayland bug is fixed! It was actually not a Wayland but
>> damn Gnome CSD (client-side decorations). The calculation for the dialog
>> size was not correct when CSD is used; that is now fixed. The same app will
>> now correctly work on both Wayland and X11.
>> There is one issue with the Gnome and GL examples, though: they run
>> without decorations. It seems the same option that is needed to draw on the
>> canvas is the one that tells it NOT to draw the decorations. I lost so much
>> time with damn Gnome CSD. Here, for another project, I have no motivation
>> to touch that again. In KDE and all other DEs, it works properly and
>> normally.
>>
>>  - I added an SNI tray implementation for modern Linux distributions. It
>> is based on GIO and GDBus, so there are no new dependencies besides GTK. I
>> extracted the old tray code from iupgtk_dialog to the iupgtk_tray_xembed.c
>> file. The new implementation is in iupgtk_tray_sni.c.
>> I have a build tag `xembed` if any user would specifically want old tray
>> support. You can add a similar build option. XEmbed tray support is
>> deprecated in GTK3; tray support was removed in GTK4, so some fallbacks do
>> not make sense. All other distros have switched and support only SNI.
>> QSystray from Qt is the only one left that supports both XEmbed and SNI.
>>
>> - GTK now also supports the TABDRAGGABLE attribute
>>
>>  - Also, for modern Linux, a small but important change: `xdg-open` is
>> now used instead of hard-coded browser names.
>>
>>  - The iup_thread.c is fixed; there was some error on exit, double free.
>> Also, support for pthreads on Apple (and Motif) is added.
>>
>> - Both GTK and Cocoa will now use themed icons for IupTree icons.
>>
>> - GTK and Cocoa support a new attribute for IupToggle - SWITCH. When
>> enabled, the toggle will use GtkSwitch and NSSwitch native controls,
>> respectively.
>>
>> - All platforms now support DARKMODE global attribute, and
>> THEMECHANGED_CB callback. It can be useful to respond to changes, e.g., for
>> an image, a logo, whatever.
>>
>> - Motif also did get some love! The issue with icons with a black square
>> in the taskbar and window is now fixed! Also, Motif did get support for
>> both XEmbed and SNI tray - because why not! Motif is cool. XEmbed
>> implementation only uses standard X libraries. For SNI implementation, the
>> plain libdbus-1 is used. Similar implementation to GTK/GIO/GDBus, just a
>> different library. It supports both dynamic and runtime linking via dlopen
>> for the dbus library. Basically, that DBus implementation can be used
>> everywhere, and also for GTK2, but TRAY has no drivers. There are no iupdrv
>> functions for TRAY.
>> All the drawing issues with Motif are fixed! Before, it would crash
>> whenever drawing was used. There is now only one bug I notice, with the
>> `detachbox` example. Maybe I will try to fix it sometimes, but it is
>> tough to debug X apps when they just crash with the famous X messages.
>>
>> - Windows also got some updates. Now TaskDialog is used instead of the
>> old MessageDlg. Vista is, anyway, a minimal version. TaskDialog looks much
>> nicer, offers more options, and is a drop-in replacement. But more
>> importantly, its decorations can be made to follow the modern system theme.
>> All dialogs, including the new message dialog, will now change and follow
>> the system and user preferences with decorations.
>>
>> - And last, but not least, the new Edge Webview2 browser for Windows! I
>> added an implementation for the Windows 10/11 Edge browser. It follows the
>> same method as the `webview/webview` library, using a custom loader to find
>> and load the real library. Because why be simple when it can be so
>> complicated for no apparent reason? Anyway, there are no additional
>> distribution requirements; the WebView2Loader.dll is avoided, and the
>> custom solution handles everything.
>> The Cocoa WKWebView browser has been heavily updated, along with the
>> WebKitGTK browser. GTK browser now supports everything via dlopen. I am
>> using it like that. There is no way to support all the library combinations
>> across all the different distros and whatnot. With runtime linking,
>> everything just works. Of course, I also tested with the real linking
>> without dlopen. All browsers should now have equal features.
>> Because now both Windows and GTK (when used with dlopen) can return
>> failure to find the library, they both set the
>> same IUP_WEBBROWSER_MISSING_LIB attr the user can check.
>>
>> That is it for now. You can check all changes in my repo. The Cocoa
>> update is just one huge commit; I didn't bother because everything is
>> updated. After that, you can follow the changes. You can check my
>> bind_cgo.go file for CFLAGS/LDFLAGS and pkgconfig config, but besides EGL,
>> there are no new dependencies (if you use dlopen define for Motif Dbus SNI
>> tray, or dbus-1 for Motif, then it's new). Just add Cocoa files to your
>> build system, and that is it, nothing else.
>>
>> I hope you are interested in adding most of these changes.
>>
>> Cheers,
>> Milan
>>
>> _______________________________________________
>> Iup-users mailing list
>> Iup...@li...
>> https://lists.sourceforge.net/lists/listinfo/iup-users
>>
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users
>

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div>

<div>
<pre aria-label="Texto traducido: You&#39;re right, the variable is set to 1. But I have no idea what that variable does in this distro, which, as far as I know, has no relation to Ubuntu." class="tw-data-text tw-text-large tw-ta" data-placeholder="Traducci&oacute;n" data-ved="2ahUKEwiIzJOwyd6QAxVlm2oFHcHtKAIQ3ewLegQICxAU" dir="ltr" id="tw-target-text" role="text" style="text-align:left" tabindex="-1"><span class="Y2IQFc" lang="en">You&#39;re right, the variable is set to 1. But I have no idea what that variable does in this distro, which, as far as I know, has no relation to Ubuntu.</span></pre>

<div dir="ltr"><span class="Y2IQFc" lang="en">Regards</span></div>

<div>&nbsp;
<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Enviar:</b>&nbsp;jueves 6 de noviembre de 2025 a las 15:15<br/>
<b>De:</b>&nbsp;&quot;Milan Nikolic&quot; &lt;gen...@gm...&gt;<br/>
<b>Para:</b>&nbsp;&quot;IUP discussion list.&quot; &lt;iup...@li...&gt;<br/>
<b>CC:</b>&nbsp;&quot;Germ&aacute;n Arias&quot; &lt;ger...@gm...&gt;<br/>
<b>Asunto:</b>&nbsp;Re: [Iup-users] Problem with iup 3.32</div>

<div name="quoted-content">
<div>Hi,
<div>&nbsp;</div>

<div>From the code, the&nbsp;only reason why the GLOBALMENU is set to YES can be that you have &#96;UBUNTU_MENUPROXY&#96; env set? However, that was only used on some older Ubuntu versions, and it is no longer used.</div>
</div>
&nbsp;

<div class="gmail_quote gmail_quote_container">
<div class="gmail_attr">On Thu, Nov 6, 2025 at 9:06&#8239;PM Germ&aacute;n Arias via Iup-users &lt;<a href="mailto:iup...@li..." onclick="" target="_blank">iup...@li...</a>&gt; wrote:</div>

<blockquote class="gmail_quote" style="margin: 0.0px 0.0px 0.0px 0.8ex;border-left: 1.0px solid rgb(204,204,204);padding-left: 1.0ex;">Hi, I&#39;ve solved this. I was using the binaries, so I compiled the libraries from source code, but I got the same result. I looked at the IUP GTK code and realized that to get the menu size, it checks if there&#39;s a global menu. If there is, it returns zero. So I added the following line to my project:<br/>
<br/>
IupSetGlobal(&quot;GLOBALMENU&quot;,&quot;No&quot;);<br/>
<br/>
And this solved the problem. For some reason in this system (PCLinuxOS) this returns Yes, although I haven&#39;t set it anywhere.<br/>
<br/>
Regards<br/>
Germ&aacute;n<br/>
<br/>
<br/>
Enviar:&nbsp;mi&eacute;rcoles 18 de junio de 2025 a las 18:01<br/>
De:&nbsp;&quot;Germ&aacute;n Arias&quot; &lt;<a href="mailto:ger...@gm..." onclick="" target="_blank">ger...@gm...</a>&gt;<br/>
Para:&nbsp;&quot;iup-user&quot; &lt;<a href="mailto:iup...@li..." onclick="" target="_blank">iup...@li...</a>&gt;<br/>
Asunto:&nbsp;Problem with iup 3.32<br/>
<br/>
Hi, I update to iup 3.32 and compiling the file example3_5.c at tutorial, at the displayed window the toolbar overlaps the menu. This is in xfce using gtk 3. Not sure if Xfce is the problem.<br/>
Regards.<br/>
&nbsp;<br/>
<br/>
<br/>
_______________________________________________<br/>
Iup-users mailing list<br/>
<a href="mailto:Iup...@li..." onclick="" target="_blank">Iup...@li...</a><br/>
<a href="https://lists.sourceforge.net/lists/listinfo/iup-users" target="_blank">https://lists.sourceforge.net/lists/listinfo/iup-users</a></blockquote>
</div>
</div>
</div>
</div>
</div></div></body></html>

Hi,

>From the code, the only reason why the GLOBALMENU is set to YES can be that
you have `UBUNTU_MENUPROXY` env set? However, that was only used on some
older Ubuntu versions, and it is no longer used.

On Thu, Nov 6, 2025 at 9:06 PM Germán Arias via Iup-users <
iup...@li...> wrote:

> Hi, I've solved this. I was using the binaries, so I compiled the
> libraries from source code, but I got the same result. I looked at the IUP
> GTK code and realized that to get the menu size, it checks if there's a
> global menu. If there is, it returns zero. So I added the following line to
> my project:
>
> IupSetGlobal("GLOBALMENU","No");
>
> And this solved the problem. For some reason in this system (PCLinuxOS)
> this returns Yes, although I haven't set it anywhere.
>
> Regards
> Germán
>
>
> Enviar: miércoles 18 de junio de 2025 a las 18:01
> De: "Germán Arias" <ger...@gm...>
> Para: "iup-user" <iup...@li...>
> Asunto: Problem with iup 3.32
>
> Hi, I update to iup 3.32 and compiling the file example3_5.c at tutorial,
> at the displayed window the toolbar overlaps the menu. This is in xfce
> using gtk 3. Not sure if Xfce is the problem.
> Regards.
>
>
>
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users
>

Hi, I've solved this. I was using the binaries, so I compiled the libraries from source code, but I got the same result. I looked at the IUP GTK code and realized that to get the menu size, it checks if there's a global menu. If there is, it returns zero. So I added the following line to my project:

IupSetGlobal("GLOBALMENU","No");

And this solved the problem. For some reason in this system (PCLinuxOS) this returns Yes, although I haven't set it anywhere.

Regards
Germán


Enviar: miércoles 18 de junio de 2025 a las 18:01
De: "Germán Arias" <ger...@gm...>
Para: "iup-user" <iup...@li...>
Asunto: Problem with iup 3.32

Hi, I update to iup 3.32 and compiling the file example3_5.c at tutorial, at the displayed window the toolbar overlaps the menu. This is in xfce using gtk 3. Not sure if Xfce is the problem.
Regards.
 

Hi,

Very interesting. Yes, I will definitely take a look at this. The problem
is when. But I will keep you posted.

Thanks for the contribution!

Em ter., 28 de out. de 2025 às 21:02, Milan Nikolic <gen...@gm...>
escreveu:

> Hello,
>
> I have been working on this for some time now for my Go bindings here
> https://github.com/gen2brain/iup-go, and I do not see any issue with
> Cocoa anymore.
> There are 60+ examples in the repo, and they all now work correctly. There
> is no need for an .app bundle anymore; the .xib files are compiled to .nib
> and included in the generated file (there is a shell script for that).
> Those .xib files were previously designed in Xcode; there may be a way to
> recreate them programmatically, but then again, it could also make it
> easier to design future controls.
> The menu is now dynamically generated, and the default macOS menu will be
> shown even if started from the terminal. Also, the app will properly start
> in the foreground even when started from the terminal.
> I tested the examples on macOS 14, 15, and 26, as well as on old 10.15.
> 10.15 is the minimum requirement. Go 1.21 is the last version with support
> for macOS 10.15, and also, `brew` can be made to work on 10.15. I don't
> think any effort to support older versions makes sense.
> I spent a lot of time trying to use the native Tab controls, the new API,
> and the old API; everything was minimal and unusable. Finally, the
> custom-drawn tabs implementation is now used. I started with ENTabView
> (MIT-licensed), and now it is just based on that; it doesn't have any
> similarities, but I left a note that it is based on that. Tabs now look
> nice, follow the native theme colors, and support all available features,
> including some new ones (TABDRAGGABLE).
> There are also some Cocoa-specific attributes, like TOLERANCE for
> IupTimer, so you can save the user's battery if precision is not that
> important; then CONTEXTMENU, which macOS has everywhere - we can use them
> or disable them with NULL (sometimes they get in the way).
> There is also support for `NSOpenGL` for the GL backend, but I could not
> test it in the VM. I do not have real hardware, nor does anyone around me
> have Apple hw to test. I would appreciate it if anyone could test and let
> me know what is happening. There are just a few steps:
>
>     brew install go
>     git clone https://github.com/gen2brain/iup-go
>     cd iup-go/examples/glmodern
>     go build -tags gl
>
> Only GL examples need `-tags gl`, for all others, plain `go build` is
> enough (WebBrowser examples need `-tags web`). You can also install GTK
> with:
>
>     brew install gtk+3 pkgconf
>
> Then you can build with `go build -tags gtk` to compare the GTK and Cocoa
> implementations. Everything works, but there may be some issues with some
> dynamically updated attributes or some edge cases. It really needs a fresh
> look from someone else.
>
> There are more changes:
>
>  - GTK now also uses runtime checks for proper backend detection (X11 and
> Wayland on Linux). There is a new EGL backend, and I am using it for both
> X11 and Wayland. The old GLX backend is now fixed as well; it was not very
> usable. I was getting only a black screen with my glmodern example, but now
> it is fixed. I use the GLX backend now only for Motif and GTK2.
>
> - The annoying Wayland bug is fixed! It was actually not a Wayland but
> damn Gnome CSD (client-side decorations). The calculation for the dialog
> size was not correct when CSD is used; that is now fixed. The same app will
> now correctly work on both Wayland and X11.
> There is one issue with the Gnome and GL examples, though: they run
> without decorations. It seems the same option that is needed to draw on the
> canvas is the one that tells it NOT to draw the decorations. I lost so much
> time with damn Gnome CSD. Here, for another project, I have no motivation
> to touch that again. In KDE and all other DEs, it works properly and
> normally.
>
>  - I added an SNI tray implementation for modern Linux distributions. It
> is based on GIO and GDBus, so there are no new dependencies besides GTK. I
> extracted the old tray code from iupgtk_dialog to the iupgtk_tray_xembed.c
> file. The new implementation is in iupgtk_tray_sni.c.
> I have a build tag `xembed` if any user would specifically want old tray
> support. You can add a similar build option. XEmbed tray support is
> deprecated in GTK3; tray support was removed in GTK4, so some fallbacks do
> not make sense. All other distros have switched and support only SNI.
> QSystray from Qt is the only one left that supports both XEmbed and SNI.
>
> - GTK now also supports the TABDRAGGABLE attribute
>
>  - Also, for modern Linux, a small but important change: `xdg-open` is now
> used instead of hard-coded browser names.
>
>  - The iup_thread.c is fixed; there was some error on exit, double free.
> Also, support for pthreads on Apple (and Motif) is added.
>
> - Both GTK and Cocoa will now use themed icons for IupTree icons.
>
> - GTK and Cocoa support a new attribute for IupToggle - SWITCH. When
> enabled, the toggle will use GtkSwitch and NSSwitch native controls,
> respectively.
>
> - All platforms now support DARKMODE global attribute, and THEMECHANGED_CB
> callback. It can be useful to respond to changes, e.g., for an image, a
> logo, whatever.
>
> - Motif also did get some love! The issue with icons with a black square
> in the taskbar and window is now fixed! Also, Motif did get support for
> both XEmbed and SNI tray - because why not! Motif is cool. XEmbed
> implementation only uses standard X libraries. For SNI implementation, the
> plain libdbus-1 is used. Similar implementation to GTK/GIO/GDBus, just a
> different library. It supports both dynamic and runtime linking via dlopen
> for the dbus library. Basically, that DBus implementation can be used
> everywhere, and also for GTK2, but TRAY has no drivers. There are no iupdrv
> functions for TRAY.
> All the drawing issues with Motif are fixed! Before, it would crash
> whenever drawing was used. There is now only one bug I notice, with the
> `detachbox` example. Maybe I will try to fix it sometimes, but it is
> tough to debug X apps when they just crash with the famous X messages.
>
> - Windows also got some updates. Now TaskDialog is used instead of the old
> MessageDlg. Vista is, anyway, a minimal version. TaskDialog looks much
> nicer, offers more options, and is a drop-in replacement. But more
> importantly, its decorations can be made to follow the modern system theme.
> All dialogs, including the new message dialog, will now change and follow
> the system and user preferences with decorations.
>
> - And last, but not least, the new Edge Webview2 browser for Windows! I
> added an implementation for the Windows 10/11 Edge browser. It follows the
> same method as the `webview/webview` library, using a custom loader to find
> and load the real library. Because why be simple when it can be so
> complicated for no apparent reason? Anyway, there are no additional
> distribution requirements; the WebView2Loader.dll is avoided, and the
> custom solution handles everything.
> The Cocoa WKWebView browser has been heavily updated, along with the
> WebKitGTK browser. GTK browser now supports everything via dlopen. I am
> using it like that. There is no way to support all the library combinations
> across all the different distros and whatnot. With runtime linking,
> everything just works. Of course, I also tested with the real linking
> without dlopen. All browsers should now have equal features.
> Because now both Windows and GTK (when used with dlopen) can return
> failure to find the library, they both set the
> same IUP_WEBBROWSER_MISSING_LIB attr the user can check.
>
> That is it for now. You can check all changes in my repo. The Cocoa update
> is just one huge commit; I didn't bother because everything is
> updated. After that, you can follow the changes. You can check my
> bind_cgo.go file for CFLAGS/LDFLAGS and pkgconfig config, but besides EGL,
> there are no new dependencies (if you use dlopen define for Motif Dbus SNI
> tray, or dbus-1 for Motif, then it's new). Just add Cocoa files to your
> build system, and that is it, nothing else.
>
> I hope you are interested in adding most of these changes.
>
> Cheers,
> Milan
>
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users
>

Hello,

I have been working on this for some time now for my Go bindings here
https://github.com/gen2brain/iup-go, and I do not see any issue with Cocoa
anymore.
There are 60+ examples in the repo, and they all now work correctly. There
is no need for an .app bundle anymore; the .xib files are compiled to .nib
and included in the generated file (there is a shell script for that).
Those .xib files were previously designed in Xcode; there may be a way to
recreate them programmatically, but then again, it could also make it
easier to design future controls.
The menu is now dynamically generated, and the default macOS menu will be
shown even if started from the terminal. Also, the app will properly start
in the foreground even when started from the terminal.
I tested the examples on macOS 14, 15, and 26, as well as on old 10.15.
10.15 is the minimum requirement. Go 1.21 is the last version with support
for macOS 10.15, and also, `brew` can be made to work on 10.15. I don't
think any effort to support older versions makes sense.
I spent a lot of time trying to use the native Tab controls, the new API,
and the old API; everything was minimal and unusable. Finally, the
custom-drawn tabs implementation is now used. I started with ENTabView
(MIT-licensed), and now it is just based on that; it doesn't have any
similarities, but I left a note that it is based on that. Tabs now look
nice, follow the native theme colors, and support all available features,
including some new ones (TABDRAGGABLE).
There are also some Cocoa-specific attributes, like TOLERANCE for IupTimer,
so you can save the user's battery if precision is not that important; then
CONTEXTMENU, which macOS has everywhere - we can use them or disable them
with NULL (sometimes they get in the way).
There is also support for `NSOpenGL` for the GL backend, but I could not
test it in the VM. I do not have real hardware, nor does anyone around me
have Apple hw to test. I would appreciate it if anyone could test and let
me know what is happening. There are just a few steps:

    brew install go
    git clone https://github.com/gen2brain/iup-go
    cd iup-go/examples/glmodern
    go build -tags gl

Only GL examples need `-tags gl`, for all others, plain `go build` is
enough (WebBrowser examples need `-tags web`). You can also install GTK
with:

    brew install gtk+3 pkgconf

Then you can build with `go build -tags gtk` to compare the GTK and Cocoa
implementations. Everything works, but there may be some issues with some
dynamically updated attributes or some edge cases. It really needs a fresh
look from someone else.

There are more changes:

 - GTK now also uses runtime checks for proper backend detection (X11 and
Wayland on Linux). There is a new EGL backend, and I am using it for both
X11 and Wayland. The old GLX backend is now fixed as well; it was not very
usable. I was getting only a black screen with my glmodern example, but now
it is fixed. I use the GLX backend now only for Motif and GTK2.

- The annoying Wayland bug is fixed! It was actually not a Wayland but damn
Gnome CSD (client-side decorations). The calculation for the dialog size
was not correct when CSD is used; that is now fixed. The same app will now
correctly work on both Wayland and X11.
There is one issue with the Gnome and GL examples, though: they run without
decorations. It seems the same option that is needed to draw on the canvas
is the one that tells it NOT to draw the decorations. I lost so much time
with damn Gnome CSD. Here, for another project, I have no motivation to
touch that again. In KDE and all other DEs, it works properly and normally.

 - I added an SNI tray implementation for modern Linux distributions. It is
based on GIO and GDBus, so there are no new dependencies besides GTK. I
extracted the old tray code from iupgtk_dialog to the iupgtk_tray_xembed.c
file. The new implementation is in iupgtk_tray_sni.c.
I have a build tag `xembed` if any user would specifically want old tray
support. You can add a similar build option. XEmbed tray support is
deprecated in GTK3; tray support was removed in GTK4, so some fallbacks do
not make sense. All other distros have switched and support only SNI.
QSystray from Qt is the only one left that supports both XEmbed and SNI.

- GTK now also supports the TABDRAGGABLE attribute

 - Also, for modern Linux, a small but important change: `xdg-open` is now
used instead of hard-coded browser names.

 - The iup_thread.c is fixed; there was some error on exit, double free.
Also, support for pthreads on Apple (and Motif) is added.

- Both GTK and Cocoa will now use themed icons for IupTree icons.

- GTK and Cocoa support a new attribute for IupToggle - SWITCH. When
enabled, the toggle will use GtkSwitch and NSSwitch native controls,
respectively.

- All platforms now support DARKMODE global attribute, and THEMECHANGED_CB
callback. It can be useful to respond to changes, e.g., for an image, a
logo, whatever.

- Motif also did get some love! The issue with icons with a black square in
the taskbar and window is now fixed! Also, Motif did get support for both
XEmbed and SNI tray - because why not! Motif is cool. XEmbed implementation
only uses standard X libraries. For SNI implementation, the plain libdbus-1
is used. Similar implementation to GTK/GIO/GDBus, just a different
library. It supports both dynamic and runtime linking via dlopen for the
dbus library. Basically, that DBus implementation can be used everywhere,
and also for GTK2, but TRAY has no drivers. There are no iupdrv functions
for TRAY.
All the drawing issues with Motif are fixed! Before, it would crash
whenever drawing was used. There is now only one bug I notice, with the
`detachbox` example. Maybe I will try to fix it sometimes, but it is
tough to debug X apps when they just crash with the famous X messages.

- Windows also got some updates. Now TaskDialog is used instead of the old
MessageDlg. Vista is, anyway, a minimal version. TaskDialog looks much
nicer, offers more options, and is a drop-in replacement. But more
importantly, its decorations can be made to follow the modern system theme.
All dialogs, including the new message dialog, will now change and follow
the system and user preferences with decorations.

- And last, but not least, the new Edge Webview2 browser for Windows! I
added an implementation for the Windows 10/11 Edge browser. It follows the
same method as the `webview/webview` library, using a custom loader to find
and load the real library. Because why be simple when it can be so
complicated for no apparent reason? Anyway, there are no additional
distribution requirements; the WebView2Loader.dll is avoided, and the
custom solution handles everything.
The Cocoa WKWebView browser has been heavily updated, along with the
WebKitGTK browser. GTK browser now supports everything via dlopen. I am
using it like that. There is no way to support all the library combinations
across all the different distros and whatnot. With runtime linking,
everything just works. Of course, I also tested with the real linking
without dlopen. All browsers should now have equal features.
Because now both Windows and GTK (when used with dlopen) can return failure
to find the library, they both set the same IUP_WEBBROWSER_MISSING_LIB attr
the user can check.

That is it for now. You can check all changes in my repo. The Cocoa update
is just one huge commit; I didn't bother because everything is
updated. After that, you can follow the changes. You can check my
bind_cgo.go file for CFLAGS/LDFLAGS and pkgconfig config, but besides EGL,
there are no new dependencies (if you use dlopen define for Motif Dbus SNI
tray, or dbus-1 for Motif, then it's new). Just add Cocoa files to your
build system, and that is it, nothing else.

I hope you are interested in adding most of these changes.

Cheers,
Milan

Is it possible to call IUP from AOT compiled CLI web assembly code?

On 2025-08-28 20:42, Luiz Henrique de Figueiredo wrote:
> We are considering removing the targets below from the Lua Makefile:
> aix bsd freebsd mingw solaris
> 
> The motivation is that we have no access to these platforms and so no
> way to test these targets and their recipes.
> 
> Does anyone use those targets?
> All feedback welcome.
> --lhf
> 

--

[As well as a lua-l list reply, this message is being cross-posted
to the Tecgraf "iup-users" mailing list.]

--

The Tecgraf IM/CD/IUP projects strive to be portable, and especially
strives to use an all-singing, all-dancing platform tailoring file
*/src/tecmake.mak.  For example, in IUP:

        https://sourceforge.net/p/iup/iup/HEAD/tree/trunk/iup/tecmake.mak

We see:

# Known Platforms

UNAMES = Linux24 Linux24g3 Linux24g3_64 Linux26 Linux26_64 Linux26g4 Linux26g4_64 Linux26_ia64 FreeBSD54 SunOS57 SunOS58 SunOS510 SunOS510_x86 AIX43 IRIX65 IRIX6465
# [...]

ifneq ($(findstring AIX, $(TEC_UNAME)), ) [...]
endif

-------

There's more platform-specific stuff, in tec_uname.  I rewrote
Tecgraf's version for lglicua:

        https://sourceforge.net/p/lglicua/code/ci/master/tree/build/support/tec_uname

Here's a terse extract of some of the things it's looking at:

ComputeTecUname() {
    # Base Definitions
    TEC_SYSNAME=`uname -s`
    TEC_SYSVERSION=`uname -r|cut -f1 -d.`
    TEC_SYSMINOR=`uname -r|cut -f2 -d.`
    TEC_SYSARCH=`uname -m`

    # Fixes
    case "$TEC_SYSNAME" in
        SunOS | IRIX )
            TEC_SYSARCH=`uname -p`
            ;;
        AIX ) [...]
        Darwin )
            TEC_SYSNAME=MacOS
            TEC_SYSVERSION=`sw_vers -productVersion|cut -f1 -d.`
            TEC_SYSMINOR=`sw_vers -productVersion|cut -f2 -d.`
            TEC_SYSARCH=`uname -p`
            UNAME_SFX="$TEC_SYSARCH"
            ;;

        FreeBSD ) [...]
        GNU/kFreeBSD ) [...]
        SunOS ) [...]
    esac
}

--------

There may be interest in maintaining portability amongst the wider
set of users who use Lua alongside Tecgraf's toolkits.

cheers,  s-b etc

Em qua., 30 de jul. de 2025, 09:02, Antonio Scuri <ant...@gm...>
escreveu:

>
> You can workaround it, by switching the order, print(srv == txt) should
> work in this case, but it will not compare two Iup Handles.
>

Thanks, I'm now holding an empty table on each object (h.id = {}) to serve
as a comparable unique identifier.
It works, but I still need some tweaks to identify 'h' as an IUP object to
be sure that I can index it correctly.
I wonder if there's any robust way for this check (e.g., iup.ishandle(h)).
Maybe some getmetatable test?

Thanks!

Yes, there is a limitation on the equal operator. The second parameter
should be able to be anything. It is a bug.

You can workaround it, by switching the order, print(srv == txt) should
work in this case, but it will not compare two Iup Handles.

Best,
Scuri


Em qua., 30 de jul. de 2025 às 08:16, Francisco Sant'anna <
fra...@gm...> escreveu:

> Hi,
>
> This (minimal) code fails when comparing an IUP object with a socket
> handle:
>
> require "iuplua"
> s = require "socket"
> txt = iup.text{}
> srv = s.bind("*", 0)
> print(txt == srv)
>
> lua5.4: tst.lua:5: bad argument #2 to 'eq' (iupHandle expected, got
> tcp{server})
>
> I believe it should print "false".
>
> In the actual code, I have a list of listeners waiting for events. This
> list is indexed by these handles.
>
> Thanks,
> Francisco
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users
>

Hi,

This (minimal) code fails when comparing an IUP object with a socket handle:

require "iuplua"
s = require "socket"
txt = iup.text{}
srv = s.bind("*", 0)
print(txt == srv)

lua5.4: tst.lua:5: bad argument #2 to 'eq' (iupHandle expected, got
tcp{server})

I believe it should print "false".

In the actual code, I have a list of listeners waiting for events. This
list is indexed by these handles.

Thanks,
Francisco

Reading the documentation, passing IUP_CONTINUE to the callback function
should both update the NUMLIN and NUMCOL values and insert the loaded data
at the same time.

This doesn't happen; for example, with a 1x1 matrix and a 10x10 data file,
the matrix is only resized and the data is loaded into the cell 1:1.

I think the num_lin and num_col values are not updated in the
iupmatex_clipboard.c file, specifically at this point:
********************************
  num_lin = IupGetInt(ih, "NUMLIN");
  num_col = IupGetInt(ih, "NUMCOL");

  pastesize_cb = (IFnii)IupGetCallback(ih, "PASTESIZE_CB");
  if (pastesize_cb)
  {
    int vis_num_lin = iMatrixExGetVisibleNumLin(ih, lin, data_num_lin);
    int vis_num_col = iMatrixExGetVisibleNumCol(ih, col, data_num_col);
    if (lin+vis_num_lin>num_lin ||
        col+vis_num_col>num_col)
    {
      int ret = pastesize_cb(ih, lin+vis_num_lin, col+vis_num_col);
      if (ret == IUP_IGNORE)
        return;
      else if (ret == IUP_CONTINUE)
      {
        if (lin+vis_num_lin>num_lin) IupSetInt(ih, "NUMLIN",
lin+vis_num_lin);
        if (col+vis_num_col>num_col) IupSetInt(ih, "NUMCOL",
col+vis_num_col);
      }
    }
  }

  iMatrixExPasteSetData(ih, data, data_num_lin, data_num_col, sep, lin,
col, num_lin, num_col, busyname);
*****************************

P.S.: The documentation is incorrect in describing the function values;
those listed refer to the busy_cb function.

Attached is a test carried out with IupLuaScripter where I highlight what
was said above, the IupMatrix control scrolls by 1 line unlike the
Scintilla control which scrolls by 3 lines.

Il giorno mer 23 lug 2025 alle ore 13:50 Antonio Scuri <
ant...@gm...> ha scritto:

> I don't recall changing the wheel system setting. What can happen is that
> the number of scrolling lines be dynamically configured. But I also made a
> few tests here and IupMatrix is scrolling normal like other controls.
>
> Em qua., 23 de jul. de 2025 às 07:10, Maurizio Petrarota <
> mew...@gm...> escreveu:
>
>> In iupmatrix, mouse wheel scrolling is set to 1 in Windows, not honoring
>> the current system setting (the default is 3). Is there a way to change
>> this behavior, so as to make it consistent with other controls (e.g.
>> scintilla)?
>> Thanks
>>
>>
>> _______________________________________________
>> Iup-users mailing list
>> Iup...@li...
>> https://lists.sourceforge.net/lists/listinfo/iup-users
>>
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users
>


-- 
Saluti,
Maurizio

I don't recall changing the wheel system setting. What can happen is that
the number of scrolling lines be dynamically configured. But I also made a
few tests here and IupMatrix is scrolling normal like other controls.

Em qua., 23 de jul. de 2025 às 07:10, Maurizio Petrarota <
mew...@gm...> escreveu:

> In iupmatrix, mouse wheel scrolling is set to 1 in Windows, not honoring
> the current system setting (the default is 3). Is there a way to change
> this behavior, so as to make it consistent with other controls (e.g.
> scintilla)?
> Thanks
>
>
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users
>

In iupmatrix, mouse wheel scrolling is set to 1 in Windows, not honoring
the current system setting (the default is 3). Is there a way to change
this behavior, so as to make it consistent with other controls (e.g.
scintilla)?
Thanks

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi, I update to iup 3.32 and compiling the file example3_5.c at tutorial, at the displayed window the toolbar overlaps the menu. This is in xfce using gtk 3. Not sure if Xfce is the problem.</div>

<div>Regards.</div>

<div>&nbsp;</div></div></body></html>

In IupTree, I've set the 'SHOWDRAGDROP' attribute to 'YES', keeping
all other settings as default. When I drag a node within the Tree
frame, the drag icon(the icon of node) flickers constantly.

I'm unsure if I've done something wrong, or if this is a bug, or
something related to Windows or DPI settings.

I hope you can help me.

Thanks.

On 2025-05-12 01:58, Stefan Heinzmann via Iup-users wrote:
> Hi Brenton,
> 
> thank you very much for your detailed reply. I was aware of your 
> project, from the mailing list. However, I have difficulties seeing how 
> it addresses the main problem I referred to. In my opinion, the kernel 
> version should be completely immaterial, as you can have any 
> distribution on any kernel (within reason), and I don't understand how a 
> library like this can depend on the kernel version. Something looks 
> distinctly wrong.
> 
> Ubuntu does have certain kernel versions associated with each release, 
> and that appears to be what tecmake relies on. But this is only true for 
> host installs of Ubuntu, not even when running an Ubuntu-based 
> container, and certainly not with other distributions.
> 
> Your approach to finding the right Webkit version is going in the right 
> direction, as it doesn't appear to depend on the kernel, but on the 
> distribution, but in a way it is even more cumbersome, as there are at 
> least as many distributions. You effectively still require Ubuntu.
> [...]

[Apologies for typos; my morning coffee is still kicking in.]

G'day Stefan,

As I said, not only does lglicua work on specified versions of:

    * Debian-based systems:

        - Debian, Ubuntu, LinuxMint, MX and Kali;

but it also works on specified versions of:

    * Red Hat versions:

        - CentOS-7, CentOS-Stream-7, CentOS-Stream-8, Rocky.

This is all done with the modified tecmake.mak and tec_uname
files that I quoted excerpts from, as well as with more
build tailoring and package naming in 
LGLICUA/svn/assistant-database.lua.

Stuffed if I know where you got your idea:

> You effectively still require Ubuntu.

(FYI, I develop on LinuxMint, an Ubuntu derivative...)

I stomp on the package build files when package building is
initiated from within the Assistant (inside LGLICUA/build,
"quirky" script named "./q").  If you try to build
independently, you will miss out on the changeover.  If you
were to look at the sources as checked out from the repository
(note that the Assistant also uses the SVN repository, as it
often taken months for fixes to be bundled up into a new
release), then you would see the Tecgraf versions of the build
system, verbatim.  The Assistant explicitly overrides these at
the last possible moment, when the build command is given, as
it knows that the SVN version is   This may
have caused confusion.

--------------------

As new distributions get released, and as packages are updated,
it's quite possible that some of the connections that are quoted
in my script may break; I know that there are assumptions, and
that some of them may be brittle.

But, especially when looking across the spread of distributions
above, I tried, and tried, and tried to find some common ground
where, for a specified package, you could directly query an
"oracle" to find out, for a library package (e.g. webkit2-gtk),
details such as:

        * Exact Distro package manager name (e.g. webkit2-gtk-4.0);

        * Include path(s) (compiler -I<PATH>);

        * Library path(s) (compiler -L<PATH>); and/or 

        * Exact library name(s) to feed to the linker.

Some distributions (I forget which) do provide facilities for
these sorts of queries, but it can't be depended on.  My hacking
of tec_uname was done only after I'd exhausted all other avenues
I could find (a non-trivial search spanning multiple weeks).

--------------------

I've appealed to Antonio Scuri, the maintainer of many things in
Tecgraf, including IM/CD/IUP.  While we sorted out quite a number
of things in the early days of my involvement, consideration of my
input has gradually dried up.  I suspect that:

        1. As I noted in my previous message, I had the freedom to
           look at the build system from a GNU/Linux-only
           perspective, whereas the original system supports a
           wider range of OSes/VMs/emulations/clients.  Scuri may
           be loathe to perform the merger, and I don't know of
           any specification of the entire set of environments,
           packages and ultimately behaviours that tecmake.mak
           etc. might be required to support;

        2. CD and IM, and to a lesser extent, IUP, are somewhat
           stalled and/or marked for no further development; and

        3. Tecmake.mak, and other build files, are used in other
           projects inside Tecgraf, and so maintaining
           compatibility with these overrides any suggested
           improvements to the build system.

Scuri's had a year to look at my last lglicua release (0.1-beta1),
and hasn't seen fit to change the packages at all.  (I still
reckon that my use of Make's "filter" builtin is better than
the current heavy use of "findstring".)

[Source warnings have also increased, as compilers, especially
GCC, have become better at flow tracing, dodgy construct
identification, and also have more verbose error messages.
Sadly, sometimes library sources have been incorporated when at
a particular version, then tailored to fit in to the IM/CD/IUP
framework.  Newer versions of these libraries have been modified
to address the improved diagnostic capabilities of compilers,
but re-engineering the connection, by removing the old internal
sources, and then referencing the code as an external library,
is a BIG task, and the incentives for doing so (e.g. code
hygiene practices such as warning-free compilation), are not
compelling.]

cheers,

s-b etc etc etc

Hi Brenton,

thank you very much for your detailed reply. I was aware of your 
project, from the mailing list. However, I have difficulties seeing how 
it addresses the main problem I referred to. In my opinion, the kernel 
version should be completely immaterial, as you can have any 
distribution on any kernel (within reason), and I don't understand how a 
library like this can depend on the kernel version. Something looks 
distinctly wrong.

Ubuntu does have certain kernel versions associated with each release, 
and that appears to be what tecmake relies on. But this is only true for 
host installs of Ubuntu, not even when running an Ubuntu-based 
container, and certainly not with other distributions.

Your approach to finding the right Webkit version is going in the right 
direction, as it doesn't appear to depend on the kernel, but on the 
distribution, but in a way it is even more cumbersome, as there are at 
least as many distributions. You effectively still require Ubuntu.

A better way would be to rely neither on the kernel nor the 
distribution, and detect the dependencies using a configuration 
generator like the old autoconf (shudder!) or the more common CMake. 
Indeed, there is an old CMake file in the sources of iup, but I guess 
people became discouraged while trying to develop it. CMake can also 
generate .deb packages, among other package formats, so in principle 
there would be a way to automate the whole process up to the generation 
of installable packages. But I guess that would be quite an effort.

For the moment I was hoping that I can build the missing logic around 
the existing tecmake, and fool tecmake into thinking that it has a 
certain kernel when it hasn't. Or, maybe even better, to find the 
required dependencies outside, and bypass tecmake's dependency logic, 
i.e. call tecmake to build the project with the dependencies I've 
determined outside. For example, this could be done with CMake's 
ExternalProject module.

I figure that this would be much easier than replacing the entire 
tecmake, as the problems are all with the configuration logic, not the 
build itself.

I hope this makes sense to you. If you are knowledgeable enough with 
tecmake, maybe you can say how the configuration logic in tecmake can be 
bypassed, and replaced with values passed in from the outside. That 
would get me started, I think.

Cheers
Stefan


On 11/05/2025 05:49, sur-behoffski wrote:
> On 2025-05-10 01:56, Stefan Heinzmann via Iup-users wrote:
>> Hi all,
>>
>> I am building the libraries with mixed success on Linux. My problems
>> appear to originate with the system detection built into tecmake. For a
>> reason I can't find an explanation for, the Linux kernel version appears
>> to play a major role. I wonder why, can anyone here enlighten me or
>> point me to a document with the rationale?
>>
>> The problem is that you can't determine the versions of libraries
>> installed on the system from the kernel version with any reliability.
>> You can very easily have an up-to-date Ubuntu running on an old kernel,
>> for example when using containers. Containers don't include a kernel,
>> they use the kernel on the host. Having older kernels run a newer
>> distribution in the container is a common situation, and the opposite
>> also happens. Hence, the kernel version really should have no bearing at
>> all on the build process.
>>
>> Given the tecmake system as it is, I would at least need a simple way to
>> "fake" or bypass the kernel detection in a way that would match the
>> distribution used, so that the dependencies are determined correctly.
>>
>> I guess I would be able to figure this out from the tecmake sources, but
>> I was hoping there's an easier way somebody already knows about.
>>
>> Thanks for any light you can shed on the matter.
>>
>> Cheers
>> Stefan
> 
> G'day Stefan,
> 
> I've been working to bring GNU/Linux, Lua, and Tecgraf IM/CD/IUP
> together.
> 
> I have a SourceForge project called lglicua:
> 
>          L -- Lua
>          G -- GNU/Linux
>          I -- IM
>          C -- CD
>          U -- IUP
>          A -- Assistant
> 
>          https://sourceforge.net/projects/lglicua/
> 
> This has been mostly my own project, with help from Tecgraf and
> PUC-Rio Lua folks.  Because it's failed to catch the imagination,
> I'm only calling it a "beta" version.  In practice,
> 
>          https://sourceforge.net/projects/lglicua/files/
> 
> shows that releases have spanned early May 2021 to end July 2024.
> Releases are often connected to Lua and/or LuaRocks releases
> and/or bugfixes, as I whitelist these versions in the Assistant.
> 
> You can get a "hello, world" modal dialog box in only two lines:
> 
> ```
>          #!/bin/bash ../support/play-lua-tec
>          iup=require("iuplua"); iup.Message("MyApp", "hello, world")
> ```
> You don't specify the GNU/Linux distribution you are using.
> Lglicua has been tested (briefly) on [as per 0.1-beta2 release]:
> 
>          * Debian/Ubuntu family:
>                  - Debian
>                  - Kali,
>                  - Linux Mint,
>                  - MX, and
>                  Ubuntu;
> 
>          *Red Hat family:
>                  - CentOS,
>                  - CentOS-Stream, and
>                  - Rocky
> 
> Whitelisting by name and major version number is used.
> 
>          ** CentOS: Core-7, Stream-8 and Stream-9;
>          ** Debian 12.5;
>          ** Kali 2024.2;
>          ** Linux Mint 19.3, 20.3, 21.3 and newly-released 22;
>          ** MX 23.3_ahs_x64;
>          ** Rocky: 8.10, 9.3 and 9.4; and
>          ** Ubuntu: 22.04.4, 23.10 and 24.04.
> 
> Linux kernels include 3.10, 4.18, 5.4, 5.14, 5.15, 6.1, 6.5, 6.8, 6.8.11 and 6.9.8.
> 
> GCC versions span 4.8.5 (CentOS Core-7) to 13.2 (Linux Mint-22 and Ubuntu 24.04).
> 
> (Although GNU/Linux Mint 22.1 has been released, I haven't tested
> lflicua against it).
> 
> ------------------------------------------------
> 
> The Tecgraf sources for IM/CD/IUP nominate Ubuntu as the model
> distribution for GNU/Linux releases.  Looking at the sources,
> there looks to be acknowledgement for many different OSes,
> especially in "project/src/tecmake.mak".
> 
> I've looked into dependencies of libraries (GTK etc), and have
> tailored these according to distribution+release version.
> 
> --------
> 
> To your immediate difficulties:  I've encountered very similar problems
> when preparing lglicua for the wide range of distributions and
> release versions.  Two items stand out:
> 
>          1. I've replaced the IM/CD/IUP "tecmake.mak" with a rewritten
>             version of my own.  This greatly streamlines GNU/Linux
>             support, and, especially, adds support for all kernels 6.x
>             (and, hopefully,) up to 9.x.
> 
>             Library versions have a maze of dependencies, and do refer
>             to non-Linux platforms, so my rewrite may break things
>             on non-GNU/Linux platforms -- but (of course), given that
>             lglicua is, by definition, GNU/Linux, this doesn't matter.
>             In particular, look at GTK selection.  The rewritten
>             "tecmake.mak" uses (having just identified "Linux" as
>             "TEC_SYSNAME"):
> 
>                     ifneq ($(filter 3 4 5 6 7 8 9, $(TEC_SYSVERSION)), )
>                          USE_GTK3 = Yes
>                     else # [...]
> 
>             whereas the Tecgraf-shipped version uses a verbose chain
>             of Makefile "$(findstring ...)" to do the identification,
>             and this chain hasn't been updated to include Kernel 6:
> 
>                     ifneq ($(findstring Linux5, $(TEC_UNAME)), )
>                       USE_GTK3 = Yes
>                     endif
> 
>            The practical upshot of not identifying Kernel 6.x as
>            being compatible with GTK3 is that tecmake.mak gets confused
>            and lapses back to GTK2, and then library selection and
>            linking break.
> 
> 
> -------- Newer tecmake.mak: --------
> 
>> # Refine GTK default request:  Newer GNU/Linux systems get GTK3,
>> # unless GTK2 is specifically defined.
>> # 240510: CHANGED in lglicua: We incorporate a modified change of the
>> # Tecgraf IUP' r5950 change (r4.21->r4.22); the parent tested for
>> # Linux31, and only selected USE_GTK3 if, in addition, TEC_DIST is
>> # CentOS.  Here, we run this test (and, by extension, the following cygw
>> # test) if TEC_SYSNAME is Linux, but TEC_SYSVERSION is (effectively)
>> # less than 4.
>> ifdef GTK_DEFAULT
>>    ifndef USE_GTK2
>>      ifneq ($(filter linux Linux, $(TEC_SYSNAME)), )
>>        ifneq ($(filter 3 4 5 6 7 8 9, $(TEC_SYSVERSION)), )
>>          USE_GTK3 = Yes
>>        else ifneq ($(filter centos CentOS, $(TEC_DIST)), )
>>          USE_GTK3 = Yes
>>        endif
>>      else ifneq ($(filter cygw CYGW, $(TEC_UNAME)), )
>>        USE_GTK3 = Yes
>>      endif
>>    endif
>> endif
> 
> -------- Tecgraf-shipped tecmake.mak: --------
> 
>> ifneq ($(findstring Linux24, $(TEC_UNAME)), )
>>    NO_GTK_DEFAULT = Yes
>> endif
>> ifeq ($(TEC_UNAME), Linux26)
>>    NO_GTK_DEFAULT = Yes
>> endif
>> ifeq ($(TEC_UNAME), Linux26_64)
>>    NO_GTK_DEFAULT = Yes
>> endif
>>
>> ifndef NO_GTK_DEFAULT
>>    ifneq ($(findstring cygw, $(TEC_UNAME)), )
>>      GTK_DEFAULT = Yes
>>    endif
>>    ifneq ($(findstring CentOS, $(TEC_UNAME)), )
>>      GTK_DEFAULT = Yes
>>    endif
>>    ifneq ($(findstring Linux, $(TEC_UNAME)), )
>>      GTK_DEFAULT = Yes
>>    endif
>>    ifneq ($(findstring MacOS, $(TEC_UNAME)), )
>>      GTK_DEFAULT = Yes
>>    endif
>>    ifneq ($(findstring FreeBSD, $(TEC_UNAME)), )
>>      GTK_DEFAULT = Yes
>>    endif
>>    ifneq ($(findstring SunOS, $(TEC_UNAME)), )
>>      ifeq ($(TEC_SYSARCH), x86)
>>        GTK_DEFAULT = Yes
>>      endif
>>    endif
>> endif
>>
>> ifdef GTK_DEFAULT
>>    ifndef USE_GTK2
>>      ifneq ($(findstring Linux5, $(TEC_UNAME)), )
>>        USE_GTK3 = Yes
>>      endif
>>      ifneq ($(findstring Linux4, $(TEC_UNAME)), )
>>        USE_GTK3 = Yes
>>      endif
>>      ifneq ($(findstring Linux31, $(TEC_UNAME)), )
>>        USE_GTK3 = Yes
>>      endif
>>      ifneq ($(findstring cygw, $(TEC_UNAME)), )
>>        USE_GTK3 = Yes
>>      endif
>>      #Homebrew
>>      #ifneq ($(findstring MacOS10, $(TEC_UNAME)), )
>>      #  USE_GTK3 = Yes
>>      #endif
>>    endif
>> endif
>>
> 
> 
> -------- end of tecmake.mak comparison --------
> 
> 
> 
>          2. I had serious trouble trying to match GNU/Linux
>             distributions, Release versions and libraries,
>             so I extended tec_uname to help out:  For example,
>             see how WebKit is chosen according to distribution
>             name and version.  [There may be redundancies that
>             can be merged/eliminated in a future release.]:
> 
>             $ ./tec_uname webkit
> 
> 
>> ReportWebkitItems()
>> {
>>      local I
>>      local L
>>
>>      # At the time of writing (240726), GetLinuxDistro sets TEC_DISTID,
>>      # but *not* GTK.
>>      GTK="/usr/"
>>      GetLinuxDistro
>>
>>      # Use short names to keep line lengths under control.
>>      I="${GTK}include/"
>>      L="${GTK}lib/"
>>
>>      # (Note to self: We rely on the package manager to pull in
>>      # dependencies for the package list only, notably
>>      # libsoup-2.4-dev[el] or libsoup-3.0-dev[el].  However, we probably
>>      # still have to name them explicitly for #include directories.)
>>      case "${TEC_DISTID}" in
>>          centos-core.7 )
>>              WK_PACKAGES="webkitgtk4-devel"
>>              WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>>              WK_LIBRARIES="webkit2gtk-4.0"
>>              ;;
>>
>>          centos-stream.8 )
>>              WK_PACKAGES="webkit2gtk3-devel"
>>              WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>>              WK_LIBRARIES="webkit2gtk-4.0"
>>              ;;
>>
>>          centos-stream.9 )
>>              WK_PACKAGES="webkit2gtk3-devel"
>>              WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>>              WK_LIBRARIES="webkit2gtk-4.0"
>>              ;;
>>
>>          debian.12 )
>>              WK_PACKAGES="webkit2gtk-4.0-dev"
>>              WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>>              WK_LIBRARIES="webkit2gtk-4.0"
>>              ;;
>>
>>          kali.2024 )
>>              WK_PACKAGES="webkit2gtk-4.1-dev"
>>              WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>>              WK_LIBRARIES="webkit2gtk-4.1"
>>              ;;
>>
>>          linuxmint.19 )
>>              WK_PACKAGES="libwebkit2gtk-4.0-dev"
>>              WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>>              WK_LIBRARIES="webkit2gtk-4.0"
>>              ;;
>>
>>          linuxmint.20 )
>>              # LM20.3 does not have wk-4.1 etc.
>>              WK_PACKAGES="libwebkit2gtk-4.0-dev"
>>              WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>>              WK_LIBRARIES="webkit2gtk-4.0"
>>              ;;
>>
>>          linuxmint.21 )
>>              WK_PACKAGES="libwebkit2gtk-4.1-dev"
>>              WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>>              WK_LIBRARIES="webkit2gtk-4.1"
>>              ;;
>>
>>          linuxmint.22 )
>>              WK_PACKAGES="libwebkit2gtk-4.1-dev"
>>              WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>>              WK_LIBRARIES="webkit2gtk-4.1"
>>              ;;
>>
>>          MX.23 )
>>              WK_PACKAGES="libwebkit2gtk-4.1-dev"
>>              WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>>              WK_LIBRARIES="webkit2gtk-4.1"
>>              ;;
>>
>>          rocky.8 )
>>              WK_PACKAGES="webkit2gtk3-devel"
>>              WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>>              WK_LIBRARIES="webkit2gtk-4.0"
>>              ;;
>>
>>          rocky.9 )
>>              # Works for both Rocky 9.3 and 9.4.
>>              WK_PACKAGES="webkit2gtk3-devel"
>>              WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>>              WK_LIBRARIES="webkit2gtk-4.0"
>>              ;;
>>
>>          ubuntu.22 )
>>              WK_PACKAGES="libwebkit2gtk-4.1-dev"
>>              WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>>              WK_LIBRARIES="webkit2gtk-4.1"
>>              ;;
>>
>>          ubuntu.23 )
>>              WK_PACKAGES="libwebkit2gtk-4.1-dev"
>>              WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>>              WK_LIBRARIES="webkit2gtk-4.1"
>>              ;;
>>
>>          ubuntu.24 )
>>              WK_PACKAGES="libwebkit2gtk-4.1-dev"
>>              WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>>              WK_LIBRARIES="webkit2gtk-4.1"
>>              ;;
>>
>>          * )
>>              echo "Warning:__Ignoring__${TEC_DISTID}"
>>              return 42
>>      esac
>>
>>      # ?? WARNING:  Several consumers of one-liner output use the text as
>>      # a subfield within another field.  While the client could edit out
>>      # the trailing whitespace (Bash or Lua versions), it's easier on
>>      # them, and gives more readable code, if we use "echo -n" here.
>>
>>      case "$1" in
>>          webkit )
>>              cat <<EOF
>> WK_DISTID=${TEC_DISTID}
>> WK_PACKAGES=${WK_PACKAGES}
>> WK_INCLUDES=${WK_INCLUDES}
>> WK_LIBRARIES=${WK_LIBRARIES}
>> EOF
>>              ;;
>>
>>          webkit-packages )
>>              echo -n "$WK_PACKAGES"
>>              ;;
>>
>>          webkit-includes )
>>              echo -n "$WK_INCLUDES"
>>              ;;
>>
>>          webkit-libraries )
>>              echo -n "$WK_LIBRARIES"
>>              ;;
>>
>>          default )
>>              echo "Unknown ReportWebkitItems selection: ${1}"
>>              ;;
>>      esac
>> }
> 
> -------- end of tec_uname snippet --------
> 
> (There are more build/include/library dependencies in
> "LGLICUA/svn/assistant-database.lua", but I'll omit these
> as this message is getting too long.]
> 
> --
> 
> Cheers,
> 
> sur-behoffski (Brenton Hoff)
> programmer, Grouse Software
> 
> 
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users

On 2025-05-10 01:56, Stefan Heinzmann via Iup-users wrote:
> Hi all,
> 
> I am building the libraries with mixed success on Linux. My problems 
> appear to originate with the system detection built into tecmake. For a 
> reason I can't find an explanation for, the Linux kernel version appears 
> to play a major role. I wonder why, can anyone here enlighten me or 
> point me to a document with the rationale?
> 
> The problem is that you can't determine the versions of libraries 
> installed on the system from the kernel version with any reliability. 
> You can very easily have an up-to-date Ubuntu running on an old kernel, 
> for example when using containers. Containers don't include a kernel, 
> they use the kernel on the host. Having older kernels run a newer 
> distribution in the container is a common situation, and the opposite 
> also happens. Hence, the kernel version really should have no bearing at 
> all on the build process.
> 
> Given the tecmake system as it is, I would at least need a simple way to 
> "fake" or bypass the kernel detection in a way that would match the 
> distribution used, so that the dependencies are determined correctly.
> 
> I guess I would be able to figure this out from the tecmake sources, but 
> I was hoping there's an easier way somebody already knows about.
> 
> Thanks for any light you can shed on the matter.
> 
> Cheers
> Stefan

G'day Stefan,

I've been working to bring GNU/Linux, Lua, and Tecgraf IM/CD/IUP
together.

I have a SourceForge project called lglicua:

        L -- Lua
        G -- GNU/Linux
        I -- IM
        C -- CD
        U -- IUP
        A -- Assistant

        https://sourceforge.net/projects/lglicua/

This has been mostly my own project, with help from Tecgraf and
PUC-Rio Lua folks.  Because it's failed to catch the imagination,
I'm only calling it a "beta" version.  In practice,

        https://sourceforge.net/projects/lglicua/files/

shows that releases have spanned early May 2021 to end July 2024.
Releases are often connected to Lua and/or LuaRocks releases
and/or bugfixes, as I whitelist these versions in the Assistant.

You can get a "hello, world" modal dialog box in only two lines:

```
        #!/bin/bash ../support/play-lua-tec
        iup=require("iuplua"); iup.Message("MyApp", "hello, world")
```
You don't specify the GNU/Linux distribution you are using.
Lglicua has been tested (briefly) on [as per 0.1-beta2 release]:

        * Debian/Ubuntu family:
                - Debian
                - Kali,
                - Linux Mint,
                - MX, and
                Ubuntu;

        *Red Hat family:
                - CentOS,
                - CentOS-Stream, and
                - Rocky

Whitelisting by name and major version number is used.

        ** CentOS: Core-7, Stream-8 and Stream-9;
        ** Debian 12.5;
        ** Kali 2024.2;
        ** Linux Mint 19.3, 20.3, 21.3 and newly-released 22;
        ** MX 23.3_ahs_x64;
        ** Rocky: 8.10, 9.3 and 9.4; and
        ** Ubuntu: 22.04.4, 23.10 and 24.04.

Linux kernels include 3.10, 4.18, 5.4, 5.14, 5.15, 6.1, 6.5, 6.8, 6.8.11 and 6.9.8.

GCC versions span 4.8.5 (CentOS Core-7) to 13.2 (Linux Mint-22 and Ubuntu 24.04).

(Although GNU/Linux Mint 22.1 has been released, I haven't tested
lflicua against it).

------------------------------------------------

The Tecgraf sources for IM/CD/IUP nominate Ubuntu as the model
distribution for GNU/Linux releases.  Looking at the sources,
there looks to be acknowledgement for many different OSes,
especially in "project/src/tecmake.mak".

I've looked into dependencies of libraries (GTK etc), and have
tailored these according to distribution+release version.

--------

To your immediate difficulties:  I've encountered very similar problems
when preparing lglicua for the wide range of distributions and
release versions.  Two items stand out:

        1. I've replaced the IM/CD/IUP "tecmake.mak" with a rewritten
           version of my own.  This greatly streamlines GNU/Linux
           support, and, especially, adds support for all kernels 6.x
           (and, hopefully,) up to 9.x.

           Library versions have a maze of dependencies, and do refer
           to non-Linux platforms, so my rewrite may break things
           on non-GNU/Linux platforms -- but (of course), given that
           lglicua is, by definition, GNU/Linux, this doesn't matter.
           In particular, look at GTK selection.  The rewritten
           "tecmake.mak" uses (having just identified "Linux" as
           "TEC_SYSNAME"):

                   ifneq ($(filter 3 4 5 6 7 8 9, $(TEC_SYSVERSION)), )
                        USE_GTK3 = Yes
                   else # [...]

           whereas the Tecgraf-shipped version uses a verbose chain
           of Makefile "$(findstring ...)" to do the identification,
           and this chain hasn't been updated to include Kernel 6:

                   ifneq ($(findstring Linux5, $(TEC_UNAME)), )
                     USE_GTK3 = Yes
                   endif

          The practical upshot of not identifying Kernel 6.x as
          being compatible with GTK3 is that tecmake.mak gets confused
          and lapses back to GTK2, and then library selection and
          linking break.


-------- Newer tecmake.mak: --------

> # Refine GTK default request:  Newer GNU/Linux systems get GTK3,
> # unless GTK2 is specifically defined.
> # 240510: CHANGED in lglicua: We incorporate a modified change of the
> # Tecgraf IUP' r5950 change (r4.21->r4.22); the parent tested for
> # Linux31, and only selected USE_GTK3 if, in addition, TEC_DIST is
> # CentOS.  Here, we run this test (and, by extension, the following cygw
> # test) if TEC_SYSNAME is Linux, but TEC_SYSVERSION is (effectively)
> # less than 4.
> ifdef GTK_DEFAULT
>   ifndef USE_GTK2
>     ifneq ($(filter linux Linux, $(TEC_SYSNAME)), )
>       ifneq ($(filter 3 4 5 6 7 8 9, $(TEC_SYSVERSION)), )
>         USE_GTK3 = Yes
>       else ifneq ($(filter centos CentOS, $(TEC_DIST)), )
>         USE_GTK3 = Yes
>       endif
>     else ifneq ($(filter cygw CYGW, $(TEC_UNAME)), )
>       USE_GTK3 = Yes
>     endif
>   endif
> endif

-------- Tecgraf-shipped tecmake.mak: --------

> ifneq ($(findstring Linux24, $(TEC_UNAME)), )
>   NO_GTK_DEFAULT = Yes
> endif
> ifeq ($(TEC_UNAME), Linux26)
>   NO_GTK_DEFAULT = Yes
> endif
> ifeq ($(TEC_UNAME), Linux26_64)
>   NO_GTK_DEFAULT = Yes
> endif
> 
> ifndef NO_GTK_DEFAULT
>   ifneq ($(findstring cygw, $(TEC_UNAME)), )
>     GTK_DEFAULT = Yes
>   endif
>   ifneq ($(findstring CentOS, $(TEC_UNAME)), )
>     GTK_DEFAULT = Yes
>   endif
>   ifneq ($(findstring Linux, $(TEC_UNAME)), )
>     GTK_DEFAULT = Yes
>   endif
>   ifneq ($(findstring MacOS, $(TEC_UNAME)), )
>     GTK_DEFAULT = Yes
>   endif
>   ifneq ($(findstring FreeBSD, $(TEC_UNAME)), )
>     GTK_DEFAULT = Yes
>   endif
>   ifneq ($(findstring SunOS, $(TEC_UNAME)), )
>     ifeq ($(TEC_SYSARCH), x86)
>       GTK_DEFAULT = Yes
>     endif
>   endif
> endif
> 
> ifdef GTK_DEFAULT
>   ifndef USE_GTK2
>     ifneq ($(findstring Linux5, $(TEC_UNAME)), )
>       USE_GTK3 = Yes
>     endif
>     ifneq ($(findstring Linux4, $(TEC_UNAME)), )
>       USE_GTK3 = Yes
>     endif
>     ifneq ($(findstring Linux31, $(TEC_UNAME)), )
>       USE_GTK3 = Yes
>     endif
>     ifneq ($(findstring cygw, $(TEC_UNAME)), )
>       USE_GTK3 = Yes
>     endif
>     #Homebrew
>     #ifneq ($(findstring MacOS10, $(TEC_UNAME)), )
>     #  USE_GTK3 = Yes
>     #endif
>   endif
> endif
> 


-------- end of tecmake.mak comparison --------



        2. I had serious trouble trying to match GNU/Linux
           distributions, Release versions and libraries,
           so I extended tec_uname to help out:  For example,
           see how WebKit is chosen according to distribution
           name and version.  [There may be redundancies that
           can be merged/eliminated in a future release.]:

           $ ./tec_uname webkit


> ReportWebkitItems()
> {
>     local I
>     local L
> 
>     # At the time of writing (240726), GetLinuxDistro sets TEC_DISTID,
>     # but *not* GTK.
>     GTK="/usr/"
>     GetLinuxDistro
> 
>     # Use short names to keep line lengths under control.
>     I="${GTK}include/"
>     L="${GTK}lib/"
> 
>     # (Note to self: We rely on the package manager to pull in
>     # dependencies for the package list only, notably
>     # libsoup-2.4-dev[el] or libsoup-3.0-dev[el].  However, we probably
>     # still have to name them explicitly for #include directories.)
>     case "${TEC_DISTID}" in
>         centos-core.7 )
>             WK_PACKAGES="webkitgtk4-devel"
>             WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>             WK_LIBRARIES="webkit2gtk-4.0"
>             ;;
> 
>         centos-stream.8 )
>             WK_PACKAGES="webkit2gtk3-devel"
>             WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>             WK_LIBRARIES="webkit2gtk-4.0"
>             ;;
> 
>         centos-stream.9 )
>             WK_PACKAGES="webkit2gtk3-devel"
>             WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>             WK_LIBRARIES="webkit2gtk-4.0"
>             ;;
> 
>         debian.12 )
>             WK_PACKAGES="webkit2gtk-4.0-dev"
>             WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>             WK_LIBRARIES="webkit2gtk-4.0"
>             ;;
> 
>         kali.2024 )
>             WK_PACKAGES="webkit2gtk-4.1-dev"
>             WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>             WK_LIBRARIES="webkit2gtk-4.1"
>             ;;
> 
>         linuxmint.19 )
>             WK_PACKAGES="libwebkit2gtk-4.0-dev"
>             WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>             WK_LIBRARIES="webkit2gtk-4.0"
>             ;;
> 
>         linuxmint.20 )
>             # LM20.3 does not have wk-4.1 etc.
>             WK_PACKAGES="libwebkit2gtk-4.0-dev"
>             WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>             WK_LIBRARIES="webkit2gtk-4.0"
>             ;;
> 
>         linuxmint.21 )
>             WK_PACKAGES="libwebkit2gtk-4.1-dev"
>             WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>             WK_LIBRARIES="webkit2gtk-4.1"
>             ;;
> 
>         linuxmint.22 )
>             WK_PACKAGES="libwebkit2gtk-4.1-dev"
>             WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>             WK_LIBRARIES="webkit2gtk-4.1"
>             ;;
> 
>         MX.23 )
>             WK_PACKAGES="libwebkit2gtk-4.1-dev"
>             WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>             WK_LIBRARIES="webkit2gtk-4.1"
>             ;;
> 
>         rocky.8 )
>             WK_PACKAGES="webkit2gtk3-devel"
>             WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>             WK_LIBRARIES="webkit2gtk-4.0"
>             ;;
> 
>         rocky.9 )
>             # Works for both Rocky 9.3 and 9.4.
>             WK_PACKAGES="webkit2gtk3-devel"
>             WK_INCLUDES="${I}libsoup-2.4 ${I}webkitgtk-4.0"
>             WK_LIBRARIES="webkit2gtk-4.0"
>             ;;
> 
>         ubuntu.22 )
>             WK_PACKAGES="libwebkit2gtk-4.1-dev"
>             WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>             WK_LIBRARIES="webkit2gtk-4.1"
>             ;;
> 
>         ubuntu.23 )
>             WK_PACKAGES="libwebkit2gtk-4.1-dev"
>             WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>             WK_LIBRARIES="webkit2gtk-4.1"
>             ;;
> 
>         ubuntu.24 )
>             WK_PACKAGES="libwebkit2gtk-4.1-dev"
>             WK_INCLUDES="${I}libsoup-3.0 ${I}webkitgtk-4.1"
>             WK_LIBRARIES="webkit2gtk-4.1"
>             ;;
> 
>         * )
>             echo "Warning:__Ignoring__${TEC_DISTID}"
>             return 42
>     esac
> 
>     # ?? WARNING:  Several consumers of one-liner output use the text as
>     # a subfield within another field.  While the client could edit out
>     # the trailing whitespace (Bash or Lua versions), it's easier on
>     # them, and gives more readable code, if we use "echo -n" here.
> 
>     case "$1" in
>         webkit )
>             cat <<EOF
> WK_DISTID=${TEC_DISTID}
> WK_PACKAGES=${WK_PACKAGES}
> WK_INCLUDES=${WK_INCLUDES}
> WK_LIBRARIES=${WK_LIBRARIES}
> EOF
>             ;;
> 
>         webkit-packages )
>             echo -n "$WK_PACKAGES"
>             ;;
> 
>         webkit-includes )
>             echo -n "$WK_INCLUDES"
>             ;;
> 
>         webkit-libraries )
>             echo -n "$WK_LIBRARIES"
>             ;;
> 
>         default )
>             echo "Unknown ReportWebkitItems selection: ${1}"
>             ;;
>     esac
> }

-------- end of tec_uname snippet --------

(There are more build/include/library dependencies in
"LGLICUA/svn/assistant-database.lua", but I'll omit these
as this message is getting too long.]

--

Cheers,

sur-behoffski (Brenton Hoff)
programmer, Grouse Software

Hi all,

I am building the libraries with mixed success on Linux. My problems 
appear to originate with the system detection built into tecmake. For a 
reason I can't find an explanation for, the Linux kernel version appears 
to play a major role. I wonder why, can anyone here enlighten me or 
point me to a document with the rationale?

The problem is that you can't determine the versions of libraries 
installed on the system from the kernel version with any reliability. 
You can very easily have an up-to-date Ubuntu running on an old kernel, 
for example when using containers. Containers don't include a kernel, 
they use the kernel on the host. Having older kernels run a newer 
distribution in the container is a common situation, and the opposite 
also happens. Hence, the kernel version really should have no bearing at 
all on the build process.

Given the tecmake system as it is, I would at least need a simple way to 
"fake" or bypass the kernel detection in a way that would match the 
distribution used, so that the dependencies are determined correctly.

I guess I would be able to figure this out from the tecmake sources, but 
I was hoping there's an easier way somebody already knows about.

Thanks for any light you can shed on the matter.

Cheers
Stefan

Nevermind,  the issue was manifest file with x86 references.

Thanks.

Hi.

I'm trying to move to x64 and I'm having problems with IUP.

Both with the dlls provided by IUP and the ones compiled here.

Error 0xc00007b
What do you mean x86/x64 mix.

Using Dependencies shows the problem:
C:\WINDOWS\WinSxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.26100.3323_none_85b5b76df7b06d96\comctl32.dll
Machine: i386

Any ideas?

Ranier Vilela

  MASKINT is a write only attribute. It will not be saved. But I believe
that MASK was saved instead, but the limits were lost.

  I just added a small fix. Thanks for reporting.

Best,
Scuri


Em qua., 12 de fev. de 2025 às 02:34, <ir...@gm...> escreveu:

> Attached sample image.
>
> using the button Set with the MASKINT attribute does not modify the
> underlying .led file, and if the attribute MASKINT was set beforehand using
> "Set" button removes the attribute from the file. other attributes can be
> set just fine, although i did not test them all
>
> _______________________________________________
> Iup-users mailing list
> Iup...@li...
> https://lists.sourceforge.net/lists/listinfo/iup-users
>

Attached sample image.

using the button Set with the MASKINT attribute does not modify the 
underlying .led file, and if the attribute MASKINT was set beforehand 
using "Set" button removes the attribute from the file. other attributes 
can be set just fine, although i did not test them all