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 ()
Ответ на: комментарий от svu

> Но толковый менеджер хотя бы примерно представляет, кому что можно поручить.

Даже Шумахер на "запорожце" гонки не выиграет.

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

> Лучшие манагеры --- это те, которые сами в прошлом были технарями.

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

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

>Да, любителю плюсов манагерство обычно не светит.

Бред. Полный. Чистый. Незамутнённый.

Тебе фанатизм уже на мозг давит, завязывай. Я мог бы тебе привести кучу контрпримеров --- но тебе будет всё равно как об стенку горох.... =\

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

> 2Absurd: так как насчет доказательств отсуствия инкапсуляции, полиморфизма, наследования в Си++?

"Мамой клянусь, нэту их там!"(ц)

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

>Технические человеки, поставленные на правление проектом, почему-то бычно приоритеты неправильно расставляют.

Читай P.S. и много думай :)

В моей нынешней конторе почти все манагеры --- технари в прошлом. Контора успешно пережила IT-кризис 2003-го (или 2002-го, не помню точно), продолжает развиваться, ныне входит в top 100 global service companies. Заказчики --- от Корел, Нортел и много других, чьи имена называть низя по NDA :)

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

> Мысль осталась непонятной. Кто в этом треде был запорожцем?

Технология, выбранная начальством.

Собственно, это сказано вот к чему:

> Тогда умные люди либо выбирают не жабку, либо просто не ставят на этот кусок проекта студентов.

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

>так как насчет доказательств отсуствия инкапсуляции, полиморфизма, наследования в Си++?

Я сейчас ковыряю плюсовый код и во время компиляции пощу на ЛОР. Домой приду - напишу.

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

Ему хочется, чтобы его поуговаривали. Давайте все вместе: про-сим, про-сим, про-сим!

MYMUR ★★★★
()

Прочитал весь топик.

Мне кажется, идея "C - кроссплатформенный ассемблер" - одна из немногих здравых идей, высказанных в этом топике.

По сути, гномовцы так и ставят целью сделать. Есть C с ужас какими макросовыми извращениями, в который компилируется Vala - вполне себе нормальный ОО-язык, прошу заметить, с чистым синтаксисом и поддержкой всяких сигналов и рефлексии на уровне языка, причём без здорового рантайма с фреймворком и байткодом а-ля Java и .NET.

Да, конкретно сейчас в Vala нужна куча костылей, чтобы написать что-то сложнее хеллоуворлда - см. http://www.linux.org.ru/view-message.jsp?msgid=2745907 . В идеале человек будет писать на Vala и вообще не придавать значения тому, что оно компилируется в какой-то там C, точно так же, как сишники не задумываются об ассемблере, который генерируется где-то там внутри GCC.

Из зависимостей - только glib в минимальном случае. Плюс любые сишные библиотеки, причём напрямую без врапперов.

Если честно, мне странно, что никто ещё такого вроде не делал.

Ах да... был Visual Basic, который внутри себя прятал COM. Но про этот рип лучше не вспоминать.

Я должен сказать, что очень уважаю Trolltech и их труд. Qt - замечательный фреймворк. Идея QtLanguage сама по себе хороша, но он слишком оброс тяжёлым культурным наследием. Вам очевидно, что в деструкторе MyDialog: public QDialog не нужно вызывать delete для MyHighlighter: public QSyntaxHighlighter, но нужно для MyVector: public std::vector<int>? А всё потому, что для QObject применяется своё - не укладывающееся в концепцию C++ - управление памятью в лучших традициях покойного MFC, в свою очередь воплощённых гугловским девизом "I'm Feeling Lucky".

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

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

Мотивы-то могут быть разными: или решили прогнуться под микрософт и забабахать проект на дотнете, или купились на рекламки оракла, или были в восторге от презентации какой-нибудь мегасреды типа Informatica...

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

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

> По сути, гномовцы так и ставят целью сделать. Есть C с ужас какими макросовыми извращениями, в который компилируется Vala - вполне себе нормальный ОО-язык, прошу заметить, с чистым синтаксисом и поддержкой всяких сигналов и рефлексии на уровне языка, причём без здорового рантайма с фреймворком и байткодом а-ля Java и .NET.

Есть мнение, что для гуйков ОО не обязательно.

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

