Почему открытые приложения не имеют хорошего дизайна

> cmd.exe создавался как 32-битная замена command.com. Который создавался в мире, где 640К достаточно для всех. А для серьезных парней у МС сейчас есть scripting host с более другими языками. Ах, да, совсем забыл - еще у них есть семейство VB* ;)

ну с этим трудно не согласиться.

// wbr

PS Поскольку я смотрел for /? через ssh от cygwin, то вывод получился обрезанным. Пришлось сделать в цигвиновском баше "cmd.exe for /? | less". Долго думал как оно должно выглядеть в родном cmd.exe

>НО чего никогда не отнять у них, так это ДИЗАЙН - он всегда был на высоте.

Дизайн из серии "а еще мы сюда собачку забабахаем", конечно является там апофеозом всего.

> Я лично не закрываю окна IM людей, которые в онлайне (ну разве совсем тема исчезла) - и весь диалог в irc режиме отражается - чтобы сразу видеть о чем это мы говорили или поскролить повыше если надо. А так он висит в трее. Еще к стати класненная вещь в Kopete, которая отображает мессагу в балуне с кнопками ok/ignore, и если тебе просто хочет кто-то отспамить пару слов типа "ok, сделаю" без ответа - не надо открывать окно - просто последовательно просматриваешь его в балуне и не паришся взлетающим окном.

o ya! а еще в kopete/ICQ траблы с кодировками на уровне ДНК разработчиков... ;) впрочем, это вторично.

// wbr

> В отдельно взятом баше перенаправление ввода/вывода и pipeline лишены всякого смысла. А зато в виндовз форка нет!

а оно надо? там и сигналов то-же нет [может оно и к лучшему]. в POSIX допустим нет WaitForMultipleObjects(), что его явно не красит :-/

// wbr

>o ya! а еще в kopete/ICQ траблы с кодировками на уровне ДНК разработчиков... ;) впрочем, это вторично.

Ну - транскодинг всем контактам пришлось указать. А какие ище? Уже вроде как не падает от русского ввода.

> и? все-таки различайте конкретный интерпретатор и среду исполнения в целом.
> с таким же успехом и cmd можно дополнить хотя бы cygwin и получить то-же самое, что bash, лишь синтаксис немного другой.

Ха, cmd можно дополнить - а bash всегда дополняется средой исполнения (на всех стречаемых мною компах). Чувствуете разницу ? Поэтому bash не нужно повторять функционал двух десятков стандартных unix утилит так как он вместе с ними инсталлируется.

Командная строка от МС много лет специально была такой, чтобы вселить ужас перед командной строкой у пользователей которые не видели bash и т п

>>а оно надо?

make под Цигвином никогда не делал? Вот и не делай. Мучительное занятие.

>>в POSIX допустим нет WaitForMultipleObjects()

реаолизации тредов в различных операционных системах (даже посикс совместимых в остальном) настолько различны, что не поддаются стандартизации.

> make под Цигвином никогда не делал? Вот и не делай. Мучительное занятие.

нет, слава богу, не делал. а зачем ?! :-O если же nmake & K.

> реаолизации тредов в различных операционных системах (даже посикс совместимых в остальном) настолько различны, что не поддаются
стандартизации.

ну почему же, в пределах конкретно заданного класса операционных систем - например, MS Windows - они очень даже поддаются стандартизации. на и в пределах POSIX совместимых систем в общем то то-же. в пределах всей платены Земля по всей видимости нет, пока что не поддаются. c'est la vie. впрочем, не очень то и хотелось.

// wbr

>зачем же он тогда вообще создавался? :) впрочем, вопрос скорее риторический.

Вы видимо забыли .. про любимый девиз - "совместимость снизу вверх" Уродец - наследие прошлого.

Не обязательно в каждую, достаточно в гномовскую конфигурялку для шрифтов перенести линейку для измерения dpi из огнелиса.

>> в POSIX допустим нет WaitForMultipleObjects()
> реаолизации тредов в различных операционных системах (даже посикс совместимых в остальном) настолько различны, что не поддаются стандартизации.

btw история с аналогом WFMO в *INX API к стандартизации потоков как таковой особого отношения IMHO не имеет. pthreads вполне даже стандартизованы на уровне POSIX и многие ему следуют. и вопрос не столько в стандартизации, сколько в ДНК и тяжелом наследнии изначально однопоточной системы, дизайн которой не предпологал ничего, кроме процессов :) трудно скрещивать нескрестимое, кто спорит.

// wbr

>>а зачем

