|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 20 Aug 2001 14:05:06
To : Vladimir Bormotov
Subject : Linux as Desktop
--------------------------------------------------------------------------------
At 24 Jul 01 23:55:55, Vladimir Bormotov wrote to Zahar Kiselev:
RS>>> Ты ведь не станешь пpедлагать заменить инстpументы в гимпе на
RS>>> комманды и pисовать линии указывая кооpдинаты точек?
ZK>> Лично я не стану предлагать такое. Хотя в автокаде кстати можно и так
ZK>> и эдак - как удобнее пользователю в каждом данном случае.
VB> ..так говорили два человека, которые не работали с GIMP ;)))
Он мне бывает нужен только чтобы посмотреть скачанную из интернета картинку
с электронной схемой.
RS>>> Тут (в эхе) вообще очень много абсолютно глупых наездов на мышь и gui,
ZK>> Однако мне не нужен и не удобен графический интерфейс например в
ZK>> почтовой программе - потому как письмо по своей природе является
ZK>> текстом.
VB> а как на счет посмотреть присланую фотку, прям в почтовой программе?
Тут уже много было разговоров по поводу стиля юникса и стиля доса. Так вот в
досе популярен дос-навигатор, в который встроено всего понемногу, а в юниксах
более предпочтительно запустить _отдельную_ программу просмотра изображений,
которая только это и умеет, зато делает это хорошо.
ZK>> Точно так же не нужна графика чтобы позвонить провайдеру или поправить
ZK>> что-то в конфигурации системы.
VB> согласен. Hо если все остальное делается в графике, почему-бы и это не
VB> сделать ЕДИHООБРАЗHЫМ?
Потому что в графике делается _очень_ немногое. Какой смысл усложнять простые
вещи?
ZK>> И еще можно привести немало примеров, где графика совершенно не
ZK>> является необходимой.
VB> ...но всегда можно для каждого примера привести вариант, когда графика
VB> будет УДОБHЕЕ и HАГЛЯДHЕЕ.
Я думаю, что это черезвычайно субъективно. Для меня удобен и нагляден интерфейс
на основе меню, потому что мне сложно запоминать назначение многочисленных
мелких пиктограмм, а кто-то отличается превосходной почти фотографической
зрительной памятью - и ему пиктограммы удобны.
ZK>> К счастью в Линуксе в отличие от виндов ее использование не
ZK>> обязательно. Чтобы поднять ppp мне достаточно набрать в комстроке
ZK>> "pon", а то и вовсе настроить diald, написав ему один раз конфиг.
VB> Именно. В итоге, мы пришли к тому, что GUI сам по себе, как "подход" не
VB> виноват.
Конечно! Я с этим и не спорил. Просто каждому подходу свое место. Точно так же
как сложно представить тот же GIMP без GUI, так же трудно вообразить зачем может
быть нужен GUI для звонка провайдеру.
RS>>> Такое ощущение что некотоpые вообще пpотив гpафического пpедставления
RS>>> данных
ZK>> Как всегда - есть такие кто "за" и такие кто "против". Кому-то
ZK>> удобнее видеть загрузку своей BBS в виде цветной диаграммы, а кому-то
ZK>> в виде таблицы. Я отношусь ко вторым.
VB> таблица, которую тебе удобнее видеть, возможна в графике?
Вообще говоря да. Однако это будет потреблять лишние ресурсы, которым у меня
есть иное применение. Вспомнилось про "стоя и в гамаке" - можно конечно и так,
но по-моему не очень нужно.
VB> Так в чем пробелма? "В постоянном белом фоне"??? ;)))
Это уже проблема _реализации_, к сожалению встречающаяся повсеместно.
Однако месяц назад видел программу управления стендом диагностики автомобильных
двигателей(под виндами, но в данном случае это не существенно) - интерфейс хотя
и графический, но очень удобный и _совершенно_ не напоминает то, что видим
например в микрософтовском офисе. Hи белого фона, ни мелких шрифтов...
>>> и за
RS>>> пpедставление их в виде нечитабельных логов.
ZK>> Логи должны быть читабельными, а не как у ifcico, у которого все копии
ZK>> в случае многолинейной станции пишут в один лог.
VB> и это правильно. Hомер линии должен быть отдельным столбцом в логе.
VB> "лог конкретной линии" получается простейшим grep.
Было бы проще писать в отдельные файлы сразу, чем потом разгребать помойку
грепом.
Zahar
--- QDed alpha v3.57pl9.1e/Linux
* Origin: (Empty...) (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
