Блог Александра Божко
Архивы
Рубрики
Поделись с другими!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

Оригинал.(в настоящее время ссылка не доступна)

Сейчас появилось много спекуляций по поводу того, какую библиотеку/библиотеки мы увидим в следующей версии(ях) Delphi. Мы знаем, кодовое название следующая версии Delphi с кодовым названием  Fullcrum (не нажимайте здесь и здесь - данные ссылки никак не связаны с замыслами команды разработчиков : ) будет кросс-платформенным продуктом для работы в Windows, Mac OSX и Linux:

Похоже, что это будет только 32-битная версия и поддержка Linux в ней будет в ‘превью режиме’, несмотря на то, что они постараются сделать все возможное. Скорее всего, Mac OSX будет первой целью для GUI после Windows.
Также мы знаем, что компилятор будет подвергнут “капитальному ремонту“, и разделен на back-end / front-end архитектуру, что дает возможность для поддержки большего количества генераторов кода и большего количества языков, даже если для нас, дельфинистов, наиболее выгодно развитие языка, направленное на поддержку современных методик написания кода.

Но что на счет библиотек?

Мы знаем, что VCL привязана к Win32 API, а соответственно был ряд спекуляций относительно возможности VCL 2.0, которая будет кросс – платформенной родственницей VCL. Такая библиотека существует (находится в разработке) и будет представлена вместе с VCL, которая останется для Windows разработки. Ее рабочее название в новостных группах и при прочих упоминаниях  VCLX - даже если такое название кажется актуальным, название релиза будет другим : – и в дорожной карте о ней написано “ограниченная обратная совместимость”.

Но, где, же мы можем найти больше информации о VCLX?

Разбор NDA (я не знаком с аббревиатурой NDA, очевидно речь идет о новостных группах, – прим. переводчика) не приведет к решению, поверьте мне. Я против такой практики потому, что она не достоверна и даже если мы забываем, что мы люди, по крайней мере, на 11 часов, последние капли человечности.

Фактически, если бы я не нашел публичной информации об этом, я бы не сделал этот пост.

Но публичную информацию о VCLX довольно трудно найти, и я думаю, что лучше целенаправленно обсудить последствия. Так, где же находится эта ‘публичная информация’, которая информирует нас о таинственной VCLX?
Наверное здесь? (Скриншот ниже – читайте внимательно).

Для старых дельфинистов все предельно ясно: новая VCLX это подправленная (старая) Kylix CLX. Следовательно, VCLX – основана на QT. Для новичков – посмотрите также описание QT в Википедии.

Хорошо, фактически для всех это не большой сюрприз. Потому как, даже если у Mac’s OSX есть ‘нативная’ платформа, то для Linux такого просто не существует. Таким образом, они должны опираться на некоторые уже установленные рамки, поскольку делать все с нуля для Linux невозможно по ряду причин. Так же по многим причинам выбор Qt смотрится наиболее логично.

А сейчас несколько слов для Mac фанов: Парни, кажется, что они достаточно глубоко копнули в сторону  внутренней работы  Mac OSX (наверное), и мы должны ожидать некоторые приятные сюрпризы. Я думаю, что если они будут ограничиваться QT для поддержки MAC, то они не сделают далеко идущих разработок в данной области. Взгляните на материалы серии постов от одного из разработчиков компилятора. Еще, мы знаем, что Крис Бенсен (один из старших R&D инженеров Embarcadero) обратился к Apple с целью обсуждения некоторых ключевых технических вопросов с местными  ребятами (среди них есть бывшие Borland-овцы, работавшие несколько лет назад над Delphi, – не стоит обманываться содержимым их Web-страницы – нажмите на ссылку About).

Проблема Win64.

О, 64-битная разработка:. Не беспокойтесь, Ник (Ник Ходжес, – прим. переводчика) дал понять, что VCL будет использоваться для 64-битных разработок:

vcl64

vcl64

Следовательно, мы имеем:
VCL для Win32 и Win64;
– базирующийся на QTVCLX (aka CLX) для Win32, Mac OSX и Linux.

Отлично, я думаю это действительно большая новость и хорошее направление, но некоторые вопросы достойны обсуждения:

CLX был известен своими багами,

которые на сегодня сформировали ‘антиCLX-овое’ мышление. Я думаю, что одной из многих целей команды, которая работает над “новой” VCLX является повышение ее качества. И это не зависит от того, будет – ли VCLX базироваться на QT или нет.

QT-зависимость.

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

Естественная поддержка MAC.

Если у нас не будет нативных библиотек для MAC, то каким образом мы получим ‘нативный’  QT для MAC? Ок, есть ряд приложений, которые не нуждаются в нативности (мультимедиа  редакторы, другие скинованные приложения и т.д.), но фактически MAC сообщество очень чувствительно к Mac’овскому внешнему виду. Я думаю, что мы должны реагировать на них.

