LINUX.ORG.RU

Десктоп приложения GNOME на языке JavaScript

 ,


0

0

Сайт ArsTechnica.com опубликовал статью, рассматривающую наиболее продвинутые средства для создания десктоп приложений на языке JavaScript, интегрируемых в окружение GNOME.

«Недавно мы провели обзор возможностей скриптинга в популярном аудиоплеере для KDE — Amarok'е. Значительное расширение функционала было реализовано с помощью скриптинга, и, как было показано в статье, это оказалось очень лёгкой задачей даже для простого пользователя.

В скором времени на платформе GNOME может появиться схожая функциональность. Два проекта (чуть ниже) могут предоставить набор JavaScript привязок и „встраиваемый“ скриптинг для разработчиков на GTK+.

  • Проект Seed (http://live.gnome.org/Seed) — это библиотека и интерпретатор, работающие над WebKit JavaScriptCore.
  • Проект Gjs (http://live.gnome.org/Gjs) — JavaScript-движок, основанный на Spidermonkey.»

>>> Статья

Слава Шоману!

Чтоб новость никогда не воплотили.

wyldrodney
() автор топика

А я могу десктоп приложения на языке C++! Вот так-то!

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

Не. Только костыль и вило-сипед

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

>Гномеры изобрели плазму?

Пока нет, но всё будет. Подмена будет происходить плавно и незаметно (ближайших минорных релизов 10). До тех пор пока у тебя не упадёт процесс $name и вместе с ним не отвалится рабочий стол, панели волпепер и все все все ты ни о чём не будешь подозревать...

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

> Давайте уже сразу - гном на файрфоксе сделаем и дело с концами

+1

localstorm
()

Нормальные мозиловские эксты в мидори/епифани/эволюшн? Прикольно

Ingwar ★★★★★
()

Нах это надо если есть возможность писать трускринлеты и апплеты на пейтоне?

anonymous
()

Зачем это нужно если есть ОС GNU/Emacs + приложения на elisp для неё?

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

> Давайте уже сразу - гном на файрфоксе сделаем и дело с концами

+1

kost-bebix ★★
()

А мне кажется неплохой идея конфигов на JS. Минимально необходимый синтаксис прост. А если необходимо динамически вычислять значение параметра - то можно использовать функции. Базовый язык не содержит опасных средств, поэтому достаточно добавить нескольно безопасных вещей типа fread (только без пайпов как в перл и без fwrite). С помощью механизма прототипов легко обеспечивается задание параметров по умолчанию, задаваемых администратором. Не совсем понятно, как можно также элегантно предоставить админу возможность ограничения доступных пользователю настроек, впрочем в классических конфигах и этого нет. Такие мысли.

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

>>Так ведь, плазма не падает?!

>падает

а больше у тебя ничего не падает?

F_ract_a1L
()
Ответ на: комментарий от Lumi

> Гномеры изобрели плазму?

нет, это плазма переизобретение скринлетов, которые в свою очередь переизобретение десклетов и карамбы

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

А смысл хранения конфига на JS ?

В чем профит представления user_pref("calendar.view.visiblehours", 12);

вместо [Calendar.View] VisibleHours = 12

?

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

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

Давайте уже сразу - гном на файрфоксе сделаем и дело с концами

+1

rshadow
()

OHSHI~

Удачи гномерам, да.

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

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

Gorthauer ★★★★★
()

Каких только велосипедов не выдумают, лишь бы GUI в виде 9P-сервера не делать...

anonymous
()

То есть из-за того что щас аппаратура увеличивает мощность конфиги в xml стали довольно не трудными, а надо чтоб у всех всё тормозило?? Ну давайте тогда напишем обработку этих javascript-ов на яве а яву машину на mono, а лет 10 ещё проживем не меняя ничего...

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

да и XML в последнее время стила слегка нечитабельными... Теперь еще и скрипты такими же станут :)

Т.е. и раньше такими 99,9% было их таких, но щас это все на уровне генератора кода будет поставлено :)

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

