GNOME 2.12 - что день грядущий нам готовит

Да, только это все такие сопли по сравнению с торможением графических устройств... В принципе, да, артур над каиро должен быть медленнее прросто каиро - но заметит ли пользователь?... И - главное - наличие al позволяет менять бекенды. Что само по себе фича (см. gconf). Так что есть плюсы у артурки, есть...:)

>inline int my_call (int x) { return wrapp_call(x) +1; }

тебе показать тут лишний inc? а ведь это самый элементарный враппер. А если ещё вызов в зависимости от параметров должен быть переадресован соответствующей функции? и преобразование данных туда-сюда? это ты называешь "без потери производительности?

>>если C++ библиотеку нельзя без гемора заюзать нигде кроме как в C++ приложении - о какой гибкости речь?

>гибкость и ABI разные вещи :)

ок. слив защитан =)

При чем тут рама и проц?? У Вас же шина AGP торможить будет. У вас же данные в кэш проца поползут из видеопамяти медленно и печально...

>Так что есть плюсы у артурки, есть...:)

ну есть. только один больщой минус перевешивает оба маленьких плюса =)

svu
не хочу с тобой флеймить
так как ты слишком все хорошо знаешь :)

наличие обвязок не говорит об систематическом/системной использовании
правда ?
то что python c++ c# поддерживают C ABI
не говорить о хороших чертах гнома
правда ?

PS
а так у меня давно в голове крутится что сначала неплохо бы стандартизировать
что то вроде ОПП ABI (COM like ) и очень похоже что плюсы тут как раз и хорошо
- прошу не бить меня за такую фразу - это не ради флэйма а ради - думал на эту тему

>При чем тут рама и проц?? У Вас же шина AGP торможить будет.

да что-то часто слышу от кдешников "добавь памяти" и "поставь процессор нормальный"

>У вас же данные в кэш проца поползут из видеопамяти медленно и печально...

у меня данные не ползают =)

в любом случае артур для не QT-приложений бесполезен. так что тут обсуждать даже нечего

>то что python c++ c# поддерживают C ABI не говорить о хороших чертах гнома

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

>плюсы тут как раз и хорошо

плюсы тут как раз и плохо. плохо биндятся.

> GTK+ же не имеет базовых виджетов, которые давно есть в Qt.

каких?

>>>внешний вид оффтопика и кед вызывает резь в глазах

Это только у людей с глазной девиацией такие проблемы, у людей с нормальным зрением - таких проблем нету.

Т.е. единственное в чем можно обвинить комманду KDE - прненебрежение к инвалидам.

> так как ты слишком все хорошо знаешь :)

Это к Луговскому и Ирси:)

> то что python c++ c# поддерживают C ABI не говорить о хороших чертах гнома правда ?

Это говорит о продуманной языковой политике гнома. О том, что выбран базовый язык, позволяющий надстраивать все, что угодно. Ассемблер проца под названием Уних:)

> стандартизировать что то вроде ОПП ABI (COM like ) .. плюсы тут как раз и хорошо Пытались многие. COM/SOM/Corba/Bonobo/... Универсального решения не получилось. Увы. Кстати, плюсы тут не хорошо - они тянут за собой объектную модель, которая в других языках может оказаться совершенно чужеродной.

>>inline int my_call (int x) { return wrapp_call(x) +1; }
>тебе показать тут лишний inc? а ведь это самый элементарный враппер. А если ещё
>вызов в зависимости от параметров должен быть переадресован соответствующей
>функции? и преобразование данных туда-сюда? это ты называешь "без потери
>производительности?

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

