?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

Современные GUI приложения - morfizm


Jul. 28th, 2016 02:29 am Современные GUI приложения

Я не писал GUI уже тыщу лет, наверное, со времён Дельфей. Полазил посмотрел, какие есть GUI-фреймворки. В частности, посмотрел Qt и JavaFX - даже если не привязываться к конкретному языку программирования, а просто смотреть, что там вообще есть из популярного.

Текущая ситуация с гуём меня огорчает. На дворе 2016 год, а всё ещё нет ничего по-настоящему кроссплатформенного, лёгкого в использовании и выглядящего нативно. Если отбросить кроссплатформенность, то для винды есть C#. Если отбросить десктопы и работать только с клаудом или другим серверным бэкэндом, то есть куча отлаженных веб-технологий (HTML, CSS, JavaScript). Всё остальное выглядит отвратительным геморроем.

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

Пришла в голову такая идея: сделать это как маленький веб-сервер. Доступ к локальной файловой системе, к тяжеловесному коду по генерации превьюшки и к любым другим клиентским фичам сделать через HTTP или TCP. Соответственно, инсталлятор утилитки прописывает firewall rule, чтобы разрешить этот порт для localhost, шорткат для запуска запускает сервер + открывает веб страницу + по закрытию клиент посылает серверу сигнал, что пора умирать. Или сделать, чтобы клиент посылал keep-alives, и как только в течение пары минут keep alives не слышно, сервер делает себе харакири.

Плюсы:
*) Кроссплатформенность. Кроссплатформенный сервер написать можно на чём угодно. Веб сайт, открывающийся во всех браузерах, я так понимаю, не очень большая проблема, если писать его правильно. Platform-specific код это только настройка firewall в инсталляторе.
*) Лёгкая переносимость на mobile если серверную часть начать где-то хостить (cloud back-end вместо localhost/desktop back-end).
*) GUI хоть и не будет выглядеть как нативное настольное приложение (browser-таки), но будет достаточно привычным и узнаваемым. С веб страницами все умеют работать.

Минусы:
*) Browser это всё-таки ненативный интерфейс. Может быть, будет неэстетично.
*) Возможно, будет долго загружаться. Как минимум, сотни миллисекунд по горячему или секунды по холодному.
*) Я не уверен, насколько легко разрабатывать и отлаживать Web гуй. Я этого очень давно не делал, но воспоминания со времён 2000 года у меня нерадостные. Хотелось бы IDE, autocomplete, пошаговый дебаггер и всякие тому подобные классные штуки. Они есть?

Ваши мысли? Есть ли что-нибудь ещё проще/правильнее для современных GUI приложений?

16 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:birdwatcher
Date:July 28th, 2016 10:40 am (UTC)
(Link)
А чем Qt не понравился? По-моему, он прекрасен.
From:lyuden
Date:July 29th, 2016 09:12 am (UTC)
(Link)
Я работал в основном с биндингами к Питону.

ИМХО. Невероятно сложная и глючная хрень. Особенно если люди пишут на сигналах, а не на моделях. Получить циклический граф вызовов - фигня. Отладка ? Какая отладка. QVariant, блин, ненавижу. Индексы в моделях - я не знаю какой извращенец их придумал.

Нативного вида нет ни на линуксе ни на винде. Перевод вообще эпичен. Ну т.е. да с нуля писать дольше. Но геммороя все равно хватает.

Веб в этом отношении куда как разумнее и понятнее.
From:dennyrolling
Date:July 28th, 2016 01:55 pm (UTC)
(Link)
debugging sucks testing rocks, но если сильно надо то в хроме все сейчас норм с дебаггингом.
From:juan_gandhi
Date:July 28th, 2016 02:31 pm (UTC)
(Link)
Уже давно пришел я к выводу, что весь гуй надо писать на вебе (html, js), а функциональность на бакенде. И даже локальную инсталляцию разбивать на эти два кусочка.

