LINUX.ORG.RU
Новости — GNOME  

Планы по выпуску 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 ()

 ← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 →
Ответ на: комментарий от Absurd

> от многих концепций ему пришлось бы отказаться

поподробнее плз, от каких имено?

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

>> И всё же: почемуй-то memcpy позволяет двигать сишные структуры безо всяких проблем?

> По стандарту объект перемещать с помощью memcpy/GlobalUnlock/whatever нельзя, а POD можно.Cможешь сразу, без подглядывания в литературу назвать конкретный признак, которая отделяет POD от не-POD?

Наличие функций-членов, наследования и т.п. Отлично, что c++-классы двигать нельзя мы показали. Таки почему _можно_ без пробле двигать struct-ы? Показана только теоретическая возможность для этого.

>> И второе уточнение: так какие же библиотеки должны быть в стандарте языка c++? ncurses, бд, сеть ты уже назвал.

> Да этого хватит.

А почему хватит этого? И почему без этого обойтись нельзя было. Непонятненько.

> Если бы Строуструп осилил написание хотя бы примитивных гуйков, то от многих концепций ему пришлось бы отказаться.

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

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

> И то, что за более чем 20 лет существования гуйков ещё так и не написали адекватный оо-язык для их написания, говорит о многом, в т.ч. о плохой применимости оо для гуйков.

Разве? Tcl/tk, vala/gtk, Lisp/CLIM

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

>> И то, что за более чем 20 лет существования гуйков ещё так и не написали адекватный оо-язык для их написания, говорит о многом, в т.ч. о плохой применимости оо для гуйков.

> Разве? Tcl/tk,

Тикль -- "пластилиновый" язык: не имеет жёстких интерфейсов, контроля типов, у него нет понятия компиляция, следовательно и проверить ошибку можно только в рантайме. К тому же, к нему можно прикрутить любые действия, в т.ч. нарушающие оо. Я б не стал называть его строгим оо-языком.

> vala/gtk,

Читаем заголовок топика и убеждаемся в том, что оо в gtk(а, вернее, в G_language неполноценное). Начать к 3 версии задумываться о приватных методах и полях -- это сильно!

> Lisp/CLIM

В этих морях я не плавал. Но клим этот -- он точно оо?

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

>Наличие функций-членов, наследования и т.п

Неправильно. Функции-члены у POD-ов можно делать. Только вот наличие конструктора и деструктора делают структуру не-POD'ом сразу. У POD'а надо делать что-то типа MyPOD::Init() и MyPOD::Destroy().

>Таки почему _можно_ без пробле двигать struct-ы? Показана только теоретическая возможность для этого.

Если внешних указателей на структуру нет, то можно. А вместо внешних указателей можно использовать хэндлы. Чтобы получить указатель - использовать lock, чтобы разрешить фреймворку удалить структуру из памяти и записать измения на диск - unlock(). После unlock указатели само собой считаются невалидными. Таким образом происходит работа с большими tiff файлами - там надо лочить фрагменты с которыми происходит работа в настоящий момент.

>>> И второе уточнение: так какие же библиотеки должны быть в стандарте языка c++? ncurses, бд, сеть ты уже назвал.

>> Да этого хватит.

>А почему хватит этого? И почему без этого обойтись нельзя было.

Это сразу прояснило бы 80% идиом проектирования под С++. gui - asynchronous event-driven идиомы, БД - биндинги таблиц к полям объектов и кэширование, сеть - возможно вызвала бы появление RPC, сериализации и nio. Такой стресс-тест для ОО языка надо делать обязательно.

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

>> Lisp/CLIM

> В этих морях я не плавал. Но клим этот -- он точно оо?

CLIM - stream-based. Имхо, образцово-показательным ОО-гуем всегда ставили NextStep. Я ошибаюсь?

А ещё люди пишут, что архитектура гуя во многом зависит от решаемой задачи. Поэтому, например, есть event-based гуи типа Cells.

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

> Это сразу прояснило бы 80% идиом проектирования под С++. gui - asynchronous event-driven идиомы, БД - биндинги таблиц к полям объектов и кэширование, сеть - возможно вызвала бы появление RPC, сериализации и nio. Такой стресс-тест для ОО языка надо делать обязательно.