>>>если C++ библиотеку нельзя без гемора заюзать нигде кроме как в C++ приложении
>>>- о какой гибкости речь?
>>гибкость и ABI разные вещи :)
>ок. слив защитан =)
geek прошу тебя в приличной беседе не употреблять фраз типа 'слив защитан'
- это по крайней мере не красиво :(
__________
а насчет производительности
по моим наблюдениям гном тормознее кде :(

> то что python c++ c# поддерживают C ABI не говорить о хороших чертах гнома

Зато можно писать приложения под гном хоть на Ruby. Что и делает разработчик Alexandria.

> в любом случае артур для не QT-приложений бесполезен. так что тут обсуждать даже нечего

Это да - это точно минус. Просто из-за этого минуса нельзя отрицать наличие плюсов. Для конкретной ниши...

Доступа к БД, наверное:)

>о потерях производительности во врапере лучше не говорить бессмысленно и сведется к непродуманности интерфейса обертываемой библиотеки :)

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

>geek прошу тебя в приличной беседе не употреблять фраз типа 'слив защитан' - это по крайней мере не красиво :(

ладно. я буду говорить "ТУШЕ!"

=)

>а насчет производительности по моим наблюдениям гном тормознее кде :(

чем мерял? =)

>> то что python c++ c# поддерживают C ABI не говорить о хороших чертах гнома
>>правда ?
>Это говорит о продуманной языковой политике гнома. О том, что выбран базовый язык, >позволяющий надстраивать все, что угодно. Ассемблер проца под названием Уних:)
>> стандартизировать что то вроде ОПП ABI (COM like ) .. плюсы тут как раз и >>хорошо
>Пытались многие. COM/SOM/Corba/Bonobo/... Универсального решения не получилось. Увы. Кстати, плюсы тут не хорошо - они тянут за собой объектную модель, которая в других языках может оказаться совершенно чужеродной.

!!!!! давай не будем спорить на эту тему
во первых это офтопик - с++ vs c
во вторых - как ты уже сказал универсального решения не получилось
в третих - с++ object model тоже офтопик
в четвертых - в этой области не существует одинаково хренового решения для всех
НО ! такое решение необходимо ? правильно ?

я просто скажу свое мнение
!!! это суровое IMHO - критика не принимается
- нет таких причин по которым нужно делать хреновую архитектуру
- даже совместимость и переносимость

> НО ! такое решение необходимо ? правильно ?

Я тут еще 10сек подумал. И понял - неправильно. Ибо стандарт на ОО API/ABI означает стандарт на объектную модель. А она у всех разная. Так что извиняйте. Остается в сухом остатке необъектный С:)

>>о потерях производительности во врапере лучше не говорить бессмысленно и сведется к непродуманности интерфейса обертываемой библиотеки :)

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

-------- сведется к непродуманности интерфейса обертываемой библиотеки :)

>geek прошу тебя в приличной беседе не употреблять фраз типа 'слив защитан' - это по крайней мере не красиво :(

ладно. я буду говорить "ТУШЕ!"

=)

ужас а по русски - или с заменил вам родной ?
________________________________________________________________
>а насчет производительности по моим наблюдениям гном тормознее кде :(

чем мерял? =)

я бы сказал .... :))
субъективное мнение - можно не обращать внимание, пока :)
- здесь только замечание что они приблизительно одинаковы
нету различия хотябы на порядок что бы оно было убедительным

>> НО ! такое решение необходимо ? правильно ?

>Я тут еще 10сек подумал. И понял - неправильно. Ибо стандарт на ОО API/ABI означает стандарт на объектную модель. А она у всех разная. Так что извиняйте. Остается в сухом остатке необъектный С:)

нет не правильно - в сухом остатке есть объекты
все ООП их имеют
посылка сообщений и тп

остаются некоторые разногласия но в конце концов способ передачи аргументов на стэке
и формат строки С всем так-же навязал ...

-- вопрос в том что бы решение было достаточно хреновое
но не больше

Знаешь, если бы сейчас тут не было svu, то за такой твой опус специалисты по 2D (и не только 2D) могли бы тебя на маленькие кусочки растерзать ;)

----------

>>Hint: технически такой враппер привносит в скорость работы ничтожные доли процента, поскольку графические операции относительно медленные, а иногда очень медленные.

