Почему в линуксе неюзабельный UI

plumber(4) из Plan9

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

LaTeX же. Текст, графики, формулы, диаграммы. Никакого ActiveX, кстати, для этого не нужно.

ActiveX и его аналоги не нужны.

Вечно лагающие и криво вляпаные не к месту вставки одной функциональности в другую всегда озадачивали.

LaTeX же. Текст, графики, формулы, диаграммы. Никакого ActiveX, кстати, для этого не нужно.

А истчо имакс! Про имакс не забудьте!

Вечно лагающие и криво вляпаные не к месту вставки одной функциональности в другую всегда озадачивали.

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

CORBA ?

Вот только не надо проблемы своего нерабочего уя на весь линукс распространять.

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

>Вот, к примеру, у меня есть два приложения - одно для редактирования текста, другое для редактирования диаграмм.
Как мне объединить их функции, чтобы использовать для редактирования текста с диаграммами?

#include <texedit>
#include <diagram>

Что может являться примером интерфейсов для интеграции различных приложений в Linux?

KParts

CORBA

уже давно не вариант. исходная идея была неплоха, но

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

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

А в тех задачах, где требуется интеграция, гуй бесполезен. Например, управление системой, обработка данных, создание документов, сайтов, программ и т.п. В таких задачах рулят zsh, screen, vim, emacs и прочие. Вот только ССЗБ этого не понимают и продолжат забивать гвозди микроскопами.

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

Единство (например, текста, диаграмм и видео) должно быть зашито в формате изначально, а не быть чудовищем Франкенштейна, склепанным из разных кусков, типа видеороликов или диаграмм Visio в .doc.

CORBA ?

Боюсь те, кто реально работал с тем же TAO, часто кричат по ночам а иногда даже писаются. От ужаса.

Следует к концепции unix-style подойти с другой стороны.

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

То есть не линейная конструкция задаваемая в виде cat | grep | awk, а визуальный ветвящийся конвеер.

для графических приложений такого интерфейса для Linux я не знаю

Это может быть не очевидно, но приложения с графическим интерфейсом(*) предназначены для ввода/вывода в/из человеков. Потому комбинирование этих функций производится единственно возможным и довольно неэффективным способом — принуждением целевых устройств к маханию щупальцами.

(*) графические приложения вполне могут не иметь графического интерфейса. Мне известны povray, imagemagic, tex. Таковых не много, вероятно по причине того, что человеки редко способны объяснить программам, что именно первые хотят сделать с изображением, звуком, и т.п. слабоструктурированными данными. Часто тут проще итеративный процесс с пошаговым контролем.

CORBA — технологический стандарт написания распределённых приложений, продвигаемый консорциумом OMG и соответствующая ему информационная технология.

OMG

omg

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

>Это может быть не очевидно, но приложения с графическим интерфейсом(*) предназначены для ввода/вывода в/из человеков. Потому комбинирование этих функций производится единственно возможным и довольно неэффективным способом — принуждением целевых устройств к маханию щупальцами.

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

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

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

>>приложения с графическим интерфейсом предназначены для ввода/вывода в/из человеков.

Не так совсем, утилиты графической настройки конфигов например.

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

А потом уже натравить настроенный пайп на кучу файлов.

>Почему в линуксе неюзабельный UI

Потому что ты не осилил его настроить.

Такие были (и, вероятно, ещё есть)

так должен быть работать Tcl/Tk по задумке автора

>>Т.е. такая штука подошла бы для людей с дисграфией и другими препятствиями работе с текстом

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

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

http://ru.wikipedia.org/wiki/D-Bus?

>>Впрочем, недостаточное владение словарём/языком, встречается достаточно часто, т.ч. шансы у подобных извращений ненулевые.

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

Всё что ему нужно знать, например, для операции интегрирования: на входе есть функция, сетка и метод. Визуальная обертка отлично скроет все недостатки синтаксиса и неудобство пользования.

Думать же о том, является ли интервал [a..b] «вектором», «листом», «списком», «строкой» или ещё чем-нибудь в кретинской терминологии матпакета — это ломать мозги и продуктивность об страшные протезы и скобы, торчащие из абортивного уродца-поделия.

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

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

Вот, к примеру, у меня есть два приложения - одно для редактирования текста, другое для редактирования диаграмм

Вот к примеру у меня есть Photoshop CS4 для редактирования графики и Chess 2000 для игры в шахматы. Как мне объединить их функции, чтобы редактировать фигурки шахмат в то время пока я в них играю?

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

Ну да ну да. А потом они приходят к нам под дверь и начинают слезно ныться что мол почему черт возьми мир так несправедлив и ихнее маленькое комьюнити никому не нужно на белом свете кроме оного самого? Почему его не любят да что там не любят - попросту не замечают, тогда как оно все такое из себя маленькое и комьюнити? Где справедливость? А вот она. Справедливость.