Сдаётся мне, что споришь "Почему C++ не Common Lisp/Python/Ruby?". В CL, кстати, с некоторыми современными аспектами вычислительной техники тоже бардак. Например, с SMP и TCP/IP. Оно, конечно, есть в виде библиотек, но под каждую реализацию CL есть своя библиотека. А ещё есть полторы библиотеки, которые предоставляют одинаковый интерфейс, но они все Лиспы не перекрывают и глючат, к тому же. Эх, надо было МакКарти в 58-м году сразу закладываться на многоядерные процессоры, операционки с поддержкой многопоточности и TCP/IP...

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

> Если внешних указателей на структуру нет, то можно. А вместо внешних указателей можно использовать хэндлы. Чтобы получить указатель - использовать lock, чтобы разрешить фреймворку удалить структуру из памяти и записать измения на диск - unlock(). После unlock указатели само собой считаются невалидными. Таким образом происходит работа с большими tiff файлами - там надо лочить фрагменты с которыми происходит работа в настоящий момент.

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

>>> И второе уточнение: так какие же библиотеки должны быть в стандарте языка c++? ncurses, бд, сеть ты уже назвал.

> Это сразу прояснило бы 80% идиом проектирования под С++. gui - asynchronous event-driven идиомы, БД - биндинги таблиц к полям объектов и кэширование, сеть - возможно вызвала бы появление RPC, сериализации и nio.

Нахрена всё вышеперечисленное тащить в оо?

> Такой стресс-тест для ОО языка надо делать обязательно.

Не путает ли мсье оо-языки и gp-языки?

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

> Имхо, образцово-показательным ОО-гуем всегда ставили NextStep. Я ошибаюсь?

Почитал. Лписание выглядит красиво. Интересно, а почему оно не получило широкого распространения, благо открытая реализация имеется?

> А ещё люди пишут, что архитектура гуя во многом зависит от решаемой задачи. Поэтому, например, есть event-based гуи типа Cells.

Все гуйки по построению являются event-driven. Только тулкиты пытаются это скрыть, отсюда и следует их громадная сложность.

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

>Сдаётся мне, что споришь "Почему C++ не Common Lisp/Python/Ruby?

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

>Эх, надо было МакКарти в 58-м году сразу закладываться на многоядерные процессоры, операционки с поддержкой многопоточности и TCP/IP...

58-ой не 98-й (год принятия Стандарта С++)

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

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

Фотошопъ на Win3.11 работал с такой "виртуальной памятью вручную". Забавных глюков замечено не было.

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

>> Сдаётся мне, что споришь "Почему C++ не Common Lisp/Python/Ruby?

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

Удобство программирования на получившемся монстре.

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

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

> Фотошопъ на Win3.11 работал с такой "виртуальной памятью вручную". Забавных глюков замечено не было.

И спасибо за это надо сказать программистам из Adobe, которые чутко следили, чтоб никакая с... ничего не закешировала :)

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

>>>> Дело в том, что Си++ содержит _весь_ Си89 как подмножество. В том числе - триграфы.

>>> Совместимость со всяким говном мамонтов

>> Совместимость со стандартом.

> С говном мамонтов. Даже в ДОС был ANSI.SYS

Только что речь шла о триграфах, и ВНЕЗАПНО - снова о поддержке терминалов. Если ты такой ветеран, то должен знать, что обычно ANSI.SYS не загружали, чтобы сэкономить немного памяти. Ну и тема сети осталась нераскрытой.

> int *pi = malloc(sizeof(int) * some_length) прокатит в С89, но не прокатит в С++. Поскольку ты как типичный плюсофил начнешь придираться к разной х^W

Это как раз пример того, как "придираются к разной х^W".

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

>Только что речь шла о триграфах, и ВНЕЗАПНО - снова о поддержке терминалов.

Даже в ДОС была псевдографика. При отсутствии ANSI.SYS в принципе можно было писать напрямую в видеопамять, как происходило в TurboVision.

>Ну и тема сети осталась нераскрытой.

Раскрытой. На любой 32-битовой-или-более машине с виртуальной памятью сеть есть.