>да и XML в последнее время стила слегка нечитабельными... Теперь еще и скрипты такими же станут :) Т.е. и раньше такими 99,9% было их таких, но щас это все на уровне генератора кода будет поставлено :)

брр, тяжело я понял что написано

st0ke
()
Ответ на: комментарий от legolegs

> А мне кажется неплохой идея конфигов на JS.

Почтенный, вы рехнулись? Чем вы потом автоматически (т.е. с приводом от гуя) будете эти Тьюринг-полные конфиги править? Посмотрите как фуррифокс няшно с ума сходит если ему userprefs.js подпилить руками...

А если их делать с более ограниченной грамматикой, то решительно непонятно зачем там JS. JSON или YAML — я бы понял еще...

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

анонимусы не осилили обновиться хотя бы до 4.1.3? да, не та уже анонимная братия, не та

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

>А смысл хранения конфига на JS ?

Во-первых, конфиги на JS выглядят так:

var Calendar = {
 View: {
  VisibleHours: 12,
  DayNames: ["пн","вт","ср","чт","пт","сб","вс",],
 },
};

Т.е. вложенные секции делаются куда внятнее, чем в классическом ini 
(апачеподобные конфиги - нахрен). Кроме того, есть такая вещь, как
массивы. А профит (помимо стандартизированного вменяемого 
однозначного синтаксиса) - в функциях. Типа такого:
{
  Caption: getusername()+" "+curdate(),
}
Здесь значение вычислится в момент прочтения конфига. А вот другой вариант:
{
  Caption: function () { return getusername()+" "+curdate(); },
}
Здесь определяется функция и её значение вычисляется каждый раз в 
момент обращения к параметру. Это даёт впечатляющую гибкость.
PS да, отпарсить инишник - быстрее, не спорю. Но менять настройки программы в соответствии с изменяющимися условиями на лету, без усложнения программы - это может быть немалым плюсом.

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

Открыл конфиг thunderbird (prefs.js): user_pref("calendar.alarms.eventalarmlen", 7); user_pref("calendar.alarms.eventalarmunit", "days");

Открыл конфиг Firefox: user_pref("accessibility.typeaheadfind.flashBar", 0); user_pref("app.update.auto", false); похожую на твою нотацию нашел лишь в sessionstore.js, и то не такую

>Но менять настройки программы в соответствии с изменяющимися условиями на лету, без усложнения программы - это может быть немалым плюсом.

Чистейший, сферический 4.2 в вакууме.

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

>Открыл конфиг thunderbird

>Открыл конфиг Firefox

Это всё мозила. Думаешь они только на си плохо пишут? Можно закапывать.

Моя "нотация" - это обычный для JS способ объявления хэша. Внутри фигурных скобок через запятую пары идентификатор двоеточие выражение. Выражение может быть любое, в т.ч. другой хэш. Обращаться можно как через точку (a.b.c) так и через квадратные скобки (a["b"]["c"])

>Чистейший, сферический 4.2 в вакууме.

Почтенный, что вам не понравилось? Где 4.2? Что, настройки на лету вот никогда-никогда не надо менять? Или обращение к настройкам через settings.eval("somesection.somevalue"); - это такое невероятное усложнение программы? гконфу, кстати, привет.

legolegs ★★★★★
()

> "Недавно мы провели обзор возможностей скриптинга в популярном аудиоплеере для KDE - Amarok'е. Значительное расширение функционала было реализовано с помощью скриптинга, и, как было показано в статье, это оказалось очень лёгкой задачей даже для простого пользователя.

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

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

>мля, а давайте на баше настройки сделаем, не?

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

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

> гконфу, кстати, привет.

Буду дежурить у биореактора --- передам.

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

>>>Но менять настройки программы в соответствии с изменяющимися условиями на лету, без усложнения программы - это может быть немалым плюсом. >>Чистейший, сферический 4.2 в вакууме.

>Почтенный, что вам не понравилось? Где 4.2? Что, настройки на лету вот >никогда-никогда не надо менять? Или обращение к настройкам через >settings.eval("somesection.somevalue"); - это такое невероятное >усложнение программы?

