Saturday, August 23, 2008

Простенький броузер

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

Так как в то время я решил поробовать основаный на исходных кодах дистрибутив Lunar в нем firefox не коппилился под 64 разрядную архитектуру. А пользоваться инетом скартинками хотелось:-)

Маленькое отступление:
  1. Выбор был основан на том что дистрибутивы основаные на пакетах я уже пробовал - не понравилось: так как все равно сам все пытался перекомпилить и установить не стандартные версии :-)
  2. И перешел на LFS все сам руками установил:-) Поставил нужные мне версии приложений - создал подобие системы установки используя как основу скрипты из установщика Gnome - Garnome.
  3. Он у меня простоял полгода:-) И тут мне захотелось купить ноутбук. Вот он как раз AMD64 и не него я решил перенести результаты своих трудов - и появились проблемы на 64 битной платформе все было не так гладко: не мог подобрать нужные драйвера под контролер жеских дисков -- нашел нужны а он у меня после компиляции отказывался работать.
  4. И я вернулся на Ubuntu:-) но долго терпеть не мог. Так Gentoo стояла у моего друга на компьютере, я решил найти что - то подобное, но не Gentoo - в ней был старый гном, а Lunar более новый(мне тогда это казалось достаточно важным - теперь я не особо замечаю различия между версиями или они действительно стали очень мелкими).
  5. И выбор был сделан с тех пор я пользуюсь им:-) Не все конечно так отлажено как в Gentoo, но очень даже не плохо:-)
И после этой короткой(а может и не очень) исторической справки маленькое описание броузера:
  1. он может нормально обрабатывать кодировки пришедших страниц(gtkhtml понимает только utf8) ;
  2. он может отобразить html стриницу с картинками:-);
И имеет несколько мелких ошибок:
  1. Он оправляет запросы в независимости от исходной кодировки страницы utf;
  2. Очень часто ошибаеться в относительных путях если часть стриниц имеет разный путь откуда отсчитываеться относительный путь (причина очень проста - в gtkhtml не храниться кодировка страницы и путь с которого она загружена - сейчас не могу говорить точно может уже и исправили);
  3. И ужасный интерфейс без кнопочек назад и указание на какую страницу только в логах на терминал.

Вот и весь проект...

Wednesday, August 20, 2008

SilverLight WPF

Продолжая предыдущее сообщение:

Удалось создать простейшие тестовые приложения с использованием SilverLight. При создании приложения автоматически системой сборки генерируется тестовая страница и сразу можно проверить его работоспособность. Благодаря этому не нужно дополнительный проектов чтобы проверить результат, в результате отдельный сервер для тестирования не нужен( проектов под ASP создавать не нужно).

Ручками создавать проект под SilverLight из пустого проекта нельзя нужно немного подредактировать в текстовом редакторе проект, чтобы он компилировался в xap(обычный zip архив с библиотекой и ресурсными файлами) иначе получается тоже самое, но без упаковки в архив и тестовой страницы.

Изменения достаточно тривиальны: добавить список импортируемых библиотек и исправить тип результирующего файла. Затем можно это все экспортировать как шаблон и сохранить его себе и не проделывать это снова.

Единственное есть пара недостатков: нельзя проект запустить в режиме отладки и присоединять отдельно отлажены проекты под WPF - как следствие создать скачала обёртку как обычное десктопное приложение, а затем над основной его логикой(окошки и графические элементы) добавить обёртку для запуска под SilverLight.

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

Sunday, August 17, 2008

SilverLight и Visual Studio Express 2008

Пока опыт не очень удачен, но удалось заставить компилироваться примеры. Осталось заставить их работать:-) Проблемы с asp - часть примеров с ошибкой нет доступа к подчиненным папкам. Но часть проектов нормально запускается при открытии с локальной папки. Пробовал не все примеры и не очень подробно разбирался почему недоступны файлы через стандартный тестовый сервер.