Впервые это я увидел в гугловском локальном поиске, который был выкачен этак лет 10 назад, и с тех пор забыт. Так с тех пор сам и делаю.
From:_m_e_
Date:July 28th, 2016 02:57 pm (UTC)
(Link)
Знакомая дилемма. Я так в 2000-ом написал гуй на HTML в МС.
То есть пришел я только-только в МС. Как писать гуй забыл.
Мне дают утилитку написать, много кода и чуть-чуть гуя.
Пишу на С++, регистрируют как COM, делаю гуй на HTA (это у МС считалось HTML Apps, позволило избежать сервера).

Сейчас кажется популярно бандлить Хромиум с сервером в одном приложении, для этого какие-то тулы были.
From:andreyvo
Date:July 28th, 2016 03:30 pm (UTC)
(Link)
С UI/UX беда, никто его не умел и не умеет делать. А на мобильниках вообще аховая ситуация. НИЧЕГО ХОРОШЕГО НЕТ НУ ВООБЩЕ. Особенно если мутить что-то кроссплатформенное, игры там тырыпыры...

Давным-давно, в году где-то 2000-ом был у нас один веб-магазин на PHP. Заказчику срочно понадобилась оффлайн версия, каталог на CD, для понтов и презентаций. Сваял за неделю на Delphi, весь дизайн HTML-ный показывался через хитровыеб@ный ActiveX в окне IE4. MySQL базу конвертнули в .dbf-ки, каким-то макаром даже SQL запросы работали, практически без изменений, и главное весь этот глюкодром даже работал, причем с сюдюка.

From:ermouth
Date:July 28th, 2016 06:51 pm (UTC)
(Link)
Делать как HTML5 + js, компилировать в приложение с помощью http://electron.atom.io/

Какой конкретно фреймворк использовать для гуя – сложно сказать, не зная задачи и твоих скиллов/пристрастий.
From:sasha_gil
Date:July 29th, 2016 01:54 am (UTC)
(Link)
Да, я про Электрон читал на Хабре, его сравнивали с более старым фреймворком такого типа NW.js (node-webkit) https://habrahabr.ru/post/304574/, плюсов больше набрал Электрон.

Можно ещё такой финт на тему "выглядящего нативно" (то есть без HTML, JS управляет платформно-специфичным маркапом, который надо делать отдельно для мобильных платфом iOS / Android / Windows Universal, то есть Windows 10): забить на "десктоповость" и взять мобильный фреймворк React Native или NativeScript. Под Windows 10 запускать результирующее приложение как Windows Store приложение. Я сейчас смотрю на React Native, у него недавно появилась интеграция с Windows. На NativeScript я думаю посмотреть позже, сейчас просто проверил, что с Windows 10 интеграция тоже недавно появилось.

