» Вопросы по Embarcadero RAD Studio XE3

Тут с шапкой непорядок - не отображается на каждой странице! Поправил бы кто нидь, кто знает как)

sergionn

SmartMobileStudio делали не RemObjects, от RO - Oxygene for .NET и for Java. Так что паскаль для Андроида есть)) Это плюс! Но из-за малой популярности еще нет кросс-платформенных библиотек, чтобы работало и на Delphi и на Oxygene

Цитата:

SmartMobileStudio делали не RemObjects

я этого не писал

Дженерики в xe2 пользую, до перевода проекта с лазаря на xe2, пользовал их и там, все работало без особых проблем......

Добавлено:

Цитата:

Если нечего скрывать - притворись, что скрываешь ого-го что!

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

пока используешь встроенные колекции - тьфы-тьфу-тьфу.

но стоит копнуть spring4D и в их oberloade ForEach добавить свой overloaded Process от generic-класса...

В общем, в пределах своеё библиотеки они отладили, но чут ьглубже и начинается счастье.

у чехов дали ссыль на доки из x3 что нового:
_http://rghost.ru/39635456

sergionn

Действительно, в whats new умилили строки "Готовимся к поддержке Win8": а как ты к ней подготовишьсяЮ, если на WinRT не пустят Desktop приложения? Придется таки отказаться от FMX! В целом, я бы на месте ЭМРО делал бы 2 вещи:

1) компилятор на базе LLVM с фронтэндом Pascal + CLang (для стройки) и все под Win32/64, OSX, iOS, и с прицелом на Android/Linux; также язык должен допускать прозрачное расширение классов ObjC и Java (для Андроида) и интероперабилити (делегаты - блоки и тп);

2) на базе FMX сделал бы отдельно кросс-платформенную RTL (практически, что-то уже есть); кросс-платформенным должен быть слой всяких системных классов (коллекции, потоки - с специфическими платформенными расширениями), слой доступа к данным, сетевые библиотеки, - почти все невизуальное! Ну и рефакторнул бы слой GUI: должен быть выбор для GUI между FMX и нативными для платформы контрольями. FMX хорош для быстрого портирования интерфейса между платформами, но для требовательных приложений (или ограниченных по ресурсам платформ) нужны биндинги к нативным контрольям. ИМхО, нативные контролья очень нужны для iOS, и не могу ничего особо сказать про Android.. А для Win8 особого выбора то и нет - или XAML, или HTML/JS, но никак не FMX. Так что native GUI - наше ВСЕ))

если такой компилятор пилить, то можно наверное сразу поддержку QT пытаться в язык вставить

И FMX будет не нужна

Цитата:

Придется таки отказаться от FMX!

Так ведь WinRT же не отвергает существование DirectX приложений (игр, на пример). FireMonkey вполне может подойти под эту категорию.

Цитата:

если такой компилятор пилить, то можно наверное сразу поддержку QT пытаться в язык вставить

Они с CLX так сделали: не срослось. И когда думали над FMX тоже рассматривали Qt и снова им что-то не понравилось.

Arioch1
HeMet

Поддержка QT не нужна - фактически, для GUI можно сравнить QT с FMX, правда в QT было много всего и для RTL. И FMX, и QT - это эмуляция нативных контрольев на каждой платформе, при этом QT более зрелая эмуляция. QT лучше "мимикрирует" под платформу, правильно запрашивает метрики и шрифты, в отличие от FMX. В любом случае, оба фреймвока рисуют контролья на каждой платформе самостоятельно.

От QT отказались имеено по причине того, что это в любом случае "внешний" фреймвок - и C++, и развивается другой командой, а FMX же свой и весь на паскале!