Просто в качестве примера программы активно использующей форки. Поскольку цигвин эмулирует форк своими средствами, то скорость сборки любых исходников падает на порядок. Не уверен, что nmake в этом смысле лучше.

>>в пределах конкретно заданного класса операционных систем - например, MS Windows - они очень даже поддаются стандартизации.

И в Windows 3.11 в том числе?

>ну никто не мешает в том же MSO обновить Equation до полного MathType. не так уж и дорого, порядка $100 баксов. http://www.dessci.com/en/products/mathtype/ впрочем, отнюдь не исключаю, что есть и заметно более продвинутые набивщики формул.

А смысл? Сильно удобней он от этого не становится. Из продвинутых набивщиков формул только WinEDT (аналог Kile).

> Просто в качестве примера программы активно использующей форки. Поскольку цигвин эмулирует форк своими средствами, то скорость сборки любых исходников падает на порядок.

ну это уже скорее проблемы gmake и его заточенности на fork(2), не так ли? а отнюдь не win32 API.

> Не уверен, что nmake в этом смысле лучше.

не знаю, врать не буду. мне никогда не приходило в голову сравнивать их в скорости исполнения [как-то без надобности].

>> в пределах конкретно заданного класса операционных систем - например, MS Windows - они очень даже поддаются стандартизации.
> И в Windows 3.11 в том числе?

ну да, вы еще DOS + DPMI вспомните для проформы бо, например, в Pharlap DPMI Extender да и в полном DOS4GW [AFAIR] то-же были свои реализации многозадачности :) однако, тыщу лет уже нет ничего, кроме win32 API и в нем как раз с этим куском API все более-менее стабильно.

// wbr

> А смысл? Сильно удобней он от этого не становится. Из продвинутых набивщиков формул только WinEDT (аналог Kile).

вполне возможно, спорить не буду. я сам никогда не пользовался ни коммерческим MathType ни WinEDT. для сравнительно простых вещей мне вполне хватало обычного Equation.

// wbr

>Наверно, после того как увидел, что они реализовали мечту Раскина о калькуляторе, который не нужно специально запускать из дебрей меню.

Эта мечта давно реализована под винду, называется NumLock Calculator, вызывается/прячется нажатием на NumLock (при этом NumLock все равно остается включенным). Очень удобно для тех, кто использует доп. клавиатуру только для ввода чисел (как я, к примеру).

Клацнул NumLock, тут же посчитал что надо, клацнул еще раз --- калькулятор исчез.

Achtung! виндузятники в комментсах!

> Эта мечта давно реализована под винду, называется NumLock Calculator, вызывается/прячется нажатием на NumLock (при этом NumLock все равно остается включенным). Очень удобно для тех, кто использует доп. клавиатуру только для ввода чисел (как я, к примеру).

гы! клевая хреновина, не знал. спасибо за наводку :)

// wbr

Да уж, клевая. Пожалуй, единственное, чего мне действительно не хватало поначалу в Линуксе. Пока не переучился на другой хоткей, вызывающий KCalc =)

Интересно, насколько сложно реализовать подобное поведение NumLock-а (с запуском произвольного приложения) в никсах....

> Интересно, насколько сложно реализовать подобное поведение NumLock-а (с запуском произвольного приложения) в никсах....

да в принципе не сложно. но лениво :) да и зачем он мне нужен то, в putty..?

// wbr

> Перелазить из венды в линукс тяжело, но перелазить из линукса в венду еще тяжелее. По собственному опыту.

+1

Ну хоть подскажи, в каком направлении рыть, мож как-нибудь поковыряюсь.

> в ДНК и тяжелом наследнии изначально однопоточной системы, дизайн > которой не предпологал ничего, кроме процессов :) трудно скрещивать > нескрестимое, кто спорит.

А Вы уверены, что кроме процессов ещё что-то нужно? Почитайте AOUP Рэймонда, если собственный опыт это ещё не подсказал.

На винде так популярны потоки потому что создание процессов гораздо тяжелее чем в юниксах + убогий IPC. Да плюс кодеры, со времён ДОСа и win95 привыкшие думать о приложении как одном монолитном куске.

Разрабатывать и отлаживать приложение из нескольких процессов несравнимо приятнее и проще. К сожалению, мы в нашем проекте дошли до этого только произведя огромный монолитный кусок сегфолтов.

> Ну хоть подскажи, в каком направлении рыть, мож как-нибудь поковыряюсь.

