Есть ли UI движки, написанные не в ООП парадигме?

6yrop

Есть ли UI движки, написанные не в ОПП парадигме?
Без DOM и т.п.?

Maurog

Есть ли UI движки, написанные не в ОПП парадигме?
Tk ?

yroslavasako

Есть статьи по GUI в стиле FRP, движков не видел. Это же хаскель, он для академического применения.
Плюс все старые движки из 90х рассчитаны на процедурное программирование, а не ООП.

0000

Точняк - WinAPI для GUI, например :D

luna89

http://elm-lang.org/

Dasar

Не графических UI таких полно.
С графическими сложнее..
Изначально GUI собой представляет экран, состоящий из набора подобластей экрана, где каждая подобласть обладает своим состоянием и набором действий, которые с этой областью можно произвести.
И такое представление полностью совпадает с объектно-ориентированным представления.
Поверх ОО-представления можно натянуть процедурное программирование, ОО-программирование или функциональное.
Процедурное по сравнению с ОО-программированием ничего интересного не дает (единственный плюс, что можно использовать более примитивные языки). И если поскрести всякое процедурное API, то под ним почти всегда найдутся объекты
Функциональное программирование намного интереснее.. С помощью функционального программирования gui можно представить в виде stateless варианта, что увеличивает возможности по декомпозиции/композиции кода, но за это приходится расплачиваться преобразованием из stateless-вида в state-вид.
Соответственно, исполнительный движок для GUI почти всегда является объектным, а вот описание(формирование) интерфейса бывает делается в функциональном (или декларативном) виде.

Maurog

Qt Quick
off site: http://qt-project.org/wiki/Qt_Quick

6yrop

Изначально GUI собой представляет экран, состоящий из набора подобластей экрана, где каждая подобласть обладает своим состоянием
Почему там состояние?
Вот, скажем, на экране отображается DateTime.Now.ToString. Зачем у элементов UI движка состояние? Пусть сразу из системного таймера отображается на экран.

yolki

curses?

apl13

Он двухсторонний: с одной стороны деревянный декларатив, а с другой стороны JavaScript.

Bibi

http://github.com/swannodette/om/wiki/Conceptual-overview
http://adamsolove.com/js/clojure/2014/01/06/om-experience-re...

Dasar

Почему там состояние?
поведение той же кнопки (изменение отображения при наведении мышки, при переходе табом, при нажатии и т.д.) без введения понятия "изменяемое состояние" (или его аналога) - хрен опишешь.

yroslavasako

поведение той же кнопки (изменение отображения при наведении мышки, при переходе табом, при нажатии и т.д.) без введения понятия "изменяемое состояние"
зачем. У кнопки есть просто несколько луков. А изменяет состояние только "курсор" - в общем смысле.

Dasar

У кнопки есть просто несколько луков.
т.е. у кнопки есть изменяемое состояние "текущий лук"?
ps
если лук анимированный, то еще появляется состояние - текущий кадр отрисовки (время от начала отрисовки и т.д.)
pps
я согласен, что всякий изменяемый объект можно представить как последовательность immutable-объектов. Но при этом с точки зрения проектирования - это же будет всё равно один и тот же объект.

yroslavasako

т.е. у кнопки есть изменяемое состояние "текущий лук"?
нет, у кнопки есть все луки одновременно. А курсор их селектит.

apl13

Ты знаешь, в пятом Qt ввели давно напрашивавшийся коннект к просто лямбде.
Потому уже тринадцатый год на дворе, и они так устали писать свои слоты, которые превратились в велосипед.
Это так, к вопросу об объектах и просеках.
Experienced Object-Oriented Programmer тебе будет три часа с пеной у рта рассказывать, какая пиздатая его любимая AngularF++ Enterprise Platform, и как на ней в легкую реализуются любые шаблоны проектирования™. Потому что имеет очень плохое представление о том, что его любимые шаблоны проектирования™ были придуманы как маленькие функциональные костыли в AngularF++ Enterprise Platform за отсутствием там действительно функциональных шаблонов.

Dasar

нет, у кнопки есть все луки одновременно. А курсор их селектит.
да, так удобно делать.
с текстовым полем что делать? без изменяемого состояния тяжело будет
ps
отличие dblclick от click без изменяемого состояния не сделаешь. а их от mouse down + mouse move
drag&drop, мульти выделение и т.д.

Dasar

Ты знаешь, в пятом Qt ввели давно напрашивавшийся коннект к просто лямбде.
давно пора.
как в итоге выглядит?
AngularF++ Enterprise Platform
речь же сейчас не о них

apl13

как в итоге выглядит?
static QMetaObject::Connection QObject::connect(const QObject * sender, PointerToMemberFunction signal, Functor functor)

yroslavasako

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

yroslavasako

мульти выделение и т.д.
А тут просится data oriented программирование.

Dasar

А тут просится data oriented программирование.
в смысле?

