Здравствуйте, VladD2, Вы писали:
VD>Можно ли как-то улучшить отображение шрифтов в WPF?
VD>Пытаюсь прикрутить к интеграции Nemerle с VS 2008 хинты на основе WPF.
VD>При отображении шрифтов тех же размеров, что в обычных хинтах текст читается очень плохо. Даже увеличенный шрифт (Arial 14) выглядит не очень здорово (и при этом занимает намного больше места на экране). Все смазано и причем весьма криво.
Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует.
И справильными шрифтами учитывающими предпочтения юзера.
Здравствуйте, VladD2, Вы писали:
VD>Можно ли как-то улучшить отображение шрифтов в WPF?
VD>Пытаюсь прикрутить к интеграции Nemerle с VS 2008 хинты на основе WPF.
VD>При отображении шрифтов тех же размеров, что в обычных хинтах текст читается очень плохо. Даже увеличенный шрифт (Arial 14) выглядит не очень здорово (и при этом занимает намного больше места на экране). Все смазано и причем весьма криво.
Забавно, я с тем же вопросом. Вот код для начала, надо положить его например в App.OnStartup:
var fontFamily = "Calibri"; // looks really goodvar fontSize = 10.0d * (96d / 72d); // 10 points
TextElement.FontFamilyProperty.OverrideMetadata(typeof(TextElement), new FrameworkPropertyMetadata(new FontFamily(fontFamily)));
TextElement.FontSizeProperty.OverrideMetadata(typeof(TextElement), new FrameworkPropertyMetadata(fontSize));
TextBlock.FontFamilyProperty.OverrideMetadata(typeof(TextBlock), new FrameworkPropertyMetadata(new FontFamily(fontFamily)));
TextBlock.FontSizeProperty.OverrideMetadata(typeof(TextBlock), new FrameworkPropertyMetadata(fontSize));
Это решит проблему, но шрифты в TextBox-ах останутся прежними (класс Control переопределяет метаданные для шрифта и их вышеприведённым макаром не сменишь). Вопрос: как сменить шрифт для наследников класса Control одним махом?
Здравствуйте, VladD2, Вы писали:
VD>Можно ли как-то улучшить отображение шрифтов в WPF?
В 2008 почти никак Хотя ухищрения есть (см. внизу)
В 2010 Beta2 устанавливаешь UseLayoutRounding="True" на корне дерева и TextOptions.TextFormattingMode="Display", станет сильно лучше.
Здравствуйте, Sinix, Вы писали:
S>Спс. Про это в курсе. Но окромя UI в студии есть дофига и больше кода, не имеющего managed api — типа SCC, или работающего ч/з ком врапперы (shell, envDTE). Переписывание — очень много-много работы.
Я не говрил, что все переписано. Но IDE — это и есть на 90% UI. SCC это не так много кода и он далеко не всем нужен. Мне, например, не нужен.
S>Что-то я сомневаюсь что в этом релизе они успеют
Никто и не планировал все переписать. Переписан GUI включая редактор кода, тулбары и т.п. По крайней мере в 1-й бете так было.
Дерево проектов, насколько мене известно, осталось неуправляемым.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, c-smile, Вы писали:
CS>>Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует. CS>>И справильными шрифтами учитывающими предпочтения юзера.
VD>Благодаря этому совету
качество отображения стал приемлемым. Правда шрифты чуть увеличены, но так как хинт стал многоуровневым, то это не является проблемой.
Какая-то кофейная гущща, право слово. И забавный способ определения значения points:
var fontSize = 10.0d * (96d / 72d); // 10 points
это еще чего такое?
VD>Так что единственная проблема — это тормоза при первом показе.
Мда... студия и так не шеволится нонче... А тут ты еще со своим WPF...
VD>При этом то что ты предлагаешь — это нэйтив-длл-и для который еще придется писать обертки и реализовывать функциональность многоуровневости для хинтов (вряд ли она там есть по умолчанию). Так что объем работы получается внушительным, а выходы сомнительны. В общем, легаси код. Вот так вот быстро, оказывается, им можно обжиться .
Это какое-то заблуждение у тебя. В ситуациях когда есть managed/non-managed код (а в UI это всегда так)
выигрывать будет решение у которого меньшее количество переходов (вызовов) managed -> non-managed код.
В случае с htmlayout ты оперируешь десятком вызовов высокоуровневых методов. Вместо потока вызовов CreateBrush, FillRect и пр.
Каждый такой вызов как я понимаю чего-то да стоит.
Re[8]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Sinix, Вы писали:
S>Но вот перспектива "поменяем апи — проблемы у всех разработчиков дополнений" меня абсолютно не втыкает. Очевидно, не втыкает и VSX Team — в EnvDTE не так уж и много изменений.
На сколько я понимаю сап по себе API (как публичный интерфейс) пытаются сохранить для обеспечения совместимости с предыдущими вресиями. Но полной совместимости нет. Тот же ДжетБрэйнс довольно много сил тратит на интеграцию с новой версией.
К слову, в старом АПИ было попросту много не документированного. В новой оно становится документированным, но при этом полностью другим. Примером тому может служить АПИ по работе со смарт-тегами.
S>P.S. А вообще надо уже собраться и поставить... время-время
Согласен. Бэту 1 я поставил и посмотрел, а на вторую как-то времени не хватает. Старею, видимо .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Можно ли как-то улучшить отображение шрифтов в WPF?
Пытаюсь прикрутить к интеграции Nemerle с VS 2008 хинты на основе WPF.
При отображении шрифтов тех же размеров, что в обычных хинтах текст читается очень плохо. Даже увеличенный шрифт (Arial 14) выглядит не очень здорово (и при этом занимает намного больше места на экране). Все смазано и причем весьма криво.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Можно ли как-то улучшить отображение шрифтов в WPF?
VD>Пытаюсь прикрутить к интеграции Nemerle с VS 2008 хинты на основе WPF.
VD>При отображении шрифтов тех же размеров, что в обычных хинтах текст читается очень плохо. Даже увеличенный шрифт (Arial 14) выглядит не очень здорово (и при этом занимает намного больше места на экране). Все смазано и причем весьма криво.
проблемы с шрифтами и отображением иконок починили только в WPF4, который идёт с VS2010 beta2
Re[2]: [WPF] Можно ли улучшить отображение шрифтов?
V>Это решит проблему, но шрифты в TextBox-ах останутся прежними (класс Control переопределяет метаданные для шрифта и их вышеприведённым макаром не сменишь). Вопрос: как сменить шрифт для наследников класса Control одним махом?
Как я понял — это всего лишь задание шрифта Calibri.
Химия с размерами шрифта имеет смысл?
Можно ли это дело просто задать в нужный элемент, а не назначать глобально?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Vladek, Вы писали:
V>... установив нужные свойства.
Можно по подробнее?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: [WPF] Можно ли улучшить отображение шрифтов?
От:
Аноним
Дата:
30.10.09 21:13
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Можно ли как-то улучшить отображение шрифтов в WPF?
Пиши белым по черному фону как в бленде и еще лучше жирным шрифтом — будет довольно готично, но размытие реально меньше заметно.
Кстати, в бленде похоже всплывающие подсказки в коде рендерятся не WPF, уж очень чётко они выглядят по сравнению со всем остальным интерфейсом.
Re[2]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Аноним, Вы писали:
А>Кстати, в бленде похоже всплывающие подсказки в коде рендерятся не WPF, уж очень чётко они выглядят по сравнению со всем остальным интерфейсом.
Блин. Хоть выбрасывай этот WPF и бери банальный броузер.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [WPF] Можно ли улучшить отображение шрифтов?
От:
Аноним
Дата:
30.10.09 22:00
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Блин. Хоть выбрасывай этот WPF и бери банальный броузер.
А зачем там вообще WPF? Нужна какая-то интерактивность от отдельных элементов текста?
На худой конец можно рендерить текст в картинку обычными средствами и составлять хинт из картинок по такой же схеме.
Re[4]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Аноним, Вы писали:
А>А зачем там вообще WPF? Нужна какая-то интерактивность от отдельных элементов текста?
Да.
А>На худой конец можно рендерить текст в картинку обычными средствами и составлять хинт из картинок по такой же схеме.
Еще можно на принтер выводить, а потом сканировать, но я не настолько веселый парень.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [WPF] Можно ли улучшить отображение шрифтов?
От:
Аноним
Дата:
31.10.09 09:31
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Блин. Хоть выбрасывай этот WPF и бери банальный броузер.
Как вариант, а по производительности устраивает?
Я погуглил по free с# html renderer и с ходу наткнулся на это, правда больше всё-таки коммерческих контролов.
Re[4]: Опять про вывод типов и overload resolution
Здравствуйте, Аноним, Вы писали:
VD>>Блин. Хоть выбрасывай этот WPF и бери банальный броузер. А>Как вариант, а по производительности устраивает?
Первая загрузка тормозит безбожно, но потом вробе бы приемлемо.
За то по функционатьности предел мечтаний.
А>Я погуглил по free с# html renderer и с ходу наткнулся на это, правда больше всё-таки коммерческих контролов.
Спасибо. Если WPF все же достанет, попробую это дело.
В текущем варианте уже почти все готово, так что пока его бросать не хочется.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Кирилл Осенков, Вы писали:
КО>В 2008 почти никак Хотя ухищрения есть (см. внизу) КО>В 2010 Beta2 устанавливаешь UseLayoutRounding="True" на корне дерева и TextOptions.TextFormattingMode="Display", станет сильно лучше.
А можно поставить версию WPF идующую с 2010 Beta2 отдельно?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[2]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Кирилл Осенков, Вы писали:
КО>В 2008 почти никак Хотя ухищрения есть (см. внизу) КО>В 2010 Beta2 устанавливаешь UseLayoutRounding="True" на корне дерева и TextOptions.TextFormattingMode="Display", станет сильно лучше.
Кстати, 2010 Beta 1 жудко тормозила при загрузке. Это хоть немного поправят к релизу?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Можно поставить .NET Framework 4.0 Beta 2, без студии: КО>http://msdn.microsoft.com/en-us/vstudio/dd582936.aspx
КО>Там несколько вариантов, можно скачать даже не весь framework, а только Client Profile — 35 MB, но в нём WPF есть.
Я правильно понял, что повышение качества рендеринга мы получим только если перейдем на 4-ый фрэймворк.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, Кирилл Осенков, Вы писали:
КО>Да, Beta 2 значительно быстрее Beta1. А текущие билды уже ощутимо лучше Beta 2 КО>В некоторых сценариях 2010 быстрее 2008. К сожалению, не во всех.
А загрузка ускорилась?
Кстати, закинь (если есть такая возможность) мысль, о том, что МС сам подрывает доверие к WPF поставляя в составе виндовс сильно деоптимизированные 3D-дрова. Давиче мне один товарищ жаловался на неприемлемую производительность прокрутки в 2010-ой студии. После некоторого разбирательства и скачивания дров для видюхи с сайта Интела все вроде бы как нормализовалось.
Понятно, что в одночасье МС не начнет поставлять в составе виндовс быстрые дрова, но хотя бы написать в блогах и рейдми об этом надо.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, VladD2, Вы писали:
VD>А загрузка ускорилась?
Да, почти как 2008 стало.
VD>Кстати, закинь (если есть такая возможность) мысль, о том, что МС сам подрывает доверие к WPF поставляя в составе виндовс сильно деоптимизированные 3D-дрова. Давиче мне один товарищ жаловался на неприемлемую производительность прокрутки в 2010-ой студии. После некоторого разбирательства и скачивания дров для видюхи с сайта Интела все вроде бы как нормализовалось.
Хорошо, постараюсь.
VD>Понятно, что в одночасье МС не начнет поставлять в составе виндовс быстрые дрова, но хотя бы написать в блогах и рейдми об этом надо.
Да мы вроде и пишем: http://beta.blogs.msdn.com/ddperf/default.aspx
Надо больше писать, я знаю Можешь кстати на этот блог сам написать, это один из главных чуваков по VS performance (David Berg), его смотрят внимательно. Тебя даже больше слушать будут, чем если я изнутри жаловаться буду.
Re[2]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, c-smile, Вы писали:
CS>Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует. CS>И справильными шрифтами учитывающими предпочтения юзера.
Или хотя бы возьми свой собственный Rsdn.Editor, который такое тоже отлично нарисует.
Re[2]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, c-smile, Вы писали:
CS>Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует. CS>И справильными шрифтами учитывающими предпочтения юзера.
качество отображения стал приемлемым. Правда шрифты чуть увеличены, но так как хинт стал многоуровневым, то это не является проблемой.
Так что единственная проблема — это тормоза при первом показе.
При этом то что ты предлагаешь — это нэйтив-длл-и для который еще придется писать обертки и реализовывать функциональность многоуровневости для хинтов (вряд ли она там есть по умолчанию). Так что объем работы получается внушительным, а выходы сомнительны. В общем, легаси код. Вот так вот быстро, оказывается, им можно обжиться .
К тому же для управляемого прилоежения наверно лучше будет использовать управляемый-аналог (например, предложенный здесь
Так что огромное спасибо за ссылки, но пока попробуем обойтись WPF-ом. Тем более, что это полезно на будущее. Все равно следующая студия будет иметь на 90% управляемый-АПИ
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[3]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, c-smile, Вы писали:
CS>>>Влад, не занимайся ерундой. htmlayout или sciter твой UI на ура нарисует. CS>>>И справильными шрифтами учитывающими предпочтения юзера.
VD>>Благодаря этому совету
качество отображения стал приемлемым. Правда шрифты чуть увеличены, но так как хинт стал многоуровневым, то это не является проблемой.
CS>Какая-то кофейная гущща, право слово. И забавный способ определения значения points: CS>
Здравствуйте, Sinix, Вы писали:
VD>>Тем более, что это полезно на будущее. Все равно следующая студия будет иметь на 90% управляемый-АПИ
S>А можно пруфлинк? Обычно рядом с такими заявлениями лежит ещё много новостей по роадмапу — они-то меня и интересуют.
Да это и не заявление в общем-то. Все кому надо об этом уже давно знают. Тут рядом Кирил Осенков был. Он может по части ссылок будет более качественным источником. А вообще, кому надо может просто воспользоваться гуглем. Например, VS 2010 WPF.
В VS 2010 управляемым станет почти половина GUI. Ну, и главное управляемым станет редактор кода.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[4]: [WPF] Можно ли улучшить отображение шрифтов?
На самом деле самым важным здесь является именно подбор шрифта. Он меньше обычных, то что его можно задавать большим кеглем, что приводит к улучшению качества отображения. Ну, и возможно он просто чем-то лучше подходит для WPF. Повозившись с моноширными шрифтами я сделал вывод, что лучше всего на экране выглядит Consolas (шрифт идущий в поставке с VS).
VD>>Так что единственная проблема — это тормоза при первом показе.
CS>Мда... студия и так не шеволится нонче... А тут ты еще со своим WPF...
Говорят VS 2010 beta 2 работает уже на уровне 2008-ой. Меня это устроило бы (правда верится в это с трудом).
В общем-то все новые версии студии, по крайней мере те в которых были серьезные новшества, работали чуть медленнее предыдущих. Но как-то со временем железо их догоняло и они работали совершенно приемлемо. Думаю, так будет и с этой версией.
А WPF... Дык не перевели бы на него студию, то он так и прозябал бы в черт знает каком состоянии еще долгие годы. А так, доведут до ума технологию, плюс IDE будет намного более расширяемой. Уже приводили пример плагинов которые превращали DOC-коментарии в эдакие навороченные балуны с удобным форматированием и хорошо читаемым текстом.
VD>>При этом то что ты предлагаешь — это нэйтив-длл-и для который еще придется писать обертки и реализовывать функциональность многоуровневости для хинтов (вряд ли она там есть по умолчанию). Так что объем работы получается внушительным, а выходы сомнительны. В общем, легаси код. Вот так вот быстро, оказывается, им можно обжиться .
CS>Мммм... а это вот Nabu.Forms.Html из http://code.google.com/p/nabu-library/ чем не устраивает-то? CS>Или вот это вот: http://code.google.com/p/expemerent/
А черт его знает. Я об их существовании только от тебя узнал. Причем в этот всем еще разобраться нужно.
VD>>К тому же для управляемого прилоежения наверно лучше будет использовать управляемый-аналог (например, предложенный здесь
). Но и с ним, думаю, придется повозиться.
CS>Это какое-то заблуждение у тебя. В ситуациях когда есть managed/non-managed код (а в UI это всегда так) CS>выигрывать будет решение у которого меньшее количество переходов (вызовов) managed -> non-managed код. CS>В случае с htmlayout ты оперируешь десятком вызовов высокоуровневых методов. Вместо потока вызовов CreateBrush, FillRect и пр.
Заблуждение скорее у тебя. Ты очень странно смотришь на выигрыш. Для меня выигрыш не упирается в быстродействие. Быстродействие, конечно, должно быть приемлемым. Но не более того. Кроме того очень важны такие аспекты, как устойчивость, легкость отладки и возможность модификации под свои нужды. Они у управляемого-решения с открытым кодом по любому лучше.
Собственно все пойманные проблемы с WPF-ным контролом были во круг интеропа. Окно студии ведь нэйтивное пока, а стло быть подключиться к нему можно только через перехват очереди окна. Ну, и там без ошибок не обошлось. А результат — вместо исключений переодически вся студия сворачивалась без единого звука. Хорошо что хоть интероп в дотнете написан так, что в присутствии отладчика он выполняет ряд расширенных проверок которые таки выявляют проблемы. Ну, а нэйтив баги без отладчика поймать будет очень сложно. Учитывая, что использование должно быть не очень стандартным (вложенные хинты я досего времени вообще нигде не видел), вероятность их вылезания весьма высока. Так что менеджед-код написанный на коленке может, по совокупности, причин оказаться более приемлемым.
CS>Каждый такой вызов как я понимаю чего-то да стоит.
Фигню он стоит. К тому же управляемое-решение рисует все через дотнетные интрфейсы. Интероп идет не при каждом вызове методов. Вместо этого сначала все вызовы записываются во внуренее представление, а потом накатываются (если я не ошибась). Так что там намного больше зависит от наличия акселерации отрисовки. Когда-то давно она была очень слабенькой для многих видюх. Как сейчас дела обстоят я не знаю. Но по любому для хнинта это не очень актуально. Он ведь весьма статический. Нарисовался и забылся.
Я тебе о другом говорю. Лично мне проще разобраться с менеджед решением, но даже за него браться не очень хочется, так как это время на изучение, на создание самого контрола. Ведь WPF-ное решение, хотя и не лишено недостатков, но он же ведь работает. И работает, в общем, приемлемо. Если бы у меня был штат программистов и много денег, я бы посадил по программисту за каждую альтернативу и приказал им написать по реализации хинта на каждом из API. Ну, а потом выбрал бы лучшего или просто сделал бы их сменяемыми (интерфейс ведь весьма прост).
Вот если бы кто нибудь (например, ты) помог бы реализовать альтернативную версию, то я с удовольствием подключил бы ее и опробовал. Но самому мне этим заниматься просто не когда. Моя основная задача — это доделать интеграцию немерла со студией. WPF-хнит написал один добрый человек (capgoat). Если бы не он, я бы еще очень долго не взялся бы за это дело. Зато теперь хинты в немерловой интеграции куруче паравоза. Отдыхают не только студия, но и разные РеШарперы.
Здравствуйте, VladD2, Вы писали:
CS>>Мда... студия и так не шеволится нонче... А тут ты еще со своим WPF... VD>Говорят VS 2010 beta 2 работает уже на уровне 2008-ой. Меня это устроило бы (правда верится в это с трудом).
Верится с трудом, но оно таки так и есть — по моему субъективному опыту. Пока что столкнулся только с одним обидным тормозом — окно Add reference почему-то очень медленно отрисовывает список сборок. В остальном Студия работает либо не медленнее, либо заметно быстрее.
CS>>Это какое-то заблуждение у тебя. В ситуациях когда есть managed/non-managed код (а в UI это всегда так) CS>>выигрывать будет решение у которого меньшее количество переходов (вызовов) managed -> non-managed код. CS>>В случае с htmlayout ты оперируешь десятком вызовов высокоуровневых методов. Вместо потока вызовов CreateBrush, FillRect и пр. CS>>Каждый такой вызов как я понимаю чего-то да стоит.
VD>Заблуждение скорее у тебя.
Согласен. В коде на WPF вообще не будет GDI-шных CreateBrush'ей и FillRect'ов. Там аппаратно ускоряемый DirectDraw.
VD>Ты очень странно смотришь на выигрыш. Для меня выигрыш не упирается в быстродействие. Быстродействие, конечно, должно быть приемлемым. Но не более того. Кроме того очень важны такие аспекты, как устойчивость, легкость отладки и возможность модификации под свои нужды. Они у управляемого-решения с открытым кодом по любому лучше.
В этом аспекте тоже согласен. Код на WPF легче писать/поддерживать, чем код на WinForms/WinApi.
Глаза у меня добрые, но рубашка — смирительная!
Re[4]: [WPF] Можно ли улучшить отображение шрифтов?
Вряд ли. Там предлагается не пользоваться XAML-ом. В хинте и так его почти нет (только базовая часть). А тормоза явно связаны с загрузкой PresentationFramework.Aero.dll.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Да это и не заявление в общем-то. Все кому надо об этом уже давно знают.
Спс. Про это в курсе. Но окромя UI в студии есть дофига и больше кода, не имеющего managed api — типа SCC, или работающего ч/з ком врапперы (shell, envDTE). Переписывание — очень много-много работы.
Что-то я сомневаюсь что в этом релизе они успеют
Re[7]: [WPF] Можно ли улучшить отображение шрифтов?
Здравствуйте, VladD2, Вы писали:
VD>Я не говрил, что все переписано.
Все равно следующая студия будет иметь на 90% управляемый-АПИ
Всё ясно, не так вас понял
VD>Но IDE — это и есть на 90% UI.
Повторюсь, UI — далеко не весь апи.
VD>SCC это не так много кода и он далеко не всем нужен. Мне, например, не нужен.
Мне тоже. Но вот перспектива "поменяем апи — проблемы у всех разработчиков дополнений" меня абсолютно не втыкает. Очевидно, не втыкает и VSX Team — в EnvDTE не так уж и много изменений.
P.S. А вообще надо уже собраться и поставить... время-время
Хотя ухищрения есть (см. внизу)
.
