_>Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным.
Ты уже сам определись: или "исключительно функциональный стиль" или "ООП является вполне себе естественным и оптимальным".
Что из этого верно?
CS>>Тогда как практически весь современный UI (Web это 99.99% всего UI) крайне далек от той изначальной модели.
_> _>Предлагаю тебе просто открыть исходники какого-нибудь там Webkit'a и посмотреть своими глазами на реализацию этого самого Web UI — ты там увидишь всё те же самые C++ классы в классической ООП схеме.
Sciter тоже написан на C++ и использует классы и всё такое. Более того у меня используется динамическое наследование, см. мою дискуссию на SO. Здесь тоже обсуждалось. Так вот такие трюки это не совсем C++, а скорее C + VTBL руками сделанная.
Но суть в том что класс в смысле C++ там только один — namespace dom { class element; }. Т.е. снаружи такой системы UI это композиция однотипных элементов.
+ система event handlers которые уже и определяют как эти LEGO блоки себя ведут. Вот эти три <text>+<button>+<popup> собранные в одном месте есть COMBOBOX, а этот один <textarea> есть текстовый редактор.
Современная ситуация такова что базовых/классических элементов которые раньше использовались в UI в реальности не стало хватать с самого начала.
Появились всякие там OWNERDRAW и прочее попытки сделать это всё в ООП стиле... Ну кошмарно же получилось...
CS>>Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами.
_>И это всё отлично ложится как раз на ООП модель.
Я не отрицаю, но давай уточним что такое "ООП модель". Это модель внутреннего устройства (WebKit, Gecko, Trident, h-smile engine в Sciter)
или то что предлагается использовать юзерам твоей OOП (MFC,Qt,wxWidgets,etc.)?
Если внутреннего устройства то это никого не парит.
Важно как API этого GUI engine устроен и его гранулярность.
CS>>Во многом functional и declarative programming. Проблема в том что UI имеет свою внутреннюю логику.
_>В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход.
Всё остальное поскипал, но вот на том популярном заблуждении хотел бы остановится.
Это вот
<body>hello world</body>
24 байта занимает. Предложи более компактный способ сериализации. И способ восстановления из того формата который существенно быстрее скажем этого вот моего парсера который я использую в sciter.
При все при том что координаты ты сериализовать не можешь — они не известны в общем случае (разные DPI и form factors target devices).
CS>>Без GC получить динамический UI сложно.
_>Полная ерунда и невладение C++.
Подозреваю что мой код работает на твоем компьютере в одном из установленных продуктов.
Сомневаюсь что твой — на моих.
Это я про объективные оценки того кто чем владеет.
CS>>Angular и React со товарищи рулят не просто так. Declarative code binding это не прихоть, а требование времени. CS>>Мы перестали делать приложения "на всю жизнь". Время жизни UI решений теперь измеряется месяцами если не неделями. CS>>Поэтому нужно уметь быстро подстраиваться под архитектуры OS и пр. Сколько жила Windows XP? А сколько Windows 7, а Windows 8. CS>>Про Windows 10 я вообще молчу. Сейчас уже выходит Creators Update... Там некоторые UI принципы вообще другие... CS>>Как пример сколько времени мы смотрели на кнопки в виде башни танка Тигр. А сколько в виде башни T64 (WinXP...Win7)? А сколько на современные плоские? CS>>Сколько времени на цельнолитые windows? А сколько на современные blur behind (MacOS, Windows 8 и кульминация в Creators Update)...
_>Ты действительно считаешь, что правильное GUI должно это всё задавать в себе? Вообще то у разных людей разные вкусы и разные ОС, которые они настраивают под эти вкусы. Так что правильное GUI в идеале должно полностью соответствовать локальным настройкам, а не навязывать свои (такие приложения выделяются в негативную сторону, и кстати обычно это как раз приложения с веб интерфейсом или написанные на Java).
Я не знаю что такое "локальные настройки" в современном мире.
Windows XP и Windows 10 — там не то что настройки там UI API разные. В одном есть HWND во втором — уже нет (UWP).
А Linux? Gnome и KDE и твое приложение с тем самым .ui файлом что должно использовать?
Эта мулечка уже протухла лет 10 тому как... Какие нафиг "локальные настройки" в Microsoft Office? А в Visual Studio?
А если сравнить Sublime Text UI и скажем какой Notepad++ — ну блин UI/UX disaster же...
Здравствуйте, MTD, Вы писали:
NB>>что, отладчик для тебя слишком сложно?
MTD>Зачем отладчик? В отладчике появится код которого нет в исходнике? Не пытайся надувать щеки, выглядит смешно — этакий напакостивший школьник.
он поможет тебе за 5 мин понять, что конкретно происходит.
вместо мозго-ва, которым ты второй день занимаешься.
MTD>А теперь еще раз повторю вопрос:
MTD>Покажи конкретно в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни, покажи в каком случае этот счетчик увеличивается и уменьшается, покажи где там delete this, объясни как вообще этот счетчик может работать, если в Qt QObjectы везде передаются как голые указатели.
ок, понял что 5-строчный пример для тебя сложновато. нужно разжевать.
qobject_p.h
// указатель на счетчик
QAtomicPointer<QtSharedPointer::ExternalRefCountData> QObjectPrivate::sharedRefcount;
qsharedpointer_impl.h
// инициализация/инкремент sharedRefcount счетчика в объекте ptrtemplate <class X> inline QWeakPointer::QWeakPointer(X *ptr, bool) : d(ptr ? Data::getAndRef(ptr) : Q_NULLPTR), value(ptr) { }
// изменение счетчикаinline void QWeakPointer::internalSet(Data *o, T *actual)
// версия 4 -- инициализация sharedRefcount счетчика в объекте ptr. в 5-й присваивание убралиtemplate <typename Deleter> inline QSharedPointer::QSharedPointer(T *ptr, Deleter deleter) : value(ptr) { internalConstruct(ptr, deleter); }
// изменение счетчикаinline void QSharedPointer::internalSet(Data *o, T *actual)
// изменение счетчика + удаление при необходимостиstatic void QSharedPointer::deref(Data *d) Q_DECL_NOTHROW
// инициализация/инкремент sharedRefcount счетчика в объекте pinline QPointer::QPointer(T *p) : wp(p, true) { }
с тем что в QT везде передают голые указатели (QPointer тоже применяется, но редко) я не спорил, если ты не заметил
тебя ткнули носом в твое заблуждение насчет отсутствия счетчика ссылок в QObject
так доступно?
если нет, то я уже и не знаю что поможет
MTD>Нормальный, конкретный вопрос, на который ты мог ответить как взрослый человек "Ой, был не прав", но предпочел устроить клоунаду, за которой я с интересом теперь наблюдаю
я ответил, просто кто-то не смог понять
ну ты давай, не сдавайся, еще раз расскажи про балабольство или еще чего придумай...
Здравствуйте, c-smile, Вы писали:
_>>Я сам предпочитаю во многих местах использовать исключительно функциональный стиль. Только вот есть небольшой нюанс: как раз для GUI стиль ООП является вполне себе естественным и оптимальным. CS>Ты уже сам определись: или "исключительно функциональный стиль" или "ООП является вполне себе естественным и оптимальным". CS>Что из этого верно?
Вроде как вполне ясно написано "во многих местах". GUI очевидно к этим местам не относится. Ну разве что я обработчики иногда реализую через лямбды, но это вряд ли можно считать настоящим функциональным стилем. )))
CS>>>Тогда как практически весь современный UI (Web это 99.99% всего UI) крайне далек от той изначальной модели. _>> _>>Предлагаю тебе просто открыть исходники какого-нибудь там Webkit'a и посмотреть своими глазами на реализацию этого самого Web UI — ты там увидишь всё те же самые C++ классы в классической ООП схеме.
CS>Но суть в том что класс в смысле C++ там только один — namespace dom { class element; }. Т.е. снаружи такой системы UI это композиция однотипных элементов.
Ну как бы в том же Qt у тебя каждый объект так же может быть проинтерпретирован как экземпляр класса QWidget. И что с того то? Как бы полиморфизм — это и есть базовая особенность ООП. Непонятно что ты этим хотел сказать.
CS>+ система event handlers которые уже и определяют как эти LEGO блоки себя ведут. Вот эти три <text>+<button>+<popup> собранные в одном месте есть COMBOBOX, а этот один <textarea> есть текстовый редактор.
Похоже что ты всё же не заглядывал в исходники современных браузеров, но при этом пишешь тут какие-то свои фантазии на эту тему. Загляни хотя бы в папку core/html вебкита и полюбуйся на представленные там файлы. Ты там увидишь и отдельно файлы HTMLSelectElement и отдельно HTMLTextAreaElement и т.д. — собственно все html контролы (да и не только контролы, а просто все тэги). И каждый из них имеет классическое наследование от HTMLElement (или кого-то из его наследников) с кучей методов, помеченных как override. Я даже не могу себе представить более классическую ООП схему. )))
CS>>>Т.е. весь современный UI это системы Lego блоков (DOM элементов) с динамически назначаемыми event handlers, свойствами и методами. _>>И это всё отлично ложится как раз на ООП модель. CS>Я не отрицаю, но давай уточним что такое "ООП модель". Это модель внутреннего устройства (WebKit, Gecko, Trident, h-smile engine в Sciter) CS>или то что предлагается использовать юзерам твоей OOП (MFC,Qt,wxWidgets,etc.)? CS>Если внутреннего устройства то это никого не парит. CS>Важно как API этого GUI engine устроен и его гранулярность.
API абсолютно одинаковый — набор видимых (контролов) или невидимых (менеджеров разметки и т.п.) объектов, которые можно складывать иерархически (получая некое итоговое дерево). А с учётом наличия компиляторов/интерпретаторов ui/xrc файлов (которые XML внутри), я вообще не вижу никакой разницы между html движками и Qt/wxWidget. Ну кроме того, что HTML движки не представляют возможности статической компиляции в C++.
_>>В HTML это происходит на машине клиента в момент загрузки страницы, а в Qt на машине разработчика в момент компиляции *.ui файлов — более эффективный подход. CS>Всё остальное поскипал, но вот на том популярном заблуждении хотел бы остановится. CS>Это вот CS>
CS><body>hello world</body>
CS>
CS>24 байта занимает. Предложи более компактный способ сериализации. И способ восстановления из того формата который существенно быстрее скажем этого вот моего парсера который я использую в sciter. CS>При все при том что координаты ты сериализовать не можешь — они не известны в общем случае (разные DPI и form factors target devices).
Какая ещё сериализация, ты вообще о чём? Мы тут обсуждаем GUI! Или у тебя приложение стартует, подгружает с сервера свой GUI и только потом его рендерит? В приложение у тебя будет просто скомпилированная строка типа my_layout.addWidget(new QLabel("hello world")), которая априори эффективнее любого сочетания парсер+рендер.
_>>Ты действительно считаешь, что правильное GUI должно это всё задавать в себе? Вообще то у разных людей разные вкусы и разные ОС, которые они настраивают под эти вкусы. Так что правильное GUI в идеале должно полностью соответствовать локальным настройкам, а не навязывать свои (такие приложения выделяются в негативную сторону, и кстати обычно это как раз приложения с веб интерфейсом или написанные на Java). CS>Я не знаю что такое "локальные настройки" в современном мире.
Ты похоже осознал тенденцию 2000-ых, когда все переходили в веб, но как-то пропустил тенденцию 2010-ых, когда все переходили снова на приложения (только уже мобильные, а не десктопные). Сейчас у каждого приличного сайта по своему приложению в двух главных магазинах. И эти приложения на каждой из платформ выглядят нативно, что сразу заметно — стиль iOS существенно отличается от Android. Это уже не говоря о том, что они меняются от версии к версии.
CS>Windows XP и Windows 10 — там не то что настройки там UI API разные. В одном есть HWND во втором — уже нет (UWP). CS>А Linux? Gnome и KDE и твое приложение с тем самым .ui файлом что должно использовать?
Вот именно, что всё разное. И если при этом инструмент позволяет разработчику забыть про всю эту разность (при этом корректно отображая на каждой платформе все нужные особенности), то это правильный инструмент для кроссплатформенной разработки.
Re[6]: Библиотека для создания графических интерфейсов пользователя
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Zhendos, Вы писали:
_>О, уже всё есть? И как это я пропустил то такие позитивные новости... ))) Т.е. я могу спокойно программировать GUI (сереализацию и т.п. вопросы не рассматриваем) на Qt без использования при сборке проекта их препроцессора? )
В теории конечно да, т.е. чтобы подключить свою функцию к сигналу она больше не должна
быть объявлена в секции slot, т.е. в классе не обязателен Q_OBJECT и соотвественно
через moc объявление класса пропускать не нужно.
Вот если сигналы объявлять то нужен препроцессор,
т.к. это нужно чтобы и старый до C++11 и новый стиль работы одновременно
поддерживать, плюс для IDE, плюс наверное для JavaScrit движка.
Вот если бы была доступна "интроспекция" то можно было бы и не использовать moc для этого.
Re[16]: Библиотека для создания графических интерфейсов поль
Здравствуйте, MTD, Вы писали:
R>>>>я выразил свое мнение: что на sciter мне лично было легче создать гуй
MTD>Нет, твой тезис звучал иначе, в твое вранья я тебя уже ткнул.
Остыньте, горячие финские парни
Qt — оно конечно модно и прогрессивно, но имхо — так себе, я его откушал, спасибо, больше не хочется. Sciter — всё думаю попробовать, но кроме игры с демками — пока не сподобился. Для себя я выбрал wxWidgets и пока не пожалел.
У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения. А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю. И колбасит их постоянно из стороны в сторону. wxWidgets и Sciter — более консервативны, а wxWidgets еще и довольно похож на MFC, что довольно приятно. Я, правда, MFC не использовал плотно, плотно только с WTL было. А на wxWidgets проект десятилетней давности без проблем за пару дней адаптируется под новый wxWidgets, и это приятно. С КуТе это гемор на несколько месяцев обычно
Здравствуйте, MTD, Вы писали:
MTD>При чем тут Qt? За поддержку старых учеток отвечает сервер, то что тебя пока не вынудили апгрейднуть учетку, не значит что это не произойдет. Про 20 лет ты конечно не помнишь, за это время протоколы менялись несколько раз. Если твоя боль вызванная появлением непонятных для тебя слов (это же на слово Qt ты так возбудился, как и ряд забавных персонажей?) утихнет, можешь историю аськи прочитать, например, про AOL которая фактически убила аську и менявшая протоколы для борьбы с неофициальными клиентами.
Про забавных персонажей — это ты в зеркало заглянул, что ли?
Здравствуйте, Marty, Вы писали:
M>Qt — оно конечно модно и прогрессивно, но имхо — так себе, я его откушал, спасибо, больше не хочется. Sciter — всё думаю попробовать, но кроме игры с демками — пока не сподобился. Для себя я выбрал wxWidgets и пока не пожалел. M>У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения. А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю. И колбасит их постоянно из стороны в сторону. wxWidgets и Sciter — более консервативны, а wxWidgets еще и довольно похож на MFC, что довольно приятно. Я, правда, MFC не использовал плотно, плотно только с WTL было. А на wxWidgets проект десятилетней давности без проблем за пару дней адаптируется под новый wxWidgets, и это приятно. С КуТе это гемор на несколько месяцев обычно
Главный минус wxWidgets в том, что она до сих пор не может (https://wiki.wxwidgets.org/WxAndroid/Status) Android — лидирующую ОС на планете в данный момент. В наше время заявлять "кроссплатформенность" без Андроида просто смешно.
Ну а для исключительно десктопного ПО данная библиотека действительно является довольно не плохим решением.
Re[18]: Библиотека для создания графических интерфейсов поль
Здравствуйте, alex_public, Вы писали:
_>Главный минус wxWidgets в том, что она до сих пор не может (https://wiki.wxwidgets.org/WxAndroid/Status) Android — лидирующую ОС на планете в данный момент. В наше время заявлять "кроссплатформенность" без Андроида просто смешно.
У них что-то двигается в эту сторону.
А ты КуТе щупал на эту тему? Я щупал. Даже с большим геморром на андроиде уродец получается. А если хочешь нормально, гуй под андроид всё равно надо переписывать с нуля
_>Ну а для исключительно десктопного ПО данная библиотека действительно является довольно не плохим решением.
И я о том.
А чтобы везде работало одинаково — для приложений с не слишком сложным UI — опять же sciter гораздо лучше, чем куте
Здравствуйте, Zhendos, Вы писали:
_>>О, уже всё есть? И как это я пропустил то такие позитивные новости... ))) Т.е. я могу спокойно программировать GUI (сереализацию и т.п. вопросы не рассматриваем) на Qt без использования при сборке проекта их препроцессора? ) Z>https://wiki.qt.io/New_Signal_Slot_Syntax Z>В теории конечно да, т.е. чтобы подключить свою функцию к сигналу она больше не должна Z>быть объявлена в секции slot, т.е. в классе не обязателен Q_OBJECT и соотвественно Z>через moc объявление класса пропускать не нужно.
Ну так человеческий вид вызова функции connect я давно знаю и только такой и использую. Речь не об этом, а о разделах signal/slot в классах.
Z>Вот если сигналы объявлять то нужен препроцессор, Z>т.к. это нужно чтобы и старый до C++11 и новый стиль работы одновременно Z>поддерживать, плюс для IDE, плюс наверное для JavaScrit движка.
Тут в первую очередь интересует нормальная работа их дизйанера (который по команде в нём автоматически вставляет нужные обработчики в исходники).
Z>Вот если бы была доступна "интроспекция" то можно было бы и не использовать moc для этого.
По нормальному для реализации обработчиков никакой интроспекции не надо. Оно спокойно работает во всех GUI библиотеках, включая самые древние. Потребность в этом у Qt происходит исключительно от кривой изначальной архитектуры. Которая кстати во многом такая — кругом в библиотеке виден "Java-стиль", который полностью расходится с тенденциями развития C++ последнего десятилетия. И самая печаль в том, что этот уродец является сейчас лучшим из существующих решений в данной области (причём не только в мире C++, а вообще среди любых GUI библиотек).
Re[19]: Библиотека для создания графических интерфейсов поль
Здравствуйте, Marty, Вы писали:
_>>Главный минус wxWidgets в том, что она до сих пор не может (https://wiki.wxwidgets.org/WxAndroid/Status) Android — лидирующую ОС на планете в данный момент. В наше время заявлять "кроссплатформенность" без Андроида просто смешно. M>У них что-то двигается в эту сторону.
Там концептуальная проблема вследствие принципиально другой архитектуры. Qt рисует абсолютно всё сама, требуя от нижележащей платформы только поверхность для рисования и системные настройки стилей (если таковые есть — Qt умеет работать и без ОС вообще, на голом железе). wxWidgets же наоборот принципиально используется только системные контролы на всех платформах. В принципе лично мне подход wxWidgets нравится даже больше, т.к. он обеспечивает абсолютно родное поведение приложение (у Qt всё же бывают мелких огрехи в стилях или поведение контролов). Однако в случае Андроида именно этот подход наткнулся на концептуальную проблему — системные контролы там предоставляются только в виде Java API, а нативному коду предоставляется только та самая поверхность для рисования. Поэтому Qt портировалась на Андроид элементарно (собственно данная ОС для Qt практически ничем не отличается от других), а у wxWidgets серьёзные проблемы с осуществлением полноценного механизма (прокси) для вызова Java API из C++. Кстати, в Qt этот механизм тоже применяется, но только для нескольких важных системных функций, недоступных из нативного API. А wxWidget надо протаскивать через эту штуку по сути всю библиотеку — это огромный объём работы, который очевидно не под силу нескольким энтузиастам, развивающим wxWidgets.
M>А ты КуТе щупал на эту тему? Я щупал. Даже с большим геморром на андроиде уродец получается. А если хочешь нормально, гуй под андроид всё равно надо переписывать с нуля
Щупал и у меня всё отлично работает. Без всяких гемморов и получается совсем не уродец. Единственное, что это было не портирование существующего приложения, а изначальная разработка приложения, работающего сразу под всеми платформами (десктопными и мобильными). Так что оно с самых первых шагов тестировалось и корректировалось для всех ОС.
Re[2]: Библиотека для создания графических интерфейсов польз
Здравствуйте, night beast, Вы писали:
NB>он поможет тебе за 5 мин понять, что конкретно происходит.
В QObject нет счетчика ссылок управляющего его временем жизни, если бы он был ты бы не кривлялся а назвал файл и строчку.
NB>вместо мозго-ва, которым ты второй день занимаешься.
Это вроде ты как ребенок все отмазаться пытаешься, выглядит глупо
MTD>>А теперь еще раз повторю вопрос:
MTD>>Покажи конкретно в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни, покажи в каком случае этот счетчик увеличивается и уменьшается, покажи где там delete this, объясни как вообще этот счетчик может работать, если в Qt QObjectы везде передаются как голые указатели.
NB>ок, понял что 5-строчный пример для тебя сложновато. нужно разжевать.
Я понимаю, тебе наверное больно, но ты попробуй понять написанное:
Покажи конкретно в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни, покажи в каком случае этот счетчик увеличивается и уменьшается, покажи где там delete this, объясни как вообще этот счетчик может работать, если в Qt QObjectы везде передаются как голые указатели.
NB>// указатель на счетчик NB>QAtomicPointer<QtSharedPointer::ExternalRefCountData> QObjectPrivate::sharedRefcount;
Конкретно это мы с тобой разбирали уже — это никакой не счетчик ссылок управляющий жизнью QObject.
NB>с тем что в QT везде передают голые указатели (QPointer тоже применяется, но редко) я не спорил, если ты не заметил
Тогда как может работать счетчик ссылок? Если используются голые указатели невозвожно отследить время жизни и корректно удалить, когда на объект не осталось ссылок.
MTD>>Нормальный, конкретный вопрос, на который ты мог ответить как взрослый человек "Ой, был не прав", но предпочел устроить клоунаду, за которой я с интересом теперь наблюдаю
NB>я ответил, просто кто-то не смог понять
Своим бла-бла смотри отладчик? Не катит.
NB>ну ты давай, не сдавайся, еще раз расскажи про балабольство или еще чего придумай...
Зачем придумывать, в который раз тот-же самый вопрос:
Покажи конкретно в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни, покажи в каком случае этот счетчик увеличивается и уменьшается, покажи где там delete this, объясни как вообще этот счетчик может работать, если в Qt QObjectы везде передаются как голые указатели.
Re[17]: Библиотека для создания графических интерфейсов поль
Здравствуйте, Marty, Вы писали:
M>Qt — оно конечно модно и прогрессивно
Ты не в теме, модно и прогрессивно — Sciter.
M>У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения.
Мир не стоит на месте. Фреймворк живет — это же не полумертвый wxWidgets на котором весь софт выглядит сделанным 15 лет назад и не Sciter который пилит один хоть и талантливый человек, а потому шаг влево, шаг вправо — Segmentation fault.
M>А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю.
Ой, да хорош сказки рассказывать (я конечно могу допустить, что такие проблемы быть могут, но ты же тогда сможешь о ним рассказать?). Я конечно третий не застал, начал с четвертого в 2008 году, потом когда переходил на пятый весь гемор был переписать сборочные скрипты, код скомпилировался и заработал.
Re[18]: Библиотека для создания графических интерфейсов поль
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, Marty, Вы писали:
M>>Qt — оно конечно модно и прогрессивно
MTD>Ты не в теме, модно и прогрессивно — Sciter.
M>>У Qt — на мой взгляд есть один, но большой минус — оно слишком динамично развивается, даже в минорных релизах есть местами значительные изменения.
MTD>Мир не стоит на месте. Фреймворк живет — это же не полумертвый wxWidgets на котором весь софт выглядит сделанным 15 лет назад и не Sciter который пилит один хоть и талантливый человек, а потому шаг влево, шаг вправо — Segmentation fault.
+1 Пришлось как-то пересобирать http://www.ecoscentric.com/devzone/configtool.shtml написанное на wxWidgets,
такой гемор, тогда когда я его использовал разные дистрибутивы linux поставляли wxWidget c/без unicode,
с gtk2 или 3 и т.д. и т.п., пришлось руками компилировать еще и wxWidgets и таскать вместе с пришложением
библиотеки. А если бы это была бы не внутренняя утилита, а ее заказчику поставляли, ее что для всех вариантов тестировать?
Умножая на количество дистрибутивов RedHat/Ubuntu/Suse это сколько же гемора?
M>>А уж между мажорными версиями переходить — один сплошной гемморой. Это я как человек, переходивший с Qt3 на Qt4, а потом на Qt5 говорю.
MTD>Ой, да хорош сказки рассказывать (я конечно могу допустить, что такие проблемы быть могут, но ты же тогда сможешь о ним рассказать?). Я конечно третий не застал, начал с четвертого в 2008 году, потом когда переходил на пятый весь гемор был переписать сборочные скрипты, код скомпилировался и заработал.
Здесь согласен и не согласен.
Имел опыт перехода с Qt 2 -> Qt 3 -> Qt 4 -> Qt 5.
С Qt 2->3 помню не очень, но раз ничего не запомнил значит проблем особых не было.
Для перехода с Qt 3 на 4 была qt3support библиотека, т.е. по сути все что ни выкинули, можно было
вернуть этой библиотекой, а потом постепенно от нее избавляться. Поэтому портирование было элементарным.
с Qt 4 на 5 вообще не было проблем, правишь заголовочные файлы и все.
Но, с другой стороны я помню в районе Qt 4.6 они выкинули класс, на котором был завязан показ встроенной
справки, и не помню уже но какие-то были большие трудности в использовании того решения что они предлагали вместо.
И в районе Qt 5.5 они сделали deprecated Script Engine, но QJSEngine идущий ему на смену не обладает всей
функциональностью ScriptEngine.
Re[8]: Библиотека для создания графических интерфейсов пользователя
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Zhendos, Вы писали:
Z>>Вот если сигналы объявлять то нужен препроцессор, Z>>т.к. это нужно чтобы и старый до C++11 и новый стиль работы одновременно Z>>поддерживать, плюс для IDE, плюс наверное для JavaScrit движка.
_>Тут в первую очередь интересует нормальная работа их дизйанера (который по команде в нём автоматически вставляет нужные обработчики в исходники).
_>По нормальному для реализации обработчиков никакой интроспекции не надо. Оно спокойно работает во всех GUI библиотеках, включая самые древние.
А можно подробности? Вот у вас есть разделяемая библиотека с виджетами.
И по вашим словам интроспекции никакой не нужно, какими образом без всякой
мета информации IDE может понять какие виджеты есть в этой библиотеке, и какие сигналы
у этих виджетов есть? Не говорю уже о свойствах, которые мы по вашему предложению
оставляем за скобками.
Re[35]: Библиотека для создания графических интерфейсов поль
Здравствуйте, MTD, Вы писали:
NB>>он поможет тебе за 5 мин понять, что конкретно происходит.
MTD>В QObject нет счетчика ссылок управляющего его временем жизни, если бы он был ты бы не кривлялся а назвал файл и строчку.
NB>>вместо мозго-ва, которым ты второй день занимаешься.
MTD>Это вроде ты как ребенок все отмазаться пытаешься, выглядит глупо
это точно. ну да чего еще от фанакика ожидать
MTD>Я понимаю, тебе наверное больно, но ты попробуй понять написанное:
MTD>
MTD>Покажи конкретно в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни, покажи в каком случае этот счетчик увеличивается и уменьшается, покажи где там delete this, объясни как вообще этот счетчик может работать, если в Qt QObjectы везде передаются как голые указатели.
я тебе показал. если нужен конкретный файл и номер строки, то пожалуйста, мне не жалко
qatomic_cxx11.h:141
return ++_q_value != 0;
qatomic_cxx11.h:147
return --_q_value != 0;
полегчало?
NB>>// указатель на счетчик NB>>QAtomicPointer<QtSharedPointer::ExternalRefCountData> QObjectPrivate::sharedRefcount;
MTD>Конкретно это мы с тобой разбирали уже — это никакой не счетчик ссылок управляющий жизнью QObject.
хорошо, это не счетчик ссылок. тогда что, по твоему?
NB>>с тем что в QT везде передают голые указатели (QPointer тоже применяется, но редко) я не спорил, если ты не заметил
MTD>Тогда как может работать счетчик ссылок? Если используются голые указатели невозвожно отследить время жизни и корректно удалить, когда на объект не осталось ссылок.
очевидно, по крайней мере мне, что он работает когда используются не голые указатели QSheredPointer, QWeekPointer, QPointer.
что уже на протяжении нескольких дней я и пытаюсь до тебя донести.
насчет шареда признаю, был не прав. в той версии, что мы используем, все именно так, но сейчас уже эту возможность убрали.
вик поинтеры по прежнему используются.
NB>>я ответил, просто кто-то не смог понять
MTD>Своим бла-бла смотри отладчик? Не катит.
да кто бы сомневался.
NB>>ну ты давай, не сдавайся, еще раз расскажи про балабольство или еще чего придумай...
MTD>Зачем придумывать, в который раз тот-же самый вопрос:
ладно, я понял. случай безнадежный
Re[36]: Библиотека для создания графических интерфейсов поль
Здравствуйте, night beast, Вы писали:
NB>это точно. ну да чего еще от фанакика ожидать
Ох, уже который раз переход на мою личность, вот только не делает это тебя правым. Кстати, почему ты упорно называешь меня фанатиком? Я просто указываю на то, что ты не прав как в Qt контролируется время жизни QObject.
MTD>>
MTD>>Покажи конкретно в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни, покажи в каком случае этот счетчик увеличивается и уменьшается, покажи где там delete this, объясни как вообще этот счетчик может работать, если в Qt QObjectы везде передаются как голые указатели.
NB>я тебе показал. если нужен конкретный файл и номер строки, то пожалуйста, мне не жалко
Ты снова показываешь не то. Вопрос звучал конкретно:
в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни
NB>хорошо, это не счетчик ссылок. тогда что, по твоему?
Там даже комментарий написали:
these objects are all used to indicate that a QObject was deleted
Это нужно чтобы проверить, что объект уже был удален, временем жизни самого объекта это не управляет.
MTD>>Тогда как может работать счетчик ссылок? Если используются голые указатели невозвожно отследить время жизни и корректно удалить, когда на объект не осталось ссылок.
NB>очевидно, по крайней мере мне, что он работает когда используются не голые указатели QSheredPointer, QWeekPointer, QPointer.
Так можно, например, std::vector положить в std::shared_ptr и утверждать, что std::vector использует счетчик ссылок.
NB>насчет шареда признаю, был не прав. в той версии, что мы используем, все именно так, но сейчас уже эту возможность убрали. NB>вик поинтеры по прежнему используются.
Re[37]: Библиотека для создания графических интерфейсов поль
Здравствуйте, MTD, Вы писали:
MTD>Ох, уже который раз переход на мою личность, вот только не делает это тебя правым. Кстати, почему ты упорно называешь меня фанатиком? Я просто указываю на то, что ты не прав как в Qt контролируется время жизни QObject.
я называю тебя фанатиком потому что ты, ни разу не попробовав, начал обсирать годную либу, пропихивая вместо нее Qt.
причем умудрившись при этом наехать на остальных, не разделяющих твоего мнения.
это я объясняю на случай, если ты не понял, чего это до тебя докапываются.
NB>>я тебе показал. если нужен конкретный файл и номер строки, то пожалуйста, мне не жалко
MTD>Ты снова показываешь не то. Вопрос звучал конкретно:
MTD>
MTD>в каком файле на какой строке находится счетчик ссылок QObject, который управляет его временем жизни
во-первых, не надо отмазок про управление жизнью. счетчик ссылок временем жизни не занимается.
во-вторых, отмотай тред на мое первое сообщение у увидишь интересующий тебя счетчик. за номером строки можешь обратиться к поисковику.
это не сильно для тебя сложно?
NB>>хорошо, это не счетчик ссылок. тогда что, по твоему?
MTD>Там даже комментарий написали:
просто вопрос. что это такое?
на него ожидается простой ответ. это ...
MTD>>>Тогда как может работать счетчик ссылок? Если используются голые указатели невозвожно отследить время жизни и корректно удалить, когда на объект не осталось ссылок.
NB>>очевидно, по крайней мере мне, что он работает когда используются не голые указатели QSheredPointer, QWeekPointer, QPointer.
MTD>Так можно, например, std::vector положить в std::shared_ptr и утверждать, что std::vector использует счетчик ссылок.
вот есть у тебя сырой указатель на std::vector.
сможешь по нему получить std::weak_ptr?
Re[38]: Библиотека для создания графических интерфейсов поль
Здравствуйте, night beast, Вы писали:
NB>причем умудрившись при этом наехать на остальных, не разделяющих твоего мнения.
Хорошо, всем приношу свои извинения. Давай заканчивать препирательства, в принципе мы оба понимаем, что сейчас демонстрируем баранье упорство докапываясь до формулировок, по-существу все уже и так понятно. Мир, дружба