За вас уже Баллмер и Джобс все придумали. Что ж вы грязные руки к Linux тянете?

я имел ввиду, что из любого г(ДЕ, программы) можно сделать очень даже конфетку один раз, а кому не понравится, пускай настраивает под себя
и все будут счастливы
так почему это нельзя сделать?

я могу и сам за себя подумать
и руки я сегодня мыл

очевидно, что играть в шахматы в фотошопе, там даже история будет

>Вот, к примеру, у меня есть два приложения - одно для редактирования текста,

другое для редактирования диаграмм.

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

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

Сильная зависимость от состояния не укладывается в конвейер.

Что может являться примером интерфейсов для интеграции различных приложений в
Linux?

Это не связано с линуксом и тулкитами. Всё дело в приложении. Есть d-bus, некоторые приложения могут создавать сокет и принимать комманды. Многие приложения содержат встроенные средства скриптования. Но для обычного десктопного софта это малополезно.

и много кто к вам приходил плакаться? реальные примеры, быстро, решительно.

и много кто к вам приходил плакаться? реальные примеры, быстро, решительно.

LOR Talks (tm) Единая стена плача. Недостатков в клиентах явно не испытывает.

Главное, чтобы были шейдеры на фигурках и cmyk demotivation.ru/vi6m93rvq145pic.html

>типа видеороликов или диаграмм Visio в .doc.
можно в doc включить zip архив с патчами, да видел такое

можно в doc включить zip архив с патчами, да видел такое

В LKML поди? Да, там кадры прожжённые попадаются, им в пасть палец не суй.

>В LKML поди? Да, там кадры прожжённые попадаются, им в пасть палец не суй.
не настраивал одну ынтерпрайз хрень

Не совсем

> Вот к примеру у меня есть Photoshop CS4 для редактирования графики и Chess 2000 для игры в шахматы. Как мне объединить их функции, чтобы редактировать фигурки шахмат в то время пока я в них играю?

можно задать более осмысленный вопрос: у меня есть фотошоп CS4 и Corel Draw — как мне сделать, чтобы окошко выбора цвета было одинаковое в обоих программах (например, заюзать в фотошопе окошко из корела?)

или чтобы цветовая палитра, созданная для фотошопа, была доступна в кореле?

> Думать же о том, является ли интервал [a..b] «вектором», «листом», «списком», «строкой» или ещё чем-нибудь в кретинской терминологии матпакета — это ломать мозги и продуктивность об страшные протезы и скобы, торчащие из абортивного уродца-поделия

это, возможно, излишняя притензия, хотя матпакеты могут быть кретинскими, не спорю; в нормальных языках есть прототип функции integral, из которого ясно, чем является интервал

Поясните, зачем нормальным людям мешать одно приложение с другим? Есть редактор текста - им редактируется текст. Есть редактор диаграмм - им редактируются диаграммы. Из каких-таких кошмаров можно взять мешанину? Хотя, не отвечайте, из венды. Ну так, слава богу, мы не в ней.

> компоненты .Net

кинь хорошую ссылочку на описани их функциональности

они могут расшарить палитру между приложениями?

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

Для обработки данных, очевидно. Обработку с обработкой комбинировать легко (пока «тип» выходных данных соответствует таковому у входных следующего компонента). grep не занимается выводом в человека, это «терминал» делает. Потому grep легко комбинировать с подобными. Выходной тип «гуёвых» программ — двухмерное изображение предназначенное для глаз/мозгов. Т.о. их легко комбинировать только с глазами/мозгами. Входные — последовательность событий клавиатуры/указателя — проще к чему-то прицепить, потому у нас есть, например, т.н. «макросы».

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

Ничего плохого нет. Просто не всегда «стоит выделки». Допустим, описание параметров, действительно удобнее, но в каких случаях? Если параметров много — у тебя проблемы производительноси, найти в большом списке нужный тебе проще поиском по man-у. Если помнишь — выигрыш пропал, т.к. ввести кнопками тоже проще. И ни в коем случае не стоит пытаться вычислять параметры на основании других, или выходных обрабатываемых данных; рисование формул мышкой — жуткий геморрой. Итого, область эффективности — если их немного, и ты их не помнишь и не вычисляешь, или у них нев^Hподъёмно длинные названия (что есть проблема дизайна). Или при поиске «ответа» методом тыка (что опять подразумевает небольшое количество).

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

Вывод: для редкоповторяемой (любительской) работы с относительно простыми компонентами и «непредусмотримыми» правилами (иначе можно написать кнопку «сделай всё»). Осталось найти те данные, которые потребовали бы таких возможностей и были бы интересны «домашним» пользователям.

Есть подозрение, что такие вещи можно делать в системах типа Squeak, наверное можно было делать в Symbolics.