oblivioncth / qx Goto Github PK

View Code? Open in Web Editor NEW

16.0 6.0 1.0 1.54 MB

"Kix": Expands upon the functionality of the existing Qt C++ Library

Home Page: https://oblivioncth.github.io/Qx/

License: Mozilla Public License 2.0

C++ 97.37% CMake 2.60% C 0.03%

base85 cmake csv documentation library qt static template fetchcontent find-package

qx's Introduction

Qx

Qx is a basic C++ library, intended to act as a direct extension to the Qt project, with facilities and a composition that are designed to feel familiar and follow in the spirit of the original framework.

This project makes use of the CMake build system generator for both compilation and consumption of the library.

It is based on Qt 6.

Documentation:

Detailed documentation of this library, facilitated by Doxygen, is available at: https://oblivioncth.github.io/Qx/

Highlights:

Disclaimer

Use this library in your own projects with caution.

This library began as personal library that I continue to maintain for use in my own Qt-based projects. I have decided to make it public in order to allow for full transparency in said projects and ensure that I'm abiding by open source license restrictions. It has evolved to be sensibly packaged and easily consumed by anyone, but since this library is largely intended for personal use there are currently no guarantees that are generally associated with production frameworks (i.e. stable ABI, minimal non-breaking changes, etc.)

However, I do attempt to keep my changes organized and reasonable, and in the process of releasing this repository I heavily cleaned up the codebase and committed to fully documenting its API, so using this library in other projects is feasible if you so desire.

The recommendation is to use the static version of the library in order to avoid ABI issues given it's adolescent nature.

If you do end up using this project, either through my other software or in your own, feel free to contribute, complain, point out bugs, or offer suggestions.

Getting Started

Either grab the latest release or build the library from source, and import using CMake.

Building from source is recommended as this library can easily be integrated as a dependency into your project using CMake's FetchContent. An example of this is demonstrated in the documentation.

Either way you'll then need to explore the documentation, which expands on acquiring, setting up, and using Qx.

Summary

C++20
CMake 3.23.0

Dependencies

Qt6
OBCMake (build script support, fetched automatically)
Doxygen (for documentation)

Pre-built Releases/Artifacts

Releases and some workflows currently provide builds of Qx in various combinations of platforms and compilers. View the repository Actions or Releases to see examples.

For all builds, Qt was configured as follows (excluding defaults):

Release
Compiler
- Windows: win32-msvc
- Linux: linux-clang
Shared/Static Linkage
Modules: qtbase, qtimageformats, qtnetworkauth, qtsvg, qt5compat
Features: relocatable
-ssl (Linux) / -schannel (Windows)

qx's People

Contributors

Stargazers

Watchers

Forkers

z3t4byt3

qx's Issues

qx-windows TaskbarButton example images have inverted colors

This is due to a bug in the Doxygen Awesome theme, which was reported here: jothepro/doxygen-awesome-css#72

Windows auto builds inconsistently somehow end up with wrong Doxygen version and fail to build docs

This is certainly one of the most bizarre issues I've ever seen.

Windows autobuilds, at first partially, but now mostly, seem to install Doxygen 1.9.4 correctly as they always have, but then when CMake is run somehow Doxygen 1.9.1 is detected at C:/ProgramData/chocolatey/bin/doxygen.exe. In the instances where 1.9.4 is correctly found, it is located at C:/Program Files/doxygen/bin/doxygen.exe.

The obvious suspect is chocolatey, though initial investigation seems to indicate that nothing has changed with that. The runs that started experiencing this issue were performed right after the previous windows doc fix #34 was merged, which was about a week ago at the time of writing. Some changes appeared to have occurred on that same day with GitHub action runners, which seems like too much of a coincidence, perhaps something with the image changed that is somehow causing this.

There is even a run where the Qt-shared based build finds the right Doxygen version, but the Qt-static based build finds the wrong one:
Qt-shared: https://github.com/oblivioncth/Qx/runs/7014637959?check_suite_focus=true
Qt-static: https://github.com/oblivioncth/Qx/runs/7014638072?check_suite_focus=true

Windows auto builds don't terminate when an external process fails

Issue with PS. Current solution would require adding last error code check to every external process start.

Instead, waiting on feature new to have this behavior be automatic in 7.3.0

PowerShell/PowerShell-RFC#277
https://docs.microsoft.com/en-us/powershell/scripting/whats-new/what-s-new-in-powershell-73?view=powershell-7.2

TaskbarButton not working with Qt 6.4

Greetings,

Thank you for providing an alternative to window's task bar process. It seems that it is no longer working with 6.4. Any idea why would that be?

Documentation: The display of default values function parameters is not displayed in some locations

This seems to be a bug with Doxygen.

File for here: doxygen/doxygen#9504

CTest failure details are not shown on test failure on Windows runners

One of those "may never be fixed" kind of deals :/

actions/runner#1206

Documentation .qch files are not generated in auto-builds

Because of how the Qt builds used with this repo are generated, they rely on containing a static copy of qhelpgenerator that is autodetected and used when Qx is built; however, because of QTBUG-93238, static builds of qhelpgenerator have been broken for some time (in particular it affects 6.3.0 which is the currently used version) and so .qch generation is temporarily disabled until 6.3.1 is released.

More tightly bind error objects to some situations

Some classes internally rely on passing GenericError, which works and is reasonable some of the time; however, in some other cases its not entirely clear exactly what kind of information is being passed around and which properties of GenericError the receiver of a GenericError instance should care about in a given context.

Look into creating more class specific error objects for these cases.