Лидер сообщества Ubuntu представил стек для унификации GUI приложений

>> мля лемминги, поймите наконец Python - обертка вокруг C/C++ фнукций, никаких существенных тормозов она не добавляет...

Напиши сначала на нем что-то посложнее Hello World, да. В версии 2.4-2.5 у меня по сравнению с Си даже на олимпиадных числодробилках была вполне заметная разница. Хотя кода там было - 60 - 100 строк и никакого ООП.

вспоминаю задачи из олимпиад .. неудевлён :-)

GUI там нетребовалось , а вот огромное количество вложенных друг в друга цыклов (особено если задания выполнял «троешник» как я) с перемусоливанием одних данных с другими — да — много :-)

и да кстате — ООП на олимпеадах — плохо использовать не потомучто оно там якобы не нужно, а потомучто ООП помогает делать качественный код , а на олимпиадах нада побыстрее делать «скрипт» , а не 2 дня придумывать «модульную архитектуру» :-) .

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

Ну так чего ты ждешь? Беги.

Ты смари сколько быдл^W трололо наприехало сегодня.

> Ну все ж кричат, что он не тормозит.

Он, разумеется, «тормозит». Просто для десктопа это не критично ни разу. Прикладные приложения можно и нужно писать на высокоуровневых языках со сжатым синтаксисом и автоматической памятью.

А как насчет не только С++, а еще поддержка ООП в языках где ООП нету, в скриптовых языках и прочем. Добавьте сюда FreePascal или еще что-то там.

GObject - универсальное ABI для всех языков.

> Пока живут кривые поделки его использующие, она будет жить.

Ну вы сообщите нам, пжалста, какую вы можете припомнить «тормозную кривую поделку» на питоне.

У меня Mercurial - летает не хуже Subversion, Deluge - летает не хуже Transmission (и горрраздо лучше Vuze). Что я делаю не так?

А особенно студенческие олимпиады. Там еще меньше времени. В итоге код еще хуже.

>на задротов со слакой и иксмонадами никто ориентироваться не будет

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

> Ты смари сколько быдл^W трололо наприехало сегодня.

В зеркало взглянул?

> GObject - нужен для OOP ABI между языками.

и сделают одну бинарносовместимую конвенцию вызова с поддержкой ООП.

Майкрософтовцы хорошую идею ведь предложили, как ни крути - P/Invoke. В большинстве случаев не требуется из низкоуровневого языка вызывать высокоуровненвые методы. Обычно наоборот. И тут приходит на помощь P/Invoke. Бинарная совместимость ить нужна для легаси в основном. В плане реализации наработки есть у моны - бери, используй. Нет ведь, костылят-костылят...

Также прямое решение - это разные бэкенды для легаси-проектов. Т.е. имеем ява-подобную библиотеку классов, а транслятор, в зависимости от бэкенда для ГУИ, транслирует вызовы методов в ГТК, КДЕЛИБС, или ещё какое гниющее поделие. Когда легаси вымрут и десктоп для линукса унифицируются, можно иметь уже собственную реализацию.

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

акое прямое решение? Прямое решение - это когда разрабы MSVC, FreePascal, GCC/g++, SunStudio, intel C++ возьмутся за руки и сделают одну бинарносовместимую конвенцию вызова с поддержкой ООП.

Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

> То есть, для унификации GUI он попросту предложил все, что не GTK/Gnome — «фтопку»? Какое простое и оригинальное решение, вот это умный дядя, пипец!

Конечно умный. Понимает, что распыление сил - есть конкурентный проигрыш.

А не пошел бы он (думаю, он сам догадывается куда)?

Потопайте ногами, поплачьте. Компания каноникал забыла с вами посоветоваться, ай-яй-яй.

>и да кстате — ООП на олимпеадах — плохо использовать не потомучто оно там якобы не нужно, а потомучто ООП помогает делать качественный код , а на олимпиадах нада побыстрее делать «скрипт» , а не 2 дня придумывать «модульную архитектуру» :-) .

Не скажу про качество, но мне просто не попадалось таких задач, в которых можно было бы получить какой-либо профит от применения ООП. Единственное, STL иногда используется, различные очереди и т. д.

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