Проблема в другом - да, на WinRT можно нарисовать фейс через DirectX, и так и собираются делать (см _http://www.thomgerdes.com/2011/12/directx-applications-in-winrt.html ).

Но вот уже при эмулированном UI не получиться развиваться со скоростью платформы. Будут проблемы, как в случае iOS - когда на iphone появился Retina-экран: все приложения на нативных контрольях "автоматически" получили поддержку рендеринга на retina экранах.

Я бы ОЧЕНЬ СРОЧНО добавлял бы к FMX возможность работать с нативными платформами напрямую - использовать контролья, расширять системные классы, передавать делегатов и тп. Нужно ДРУЖИТЬ с платформой.

К сожалению, ЭМРО не смогло сформировать community что.бы обсуждать направления развития продуктов и эта фишка только упоминалась DavidI

Цитата:

Они с CLX так сделали

Нет. Они не сделали поддержку QT в языке, а сделали набор классов-переходинков.
Те же events остались по одному обработчику на каждое, вместо 1 publisher - many subscribers

Впрочем, вроде бы QT даже в C++ не влезает, пришлось пре-процессор делать.

Также и с ObjC вроде бы. FPC язык дорабатывает дял прямого использования, а EMB делает классы-обёртки.


Цитата:

а FMX же свой и весь на паскале!

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


Цитата:

правда в QT было много всего и для RTL

Именно. Кроссплатформные библиотеки нужны не только GUI

Arioch1

Что мешает доработать язык Delphi? Мне очень нравятся директивы FPC по поводу диалектов языка - выглядит вполне логично платформенно-зависимый код писать на платформенном диалекте языка!


Цитата:

если новый делать

Боюсь новый компилятор делать будут, стараясь обеспечить полную совместимость с текущим языком. Разумным подходом был бы подход, аналогичный Apple: оставить в среде неколько компиляторов. Например, текущий компилятор будет компилировать все legacy приложения VCL для Win32/64. А для FMX сделать LLVM компилятор с языковыми расширениями для платформ (iOS, Android, OSX, Linux).


Цитата:

Кроссплатформные библиотеки нужны не только GUI

У меня более категоричный взгляд - кроссплатформенные GUI-библиотеки ПОЧТИ НЕ НУЖНЫ, а нужны только non-visual библиотеки (потоки, БД, обработка данных XML/JSON/..., сетевые протоколы, object persistence ...).

Цитата:

Боюсь новый компилятор делать будут, стараясь обеспечить полную совместимость с текущим языком.

ну как там будет - кто его знает.
но на форукме увязывали переработку языка и переработку компилятора.

язык надо перерабатывать, если не одновременно вс новым поколением компиляторов - то когда ?

Но в переработанный язык QT может лечь как родной, а ограниченный старым языком FMX/VCL оказаться устаревшими

Цитата:

но на форукме

any links?


Цитата:

QT может лечь как родной

Не понимаю, чем вам так мил QT? FMX по архитектуре особо не хуже, а по поддержке GPU - так даже вполне передовой) Да, QT чуть более "вылизан", но FMX сейчас вылизывают! На мой взгляд - шило на мыло))

deks


Цитата:

QT лучше "мимикрирует" под платформу, правильно запрашивает метрики и шрифты, в отличие от FMX. В любом случае, оба фреймвока рисуют контролья на каждой платформе самостоятельно.

В принципе, ничего не мешает и в FMX получать метрики. Другое дело, что существующие стили этого не учитывают.


Цитата:

Но вот уже при эмулированном UI не получиться развиваться со скоростью платформы. Будут проблемы, как в случае iOS - когда на iphone появился Retina-экран: все приложения на нативных контрольях "автоматически" получили поддержку рендеринга на retina экранах.

В FMX с этим все просто. Контейнеру гуя, лайауту например, устанавливается скейлинг в соответствии с пропорциями экрана устройства и всё будет отмасштабировано. Кстати, если видели демки XE3 и заглядывали в .fmx файлы, то могли обнаружить у форм свойство FormFactor со свойством AspectRatio. Подозреваю, что, как раз, для вышеозначенных целей.

Цитата:

any links?

обсуждали же уже.

нет, не будет. Потому что с тех пор форум грохнулся. Кто захочет/Сможет - найдет так же как искал бы я.

кроме того, рахзговоры-разговорами, а маркетологи могут взят и перерешить. Вот мне на QC обещали обновление к XE2, еще одно. Кто-нибудь в это верит ?


Цитата:

FMX по архитектуре особо не хуже

