coderextreme commented 9 months ago

Any thoughts for a port to XWayland? I don't know what it would entail, probably changes to imake and upgrade C++ to latest gcc/llvm/what have you.

John

barak commented 9 months ago

I don't think there's any changes necessary for XWayland, that's just another X11R4 server that happens to back-end on Wayland rather than directly to a device. A port to native Wayland, now that's another question... Probably easiest to do it via switching graphics libraries to gtk4, which can use either X or Wayland APIs transparently.

vectaport commented 9 months ago

As long as XWayland supports the X11 protocol I don't think there will be any porting needed. But I'm sure there will be a challenge getting it built on the latest compiler/library/OS delivery of RedHat, as has consistently been the case for the past 3 decades. The C++ code remains the same but the language keeps on drifting. I will offer support to anyone who tries to build ivtools so it can use XWayland. Good luck.

barak commented 9 months ago

The Redhat announcement about getting rid of Xorg means they're no longer going to package the X servers for various GPUs. The only X server they'll package will be XWayland, which back-ends on Wayland instead of directly onto a GPU or frame buffer. That's been the default configuration for Debian and Ubuntu and Redhat for years. They all default to running a Wayland server to deal with the hardware, and provide the X11 API via XWayland. The device-specific X servers are installed, but unused by default.

To my knowledge, there are no plans to get rid of XWayland; that would break all kinds of programs that do their graphics via the X11 API and have no Wayland port. So I think you can relax.

Well, you can relax about that! There are other sticking points with 1.2, namely getting it to compile with up-to-date GCC etc. Which I'm working on...

coderextreme commented 9 months ago

Well, I installed Weston and X11 on WSL 2 with Ubuntu on Windows 10. I got the draw tools in /usr/local/bin working in InterViews installation with minor changes to IV (added signal.h include, added std::). Now I’m trying to figure out how to start XWayland/use the XWayland library. I have no clue how to use XWayland, but I haven’t done any googling.

I haven’t tried any vectaport tools on WSL.

So my report is I got ivtools mostly working on Ubuntu-WSL2-Windows…is there something you want me to try besides XWayland? I don’t know if I tried Unidraw or not. I didn’t see a binary, but I don’t know what it’s called.

My goal for WSL is get Mesa/Vulkan/OpenGL working, but I’m also looking into licensing Government Acquisition Through Electric Commerce (GATEC) procurement app suite: see http://www.dsmforum.org/events/dsvl01/carlson.pdf — EDI translator’s workbench(TWB) an iconic programming IDE “IV desktop” automation tool with reversible debugging. This was in production for several years, so the GATEC version should be solid. I was adding multi-user support to TWB or libIV, if this makes any sense, such that one could do multi-user programming, but I doubt if that’s included. Then I got pulled away onto something else.

Plus I’d like to port the GATEC client/server UI cross-platform forms-based toolkit to the web—the web can support it better now with JSON and XML. There’s a potentially a partial port to InterViews there…I worked on it, but I’m not sure it got included in the GATEC package. As I recall, it’s only dependent libIV.so as far as InterViews goes. I think there was some issues with layouts and field validation. I think GATEC does include a version of Henry Spencer’s regexp library

If you’re interested in licensing or sublicensing the TWB, I’m pinging the LLNL Industrial Partnerships Office: https://ipo.llnl.gov. It would be way cool to get the TWB working on modern *nix systems. I had it a version working on Windows and Solaris. I don’t know if LLNL still has GATEC still on record.

Nvidia’s stuff looked like it ran on Ubuntu-WSL, so I didn’t try anything else. Maybe if I can get XWayland working on Ubuntu-WSL we could transfer the knowledge to RedHat or preferably SUSE or something non-RedHat. I know RedHat runs 90% of the servers, but their stance on charging for Linux source code truly sucks, and I would prefer even Oracle.

I’m off to google XWayland.

I will provide diffs and pull requests to ivtools when complete/resigned. If necessary, I can do a pull request.

John

On Mon, Dec 4, 2023 at 12:15 PM Scott Johnston @.***> wrote:

As long as XWayland supports the X11 protocol I don't think there will be any porting needed. But I'm sure there will be a challenge getting it built on the latest compiler/library/OS delivery of RedHat, as has consistently been the case for the past 3 decades. The C++ code remains the same but the language keeps on drifting. I will offer support to anyone who tries to build ivtools so it can use XWayland. Good luck.

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1839208059, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ53FN6PXJGUJYLKB47DYHYHL7AVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZZGIYDQMBVHE . You are receiving this because you authored the thread.Message ID: @.***>

coderextreme commented 9 months ago

I don’t know how many “True Wayland” apps there are. Try looking for a Wayland browser or finder app or email client or a list of apps for Wayland. So at this point an X11 proxy (XWayland) is required except for programmer, screenshot and wallpaper apps.