>> int *pi = malloc(sizeof(int) * some_length) прокатит в С89, но не прокатит в С++. Поскольку ты как типичный плюсофил начнешь придираться к разной х^W

>Это как раз пример того, как "придираются к разной х^W".

Да, не пропускаем типичную мэйнстримовскую конструкцию на Си для аллокации динамического массива, зато тянем совместимость с триграфами. Зашибись логика.

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

>> Ну и тема сети осталась нераскрытой.

> Раскрытой. На любой 32-битовой-или-более машине с виртуальной памятью сеть есть.

Сеть подключена к 17 биту? :о)

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

> При отсутствии ANSI.SYS в принципе можно было писать напрямую в видеопамять, как происходило в TurboVision.

Какая система кроме доса это позволяла?

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

>> При отсутствии ANSI.SYS в принципе можно было писать напрямую в видеопамять, как происходило в TurboVision.

>Какая система кроме доса это позволяла?

Вопрос: Что такое икапсуляция в ОО? Ответ: Это способ скрыть делали реализации от клиента кода. Вопрос: Является ли способ выводить псевдографику, например через прямую работу с видеопамятью или через Escape-последовательности "деталью реализации"? Ответ: Да.

Это достаточно исчерпывающе?

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

>>Ну и тема сети осталась нераскрытой.

>Раскрытой. На любой 32-битовой-или-более машине с виртуальной памятью сеть есть.

Ты опять соскочил с темы. Ну да ладно... в DOS extenderжах сети обычно не было. В OS/2 сокетов обычно не было.

>>> int *pi = malloc(sizeof(int) * some_length) прокатит в С89, но не прокатит в С++. Поскольку ты как типичный плюсофил начнешь придираться к разной х^W

>>Это как раз пример того, как "придираются к разной х^W".

>Да, не пропускаем типичную мэйнстримовскую конструкцию на Си для аллокации динамического массива

На эту конструкцию ругались как минимум некоторые компиляторы Си того времени.

> зато тянем совместимость с триграфами. Зашибись логика.

Я не понял, это претензия к Си или Си++?

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

>>>Ну и тема сети осталась нераскрытой.

>>Раскрытой. На любой 32-битовой-или-более машине с виртуальной памятью сеть есть.

>Ты опять соскочил с темы.

Я не соскакивал ни с какой темы. Не надо врать.

>в DOS extenderжах сети обычно не было. В OS/2 сокетов обычно не было.

А кинуть экзепшен "Сеть недоступна" не судьба?

>>Да, не пропускаем типичную мэйнстримовскую конструкцию на Си для аллокации динамического массива

>На эту конструкцию ругались как минимум некоторые компиляторы Си того времени.

Это законная конструкция, т.к. конверсия void* -> T* по стандарту C89 имеет право быть неявной. Наверно, ты писал Си - код в файлах с расширением cpp.

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

> Почитал. Лписание выглядит красиво. Интересно, а почему оно не получило широкого распространения, благо открытая реализация имеется?

Миром правят маркетологи

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

>>в DOS extenderжах сети обычно не было. В OS/2 сокетов обычно не было.

>А кинуть экзепшен "Сеть недоступна" не судьба?

Ты сказал "на любой 32-битовой-или-более машине с виртуальной памятью сеть есть"? Это не так, и не отмазывайся.

Впрочем, это не имеет отношения к делу.

> конверсия void* -> T* по стандарту C89 имеет право быть неявной. ]

Возможно, стандарта под рукой нет. Предупреждения помню,

Впрочем, то, что Си++ запрещает неявные преобразования из void *, не значит, что он не должен поддерживать и триграфы тоже.

> Наверно, ты писал Си - код в файлах с расширением cpp.

Нет.

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

>>>в DOS extenderжах сети обычно не было. В OS/2 сокетов обычно не было.

>>А кинуть экзепшен "Сеть недоступна" не судьба?

>Ты сказал "на любой 32-битовой-или-более машине с виртуальной памятью сеть есть"? Это не так, и не отмазывайся.

