Здравствуйте, MTD, Вы писали:
NB>>причем умудрившись при этом наехать на остальных, не разделяющих твоего мнения.
MTD>Хорошо, всем приношу свои извинения. Давай заканчивать препирательства, в принципе мы оба понимаем, что сейчас демонстрируем баранье упорство докапываясь до формулировок, по-существу все уже и так понятно. Мир, дружба
принято.
отрадно видеть что мои усилия были не напрасны
Re[9]: Библиотека для создания графических интерфейсов пользователя
Здравствуйте, Zhendos, Вы писали:
_>>По нормальному для реализации обработчиков никакой интроспекции не надо. Оно спокойно работает во всех GUI библиотеках, включая самые древние. Z>А можно подробности? Вот у вас есть разделяемая библиотека с виджетами. Z>И по вашим словам интроспекции никакой не нужно, какими образом без всякой Z>мета информации IDE может понять какие виджеты есть в этой библиотеке, и какие сигналы Z>у этих виджетов есть? Не говорю уже о свойствах, которые мы по вашему предложению Z>оставляем за скобками.
О чём вообще речь? Какую информацию IDE (кстати какая именно? А то многие вообще считают это ошибкой в коде) понимает о Qt благодаря сигналам/слотам? )))
Re[10]: Библиотека для создания графических интерфейсов пользователя
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Zhendos, Вы писали:
_>>>По нормальному для реализации обработчиков никакой интроспекции не надо. Оно спокойно работает во всех GUI библиотеках, включая самые древние. Z>>А можно подробности? Вот у вас есть разделяемая библиотека с виджетами. Z>>И по вашим словам интроспекции никакой не нужно, какими образом без всякой Z>>мета информации IDE может понять какие виджеты есть в этой библиотеке, и какие сигналы Z>>у этих виджетов есть? Не говорю уже о свойствах, которые мы по вашему предложению Z>>оставляем за скобками.
_>О чём вообще речь? Какую информацию IDE
>(кстати какая именно?
Любая создатели которой хотят чтобы в их IDE программировать GUI было удобно.
>А то многие вообще считают это ошибкой в коде)
Хм, ну тогда эти IDE абсолютно бесполезны для C++,
если они не могут расспарсить:
#define signals private
class Foo {
signals:
void f();
};
то нахрена нужны такие IDE?
> понимает о Qt благодаря сигналам/слотам? )))
Мы же только что это обсуждали:
> Тут в первую очередь интересует нормальная работа их дизйанера (который по команде в нём автоматически вставляет нужные обработчики в
+исходники).
В IDE подгружается плагин с виджетами, это могут виджеты из QtGui или реализованные вами,
и IDE должна позволить положить виджет на формочку, и кликнув на виджете сказать хочу
подписать на этот сигнал, как без аналога metaclass это сделать?
Re[11]: Библиотека для создания графических интерфейсов пользователя
Здравствуйте, Zhendos, Вы писали:
>>(кстати какая именно? Z>Любая создатели которой хотят чтобы в их IDE программировать GUI было удобно.
Я имею в виду, в какой это реализовано уже прямо сейчас?
>> понимает о Qt благодаря сигналам/слотам? ))) Z>Мы же только что это обсуждали: >> Тут в первую очередь интересует нормальная работа их дизйанера (который по команде в нём автоматически вставляет нужные обработчики в Z>+исходники). Z>В IDE подгружается плагин с виджетами, это могут виджеты из QtGui или реализованные вами, Z>и IDE должна позволить положить виджет на формочку, и кликнув на виджете сказать хочу Z>подписать на этот сигнал, как без аналога metaclass это сделать?
А, ну т.е. речь не про IDE, а про визуальный редактор GUI. Это кстати отдельное приложение из встроенных инструментов библиотеки Qt. Так вот я что-то не помню, чтобы оно могло такое, без установки дополнительных плагинов. Т.е. вот допустим есть библиотечка компонентов Qwt для Qt и в неё входит специальный плагин, который надо добавить в визуальный редактор Qt, для поддержки этих новых компонент. Так что...
Ну а если говорить не о произвольных компонентах, а о фиксированном их наборе, то это действительно работает. Причём работает и в wxWidgets и даже в древней MFC. ))) Без всяких signal'ов и slot'ов. )))
Re[18]: Библиотека для создания графических интерфейсов поль
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, c-smile, Вы писали:
CS>>На reddit любая тема про Electron или Atom... S>Да там больше про то, что они при своем размере и пожираемых ресурасах не могут открывать большие файлы. Про размер дистрибутивов жалобы чаще всего на студию/винду
The fact that each application comes with its own version of Chromium (the 20 million LOC, ~30MB [packaged] Web runtime) is one of the most criticised aspects.
Здравствуйте, MTD, Вы писали:
MTD>А давай, чтобы понятно было какой у тебя опыт в разработке кроссплатформенного гуя на Qt ты покажешь свой проект? Вот мой: https://icq.com/ MTD>Из того, что еще хорошо знаю, Telegram на Qt написан: https://telegram.org/
Ужасающе тормозит в RDP.
Там как-то можно отключить (или вырезать болгаркой) тормознутость? К сожалению, вынужден держать это в RDP для совместного доступа.
Re[5]: Библиотека для создания графических интерфейсов польз
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Vetal_ca, Вы писали:
MTD>>>Из того, что еще хорошо знаю, Telegram на Qt написан: https://telegram.org/
V_>>Ужасающе тормозит в RDP.
MTD>Не проблема, бери написанный на Sciter — все летать будет. Или тоже тормозить? Не знаю, расскажешь.
Да что-ж ты так реагируешь то болезненно.
К слову Sciter в RDP лучше работает потому как использует Direct2D про который Windows всё знает.
Qt рисует или в bitmap или в OpenGL что не сильно RDP friendly как сам понимаешь.
Но конечно RDP это не critical use case для messengers поэтому можно забить в общем-то.
Re[15]: Библиотека для создания графических интерфейсов польз
Здравствуйте, c-smile, Вы писали: CS>... CS>У каждого QObject есть еще QObjectData. Т.е. дополнительная косвенность обращений.
Ну надо понимать, что это небольшие накладные расходы. И object data нужен больше для аккуратного кода. Да и вообще в Qt очень любят pimpl делать (изначально для бинарной совместимости). CS>А каждый QPointer содержит в себе QWeakPointer который уже есть refcounter штука
Ну так надо понимать, что такое QPointer — это умный указатель, который автоматически зануляется, если уничтожить объект (который обязательно QObject) в другом месте. Я почему-то изначально думал, что это реализовано на сигналах/слотах, но через weak pointer действительно эффективнее.
По сути это и есть QWeakPoniter, для конструирования которого не нужно иметь экземпляр QSharedPointer.
Так что в этом случае использование подсчёта ссылок — общепринятый подход. CS>В то же самое время HTML DOM это direct parent-child tree:
CS>Т.е. построено на прямых pointers — более легковесное.
Повторюсь — использование QObject-а само по себе достаточно накладно при больших вычислениях. Например — делать каждый элемент графической сцены (типа entity в любом абстрактном игровом движке) нет смысла. Да и вообще нужно понимать, когда QObject нужен, а когда нет. QObject дорогой при создании, не копируемый по определению, но не имеет практически никакого оверхеда при использовании. Т.е. он является отличной базой для описания GUI объектов (их часто создавать не надо) — тут и обработка событий и сигналы/слоты (аля делегаты).
Поэтому лично я не вижу никакого плюса от заявленной вами легковесности для GUI.
-----
Вообще, если закрыть глаза на личностные выпады, то достаточно интересно читать этот топик. Получается классический холивар на тему Qt vs остальные. Кратко опишу своё мнение и свой опыт:
Я делал на Qt сервера (fastcgi, базы), делал достаточно сложный GUI (ланчеры для всяких игр с сильной кастомизацией, чаты, 3д редактор игровых уровней). wxWidgets — видел исключительно на уровне hello world. О sciter узнал только недавно, не щупал.
Теперь мнение: Qt однозначно лучше для коммерческих и долгосрочных проектов, где сложность превышает пару окон и нужно делать кастомные контролы. Причины очень простые — отличная документация практически по всем фичам, с примерами. Плюс — огромное комьюнити, практически на всё можно найти ответы на SO. И достаточно понятные исходники.
Re[6]: Библиотека для создания графических интерфейсов пользователя
_>О, уже всё есть? И как это я пропустил то такие позитивные новости... ))) Т.е. я могу спокойно программировать GUI (сереализацию и т.п. вопросы не рассматриваем) на Qt без использования при сборке проекта их препроцессора? )
Здравствуйте, SaZ, Вы писали:
CS>>А каждый QPointer содержит в себе QWeakPointer который уже есть refcounter штука SaZ>Ну так надо понимать, что такое QPointer — это умный указатель, который автоматически зануляется, если уничтожить объект (который обязательно QObject) в другом месте. Я почему-то изначально думал, что это реализовано на сигналах/слотах, но через weak pointer действительно эффективнее. SaZ>По сути это и есть QWeakPoniter, для конструирования которого не нужно иметь экземпляр QSharedPointer. SaZ>Так что в этом случае использование подсчёта ссылок — общепринятый подход.
но тут надо понимать, что при использовании в разных потоках можно получить проблемы с обращением к удаленному объекту.
Здравствуйте, Marty, Вы писали:
M>У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения.
API не меняется, обратная совместимость есть. Что еще надо?
M>А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю.
Это случается примерно раз в 15 лет.
M>И колбасит их постоянно из стороны в сторону. wxWidgets и Sciter — более консервативны, а wxWidgets еще и довольно похож на MFC, что довольно приятно.
M>Я, правда, MFC не использовал плотно, плотно только с WTL было. А на wxWidgets проект десятилетней давности без проблем за пару дней адаптируется под новый wxWidgets, и это приятно. С КуТе это гемор на несколько месяцев обычно
Зачем вам адоптировать старый проект под новую Qt? Ради новых фич? Так в wxWidgets этих фич нет вообще, так что сравнение не имеет смысла
Re[19]: Библиотека для создания графических интерфейсов поль
Здравствуйте, Zhendos, Вы писали:
Z>И в районе Qt 5.5 они сделали deprecated Script Engine, но QJSEngine идущий ему на смену не обладает всей Z>функциональностью ScriptEngine.
ScriptEngine был помечен как deprecated уже лет 10, где-то с 4.8, но они его поставляли по просьбам пользователей.
Re[17]: Библиотека для создания графических интерфейсов польз
Здравствуйте, night beast, Вы писали:
NB>но тут надо понимать, что при использовании в разных потоках можно получить проблемы с обращением к удаленному объекту.
Обчно нет, так как обращение к наследникам QObject чаще всего не прямое, а через signal-slot.
Здравствуйте, SaZ, Вы писали:
SaZ>Qt vs HTML.
А тебе исходники того, что они там демонстрируют, не попадались? На картинке красиво, но хотелось бы потрогать...
Re[18]: Библиотека для создания графических интерфейсов поль
Здравствуйте, Skorodum, Вы писали:
NB>>но тут надо понимать, что при использовании в разных потоках можно получить проблемы с обращением к удаленному объекту. S>Обчно нет, так как обращение к наследникам QObject чаще всего не прямое, а через signal-slot.
QPointer никак с наследниками не связан. Просто обычно наследники работают в родительском потоке, поэтому конкурентного доступа к объекту нет.
но если будет обращение к QPointer'у из другого потока, то можно нарваться на грабли (из слабого получаем сырой указатель, в этот момент происходит его разрушение и в итоге работаем с удаленным объектом)
моловероятно, но возможно
Здравствуйте, night beast, Вы писали:
NB>QPointer никак с наследниками не связан. Просто обычно наследники работают в родительском потоке, поэтому конкурентного доступа к объекту нет. NB>но если будет обращение к QPointer'у из другого потока, то можно нарваться на грабли (из слабого получаем сырой указатель, в этот момент происходит его разрушение и в итоге работаем с удаленным объектом) NB>моловероятно, но возможно
Из других потоков обращение обычно идет через сигнал-слот и никаких проблем нет
Re[17]: Библиотека для создания графических интерфейсов польз
Здравствуйте, night beast, Вы писали:
NB>но тут надо понимать, что при использовании в разных потоках можно получить проблемы с обращением к удаленному объекту.
Да, вы очень правильно говорите, что надо понимать, что и когда использовать.
Одна из фич QObject-а это возможность задать принадлежность к определённому потоку (при наличии у него event-loop). В этом потоке и будут вызываться слоты. Не более. QObject изначально не проектировался для того, чтобы быть потокобезопасным. А QPointer может применяться только к наследникам QObject. И удалять такой объект можно через deleteLater (очень удачный подход для сигнал/слотовой системы).
Делать на С++ потокобезопасный класс — это целиком ответственность программиста, а не фреймворка. К реализации QPointer это никакого отношения не имеет.
Если вы явно не контролируете время жизни объекта, то стоит использовать QSharedPointer/std::shared_ptr. Тогда не будет описанной вами проблемы. Во всех остальных случаях можно или std::unique_ptr/QScopedPointer, или использовать управление памятью через иерархию QObject-ов.
Где-то была заметка по поводу того, почему в Qt только один поток работает с GUI (в случае QtWidgets, а не QtQuick). Если кратко, то потому что профит от реализации многопоточности незначительный, а вот качество и раздутость кода очень сильно страдает. Вообще, мне очень нравится такой подход, если хочешь что-то сложное отобразить, то собираешь данные в отдельных потоках, строишь модель и потом, когда всё готово — кидаешь сигнал. При этом сохраняется полная отзывчивость интерфейса.