Надеюсь это кому-то поможет...

Основа опыта здесь. Но получилось это сделать немного правильнее по моему мнению.

Отличия от описанного я файлы требуемые для компиляции получил из стандартного пакета разработки под SilverLight 2.0(Silverlight Tools Beta 2 for Visual Studio 2008 silverlight_chainer.exe). Этот пакет требует для своей установки полной версии VS, но это можно обойти распаковав это пакет и запустив непосредственно версию SilverLight 2.0(Silverlight.2.0_Developer.exe) и библиотеки для разработки silverlight_sdk.msi.

После этого можно приступать непосредственно к открытию файлов примеров. Так как все примеры расчитаны на полную версию при открытии их появиться сообщение, что не все проекты удалось открыть. Для того чтобы их открыть нужно немного подправить файл описания проектов, которые не удалось открыть, удалив строки productversion и projecttypeguids.

Более подробно можно посмотреть по указанной выше ссылке.

Скачать установочный пакет SilverLight можно с официального сайта.

Удачи всем:-)

Wednesday, August 6, 2008

Портирование приложений СSharp на mono

Начальные действия.

Написано на основе опыта полученного при портировании толстого клиента, так как портирование еще не завершено(приостановлено), то опыт не полный.

Первое и самое важное что нужно сделать это определить какой именно функционал требуется в результате портирования. Так как скорее всего в результате портирования получается несколько урезанная версия в связи с ограничениями реализации mono и возможным использованием недокументированные функций из .NET в результате чего приложения будет работать некорректно.

Определить, где хранятся основные файлы приложения и важность именно такого расположения файлов и конфигураций. Хранение данных в реестре и использование установочных пакетов удобно в Wiondows, при запуске под Linux второе не используется, а для первого нужно самому внести все данные в реестр. В моем случае это было не критично так как в реестре храниться только версия установленного приложения в системе. И как следствие приложение не сможет себя автоматически обновить.

Для определения соответствия путей можно воспользоваться расположенным ниже списком:

  1. Environment.SpecialFolder.ApplicationData===домашний каталог/.config
  2. Environment.SpecialFolder.CommonApplicationData===/usr/share
  3. Environment.SpecialFolder.CommonProgramFiles===пустое значение
  4. Environment.SpecialFolder.Cookies===пустое значение
  5. Environment.SpecialFolder.Desktop===домашний каталог/Desktop
  6. Environment.SpecialFolder.DesktopDirectory===домашний каталог/Desktop
  7. Environment.SpecialFolder.Favorites===пустое значение
  8. Environment.SpecialFolder.History===пустое значение
  9. Environment.SpecialFolder.InternetCache===пустое значение
  10. Environment.SpecialFolder.LocalApplicationData===домашний каталог/.local/share
  11. Environment.SpecialFolder.MyComputer===пустое значение
  12. Environment.SpecialFolder.MyDocuments===домашний каталог
  13. Environment.SpecialFolder.MyMusic===домашний каталог/Music
  14. Environment.SpecialFolder.MyPictures===домашний каталог/Pictures
  15. Environment.SpecialFolder.Personal===домашний каталог
  16. Environment.SpecialFolder.ProgramFiles===пустое значение
  17. Environment.SpecialFolder.Programs===пустое значение
  18. Environment.SpecialFolder.Recent===пустое значение
  19. Environment.SpecialFolder.SendTo===пустое значение
  20. Environment.SpecialFolder.StartMenu===пустое значение
  21. Environment.SpecialFolder.Startup===пустое значение
  22. Environment.SpecialFolder.System===пустое значение
  23. Environment.SpecialFolder.Templates===пустое значение
Все не установленные пути лучше не использовать так как результат будет зависеть от текущей папки(обычно это папка где запустили) и возможны неприятные неожиданности.

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

