» Вопросы по Embarcadero RAD Studio XE2 (Pulsar)

Arioch1

Цитата:

(это какой год? 94й ? 95й ?)

Лучше сразу считать, что это до 95.


Цитата:

Object Inspector сразу перестали работать, как будто их и не было.

В ремот-юниксе запрещены интерфейсы, или запрещён дезигн-дебаг тайм? Если нет, то это решает отдельное IDE среды.

Arioch1

Реализация IDE form Design может быть такая - взаимодействие студии с кастомным сервером на маке. Сейчас, кстати, именно так и работает деплой и отладка на маке.

Допустим, мы хотим разработать форму для Mac OS X приложение. Сама студия работает под виндой. На маке должно быть хост-приложение - сейчас оно называется PAServer, которое будет "рисовать" форму для дизайна. Для этого мы даем ему команды "отрисовать" нужную форму, объясняем какие там есть контролы - ну или тупо подсовываем dfm. По имеющемуся dfm мы внутри этого серверного приложения рисуем форму (нам нужны только инициализированные контролы, без обработчиков ошибок и без поведения) и передаем эту форму как картинку (bitmap) для студии под виндой. Студия уже рисует полученную картинку в дизайнере.

Так как мы знаем чего и как на форме, то студия сама накладывает "выделение" контролов,. Перемещение отрабатывается понятным способом - посылкой соответствующей команды серверу и он передвинет контрол и пошлет форму обратно.

Создание iOS виджетов может быть аналогично, только с использованием iOS приложения под эмулятором.

upd:

По поводу редактора ресурсов. Под OSX/iOS в XCode сейчас все действительно так, ресурсы там nib называются и делаются в XCode в Interface Builder. Причем, если у тебя в приложении кастомный класс, то Interface Builder его "квадратиком" отобразит. Однако такой подход дает возможность быть "своим" на платформе - расширять имеющиеся классы, кастомизировать их, сразу же внедрять новинки и тп. Хочу отметить, что по этому поводу никто особо не страдает в XCode. Более того, излишняя визуальная "свобода" в Delphi приводит к перемешиванию слоев в приложении и слабой возможности следовать MVC/MVP шаблонам. Так что может и неплохо!

Зачем изобретать велосипед? Все кроссплатформенные IDE давно уже на java. Eclipse с кучей IDE на его основе, IDE от jetbrains, netbeans. У них самих был jbuilder. LLVM бы еще прикрутили.

Цитата:

ресурсы там nib называются

Исходный код - xib; nib в скомпилированном виде.

Цитата:

LLVM бы еще прикрутили.

LLVM они как раз для новых компиляторов и прикручивают.

Цитата:

взаимодействие студии с кастомным сервером на маке.

Да это понятно. Вот только это не так просто, даже если вместо роджных компонентов использовать X Server. А с родными, где отрисовка по сети не предусмотрена вообще, и того сложнее.
Этак уже лучше всю среду делать нативной.

Тут отладку и компиляцию до конца не доделали, а ты хочшеь ещё один немаленький проект им добавить.
Причём проект, который надо будет обновлять при выходе свежих XSDK.


Цитата:

Eclipse. Но это у них еще года на 3 затянется.

Ну в принципе опыт у них есть, JBuilder же выпускали.
Паскаль-плагин тоже кто-то для Эклипса делал, только он заточен наверное на FPC или м.б. на GCC, а не на Эмбу


Цитата:

Interface Builder его "квадратиком" отобразит. Однако такой подход дает возможность быть "своим" - ... сразу же внедрять новинки и тп.

Угу, квадратиками. На Эппле, зацикленном на карсивом гламурном дизайне свою программу "квадратиками" дизайнить.


Цитата:

OLE custom controls were introduced in 1994

и обходились без квадратиков...

Arioch1


Цитата:

Вот только это не так просто

Никто не говорил, что просто. Но это не так сложно. На маке вообще AirPlay работает - они целиком экран компа стримят как видеопоток! Не вижу сложностей отрисовать форму в bitmap.

а насчет новых версий SDK - куда ж без обновлений! Если возможности добавляются, так не грех и обновиться! Благо, цикл обновлений всегда предсказуем (раз в год обновление OS), примерно раз в два года - мажорные изменения в OS.

