> да чего уж там, пусть плазму целиком копируют. с плазмоидами.

Вы чо, там с мака тырят, не путайте :)

Скоро кеды и гном станут похожи как близнецы))

Вот этого боюсь БОЛЬШЕ ВСЕГО.

>>Зачем? Clutter же без вопросов круче Qt для таких штук :-).

Чем круче? Не флейма ради.

> Приборная доска написана на JavaScript
А-ха-ха... это п-ц.

Против JS я ничего не имею, а вот перегружать итак самодостаточное DE я считаю глупым. Но видимо сейчас так модно...лепить на экран всякие виджеты.

Я вот поразмыслил... Идея с JS - хорошая. Простой ЯП с невысокой производительностью, но большой простотой будет управлять высокопроизводительными и аппаратно ускоренными с самого начала разработки либами на С. Итог: и приложения писать легко и они быстро работают. Все счастливы кроме троллей. На данный момент.

Но через время обычно людям начинает нехватать простых средств и начнуть городить тулкиты. Вот тут появляется проблема - ГДЕ их городить. На уровне С или на уровне JS. Если на уровне С/Vala - все счастливы, рай на Земле в мире IT продолжается. А если на уровне JS - то может случиться фейл, тормоза и т.д. и т.п.

Гному нужна одна концепция построения приложений, которая будет хорошо раскрыта в доках. Описания взаимоотношения динамических языков и языков написания библиотек. Строгая рекомендация на чем писать так называемую «бизнес-логику», а на чем тулкиты. Какие-то рекомендации по стандартному шаблону проекта, или хотя-бы макросы для CMake. СТАНДАРТНЫЕ.

Сделали бы How-TO: Building Gnome Application. Издание 2010 года, в котором есть примеры Clutter+JS проектов, как они делаются от начала до конца, от пустой папки, до пакета deb, ебилда или даже Windows приложения. Как туда безболезнено впилить GConf.

Даже бы не помешал официальный, поддерживаемый в первую очередь ЯП для прикладного уровня приложений Gnome. Python или Vala полне подошли бы. Только не крутится вокруг них весь мир Gnome, а должен был бы.

Гному некоторых вещей нехватает. Не нужен «напиши приложения в два клика мышей» в стиле MS, и не нужен 100-tier распределенный мегоынтерпрайз, как в Java, но чуточку всего этого бы не помешало. А так ни ынтерпрайза, ни скорости разработки. Разве что стабильность, правильность дизайна библиотек.

Радует то, что этим занимаются. Сделали buildj и чистят Gtk. Хочется видеть совместимый и стандартизированый Gnome 3. Я был бы счастлив если бы даже ничего не поменяли, а просто вычистили библиотеки и сделали стандарт Gnome Application, сделали Gnome IDE, и систему сборки по типу Maven. Больше ничего не надо. А новое нужно уже делать на этой базе.

By the way, по теме не могу ничего сказать. Мне не нужно «пространство для быстрого размещения фотографий, аудио и видело, текста, заметок и т.д»

> JavaScript

GObject Introspection

Clutter

*facepalm*

> будут отличаться только названиями и языком, на котором написаны.
А что , javascript бывает разный?

> а чего вообще за мода пошла на js писать для десктопа?

А чего вообще за мода пошла с серьезным видом «кидать предъявы» и вообще дискутировать на темы языков программирования, ни черта не разбираясь в теме? Вас таких тут набралось как минимум с десяток, как я погляжу.

JavaScript в сегодняшнем состоянии - мощный динамический объектно-ориентированный язык с некоторыми удачными заимствованиями у ФЯП. Обе реализации, используемые в GNOME (GJS и Seed), снабжены JIT-компиляторами. Всем здешним крикунам о якобы «медленном JS» рекомендую сходить на Shootout и удаивиться. JavaScript в GNOME, на минуточку, одной левой уделывает Python, в котором JIT нет и не предвидится, назло камраду tailgunner.

