Тривиальный пример. В Visual Studio .Net появилась функция — Replace In Files. Очень хорошо! Можно сделать глобальный search/replace по всем файлам. Но на практике, нам автоматического search/replace как правило недостаточно, требуется, например, поправить форматирование при этом. И вот здесь сразу наступает "приплыли". Функция search/replace в чистом виде довольно бесполезна. Лично мне она нужна крайне редко. Гораздо чаще требуется search,replace,поправить-что-то-рядом. В студии есть кнопки F3 и Ctrl-C/Ctrl-V — я ими и пользуюсь в пределах одного файла. Но мне надо точно такую же функцию, но по все файлам, иначе говоря Find Next In Files. А ее-то как раз и нету.

Получается два сценария решения задачи.
1. Находим все вхождения (Find In Files).
2. Double-click в нижнем окне (Find Results 1)
3. Нажимаем F3, чтобы слово выделилось (не вручную же его селектировать)
4. Нажимаем Ctrl-V
5. Правим что-то вокруг (как правило, выравниваем форматирование).
6. Втираем 2...5 до полного удовлетворения.

Второй сценарий не менее тоскливый.
1. Запускаем Replace In Files (Ctrl-Shift-H).
2. Нажимаем Find Next и далее — Replace.
3. Пытаемся что-то еще поправить в тексте и обнаруживаем, что не можем — окно диалога модальное.
4. Матюгаемся, нажимаем Esc, правим.
6. Снова нажимаем Ctrl-Shift-H и снова матюгаемся — в поле "Find What" у нас теперь совсем не то, что нам нужно (оно "любезно" подставило нам то, что под курсором). Ну, не говоря уже о таких "мелочах", что значения "Match case" и "Match whole word" каждый раз сбрасываются.

Можно возразить, что "это всего лишь жалкий частный случай". Но ведь весь интерфейс состоит из этих "частных случаев"! При этом, уровень халтурности интерфейса виден сразу, как только пытаешься решить задачу, хоть на 0.1% отступающую от стандартной. Поэтому я и говорю, что хороший ГУИ — задача очень сложная, даже на простейших вещах. А основная масса "кумаров раджешей" даже им не подозревает, что при разработке ГУИ надо много думать. Отсюда и дурная репутация программистов ГУИ.

Здравствуйте, McSeem2, Вы писали:

MS>Тривиальный пример. В Visual Studio .Net появилась функция — Replace In Files. Очень хорошо! Можно сделать глобальный search/replace по всем файлам. Но на практике, нам автоматического search/replace как правило недостаточно, требуется, например, поправить форматирование при этом. И вот здесь сразу наступает "приплыли". Функция search/replace в чистом виде довольно бесполезна. Лично мне она нужна крайне редко. Гораздо чаще требуется search,replace,поправить-что-то-рядом. В студии есть кнопки F3 и Ctrl-C/Ctrl-V — я ими и пользуюсь в пределах одного файла. Но мне надо точно такую же функцию, но по все файлам, иначе говоря Find Next In Files. А ее-то как раз и нету.

В Source Insight это сделано очень удобно

Вместо double-click в нижнем окне жми F8 / Shift+F8 — поиск следующего-предыдущего найденого.

Здравствуйте, McSeem2, Вы писали:

MS>наче говоря Find Next In Files. А ее-то как раз и нету.

Вообще-то есть. Более того доступна по F8 после первого поиска в диалоге.

3. Пишем макрос...
4. Реплэйсим, а потом РеШарпером форматируем.
5. Пишем мелкий прокт на Шарпе или Жлабэйсике и получаем вообще все что хочешь. Хотя при наличии макросов смысла в нем не так много. Ну, разве что предпочиташь Шарп Жлабэйсику.

MS>Можно возразить, что "это всего лишь жалкий частный случай". Но ведь весь интерфейс состоит из этих "частных случаев"! При этом, уровень халтурности интерфейса виден сразу, как только пытаешься решить задачу, хоть на 0.1% отступающую от стандартной.

Или когда танцор начинает пинать на гениталии.

MS> Поэтому я и говорю, что хороший ГУИ — задача очень сложная, даже на простейших вещах. А основная масса "кумаров раджешей" даже им не подозревает, что при разработке ГУИ надо много думать. Отсюда и дурная репутация программистов ГУИ.

