Графический пользовательский интерфейс

[Aether]

Добрый день.

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

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

Также иногда посещает идея попробовать реализовать в Linux на базе fbdev и протестировать с пробными приложениями, но я ещё не настолько компетентен.

[Алексей++]

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

Затраты мощности на перекрытие окон ? Это ты серьёзно ?

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

[RXL]

Мне наиболее комфортно работается под Linux с множеством десктопов. Последние 4 года на Ubunta 12-14-16. Настраиваешь 4-8 десктопов, располагаешь по одному приложению на десктоп и горячими клавишами мгновенно перемещаешься точно в нужное приложение. Редко используемые приложения сваливаю на один десктоп и переключаюсь обычным Ctrl+Tab (но в рамках одного десктопа). После этого дома в винде страдаю, когда число окон переваливает через 3.

[Aether]

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

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

Затраты мощности на перекрытие окон ? Это ты серьёзно ?

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

Сейчас Ultra HD это 3840х2160 пикселей, что в сумме 23,7 Мб. При тридцати кадрах в секунду получается 712 Мб/с. Я бы не сказал, что это маленький поток. Любая дополнительная опция будет нагрузкой.

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

Вопрос в первую очередь любителям Linux: неужто всё упирается в подражание Windows? Пока что наделана куча рабочих сред, которые копируют интерфейс друг друга, тем не менее, на сам xorg никто не покушается, а возможно, именно отсутствие нормального доступа (вроде DirectX) к графическому интерфейсу тормозит активному использованию и распространению системы, как таковой.

[Джон]

После этого дома в винде страдаю, когда число окон переваливает через 3.

Ром, переходи на 10-ку, там такая фича тоже есть.

с множеством десктопов.

Добавлено через 3 минуты:

Сейчас Ultra HD это 3840х2160 пикселей, что в сумме 23,7 Мб. При тридцати кадрах в секунду получается 712 Мб/с. Я бы не сказал, что это маленький поток. Любая дополнительная опция будет нагрузкой.

Только не надо забывать, что кадру по барабану, что и сколько на нём отрисовано. Хоть тысячи окон, всё-равно будет одна битмап на кадр.

[Алексей++]

Aether, а почему бы и не подражание, если это удобно ?

Ром, у меня и по 10 окон бывает Возможно, дело привычки

Добавлено через 3 минуты и 37 секунд:
Aether, мне, скажем, часто требуется видеть именно краешек окна (лог ползёт или иная инфа). Нескольких окон. Определённый краешек. Как это сделать на статичных разбиениях ? Скролл представления приложения ?
Я понимаю, что тут гораздо проще второй монитор подключить (но обычно без этого обходится)

[RXL]

Леш, я пользуюсь закладками: основные приложения — браузеры, мессенджеры и терминалы, и во всех есть закладки, т.е. фактические окна у меня десятками меряются. А под винду нет ни одного нормального терминала, даже putty уродливо работает.

Aether, уже 20 лет назад видеокарты поддерживали функции рисования окошек: рисование линий и прямоугольников, заливка областей, копирование глифов и т.п. Современные могут намного больше. Т.ч. забудь эту "проблему". Софтовый рендеринг составляет малую долю отображения.

[darkelf]

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

Вопрос в первую очередь любителям Linux: неужто всё упирается в подражание Windows? Пока что наделана куча рабочих сред, которые копируют интерфейс друг друга, тем не менее, на сам xorg никто не покушается, а возможно, именно отсутствие нормального доступа (вроде DirectX) к графическому интерфейсу тормозит активному использованию и распространению системы, как таковой.

Имхо, конечно, Вы не совсем правы - имеются и разные виды оконных менеджеров на любой вкус, зачастую очень сильно отличающиеся друг от друга. Которые пытаются подражать и интерфейсам и MacOS, и Windows, и даже разным Amiga-м и прочим Plan 9.

И поддержка 3-D ускорения есть - OpenGL, сам графикой не занимаюсь, но как я понял, довольно близкий аналог Direct X - SDL.

