15.05.2012 10:18, Ivan Shmakov пишет: >>>>>> Артём Н <[email protected]> writes: >>>>>> 14.05.2012 18:50, Ivan Shmakov пишет: > > >>> Не всегда. Прописать длинное правило дольше, менее наглядно, > >>> сложнее (больше всего надо помнить и вспоминать), чем использовать > >>> GUI, а вероятность допустить ошибку выше. > > >> Хм. Есть большая разница между « », « » и « ». Наглядно? > > >> А если так: « », « » и « »? > > > Причём тут интерфейс? > > Это не к «интерфейсам», но к «наглядности.» > > Так, можно поспорить, что LaTeX (*roff, HTML, Markdown, etc.) — > нагляднее WYSIWYG. Три вида пробелов в HTML (блин, о   я даже не знал). Каждый имеет определённые особенности в некоторых условиях, при отображении. Пользователю нужно видеть пробел. Ему не нужно знать какой закорючкой в языке разметки (предназначенном для визуального отображения), пробел рисуется. В правильно спроектированном интерфейсе (пусть даже это web-сайт), пробел останется пробелом, безо всяких неоднозначностей.
> > >>>> Гуй нужен для создания визуального представления для человека. > >>>> Больше ни для чего. > > >>> Ага. Вот этот ГУЙ, как-раз только эту задачу и выполняет. Это и > >>> нравится. Кстати, CLI тоже нужен только для взаимодействия с > >>> человеком. > > >> Здесь речь не столько о GUI vs. CLI, сколько о «меню» vs. «язык > >> программирования.» > > >> Основная проблема «типовых» GUI — невозможность «записать» > >> последовательность команд, отданных пользователем, для последующего > >> повторного использования. В тех же случаях, когда такая возможность > >> предоставляется (через определение «макрокоманд»), записанную > >> последовательность нередко нельзя /параметризовать/. > > > В случае с GUI, о котором речь, эти проблемы не стоят. :-) > > Почему? Потому что там не нужно повторять последовательность команд, настройки сохраняются, а дописать своё возможно в пролог или эпилог скрипта. > > >> Напротив, при использовании языков, производных от POSIX Shell, все > >> эти возможности, как правило, в наличии. > > > Это проблемы конкретного интерфейса. Нужен язык - достаточно > > встроить движок в интерфейс. > > Конечно. Но если мы создаем команднострочное приложение, то > язык мы получаем «бесплатно», в то время как при создании > приложения с графическим интерфейсом язык требует отдельного > внимания. Как и сам интерфейс. > Как показывает практика, в подавляющем большинстве случаев, > «проблемы advanced users разработчиков не волнуют», поэтому > «возможность» добавить язык к GUI-приложению остается лишь > возможностью. Возможно иметь GUI и CLI одновременно. Хотя бы поддержку опций. Иногда GUI удобнее. Я ж не говорю о том, что нужно ставить вопрос GUI vs CLI. :-\ Тут дело в том требуется ли такое в интерфейсе, а не в advanced users. > > o.O Фигасе. Посмотрел что такое. Ну стоит у меня ubiquity в > > iceweasel (в репозитории увидел и решил посмотреть, что такое). Я > > даже помню, как он вызывается, но не пользуюсь. Есть подозрение, что > > ихний HUD постигнет та же учесть, что и десяток (или сотню?) подобных > > велосипедов. > > Возможно. Но, на мой взгляд, запомнить название команды^W > пункта меню куда проще, чем название /и/ положение оного. Ну да... "artiom@dana:~/Desktop$ l Display all 201 possibilities? (y or n)" > --cut: http://tourlib.net/books_others/gates_doroga_04.htm -- O_O -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