>"поставь 4гц проц, видяху за 500уёв, два гига рамы и не епи мозг"? КДЕшники всё-таки скомуниздили девиз у жабакодеров =)

>нет не правильно - в сухом остатке есть объекты все ООП их имеют посылка сообщений и тп

в C нет объектов, как таковых.

да и от языка к языку ООП-модель меняется. в C# она немножко более другая, чем в C++. Или с жабой сравнить. так что...обломс.

>Знаешь, если бы сейчас тут не было svu, то за такой твой опус специалисты по 2D (и не только 2D) могли бы тебя на маленькие кусочки растерзать ;)

я кажется всё доходчиво написал =) и не надо меня хинтами тыкать.

> нет не правильно - в сухом остатке есть объекты все ООП их имеют посылка сообщений и тп

Увы, это все базис. Этого недостаточно для нормальной работы. А вот как наполнять начнете - вот тут посыпется. Как быть с классами? С интерфейсами? С множественным наследованием? Являются ли всякие int/char/... классами? Как только Вы начинаете полноценно разрабатывать все это дело - Вы получаете объектную модель. И те, кто ей не соответствует - отдыхают. А если вы будете искать "наибольший общий делитель" - Вы получите такой минимум бенефитов, что он не будет стОить свеч.

Разработчик Gnome о политике разработки у гномеров и превосходстве KDE!!!

Всем! Отличный сайт создателя Rosegarden и разработчика GTK-- : http://www.telegraph-road.org/index.php?p=writings

Рекомендую(по теме): http://www.telegraph-road.org/writings/thoughts_on_rg_devel.html

Или гномеры по-английски читать не умеют?

>> нет не правильно - в сухом остатке есть объекты все ООП их имеют посылка сообщений и тп

>Увы, это все базис. Этого недостаточно для нормальной работы. А вот как наполнять начнете - вот тут посыпется. Как быть с классами? С интерфейсами? С множественным наследованием? Являются ли всякие int/char/... классами? Как только Вы начинаете полноценно разрабатывать все это дело - Вы получаете объектную модель. И те, кто ей не соответствует - отдыхают. А если вы будете искать "наибольший общий делитель" - Вы получите такой минимум бенефитов, что он не будет стОить свеч.


э говорю только о достаточно хреновом решении
во первых ...
Как быть с классами? - никак это проблемы конкретных языков
С интерфейсами? - а вот это очень важно
С множественным наследованием? - множественное наследование интерфейсов- поддерживают почти все (не знаю кто не могет)
Являются ли всякие int/char/... классами? - все остальное как в С
- достаточно ввести ABI call:
result_t send_message(object_t* object, selector_t selector, struct arg_list_t arg_list);
и какой либо стандарт на манипуляцию arg_list
насколько вы знаете - в различных вариантах подобную вещь
повторяют с десяток систем
вопрос в том - а не пора ли прийти к единому мнению ?
и прекратить войну языков

извиняйте
сигнатура конечно хреновая
но хотя бы общий вид ....

>вопрос в том - а не пора ли прийти к единому мнению ? и прекратить войну языков

зачем? использование на нижнем уровне C (или любого другого компилируемого процедурного языка) не приводит к войне. Война начинается когда пытаются использовать C++-библиотеки из других языков.

> result_t send_message(object_t* object, selector_t selector, struct arg_list_t arg_list);

ужос =)

geek не встревай, пожалуста
просто посмотри
objective c runtime
ffcall
corba
com
xpcom
и тд
кстати в с++ необходимость в таких вещах уже назрела
надеюсь что страуструп не будет ждать пока кто то не докажет полезность
(у них у все - страуструп, торвальдс - политика такая
нихрена не делать - тогда не обвинят в глупости :))
и в следующем стандарте оно будет
- ну вот тогда станет интересно
насколько GNOME API будет гибким и переносимым :)
если изменить ABI ;))

>result_t send_message(object_t* object, selector_t selector, struct arg_list_t arg_list)

распиши, что такое result_t, object_t, selector_t, arg_list_t =)

>objective c runtime ffcall corba com xpcom

