LINUX.ORG.RU

GNOME OS

 , ,


0

0

Вы думали — это шутка? Нет, это реальность. Среди прочего, на конференции GUADEC было предложено закономерно развить идею GNOME Shell и довести проект до уровня операционной системы.

Идея была озвучена Джоном МакКанном из Red Hat (Red Hat’s Jon McCann), который предложил сделать GNOME не коллекцией отдельных проектов, наборов инструментов и передовых идей, а платформой, на которой дистрибутивы и разработчики могли бы базировать свои продукты. Linux должен стать одной из деталей реализации.

Важно то, что мы предоставляем пользователям и разработчикам. Я предлагаю учесть опыт Android, WebOS, MeeGo и других, спрятать Linux под капот и начать делать операционную систему такой, какой мы её себе представляем.

>>> Подробности

★★

Проверено: catap ()
Последнее исправление: MuZHiK-2 (всего исправлений: 3)
Ответ на: комментарий от MuZHiK-2

> С точки зрения конечного пользователя, приложение должно работать нормально из коробки и не доставать пользователя вагоном настроек и чекбоксов, как в кедах - об этом должен думать разработчик, а не пользователь

Предупреждения.

Если вы фанатеете от qt или gtk и/или хотите увидеть здесь их аналог - проходите мимо, создавать «догоняющий» продукт я не намерен, а вы разочаруетесь.

Если вы считаете, что должен существовать только WIMP (window, icon, menu, pointing device), что текущее поведение всех окон и виджетов нужно сохранить - проходите мимо, создавать еще один клон интерфейса от Ксерокса, но с новыми текстурками и цветами я тоже не собираюсь, равно как и изобретать 100500 виджетов к нему. К сожалению, быстро от него не уйти, но нужно пытаться.

Если вы считаете своих пользователей идиотами или овощами - тем более не пользуйтесь, им WIMP освоить сложно, а тут вообще страхи будут.

Если вы любите гном и минимум настроек, а файловый диалог считаете дружелюбным - БЕГИТЕ ОТСЮДА, ВАМ МОЖЕТ БЫТЬ ПЛОХО.

Если вы считаете себя главным, определяющим внешний вид приложения - у меня для вас плохие новости.

Рассуждения (можно не читать)

Вам никогда не приходила мысль «все отлично, но вот этот элемент я бы переставил сюда, а это сюда, а это бы вообще выкинул... Эх, переписать бы...»? Однажды это добешивает и я действительно бегу патчить приложение. Вам никогда не хотелось изменить надписи на кнопках или в диалогах? Бывают такие фимозные локализации, что подвисаешь, а потом переключаешься на английскую локаль и все понимаешь. Благо, многие приложения умеют и локализацию, и перестановку кнопок на тулбарах, а порой и сами тулбары переставлять можно.

Идея.

ВНИМАНИЕ: возможно у меня www-головного мозга, но я вижу за асинхронной стейтлесс моделью приложений будущее.

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

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

Шаг1:

Берем программный интерфейс, скажем int ipc_buildid(struct ipc_ids* ids, int id, int seq);, разбираем его на составные части и на его основе строим форму: 2 числовых поля и вложенную форму для структурки. Аналогично поступаем с сложенными структурами (рекурсивно). Замечу, что тут пока не идет речь о красивых виджетах, однако есть намек на них, пока в виде валидации. Каждая форма может иметь заранее предопределенные данные, средства истории и автозаполнения, поэтому если нужные нам структурки уже были заполнены ранее (динамически или в предыдущей сессии), то вводить их уже нет надобности, пользователю останется только подтвердить отправку данных в функцию и все начнет работать.

Шаг2:

У нас уже есть возможность запустить приложение, но как быть с выводом данных? По умолчанию открываются 2 дескриптора - это stdout + stderr, что в принципе позволит выводить все состояние. Вот только что в выводе? Смесь сообщений для человека, логов, а то и вообще машинный бинарник? А если я хочу видеть выполнение каждого цикла приложения, мне надо будет gdb запускать? А что если заранее определить все переменные/потоки приложения как «публичные» и расшарить их в shared memory, а гуи-оболочка будет брать данные оттуда? Таким образом пользователь сам сможет определить интересующее его, начиная от сообщения «all done» и заканчивая отладочными логами. Больше не будет помарок, когда программист не реализовал прогресс-бар, а пользователь гадает «а не зависло ли приложение?» (в этом месте хочу передать привет автору экспортера m3g для блендера, который работает 2 часа, не грузит CPU, но в конце таки выполняет свою задачу, когда надежды на результат нет). В этом же направлении работает Марк со своими виндикаторами, сюда же можно отнести единое адресное пространство фантома.

Шаг3:

