Qt vs GTK+

не нужно даже STL знать

Вот это больше всего и бесит в кьютэ, на стандарт C++ они клали с прибором. Я когда в первый раз выбирал тулкит для линуксового C++ приложения, остановился на gtkmm, потому что от примеров кода на Qt у меня глаза чуть не вытекли, а от gtkmm волосы стали мягкими и шелковистыми.

как раз под вендой библиотеки без проблем какие хочешь юзай
а если тащишь нужное с собой — то в репы не принимают

Если хочешь как в винде, то и жить без реп, как в ... Все закономерно.

Tk совсем не выглядит по-нативному. или я какой-то не тот Tk смотрел.

Глядучи на то в ttk есть увязка с MS-овским visual стилями то какой-то не тот.

на стандарт C++ они клали с прибором

Ты норкоман, да?

Да ты прикалываешься что-ли?
Оно вот так выглядит в стандартных диалогах: #1, #2.
Я когда сию программу запустил, подумал что оно на CDE/Motif написано.
Eddy_Em'у должно такое нравится, но лично у меня такой интерфейс вызывает тугую рвотную струю в лицо разработчикам этого поделия. И вообще, почему тёмная тема захардкожена? Далее

Что бы там не говорили, с кроссплатформенностью тоже всё ок.

Почему тогда для винды в качестве официального клиента используют наркоманский uTox, а не Venom?

Короче, весьма неудачное приложение для демонстрации возможностей связки (GTK+/Vala). Давай что-нибудь ещё.

Tk - не нативен. От тикля в оффтопе несёт за версту. Если бы с ним всё было норм, тогда все дизайнеры, не могущие в командную строку/терминал, юзали бы gitk, а не TortoiseGit.

Какой тулкит выбрать
Qt vs GTK+

Первое — говно, второе (если GTK2) — кактус (или тоже говно, если GTK3).

Выбирай, что есть: говно или кактус.

По-моему, ни то, ни другое не стоит...

Тут смотря какого рода программа или пакет программ. Если я не ошибаюсь, по канонам юникс-вея было бы правильно пилить консольный независимый интерфейс и два или более фронт-енда - на qt и gtk соответственно. А если проект настолько крупный, сложный и серьезный, что пилить два фронтенда не целесообразно, то тулкит надо выбирать исходя из специфики задачи, целевой аудитории и прямоты собственных рук.
Не программист.

ппц какой толстый вборс

обертки практически все на C++. да, я писал на MFC, ATL, WTL, и не только. и много. не понравилось.

Имхо, программирование GUI на любом языке выглядит как говно. Qt хорош тем что позволяет с минимальными усилиями строить сложные интерфейсы, в том числе, с кастомными контролами. Что-то сравнимое по мощности разве что в .Net есть (не трогал его лет эдак 7).

Выбирай Qt. Реальных альтернатив у него сейчас попросту нет по таким параметрам как: стабильность API, количество документации, размер сообщества (количество людей на различных ресурсах готовых подсказать). Сюда же можно приплюсовать нормальный внешний вид на всех мало-мальски популярных платформах (ОS + рабочий стол).

Первое — говно

аргументы ?

По-моему, ни то, ни другое не стоит...

что тогда ?

А на мой взгляд вполне годный пример. Работает под оффтопом? Работает. Venom сейчас активной разработке и адаптация под оффтопик - не приоритетная задача. Когда больше делать нечего будет, может выпустят более красивый билд для венды. Факт в том, что это можно сделать.

Ну и да, темная тема захардкожена, он и в линуксе так выглядит.

А uTox выбрали, потому что он и по фичам веном обгоняет и да, под вендой лучше работает.

Кстати, я не в курсе, приложения, разработанные Yorba (Shotwell, Geary, California) имеют сборки под оффтопик или нет. Если да, то вот тебе примеры.

Баг с раскладкой: в Qt5-приложениях не работают сочетания клавиш (Ctrl+C, к примеру), если раскладка в системе отличная от «En»;

есть некие успехи: https://bugreports.qt-project.org/browse/QTCREATORBUG-9589

Ладно, все-таки буду использовать Qt. Однако еще один вопрос: как у него с Python?

Просто прекрасно в отличие от Gtk. У Gtk пока наблюдается небольшой хаос:

есть Gtk2 (начинает устаревать) и Gtk3,

есть PyGtk (устарел) и PyGObject,

также есть Python2.X и Python3

и кроссплатформенность (а именно переносимость на Windows).

Так вот не все эти вещи пересекаются, а хотелось бы. К примеру тебе нужно A + C + E, а получится только A + B + D, причем (B хуже C) и (D хуже E) в итоге чем то жертвуешь.

А вот у PyQt тут все отлично: поддержка Qt4 (мейнстрим), в будующем думаю и Qt5 будет, поддержка Python2.X + Python3, кроссплатформенность (Windows + Linux как минимум)

не нравится из-за C++

Не осилил божественные кресты? Так бы сразу и сказал. А то «нативный внешний вид», бла-бла-бла...

man gtkmm

Но сам не пробовал.

аргументы?

