GTK3

[qivi]

Прочитал запоздало о GTK 3:
http://www.opennet.ru/opennews/art.shtml?num=29565

Вроде как прилично изменено, со следущего поколения дистрибутивов Линукса вероятно станет основным. Вопрос собственно только один: Через какое время Лазарус будет его поддерживать?

[Mr.Smart]

В LCL GTK2 до сих пор ещё бета, как тут можно делать прогнозы!

[hinst]

а я что-то читал, что наоборот, в лазарусе GTK2 сделали теперь основным набором виджетов под линух, а GTK1 вообще не будет больше поддерживаться лазарусом

[qivi]

Вопрос поддержки GTK3 в Lazarus'ом начинает действительно остро беспокоить, сегодня это уже не новость, а реальность, ещё пол года - год и GTK2 будет историей. Хотелось бы спросить участников проекта Lazarus, ведутся ли какие то работы по поддержке GTK3?

[Mr.Smart]

qivi http://wiki.freepascal.org/Gtk%2B3

[qivi]

Честно сказать мне мало о чём поведал перевод этой страницы но надо так понимать, что работы в этом направлении ведутся?

[Mr.Smart]

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

Добавлено спустя 2 минуты 31 секунду:

В LCL GTK2 до сих пор ещё бета

Извиняюсь Уже не бета

[*Rik*]

Поставил Lazarus 4.4, в нем библиотека виджетов GTK3 в стадии готовности alpha. Собрал с ним свой движок Дизель и.. о чудо, почти работает. Дизайнер Дизеля запускается но криво, для GTK3 пока рано, а вот машина приложения запускает, даже большие корпоративные. Маленькие приложения, в большинстве работают корректно. Есть косяки, которые требуют коррекции, но уже появилась надежда, что поддержка GTK3 в Lazarus когда-нибудь уже взлетит.
На скрине приложения с интерфейсом GTK3

[Alexx2000]

Тестировать GTK3 надо c Lazarus 4.99, там его поддержку очень серьезно допилили (где-то до беты).

[Сквозняк]

Базовый функционал GTK3 давно допилили, можно пользоваться, а вот сам лазарус при работе с формами имеет костыльный старт. Вроде есть событие onCreate, но напрямую его использовать можно только после гадания на кофейной гуще. Чтобы не словить баг, нужно пихать флаг в событие onShow и при первом его срабатывании выполнять всё ресурсоёмкое, что надо было впихнуть в onCreate. А если форма невидимая и onShow не сработает, то нужно искать и ему альтернативу. Вот почему нельзя было сделать срабатывание события onCreate после полной загрузки формы?

[WAYFARER]

Базовый функционал GTK3 давно допилили, можно пользоваться, а вот сам лазарус при работе с формами имеет костыльный старт. Вроде есть событие onCreate, но напрямую его использовать можно только после гадания на кофейной гуще. Чтобы не словить баг, нужно пихать флаг в событие onShow и при первом его срабатывании выполнять всё ресурсоёмкое, что надо было впихнуть в onCreate. А если форма невидимая и onShow не сработает, то нужно искать и ему альтернативу. Вот почему нельзя было сделать срабатывание события onCreate после полной загрузки формы?

Это не костыльный старт. Это не только в GTK3. Тут как повезет.
То есть проблема не в том, что OnCreate или GTK3 “неправильное”, а в том, что от него нельзя требовать гарантий готовности UI. Просто об этом нужно помнить и все.
Для GTK3 это критично, для GTK2/Qt/Cocoa тоже, но в чуть меньшей степени.
Для Win32 попроще, но и там можно словить проблем если лезть в handle-зависимые вещи до того как у окна реально создан HWND.
Короче, данные/файлы/сеть/БД/etc - onCreate, все что затрагивает UI - onShow (или отложенный вызов сразу после onCreate если форма может быть невидимой).

Впрочем, я и сам много лет использовал эти события неправильно, потому что начинал с Delphi в Windows и меня так научили)).

[Сквозняк]

Это не костыльный старт. Это не только в GTK3. Тут как повезет.
То есть проблема не в том, что OnCreate или GTK3 “неправильное”, а в том, что от него нельзя требовать гарантий готовности UI. Просто об этом нужно помнить и все.

Просто помнить недостаточно. Если при старте окна нужно поменять его заглавие в шапке, то это может вызвать ошибку, а значит нужно писать код, который будет считать отклики от формы. И так каждый раз, когда выполняется потенциально опасный код, а значит уже в лазарус нужно добавить событие с этим подсчётом, чтобы не писать лишнее. Как бы нужно переносить рутину в движок для оптимизации действительно уникального кода.

[sts]

Короче, данные/файлы/сеть/БД/etc - onCreate, все что затрагивает UI - onShow (или отложенный вызов сразу после onCreate если форма может быть невидимой).

Впрочем, я и сам много лет использовал эти события неправильно, потому что начинал с Delphi в Windows и меня так научили)).

нет естественно, дельфи под винду все правильно учила, в OnShow ни в коем случае нельзя делать то что меняет видимость элементов UI, потому что контракт - в OnShow нельзя делать OnShow, ибо это потенциальная рекурсия.

если есть проблемы в OnCreate это либо проблема в реализации контролов, либо вы забыли вызвать HandleNeeded, спец метод когда нужен хендел, они не стали пихать его куда нибудь типа в GetHandle, по естественным причинам - это неправильно.

Добавлено спустя 6 минут 4 секунды:
на практике, HandleNeeded понадобился один раз, в остальных случая просто делал что то не так, и переписал, с матами, кучу OnShow, написанных другими, на OnCreate и близкие типа RestoreState, исправляя глюки.

Добавлено спустя 9 минут 55 секунд:

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

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