там есть signal/slot ? HTML ? поддержка Linux'a ? OpenGL ?

QT - не только GUI
и разработччиков у него больше, чем у FMX

Цитата:

войство FormFactor со свойством AspectRatio.

ага, интересно как это нам можно будет использовать:

FormFactor.Width = 1920
FormFactor.Height = 1200
FormFactor.Devices = [dkDesktop, dkIPhone, dkIPad]
FormFactor.Aspect = 0.625000000000000000

FormFactor.Width = 2020
FormFactor.Height = 1272
FormFactor.Devices = [dkDesktop, dkIPhone, dkIPad]
FormFactor.Aspect = 0.629702985286712700

Добавлено:

Цитата:

там есть signal/slot ? HTML ? поддержка Linux'a ? OpenGL ?

да в обезьяне есть поддержка opengl для osx и opengl es для ios
а для винды directx, именно из-за отсутствия в qt поддержки directx там есть проблема с быстрой поддержкой winrt.........
поэтому и печально что имея такое преимущество в виде директх в обезьяне нет до сих пор winrt слоя........
поэтому портирование на линукс обезяны тоже не вызывает особых проблем,
но видимо евгений пишет один свой фреймворк, ну оооочень медленно..........

Arioch1


Цитата:

там есть signal/slot ? HTML ? поддержка Linux'a ? OpenGL ?

TThread есть, как синхронизация сделана - не в курсе, но как то сделана!
HTML нет, но есть DataSnap, где есть генерация HTML и он на FMX работает.
OpenGL конечно есть! Scene3D может юзать OpenGL, да и в 2D тоже можно OpenGL задействовать - это было еще в KSDev.
Linux поддерживался еще в KSDev - через FPC.

Так что не надо особо ругать FMX - вполне себе перспективный фреймвок, но с подходом к GUI, который мне кажется неперспективным. Идеально все ж таки иметь нативные контролья, и при необходимости вставлять сцену от FMX куда нужно.


Цитата:

разработччиков у него больше, чем у FMX

Это пока Nokia не обанкротилась - к тому же именно QT инженеров они нынче сокращают. Муртазин часто про это пишет))

Кстати, я что-то не припомню ни одного успешного и хорошего кросс-платформенного GUI... У всех какие-то сложности!)

Цитата:

Кстати, я что-то не припомню ни одного успешного и хорошего кросс-платформенного GUI... У всех какие-то сложности!)

а я не увидел много успешных коммерческих приложений на qt...........
_http://habrahabr.ru/post/143391/
_http://habrahabr.ru/post/46293/


Цитата:

Так что не надо особо ругать FMX - вполне себе перспективный фреймвок, но с подходом к GUI, который мне кажется неперспективным. Идеально все ж таки иметь нативные контролья, и при необходимости вставлять сцену от FMX куда нужно.

Я вообще не вижу никаких преимуществ в нативных контролах ,какая разница кто их рисует - сам кросплатформенный фреймворк или слой системы, все работают через одни и те же api, в обоих случаях есть свои проблемы и преимущества, которые в итоге нивелируют друг друга. НО КРОСПЛАТФОРМЕННОСТЬ это наше ВСЕ! т.к больше времени уделяется непосредственно логике своей программы.
И вообще достаточно просто задекларировать все нативные контролы в обезьяне, а мы сами будет решать использовать или нет........

Цитата:

TThread есть

а при чем он тут ? я про множественные events говорил.
http://habrahabr.ru/post/50812/

Цитата:

а я не увидел много успешных коммерческих приложений на qt

Вот именно) QT как пример очередного кросс-платформенного UI, который нахрен никому не уперся!)


Цитата:

какая разница кто их рисует

На iOS у слоя системы приоритет выполнения выше, чем у пользовательского кода. В результате, анимации, transiotions и в целом GUI нативных приложений очень даже отзывчив. А вот FMX приложение с часиками только запускается секунд по 10-15, и это на iphone 4S!


Цитата:

все работают через одни и те же api

