30.07.2012 2:43 дп

NakeyMonkey

Jason Southwell предлагает разработать набор FireMonkey-оберток для нативных контролов Windows/OSX и собирает на это деньги. Планирует для начала собрать 20 тысяч долларов.

Идея ясна. Существующие компоненты FireMonkey отрисовываются средствами Delphi практически с нуля, что с одной стороны во многом и обеспечивает их кроссплатформенность, но с другой — в результате мы получаем компоненты не вполне естественно выглядящие в обеих поддерживаемых на сегодня ОС. И это полбеды — кроме внешнего вида, приходится самостоятельно разрабатывать и логику этих компонентов. Например, RichEdit довольно сложен, самостоятельно повторить его логику в рамках FireMonkey — задача не из тривиальных. И VCL, и CLX не изобретали велосипедов, а пользовались готовым.

На резонный вопрос «почему у NakeyMonkey получится то, что у Kylix CLX в свое время не получилось?» Джейсон отвечает, что проблема CLX была в использовании лишнего промежуточного слоя в виде Qt, NakeyMonkey же не будет привязан к циклу разработки и прочим прихотям третьесторонней библиотеки, но в целом ей будут присущи все тяготы и лишения CLX.

Ваши мнения? Как это могло бы вписаться в идеологию стилей FireMonkey?

update
Алексей Казанцев обнаружил интересный комментарий Дэвида И. Суть в том, что Embarcadero работает над нативными компонентами для FireMonkey и у разработчиков будет выбор, какие компоненты использовать: векторные или нативные. По-моему, это очень серьезная новость.

Метки: Delphi, FireMonkey

19 комментариев

1. Андрей

30 Июл 2012 9:59 дп

Бегло прочитал оригинал. Объяснение немного туманное. Не увидел, где бы объяснялось как он собирается отделить отрисовку от логики в старых компонентах, чтобы адаптировать для FMX. На вебинарах по FMX Крюков прямо говорил, что некоторые компоненты из VCL они не перенесли в FMX, потому что исходный код заточен под Windows.

Сама по себе идея имеет место быть, но я думаю, что это всего лишь следствие текущего состояния FMX. Со временем, если платформа «состоится», будут созданы нативные компоненты и «мосты» потеряют свою актуальность.

На мой взгляд основная проблема FMX на данный момент заключается в том, что предлагается разобраться в ней самостоятельно, а не отсутствие каких-то компонент.

ps: На вебинарах говорилось, что уже есть порт TWebBrowser

2. Алексей

30 Июл 2012 11:43 дп

Ух ты! Так оказывается FireMonkey ещё не использует нативные контролы(хотя, можно было догадаться..)! Я удивляюсь тому, что обезьянка ещё жива. А ещё удивлялся почему он так систему страшно грузит.. Помнится, неуважением к нативным контролам увлекался ещё Qt ранних версий, но сейчас, кажется, они идут на попятную и хотят использовать нативные контролы по максимуму(правда, не знаю, что там у них с пятой версией).

Embarcadero надо исправляться и в XE3 выпустить максимально нативную, полностью переработанную обезьяну, или, ИМХО, обезьянка сгорит.

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

3. Алексей

30 Июл 2012 11:47 дп

Прочитал комментарий выше, хотя я на вебинарах не был(у меня нет XE2), порт TWebBrowser — это хорошо, но маловато…

А по поводу «предлагается разобраться в ней самостоятельно» — сейчас много статей, причем авторских, + куча Help Update’ов. И, я думаю, сейчас разобраться уже не проблема(ну, в крайнем случае, всегда можно исходники посмотреть).

4. Роман Янковский

30 Июл 2012 12:00 пп

Слова о порте TWebBrowser меня пугают :)

Это будет обертка над IE или WebKit’ом или все же в духе FireMonkey все будет с делано с нуля? Если второе, то ой, если первое, то как раз этот подход предлагается в NakeyMonkey и непонятно как это впишется во всю файрманковскую идею со стилями.

5. Kazantsev Alexey

30 Июл 2012 12:35 пп

Использование нативных контролов платформы неизбежно вступит в конфликт с идеей стилизации по причине того, что отрисовываемые в битмап нативные контролы ни о какой стилизации не знают. И возможности их кастомизации, если таковые и будут предусмотрены, будут сильно ограничены. Это не страшно, если вы хотите сделать нативно выглядящее приложение. Но в таком случае логичнее выглядит идея создания библиотеки нативных контролов не основанной на FMX. Впрочем, ни один из вариантов мне не кажется достаточно хорошим т.к. в первом случае у нас будут проблемы со стилями, а во втором проблема с покрытием поддерживаемых платформ и отказ от «прелестей» FMX. Единственным верным решением будет третий вариант — самостоятельная реализация всех контролов в рамках FMX силами Embarcadero либо сторонних разработчиков. Однако, тут понятно и желании компании переложить часть работы на сообщество. Правда, для этого сторонные разработчики должны увидеть в FMX надежную, качественную основу, а с этим, пока (?), беда. FMX’овым стилям явно не хватает выразительности, а стилям предлагаемым «из коробки» проработанности.

@Андрей:
Крюков упоминал, скорее всего, вот об этом: https://code.google.com/p/delphichromiumembedded/ Когдя я его смотрел, с отрисовкой скроллбаров там какая-то беда была, и, разумеется, ни какой стилизации. Да и перспектива таскать за собою 36MB бинарников хромиума не всем нравится.