Я как раз верю, что это сделать проще, чем переписать среду под Eclipse. К тому же Eclipse реально более тормозная штука, чем RAD Studio.


Цитата:

На Эппле, зацикленном на карсивом гламурном дизайне свою программу "квадратиками" дизайнить.

Ну - на XCode ж так дизайнят, и ничего, получается красиво и гламурно!) Визуальный редактор форм =/= красиво и гламурно.

p.s. Я вообще больше верю, что такую штуку как iOS/OS X native pascal выпустит RemObjects, со своим Oxygene. Они могут просто сделать Oxygene for OS X/iOS.

Цитата:

выпустит RemObjects, со своим Oxygene

А что, они разве делают нативные компиляторы ? уж скорее Эмбы LLVM допилят

Добавлено:

Цитата:

iOS/OS X native pascal выпустит RemObjects

Т.е. переименуют FPC ?

Arioch1

А что, Oxygene for Java не компилирует паскаль в Dalvik/JVM? Или Oxygene for .NET не компилирует в IL?


Цитата:

переименуют FPC

Мне от RO нужна нормальная интеграция с приличной средой (в данном случае VS), чтобы было приятно разрабатывать, рефакторинги и прочие современные плюшки. Lazarus назвать удобной и современной средой не получается.

Ну а так - подход FPC в интеграции с OSX мне представляется верным: делаем легкие изменения языка для более тесной интеграции с платформой.

upd: В блоге _http://www.deltics.co.nz/blog/?p=936 появилась новая информация про XE3. Во-первых, пост, который я перевел в варезнике (зря, кстати - нужно было сразу тут), переведенный мною коммент удалили - за нарушение NDA. Зато появились комменты DavidI, в одном из которых он говорит, что они работают над предоставлением альтернативы - нативных биндингов контрольев под каждой платформой. Очень рад))

Цитата:

Oxygene for Java не компилирует паскаль в Dalvik/JVM? Или Oxygene for .NET

вы кажется про нативные компиляторы говорили, а не про JVM и ее майкрософтовское развитие

Arioch1

Смотря как считать нативное. Я более склоняюсь к определению нативного относительно платформы. Для Android нативным тогда будет Dalvik, для WP7 - Silverlight, для ios - xcode/objc.

А как именно код превращается в нативные инструкции для CPU - уже не так важно. Программу то пишешь не для CPU, а для платформы (скорее даже для RTL платформы).

objc не интерпретатор, так что с Dalvik или JVM его рaвнять не стоит.

Думается, что у виртуальных машин типа JVM есть сильные отличия от кремниевых процессоров, и опыт в кодогенераторе для виртуалки и ее библиотек вовсе не гарантирует хороший компилятор для кремния и non-managed библиотек.

Как именно - тоже важно. В том же Delphi глюки компилятора - не редкость.
Я уж не говорю про учебники, в которых рекомендуют
var v: word;
if IntToHex(v, 2) = '$FF' then ...

Arioch1

ObjC - язык динамический, поэтому отличия от лукавого!

Про кремниевые процессоры тоже все не так однозначно. Например, для next-gen compiler for C++ предполагается заюзать clang, который все ж делает код для абстрактной виртуальной машины (IL) и скармливает его LLVM.

Я про то, что есть технологии, которые обеспечивают лучший результат для определенных целевых платформ. Сейчас есть потребность делать приложения для PC (Win/Mac), которые взаимодействуют с мобильными дивайсами типа планшетов/смартфонов (Android/iOs/WP), а еще и сервера для этих приложений (тут уже очень широкий перечень технологий - от EC2 до Parse) - которые связывают единым сервисом всех клиентов под любые платформы. Не забываем что есть еще и web-клиенты))

И у ЭМРО есть уникальная возможность предложить средства cross-platform разработки, так как сейчас большие вендоры предлагают средства только для своей платформы: Apple для OSX/iOS, Google - для Andriod, MS - для Win/WP, а для Linus серверов никто ничего особо не предлагает))