В каком месте? Тут, имхо, дело привычки, ибо если человек привык писать аккуратно, давать осмысленные имена переменных, не прибегать к неоднозначным и некрасивым конструкциям, не производить ненужных действий, он всегда будет так писать. Хотя то, что стихия другая - да, согласен.

> А как насчет не только С++, а еще поддержка ООП в языках где ООП нету

Зачем?

в скриптовых языках и прочем.

А, понятно. Еще один мечтатель.

GObject - универсальное ABI для всех языков.

GObject головного мозга.

> Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++)

Pascal уже есть.

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

Виртмашины сильно помогают в отладке, в диспетчеризации и в сборке мусыря. Другое дело, что они бывают плохие и медленные (Java) и хорошие и быстрые (Lua, новые движки JavaScript). Надо быстрые виртмашины.

Ну и, попробуйте Haskell.

В зеркало взглянул?

какой-то ты унылый тролль, ничего окромя «отражения» не выучил? :)

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

ООП помогает в диспетчеризации и модульности. Диспетчеризация нужна для обобщённого программирования (которое опять-таки помогает с модульностью).

Так что чем больше проект - тем важнее модульность и тем больше можно профиту получить с ООП, это факт.

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

> какой-то ты унылый тролль

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

> Почему в списке нет Mono? :-D

Его оставили для серьезного етерпрайза, десктоп и на питоне перебьется.

>> возьмутся за руки и сделают одну бинарносовместимую конвенцию вызова с поддержкой ООП.

Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

низкоуровневые библиотеки, самое ядро, вообще не должны использовать ООП. ООП должен быть уже на уровне биндингов

> В плане реализации наработки есть у моны - бери, используй.

Этого не будет, причины известны.

. Т.е. имеем ява-подобную библиотеку классов, а транслятор, в зависимости от бэкенда для ГУИ, транслирует вызовы методов в ГТК, КДЕЛИБС, или ещё какое гниющее поделие.

Вы плодите сущности (еще одну либу) на основе личной уверенности что Gtk или Qt гниют. А они нормально поживают. Унифицированность - враг конкуренции. И то и то - хорошо.

Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

Как в нативе сделать garbage collection? Вирутальные машины сделаны по причинам. Почему они большие? Потому что они универсальные - Java решат любую проблему программирования. Это полноценная платформа, на котором можно написать почти что угодно. Почему их такими большими сделали? Потому что корпорации, которые над ними работали не могут позволить себе тратить деньги на легковесные поделки, которые ничего не умеют. Они хотят сделать плафторму, про которую можно сказать «Она умеет все». Причем на всех платформах, быстро, безопасно и легко. В итоге раздулись они по размеру в ОЗУ, хоть и быстро работают.

> какой-то ты унылый тролль, ничего окромя «отражения» не выучил? :)

Ну от вас пока поступило только несколько неаргументированных пуков в лужу на тему «ай яй тормозной питон».

По унылости вы лидируете.

В каком месте? Тут, имхо, дело привычки, ибо если человек привык писать аккуратно, давать осмысленные имена переменных, не прибегать к неоднозначным и некрасивым конструкциям, не производить ненужных действий, он всегда будет так писать. Хотя то, что стихия другая - да, согласен.

вобщемто я имел ввиду архитектуру кода , а не названия переменных\функций...

...хотя конешно и это важно

хотел тут написать большой абзац , но передумал . так как что рассуждать на пустом месте :-)

> что они бывают плохие и медленные (Java)

Иди сюда и смотри http://shootout.alioth.debian.org/

Много там жабку обгоняют?

Deluge - летает не хуже Transmission

Я понимаю, что у _тебя_ все работает, но ты не один. На ЛОРе сообщения о зависании Deluge на старте проскакивали. Тоже самое случалось у меня на ноутбуке, хотя на десктопе работало вменяемо(версии пакетов в дистрибутивов были одинаковые). Но жирнота новой версии меня добила и на Transmission я таки переполз обратно. Одно время вспоминаю веселье с gajim, который очень любил съедать CPU. Учитывая, что ничего pyGTK'ашного на десктопе с ноутом сейчас не используется и названия того, что когда-то тестировал не вспомню, разводить холивар не буду. Ну и выше писал - мой первый пост не более чем сарказм.

>> Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++)

Pascal уже есть.

Угу, только комьюнити под него в линуксе довольно ограниченное количественно и качество, да к тому же «си-подобный синтаксис» уже стал стандартом де факто

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

