Замечание по ведению журнала
Jun. 1st, 2009 01:05 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerЕсли еще кто-то когда-то в моем журнале будет упоминать в положительном контексте что-либо, сделанное в рамках GNOME и KDE, буду банить как за мат.
vitus_wagnervitus_wagner
Page Summary
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Style Credit
- Style: Clarity for Paletteable by branchandroot
- Resources: Holiday
Expand Cut Tags
No cut tags
no subject
Date: 2009-06-01 09:37 am (UTC)Но что делать с человеком, у которого потребностей в колбасе нет?
no subject
Date: 2009-06-01 09:50 am (UTC)на самом деле бесят интегрированные вещи в себе, это у гномокде есть. повыбрасывали бы костыли и сделали нормальную инфраструктуру для работы произвольных приложений. а DE лишь сверху крутилось.
no subject
Date: 2009-06-01 10:38 am (UTC)Надо понимать, что для современного "произвольного" десктопного приложения нужно очень много:
- Полноценный HTTP-клиент.
- HTML-компонент для вывода произвольного HTML.
- Требуется безгеморройная работа со звуком, хотя бы базовая "проиграть звук".
- Диалоги открытия/сохранения файлов с превьюшками и поддержкой сетевых путей.
- Система печати.
Писать это в рамках каждого нового проекта ни у кого (кроме OOo и Mozilla) сил нет, конечно же.
Поэтому сейчас и далее будут неизбежно играть интегрированные приложения.
no subject
Date: 2009-06-01 10:47 am (UTC)Во-вторых - он есть. wget называется. popen("wget -O - url","r") и вперед.
С полноценным HTML-вьюером - сложнее. Во-певрых, его нету, кроме Мозиллы. Webkit, увы, пока далеко не полноценный. Во-вторых, есть некоторые проблемы со встраиванием. Потому что в отличие от HTTP-клиента, HTML-вьюер должен быть видимым в GUI. Привычки встраивать окно отдельного процесса в свой GUI у нынешних разработчиков нет.
На самом деле интеграция - это хорошо. Проблема в неверно выбранном уровне этой интеграции. Вот unix shell - он интегрирует разнообразные утилиты на уровне отдельных процессов. Получается весьма прилично. Но без GUI. Средства для интеграции GUI-компонентов, работающих в раздельном пространстве памяти (вспоминаем, что то,с чем придется работать - попадает под закон Старджона, а соответтвенно, 90% этого будет течь, глючить и падать в непредсказуемые моменты), да еще с приличной fault tolerance - пока что труднодоступны. То есть в xlib все необходимое есть. Нету во-первых, правильного учебника как этим пользоваться, во-вторых удобных инструментов, упрощающих разработку.
no subject
Date: 2009-06-01 11:44 am (UTC)Это не будет работать в случае, когда нам интересно выкачать страничку для отображения HTML-вьюером.
Придётся делать wget -p -k, смотреть его и разрабатывать собственную foreign host policy.
Вы НЕ хотите заниматься этим, если у вас задача - написать десктопное приложеньице. Это yak shaving.
"С полноценным HTML-вьюером - сложнее. Во-певрых, его нету, кроме Мозиллы. Webkit, увы, пока далеко не полноценный."
(из анекдота):
(женский голос) - Вы только послушайте! Всех удовлетворяет, а ее, видители, не удовлетворяет!
(мужской голос) - Да ее никто не удовлетворяет!
Вот так и тут. Google удовлетворяет, Apple удовлетворяет, а
"Средства для интеграции GUI-компонентов, работающих в раздельном пространстве памяти (вспоминаем, что то,с чем придется работать - попадает под закон Старджона, а соответтвенно, 90% этого будет течь, глючить и падать в непредсказуемые моменты), да еще с приличной fault tolerance - пока что труднодоступны."
Ну почему же, вон Konqueror испокон веков открывает плагины в отдельном процессе. Кстати, мокросовт это внезапно придумал полгода назад и продаёт за пример своего технологического гения.
COM вендовый примерно так же работал, но не могу сказать, что разработка таким образом давала какие-то принципиальные преимущества.
no subject
Date: 2009-06-01 12:04 pm (UTC)А для этого - и не надо :
system("$BROWSER url")
Выкачивать что-либо в приложении нужно тогда, когда эти данные предназначены не для человека, а для приложения.
Вот когда они свои проприетарные патчи отдадут в upstream, тогда посмотрим на это дело еще раз. Последняя моя попытка что-то делать с webkit привела к глубокому убеждению, что там работа с https попросту недописана.
COM вендовый умел много всяких гитик. И out-of-process server - далеко не самый распространенный способ его употребления.
Ну и да - основная проблема - это fault tolerance. Причем изложенная таким языком, чтобы самый тупой php-шник понял, и смог это правильно использовать в коде. А то вот тут в соседнем треде кто-то плачется, что у него студенческая поделка pyicqt выносит ejabberd, А у меня jabberd-1.4 - не выносит.
no subject
Date: 2009-06-01 12:36 pm (UTC)FAIL
Fault tolerance мне вот лично по барабану: kpdf у меня не падал, akregator у меня не падал, amarok у меня падает раз в полгода. У меня железо чаще глючит. Меня интересует функциональность; с твоим подходом ее не будет, зато ее отсутствие будет хорошо обосновано. А то я не знаю.
no subject
Date: 2009-06-01 12:43 pm (UTC)А я удивляюсь про что это они - у меня все работает &tm; на 96Мб PII-233 или 400Mhz ARM/128Мб.
Проблема еще и в том, что функциональности в КДЕ/ГНОМЕ, на мой взгляд, нет. Когда это надо руками делать и глазами смотреть, это не функциональность. Функциональность это когда один раз посмотрел глазами и сделал руками, второй раз, а на третий преодолел лень, написал три строчки и дальше оно само.
no subject
Date: 2009-06-01 12:59 pm (UTC)До этого несколько лет был Athlon простой на 1.2 ГГц, 256 мегабайт памяти, всё отлично работало, память свободная оставалась.
Прекращай уже жечь, а?
no subject
Date: 2009-06-08 06:28 am (UTC)"Обычный юзер" толком написать три строчки, как правило, умеет только на естественном языке. Для него компьютер — инструмент, наподобие автомобиля: надо, чтобы он ехал с минимальными когнитивными усилиями, хоть и не нулевыми. "Обычный юзер" — не глупый человек, просто он специалист в другом, не в компьютерах.
Соответственно, с выходом линукса на массовую аудиторию open source-разработчики срочно пытаются как-то сделать удобно обычному пользователю. Но, не будучи специалистами во всяком UI и usability, делают, как получается: внутренне неоптимально, не слишком логично, архитектурно неуклюже. Вы их за это, соотвественно, ругаете.
Грубо говоря, в FOSS хватает людей, умеющих писать код. Для этого есть масса инструментов, понятия наработаны. А для разработки взаимодействия с юзером всего этого, imho, практически нет. Непонятно, что взять, чтобы поиграться с интеграцией GUI-компонентов, да и где взять эти компоненты в подходящем виде — более того, непонятно, какой вид для них вообще подходящий.
Это всё давно известно, конечно. Но что с этим делать, по-преднему непонятно.
no subject
Date: 2009-06-08 06:42 am (UTC)Потому что любой инструмент, и софт в том числе может пользователя либо порабощать, либо освобождать. Третьего не дано. Инструмент порабощает, когда он сужает горизонты, ограничивает кругозор и заставляет человека выполнять тупую механическую работу по обслуживанию инструмента, не задумываясь о том, ЗАЧЕМ нужен вообще-то этот инструмент (или ограничиваясь утверждением "за это деньги платят").
Инструмент осовобождает, когда расширяет пространство возможностей, позволяет выбрать путь, который без этого инструмента был бы невозможен.
Понятно, что это освобождение работает по тому же принципу как магия сиды Немайн = количество кубометров земли, которое надо перекидать, чтобы колдовство сработало, никакому рабу не снилось.
Но тем не менее, это освобождение, возможность собственного выбора пути.
no subject
Date: 2009-06-10 01:13 am (UTC)"Средний человек", как правило, не особо владеет языком, иногда даже родным. Подозреваю, что надо эксплуатировать систему "глаз-рука", как более древнюю и хорошо отработанную %) Но пока это мало кто умеет.
А то был бы интерфейс системного конфигурирования наподобие Scratch :)
no subject
Date: 2009-06-10 03:22 am (UTC)И кончится это тем, что офисный планктон будет вытеснен обезьянами, как более дешевыми в эксплуатации.
no subject
Date: 2009-06-10 04:55 am (UTC)Хотя я о другом несколько. Посмотрите на любую видеоигру. Там бывают и богатые, сложные интерфейсы, обходящиеся, однако, без написания пользователем хоть одного слова. Или там условия выборки и сортировки в GUI-шной табличке какой часто задаются перетаскиванием столбцов и кликаньем на заголовки.
Возможно, в этой области лежит некоторое число решений, которые позволят простым пользователям™ лучше пользоваться гибкостью, заложенной в софт. Интерфейс ведь не обязан быть непременно тривиальным; преимущество GUI — discoverability и соотв. более низкий порог вхождения. При этом я не считаю нынешние мэйнстримные WIMP-интерфейсы слишком адекватными, разумеется. Опять сравню с играми.
А те, кто начнёт этим же софтом пользоваться совсем профессионально, освоят я написание команд, просто потому, что это быстрее :) Но им будет легче, потому что уже будет понятие, из каких доступных управлению кусочков софт состоит.
no subject
Date: 2009-06-11 09:33 am (UTC)Командный интерфейс, при этом, совсем не отменяет discoverability. Как пример -- расширение ubiquity для Firefox. Офигительные, действительно контекстные подсказки без лишних телодвижений. Если еще расширить это возможностью класть типовые команды на Link Bar, как bookmarklet... К сожалению, подобного интерфейса для повседневной работы, на замену Unix shell, я что-то не видел, но это не означает, что такое невозможно.
Кстати, из разговора с одним из экспертов по User eXperience почерпнул интересное знание о культурных различиях пользователей. Западные пользователи, как правило, умеют работать с клавиатурой, поэтому они нормально относятся к вводу текстовых команд (особенно, если есть подсказка, вроде ubiquity). Российский простой пользователь™ набирает текст одним пальцем, поэтому ему легче десять раз мышкой кликнуть, чем три буквы набрать. У восточных народностей с набором текстов тоже не сахар (~50 тыс. иероглифов, поди), даже для тех, кто вполне бегло строчит по клавишам. Отсталым вообще проще в тачскрин пальцем тыкать, ибо по земляному полу даже мышку нормально не покатаешь.
no subject
Date: 2009-06-11 07:42 am (UTC)akregator — жутко падучая вещь. Да и еще и использует свою лисапедную metakit вместо кошерного sqlite, вследствие чего постоянно падает и теряет данные.
no subject
Date: 2009-06-13 04:43 pm (UTC)Данные вроде не терял. Пару раз странно терял непрочитанность на нескольких статьях, я так и не понял, почему.
SQL сосёт, так что их можно понять.
no subject
Date: 2009-06-13 04:55 pm (UTC)Либо metakit не любит x86-64. Либо что-то еще. Но факты остаются фактами. На двух моих машинах падает.
SQL sucks, но что в этом мире не sucks? Хоть SQL и sucks, но «настоящие» субд, по крайней мере, данных своих не теряют.
no subject
Date: 2009-06-13 05:02 pm (UTC)no subject
Date: 2009-06-01 02:05 pm (UTC)ActiveX всю жизнь могли быть в отдельном apartment. Это позволяла даже древнее OLE, не говоря о том времени, когда оно стало называться COM.
no subject
Date: 2009-06-01 02:23 pm (UTC)Они браво доложили, что они не будут радикально, как хром, делать по процессу на вкладку, но вынесут в отдельные процессы плагины.
Я так читал.
no subject
Date: 2009-06-01 02:02 pm (UTC)Ой ли? А как же Safari который чуть ли не более стандартен (относительно w3c) чем FireFox 3.0.x, не говоря уже об IE?
no subject
Date: 2009-06-01 02:06 pm (UTC)no subject
Date: 2009-06-01 11:01 am (UTC)s/HTML-компонент для вывода произвольного HTML/стандартный raw интерфейс для встраиваемых виджетов/
s/Требуется безгеморройная работа со звуком, хотя бы базовая "проиграть звук"/стандартный интерфейс для работы со звуком/
s/Диалоги открытия\/сохранения файлов с превьюшками и поддержкой сетевых путей./стандартный интерфейс для вызова таких диалогов/**
** это нужно хотя бы для того, чтоб поднять безопасность десктопа. если программу заразили, можно хотя бы определить, когда она сама начнёт шариться по дискам.
и т.д. и т.п.. проблема в стандартизации, а вернее её убогой эмуляции под названием LSB
no subject
Date: 2009-06-01 11:48 am (UTC)Возьмись, если такой умный. Я думаю, что не взлетит.