https://bugs.kde.org/show_bug.cgi?id=470679

            Bug ID: 470679
           Summary: Consider adding a library variant that works without
                    QtGui
    Classification: Frameworks and Libraries
           Product: frameworks-syntax-highlighting
           Version: unspecified
          Platform: Compiled Sources
                OS: All
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: framework
          Assignee: kwrite-bugs-n...@kde.org
          Reporter: textsh...@uchuujin.de
  Target Milestone: ---

Currently the syntax highlighting framework depends on QtGui for its color
representation. For Applications linking to QtGui anyway this is of course
convenient. But it would be great to have an option to build a variant of the
library without QtGui dependencies.

I'm working on a text editor[1] for use in terminals using a toolkit based on
QtCore and would like to add syntax highlighting. But pulling in all of QtGui
and its dependencies is a problem for usage e.g. on slim server installations
or containers.

I've been testing a few things and it seems the amount of features in QColor
that are used in the core classes of the syntax highlighting framework is not
very big and would be fairly easy to reimplement in a source compatible manner.
Of course features like QSyntaxHighlighter and QML support would be disabled in
such a build mode.

Of course i assume we would want to keep source and abi compatibility for all
the software already using the framework. So i expect that a mode of building
the framework without QtGui usage would produce a library with a name suffix
(like NoQtGui or Core, or [bikeshed]).
Allowing both to compile from a single source can be done using type aliases
and switching most of the framework to use these and have some #ifdef logic to
default those aliases to QColor and QRGB. (Or maybe there is an even better
way?)

What do the maintainers think? Can this be done upstream? What would be your
favored implementation strategy?
If there is a way forward i'm happy to contribute to make this work.

(I'm aware that there currently is a mode to build without QtGui, but that
current mode excludes building the library completely and only builds code
needed as native executable while cross compiling)


[1] https://github.com/istoph/editor

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to