Ну и наконец не Xorg-ом единым - сейчас активно развивается Wayland/Weston, те-же товарищи из Ubuntu пытаются развивать свой Mir. Да и сам Xorg не стоит на месте, хотя и развивается не так активно, как раньше и как, наверное, хотелось-бы.

[Aether]

Только не надо забывать, что кадру по барабану, что и сколько на нём отрисовано. Хоть тысячи окон, всё-равно будет одна битмап на кадр.

О чём речь? У Вас, например, тысяча окон, из них двадцать являются видимыми на экране, значит система должна выдать сообщение каждому из этих двадцати приложений на перерисовку. В то же время, сложно учитывать необычные формы вырезок при наложении окон, значит функции рендеринга каждого окна обязаны будут пересчитать всю зону своего текущего габарита. Конечно, тут может быть хитрость, когда нет прямого доступа, как в GDI, но при этом теряется другое - качество.
Так вот, для Вашего экрана будет один битмэп, например, 640х480, площадью 307200 кв. пикселей. А общий входной поток для оконного менеджера, получается двадцать окон, например, 400х300 пикселей, в сумме выдающий 2400000 кв. пикселей.
Так вот, про что я говорил, так это наблюдаемая статистика использования видео выхода: в большинстве случает пользователь использует одно приложение, разворачивая его на всю площадь. Когда окон на экране становится более 3-4 штук их размер становится настолько мал, что с ними невозможно полноценно работать. И третье: ручное выравнивание приводит к тому, что из десятка активных окон полезными будут 2-3, зато системе придётся работать с отображением всех десяти.

Приведу такой пример: среди инженеров используются разные CAD, из двумерных самые частые в РФ - это AutoCAD и КОМПАС. Первая CAD очень гибкая в настройке, и какой ерунды я только не видел: на чертежах 30-80 слоёв, у каждого свой цвет, толщина, стиль... - и это ещё и противоречит требованиям ЕСКД. Почему так выходит? Да всё просто: соседние конторы: у одной один Бетховен, у другой другой. Одна другой передаёт КД и понеслось добавление костылей. Во второй CAD, изначально ограничили оформление требованиями ЕСКД - работать приятное дело, просто потому, что Бетховенам не дают избыток свободы - иногда он бывает крайне вреден.

Aether, а почему бы и не подражание, если это удобно ?

Добавлено через 3 минуты и 37 секунд:
Aether, мне, скажем, часто требуется видеть именно краешек окна (лог ползёт или иная инфа). Нескольких окон. Определённый краешек. Как это сделать на статичных разбиениях ? Скролл представления приложения ?

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

Не понял, Вам нужен скролл и так, и так. Каким бы большим окно не было, его размер всё равно лимитирован размером экрана.

И поддержка 3-D ускорения есть - OpenGL, сам графикой не занимаюсь, но как я понял, довольно близкий аналог Direct X - SDL.

Ну и наконец не Xorg-ом единым - сейчас активно развивается Wayland/Weston, те-же товарищи из Ubuntu пытаются развивать свой Mir. Да и сам Xorg не стоит на месте, хотя и развивается не так активно, как раньше и как, наверное, хотелось-бы.

SDL - это, вроде, просто библиотека, в Windows она будет опираться на DirectX, а в Linux, скорее всего на Xorg.

У Xorg сам подход ориентирован на удалённое использование компьютера, а передача полноценного видео трафика через сеть не эффективна, как таковая, особенно, если будет происходить повсеместно. Поэтому Xorg скорее всего в DirectX не превратится. Из остальных видов видеосистем, знаю больше сами названия, нежели подробности.

[darkelf]

SDL - это, вроде, просто библиотека, в Windows она будет опираться на DirectX, а в Linux, скорее всего на Xorg.

DirectX тоже библиотека. Возможно с определённой поддержкой на уровне ядра ОС и в драйверах, но тем не менее - это API. Одно время в Windows вполне нормально поддерживались и OpenGL, даже были игры, которые его использовали.

Просто почему я привёл SDL - насколько я понял, он предоставляет доступ, кроме 3D, который есть в OpenGL, ещё и унифицированный интерфейс к мышкам, клавиатурам, звуку и прочим сетям, которых в OpenGL нет, но которые, если не ошибаюсь, есть в DirectX.

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

