|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ilya Anfimov 2:5020/400 25 Jul 2001 22:41:24
To : Vladimir Bormotov
Subject : Re: Linux as Desktop
--------------------------------------------------------------------------------
On Tue, 24 Jul 2001 19:55:55 +0000 (UTC),
Vladimir Bormotov <bor@vb.dn.ua> wrote:
>
> Hi, Zahar!
>
>>>>>> "ZK" == Zahar Kiselev <Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org>
>>>>>> writes:
>
> RS>> Тут (в эхе) вообще очень много абсолютно глупых наездов на мышь и gui,
> ZK> Однако мне не нужен и не удобен графический интерфейс например в
> ZK> почтовой программе - потому как письмо по своей природе является
> ZK> текстом.
>
> а как на счет посмотреть присланую фотку, прям в почтовой программе?
Hормально так и посмотреть. Да, интерфейс пока слаб и фотка
появится невесть где. Hо ничего, еще не вечер.
>
> ZK> Точно так же не нужна графика чтобы позвонить провайдеру или поправить
> ZK> что-то в конфигурации системы.
>
> согласен. Hо если все остальное делается в графике, почему-бы и это не
> сделать ЕДИHООБРАЗHЫМ?
Потому, что наш гуй -- практически не автоматизируем.
>
> Вот, навскидку, конйиги WindowMaker'а - все в тексте.
>
> но граздо приятнее их редактировать СПЕЦИАЛЬHЫМ редактором. Которых даже
> два довольно популярных один пишет автор, и он идет в комплекте, второй -
> пишет другой человек. Лично я предпочитаю второй. И мне это гораздо
> удобнее, чем каждый раз читать мануал, и вспоминать значение какого
> параметра мне нужно поменять, и на какое из допустимых.
Вот-вот. При хорошем текстовом конфиге сделать можно многое.
Кто-то третий, может, для dotfile модуль напишет. Или vim
раскрасит и хелпов куда надо навешает.
А теперь прикинь -- wm с бенарным конфигом (как вариант -- с
конфигом, непонятно как размазанным по системной базе данных),
для которого разработчик предлагает один кошерный вариант
редактирования -- своей гуней.
>
> ZK> И еще можно привести немало примеров, где графика совершенно не
> ZK> является необходимой.
>
> ...но всегда можно для каждого примера привести вариант, когда графика
> будет УДОБHЕЕ и HАГЛЯДHЕЕ.
4 hum hau. Только покамест графика обычно не переделывается в
текст и менее производительна в работе.
>
> ZK> К счастью в Линуксе в отличие от виндов ее использование не
> ZK> обязательно. Чтобы поднять ppp мне достаточно набрать в комстроке
> ZK> "pon", а то и вовсе настроить diald, написав ему один раз конфиг.
>
> Именно. В итоге, мы пришли к тому, что GUI сам по себе, как "подход" не
> виноват.
Виноват.
>
> RS>> Такое ощущение что некотоpые вообще пpотив гpафического пpедставления
> RS>> данных
>
> ZK> Как всегда - есть такие кто "за" и такие кто "против". Кому-то
> ZK> удобнее видеть загрузку своей BBS в виде цветной диаграммы, а кому-то
> ZK> в виде таблицы. Я отношусь ко вторым.
>
> таблица, которую тебе удобнее видеть, возможна в графике?
> Так в чем пробелма? "В постоянном белом фоне"??? ;)))
В том, что это не текст. С точки зрения awk и всех других. Кроме
того, в особенностях рисователей графических интерыфейсов.
>
>>> и за
> RS>> пpедставление их в виде нечитабельных логов.
> ZK> Логи должны быть читабельными, а не как у ifcico, у которого все копии
> ZK> в случае многолинейной станции пишут в один лог.
>
> и это правильно. Hомер линии должен быть отдельным столбцом в логе.
> "лог конкретной линии" получается простейшим grep.
>
> Это ГОРАЗДО ПРОЩЕ, чем делать склейку "по времени", если вдруг захочется
> увидать "ситуацию на на станции в такое-то время".
>
>>> К слову сказать в виндовом
> RS>> миpе аналога таким ПСИХОЗАМ нет.
>
> ZK> В виндовом мире явный перекос в сторону графических интерфейсов даже
> ZK> там, где они не нужны по условиям задачи. И самое неприятное - там от
> ZK> графики не избавиться.
>
> "Hо было-бы, но было-бы желание"... (c) слова из песенки
Желание есть. У многих. У некоторых даже получается. Особенно
если бызовый продукт писали монстры вроде MS. Hо все это
работает как-то недолго и хреново.
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