Поведение и гибкость.

Pascal уровень поверх QT уровня поверх ОС уровня: Вроде бы ясно. Но, здесь мы должны учитывать две вещи: FreePascal группа не жалуется на слишком большое количество вопросов о производительности (по крайней мере, насколько я знаю, поправьте меня, если я ошибаюсь). GUI часть (та часть, где кросс платформенная система особенно нужна) не так уж требовательна к скорости. Возможно, было бы целесообразно обеспечить тонкий (да, а толстый и не сделаешь :-)) слой, с прямым доступом к API / ABI  операционной системы?
Совместимость. Уххх: совместимость. С  VCL, конечно. При условии, что у нас нет одинаковых UI виджетов. Но, я думаю, что мы можем извлечь пользу (иногда весомую) из одинаковой RTL и одинаковых не визуальных классов (TstringList, например) – еще, если малой кровью привязать это к Prism, то почему нет?

Поддержка сторонних производителей:

Связано с предыдущим пунктом. Конечно, мы считаем, что для достижения успеха, VCLX должна иметь строгую поддержку сторонних производителей. Но здесь интересно заметить, что если родные компоненты будут достаточно хороши для того, что бы использовать их в 2010-ом году, то давление на вторичный рынок значительно снизится. Например, если VCLX’s DBGrid будет довольно хорош (ребята, сейчас не каждое поле может быть отображено и отредактировано в TDBEdit) тогда многие пользователи умерят свои запросы. В противном случае они не станут покупать. И будут ждать. И снова ждать: или уходить, конечно.

Цена.

Что заставит нас купить Delphi, когда есть QT и QTCreator? Когда есть XCode? Язык? IDE? Неординарные возможности в VCLX/RTL? DataSnapX?  До настоящего момента DataSnap был доступен только в Architect редакции. Я думаю, что RAD Studio 2011 должна иметь четкие самобытные особенности, отличные, как от QT, так и от свободно распространяемых инструментов Apple (XCode / Interface Builder), для того что бы получить прозрачные точки сбыта.

Итак, после всех этих пунктов (хотя, я уверен, что их намного больше – пожалуйста, не стесняйтесь добавлять их в комментариях), я продолжаю считать, что это хорошее направление, но все зависит от того, как это будет реализовано.


Поделись с другими!
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  

9 комментариев: Delphi 2011 и далее: будущее библиотек.

  • > я не знаком с аббревиатурой NDA, очевидно речь идет о новостных группах

    NDA – Non Disclosure Agreement – договор о нераспространении
    http://anticopyright.ru/index.php?title=NDA&oldid=7241

  • Спасибо

  • Lazarus рулит!
    И уже давно…

  • Начну с пожеланий.
    1) Прикрутите к блогу(?) поддержку OpenID.
    2) Впредь не торопитесь с переводом. Качество оставляет желать лучшего. Но тут исходник, конечно, “ниачём”.

    Теперь по “сабжу”. Ну, во-первых, Qt пишеться именно так и никак ни QT. Последняя аббревиатура расшифровывается QuickTime. Учитывая о чём материал, это может ввести в заблуждение. Знаю, знаю. В оригинале также. Это говорит лишь об одном – автор, простите, профан в излагаемом материале. А стоило вообще этот бред переводить?

    Ну и так далее, Mac пишеться Mac, а не MAC…

    И вообще, какой смысл делить шкуру неубитого медведя? Вот выйдет хотя бы Public Beta, тогда и увидим, что да как…

  • Hi,

    When you copy an article from somewhere perhaps is better to say it and post a link to the original article?

    http://wings-of-wind.com/2010/03/14/delphi-2011-and-beyond-the-libraries-ahead/

  • 2 Wings of Wind

    Link to original article is present. Please, see word “Оригинал” on top of this post (russian “Original”).

    Thank you for good analytics into your post.

  • 2 kemiisto

    В оригинальном посте использовалась аббревиатура QT (правда через раз), думаю это писалось в “умном” редакторе, который сам исправлял регистр.

    В любом случае, спасибо за замечание, хотя автор явно не профан.

    OpenID на досуге прикручу.

  • Интересный пост. Есть над чем призадуматься.

    И всё таки, Александр, как Вы думайте… Если есть предположим небольшой проектик, клиент от 2-х звенки, доступ к БД через dbExpress, обычные формочки, гриды наследники DBGrid, будет ли возможность скомпелить его под 3 системы не меняя код?

  • Сомневаюсь. Но вообще, смотря как код организован.

Продукты DevArt
Купить онлайн:



Читай русскоязычные Delphi блоги
Каталог блогов Blogdir.ru
Яндекс.Метрика