Думаю, что при разработке ГУИ многие очень сильно думают. Вот только не все кто пользуется этими ГУИ тоже хотят думат. Им подавай факсовую кнопку. Чтобы нажал и все само.

Здравствуйте, VladD2, Вы писали:


VD>Или когда танцор начинает пинать на гениталии.
+

MS>> Поэтому я и говорю, что хороший ГУИ — задача очень сложная, даже на простейших вещах. А основная масса "кумаров раджешей" даже им не подозревает, что при разработке ГУИ надо много думать. Отсюда и дурная репутация программистов ГУИ.

VD>Думаю, что при разработке ГУИ многие очень сильно думают. Вот только не все кто пользуется этими ГУИ тоже хотят думат. Им подавай факсовую кнопку. Чтобы нажал и все само.
+

Здравствуйте, McSeem2, Вы писали:

/* поскипано */

Знаете, Максим, у Вас проблем с компьютером больше, чем, скажем, у бухгалтера. Ставите задачи типа "а напиши ка за меня программу". Думаю, что все очень выиграют, если Вы сами придете работать в MS и научите их там как надо писать GUI.

MS>Можно возразить, что "это всего лишь жалкий частный случай". Но ведь весь интерфейс состоит из этих "частных случаев"! При этом, уровень халтурности интерфейса виден сразу, как только пытаешься решить задачу, хоть на 0.1% отступающую от стандартной. Поэтому я и говорю, что хороший ГУИ — задача очень сложная, даже на простейших вещах. А основная масса "кумаров раджешей" даже им не подозревает, что при разработке ГУИ надо много думать. Отсюда и дурная репутация программистов ГУИ.

Здравствуйте, VladD2, Вы писали:

VD>Думаю, что при разработке ГУИ многие очень сильно думают. Вот только не все кто пользуется этими ГУИ тоже хотят думат. Им подавай факсовую кнопку. Чтобы нажал и все само.

Ты не понял. Мне как раз не надо чтоб "все само". Хороший ГУИ — это не тот, который навороченный, а тот, который хорошо продуман. По теме — меня вполне устраивает, как реализован поиск в пределах одного файла. То есть, Find/Find Next. Почему бы поиск во всех фалах не сделать идентичным образом? Это было бы логично и правильно. Но об этом просто-напросто не подумали и никакого рационального объяснения этому не существует.

Здравствуйте, ArtemGorikov, Вы писали:

AG>Знаете, Максим, у Вас проблем с компьютером больше, чем, скажем, у бухгалтера. Ставите задачи типа "а напиши ка за меня программу". Думаю, что все очень выиграют, если Вы сами придете работать в MS и научите их там как надо писать GUI.

По существу возражения есть? Я лишь привел простейший пример нелогичности и недоработки. На самом деле подобных ляпов — вагон и маленькая тележка. То, что можно писать макросы на васике — это, конечно хорошо, но это ни в коем случае не отменяет необходимости тщательно полировать чисто кнопочно-мышиную часть. И вот с этим как раз серьезные проблемы.

Ещё одна халтура — окно изменения путей к include директориям. Очень неудобный resize. VS2005 beta2 продолжает эти традиции.

Ещё одна халтура — окно изменения путей к include директориям. Очень неудобный resize. VS2005 beta2 продолжает эти традиции.

Здравствуйте, McSeem2, Вы писали:

MS>По существу возражения есть? Я лишь привел простейший пример нелогичности и недоработки. На самом деле подобных ляпов — вагон и маленькая тележка. То, что можно писать макросы на васике — это, конечно хорошо, но это ни в коем случае не отменяет необходимости тщательно полировать чисто кнопочно-мышиную часть. И вот с этим как раз серьезные проблемы.

Не знаю скока разработчиков пользуются Студией, но я бы хотел посмотреть на интерфейс и функционал той АППЛИКУХИ (иначе ее назвать не магу) которая бы удовлетворила желание и функц. потребности всех этих людей да еще и именно так как ОНИ того хотят ( не все же мы одинаковы )... Ну не каждый же день вы этим риплейсом по фйлам занимаетесь! Да и F8 отлично работает. А вообще вот в студии и аутокомплит не сильно продвинут ( откуда Решарпер, Ассист и остальные ) и автоинкремента версиий нет в VC, и ...

