на чем писать desktop приложение
На чем писать мультиплатформенное desktop-приложение? Взгляд менеджера
Сегодня авторы большинства приложений уже не могут позволить себе выпускаться под одну платформу. Early adopters сидят под маками, мейнстрим сидит под Win32, а гики и адепты open source предпочитают Linux. Каждая из этих аудиторий обладает уникальными свойствами, а поэтому важна для большинства проектов.
Данная статья задумывалась как открытая попытка разобраться, на чем стоит писать мультиплатформенное desktop-приложение. Приглашаю высказать свое мнение людей с опытом создания таких приложений.
Изначально определим критерии, по которым будем оценивать различные платформы. В первую очередь — это удобство пользователя. Уверен, что вы замечали общие черты у приложений, написанных под разные платформы. Во вторую — это интересы проекта. Моя задача — построить успешный бизнес, а не играться с различными инструментами.
Обозначим рамки исследования. Мое приложение — небольшая утилита для пользователя-«чайника», которая качает файлы из интернета: минимум GUI, небольшой набор функциональности, использование внешних С++ библиотек.
Ну что, начнем. Какие есть варианты? Я рассмотрю Java, C#, C++, Python. Буду рад, если вы расскажите о других альтернативах.
Данный язык/среда изначально задумывались как нечто мультиплатформенное. На Java написано большое количество приложений, крупные проекты вроде Eclipse используют именно этот фреймворк.
Все приложения, которыми мне доводилось пользоваться, не использовали «родной» интерфейс Win32. Не знаю, чем руководствовались разработчики, но с точки зрения конечного пользователя это выглядит очень не симпатично.
Примеры приложений: Eclipse, ZDE, клиент для Gnutella Limewire.
Плюсы: мультиплатформенность, большое количество кадров, развитость фреймворка.
Минусы: необходимость установки фреймворка, кривость GUI, низкая производительность.
Аналогично с Java, приложения на C# имеют большой минус — необходимость устанавливать фреймворк. Я сам отказался от установки несколько приложений, которые требовали этого фреймворка. Менее продвинутые пользователи будут ещё более требовательными.
В остальном — сплошные плюсы, на мой взгляд.
Примеры приложений😕
Плюсы: мультиплатформенность, большое количество кадров, хорошая производительность, развитость фреймворка.
Минусы: необходимость установки фреймворка.
Старичок дотянул до наших дней и замечательно себя чувствует. Много приложений под платформы Linux и Windows до сих пор пишутся на этом языке.
Программы, написанные на C++, являются примером для других по размеру дистрибутива и экономному использованию системных ресурсов (процессор, память). Тем не менее у разработчиков есть масса претензий к С++. По моему мнению, язык является «устаревшим» и его популярность в дальнейшем будет снижаться, что подтверждается индексом TIOBE.
С точки зрения развития проекта, по сравнению с динамическими интерпретируемыми языками (вроде Ruby и Python), разработка на данном языке может иметь менее высокую скорость и более высокие издержки изменения проекта. Для стартапа, которому не столь важна производительность приложения, это может стать существенным минусом.
Примеры: Firefox.
Плюсы: отличная производительность, большое количество кадров, большое количество библиотек.
Минусы: невысокая скорость разработки.
Python
Взглянуть на Python в качестве платформы для desktop-приложений меня заставила программа MusicBrainz Picard. Несмотря на свою скриптовую сущность, Python легко собирается в один exe-файл, не требуя от пользователя установки дополнительных компонентов.
В случае разработки небольшого приложения, интерпретируемые языки вроде Python будут большим плюсом. Легкость написания и высокая скорость изменения приложения пригодится любому стартапу.
Огромным минусом различных «модных» технологий является их низкое распространение, а значит серьезные проблемы в поиске квалифицированных кадров. Ситуация с поиском программистов итак плачевная, а если ограничиться узким языком — можно вообще никого не найти. С другой стороны, храбрость перейти на новый язык имеют наиболее прогрессивные разработчики. Может получиться так, что выбрав «перспективный» язык, мы сразу отсечем миллионы середнячков, оставив себе выбор из нескольких перспективных разработчиков.
Пример: MusicBrainz Picard, оригинальный BitTorrent.
Плюсы: высокая скорость разработки и изменений, хорошая интеграция с библиотеками на С и С++.
Минусы: мало кадров, низкая производительность.
Выводы
К сожалению, любая из вышеперечисленных платформ имеет свои плюсы и минусы, однозначного решения найти не удалось. Выбор одной из них сегодня принесет преимущества и недостатки, влияние которых на проект мы увидим только завтра.
Я пока выбираю между С++ и Python. Первый является «надежным» решением с известными недостатками. Второй является «рискованным», но интересным и перспективным. Надеюсь, ваши отзывы помогут мне сделать окончательный выбор. Какую платформу выбрали бы вы на моем месте?
PS. Я сейчас ищу программистов в этот стартап (с++/python/php), поэтому если кому интересно — присылайте свое резюме.
Какой язык программирования выбрать для создания десктопных приложений?
Какой язык программирования будет предпочтительнее для создания десктопных приложений?
Сейчас учу С++, но в итоге много начитался всякого и положил глаз на такой ЯП как Python. Вообще, о нём положительно отзываются, говорят, что самое то для новичка, кем я и являюсь. И еще, я самоучка, в дальнейшем, набравшись каких-то знаний и опыта, хотел бы попробовать устроиться на работу программистом, исходя из этого, я скорректирую первоначальный вопрос: какой язык программирования выбрать, желательно, чтобы он был востребован на рынке, ну если нет, то хотя бы чтобы давал неплохую базу, вообще средства для разработки.
Живу в СПб. В основном, как я посмотрел, нужны знания таких ЯП»ов как: 1с, С#, С++. Ну и ряд других для веба, как я понимаю, что-то типа PHP, Java Script etc.
Вообще, для начала, я вижу путь таким: учить какой-нибудь ЯП; окунуться в базы данных типа SQL/MySQL, ну и конечно же English. А что скажете Вы на этот счёт? Я как-то расплывчато всё написал, даже частично съехал с темы, но за любые советы будут премного благодарен.
Оценить 6 комментариев
> дело не только в IDE, а в жёсткой привязке к графическому интерфейсу и кастрированной командной строке.
Это вы о чем?
> GUI — это, безусловно, нужно, полезно, красиво и часто удобно, но многие задачи, особенно связанные с разработкой, удобнее делать в консоли.
А здесь я уже включаю Architect’а, и говорю, что консольность ядра приложения еще никак не исключает отсутствие GUI-оболочки.
Но линуксоиды с этим не согласны и в большинстве своем не любят GUI, а любят консоль и скрипты. Именно поэтому линуксоидовские Development Tools отстают по GUI. И с этим *не* нужно что-то делать.
А вот на винде, GUI во все поля, и с этим также ничего не поделать, а значит, на винде надо юзать C#, а не линуксоидовские Development Tools.
В общем, мы пришли к тому же, от чего пытались уйти.
Да, я пишу десктопные приложения под Windows
Здравствуйте, меня зовут Владимир и я анонимный разработчик десктопных приложений под Windows. В этом месте все должны сказать «Здравствуй, Владимир!», а кто-то может быть добавит «Молодец, что осознал!». А потом все похлопают. Нет, правда, иногда от чтения Хабра у меня возникают именно такое ощущение, что нормально, нет, даже не «нормально», а допустимо и одобряемо сегодня писать только микросервисы для каких-то стартапов, которые будут по какому-то REST API отдавать данные какому-нибудь фронтенду на Ангуляре, который и будет, наконец, показывать пользователю что-то невероятно полезное, вроде таблицы с аггрегированными отзывами о стрижках пуделей с возможностью посмотреть на гуглокартах где бы в вашем городе можно было сделать именно такую стрижку вашему пуделю (несуществующему). А никаких других программ писать уже нет-нет, никак нельзя! Что за чушь?!
Да, многое сегодня происходит в вебе и на мобильных устройствах, но, знаете ли, далеко не всё. Значительная часть приложений по-прежнему является десктопным софтом. И даже (о, ужас!) не под Mac Os или Linux, а под тот самый богомерзкий Windows. И, знаете ли, софт этот живёт, развивается, поддерживается и является ежедневным рабочим инструментом миллионов людей. И никуда он мигрировать не собирается, потому что есть причины, по которым иногда именно десктопное приложение является лучшим вариантом.
Десктопный софт работает без интернета
Работа пользователя не прервется от падения столба на датацентр Амазона или умелого тракториста в соседнем дворе. Вся мощь криворуких сисадминов провайдера, Великих Правительственных Файрволов, горе-хакеров, облачных сервисов, которые на самом деле ни разу не облачные — всё это бессильно перед ПО, которому не нужен интернет, чтобы работать. Пользователь приходит на работу, открывает свой Autocad\Maya\ПО_по_рассчёту_дырчатости_бубликов — и получаёт свой результат, который принесёт его фирме деньги. А больше ничего и не надо.
Лицензирование десктопного софта просто и понятно
Нет, бывают, конечно оригиналы, которые невероятно удачную модель лицензирования «ваша программа через год превратиться в тыкву» заменяют на ещё более удачную «ваша программа через год откатит все апдейты и превратится в семена тыквы». Но это редко. В основном вы покупаете программу, активируете лицензию — и она работает. Всё, что бы там дальше не стрельнуло в голову её авторам — уж по крайней мере эта версия у вас работать не перестанет! 100% гарантия того, что завтра вы включите компьютер и вот этот вот ярлык запустит то же самое, что работало вчера — не прекрасно ли это? Можете ли вы рассчитывать на такую же гарантию у веб-сайта? Да черта с два — вспоминаем недавнюю историю с некоторым популярным сервисом про кино. Ну так ладно кино, а если бы что-то подобное произошло с ресурсом, на который завязана ваша работа и зарплата?
Десктопный софт выглядит одинаково каждый день
Установив некоторую версию софта, человек может научиться работать в ней быстро и эффективно. Со временем ты изучаешь быстрые клавиши, уже не ищешь ту или иную кнопку, ты знаешь что сейчас произойдёт и сколько времени это займёт. Работа становится предсказуемой. Если менеджер в фирме по установке пластиковых окон уже рассчитал в некоторой специализированной программе 100 окон, то время рассчёта 101-го окна он может вам назвать с точностью до пары секунд. И будет прав. Можем ли мы рассчитывать на что-то похожее с веб-сервисами? Ага, разогнались. Как же меня в своё время бесил Gmail, который к такой элементарной вещи как почта каждые 2 недели придумывал то фильтры, то теги, то категории, то 5 разных видов UI, то чат, то ещё какого-то черта лысого. Просто дай мне мою почту и ничего не меняй! Нет, так нельзя, надо вот сюда рюшечку и сюда иконочку. Ну и ладно, пойду-ка я в Outlook. С десктопным софтом вы сами, по крайней мере, решаете когда именно он будет обновляться и до какой версии.
Десктопный софт доступен для расширения
Частенько у десктопного софта есть система плагинов и есть уже готовые плагины, которые можно скачать и поставить. Ну или есть SDK и можно написать плагин самому. Или заплатить за его разработку. А даже если системы плагинов нет, то всё равно что-то да есть: есть интерфейс, который можно автоматизировать с помощью чего-то типа AutoIt, есть входные и выходные форматы данных, которые можно парсить, есть в конце-концов, бинарники, которые можно дизассамблировать и что-то подправить\понять\добавить. Нет, такое, конечно, по лицензии часто делать нельзя, но если очень надо, вот вопрос жизни и смерти человечества, то это по крайней мере физически возможно. А что с сайтом? Зачастую у нас либо нет вообще ничего, поддающегося расширению, либо есть API, который ограничен ровно настолько, чтобы ничего толком полезного с ним было сделать нельзя. Ну, спасибо большое.
Десктопный софт работает
В десктопной программе мне не нужно рассказывать пользователю, что у него старая версия IE или нет Flash или заблокировна Java — я просто поставлю инсталлятором всё необходимое. Мне не нужно его разрешение на геолокацию или доступ к папке с фотографиями — я пропишу его согласие на это в том лицензионном соглашении, которое все принимают не читая. У меня есть доступ к железу. У меня есть доступ к диску. Я могу написать всё, что угодно и не заниматься героическим решением задач типа «как передать данные из одной вкладки браузера в другую» или «как подписать платёж с помощью аппаратного криптоключа».
С десктопным софтом быстрее начать работать
Это кажется парадоксальным — ведь устанавливаемое ПО нужно скачать и установить, а сайт можно просто открыть в браузере. Но давайте посмотрим, что будет дальше: десктопное ПО запустится по двойному клику на иконке и сразу готово к работе. В то время как сайт, скорее всего, попросит вас зарегистрироваться (нудная процедура, ещё небось и капчу разгадывать заставят), потом пришлёт вам письмо для подтверждения почты, потом попросит авторизоваться. Если мы говорим о платных сервисах, то за десктопную программу нужно заплатить 1 раз, а сайт скорее всего попросит подписаться на регулярные взносы. В итоге скачать пару мегабайт и 2 раза нажать «Next» в инсталляторе получается куда быстрее пробежки по граблям при попытке начать пользоваться модным сайтом.
Десктопный софт работает быстро
Да-да, я знаю что Javascript по бенчмаркам работает уже в 2 раза быстрее ассемблера. Да хоть в 10 раз бенчмарки эти ваши будут показывать — что-то не выходят пока что последние Call of Duty и GTA в браузерах. По-старинке гоняют байтики древним нативным кодом. И чего это они? Не понимают ничего, видимо.
Десктопный софт можно контролировать
Саму инсталяху можно проверить антивирусом. И установленную программу можно. А ещё её можно запустить от юзера с ограниченными правами. Или в виртуалке. Или ограничить файрволом. Данные из неё можно сохранить локально, а можно — на удалённый диск. Можно забекапить. Удалить можно. Что из этого всего можно сделать с веб-сайтом? Вы понятия не имеете, что он сделает с вашими данными, куда сохранит, кому продаст, когда потеряет, почему не забекапит и зачем оставит после удаления вашего аккаунта.
Почему же в окружающей нас хабрареальности (и не только) так мало уделяется внимания десктопному ПО и так много информации о веб- и мобильной разработке?
Где писать desktop приложений на C++ под Windows?
Здравствуйте!
Я только учусь программированию и на данный момент изучаю C++, так уж вышло, что я хочу разрабатывать именно на этом языке именно Desktop приложения. Не могли бы вы подсказать что для этого лучше всего подходит, что дополнительно к C++ стоит выучить?
В интернете я нашёл связку C++ + Qt, она действительно самая лучшая или есть что-то кроме неё?
Простой 5 комментариев
Если хочешь писать быстро и качественно, то C++ тебе тут не поможет при всём моём уважении к QT. Ответ всегда супер очевидный, хочешь писать десктопные приложения(это очевидно только Windows/macOS), то писать нужно нативно. Под Windows это C#+WPF, под macOS это Swift. Оба эти языка позволяют с лёгкость(ну почти) перейти на другой род деятельности. Скажем с C#+WPF(делаем десктопные приложения), перейти в WebDev с тем же языком C#+что-то, перейти на написание игр под Unity(тоже C#), писать мобильные приложения под iOS/Android на Mono(тоже C#). Вообщем сами видите, что C# Вас ни в чём не ограничивает, плюс как язык он куда быстрее развивается нежели C++(да это не всегда говорит, что язык лучше, но всё же). История про Swift развивается таким же макаром, только там платформа macOS.
А что C++? Куда Вы пойдете дальше, если Вам захочется делать что-то другое? На C++ пишут игры, может узко специализированные вещи, которые на данном этапе Вы конечно делать не будете.
Десктопные приложения на JavaScript. Часть 1
Ни для кого не секрет, что в наше время JavaScript стал одним из самых популярных языков программирования. В далекие 90е годы, в момент зарождения языка, когда он был создан с единственной целью добавить интерактивность веб страницам и улучшить процесс взаимодействия с пользователем, кто бы мог подумать, что он достигнет столь небывалых высот. Ведь сейчас на нем можно делать практически все что угодно. Хотите написать сайт: и бэкэнд и фронтэнд на JavaScript? пожалуйста! Хотите написать мобильное приложение на JavaScript? нет проблем. Программируете микроконтроллер – и тут вам на помощь придет JavaScript.
Есть конечно небольшие минусы в подходе использования JavaScript везде, но если поразмыслить, то сколько времени и сил можно сэкономить, изучив всего лишь одни язык, особенно, если то же самое приложение должно работать на разных платформах. Разных платформах говорите? Хм… Точно – разных платформах – теперь JS может позволить себе десктопные приложения для Windows, Linux, Mac, как спросите вы? Ответ прост: встречайте – NW.js.
По первым буквам можно прочитать – Node.js + Webkit, если данные понятия вам пока не знакомы, то скоро вы поймете о чем идет речь.
Node.js – программная платформа, основанная на движке V8, который транслирует наш скрипт в машинный код. Данная платформа была создана в 2009 году преимущественно для работы с бэкэндом сайтов.
WebKit — свободный движок, разработанный компанией Apple. Впервые был анонсирован в составе Safari в 2003 году
Итак, коду, написанному на JS для данной технологии, будут доступны как Node.js модули, так и стандартный браузерный API (соответственно WebKit)
Быстрый старт
Все это конечно хорошо, но с чего же начать? На github можно найти и скачать репозиторий с исходным кодом. Так же здесь можно найти прямые ссылки для скачивания под ту платформу, на которой будет вестись разработка. Помимо прочего нам понадобится установленная node.js.
После того, как необходимое ПО скачано и установлено, вы написали свое приложение на любимом JS (как это сделать читайте далее) и локализовали все в одну папку. Полдела сделано, теперь остается самое сложное и долгое – упаковать все в один файл и подготовить для распространения. Для упрощения вы можете воспользоваться готовыми библиотеками, например nw-builder. Установка библиотеки не составит труда, если вы уже работали с node.js. Как известно, в состав node.js входит менеджер пакетов npm, с которым нужно работать из командной строки. Для того, чтобы поставить какую-либо библиотеку, необходимо выполнить команду:
Обратите внимание, что библиотеку можно ставить, как локально, так и глобально, для локальной установки используйте опцию —save-dev, для глобальной -g. Таким образом поставим наш сборщик для NW.js глобально, выполнив команду:
Для того, чтобы собрать наше приложение, необходимо выполнить команду (с большим количеством опций можно ознакомиться в документации):
В качестве имени платформы могут быть следующие значения: win32, win64, osx32, osx64, linux32, linux64.
Во время разработки нет нужды каждый раз собирать приложение, можно просто запустить его как есть и оно откроется в отдельном окне. Для этого нужно запустить приложение nw.exe из командной строки и передать в качестве параметров путь к папке с вашим приложением. Кроме того, если вы работаете под Windows, можно просто методом drag-n-drop перетащить папку с исходным кодом приложения на JS (обратите внимание, что именно папку целиком) в nw.exe.
Hello, world!
Теперь, когда вы знаете, как запустить приложение, как собрать его в один файл, давайте напишем что-нибудь. По традиции знакомство с новой платформой начинается с написания приложения Hello, world.
Для данного приложения, нам даже не понадобится JavaScript, только HTML. Создадим папку с названием HelloWorld. Поместим внутрь файл index.html со следующей разметкой:
Кроме того для каждого приложения под NW.js необходим файл, который обязательно должен называться package.json. Из него будет браться информация для построения приложения. Создадим простейший вариант файла и поместим в папку HelloWorld. Итак:
Содержимое файла понятно без пояснений (обратите внимание, что обязательные поля только main и name). В main необходимо записать файл с разметкой, который будет являться точкой входа в приложение. Секция window настраивает параметры окна (в данном случае мы отключаем панель инструментов и задаем размеры окна 500×200).
Кроме того, можно настроить такие поля как (за полным списком опций обращайтесь в документацию):
Приложение написано, но в нем всего один div элемент и совсем нет логики, а что делать, если у нас богатая на элементы разметка и сложная логика? На помощь к нам приходит элемент конфигурационного файла toolbar, который мы установили в false. Для того, чтобы сделать доступными средства отладки, необходимо установить toolbar в true. Проделав это при запуске приложения мы получим следующее окно:
После нажатия на кнопку в верхнем правом углу откроется еще одно окно, в котором будут отображены знакомые инструменты разработчика:
Работа с нативными контролами
NW.js позволяет работать с нативными контролами. Рассмотрим работу на примере меню. Для работы с нативным UI контролами в nw.js необходимо использовать модуль nw.gui, который можно подключить следующим образом:
Общий шаблон для использования контролов:
Таким образом для создания элементов меню можно воспользоваться следующей конструкцией:
Кроме того любые свойства созданного нами объекта можно легко изменить стандартными конструкциями JS, например так:
Меню создано, теперь нужно его заполнить, для манипуляции дочерними элементами существуют методы:
Кроме того для более гибкого добавления элементов в menu можно воспользоваться методом insert, в параметрах которого необходимо передать MenuItem и номер позиции, куда его вставить (позиция перед первым элементом соответствует 0).
Для доступа к созданным элементам можно использовать свойство items:
Обратите внимание, что нельзя напрямую создавать элементы:
Самое главное при работе с нативными контролами, это помнить, что любая ошибка при работе с ними может привести к краху всего приложения, поэтому необходимо быть крайне внимательными и по возможности при удалении элементов, также присваивать переменной значение null. Таким образом для удаления контрола, можно выполнить следующее:
Для более удобной работы с контролами, они унаследованы от EventEmitter, поэтому хорошая новость в том, что мы можем легко работать с событиями, например так:
Меню было создано, но если запустить приложение, то никакого меню вы не увидите. Для отображения меню существует метод popup, в параметрах которого необходимо передать координаты для отображения меню.
Для демонстрации основных возможностей меню добавьте следующий скрипт к созданному ранее проекту Hello, world:
После запуска приложения, мы можем увидеть созданное контекстное меню для body. Таким образом, мы можем определить контекстное меню для любого элемента.
Итак, теперь кроссплатформенные приложения может создавать каждый, но за все нужно платить. В данном случае мы жертвуем как скоростью, так и занимаемым объемом памяти (собранное приложение получается достаточно большим, более 50 Мб). Список приложений, созданных, используя данную технологию можно найти на github.
Во второй части статьи мы рассмотрим технологию более подробно.