Заменить в проекте все сообщения об ошибках на более информативные с указание стека выполнения. На пример: я добавил новый компонент которые отображает ошибку и в текстовом поле под ним отображает полный стек. Это очень важно так как исключения могут возникать по самым на первый взгляд безобидным причинам и приложение будет отказываться работать.

Установить последнюю версию mono и monodevelop - последнюю - так как скорее всего, именно в ней будет реализовано максимум возможностей из .Net. Если есть ограничение на дистрибутив максимально свежую из доступных в нем.

Сделать копию описания проекта и назвать его как нибудь на подобии проект_под_VS. После этого открыть проект под VS в monodevelop - при открытии, если был установочных проект, то среда сообщит, что он не передерживается. Это нормальная реакция системы после этого проект будет уже сохранен без не поддерживающихся частей и в результате для создания установочного пакета нужно будет использовать копию проекта сделанную ранее. В остальном проект можно использовать в на обоих платформах.

При компиляции возникает 2 типа ошибок(возможен и третий но очень редко.):

  1. Не корректно по мнению компилятора написанный код - возможно прийдеться раставить в местах ошибок дополнительные скобки чтобы исправить неоднозначности кода.
  2. Не корректная кодировка файла - самая подлая ошибка:-) Для избежания ее нужно все файлы используемые в проекте перевести из cp1251 в utf8. Ее симптомы компилятор ругается на нормальный на вид код и приложение работает неправильно , идет не по тем путям куда должно было. В моем случае некоторые элементы имели русское название и отображались не те формы или не те компоненты и не срабатывали нужные реакции.
  3. Не реализованы какие-то функции вообще никак, отсутствие некоторых свойств - очень редкое событие, но вполне возможно. Единственный метод решения этой проблемы не использовать этот код.
После выполнения всех этих шагов мы должны получить код который компилируется и запускается, но еше не работает.

Запускаем приложение

Основная проблема возникающая при работе: это отсутствие отладчика в monodevelop. И всю отладку скорее всего нужно проводить методом отладочных печатей и логов.

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

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

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

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


       /// 
/// Запущены под моно
///

/// нужно урезать объем отображения
public static bool IsRunningOnMono()
{
return Type.GetType("Mono.Runtime") != null;
}

///
/// Запущена не под XP(Считаем ее самой распространенной пользовательской системой)
///

///
public static bool IsTerminalServer()
{
return !(Environment.OSVersion.Version.Major == 5 && Environment.OSVersion.Version.Minor == 1);
}

///
/// Запущены под юникс
///

/// нужно запретить специфичные для виндоус операции
public static bool IsUnix()
{
return Environment.OSVersion.Platform == PlatformID.Unix;
}
После выполнения этих шагов мы получаем приложение(альфа версия), которое работает с урезанным функционалом, но выглядит очень странно:-)

Исправление внешнего вида

Эта стадия еще не завершено мной, в новой версии mono 2.0 все компоненты выглядят очень похожими на оригинальный , но лучше все таки проверить.

На этом шаге нужно изменить размеры всех элементов которые по каким-то причинам съехали или расползлись. Эта часть скорее относиться к дизайну, а не к функционалу. Но если ее не выполнить приложение будет очень не удобно использовать.

Как результат мы получим приложение которое можно тестировать(бета версия).

Исправление функционала

После того как мы получаем версию с нормальным отображение компонентов можно уже искать ошибки в приложении связанные с особенностями архитектур и платформ.

Зачем это все надо

При портировании и использование другого компилятора мы получаем ряд преимуществ:

  1. При компиляции мы можем обнаружит части кода которые по каким-то причинам были не завершены или сделаны не качественно - присутствуют не используемые переменные, не проверяются ответы от функций и параметры функций не проверяются на корректность.
  2. Приложение, когда это потребуется, можно будет портировать, и затратить на это меньше времени.
  3. И как следствие предыдущего факта при смене версии ос даже на одной платформе (XP -> Vista) с большей вероятностью будет работать.