Дима, если ты это читаешь - кроме рассматриваемой идеи JS-приложения имей так же в виду Xamarin (кроссплатформенный С#), он нынче бесплатный extension к Visual Studio 2015. Unity - тоже кроссплатформенный C#, но это коммерческий продукт (и я не знаю, как там с библиотеками контролов, это игровая платформа в первую очередь). Если всё-таки выберешь JS... Я лично, если буду когда-либо что-либо делать на JS, буду с самого начала использовать TypeScript. У NativeScript он с самого начала хорошо прикручен, но, по идее, прикрутить можно где угодно с компиляцией в JS.

Коррекция: я писал выше "Windows 10" как синоним "Universal Windows", однако возможность строить "Universal Windows" приложения для Windows Store появилась в Windows 8.1. Это мелочи, поскольку Windows-телефонами никто не пользуется (и, вероятно, они умрут, но ещё не умерли). Да, вот тут https://www.nativescript.org/blog/nativescript-and-xamarin авторы / хозяева NativeScript сравнивают его с Xamarin.

Edited at 2016-07-29 02:45 am (UTC)
From:_m_e_
Date:July 29th, 2016 08:00 am (UTC)
(Link)
спасибо за линки, очень интересно!
From:sasha_gil
Date:July 29th, 2016 06:56 pm (UTC)
(Link)
Это вприглядку в основном - на практике я установил и пособирал в разных конфигурациях React Native для Windows Store в рамках короткого экспериментального проектика. Программировать простую UI логику на JS удобно, потому что типа быстрый REPL (ну ты сам про это написал выше по опыту 16-летней давности), но я этот язык так и не полюбил, хотя два года на нём писал. Он, правда, улучшается, и поддержка в IDE улучшается тоже. Если ты что-то интересное найдёшь, дай знать! В этой области "актуальные" вещи меняются довольно быстро.
From:ermouth
Date:July 29th, 2016 11:36 am (UTC)
(Link)
Насчёт TS/NS – по-моему, вы зря продвигаете технологии, которыми сами не пользуетесь.

TS в маленьких проектах, делаемых в одно лицо – просто лишний слой. «В гамаке и скафандре», да.

Насчёт NS – там всё грустно с поддерживаемыми гуёвыми контролами. Хотите контрол с календариком? Извольте заплатить $199.

Начинать с них точно не стóит.
From:sasha_gil
Date:July 29th, 2016 05:53 pm (UTC)
(Link)
конкретнее про мой опыт с TS версус JS. Я писал три года назад на JS в Visual Studio апп для Windows Store среднего размера в команде человек пять и чувствовал себя очень некомфортно, собирался переводить на TS, но проект закончился раньше. Года два назад помогал школьнику с маленьким проектиком и тоже почувствовал себя легче с TS. С тех пор JS обновился, и среду разработки можно выбрать более дружественную к JS, но мне лично этот лишний слой при работе с Visual Studio был нужен. Правда, я сейчас на C++ пишу, моё мнение неуместно и необосновано. Расскажите поподробнее про Электрон, вы с ним работаете / работали?
From:ermouth
Date:July 29th, 2016 08:47 pm (UTC)
(Link)
> но мне лично этот лишний слой при работе с Visual Studio был нужен

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

Скромное распространение TS, особенно если учесть мощь вендора – дополнительный (хотя и небесспорный) аргумент в пользу того, что накладываемые ограничения серьёзно обесценивают ООП-шные плюшки.

> Расскажите поподробнее про Электрон, вы с ним работаете

Тут надо сравнить nw.js и Электрон, по-хорошему то, и объяснить, почему я посоветовал Электрон.

Мы не делаем десктопные/мобильные приложения на заказ, поэтому с Электроном я только вдумчиво баловался. С nw.js всё чуть серьёзнее, его мы используем в боевых условиях, но не как обёртку для изготовления стэндэлон-приложений. То-есть, приложения я с ним делал, но тоже в рамках вдумчивого «поиграться».

В силу того, что я занимаюсь по преимуществу гуем или тем, у чего есть гуй и он важен, я, конечно, пробовал обернуть уже имеющийся код сложных гуёвых разработок. С Электроном порог входа из точки «вот у меня есть html+js+css, сделай десктопное приложение» чуть выше, чем с nw.js. Тем не менее, после прохождения порога дальше телодвижений точно меньше.

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

Дима, скорее всего, будет в это всё погружаться из другой начальной точки. Что-то вроде «вот у меня есть логика, мне к ней нужен гуй» – он примерно про это пишет. С такими вводными и порог вхождения в Электрон будет ниже, чем в нод-вебкит, при сохранении мéньшего количества телодвижений overall.
From:sasha_gil
Date:July 30th, 2016 06:16 am (UTC)
(Link)
Да, это был ООП-стиль - во-первых, в обоих случаях обстоятельства диктовали; во-вторых, у меня нет опыта программирования в другом стиле.

Спасибо за информацию про Электрон / nw.js! Попробую найти время / силы поиграться с Электроном.
From:_winnie
Date:July 28th, 2016 07:07 pm (UTC)
(Link)
А после отладки в браузере - нет проблем приклеить вместо html-рендера какой-нибудь другой, если так будет сильно лучше для конкретной платформы (это сможет сделать даже другой человек).
From:lyuden
Date:July 29th, 2016 09:05 am (UTC)
(Link)
Эта идея мягко говоря не нова. Я сейчас лоббирую переписывание нашей программы с PyQt4 на embedded Chrome + react.js + HTML

https://github.com/cztomczak/cefpython

Тем более что мы параллельно все равно разрабатываем интерфейс для веба.

Вебсервер необязателен, так как можно вызывать функции из javascript нативно.


IDE отладка и тестирование для веб-интерфейса, на голову превосходят все что есть для отладки GUI не под javascript.