У Xorg сам подход ориентирован на удалённое использование компьютера, а передача полноценного видео трафика через сеть не эффективна, как таковая, особенно, если будет происходить повсеместно. Поэтому Xorg скорее всего в DirectX не превратится.

Он позволяет работать через сеть, но на локальном компьютере работа идёт через разделяемую память. А с помощью интерфейсов типа DRI2/DRI3, прикладные программы могут вполне себе задействовать возможности ускорителя минуя X-сервер вообще.

По поводу неэффективности передачи видео трафика по сети - например, в X Window System есть возможность, как в GDI рисовать примитивами, есть возможность на уровне сервера выводить текст нужными шрифтами, это позволяет создавать интерфейсы, которые очень быстро и с минимумом трафика передаются по сети, но проблема заключается в том, что основные популярные библиотеки Qt и GTK этими не пользуются, а сами формируют целиком картинку, и на сервер уже отсылают bitmap. В таком случае трафик получается на порядки больше. Обычных 100 мегабитных каналов для программ типа Firefox уже хватает очень с трудом.

Из остальных видов видеосистем, знаю больше сами названия, нежели подробности.

Там, как я понял, просто пытаются уйти от наслоений, которые накопились за 30 лет существования X Window System и узаконить сложившуюся на данный момент практику. Первоначально вообще не было графических драйверов, и каждый разработчик видео ускорителей должен был разрабатывать целиком свой X-сервер. Потом это дело стали упрощать, придумали графические драйвера, которые были уже библиотеками и работали через определённые интерфейсы с X-сервером. А затем эти драйвера понемногу начали переезжать из пространства пользователя, в котором функционирует X-сервер в ядро ОС.

Вообще, по моему мнению, графика, на примере тех-же игр, в Linux, в отличие от Windows, не особо развивается из-за сильной фрагментации платформы. Существуют сотни вообще, и десятки сравнительно популярных в частности дистрибутивов. Собирать и проверять на работоспособность своё ПО под каждый из них не выдюжит практически ни одна коммерческая компания. А собирать под один - смысла нет - слишком малый процент охваченных пользователей оказывается. Это из-за того, что развитие Linux-а предполагает Open Source модель - если есть исходные тексты, то пользователи (или разработчики дистрибутива) сами соберут программу. С закрытыми исходниками так не получается.

В общем, получается практически по В.И.Ленину - "Пользователи - не могут собирать программы для своих дистрибутивов (из-за отсутствия исходных текстов программ), а компании не хотят (из-за огромного количества работы, которая в дальнейшем может не оправдаться)".

Кстати, касательно картинки, которую Вы привели в своём первом сообщении - есть такое понятие тайловые, ну или более официально - фреймовые оконные менеджеры.

[Aether]

, но проблема заключается в том, что основные популярные библиотеки Qt и GTK этими не пользуются, а сами формируют целиком картинку, и на сервер уже отсылают bitmap.

Рисование примитивами не уменьшает общий объём работ, но распределяет их. Когда сервер и клиент в одном ПК, тактика примитивов смысла не имеет. Когда же они разнесены, графические преобразования берёт на себя клиент, и мал лишь сетевой трафик. Но, так ли это важно? Для удалённой работы консольные приложения более выгодны, рациональны. Вещи, вроде GDI, хороши разве что для программ, вроде, "Удалённый помощник" и прочих средств наблюдения за пользователем.

Вообще, по моему мнению, графика, на примере тех-же игр, в Linux, в отличие от Windows, не особо развивается из-за сильной фрагментации платформы.

Может быть.

Кстати, касательно картинки, которую Вы привели в своём первом сообщении - есть такое понятие тайловые, ну или более официально - фреймовые оконные менеджеры.

Вот примерно об этом и говорю.

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

Подготовил небольшую презентацию.

[BlueWhite]

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

[RXL]

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

[Алексей++]

кстати, при общении с ютубом, к примеру, тачскрин - боль