Здравствуйте, ArtemGorikov, Вы писали:

AG>Думаю, что все очень выиграют, если Вы сами придете работать в MS и научите их там как надо писать GUI.
Кстати да! Как минимум гуи станет полностью векторным и шибко красиво и качественно антиалиаснутым, что в общем-то давным давно пора, в том числе и с точки зрения юзабилити.

А по теме, ИМХО студия слишком навороченная от того и все проблемы.

Здравствуйте, Рома Мик, Вы писали:

AG>>Думаю, что все очень выиграют, если Вы сами придете работать в MS и научите их там как надо писать GUI.
РМ>Кстати да! Как минимум гуи станет полностью векторным и шибко красиво и качественно антиалиаснутым, что в общем-то давным давно пора, в том числе и с точки зрения юзабилити.

Вы будете смеяться, но как раз сейчас некий Matthew MacLaurin интенсивно зазывает меня работать в MSX (Microsoft User Experience) group.

Здравствуйте, McSeem2, Вы писали:
MS>Вы будете смеяться, но как раз сейчас некий Matthew MacLaurin интенсивно зазывает меня работать в MSX (Microsoft User Experience) group.
Лично я был бы очень рад узнать о том, что ты туда перешел

Здравствуйте, Sinclair, Вы писали:

S>Лично я был бы очень рад узнать о том, что ты туда перешел

Спасибо за добрые слова!

Честно говоря, я бы больше хотел вернуться к чему-то более электронно-механическому. Ну, например, изобрести что-то новое в UI. И вообще, я изменил электронике с механикой только лишь потому, что в советские времена не было денег на хорошие транзисторы и конденсаторы.
Но я прекрасно понимаю свою ограниченность и поэтому... А собственно, что "поэтому"? Ну в общем, не знаю, но чувствую, что крутой поворот может больно ударить. Но это говорит моя трусливость.

Здравствуйте, McSeem2, Вы писали:
MS>Честно говоря, я бы больше хотел вернуться к чему-то более электронно-механическому. Ну, например, изобрести что-то новое в UI.
Знаешь, то новое, чего остро не хватает в соврменном UI — это нормальной, полноценной графики.

Попробую изложить свою точку зрения:
1. Принципиально важна векторная графика.
Это позволило бы эффективно использовать устройства вывода для самых разных разрешений.
2. Принципиально важна высокая производительность. До сих пор неудачная графика жрет неприлично много ресурсов процессора. Если в Delphi 7 включить галочку "показывать прогресс компиляции", то он будет компилять раза в три дольше. Бред.
Тут есть на самом деле два аспекта:
2.1. Высокая низкоуровневая производительность. Типа рисовать сглаженный шрифт со скоростью миллион символов в секунду, а не тысячу.
2.2. Удачная вычислительная модель, которая не выполняет лишних перерисовок. К слову: вплоть до Windows2000, скорость перерисовки Progress Bar из Common Controls линейно падала с ростом прогресса. Пацаны не знают, что можно перерисовывать дельту. Особенно приятно, что эта зараза честно перерисовывается даже тогда, когда его Position изменяется на столь малую величину, что пиксельная граница не движется.
Вот так делать ни в коем случае не надо.

3. Важна возможность композиции графики.
Затрудняюсь внятно объяснить, но это про иконки. Вот сейчас у нас есть возможность добавлять к изображению из ImageList оверлейное изображение. Идея неплоха, но хочется ее рвзвить. Ну вот типа того, что если у нас есть, к примеру, пестня. У пестни, ясно, есть иконка. Так вот в 99% случаев у нас будут производные вещи, типа "фолдер с пестнями" или "группа песен". Есть официальная рекомендация от МС про то, как должен выглядеть "фолдер с пестнями". Вместо этой редко читаемой инкунабулы надо дать стандартный способ скомбинировать иконку "фолдер" с иконкой "пестня". Естественно а) векторно, т.е. для любого разрешения и б) многослойно и альфаканально, т.к. уже в XP "фолдер с пестнями" должен всовывать иконку пестни между задней стороной и полупрозрачной передней.

