Вери мач сорри за то, что так надолго забросил наше детище — на то были свои причины. Теперь хочу возобновить работу.
Пока, на досуге, решил проверить наш "продукт" на...
кроссплатформенность. Поскольку языком проекта является C#, то особого выбора не было — речь пойдет о Линуксе. Ведь там, как известно, имеется Mono.
Изучив вопрос на сайте первоисточника —
www.-mono-project.com, я пришел к следующим выводам:
— в Линуксе нужно использовать оконную среду GNOME, т.к. Mono "любит" Гном;
— для GUI лучше использовать библиотеку Gtk# (она, кстати, кроссплатформенная,
есть версия и для Windows);
Почему я остановился на Gtk# (gtk-sharp)? А других вариантов и не было. Gtk — "родная" GUI библиотека для GNOME. Кроме того, отрисовку в Gtk# можно осуществлять, используя обычные средства System.Drawing.
Чем отличается Gtk# от WinForms? В первую очередь тем, что Контрол (Control) там называется Виджетом (Widget)
. Ну а если серьезно, то обе эти библиотеки являются событийно-управляемыми, обе имеют приблизительно одинаковый набор элементов управления (контролов, то бишь виджетов). Главное отличие — способ позиционирования контролов. Если в WinForms мы можем, к примеру, взять панель и положить на нее какой-нибудь TextBox, назначив координаты его правого верхнего угла (10,10), то в Gtk# такой номер не пройдет. Там вообще нет никаких координат.
Для размещения (или, по терминологии Gtk, упаковки) дочерних виджетов существуют родительские виджеты-контейнеры. Эти контейнеры могут содержать один или несколько слотов (ячеек) для упаковки дочерних виджетов или других контейнеров. Эти слоты могут быть расположены либо по вертикали, либо по горизонтали, либо в виде таблицы, причем любые смежные слоты одного контейнера могут быть объединены. И главное правило: один слот — один дочерний виджет. Дочерние виджеты могут расширяться на весь слот по вертикали и/или горизонтали, сжимать родительский слот под свой размер, устанавливать размер отступов от границ слота. Поначалу трудно привыкнуть к этим правилам, но потом убеждаешься, что они удобны.
Для визуального редактирования форм используется специальное средство — Glade. Это аналог дизайнера форм WinForms. Первое время Glade управляет тобой, но вскоре ты его одолеваешь и управляешь Glade'ом сам
. Glade сохраняет всю иерархию виджетов в отдельный файл в формате XML. Этот файл может быть программно подключен в приложении, допустим, в конструкторе главной формы.
Одно плохо в Gtk# — слабоватая документация. Есть on-line вариант — в составе Mono Documentation Library (
www.go-mono.com/docs), для Линукса есть его оффлайн аналог — Monodoc. Но там просто перечислены классы и прототипы методов и свойств. Очень мало примеров, очень мало описаний технологий — "How To...". Основной способ отыскать какую-либо информацию — ключевые слова, Google — и вперед по форумам и блогам. Ну да это дело временное...
Проверим работу Gtk# в Windows для .Net Framework 1.1. По
этому адресу скачиваем инсталляторы gtksharp-runtime-1.9.3.1-win32-0.0.exe и gtksharp-1.9.3.1-win32-0.2.exe (всего около 16 Mb). После инсталляции мы можем создавать в VS проекты типа "Glade Project" и "Gtk# Project". Они отличаются тем, что в первом можно использовать вышеупомянутый дизайнер Glade.
Технически переход на платформу Gtk# для виртуального грида осуществляется довольно легко. Ведь ВГ был спроектирован так, чтобы максимально абстрагироваться от конкретной платформы. Нужно только заменить зависящие от платформы PalControl , PalView и DrawContext. PalControl — это родительский контрол, к которому подключается собственно грид. PalView — физическая область отображения грида. DrawContext — контекст отрисовки.Кстати, DrawContext для Gtk# практически идентичен контексту Gdi, т.к., повторюсь, мы можем делать отрисовку в Gtk# средствами System.Drawing. Просто чуть-чуть другая инициализация. Ну и конечно, главная форма для Gtk# будет совершенно другая. Там нужно подключать .glade файл, особым образом привязывать PalControl.
Надо сказать, что мне не удалось пока реализовать скроллинг, а только отображение скроллбаров. Ведь для платформы WinForms мы скроллинг, грубо говоря, "хакнули", импортировав API функции, а с Gtk# такой номер не пройдет, нужно подумать... И MultiView (возможность отображения грида сразу в нескольких окнах) я пока не занимался. Немного другой подход в Gtk...
Здесь лежит скриншот с обзором всего хозяйства под Windows. В верхней части находятся служебные окна Glade, в нижней — работающие приложения на платформах Gtk# и WinForms. Как видно, Gtk# для Windows отлично поддерживает темы XP.
Теперь опробуем наш проект в другой ОС — Линуксе.
Линуксом у меня является Debian-подобный Ubuntu. Это легковесный (всего на 1 CD) дистрибутив, в последнее время набирающий популярность. Некоторые называют его "бедноватым", но я так не думаю. Главное для меня, что в нем, как правило, используется свежий Гном, да и остальной софт последних версий. Mono устанавливаем версии 1.1.8.3 — это последний билд. Кстати, я не ожидал такой "продвинутости" от Mono. Та же .Net Framework 1.1, я различий не заметил
, по крайней мере, для своих задач. Мало того, в нем можно компилировать и запускать простые приложения WinForms. А может, уже и не простые — я не пробовал... Правда, приложения WinForms пока не поддерживают тем Gtk. Авторы Mono придумали для окон и контролов какой-то серовато-невзрачный стиль а-ля Classic тема в Windows, но обещают исправить положение в будущем. Т.е. никакой Gtk# в будущем и не нужен будет, я так понимаю
.
Установив Mono, в Линуксе можно скомпилировать и запустить наш проект из командной строки. Но я захотел протестировать "местную" среду разработки для Mono — MonoDevelop. Эта среда является портом проекта SharpDevelop для библиотеки Gtk#. Насколько я понял, она полностью написана на C#.
Впечатления от MD остались скорее положительные, чем отрицательные. Основные фичи IDE присутствуют, есть автозаполнение, компиляция быстрая. В официальном последнем билде (версия 0.7) есть даже поддержка Debug. Правда, пока она выражается только в остановке програмы по Breakpoint. Функции Watch, Stack Trace пока не работают. Я брал версии MonoDevelop из SVN репозитария, и по исходникам видел, что работа над этим ведется. C# — не единственный язык MonoDevelop. Есть поддержка .NET версий Java (ikvm) и Python (boo), а также VB.NET.
Также заявлена поддержка системы контроля версий и интеграция основных серверов баз данных в Линуксе — MySQL, PostgreSQL, и т.д. Есть еще и Add-In для тестирования написанных приложений — NUnit. Я бы рассказал об этом поподробнее, но мне ни разу (!) не удалось собрать последний билд из репозитария MonoDevelop. Очевидно, разработчики не обязывают себя заливать в рабочий репозитарий компилирующийся проект
, или мне как-то с этим не везло. Кстати, официальный релиз, выложенный на сайте monodevelop.com, тоже не скомпилировался с включенной опцией подержки Debug. Пришлось долго гуглевать и искать решение. И еще негативный момент. Дело в том, что файлы солюшена и проекта в VS.NET и MonoDeveloop имеют разный формат. Так вот, для этого, в MonoDevelop есть специальная команда — Import Visual Studio .NET Project. И, самое печальное, что этот импорт не работает
. MD просто вылетает. Это тоже лечится, но как-то руки не дошли. Пришлось самому создавать солюшн и все проекты для него.
Это было последним неприятным моментом. Проект собрался в Линуксе без малейшей коррекции исходников, которые я написал для Gtk# под Windows. Причем, скомпилировалась и часть проекта для Win32-платформы (правда я ее не запускал
). Результаты работы можно увидеть на
этом скриншоте. На экране — MonoDevelop (правый верхний угол), окошки Glade слева вверху, работающая демо-версия грида — слева внизу. Кроссплатформенность.NET в действии, так сказать... Опять же отмечу поддержку тем.
Теперь можно разрабатывать Gtk#-версию грида хоть в Линуксе, хоть в Windows — благо, имеется SVN-сервис, любезно предоставленный RSDN
.
Как среда разработки .NET-приложений под Линукс, MonoDevelop даже в таком виде может удовлетворить спрос, а через 6-8 месяцев, я думаю, между MD и VS уже не будет большой разницы. Не забывайте, что MD, как и Mono — свободное ПО. Кстати, название проекта "Mono" переводится с испанского как "обезьяна". Чувствую, что будут обезьянничать, пока не сделают продукт по возможностям один к одному.
Уже сейчас есть кросс-платформенная IDE среда для .NET, которую очень хвалят. Если вы не слышали о X-Develop, зайдите по адресу
www.omnicore.com и убедитесь сами. До лета 2005 года эта среда отличалась от MonoDevelop большей навороченностью и стабильностью (а также ценой, т.к. MD бесплатна, а XD — отнюдь). А вот с июля в XD (с версии 1.1) появился дизайнер, который работает и с WinForms, и с Gtk#. Надо скачать trial-версию и посмотреть, что за зверь. Цена коммерческой версии, кстати, не такая уж и большая — то ли 300 баксов за одиночную лицензию, то ли около того.
Таким образом, мы убедились, что .NET-приложения можно создавать не только для MS-Windows. Не буду делать долгосрочных прогнозов (я не "Священный Воин" и не "Евангелист"
), но мне кажется, что через пару выходов новых версий Mono и MD число разработок .NET-приложений в секторе свободного ПО несомненно увеличится. Я показал здесь возможность кроссплатформенного решения на примере простенького GUI-проекта, но думаю, что и более сложные вещи (тот же Janus, например) можно будет реализовать.
Да, и самое главное
. Приглашаю желающих к сотрудничеству в проекте "Виртуальный грид". Нужны свежие идеи — пора выходить из застоя...
Здравствуйте, VladD2, Вы писали:
VD>Почему-то мне кажется, что сначала надо сдалать хоть какой-то релиз.
До релиза нужно решить следующие проблемы:
1. Внятное размещение дочерних вью — утряска вопросов с докингом, позиционированием, сплиттерами.
Мое предложение:
Во-первых, нужно взять за правило, что дочерние вью полностью покрывают (заполняют) родительский вью.
Во-вторых, физические окна дочерних вью не должны помещаться непосредственно в физическое окно родительского. Нужно написать промежуточный контрол — как бы таблицу, ячейки которой будут заполняться физическими окнами вью. При создании вью отказаться от Top-Left координаты, а указывать строку и столбец ячейки, а также количество строк и столбцов, занимаемым дочерним вью (их может быть несколько, если вью располагается в нескольких смежных ячейках).
Вот во втором фреймворке есть TableLayout — может он подойдет? Его, кстати, предлагал ранее
здесьАвтор: Блудов Павел
Дата: 30.07.04
Блудов Павел.
2. Сделать фиксированные ячейки — хотя бы по одному ряду с каждой стороны грида.
3. Дописать горизонтальный скроллинг.
