Рубрика «Qt Software» - 4

Qt на Android: Episode OneЯ начинаю публиковать новую серию постов о Qt на Android.

Первая часть о том, как всё начиналось, как это работает, текущий статус, чего стоит ждать от Qt 5.2 и мои планы на Qt 5.3. В следующей части я расскажу подробнее о разработке для Android.

Давайте начнём:

Как всё начиналось?

В июне 2009 года я присоединился к ROUTE 66 в качестве старшего разработчика для Linux. Моим первым заданием было портирование навигационного движка на Android. Google тогда ещё официально не выпустила NDK, поэтому мне пришлось написать его самому, используя исходный код Android.

Вскоре мне удалось заставить движок работать. Я полюбил Android, но мне стало чего-то не хватать, чего-то, что было для меня очень важным. Это был Qt, мой любимый фреймворк. Вот чего не хватало! И я сказал себе, что я должен изменить положение вещей.

В октябре 2009 года Nokia (да, Qt тогда принадлежал Nokia...) анонсировала проект Lighthouse. Этот проект позволял разработчикам легко портировать Qt на (почти) любую платформу.

Читать полностью »

Введение

В этой статье нет ничего сверхъестественного. Я хотел просто собрать вместе все нюансы и проблемы, с которыми я столкнулся, связанные с построением Qt в одной статье — вдруг кому-нибудь пригодится.
Читать полностью »

Qt Meta System over Network. Часть 2 — сигналы и слоты
Часть 1 — Свойства
Продолжаем разбираться с метасистемой Qt. В этот раз рассмотрим создание виртуальных сигналов и слотов.
Читать полностью »

Qt Meta System over Network. Часть 1 — свойства
У меня с завидной регулярностью появляется задача написания клиент-серверных приложений с использованием Qt. И я подумал – почему бы не упростить этот процесс? В самом деле, зачем каждый раз изобретать какой-то новый протокол, если можно использовать привычные сигналы и слоты? Что-то подобное уже есть, например D-Bus или QRemoteSignal, но мне они показались не очень удобными, да и некоторых возможностей в них нет.
Читать полностью »

QtCreator: Qt кросс компиляция из linux 64 в linux 32, win32, win64 и Mac OS X; upx, usb, dmg, etc

Библиотека Qt позволяет делать действительно кроссплатформенные приложения. Единожды написанный код можно откомпилировать под многие операционные системы. Но проблема именно в слове «компилировать», т.к. подразумевается, что необходимо перезагрузиться под целевую систему, иметь в ней настроенную среду разработки, установленный и настроенный зоопарк библиотек. Спасает кросс-компиляция — компиляция, производящая исполняемый код для платформы, отличной от той, на которой исполняется.
Читать полностью »

Вступление

Язык QML для Qt Quick позволяет c легкостью делать многие вещи, особенно что касается анимированных пользовательских интерфейсов. Однако, не всё возможно сделать или не всё подходит под реализацию в QML, в частности:

  • получение доступа к функциональности извне окружения QML/Javascript
  • реализация критических по производительности функций, где требуется нативный код для повышения эффективности
  • большой или сложный не декларативный код, который было бы утомительно реализовывать в JavaScript

Как Вы увидите впоследствии, Qt легко отображает C++ код для QML. В этой статье мы создадим маленькое, но функциональное приложение, делающее это. Пример написан для Qt 5 и использует компоненты Qt Quick, поэтому для запуска примера Вам необходим как минимум Qt 5.1.0.
Читать полностью »

в 3:17, , рубрики: QML, qt, qt quick, Qt Software, метки: , ,

image
Однажды один мой знакомый спросил: «Как можно отобразить древовидную структуру в qml?» Получившейся вариант я уже пытался опубликовать на хабре, но в тот раз проспал инвайт… Под катом вторая попытка опубликовать таки статью.
Цель: разработать тестовое приложение отображающее древовидную структуру с помою Qt Quick.
Результат можно посмотреть на GitHub: github.com/1KoT1/QMLPresentTree
Читать полностью »

Модель у нас отвечает за доступ к данным. Модель может быть реализована как в самом QML, так и на C++. Выбор тут больше всего зависит от того, где находится источник данных. Если в качестве источника данных используется код на C++, то там удобнее сделать и модель. Если же данные поступают напрямую в QML (например получаются из сети при помощи XMLHttpRequest), то лучше и модель реализовать на QML. Иначе придется передавать данные в C++, чтобы затем обратно их получать для отображения, что только усложнит код.

По тому, как модели реализуются, я разделю их на три категории:

  • модели на C++;
  • модели на QML;
  • модели на JavaScript.

JavaScript-модели я вынес в отдельную категорию, т.к. у них есть определенные особенности, про них я расскажу чуть позже.
Начнем рассмотрение с моделей, реализованных средствами QML.

Model-View в QML:

  1. Model-View в QML. Часть нулевая, вводная
  2. Model-View в QML. Часть первая: Представления на основе готовых компонентов
  3. Model-View в QML. Часть вторая: Кастомные представления
  4. Model-View в QML. Часть третья: Модели в QML и JavaScript

Читать полностью »

в 8:52, , рубрики: pgp, qt, Qt Software, tutorial, метки: , ,

