[вброс][некрофилия][вещества] N идей из Windows 98, о которых стоило бы знать разработчикам современных DE.

Например, в моём наколеночном гуе, написанном за 4 вечера. Единственное, что надо доделать, — читать меню из конфига, а не заходкоживать в код.

А вот какого хрена это не рализовано в других тулзах — это более интересный вопрос. И не только в поисковых, а вообще где угодно, где бывают списки файлов. Например.

MDI и табы - это наикостыльнейший из вариантов решения.

в каком месте один клик для переключения хуже, чем 2 или 1+ожидание?

в каком месте один клик для переключения хуже, чем 2 или 1+ожидание?

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

плюс негибкость - ты не можешь объединять в группы табы из разных приложений

плюс негибкость - ты не можешь объединять в группы табы из разных приложений

вылезай из криокамеры

если у тебя открыто другое приложение?

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

Шо, за пять дней срача девяносто восьмую не похоронили? Ну хоть девяносто пятую уже можно закапывать?

вылезай из криокамеры

вылез. Объедини-ка мне вместе табы из chromium, remmina, какого-нибудь терминала

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

Объедини-ка мне вместе табы из chromium, remmina, какого-нибудь терминала

http://dl.dropbox.com/u/998228/LOR/window-tabs.png

Что и требовалось доказать: табы в приложениях — костыли и не нужны.

именно

Что и требовалось доказать: табы в приложениях — костыли и не нужны.

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

Вообще я считаю, что нужно добавить оконный протокол для работы с табами. Чтобы стал возможен следующий сценарий:

* Пользователь нажимает хоткей создания нового таба.
* Приложение смотрит, умеет ли WM табы.
* Если нет, просто создаёт таб внутри окна.
* Если да, берёт group id текущего окна, создаёт новое окно, назначает ему этот group id.
* WM видит, что замапилось новое окно с уже задействованным group id, добавляет это окно в соответствующую группу, образующую «вкладочный» набор окон.

Кстати, у тебя и браузер без табов?

У меня браузер с табами, потому что нет стандарта на работу с табами на уровне WM. Если у человека нога с дефектом, это не значит, что костыли — это нормально. Костыли — это костыли.

про микроскоп и гвозди напомнить?

Напомни. Только сначала не забудь уточнить, что здесь микроскоп, а что — гвозди.

Кстати, у тебя и браузер без табов?

у меня без табов, отключены

У меня браузер с табами, потому что нет стандарта на работу с табами на уровне WM.

это да, было бы еще лучше. Кеды вон уже продвинулись в этом направлении, но до стандартизации еще далеко

Только сначала не забудь уточнить, что здесь микроскоп, а что — гвозди.

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

у меня без табов, отключены

и чем ты пользуешься для переключения между страницами? Неужели калечной группировкой в таскбаре?

и чем ты пользуешься для переключения между страницами? Неужели калечной группировкой в таскбаре?

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

А так - в dmenu список окон с интерактивным поиском(если окон куча на рзаных десктопах). Плюс тайловый WM, плюс 2 монитора.

Целостность должна обеспечиваться соглашениями (потоколом, спецификациями), а не конкретной реализацией.

Почему должна? Я вообще думал, что подходы и архитектуры выбираются исходя из условий решаемых задач, а не постулируются.

Иначе твой Fvwm — это еще один комбайн а ля Unity.

Ну раз панельки умеет рисовать, то допустим. И что в этом плохого? Не согласуется с постулатами построения идеального ПО? Не очень юниксвейно? ПО должно задачи решать и его архитектура не должна становится самоцелью. Много толку от расчудесной микроядерной архитектуры Танненбаума? Ну кроме того, что Линус ей очень вдохновился и сделал всё наоборот.

Ты не ответил.

И не отвечу. Потому что говорю о концепции. Я вижу, что компоненты рабочего окружения разрабатываются разрозненно, дублируют функционал друг друга и слабо интегрируются. Решение вижу в выделении логического ядра окружения. Нет ещё никаких реализаций. Только идея «назначить главного». Можно даже назвать её организационной.

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

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

ПО должно задачи решать и его архитектура не должна становится самоцелью.

Ну так и какую задачу ты хочешь решить? Это разговор беспредметный. Называй конкретные функции.

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

Много толку от расчудесной микроядерной архитектуры Танненбаума?

1. Практической пользы от Танненбаума вообще не много.

2. От микроядер толку много. Если не знаешь, погугли.

3. Аналогии сосут.

Потому что говорю о концепции.

