Tkd — кроссплатформенный GUI тулкит для D

Напиши сам (c) Люди проприетарщину реверс-инжинируют как орешки, а он боится потестить, что и когда функция возвращает...

Ответ из категории: «сами ебитесь».

Это же хорошо: не нужен какой-то компонент - не тащи.

Разницу между разнородностью и модульностью ты не видишь? Qt кстати можно собрать с минимальным количеством компонентов, ага.

Когда Qt начнут поддерживать KDEшники, его можно будет уверенно закопать сразу, ибо они сделают из него ещё более жирное прибитое к kdelibs говно.

Ага, учесть что они хотят видеть и Qt и kdelibs более раздробленным на модули, с минимальными взаимными зависимостями (собственно они это уже делают с Qt и KDF, что не скажешь о мёртвом тулките).
Вообще какбэ кути можно собрать с одним только QtNetwork, к примеру.

Круто!

Да. Только сопровождать некому. Сейчас выяснил, что gtk-cffi-ext:with-progress-bar не работает, так как cl-cairo2 изменилось. В консоли куча сообщений deprecated от cffi, так как он тоже успел обновиться. А переделывать всё времени нет.

Какой-то новый биндинг через GIR?

Новый через GIR есть: https://github.com/andy128k/cl-gobject-introspection

ИСЧХ все три автора из exUSSR :)

У меня лежит :(. Может комп недостаточно мощный. Питон, 40к просто забить по порядку - уже проблемы, 400к - даже не дождался когда завершится.

ИСЧХ все три автора из exUSSR

https://github.com/hying-caritas вроде китаец. Или откуда ты инфу берёшь?

40к просто забить по порядку - уже проблемы, 400к - даже не дождался когда завершится.

Ты может просто не дождался пока ListStore заполнится? Там да, не самый быстрый интерфейс. Я просто свою модель на массиве сделал и переопределил GtkTreeModel::GetValue

А когда модель заполнена, то работает довольно шустро.

К слову, GtkListStore не быстрый — для биндингов. Там куча промежуточной фигни создаётся (GValue, GtkIter) на каждый вызов. Получается около 1000-5000 строк в секунду можно добавлять.

Если использовать C или php, то в 10-100 раз быстрее.

Я пробовал ещё Vala - компилится в нативный Си (правда он может тоже тупить и GtkIter создавать через malloc), но тем не менее, промежуточный код не является ботлнеком. Профилировщик показывает ступор где-то на gtk_tree_store_set и gtk_tree_store_insert_before.

Хотя меня не удивляет: https://git.gnome.org/browse/gtk /tree/gtk/gtktreeview.c Copyright (C) 2000 Red Hat, Inc., 16 тыщ строк кода:) Кто его когда вообще рефакторил с 2000-го?

Профилировщик показывает ступор где-то на gtk_tree_store_set и gtk_tree_store_insert_before

Во-первых, зачем tree_store для списка. Используй list_store.

Во-вторых, на _set может тупить, если вдруг у модели включена сортировка. Тогда получишь пересортировку после каждого сета (при изменении значения в сортированной колонке).

gtk_tree_store_insert_before — лучше gtk_tree_store_insert(store, iter, NULL, 0) — тогда не будет поиска узла в дереве.

https://git.gnome.org/browse/gtk /tree/gtk/gtktreeview.c

С этим файлом как раз всё очень неплохо. Тормоза в https://git.gnome.org/browse/gtk /tree/gtk/gtktreestore.c

list_store значительно быстрее:) Около трёх секунд ушло на создание. Да, это что-то я напутал с деревьями.

kdelibs 5 отличается от четвертых тем, что разбито на множество модулей

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

И уж в руках KDE ему будет явно лучше, чем в руках Дигии, которой сообщество, в целом, параллельно. У них бизнес.

Дигия продаёт тулкит множеству компаний, занимающихся в том числе эмбеддедом. Разжирять тулкит (и вместе с тем адаптировать его под неынтырпрайзные языки) им недосуг, в отличие от KDEшников.

