LINUX.ORG.RU

[мысли thread] Стоит ли братья за GTK


0

3

У меня уже практически окончательно сложилось мнение, что GTK - это то, что надо для gui. Обычно пишу под clr, но периодически возникают мысли о том, что, не смотря на то, что mono / net сейчас есть на любой машине, маленькие утилиты должны быть самодостаточны. Qt мне никогда особенно не нравилось. Да и jvm не хочется. Вот единственное, сейчас мало кто использует голые gtk как мне кажется, кроме того это совсем не актуально на рынке труда. может быть мне только это кажется?

Доброе утро всем )


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

Да GList-то Бог с ним, основная сложность - алгоритмы на нём, а не он сам :) Там и ногу проще отстрелить

С ассоциативными контейнерами, особенно без Glib, дело обстоит в разы печальнее

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

> В моих глазах C и C++ должны выполнять довольно узкий круг задач

это узкий взгляд на вещи )
Qt модульна - бери нужный модуль и не будет тебе «тяжести»

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

Сейчас такое считается очень плохим стилем. В андроиде, например, работать с интерфейсом можно исключительно из ui потока, вызов большинства методов любого экранного объекта поднимает исключение.

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

> Я предпочту Mono/.NET, Qt мне очень напоминает VCL, к чему я возвращаться не хочу совсем.

В каком месте вы нашли у них что-то общее? VCL Вообще об принципах ООП не слишали, в то время как Qt весьма хорошо разработан.

В двух словах : Я не хочу писать на С++ с использованием тяжёлого фреймворка.

boost + gtkmm + ... + glade = Qt

gtkmm = QtGui

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

Я как-то и не пытался тебя переубедить, я хотел сказать что все преведенные тобою причины стандартные аргументры Т.Р.О.Л.Л.Я., которые не являются достаточно весомым фактом для отказа.

А о вас у меня сложилось мнение, что у вас тупо нет своего личного мнения и вы пользуютесь мнением ТРОЛЛЕЙ вместо того чтобы лично выбрать подходящий для вас инструмент.

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

И? 2010 это каменный век? Да вы, батенька, зажрались. Не все как GTK только функции выбрасывают, объявляя новые версии.

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

В IT год - это достаточно большой срок. А учитывая что разработчиков там 5 человек, я бы не стал брать это на долгосрочный проект.

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

Доо. Qt5 уже вышел что ле? Плюс оно базируется на Smoke. Тебе ещё туда надо смотреть.

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

не являются достаточно весомым фактом для отказа и нет своего личного мнения

получается, что я защищаю чьё-то мнение, важными для кого-то фактами что-ли ?

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

окошки описывают в qt дизайнере. из получившегося ui генерится python или c++ код. руками это делают только извращенцы

Reset ★★★★★ ()

> не смотря на то, что mono / net сейчас есть на любой машине

facepalm

Gunnerua ()
Ответ на: комментарий от fat_angel

> А если динамический интерфейс надо?

а если динамический интерфейс надо - не надо пользоваться статическими описателями интерфейсов, такими как glade или qtdesigner

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

> Я тоже недолюбливаю python, но для гуев возьму его вместо C, время дороже.

Потом пользователи будут недолюбливать тебя за тормозной GUI.

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

Чем мне понравилась идея валы, так это выплёвывание чисто C-шного кода, который можно скомпилировать. Помню, когда под офтопиком не хотелось устанавливать валу, а gtk уже был всё равно, пригодилось. Да и для проверки/поиска хитрой ошибки прекрасно! В отличие от плюсов.

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

А я бы создал базовый интерфейс с помощью дизайнера, а потом динамически подменял бы его части. Через glade (а теперь уже и gtkbuilder) можно получить указатель не только, скажем, на поле ввода, но и на его содержащий контейнер.

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

GTK уникален! Ведь для некоторых (многообещающих) языков (go), это вообще единственный биндинг, если не ошибаюсь.

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

тебя за тормозной GUI

Уж питон здесь вообще не при чем. Не он же виджеты рисует.

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

И чем это отличается от «рисования морды» в glade?

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

>Потом пользователи будут недолюбливать тебя за тормозной GUI.

Как питон сам по себе может затормозить GUI? GTK как была, так и останется сишной библиотекой, пусть даже её юзает питон. Или речь идёт о торможении диспетчеризации сообщений в ивентлупе изза тормозного питона?

yoghurt ★★★★★ ()

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

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

> Вот понадобился мне ассоциативный контейнер на сишке, что делать? Юзать всякие RBTREE из /sys - привязываться к ОС, таскать их с собой лень

Ну, вот те, кому не лень, получают инвестиции на раскрутку в три ляма зелени. ;)

И да, «таскать с собой» - единственный реально работающий способ максимизации показателя переносимости на другие платформы.

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

С позиции разработчика я диву даюсь, что до сих пор (наблюдаю за этим уже без месяца 5 лет) в win32 нельзя в потоке вызвать диалог (http://developer.gnome.org/gdk/2.24/):

«GTK+ is „thread aware“ but not thread safe — it provides a global lock controlled by gdk_threads_enter()/gdk_threads_leave() which protects all use of GTK+. That is, only one thread can use GTK+ at any given time.

Unfortunately the above holds with the X11 backend only. With the Win32 backend, GDK calls should not be attempted from multiple threads at all.»

Проверял пару лет назад. Подвисает. Решение в обход: если после какой-то работы в потоке нужно вывести сообщение для пользователя, необходимо создать спец. функцию с этим диалогом, а потом зарегистрировать её вызов как idle-функцию. Ну и надеяться, что сразу после завершения работы в потоке приложению наступит этот idle, иначе будет непонятка. Ну а если таких диалогов много, то эффективной разработке такое не поспособствует.

Из ещё замеченных мною «кроссплатформенностей» была работа с последовательным портом/сетью. Было оно как-то через ..._unix_... / ..._win_... Ну да ладно, это ж glib, не gtk. Хотя они и дружат крепко.

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