если бы что-то из этого было достаточно удобным...однако универсального решения нет. Любая из этих технологий предусматривает жесткую ООП-модель. Даже исключительно ООП-языки привести к одному знаменателю не получится. Ну а если сильно хочется что-то вроде этого - есть .net/mono

ps: за такую конструкцию вызова метода ты будешь проклят процедурщиками и функциональщиками =) ты представляешь себе подготовку данных перед ТАКИМ вызовом?

int, int, int, int :))))))))))))))))
существуют и подобные варианты :)))
в рамках архитектуры - это не важно :)))
могу только сказать достаточно простые типы но не очень
что бы народ не сильно выл (поскулил чуть чуть :)

>ps: за такую конструкцию вызова метода ты будешь проклят процедурщиками и функциональщиками =) ты представляешь себе подготовку данных перед ТАКИМ вызовом?

для с - хреново и очень
но там всегда было хреново
для всех остальных решаемо на уровне abi и даже возможно и без overhead :))
по отношению к имеющему быть :)

>int, int, int, int :)))))))))))))))) существуют и подобные варианты :)))

нда...

>могу только сказать достаточно простые типы но не очень что бы народ не сильно выл (поскулил чуть чуть :)

не получится. почему - см. выше. унифицированные языки - это утопия. Проще законодательно обязать всех писать на плюсах =)

geek
а вызов с функции из scheme - это утопия ?
а почему это имеет место быть ?
выкинь из головы нет - речь идет только об интерфейсах

>для с - хреново и очень но там всегда было хреново

gtk_button_size_request(widget,requisition);

что тут хренового? а arg_list_t...кто поймет, что там внутри?

Никому этот freedesktop.org и даром не нужен. Кроме гномовцев, которым команду сверху спустили.

>Нет строгого соответствия версия билиотеки <-> версия GNOME, проме нескольки ну совсем уж специфичных, совсем нет. В основном как раз потому, что GNOME состоит из мелких кусочков с согласованными интерфейсами :-)

Тогда такой вопрос. Кто мне даст номинальную гарантию, что даже при неизменном апи эти библиотеки будут совместимы в каком-то масштабе с остальными?

Получается, что в KDE у меня есть такая гарантия от разработчиков + от дистростроителей. В gnome гарантия только от последних.

>Нужно ответить прямо - те, кому не нужно 13 настроек для апплета "часы" в панели, 7 сплэшей при загрузке и krename :-)

Это напоминает мне такой анекдот:

Поймал грузин рыбку, а та оказалась золотой. Ну и говорит ему:

- Загадывай три желания, только отпусти меня.

Ну тот подумал, кепку почесал.

- Хочу, чтобы у меня нос мясистый был.

Рыбка удивилась, но сделала.

- Давай теперь второе желание.

- Ну... Хочу, чтобы у меня уши были мясистые.

Еще сильнее удивилась, но сделала. Грузин упорно думает дальше. Рыбка его торопит.

- Третье давай уже, сил никаких нет, задыхаюсь.

- Ну тогда хочу, чтобы у меня были губы мясистые.

Еще сильнее удивилась рыбка, но сделала. Грузин ее отпустил. Рыбка плавала-плавала. Думала-думала, не выдержала, приплывает обратно и спрашивает:

- Слушай, мужик, почему ты себе какую-то фигню загадал? Вот все загадывают замки, денег, жен красивых, а?

- А что, можно было?

-----------------

Так и тут. Одни часы, один апплет. А что, можно было что-то другое?

>Саратов --- население ~800 тыс + Энгельс ~300тыс в 4км восточнее час dialup стоит ~10 руб. за 50 бесплатных попыток дозвониться и ~20 у нормальных провайдеров

У меня девочка знакомая в Саратове живет. Диалап. 37500. У меня в Зелеке на модеме больше 28800 ни на одном телефоне не поднималась (чтобы на этом можно было работать). Это Москва...

