LINUX.ORG.RU

Qt vs GTK+

 , , ,


0

2

Salve, amici:)

Это мое первое сообщение на данном форуме, так что сильно не бейте:)

Вопрос состоит в следующем: требуется написать пакет программ с графическим интерфейсом. Какой тулкит выбрать, учитывая то, что программы должны будут запускаться и в KDE и в оболочках на GTK+?

Довольно хорошо владею Си и C++, для меня по барабану какой язык использовать. Но если я правильно понимаю, выбрав Qt лучше писать на C++, а GTK+ — тогда воспользоваться чистым C?

Ответ на: комментарий от waker

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

.Implicit Sharing
.unicode
.QString::arg
.QString::contains (тут и далее +regexp)
.QString::insert/remove/replace
.QString::toDouble(и остальные типы)
.QString::operator
.QString::number

qt это ведь не только gui (http://qt-project.org/doc/qt-5/topics-core.html) - переписать все это для себя можно, но зачем ???

x905 ★★★★★ ()
Ответ на: комментарий от Eddy_Em

Если мне нужно закрутить 1 шуруп, я беру отвертку; если много — шуруповерт;

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

x905 ★★★★★ ()
Ответ на: комментарий от waker

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

консольки мне не хватит, но вопрос для примера - поступило предложение выкинуть qt/gtk и писать все на opengl - хотелось бы посмотреть на приложения на opengl «типа редактора» по сложности, но не предлагать движки

x905 ★★★★★ ()
Ответ на: комментарий от waker

а я и использую vala для генерации gobject boilerplates

Тогда я вообще не вижу смысла не писать весь код на Vala. Ведь, как и в случае с gobject boilerplates можно поставлять _дополнительно_ исходники со сгенерированным C-шным кодом и пускай пользователь компилирует хоть при отсутствующем valac!?

Не знаю, в общем, года 2-3 назад пытался писать исключительно в C-стиле, понял что решения некоторых задач без ООП не могу реализовать. В C тоже можно делать классы/интерфейсы даже проще, чем в GObject, правда с меньшими возможностями, но это тоже ссзб за исключением ядра.

backbone ★★★★★ ()
Последнее исправление: backbone (всего исправлений: 2)
Ответ на: комментарий от x905

и ты как бы намекаешь, что с чем-то из этого в сишечке есть проблемы, настолько критические что без QString просто не жить?

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

тебя никто не заставляет :)

waker ★★★★★ ()
Ответ на: комментарий от backbone

Тогда я вообще не вижу смысла не писать весь код на Vala.

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

понял что решения некоторых задач без ООП не могу реализовать.

так делай с ООП, в чем проблема-то? (или ты именно без gobject не можешь?)

waker ★★★★★ ()
Последнее исправление: waker (всего исправлений: 1)
Ответ на: комментарий от x905

В Glib большая часть этого есть, если не ошибаюсь.

backbone ★★★★★ ()
Ответ на: комментарий от waker

так делай с ООП, в чем проблема-то?

На C получается много кода, рефакторить долго. C++ не предлагать, озвучил выше, но и другие причины есть.

backbone ★★★★★ ()
Последнее исправление: backbone (всего исправлений: 1)
Ответ на: комментарий от backbone

Ведь, как и в случае с gobject boilerplates можно поставлять _дополнительно_ исходники со сгенерированным C-шным кодом

я вообще-то это и делал. но это решает только проблему сборки в принципе (без зависимости от valac), но не решает проблему со сборкой GTK2+GTK3 из одной кодобазы.

waker ★★★★★ ()
Ответ на: комментарий от backbone

На C получается много кода, рефакторить долго.

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

waker ★★★★★ ()
Ответ на: комментарий от waker

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

На Си в ООП стиле получается много кода независимо от того, как этот код реализуется - через GObject или без него. Или я не прав?

В Glib, кстати, тоже используются классы без GObject, но, используя их, много контроля ложится на плечи программиста, хотя по объёму, да, получается примерно сколько и на C++/Vala.

backbone ★★★★★ ()
Последнее исправление: backbone (всего исправлений: 1)
Ответ на: комментарий от backbone

Или я не прав?

без конкретного примера невозможно определить. смотря что надо делать. в C-программах, типично, ООП применяется только там, где нужно. поэтому если и есть увеличение кода по сравнению с C++ — оно незначительное, если вообще есть. по сравнению с Vala, и другими языками с кучей сахара, — да, может быть существенно больше кода. даже без ООП.

waker ★★★★★ ()
Ответ на: комментарий от waker

Я неточно выразил мысль. Объём в смысле нагрузки на программиста, а не в смысле числа строк или их длины.

Проверка на соответствие типов, на NULL, ручная работа с памятью и контроль за разделяемыми объектами.

Но и объём в смысле числа букв, когда нужно реализовать наследование, вирт. методы, деструкторы.

В средствах языка отсутствуют шаблоны, поэтому, взяв элемент GList программист должен точно знать, к чему приводить void*.