Теперь мы можем запускать и видеть результаты запуска приложения. Но как быть, если вводить системные ID слишком сложно? Как быть, если прогресс-бар только рисует процентики, совершенно не говорящие о времени завершения? Все, что у нас есть - это только поля ввода и вывода, возможно не слишком дружелюбные к пользователю. А давайте их улучшим? К примеру, список файлов в файловом менеджере, несколько колонок вроде «название», «размер файла», «занято на диске» (что актуально для sparse-файлов, которыми у меня являются все торренты). Неплохо бы иметь возможность вводить новые, произвольные данные. Например, «осталось докачать», а источник данных можно записать как «=размер_всего-размер_на_диске». И данные «Примерно ждать», записать как «=осталось_докачать/(сейчас-дата_создания)». Ведь это просто отображение данных, ничего нового тут нет, а значит этим может заниматься и тулкит. А по идее можно пойти еще дальше: создать колоночку «пиры», записанную как: «=some_IPC(&torrent_client, „get_peers“, this.file)» и прямо в файловом менеджере получать актуальную информацию - идеальная вещь для интеграции нескольких приложений в единое целое, никаких сложностей во взаимодействии. Или даже колоночку «комментарии», вроде как «=some_IPC(&myrutrackercoolparser, „get_comments“, this.file)», пускай тянет описание из интернетов. Или рейтинги из IMDB. Ведь приложение фактически должно только отображать данные, а что мешает строить мешапы? Можно придумать еще десяток другой полей, как облегчающий ввод, так и облегчающий чтение данных. В результате получаем все нужное и максимально дружелюбное.

Шаг4:

Данных у нас навалом, все структурированно, осталось только все это подать пользователю. Но как? Разложить в прямоугольничках х11? Через консоль или веб? Можно сделать xmpp/icq/email-бота, IVR-сервис, OSD на мультимедийном проигрывателе, приложение для мобильного телефона и т.д., возможностей масса. Время подумать о расположении наших данных на экране, которые могут быть таблицей, списком через запятую, всплывающим(и) меню или любым другим виджетом-контейнером, и даже менять представление во время работы. Для пущих красивостей можно прицепить типы данных и рисовать не сами данные (в виде цифр), а гламурные прогресс-бары и часики, поля ввода разделить на текстовые, чекбоксы и радиокнопки. Причем прогресс-бар может не только показывать процент выполненного, но и сообщать текущий этап работы приложения, оставшееся время и т.д., а список чекбоксов легко трансформируется в текст для копирования/поиска, в общем все, что только пожелает пользователь. Нужно строить графики по рядам, искать максимальные значения, подсвечивать строки в зависимости от значений, фильтрацию и прочее? Все это может делать пользователь без перезапуска, в рантайме.

Шаги 3-4 предполагается дать самому пользователю, дабы именно он решал, какое приложение он хочет видеть. И как именно видеть. Кому-то милее консоль, кому-то гламурные кнопочки с полупрозрачностью, кому-то все это приятнее засунуть в свой телефон - зачем заставлять пользователя делать что-то? Пусть будет выбор!

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

короче говоря, ты предлагаешь, чтобы все ПО сделать обратно консольным, а фронт-енды пусть юзеры сами для себя клепают? Перспективно. Инновационно.

P.S. капча «Eskimos un»

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

Ну почему сразу консольным? Консольное - это только одно из проявлений интерфейса, можно и консольным, можно и графическим, опционально с 3D-шариками и взрывами. Главное, что пользователь (+мейнтейнер) контролирует представление до последнего пикселя

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

>(+ мейнтайнер)

фуф. обнадежил, а то я подумал, что в «небыдлом» опять окажутся только только сами разработчики (как изначально было в *nix).

Блин, сколь ко же лет придется тогда ждать очередного дебиан стейбл, наступи такое светлое будующее?

И в итоге получим еще более высокий слоёно-велосипедный торт: теперь будет ядро ОС, ядра прикладного ПО, мейнтайнеры опять же со своими несовместимыми между разными дистрибами репами, и по 5-10 видов каждой программы для конечного пользователя (с разными интерфейсами). только как-то совсем не торт...

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

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

интерфейс для слепых через голосовой синтез

или еще какой немыслемый плазмотрон.

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

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

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

> только как-то совсем не торт...

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

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

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

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

Обратная связь с разработчиками конечно нужна, но потенциальных фичреквестов всегда больше, а желания их выполнять у разработчиков меньше, поэтому принцип независимой разработки (не только на уровне «вот тебе код, разбирайся сам», а на уровне SDK к тулкиту, понятного каждому) можно только приветствовать

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

> Шаги 3-4 предполагается дать самому пользователю

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

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

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

Ага, а неленивым деваться некуда, так как все сделано для ленивых. НЕНАВЕСТ.

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