Хрен его знает, годится ли wxWidgets в наши дни для чего-то одновременно графически сложного, динамичного, нативно выглядящего, да еще и на high-dpi. Надо пробовать. Но для простых утилиток на дюжину графических элементов, когда слоноподобный Qt нафиг не уперся — wxWidgets живее всех живых. Регулярно обновляемый Cydia Impactor вполне шустренько крутится под Win/Mac/Linux, мало весит и нативно выглядит.
Здравствуйте, Homunculus, Вы писали:
H>Заказчику стрельнуло в башку, что он не хочет Qt. Говорит писать на чистом API. Так как это треш и содомия, то вспомнилось, что лет 10 назад пробовал wxWidgets и очень понравилось. Они живы вообще? По-прежнему все в хидерах и не будет у проги зависимости от внешних либ?
Открываю список и среди неизвестного софта сразу вижу... PostgreSQL! Эти крупные и живее всех живых. Интересно, где они используют wxWidgets? Читаем:
Unlike prior versions that were written in Visual Basic, pgAdmin III is written in C++, using the wxWidgets framework allowing it to run on most common operating systems. The query tool includes a scripting language called pgScript for supporting admin and development tasks. In December 2014, Dave Page, the pgAdmin project founder and primary developer,[68] announced that with the shift towards web-based models, work has begun on pgAdmin 4 with the aim to facilite cloud deployments. In 2016, pgAdmin 4 was released. pgAdmin 4 backend was written in Python, using Flask and Qt framework.
2018-07-12 — pgAgent v4.0.0 Released
...
Remove the dependency on wxWidgets. pgAgent now uses Boost for thread management and synchronisation [Neel Patel]
Хм! "Хороший заказчик, разумный, больше бы таких" (a7d3)
Здравствуйте, Nuzhny, Вы писали:
N>Открываю список и среди неизвестного софта сразу вижу... PostgreSQL! Эти крупные и живее всех живых. Интересно, где они используют wxWidgets? Читаем: N>
N>Unlike prior versions that were written in Visual Basic, pgAdmin III is written in C++, using the wxWidgets framework allowing it to run on most common operating systems. The query tool includes a scripting language called pgScript for supporting admin and development tasks. In December 2014, Dave Page, the pgAdmin project founder and primary developer,[68] announced that with the shift towards web-based models, work has begun on pgAdmin 4 with the aim to facilite cloud deployments. In 2016, pgAdmin 4 was released. pgAdmin 4 backend was written in Python, using Flask and Qt framework.
Был pgAdmin на С++, стал на питоне и что с того?
Тем более, когда в том же абзаце изложено как и почему.
Здравствуйте, a7d3, Вы писали:
A>Был pgAdmin на С++, стал на питоне и что с того? A>Тем более, когда в том же абзаце изложено как и почему.
Не, ну очень логично, когда избавляются от одной С++ библиотеки, но начинают использовать другие: boost и Qt. А Питон — это клей для С++ библиотек, а не основной язык разработки.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, a7d3, Вы писали:
A>>Был pgAdmin на С++, стал на питоне и что с того? A>>Тем более, когда в том же абзаце изложено как и почему.
N>Не, ну очень логично, когда избавляются от одной С++ библиотеки, но начинают использовать другие: boost и Qt. А Питон — это клей для С++ библиотек, а не основной язык разработки.
А если бы они выбрали не Python, а на тот же JavaScript + Electron или же вообще обратно на Visual Basic, то это как-то бы характеризовало wxWidgets? Говорило бы это о том, что от нее избавились?
Здравствуйте, a7d3, Вы писали:
A>А если бы они выбрали не Python, а на тот же JavaScript + Electron или же вообще обратно на Visual Basic, то это как-то бы характеризовало wxWidgets? Говорило бы это о том, что от нее избавились?
Конечно, избавились-то они в любом случае: только от wxWidgets или от всего десктопного решения целиком. Тут надо детально знать причины решения во всех тонкостях.
Тут ещё интересен контекст: в твоей аргументации PostgreSQL идёт аргументом за wxWidgets, потому что присутствует в списке "Software that uses wxWidgets". Но фо факту, PostgreSQL не использует wxWidgets и его надо удалить из этого списка. Мало ли кто использовал, если это уже давно не актуально?
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, a7d3, Вы писали:
A>>А если бы они выбрали не Python, а на тот же JavaScript + Electron или же вообще обратно на Visual Basic, то это как-то бы характеризовало wxWidgets? Говорило бы это о том, что от нее избавились?
N>Конечно, избавились-то они в любом случае: только от wxWidgets или от всего десктопного решения целиком. Тут надо детально знать причины решения во всех тонкостях. N>Тут ещё интересен контекст: в твоей аргументации PostgreSQL идёт аргументом за wxWidgets, потому что присутствует в списке "Software that uses wxWidgets". Но фо факту, PostgreSQL не использует wxWidgets и его надо удалить из этого списка. Мало ли кто использовал, если это уже давно не актуально?
А с моей стороны была какая-то аргументация за wxWidgets? Или же прямой ответ на один из вопросов топик-стартера?
Хорошо, когда люди не желают идти на поводу у хайпа — модных трендов, закрывая глаза на явные недостатки хайповых подходов с решениями. Но это относится к вопросу отказа от Qt, рассмотрению альтернатив при начале нового проекта. А не выбора именно wxWidgets или какого-нибудь WTL, BCG, Enlightenment.
Сколько людей, столько и мнений, даже в таких сугубо технических вопросах. Смотря на один и тот же список проектов люди будут видеть разное и делать совершенно различные выводы. Зато потом будет меньше инфантилизма — перекладывания ответственности за принятое решение на кого-то другого.
Здравствуйте, a7d3, Вы писали:
A>А с моей стороны была какая-то аргументация за wxWidgets?
Была в виде списка проектов, которые его используют. Во всяком случае, твои ссылки воспринимаются, как аргументация.
A>Хорошо, когда люди не желают идти на поводу у хайпа — модных трендов, закрывая глаза на явные недостатки хайповых подходов с решениями. Но это относится к вопросу отказа от Qt, рассмотрению альтернатив при начале нового проекта. А не выбора именно wxWidgets или какого-нибудь WTL, BCG, Enlightenment.
Тогда давай начнём читать стартовое сообщение и увидим: "Говорит писать на чистом API..."
И где тут альтернативы? Если я правильно понял, то предлагается писать на чистом Win32 API, а это и правда полный треш. У меня был богатый опыт со всеми этими процедурами окна, разном поведении на разных версиях ОС, windows subclassing и ручного рисования контролов, когда стандартных средств убогого API не достаточно.
A>Сколько людей, столько и мнений, даже в таких сугубо технических вопросах. Смотря на один и тот же список проектов люди будут видеть разное и делать совершенно различные выводы. Зато потом будет меньше инфантилизма — перекладывания ответственности за принятое решение на кого-то другого.
Сначала надо не просто смотреть на список проектов и доверять ему, а детально разобраться, что там за проекты, что они делают, когда и почему приняли то или иное решение.
N>Тогда давай начнём читать стартовое сообщение и увидим: "Говорит писать на чистом API..." N>И где тут альтернативы? Если я правильно понял, то предлагается писать на чистом Win32 API, а это и правда полный треш. У меня был богатый опыт со всеми этими процедурами окна, разном поведении на разных версиях ОС, windows subclassing и ручного рисования контролов, когда стандартных средств убогого API не достаточно.
Молодец заказчик — обратная совместимость с платформой гораздо более долгоживующая и долгоиграющая вещь, нежели с версией какой-то даже очень популярной библиотеки ставшей фреймверком. А интересы владельца софта (заказчика решения) должны стоять выше желания разработчиков использовать модно-хайповые инструменты (упорно выдаваемые за мейнстрим).
Работа с тем же WTL не была особой мукой и формально подходит под требования реализации на чистом API. Потому что и сама библиотека и GUI-контролы к ней — все header only. Софт получался очень отзывчивым по части взаимодействия с пользователем, даже когда вращался на слабеньких виртуальных машинах.
При современном подходе, вроде MVVM (заменившего три варианта MVC) — можно написать очень неплохое решение. С четким и однозначным отделением абстракцией GUI в отдельный слой. Который и будет меняться при портировании под другую десктоп-платформу или же во время прикручивания веб-интерфейса. Остальная же часть решения при этом портировании может оставаться нетронутой, сохраняя инвестиции в кодовую базу.
Если же допустить в проект Qt или другой схожий монстроидальный фреймверк, умеющий не только GUI, то специфика его использования проникнет чуть ли не во все уровни с подсистемами в разрабатываемом решении.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, a7d3, Вы писали:
A>>Сколько людей, столько и мнений, даже в таких сугубо технических вопросах. Смотря на один и тот же список проектов люди будут видеть разное и делать совершенно различные выводы. Зато потом будет меньше инфантилизма — перекладывания ответственности за принятое решение на кого-то другого.
N>Сначала надо не просто смотреть на список проектов и доверять ему, а детально разобраться, что там за проекты, что они делают, когда и почему приняли то или иное решение.
Люди видят то, что хотят видеть и делают то, что считают нужным. Отбирать это право у людей нельзя, тоталитаризмом уже все наелись вдоволь.
Если у человека нет навыков системного анализа — это его проблема. Нет смысла из жалости подкидывать ему пару рыбин — лучше научить рыбачить, чтобы всегда был сытым, а не только сегодня.
Здравствуйте, a7d3, Вы писали:
A>Молодец заказчик — обратная совместимость с платформой гораздо более долгоживующая и долгоиграющая вещь, нежели с версией какой-то даже очень популярной библиотеки ставшей фреймверком. А интересы владельца софта (заказчика решения) должны стоять выше желания разработчиков использовать модно-хайповые инструменты (упорно выдаваемые за мейнстрим).
Подожди, чуть выше заказчик был молодец, потому что рассматривал альтернативы. А теперь он молодец, потому что их не рассматривает?
Чуть выше ты кидал ссылки в пользу wxWidgets, а теперь против фреймворков и за нативные решения? Хм.
A>Если же допустить в проект Qt или другой схожий монстроидальный фреймверк, умеющий не только GUI, то специфика его использования проникнет чуть ли не во все уровни с подсистемами в разрабатываемом решении.
Ну, это также возможно, как и со всеместным проникновением любого другого API. Зависит исключительно он разработчика, а не от фреймворка.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, a7d3, Вы писали:
A>>Молодец заказчик — обратная совместимость с платформой гораздо более долгоживующая и долгоиграющая вещь, нежели с версией какой-то даже очень популярной библиотеки ставшей фреймверком. А интересы владельца софта (заказчика решения) должны стоять выше желания разработчиков использовать модно-хайповые инструменты (упорно выдаваемые за мейнстрим).
N>Подожди, чуть выше заказчик был молодец, потому что рассматривал альтернативы. А теперь он молодец, потому что их не рассматривает? N>Чуть выше ты кидал ссылки в пользу wxWidgets, а теперь против фреймворков и за нативные решения? Хм.
A>>Если же допустить в проект Qt или другой схожий монстроидальный фреймверк, умеющий не только GUI, то специфика его использования проникнет чуть ли не во все уровни с подсистемами в разрабатываемом решении.
N>Ну, это также возможно, как и со всеместным проникновением любого другого API. Зависит исключительно он разработчика, а не от фреймворка.
Молодец потому что не плывет по течению, а ищет альтернативы впариваемых под видом мейнстрима всяких модно-трендовых решений.
Что ни проект с гуями на Qt, так вечно использование этого самого Qt размазано где только можно — на всех слоях с уровнями. В основном из-за того, что это не совсем GUI'евая либа, а именно framework для клепания приложений, занимающий ныне ту нишу, где раньше царили всякие RAD'ы — Delphi, C++Builder & etc.
Если дело не во фреймверке, то значит его используют в основном лишь такие вот специфичные... гмы... «специалисты».
Здравствуйте, a7d3, Вы писали:
A>Если дело не во фреймверке, то значит его используют в основном лишь такие вот специфичные... гмы... «специалисты».
Только вот мне, как программисту, интересно решать задачу, ради которой делается программа, а не тратить время на всякую фигню типа «чем отличается png от jpg”, “а как тут при редактировании этого, сделать чтоб менялось тут», а как хоткеи с тулбарами делать. И прочий визуальный бред, на который угрохается миллион времени, если делать без фреймворков (Qt в частности), и на которой вообще не обращаешь внимание, если юзаешь уже созданные решения. Причем созданные на одной базе, а не так, что при работе с картинками используется строковый класс ImageLibString, при работе с TreeView какой-нибудь TreeViewLibString, а при драг-н-дропе третий DragdropString.
Кому нравится в этом копаться, а не решать конкретные прикладные задачи — вперед, стряпайте вермишель на WinAPI. У меня заниматься этой фигней нет ни времени, ни желания.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, a7d3, Вы писали:
A>>Если дело не во фреймверке, то значит его используют в основном лишь такие вот специфичные... гмы... «специалисты».
H>Только вот мне, как программисту, интересно решать задачу, ради которой делается программа, а не тратить время на всякую фигню типа «чем отличается png от jpg”, “а как тут при редактировании этого, сделать чтоб менялось тут», а как хоткеи с тулбарами делать. И прочий визуальный бред, на который угрохается миллион времени, если делать без фреймворков (Qt в частности), и на которой вообще не обращаешь внимание, если юзаешь уже созданные решения. Причем созданные на одной базе, а не так, что при работе с картинками используется строковый класс ImageLibString, при работе с TreeView какой-нибудь TreeViewLibString, а при драг-н-дропе третий DragdropString.
H>Кому нравится в этом копаться, а не решать конкретные прикладные задачи — вперед, стряпайте вермишель на WinAPI. У меня заниматься этой фигней нет ни времени, ни желания.
Звучит так, словно существуют магические фреймверки способные заменить толкового GUI'шника в проектной команде, не говоря уже про UX/UI-специалистов.
Здравствуйте, a7d3, Вы писали:
A>Звучит так, словно существуют магические фреймверки способные заменить толкового GUI'шника в проектной команде, не говоря уже про UX/UI-специалистов.
Да, с переходом на Qt я забыл вообще что такое проблемы с GUI. Вспоминаю ужас MFC с содроганием. Про голый api так вообще молчу.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, a7d3, Вы писали:
A>>Звучит так, словно существуют магические фреймверки способные заменить толкового GUI'шника в проектной команде, не говоря уже про UX/UI-специалистов.
H>Да, с переходом на Qt я забыл вообще что такое проблемы с GUI. Вспоминаю ужас MFC с содроганием. Про голый api так вообще молчу.
Никто и не сомневается, что софт делаемый раньше в Delphi/Builder'е будут ваять и дальше, теми или же иными средствами, пусть и не RAD'ами.
А вот мало мальски серьезные программные продукты обречены на прозябание без участия толкового GUI'шника и UX/UI-дизайнера. Есть такие профессии как стоматологи, проктологи и даже ассенизаторы — труд которых востребован и важен, но понравится мало кому из офисного планктона. И пока что нет вариантов переложить эти виды деятельности с людей на технику.
Здравствуйте, Homunculus, Вы писали:
H>Здравствуйте, sergey2b, Вы писали:
S>>я спрашиваю потому что мне надо сделать GUI, для win приложения S>>MFC я знаю, но думаю может на чем то другом сделать
H>Конечно Qt, о чем думать. Если нет таких шибанутых условий как у меня. Об MFC вспоминаю с содроганием. H>Qt секси.
У Qt очень хорошая и удобная архитектура с точки зрения программиста. Но отвратительный User Experience для пользователей, как по мне, из-за того что сделано все по-своему. Чем-то сродни UI на Java. То есть, на мобилках, например, без долгой и нудной допилки интерфейса, все выглядит крайне неестественно и выбешивает этой искусственностью. Для десктопа, особенно Windows, он неплох, хоть и тяжел, и, опять же, приложение выглядит не до конца нативно, это выражается в мелочах.