Не сворачивай в степь. Сворачивай в лес. Ты говорил "Но менять настройки программы в соответствии с изменяющимися условиями на лету, без усложнения программы - это может быть немалым плюсом." - вот это и есть утверждение подпадающее под 4.2. форма хранения настроек с наигибчайшим функционалом не коррелируются, ибо доступ к настройкам производится через некоторый API. В то же время от формы хранения настроек зависит сложность/ресурсоемкость парсера DSL который работает с представлением этих настроек. В этом плане сохранение настроек в виде JS или Haskell (а чо? ваще язык! Тока на нем настройки и хранить!) - суть одинаковый выебон^Wспособ распила бабок^W, но глупый способ, ибо а) тормознее чем туповатый DSL а-ля INI или даже XML b) поболе жрет ресурсов (памяти, CPU) с) Плюсов не вижу = тоже критический минус

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

Вдогонку. eval - порочная функция.

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

>мля, а давайте на баше настройки сделаем, не?

давно таких тупых постов не читал....

mono ★★★★★
()

А вообще интересно это сделать на Google.V8, что бы совсем круто было.

mono ★★★★★
()

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

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

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

Ты чем читал? Каждый параметр может вычисляться заново в момент обращения, если будет задан как функция (а не строка, к примеру).

>В то же время от формы хранения настроек зависит сложность/ресурсоемкость парсера DSL который работает с представлением этих настроек

Что такое ресурсоёмкость? это память и проц, да? Разберёмся с памятью. Бинарный файл парсера загружается в память один раз как любая другая .so'шка. Память расходуется лишь на хранение настроек (чисел и строк в основном) и на накладные расходы. Они, конечно, будут. Сколько-то байт на каждый параметр: поле типа, и, возможно, указатель. А, ну и размер для массивов и какие-то служебные структуры для хэшей. Кошмарный оверхед прямо. Короче, потребление памяти незначительно возрастёт. Основное потребление процессора приходится на исполнение функций, которые 1) нужны не всегда 2) в других системах хранения конфигов тупо отсутствуют. В остальных случаях надо всего-лишь получить значение переменной численного или строкового типа - ничего особо тормозного.

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

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

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

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

Нет - в том что конфиг исполняемый. О чем мечтали лугогвские слиспом сбылось на жабаскрипте:)

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

>Ты чем читал? Каждый параметр может вычисляться заново в момент >обращения, если будет задан как функция (а не строка, к примеру).

Сам понял чего сказал? Если ты не видишь разницы между JSформой и, скажем, INI то поясню на примерах

Пример 1 Пусть настройки хранятся в виде строк a.b.c.d = v имеем очень сложный движок для работы с парсером GetCfgValue(paramName) - функция открывает-читает-закрывает файл настроек построчно и находит нужный парам путем сравнения строк.

Итого имеем для гибкого вытягивания настроек обходимся 1 функцией. Расход памяти - на файловые дескрипторы и временные переменные. Скорость - в теории ограничена скоростью доступа к дисковой подсистеме.

Пример 2 Пусть настройки хранятся в виде JS-кода Имеем: Прикрутить JS-движок (вручную не парсим, так?) Для получения значения выполним пресловутый eval("settings.GetParam(blablabla)")

Что там происходит? Парсится JS (память на парсер и транслятор кода -- ррраз! Скорость исполнения -- дддва!) обращается в память или диск (уже не важно) и вынимает тот же параметр. Плюс сам eval емнип повторно пускает цепочку парсер-транслятор.

На выходе - то же самое значение, только с затратами памяти на JS движок со всеми его объектами-таблицами-переменными.

Где профит, брат?

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

Ну тут какбэ один нюанс... Если основной код приложения тоже написан на JS.

Тогда да, красатень для программиста.

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

>Где профит, брат?

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

Все это на самом деле работает и в других средах, например, в ткаббере конфиг, это обычный скрипт на том же tcl.

В javascript есть json - формат сериализации данных и объектов и легкое использование анонимных функций.

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

> Чем вы потом автоматически (т.е. с приводом от гуя) будете эти Тьюринг-полные конфиги править?

А не надо с приводом от *уя. vi еще никто не отменял.

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