В FMX-приложении все живет внутри собственной песочницы, со своей RTL, которая не особо построена и может взаимодействовать с платформой. Вы попробуйте сделать на FMX элемент для системных настроек на OS X (это аналог .cpl для win) - а для OSX разработанная RTL вполне даже ничего! На iOS взаимодействие с платформой делается вообще порой через жуткие хаки!


Цитата:

НО КРОСПЛАТФОРМЕННОСТЬ это наше ВСЕ!

Не путаем КРОССПЛАТФОРМЕННОСТЬ с кроссплатформенным UI.

Успешные многоплатформенные программы (такие как Sparrow, Evernote, etc) всегда делали отдельную версию со своим UI для каждой платформы. Иначе пользовательский опыт будет ужасным: например, если hints для Win это ок и даже хорошо, то как вы представляете их на iPad - там же мыши НЕТУ!

В общем, если для OSX еще можно как-то перенести софт с Win (пусть и выглядеть он будет убого и чужеродно), то на мобильных дивайсах desktop-приложениям вообще делать нечего. Я молчу, что продать софт в Mac AppStore, который выглядит "сомнительно" - это сложно, значит ниша для FMX - это портирование enterprise приложений..

Ну и я целиком за кроссплатформенный back-end: все что связано с невизуальными объектами, доступом к данным, сетью, контейнерам/коллекциям, и тп! Но это - 40-60% от объема программы) А остальное - UI, и его нужно под каждую платформу переписывать! А FMX не дает особых возможностей сделать нативные UI


Добавлено:
Arioch1


Цитата:

множественные events

В Delphi их нет, факт) В принципе, несложно сделать самому: например тут сделано: _http://www.deltics.co.nz/blog/?tag=multicast-events

Я бы добавил в язык такие штуки! Надеюсь Livebinding как-то сможет их заменить..

Цитата:

На iOS у слоя системы приоритет выполнения выше, чем у пользовательского кода. В результате, анимации, transiotions и в целом GUI нативных приложений очень даже отзывчив. А вот FMX приложение с часиками только запускается секунд по 10-15, и это на iphone 4S!

обезьяна и на винде то работает туго, а вот ее родитель vgscene, летает, думаю тут гдето затык случился по отрисовке компонентов сцены, посмотрим как будет в xe3........

Можно по подробней про ios, т.е. получается если я пишу игру на ios и использую opengl es, то графика будут отрисовываться заведомо медленней чем ui элементы?
Это же противоречит здравому смыслу
А как же игры там так шустро бегают на ios?



Цитата:

если hints для Win это ок и даже хорошо, то как вы представляете их на iPad - там же мыши НЕТУ!

не вижу тут проблемы - нет мыши, над контролом не проходит курсор, нет хинта, будет проходить курсор - вывалится хинт - т.е. ОДНО ДРУГОМУ НЕ МЕШАЕТ!
У меня на планшете msi winpad есть джойстик для мышки, стоит win8 - так вот я с успехом пользуюсь как пальцем, так и в некоторых случаях мышкой - все очень гармонично и удобно, а то что айпад культивировал только ввод пальцем - так это все временное.........Вот и ручка уже ОПЯТЬ появилась в samsung galaxy note........


Цитата:

В общем, если для OSX еще можно как-то перенести софт с Win (пусть и выглядеть он будет убого и чужеродно)

с чего вдруг, все смотриться ок!

Цитата:

vgscene, летает

Да не сказал бы! Меню и попапы всегда тупили не по детски, и иногда бывали жесткие глюки с перерисовкой. Например, перетаскивание элементов TreeView.


Цитата:

графика будут отрисовываться заведомо медленней

Да, это можно наблюдать, когда во время игры приходит какой-нибудь email, и вверху вылезает баннер notification. Игра жестко тупит, когда работает анимация банера (он типа "поворачивается").

FMX тупит больше игр из-за того, что мало оптимизирован: обрабатывает по всей сцене события мыши, "руками" перерисовывает контролья и тп. игры устроены проще: тупо рисуют сцену, само рисование за счет GPU довольно быстрое. Но вот ARM-процессор это слабое место: а FMX процессор сильно задействует)