Dasar

Есть только одно поле, текущее, которое можно менять.
введенный текст где хранится? и позиция курсора внутри текста?

yroslavasako

в смысле?
http://en.wikipedia.org/wiki/Data-driven_programming
То есть мы работает с не с конкретным объектом, который может быть выделен или нет, а с коллекцией сразу.
введенный текст где хранится? и позиция курсора внутри текста?
В процессе ввода - в самом макрокурсоре. Потом дискардится. В макрокурсоре, конечно, есть состояние, но взаимодействие с юзером совсем без состояния сделать не возможно. ООП - это когда состояние размазывается между объектами. А здесь оно сведено в одной точке - фокус юзерского ввода (и клавы и мышки).
Вообще забавный может получиться фреймворк, если основным принципом его построения положить "назло маме отморожу уши никакого ООП"

Dasar

http://en.wikipedia.org/wiki/Data-driven_programming
То есть мы работает с не с конкретным объектом, который может быть выделен или нет, а с коллекцией сразу.
вопрос скорее о том: как это будет выглядеть?
В процессе ввода - в самом макрокурсоре. Потом дискардится.
если внимательно посмотреть на работу текущего ui, то видно, что позиция внутри textbox-а не сбрасывается при переходе между textbox-ами.
Вообще забавный может получиться фреймворк, если основным принципом его построения положить "назло маме отморожу уши никакого ООП"
их как грязи (выше, например, ссылку давал ). не удобно большие приложения писать, потому что всё состояние и все ссылки наружу торчат, и приходится их в явном виде протаскивать от кадра к кадру

yroslavasako

если внимательно посмотреть на работу текущего ui, то видно, что позиция внутри textbox-а не сбрасывается при переходе между textbox-ами.
чем-то придётся жертвовать

yroslavasako

их как грязи (выше, например, ссылку давал )
Я как-то веб как гуи вообще не рассматриваю. Изначально веб - это формочки и представление данных, и никакого стейта (стейт обслуживает внешний по отношению к веб-приложению браузер). Потом туда добавили js, который есть дешёвая поделка для тех, кто не осилил common lisp, так что идея делать гуи на вебе порочна сама по себе, и фреймворки для этого можно просто не рассматривать. Они появляются не для развития гуи, а в качестве ретроградного отката к основам веба, когда гуи не было, не было нужды и объекты хранить, только формочки делать.

Dasar

Я как-то веб как гуи вообще не рассматриваю.
какая разница веб/не-веб?
Задачи, проблемы и способы их решения всё равно же одни и те же.

luna89

отличие dblclick от click без изменяемого состояния не сделаешь. а их от mouse down + mouse move
drag&drop, мульти выделение и т.д.
Без проблем, вот pure functional FRP double click на эльме:
 

import Mouse

clickTimestamp = lift fst (timestamp Mouse.clicks)