6. deksden

30 Июл 2012 5:22 пп

FMX в существующем виде жизнеспособен на Win/OSX — за счет огромной мощности современных настольных процессоров, которые позволяют с должной скоростью отрисовывать эмуляцию нативных контролов.

На мобильных же платформах, типа iOS и Win8, а также Android, скорости процессора и приложения в «ользовательском» приоритете не хватает на нормальную эмуляцию. Вы посмотрите — сколько только загружается по времени приложение «часы» на iphone — около 10 секунд! И это на 4S!

Думаю, только нативный UI жизнеспособен. Кросс-платформенным должен быть backend приложения, слой доступа к данным, worker объекты и тп. UI же должен быть нативным, чтобы следовать гайдлайнам платформы и быть привычным для пользователя RemObjects в своем блоге писали на эту тему про platform-native разработку. Согласен с этим — код должен быть native не для CPU, а для платформы!

7. Kazantsev Alexey

30 Июл 2012 6:00 пп

@deksden: Для отрисовки контролов никакая огромная мощность не нужна. Нужна качественная реализация, только и всего. С качеством у FMX беда, это да. Но это не означает, что в перспективе все плохо.

8. deksden

31 Июл 2012 7:03 пп

@Kazantsev Alexey: вы не мерили разницу в реальной производительности ПРОЦЕССОРА на ARM по сравнению с i5/i7? вы удивитесь — какая она серьезная))

Ну и мощность для отрисовки не нужна, но для анимации (которая является важной частью интерфейса iOS) — очень не помешает. Можность позволяет компенсировать работу UI слоя в пользовательском процессе вместо системного. Дело даже не в можности, а в том, с каким приоритетом выполняется процесс отрисовки. В iOS весть код, отвечающий за UI и Touch события выполняется с приоритетом ядра, самым высшим. Поэтому устройство остается отзывчивым всегда. А пользовательский код выполняется тогда, когда это можно. Поэтому никогда эмуляция интерфейса не будет такой же плавной и качественной, как нативные контролья на iOS.

Подобная проблема была в ранних версиях Андроида (до версий 4 или 4.1) — по сообщениям, с ней борются, но не очень успешно, так как мешают ранее принятые архитектурные решения

9. Kazantsev Alexey

31 Июл 2012 7:39 пп

@deksden: Зачем мне мерять разницу между ARM и x86? И так ясно, что производительность ARM’ов существенно ниже. Только о чем это говорит? Да ни о чем, кроме того, что код должен быть вылизан. А кто с этим спорит?

На счет iOS у меня есть большие сомнения, что, например, браузеры там отрисовывают контент с каким-то особым приоритетом. А в чем отличие отрисовки веб-страницы от отрисовки гуя? Да ни в чем, кроме, разве-что, более сложной отрисовки требующейся для веб-страничек. Графическая подсистема там определенно использует акселерацию OpenGL ES, ну так это доступно всем приложениям. Беда FMX в жутко кривом, неоптимизированном коде. Ну о чем можно говорить, когда банальное применение стиля длится несколько секунд, а простейшая анимация выполняется рывками на мощном десктопе. Но это не проблема самостоятельной отрисовки гуя, это проблема реализации FMX.

10. Alex

1 Авг 2012 2:15 дп

Путь Саусвелл постарается, сделает ОПТИМАЛЬНО эти контролы. А потом Эмбарко купит этого Саусвелла, или его контролы. И всем будет хорошо. Или сделает аналогично, неважно

11. Kazantsev Alexey

1 Авг 2012 2:40 дп

Появился довольно интересный комментарий, относительно нативных контролов, от Дэвида Ай: http://www.deltics.co.nz/blog/?p=936&cpage=1#comment-11408

12. Андрей

1 Авг 2012 9:50 дп

2Alex:
Почему бы Эмбарке уже сейчас не купить фастрепорт, фибплюс и девэкспресс (ну или хотя бы эхлиб), чтобы уже сейчас всем стало хорошо?
Аналогичные они делать не собираются.

13. Роман Янковский

1 Авг 2012 2:42 пп

@Kazantsev Alexey, спасибо, действительно очень интересно. Добавил в пост.

@Андрей, даже MS не покупает DevExpress. Да и зачем им это?

14. Alex

1 Авг 2012 4:25 пп

2Андрей
Думаю потому что не окупится для Эмбарки это. (ну и тут то же может статься)

15. Alex W. Lulin

7 Апр 2013 8:34 пп

У меня есть немного другие соображения про FM. Связанные скорее со скоростью. Но это надо пока конкретно замерять.

16. Alex W. Lulin

7 Апр 2013 8:43 пп

http://18delphi.blogspot.com/2013/04/blog-post_7.html

17. Alex W. Lulin

8 Апр 2013 5:21 пп

А вы кстати в курсе, что компоненты VGScene можно было запросто смешивать с VCL? И в таком разрезе — может быть проблема — не в технической плоскости лежит.

18. Роман Янковский

8 Апр 2013 5:24 пп

Нет, я с VGScene никогда не работал. По сети бродит вот такое видео: This video demonstrates how to mix FireMonkey forms into VCL Projects, without the use of DLLs or BPLs. http://www.youtube.com/watch?v=TbCLU6vWjeQ

Это не из той же оперы?