ну например, посмотри как сделан перехват глобальных хоткеев в KDE :) поковырявшись в ней с пару часиков даже не зная потрохов kdelibs IMHO вполне можно найти. или в сущьности если затачивать под KDE то лучше разобраться, как аттачить в ней глобальные хоткеи. тогда и делать то ничего особо не нужно, разве что сам калькулятор нарисовать.

// wbr

Судя по обилию комментирующих вендузятников, все здравомыслящие люди должны были сделать только один вывод: эта статья была написана только для того чтобы у дрессированых вендузятников из отдела продаж M$ был повод отметиться на http://linux.org.ru/

> А Вы уверены, что кроме процессов ещё что-то нужно? Почитайте AOUP Рэймонда, если собственный опыт это ещё не подсказал.

спасибо, но я как-нибудь обойдусь без опыта комрадо Эрика :) слава богу, что и без него источников вполне достаточно. но не в Эрике вообщем-то дело, это так, лирика.

> На винде так популярны потоки потому что создание процессов гораздо тяжелее чем в юниксах + убогий IPC.

извините, но IPC на Win32 ни чуть не лучше и не хуже, чем IPC на POSIX и предоставляет ту же самую функциональность :)

> Да плюс кодеры, со времён ДОСа и win95 привыкшие думать о приложении как одном монолитном куске.

это уже проблемы кокретный кодеров и на Win32 API оно IMHO никак не сказалось. и чтобы грамотно написать многопоточное приложение [не важно в какой именно среде] нужно иметь весьма неплохой опыт и понимание происходящего.

как раз одноклеточные программисты DOS зачастую очень неуютно себя чувствовали в любой многозадачной системе, а тем более в многопоточной. но это уже то-же в сущности в прошлом.

или вы считаете, что потоки, которые хотя и непросто но тем не менее вполне уверенно входящие в обиход большинства *NIX программистов - это то-же дань DOS & K? :)

> Разрабатывать и отлаживать приложение из нескольких процессов несравнимо приятнее и проще.

не факт, не факт. зависит от конкретного случая.

> К сожалению, мы в нашем проекте дошли до этого только произведя огромный монолитный кусок сегфолтов.

ну у всех бывает. не производите и будет вам счастье :)

// wbr

> "Оккам обкурился чем-то не тем"

"Оккам обкурился где-то не там" тогда уж, чтоб рифму держать :)

или

"Оккам укурился в хлам".

Аллах с ней, рифмой. Оккама жалко. И пользователей cmd.exe

>виртуальные рабочие столы это ни что иное как костыль - удобство их использования крайне сомнительное.

В некоторых случаях и компьютер - костыль, компенсирующий отсутствие мозга. Может, дадите оценку его юзабилити?

Если оставить голый баш, то он по функционалу недалеко ушел от cmd, но зачем пользоваться cmd, всегда в %ComSpec% можно прописать другую более продвинутую оболочку. Единственно чего не сделать, не прикрутить полупрозрачность в консоль, значит OpenSource все-таки красивее.

Наконец то обратили внимание что дизайн открытых программ г***о. До mac и windows вам как до луны.

А мне вот пользователей некоторых стандартных для промышленных юниксов шеллов жалко. Помнится, сижу на курсах по аиксу и набираю 'du --max-depth=1', а препод качает головой и говорит, что в аиксе такое не работает. Как оказалось, там много ещё чего полезного нет :)

>Наглая ложь. Не ничего неудобного, есть непривычное.

дело не в "неудобном" - дело в "страшном", и таким страшным является 90% opensource-софта.. и слоновьи виджеты и кнопки, и старые страшные лохматые иконки на фоне gtk1 - и неудобное расположение полей и кнопок в настройках программ (об их форме и размерах я уже и не говорю).. А диалог открытия/сохранения файла в нынешнем гноме - просто издевательство.. Перечислять можно до бесконечности - негатив копится годами..

А кто сказал что в винде и на маках интерфейс этолонен и всем в них удобено работать? К чему боготворить интерфейс? Да дакопатся можно до чего угодно, до любого интерфейса! Хоть до маковского хоть до какого.

> А диалог открытия/сохранения файла в нынешнем гноме - просто издевательство

Страсбургский суд по правам человека всё ещё ждёт искового заявления от плохого танцора в адрес своих ног

Обычно люди, пишущие через запятую макос и виндоуз (особенно в вопросах дизайна) имеют расплывчатое представление либо об одном, либо о другом. Не всегда, конечно, но...

Кстати после выхода win95 в интерфейсе виндовых програм кроме тем, никаких изменений я так и не увидил, вот уж прогрес за 11 лет так прогрес, ах ну да это же эталон удобства!