backbone ★★★★★ ()
Ответ на: комментарий от backbone

Проверка на соответствие типов, на NULL, ручная работа с памятью и контроль за разделяемыми объектами.

все это не имеет никакого отношения к ООП.

Но и объём в смысле числа букв, когда нужно реализовать наследование, вирт. методы, деструкторы.

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

В средствах языка отсутствуют шаблоны

и это несказанно радует.

поэтому, взяв элемент GList программист должен точно знать, к чему приводить void*.

а можно просто не брать GList, и пользоваться сразу правильными типами, без void *.

waker ★★★★★ ()
Ответ на: комментарий от waker

и ты как бы намекаешь, что с чем-то из этого в сишечке есть проблемы, настолько критические что без QString просто не жить?

надо быть внимательным при передаче char* в и из функции, ктото должен очистить память; чегото нет вообще (нужно дописать)

да, всё можно написать, но смысла я в этом не вижу, если это _уже_ реализовано в qstring - бери и пользуйся

для меня это настолько критично, что использовать char* для строк я категорически откажусь (и от чистого C тоже)

x905 ★★★★★ ()
Ответ на: комментарий от x905

я возьму шуроповерт и для 1 шурупа

И потратишь больше времени.

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от x905

надо быть внимательным при передаче char* в и из функции, ктото должен очистить память; чегото нет вообще (нужно дописать)

ну это у вас в C++ принято для всего память на хипе выделать, совать в обертки типа QString, и думать как бы память не потекла. а мы просто выделяем на стеке, преимущественно, и не паримся. и да, такое бывает, что чего-то нет. но найти готовый код, или написать свой - проблемы не составляет. уверен, что и на C++ тебе тоже код писать иногда приходится, а не только готовые модули из Qt подключать.

да, всё можно написать, но смысла я в этом не вижу, если это _уже_ реализовано в qstring - бери и пользуйся

так оно и в glib реализовано - бери и пользуйся. а не нравится - есть другие либы. причем, в отличие от C++, все эти либы еще и совместимы друг с другом, ибо char *. да еще и без оверхеда на копирование.

для меня это настолько критично, что использовать char* для строк я категорически откажусь (и от чистого C тоже)

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

waker ★★★★★ ()
Ответ на: комментарий от x905

надо быть внимательным при передаче char* в и из функции, ктото должен очистить память; чегото нет вообще (нужно дописать)

При передаче в/из библиотеки или плагина строки QString ведь надо преобразовывать в char* и без C не обойтись. К слову, в Vala такой контроль выпоняется автоматически и к мысли, что идеальных языков не придумали.

backbone ★★★★★ ()
Ответ на: комментарий от backbone

да, нужно конвертить, для этого использую QString

x905 ★★★★★ ()
Ответ на: комментарий от Eddy_Em

Мне это убожество не нужно. Есть char* — и его за глаза хватает!

Разупорись. char * - это не строка. То, что этот тип используют как строку - историческое недоразумение. Строки без UTF-8 в 21 веке не нужны.

border-radius ()
Ответ на: комментарий от waker

Мне просто нужно было определиться. И какашки,летающие в сторону GTK, мне помогли:)

Borsalino ()
Ответ на: комментарий от border-radius

Разупорись. char * - это не строка. То, что этот тип используют как строку - историческое недоразумение. Строки без UTF-8 в 21 веке не нужны.

ты как бы намекаешь, что char * не может указывать на UTF8 строку, да?

waker ★★★★★ ()
Ответ на: комментарий от Borsalino

Юникодофобия - это хуже нацпола, это хуже всех смертных грехов. Хуже этого только упоротые юзерстайлы в фоксе, которые превращают этот самый фокс в links -g, а вышеупомянутый персонаж этим тоже страдает.

border-radius ()
Ответ на: комментарий от waker

И это костыли, когда в 21 веке есть уйма ЯП с нативной поддержкой строк в UTF-8. Да, в Qt эти костыли наиболее безболезненны (QString + trUtf8), но они есть.

border-radius ()
Ответ на: комментарий от border-radius

QString хотя бы в остальные костыли гармонично вписывается.

меня эти высокие костыльные гармонии слабо интересуют.

waker ★★★★★ ()
Ответ на: комментарий от Borsalino

проблема уже решена

только тебе так кажется. всем остальным нет. что это значит?

anonymous ()
Ответ на: комментарий от border-radius

Ты смотри, осторожней: вчера С++ вместо С стал использовать, сегодня ты культи культивируешь, а завтра за мужика замуж выйдешь?

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

98% времени я ни на сях, ни на плюсях не пишу, лохматый ты наркоман. Но есть пара проектов на Qt, да и в тех весь интерфейс, не считая трей-менюхи - QWebView.

border-radius ()
Ответ на: комментарий от border-radius

В вебе вообще наркоманы сплошные. Как на поделия посмотришь, сразу видно, что явно у человека что-то с башней не так!

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

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

border-radius ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.