Такие средства позволят
а) избегать комбинаторного взрыва количества необходимых иконок. Это должно привести к росту качества иконсетов. Потому как сейчас как посмотришь на необходимость отрисовать 150 иконок — так руки и опускаются, и воруются первые попавшиеся более-менее похожие иконки. А так дезигнер сможет тщательно отполировать 3-4 основных иконки, а остальные получить на халяву при помощи композера
б) лучше поддерживать единство стиля. Т.е. допустим у нас есть некий прикладной объект, для которого есть иконка. При смене системной темы сменится иконка "фолдер", и автоматически все иконки "фолдер с ..." приобретут необходимый вид.

4. Важна удачная модель позиционирования. Абсолютное позиционирование суть великое зло. Оно имеет смысл только для объектов с разными Z-координатами. Я пока себе слабо представляю, как должна работать эта модель в свете векторной графики — не вполне понятно, как кто кому будет подчиняться, и что к каким точкам будет привязано. Ну вот типа в visio есть какие-то средства по заякориванию одних объектов за другие. Лично мне удается сделать то, чего я хочу, лишь в исключительных случаях. Либо я дебил, либо надо как-то модель пересматривать, либо на самом деле модель и так нормальная при программном доступе, и просто UI к ней сейчас не дает возможности контролировать привязки с достаточной точностью.

Здравствуйте, Sinclair, Вы писали:

S>2. Принципиально важна высокая производительность. До сих пор неудачная графика жрет неприлично много ресурсов процессора. Если в Delphi 7 включить галочку "показывать прогресс компиляции", то он будет компилять раза в три дольше. Бред.
S>Тут есть на самом деле два аспекта:
S>2.1. Высокая низкоуровневая производительность. Типа рисовать сглаженный шрифт со скоростью миллион символов в секунду, а не тысячу.

Здесь мы затрагиваем аспект аппаратного ускорения. Все, что достигнуто — это быстрая отрисовка треугольников и текстур. И даже современные вертексные и пиксельные шейдеры нисколько не помогают нарисовать банальную линию в 10 пикселов шириной с round-join. Ситуация вообще смешная. Чтобы нарисовать кривую Безье, приходится генерировать уйму мелких треугольников. И делается это на CPU, а не на GPU. Но лично я умею растеризовать эту кривую быстрее, чем любой тесселятор. А после тесселятора надо еще загнать эти треугольники в GPU и подождать, пока он их нарисует. Следовательно, даже современные GPU совершенно бесполезны для высококачественной векторной графики. Все ушли в сторону видеоэффектов и забыли про собственно графику. А виновата в этом та же самая mass-media, накачивающая народ жвачной попсой.

S>2.2. Удачная вычислительная модель, которая не выполняет лишних перерисовок. К слову: вплоть до Windows2000, скорость перерисовки Progress Bar из Common Controls линейно падала с ростом прогресса. Пацаны не знают, что можно перерисовывать дельту. Особенно приятно, что эта зараза честно перерисовывается даже тогда, когда его Position изменяется на столь малую величину, что пиксельная граница не движется.
S>Вот так делать ни в коем случае не надо.

Это не совсем так. Нет ничего плохого в том, чтобы перерисовать всю сцену. Инкрементальная перерисовка может работать даже медленнее (!), поскольку является нетривиальной задачей для общего случая. Инкрементальная перерисовка важна только в случае узкого канала — и не более того. А AGP — это очень широкий канал. Проблема не в том, что перерисовывается слишком много, а в том, что это делается слишком часто. В тех же Progress Bar или Delphi больше 10 FPS и не нужно. А выполняется это наверняка тысячи раз в секунду. То есть, налицо гораздо более банальная халтура, поскольку искусственно понизить frame rate — задача тривиальная, в отличие от инкрементальной перерисовки.

Вот, другой пример: http://antigrain.com/stuff/particle_demo2.exe
Здесь 200 "шайбочек" на моем древнем P4-1.9 уже дают 100 FPS при использовании bitmap cache. Вся сцена каждый раз формируется с нуля. При этом нет ни HW acceleration, ни MMX/SSE оптимизации.