Так как оказалось, что наши коммуникации довольно легко просматриваются товарищами из АНБ то похоже что нужно шифровать все коммуникации. Я решил проверить насколько сложно подключить шифрование в разработке Qt приложений. Как оказалось что все совсем несложно даже в случае использовании PGP.

Так что тут больше дело привычки разработчика чтобы шифровать критические данные.

Вот и попробуем использовать PGP в нашем простом примере. Конечно уже существует отличный framework QCA (http://delta.affinix.com/qca/) который сделает все за нас. Нам только разобраться с правильным использованием QCA.

Создадим простое десктопное пролижение которое может зашифровать входной текст. Предполагается что у нас уже установлен GnuPG, сгенерированны ключики, получены ключики получателя, установлен и отконфигурирован gpg-agent, установлен и проверен pinentry-qt/pinentry-gtk(дада, мы на линуксе). Затем нам нужно установить qca и qca-gnupg

emerge --ask qca qca-gnupg

Запустим Qt Creator, выберем Qt Gui application, добавим туда qca:Читать полностью »

Доброго времени суток!

Задача

В текущем проекте столкнулся с необходимостью генерировать объекты-наследники от общего интерфейса, при этом порождать наследников необходимо, передавая им в конструкторе некий объект-инициализатор. Конструктора по-умолчанию у классов может и не быть. При этом конкретная фабрика объектов определяется в динамически подгружаемых плагинах, поэтому должна иметь определенный интерфейс.

Могу предложить два способа решения данной задачи.

Исходные данные

Допустим, интерфейс фабрик должен выглядеть следующим образом

class IFactoryBasic
{
public:
    IFactoryBasic() {}
    virtual ~IFactoryBasic() {}
    virtual Test* create(const QString &key, const QString &args)=0;
};

где Test — некий базовый класс

class Test
{
protected:
    QString _word;
public:
    Test(const QString &word):_word(word) {}
    virtual ~Test() {}
    virtual void test(){ qDebug()<<"test "<<_word; }
};

class TestChild: public Test
{
public:
    TestChild(const QString &word): Test(word) {}
    virtual void test() { qDebug()<<"test child"<<_word; }
};

TestChild — наследник Test
Оба класса принимают в конструкторе строковый параметр word, который потом мы можем верифицировать в функции test().

Первый способ

Способ простой. Он основан на создании шаблонного каркаса для будущей фабрики.

template<class T, class C, class A>
class IFactory
{
    QMap<QString, C* (T::*)(const A&) > handler;
protected:
    void add(const QString &key, C *(T::*func)(const A &))
    {
        handler[key]=func;
    }

public:
    IFactory() {}
    virtual ~IFactory() {}
    C *make(const QString &key, const A &args)
    {
        if(handler.contains(key))
        {
            T* inheritor = dynamic_cast<T*>(this);
            if(inheritor)
                return (inheritor->*handler[key])(args);
        }
        return 0;
    }
};

Здесь есть маленькое обязательство для пользователей класса. Первый шаблонный параметр должен быть классом, который наследуется от IFactory. Далее будут пояснения, для чего это было нужно.
handler в классе IFactory — ассоциативный контейнер, содержащий ключ и соответствующую функцию создания объекта. Сигнатура функции порождения описывается как C* (T::*)(const A&), то есть возвращаемое значение будет иметь указатель на некий класс C, как аргумент функции передается ссылка на объект типа A.
Функция add(...) добавляет в контейнер пару ключ-функция <key,func>.
Функция make(...) вызывает функцию порождения, если она имеется в контейнере (предварительно динамически преобразовав тип указателя this к типу наследника, иначе нельзя вызвать функции, которые там были определены).
Это основной каркас фабрики, осталось описать конкретную фабрику

class FactoryFst: public IFactory<FactoryFst, Test, QString>, public IFactoryBasic
{
    Test *createOrigin(const QString &args){ return new Test(args); }
    Test *createChild(const QString &args) { return new TestChild(args); }
public:
    FactoryFst()
    {
        add("test", &FactoryFst::createOrigin);
        add("testchild", &FactoryFst::createChild);
    }

    Test *create(const QString &key, const QString &args) { return make(key, args); }
};

Нетрудно догадаться, что мы используем множественное наследование для удовлетворения требованиям интерфейса IFactoryBasic. Для другого родителя мы явно указываем наследника FactoryFst, возвращаемый указатель будет указателем на объект класса Test, и в качестве аргумента передается ссылка на объект QString.
В соответствии с этим определением создаются функции, генерирующие объекты типа Test и TestChild:
Test *createOrigin(const QString &args){ return new Test(args); } — создает объект типа Test, передавая ему в конструктор аргумент QString.
Test *createChild(const QString &args) { return new TestChild(args); } — аналогично создает объект типа TestChild.
Остается только в конструкторе FactoryFst зарегистрировать данные функции и определить функцию create(...) интерфейса IFactoryBasic.

Второй способ

Этот метод в большей степени использует шаблоны.
Для построения фабрики нам нужна небольшая подготовка. Для начала нужно определить некоторые используемые фабрикой классы.

Для начала определим вспомогательный класс для хранения значений передаваемого аргумента. Для того, чтоб можно было беспрепятственно использовать указатели на данный класс, сделаем его наследуемым от нешаблонного базового класса.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js