Re: CLI vs. GUI
Артём Н. - debian-russian@lists.debian.org @ Tue, 22 May 2012 22:48:11 +0400: Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. АН Как-раз для HTML, GUI необходим. Если, конечно, вы не АН рассчитываете на то, что все ваши пользователи используют АН lynx, links, w3m или подобное. Доктор, это ничего, что у меня есть информативный сайт, все HTML которого написаны вручную, старые в vim, новые в emacs? Ключевое слово - информативный. АН Вообще-то, это частный случай, когда требуется преимущественно АН подсветка HTML и CSS. С чем VIM неплохо справляется. Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном файле, отчего все еще проще. АН Правильный редактор не должен рассчитывать на то, что всё будет по АН уму, к тому же, иногда надо смешивать CSS и HTML. Правильный _для меня_ - имеет право на это рассчитывать. Более того, ему рекомендуется так делать. Типа если он не справляется с подсветкой, значит, я фигню порю. emacs вполне успешно справляется с задачей ловли меня за руку. Смешивать CSS и HTML иногда надо. Но если это приходится делать до такой степени, что нужна синтаксическая подсветка CSS - фигню порешь. Что и наблюдается в случае HTML из-под винворда :-) Суть, собственно, в том, что vim и emacs - это TUI, а не GUI. Хотя emacs даже умеет показывать картинки. Лучше б не умел... А если мне нужно интерактивное веб-приложение, то там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно ручное редактирование. АН Хм... Haml - любопытно. Угу. Технология создания веб-приложений сводится к тому, что дизайнер делает дизайн, HTML-верстальщик (это совершенно другой человек) превращает его в HTML, CSS и набор картинок, а программист превращает эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов, которые динамически заполняются данными. Гуй для HTML при этом может использоваться в принципе только на втором этапе, но тем верстальщикам, кто пытается его там использовать, быстро отрывают руки. Ну, или результат получается, мягко говоря, неюзабельным для пользователя. АН Хм. Что, вы хотите сказать, что во всех компаниях, которые АН занимаются созданием WEB-данных (документов или приложений и т.п.) АН и могут позволить себе иметь дизайнера, не имеющего представления о АН вёрстке и ей не занимающегося, верстальщика и прочих, вторые всегда АН работают без GUI? Кстати, а дизайнер тоже обязательно, либо не АН использует компьютер, либо работает без GUI? :-) Или, всё-таки, на АН первом этапе тоже есть GUI, только совершенно отличный от GUI АН верстальщика? К слову, в большинстве контор, занимающихся созданием веб-приложений, своего дизайнера вообще нет. Аутсорсят. Дизайнер не работает с HTML, поэтому ему гуй для (читаем внимательно!) HTML не нужен. Верстальщик тоже работает с гуем - но не для создания HTML, а для нарезки того, что сделал дизайнер, и для извлечения оттуда информации о цветах :-) АН Кстати, а операторам на станциях например, GUI тоже не требуется? АН :-) Или, всё-таки, он иногда нужен (почему-то вы та упорно АН пытаетесь доказать, что GUI - всегда плохо)? Почему-то вы упорно вычитываете в моих словах то, что там не написано. Как это выглядит, нужно смотреть в браузере и только в браузере. Желательно не в одном. АН Как это выглядит и работает нужно проверять в браузере. Обязательно АН не в одном, как говорят. По крайней мере, в наиболее популярных АН (или в тех, на которых это будет работать, если это нечто АН специфическое). И, затем ещё вносить корректировки для конкретных АН экземпляров. :-| Тонкость в том, что если у тебя есть информация, то можно написать достаточно простой HTML для того, чтобы проверять его нужно было максимум в одном. Тому, кому есть, что сказать, дизайнерские изыски обычно не шибко нужны. АН Просто выглядящий и преподносящий информацию в удобочитаемом виде АН или просто устроенный? :-) Все три. Первые два вообще очень тесно коррелируют - чем проще выглядит HTML, тем информация в нем удобочитаемее. Мешает он тем, что то, как это выглядит в этом гуе, автор и считает реальным видом документа. А что этот гуй выдает в код, и какой ужас потом в браузере... Это - практика. АН o.O Я разве агитирую за Фронтпэйдж? Я предполагаю, что автор АН имеет представление о том, что существуют разные средства вывода АН (и, если уж быть точным, не обязательно визуальные). Наличие гуя провоцирует не иметь такого представления. АН Это, как наличие пистолета провоцирует с кем-то разобраться... АН Уменьшает порог вхождения. АН Но человек во вменяемом состоянии, вряд ли побежит разбираться с АН кем-то лишь потому, что у него в кармане оружие. Аналогии лгут. А JS длиннее одного
Re: CLI vs. GUI
On Wed, May 23, 2012 at 10:10:59AM +0400, Artem Chuprina wrote: Смешивать CSS и HTML иногда надо. Но если это приходится делать до такой степени, что нужна синтаксическая подсветка CSS - фигню порешь. Что и наблюдается в случае HTML из-под винворда :-) Это второй вопрос. Но программа на JS, если она используется, должна быть в отдельном файле, а не включена в тот же HTML. АН Когда как... Ни одного контрпримера не попадалось. Проблема в том, что Билл Гейц и Ко сумели творчески переработать принцип: Все есть файл в Нечто есть _один_ файл. Как следствие, появилось поколение калек, для которых мысль о необходимости копирования _нескольких_ файлов для того чтобы разместить страницу, кажется странной. Как следствие, какой-нибудь, опенофис вместо того чтобы создать каталог с читаемыми файлами создает архив, а, говорят, может и одну xml-простыню родить. Или в багрекере inkscаpe многие годы добивались возможности инкапсуляции растра в SVG. Добились, кстати. А любимый, некоторыми, fb2? -- Иван Лох -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120523100209.ga12...@nano.ioffe.rssi.ru
Re: CLI vs. GUI
23.05.2012 14:02, Иван Лох пишет: On Wed, May 23, 2012 at 10:10:59AM +0400, Artem Chuprina wrote: Смешивать CSS и HTML иногда надо. Но если это приходится делать до такой степени, что нужна синтаксическая подсветка CSS - фигню порешь. Что и наблюдается в случае HTML из-под винворда :-) Это второй вопрос. Но программа на JS, если она используется, должна быть в отдельном файле, а не включена в тот же HTML. АН Когда как... Ни одного контрпримера не попадалось. Проблема в том, что Билл Гейц и Ко сумели творчески переработать принцип: Все есть файл в Нечто есть _один_ файл. Как следствие, появилось поколение калек, для которых мысль о необходимости копирования _нескольких_ файлов для того чтобы разместить страницу, кажется странной. Как следствие, какой-нибудь, опенофис вместо того чтобы создать каталог с читаемыми файлами создает архив, а, говорят, может и одну xml-простыню родить. Или в багрекере inkscаpe многие годы добивались возможности инкапсуляции растра в SVG. Добились, кстати. А любимый, некоторыми, fb2? Ну, не всё так сурово. Я про более частный случай. Кстати, тесно связанный с MS. :-) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbcf44e.8060...@yandex.ru
Re: CLI vs. GUI
23.05.2012 10:10, Artem Chuprina пишет: Артём Н. - debian-russian@lists.debian.org @ Tue, 22 May 2012 22:48:11 +0400: Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. АН Как-раз для HTML, GUI необходим. Если, конечно, вы не АН рассчитываете на то, что все ваши пользователи используют АН lynx, links, w3m или подобное. Доктор, это ничего, что у меня есть информативный сайт, все HTML которого написаны вручную, старые в vim, новые в emacs? Ключевое слово - информативный. АН Вообще-то, это частный случай, когда требуется преимущественно АН подсветка HTML и CSS. С чем VIM неплохо справляется. Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном файле, отчего все еще проще. АН Правильный редактор не должен рассчитывать на то, что всё будет по АН уму, к тому же, иногда надо смешивать CSS и HTML. Правильный _для меня_ - имеет право на это рассчитывать. Более того, ему рекомендуется так делать. Типа если он не справляется с подсветкой, значит, я фигню порю. emacs вполне успешно справляется с задачей ловли меня за руку. А вы будете в своём правильном редакторе просматривать исключительно правильный код? :-) Или что-то чужое иногда приходится читать? Да и неплохо бы дать пользователю _выбирать_, что для него правильно... Смешивать CSS и HTML иногда надо. Но если это приходится делать до такой степени, что нужна синтаксическая подсветка CSS - фигню порешь. Что и наблюдается в случае HTML из-под винворда :-) Не обязательно (именно про подсветку в CSS, даже когда он в отдельном файле). Синтаксическая подсветка позволит визуально выделить элементы (я не про помойку CSS+HTML, а про выделение элементов в самом CSS). Меньше придётся напрягаться, например, при визуальном поиске (в глаза сразу бросаются имена атрибутов, например, в полотне параметров и своих классов). Меньше усталость, комфортнее работать. Я не прав? Суть, собственно, в том, что vim и emacs - это TUI, а не GUI. Хотя emacs даже умеет показывать картинки. Лучше б не умел... А если мне нужно интерактивное веб-приложение, то там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно ручное редактирование. АН Хм... Haml - любопытно. Угу. Технология создания веб-приложений сводится к тому, что дизайнер делает дизайн, HTML-верстальщик (это совершенно другой человек) превращает его в HTML, CSS и набор картинок, а программист превращает эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов, которые динамически заполняются данными. Гуй для HTML при этом может использоваться в принципе только на втором этапе, но тем верстальщикам, кто пытается его там использовать, быстро отрывают руки. Ну, или результат получается, мягко говоря, неюзабельным для пользователя. АН Хм. Что, вы хотите сказать, что во всех компаниях, которые АН занимаются созданием WEB-данных (документов или приложений и т.п.) АН и могут позволить себе иметь дизайнера, не имеющего представления о АН вёрстке и ей не занимающегося, верстальщика и прочих, вторые всегда АН работают без GUI? Кстати, а дизайнер тоже обязательно, либо не АН использует компьютер, либо работает без GUI? :-) Или, всё-таки, на АН первом этапе тоже есть GUI, только совершенно отличный от GUI АН верстальщика? К слову, в большинстве контор, занимающихся созданием веб-приложений, своего дизайнера вообще нет. Аутсорсят. Дизайнер не работает с HTML, поэтому ему гуй для (читаем внимательно!) HTML не нужен. Верстальщик тоже работает с гуем - но не для создания HTML, а для нарезки того, что сделал дизайнер, и для извлечения оттуда информации о цветах :-) Ну, я про это и говорю (читаем внимательно в предыдущем сообщении): раздельный ГУЙ. Но дизайнер тоже работает с гуём... АН Кстати, а операторам на станциях например, GUI тоже не требуется? АН :-) Или, всё-таки, он иногда нужен (почему-то вы та упорно АН пытаетесь доказать, что GUI - всегда плохо)? Почему-то вы упорно вычитываете в моих словах то, что там не написано. Ну, потому что мне кажется, что вы упорно доказываете то, что я там вычитываю. :-) Как это выглядит, нужно смотреть в браузере и только в браузере. Желательно не в одном. АН Как это выглядит и работает нужно проверять в браузере. Обязательно АН не в одном, как говорят. По крайней мере, в наиболее популярных АН (или в тех, на которых это будет работать, если это нечто АН специфическое). И, затем ещё вносить корректировки для конкретных АН экземпляров. :-| Тонкость в том, что если у тебя есть информация, то можно написать достаточно простой HTML для того, чтобы проверять его нужно было максимум в одном. Тому, кому есть, что сказать, дизайнерские изыски обычно не
Re: CLI vs. GUI
On Wed, May 23, 2012 at 06:43:38PM +0400, Артём Н. wrote: Главная страница может использовать общий стиль. Но у неё есть некоторые особенности. Зачем для неё выносить CSS в отдельный файл (читайте отдельный Ну и ввести набор классов специально для особенностей главной страницы. запрос), если он больше нигде не дублируется? IE поддерживает условные комментарии (aka костыли), которые приходится применять Это уже треш какой-то -- Иван Лох -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120523163650.gb12...@nano.ioffe.rssi.ru
Re: CLI vs. GUI
20.05.2012 23:31, Artem Chuprina пишет: Артём Н. - debian-russian@lists.debian.org @ Sun, 20 May 2012 21:56:09 +0400: Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. АН Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете АН на то, что все ваши пользователи используют lynx, links, w3m или АН подобное. Доктор, это ничего, что у меня есть информативный сайт, все HTML которого написаны вручную, старые в vim, новые в emacs? Ключевое слово - информативный. АН Вообще-то, это частный случай, когда требуется преимущественно АН подсветка HTML и CSS. С чем VIM неплохо справляется. Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном файле, отчего все еще проще. Правильный редактор не должен рассчитывать на то, что всё будет по уму, к тому же, иногда надо смешивать CSS и HTML. Суть, собственно, в том, что vim и emacs - это TUI, а не GUI. Хотя emacs даже умеет показывать картинки. Лучше б не умел... А если мне нужно интерактивное веб-приложение, то там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно ручное редактирование. АН Хм... Haml - любопытно. Угу. Технология создания веб-приложений сводится к тому, что дизайнер делает дизайн, HTML-верстальщик (это совершенно другой человек) превращает его в HTML, CSS и набор картинок, а программист превращает эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов, которые динамически заполняются данными. Гуй для HTML при этом может использоваться в принципе только на втором этапе, но тем верстальщикам, кто пытается его там использовать, быстро отрывают руки. Ну, или результат получается, мягко говоря, неюзабельным для пользователя. Хм. Что, вы хотите сказать, что во всех компаниях, которые занимаются созданием WEB-данных (документов или приложений и т.п.) и могут позволить себе иметь дизайнера, не имеющего представления о вёрстке и ей не занимающегося, верстальщика и прочих, вторые всегда работают без GUI? Кстати, а дизайнер тоже обязательно, либо не использует компьютер, либо работает без GUI? :-) Или, всё-таки, на первом этапе тоже есть GUI, только совершенно отличный от GUI верстальщика? Кстати, а операторам на станциях например, GUI тоже не требуется? :-) Или, всё-таки, он иногда нужен (почему-то вы та упорно пытаетесь доказать, что GUI - всегда плохо)? Как это выглядит, нужно смотреть в браузере и только в браузере. Желательно не в одном. АН Как это выглядит и работает нужно проверять в браузере. Обязательно АН не в одном, как говорят. По крайней мере, в наиболее популярных АН (или в тех, на которых это будет работать, если это нечто АН специфическое). И, затем ещё вносить корректировки для конкретных АН экземпляров. :-| Тонкость в том, что если у тебя есть информация, то можно написать достаточно простой HTML для того, чтобы проверять его нужно было максимум в одном. Тому, кому есть, что сказать, дизайнерские изыски обычно не шибко нужны. Просто выглядящий и преподносящий информацию в удобочитаемом виде или просто устроенный? :-) Мешает он тем, что то, как это выглядит в этом гуе, автор и считает реальным видом документа. А что этот гуй выдает в код, и какой ужас потом в браузере... Это - практика. АН o.O Я разве агитирую за Фронтпэйдж? Я предполагаю, что автор АН имеет представление о том, что существуют разные средства вывода АН (и, если уж быть точным, не обязательно визуальные). Наличие гуя провоцирует не иметь такого представления. Это, как наличие пистолета провоцирует с кем-то разобраться... Уменьшает порог вхождения. Но человек во вменяемом состоянии, вряд ли побежит разбираться с кем-то лишь потому, что у него в кармане оружие. А JS длиннее одного вызова функции в script в ручную написанном HTML - это признак того, что у автора слишком много свободного времени, и ему нечем это время занять, кроме как вычисткой потом глюков из результата. АН Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один АН внешний JS, который включает объект её реализующий? Про много АН свободного времени - это вы объясните авторам всяких там гуглов и АН ещё 100500 сервисов, которые этим JS буквально пронизаны (местами АН это даже удобно и, бывает, работает). Это второй вопрос. Но программа на JS, если она используется, должна быть в отдельном файле, а не включена в тот же HTML. Когда как... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fbbdf6b.8090...@yandex.ru
Re: CLI vs. GUI
Maksym Tiurin - debian-russian@lists.debian.org @ Mon, 21 May 2012 08:38:35 +0300: Меню организуют структуру команд и позволяют быстро найти нужную (они не заменяют горячих клавиш), без использования справки... MT Представил себе меню emacs со всеми командами. MT Ужаснулся. Быстро там найти явно ниче нельзя будет. Да ладно! Я иногда включаю menu-bar-mode, когда не помню комбинацию клавиш для операции. И успешно там нахожу. MT Все? В меняю всех никогда ИМХО не было. Например режимы для работы с MT Version Control Systems очень куцо в меню представлены. Может быть. Но это недостаток данного меню, а не возможностей меню вообще. У gnus очень развесистые меню, и в них при этом неплохо ищется. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obpi9hn7@wizzle.ran.pp.ru
Re: CLI vs. GUI
Артём Н. - debian-russian@lists.debian.org @ Fri, 18 May 2012 12:07:00 +0400: Поскольку им нужно не только видеть, как выглядит текст сейчас, но и понимать что с ним будет происходить при некоторых изменениях (например при переформатировании на другую ширину) и быть уверенными что от этого смысл не потеряется. АН И, всё-таки, GUI... :-) Конкретно в этой задаче GUI как раз сильно мешает. Особенность человеческой психики, ничего личного. Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. АН Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете АН на то, что все ваши пользователи используют lynx, links, w3m или АН подобное. Доктор, это ничего, что у меня есть информативный сайт, все HTML которого написаны вручную, старые в vim, новые в emacs? Ключевое слово - информативный. А если мне нужно интерактивное веб-приложение, то там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно ручное редактирование. АН К тому же, для написания кода необходим нормальный интерфейс (ну, используя cat АН или echo, тоже возможно кое-что написать, но идея плохая (как крайний случай)). АН Если вы будете писать в notepad-like, это затянется. АН Т.е. нужен редактор с подсветкой синтаксиса. Причём, желательно, с АН автоматическим определением по контексту того, что подсвечивать (например, js в АН script и css должны подсвечиваться по-разному). АН Он не обязательно должен работать в графическом режиме, Дело не в этом. Дело в том, что он обязательно НЕ должен быть WYSIWYG. Как это выглядит, нужно смотреть в браузере и только в браузере. Желательно не в одном. АН но графический режим добавляет возможность предосмотра картинок, АН например. Поддержка мышки и dd добавляет возможность быстрой АН компоновки. Меню организуют структуру команд и позволяют быстро АН найти нужную (они не заменяют горячих клавиш), без использования АН справки... В итоге, получается GUI (причём, никто не отменяет АН поддержку консольного режима). По-моему, это очевидно. И чем тут АН он мешает (при условии, что он спроектирован и реализован АН грамотно)? Мешает он тем, что то, как это выглядит в этом гуе, автор и считает реальным видом документа. А что этот гуй выдает в код, и какой ужас потом в браузере... Это - практика. А JS длиннее одного вызова функции в script в ручную написанном HTML - это признак того, что у автора слишком много свободного времени, и ему нечем это время занять, кроме как вычисткой потом глюков из результата. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762bqdb04@wizzle.ran.pp.ru
Re: CLI vs. GUI
Stanislav Vlasov - Артём Н. @ Fri, 18 May 2012 14:20:53 +0600: SV Не совсем так. GUI здесь необходим, если вы разрабатываете _дизайн_ страницы. Причем этот гуй называется, surprise, Adobe InDesign, и ничего общего с HTML не имеет... -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871umedaxv@wizzle.ran.pp.ru
Re: CLI vs. GUI
Maksym Tiurin - Артём Н. @ Fri, 18 May 2012 23:05:30 +0300: Меню организуют структуру команд и позволяют быстро найти нужную (они не заменяют горячих клавиш), без использования справки... MT Представил себе меню emacs со всеми командами. MT Ужаснулся. Быстро там найти явно ниче нельзя будет. Да ладно! Я иногда включаю menu-bar-mode, когда не помню комбинацию клавиш для операции. И успешно там нахожу. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wr46bwbu@wizzle.ran.pp.ru
Re: CLI vs. GUI
20.05.2012 21:21, Artem Chuprina пишет: Артём Н. - debian-russian@lists.debian.org @ Fri, 18 May 2012 12:07:00 +0400: Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. АН Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете АН на то, что все ваши пользователи используют lynx, links, w3m или АН подобное. Доктор, это ничего, что у меня есть информативный сайт, все HTML которого написаны вручную, старые в vim, новые в emacs? Ключевое слово - информативный. Вообще-то, это частный случай, когда требуется преимущественно подсветка HTML и CSS. С чем VIM неплохо справляется. А если мне нужно интерактивное веб-приложение, то там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно ручное редактирование. Хм... Haml - любопытно. Как это выглядит, нужно смотреть в браузере и только в браузере. Желательно не в одном. Как это выглядит и работает нужно проверять в браузере. Обязательно не в одном, как говорят. По крайней мере, в наиболее популярных (или в тех, на которых это будет работать, если это нечто специфическое). И, затем ещё вносить корректировки для конкретных экземпляров. :-| АН но графический режим добавляет возможность предосмотра картинок, АН например. Поддержка мышки и dd добавляет возможность быстрой АН компоновки. Меню организуют структуру команд и позволяют быстро АН найти нужную (они не заменяют горячих клавиш), без использования АН справки... В итоге, получается GUI (причём, никто не отменяет АН поддержку консольного режима). По-моему, это очевидно. И чем тут АН он мешает (при условии, что он спроектирован и реализован АН грамотно)? Мешает он тем, что то, как это выглядит в этом гуе, автор и считает реальным видом документа. А что этот гуй выдает в код, и какой ужас потом в браузере... Это - практика. o.O Я разве агитирую за Фронтпэйдж? Я предполагаю, что автор имеет представление о том, что существуют разные средства вывода (и, если уж быть точным, не обязательно визуальные). АН К тому же, для написания кода необходим нормальный интерфейс (ну, используя cat АН или echo, тоже возможно кое-что написать, но идея плохая (как крайний случай)). АН Если вы будете писать в notepad-like, это затянется. АН Т.е. нужен редактор с подсветкой синтаксиса. Причём, желательно, с АН автоматическим определением по контексту того, что подсвечивать (например, js в АН script и css должны подсвечиваться по-разному). АН Он не обязательно должен работать в графическом режиме, Дело не в этом. Дело в том, что он обязательно НЕ должен быть WYSIWYG. Вот именно об этом я и говорю. WISYWYG плохо, потому что это WISYWYG (и ещё десять надуманных причин). Дело в том, что там он крайне желателен. Вопрос удобства. Пример грамотно (несмотря на то, что они там напилили в последних версиях и ещё множество лишних вещей) реализованного редактора - Dreamweaver. WISYWYG нужен для примерного представления о том, как будет выглядеть документ. Никто не отменяет ручной правки результата. Но этак даже формочки во всяких Делфи возможно вручную делать. Но зачем? А JS длиннее одного вызова функции в script в ручную написанном HTML - это признак того, что у автора слишком много свободного времени, и ему нечем это время занять, кроме как вычисткой потом глюков из результата. Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один внешний JS, который включает объект её реализующий? Про много свободного времени - это вы объясните авторам всяких там гуглов и ещё 100500 сервисов, которые этим JS буквально пронизаны (местами это даже удобно и, бывает, работает). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb93039.8070...@yandex.ru
Re: CLI vs. GUI
Артём Н. - debian-russian@lists.debian.org @ Sun, 20 May 2012 21:56:09 +0400: Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. АН Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете АН на то, что все ваши пользователи используют lynx, links, w3m или АН подобное. Доктор, это ничего, что у меня есть информативный сайт, все HTML которого написаны вручную, старые в vim, новые в emacs? Ключевое слово - информативный. АН Вообще-то, это частный случай, когда требуется преимущественно АН подсветка HTML и CSS. С чем VIM неплохо справляется. Причем, если делать по уму, то HTML и CSS не нужно смешивать в одном файле, отчего все еще проще. Суть, собственно, в том, что vim и emacs - это TUI, а не GUI. Хотя emacs даже умеет показывать картинки. Лучше б не умел... А если мне нужно интерактивное веб-приложение, то там вообще будет, скорее всего, либо haml, либо hamlet, и однозначно ручное редактирование. АН Хм... Haml - любопытно. Угу. Технология создания веб-приложений сводится к тому, что дизайнер делает дизайн, HTML-верстальщик (это совершенно другой человек) превращает его в HTML, CSS и набор картинок, а программист превращает эти HTML и CSS (картинки обычно оставляет как есть) в набор шаблонов, которые динамически заполняются данными. Гуй для HTML при этом может использоваться в принципе только на втором этапе, но тем верстальщикам, кто пытается его там использовать, быстро отрывают руки. Ну, или результат получается, мягко говоря, неюзабельным для пользователя. Как это выглядит, нужно смотреть в браузере и только в браузере. Желательно не в одном. АН Как это выглядит и работает нужно проверять в браузере. Обязательно АН не в одном, как говорят. По крайней мере, в наиболее популярных АН (или в тех, на которых это будет работать, если это нечто АН специфическое). И, затем ещё вносить корректировки для конкретных АН экземпляров. :-| Тонкость в том, что если у тебя есть информация, то можно написать достаточно простой HTML для того, чтобы проверять его нужно было максимум в одном. Тому, кому есть, что сказать, дизайнерские изыски обычно не шибко нужны. АН но графический режим добавляет возможность предосмотра картинок, АН например. Поддержка мышки и dd добавляет возможность быстрой АН компоновки. Меню организуют структуру команд и позволяют быстро АН найти нужную (они не заменяют горячих клавиш), без использования АН справки... В итоге, получается GUI (причём, никто не отменяет АН поддержку консольного режима). По-моему, это очевидно. И чем тут АН он мешает (при условии, что он спроектирован и реализован АН грамотно)? Мешает он тем, что то, как это выглядит в этом гуе, автор и считает реальным видом документа. А что этот гуй выдает в код, и какой ужас потом в браузере... Это - практика. АН o.O Я разве агитирую за Фронтпэйдж? Я предполагаю, что автор АН имеет представление о том, что существуют разные средства вывода АН (и, если уж быть точным, не обязательно визуальные). Наличие гуя провоцирует не иметь такого представления. АН Но этак даже формочки во всяких Делфи возможно вручную делать. Но зачем? В Delphi - можно, но тяжело и неудобно. А в Tk - удобно... А JS длиннее одного вызова функции в script в ручную написанном HTML - это признак того, что у автора слишком много свободного времени, и ему нечем это время занять, кроме как вычисткой потом глюков из результата. АН Мда? А эта функция тянет за собой библиотеку на 300 Кб и ещё один АН внешний JS, который включает объект её реализующий? Про много АН свободного времени - это вы объясните авторам всяких там гуглов и АН ещё 100500 сервисов, которые этим JS буквально пронизаны (местами АН это даже удобно и, бывает, работает). Это второй вопрос. Но программа на JS, если она используется, должна быть в отдельном файле, а не включена в тот же HTML. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87396ubqew@wizzle.ran.pp.ru
Re: CLI vs. GUI
Artem Chuprina writes: Maksym Tiurin - Артём Н. @ Fri, 18 May 2012 23:05:30 +0300: Меню организуют структуру команд и позволяют быстро найти нужную (они не заменяют горячих клавиш), без использования справки... MT Представил себе меню emacs со всеми командами. MT Ужаснулся. Быстро там найти явно ниче нельзя будет. Да ладно! Я иногда включаю menu-bar-mode, когда не помню комбинацию клавиш для операции. И успешно там нахожу. Все? В меняю всех никогда ИМХО не было. Например режимы для работы с Version Control Systems очень куцо в меню представлены. -- With Best Regards, Maksym Tiurin JID:mrko...@jabber.pibhe.com -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m31umert44@comp.bungarus.info
Re: CLI vs. GUI
17.05.2012 15:09, Artem Chuprina пишет: Артём Н. - debian-russian@lists.debian.org @ Thu, 17 May 2012 09:42:11 +0400: Поскольку им нужно не только видеть, как выглядит текст сейчас, но и понимать что с ним будет происходить при некоторых изменениях (например при переформатировании на другую ширину) и быть уверенными что от этого смысл не потеряется. АН И, всё-таки, GUI... :-) Конкретно в этой задаче GUI как раз сильно мешает. Особенность человеческой психики, ничего личного. Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете на то, что все ваши пользователи используют lynx, links, w3m или подобное. К тому же, для написания кода необходим нормальный интерфейс (ну, используя cat или echo, тоже возможно кое-что написать, но идея плохая (как крайний случай)). Если вы будете писать в notepad-like, это затянется. Т.е. нужен редактор с подсветкой синтаксиса. Причём, желательно, с автоматическим определением по контексту того, что подсвечивать (например, js в script и css должны подсвечиваться по-разному). Он не обязательно должен работать в графическом режиме, но графический режим добавляет возможность предосмотра картинок, например. Поддержка мышки и dd добавляет возможность быстрой компоновки. Меню организуют структуру команд и позволяют быстро найти нужную (они не заменяют горячих клавиш), без использования справки... В итоге, получается GUI (причём, никто не отменяет поддержку консольного режима). По-моему, это очевидно. И чем тут он мешает (при условии, что он спроектирован и реализован грамотно)? -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb60324.6010...@yandex.ru
Re: CLI vs. GUI
18 мая 2012 г., 14:07 пользователь Артём Н. artio...@yandex.ru написал: Поскольку им нужно не только видеть, как выглядит текст сейчас, но и понимать что с ним будет происходить при некоторых изменениях (например при переформатировании на другую ширину) и быть уверенными что от этого смысл не потеряется. АН И, всё-таки, GUI... :-) Конкретно в этой задаче GUI как раз сильно мешает. Особенность человеческой психики, ничего личного. Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете на то, что все ваши пользователи используют lynx, links, w3m или подобное. Не совсем так. GUI здесь необходим, если вы разрабатываете _дизайн_ страницы. Если же требуется написать её содержимое - здесь нужен редактор, который умеет разметку. Или даже достаточно отконвертировать документ откуда-то еще, дополнив элементами, созданными дизайнером для приведения внешнего вида к нужным кондициям. -- Stanislav
Re: CLI vs. GUI
17.05.2012 13:12, Иван Лох пишет: On Thu, May 17, 2012 at 09:42:11AM +0400, Артём Н. wrote: Хм... Наверное, пользователь документа - это тот, кто использует документ (пусть даже это сайт, хотя тогда документ - не совсем верно). Тот, кто пишет - писатель или разработчик. браузеры которые слушаются пользователя лучше, чем дизайнера), а человек, который хочет донести до читателя смысл текста. Да, но читателю не нужно видеть разницу. Писатель предоставляет данные и способ их отображения программе-обработчику. Он тоже использует интерфейс, но уже другой. И, естественно, с другим уровнем детализации. Каждому - своё. Это вопрос о возможности модификации контента в широком смысле. Корпорация всегда стремиться затруднить активное использования продуктов своей жизнедеятельности. То есть свести все отношения к паре писатель-читатель. С первым - согласен. Поскольку, монополизация идеи или другой интеллектуальной собственности, вероятно, позволяет увеличить прибыль от её использования. Со вторым - нет. Мне, например, не интересно исправлять ошибки в каком-нибудь networkmanager (он недавно сглючил) или модифицировать его. Мне достаточно быть читателем. В плане документов... Если это технический текст или код, возможно вам потребуется его дополнять. Но это частный случай, который редко встречается. Мало того, для этого требуется определённая квалификация (ну нет простых в использовании инструментов для создания программ, даже если это RAD), а главное - технические знания и понимание не только того, что сделал автор, но и как он это сделал. Прибавьте к этому частоту таких модификаций, сложность их сопровождения, сложность... Не каждому это нужно. Но, точно также, как и в opensource вне копирайтерских корпораций вопрос использования, и трансформации контента стоит везде. И там где используется CC-SA вопрос о виде пробелов и возможности их дальнейшего использования более чем актуален. Вообще, потеря эмфазы, например, в цитатах, может исказить сегодня их смысл. Поэтому доступ к исходным кодам произведения вполне важен. Этот процесс во многих областях идет. В науке, например, где 90% фальсификаций скрыто за тремя кнопками, пресловутого, ориджина -- тоже. Вопрос о доступе к исходным кодам - тема отдельного холивара. Я лишь говорю о том, что для каждой задачи - свой инструмент. А отвергать GUI, потому что он GUI, как-то странно... То же самое и GUI. sendmail, emacs, awesome, какой-нибудь, предоставляют каждому широкую возможность модификации продукта прямо через конфигурационные файлы. Любые GUI разом лишат их 90% функциональности. Ага, особенно учитывая известную простоту настройки sendmail, красоту и понятность её конфига (по благодарным отзывам пользователей), думаю многие не против настроить её через GUI. :-) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb6085a.5010...@yandex.ru
Re: CLI vs. GUI
Иван Лох - debian-russian@lists.debian.org @ Thu, 17 May 2012 19:17:12 +0400: Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я ИЛ А потом потребуется постер или, например, буклет... Так это я буду делать acroread'ом уже из PDF'ов. А если потребуется серьезный постер, то все равно переделывать. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87sjeyd45o@wizzle.ran.pp.ru
Re: CLI vs. GUI
18.05.2012 12:20, Stanislav Vlasov пишет: 18 мая 2012 г., 14:07 пользователь Артём Н. artio...@yandex.ru написал: Поскольку им нужно не только видеть, как выглядит текст сейчас, но и понимать что с ним будет происходить при некоторых изменениях (например при переформатировании на другую ширину) и быть уверенными что от этого смысл не потеряется. АН И, всё-таки, GUI... :-) Конкретно в этой задаче GUI как раз сильно мешает. Особенность человеческой психики, ничего личного. Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. Как-раз для HTML, GUI необходим. Если, конечно, вы не рассчитываете на то, что все ваши пользователи используют lynx, links, w3m или подобное. Не совсем так. GUI здесь необходим, если вы разрабатываете _дизайн_ страницы. Если же требуется написать её содержимое - здесь нужен редактор, который умеет разметку. Или даже достаточно отконвертировать документ откуда-то еще, дополнив элементами, созданными дизайнером для приведения внешнего вида к нужным кондициям. Да, согласен, в этом случае GUI не всегда нужен, но страница может включать иллюстрации, а специфичный GUI (например, специально для этого созданный), позволит более просто содержимое подготовить (например, для Wiki не помешал бы такой, поскольку копаться в справке по wiki специфичным тегам и разметки (ну или искать примеры в коде), ради небольшого изменения (пример - добавление сноски), вряд ли у кого вызовет серьёзный энтузиазм). -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb609d0.60...@yandex.ru
Re: CLI vs. GUI
Артём Н. writes: Меню организуют структуру команд и позволяют быстро найти нужную (они не заменяют горячих клавиш), без использования справки... Представил себе меню emacs со всеми командами. Ужаснулся. Быстро там найти явно ниче нельзя будет. -- With Best Regards, Maksym Tiurin JID:mrko...@jabber.pibhe.com -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m3fwaxs19x@comp.bungarus.info
Re: CLI vs. GUI
On Thu, May 17, 2012 at 09:42:11AM +0400, Артём Н. wrote: Хм... Наверное, пользователь документа - это тот, кто использует документ (пусть даже это сайт, хотя тогда документ - не совсем верно). Тот, кто пишет - писатель или разработчик. браузеры которые слушаются пользователя лучше, чем дизайнера), а человек, который хочет донести до читателя смысл текста. Да, но читателю не нужно видеть разницу. Писатель предоставляет данные и способ их отображения программе-обработчику. Он тоже использует интерфейс, но уже другой. И, естественно, с другим уровнем детализации. Каждому - своё. Это вопрос о возможности модификации контента в широком смысле. Корпорация всегда стремиться затруднить активное использования продуктов своей жизнедеятельности. То есть свести все отношения к паре писатель-читатель. Но, точно также, как и в opensource вне копирайтерских корпораций вопрос использования, и трансформации контента стоит везде. И там где используется CC-SA вопрос о виде пробелов и возможности их дальнейшего использования более чем актуален. Вообще, потеря эмфазы, например, в цитатах, может исказить сегодня их смысл. Поэтому доступ к исходным кодам произведения вполне важен. Этот процесс во многих областях идет. В науке, например, где 90% фальсификаций скрыто за тремя кнопками, пресловутого, ориджина -- тоже. То же самое и GUI. sendmail, emacs, awesome, какой-нибудь, предоставляют каждому широкую возможность модификации продукта прямо через конфигурационные файлы. Любые GUI разом лишат их 90% функциональности. -- Иван Лох -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120517091220.ga10...@nano.ioffe.rssi.ru
Re: CLI vs. GUI
Артём Н. - debian-russian@lists.debian.org @ Thu, 17 May 2012 09:42:11 +0400: Поскольку им нужно не только видеть, как выглядит текст сейчас, но и понимать что с ним будет происходить при некоторых изменениях (например при переформатировании на другую ширину) и быть уверенными что от этого смысл не потеряется. АН И, всё-таки, GUI... :-) Конкретно в этой задаче GUI как раз сильно мешает. Особенность человеческой психики, ничего личного. Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871umjdpym@wizzle.ran.pp.ru
Re: CLI vs. GUI
On Thu, May 17, 2012 at 03:09:05PM +0400, Artem Chuprina wrote: Так что писать на коленке презентацию, которая будет выведена плюс-минус так, как ты ее видишь, еще можно (и то не всегда нужно - видел я А потом потребуется постер или, например, буклет... подобные поползновения печатать объявления в ворде...), а HTML - уже ни в коем разе. -- Иван Лох -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120517151712.ga13...@nano.ioffe.rssi.ru
Re: CLI vs. GUI
15.05.2012 11:12, Victor Wagner пишет: On 2012.05.15 at 10:58:27 +0400, Артём Н. wrote: Так, можно поспорить, что LaTeX (*roff, HTML, Markdown, etc.) — нагляднее WYSIWYG. Три вида пробелов в HTML (блин, о ensp; я даже не знал). Каждый имеет определённые особенности в некоторых условиях, при отображении. Пользователю нужно видеть пробел. Ему не нужно знать какой закорючкой в языке разметки Кого вы тут считаете пользователем? Читателя готового сформатированного текста на айпаде? Или все-таки человека, который документ ПИШЕТ? Хм... Наверное, пользователь документа - это тот, кто использует документ (пусть даже это сайт, хотя тогда документ - не совсем верно). Тот, кто пишет - писатель или разработчик. Тому, кто документ пишет, принципиально видеть разницу между неразрывным пробелом и обычным, особенно если это не веб-дизайнер, гордящийся тем, что запретил пользователям увеличивать шрифт (не зная о том, что есть браузеры которые слушаются пользователя лучше, чем дизайнера), а человек, который хочет донести до читателя смысл текста. Да, но читателю не нужно видеть разницу. Писатель предоставляет данные и способ их отображения программе-обработчику. Он тоже использует интерфейс, но уже другой. И, естественно, с другим уровнем детализации. Каждому - своё. Поэтому все опытные пользователи WYSIWYG текстовых процессоров, которых я знаю, всегда включают режим отображения невидимых символов в LibreOffice/Microsoft Office или окно разметки в WordPerfect. Поскольку им нужно не только видеть, как выглядит текст сейчас, но и понимать что с ним будет происходить при некоторых изменениях (например при переформатировании на другую ширину) и быть уверенными что от этого смысл не потеряется. И, всё-таки, GUI... :-) -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb48fb3.4020...@yandex.ru
Re: CLI vs. GUI
GUI хорош для одних вещей, CLI для других. В сущности скрипты которые мы пишем позволяют нам АВТОМАТИЗИРОВАТЬ некоторые задачи. В этом их суть, их эго если хотите. Если брать чисто командную строку, суть так или иначе сводится к скриптам и алиасам. Долбить постоянно строку из 300 символов вряд ли кто хочет. А вот создание текстовых документов с некоторой графикой и средней степенью сложности форматирования, текстовые GUI процессоры, весьма и весьма хороши. И опять же, да, не отображаемые символы наше всё. -- Константин Фадеев
CLI vs. GUI
Артём Н artio...@yandex.ru writes: 14.05.2012 18:50, Ivan Shmakov пишет: Не всегда. Прописать длинное правило дольше, менее наглядно, сложнее (больше всего надо помнить и вспоминать), чем использовать GUI, а вероятность допустить ошибку выше. Хм. Есть большая разница между « », « » и « ». Наглядно? А если так: « », «nbsp;» и «ensp;»? Причём тут интерфейс? Это не к «интерфейсам», но к «наглядности.» Так, можно поспорить, что LaTeX (*roff, HTML, Markdown, etc.) — нагляднее WYSIWYG. Гуй нужен для создания визуального представления для человека. Больше ни для чего. Ага. Вот этот ГУЙ, как-раз только эту задачу и выполняет. Это и нравится. Кстати, CLI тоже нужен только для взаимодействия с человеком. Здесь речь не столько о GUI vs. CLI, сколько о «меню» vs. «язык программирования.» Основная проблема «типовых» GUI — невозможность «записать» последовательность команд, отданных пользователем, для последующего повторного использования. В тех же случаях, когда такая возможность предоставляется (через определение «макрокоманд»), записанную последовательность нередко нельзя /параметризовать/. В случае с GUI, о котором речь, эти проблемы не стоят. :-) Почему? Напротив, при использовании языков, производных от POSIX Shell, все эти возможности, как правило, в наличии. Это проблемы конкретного интерфейса. Нужен язык - достаточно встроить движок в интерфейс. Конечно. Но если мы создаем команднострочное приложение, то язык мы получаем «бесплатно», в то время как при создании приложения с графическим интерфейсом язык требует отдельного внимания. Как показывает практика, в подавляющем большинстве случаев, «проблемы advanced users разработчиков не волнуют», поэтому «возможность» добавить язык к GUI-приложению остается лишь возможностью. Впрочем, с учетом появления Ubuntu HUD, не исключено, что CLI обретет «вторую жизнь» в рамках ныне существующей «GUI-инфраструктуры.» o.O Фигасе. Посмотрел что такое. Ну стоит у меня ubiquity в iceweasel (в репозитории увидел и решил посмотреть, что такое). Я даже помню, как он вызывается, но не пользуюсь. Есть подозрение, что ихний HUD постигнет та же учесть, что и десяток (или сотню?) подобных велосипедов. Возможно. Но, на мой взгляд, запомнить название команды^W пункта меню куда проще, чем название /и/ положение оного. --cut: http://tourlib.net/books_others/gates_doroga_04.htm -- Но графический пользовательский интерфейс недостаточно прост для будущих систем. Мы столько всего размещаем на экране, что начинаем путаться в программах или функциях, применяемых от случая к случаю. Все эти возможности хороши для людей знающих, а к среднему пользователю машина должна быть дружелюбнее, иначе ему с ней очень неуютно. […] --cut: http://tourlib.net/books_others/gates_doroga_04.htm -- […] -- FSF associate member #7257 -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/868vgurmq3.fsf...@gray.siamics.net
Re: CLI vs. GUI
15.05.2012 10:18, Ivan Shmakov пишет: Артём Н artio...@yandex.ru writes: 14.05.2012 18:50, Ivan Shmakov пишет: Не всегда. Прописать длинное правило дольше, менее наглядно, сложнее (больше всего надо помнить и вспоминать), чем использовать GUI, а вероятность допустить ошибку выше. Хм. Есть большая разница между « », « » и « ». Наглядно? А если так: « », «nbsp;» и «ensp;»? Причём тут интерфейс? Это не к «интерфейсам», но к «наглядности.» Так, можно поспорить, что LaTeX (*roff, HTML, Markdown, etc.) — нагляднее WYSIWYG. Три вида пробелов в HTML (блин, о ensp; я даже не знал). Каждый имеет определённые особенности в некоторых условиях, при отображении. Пользователю нужно видеть пробел. Ему не нужно знать какой закорючкой в языке разметки (предназначенном для визуального отображения), пробел рисуется. В правильно спроектированном интерфейсе (пусть даже это 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 debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fb1fe93.2020...@yandex.ru
Re: CLI vs. GUI
On 2012.05.15 at 10:58:27 +0400, Артём Н. wrote: Так, можно поспорить, что LaTeX (*roff, HTML, Markdown, etc.) — нагляднее WYSIWYG. Три вида пробелов в HTML (блин, о ensp; я даже не знал). Каждый имеет определённые особенности в некоторых условиях, при отображении. Пользователю нужно видеть пробел. Ему не нужно знать какой закорючкой в языке разметки Кого вы тут считаете пользователем? Читателя готового сформатированного текста на айпаде? Или все-таки человека, который документ ПИШЕТ? Тому, кто документ пишет, принципиально видеть разницу между неразрывным пробелом и обычным, особенно если это не веб-дизайнер, гордящийся тем, что запретил пользователям увеличивать шрифт (не зная о том, что есть браузеры которые слушаются пользователя лучше, чем дизайнера), а человек, который хочет донести до читателя смысл текста. Поэтому все опытные пользователи WYSIWYG текстовых процессоров, которых я знаю, всегда включают режим отображения невидимых символов в LibreOffice/Microsoft Office или окно разметки в WordPerfect. Поскольку им нужно не только видеть, как выглядит текст сейчас, но и понимать что с ним будет происходить при некоторых изменениях (например при переформатировании на другую ширину) и быть уверенными что от этого смысл не потеряется. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120515071220.ga5...@wagner.pp.ru
