LINUX.ORG.RU

Планы по выпуску GTK+ версии 3

 


1

0

В списке рассылки gtk-devel-list обсуждаются планы выпуска GTK+ версии 3. Основные подготовительные действия, которые необходимо предпринять в текущей ветке:

  • Спрятать все открытые поля структур с помощью макроса GSEAL(). В случае необходимости предоставить новые методы доступа к этим полям. Также должны быть скрыты поля-указатели "priv" на структуры, содержащие закрытые данные. Эти действия уже практически полностью проведены в репозитории git://git.imendio.com/projects/gtk+.git
  • Реализовать закрытые члены класса, что включает изменения в коде GType.
  • Объявить как deprecated публичные данные класса с помощью макроса GSEAL().
  • Поскольку не останется простого способа для доступа к полям класса, а использование g_object_[sg]et() утомительно, необходимо ввести новые методы доступа, вроде g_object_get_int(), *double(), *string() и т.д.
  • Существует множество макросов, таких как GTK_WIDGET_GET_FLAGS(), которые всегда были причиной многочисленных проблем (см. bug #69872). Необходимо реализовать нормальные методы доступа (в виде функций) и избавиться от этих макросов.
  • GtkStyle, без сомнений, самый сложный тип, нуждающийся в скрытии публичных полей, и до релиза должно быть проведено множество исследований.
  • Избавиться от всего кода, объявленного deprecated в 2.x. Это подразумевает все соответствующие виджеты и функции.
  • Удалить все поля структур из публичного API. Есть два способа достичь этого:
    a) переместить все структуры в закрытые заголовки;
    b) переместить структуры в C-файл реализации, но тогда всей библиотеке придётся использовать соответствующие методы доступа.
    Эти варианты ещё обсуждаются.
  • Отключить deprecated-код по умолчанию во флагах компиляции.
Таким образом, версия 3.0 будет готова к релизу. Все приложения, которые собираются для ветки 2.x с макросом GSEAL() и не используют deprecated-кода, будут без проблем собираться для ветки 3.x. Наверное, таким образом разработчики пытаются избежать кошмара миграции, который можно видеть на примере библиотеки Qt.

>>> Подробности

★★★★

Проверено: JB ()
Ответ на: комментарий от Absurd

> При этом они кстати постоянно должны модифицироваться. Конфиги в основном читаются.

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

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

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

А что программе делать, если это демон на далёком сервере? Плохая программа, без окон?..

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

ну если это настолько плохая программа :) тогда можно и однажды прочитать, но к таким похим программам обычно пишут хорошие - фронтэнды для правки конфигов, а вот они должны уже уметь писать, причем если эта хорошая программа настолько хороша, что написана под МакОС, то она обязана после каждого чиха переписывать конфиг, т.к. кнопок Apply/OK нет :)

а если серьезно, то мы сами пишем сервер БД( я больше занимаюсь гуи к нему ), и конфиг конечно читается один раз, но это не значит, что значения прочитанные из него железно константы, клиентская прога через API/SQL может сменить их, и после изменения "ключа" необходимо выполнить действия аналогичные - сохранить его, "рассказать" об этом необходимым обьектам, разве что в файл не записать, таким образом тут имеем дело с конфигом в памяти, только и всего, зачем дублировать код по его загрузке/сохранению на две копии?

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

>> При этом они кстати постоянно должны модифицироваться. Конфиги в основном читаются.

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

Возможно так, но в случае с std::map должны постоянно меняться ключи а не значения, чтобы поиметь бонус в перформансе. В конфигах ключи обычно более чем полностью статичны.

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