Очередной мега-фронт-енд.
 

Раньше пользовался Centrafuse 2, сейчас 3.1, в общем-то почти устраивает, но раздражают тормоза и есть проблемы с изменением скина. Роадраннер пытался покрутить пару раз, почему-то не вдохновило, не знаю почему конкретно. Разработки здешних пользователей глядел, те же яйца, только вид сбоку - каждый делает то что интересно именно ему, хотя это в общем-то нормально.

Решил в свободное от отдыха время придумать что-то принципиально другое. Вот что получилось:
1. Основа для функциональности - скриптовый язык Lua с JavaScript-подобным строением объектов. В основу философии положил объект node, который имеет родителя, детей, положение, размер, текстуру и прочие нужные-важные поля. Кроме того есть базовый объект root, от которого все растет. Работает это примерно так:
local node = root.createNode({id="Main", visible=true})
node.left = 0 (можно так)
node.top = 0
node.setAttr({width=800, height=600}) (можно и так)
node.onLeftPress = function(this)
(и так далее...)
end
Для мультимедиа-функций будет существовать глобальный объект objects.mediaPlayer с методами (например startTrack) и событиями (например onTrackEnd). Ну и подобные объекты для других глобальных подсистем.
Lua быстра, а учитывая то что при первом запуске скрипт компилируется и лежит в памяти готовым-для-запуска, оно вообще летает.
2. Основа для графики - OpenGL. Решает проблемы с корректным масштабированием, со скоростью отрисовки, но не жрет много ресурсов.
3. Встраивание приложений - возможно будет как базовый модуль (например objects.extApps). Сейчас встраивание готово, в Lua пока не добавлено, но работает корректно и глюков с непрорисовкой главного меню iGo (как в Centrafuse 3.1) нет.

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

Может кто-нибудь покритикует идею, чтобы убрать слабые места, о которых я не подумал?

А чего ж не поюзать xml, раз всё в нодах? И читабельней в разы, и работать с ним приятней, раз уж всё в открытотекстовом виде жить будет.

Ну xml вообще очень статичен. Вот например простейший обработчик кнопки "next track" на моем lua:

local size = objects.mediaPlayer.getPlaylist().getSize()
local index
if objects.storage.getBoolean("Shuffle") then
index = random(size)
else
index = objects.mediaPlayer.getPlaylist().getTrack() + 1
if index == size then
index = 0
end
end
objects.mediaPlayer.startTrack(index)

Такое на xml невозможно.

а чего ж идею критиковать ) выкладывай на общее обозрение, будем ловить баги и критиковать)

Если что-то было задумано сильно не так, то потом в какой то момент придется все сильно переписывать. Уверен на 99% что мне будет лень.

Идеи всегда имеют права на жизнь! Но тебе не кажется, что получится слишком уж сложно?
Я не работал с Lua, но в конечном итоге у тебя получится еще 1 узкоспециализированный язык для разработки чего угодно. Это тот же , что и с++, c#, delphi и т.д. и т.п. но ориентированный на определенный результат.

Это пока идея, и чтобы понять как это все будет выглядеть и насколько будет удобно нужно это увидеть в реализованном виде. В большинстве случаев, никому не нужно, лазить в сурсах проекта, и что-то там менять. Нужен документированный интерфейс, для подключения внешних модулей + легкий способ изменить интерфейс окна. Думаю, как-то так! :)

по поводу идеи, хотелось бы видеть такое(помимо того что уже перечислено):
1. помимо мр3 обязательно поддержка CUE
2. легко создаваемые скины которые могут полностью менять внешний вид программы.
удачи в разработке) готов стать бета тестером под вин7 и ХР

Если говорить о треках - зачем изобретать велосипед? Я бы использовал изобретенный замечательный foobar.
А по использованию xml - я бы в нем хранил интерфейс.
А в приведенном примере я вообще не увидел применения xml.

Насколько я знаком с xml - это язык разметки со структурой дерева, к программированию никакого отношения не имеет, к конфигурации больше. Я хочу сделать все-в-одном, то есть и логика и скин определяются одним языком одинаково. Хочешь поправить расположение элемента - правишь циферки, хочешь логику срабатывания - правишь буковки. Причем логику не в пределах, дозволенных базовой программой, а гораздо шире, потому что базовая программа на себя много не берет, а отдает скрипту.
Насчет фубара подумаю, но пока bass как обычно.

BASS почти у всех есть. Лучше SDK Foobar2000 посмотри.

Тем более что... :)

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

Поддерживаю идею проекта. Если не устраивает Centrafuse и другие, то может выйти из проекта действительно что-то новое и толковое.

Да не будет у этой идеи продолжения...всё что описал автор обычные классы в С, делфях и тд. Помимо это нужен ява-машина. Это тотже хер что и Net Framework или как там её...быстрые вещи делаются только на API под винду. Я програмлю на делфях (7 версия еще) и если использовать все её классы и наследия обычное ОДНО окно без ничего ваще имеет размер порядка 700кб(поздние дельфи еще больше)...таже хрень справедлива и для Си билдера. Если юзать API (писать надо ручками), а не городить из готовых компонентов то размер того же ОДНОГО окна 20-30кб. Для примера программерам на делфи смотреть KOL по моему Юрия Кладового.

