Спустя более двух лет с момента выхода ветки 3.0 представлен (https://www.wxwidgets.org/news/2016/02/wxwidgets-3.1.0-released/) выпуск кроссплатформенного тулкита wxWidgets 3.1.0 (http://wxwidgets.org/), позволяющего создавать графические интерфейсы для Linux, Windows, OS X, UNIX и мобильных платформ. wxWidgets 3.1.0 позиционируется как ветка для разработчиков, в которой развиваются новые возможности для следующего стабильного релиза 3.2.0. По сравнению с веткой 3.0 наблюдается ряд несовместимостей на уровне API и не гарантируется неизменность ABI между промежуточными выпусками 3.1.x.Тулкит написан на языке С++ и распространяется под свободной лицензией wxWindows Library Licence (http://www.wxwidgets.org/about/licence3.txt), одобренной Фондом СПО и организацией OSI. Лицензия основана на LGPL и отличается позволением использования собственных условий для распространения производных работ в бинарной форме. Кроме разработки программ на Си/Си++ wxWidgets предоставляет биндинги для большинства популярных языков программирования, в том числе для PHP (http://wxphp.org/), Python (http://wxpython.org/), Perl (http://wxperl.sourceforge.net/) и Ruby (http://wxruby.rubyforge.org/). В отличие от других тулкитов, wxWidgets обеспечивает для приложения по-настоящему родной для целевой системы внешний вид и методы взаимодействия, благодаря использованию системных API, а не имитации GUI.
Основные новшества wxWidgets 3.1.0:
- Новый экспериментальный порт wxQt;
- Переработана поддержка OpenGL, которая адаптирована для задействования возможностей новых версий OpenGL 3.2+;
- Улучшена поддержка стандарта C++11;
- Поддержка новых компиляторов MSVS 2015, g++ 5.3 и clang 3.8;
- Многочисленные исправления в портах wxGTK3 и wxOSX/Cocoa;
- Улучшена работа на экранах с высоким DPI;
- Новые классы wxActivityIndicator, wxNativeWindow, wxAddRemoveCtrl,
wxAppProgressIndicator и wxPowerResourceBlocker;
- Расширение возможностей классов wxBusyInfo и wxNotificationMessage;
- Новые методы wxTextEntry::ForceUpper(), wxProcess::Activate(), wxDateTime::GetWeekBasedYear(), wxListBox::GetTopItem(), wxStandardPaths::GetUserDir(), wxUIActionSimulator::Select().
- Представлен новый тип событий wxEVT_MAGNIFY;- Обновлены версии поставляемых в комплекте сторонних библиотек, таких как libpng;
- Добавлена поддержка GStreamer 1.0.
URL: https://groups.google.com/forum/#!topic/wx-announce/g3hGOnyu7R4
Новость: http://www.opennet.me/opennews/art.shtml?num=43969
теперь интерфейс 1С летать будет?
Они что, написали его на wxWidgets? Придурки
Да нет, у них свое.
>Добавлена поддержка GStreamer 1.0.Неужели?
Осталось подождать ещё года 2, когда 3.2 выпустят, и года 2, когда Audacity на него портируют, и наконец-то можно выкинуть GStreamer 0.1 из системы. Но это будет не скоро. :-(
>Не уже ли?Да в но хотели.
У меня для вас две новости:
хорошая - можете выкинуть GStreamer из системы прямо сейчас
плохая - его можно было выкинуть и раньше, так как Audacity его не использует :)
> У меня для вас две новости:
> хорошая - можете выкинуть GStreamer из системы прямо сейчас
> плохая - его можно было выкинуть и раньше, так как Audacity его
> не использует :)Спасибо, Вы меня и в самом деле обрадовали. :-)
Глянул zypper-ом, а его у меня уже и нет. Audacity, по крайней мере в openSUSE, недавно перестал требовать пакет libwx_gtk2u_media-suse1, который требовал libgstreamer-0.10.so.0()(64bit) и после очередного обновления я и не заметил, как его и не стало. :-)
Вероятно, там наконец-то пересобрали wxGTK с GTK3
А для Rust есть биндинг?
Как только станет языком - будет и для него биндинг, IMHO...
твое мнение очень для нас, у3бище
Уважаемые, а о каких мобильных платформах речь и что на них вообще доступно?
а зачем это нужно? С таким стилем кода ненужно
Это хорошо подходит, например, для превращения написанного с MFC или VCL в нечто кроссплатформенное. Архитектура очень похожая, не так уж много придется переписывать.
Если, конечно, сейчас такой код еще не весь вымер.
>написанного с MFC или VCL
>Если, конечно, сейчас такой код еще не весь вымер.разве LibreOffice использует не VCL?
"Visual Components Library, an internal part of OpenOffice.org and LibreOffice, not to be confused with the Visual Component Library"
>Если, конечно, сейчас такой код еще не весь вымер.Лучше бы вымер.
Прекрасная новость, омраченная только двумя пунктами:
1. Это нестабильный релиз.
2. Последний минорный релиз стабильной ветки вышел полгода назад.
В таком виде новость уже как-то не очень радует...
А есть чего для Сей без плюсов?
Вроде бы нет. если не считать Gtk, который пытается делать ООП на С - результат понятен.
Удобство и отсутствие недостатков плюсов.
> Удобство и отсутствие недостатков плюсов.То-то они от такой хорошей жизни Vala и Genie под это дело запилили ...
> ValaКак будто что-то плохое
Недостатки плюсов перед С, в части прикладухи?А перед машинными кодами в HEX редакторе - у него есть недостатки, с точки зрения написания бизнес-логики и теплых ламповых иконок?
В части прикладухи, выбор между С++ и С - это выбор между злом и ещё большим злом.
Ну как сказать, окна на С++ стартуют и рисуются все-таки быстро, игры получаются быстрее, FPS стабильней чем на C# том же, а это огромный рынок. Будет жить.Но С для GUI... Вот это реальный изврат.
Удобство и отсутствие недостатков плюсов.
> А есть чего для Сей без плюсов?Tk
X Athena Widgets
> А есть чего для Сей без плюсов?IUP
Motif
кстати, Motif очень даже нечего)
ну нечего, так нечего
API wxWidgets как бы говорит нам "Ломай меня полностью!")
>> экспериментальный порт wxQt;Особый изврат :)
Сразу возникает вопрос, зачем вообще нужен wxWidgets, когда сразу все можно написать с использованием Qt.
Чтоб перейти на Qt поплеваться с вида UI, блевануть вспомнив что есть moc, и перейти обратно к нативным отрисовщикамОставив впрочем этот вариант отрисовщика на всякий случай для маргинальных платформ
Ребят, я тут изучаю в свободное время PyQt 5. Скажите, стоит ли начать изучать wxPython, и легче ли он чем PyQt?
После Qt это будет мазохизм.
> После Qt это будет мазохизм.Qt и есть мазохизм
60 мегабайтная библиотека для HelloWorld
О супергенераторе Moc влобще лучше промолчать
WX попроще будет. Qt - это "systemd мира ГУЁв" - бестолковый монстр, берущий на себя куда больше, чем должен.
Объясните несведущему, зачем юзать это пoделие, нежизнеспособное без кучи gtk-шных либ? Почему не взять нативный gtk, или он совсем так плох?
За тем что:
- wx будет на всех платформах выглядеть как родное приложение, ибо это прослойка
- один и тотже код собирается на разных платформах и ведет себя одинаково (ну или почти)
- достаточно быстрая работа.
Как там поживает gtk на Win64?
Отличный тулкит, который использует __НАТИВНЫЕ__ контролы под каждую из систем:GTK+ под GNU/Linux
Win32 API под MS Windows
Cocoa под OS XИ не выглядит вырвиглазно, в отличие, от, например, Qt, который всё рисует своими силами и мимикрия не полная.
если не ошибаюсь, wxwidgets тоже начинает мостраизироваться...
жаль нет ничего связанного с бустом, чтобы только gui там и было, а все остальное из буста. у меня как-то была идея такого стартапа, но чего-то не пошло.
> если не ошибаюсь, wxwidgets тоже начинает мостраизироваться...Странно слышать такое от любителя буста ...
ИМХО wxWidgets сама легковесность и минимализм в сравнении с бустом.
>> если не ошибаюсь, wxwidgets тоже начинает мостраизироваться...
> Странно слышать такое от любителя буста ...
> ИМХО wxWidgets сама легковесность и минимализм в сравнении с бустом.ну, буст - это как бы почти стандарт.. некоторые части уже в std.. просто такое дело - я все равно буду компилить буст потому что обязательно что-нибудь от туда понадобится, и получится, что у меня одна и та же функциональность реализована в нескольких библиотеках. потоки например (std, boost, wxwidgets). все то, что реализованно в wxw уже реализованно в бусте (кроме конечно самого гуи).
к тому же буст организован как-то по-лучше.. логичнее что ли.. у него есть "подбиблиотеки", но они как отдельные библиотеки, а там все вместе, без пространства имен.
Если приглядеться к классам wxWidgets, внезапно окажется, что с Бустом они пересекаются только в тех вещах, которые практически каждый фреймворк делает "под себя" - строки, контейнеры, ввод-вывод... Более того, часть из них настройками компиляции можно просто превратить в обертки над STD-классами. Если бы в wx была только эта база, ее никто бы и не использовал.
При этом библиотека совершенно не требует использования именно своих классов. Мне, скажем, не нравится wxXmlDocument - я на него забил и использую pugi::xml. Ничуть по этому поводу не страдая.
> Если приглядеться к классам wxWidgets, внезапно окажется, что с Бустом они пересекаются
> только в тех вещах, которые практически каждый фреймворк делает "под себя"
> - строки, контейнеры, ввод-вывод... Более того, часть из них настройками компиляции
> можно просто превратить в обертки над STD-классами. Если бы в wx
> была только эта база, ее никто бы и не использовал.
> При этом библиотека совершенно не требует использования именно своих классов. Мне, скажем,
> не нравится wxXmlDocument - я на него забил и использую pugi::xml.
> Ничуть по этому поводу не страдая.обертками над std? не знал.. там доки есть?
я так сказал потому что обычно я пишу гуй отдельно, так, чтобы можно было сделать веб морду например, использовать qt или wxwidgets или вывести на консоль - не важно. для этого весь функционал вывожу в специальные классы (ну, аля контролеры), а потом просто вешаю обработчики (так можно новую морду очень бысто сделать).
весь ввод-вывод использую из std, перевод - boost::locale (до этого тоже его, только от автора). совершенно не понимаю, зачем писать строки, свой перевод и так далее.. есть же уже.. из-за этого приходится переделывать строки в wxString. то есть основное время на адаптирования моего "контролера" для wx - это переделывание данных из стандартных форматов в wx. это раздражает.но из того, что есть wxWidgets - лучший в этом плане.
А зачем "переделывать" строки в wxString? У wxString есть конструктор из std::string и std::wstring, вполне можно передавать стандартные строки в функции, ожидающие wxString.
> __НАТИВНЫЕ__ контролы под каждую из системЭто и достоинство, и недостаток.
Например, есть у меня программка, использующая wxListBox. На винде она работает долгие годы, все вылизано. Собираю под Linux - и обнаруживаю, что у аналогичного элемента GTK заметно отличается функционал (да, в документации это отражено).
Например, под виндой в том списке можно одним щелчком снять выделение со строчки в wxListBox, а GTK-порт делает это только и исключительно с зажатым Ctrl. Лезу в код, чтобы привести все к единому знаменателю... а нету такого кода! Весь класс wxListBox и его родители - это просто обертки над вызовами к GTK или MSW. И все, приплыли...
> привести все к единому знаменателюЧтобы поведение твоей программы отличалось от других? Зачем ты издеваешься над пользователем и ломаешь его целостную систему?
Контролы, которые юзер использует постоянно, в первую очередь должны быть удобны ему.
Во вторую - следовать стандартам системы.
В приведенном примере выделение элементов списка и снятие этого выделения - одно из самых частых действий, которые пользователь программы совершает в течение рабочего дня. Вы предлагаете ему ради целостности системы весь день зажимать Ctrl?Не надо путать небо с отраженными в луже звездами. Целостность гуя очень полезна для удобства работы, но если средства мешают цели - от них необходимо отказываться.
> Не надо путать небо с отраженными в луже звездами.Анджей Сапковский? :-)
>Контролы, которые юзер использует постоянно, в первую очередь должны быть удобны ему.И вот тут интересный момент: юзеров много и каждому в мысли не заглянешь (и одному-то проблема), а стандарт один (в идеале).
> И вот тут интересный момент: юзеров много и каждому в мысли не заглянешь (и одному-то проблема), а стандарт один (в идеале).В том идеале, который возможен в реале, программист сам некоторое время выполняет эту работу и отталкивается от рабочего процесса, а не от отвлеченных стандартов.
Потом как-то естественно получаются инструменты, позволяющие одному специалисту проворачивать объем работы, над которым мог бы сидеть целый отдел ценителей стандартов.Для полной прозрачности уточню: это не теоретический размышлизм, а конкретный опыт по тому примеру, о котором, собственно, речь.
Есть же какие-то общие идеи, применимые к большинству! Юзабилити бы не существовало, если бы все были извращенцами "think different!" :)
Я всё же выступаю ЗА нативные контролы, но чтобы библиотека могла без проблем "улучшить" любой из них. На примере винды видно, что их тухлый набор гуёв (из Win32) покрывает едва ли 50% потребностей юзеров - потому и так популярны всякие девэкспрессы, что сильно расширяют "стандартное фуфло". :)
Интересно как wxQt под android заведется...