I've written a shared library I'd like to make available for installation via the terminal and various package managers for FreeBSD. How would I go about doing this? I would also like to make the source code available for those who want to have it compiled directly into their C++ projects without needing to statically or dynamically link anything, simply by including the header and using the namespace. How would I go about doing this? What review process / quality control is there involved?
Here's the shared library I'd like to upload, it's a wrapper for zenity and kdialog using one cross-platform API:
github.com
Screenshots: Win32 | Cocoa | GTK+ | KDE
I would also like this command line app to be an official package as well:
github.com
In this topic I am also requesting from the FreeBSD maintainers, developers, and contributors if they could critique these two packages before I attempt to submit them. Basically just suggest any changes that should be made before it will meet the quality standards necessary and have code that is formatted, clear, and concise enough to be acceptable as a contribution.
The first package, DialogModule is meant specifically for games and small applications in which the dialog functions included are sufficient for completing the software that uses it. Kinda the whole point of this shared library is to bypass the GPL/LGPL limitations of GTK+ and KDE/Qt by not actually linking to such libraries directly, but rather, executing a CLI (in this case zenity and kdialog) through a pipe and reading the output. This is very useful for people who want to sell their software and games without also needing to give out their source code, which pretty much makes selling the software 100% unappealing because people can just get it for free via the source code anyway. So yeah, as far as I know, this would bypass that concern, and do so legally, which is why I ported it to Linux and BSD to begin with.
The second package, XTransientFor, allows you to run applications that have the _NET_WM_PID atom set correctly to their own process id to be used as a "dialog" and ran "transient for" the parent process's window id. This simple CLI uses the same basic logic as DialogModule under the hood in some ways. It keeps the app it executes on top of the parent process window id, and it can also change certain settings of that app's window such as startup position, size (if sizeable), add a PNG icon for the title bar and task manager, and other various things.
Please let me know if these things are useful enough to become actual packages, in your honest opinion.
Thanks,
Samuel
Here's the shared library I'd like to upload, it's a wrapper for zenity and kdialog using one cross-platform API:
GitHub - time-killer-games/libdlgmod: The World's Simplest Way to Dialog
The World's Simplest Way to Dialog. Contribute to time-killer-games/libdlgmod development by creating an account on GitHub.
github.com
Screenshots: Win32 | Cocoa | GTK+ | KDE
I would also like this command line app to be an official package as well:
time-killer-games/XTransientFor
Launch executables transient for the parent process and read output. - time-killer-games/XTransientFor
github.com
In this topic I am also requesting from the FreeBSD maintainers, developers, and contributors if they could critique these two packages before I attempt to submit them. Basically just suggest any changes that should be made before it will meet the quality standards necessary and have code that is formatted, clear, and concise enough to be acceptable as a contribution.
The first package, DialogModule is meant specifically for games and small applications in which the dialog functions included are sufficient for completing the software that uses it. Kinda the whole point of this shared library is to bypass the GPL/LGPL limitations of GTK+ and KDE/Qt by not actually linking to such libraries directly, but rather, executing a CLI (in this case zenity and kdialog) through a pipe and reading the output. This is very useful for people who want to sell their software and games without also needing to give out their source code, which pretty much makes selling the software 100% unappealing because people can just get it for free via the source code anyway. So yeah, as far as I know, this would bypass that concern, and do so legally, which is why I ported it to Linux and BSD to begin with.
The second package, XTransientFor, allows you to run applications that have the _NET_WM_PID atom set correctly to their own process id to be used as a "dialog" and ran "transient for" the parent process's window id. This simple CLI uses the same basic logic as DialogModule under the hood in some ways. It keeps the app it executes on top of the parent process window id, and it can also change certain settings of that app's window such as startup position, size (if sizeable), add a PNG icon for the title bar and task manager, and other various things.
Please let me know if these things are useful enough to become actual packages, in your honest opinion.
Thanks,
Samuel