RedHat pretty much runs on server farms so a client-server or distributed protocol is required for the servers to display on a GUI. That means X11 over ssh, VNC, or RDP. AFAIK, the Wayland protocol doesn’t communicate outside a single machine. (But please correct me). Wayland by itself is not a program.

For WSL, I also had to configure x11 library folder and x include folder in ivtools.

The “new thing” I am doing is getting ivtools working on WSL with a Wayland compositor.

On Mon, Dec 4, 2023 at 2:02 PM Barak A. Pearlmutter < @.***> wrote:

The Redhat announcement about getting rid of Xorg means they're no longer going to package the X servers for various GPUs. The only X server they'll package will be XWayland, which back-ends on Wayland instead of directly onto a GPU or frame buffer. That's been the default configuration for Debian and Ubuntu and Redhat for years. They all default to running a Wayland server to deal with the hardware, and provide the X11 API via XWayland. The device-specific X servers are installed, but unused by default.

To my knowledge, there are no plans to get rid of XWayland; that would break all kinds of programs that do their graphics via the X11 API and have no Wayland port. So I think you can relax.

Well, you can relax about that! There are other sticking points with 1.2 are getting it to compile with up-to-date GCC etc. Which I'm working on...

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1839385589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ53OMXHI32F57UB7S43YHYT4ZAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZZGM4DKNJYHE . You are receiving this because you authored the thread.Message ID: @.***>

coderextreme commented 9 months ago

I mean to correct myself, I’m getting ivtools working with WSL (X11 Server?) and Weston through XWayland (X11 on one side, Wayland on the other). I think what Scott wants is a Wayland port of ivtools. I don’t think that that will work with Redhat servers, so please explain?

On Mon, Dec 4, 2023 at 2:39 PM John Carlson @.***> wrote:

I don’t know how many “True Wayland” apps there are. Try looking for a Wayland browser or finder app or email client or a list of apps for Wayland. So at this point an X11 proxy (XWayland) is required except for programmer, screenshot and wallpaper apps.

RedHat pretty much runs on server farms so a client-server or distributed protocol is required for the servers to display on a GUI. That means X11 over ssh, VNC, or RDP. AFAIK, the Wayland protocol doesn’t communicate outside a single machine. (But please correct me). Wayland by itself is not a program.

For WSL, I also had to configure x11 library folder and x include folder in ivtools.

The “new thing” I am doing is getting ivtools working on WSL with a Wayland compositor.

On Mon, Dec 4, 2023 at 2:02 PM Barak A. Pearlmutter < @.***> wrote:

The Redhat announcement about getting rid of Xorg means they're no longer going to package the X servers for various GPUs. The only X server they'll package will be XWayland, which back-ends on Wayland instead of directly onto a GPU or frame buffer. That's been the default configuration for Debian and Ubuntu and Redhat for years. They all default to running a Wayland server to deal with the hardware, and provide the X11 API via XWayland. The device-specific X servers are installed, but unused by default.

To my knowledge, there are no plans to get rid of XWayland; that would break all kinds of programs that do their graphics via the X11 API and have no Wayland port. So I think you can relax.

Well, you can relax about that! There are other sticking points with 1.2 are getting it to compile with up-to-date GCC etc. Which I'm working on...

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1839385589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ53OMXHI32F57UB7S43YHYT4ZAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZZGM4DKNJYHE . You are receiving this because you authored the thread.Message ID: @.***>

coderextreme commented 9 months ago

It seems like there's "root-less" Wayland compositor already built into WSL plus an XWayland server, but I can't identify their processes. Any help would be appreciated. Are they built into the WSL "kernel"?

I can definitely see weston pop up when I start it, and I see it in the process list, but i don't think I see a need for it. I can't run Xwayland separately, unless I point it at a different DISPLAY (environmental variable), which I've forgotten how to do for X servers.

So if you truly want a "Wayland-local" port of InterViews, have you considered porting InterViews to Fresco, and Fresco to Wayland? Fresco has a much better abstraction for multi-toolkit apps, AFAIK. Fresco has some of the drawing operations that InterViews has (see fdraw).

It was really a shame to see Fresco get put on the chopping block after WWW came on the scene. AFAIK, the core stuff is still there, if not the Berlin enhancements.

Since I apparently have gotten ivtools working with some form of XWayland, I'm going to set that aside. If you need any help with WSL installation, let me know, I just followed the documentation the web pages, though. The key is to follow the Ubuntu-WSL 2 path and install X11 stuff from apt. If you want weston, it's there, but the problem I had with it was that it was difficult to resize. If there's a better compositor to install, let me know.