С каких это пор для сборка мусора незаменимо наличие вирт. машины? ;) Насчёт отладки спорновато. По-моему, одинаково процесс идёт.

> Как в нативе сделать garbage collection? Вирутальные машины сделаны по причинам.

http://www.digitalmars.com/d/

Почему они большие? Потому что они универсальные - Java решат любую проблему программирования.

Что такое «проблемы программирования» и как их решает Java и почему их «не решает» любой другой Тьюринг-полный ЯП без ВМ?

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

Нет. Потому что компания Sun и Гослинг в частности - феерические балбесы. А команда .Net тупо скопировала значительную часть их ошибок.

Никаких принципиальных причин делать ВМ столь монструозной и монолитной не было.

Очень круто. PyGTK для создания графических приложений на основе Сишных библиотек гнома. Gstreamer - тоже неплохо (в чем вообще проблемы с ним? И какая альтернатива?)

Vala может быть неплох, но знают его пока немногие, в отличие от связки PyGTK. В любом случае, все это лучше, чем Mono.

А главное - судя по всему, они сделают некий SDK, отполируют к нему документацию, и жизнь удастся.

По поводу KDE (в смысле, что эта спецификация вообще положила на него болт) - печально, но ожидаемо. Весь мир KDE-приложений крутится вокруг самого KDE и ряда приложений для него (Amarok, Koffice, digiKam), и тут Ubuntu просто не сможет иметь какого-либо влияния на положение вещей. Очевидно, что в свое время Шаттлворт вкладывал свои миллионы нефти в KDE именно чтобы этого не произошло, но сейчас мощное чувство, что Kubuntu отпадет вслед за Xubuntu. Уже для Lucid Lynx из двух с лишним сотен blueprints Kubuntu касаются лишь 8. Видимо, от Kubuntu не отказываются просто потому, что нуждаются в поддержке Qt-приложений.

Ну а XFCE и прочие - пардон, но они официально не поддерживаются Ubuntu уже.

По теме:

Ground Control порадовал

http://doctormo.wordpress.com/2010/01/27/ground-control-demonstration/

Вкусно. Кому не нравится, можно не юзать

> Иди сюда и смотри http://shootout.alioth.debian.org/

Много там жабку обгоняют?

Надо понимать, что на шутауте тестируют числодробилки. Числодробление в жабе разогнали на ура, факт. Это всё очень мило и приятно. Но от попыток использовать на десктопе жабные приложения (Vuze, Eclipse, Netbeans) меня подташнивает до сих пор (2 Ггц Core2Duo, 3 Гб памяти).

Жаба быстро работает. Она очень медленно всё подгружает. Ну и с гуями там всё не сильно радостно.

Язык программирования Python;

Закопать и не выкапывать, ибо ненужный велосипед, причём тормозной!

Десктоп окружение GNOME;

Правильно, всякие недокеды не нужны.

Графический тулкит GTK;

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

> Что такое «проблемы программирования» и как их решает Java и почему их «не решает» любой другой Тьюринг-полный ЯП без ВМ?

Вы видели библиотеку классов Java SE? А Java EE? А JavaFX? Когда кто-то говорит, что Qt - самая мощная платформа, я смеюсь

Этому топику место в Палате мер и весов, в качестве идельной провокации флейма.

Я восхищаюсь целостостью и завершенностью сказанного. Здесь есть все: и питон, и ГТК, и Гном, и упоминание ЛАМП в положительном ключе.

Господа. После этого топика на главной всякий троллинг утратил смысл. Мир никогда не будет таким, как прежде.

> А главное - судя по всему, они сделают некий SDK, отполируют к нему документацию, и жизнь удастся.

Самое главное - норм IDE. Вот где у Qt преимущество - QtCreator

> ну хотя бы Mono vs Vala vs Python, или JACK vs GStreamer. А тут - обычное уныние.

Оцени, сколько тут людей знают все эти слова одновременно, и сколько из них захотят устроить срач, а не отделаются парой замечаний по делу...

Недождешься, короче... :-)

> Как в нативе сделать garbage collection? Вирутальные машины сделаны по причинам