S>3. Важна возможность композиции графики.
S>Затрудняюсь внятно объяснить, но это про иконки. Вот сейчас у нас есть возможность добавлять к изображению из ImageList оверлейное изображение. Идея неплоха, но хочется ее рвзвить. Ну вот типа того, что если у нас есть, к примеру, пестня. У пестни, ясно, есть иконка. Так вот в 99% случаев у нас будут производные вещи, типа "фолдер с пестнями" или "группа песен". Есть официальная рекомендация от МС про то, как должен выглядеть "фолдер с пестнями". Вместо этой редко читаемой инкунабулы надо дать стандартный способ скомбинировать иконку "фолдер" с иконкой "пестня". Естественно а) векторно, т.е. для любого разрешения и б) многослойно и альфаканально, т.к. уже в XP "фолдер с пестнями" должен всовывать иконку пестни между задней стороной и полупрозрачной передней.

Здесь мы просто имеем каменный век в эпоху авиалайнеров. Функция WinAPI AlphaBlend() появилась только в Win2K, то есть в 1999 году! Но вообще-то, кроме AlphaBlend существует еще 23 классических операций смешивания цветов:
http://www.w3.org/TR/2004/WD-SVG12-20041027/rendering.html#comp-op-prop
Все эти операции были специфицированы еще в 80-лохматых годах. Ну и где это все в виде API?!
Вот, я сделал и ничего в этом "страшного-ужасного" нет:
http://antigrain.com/demo/compositing.zip

S>Такие средства позволят
S>а) избегать комбинаторного взрыва количества необходимых иконок. Это должно привести к росту качества иконсетов. Потому как сейчас как посмотришь на необходимость отрисовать 150 иконок — так руки и опускаются, и воруются первые попавшиеся более-менее похожие иконки. А так дезигнер сможет тщательно отполировать 3-4 основных иконки, а остальные получить на халяву при помощи композера
S>б) лучше поддерживать единство стиля. Т.е. допустим у нас есть некий прикладной объект, для которого есть иконка. При смене системной темы сменится иконка "фолдер", и автоматически все иконки "фолдер с ..." приобретут необходимый вид.

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

С векторной графикой ситуация гораздо сложнее. Мы имеем кучу устоявшихся растровых форматов — GIF, JPG, PNG и ни одного векторного!
Все, что есть реально используемого — это Flash. Но чем его рисовать и чем его рендерить? Сам формат является настолько нетривиальным, что фактически ничем, кроме средств самой Macromedia (ныне Adobe) мы воспользоваться не можем. Ни для создания, ни для отрисовки.
Есть SVG — но это такой монстр, что для имплементации даже TinySVG требуется пара-тройка человеко-лет. XAML — не лучше. Фактически он с SVG и содран — еще одна попытка объять необъятное. В то же время, надо что-то простейшее — базовые фигуры, кривые Безье, текст и градиенты. Но так, чтобы это было легко воспроизводимо и хорошо стандартизовано.

S>4. Важна удачная модель позиционирования. Абсолютное позиционирование суть великое зло. Оно имеет смысл только для объектов с разными Z-координатами. Я пока себе слабо представляю, как должна работать эта модель в свете векторной графики — не вполне понятно, как кто кому будет подчиняться, и что к каким точкам будет привязано. Ну вот типа в visio есть какие-то средства по заякориванию одних объектов за другие. Лично мне удается сделать то, чего я хочу, лишь в исключительных случаях. Либо я дебил, либо надо как-то модель пересматривать, либо на самом деле модель и так нормальная при программном доступе, и просто UI к ней сейчас не дает возможности контролировать привязки с достаточной точностью.

А здесь мы имеем каменный век в UI графических редакторов. Пока что я не видел ни одного векторного редактора, в котором бы можно заселектировать не объекты целиком, а отдельные точки этих объектов. Вот тривиальный пример — есть диаграмма с неким кружочком и подходящими к нему стрелками. Задача — передвинуть этот кружочек вместе с концами стрелок.
Кстати, подобные простейшие привязки неплохо было бы иметь и в самих векторных форматах. Так, чтобы при простейшей анимации мне не требовалось передвигать кучу координат. Но ни в SVG, ни в XAML этим даже и не пахнет. Никому это даже в голову не пришло.

Начинать надо со спецификации и стандартизации векторного формата. Вот, есть некая попытка узаконить: http://www.khronos.org/openvg/
И в принципе, спецификация вполне разумная. Но сколько лет пройдет, прежде чем подобный API будет доступен в любой видеокарте и любой мобиле? В принципе, AGG покрывает весь этот API. Осталось совсем чуть-чуть — встроить его во все видеокарты...