Сидит она, не вылезая из инета. Думаю, при ее зарплате вряд ли она бы стала платить 10-20 рублей за 50 попыток. ;)

в общем я утверждаю что переносимость GNOME написанного на С завязана на определенном соглашении о низкоуровневых операциях если такое соглашение будет изменено или расширено то ВЕСЬ ! гном обвалится еще раз - весь !!! тогда как другие языки возможно даже не заметят перехода ---- единственное IMHO я подозреваю устойчивое движение к такому вот переходу

PS поэтому я и считаю что в самом начале пректа GNOME было принято плохое решение и что сам проект потенциально опасен

>выкинь из головы нет - речь идет только об интерфейсах

не ты один такой умный. Попытки унифицировать интерфейсы были (ты сам же перечислил). Только почему-то широкого применения эти попытки не нашли (наверное всё упирается в злостных сишников =))

btw: по поводу xpcom - "extern "C" symbols exported from the XPCOM library"

что такое extern "C", надеюсь, не надо объяснять? У тпрочих компонентных технологий те же проблемы =)

а заставить C++-компилятор вызовы в call с arg_list_t...нереально. На самом деле, я подозреваю, что подводных камней гораздо больше. Просто поверь, если бы можно было сделать общий ООП ABI для разных языков _без_ модификации и накладывания каких-либо ограничений на эти языки - его давно сделали бы.

ладно
скоро конец рабочего дня :)
я прекращаю флэйм

Дичь. Слава богу, и гномовцы, и кдешники (даже не смотря на) так не считают. Только fd.o (и некоторые базовые стандарты X) позволяют взаимодействовать и сосуществовать g и k прогам. Причем чем больше вещей стандартизовано на fd.o - тем лучше, полнее это взаимодействие. Посмотрите хотя бы на то, что уже есть - стандарт на винманагер, стандарт на notification area, на menus.

>Получается, что в KDE у меня есть такая гарантия от разработчиков + от дистростроителей. В gnome гарантия только от последних

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

>сильной вертикальной упаковки менюшки в большинстве тем

Не понял высказывания. Поясни, пожалуйста.

>да и сами темы "аляповатые" и "кричащие" своей псевдотрехмерностью, множество ненужных 95% пользователей программ типа "линеек

На самом деле они нужны, но изредка. Много места не жрут. Но можно и не ставить - они в большинстве своем в kdeutils лежат. У debian хорошо все поделено. Жду, когда у других так же поделятся пакеты.

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

>GNOME написанного на С завязана на определенном соглашении о низкоуровневых операциях если такое соглашение будет изменено или расширено то ВЕСЬ ! гном обвалится еще раз - весь !!!

если вдруг сменить calling convention - то обвалится. И не только гном, но и всё на свете =)

имхо, ты сейчас чушь сказал

> - А что, можно было?

Найдено за 5 мин на gnomefiles:

http://home.jesus.ox.ac.uk/~ecatmur/worldclock-applet/

http://glunarclock.sourceforge.net/screenshots.php

http://www.bonnyswan.com/gtubeclock/

Это том в смысле, что свистелки и для гнома можно делать. Только нафиг это все в дефолтный десктоп пихать?

> Это том в смысле, что свистелки и для гнома можно делать. Только нафиг
> это все в дефолтный десктоп пихать?

кто даст хоть какую-то гарантию на качество кода этой свистелки ? куда слать багрепорты или патчи ? не сломается ли интерфейс при переходе с одной версии гнома на другую ?

такими свистелками весь интернет завален и не только для гнома.

> если такое соглашение будет изменено или расширено

Угу. Только этого ни разу не происходило. Потому что гномеры имеют контроль за этим соглашением - и оно достаточно разумно, чтобы существовать уже скоро 10 лет (или уже было 10?). А вот что произошло с КДЕ и прочими плюсовыми фреймворками, когда gcc 3.0 поменял конвенции - помнят все, наверное. Потому кто КДЕ не имеет контроля за этим аспектом. Не то, чтобы он этим "потенциально опасен"...:)