timeSinceLastClick = lift snd (foldp (\current (prev,delta) -> (current, current - prev (0,0) clickTimestamp)

dblclick = keepIf (\delta -> delta < 200) 0 timeSinceLastClick

main = lift asText (count dblclick)

Функция timestamp добавляет timestamp к сигналу. foldp позволяет склеить старое и новое значение сигнала, таким образом получаем сигнал со временем между двумя последними кликами. Отбрасывая клики, которые были после 200мс после предшествующего клика, получаем сигнал для дабл клика.

Dasar

такая замена изменяемого состояния раздувает код.

6yrop

их как грязи (выше, например, ссылку давал ). не удобно большие приложения писать, потому что всё состояние и все ссылки наружу торчат, и приходится их в явном виде протаскивать от кадра к кадру
Если состояние, действительно, есть по смыслу задачи, то оно и в программе пусть будет. Другое дело, зачем вводить лишнее состояние.
Пример. Пусть есть два текстовых (числовых) поля A и B. И есть просто выводимый текст C = A + B. И еще, если С > 77, то текст должен быть красным. В ООП движках мы должны написать:
C = A + B;
labelC.Text = C.ToString;
lableC.Color = C > 77 ? Red : Black;
Зачем здесь два изменяемых состояния labelC.Text и lableC.Color? В самой задаче этих состояний нет.

Dasar

согласен.
ps
мы сейчас, кстати, у себя во вспомогательных приложениях для GUI используем embedded web browser через FP-парадигму
код получается следующий (для данного примера):


HElement HView(int A, int B)

{

   var C = A + B;

   return h.Html

   (

      h.Body

      {

          h.Span(h.style(string.Format("color:{0};", C > 77, "red" : "black" C)

      }

   );

}

и дальше он сам автоматически обновляется
pps
html вместо winforms, wpf, qt и т.д. - из-за того, что для html много проще пишется автоматическое преобразование из FP-представления в object tree.
и есть крепнущее подозрение, что на большом сложном объектном дереве html-движок бегает много быстрее, чем нативные движки .

6yrop

embedded web browser
а конкретнее? IE или WebKit?

yroslavasako

Задачи, проблемы и способы их решения всё равно же одни и те же.
нет. Они разные. Ну если только совсем на абстраргироваться, но тогда консоль и гуи тоже решает одни и те же проблемы одинаковым способом.
Веб - это изначально формы, отправление которых контролировалось не самим веб-приложением, а браузером. То есть фактически stateless, а это на гуи не тянет. Потом по маркетологическим соображениям "веб - самая распространённая платформа" к нему прикрутили слой эмуляции, чтобы добавить стейт и там развилось ООП. Потому народ заметил, что это нихреновый оверхед как для программистов, так и для софта, и появилось движение за откат к основам, но с некоторым украшательством. И возможным он стал только благодаря тому, что веб изначально был стейтлес. Вся эта движуха - локальный веб-мем, и к ГУИ общего назначения не применим.

yroslavasako

такая замена изменяемого состояния раздувает код.
CPS тоже раздувает, но лечится сахаром. Здесь, думается мне, тоже можно вылечить.

Dasar

CPS тоже раздувает, но лечится сахаром. Здесь, думается мне, тоже можно вылечить.
в данном случае, сахар будет делать хитрое замыкание, а это тот же объект - вид в профиль.

luna89

ак что идея делать гуи на вебе порочна сама по себе,
Какая на твой взгляд лучшая платформа для гуя?

Dasar

Вся эта движуха - локальный веб-мем, и к ГУИ общего назначения не применим.
ты зачем-то ее рассматриваешь с точки зрения исторического развития.
если же просто посмотреть на то, что выросло, то нет никакой серьезной разницы между QT, WinForms, Gtk, WPF и Html dom. Везде объектные деревья, события и т.д., рядом (нативно или с помощью каких-нибудь костылей) болтается возможность задать дерево декларативно, с еще большими костылями бывает прикручена и FP-парадигма.
Соответственно, на всех этих движках идеология построения интерактивного UI получается одинаковая.

Dasar

а конкретнее? IE или WebKit?
IE. 9-ый движок вполне неплох.
webkit здоровый, а под linux-ом всё равно не работает.

6yrop

код получается следующий (для данного примера):
это C#?

Dasar

это C#?
да

yroslavasako

Какая на твой взгляд лучшая платформа для гуя?
Ну бекенд точно должно уметь сорт opengl, сама платформа предоставлять широкий канал для передачи сообщений для общения элементов гуя друг с другом. Логику можно выносить на сервер, но это не суть важно. html предоставляет возможность для второго (javascript даже будучи интерпретируемым даёт неплохую скорость но не для первого. Если для логики приложения допустимо использовать медленный скриптовый язык, то для написания самих виджетов - нет.

Dasar

то для написания самих виджетов - нет
пример можно когда js не хватает?
ps
webgl, кстати, уже более-менее везде поддерживается

yroslavasako

анимированные виджеты с эффектами.

Dasar

анимированные виджеты с эффектами.
js не хватит только если состояние каждого пикселя по отдельности считать.
если же использовать более массовые примитивы (полигоны, градиентную заливку и т.д. то js вполне хватит.

yroslavasako

А если классические текстуры?

Dasar

А если классические текстуры?
тогда это просто картинка, которая привязывается по паре точек.

karkar

>их как грязи (выше, например, ссылку давал )
Я как-то веб как гуи вообще не рассматриваю.
В случае Elm там вебность не особо ощущается, так, деталь реализации. Программа там оперирует достаточно универсальными вещами (текст, картинка, кнопка, мышка, расположение элементов так и сяк). Тот же самый Elm можно сделать с отображением средствами WPF или OpenGL или GDI, ничего не поменяется в самом языке и подходе.

karkar

такая замена изменяемого состояния раздувает код.
По моему скромному опыту - обычно наоборот, код сильно короче получается. Но чтобы к нему прийти, надо сперва сильно мозг вывихнуть, очень непривычно в FRP работать.
Мой реальный пример с обсуждением тут:
http://thedeemon.livejournal.com/66870.html
Вообще на примеры тут полезно полюбоваться:
http://elm-lang.org/Examples.elm
Правда, если говорить конкретно про Elm, то для практических применений у него UI библиотека слишком бедная сейчас.

6yrop

для практических применений у него UI библиотека слишком бедная сейчас
как раз для серьезного практического применения набор готовых контроллов не так важен. При серьезном использовании контроллы пишутся свои. Написание контроллов — хорошо для освоение инструмента. Главное, чтобы базовые элементы: язык, примитивы, были правильные.

Dasar

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

bleyman

Точняк - WinAPI для GUI, например
что. WinAPI это самое что ни на есть хардкорное ООП, прям как Grady Booch его описывал в основополагающей книжке.
Оставить комментарий
Имя или ник:
Комментарий: