Не Windows единой: как писать кроссплатформенные приложения с GUI на C#
На C# можно создавать красивые приложения, но до недавних пор — не для всех платформ. Рассказываем, как писать одно приложение для всех ОС сразу.
Microsoft выпустила уже третью версию кроссплатформенного .NET Core с открытым исходным кодом, но мы до сих пор не получили инструмента для создания графических интерфейсов.
Пока есть Xamarin, который можно использовать только для Windows 10 и мобильных устройств. Но что делать тем, кто хочет создавать графические интерфейсы для Linux или Mac OS?
Тут помогут фреймворки от сторонних разработчиков.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Какой фреймворк выбрать
Мне удалось найти 2 более-менее популярных фреймворка (оба основаны на Skia ):
- SpaceVIL. Он привлёк меня тем, что в нём элементы GUI отрисовываются, а не берутся из API операционной системы. Поэтому приложение будет выглядеть одинаково на всех устройствах. В нём даже можно создавать собственные элементы любого вида. Однако он пока достаточно сырой — об этом говорит уже то, что в официальной документации есть ошибки в инструкции для новичков.
- AvaloniaUI. Это более популярный и проработанный фреймворк, который позволяет создавать интерфейсы как для мобильных устройств, так и для Linux и OS X. Также в нём используется диалект XAML, что будет плюсом для тех, кто пробовал создавать приложения для Windows. В нём даже есть поддержка MVVM.
Я попробовал оба, и второй показался мне более удобным: в нём есть язык разметки, поддержка MVVM, быстрая установка, лёгкий переход с WPF. Поэтому я выбрал его.
Как начать использовать AvaloniaUI
Я буду создавать приложение в Linux Ubuntu, но эта инструкция подойдёт всем, кто использует .NET Core. Создавать приложения можно и в Visual Studio, скачав для него расширение, но так как его нет на Linux, я буду пользоваться терминалом.
Для начала клонируйте себе на компьютер этот репозиторий:
В нём находятся шаблоны для создания приложения с AvaloniaUI. Если вы не умеете пользоваться git, то просто скачайте содержимое и распакуйте куда-нибудь на компьютере. Затем откройте консоль и введите следующую команду:
Она установит шаблоны для создания приложения. Чтобы проверить, добавились ли шаблоны, используйте команду:
Вы увидите список всех установленных шаблонов. Среди них должны быть Avalonia Window, Avalonia .NET Core MVVM App, Avalonia UserControl и Avalonia .NET Core App. Если они на месте, можно продолжать.
Откройте в консоли папку, в которой хотите создать проект, и введите:
Будет создано приложение с использованием MVVM. Практически вся документация по AvaloniaUI написана с использованием этого паттерна, поэтому проще будет разрабатывать на нём.
Теперь можно приступать к работе над приложением.
Создаём калькулятор на AvaloniaUI
У вас будут созданы следующие папки
- Assets — сюда можно загружать различные компоненты программы вроде иконок, изображений, звуков и прочего.
- Models — эта папка предназначена для классов, которые будут выступать в роли модели.
- ViewModels — здесь находятся классы-посредники между видом и моделью.
- Views — все окна будут находиться здесь.
Сначала посмотрим в файл Program.cs в корневом каталоге:
Нас интересует метод AppMain(). В нём создаётся окно (MainWindow) с указанием DataContext (используется для привязки данных), а потом это окно запускается.
В этом методе можно определить свою логику инициализации приложения. Например, объявить экземпляр модели и передать его в конструктор MainWindowViewModel(). Однако перед этим нужно определить конструктор, который будет принимать такой аргумент.
У нас очень простое приложение, поэтому мы реализуем всю логику прямо в MainWindowViewModel.cs. Там будут необходимые свойства и методы.
Для начала нужно подключить пространство имён ReactiveUI, которое в AvaloniaUI используется для реализации паттерна MVVM:
Источник статьи: http://skillbox.ru/media/code/ne_windows_edinoy_kak_pisat_krossplatformennye_prilozheniya_s_gui_na_c/
Как написать программу с графическим интерфейсом на c
Урок № 26. Первое графическое приложение
Создание первого приложения с графическим интерфейсом
Доброго времени суток! В этом уроке мы создадим Ваше первое приложение с графическим интерфейсом в MS Visual Studio. Это будет своего рода «Hello World» для графических приложений. Скажу сразу, что использование Windows Forms — не единственный способ создания графических приложений (приложения с графическим интерфейсом пользователя) для C# программистов, но начать изучение лучше именно с этого. И так, запускаем Visual Studio.
Запустили? Тогда к делу! Идем в главное меню и выбираем пункт «Файл — Создать — Проект», как показано на рисунке ниже.
- в левой части выбираем «Шаблоны — Visual C# — Windows»;
- в основной области выбираем элемент «Приложение Windows Forms»;
- в нижней части окна вводим имя проекта и указываем его расположение на диске.
В общем, как показано на рисунке ниже.
Указали что нужно? Тогда нажимайте на кнопку «OK». Теперь вы должны увидеть примерно следующее (основные области выделены прямоугольниками):
Только что созданный проект
На рисунке выше, я обозначил основные области: область дизайнера (слева вверху), область обозревателя решений (справа вверху) и область свойств (справа внизу). С этими областями, мы будем работать чаще всего.
В области дизайнера, сейчас располагается пустая «форма», это так называемое окно, в данном случае, главное окно нашей программы. В области свойств, отображаются свойства выделенного в дизайнере элемента, в данном случае, нашей формы, ну а область обозревателя решений, содержит файлы проекта, в том числи, относящиеся и к формам (окнам) программы. А теперь, давайте немного изменим нашу форму, и запустим это первое приложение.
Для этого, выделим в дизайнере форму (для этого, можно просто кликнуть левой кнопкой мыши по форме) и перейдем в блок свойств, в котором найдем строку «Text» (слово текст, ищем в левом столбце), как показано на рисунке ниже.
Свойство «Text» основной формы приложения
Обратите внимание, в левом столбце указано имя (название свойства), а в правом — его значение.
В данном случае, мы имеем дело с текстовым свойством, и его значение, отображается в заголовке окна, так что, давайте теперь укажем там что-то свое, например, что-то вроде: «Главное окно», как показано на рисунке ниже:
Теперь, можно собрать проект и запустить. Для этого идем в главное меню и выбираем пункт «Сборка — Собрать решение». А потом запускаем приложение, для этого выбираем пункт «Отладка — Запуск без отладки» в главном меню. В результате Вы должны увидеть окно следующее окно.
Окно первого графического приложения
В следующем уроке, мы рассмотрим простую работу с дизайнером форм, и настройку элементов графического интерфейса, а на этот урок подошел к концу, мы создали первое графическое приложение, собрали и запустили его.
Источник статьи: http://plssite.ru/csharp_lessons/csharp_basic_stage/csharp_winforms_part_lessons/charp_first_winforms_project_lesson
Почему C++ не подходит для написания графических пользовательских интерфейсов
Я люблю C++, но.
Сразу оговорюсь, что C++ мой любимый язык, я на нем пишу практически «с детства» и отрицать его важность, как лучшего одного из лучших языков для написания программ для любых целей, не буду. Тем более не вижу смысла начинать очередной холивар или меряться «указками». Это статья — лишь описание неудачного опыта работы с языком, объясняющая некоторые его аспекты, знание которых поможет другим программистам в будущем.
Однажды я столкнулся с развивающейся библиотекой GUI класса. С точки зрения C++, а точнее его классов, экземпляров и иерархий, этот язык представляется невероятно близким к концепции управления GUI, в частности таким элементам, как виджеты, окна классов и подокна. OO модели C++ и оконной системы тем не менее разные. C++ был задуман как «статический» язык с охватом лексем, статической проверкой типов и иерархий определенных во время компиляции. Окна и их объекты с другой стороны, по своей природе динамичны, они обычно живут за рамкам отдельной процедуры или блока, с помощью которой были созданы; иерархии виджетов в значительной степени определены расположением, видимостью и потоками событий. Основы графического пользовательского интерфейса, такие как динамические и геометрические иерархии окон и управления, протекания событий, не поддерживаются непосредственно синтаксисом С++ либо его семантикой. Таким образом, эти функции должны быть воспроизведены в коде C++ GUI. Это приводит к дублированию графического инструментария, или функциональности оконного менеджера, код «раздувается», мы вынуждены отказываться от многих «сильных» особенностей C++ (например, проверки типов во время компиляции). В статье приведено несколько простых примеров C++ / GUI «не стыковок».
Не создавайте конструкторы (или, по крайней мере, не используйте их)
Когда полученный класс переопределяет виртуальный метод родительского класса, надо иметь в виду, что переопределение не вступает в силу, пока конструктор базового класса выполняется. Это особенно раздражает, когда объекты запрашивают виджеты, которые реагируют на события GUI. Предположим, что класс Basic_Window был предназначен для создания ванильного черно-белого окна на экране:
Здесь gt_create_window() отвечает за низкоуровневый вызов основного графического инструментария (например, xvt_win_create()). Эта функция выделяет место под данные инструментария, уведомляет оконный менеджер, регистрирует этот объект, как получателя событий, и в примере выше, инициализирует графический вывод в окно на экране.
Предположим, мы хотим создать экземпляр Basic_Window, но с красным фоном. Обычно, чтобы изменить поведение класса, надо извлечь из него и переопределить соответствующие виртуальные методы. Мы пишем:
class RedWindow : public Basic_Window <
virtual void handle_create_event() < set_background(RED); >
public:
RedWindow(Rect rect) : Basic_Window(Rect rect) <>
>;
RedWindow red_window(default_rect);
Но red_window появится белым, а не красным! Чтобы создать RedWindow, родительский объект должен быть создан первым. После завершения Basic_Window::Basic_Window(), виртуальные таблицы RedWindow вступают в силу, метод handle_create_event() становится неприменимым, и конструктор RedWindow() выполняется. Конструктор Basic_Window() регистрирует объект графического инструментария, который мгновенно начинает посылать события объекту (например, CREATE-событие). Конструктор Basic_Window() еще не закончен (это не гарантировано), поэтому переопределенный виртуальный метод еще не на месте. Таким образом, CREATE-событие будет обрабатываться Basic_Window::handle_create_event(). Виртуальные таблицы RedWindow класса будут созданы лишь тогда, когда базовый класс полностью построен, то есть, когда окно уже на экране. Изменение цвета окна на данном этапе приведет к досадной ошибке.
Есть простой обходной путь: запретить каждому конструктору регистрировать объект графического инструментария. Обработка событий будет построена таким образом, чтобы сдержать окончание инициализации до производных классов. Очень заманчиво рассматривать виджеты на экране, как «лицо» объекта GUI приложения в памяти. Как показывает приведенный выше пример, эта связь между экраном и C++ объектом реализовать не так просто: они рождаются отдельно.
Нет синтаксических средств переключения событий
Предположим, что библиотека классов включает в себя графический интерфейс класса PictWindow, который отображает фотографию в окно:
class PictWindow <
Picture picture;
public:
virtual void repaint() < gt_draw_pict(picture); >
.
>;
Мы хотели бы наложить небольшой прямоугольник в определенной области изображения. С этой целью, мы можем попытаться создать подкласс PictWindow:
class OvWindow : public PictWindow <
Rect rect;
virtual void repaint() < gt_draw_rect(rect); >
>;
К сожалению, когда мы создадим экземпляр OvWindow, то увидим только прямоугольник в пустом окно, и никакого изображения. С того момента, как OvWindow::repaint() переопределяет PictWindow::repaint(), последняя функция не будет вызываться, когда окно должно быть отрисовано. Мы должны были реализовать OvWindow так:
class OvWindow : public PictWindow <
Rect rect;
virtual void repaint() < PictWindow::repaint(); gt_draw_rect(rect); >
public:
OvWindow(void) : PictWindow() <>
>;
Конструктор OvWindow изложен, чтобы подчеркнуть, что метод OvWindow::repaint() должен быть отложен до суперкласса, как делают конструкторы. В самом деле, конструктор производного объекта с начала вызывает конструктор корреспондирующего объекта. repaint() следует отложить его родитель: методу в базовом классе, который его переопределяет.
В итоге: Плохая совместимость C++ / GUI
C++ был разработан как «статический» язык:
- с отслеживанием лексем
- проверкой статических типов
- со статическими иерархиями классов
- без «сборки мусора»
- с системой сообщений без определенных иерархий времени компиляции
GUI объекты:
- характерны динамические объекты, а зачастую и единственные в своем роде
- как правило, живут далеко за рамками, в которых они были созданы
- иерархии определяются в значительной степени потоками событий и их расположением, а не наследованием классов
- иерархии строятся и разрушаются во время выполнения, зачастую в ответ на непредсказуемые действия пользователя
C + + не предназначен для поддержки динамической защиты обмена сообщениями и передачами (кроме исключений). Все это приводит к дублированию графического инструментария и функциональности оконного менеджера, разрастанию кода, использованию небезопасных функций и отказ от многих сильных сторон C++.
Выводы
Конечно, все эти «коряги» не являются фатальными. C++ является универсальным и мощным языком и, следовательно, способен выразить все возможные алгоритмы расчета. Поэтому, если приложение требует динамических функций, таких как те, что есть в Tcl / Tk, Scheme / Tk, Postscript и подобных; используя C++, Вы всегда можете сделать что-то по их примеру. С другой стороны, почему бы не использовать язык, где все эти черты присутствуют?
Источник статьи: http://habr.com/ru/post/93611/