Сама iOS занимается жесткой оптимизацией перерисовки GUI и перекладывает как можно больше работы на GPU: кэширование уже нарисованных пунктов ListView в Bitmap, кэширование самих объектов ListViewItem (чтобы конструктор объекта не вызывать лишний раз - делается пул объектов для ListView), отрисованная заготовка объекта кэшируется, а текст сверху этого объекта наносится как отдельный "прозрачный" bitmap, анимация очень жестко оптимизируется (рисуется контрол на bitmap, а потом уже делается анимация этого bitmap средствами OpenGL).


Цитата:

игры там так шустро бегают на ios

Вот только игры и бегают шустро! Все CPU-intensive task это не очень.. Например, перестройка CoreData-базы из-за обновления структуры данных (это SQLite Embedded+ORM) на старте приложения вполне может и крэшить app: если софт не пускается более 30 секунд, он закрывается принудительно; если главный поток более 5 секунд не отвечает, приложение закрывается.. В общем, iOS очень экономит CPU.


Цитата:

не вижу тут проблемы

А я вижу - никто ваше приложение, которое выглядит как школьная поделка, не купит. А на iOS приложения покупают!


Цитата:

все смотриться ок

Приведите хоть одно реальное приложение которое было портировано с Win на OSX и смотрелось ок без переделки фейса. Можно даже скрин)

deks
про отвратную оптимизацию в обезъяне согласен на 100%: на некоторые куски кода без слез смотреть нельзя - сижу, многое переписываю с нуля...........
поживем посмотрим, что будет в xe3.........


Цитата:

Приведите хоть одно реальное приложение которое было портировано с Win на OSX и смотрелось ок без переделки фейса. Можно даже скрин)

а что приводить - повторяют gui osx, а за содержимое самой демки мы не в ответе........

Цитата:

Надеюсь Livebinding как-то сможет их заменить..

Это который все по текстовым названиям ищет в цикле ? COM Automation, Delphi edition ?
Ни проверки при компиляции, ни скорости. Просто таки Excel VBA получился идеологически.

Такое может быстро работать на JVM/.Net, которые такой кусок теоретически могут скопилировать во время выполнеения с прямой привязкой к соотв. сеттера/геттерам. А на Delphi это...
Да и то, про ошибки компиляции можно забыть...


Цитата:

портирование enterprise приложений

...еще не написанных enterprise приложений

Кстати, для Ent. закос под платформу не так и важен, может и наоборотм.

В "офисе" мне бы было приятно, чтобы осовная программа выглядела и вела себя одинаково на любом компьютере/планшете, независимо какая там ОС будет. Впрочем, эту нишу будет постепенно занимать HTML5



Добавлено:

Цитата:

В принципе, несложно сделать самому

Да, но это не буджет использоваться другими библиотеками. Если какая-то библиотека вешается на ивенты, то она будет просто выбивать нафиг этот мультипликатор. Если две библиотеки будет использовать каждаясвой мультипликатор... И т.д.

Цитата:

К сожалению, ЭМРО не смогло сформировать community что.бы обсуждать направления развития продуктов и эта фишка только упоминалась DavidI

Мне кажется, они и не пытались особо. А обсуждением развития продуктов они не занимаются, хотя информацию могут дать под неразглашение. Вместо этого они раз в год всем делают сюрприз.

Цитата:

Что мешает доработать язык Delphi? Мне очень нравятся директивы FPC по поводу диалектов языка - выглядит вполне логично платформенно-зависимый код писать на платформенном диалекте языка!

Если уж перерабатывать язык, то, наверное, удачные решения из других можно включить в основной набор. Те же протоколы из Objective-C выглядят на первый взгляд, как расширение интерфейсов в Delphi.

Цитата:

Это который все по текстовым названиям ищет в цикле ?

Поподробнее можно? ЕМНИП, то выражение он разбирает только раз, используя IBindScope и сохраняя результат в байткод, который уже использует движок (довольно простой конечный автомат).

я не копался в реализации LiveBinding
Мне они не показались дающими что-то новое.
Если там создается и кэшируется шитый код, то это неплохо.