От своих слов я не отказываюсь, но подгонять стандарт под частные случаи без сети второй половине 90-х это ошибка. Тем более что они так и не подогнали стандарт под машины без виртуальной памяти (хотя и пытались это сделать [Meyers, Effective STL, глава про аллокаторы])

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

> Вопрос: Является ли способ выводить псевдографику, например через прямую работу с видеопамятью или через Escape-последовательности "деталью реализации"? Ответ: Да.

> Это достаточно исчерпывающе?

Достаточно. Просто я помню, с какой скоростью происходил вывод в crt.tpu/TV и через прямую запись в видеопамять. Уж слишком дорогая "деталь реализации" :)

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

>> Почитал. Лписание выглядит красиво. Интересно, а почему оно не получило широкого распространения, благо открытая реализация имеется?

> Миром правят маркетологи

Ну маркетологи могли вполне убить nextstep. Но gnustep-то никуда не делся.

Собственно, сформулировался такой вопрос: почему гном написан не на всём таком красивом openstep, а на gtk, который до 2008 года до ума доводят? Маркетолог де Иказа помешал?

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

>почему гном написан не на всём таком красивом openstep, а на gtk, который до 2008 года до ума доводят? Маркетолог де Иказа помешал?

Я не пытался ковырять биндинги ObjectiveC->gtk. Вероятно стоит попробовать.

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

> Собственно, сформулировался такой вопрос: почему гном написан не на всём таком красивом openstep, а на gtk, который до 2008 года до ума доводят? Маркетолог де Иказа помешал?

Я тоже в шоке, почему сейчас не пишут исключительно на Лиспе. И, да, куда делись аппаратные лисп-машины? ;)

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

> И, да, куда делись аппаратные лисп-машины? ;)

Часть - в музеи, остальные - на помойку :D

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

>> И, да, куда делись аппаратные лисп-машины? ;)

> Не иначе как происки Страуструпа! :о)

"Oops you found out... now we have to kill you" (с)

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

>> Имхо, образцово-показательным ОО-гуем всегда ставили NextStep. Я ошибаюсь?

> Почитал. Описание выглядит красиво. Интересно, а почему оно не получило широкого распространения, благо открытая реализация имеется?

Даже две, GNUStep и Cocotron.

Apple это [нераспространённость] на руку, потому что Mac OS X остаётся уникальной. Trolltech это выгодно по понятным причинам, две женщины на одной кухне не уживаются, а там ещё gtk+. Microsoft выгодно подсаживать на непереносимые API.

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

> Собственно, сформулировался такой вопрос: почему гном написан не на всём таком красивом openstep, а на gtk, который до 2008 года до ума доводят?

GNUStep тоже надо доводить. В Etoile разную функциональность дописывают, помимо окружения рабочего стола, но Etoile в моём менеджере пакетов качается не тарболлом, а из SVN, а это говорит о сырости.

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

>> Собственно, сформулировался такой вопрос: почему гном написан не на всём таком красивом openstep, а на gtk, который до 2008 года до ума доводят?

> GNUStep тоже надо доводить.

Ну явно там доводки гораздо меньшие чем переработка фундамента языка, на котором написан тудкит(я снова покосился на топик).

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

>Не, гик в последнее время какой-то квёлый :)

Принялся изучать этимологию слова "квелый" и на первой же странице гугла натолкнулся на ссылку "c++/6807: G++ doesn't recognize templated reference conversion operators"

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

>> Не, гик в последнее время какой-то квёлый :)

> Принялся изучать этимологию слова "квелый" и на первой же странице гугла натолкнулся на ссылку "c++/6807: G++ doesn't recognize templated reference conversion operators"

Теперь я понял, каково "надорвать живот от смеха" :)

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

> Ну явно там доводки гораздо меньшие чем переработка фундамента языка, на котором написан тудкит(я снова покосился на топик).

Меня, и не меня одного не совсем устраивает ObjC. Там довольно странная схема именования. [myObject setColorWithRed:0.4 green:0.3 blue:0.0 alpha:1.0]; -- как вам это?

Неприятно к такому привязываться. red становится частью другого идентификатора, меняет кейсинг. Сильно непохоже на то, что в других языках. И непонятно, зачем это в языке, основанном на C? Франкенштейн какой-то. Динамическое связывание ObjC меня устраивает, допустимый компромисс, но вот имена всё портят. Плюс к этому, [array objectAtIndex:n] вместо array[n]. Плюс, плоское сишное пространство имён.

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