Ну как же, отсутствие изменений есть стабильность, а потому благо :)))

> Обычно люди, пишущие через запятую макос и виндоуз (особенно в вопросах дизайна)

Если имеется ввиду гуи 95-го и именно macos - то тут можно ставить знак равно бо интерфейс первого был чисто слизан с макосового платинума.

> негатив копится годами..

А сколько лет "страшному" диалогу открытия файлов в гноме ?

От ля... умник нашелся... ну сделай мне в VC пятью кликами мышки желтую на форме кнопку с синей налписью курсивом рамером в 14 пунктов, я засекаю время и иду пить чай... Kdevelop это лимузин, а VC - жалкий запорожец.

> От ля... умник нашелся... ну сделай мне в VC пятью кликами мышки желтую на форме кнопку с синей налписью курсивом рамером в 14 пунктов, я засекаю время и иду пить чай... Kdevelop это лимузин, а VC - жалкий запорожец.

если в MSVC интегрирован Qt, то это сделать ни чуть не сложнее, чем в kdevelop. а может и проще.

а вот заэкспортировать проект в kdevelop - это действительно проблема. не так давно, примерно с месяц назад, я пытался это сделать в последней версии. сотственно экспортировалось дерево исходников openttd. там всех исходников то с гулькин нос, два-три мегабайта на C, не больше. ага.. шуршал kdevelop винтом долго-долго, минут десять как минимум, сожрал всю доступную память плюс своп [256+2x256] после чего грохнулся в корку на полгига. да уж, отличная среда разработки, бесспорно :-/

// wbr

> после чего грохнулся в корку

Но согласись бонбу показал красивую ? А вы все "не имеет хорошего дизайна".

> Но согласись бонбу показал красивую ? А вы все "не имеет хорошего дизайна".

mmm.. чего, пардон, показал?

ps: я слабо себе представляю, какую нужно иметь машину, чтобы ее ресурсов хватило для успешного экспорта в kdevelop чего-то более-менее крупного, например, каких то ~10Мб ACE (код C++). при чем что тот-же MSVC .Net 2003 прекрасно держит текущий проект на C/C++/#C с размером исходников давно переваливших за 100Mb. и шустро сволочь работает, включая поиск по всему дереву и пр. и пр. мелочи жизни и kdevelop, пардон, радом даже не лежало.

// wbr

> cmd.exe для выполнения скриптов?????? При том, что там нет sleep вообще? При отсутствии возможности создавать функции (изврат с goto не считается)? При том, там переменные вычисляются один раз при старте (если не указан правильный setlocal)? Я за последний год чуток поигрался с cmd.exe скриптами - это добавило мне нехилое кол-во седых волос.

+1. Под вендой батники используются с единственной целью - прописать одну или несколько bash -c "...", где "..." - нормальный, правильный скрипт ;)

> make под Цигвином никогда не делал? Вот и не делай. Мучительное занятие.

Ой, да ладно, даже ./configure делать приходилось ;)

Помнится полгодика назад допиливал ccache для применения совместно с M$ cl.exe с понятной целью - так тогда и стало окончательно понятно, что этому хламу даже ccache не в состоянии помочь - в особенности в сочетании с любовью вендавозников генерить вместо нормальных мэйкфайлов какую-то непонятную хрень в XML/еще чем-то там.

> mmm.. чего, пардон, показал?

Красочно офрмленный диалог с баааальшой черной бомбой...

> ну почему же, в пределах конкретно заданного класса операционных систем - например, MS Windows - они очень даже поддаются стандартизации. на и в пределах POSIX совместимых систем в общем то то-же. в пределах всей платены Земля по всей видимости нет, пока что не поддаются. c'est la vie. впрочем, не очень то и хотелось.

Говоря по-русски: "в пределах одной и той же среды исполнения стандартизовать реализацию __чего угодно__ можно за отрезок времени стремящийся к нулю".

> Неправда. Тогда с вашей точки зрения, заучивание хоткеев - адский труд. Что противоречит вам же. Я вам говорю: *поработайте* в MSO2000, XP, а потом в 2007 и сравните. Это оно сначала необычно, а потом скорость работы возрастает в разы.

Сразу ясен уровень вашей квалификации. Скорость может вырасти только у мышевозников. Тот, кто давно и много работает в Word, уже давно перешёл на шорткаты, и ему пох, что там творится в менюшках и на панельках. И это - ПРАВИЛЬНО.