LINUX.ORG.RU

Gtk/GtkTreeView: неужели все так паршиво?


0

0

Начал только разбираться с Gtk+. И вот стоит у меня задача написать кастомную модель для GtkTreeView.
И вот что оказывается: не так уж это и просто сделать; для начала нужно перелопатить тонны манов, что бы понять как работают GObject,
GType, как создаются новые классы и т.п.
И только после этого пишется стопка однообразного кода. Непродуктивно.

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

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


А нужно мне следующее: сделать два параллельных ListView для каждой 
из структур соответственно. В каждой из View должны отображаться только 
определенные поля, остальные -- скрытые и меняются только при 
наступлении определенных событий.

+----------+
| struct A |
+----------+
| field A  |         +----------+
|          |         | struct B |
| GSList *-----------|          |
+----------+         +----------+

Т.е. когда селектится элемент из A, соседний View обновляется контентом из B.

Спасибо.
anonymous

Я думаю, нет для этого генераторов. Могу только посочувствовать. Для меня знакомство с GtkTreeView стало моментом, когда прошла первая эйфория от того, как в Gtk+/GObject можно замечательно обходиться чистым C, и появились подозрения, что что-то не так. Я тогда ещё столкнулся с багом в TreeView - зарепортил, к следующему релизу пофиксили. Просто неудобно на Gtk+ писать. Недружественная она к программисту ;) Непродуктивное средство, правильно подмечено.

anonymous
()

Мой первый шаг при создании нового класс - копировать/вставить.

Хотя, в данном случае я не вижу причин для создания чего-то нового, почему бы не попытаться использоватm уже существующие GtkTreeModelFilter & GtkListStore.

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

> Мой первый шаг при создании нового класс - копировать/вставить.

Копипаст вреден. Особенно если понятия не имеешь как это работает -- поэтому предварительно надо обязательно перелопачивать все эти фундаментальные идеи тулкита. Что в свою очередь может привести к значительной потере времени.

Кстати, да. Создание собственной модели для GtkTreeView, увы, отличнейший способ разрушить иллюзии об удобстве Gtk+.

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

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

alexru ★★★★
()

Такое впечатление, что ты пишешь на Си. Это жесткое требование? На Питоне для Gtk писать довольно просто.

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

> Такое впечатление, что ты пишешь на Си.

Именно так.

> Это жесткое требование? На Питоне для Gtk писать довольно просто

Python'ом я владею, но я специально придумал себе множество причин что бы именно эту задачу на нем не решать :).

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

> Посмотри на vala.

Уже смотрел. Пока не понравилось -- на игры с еще одним языком уйдет время. Хотя если совсем приспичит -- придется более основательно на него смотреть.

anonymous
()

не понял в чем проблема,
это все нормально делается в Gtk+.
Похоже автор хотел просто и быстро,
а тут надо читать маны, и он немного разочарован.

anonymous
()

>Т.е. когда селектится элемент из A, соседний View обновляется контентом из B.

Делается это через фильтры. На самом деле Вы просто не прочувствовали суть. Там весьма удобно и продумано сделано. Есть некоторые неудобства, но они на общем фоне не видны.

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

>на gtkmm тож как бы не сложно

Только GTK для того и создавали, чтобы не пользоваться *mm.

anonymous
()

AnjutaIDE умеет генерировать GObject-классы.

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