ЗЫ. Делал диджейскую программу, точнее сам движок видео-аудио с помощью COM объектов, то сама библа этого движка получилась около 200кб, что есть гут. А вот интерфейс лепил из скин библы от almdev.com. Сразу тормоза при перерисовке, когда много разных объектов на форме (окне). Для примера приведу туже аудио библу BASS...размер её видели??? то то порядка 120 кб...вот она действительно летает. А не то гавно как центрифуга 3 и ей подобное.

Не надо сравнивать размер бинарника на диске с развернутым в памяти исполнимым модулем. Это разные вещи.

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

А мне кажется что недавна, хотя по словам о Дельфях7 можно судить об обратном... Но не в этом суть топика, не будем автору мешать творить, ибо он, в отличие от нас, что-то делает, а это уже заслуживает уважения.
офф: можно написать пустышку с бинарником в мегабайты, которая будет кушать килобайты памяти, и наоборот. Не об этом здесь, не об этом.

Ну когда кажется...сами знаете что надо ))). Тут много кто-то что-то делает, а толку практически ноль...нужно здраво оценивать свои силы, а не так - слышал звон да не знаю где он. Я уже поначалу вижу, что идея дальше слов не пойдет. Хотя посмотрим...

Как то уж больно бескомпромиссно.
"Все, что описал автор" - это не обычные классы. Никакой явы, никаких net фреймворков нет, есть две дллки луа и басса.
Сейчас готова базовая функциональность дерева объектов, рендер этого дерева и простейшие события на нажатие и отпускание кнопок мыши. В принципе можно уже нарисовать экраны скина и перемещением по ним (все это делается в скрипте конечно же). С фотошопом не очень дружен, поэтому нарисовал только один экран с тремя кнопками.

Пока написано на коленке, но могу выложить если такое интересно.

Выкладывай. Интересно! :)

Хм, ну это то же самое что ничего! Ну а то, что ты еще сохраняешь картинки всего окна и из него вырезаешь нужную область - плохо. Возможно так работает Lua, хз. Но пока не вдохновило. Ждем продолжения.

А я и не говорил, что это "что-то".
Вырезаю нужную чтобы проще было из фотошопа кнопки переносить в скин. Уже сейчас можно делать как угодно - одна картинка на один объект, одна картинка на несколько объектов, одна картинка на весь экран. Другой вопрос, что установка текстуры может быть медленной (в opengl), и если этих картинок очень много, то лучше объединять в одну и вырезать. Хотя в масштабах пары сотен полигонов это скорей всего не важно.
Луа вообще работает никак - это просто компилятор скрипта, сама по себе она ничего не умеет.
Продолжаю наблюдение :)

Как успехи? Дело идет? Или пауза?

Как обычно, дела-заботы. Руки не доходят...

Может уже и поздно критиковать и автор сам все понял, но раз просили...

Насколько я понял из написанного, автор просто вдохновился LUA, а LUA - всего лишь еще одна технология программирования с использованием конфигураций, т.е. вместо LUA можно использовать и xml и ini файлы и UML, spring и т.д. и т.д. сути не меняет, меняются подходы.
Все относительно... По сравнению с вызовом конструкторов с переданными параметрами "зашитыми" в код классов в C, C++, Pascal и т.д. Lua просто самый последний тормоз :smile1: Но она не для этого и при правильном использовании ее быстродействие не имеет значения, при неправильном это постоянные тормоза, которые так или иначе будут исправлены до использования.
Ха-ха :laugh2: И в чем плюс? :smile1: Что пользователи которые не хотят программировать должны будут копаться не в 20-100 настройках, а править целый скрипт или скрипты? да еще и без отладки и как я понимаю без подробного логирования? :smile1: Любите искать более менее трудные ошибки в программе без дебагера и логов? :laugh2:
А те кто хотят программировать не смогут, т.к. часть исходников (движок) закрыты (с таким успехом можно считать, почти любую программу, с открытыми исходниками, ведь настройки можно менять :derisive: ). Да и вообще, что же мешает сделать проект c/без LUA и предоставить исходники раз это такой большой "+" :smile1:
Популярные графические движки, пока слава богу, не жрут память!:smile1: Память жрут плохие алгоритмы и ошибки :smile1:
В принципе, конечно идея более гибкого, внешнего конфигурирования, фрон-енда, это хорошо, но только когда уже есть фрон-енд, система логирования работы фрон-енд и хорошая документация, а без этого смысла нет.
И на завершение, есть проект evilcpc, который решает данные задачи (конфигурирования) менее гибко, используя технологию плагинов (не радуемся, как я понял, использовать его из коробки как фронт-енд для стороннего ПО нельзя).

:) прям настальгию вызывает:)))

В подписе найдете проект myfrontend. Суть проекта примерно та же. Вся конфигурация лежит в xml в нем же полноценно поддерживающейся JavaScript. Поддерживается отладка. Модульность. Технология источников данных. Есть возможность быстрого расширения доступных нативных классов. Есть возможность создания внутренних объектов на скриптах.

Встроенная поддержка bass, wifi, модемов, tcp/ip сокетов, COM портов и т.п.

Сам пользуюсь уже пару лет.

В общем никому Ваше конфигурирование нафиг не нужно. Скажу как есть. Всем нужно готоое решение.

А те кто могут что-то делать... Как бы это сказать... Им гордость не позволяет делать на чужом :)))) делают свое с нуля.

Т.ч. удачи конечно:)))