Elipse RCP. Linux круче, чем Windows!

У меня не работал в моем проекте импорт файлов из файловой системы. Google порекомендовал добавить плагин org.eclipse.core.runtime.compability, но так просто всё сделать никак не получилось.
Вначале я начал тестить на Eclipse Europa win32: добавляю в dependencies, добавляю в launch configuration, и... ничего не запускается, после заcтавки мне сообщают, что No application id has been found.
Дальше я лезу в мой Debian GNU/Linux и проделываю всё то же самое: всё благополучно работает. Наверное это потому, что у меня тут Ganymede, а там Europe версия! Лезу в винду, скачиваю Ganymede (не знаю какой точно билд скачиваю, но последний), и имею те же проблемы, что и с Europой.
Так что жe такое получается? Linux roolez, Windows must die?

P.S. Наверное такое заслуживает багтрекера Eclipse.

Eclipse RCP. Команды пунктам меню

Саму менюшку можно создать поковыряв plugin.xml на вкладке Extensions. Однако, там могут возникать некоторые проблемы такого рода: некоторые пункты меню работают, а некоторые - нет. Например, у меня есть несколько пунктов в меню File: Save и Exit. Реализации, прописанные в CommandId у них org.eclipse.ui.file.save и org.eclipse.ui.file.exit соответственно. Имеем ситуацию, когда Save не работает, а Exit - работает. Не работает - в смысле "серый", на него нельзя кликнуть.

Я попробовал создавать менюшку руками:

public class ApplicationActionBarAdvisor extends ActionBarAdvisor {

private IWorkbenchAction exitAction, saveAction;

protected void makeActions(IWorkbenchWindow window) {

exitAction = ActionFactory.QUIT.create(window);

register(exitAction);

saveAction = ActionFactory.SAVE.create(window);

register(saveAction);

}

protected void fillMenuBar(IMenuManager menuBar) {

MenuManager hyperbolaMenu = new MenuManager(

"&Hyperbola", "hyperbola");

hyperbolaMenu.add(saveAction);

hyperbolaMenu.add(exitAction);

menuBar.add(hyperbolaMenu);

}

}

Отлично, всё работает: и выход, и сохранение. Если убрать register(saveAction) - сохранение перестанет работать. По-видимому некоторые Actions сами создаются, а некоторые надо ручками. Магия!

Был на докладе по Mono.

Ну, собственно, доклад про Mono вел не чел из Microsoft, мне надо было лучше читать расписание этой тусовки, которую я читал только наискосок.

Microsoft имеет к Mono не такое прямое отношение как может показаться на первый взгляд. В США с их глупыми законами и патентными программами можно запросто сесть за использование Mono на своем компьютере, если только ты не делаешь это на операционке, купленной у Novell, с которой Майкрософт имеет соглашение о непреследовании по закону клиентов Novell. Хорошо что мы не в Америке.

На вопрос глючености Mono господин докладчик начал аккуратно ссылаться на кривые руки программистов; вспомнил времена, когда сообщество ругалось на Висту из-за того что не все ХРшные программы под ней работали (якобы из-за того, что в Висте убрали баги и доступ к недокументированным возможностям системы). Он слезно просил нас не писать платформо зависимых функций в своем коде и утверждал, что тогда всё будет аккуратно запускаться и там, и там.

Также ловко автор обошел проблему того что расчетные задачи на Mono выполняются на 20% медленне чем на .NET: по его словам расчетные задачи надо решать на С++, а .NET только для бизнес-приложений применяется (для меня это вообще откровение). Сказал ждать в июне новую версию Mono, с пофиксеными багами, не так тормозящую, ещё более кроссплатформенную чем сейчас)

Первые шаги c Eclipse RCP. Пункты меню

Я учавствую в проекте, где интерфейс создается на технологии Eclipse RCP. Пару недель назад я увидел её впевые и многое было непонятно. Например, я не мог даже добавить нормально менюшку ещё одну к списку готовых. Порой проскаквало ощущение, что если участие моё в этом проекте как-нибудь положительно закончится, то я ни за что больше не буду писать в Eclipse=)

Первое, что мне захотелось сделать, это добавить новую менюшку к уже имеющимся. Сразу встала проблема понимания как всё в этой технологии завязано, зачем нужны для одной менюшки и Action, и command (org.eclipse.ui.commands) на который вешается какой-то handler, унаследованный, например, от AbstractHandler (org.eclipse.core.commands.AbstractHandler). Методом научного тыка пришло понимание как всё это работает.

В терминах Eclipse то, что я создаю называется plugin. Значит так, открываем plugin.xml, идет на вкладку Extensions. Создадим новую команду - добавим расширение org.eclipse.ui.commands. Повесим какой-нибудь handler - IDE нам помагает очень просто это сделать, а также укажем какой-нибудь ID - его запомним в голове.

Теперь создадим новый ActionSet (org.eclipse.ui.actionSets) и в нём новый Action. Поля id, label и class интуитивно понятны, а вот в definitionID надо написать имя созданного нами handler'a. Иначе при выборе пункта меню мышкой мы будем постоянно получать сообщение о том, что действие не реализовано.

Последний штрих: укажем расположение в меню. Для этого есть поле menubarPath. Здесь надо просто указать ID пункта меню. Будьте внимательны, если хотите сделать подменю, то не забудьте "/" в конце!

размещение окон в Visual Studio

Забавно. По умолчанию окно Solution Explorer цепляется к правой границе экрана. Не долго думая, я всегда цеплял остальные окна там же: Properties, ToolBox. И меня это до некоторых пор устраивало, до тех пор, пока я не начал ковырять xaml.

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

Какая гадость, достало. Так постепенно у людей складывается от вращение к Майкрософт. Наверное я слишком дотошный. Непонятно почему в eclipse и NetBeans все такие мелочи давно предусмотрены...

Рефакторинг XAML в WPF

Кoвыряю WPF первый день.
Кучу времени убил на такую проблему: переименовываю класс, наследуемый от Window и сразу лезет туча ошибок. Кое-как допер что файл .cs он редактирует, а .xaml нада ручками подправлять. Объясните, почему мелкомягкие не сделали рефакторинга нормального?