Ну вот потому мы и говорим о концепции, что говорим о концепции.

Я вижу, что компоненты рабочего окружения разрабатываются разрозненно, дублируют функционал друг друга и слабо интегрируются. Решение вижу в выделении логического ядра окружения. Нет ещё никаких реализаций. Только идея «назначить главного». Можно даже назвать её организационной.

Если ты не понял, я повторю снова: идея ничего не стоит, если ты не знаешь пути её реализации. Если ты не знаешь, что делать с твоей идей, то я тем более знать не могу. И никто не знает. Сейчас это пустая идея.

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

Это было во-первых. Теперь во-вторых. Капитан подсказывает, что если рассмотреть панель задач и WM, окажется, что их функции пересекаются лишь частично. Например:
* WM ничего не знает и не должен знать о порядке кнопок на панели.
* Панель ничего не знает и не должна знать о том, какого цвета заголовки у окон.
И нет никаких причин учить их знать это друг о друге — это всё равно, что учить текстовый редактор еще и видео проигрывать.

Зато в том, что касается непосредственно контроля над окнами, они знают друг о друге всё, что нужно. И получается всё ровно так, как ты писал:

WM - логическое ядро. Панели, пейджеры и пр. - плагины.

Так чем ты не доволен?

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

Какие конкретно действия ты собрался засовывать в меню? Все действия над окнами определены в NETWM. Панель работает ровно с тем набором действий, что ей доступен по протоколу. Более того, поскольку WM умеет сообщать список поддерживаемых фич, то панель работает и с частными расширениями протокола конкретных WM. Например, openbox имеет собственные соглашения об управлении декорированием окон, выходящие за рамки NETWM.

Так что повторяю в который уже раз: что ты конкретно хочешь сделать?

Ты изначально заговорил именно об архитектуре, потому мы и говорим об «архитектуре вообще».

Не «вообще», а рабочего окружения.

Все действия над окнами определены в NETWM.

Нет, определены базовые параметризируемые функции, интерфейс. См. ниже.

Какие конкретно действия ты собрался засовывать в меню?

Пример. Я определяю функции разворота на левую/правую половину экрана (максимайз на 100% по высоте и на 50% по ширине, перемещение к 0,0 или 50%,0). Плюс неперекрывающий максимайз, увеличесние размеров до ближайших окон текущего стола. Плюс действие создания скрина текущего окна. Все эти функции я спокойно определил в Fvwm, назначил хоткеи и разместил в меню окна. И использую. Нормальные же примеры?

А теперь высказываю свою хотелку, чтобы панельки при нажатии в панели задач показывали моё меню действий, где нет неиспользуемых мной некоторых стандартных действий, но есть мои дополнительные. Такая вот простая «пользовательская» хотелка. И сопутствующие мысли о том, почему получается иначе и какое я вижу решение. Прислушиваться или нет решай сам, я не настаиваю ;)

В твоём примере фигурирует 3 сущности: окна; агенты, могущие выполнять действия с окнами; средства взаимодействия пользователя с окнами.

Как это сделать правильно:
* Агенты публикуют в свойствах окна информацию о возможных действиях с ними.
* Различное ПО (панель задач, WM, черт с рогами) использует эту информацию для создания меню и вызова действий.

То, что у тебя WM одновременно выступает и в роли действиевыполнятеля, и в роли действиезаказывателя — не более чем частный случай. С тем же успехом анонсировать информацию о доступных действиях может непосредственно процесс-вдаледец окна, наколеночный bash-скрипт в автозапуске сеанса, или какой-нибудь демон из недр гномокед.

Собственно, моё предложение, про которое все так дружно кричали ненужно, было именно про это (как одна из ключевых фич в).

Допустим, что есть у нас расширение протокола/dbus-сервис/libastral для публикации сведений о доступных действиях окна. Сами приложения туда могут пихать действия, информацию о вкладках и файлах и прочую «семантику». WM туда пихает свои команды, ещё какая-нибудь хрень свои. Такое построение я понимаю.

Не могу понять, почему в твоём примере WM только получает информацию о действиях с окнами. Кто тогда её публикует?

Не могу понять, почему в твоём примере WM только получает информацию о действиях с окнами. Кто тогда её публикует?

А? Я ничего не понял.

Кто хочет обрабатывать действия для окна, тот их к нему и цепляет. Логично?

Кто хочет обрабатывать действия для окна, тот их к нему и цепляет.

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

Присоединюсь к числу ожидающих черновик спеки.