fluxer / katie Goto Github PK

C++ toolkit derived from the Qt 4.8 framework

Home Page: https://bitbucket.org/smil3y/workspace/projects/KATANA

License: BSD 3-Clause "New" or "Revised" License

CMake 0.78% C++ 90.25% C 5.58% Shell 0.03% Python 0.28% QMake 0.01% GAP 0.69% Perl 0.01% PostScript 0.03% Makefile 0.01% Roff 0.10% QML 0.18% JavaScript 2.06% Brainfuck 0.01%

cpp toolkit qt4 c-plus-plus

katie's People

Contributors

Stargazers

Watchers

Forkers

gerdagoddess leashi pf94 barracuda156

katie's Issues

Build on Windows with MSYS2 UCRT64

Hi. I'm searching for Qt4 forks on Github and found your project. Unfortunately I'm on Windows and your project seems don't support Windows. If you could add Windows support I'm very pleased to help test building on MSYS2 UCRT64. Please consider. Thank you.

Possible to backport QtWidgets from Qt5?

Multiple ports require specifically QtWidgets, and this prevents from building them with Qt4 (perhaps among other issues, but this is a notable one). Is it possible to backport/implement it here?

tests are not namespace aware

tests are build with QT_NAMESPACE_COMPAT defined for that reason

Make use of QStandardDirs trought the codebase

HaikuOS support

HaikuOS is not on https://github.com/fluxer/katie/wiki/Unsupported-Operating-Systems.

JSON classes rewrite

Too complicated for most of the use cases (used as key-value pair storage) and the QVariant type system allows to iterate over QVariantMap similar to the object/array concept, e.g.:

#include <QDebug>
#include <QVariant>
#include <QStringList>

QT_USE_NAMESPACE

int main() {
    QVariantMap map;
    QStringList list = QStringList() << "1" << "2";
    QVariantMap map2;
    QStringList list2 = QStringList() << "3" << "4";
    map2.insert("map", list2);
    map.insert("list", list);
    map.insert("map2", map2);

    foreach(const QString &key, map.keys()) {
        const QVariant value = map.value(key);
        if (value.type() == QVariant::StringList) {
            qDebug() << "list" << key << value;
        } else if (value.type() == QVariant::Map) {
            qDebug() << "map" << key << value;
        }
    }

    return 0;
}

In other words QJsonDocument will be kept with the API to convert to/from QByteArray, to/from QVariantMap and report errors, the rest is redundant. As to why that is simple - common use case for it is parsing somewhat unknown objects and values which should be validated beyond the validations done by JSON parses (e.g. if string is file or directory path) with possible recursion limit and aborting the processing of the data to shave-off computation time, the current implementation does not make the processing any better since it does not provide the capability to do that and even if it does someone probably already tought about it. For example:

https://github.com/fluxer/kde-baseapps/blob/master/kate/addons/kate/project/kateproject.cpp
https://github.com/fluxer/kde-workspace/blob/master/plasma/runners/bookmarks/browsers/chrome.cpp

Deal with obsolete headers, besides those mentioned in the CMake files

This is important for projects that want to support both Qt4 and Katie. The task involves mostly build system modifications because Katie provides a CMake macro for generating obsolete headers. One can use and even update the incfsck script provided with the source code to get a list of obsolete headers but (as of the time of writing) the list is incomplete.

New logo, branding, copyright header changes, etc.

As much as I hate to do it at some point things will have to be copyrighted and I've touched pretty much every file for one reason or another (fixes, adjustments, whatnot). The question is what license should be chosen for fresh code - keen on BSD 3-clause.

For the logo - I'm not an artist so help with that would be appreciated.