> Если С не заявляет себя ОО - это честно. И ему нужно кучу всего добавить, чтобы дать программисту ОО. Если С++ заявляет себя ОО на уровне языка - он должен предоставлять достаточный набор фич ОО безо всяких макросов.

Здравствуйте, Сергей!

Рад, что у Вас в Гренландии всё хорошо и Вы сохраняете свой максимализм :). Живо представляю, как Вы в иглу, грея пальцы над керосинкой, терзаете olpc, пытаясь определить, где чёрное, а где белое. Это не наезд! :)

С уважением, Евгений

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

> Если честно, мне странно, что никто ещё такого вроде не делал.

Objective C посмотрите. Возможно, это оно. Похоже по описанию.

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

> А всё потому, что для QObject применяется своё - не укладывающееся в концепцию C++ - управление памятью в лучших традициях покойного MFC

Кстати, я работал с ними вполне в стиле C++, особых граблей не наблюдал. Разве что надо было заметить в манах строчку, что если ставишь на окно флаг "удалить по закрытии", то не надо для него делать delete.

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

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

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

> Это не наезд! :)

Да, это как-то больше похоже на траву. Или ацетон. В общем, вещества.

Просто как-то непонятно, к чему был этот камент...

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

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

Ну вот есть у меня одна полноценно гуйковая программа, в которой ни грамма ОО нет. А всё потому, что выбрана соответствующая графическая библиотека.

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

> Есть мнение, что для гуйков ОО не обязательно.

Если они написаны в стиле "волшебная кнопка" - безусловно.

Sikon ★★★
()

>Поскольку не останется простого способа для доступа к полям класса, а использование g_object_[sg]et() утомительно, необходимо ввести новые методы доступа, вроде g_object_get_int(), *double(), *string() и т.д.

Ждём gtemplate? =)

// AX

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

История не придумана. Я писал улучшенную функцию View Source для Arora, там в QDialog создавался QSyntaxHighlighter и привязывался к QPlainTextEdit::document. В конструкторе new, в деструкторе delete, всё выполнялось нормально. Потом разработчик сказал, что delete в деструкторе не нужен, потому что это QObject и он освободится автоматически...

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

> Потом разработчик сказал, что delete в деструкторе не нужен, потому что это QObject и он освободится автоматически...

Видимо это отсюда:

QObjects organize themselves in object trees. When you create a QObject with another object as parent, the object will automatically add itself to the parent's children() list. The parent takes ownership of the object i.e. it will automatically delete its children in its destructor.

Но тут не сказано, что нельзя делать delete. Я рассматриваю это автоудаление как удобную фишку для забывчивых, но не как отказ от традиционного new/delete.

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

>>Потом разработчик сказал, что delete в деструкторе не нужен, потому что это QObject и он освободится автоматически...

Это просто удобство, delete никто не запрещает делать.

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

>Я писал улучшенную функцию View Source для Arora, там в QDialog создавался QSyntaxHighlighter и привязывался к QPlainTextEdit::document. В конструкторе new, в деструкторе delete, всё выполнялось нормально. Потом разработчик сказал, что delete в деструкторе не нужен, потому что это QObject и он освободится автоматически...

Так и есть. Если объекту, унаследованному от QObject, назначить "родителя" (тоже унаследованного от QObject, разумеется), то он будет автоматически удалён при удалении родителя. Но ничего страшного не случится, если удалить его вручную через delete.

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

> Да, это как-то больше похоже на траву. Или ацетон. В общем, вещества.

О! Мне жаль.

> Просто как-то непонятно, к чему был этот камент...

Ну, не буду объяснять. Считайте, его не было. Извиняюсь. Евгений.

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

>Ещё насколько лет, и разработчики gtk вплотную приблизятся к изобретению C++ ;)

Что будет потом, страшно подумать. Наверняка возьмутся писать Qt =)

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

> Это просто удобство, delete никто не запрещает делать.

Достаточно указать 0 вместо parent...

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

> скорее пойдут дальше и изобретут java ;)

Дык, Vala уже есть. Которая похожа на C# с заточками под gobject.

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

> А вы др. новости на ЛОРе читали? Там раньше говорилось, что в gtk3 могут даже физику включить.

Все уже на химию переходят, а оне тут ещё с физикой мучаются...

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