Но, имхо, в ЭМРО пошли не совсем верным путем - они пытаются сделать универсальное средство разработки! А это хреновая тема из-за lowest common denominator. К тому же FMX работает как эмуляция GUI.. Хреново, в общем. поэтому конкурировать с любым вендором платформы ЭМРО тяжело.

>> Beta test for XE3 is going on now. They are looking for leaked serials. (:

_http://delphihaters.blogspot.com/2012/08/delphi-xe3-coming-soon.html

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

Пока LLVM не собирает байткод JVM/MSIL и это наверное не просто так.
http://llvm.org/docs/GettingStarted.html#hardware


Для линукс-серверов - Ява и производные.

Заметил один не очень приятный момент. Если производить поиск во всех модулях (Ctrl+Shift+F) по русским словам, то поиск происходит только в открытых на момент поиска модулях. Если искать английские слова, то все нормально, ищет во всех модулях.
Есть ли выход из этой ситуации? Или каждый раз нужно открывать все модули и потом делать поиск?

Цитата:

а для Linus серверов никто ничего особо не предлагает

Да, ладно. Если брать именно кроссплатформенные приложения, то это весь java world. А также скриптовые языки php/python/ruby и прочие. Ну и с/с++, классика жанра. Есть относительно кроссплатформенные решения вроде qt.


Добавлено:

Цитата:

iOS/OS X native pascal выпустит RemObjects

А зачем там паскаль?

можно глянуть на некоторые фичи xe3:
http://radstudiodemos.svn.sourceforge.net/viewvc/radstudiodemos/branches/RadStudio_XE3/
если это самые козырные "вкусности", то я катастрофически разочарован, т.к. они не только обломили в xe3 с андроидом и метро, с безкостыльной ios, но и саму обезьяну до уровня не довели.........
получается, что "подчищенный" с форумов инсайдер был прав.........

AlxMonster


Цитата:

А зачем там паскаль?

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

Цитата:

т.к. они не только обломили в xe3 с андроидом и метро

Судя по этой ссылке _http://www.embarcadero.com/landing-pages/2012-rad-studio-xe3-tour Метро там как раз будет и для VCL и для FM, а интерфейс пользователя будет на html 5.

HeMet
также красноречиво и непонятно год назад они писали и пишут сейчас про разработку под os x и ios в xe2, а на деле вышли одни костыли.......
хотя надежда как всегда умирает последней............


Добавлено:

Цитата:

интерфейс пользователя будет на html 5.

я так понял, что будет отдельный HTML5 Builder что-то на подобии http://smartmobilestudio.com/..........
у кого какие мысли?

Вопросы по Embarcadero RAD Studio XE3, будьте любезны пройти.

Цитата:

пишут сейчас про разработку под os x и ios в xe2

Ну поддержка os x хоты бы менее костыльная, хотя тоже не фонтан. По мне так они слишком спешат. Лучше бы делали по одной крупной фиче на релиз.

Цитата:

у кого какие мысли?

Если они хотят по-родному подключиться к Метро, то в плане интерфейса у них выбор XAML или HTML5. Видимо, выбрали последнее, тем более, что его в перспективе можно использовать для вэба.

Хорошая вещь, только тут в шапку тоже добавь Plz
а то на следующей странице опять начнут здесь обсуждать

Добавлено:

Цитата:

Вопросы по Embarcadero RAD Studio XE2

Во-первых, XE3 Я тоже описался сначала. Привычка.

Во вторых я бы все-таки вынес для начала в начало шапки, потому что по привчке будут писать здесь, никто длинные списки перечитывать не будет. Где0нибудь в октябре можно будет и в серый унылыый список.

А пока - лучше чтоыб в глаза бросалось: достаточно большими буквами ( я size=2 делал), в начале и отдельным абзацем

Цитата:

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

Смысла в этом вообще нет. Предпочтения в языке у меня были только первые 2-3 года обучения. Потом смотришь уже не столько на язык, сколько на библиотеку стандартных классов этого языка и сторонние библиотеки (их количество, качество, стоимость). И модель управления памятью. Да, по началу pascal будет знакомый. Но все примеры для ios/mac идут на objective c. Objective с понимать все равно придется, так что лучше его изучить сразу. Да, на первый раз от его синтаксиса глаза выпадают, но через неделю привыкаешь. Библиотека базовых классов все равно cocoa/cocoa touch. На паскале - перевод сишних заголовков. И делается он не очень оперативно. Кроме того на паскале все эти обращения выглядят странно.

AlxMonster

То то и оно, что сторонние библиотеки хотелось иметь знакомые по архитектуре! А пока только RemObject делают SDK и DataAbstract на разных платформах. Других решений между платформами особо не наблюдаю.. А хотелось бы иметь - типа стеммеров, простых алгоритмов (CRC/ MD5, SHA1...) и тп.

Если бы дельфи компилировались на несколько платформ - возникли бы предпосылки для создания таких библиотек. Например, были бы JCL кросс-платформенные, OTL... может, кто б наваял BT-клиент! Да, FPC уже давно кросс-платформенный. но он не так распространен, как дельфи!

А сейчас - при переходе на новую платформу ты остаешься "голый" - приходится искать аналоги, и тп.. Я не говорю, что это невозможно, но добавляет НЕНУЖНЫЕ сложности.

Используйте java. Платформа вас вообще никак волновать не будет.

Хммм... типа для любой платформы есть одинаковые быстрые нативные библиотеки ?

Вот когда JDownloader будет запускаться так же быстро, как ReGetDx Personal или FreeDownloadManager - тогда м.б. и поверю

AlxMonster

Я ж не говорю, что многоплатформенных языков нет! Я сожалею о том, что Паскаль мог бы присоединиться к ним на нормальных условиях, и даже в чем-то стать лучше! А так - да, есть Ява, C#/Mono, C/C++/Qt.

Добавлено:
Arioch1

Вы про RemObjects? Да, у них есть wire-compatible библиотеки на скольких платформах. Вполне себе быстрые.

Поставил delphicbuilder_xe2_4429_win_dl.iso.
С делфи все нормально.
В Си при создании нового проекта и компиляции его требовало либки.
Указал пути к ним.
Теперь куча ошибок, типо:
[more]
[BCC32 Error] sysmac.h(64): E2209 Unable to open include file 'stdint.h'
Full parser context
Project2.cpp(3): #include c:\program files\embarcadero\9.0\include\windows\vcl\vcl.h
vcl.h(10): #include c:\program files\embarcadero\9.0\include\windows\vcl\basepch0.h
basepch0.h(62): #include c:\Program Files\Embarcadero\9.0\include\windows\rtl\System.hpp
System.hpp(18): #include c:\Program Files\Embarcadero\9.0\include\windows\rtl\sysmac.h

[BCC32 Error] sysmac.h(103): E2209 Unable to open include file 'windows.h'
Full parser context
Project2.cpp(3): #include c:\program files\embarcadero\9.0\include\windows\vcl\vcl.h
vcl.h(10): #include c:\program files\embarcadero\9.0\include\windows\vcl\basepch0.h
basepch0.h(62): #include c:\Program Files\Embarcadero\9.0\include\windows\rtl\System.hpp
System.hpp(18): #include c:\Program Files\Embarcadero\9.0\include\windows\rtl\sysmac.h

[BCC32 Error] sysmac.h(104): E2209 Unable to open include file 'delayimp.h'
Full parser context
Project2.cpp(3): #include c:\program files\embarcadero\9.0\include\windows\vcl\vcl.h
vcl.h(10): #include c:\program files\embarcadero\9.0\include\windows\vcl\basepch0.h
basepch0.h(62): #include c:\Program Files\Embarcadero\9.0\include\windows\rtl\System.hpp
System.hpp(18): #include c:\Program Files\Embarcadero\9.0\include\windows\rtl\sysmac.h

и др.
[/more]
Что не так? Переустанавливал и репеир делал, не помогло.
В Tools - Options все пути прописаны.

Man_Without_Face

Стройку нынче не пользую, но раньше за ней были замечены нетерпимости к пробелам и кириллическим (не ansi на самом деле) символам в путях.

С тех самых времен у меня привычка ставить все версии студии в C:\Dev, а не C:\Program Files!))

Попробуйте переставить в путь "без пробелов".

Еще вариант: добавить в PATH пути (переменная окружения).