0) C++, 1) overhead, 2) вырвиглазные тулкиты, 3) свистит-пердит-тормозит.

что тогда?

web или OpenGL (чистый, без туалетной бумаги)

Не осилил божественные кресты?

напротив, осилил достаточно, чтобы не хотеть больше с ними иметь дел.

Бери тогда WxWidgets, это по сути большая обёртка, в винде над виндовым API, в Linux над GTK и отдельно есть версия для обёртки над xlib, в маках правда хуже всего с ней дела обстоят, но делать нативность для 1%? Они (да и Linux юзеры) и не нативное оформление поюзают.

Кстати что за WebUI? Много про него слышу но конкретного ответа даже гугл не смог найти

0) C++,

это аргумент за, а не против

1) overhead,

модульность или что ты там лишнего углядел ?

2) вырвиглазные тулкиты,

стили ?

3) свистит-пердит-тормозит.

доказывай примерами

web

десктопные программы через web ?
вот это как раз «свистит-пердит-тормозит», или это браузеров проблема? )

или OpenGL

все виджеты самому рисовать ?
есть успешные примеры десктопных приложений ?

MFC, ATL, WTL,

Я с ними немного писал тоже. Одно слово: Monstrosity. Мне больше понравились WinForms и WPF.

Вроди видел ещё пару интересных win-only тулкитов, сейчас даже не вспомню названий. wxWidgets — тоже неплохая.

Но опять же — они для Qt и в подметки не годятся.

Обычная веб-морда с жабоскриптом. На сервере — CGI, вебсокеты или самописный демон (если кроме этой веб-морды ничего не нужно).

это аргумент за, а не против

Никак нет: с++ нужен лишь в очень редких случаях. А пихать его везде — это как бегать со стеклянным МПХ, пихая его во все дыры!

стили?

нет, не слышал.

доказывай примерами

Запусти окуляр. А потом запусти xpdf. Сравни время запуска и отклик. Обе программы одинаковую задачу выполняют — показывают pdf'ки.

десктопные программы через web?

А почему бы и нет? Очень мало софта, которому нужен гуй. Подавляющее большинство можно запихать в браузер. А что нельзя — есть opengl.

все виджеты самому рисовать?

Виджеты не нужны. Простота — вот что главное!

MFC, ATL, WTL,

Я с ними немного писал тоже. Одно слово: Monstrosity. Мне больше понравились WinForms и WPF.

Похоже совсем не писал. Или слово неправильно использовал.

Ну надо же, WTL и ATL monstrosity.

Для С++ есть ещё AGAR. Работает судя по заявлениям почти на всём, даже на Nintendo и Amiga :)

GTK+ — тогда воспользоваться чистым C

Переписав C-шный проект на Vala, убедился, что это удобнее и проще. По объёму тоже разница заметная:

$ cat *.{c,h} | wc
  16119   49813  504934
$ cat *vala | wc
   3483   11240   94224

Спасибо за предложение, но, во-первых, я не нуждаюсь в советах, и сам способен выбрать инструменты для своих задач (ты наверное перепутал меня с ТС), а во-вторых, я уже написал, чем меня не устраивает wxWidgets.

есть успешные примеры десктопных приложений ?

я не Eddy, но могу привести в пример blender и unity3d (не тот который убунта, а тот который 3д движок).

Переписав C-шный проект на Vala, убедился, что это удобнее и проще.

а тебя не напрягло, что синтаксис языка разный в разных версиях компилятора, и собрать программу на другом компе с valac из репов невозможно? я именно из-за этого от vala отказался. может сейчас что-то поменялось, не проверял.

есть и другие проблемы, конечно. например, трудности сборки под gtk2 + gtk3 из одной кодобазы, но, думаю, для большинства линукс-приложений это не критично.

с++ нужен лишь в очень редких случаях.

функционал QString для char* ты сам будешь писать (и рекомендуешь так делать каждому) ?

Простота — вот что главное!

сложность это сама простота, изложенная подробно

сейчас тебе нет нужды в дополнительном функционале (только показать pdf или вызвать printf вместо qmessagebox), но потом понадобится - придется подключать дополнительные либы, менять тулкит или язык

итого твое заявление «qt гавно» - я воспринимаю как слишком «сложно» для тебя

но могу привести в пример blender и unity3d

основа этих проектов - движок, который все равно самому писать, тут свои виджеты сделать (для единого стиля) труда уже не составит

но пусть надо написать чтото более десктопное, например kate - пример таких на opengl есть ?

функционал QString для char* ты сам будешь писать (и рекомендуешь так делать каждому) ?

Мне это убожество не нужно. Есть char* — и его за глаза хватает! Если слишком часто надо strlen() вызывать, то можно создать структуру: строка + ее длина.

но потом понадобится

Тогда и будем говорить.

я воспринимаю как слишком «сложно» для тебя

Правильно. Зачем излишние сложности? man "бритва Оккама"! Если мне нужно закрутить 1 шуруп, я беру отвертку; если много — шуруповерт; если очень много — подключаю шуруповерт к сети и таскаю удлинитель.

Напрягало, пока не нашёл способ легко и непринуждённо собрать нужную версию Vala и libgee под deb/win32.