Here's my patches to ivtools. You might have to #ifdef #include signal.h, I didn't try it anywhere else.

diff --git a/src/ComTerp/comterp.c b/src/ComTerp/comterp.c index 8bb0e95d..12e831d2 100644 --- a/src/ComTerp/comterp.c +++ b/src/ComTerp/comterp.c @@ -1133,7 +1133,7 @@ int ComTerp::run(boolean one_expr, boolean nested) { ostream out(&fbuf);

else

FILE *fp = handler() && handler()->wrfptr() ? handler()->wrfptr() : (_fd>0 ? fdopen(_fd, "w") : stdout);

streambuf* strmbuf = new std::strstreambuf();
std::streambuf* strmbuf = new std::strstreambuf(); ostream out(strmbuf);

endif

boolean eolflag = false; diff --git a/src/comterp/main.c b/src/comterp/main.c index 0800b52e..c13e4457 100644 --- a/src/comterp/main.c +++ b/src/comterp/main.c @@ -36,6 +36,7 @@ static const char *const SERVER_HOST = ACE_DEFAULT_SERVER_HOST;

include

include

+#include

include <sys/stat.h>

include

Have fun!

John

On Mon, Dec 4, 2023 at 2:02 PM Barak A. Pearlmutter < @.***> wrote:

The Redhat announcement about getting rid of Xorg means they're no longer going to package the X servers for various GPUs. The only X server they'll package will be XWayland, which back-ends on Wayland instead of directly onto a GPU or frame buffer. That's been the default configuration for Debian and Ubuntu and Redhat for years. They all default to running a Wayland server to deal with the hardware, and provide the X11 API via XWayland. The device-specific X servers are installed, but unused by default.

To my knowledge, there are no plans to get rid of XWayland; that would break all kinds of programs that do their graphics via the X11 API and have no Wayland port. So I think you can relax.

Well, you can relax about that! There are other sticking points with 1.2 are getting it to compile with up-to-date GCC etc. Which I'm working on...

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1839385589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ53OMXHI32F57UB7S43YHYT4ZAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZZGM4DKNJYHE . You are receiving this because you authored the thread.Message ID: @.***>

coderextreme commented 9 months ago

Another idea is porting InterViews to a web browser renderer rather than or in addition to Wayland. This would improve portability, but probably increase compile time. Then one could target multiple toolkits at the same time, with, AFAICT, native compatibility.

This is probably a better idea than the Fresco idea, unless you're still pushing a client/server across the network idea which is good for server deployment.

Hmm.

On Mon, Dec 4, 2023 at 3:45 PM John Carlson @.***> wrote:

It seems like there's "root-less" Wayland compositor already built into WSL plus an XWayland server, but I can't identify their processes. Any help would be appreciated. Are they built into the WSL "kernel"?

I can definitely see weston pop up when I start it, and I see it in the process list, but i don't think I see a need for it. I can't run Xwayland separately, unless I point it at a different DISPLAY (environmental variable), which I've forgotten how to do for X servers.

So if you truly want a "Wayland-local" port of InterViews, have you considered porting InterViews to Fresco, and Fresco to Wayland? Fresco has a much better abstraction for multi-toolkit apps, AFAIK. Fresco has some of the drawing operations that InterViews has (see fdraw).

It was really a shame to see Fresco get put on the chopping block after WWW came on the scene. AFAIK, the core stuff is still there, if not the Berlin enhancements.

Since I apparently have gotten ivtools working with some form of XWayland, I'm going to set that aside. If you need any help with WSL installation, let me know, I just followed the documentation the web pages, though. The key is to follow the Ubuntu-WSL 2 path and install X11 stuff from apt. If you want weston, it's there, but the problem I had with it was that it was difficult to resize. If there's a better compositor to install, let me know.

Here's my patches to ivtools. You might have to #ifdef #include signal.h, I didn't try it anywhere else.

diff --git a/src/ComTerp/comterp.c b/src/ComTerp/comterp.c index 8bb0e95d..12e831d2 100644 --- a/src/ComTerp/comterp.c +++ b/src/ComTerp/comterp.c @@ -1133,7 +1133,7 @@ int ComTerp::run(boolean one_expr, boolean nested) { ostream out(&fbuf);

else

FILE *fp = handler() && handler()->wrfptr() ? handler()->wrfptr() : (_fd>0 ? fdopen(_fd, "w") : stdout);

streambuf* strmbuf = new std::strstreambuf();

std::streambuf* strmbuf = new std::strstreambuf(); ostream out(strmbuf);

endif

boolean eolflag = false; diff --git a/src/comterp/main.c b/src/comterp/main.c index 0800b52e..c13e4457 100644 --- a/src/comterp/main.c +++ b/src/comterp/main.c @@ -36,6 +36,7 @@ static const char *const SERVER_HOST = ACE_DEFAULT_SERVER_HOST;

include

include

+#include

include <sys/stat.h>

include

Have fun!

John

On Mon, Dec 4, 2023 at 2:02 PM Barak A. Pearlmutter < @.***> wrote:

The Redhat announcement about getting rid of Xorg means they're no longer going to package the X servers for various GPUs. The only X server they'll package will be XWayland, which back-ends on Wayland instead of directly onto a GPU or frame buffer. That's been the default configuration for Debian and Ubuntu and Redhat for years. They all default to running a Wayland server to deal with the hardware, and provide the X11 API via XWayland. The device-specific X servers are installed, but unused by default.

To my knowledge, there are no plans to get rid of XWayland; that would break all kinds of programs that do their graphics via the X11 API and have no Wayland port. So I think you can relax.

Well, you can relax about that! There are other sticking points with 1.2 are getting it to compile with up-to-date GCC etc. Which I'm working on...

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1839385589, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ53OMXHI32F57UB7S43YHYT4ZAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMZZGM4DKNJYHE . You are receiving this because you authored the thread.Message ID: @.***>

barak commented 9 months ago

Unless you go to strenuous effort, your Wayland session is very likely to have Xwayland running. Here's what I see:

$ ps x|egrep -i 'way()land'
   1903 tty2     Ssl+   0:00 /usr/libexec/gdm-wayland-session /usr/bin/gnome-session
   3953 ?        Sl     0:08 /usr/bin/Xwayland :0 -rootless -noreset -accessx -core -auth /run/user/1000/.mutter-Xwaylandauth.4HJFF2 -listenfd 4 -listenfd 5 -displayfd 6 -initfd 7

If you just run xlsclients or something like that you'll likely see that you do have X11 available in your Wayland session.

That said, there are programs that can run directly on Wayland without using the X11 API. These include Firefox (which is about to switch to default to Wayland instead of X11 when both are available), GNU Emacs (which can use either when set up with gtk, albeit with a compile-time option; the debian package emacs-gtk prefers X11 while emacs-pgtk prefers Wayland), etc.

The quick way to tell if foo is using X11 or Wayland APIs is to run xeyes and see if they follow the cursor when you're in the foo window. I just used this: if I run xournalpp it uses Wayland, but env GDK_BACKEND=x11 xournalpp uses X11.

The "right" way to port ivtools, I think, would be to slip in something that has multiple backends instead of libx11. Gtk being the obvious candidate, see https://docs.gtk.org/gdk4/func.set_allowed_backends.html for available back-ends:

broadway
macos
wayland
win32
x11

but note that not all programs can use all backends: there is backend-specific code, and you have to take care if you want to be generic over all backends.

vectaport commented 9 months ago

John,

Thanks for the patch to comterp.c etc.. to get things built on your latest environment. I have just pushed a commit to ivtools that incorporates this change.

As for porting ivtools to "native" Wayland, I would consider not porting the glyph toolkit that came with InterViews (gtk and Java Swing became the future, not InterViews or Fresco) but instead port the core of the Unidraw framework currently built on top of InterViews/X11. This would mean just the canvas of the drawing editor would carry on, and with the built-in networked scripting language that ivtools added it makes for a vector graphic drawing server.

But as far as I'm concerned this is a project for the distant future. Thanks for your feedback and interest in ivtools.

Scott Johnston johnston@vectaport.com

barak commented 9 months ago

This seems like a reasonably mechanical job; I wonder if one of those LLM-based tools could mostly automate the port.

coderextreme commented 9 months ago

Good question about LLMs. I have not tried them for C++.

About Fresco, the X11R6 version. Here it is running in WSL 2. I almost gave up, so this is terrific to see. Let me know if you want it, or need help setting it up or anything. I have not tried the Fujitsu or Berlin or any follow-up version recently.

Let me know if you want a version, I can zip up a few folders, but I had to tweak Makefiles. I set it up for Linux, so I don't know how it would work in your environments!

John

coderextreme commented 9 months ago

Barak wrote:

ps x|egrep -i 'way()land'

Apparently, this is not how WSL 2 works. I saw Remote Desktop in my Task Manager when I had an X11 Client running $ ps x|egrep -i 'way()land' $ env |grep DIS WSL_DISTRO_NAME=Ubuntu WAYLAND_DISPLAY=wayland-0 DISPLAY=:0 $ xeyes & [2] 71785 $ xlsclients DESKTOP-8OPL3IE xeyes

coderextreme commented 9 months ago

port the core of the Unidraw framework

As I have not used much C++ for years, and never looked at the code for the Unidraw framework, this is not a task for me. Perhaps porting Unidraw to ImGui would be something approachable for a seasoned C++ porter. https://github.com/ocornut/imgui/ I agree that X11 still has applicability for accessing Linux servers, but tools like RDP and VNC are also competitors. I think there may be a place for connecting to multiple displays, but that seems less secure, and susceptible to confused deputy issues. Perhaps your drawing server eliminates the issue.

I don't know if broadway and Unidraw fit will together, or even broadway and ImGUI, but I'm willing to be corrected.

coderextreme commented 9 months ago

If you’re interested in licensing or sublicensing the TWB, I’m pinging the LLNL Industrial Partnerships Office: https://ipo.llnl.gov.

They said the software was "unavailable." I contacted someone who did license it, and they turned their version in to their employer.

coderextreme commented 9 months ago

After reviewing the GDK Wikipedia page:

“GDK is a thin wrapper around Xlib https://en.m.wikipedia.org/wiki/Xlib. The X Window System comes with a low-level library called Xlib https://en.m.wikipedia.org/wiki/Xlib. Almost every function in GDK is a very thin wrapper around a corresponding Xlib function; but some of the complexity (and functionality) of Xlib is hidden, to simplify programming and to make GDK easier to port to other windowing systems, such as Wayland https://en.m.wikipedia.org/wiki/Wayland_(display_server_protocol) or Microsoft Windows. ”

It sounds like a port to GDK rather than GTK4 is much more doable (and probably more efficient results). And, as far as I know, still carries the same cross-platform features.

You can get new L&F by using InterViews built in stuff, or customizing your own L&F.

It might be interesting to build a theme editor in InterViews if there isn’t one.

But yeah, I remember that .Xresources/.Xdefaults stuff.

Is Copilot a satisfactory LLM, or should I try Bard or Claude?

What about Android support?

John

On Tue, Dec 5, 2023 at 1:58 PM Barak A. Pearlmutter < @.***> wrote:

This seems like a reasonably mechanical job; I wonder if one of those LLM-based tools could mostly automate the port.

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1841526384, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ534NOSCW6AUWFA2IS3YH54IDAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRGUZDMMZYGQ . You are receiving this because you authored the thread.Message ID: @.***>

coderextreme commented 9 months ago

It might also might be worth considering creating xwin32, xmac, xbroadway, … servers like xwayland. I don’t even know why a server would be necessary, you’d just have an X11 API implemented with native code.

So instead of porting your app, you port X11 to a different backend as was done with X11.

I would say the lower the port, the better.

Of course, there are allied things that would need to be ported.

I’m also thinking macwayland, winwayland, etc., as well.

Maybe someday, we’ll come up with a higher abstraction than a GUI toolkit and be able to generate code for a specific API and platform. LLMs hold that promise, but if humans can’t accomplish it, how do LLMs?

There was Serpent UIMS.

John

On Wed, Dec 6, 2023 at 3:58 AM John Carlson @.***> wrote:

After reviewing the GDK Wikipedia page:

“GDK is a thin wrapper around Xlib https://en.m.wikipedia.org/wiki/Xlib. The X Window System comes with a low-level library called Xlib https://en.m.wikipedia.org/wiki/Xlib. Almost every function in GDK is a very thin wrapper around a corresponding Xlib function; but some of the complexity (and functionality) of Xlib is hidden, to simplify programming and to make GDK easier to port to other windowing systems, such as Wayland https://en.m.wikipedia.org/wiki/Wayland_(display_server_protocol) or Microsoft Windows. ”

It sounds like a port to GDK rather than GTK4 is much more doable (and probably more efficient results). And, as far as I know, still carries the same cross-platform features.

You can get new L&F by using InterViews built in stuff, or customizing your own L&F.

It might be interesting to build a theme editor in InterViews if there isn’t one.

But yeah, I remember that .Xresources/.Xdefaults stuff.

Is Copilot a satisfactory LLM, or should I try Bard or Claude?

What about Android support?

John

On Tue, Dec 5, 2023 at 1:58 PM Barak A. Pearlmutter < @.***> wrote:

This seems like a reasonably mechanical job; I wonder if one of those LLM-based tools could mostly automate the port.

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1841526384, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ534NOSCW6AUWFA2IS3YH54IDAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRGUZDMMZYGQ . You are receiving this because you authored the thread.Message ID: @.***>

coderextreme commented 9 months ago

Okay, I checked out the Wayland client API, and I didn’t see and drawing primitives:

https://wayland.freedesktop.org/docs/html/apb.html#id-1.10.2

This seems useful. I don’t see Wayland as a 2d or 3d graphics protocol or API:

https://www.reddit.com/r/GraphicsProgramming/s/Psq97ToRGY

So porting X11 client API to Wayland client API is pretty non-sensical, AFAICT. Embedding some version XWayland in your app makes more sense (minus X11 protocol).

I’m still voting for ImGUI and/or a SVG-like layer, below X11-like client libs. AFAICT, broadway is hokey.

On Wed, Dec 6, 2023 at 6:17 AM John Carlson @.***> wrote:

It might also might be worth considering creating xwin32, xmac, xbroadway, … servers like xwayland. I don’t even know why a server would be necessary, you’d just have an X11 API implemented with native code.

So instead of porting your app, you port X11 to a different backend as was done with X11.

I would say the lower the port, the better.

Of course, there are allied things that would need to be ported.

I’m also thinking macwayland, winwayland, etc., as well.

Maybe someday, we’ll come up with a higher abstraction than a GUI toolkit and be able to generate code for a specific API and platform. LLMs hold that promise, but if humans can’t accomplish it, how do LLMs?

There was Serpent UIMS.

John

On Wed, Dec 6, 2023 at 3:58 AM John Carlson @.***> wrote:

After reviewing the GDK Wikipedia page:

“GDK is a thin wrapper around Xlib https://en.m.wikipedia.org/wiki/Xlib. The X Window System comes with a low-level library called Xlib https://en.m.wikipedia.org/wiki/Xlib. Almost every function in GDK is a very thin wrapper around a corresponding Xlib function; but some of the complexity (and functionality) of Xlib is hidden, to simplify programming and to make GDK easier to port to other windowing systems, such as Wayland https://en.m.wikipedia.org/wiki/Wayland_(display_server_protocol) or Microsoft Windows. ”

It sounds like a port to GDK rather than GTK4 is much more doable (and probably more efficient results). And, as far as I know, still carries the same cross-platform features.

You can get new L&F by using InterViews built in stuff, or customizing your own L&F.

It might be interesting to build a theme editor in InterViews if there isn’t one.

But yeah, I remember that .Xresources/.Xdefaults stuff.

Is Copilot a satisfactory LLM, or should I try Bard or Claude?

What about Android support?

John

On Tue, Dec 5, 2023 at 1:58 PM Barak A. Pearlmutter < @.***> wrote:

This seems like a reasonably mechanical job; I wonder if one of those LLM-based tools could mostly automate the port.

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1841526384, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ534NOSCW6AUWFA2IS3YH54IDAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBRGUZDMMZYGQ . You are receiving this because you authored the thread.Message ID: @.***>

barak commented 9 months ago

Yes, by gtk I really meant gdk/gtk. Maybe all the calls could be plain gdk, I dunno. The URL that I gave for specifying backends, https://docs.gtk.org/gdk4/func.set_allowed_backends.html, actually points to a gdk routine, not a gtk one.

If someone has done a port of X11 inside WSL, please push to a fork here on github? I might be able to pick up some of it for the Debian package. I did a port of the build system from xmkmf to autoconf, but that's probably orthogonal.

coderextreme commented 9 months ago

You need WSL 2, I used Ubuntu-WSL/WSL-Ubuntu cuda drivers from NVIDIA, but I don’t know if they are necessary. Otherwise, use X11 libraries from the WSL Ubuntu distribution. You can use apt to install cuda drivers, NVIDIA has instructions. Be sure to specify Ubuntu-WSL for correct instructions.

I don’t know if there is sound yet.

I’m not sure if other WSL Linux distros have X11.

This is pretty much all Microsoft binaries. Since it’s Linux, you should be able to find the source, maybe there’s a source PPA from Microsoft?

I did download X11R6 to run Fresco.

“Alternatively, you may obtain corresponding source code for certain packages or material by sending an email to @.***, including the package name and version information.”

— https://learn.microsoft.com/en-us/linux/packages

This might be what you want: referenced from previous page:

https://packages.microsoft.com

John

On Wed, Dec 6, 2023 at 10:54 AM Barak A. Pearlmutter < @.***> wrote:

Yes, by gtk I really meant gdk/gtk. Maybe all the calls could be plain gdk, I dunno. The URL that I gave for specifying backends, https://docs.gtk.org/gdk4/func.set_allowed_backends.html, actually points to a gdk routine, not a gtk one.

If someone has done a port of X11 inside WSL, please push to a fork here on github? I might be able to pick up some of it for the Debian package. I did a port of the build system from xmkmf to autoconf, but that's probably orthogonal.

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1843285895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ5YBCECE6GPNAJEIM5LYICPKTAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTGI4DKOBZGU . You are receiving this because you authored the thread.Message ID: @.***>

coderextreme commented 9 months ago

https://packages.microsoft.com

I did see a Sources and Sources.gz under debian 12, but I have no clue what they are for. I will look at my apt config to see if source is available there. I’ve compiled a Linux kernel before, but not under Windows.

Here's the apt config. Looks like you can download jammy source from ubuntu.com. Maybe give that a try? If you need more help, give me the command to download source code from ubuntu.com's jammy.

$ cat sources.list

See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to

newer versions of the distribution.

deb http://archive.ubuntu.com/ubuntu/ jammy main restricted

deb-src http://archive.ubuntu.com/ubuntu/ jammy main restricted

Major bug fix updates produced after the final release of the

distribution.

deb http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted

deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted

N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu

team. Also, please note that software in universe WILL NOT receive any

review or updates from the Ubuntu security team.

deb http://archive.ubuntu.com/ubuntu/ jammy universe

deb-src http://archive.ubuntu.com/ubuntu/ jammy universe

deb http://archive.ubuntu.com/ubuntu/ jammy-updates universe

deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates universe

N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu

team, and may not be under a free licence. Please satisfy yourself as to

your rights to use the software. Also, please note that software in

multiverse WILL NOT receive any review or updates from the Ubuntu

security team.

deb http://archive.ubuntu.com/ubuntu/ jammy multiverse

deb-src http://archive.ubuntu.com/ubuntu/ jammy multiverse

deb http://archive.ubuntu.com/ubuntu/ jammy-updates multiverse

deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates multiverse

N.B. software from this repository may not have been tested as

extensively as that contained in the main release, although it includes

newer versions of some applications which may provide useful features.

Also, please note that software in backports WILL NOT receive any review

or updates from the Ubuntu security team.

deb http://archive.ubuntu.com/ubuntu/ jammy-backports main restricted universe multiverse

deb-src http://archive.ubuntu.com/ubuntu/ jammy-backports main restricted

universe multiverse

deb http://security.ubuntu.com/ubuntu/ jammy-security main restricted

deb-src http://security.ubuntu.com/ubuntu/ jammy-security main restricted

deb http://security.ubuntu.com/ubuntu/ jammy-security universe

deb-src http://security.ubuntu.com/ubuntu/ jammy-security universe

deb http://security.ubuntu.com/ubuntu/ jammy-security multiverse

deb-src http://security.ubuntu.com/ubuntu/ jammy-security multiverse

On Wed, Dec 6, 2023 at 10:54 AM Barak A. Pearlmutter < @.***> wrote:

Yes, by gtk I really meant gdk/gtk. Maybe all the calls could be plain gdk, I dunno. The URL that I gave for specifying backends, https://docs.gtk.org/gdk4/func.set_allowed_backends.html, actually points to a gdk routine, not a gtk one.

If someone has done a port of X11 inside WSL, please push to a fork here on github? I might be able to pick up some of it for the Debian package. I did a port of the build system from xmkmf to autoconf, but that's probably orthogonal.

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1843285895, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ5YBCECE6GPNAJEIM5LYICPKTAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTGI4DKOBZGU . You are receiving this because you authored the thread.Message ID: @.***>

barak commented 9 months ago

Sorry, I meant a port of ivtools 2.1 to X11/WSL. I didn't mean a port of X11 itself.

coderextreme commented 9 months ago

I just downloaded master from github. Scott made a patch for the changes I submitted.

What's the difficulty? I can try downloading 2.1, but I'd have to reapply patches.

You do need X11 installed from the Ubuntu distribution. Did you forget that?

I didn't test all the binaries, and I don't know if I successfully compiled all the binaries.

/usr/local/bin$ ls comdraw comterp_run csvfilt drawserv flipbook glyphterp iclass idraw ivtext nsys stdcmapppm comterp comtest dclock drawtool gclock graphdraw idemo ivgetjpg ivtiftopnm nsys-ui

/usr/local/lib$ ls ivtools libComUnidraw.so.2.1.0 libIV-common.so.2.1.0 libTopoFace.so.2.1.0 libAttrGlyph.so libComUtil.so libIV.so libUniIdraw.so libAttrGlyph.so.2.1.0 libComUtil.so.2.1.0 libIV.so.2.1.0 libUniIdraw.so.2.1.0 libAttribute.so libDrawServ.so libIVGlyph.so libUnidraw-common.so libAttribute.so.2.1.0 libDrawServ.so.2.1.0 libIVGlyph.so.2.1.0 libUnidraw-common.so.2.1.0 libComGlyph.so libFrameUnidraw.so libOverlayUnidraw.so libUnidraw.so libComGlyph.so.2.1.0 libFrameUnidraw.so.2.1.0 libOverlayUnidraw.so.2.1.0 libUnidraw.so.2.1.0 libComTerp.so libGraphUnidraw.so libTime.so python3.10 libComTerp.so.2.1.0 libGraphUnidraw.so.2.1.0 libTime.so.2.1.0 libComUnidraw.so libIV-common.so libTopoFace.so

Looks like 2.1.

Apparently, Scott did not push patches?

I'll fork and apply patches to my fork.

John

On Wed, Dec 6, 2023 at 12:22 PM Barak A. Pearlmutter < @.***> wrote:

Sorry, I meant a port of ivtools 2.1 to X11/WSL. I didn't mean a port of X11 itself.

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1843439141, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ56PJR34OQ4E7MLO47DYICZWLAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTGQZTSMJUGE . You are receiving this because you authored the thread.Message ID: @.***>

barak commented 9 months ago

Sorry, didn't see the patch. Got it now, thanks!

coderextreme commented 9 months ago

I see Scott's patch now!

Great!

I'm going to play around with Dear ImGUI to see if the WSL 3D is working.

ocornut/imgui: Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies (github.com) https://github.com/ocornut/imgui

Hmm!

John

On Wed, Dec 6, 2023 at 12:54 PM Barak A. Pearlmutter < @.***> wrote:

Sorry, didn't see the patch. Got it now, thanks!

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1843510174, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ5235CXG35D6XMAVCA3YIC5PFAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTGUYTAMJXGQ . You are receiving this because you authored the thread.Message ID: @.***>

coderextreme commented 9 months ago

I got OpenGL3 (2D) working in Dear ImGUI C++ on WSL.

John

On Wed, Dec 6, 2023 at 2:36 PM John Carlson @.***> wrote:

I see Scott's patch now!

Great!

I'm going to play around with Dear ImGUI to see if the WSL 3D is working.

ocornut/imgui: Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies (github.com) https://github.com/ocornut/imgui

Hmm!

John

On Wed, Dec 6, 2023 at 12:54 PM Barak A. Pearlmutter < @.***> wrote:

Sorry, didn't see the patch. Got it now, thanks!

— Reply to this email directly, view it on GitHub https://github.com/vectaport/ivtools/issues/20#issuecomment-1843510174, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMJ5235CXG35D6XMAVCA3YIC5PFAVCNFSM6AAAAABAGBC6BOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTGUYTAMJXGQ . You are receiving this because you authored the thread.Message ID: @.***>

coderextreme commented 4 months ago

I am doing more research into GTK. I liked that it’s C based. There’s GDK for windowing, GSK for Cairo, OpenGL and Vulkan, and GTK for the GUI toolkit. I don’t know if GTK relies on GSK. There’s probably stuff like Atoms in X11 that don’t translate well. If someone can recommend an MVP for porting, that would be cool.

Scott says:

As for porting ivtools to "native" Wayland, I would consider not porting the glyph toolkit that came with InterViews (gtk and Java Swing became the future, not InterViews or Fresco) but instead port the core of the Unidraw framework currently built on top of InterViews/X11. This would mean just the canvas of the drawing editor would carry on, and with the built-in networked scripting language that ivtools added it makes for a vector graphic drawing server.

Since you guys are making more use of Unidraw than I every will, I will try porting Unidraw to GSK, and leave other possibilities alone.

Note that GTK has moved to a CSS-like way of doing things. So this may be a very different kind of port, especially if Cairo uses CSS.

I am also in looking at your network scripting language, as I have written CPPON (C++ Object Notation).

I hear there’s a bit of rebellion against GTK4, but I will continue with GSK, if it works.

vectaport / ivtools

XWayland #20

else

endif

include

include

include <sys/stat.h>

include

else

endif

include

include

include <sys/stat.h>

include

See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to

newer versions of the distribution.

deb-src http://archive.ubuntu.com/ubuntu/ jammy main restricted

Major bug fix updates produced after the final release of the

distribution.

deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates main restricted

N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu

team. Also, please note that software in universe WILL NOT receive any

review or updates from the Ubuntu security team.

deb-src http://archive.ubuntu.com/ubuntu/ jammy universe

deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates universe

N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu

team, and may not be under a free licence. Please satisfy yourself as to

your rights to use the software. Also, please note that software in

multiverse WILL NOT receive any review or updates from the Ubuntu

security team.

deb-src http://archive.ubuntu.com/ubuntu/ jammy multiverse

deb-src http://archive.ubuntu.com/ubuntu/ jammy-updates multiverse

N.B. software from this repository may not have been tested as

extensively as that contained in the main release, although it includes

newer versions of some applications which may provide useful features.

Also, please note that software in backports WILL NOT receive any review

or updates from the Ubuntu security team.

deb-src http://archive.ubuntu.com/ubuntu/ jammy-backports main restricted

deb-src http://security.ubuntu.com/ubuntu/ jammy-security main restricted

deb-src http://security.ubuntu.com/ubuntu/ jammy-security universe

deb-src http://security.ubuntu.com/ubuntu/ jammy-security multiverse