>Как как насчет доказательств отсуствия инкапсуляции, полиморфизма, наследования в Си++?

Ну ладно, давай начнем кратко.

>инкапсуляции,

Её нет, так как надо модифицировать интерфейс (.h файл) при добавлении изменений в private секцию. Кроме того, по поводу приватности следует прочитать [Sutter 2005, Item 16]

Если оставаться в рамках Си, то можно не давать клиенту кода описание типа, оставляя только предварительную декларацию и пользоваться функциями с внутренней (static) линковкой.

>полиморфизма,

Если не ковырять в носу, то полиморфизм нужен для того чтобы из старого кода можно вызывать новый код без модификации старого. Вообще говоря, старый код ничего не знает про новые типы, и следовательно в С++ он не может создать инстанс нового класса, в отличие от Objective C где есть виртуальные конструкторы. Решение этой проблемы (фабрики объектов) нетривиально [Alexandrescu 2001, Chapter 8]

Пример очень старого кода, который вызывает очень много нового кода с конца 80-х до сего дня - это функция DispatchMessage в Windows. Она вообще ничего не знает про весь тот код который она вызывает ни про сообщения которые идут от новых версий ядра и новых контролов. Добавление новых оконных сообщений не ломает ни нее, ни унаследованный код. Программисту доступна маршрутизация этих сообщений - он может заставить контрол перенаправлять часть сообщений в хостящее окно например. И эта функция не пользуется полиморфизмом в плюсовом понимании.

>наследования

Наследования в С++ нет, так как в С++ нету мета-объектного протокола. То что имеет место в С++ это склеивание быдлоблобов и синтаксический сахар для работы с этими быдлоблобами. [Absurd @ LOR]

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

> Да нет, это Вы извините

Да уж. Вы возвращайтесь оттель, где Вы там нынче обретаетесь. Не на пользу это русскому человеку. У нас программа репатриации действует :)

С уважением, Евгений.

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

> Вам очевидно, что в деструкторе MyDialog: public QDialog не нужно вызывать delete для MyHighlighter: public QSyntaxHighlighter

Не "не нужно", а "можно не". А можно и вызвать... Или я чего-то не понимаю? :)

А вот один раз объявил что-то Q* статиком, смешно получилось, это да... :)

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

Чудесно, просто чудесно! Сначала рьяно принялся строчить ответит, но потом подумал, что такой шедевр пошло портить никчёмными комментами. Поражён до глубины души полётом мысли :-D

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

>> Как как насчет доказательств отсуствия инкапсуляции, полиморфизма, наследования в Си++?

> Ну ладно, давай начнем кратко.

А не будет наглостью повторно попросить определения терминов "инкапсуляция", "наследование" и "полиморфизм"? Неформальное вполне устроит.

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

да вы батенька какой-то новый c++ придумали! =)

>>инкапсуляции,

>Её нет, так как надо модифицировать интерфейс

угу, а ещё её нет потому, что монитор LCD

>>Вообще говоря, старый код ничего не знает про новые типы, и следовательно в С++ он не может создать инстанс нового класса

Ничего не понял. Одно с другим не вяжется.

Вот захотел я сделать файлманагер с кешированием в sqlite. Написал наследника KDirLister с поддержкой кеширования и скормил его KDirOperator'у. Всё как работало так и работает + поддержка кэша. Файл манагер работает с моим листерм ТАКЖЕ как и со стандартным, но ОТВЕТНЫЕ действия листера различаются.

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

>Не "не нужно", а "можно не". А можно и вызвать... Или я чего-то не понимаю? :)

Именно так, но скорее всё-таки "не нужно", а не нальзя. Просто чтобы лишний бесполезный код не плодить.

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

> И что это даст ? :)

Возможность смело использовать delete

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

> Не "не нужно", а "можно не". А можно и вызвать... Или я чего-то не понимаю? :)

Для QObject есть более безопасное - deleteLater() и то, если припрёт..

anonymous
()

закапывайте

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

> не подходит для gui классов

С виджетами совсем другая песня. В особо тяжёлых случаях мне хватало Qt::WA_DeleteOnClose для всяких диалогов.

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

Да не парься ты на ровном месте. Если задан parent, то можно удалять руками, а можно и не удалять --- parent почистит. Если удаляешь руками, то parent по второму разу удалять не будет :)

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