Но это всё лишь потому, что язык пока ещё молодой и интерфейс не стабилизировался.

трудности сборки под gtk2 + gtk3

Переписывал библиотеку (не графическую). С графикой лишь экспериментировал на Gtk+-3 совместно с CMake. Вариант поддержки двух версий тулкитов из одной кодобазы не рассматривал, кажется сложным.

но пусть надо написать чтото более десктопное, например kate - пример таких на opengl есть ?

думаю, писать текстовый редактор с гуем на opengl — просто странная идея. у меня лично возникает вопрос «зачем?».

функционал QString для char* ты сам будешь писать (и рекомендуешь так делать каждому) ?

ты сначала придумай, нахрена этот QString нужен где-то кроме Qt.

Напрягало, пока не нашёл способ легко и непринуждённо собрать нужную версию Vala и libgee под deb/win32.

ну это ты себе придумал способ. я-то ведь тоже на своем компе без проблем могу свой софт собирать. а как быть с распространением в исходниках? заставлять юзеров себе вальку компилять нужной версии?

Вариант поддержки двух версий тулкитов из одной кодобазы не рассматривал, кажется сложным.

на сишечке совсем не сложно. на вальке я вроде пытался придумать, как это делать, но так и не придумал.

И выходит под линукс ничего нет из-за разарботчиков софта просто.

Нет, а из-за пользователей, которые думают, что разработчики им должны. Большинство разработок держится на голом энтузиазме.

думаю, писать текстовый редактор с гуем на opengl — просто странная идея. у меня лично возникает вопрос «зачем?».

затем что на opengl было предложение писать софт - просто жеж !

ты сначала придумай, нахрена этот QString нужен где-то кроме Qt.

есть функционал по обработку строк, удобный, безопасный - нахрена его переписывать для char* ?

для текстового редактора хватит и консольки. нафиг там opengl?

есть функционал по обработку строк, удобный, безопасный - нахрена его переписывать для char* ?

примеры того, что надо переписывать, будут?

(надеюсь, про string.h ты в курсе)

А в любом случае ведь собирать придётся под конкретный дистрибутив - двоичные зависимости те же, что и в C-шной версии программы. Я тут не вижу разницы. Разве что пользователь сам хочет скомпилировать новую версию приложения, отсутствующего в репозиториях, на _данный_момент_ в этом случае придётся искать vala_0.24_amd64.deb/компилять самому и т.д.

gtk 2 + 3

Имхо, если поддерживать несколько тулкитов, то неплохо сюда и Qt добавить, хотя наверное это другого порядка сложности...

Ещё бы если было можно легко и непринуждённо C-шный код модифицировать в плане изменения иерархии классов/интерфейсов.. Тут Vala мне показался намного проще, особенно по количеству нажатий клавиш. Может есть какие-то инструменты для GObject, которых не знаю...

А в любом случае ведь собирать придётся под конкретный дистрибутив - двоичные зависимости те же, что и в C-шной версии программы.

я как бы спрашиваю про тот случай, когда юзеру надо собрать под конкретный дистрибутив, а в нем версия valac не совпадает.

Имхо, если поддерживать несколько тулкитов, то неплохо сюда и Qt добавить, хотя наверное это другого порядка сложности...

это не по теме

Ещё бы если было можно легко и непринуждённо C-шный код модифицировать в плане изменения иерархии классов/интерфейсов..

сишный код как раз можно легко и непринужденно модифицировать и развивать по причине отсутствия в нем классов и интерфейсов. или ты для собственного кода, не имеющего отношения к GTK, используешь gobject? это уже крайняя стадия ССЗБ, и чем тут помочь, не знаю.

я как бы спрашиваю про тот случай, когда юзеру надо собрать под конкретный дистрибутив, а в нем версия valac не совпадает.

Проблема дистрибутива. Пока проект не достиг стабильного релиза должна использоваться последняя доступная версия.

это не по теме

Если абстрагироваться от реализации граф. интерфейса, как это сделано в некоторых проектах, проблема поддержки gtk2+gtk3 отпадёт, разве нет?

сишный код как раз можно легко

Это будет спором о парадигмах и фломастерах...

собственного кода, не имеющего отношения к GTK, используешь gobject? это уже крайняя стадия ССЗБ

А совместно с GTK - вынужденная мера, да. Имхо, GObject хорош совместно с генератором кода.

Если абстрагироваться от реализации граф. интерфейса, как это сделано в некоторых проектах, проблема поддержки gtk2+gtk3 отпадёт, разве нет?

проблемы поддержки gtk2/gtk3/qt/android/cocoa/... нету, все абстрагировано, и работает. есть проблема сборки интерфейсов gtk2/gtk3 из одной кодобазы на vala (точнее, такая проблема была несколько лет назад, с тех пор давно перевел все обратно на сишечку). остальное не имеет отношения к теме про vala-проблемы.

Имхо, GObject хорош совместно с генератором кода.

а я и использую vala для генерации gobject boilerplates. как по мне, оно больше ни на что и не годно. но вот для этого полезно. но это бывает нужно раз в год максимум.