> Там довольно странная схема именования. [myObject setColorWithRed:0.4 green:0.3 blue:0.0 alpha:1.0]; -- как вам это?

Нам это не по душе. Однако, вроде бы в Objective C 2.0 это поправили?

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

> Меня, и не меня одного не совсем устраивает ObjC. Там довольно странная схема именования. [myObject setColorWithRed:0.4 green:0.3 blue:0.0 alpha:1.0]; -- как вам это?

Мда, действительно странновато. Но ведь не смертельно. Вот лично меня записи типа "tablelist::tablelist $resultWidget -listvariable result -titlecolumns 0 -showseparators 1 -labelcommand tablelist::sortByColumn" не пугают.

Там хоть с этими объектами оперировать как с примитивами можно? Адрес брать, копировать?..

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

>> Принялся изучать этимологию слова "квелый" и на первой же странице гугла натолкнулся на ссылку "c++/6807: G++ doesn't recognize templated reference conversion operators"

>http://www.anekdot.ru/id.html?-10001462

Да не, это правда. Я искал "squell", а баг запостил некий чувак под ником squell. Потом накопал слово quell по которому подходит http://lingvo.yandex.ru/en?text=quell

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

> Там хоть с этими объектами оперировать как с примитивами можно?
> Адрес брать, копировать?

Адрес -- запросто, там по адресу, в основном, работа и идёт. id -- универсальный
указатель вместо void*, на void* сообщения посылать нельзя. Для копирования есть
протоколы NSCopying и NSMutableCopying.

Да, ещё особенность. Инкапсуляция неполная. Скажем, NSCursor.h смотрим:

@interface NSCursor : NSObject <NSCoding> {                                                     
    /*All instance variables are private*/                                                      
    NSPoint _hotSpot;                                                                           
    struct _cursorFlags {                                                                       
        unsigned int onMouseExited:1;                                                           
        unsigned int onMouseEntered:1;                                                          
        unsigned int cursorType:8;                                                              
        unsigned int :22;                                                                       
    } _flags;                                                                                   
    id _image;                                                                                  
#ifdef WIN32                                                                                    
    void *_windowsCursor;                                                                       
#endif                                                                                          
}                                                                                               


При ObjC'шной реализации динамического связывания эта особенность в очередной
раз портит всю картину. В текущем варианте можно наследовать классы от закрытых
реализаций, но тогда они должны иметь зафиксированное внутреннее устройство.
Текущее решение инкапсуляции в виде

@interface NSPrinter: NSObject<NSCopying, NSCoding> {                                           
    @private                                                                                    
    unsigned char _44BytesOfPrivateData[44];                                                    
}                                                                                               

(NSPrinter.h) или в виде внутреннего вложенного объекта id не впечатляет. Сделать
так, чтобы размер приватной части узнавался в рантайм, тяжелее, но без этого как-то
несимпатично.

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

>> Меня, и не меня одного не совсем устраивает ObjC. Там довольно странная схема
>> именования. [myObject setColorWithRed:0.4 green:0.3 blue:0.0 alpha:1.0]; -- как вам
>> это?

> Мда, действительно странновато. Но ведь не смертельно. Вот лично меня записи типа
> "tablelist::tablelist $resultWidget -listvariable result -titlecolumns 0 -showseparators 1
> -labelcommand tablelist::sortByColumn" не пугают.

Я думаю, в Tcl, если поменять местами -listvariable result и -showseparators 1, ничего не
случится, а вот если что-нибудь переставить в

_pixelBuffer = [[NSOpenGLPixelBuffer alloc] initWithTextureTarget:GL_TEXTURE_2D
                textureInternalFormat:GL_RGBA textureMaxMipMapLevel:9
                pixelsWide:512 pixelsHigh:512];

то селектор будет уже другой

Если тип указателя не id, то компилятор кидает ворнинг. В рантайме разницы между
NSArray*, NSPanel* и id никакой.

Nihilist ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 →
GNOME