Так же сделать, как и сделаны виртуальные методы в С++. Программа хранит в себе небольшой прекомпилированный оптимизированный набор внутренних структур, которые располагают информацией о типах (в с++ же есть RTTI). Типы хранят набор смещений, по которым хранятся ссылки на объекты в куче. Каждый объект хранит в себе ссылку на такую структуру-тип. Только этого уже достаточно для реализации compacting gc. В плане стека для скорости можно сделать исключение, и там сделать partly-консервативный GC, т.е. все сканируемые значения стека считаются ссылками по умоланию и в результирующей сборке by compacting gc игнорируются.

Настраиваем опции. У вас много ОЗУ? Делаем -Xbatch и вперед.

С гуями в жабе - очень мощно. Swing - хоронит и QtGui, и Gtk, и Cairo. Если вам не нужна его мощность, то можно юзать в жабе байндинги. Приложения на java-gnome очень легковесные. Я пробовал.

> да к тому же «си-подобный синтаксис» уже стал стандартом де факто

Сам факт предложения питона в данном стеке говорит о том, что «си-подобный» быдлосинтаксис уже давно не догма.

С каких это пор для сборка мусора незаменимо наличие вирт. машины? ;) Насчёт отладки спорновато. По-моему, одинаково процесс идёт.

Нативный код отлаживается только когда к нему отладчик присосан. Код в виртуальной машине ВСЕГДА работает в «отладочном» режиме. Если у пользователя на другом конце планеты что-то где-то упало - он заведомо сможет предоставить вменяемый трэйсбэк.

С каких это пор для сборка мусора незаменимо наличие вирт. машины? ;)

Где я писал «незаменимо»? Помогает. Перемещающий сборщик без ВМ будет писать довольно затруднительно.

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

вобщемто я имел ввиду архитектуру кода

Как бы я и это имел в виду. И модульность, в том числе. Некоторые куски алгоритма часто бывает, например, выгодней вынести в функцию, чем морочиться, когда придется их немного поправить.

// так как что рассуждать на пустом месте
Воистину. Тред не об этом.

> С гуями в жабе - очень мощно. Swing - хоронит и QtGui, и Gtk, и Cairo.

Мне пофиг кого он там хоронит. Я как пользователь говорю. Все жабные приложения уже выглядят ещё не мерзотно (5-10 лет назад), но всё ещё неуютно.

Впрочем, фаерфоксовый XUL тоже не подарок, но люди ж как-то пользуются.

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

> Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

ты только что написал про D. уборка мусора там тоже есть, кстати. Это тем, кто начинает кричать, что нельзя организовать ГК без виртуальной машины.

питон не нужен

жестрим тоже не нужен.

В остальном разумно.

> Все жабные приложения уже выглядят ещё не мерзотно (5-10 лет назад), но всё ещё неуютно.

Мне Nimbus больше нравится, чем стандартная тема Ubuntu и темы в Windows

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

Опять мимо :) -rdynamic (в ELF'е, насчёт PE не знаю) + backtrace_symbols_fd + сигналирование тебе в помощь. Когда моё поделие на си сегфолтит, оно рисует полный стектрейс. Для этого виртуальная машина опять не нужна.

Какие ключи именно вы для этого указываете? Хочу попробовать

> Все эти свистелки и перделки реализуемы в нативе, причём с оверхедом максимум в пару сотен кб машинного кода.

Ну реализуйте. Потом заметите, что у вас по факту получилась собственная ВМ.

> Когда моё поделие на си сегфолтит, оно рисует полный стектрейс.

Даже когда оно затерло стек вызовов? Сказки.

Ну хотябы когда не затерло. Это тоже хорошо. Устал запускать для этого под valgrind. Программа тормозит сильно.

>> Нет, прямое решение это чистый, вылизанный синтаксис джавы/сишарпа (а не монструозный ужас С++) плюс компиляция в натив минуя всякие виртуальные машины.

ты только что написал про D. уборка мусора там тоже есть, кстати. Это тем, кто начинает кричать, что нельзя организовать ГК без виртуальной машины.

забыл упомянуть «стройная, унифицированная библиотека классов», чего не скажешь о Д.

> Гном ... не вылетит ни с того ни с сего ... в отличие от.

Это потому, что он не на С++ написан.

>Гном же, несмотря на некую «разрозненность» компонентов что ли в сотни раз приятнее в плане юзабельности и стабильности.

В GNOME 3.0 это «исправят». Или как принято GNOME3 != GNOME 3.0 лол?