Хотя могли бы и JIT сделать. Бесплатный VirtualDub взял и сделал JIT с плавающей точкой.
А дорогущий дельфи для целочисленного и достаточно простого кода не может...

но в любом случае это отключает проверку при компиляции и мне это не нравится. Нравилос ьбы - писал бы на Java Script'e

HeMet

По поводу развития языка: в том же Oxygene много удачных конструкций есть! Сделали ж они тот же await.

Цитата:

Сделали ж они тот же await.

Судя по их статье о реализации await, она очень сильно завязана на возможности RTL. И если в их случае весь RTL, если я не ошибаюсь, написан МС, а с них только поумневший компилятор, то Эмб придётся делать всё самим. Но неплохо было бы заиметь такие штуки в Delphi. Интересно, насколько их реализация осложняется отсутствием сборки мусора. Вон перегрузку операторов на классах потому и не делают, что по словам Барри Келли без неё эта функция почти бесполезна.

Цитата:

перегрузку операторов на классах потому и не делают

где не делают ? в каком смысле не делают?

в конце концов default properties сделали очень давно, а это частный случай перегрузки

@GSirr

GSirr

Рекомендовал бы интеграторы блогов _DelphiFeeds.com и DelphiFeeds.ru

HeMet

Вот не далее как недели две назад Gabr (theDelphiGeek.com) писал как можно сделать что-то похожнее на await на его OTL! Да, без поддержки компилятором получается громоздко) Но вполне себе возможно!) Думаю, може препроцессор сделать на CastaliaParser (или DWS), который добавляет await на OTL?

По поводу сборки мусора - не вижу вообще никаких проблем! Делаем тред, выполняем, передаем результаты в вызвавшую процедуру, доделываем процедуру. После финиша треда и после передачи данных прибиваем тред (возвращаем в пул тредов?). После финиша "остатка" функции прибиваем объекты на ее стеке (ну и на финише функции должны быть деструкторы временных объектов). Так что при принятом в Дельфях методе управления памятью - все работает!) Гляньте пост Gabr

Добавлено:
sergionn

Посмотрел раздел про проги на QT!) Ни одной популярной и с нормальным интерфейсом уровня FlipBoard/Instagram/TweetBot/Sparrow.

VLC приводить как пример интерфейса - да там только кнопка Play нужна (перемотка и громкость) ну и окно настроек, основная мощь inside?) Opera чуть QT пользует, Skype вообще хз) Google Earth в основном землю показывает, а не свой интерфейс, так что QT тоже не разглядишь..

В общем - не знаю!

deks


Цитата:

Да, это можно наблюдать, когда во время игры приходит какой-нибудь email, и вверху вылезает баннер notification. Игра жестко тупит, когда работает анимация банера (он типа "поворачивается").

Это может указывать на то, что сервисы системы имеют больший проиритет нежели приложения, и только. И тут уже не важно, рисуешь ты или делаешь еще что-то. Есть же куча приложений русующих самостоятельно, взять хоть тот же OmniGraffle.


Цитата:

FMX тупит больше игр из-за того, что мало оптимизирован

Вот именно. То есть вопрос тормозов FMX это не вопрос кастомной отрисовки контролов.

Arioch1


Цитата:

где не делают ? в каком смысле не делают?

Delphi не поддерживает перегрузку операторов для классов, только для записей. Delphi for .NET поддерживала и для классов.


Цитата:

в конце концов default properties сделали очень давно, а это частный случай перегрузки

Это далеко не перегрузка операторов. Это синтаксический сахар над свойством с индексатором. Свойства, в свою очередь, синтасический сахар над вызовом методов.

Полноценная перегрузка операторов подразумевает возможность создания объектов (экземпляторв класса) в процессе, собственно, выполнения кода операторов. И без мусорщика такая реализация будет не полноценной, хотя и возможной.

deks

Цитата:

Посмотрел раздел про проги на QT!) Ни одной популярной и с нормальным интерфейсом уровня FlipBoard/Instagram/TweetBot/Sparrow.

VirtualBox, GoldenDict. Имеют хороший интерфейс и выглядят нативно.