Установка дополнительных компонентов в Qt Creator

Qt Creator, Qt, Qwt

Рекомендуем хостинг TIMEWEB

Стабильный хостинг, на котором располагается социальная сеть EVILEG. Для проектов на Django рекомендуем VDS хостинг.

Qt Charts лучше, чем Qwt, рекомендую его использовать. Qwt - это сторонняя библиотека, а Qt Charts - это уже модуль Qt. Тем более, что они обе распространяются под GPL.

Что касается дизайнера, то это возможно. Автоматически дизайнер не будет подхватывать сторонние библиотеки, но его можно научить ими пользоваться в отдельно взятом проекте. Это возможно в том случае, если класс наследован от какого-либо Qt-шного класса, например, от QWidget или QTableView .

Для этого нужно перейти в дизайнер интерфейсов, кликнуть правой кнопкой мыши на тот объект, которые хотите преобразовать в наследованный класс (объект уже должен быть помещён в компоновщик). Объект который хотите преобразовать должен соответственно располагаться в древовидном списке добавленных объектов. В контекстном меню выбираете пункт "Преобразовать в" / "Promote to" и откроется диалоговое окно, где Вы указываете название класса и его заголовочный файл. Если используете namespace , то название класса нужно указывать вместе с namespace , например, dialogs::MyWidget .

Во вложении внешний вид этого диалогового окна.

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

О таком методе я знаю, хотелось чтобы все было визуально. А как начет библиотеки phonon она была раньше в составе Qt и имела визуальные компоненты, а теперь ее прикрутить не выходит. И все таки есть ли возможность в Qt прикрутить компоненты сторонние или не сторонние, которые почему-то не входят в состав Qt или исключены из него?

С phonon не довелось работать. Особо и не работал с мультимедия системой в Qt.

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

Но насчёт плагинов не могу ничего посоветовать.

Что касается подключения этой библиотеки в качестве плагина. То очень сомневаюсь, что она для этого подготовлена.

Как пишется в документации - да подготовлена, только не становиться она и меня по тому как описано. Ну это уже не столь важно.

Вопрос как компонент Qt Charts разместить на форме визуально и настроить некоторые его свойства?

21-й век все должно быть визуально - от этого зависит скорость разработки софта.

Зачем тратить время на программирование интерфейса и размещение компонентов вручную если это можно сделать в дизайнере?

21-й век все должно быть визуально - от этого зависит скорость разработки софта.

Согласен с этим. Сам стараюсь делать большую часть работы через дизайнер.

Но вот что касается использования графиков, то на форуме Qt Company не так давно попадалось сообщение от модератора, что нужно использовать способ, который я предложил вам выше, то есть через "Promote to" . Так что на данный момент альтернатив нет. А если учесть, что Qt Charts только в версии Qt 5.7 официально добавили в виде скомпилированных библиотек под лицензией GPL, до этого они были только в коммерческой версии, то остаётся только ждать, когда виджеты Qt Charts добавят в дизайнере, вопрос лишь в том, когда именно их добавят.

Хорошо, спасибо, буду работать через "Promote to".

И вопрос так не по теме, а просто, что бы понять как лучше и почему другие так делают.

Нашел я на одном сайте как на Qt пишут калькулятор, только пишут его создавая свой класс. Хотя калькулятор и так вроде бы как написать не сложно (сам не пробовал).

Вот и возник вопрос, что лучше при написании любой программы и не только калькулятора:

1. Не создавать класс и написать имеющимися средствами (предположение, что все средства есть и в этом нет проблем);

2. Написать свой класс, который будут заточен на выполнение необходимой работы.

Что будет более правильным, быстрым и менее трудоемким - скажем так "золотая середина"?

Согласен. Написание простого калькулятора, который будет иметь комплект кнопок, окошко ввода и некоторую логику - процесс не сложный на Qt. И всё можно уместить в класс основного окна приложения.

Проблемы начнутся тогда, когда захочется сделать сохранение результатов, добавление формул, настройки, какие-то ещё дополнительные плюшки. И т.д. и т.п. А проблемы будут заключаться в том, что программный код нарастёт как снежный ком и весь функционал будет вперемежку. А если же брать как пример калькулятор, то имеется три традиционных разновидности калькулятора: обычный, инженерный, программистский (где различные системы счисления). Поэтому будет логичным написать три различных класса для каждого типа калькулятора, пускай даже они будут наследованы от одного общего базового класса. Тогда

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

Написание отдельных классов с выделением определённого функционала позволит впоследствии просто наследоваться от этих классов и расширять функционал, если понадобится тоже самое, но немного другое.

Я в данный момент занят в одном крупном проекте на Qt и если отталкиваться от того, что я вижу в этом проекте, то можно утверждать, что порой приходится наследоваться практически от всех классов Qt вплоть до QLineEdit и QTextDocument, поскольку требования к функциональности программы таковы, что приходится кастомизировать практически всё. Недавно мне пришлось делать аналог LineEdit из QTextEdit, поскольку QLineEdit не поддерживает требуемый функционал, а реализация поддержки этого функционала выглядит крайне уродливой. Решение на QTextEdit оказалось более изящным.

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

Поэтому, если вернуться к калькулятору, то это набор кнопок и логика, но есть ещё настройки, история результатов и т.д. Поэтому эти кнопки и логику отделяют от остального функционала.

Спасибо!

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

А вот насчет кликабельного QLabel - это разочарование. В C# есть уже готовый LinkLabel. Только C# оказался не очень-то и кросплатформенным :)

Судя по названию, LinkLabel отвечает за открытие ссылок. В QLabel тоже можно ссылки открывать, просто он не испускает сигнал clicked .

Этот испускает. А про ссылки можно подробнее?

QLabel , как и многие виджеты в Qt, которые отображают текст, поддерживает отображение текста в html формате. Не в таком полном виде как браузер, конечно, но в достаточном, чтобы сверстать логически разбитый на параграф текст с добавлением изображений и ссылок.

Так вот, QLabel не имеет сигнала clicked , но может испускать сигналы linkActivated или linkHovered, которые передают url, который можно открыть с помощью QDesktopServices . А если установить openExternalLinks в True , то можно автоматически открывать ссылку из QLabel в браузере или файловом менеджере, просто кликнув по ней в QLabel, там уже автоматически будет открыто приложение по умолчанию, которое отвечает за подобные ссылки, то есть браузер или файловый менеджер соответственно.

Спасибо. Это практически LinkLabel в C#.