Единственной объективной претензией к JavaScript может служить упрек в динамической типизации. Но JavaScript в GNOME используется именно там, где есть место его динамизму - в динамической, сценарной части программ. Всяческий низкоуровневый хардкор - это удел С или же более современной Vala. Итог - гибридные программы, максимизирующие производительность программиста и минимизирующие число ошибок. Это весьма современная парадигма, называемая «polyglot programming», и разработчики GNOME были настолько прозорливы, что еще 12 лет назад заложили для нее мощнейший фундамент в виде GObject.

А кое-кто (не будем показывать пальцем на KDE) вынужден до сих пор жевать колючки С++.

Все правильно сказано. Только

Всем здешним крикунам о якобы «медленном JS» рекомендую сходить на Shootout и удаивиться

Единственной объективной претензией к JavaScript может служить упрек в динамической типизации.

Динамическая типизация == медленно. НО, медленно по сравнению с C, C++, Java, но никак не обязательно медленно в целом. Пользоваться можно и нужно. Тем более в такой связке как связка с Clutter получается очень удачно и легковесно. Как раз в снарной части. Но если на JS начнут городить многослойные тулкиты - все RIP.

А что если сделать для Clutter JS интерфейс source-совместимый с jQuery. Будет нужно кому-то

> Но если на JS начнут городить многослойные тулкиты - все RIP.

Слава Б-гу, с головой у разработчиков вроде все в порядке, никто не будет лепить системный код на динамическом языке. Взять тот же фигурирующий в новости Mx (как хороший пример нового «слоя») - там не найдется ни одной строчки на JavaScript, он написан на pure C.

Кстати,

Динамическая типизация == медленно... по сравнению с Java

Вы слыхали, что в Java 7 будет invokedynamic?

Вы слыхали, что в Java 7 будет invokedynamic?

Слыхал. А в JavaScript будет invokestatic? ) JS - только динамический, а вот теперь Java (или JVM) сможет стать динамической, но пользоваться этим не обязательно.

>одной левой уделывает Python, в котором JIT нет и не предвидится

Э?
http://code.google.com/p/unladen-swallow/wiki/ProjectPlan
http://psyco.sourceforge.net/introduction.html
http://codespeak.net/pypy/dist/pypy/doc/jit/index.html

А в JavaScript будет invokestatic?

Он МОГ быть, но увы, нехорошие люди из MS, Apple и Yahoo зарубили ES4 на корню. Теперь есть надежда на ES Harmony, посмотрим, что там сделают.

Теперь и гном скатывается сами знаете куда, куда бежать с корабля?

Я бы вообще за какой нибудь Java Minimal Desktop Edition. Спецификация легковесной JVM и библиотеки классов без всяких сложных вещей, которые часто болтаются в воздухе и кушают память.

гном будет падать?

гном катится в СГ.

Как кедеешник. у которого на столе из виджетов только фотка любимой - скажу: «Ну вы блин нашли, что скопировать...!»

KDE4 — это Gnome5 уже сегодня!

>Единый стандарт на плазмои^W виджеты и правда не помешал бы.

+1

>Я бы вообще за какой нибудь Java Minimal Desktop Edition. Спецификация легковесной JVM и библиотеки классов без всяких сложных вещей

можно подумать, что ява тормозит из-за большого classpath

>А кое-кто (не будем показывать пальцем на KDE) вынужден до сих пор жевать колючки С++.

4.2, у Qt, kdelibs и плазмы куча биндингов к динамическим языкам

> И да, афтор - школьнег? Иначе, где он последний раз видел такую тетрадь в крупную линейку...

нет, просто автор не студентег, у него уже дети в школу ходят.

1. Java не тормозит
2. Java долго загружается из-за JIT по БОЛЬШОМУ classpath
3. Java жрет ресурсы ОЗУ из-за большого classpath, в котором загружается много ненужных для конкретного приложения классов с самого начала.

