В составе моего продукта есть просмотрщик внутреннего формата.
Написан был очень давно, на С++ c использованием древней библиотеки, которая, в свою очередь, завязана на MFC.
Это несет ряд сложностей с поддержкой, исправлением и добавлением новых фич. Есть потребность переписать GUI.
Пока склоняюсь к C# + WPF. Есть какие-нибудь разумные альтернативы? Перенести в браузер — сложновато будет, на Qt завязываться не хочется, кросс-платформенность не нужна.
Здравствуйте, remotecpp, Вы писали:
R>Пока склоняюсь к C# + WPF. Есть какие-нибудь разумные альтернативы? Перенести в браузер — сложновато будет, на Qt завязываться не хочется, кросс-платформенность не нужна.
А что нужно от гуя-то? А может там одна формочка с гридом — и ради этой красоты городить огород?
А то вот сейчас порекомендую свою либу с неблагозвучным названием — там все нативненько и кучеряво
Здравствуйте, remotecpp, Вы писали:
R>Это вьюер, наподобие Acrobat Reader.
А что там такого навороченного, что нужно что-то специальное? Из всего приходит в голову только "навороченный" тулбар
По моему, данный функционал можно сделать на чем угодно, хоть на голом WinAPI. Делай на том, что хорошо знаешь и будет все тип-топ.
Здравствуйте, remotecpp, Вы писали:
R>В составе моего продукта есть просмотрщик внутреннего формата. R>Написан был очень давно, на С++ c использованием древней библиотеки, которая, в свою очередь, завязана на MFC.
R>Это несет ряд сложностей с поддержкой, исправлением и добавлением новых фич. Есть потребность переписать GUI.
R>Пока склоняюсь к C# + WPF. Есть какие-нибудь разумные альтернативы? Перенести в браузер — сложновато будет, на Qt завязываться не хочется, кросс-платформенность не нужна.
Если бы я сейчас сел делать с нуля GUI-приложение, взял бы QT. Красиво, удобно (не смотрел ещё), вроде даже с открытыми исходниками.
Кросс-платформенность вначале всегда не нужна, а потом поздно...
Сейчас пилю шароварку-тулзовину на Qt, завелась под вин/мак/линукс практически сразу. Были ньюансы с:
1. clang (не поддерживает OpenMP), но для мака я его быстро заменил на GCD.
2. размером wchar_t (для visual studio-компилера 2 байта, а для g++ и clang — 4 байта), пришлось писать конвертор UTF8 <-> UTF16 <-> UTF32 (это для ядра программы, где Qt не использовал). Возможно, надо было устанавливать версию Qt для Windows с MinGW.
3. размер штифтов в GUI контролах для win/mac/linux — разный, из-за чего в *nix системах не влазит текст. пришлось подшаманить.
4. некоторые стандартные контролы выглядят по-разному, поэтому иногда несуразная компоновка получается.
5. не такая удобная отладка как в VisualStudio
6. При использовании LGPL-лицензии на Qt — достаточно большой вес дополнительных Qt-библиотек, отчего инсталлятор получился около 35 MB.
плюсы:
1. Достаточно удобный интерфейс QtCreator
2. Встроенная поддержка Git (пользуюсь Bitbucket в качестве сервиса удаленного репозитория)
3. Можно доустановить Qt Installer Framework, сделать инсталлятор. Пока сделал простенький под Windows, для других систем инсталлер не собирал.
Классы Qt старался использовать только для интерфейса, само ядро программы — на C++ и STL (в основном, для контейнеров). Хотел поначалу собрать ядро как либу, но потом просто попользовал классы ядра — так, как мне показалось, легче дебажить и защита ядра лучше.
Здравствуйте, jasoni, Вы писали:
J>Здравствуйте, CEMb, Вы писали:
J>Сейчас пилю шароварку-тулзовину на Qt, завелась под вин/мак/линукс практически сразу. Были ньюансы с:
[...]
J>плюсы: J>1. Достаточно удобный интерфейс QtCreator J>2. Встроенная поддержка Git (пользуюсь Bitbucket в качестве сервиса удаленного репозитория) J>3. Можно доустановить Qt Installer Framework, сделать инсталлятор. Пока сделал простенький под Windows, для других систем инсталлер не собирал.
Спасибо за отзыв.
Но теперь точно Qt не стану пробовать. Плюсов никаких не вижу, зато куча граблей.
Здравствуйте, jasoni, Вы писали:
J>Классы Qt старался использовать только для интерфейса, само ядро программы — на C++ и STL (в основном, для контейнеров). Хотел поначалу собрать ядро как либу, но потом просто попользовал классы ядра — так, как мне показалось, легче дебажить и защита ядра лучше.
А мне вот Qt в свое время не особо понравилось в плане UI для Windows. Тормозило заметно, плюс UI у них полностью свой (Qt не используется стандартные контролы а рисует все сама). То есть пока делаешь что то простенькое в плане UI — Qt отлично работает, как только начинаешь делать что-то завязанное на Windows то сразу огребаешь кучу проблем и костылей. Пока пришел к выводу что для UI лучше всегда использовать нативные фреймворки, заточнные под конкретную платформу.
Я бы смотрел в сторону HTML+JS. Например, обернутая в Chrome Embedded Framework.
Плюсы такие:
* Быстрая отрисовка "из коробки".
* Для большинства видов верстки есть готовые решения в интернете.
* Большое количество разработчиков/фрилансеров. Сможете заутсорсить часть разработки на сторону.
* Поддержка Hi-Dpi "из-коробки".
* Большое количество библиотек и UI компонентов (Bootstrap, Ext JS, PhoneJS, Kendo UI...).
* Съедобные IDE. Например, WebStorm. Рабочий рефакторинг всего 49 за индивидуального разработчика.
* Если есть сложности с прототипным языком программирования, используйте TypeScript.
* Если наткнетесь на проблемы с браузером, можно будет слезть на другой или написать свой уровень абстракции, а JS гонять в V8.
Здравствуйте, remotecpp, Вы писали: R>Пока склоняюсь к C# + WPF. Есть какие-нибудь разумные альтернативы? Перенести в браузер — сложновато будет, на Qt завязываться не хочется, кросс-платформенность не нужна.
Здравствуйте, remotecpp, Вы писали:
R>Пока склоняюсь к C# + WPF. Есть какие-нибудь разумные альтернативы? Перенести в браузер — сложновато будет, на Qt завязываться не хочется, кросс-платформенность не нужна.
небольшая справка по голосованиям, проводившимся на rsdn за последние годы (в голосованиях можно было выбрать больше одного варианта):
далеко идущих выводов из этих цифр делать не стоит (например, в 2013 в опросе упомянуты ещё и delphi, а не только c++ тулкиты), но составить приблизительное представление о популярности тулкитов можно.
R>В составе моего продукта есть просмотрщик внутреннего формата. R>Написан был очень давно, на С++ c использованием древней библиотеки, которая, в свою очередь, завязана на MFC.
R>Это несет ряд сложностей с поддержкой, исправлением и добавлением новых фич. Есть потребность переписать GUI.
R>Пока склоняюсь к C# + WPF. Есть какие-нибудь разумные альтернативы? Перенести в браузер — сложновато будет, на Qt завязываться не хочется, кросс-платформенность не нужна.
Разумных альтернатив Си-Шарпу нет.
Внутренний формат — это видео?
Здравствуйте, const_volatile, Вы писали:
_>далеко идущих выводов из этих цифр делать не стоит (например, в 2013 в опросе упомянуты ещё и delphi, а не только c++ тулкиты), но составить приблизительное представление о популярности тулкитов можно.
...о популярности тулкитов на рсдн. На хабре, ИМХО, такое голосование будет сильно перекошено в сторону html5/node-js.
Здравствуйте, remotecpp, Вы писали:
R>Есть потребность переписать GUI. R>Пока склоняюсь к C# + WPF. Есть какие-нибудь разумные альтернативы? Перенести в браузер — сложновато будет, на Qt завязываться не хочется, кросс-платформенность не нужна.
HTMLayout. HTML, но не браузер. С++. Техподдержка на русском.
Здравствуйте, remotecpp, Вы писали:
R>Пока склоняюсь к C# + WPF. Есть какие-нибудь разумные альтернативы? Перенести в браузер — сложновато будет, на Qt завязываться не хочется, кросс-платформенность не нужна.
Здравствуйте, remotecpp, Вы писали:
R>В составе моего продукта есть просмотрщик внутреннего формата. R>Написан был очень давно, на С++ c использованием древней библиотеки, которая, в свою очередь, завязана на MFC.
R>Это несет ряд сложностей с поддержкой, исправлением и добавлением новых фич. Есть потребность переписать GUI.
R>Пока склоняюсь к C# + WPF. Есть какие-нибудь разумные альтернативы? Перенести в браузер — сложновато будет, на Qt завязываться не хочется, кросс-платформенность не нужна.
Я бы выбрал Delphi XE6. Дорого, но это мой выбор! Плохо но это работает!
Здравствуйте, remotecpp, Вы писали:
CS>>Sciter на самом деле, нынче это наше всё.
R>В чем именно оно все? Кросс-платформенность не рассматриваем. R>Работает быстрее, чем найтивный интерфейс? Скорость разработки вне конкуренции?
Некая корпорация (назовем её Foo Corp) так мне объяснила бенефиты от Sciter которые они с 2006 года используют:
1. Они выпускают новую версию своего продукта раз в год. При этом логика (backend) не сильно у них меняется за последние лет 20 или около того.
Но UI (то что customer's видят) они меняют регулярно — каждый год. Вчера были модны 3D кнопки, сегодня Metro UI.
В какие-то года они обходятся вообще косметическим редактированием CSS. Поэтому Sciter.
2. Их UX guy мне выдал следующую максиму: пользователь принимает решение покупать или нет в течение первых 40 секунд от начала download.
Т.е. скорость запуска и размер matters. Они вообще используют UI composition (загрузку интерфейса по требованию) когда пользователь
жмет кнопку "Детали..." или что-то там. Поэтому Sciter и HTML со скриптами в нем.
3. У них команды делающие UI и backend разделены. backend в своих worker threads выдает JSON или что-то на него похожее. frontend (UI) его потребляет.
Активно используется data-binding (sdk/samples/+plus — AngularJS alike databinding механизм).
Команды работают независимо практически ибо UI на данные не завязан сильно (естественное разделение UI и logic layers). Поэтому Sciter.
4. Direct2D graphics это GPU акселерация. В свете наличия уже на рынке retina grade (high-DPI) мониторов имеем увеличение фактически на порядок
количества пикселей которые CPU должен обработать (GDI, GDI+ и прочая). Только GPU короче. И в свете тех же мониторов получаются очень
нетривиальные конфигурации — здесь. Поэтому Sciter.
Там есть еще с десяток пунктов, но эти главные я думаю.
CS>>Примеры UI
R>Ну как-то сильно на любителя... Сплошные диалоги-раскраски с разноцветными кнопками.
Это да, согласен. Вот более гуманный что-ли, это все тоже HTML/CSS и скрипты по вкусу
Здравствуйте, ov, Вы писали:
CS>>Mac port я делал два месяца. Линукс будет дольше немного ибо приоритет пониже. Но около того.
ov>на последней макоси не запускается, кстати. даже ошибку не показывает.
ov>>на последней макоси не запускается, кстати. даже ошибку не показывает. CS>Эта версия mac os x и эта версия sciter?
макось 10.9.3, а скайтер из сдк с сайта. в sciter.app в info.plist прописана версия 1.0
в console.app при этом вылезает что-то такое:
27/06/14 3:30:55.808 pm com.apple.launchd.peruser.502[259]: (terrainformatica.sciter.110384[26611]) Job failed to exec(3) for weird reason: 13
27/06/14 3:30:55.809 pm Finder[26551]: 8837325: Attempting to SIGCONT to pid #26611 failed, with errno=#3, or the process failed to actually start
27/06/14 3:30:55.817 pm loginwindow[236]: ERROR | -[Application setAppContext:] | Unable to get PID for context [0,2929355]
27/06/14 3:30:55.817 pm Dock[302]: no information back from LS about running process LSASN:{hi=0x0;lo=0x2cb2cb}
27/06/14 3:30:55.819 pm Finder[26551]: 8837325: Attempting to SIGCONT to pid #26611 failed, with errno=#3, or the process failed to actually start
27/06/14 3:30:55.830 pm Finder[26551]: 8837325: Attempting to SIGCONT to pid #26611 failed, with errno=#3, or the process failed to actually start
27/06/14 3:30:55.841 pm Finder[26551]: 8837325: Attempting to SIGCONT to pid #26611 failed, with errno=#3, or the process failed to actually start