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 <[email protected]> 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/iup-users >
_______________________________________________ Iup-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/iup-users