Это так, вкратце, не вдаваясь в подробности. Пускай даже обычно загружается 5% от всех классов из classpath. Это ДОХЕРА.

на мак

> А кое-кто (не будем показывать пальцем на KDE) вынужден до сих пор жевать колючки С++.

У KDE тоже есть биндинги к JS. И не только к JS.

>Java долго загружается из-за JIT по БОЛЬШОМУ classpath

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

>на мак

он уже давно там:)

> А что если сделать для Clutter JS интерфейс source-совместимый с jQuery. Будет нужно кому-то

товарищ видел возможности jQuery сбоку? или я чего-то не улавливаю?

> SideBar, очевидно же

http://live.gnome.org/GnomeShell/Sidebar :)

Ее идея, правда, мне не кажется хоть сколько-нибудь удобной, но... на моем 16:9 широкоформатнике можно будет попробовать.

> А кое-кто (не будем показывать пальцем на KDE) вынужден до сих пор жевать колючки С++.

в kde подобные перделки даааавным-давно можно ваять хоть на ruby, хоть на python, хоть на javascript. это так, jfyi

вопли хомячков, видевших^W знающих, что javascript есть где-то там в браузере восхищают

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

Простые консольные приложения могут прилично кушать ОЗУ, хотя ситуация намного лучше с -client. Все равно скорость загрузки несравнима с С++ приложениями. А скорость работы вполне себе сравнима, и иногда Java быстрее, хоть и в меньшинстве случаев.

> У KDE тоже есть биндинги к JS. И не только к JS.

Собственно,

http://kde-look.org/index.php?xcontentmode=77

Более того, что мне нравится в KDE в этом плане, так это то, что в само DE встроено приложение, позволяющее производить поиск новых плазмоидов (а также тем, обоев etc) и устанавливать их, не сходя с места и не изучая kde-look.org, не занимаясь ручным скачиванием, распаковкой в нужную директорию etc.

http://userbase.kde.org/images.userbase/thumb/4/4c/Plasma_InstallingPlasmoids...

Надеюсь, в Gnome предвидится нечто подобное.

> кто-нибудь догадается что можну пускать апач и писатьвсё на ПХП.
Писать на php вирусы и трояны, Ваш хомяк заблокирован, для разблокировки отправь sms на ....

> Как только браузер окончательно интегрируется в десктоп кто-нибудь догадается что можну пускать апач и писатьвсё на ПХП.

для php есть (btw, были) биндинги для gtk+. апач не нужен :)

> одной левой уделывает Python, в котором JIT нет и не предвидится, назло камраду tailgunner.

ЩИТО? Очень даже предвидится (правда, в Python 3.3): http://www.python.org/dev/peps/pep-3146/

Более того, может быть и второй JIT: http://morepypy.blogspot.com/2010/06/pypy-13-released.html %)

Да и старый Psyco еще жив.

сомневаюсь, что оно будет удобно.

Тоже как KDE-шник скажу гномерам: вы хотите странного.

> Динамическая типизация == медленно. НО, медленно по сравнению с C, C++, Java

Современный tracing JIT умеет извлекать статическую типизацию из программы, написанной на динамическом языке, если сама программа не написана калекой с динамической типизацией головного мозга.

> Приборная доска написана на JavaScript

Петька и Чапаев установили Гном:

- Петька, приборы!

- 120!!!

- Шо «120»?

- А шо «приборы»?

Посмотрел что это. Но так и не понял в чем польза....?

>очень даже неплохо.Есть идея - воплоти ее!!! правильно делают.Пусть хоть с Кде ,хоть с Винды .Главное ,что есть! И перед отправкой нам,авторитетным судьям,надо его отладить или попросить помощи у нас

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

Гному остается только догонять.

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

>вот хотелось бы у кдеешников узнать сколько подобных виджетов они используют?

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