Не так сильно и вырос

24% - не сильно?

Так что расти ещё есть куда.

Оперативно вырастет, не беспокойся.

Разницу между разнородностью и модульностью ты не видишь?

А какую роль играет однородность/неоднородность, если у этих компонентов разные задачи? Ты хочешь, чтоб у всех библиотек были похожие API?

Qt кстати можно собрать с минимальным количеством компонентов, ага.

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

Ага, учесть что они хотят видеть и Qt и kdelibs более раздробленным на модули

«Хотят», потому что сообщество надавило.

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

Дистрибопроблемы, надо будет пинать мантейнеров.

Дигия продаёт тулкит множеству компаний, занимающихся в том числе эмбеддедом. Разжирять тулкит (и вместе с тем адаптировать его под неынтырпрайзные языки) им недосуг, в отличие от KDEшников.

Дигия, окромя прочего, сейчас пишет коммерческие модули для Qt. KDE собираются разбить на модули kdelibs, и нет никаких оснований полагать, что при этом они объединили бы модули Qt. Скорее, добавили бы отдельные модули, которые себе тащить никто и сейчас не заставляет.

tkabber, например.

Ждём MotifD.

Дистрибопроблемы, надо будет пинать мантейнеров.

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

$ dpkg -l *libqt5*
ii  libqt5clucene5 5.2.1-8      i386         Qt 5 CLucene module
un  libqt5core5    <нет>        <нет>        (описание недоступно)
ii  libqt5core5a:i 5.2.1+dfsg-3 i386         Qt 5 core module
ii  libqt5dbus5:i3 5.2.1+dfsg-3 i386         Qt 5 D-Bus module
ii  libqt5designer 5.2.1-8      i386         Qt 5 designer module
ii  libqt5gui5:i38 5.2.1+dfsg-3 i386         Qt 5 GUI module
ii  libqt5help5:i3 5.2.1-8      i386         Qt 5 help module
ii  libqt5network5 5.2.1+dfsg-3 i386         Qt 5 network module
ii  libqt5printsup 5.2.1+dfsg-3 i386         Qt 5 print support module
ii  libqt5sql5:i38 5.2.1+dfsg-3 i386         Qt 5 SQL module
un  libqt5sql5-iba <нет>        <нет>        (описание недоступно)
un  libqt5sql5-mys <нет>        <нет>        (описание недоступно)
un  libqt5sql5-odb <нет>        <нет>        (описание недоступно)
un  libqt5sql5-psq <нет>        <нет>        (описание недоступно)
ii  libqt5sql5-sql 5.2.1+dfsg-3 i386         Qt 5 SQLite 3 database driver
ii  libqt5test5:i3 5.2.1+dfsg-3 i386         Qt 5 test module
ii  libqt5widgets5 5.2.1+dfsg-3 i386         Qt 5 widgets module
ii  libqt5xml5:i38 5.2.1+dfsg-3 i386         Qt 5 XML module

С зависимостями всё в порядке.

ога, на этом, похоже, всё

потому что с первых же секунд тырфейс отдаёт «юниксвеем».

Побольше бы такого, а то тошно уже. Компьютер - не для кур! Юниксвей - в президенты! :)

которой сообщество, в целом, параллельно. У них бизнес.

Вот в том-то и беда, того-то и бояться... бизнес у них

Ну так соглашения с KDEшениками то они отменить не могут.

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

Оно ж под LGPL. Форкни, и форк будет принадлежать тебе.

tkgate ещё.

Если кому интересно, я скачал сорсы, скомпилял, запустил пример (винда-7) - получилось очень даже нативненько! С таким внешним видом с удовольствием буду этим пользоваться.

пример

В Линуксе, к сожалению, выглядеть будет страшненько. Если бы там была поддержка чартов для рисования графиков, цены бы этому поделию не было. Пока использую gnuplot, поскольку с plot2kill программы периодически не собираются.