# Adding NeXtaw option to ports as Athena Widgets, and porting to XCB



## sidetone (Oct 5, 2021)

I want to add Nextaw (x11-toolkits/neXtaw) options to applications that use Xaw (x11-toolkits/libXaw) in ports. I've thought about working on adding port customizations since starting the thread Thread athena-xaw-implementations.81588.

To start with, I learned a lot about adjusting Makefiles by using the Porters Handbook, and learning a bit from others. My jail is set up for trying this out: Thread bastille-jail-to-build-and-test-builds.82155.

For manually setting a program that works with Xaw to work with NeXtaw, this is what was done before:
`cd /usr/local/lib
mv libXaw.so.6 libXaw2d.so.6
mv libXaw.so.7 libXaw2d.so.7
ln -s libneXtaw.so libXaw.so.6
ln -s libneXtaw.so libXaw.so.7`

I've starting by adding Nextaw dependency options to a Makefile. The build process for most ports asks for a libXaw header. When, I use both Xaw and NeXtaw as a dependency, the appearance still works like it's built with Xaw. This means, even though the Makefile is set up for NeXtaw, that it needs Xaw and uses Xaw for building. Linking to NeXtaw seems to be excluded.

For the next step, would making a patch file using shell, to conditionally have the NeXtaw header or dependency replace the Xaw one? Would fixing this also require learning C? Would it require unzipping files, and reading through C code, without necessarily adjusting that, except for header inclusions? Are there any pointers for the next steps?

I understand a lot from the shell part on how to adjust the Makefile, and I may need to understand how to use shell to fix patches for replacements. I want to focus on this for NeXtaw, and not on adding options from ports for other Xaw implementations. It's the best one appearance-wise imo.

Update: I found out about BINARY_ALIAS in the Porter's Handbook (5.17.) which can replace patches for binary file needs. I still hope for pointers from those familiar with port building, maintenance or improvements, and from others who know about any part of the process. Is there a way to see if this may have been done before for a similar OS? In the meantime, I'll look through an ebook about debugging builds.


Here's how NeXtaw looks:







Here's NeXtaw in comparison to other Xaw implementations:


----------



## sidetone (Oct 7, 2021)

The BSD's lack a native gui toolkit. I was looking into taking an existing one, and slowly learning about it to take the steps to make it a reasonable first class toolkit for BSD's

Of the Xaw implementations, NeXtaw is the best looking one, and it's acceptable in appearance. It's comparable to ISC's Motif which became LGPL. NeXtaw's license fits with BSD's perfectly as well.


I'll work on adding options NeXtaw options to programs that use Xaw, this may take a while. About Xaw, and screenshots for comparison: Thread athena-xaw-implementations.81588.

Then, I'll work on porting NeXtaw to XCB, even if only partially through XCL. Thread xcb-x-c-binding.81694.


Before, I considered that there was a way that makes a program implementation BSD-like. Actually, it a lot has to do with about portability the UNIX way, more than BSD specific compatibility. That a program work on top of base applications or types of program that could eventually find their way into base, instead of an alternate in ports is additionally a means of programs tailored for being tailored for BSD.

Cmake dependencies are also portable, but they're additionally Windows portable. Instead of programs being made tailored upstream for BSD use, it's better for the persuasion to be for portability. Is SystemD made for portability, or for absorbing and integrating into superficial complexities? Palemoon developers want their flagship program to have its own unique set of dependencies, rather than be portable. Some programs or software suites aren't leaned towards portability. Fortunately, the applications I want to work on are already portable enough to need less patches for use on FreeBSD. The Unix portability test would be, if it builds with bmake or imake.


----------



## sidetone (Apr 15, 2022)

Looking at this, NeXtaw hasn't had an update in 20 years.

x11-toolkits/libxaw3dxft (https://sourceforge.net/projects/sf-xpaint/files/libxaw3dxft/) may be the way to go instead. It's the only Athena implemenation that's modern enough, and that has Unicode (UTF-8) and Freetype for Internationalization support. That website also has patches for a few Xaw programs to work with it.

libxaw3dxft 1.6.2h from xpaint, is based off of the official libxaw3d 1.6.2 from Xorg. The newest version of libXaw3d available is 1.6.3, while x11-toolkits/xaw3d in ports has the old name and is obsolete: Thread libxaw3d-port-update.84390/. The recent versions of both of these implementations from 1.6.2 have similar visual appearances rather than the obsolete xaw3d. Xorg's official versions of libxaw/libxaw3d are at: https://gitlab.freedesktop.org/xorg/lib.

As for extended fonts for XCB:

https://github.com/venam/fonts-for-xcb
https://venam.nixers.net/blog/unix/2018/09/02/fonts-xcb.html

https://github.com/joshuakraemer/sft

On another note, compositor libraries that use Xwayland use libXCB for dependencies rather than libX11. This is good, because it will facilitate the move to libxcb.


----------

