Какая версия Delphi, по вашему мнению, была (или является) лучшей?

Самая свежая

Та, которая есть. Если она устраивает.

D7

> Kerk ©   (25.03.17 00:03) [1]
>
> Самая свежая


10.2?

Delphi 5 1998 года

> Belkin ©   (25.03.17 10:19) [4]

10.2 пока не успел посмотреть. Но обычно тенденция такова, да.

> Kerk ©   (25.03.17 12:46) [6]

ну список правок внушительный, хотя, нет ничего особо существенного, кроме linux, похоже на то, что взяли курс на стабильность и мелочи.

D7

> Eraser ©   (25.03.17 12:51) [7]

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

Там, кстати, bpl совместимы с 10.1?

> Там, кстати, bpl совместимы с 10.1?


Кстати нет


> по работе фокус с делфи сместился на другие платформы


Опять Delphi умирает. Тенденция, однако.

> Игорь Шевченко ©   (25.03.17 15:18) [10]
>
> > Там, кстати, bpl совместимы с 10.1?
>
> Кстати нет

Предсказуемо :)

Если не секрет, куда сместился фокус?

nodejs

D5... более новых не видел (

> Kerk ©   (25.03.17 00:03) [1]
> Самая свежая


неа.

Пока самая лучшая Berlin 10.1 upd 2.
Tokyo пока сыровата.

> Kerk ©   (25.03.17 14:03) [9]
>
> > Eraser ©   (25.03.17 12:51) [7]
>
> К сожалению, по работе фокус с делфи сместился на другие
> платформы


А чего вместе с Delphi не сместились на другие платформы? Там же поддержка 4 платформ.
Дорого?

> Tokyo пока сыровата.


Правда я не смотрел, но так говорят.. Надо смотреть. У меня сейчас проекты под Android и iOS - нет времени на переход на Токио. Там кстати под андроид есть одно ключевое изменение - перенесли главный application поток в поток Android UI thread.

> Кто б сомневался ©   (26.03.17 02:11) [16]
> А чего вместе с Delphi не сместились на другие платформы?
>  Там же поддержка 4 платформ.
> Дорого?

Delphi не успевает за трендами. Они в принципе угадали с Linux и IoT, как до этого угадали с мобилками. Но вот написал я делфи-проект под линукс, запихал его в docker-контейнер, дальше-то что? Где библиотеки для работы с Google Datastore, Google PubSub? Где поддержка GraphQL? MQTT? И так далее. Самому писать? Часть из этого можно купить, часть найти начатое кем-то и заброшенное. Но проще воспользоваться готовой доступной инфраструктурой. Как ни печально.

Как и в случае с мобилками, они скорее всего доведут всё до ума. Лет через пять. Но нужно-то уже сегодня.

> Кто б сомневался ©   (26.03.17 01:57) [15]
>
> Пока самая лучшая Berlin 10.1 upd 2.
> Tokyo пока сыровата.

Возможно, первые звоночки передачи работы на аутсорсинг :(

D7
Просто на этой версии удалось максимально долго сопровождать что то, что делал.
Наверное я сторонний наблюдатель, кроме БД ничего не знаю и не понимаю.

> Kerk ©   (26.03.17 13:28) [18]


Linux появился только неделю назад в Tokyo, о чем ты говоришь.
А по поводу

> Как и в случае с мобилками, они скорее всего доведут всё
> до ума. Лет через пять.


Если брать последний Berlin - уже все вполне быстро работает. Широкий набор необходимых мультиплатформенных компонент тоже есть, втч компоненты сторонних разработчиков с нативным API, чего не хватает конкретно?
Да поначалу с непривычки будет неудобно, но затем все пойдет по накатанной - зато проект работает под Android\iOS (Win\MacOS).

> Delphi не успевает за трендами.


Расскажи, какие из мультиплатформенных средств успевают за трендами?

Лисп и Лого. Всегда в тренде.

> Возможно, первые звоночки передачи работы на аутсорсинг
> :(


В Tokyo запороли платформу Android, это временный конечно фактор - фактически невозможно делать программы под андроид из за того, что все дико тормозит. Большой cписок ListBox с контролами (edit, combo, memo  итд ) может открываться минуту, хотя раньше это было почти мгновенно. FPS упал раза 3. Толи это из за переноса главного потока в UI thread толи из за  мультипотокового TBitmap. Я не проверял, но читал комменты на оф. форуме. Проблема только с Андроид, в других осях вроде ок.
Недотестировали..

> Кто б сомневался ©   (27.03.17 09:59) [23]

скорее всего ошибка в 17 строке. стабильную версию увидим после первого апдейта, как обычно.


> Недотестировали..

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

> Кто б сомневался ©   (27.03.17 02:55) [20]
>
> Если брать последний Berlin - уже все вполне быстро работает.

Я хотел сказать, что мобилки довели до ума лет через пять после того, как впервые анонсировали. Ну или не через пять. Суть не в конкретной цифре, а в том, что сильно не сразу. Когда это впервые появилось, этим почти нельзя было пользоваться.

Неделю назад анонсировали Linux. Ну ждем теперь когда доведут до ума :). А тем временем знаешь сколько мы платим за несколько сотен виндовых лицензий?

Или вот например у нас приложение большое и сложное для персонала, обслуживающего систему. Оно естественно на Delphi под Windows. А так уж сложилось, что очень многие используют макбуки и запускают наше приложение в виртуальной машине. Это не удобно. Что предлагается? Переписать его на FMX без компонентов DevExpress и многого другого? Можно конечно, но проще сразу подумать над веб-версией.

Мы сейчас временно используем Thinfinity VirtualUI, чтобы с нашим приложением можно было работать через браузер. Но во-первых, это опять платно. А во-вторых все равно не так удобно, как если бы это изначально было веб-приложением.

> Кто б сомневался ©   (27.03.17 02:58) [21]
>
> > Delphi не успевает за трендами.
>
> Расскажи, какие из мультиплатформенных средств успевают
> за трендами?

В нашем случае это JavaScript. У всех ведь разные потребности. Для нас мультиплатформенность - это клиент/сервер и встраиваемая техника. На мобилках JS тоже что-то предлагает, но я особо не интересовался, на мобилках у нас нативные приложения на ObjectiveC и Java.

Не надо думать, что я Delphi как-то очерняю. Я сам известный делфи-адвокат :). И в JS меня многие вещи жутко раздражают. Но так уж вышло, когда сложили все "за" и "против".

> Eraser ©   (27.03.17 11:25) [24]
>
> они обречены тестировать на юзерах пока не будет взрывного
> роста популярности, на порядок.

У них на бету не так уж мало людей подписано. Многие из моих знакомых. Самому мне всегда было лень :)

> на мобилках у нас нативные приложения на ObjectiveC и Java.

Опять же. Доведи Embarcadero всё до ума хотя бы года два-три назад, может и на Delphi были бы мобильные приложения у нас, кто знает. В этом вот и выражается запаздывание.

> Мы сейчас временно используем Thinfinity VirtualUI, чтобы
> с нашим приложением можно было работать через браузер. Но
> во-первых, это опять платно. А во-вторых все равно не так
> удобно, как если бы это изначально было веб-приложением.
>


Мы часть интерфейсов переносим на Унигуй. Это уже почти веб. Либы очень интересные и удобные, скорость разработки против веба: то, что делалось на вебе (jQuery) полгода, сделали за три дня.


> Где библиотеки для работы с Google Datastore, Google PubSub?
>  Где поддержка GraphQL? MQTT? И так далее. Самому писать?


Писать, использовать и продавать, как вариант.

> это клиент/сервер и встраиваемая техника. На мобилках JS
> тоже что-то предлагает, но я особо не интересовался, на
> мобилках у нас нативные приложения на ObjectiveC и Java


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

> Дмитрий Белькевич ©   (27.03.17 14:02) [28]

Так эти приложения уже есть. Не переписывать же их теперь.

Если поддерживать не нужно больше, чем они есть - то, конечно, нет смысла. А если нужна постоянная поддержка, то чего ради? Мы у себя с десятка два форм виндового гуя планируем выкинуть, и десяток страниц в вебе, заменим всё на унигуй.
Поддержка зоопарка немного напрягает (особенно в вебе), вдобавок не все фишки есть у виндового гуя. Например - много-юзерский интерфейс. Да и грид унигуевый мне даже больше симпатичен, чем тот, что мы используем.

> много-юзерский интерфейс
это как?

> что делалось на вебе (jQuery) полгода, сделали за три дня.
весьма сомнительно, если только те кто делал ни веба ни квери до того в глаза не видели

> это как?


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


> весьма сомнительно, если только те кто делал ни веба ни
> квери до того в глаза не видели


Ну как бы вот так.

> Кто б сомневался ©   (27.03.17 09:59) [23]
> В Tokyo запороли платформу Android


Я сижу на Berlin 10.1 и пишу в основном для Android. Другими словами, мне на Токио переходить не рекомендуется, верно?

Еще такой вопрос возник. Тут некоторые говорят, что сидят до сих пор на Delphi 5-7 и не жжужат, потому что всё равно получается рабочий код, который запускается на всех версиях Windows.

А как насчет Андроида? Будет ли код, написанный на Berlin 10.1, работать в следующих версиях Android?
Я не говорю про использование новых фишек ОС, а о работоспособности приложения. Можно ли просто заморозиться на текущей, вполне сносной версии Delphi 10.1?

>  Другими словами, мне на Токио переходить не рекомендуется,
>  верно?

Лучше не переходить. Там сочные баги, вплоть до нерабочих компонентов (MEdia плеер например)


> Можно ли просто заморозиться на текущей, вполне сносной
> версии Delphi 10.1?


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

А так по идее можно поставить обновленное Android SDK на нужную версию Delphi  и вперед (лучше так не делать, а использовать рекомендуемое SDK по умолчанию)

> Kerk ©   (27.03.17 12:56) [25]
>
> Или вот например у нас приложение большое и сложное для
> персонала, обслуживающего систему. Оно естественно на Delphi
> под Windows. А так уж сложилось, что очень многие используют
> макбуки и запускают наше приложение в виртуальной машине.
>  Это не удобно. Что предлагается? Переписать его на FMX
> без компонентов DevExpress и многого другого? Можно конечно,
>  но проще сразу подумать над веб-версией.


Вы на это решение смотрели? https://www.codeweavers.com/?

Фактически результат воспринимается как отдельная программа под MacOS, технически ваша Windows программа запускается под Wine.

Мы пробовали Parallels Desktop. По описанию это вроде где-то рядом. Но это опять дополнительные расходы.

Стоимость делфи - это одно. Это можно себе позволить. Но дополнительные расходы, которые увеличивают стоимость каждого устройства и пользовательского рабочего места (лицензии на Windows, Parallels и т.п.) - это уже проблема.

> Kerk ©   (27.03.17 23:04) [37]


Можно перевести часть работников на удаленку, они пусть работают себе дома как они обычно работают (на пиратках или покупной Delphi), - а в офис меньше лицензий покупать.

Кто б сомневался ©   (27.03.17 23:25) [38]

Странный ты.

> Кто б сомневался ©   (27.03.17 23:25) [38]

Можно конечно делать это стоя на лыжах, в гамаке. Но зачем? :)

а вот я не понял, почему [38] странность автора и лыжегамачность.
то, что это пиратско - это понятно. но удаленка - нормальный современный метод. минимизация расходов - тоже нормальный метод, и предложенный еще не самый противозаконный.

> Kilkennycat ©   (27.03.17 23:59) [41]

Как это должно выглядеть? Нужно прийти к клиенту, к самому главному их начальнику и сказать: "Так как мы пишем на Delphi, вы все делаете неправильно, вы должны под нас подстраиваться. Выбросьте макбуки сотрудников в окошко и отправьте их домой сидеть на пиратской винде. И вообще привыкайте к накладным расходам, с нами их у вас будет очень много". Как-то так? Не, так дела не делаются.

> Kilkennycat ©   (27.03.17 23:59) [41]


Это да, более того, вам еще и работники благодарны будут, не все же экстраверты.
Я имел ввиду не работников клиента, а конкретно работников вашей компании.


> И вообще привыкайте к накладным расходам, с нами их у вас
> будет очень много".


Ну можно перенести на crossover, это стоит 20$ в год.
Можно портировать Delphi VCL на FMX и оттуда на МACOS, а также на Android и iOS.

Сделать один универсальный мультиплатформенный проект. Правда затратив больше времени (т.к. придется переписывать все).
Вместо 4 разношерстных проектов, на 4 разных языках, собранный на разных платформах, разными программистами, где каждое мизерное изменение программы, проходит длиннющую цепочку событий и затрагивает множество людей.

Конечно я не знаю деталей, возможно действительно лучше будет сделать вебверсию..

> Кто б сомневался ©   (28.03.17 00:49) [43]

кроссплатформенность - это костыль, позволяющий небольшим командам сильно упростить жизнь на определенном этапе. ясное дело, что лучше иметь родные приложения под каждую платформу, если есть такая возможность. какие тут могут быть вайны, кроссоверы, FMX и т.д.
backend тоже лучше на node.js писать, если есть для этого квалифицированные кадры, а не заниматься извращениями.

> ясное дело, что лучше


Ой, вам прям в журналисты надо было идти с такими формулировками.

> Кто б сомневался ©   (28.03.17 09:14) [45]

ты о чем? почитай какое бурление г. начинает в qa различных кроссплатформенных инструментов (особенно FMX) после выхода новой версии iOS или андроида. а те, кто изначально работают на xCode к моменту релиза новой iOS уже могут выпустить продукт не то что работоспособный, но и с поддержкой новой SDK со всеми ее фитчами, в тот же день практически.
я сам использую FMX, по возможности, для каждой платформы уйдем в родные IDE и языки. другой вопрос, что такой возможности пока нет.

> ясное дело, что лучше иметь родные приложения под каждую
> платформу, если есть такая возможность


Всё хорошо, только что в разработке это будет всегда дороже.


> какие тут могут быть вайны, кроссоверы,


С этим согласен. Сам очень не люблю всевозможные прослойки.


> Конечно я не знаю деталей, возможно действительно лучше
> будет сделать вебверсию.


Если в том же унигуе хватает функций и скорости - то я бы даже сильно не думал.

> Eraser ©

Да, Delphi проявила себя прекрасно пока у нас долгое время было два разработчика, а до моего прихода вообще один. Я не представляю какое другое средство разработки позволило бы сделать так много. Но постепенно приходит необходимость расти, становится гибче, масштабируемее и удобнее.

Дмитрий Белькевич ©   (28.03.17 10:32) [47]


> Всё хорошо, только что в разработке это будет всегда дороже.


Если прибыль от эксплуатации превышает стоимость разработки, то какая нафиг разница ?

фмх помрет точно так же как помер интравеб в районе D2

а ведь он был почти как кошерный asp.net и даже лучше

> Если прибыль от эксплуатации превышает стоимость разработки,
>  то какая нафиг разница ?


Разница в том, что, как правило, коммерческие организации стремятся к увеличению прибыли. Если же этой цели не ставится - то да, разницы нет никакой.

Коммерческие организации как правило существуют не в вакууме. И когда у конкурентов все лакировано и блестит, а тебя тут работает, тут не очень, а тут скотчем замотано - это как минимум вызывает вопросы.

Кроссплатформенность - это хорошо. Но это всегда компромисс. Никогда не будет кроссплатформенное приложение работать как родное. И тут не в Delphi дело. Я уж не говорю про то, что предложение пересадить всех на пиратскую винду - это совсем не серьезно уже.

Я не представляю какое другое средство разработки позволило бы сделать так много. Но постепенно ......

тоже так же думал когда-то давно.
но постепенно вышло так, что делфи достаю из пыльного шкафа пару раз в год.
а раньше на каждый чих - Project1.exe

> Но постепенно приходит необходимость расти, становится гибче,
>  масштабируемее и удобнее.


Никто, впрочем не мешает совместно с Делфи использовать веб :) Мы у себя часть функций делаем в вебе. Часть, правда, будем возвращать назад, как писал. Благо, что как раз допилили унигуй.

Интересно, а есть сравнения работы компиляторов Delphi разных версий? В плане насколько быстродействующим получается выходной файл.

Например, сравнить все компиляторы от Delphi 2 до Delphi Токио, прогнав миллион итераций Inc(I)

да кому это надо вообще

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


Если так - то тут сложно что-то возразить. У нас ситуация скорее наоборот. Как раз у конкурентов скорее примотано скотчем. А веб позволил более-менее единообразно всё сделать.


> Например, сравнить все компиляторы от Delphi 2 до Delphi
> Токио, прогнав миллион итераций Inc(I)


Тест ни о чем.

> > Например, сравнить все компиляторы от Delphi 2 до Delphi
> > Токио, прогнав миллион итераций Inc(I)
>
>
> Тест ни о чем.


В моей программе много используется этот оператор, а также операторы сравнения. И всё это рекурсивно

и што?

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

вопрос:
сколько лет потребуется чтобы натикало хотя бы месяц этой разницой в пять наносекунд?

Ох, вот DevilDevil рассказал бы нам, что пять наносекунд - это очень важно, а мы тут все лузеры. Я аж заскучал... :)

В переборных задачах выигрыш на одном операторе даже в 5 наносекунд важен

> Belkin ©   (28.03.17 13:05) [55]
>
> Например, сравнить все компиляторы от Delphi 2 до Delphi
> Токио, прогнав миллион итераций Inc(I)


> Belkin ©   (28.03.17 14:47) [58]

> > Тест ни о чем.
>  
> В моей программе много используется этот оператор, а также
> операторы сравнения. И всё это рекурсивно

Ешё один "партнёр" нарисовался.
Зачем тебе этот бессмысленный тест? Даже тебе он неинтересен.

> rrrrr ©   (28.03.17 15:07) [59]
> и што?
>
> допустим ты клепаешь три месяца на одной студии,
> и внезапно понимаешь, что в другой студии инк на пять наносекунд
> быстрее.
> еще месяц портируешь все на эту студию.
>
> вопрос:
> сколько лет потребуется чтобы натикало хотя бы месяц этой
> разницой в пять наносекунд?

Расскажи это разработчикам систем машинного зрения, например... :)
Хотя конкретно, про Ink согласен - ни о чем...

> про Ink

Inc, разумеется. :)

> Eraser ©   (28.03.17 09:45) [46]
>
> > Кто б сомневался ©   (28.03.17 09:14) [45]
>
> ты о чем? почитай какое бурление г. начинает в qa различных
> кроссплатформенных инструментов (особенно FMX) после выхода
> новой версии iOS или андроида.


Ерунда какая, вы что каждый раз под новый SDK свои продукты переписываете (независимо от языка)? Под Windows вы также делаете что-ли?
Это ж сколько времени надо, особенно если проектов как минимум больше 3 и какой в этом смысл? Имхо достаточно запустить и протестировать работает или нет без компиляции итп.

Родные инструменты лучше с точки зрения "запуститься на последних обновлениях ОС", это понятно, но нужно учитывать что кроссплатформенные инструменты начали развиваться совсем недавно, раньше их не было. И вы судите по старым критериям, т.к. - 10 лет назад этого и не было.

Что даст кроссплатформа - единый код, единый интерфейс, единую логику, универсальность.
Дело не только в деньгах, это удобно и время экономится.
Как можно отрицать такие очевидные вещи.

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

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

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

И про какие 4 платформы речь? Если перенос пользовательского интерфейса из iOS в Андроид еще можно себе представить, то переносить формы из Windows на мобильные платформы? Ну вряд ли...

Расскажи это разработчикам систем машинного зрения, например... :)
Хотя конкретно, про Ink согласен - ни о чем...



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

Что даст кроссплатформа - единый код, единый интерфейс, единую логику, универсальность.
Дело не только в деньгах, это удобно и время экономится.
Как можно отрицать такие очевидные вещи.

что мне дала конкретная кроссплатформа (как ее эксплуатанту)

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

> Kerk ©   (28.03.17 19:52) [66]
> Проблема в том, что на каждой платформе есть свои традиции
> построения и реализации интерфейсов. Поэтому эта кнопочка
> на каждой платформе будет в разном месте и иногда даже вести
> себя должна будет по-разному. А иногда этой кнопочки вообще
> не будет.
>
> И про какие 4 платформы речь? Если перенос пользовательского
> интерфейса из iOS в Андроид еще можно себе представить,
> то переносить формы из Windows на мобильные платформы? Ну
> вряд ли...


Вы наверное не пользовались FMX. А там есть такая классная вещь как стили. Это
что то типа скинов, но лучше, т.к. позволяют что-то делать в зависимости от действия юзера. Так вот делается отдельный стиль для каждой платформы где учитываются ньюансы платформ, и все это натягивается на дефолтные элементы управления.
К примеру табы, списки и др. у Андроид имеют один вид и расположение, на маке другой, на iOS третий, и все это на едином TTabControl. Причем там даже встроенные говые стандартные иконки есть  - выбираешь тип иконки и для iOS FMX автоматом ставит нужную.
Также можно легко это стиль отлаживать в Винде (нужно сделать правку в Style файле - в строке platform). Я например на винде делаю стиль для андроида (на основе существующего) и iOS и потом когда все готово, проверяю на реальном устройстве.  Причем рисует его один в один, нет никаких косяков с ресайзом, масштабом, размерами\пропорциями на других платформах вот что значит свой единый фрэймворк.
И в целом FMX очень продвинута по графике и анимации.

И да, сейчас пошла тенденция делать внешний вид на винде и маке как на мобильных платформах.
Вобщем то и MS туда же пришли - начиная с винды 8 у них дефолтный скин косит под мобильный.
Вот например Комодо.
https://i.stack.imgur.com/2Q5GB.jpg

Kerk ©   (28.03.17 19:52) [66]
> то переносить формы из Windows на мобильные платформы? Ну
> вряд ли...


У Комодо антивирус точно такой же интерфейс и на Винде и на Маке, отличается только расположением системных кнопочек (Delphi и их рисует автоматом в нужном месте).
goo.gl/lzHxCz

А по факту это мобильный интерфейс для планшетов (крупные элементы без менюшек, для тыканья пальцем)
Т.е. можно особо не печалиться и с FMX сделать в программе универсальный интерфейс для больших экранов (PC и планшеты) и маленьких (мобильные телефоны) независимо от платформы.

> Кто б сомневался ©

Дьявол кроется в мелочах.

Вот простейший пример. Обычная кнопка. В FMX и VCL. Видишь разницу?

http://yankovsky.me/fmx-button.gif
http://yankovsky.me/vcl-button.gif

Я даже не буду приводить в пример какие-то баги. Достаточно таких вот неуловимых мелочей, которые отличают родное приложение от стилизации под родное приложение.

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

> У Комодо антивирус точно такой же интерфейс и на Винде и
> на Маке, отличается только расположением системных кнопочек
> (Delphi и их рисует автоматом в нужном месте).

Странный аргумент. В итоге это их приложение выглядит как неродное в любой операционной системе. И это плохо.

Несколько замечаний.


> Странный аргумент. В итоге это их приложение выглядит как
> неродное в любой операционной системе. И это плохо.


1. А мне нравится, как комод выглядит.

2. Криков начал делать новую либу - CrossVCL:

http://www.crossvcl.com/

3. Я всегда говорил, что нужно делать надстройки над стандартными контролами даже в кросс-платформенных компонентах вместо рисования своих. ИМХО это тупиковый путь.

> Вот простейший пример. Обычная кнопка. В FMX и VCL. Видишь
> разницу?
а где разница? что то не заметил :)

> Странный аргумент. В итоге это их приложение выглядит как
> неродное в любой операционной системе.
уже наплевали давно все на единый подход, может мода и вернется когда нибудь, а пока все делают как "не родные", мы вот тоже свою сделали аля метро стайл, всем это неродное нравится, можно тыкать в планшете а можно и мышкой виндовой.

Непонятно только с каких пор метро неродное.

Ну да ладно. Я свои аргументы привел уже давно в [18] и [25]. Никого переубеждать не буду.

Дмитрий Белькевич ©   (28.03.17 22:49) [73]


> 2. Криков начал делать новую либу - CrossVCL:


Евгений - он Крюков.

А я до сих пор не понимаю, какое серьезное приложение может одновременно использоваться на разных платформах. Ну кроме wordlines, разумеется.

> Kerk ©   (28.03.17 23:12) [75]
> Непонятно только с каких пор метро неродное.


Потому что Метро это планшетный стиль содранный с Android, родной стиль Windows это менюшки, тулбар с мелкими кнопками, 3D контролы, иконки разного цвета, итп в общем все для работы с мышкой..


>
> В итоге это их приложение выглядит как неродное в любой
> операционной системе. И это плохо.


Судя по популярности комода это не так уж и плохо.
Кстати почему Метро стиль тебя не смущает в винде, хотя это чужой для нее стиль и с ним не удобно работать. Где ж тут логика.


> Kerk ©   (28.03.17 22:21) [72]


Такую анимацию кнопки легко добавить в существующий стиль за пару минут. Причем никакого код не надо.

> Игорь Шевченко ©   (28.03.17 23:32) [77]

Ну я приводил выше пример. Наше клиентское приложение для обслуживания системы писалось под Windows и этого хватало. А тут мы пришли, а там почти у всех макбуки. Виртуализацией мы костылей понаставили и вроде работает, но уже не то, что нормальное приложение. Такие вещи проще сразу в веб.

> Кто б сомневался ©   (28.03.17 23:44) [78]
> Кстати почему Метро стиль тебя не смущает в винде, хотя
> это чужой для нее стиль и с ним не удобно работать. Где
> ж тут логика.

Потому что это не чужой для нее стиль, а стиль предоставленный производителем.

> Судя по популярности комода это не так уж и плохо.

Да пофиг. Если заставить людей по 8 часов в день с таким разноцветным аляпистым попугаем работать, у них глаза вытекут.

> Такую анимацию кнопки легко добавить в существующий стиль
> за пару минут.

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

В последний раз :)
FMX хорош как компромисс. Чтобы сделать достаточно хороший интерфейс в целом похожий на настоящий. Но нюансы всегда будут лезть наружу.

Kerk ©   (28.03.17 23:50) [80]
> FMX хорош как компромисс. Чтобы сделать достаточно хороший
> интерфейс в целом похожий на настоящий. Но нюансы всегда
> будут лезть наружу.


То вы определитесь, вам шашечки или ехать.

На данном этапе хотим покататься с шашечками.

Как я писал в [48] (извиняюсь за обильное самоцитирование): "Delphi проявила себя прекрасно пока у нас долгое время было два разработчика, а до моего прихода вообще один. Я не представляю какое другое средство разработки позволило бы сделать так много. Но постепенно приходит необходимость расти, становится гибче, масштабируемее и удобнее."

> А я до сих пор не понимаю, какое серьезное приложение может
> одновременно использоваться на разных платформах. Ну кроме
> wordlines, разумеется.
например браузеры, и все что в них, а там уже не мало а будет еще больше, вот и Kerk © & ko в ту сторону смотрят )

> Кто б сомневался ©   (28.03.17 19:24) [65]


> Ерунда какая, вы что каждый раз под новый SDK свои продукты
> переписываете (независимо от языка)?

нет. но, почему бы и нет? я считаю, что нормальный проект, рассчитанный для более-менее массового использования, должен уметь легко апгредиться, как для поддержки новых SDK, так и для поддержки новых IDE. таковы реалии. увы, Делфи не поспевает за этим даже в винде, на данный момент (например, где ARM? - отсутствует, где метро-технологии? - в самом зачатке).
вот такие перцы, типа работает - не трогай, набигают потом на форум в 2017 году с вопросами про UAC, юникод, упоминая при этом Делфи 7.


> А там есть такая классная вещь как стили. Это
> что то типа скинов,

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

согласен с Kerk'ом. всякие кроссплатформенные утилиты хороши, когда нужен быстрый и приемлемый результат. возможно, для части проектов лучшего и не надо. но там, где дело доходит до массовости и конкуренции нужно, в итоге, идеальное решение, а не компромисс.

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


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


> ARM? - отсутствует

Что такое "Arm?" в контексте Windows Desktop?
Delphi работает на процессорах Armv7 и Armv8 на Android (+ Intel через спец. ARM эмулятор который обычно сразу идет в коробке с Intel-Android девайсом ). А вот что такое Arm для винды, пока не знаю...


> , где метро-технологии?

Что можно сделать с WinRT чего нельзя сделать с обычным Win32\64 методом? По факту это обертка.

Вы кстати в курсе что MS монополист и не дает поддерживать WinRT другим:

Metro-style apps can only be developed using Microsoft's own development tools. According to Allen Bauer, Chief Scientist of Embarcadero Technologies, there are APIs that every computer program must call but Microsoft has forbidden them, except when the call comes from Microsoft's own Visual C++ runtime.
https://en.wikipedia.org/wiki/Universal_Windows_Platform_apps
А вы Delphi обвиняете.


> это скины и есть. что в них замечательного - не ясно. достаточно
> посмотреть как выглядит современное брендовое приложение
> для iOS со всеми их новомодными полу-прозрачностями и прочими
> эффектами и сравнить с Делфи-FMX-скинами, очередным костылем.
>


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

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

А скин не позволяет такое делать.

В FMX также есть прозрачность и null цвет. Можно указывать Opacity для каждого компонента (к примеру таким образом делается fade анимация), можно использовать векторные пути, png с альфа каналом..

Вот сейчас  рисую FilmFrame ленту для горизонтального списка там все на полупрозрачных PNG + анимация добавления, прозрачная картинка летит в ячейку списка уменьшаясь и плавно становясь не прозрачной и все это не сложно сделать - причем никаких таймеров не нужно, есть специальные компоненты для анимации.

> Kerk ©   (28.03.17 22:21) [72]
>
>
> Вот простейший пример. Обычная кнопка. В FMX и VCL. Видишь
> разницу?
>
> http://yankovsky.me/fmx-button.gif
> http://yankovsky.me/vcl-button.gif


Самое интересное, что когда делаешь такую кнопку, то в компоненте анимации там по умолчанию включен плавный fade, почему его выключили в стандартном скине не знаю..
Вот точно такой же пример, как легко это делать:
https://youtu.be/Q6vXbXFthLU?t=10m17s

странно, форма не активна, а онховер ловит...

Самое интересное у Керка из логики то, что ему хочется 'шашечек' - то есть полностью нативно-выглядящих приложений, а уходить они собираются в сторону веба - к нативности вообще отношения не имеющего. Немного альтернативный взгляд на разработку, как по-моему. Так бы на пачке всего и оставались, если ресурсы позволяют.

Kerk ©   (28.03.17 23:44) [79]

Ваше - это конечно мне сразу многое говорит, но я все равно не понимаю его целей и задач. WEB - это конечно хорошо, но там костылестроения обычно тоже хватает для поддержки состояния - или надо приложение перекраивать. Уж лучше виртуализацией, мне кажется.

ухты ©   (29.03.17 00:24) [83]

Браузеры уже написаны.

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


Убейтесь вы уже :)) Вот тоже самое, что с фильмами - вместо серъезных проблем во главу угла встает насыщенность спецэффектами.

> Дмитрий Белькевич ©   (29.03.17 09:17) [88]

Нативные приложения на мобилках, веб на компьютерах.

По сути это разные целевые аудитории. Мобильные приложения для внешних пользователей, веб для сотрудников.

А планшеты в куда? на них как с вебами? что только не наслушаешься)

Планшеты нам не нужны.

И не понимаю чего так докопались до клиентских приложений, если я еще в начале ветке написал, что в делфи-мире отсутствуют библиотеки для целого стека технологий, которые нужны уже здесь и сейчас. Мне этот ваш FMX всякие гугловые облака, нужные мне протоколы и прочие современные технологии заменит? Нет, не заменит. Ну так и чего обсуждать?

> Кто б сомневался ©   (27.03.17 19:31) [35]
>
>
> >  Другими словами, мне на Токио переходить не рекомендуется,
>
> >  верно?
>
> Лучше не переходить. Там сочные баги, вплоть до нерабочих
> компонентов (MEdia плеер например)


Интересно, а как можно испортить TMediaPlayer? Вроде несложный компонент, смотрел внутренности.

> Игорь Шевченко ©   (28.03.17 23:32) [77]
> А я до сих пор не понимаю, какое серьезное приложение может
> одновременно использоваться на разных платформах. Ну кроме
> wordlines, разумеется.

Например, Adobe Photoshop, MS Office, игры (практически, все) итд...
Или это все несерьезные приложения?


> Игорь Шевченко ©   (29.03.17 10:15) [90]
> Браузеры уже написаны.

Все? :)

asail ©   (29.03.17 15:35) [97]

Photoshop на планшете ? Месье понимает толк в извращениях.

MS Office - где используется, если не трудно ? У меня на устройствах под андроидом, например, его нету.

Игры практически все - даже не смешно.


> Все? :)


Все.

> Игорь Шевченко ©   (29.03.17 16:06) [98]

Почему фотошоп не может работать и на планшете? Учитывая мощности современных мобильных устройств, так и на многих телефонах сможет. Только не надо про маленькие экраны говорить... Ничто не помешает подключить тот-же телефон к внешнему монитору, да хоть в 40 дюймов диаметром.
Да и планшеты разные бывают. Почему фотошопу можно работать на 10-ти дюймовом ультрабуке под виндой, но никак низя на 10-ти же дюймовом планшете под андроидом? Окромя сугубо религиозных причин, других не вижу.
И да. Кроссплатформенность - это не только планшеты и телефоны. А еще, как минимум, MacOS и линукс...
Объясните мне извращенцу, почему фотошопу нельзя работать под MacOS?

И MS Office используется, например, на MacOS... Да и на андроиде он есть, только ущербный... Возможно, как раз потому, что не кроссплатформенный... Я бы не отказался от полноценного офиса и на андроиде.

> Игорь Шевченко ©   (29.03.17 16:06) [98]
>
> Все.

Т.е. новых браузеров больше не будет? Никогда, никогда? Очень спорное утверждение...
Вот, например, Эдж... Совсем же недавно появился.

> Игорь Шевченко ©   (29.03.17 16:06) [98]
>
> Игры практически все - даже не смешно.

Не смешно, ибо так и есть... Например, Counter Strike, помимо винды, есть и под OS X. Разве это не разные платформы?

asail ©   (29.03.17 16:43) [99]


> Почему фотошоп не может работать и на планшете?


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

Но речь не о том, как можно поизвращаться, запуская на планшетах всякое и разное. Речь как раз о том, что Delphi со своим FMX является инструментом кросс-платформенной разработки.
Я высказался именно в этом ключе, что не вижу приложений, для которых нужно такое средство.
Фотошоп и младший брат его лайтрум прекрасно работают на маках, но они не кроссплатформенны, они для каждой платформы были написаны отдельно, равно как и Ms Office, последний вообще чуть ли не разными командами разработчиков.

asail ©   (29.03.17 16:46) [100]


> Вот, например, Эдж... Совсем же недавно появился.


А чем он отличается от других ? Мне кажется, ничем. Обзови его MS очередной версией Internet Explorer и ничего бы не изменилось.

> Я высказался именно в этом ключе, что не вижу приложений,
>  для которых нужно такое средство.
> Фотошоп и младший брат его лайтрум прекрасно работают на
> маках, но они не кроссплатформенны, они для каждой платформы
> были написаны отдельно, равно как и Ms Office, последний
> вообще чуть ли не разными командами разработчиков.

Так тут-то и проблема... По логике, фотошоп на маке ничем не должен отличаться от фотошопа под виндой. Та же бизнес-логика у обоих. При отсутствии нормальных средств кроссплатформенной разработки приходится вести два (и более) ОДИНАКОВЫХ продукта. Добавили что-то в бизнес-логику первого, будьте добры, добавить и во второй. Хорошо еще, если ЯП один и тот-же в обоих продуктах, многое можно скопипастить... А если языки разные (библиотеки и апи, уж наверняка, разные)? Добавили новую фичу под виндой, скажем на шарпе, а теперь ее еще и под с++ для мака переписывать? Не жалко ресурсы-то?
ГУи тут, как раз, дело десятое... Не проблема в FMX и разные окна отрисовать под разные платформы. А вот иметь ОДНУ реализацию всей бизнес-логики под все платформы было бы очень не вредно!
Все ИМХО, разумеется... )

> А чем он отличается от других ? Мне кажется, ничем. Обзови
> его MS очередной версией Internet Explorer и ничего бы не
> изменилось.

Да пофиг на эдж! Представь, ты - Гугл. И у тебя есть Хром, отдельно под каждую из существующих платформ (винда, линукс, мак, яОС, андроид и, фиг знает, что еще). И тут появился новый стандарт, назовем его HTML343425... И теперь тебе надо под каждый свой Хром реализовать поддержку оного стандарта, вместо одного кроссплатформенного Хрома... Грусть-тоска, короче...

> Кто б сомневался ©   (29.03.17 02:58) [85]


> А вот что такое Arm для винды, пока не знаю...

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


> Что можно сделать с WinRT чего нельзя сделать с обычным
> Win32\64 методом?

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


> Вы кстати в курсе что MS монополист и не дает поддерживать
> WinRT другим:

еще одно подтверждение моих слов про кроссплатформенность в целом.


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

тут есть такая тонкость, которую никак не хочешь понять. мне не интересно заниматься построением своего GUI практически с нуля и рисованием. народ вообще приложения на игровом движке unity пишет, это его право. мне нужна прорисовка всех красивостей стандартными средствами. графические возможности нативной iOS несколько отличаются от того, что предлагает FMX.

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


> Вообще хоть смотрели FMX?

https://itunes.apple.com/us/app/remote-utilities/id793320970?ls=1&mt=8

честно говоря, жду не дождусь, когда дойдет дело переписать это все на swift для iOS и java для андроид.

> asail ©   (29.03.17 18:34) [105]


> Да пофиг на эдж! Представь, ты - Гугл. И у тебя есть Хром,
>  отдельно под каждую из существующих платформ (винда, линукс,
>  мак, яОС, андроид и, фиг знает, что еще). И тут появился
> новый стандарт, назовем его HTML343425... И теперь тебе
> надо под каждый свой Хром реализовать поддержку оного стандарта,
>  вместо одного кроссплатформенного Хрома... Грусть-тоска,
>  короче...

https://ru.wikipedia.org/wiki/Alphabet
Оборот
▲ $77.2 млрд (2016)
Операционная прибыль
▲23 716 000 000 $ (2016)[2]
Чистая прибыль
▲ $17 млрд (2016)
Активы
▲ $150 млрд (2016)
Капитализация
▲ $586 млрд (2017)[1]
Число сотрудников
66,575 (2016)

как-то справятся )

> как-то справятся )

Верю, что справятся...
Но, не у всех есть возможность сорить деньгами, как гугл или МС. Есть небольшие группы разработчиков, искренне желающие добиться максимального охвата рынка для своих продуктов. В том числе, и на разных платформах. И тут кроссплатформенность была бы нелишней...

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

Как бы да, но не совсем... Понятно, что ни один самый мощный планшет не сравним с современным десктопом (хотя, вполне может быть сравним с некоторыми ноутбуками, даже современными). Но у всех ли в любой момент времени есть самый современный десктоп?
Вот, у меня например, десктоп на базе древнего Q6600... Мне хватает (для фотошопа, в том числе), поэтому и не меняю. И что-то мне подсказывает, что мой телефон по вычислительной мощности, как минимум, не уступает этому десктопу, а скорее всего, превосходит... Так почему бы, мне не иметь весь софт, установленный на этом самом десктопе и на телефоне? Я бы, может, вообще от десктопа отказался бы... Докстэйшн, внешний моник и клава с мышью - и всего делов...

Мы вот свой софт под две платформы делаем - Win + Lin, и не жужжим. Софт работает, деньги платят. А на чём оно там написано - юзерам, чаще всего, пофигу. А написано оно на Лазарусе. Один код под 2 среды (Delphi, Lazarus) и несколько платформ. Вполне рабочее решение, и не сильно много головняка.

> Дмитрий Белькевич ©   (29.03.17 19:35) [110]
> Мы вот свой софт под две платформы делаем - Win + Lin, и
> не жужжим. Софт работает, деньги платят. А на чём оно там
> написано - юзерам, чаще всего, пофигу. А написано оно на
> Лазарусе. Один код под 2 среды (Delphi, Lazarus) и несколько
> платформ. Вполне рабочее решение, и не сильно много головняка.

Ну вот, как вариант кроссплатформы. С маками, правда, засада в лазарусе, насколько знаю. Но под линукс/винда - вполне...

На маке пока не пробовали, сложно сказать. Откуда сведения? Насколько я знаю - лазарь вполне работает на маках.

Я тут парочку глав в документации к нему переводил, упоминается часто:

https://drive.google.com/drive/folders/0By1Ihlfr9cFlLUdtMFhlTUdlblU

> Eraser ©   (29.03.17 18:56) [106]
>
> > Вообще хоть смотрели FMX?
>
> https://itunes.apple.com/us/app/remote-utilities/id793320970?
> ls=1&mt=8
>
> честно говоря, жду не дождусь, когда дойдет дело переписать
> это все на swift для iOS и java для андроид.


Расскажите почему вас не устраивает FMX.

собственно покодить на планшете чем не вариант, все есть, клаву бы только удобную, а батоны кидать и пальцем не зазорно ))

asail ©   (29.03.17 19:28) [109]


> Вот, у меня например, десктоп на базе древнего Q6600...
> Мне хватает (для фотошопа, в том числе), поэтому и не меняю.
>  И что-то мне подсказывает, что мой телефон по вычислительной
> мощности, как минимум, не уступает этому десктопу, а скорее
> всего, превосходит


А мне что-то подсказывает, что уступает, причем сильно.


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


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

>  Кто б сомневался ©   (29.03.17 20:34) [113]

Смотри куда мы FMX запихали :)
https://www.instagram.com/p/BSOrEhQhGaPWHYZYXiFQ9ofy06ZM10nz7oqnig0/?taken-by=romanyankovsky

Прикольно.

У FMX широкий охват устройств.

Процитирую:

На всех Android версиях от 4.0.4 до 7. На процессорах ARMv7. Также работает на Intel (Atom) процессорах через эмулятор ARM который разрабатывает Intel - libhoudini  обычно уже сразу установлен в таких девайсах.

Также работает на процессорах  ARMv8 (x64) т.к. они поддерживают  инструкции ARMv7.

По факту это наибольший сегмент мобильных устройств. Втч это Android Wear, Google Glass, разные Smart TV, Amazon FireTV, Amazon FirePhone, BlackBerry, см. статью ниже.

Не работает на ARMv6 и ниже довольный старый сегмент девайсов, ~2010, там и Android второй версии. Aндроид меньше 4 версии используют около ~1% устройств сейчас (https://developer.android.com/about/dashboards/index.html).


Интересная статья:
https://community.embarcadero.com/blogs?view=entry&id=8520

http://docwiki.embarcadero.com/PlatformStatus/en/Main_Page

http://docwiki.embarcadero.com/RADStudio/Berlin/en/Android_Devices_Supported_for_Application_Development

Кто б сомневался ©   (29.03.17 22:34) [117]


> У FMX широкий охват устройств.


Шире чем у Java ? :)

> Шире чем у Java ? :)


Если не брать iOT, то думаю не меньше. Ведь Java нет iOS.

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

> Кто б сомневался ©   (29.03.17 20:34) [113]


> Расскажите почему вас не устраивает FMX.

потому что практически все что угодно, более сложное, чем кнопка на форме упирается в какие-то грабли и ограничения FMX. особенно то, что связано с различными сервисами ОС. например, попробуй сделать перехват набора клавиш для android. таких примеров масса.
да и UI кривоват, по сравнению с тем, что можно в iOS через xCode сделать особо не напрягаясь.

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

> например, попробуй сделать перехват набора клавиш для android.

Попробуй это сделать на Java.
Это же не винда с хуками, там каждая программа в отдельной песочнице.
Удалось сделать?


>  таких примеров масса.
> да и UI кривоват, по сравнению с тем, что можно в iOS через
> xCode сделать особо не напрягаясь.


Насчет API cогласен. Но если понять как адаптировать Android API с Java на Delphi через jnibridge, то затем легко это можно делать, тем более примеров на Java много. Просто нужно руку набить.
Но дело в том, что и на Java вам нужно будет это изучать как перехватить клавиши на Android. Это очень непростая задача, и я вообще сомневаюсь что она возможна без рута, в iOS и в Android.


> да и UI кривоват, по сравнению с тем, что можно в iOS через
> xCode сделать особо не напрягаясь.

Не знаю что там кривого. Не замечал.
Может раньше и был кривоват, я просто вплотную занялся FMX где то с XE 8.

Но согласен по поводу адаптации API, - мало примеров и нужна высокая квалификация программиста, но такова цена кроссплатформы.
Да и раньше таких средств не было, фактически они первопроходцы.

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

> Кто б сомневался ©   (30.03.17 10:08) [122]


> Это же не винда с хуками, там каждая программа в отдельной
> песочнице.
> Удалось сделать?

в том то и дело, что перехват не глобально по всей системе, а в конкретном приложении. т.е. есть пустая форма, нужно перехватывать событие OnKeyDown. Что называется, удачи.
победить удалось конечно, но для этого пришлось копировать в свою папку юнит из генофонда FMX и править его, т.к. умники, проектирующие FMX леняться написать слово virtual лишний раз.
таких примеров я очень много могу вспомнить, вся разработка была с ними сопряжена.
вот оно мне надо - тратить время на изучение FMX, когда куда полезнее потратить его на изучение непосредственно целевой ОС? вопрос риторический. повторюсь, в свое время FMX помогла в довольно короткий срок сделать то, что на нативных платформах заняло бы на порядок больше времени. но перспективы я пока не вижу. куда комфортнее работать на нативной платформе.
И VCL ушел бы в топку, если бы в MS более ответственно подходили к обратной совместимости, и чтобы приложение, построенное без танцев с бубном на самой новой VS, запускалось хотя бы на WinXP, тоже без танцев с бубном. с построением UI у них беда, все таки.

так всетаки какая версия дельфи лучше?

> т.е. есть пустая форма, нужно перехватывать событие OnKeyDown


Перехватываю OnKeyUp на Android - вроде не замечал проблем.. Все стандартно.


> вот оно мне надо - тратить время на изучение FMX, когда
> куда полезнее потратить его на изучение непосредственно
> целевой ОС?


Тоже самое было бы при изучении Swift и Java. В Java+Android там тоже ньюнсов хватает. Также пришлось бы копаться в недрах. Не все так просто.

virex(home) ©   (30.03.17 11:40) [124]

Последняя, если она стабильная.

Сейчас это:
Если вы не разрабатываете под Android тогда Delphi Tokyo.

Если используете Android тогда Delphi 10.1 Berlin update 2, до первого обновления Tokyo.

> Игорь Шевченко ©   (29.03.17 21:31) [115]
> А мне что-то подсказывает, что уступает, причем сильно.

Боюсь, что зря оно тебе это подсказывает... Например, вот результаты мультиплатформенного популярного синтетического теста Geekbench 4.

Для Q6600:
https://browser.primatelabs.com/v4/cpu/search?q=q6600

SD820/821 (Kryo):
https://browser.primatelabs.com/v4/cpu/search?utf8=%E2%9C%93&q=MSM8996

Как видим, результаты более чем сопоставимы...
Ну, а последнее поколение мобильных процессоров (snapdragon 830/835) явным образом превосходит по производительности моего старичка на Q6600:
https://browser.primatelabs.com/v4/cpu/search?utf8=%E2%9C%93&q=MSM8998

Как-то так...

asail ©   (30.03.17 13:12) [126]

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

> Игорь Шевченко ©   (30.03.17 14:36) [127]
>
> Ты пойми простую вещь - чтобы вычислительная система обладала
> соответствующей мощностью, она должна при одинаковом уровне
> технологии еще большую мощность потреблять. Мне с трудом
> верится, что за последние годы достигут прорыв в технике,
>  который позволяет при меньших затратах на потребление достигнуть
> аналогичных результатов по вычислительной мощности.

В том то и дело, что уровень технологии уже другой.
Q6600 выполнен по 65-нм технологии, а Snapdragon 835 - по 10-нм.
Отсюда и большее потребление при меньшей мощности у первого...
Причем заметь, что Q6600 все еще достаточно мощен на сегодняшний день, мощнее многих low-end современных компов и ноутбуков под виндой. Он вполне сравним, скажем, с i5-4200U...
Еще раз, я понимаю, что самый мощный телефон или планшет на ARM в разы (если не на порядки) уступает самым мощным и современным i7... Но, всем ли нужна такая мощь в быту и для большинства повседневных задач?
И лично для меня, единственная причина, по которой я не отказываюсь от этого самого десктопа на Q6600 - это отсутствие нужного мне софта под мой телефон на андроиде. Причем, мощности этого самого телефона, как видим вполне, хватает для всего этого нужного мне софта...

В догонку...
i7-7700K 4.2GHz имеет TDP 95W
Intel Q6600 2.4GHz имеет TDP 105W
Угадай с трех раз, который из них мощнее? :)

asail ©   (30.03.17 16:19) [128]


> Q6600 выполнен по 65-нм технологии, а Snapdragon 835 - по
> 10-нм.


И чего ? Ты посмотри, сколько рассеивает Q6600 и сколько мобильный процессор (любой).


> Причем, мощности этого самого телефона, как видим вполне,
>  хватает для всего этого нужного мне софта...


Смотря какой софт тебе нужен. Мне например проигрывания музыки и чтения книжек на телефоне вполне хватает тоже, десктопный процессор для этого не нужен.

> И чего ? Ты посмотри, сколько рассеивает Q6600 и сколько
> мобильный процессор (любой).

См. пост [129]. i7-7700K рассеивает меньше (уж точно, не больше), чем Q6600, при этом несоизмеримо мощнее. Так что, ни потребляемая мощность, ни соответственно, рассеиваемое тепло не являются пропорциональными вычислительной мощности, в частном случае...

> Смотря какой софт тебе нужен. Мне например проигрывания
> музыки и чтения книжек на телефоне вполне хватает тоже,
> десктопный процессор для этого не нужен.

Как какой? Весь, что используется на десктопе с тем самым Q6600... И тогда я бы мог вместо двух девайсов использовать всего один!

> в частном случае.

в общем случае... Гы... :)

asail ©   (30.03.17 17:44) [131]


> при этом несоизмеримо мощнее


Э...а почему несоизмеримо-то ? Вполне себе соизмеримо.


> Весь, что используется на десктопе с тем самым Q6600...


Я не знаю, какой ты софт используешь на десктопе, мне трудно судить. То, что я использую, на телефоне/планшете/etc использовать не получится.

И вообще - телефон нужен, чтобы звонить.

> Э...а почему несоизмеримо-то ? Вполне себе соизмеримо.

Это так... Для убедительности... :) Ну, скажем, на порядок... Так правильнее?


> Я не знаю, какой ты софт используешь на десктопе, мне трудно
> судить. То, что я использую, на телефоне/планшете/etc использовать
> не получится.

Например, Дельфи... :)
Почему не получится? Не хватит ресурсов того же Q6600 и обязательно нужен какой-нибудь i7 из последних поколений? Тады да. Но, мне на все хватает и мощности Q6600, а значит, как мы уже выяснили, хватит и мощности телефона на тоже самое...
Ну, а экран, мышь, клавиатура и прочая переферия, в большинстве случаев, без проблем подключается и к телефону, при наличии соответствующих драйверов...


> И вообще - телефон нужен, чтобы звонить.

Давай так. Как мы выяснили, современный телефон по мощности не уступает тому-же десктопу на Q6600.
Теперь представь, что телепон этот бежит под полноценной Виндоус 10 (не РТ) и для него имеется док-станция с кучей usb 3.0 портов, hdmi и т.д.
А теперь убеди меня в необходимости держать еще и тот самый десктоп на Q6600... :)

> И вообще - телефон нужен, чтобы звонить.


Я тебя, Игорь, разочарую :) На телефонах уже давно-давно не только звонят. Вылазь из прошлого века.
Нам уже доктора всё прожужжали - хотят свои картинки на телефонах смотреть. И смотрят, что характерно :) Веб.

Дмитрий Белькевич ©   (30.03.17 18:38) [135]

Так это понты на самом деле. Ими еще и фотографируют, но я предпочитаю зеркалку.

asail ©   (30.03.17 18:19) [134]


> Как мы выяснили, современный телефон по мощности не уступает
> тому-же десктопу на Q6600.


Это тебе кажется, что ты выяснил и пытаешься меня убедить. Но у тебя не получается :)


> Теперь представь, что телепон этот бежит под полноценной
> Виндоус 10 (не РТ) и для него имеется док-станция с кучей
> usb 3.0 портов, hdmi и т.д.
> А теперь убеди меня в необходимости держать еще и тот самый
> десктоп на Q6600... :)


А теперь представь, что у меня на десктопе скайп, путем которого я тоже могу звонить (и кстати звоню). И зачем мне телефон в таком случае ?

>  Как мы выяснили, современный телефон по мощности не уступает
> тому-же десктопу на Q6600

Мобильные процессоры, даже самые мощные и современные в подметки не годятся десктопным 5 летней давности. Особенности архитектуры.

> Мобильные процессоры, даже самые мощные и современные в
> подметки не годятся десктопным 5 летней давности. Особенности
> архитектуры.

Начем основывается это безапелляционное утверждение? Я вот, выше, привел ссылки на результаты синтетических тестов, говорящих об обратном...
Я понимаю, что при прочих равных (частота, кол-во ядер, размер кэша и т.д.), arm явно уступает. Но при не равных - может быть и наоборот... По тестам, i5-4200U несколько уступает Snapdragon 835...

> А теперь представь, что у меня на десктопе скайп, путем
> которого я тоже могу звонить (и кстати звоню). И зачем мне
> телефон в таком случае ?

Я могу больше представить... У тебя дома вполне может быть и стационарный телефон. Зачем тебе скайп? :)

> А теперь представь, что у меня на десктопе скайп, путем
> которого я тоже могу звонить (и кстати звоню). И зачем мне
> телефон в таком случае ?


Наверное чтобы быть мобильным.


> Где библиотеки для работы с Google Datastore,

Между прочим если кто не знает, есть шикарный набор компонент TMS Cloud Pack http://www.tmssoftware.com/site/tmsfmxcloudpack.asp

Он стоит дофига, но если захотеть...

> Кто б сомневался ©   (30.03.17 21:49) [140]


> > Где библиотеки для работы с Google Datastore,
>
> Между прочим если кто не знает, есть шикарный набор компонент
> TMS Cloud Pack http://www.tmssoftware.com/site/tmsfmxcloudpack.
> asp
>
> Он стоит дофига, но если захотеть...
>
>

http://sourceoddity.com/fi_tms.html
просто оставлю это здесь )

add свои 5 коп
D5/D7 - до сих пор использую
хватает

asail ©   (30.03.17 21:14) [139]


> Я могу больше представить... У тебя дома вполне может быть
> и стационарный телефон. Зачем тебе скайп? :)


Мы отвлеклись. Если ты помнишь, разговор начался с того, что я не понимаю, какие приложения можно использовать одновременно на куче платформ, кроме всяких мелких (типа того же скайпа, кстати).
То, что ты бы использовал, если бы они были, вместо того, что у тебя на ноутбуке - это мечты. Потому что их нет и вряд ли когда-либо появятся, все-таки у мобильных и настольных устройств ниши разные (так же, как и у настольных и мэйнфреймов). Теперь второй вопрос - а почему они не появляются на других платофрмах (давай мак пока оставим в стороне, я не сильно знаю, что там происходит), давай про андроид. Я на своем веку пока не успел увидеть Android Studio на мобильной платформе, да и в википедии про нее пишут, "что доступна для Windows, OS X и Linux".

Кто б сомневался ©   (30.03.17 21:49) [140]


> Наверное чтобы быть мобильным.


Нет, чтобы редко звонить и редко отвечать на звонки. А "быть мобильным" я могу и без телефона, просто гуляя по улице.

> asail ©   (30.03.17 21:14) [138]


> Я вот, выше, привел ссылки на результаты синтетических тестов,
>  говорящих об обратном...

Туфта эти синтетические тесты.
Вот тебе другой тест.
http://cpuboss.com/cpus/Qualcomm-Snapdragon-800-vs-Intel-Core2-Quad-Q6600
Разница в два раза со старичком Q6600. С Corei7 разница в 10 раз.
В реальной жизни разница больше чем в синтетических тестах.

> Туфта эти синтетические тесты.
> Вот тебе другой тест.
> http://cpuboss.com/cpus/Qualcomm-Snapdragon-800-vs-Intel-
> Core2-Quad-Q6600
> Разница в два раза со старичком Q6600. С Corei7 разница
> в 10 раз.
> В реальной жизни разница больше чем в синтетических тестах.
>

Этот тест, как раз, подтверждает то что я писал ранее..  Снап 800 очень старый проц. 835 минимум вдвое быстрее, а значит, как раз, на уровне q6600.
За реальную жизнь судить не возьмусь - не знаю, как проверить. Про i7 говорить не надо, а то я в качестве контраргумента про интел атом напомню... :)

>  835 минимум вдвое быстрее, а значит, как раз, на уровне
> q6600.

А весь остальной обвес в телефоне также на уровне? Боюсь что нет.

> А весь остальной обвес в телефоне также на уровне? Боюсь
> что нет.

Ну, смотря что именно, и под какие задачи... GPU в мобильниках сравнимы со встроенной графикой многих интеловских процев (не всех, разумеется). С дискретными картами, аля GTX1060 им, конечно же, тягаться бессмысленно.
Память, в принципе, та же... У меня, например в телефоне 4GB LDDR4.
Что же касается ЖД... Например, на моем десктопе (все тот же несчастный q6600) стоит WD Black на 1ТБ, а в телефоне 128Гб, считай, SSD... Всяко, в моем конкретном случае, по производительности "диска" телефон впереди... :)
Короче, я к чему это все? Для большинства приложений под винду, мощности телефона вполне может оказаться достаточно. Ясен пень, что не для всего...

> Игорь Шевченко ©   (30.03.17 22:26) [143]
>
> Мы отвлеклись. Если ты помнишь, разговор начался с того,
>  что я не понимаю, какие приложения можно использовать одновременно
> на куче платформ, кроме всяких мелких (типа того же скайпа,
>  кстати).
> То, что ты бы использовал, если бы они были, вместо того,
>  что у тебя на ноутбуке - это мечты. Потому что их нет и
> вряд ли когда-либо появятся, все-таки у мобильных и настольных
> устройств ниши разные (так же, как и у настольных и мэйнфреймов).
>  Теперь второй вопрос - а почему они не появляются на других
> платофрмах (давай мак пока оставим в стороне, я не сильно
> знаю, что там происходит), давай про андроид. Я на своем
> веку пока не успел увидеть Android Studio на мобильной платформе,
>  да и в википедии про нее пишут, "что доступна для Windows,
>  OS X и Linux".

Не совсем отвлеклись... Напомню, что разговор начался с того, что те же приложения (с тем же функционалом) на мобильных устройствах работать не смогут в силу слабой производительности последних. Я же думаю (и пытаюсь аргументировать), что это не совсем так... Для любого приложения, сносно работающего на том же Q6600 или i5-4200U, мощности современных мобильных девайсов вполне достаточно.
И да, Игорь, второй вопрос правильный: почему они не появляются на других платформах? Возможно, потому, что до сих пор нет достаточно успешных средств кросс-платформенной разработки?
И да. Мне мой десктоп на стареньком q6600 нужен, практически, только для работы с D6 (и изредка с D XE7). И если бы, я мог работать с ними на том же телефоне (да с большим монитором и внешними клавиатурой/мышью), то этот десктоп отправился бы на помойку... Со всеми остальными задачами, телефон, вроде, и так справляется (тот же офис и т.д.).

Кстати, недавно МС демонстрировала работу полноценной Windows 10 на мобильном устройстве (планшет на последнем снапдрагоне 835)... Они там и офис и фотошоп полноценный запускали. Может, туда все и скатится в конце концов?

У меня нормально работает на планшете (атом) обычный софт под 8-кой, так - к слову :) Я уже тут вроде писал - неожиданно хорошо работает.

asail ©   (31.03.17 00:51) [149]


> Кстати, недавно МС демонстрировала работу полноценной Windows
> 10 на мобильном устройстве (планшет на последнем снапдрагоне
> 835)... Они там и офис и фотошоп полноценный запускали.
> Может, туда все и скатится в конце концов?


У МС появился фотошоп ? Вот новость.


> Для любого приложения, сносно работающего на том же Q6600
> или i5-4200U, мощности современных мобильных девайсов вполне
> достаточно.


Недостаточно. Было бы достаточно, никто бы не делал сковородки от Intel и AMD, а все бы вставляли мобильные процессоры во все щели. И софт бы для них появился куда быстрее, чем в твоих мечтах. Средство кроссплатформенное есть - это Java.

Дмитрий Белькевич ©   (31.03.17 01:30) [150]


> У меня нормально работает на планшете (атом) обычный софт
> под 8-кой, так - к слову :) Я уже тут вроде писал - неожиданно
> хорошо работает.


У меня 2048 тоже на телефоне с андроидом нормально работает. И даже неожиданно хорошо.

> Игорь Шевченко ©   (31.03.17 10:17) [151]

> У МС появился фотошоп ? Вот новость.

Ага. Надеюсь, они его купили, а не пиратку с торрента скачали...
Вот, кстати видео. Это на какой-то выставке в Китае демонстрировалось, насколько я понял.
https://www.youtube.com/watch?v=A_GlGglbu1U


> Недостаточно. Было бы достаточно, никто бы не делал сковородки
> от Intel и AMD

Игорь, я десять раз уже говорил, что не под все задачи годятся арм. Но под большинство стандартных задач - вполне.


> Средство кроссплатформенное есть - это Java.

И что толку? Весь софт под х86, который ты знаешь, написан на жаве? Так, чтоб легким движением руки, перенести его на другие платформы?
Чем эта жава поможет кокретно нашей компании, имеющий продукт (один из), который писали в течении порядка 20 лет на Дельфи десятки разрабов? Его же переписать придется чуть более, чем полностью! А это десятки человеко-лет... Нереально.
А клиенты хотят и на планшеты... Вот, один из клиентов разорился на несколько сот планшетов HP с Атомами на борту и с виндой 7. А они бешенных денег стоят, причем ни разу не мощнее планшетов под андроид. Но выбора нет... Увы.

asail ©   (31.03.17 12:02) [152]


> Вот, кстати видео. Это на какой-то выставке в Китае демонстрировалось,
>  насколько я понял.
> https://www.youtube.com/watch?v=A_GlGglbu1U


Посмотрел, это как Windows-95 на компьютере с Intel 386 и 4 мегабайтами памяти.
Настолько несмешные аргументы, что даже развивать дискуссию не хочется.

asail ©   (31.03.17 12:02) [152]

В чем я с тобой совершенно согласен - это в том, что для 80% десктопного софта хватает мощности 386-го (первого Pentium) процессора, особенно если с приложений хромовое покрытие счистить :)

> Игорь Шевченко ©   (31.03.17 10:17) [151]
> Средство кроссплатформенное есть - это Java.


Java нет на iOS. А это вторая по популярности мобильная ОС после Android.

> Kerk ©   (02.04.17 15:51) [156]


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

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

https://www.codenameone.com/blog/what-sucks-in-codename-one-how-can-we-fix-it.html

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

Время показало, что переносимость кода между компьютерами и мобилками особо не нужна. Все (C#, Delphi, Java, C++ и многие другие) попробовали. Не получилось.

Есть очень узкая ниша корпоративных приложений, где главное - это дешево и сердито. Ну и энтузиасты конечно, куда без них. Но для массового пользователя, не смотря на огромный выбор кроссплатформенных средств, мобильные приложения продолжают писать на Java под Android и на ObjectiveC/Swift под iOS. Как так получается? Наверно все эти люди дураки?

> Кто б сомневался ©   (02.04.17 20:00) [158]
>
> codenameone лучший из перечисленного списка, судя по отзывам.
> Но там баг на баге, больше проблем.

Ну в Delphi-то нету багов...

Ты кстати задумайся почему Appmethod закрыли, а Delphi нет.

Kerk ©   (02.04.17 20:05) [159]

> Время показало, что переносимость кода между компьютерами
> и мобилками особо не нужна. Все (C#, Delphi, Java, C++ и
> многие другие) попробовали. Не получилось.


Какое еще "время показало"? 10 лет назад не было таких средств вообще.
Ни Xamarin, Apache Cordova, Ionic, Delphi все это появилось 6 - 8 лет назад.


> Не получилось.

Чтобы сделать такой вывод, нужно чтобы прошло лет 15.


> Есть очень узкая ниша корпоративных приложений, где главное
> - это дешево и сердито

Наверное наоборот. Java и С\Swift это дешево. Ну потому что реально это дешевле delphi.


>  продолжают писать на Java под Android и на ObjectiveC/Swift
> под iOS. Как так получается? Наверно все эти люди дураки?
>

Куча наработок (готового CopyPaste кода), легче войти в курс дела.

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

Кто тебе не дает, пиши на чем хочешь. Клиенту на деле пофиг на чем написано, лишь бы результат был ну и желательно с рюшечками, анимацией и чтоб "не сильно" тормозило ("не сильно" - т.к. медленно работать это уже стало нормой для веба).
Все остальное - удобство для разработчика. Для меня один проект, один код для разных ОС это очень удобно и экономно по времени.

> Кто б сомневался ©   (02.04.17 22:01) [161]
>
> Kerk ©   (02.04.17 20:05) [159]
>
> > Время показало, что переносимость кода между компьютерами
> > и мобилками особо не нужна. Все (C#, Delphi, Java, C++ и
> > многие другие) попробовали. Не получилось.
>
> Какое еще "время показало"? 10 лет назад не было таких средств
> вообще.
> Ни Xamarin, Apache Cordova, Ionic, Delphi все это появилось
> 6 - 8 лет назад.

Ну и все это вместе взятое хоть сколько-нибудь заметную часть рынка не отъело. Потрясающий результат для 6-8 лет развития.

> > Не получилось.
>
> Чтобы сделать такой вывод, нужно чтобы прошло лет 15.

Через 15 лет все будут писать для трехмерных голографических очков вживленных в мозг, а для мобильные платформы останутся для дедушек :) Не факт, что Android и iOS вообще будут существовать в сегодняшнем виде через 15 лет. Слишком уж большой срок это.

> > Есть очень узкая ниша корпоративных приложений, где главное
> > - это дешево и сердито
>
> Наверное наоборот. Java и С\Swift это дешево. Ну потому
> что реально это дешевле delphi.

Господа-пиарщики кроссплатформенности, вы между собой как-то согласуйте аргументы. То у вас кроссплатформенность - это дешевле, потому что не надо код по три раза переписывать. То у вас кроссплатформенность - это дороже потому что Java/Swift - это бесплатно, а за делфи платить надо. Так как же все-таки на самом деле? :)

> >  продолжают писать на Java под Android и на ObjectiveC/Swift
> > под iOS. Как так получается? Наверно все эти люди дураки?
>
> Куча наработок (готового CopyPaste кода), легче войти в
> курс дела.

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

Это вот самое-самое слабое место современного Delphi. Отсутствие наработок на новых платформах. Почему? Потому что они никому не нужны. Это не то чтобы плохо, это просто факт. Такая вот особенность сообщества. Всех и так всё устраивает. Вон до сих пор сколько вакансий с Delphi7.

> медленно работать это уже стало нормой для веба
как так.. еще недавно говорили что скрипты опережают натив, а тут на тебе ))

> Это вот самое-самое слабое место современного Delphi. Отсутствие
> наработок на новых платформах. Почему? Потому что они никому
> не нужны.


Потому что мало времени прошло. Постепенно база набирается, люди пишут статьи, отвечают на вопросы.
Но создать ПО для разных ОС на Delphi будет быстрее, чем если создавать его как отдельный проект, на отдельном языке для каждой платформы.

Но создать ПО для разных ОС на Delphi будет быстрее, чем если создавать его как отдельный проект, на отдельном языке для каждой платформы.

контроллер с логикой умного дома например.
чтоб и на win-pc, роутере или orange/banana/rasp etc

> Кто б сомневался ©   (03.04.17 08:52) [164]


> Но создать ПО для разных ОС на Delphi будет быстрее, чем
> если создавать его как отдельный проект, на отдельном языке
> для каждой платформы.

так с этим никто не спорит, даже наоборот.
весь вопрос в том, что когда ПО (точнее сервис, частью которого является мобильное ПО) становится известным и мейнстримовым, возможностей кроссплатформенных инструментов начинает не хватать.
к тому же, любой кроссплатформенный инструмент будет всегда заведомо в оппозиции к разработчику платформы. Java - ярчайший тому пример. Не будь корпоративной политики - это было бы, уже давно, идеальное кроссплатформенное средство.

> Eraser ©   (03.04.17 09:01) [166]


> к тому же, любой кроссплатформенный инструмент будет всегда
> заведомо в оппозиции к разработчику платформы. Java - ярчайший
> тому пример. Не будь корпоративной политики - это было бы,
>  уже давно, идеальное кроссплатформенное средство.

а что мы имеем сейчас? даже FF скоро запретит запуск Java аплетов, Хром уже давно запретил. ibank2, к примеру, переписали все на html5. для такого типа ПО это даже хорошо, но если ПО требуется более тесное взаимодействие с системой - тут никакой html не поможет.

но если ПО требуется более тесное взаимодействие с системой - тут никакой html не поможет.

а зачем хтмлу самому тесно взаимодействовать с системой?

>  Кто б сомневался ©   (03.04.17 08:52) [164]
>
> > Это вот самое-самое слабое место современного Delphi. Отсутствие
> > наработок на новых платформах. Почему? Потому что они никому
> > не нужны.
>
> Потому что мало времени прошло. Постепенно база набирается,
>  люди пишут статьи, отвечают на вопросы.

Нормально времени прошло.

Первая версия Delphi вышла в 1995 году. Прошло 5 лет. К 2000 году была развита огромная экосистема. Компоненты, библиотеки, статьи, книги, форумы. Жизнь хлестала через край.

Такая фирма как DevExpress, к слову, была основана в 1998 году. Через 3 года после появления Delphi из ниоткуда. А сейчас они FMX даже трогать не хотят.

Google Cloud Platform открыта в 2011 году. С тех пор на NodeJS написана вся необходимая инфраструктура, бери и пользуйся. Для Delphi не сделано ничего, кроме пары платных библиотек, даже и близко не покрывающих всего спектра потребностей.

И это не проблема Delphi как средства разработки, всё это можно на Delphi написать при необходимости. Это особенность сообщества, которому всё это не нужно.

> контроллер с логикой умного дома например.
> чтоб и на win-pc, роутере или orange/banana/rasp etc


Вполне. На том же Лазаре уже реализуемо.

Мы как раз несколько программ хотим утащить под оранж. У Романа, вероятно, софт, в основном, 'интерфейсный'. У нас же программы на 70-80% состоят из неинтерфейсных библиотек и от кросс-платформенных инструментов у нас огромный выигрыш. Делфи + лазарус отлично подходят. Безусловно, инструменты неидеальные. Но где вы видели золотую пулю? Плюсы? Жава? Переписывать всю пачку библиотек на кучу платформ? Чего ради?


> Через 15 лет все будут писать для трехмерных голографических
> очков вживленных в мозг, а для мобильные платформы останутся
> для дедушек :)


Всё равно это гуй. А все обвязончные либы никуда не денутся. Будут такие интерфейсы - будем под них писать, пофиг.

Вполне. На том же Лазаре уже реализуемо.

да ктож сказал-то что нереализуемо.
вопрос был про секундомер.

сколько часов на скриптах и сколько дней на лазаре.

Переписывать всю пачку библиотек на кучу платформ? Чего ради?

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

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

> ibank2, к примеру, переписали все на html5


У нас веб - обязательно без флеша (который уже почти выпилили), без жавы, без ActiveX. Только HTML + JS. HTML5 + WebGL.


> но если ПО требуется более тесное взаимодействие с системой
> - тут никакой html не поможет


Уже тоже не совсем верно :) Вспоминая WebGL. Хотя, конечно, веб очень сильно ограничен браузерной песочницей. До того же клипбоарда нельзя добраться, какое тут нафиг железо :)

> от нее надо просто отказаться и пользоваться другими кучами
> которые на тех платформах уже есть.


Видишь ли, ключевые библиотеки должны быть свои. Чужие подходят мало. Господа, вот не нужно нас учить бизнесу, хорошо? :)

> ну какую кучу? которую вы налабали за десять лет усевшись
> на делфи?
> так ее не надо переписывать под сто платформ.
> от нее надо просто отказаться и пользоваться другими кучами
> которые на тех платформах уже есть.


Детский сад и десткий лепет.

Видишь ли, ключевые библиотеки должны быть свои. Чужие подходят мало. Господа, вот не нужно нас учить бизнесу, хорошо? :)

это детский сад и детский лепет.

вот это вот оно и есть

Переписывать всю пачку библиотек на кучу платформ? Чего ради?

на деле лень и нежелание отрываться от привычного иде,
а на словах "ключивые библиатеки должны быть сваи, мыж бизьнесьмены емае"

Угу, посоветуй еще майкрософту отказаться от TCP/IP стёка.

ты еще скажи что аякс с вебсокетами у вас свой колхозный плюс дом с джейсоном теплый и ламповый

Аякс с веб-сокетами не являются для нас ключевыми. Как и джесон-библиотеки.

да я уже понял что ключевой у вас кнопачки с глификами

> Дмитрий Белькевич ©   (03.04.17 09:32) [170]
>
> У Романа, вероятно, софт, в основном, 'интерфейсный'. У
> нас же программы на 70-80% состоят из неинтерфейсных библиотек
> и от кросс-платформенных инструментов у нас огромный выигрыш.

Да бог с ними с интерфейсами, я на протяжении всей ветки говорю, что инфраструктура для работы с БД и сетью в Delphi остановилась в развитии году в 2005м. В лучшем случае.

Её конечно можно написать. Но что-то никто не пишет. Мы тоже не хотим становиться первыми и тратить кучу времени, т.к. у других средств программирования есть уже всё готовое, сопровождаемое большим сообществом, и даже бесплатное.

А вы мне все интерфейсы-интерфейсы.

Но что-то никто не пишет.

дык все D заняты сопряжением клавы на планшете с микрософт вордом на писи

http://pda.delphimaster.net/?id=1491028473&n=18

> Первая версия Delphi вышла в 1995 году. Прошло 5 лет. К
> 2000 году была развита огромная экосистема. Компоненты,
> библиотеки, статьи, книги, форумы. Жизнь хлестала через
> край.


Ты бы видел, что творилось в 1996-м году...

в 96-м прокатилась волна самоубийств клиппера, фокспро, клариона .....

> , я на протяжении всей ветки говорю, что инфраструктура
> для работы с БД и сетью в Delphi остановилась в развитии
> году в 2005м


А как же мультиплатформенный FireDac? Там много чего есть.
Indy продолжает развиваться, появилась библиотека System.net .

> да я уже понял что ключевой у вас кнопачки с глификами


Сетевые и файловые DICOM библиотеки самые критичные. Хотя не только они. В мире пяток реализаций. Одна - наша.
Кнопачки с глифками мы уже третий набор сторонних меняем. Скорее всего не последний :)


> что инфраструктура для работы с БД


А что-то принципиально новое появилось в БД с 2005-го года? Появился NoSQL? Он всем нужен и всем подходит?

В мире пяток реализаций.

не потому что это сложно, но потому что узкоспециализированная вещь.

и уж точно это не то, чего нельзя было бы накатать на любом другом языке.

> у других средств программирования есть уже всё готовое,
> сопровождаемое большим сообществом, и даже бесплатное


Я, Роман, тебя разочарую. Не бывает в нашем мире ничего бесплатного. И, так или иначе, придётся, рано или поздно, чем-то заплатить. Закроет гугл через какое-то время доступ к бесплатным ресурсам, как уже это не однократно делал. А у тебя вся инфраструктура на него завязана. Или, вообще, запретит использовать в очередном 'Гондурасе'. По тем либо иным интересным причинам. И поминай как звали.

> Кто б сомневался ©   (03.04.17 10:36) [186]
>
> А как же мультиплатформенный FireDac? Там много чего есть.

Там нет практически ничего, что появилось в мире БД последние 10-15 лет. Из всего обилия современных nosql кое-как поддерживается только MongoDB. С облаками дела тоже не лучше.

Indy я вообще не хочу обсуждать. Это ужас летящий на крыльях ночи. Много копался в его коде в течении прошедшего года.

> Дмитрий Белькевич ©   (03.04.17 10:40) [187]
>
> Появился NoSQL? Он всем нужен и всем подходит?

Kerk ©   (02.04.17 22:36) [162]
Такая вот особенность сообщества. Всех и так всё устраивает.

Kerk ©   (03.04.17 09:21) [169]
Это особенность сообщества, которому всё это не нужно.

Не вынуждай повторяться :))

> Дмитрий Белькевич ©   (03.04.17 10:53) [189]

А причем здесь гугл? Сервисы гугла и так платные. А вот библиотеки, фреймворки, API для работы с ними - это совсем другой вопрос. Чтобы начать работать с Google Cloud PubSub на Delphi мне придется убить много часов на написание оберток API. Чтобы начать работать с Google Cloud PubSub на других языках, мне понадобится три минуты на скачивание.

И дело совсем не в том, что на делфи нельзя этого написать. А в том, что как ты сам заметил "он не всем нужен и не всем подходит". И так уж получилось, что в дельфовом сообществе в основном не нужен и не подходит. Это не то, чтобы плохо, это просто жизненный факт.

> тобы начать работать с Google Cloud PubSub на Delphi мне
> придется убить много часов на написание оберток API.


Да, но кроме первого проекта, тебе ведь придется убивать много времени на написание точно такого же проекта на другой ОС, плюс время которое затратится на поиск информации ведь там все по другому.
Плюс еще время на написание точно такого же третьего проекта для следующей ОС,  плюс время которое затратится на поиск информации ведь там все по другому.

Плюс время на написание точно такого же четвертого проекта для следующей ОС,
плюс время которое затратится на поиск информации ведь там все по другому.

Как с этим быть?

Кто б сомневался ©   (03.04.17 11:09) [192]


> Как с этим быть?


1. Тратить время.
2. Писать на Java :)

Как с этим быть?

проснуться и вспомнить что есть скриптовые средства?

> 2. Писать на Java :)


Но Java нет на iOS, третий раз уже повторяю.


> rrrrr ©   (03.04.17 11:12) [194]
>
> проснуться и вспомнить что есть скриптовые средства?

И что можно что-то серьезно написать на скриптовых средствах?
Например андроид сервис, который в фоне что-то делает, плюс имеет гуи который показывает карту с текущими координатами и отображает веббраузер.
Желательно это и под iOS (там правда без сервисов).

> Кто б сомневался ©   (03.04.17 11:09) [192]
>
> > тобы начать работать с Google Cloud PubSub на Delphi мне
> > придется убить много часов на написание оберток API.
>
> Да, но кроме первого проекта, тебе ведь придется убивать
> много времени на написание точно такого же проекта на другой
> ОС, плюс время которое затратится на поиск информации ведь
> там все по другому.

Не придется. Кроссплатформенный сервер вот как-то нафиг не сдался. А конечному пользователю прямой доступ к внутренностям системы не нужен и даже вреден.

И что можно что-то серьезно написать на скриптовых средствах?

и в чем проблема?

вот рядом крутится демон на lua на роутере. и не пыхтит.

вот чуть подальше сидит нода распределенного доступа к sql данным. ты допустим сейчас с какого-нибудь вайфай утюга в нативном синтаксисе оракла юзаешь sql сервер в другом полушарии даже не имея oci локально

месяц назад нормализованы адресные данные у полмульта людей с помощью веба и vbs

продолжать?

> Кроссплатформенный сервер вот как-то нафиг не сдался.


А вот нам как раз такие нужны :) Точнее - не нам, а покупателям.

плюс имеет гуи который показывает карту с текущими координатами и отображает веббраузер.

лет 8 назад наши автобусники поставили gps и стали публиковать карту движения.
но юзеру нужно было ставить гугло ёф (не мапс, а именно глобус)

я взял домашний нас с пхп и нарисовал тоже самое но для браузера (пхп + js + leaflet) по их же данным из кмз который они выкладывали раз в минуту кудато на юкоз.

что не так со скриптами?

> Не придется. Кроссплатформенный сервер вот как-то нафиг
> не сдался


То есть клиенты на телефонах - это, фактически, гуй сервера? И я был прав, что клиент на 80% состоит из гуя?

Что плохо с вебом, так это работа с периферией.
Например что то напечатать как надо, а не как возможно, становится большой проблемой.
А все разговоры про медленость, скрипты и т.п. ерунда.

Плохо в вебе - это куча всевозможных ограничений. Да, становится лучше. Но - так как в чистой ОС не будет никогда. Иначе веб и будет сама ОС. Пока увы. Даже великий и ужасный Гугл пока не осилил.

как надо, а не как возможно, становится большой проблемой.
не такая это уш и проблема.

расскажу вообще смешное.
однажды пришел ко мне начальник ведя под руку D программера.
им нужно было прикрутить "немножко нетакую" печать в дельфи системе.

ps я тогда сидел без Д на скриптах.

> Дмитрий Белькевич ©   (03.04.17 11:36) [200]
>
> То есть клиенты на телефонах - это, фактически, гуй сервера?
>  И я был прав, что клиент на 80% состоит из гуя?

Ну да. Как и большинство других клиентов на телефонах :)

Редактирование профайла, история действий, карта, кнопка "действие", чатик. Ну и все. Хватит. Все сложное пусть делает сервер.

Вот тут можно скриншоты посмотреть, если интересно https://play.google.com/store/apps/details?id=no.urbaninfrastructure.bysykkel

Тонкость клиента очень хорошо способствует кроссплатформенности.

> ухты ©   (03.04.17 11:43) [201]
>
> Что плохо с вебом, так это работа с периферией.
> Например что то напечатать как надо, а не как возможно,
> становится большой проблемой.

Экспорт в PDF в вебе как-то иначе работает разве?

Не, веб конечно имеет очень ограниченный доступ к ресурсам компьютера. Но часто ли он на самом деле нужен этот доступ?

Кто б сомневался ©   (03.04.17 11:23) [195]


> Но Java нет на iOS, третий раз уже повторяю.


Выброси iOS и перестань повторять.

> Выброси iOS и перестань повторять.
>


Идеальный мир Игоря испортили :)

Так вроде упоминались уже варианты работы с Java на iOS. Но там баги, не то что в делфи :)

ява не жилец

> Но там баги, не то что в делфи :)

Но в Delphi нет каких то критических багов, которые не дают делать проект, это в основном мелкие баги, а в CodenameOne есть причем они разнообразные, почитайте по той ссылке.

> Экспорт в PDF в вебе как-то иначе работает разве?
работает он одинаково., только этого мало. печать разная бывает, и девайсы тоже, иногда нужна тонкая настройка, и это часть все-таки клиента
к примеру, в свое время микрософт не просто так выпустил RSClientPrint активикс, для своего репортера, не смотря на то что уже давно был пдф


> Но часто ли он на самом деле нужен этот доступ?
не часто, многое можно обойти на сервере, но когда надо, то тут уже никуда

> Kerk ©   (03.04.17 11:52) [205]
> Не, веб конечно имеет очень ограниченный доступ к ресурсам
> компьютера. Но часто ли он на самом деле нужен этот доступ?
>


Тут Eraser говорил обратное недавно:


> Eraser ©   (03.04.17 09:01) [166]
>
> > Кто б сомневался ©   (03.04.17 08:52) [164]
>
>
> > Но создать ПО для разных ОС на Delphi будет быстрее, чем
>
> > если создавать его как отдельный проект, на отдельном
> языке
> > для каждой платформы.
>
> так с этим никто не спорит, даже наоборот.
> весь вопрос в том, что когда ПО (точнее сервис, частью которого
> является мобильное ПО) становится известным и мейнстримовым,
>  возможностей кроссплатформенных инструментов начинает не
> хватать.


А у веба ведь еще больше ограничений. Плюс тоже баги причем разные на разных платформах и от версии к версии.

Ладно, с религиозными людьми я не спорю. В мире без тонких клиентов, веба, nosql и всей прочей чепухи тоже наверно жить не так уж и плохо.

Ну, Роман, поищи серебряную пулю там. Расскажешь :)

> Плюс тоже баги причем разные на разных платформах и от версии
> к версии.


Плюс от браузеру к браузеру. От версии браузера к версии. Мало глюков системы, языка, еще глюки прослоек добавляются.

Ну и Цукерберга можно вспомнить "Марк Цукерберг: самая большая ошибка Facebook — выбор HTML5".

Нет, я не отговариваю от веба. И мы, в конце концов его активно используем и достаточно успешно продаём. Но сказать, что бы от этого получали большое удовольствие - то нет.

> Дмитрий Белькевич ©   (03.04.17 15:23) [216]
>
> Ну и Цукерберга можно вспомнить "Марк Цукерберг: самая большая
> ошибка Facebook — выбор HTML5".

На что же Цукерберг в итоге променял HTML5 на мобилках? Неужто на суперкроссплатформенное средство вроде Delphi или Xamarin? Поведай :)

По кругу ходим. Я хоть раз сказал, что HTML5 на мобилках лучше родных приложений? Ну так и к чему тогда этот аргумент?

Одно дело если апликация не требует инета или просто сети.
В противном случае о веб версии задуматься надо как минимум.

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


> Неужто на суперкроссплатформенное средство вроде Delphi
> или Xamarin? Поведай :)


Вот что Эмбе в своё время нужно было сделать, или Идере сейчас - договорится с кем-то типа Цукербера, а, возможно, и с ним самим, сделать клиенты на Делфи. Их дело, конечно. Но, думаю, рекламы была бы более чем хорошей.
Впрочем, с продажаниками Делфе всегда не везло.

> Дмитрий Белькевич ©   (03.04.17 18:44) [219]
>
> Задуматься также стоит и о том, что довольно много сайтов,
>  когда к ним заходишь в браузере, рекомендуют установить
> свои нативно-платформенные клиенты.

А есть сайты предлагающие установить нативный клиент под винду? Покажи парочку :)

> Вот что Эмбе в своё время нужно было сделать, или Идере
> сейчас - договорится с кем-то типа Цукербера, а, возможно,
>  и с ним самим, сделать клиенты на Делфи.

А Цукербергу это нафига?

> Впрочем, с продажаниками Делфе всегда не везло.

А кому повезло? Какое из кроссплатформенных средств в итоге заняло на мобилках какую-то заметную нишу?

> Kerk ©   (03.04.17 18:47) [220]

> А есть сайты предлагающие установить нативный клиент под
> винду? Покажи парочку :)


Все мессенджеры - WhatsApp, Skype, Viber, и тот же FaceBook и многие др. имеют и под веб и под винду и под Android и под iOS. Хотя казалось бы...

Предлагают поставить по разного рода причинам.
Например нельзя на 1 странице в разных фреймах держать 2 разных сайты (если они не твои, в общем), а простой десктоп это решает. И еще всяко разно.
Т.о. не всегда то что есть предложение это из-за того что сам по себе вет весь из себя фиговый, тормозной, скриптовый и  без рюшек.. Вот ограничения, впрочем не всегда на наш взгляд адекватные, приводят к таким последствиям.

> Кто б сомневался ©   (03.04.17 18:56) [221]

Убедил:))) Если буду писать чатик, сделаю клиент под винду тоже.

Но никто из них представляя клиенты под все платформы, не используют суперкрутые кроссплатформенные средства разработки? Дурачки?

> ухты ©   (03.04.17 18:58) [222]

Ну вот например у этого сайта раньше был отдельный виндовый клиент. Но время в итоге все решило само.

> Kerk ©   (03.04.17 18:58) [223]


Откуда ты знаешь что они используют? Ты ж не проверял, они не афишировали. Работает да и ладно.
FaceBook на Android занимает больше 200 мб. на диске и в RAM начиная от 80 мб, иногда отжирает и больше 200 мб, вполне возможно что это подчерк Xamarin, он более прожорливый. Delphi между прочим не такая прожорливая на Андроид как Xamarin.
Думаешь там кто то выбирал что да как, - дали объяву, наняли индуса он им и наклепал. Работают ну и все.

Оказывается FaceBook использует ReactNative на JS .
Вот вам плохой пример веба, который неслабо отжирает ресурсов  и тормозит.

Дмитрий Белькевич ©   (03.04.17 18:44) [219]


> Задуматься также стоит и о том, что довольно много сайтов,
>  когда к ним заходишь в браузере, рекомендуют установить
> свои нативно-платформенные клиенты. Наверно ведь они так
> просто это делают? :)


Клиентов привлекают, я считаю. Нет ?

> Кто б сомневался ©   (03.04.17 20:21) [225]
> Думаешь там кто то выбирал что да как, - дали объяву, наняли
> индуса он им и наклепал. Работают ну и все.

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

Хотел еще попросить ссылку на эти суперкроссплатформенные приложения на делфи/xamarin, которые в течение всей ветки рекламируются, но это будет удар ниже пояса.

Роман, Делфи дал для тебя всё, что смог. Ты для него - тоже. Расти дальше :) Ну а мы, пока, по-старинке, продолжаем развлекаться.

> я пожалуй закончу. Тем более я все равно устал


Я устал, я мухожук?
Потом расскажи как-нибудь, сводки js с полей. А хотя судя по обсуждению ты и с FMX не работал под мультиплатформами, так что и сравнить не сможешь..

Kerk ©   (03.04.17 22:31) [228]

Кто хочет тот выкладывает сюда :
http://fire-monkey.ru/forum/18-приложения-написанные-с-использованием-firemonkey/

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

Кто б сомневался ©   (04.04.17 09:04) [230]


> А хотя судя по обсуждению ты и с FMX не работал под мультиплатформами


Дружный смех в зале :)


> Кто хочет тот выкладывает сюда :


Ты сразу на свои приложения дай ссылку ?

> Ты сразу на свои приложения дай ссылку ?


За почти год работы с FMX конкретно для Android\iOS я сделал 3 программы все они не публичные, для одной автомастерской - SMS планировщик - для авто рассылки смс, Рация для обслуживание клиента удаленно, с возможностью фото и видео фиксации поломки, и прога для гостиницы для внутренних нужд.

> Кто б сомневался ©   (04.04.17 09:04) [230]
> Я устал, я мухожук?

Именно.

Вот тут кстати можно ознакомиться с переписью дураков

https://stackoverflow.com/insights/survey/2017/#technology-programming-languages
https://stackoverflow.com/insights/survey/2017/#technology-frameworks-libraries-and-other-technologies


> Потом расскажи как-нибудь, сводки js с полей.

За мной не заржавеет :)
Я уже прямо сейчас могу рассказать про JS много гадостей. Но толку-то, если не смотря на эти гадости на JS есть все возможные библиотеки/фреймворки/инфраструктура? Не я такой, жизнь такая.

Было бы удивительно, если было бы по-другому:

https://stackoverflow.com/insights/survey/2017/#developer-roles

Больше 70% тусующихся на стэке - Web developer.

По опросам в интернете интернет используют 100% пользователей :)))

> Kerk ©   (04.04.17 11:35) [233]
> Вот тут кстати можно ознакомиться с переписью дураков


Ну это ты себя успокаиваешь.
Я уже зарабатываю на Delphi FMX, притом клиентов хватает - т.к. 4 оси, и гораздо дешевле -  т.к. сразу бонусом идет iOS (если это конечно не какая то специфическая задача) чем если клиент будет заказывать у других отдельно для Android и для IOS.

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

А ты можешь смотреть на графики и самоудовлетворяться от вида того, что фреймворк который ты используешь для создания программ на первом месте в этом графике.

Кто б сомневался ©   (04.04.17 12:34) [236]


> Я уже зарабатываю на Delphi FMX


Некоторые ассенизацией занимаются, тоже полезное занятие.


> все итак работает, быстро и стабильно.


да-да.


> наняли индуса он им и наклепал. Работают ну и все.

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

так вот они тоже когда-то давно говорили что мол если фокс прикроют, то по бырому выучим дельфи. а пока же денежка капает....

rrrrr, не завидуй.

кому конкретно-то?
вижу здесь двух мальчиков, и у обоих комплекс на тему "а мы тоже погромисты"

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

> кому конкретно-то?


Всем по чуть-чуть :)


> охренеть бином ньютона


Есть немного :)

Для информации. У нас лицуха самой дешевой программы стоит около 1000$. Обычной - порядка 3 кб. Сервера - от 10 кб. Порядка 60-70% (кроме купленных библиотек) кода в проектах моего. Самый крупный проект, вместе с либами, занимает больше миллиона строк. Проектам 15+ лет.

ну в общем я не ошибся.

Удалено модератором
Примечание: Выражения выбираем, не в пивной

В общем, я тоже :)

вы двое со стороны выглядите примерно так:

вчерашняя школота, волею случая попавшая в некую ситуацию, говорит :не учите нас вести бизнец, у меня миллион строк.

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

Удалено модератором

Я совладелец, если что :)

> Проектам 15+ лет.
https://www.youtube.com/watch?v=i8SHQT8HN30

Меняемся каждодневно, можешь спать спокойно. :) Winmerge посмотришь иногда на модули по 10 тысяч строк - красным красно, в пределах одной под - версии. С нашим конкурентами особенно не поскучаешь )))

К слову - скриптовики - затейники, нужна консультация. В андроидах существует что-то наподобие батников винды? Или какие-либо другие консольные текстовые скрипты?
Нужно файлы из папки перекачать на фтп телефоном. На винде это я делаю батником.

Файлы уже лежат на телефоне, если что. 'Ходить' за ними никуда не нужно.

Я не пробовал, но там же по идее линукс.
По запросу "android sh script example" гугл дает варианты.

Спасибо, Роман, гляну. Если кто еще знает что - пишите.

> Нужно файлы из папки перекачать на фтп телефоном. На винде
> это я делаю батником

Можно залить их на облако, напр. dropbox стандартными средствами.

Нужно именно на фтп (на свой). Программа для заливки у меня есть (AndFTP отлично справляется), но нужно делать это автоматически.

Купил AndFTP, он это, похоже, умеет делать сам (синхронизация). Пока, правда, ничего от него не добился, пинаю саппорт.

По поводу интерфейса, хорошо написано:

"Немного про ГУЙ.

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

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

http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1254731&msg=20357924

Если единственное, что отличает вас от конкурентов - это красота и фейд кнопок, то, думаю, что ваш продукт - коммерческий труп.

> Дмитрий Белькевич ©   (06.04.17 00:19) [257]


Сколько он стоит? Если он не умеет такое делать (запускаться и синхронизировать по времени), появилась идея сделать такое под Android и iOS.

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

Коммандной строки достаточно для всего. Продукт, которому нужен графический интерфейс, коммерчески мертв.

Поражаешься иногда людям. 14 страниц разговаривать и не вынести из постов оппонентов НИЧЕГО? Ну ладно не соглашаться, но понять-то хотя бы чуточку можно... капец.

Рома, не нервничай так :) Всё мы уже поняли. Удобнее писать под JS - флаг, как говорится, в руки и барабан на шею :)
Я бы вообще так не делал, а поднимал бы свою инфраструктуру. Что мы у себя, например, и делаем, и не космос это всё стоит. Ну да ладно, вы уже себе выбрали решение - занимайтесь.

p.s. Разобрался я с синхронизацией всё таки :)

> Коммандной строки достаточно для всего. Продукт, которому
> нужен графический интерфейс, коммерчески мертв.


Марксизм не догма, а руководство к действию. Зачем-то в винду Powershell встроили.

> Продукт, которому нужен графический интерфейс, коммерчески
> мертв


Ты это MS'офту расскажи :)))

> Дмитрий Белькевич ©   (06.04.17 11:57) [262]
>
> Рома, не нервничай так :) Всё мы уже поняли. Удобнее писать
> под JS - флаг, как говорится, в руки и барабан на шею :)

Вы мне 14 страниц рассказывали про то, какие в FMX крутые стили, эффекты и прочая шелуха, совершенно игнорируя тот факт, что мне эти ваши бантики нафиг не сдались. чтобы этим вот закончить? Ну ладно. Пусть так.

> Дмитрий Белькевич ©   (06.04.17 12:24) [264]
>
> > Продукт, которому нужен графический интерфейс, коммерчески
> > мертв
>
> Ты это MS'офту расскажи :)))

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

> Я бы вообще так не делал, а поднимал бы свою инфраструктуру.
>  Что мы у себя, например, и делаем, и не космос это всё
> стоит. Ну да ладно, вы уже себе выбрали решение - занимайтесь.

В 2003 году все так делали. В 2017м году больше волнует стоимость масштабирования. Поднять сотню новых серверов? Пара команд в консоли и готово. Или даже держать приложения в контейнерах, чтобы абстрагироваться от серверов совсем. Или вообще использовать serverless-функции. А ведь можно не только расти, но и уменьшаться при необходимости, то есть платить только за те ресурсы, которые реально нужны. И все это без толпы сисадминов и DBA в галстуках.

> Вы мне 14 страниц рассказывали про то, какие в FMX крутые
> стили, эффекты и прочая шелуха, совершенно игнорируя тот
> факт, что мне эти ваши бантики нафиг не сдались.


Угу. А это я, конечно всё понаписал :)


> Дьявол кроется в мелочах.
>
> Вот простейший пример. Обычная кнопка. В FMX и VCL. Видишь
> разницу?
>
> http://yankovsky.me/fmx-button.gif
> http://yankovsky.me/vcl-button.gif
>
> Я даже не буду приводить в пример какие-то баги. Достаточно
> таких вот неуловимых мелочей, которые отличают родное приложение
> от стилизации под родное приложение.



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



> Кроссплатформенность - это хорошо. Но это всегда компромисс.
>  Никогда не будет кроссплатформенное приложение работать
> как родное. И тут не в Delphi дело.

> В 2003 году все так делали. В 2017м году больше волнует
> стоимость масштабирования.


Хорошо, не буду судить о твоём случае, не зная точно задачу.

> Продукт, которому нужен графический интерфейс, коммерчески
> мертв.


Во первых почему это звучит как аксиома?
Вот уже лет 25 вокруг куча противоположных примеров, начиная с самой Windows и всяких WYSIWYG средств разработки.

Во вторых про графику мы начали говорить с твоей подачи. ¯\_(ツ)_/¯
Я акцентировал внимание на другом, - на том что с Delphi можно сделать один проект, один код и один GUI для 4 платформ. А это экономно в плане времени, да и удобства. Да чего-то там не хватает, но и это можно найти или купить в виде компонент.
Я говорил про разработку самых обычных программ для мобильных и Desktop устройств для пользователей. Не про разработку чего-то в северной части.

> Кто б сомневался ©   (06.04.17 15:17) [268]
>
> Я акцентировал внимание на другом, - на том что с Delphi
> можно сделать один проект, один код и один GUI для 4 платформ.


Всё-таки создание интерфейса для Windows и создание интерфейса для мобильных ОС - не одно и тоже

Для этого под мобильные ОС и под Windows пишутся разные интерфейсы. У нас (да я думаю, у большинства так) и веб-клиент выглядит совершенно по-разному.
FMX, насколько я знаю, специально под это заточен.

> Belkin ©   (06.04.17 18:37) [269]
> Всё-таки создание интерфейса для Windows и создание интерфейса
> для мобильных ОС - не одно и тоже


Если сделать унифицированный интерфейс, как например Comodo Firewall или Antivirus  в стиле мобильного планшета - то это вполне возможно.
А так одно GUI для Windows - MacOS, другое для Android-iOS.

Кто б сомневался ©   (06.04.17 22:59) [271]

Тем более что современный Windows Metro это и есть планшетный, мобильный стиль GUI - разница с мобильными версиями небольшая.

Когда я пишу прогу под Windows, то первым делом на главную форму кидаю TMainMenu, тулбар и статусбар. Практически не задумываясь.

А когда пишу под Андроид, то долго думаю, как и с какими компонентами лучше

http://delphimaster.net/view/15-1446991183
както скучно прошлый раз было, хотя вопросы похожие )

> ухты ©   (09.04.17 04:29) [274]

Были люди в наше время... :)

> Kerk ©   (10.04.17 11:14) [275]
>
>
> > ухты ©   (09.04.17 04:29) [274]
>
> Были люди в наше время... :)


Так наоборот, он имеет в виду, что сейчас активнее

> Кто б сомневался ©   (30.03.17 13:04) [125]
>
> > т.е. есть пустая форма, нужно перехватывать событие OnKeyDown
>
>
> Перехватываю OnKeyUp на Android - вроде не замечал проблем.
> . Все стандартно.

Добрался до дома и до андроидофона, соответственно. Протестировал - ожидаемо, ничего не перехватывается. Тестировал на последнем Берлине.

Вот такой нехитрый код


unit Unit1;

interface

uses
 System.SysUtils, System.Types, System.UITypes, System.Classes,
 System.Variants,
 FMX.Types, FMX.Controls, FMX.Forms, FMX.Graphics, FMX.Dialogs,
 FMX.Controls.Presentation, FMX.StdCtrls, FMX.VirtualKeyboard,
 FMX.Platform;

type
 TForm1 = class(TForm)
   Button1: TButton;
   procedure Button1Click(Sender: TObject);
   procedure FormKeyDown(Sender: TObject; var Key: Word; var KeyChar: Char;
     Shift: TShiftState);
   procedure FormKeyUp(Sender: TObject; var Key: Word; var KeyChar: Char;
     Shift: TShiftState);
 private
   { Private declarations }
 public
   { Public declarations }
 end;

var
 Form1: TForm1;

implementation

{$R *.fmx}

procedure TForm1.Button1Click(Sender: TObject);
var
 Keyboard: IFMXVirtualKeyboardService;
begin
 Keyboard := TPlatformServices.Current.GetPlatformService(IFMXVirtualKeyboardService) as IFMXVirtualKeyboardService;
 Keyboard.ShowVirtualKeyboard(Self);
end;

procedure TForm1.FormKeyDown(Sender: TObject; var Key: Word; var KeyChar: Char;
 Shift: TShiftState);
begin
 ShowMessage('FormKeyDown');
end;

procedure TForm1.FormKeyUp(Sender: TObject; var Key: Word; var KeyChar: Char;
 Shift: TShiftState);
begin
 ShowMessage('FormKeyUp');
end;

end.

Жмем на Button1 - появляется виртуальная клавиатура.
Клавиши на виртуальной клавиатуре не срабатывают, я бы сильно удивился, если бы начали срабатывать.
Хардверные кнопки, конечно же, срабатывают.

> Kerk ©   (04.04.17 11:35) [233]
>
> Вот тут кстати можно ознакомиться с переписью дураков


А здесь Delphi за прошлый год с 11 места перешла на 9.

https://www.tiobe.com/tiobe-index/


> Eraser ©   (10.04.17 21:46) [277]


Я только хардверные кнопки ловил, не в курсе это проблемы.

Почитал, это проблема Android и это описано  мануале, на Java такая же проблема, все точно также - софт кнопки не ловятся, хардверные ловятся:

https://developer.android.com/reference/android/view/KeyEvent.html

As soft input methods can use multiple and inventive ways of inputting text, there is no guarantee that any key press on a soft keyboard will generate a key event: this is left to the IME's discretion, and in fact sending such events is discouraged. You should never rely on receiving KeyEvents for any key on a soft input method. In particular, the default software keyboard will never send any key event to any application targetting Jelly Bean or later, and will only send events for some presses of the delete and return keys to applications targetting Ice Cream Sandwich or earlier.

https://developer.android.com/training/keyboard-input/commands.html#SingleKey

Note: When handling keyboard events with the KeyEvent class and related APIs, you should expect that such keyboard events come only from a hardware keyboard. You should never rely on receiving key events for any key on a soft input method (an on-screen keyboard).

http://stackoverflow.com/questions/11273243/android-get-keyboard-key-press

Кто б сомневался ©   (11.04.17 11:57) [278]


> А здесь Delphi за прошлый год с 11 места перешла на 9.


Ты всерьез считаешь это достижением ? :))

> Игорь Шевченко ©   (11.04.17 12:07) [279]


Нет. Это для тех, кто любит на графики смотреть на разных сайтах.

Достижением я считаю реализацию мультиплатформенного инструмента.

Графики на которых ассемблер, VB, Swift, Perl и ObjectiveC одинаково популярны - это очень серьезно. Аргументация уровня "боженька". Хочешь, я тебе нарисую график, где Delphi на первом месте с отрывом? С удовольствием сделаю тебе приятно :)

> Кто б сомневался ©   (06.04.17 15:17) [268]
>
> > Продукт, которому нужен графический интерфейс, коммерчески
> > мертв.
>
> Во первых почему это звучит как аксиома?

Вот как можно серьезно разговаривать с тобой? Я постебался над [258] очевиднейшим образом. Но что ты, что Дмитрий Белькевич приняли за чистую монету и ввязались в спор. Серьезно??!!

> Во вторых про графику мы начали говорить с твоей подачи.

Вот это как раз то, о чем я писал Диме. Полное нежелание понять о чем речь. Мне эта ваша графика нафиг не нужна. Для меня кнопка - это кнопка. Я всего-лишь хочу не думать о ней и чтобы она была такая же, как у всех. Это ТЫ мне в противовес рассказываешь про крутые стили и фейды. Но мне эти стили нафиг не нужны. Мне нужна обычная кнопка как у всех.

>  один проект, один код и один GUI для 4 платформ

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

Если у тебя конечно не антивирус с попугайским интерфейсом или еще что-то, что входит в 0.00001% софта.

> Дмитрий Белькевич ©   (06.04.17 13:50) [266]
>
> > Вы мне 14 страниц рассказывали про то, какие в FMX крутые
> > стили, эффекты и прочая шелуха, совершенно игнорируя тот
> > факт, что мне эти ваши бантики нафиг не сдались.
>
> Угу. А это я, конечно всё понаписал :)
>
> [поскипано]

Вы Кто б сомневался не братья случайно? Интерфейс органично смотрящийся в соответствующей среде - это по-вашему "бантики" и "графика"? Серьезно?

Видимо, это какая-то сложная и неочевидная мысль.

По графикам то шарпей совсем плох:

https://www.tiobe.com/tiobe-index/csharp/

Глупо, конечно, выбирать по этим графикам что либо.

Уточню свою позицию для Романа. Я не говорил, что качественный интерфейс не нужен. Я говорил о том, что мне пофиг, как выглядят кнопки антивируса, если он отлично выполняет свои функции. Если же он пропускает всё подряд или тормозит всю систему - то никакой fade на кнопках от удаления его не спасёт.
К слову - комод 10-й стал выглядеть еще лучше.

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

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


Во-первых не везде большая часть кода программы это интерфейс. Если интерфейс программы занимает от силы 20-30% (Навител, например) - то выигрыш от мульти-платформенных программ огромный. У нас, например, в серверах интерфейса вообще может не быть. Но они уже, с одним и тем же кодом, работают на windows + linux. Впрочем - гуй сервиса я тоже переписал на LCL + VCL. Нормально работает и собирается в Делфи и Лазаре с одним и тем же кодом и минимально разными формами. Сколько человеко-лет пришлось бы потратить на переписывание на другой язык - сложно представить, я сам справился за приблизительно три месяца.

Во-вторых десктоп + мобил, это почти две платформы. А Windows + MakOS + Linux + Android + iOS + WinMob + эт сетера - это до десяти платформ.

>  Но мне эти стили нафиг не нужны. Мне нужна обычная кнопка
> как у всех.


Ну и как, удается сделать на вебе такую же кнопку, как у всех?


> Если у тебя конечно не антивирус с попугайским интерфейсом
> или еще что-то, что входит в 0.00001% софта.


Как-нибудь посмотри на Windows Defender.
Он тоже в Android стиле. И вообще Комод пытается быть похожим на него.


>
>
> Kerk ©   (11.04.17 13:12) [281]
> Графики на которых ассемблер, VB, Swift, Perl и ObjectiveC
> одинаково популярны - это очень серьезно. Аргументация уровня
> "боженька".
>

Я то причем, на этот ресурс многие ссылаются. Часто его встречал и раньше.
А они пишут что данные берут из статистики поисковиков и популярных сайтов (ютуб). Там над таблицей есть ссылка.

Я уже забыл о чем мы спорим, меня пока устраивает разрабатывать программы способом который предлагает мультиплатформенный Delphi RAD,
тебя не устраивает, ты решил делать мультиплатформенные проекты с помощью веба, в надежде что там будет меньше багов (т.к. инструмент более обкатан) и это займет меньше времени чем с помощью предыдущего способа.

Не знаю что лучше.
Наверное время покажет.

Возможно кому-то форк ноды будет интересен:

https://github.com/BazisSoft/node-delphi

вебсокеты еще:

https://github.com/andremussche/DelphiWebsockets

А вот еще классный сайт

http://www.fmxexpress.com/

> Кто б сомневался ©   (11.04.17 11:57) [278]

я это все читал 2-3 года назад. в итоге пришлось делать копию FMX.VirtualKeyboard.Android.pas и добавлять туда нужный функционал с помощью костылей и подпорок, но работает.

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

с жестами там вообще края крайние, в каждой системе кто во что горазд. в итоге - для каждой ОС своя реализация.

Интересная вещь, вроде бы http://fmxlinux.com/

Eraser ©   (12.04.17 10:58) [292]
Между прочим это разработка Крюкова.
А он атэц-изобретатель FireMonkey. Думаю скоро это будет в стандартном Delphi.

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

Кто б сомневался ©   (13.04.17 18:32) [293]

> Думаю скоро это будет в стандартном Delphi.

С чего бы? Думаешь, эмбаркадера этот проект выкупит?

> Кстати не пойму, почему этот человек не работает в Embarcadero.

Потому что его уволили.

> И вообще кто нибудь в курсе что там происходит, судя по
> реддит там прошла какая то волна увольнений, но инфы нет,
>  дни слухи.

Почти все разработчики Эмбаркадеры занимавшиеся Delphi и её библиотеками уволены. Полностью закрыты офисы в Испании, Питере и еще где-то, не помню. В частности, команды FMX и FireDAC уволены целиком. Внутри компании остался самый минимум. Всю разработку, которую смогли, отдали на аутсорсинг.

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

Кто б сомневался ©   (13.04.17 18:32) [293]

А тебе какая разница, что происходит в Embarcadero ? Delphi они уже не производят и не продают.

Кстати, Крюков "отец" VG-Scene, для исторической справедливости.

Kerk ©   (13.04.17 19:05) [294]


>  я сразу говорил, что все закончится массовыми увольнениями.


Т.е. ты заранее спрогнозировал? А почему?
Может есть какие то интересные ссылки где почитать об этом?

> Кто б сомневался ©   (13.04.17 19:16) [296]
>
> Kerk ©   (13.04.17 19:05) [294]
>
> >  я сразу говорил, что все закончится массовыми увольнениями.
>
> Т.е. ты заранее спрогнозировал? А почему?

Idera - разработчик инструментов для БД. Embarcadero - разработчик инструментов для БД и еще RAD Studio. Idera покупает Embarcader-у. Мне сразу показалось, что Delphi для Idera будет чемоданом без ручки. Выбросить вроде жалко, но тащить тяжело.

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

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

> Может есть какие то интересные ссылки где почитать об этом?

Сейчас не вспомню, если подвернется, сброшу сюда.

https://plus.google.com/u/0/105338484741532774705/posts/SnK5twK939Y

Мда, что то я не пойму логики менеджеров Idera, как можно увольнять ключевого  персонажа.. Крюкова.

https://plus.google.com/u/0/116630640873535683271/posts/GpsiqXzmFdv

So, let's look at the whole picture of the Delphi core development team.
Compiler: Danny Thorpe & Allen Bauer - check.
FMX: Eugene Kryukov & Yaroslav Brovin - check.
FireDAC: Dmitry Arefiev - check.
VCL: ?
I can figure out some pattern and I don't like it.

Хотя я видел код и компоненты которые писал Бровин, и это далеко не лучший код. Баги TMuitiView до сих пор появляются (к примеру сейчас тупо не работает popover режим).
А FMX TimageList - компонент написанный одним из разработчиков из Питера портит через время картинки до сих пор. А добавление обычной картинки в RunTime в TImageList  это целая эпопея из трех списков (Source, Dest и layer списки ).

В общем не знаю.

Ну вот сейчас их заменили на безымянных аутсорсеров, которые FMX раньше никогда не видели, и конечно же все станет лучше :)

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

Это всё, впрочем, не мешает Крюкову продолжать разрабатывать FMX for Linux, Cross VCL и т.п.
Смотрим, что дальше будет.

За деньги.

Плати эмбаркадере за делфи, дэвэкпрессу за devexpress, Крюкову за cross vcl, TMS-у еще за что-нибудь. Потом рассказывай всем как экономишь разрабатывая один проект для 4х платформ :)

> Kerk ©   (13.04.17 20:00) [297]


> Idera - разработчик инструментов для БД. Embarcadero - разработчик
> инструментов для БД и еще RAD Studio. Idera покупает Embarcader-
> у.

тут проблема в том, что Delphi это не Java, а Idera не Oracle.
а время, когда Delphi можно было уйти к топ-компании ушло.

> Потом рассказывай всем как экономишь разрабатывая один проект
> для 4х платформ :)


Всё просто. Программисты дороже.

Средство купили один раз и на, как минимум, несколько лет (некоторые до сих пор на 7-ках сидят). А программисты хотят кушать каждый месяц.

Вот чтоб особо умные не покупали раз в несколько месяцев, эмбаркадеро и остальные придумали годовую подписку :)

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

У Appmethod была хорошая система лицензирования, но он оказался никому не нужным...

Дмитрий Белькевич ©   (14.04.17 00:39) [304]


> Всё просто. Программисты дороже.


Уже не смешно. Сегодня программисту гораздо проще освоить бесплатные средства, ту же Android Studio, а те, кто клепал формы для бухгалтерии на Delphi - ну увы.

Если сам всё пишешь - то может это проще. Самое веселье начинается, когда нужно людей привлекать. Одного - на андроид, другого - под iOS, тетьего - под веб, 4-го - под винду и так далее. И каждый месяц платить зарплату. При том, как правило, немалую и постоянно, пока проект живёт.


> эмбаркадеро и остальные придумали годовую подписку


Как будто среда после года работы перестанет работать :) Мы, вот, на XE6-й до сих пор сидим и не жужжим, хватает.

Самое веселье начинается, когда нужно людей привлекать. Одного - на андроид, другого - под iOS, тетьего - под веб,

а вокруг одни делфисты тучами и ордами роятся......

в чем конкретно веселье-то?

> а вокруг одни делфисты тучами и ордами роятся


Переучиваются за месяц, по опыту.


> в чем конкретно веселье-то?


В зарплате.

делфистам в смысле можно не платить?
или в смысле этот клан с самыми нищебродскими окладами?

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

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


> Особенно на старте новых проектов.


Под перспективные стартапы деньги найти не проблема. Другое дело, что их таких (перспективных стартапов) мало.

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

нехватает миру настоящих мозговитых бизнецменов.

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

> Дмитрий Белькевич ©   (14.04.17 10:45) [309]
>
> > эмбаркадеро и остальные придумали годовую подписку
>
> Как будто среда после года работы перестанет работать :)
> Мы, вот, на XE6-й до сих пор сидим и не жужжим, хватает.

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

Так-то понятно, что даже D7 еще в ходу.

> Дмитрий Белькевич ©   (14.04.17 11:42) [313]
>
> В смысле, что делфисту работы может быть меньше в несколько
> раз, чем всем по отдельности.

Бывает и так. Я где-то выше тут уже писал, что у нас на определенном этапе Delphi проявила себя очень хорошо. Не надо думать, что я тут смерть Delphi предсказываю.

Тут кстати немаловажен еще и рынок труда. Толкового делфиста найти очень сложно. Зато легко можно встретить делфиста, которые не знает зачем дженерики нужны. Распространенность D7 имеет и обратную сторону. Люди сидят на ней 20 лет и за окно не смотрят.

Да-да. не смотрят. ни на дженерики, ни на что-то помимо делфи. как выяснилось, мне делфи не нужна. сишарп полностью удовлетворяет. Алилуйя ))

> Тут надо понять что конкретно мы обсуждаем.


1. Если стартап 'пошёл', то можно и заплатить. А если не идёт - то никакие бесплатные средства не помогут.
2. Политика с исправлениями багов в Эмбе мне категорически не нравится, что есть, то есть.
3. Толкового программиста найти вообще проблема. Если же он толковый на тех же плюсах, то переучится можно достаточно быстро.

> Дмитрий Белькевич ©   (14.04.17 16:04) [319]
>
> > Тут надо понять что конкретно мы обсуждаем.
>
> 1. Если стартап 'пошёл', то можно и заплатить. А если не
> идёт - то никакие бесплатные средства не помогут.

"Пошел" он или нет, ты узнаешь только после релиза. Еще не факт, что после первого. Эти потраченные деньги тебе никто не вернет.

> 3. Толкового программиста найти вообще проблема. Если же
> он толковый на тех же плюсах, то переучится можно достаточно
> быстро.

А ему оно надо? Совсем не тот случай, когда можно поиграться с чем-то новым ради строчки в резюме.

Одно дело, когда компания друзей хочет поработать над каким-то проектом бесплатно в надежде, что оно выстрелит и отобьет все усилия. А другое, когда эта компания друзей прямо на старте должна выложить несколько тысяч долларов на инструменты для разработки.

Тут просто надо быть честным и признать, что в такой ситуации либо берут один из многочисленных бесплатных вариантов, либо делфи со всеми ее сторонними платными библиотеками с торрентов.

Понятно, что есть страны где программист со своей $10 тыс в месяц на основной работе для стартапа может себе позволить выбирать между С++, Java, C# и Delphi. Но в России это обычно выбор между C++, Java, C# и торрентами.

> Если же он толковый на тех же плюсах, то переучится можно
> достаточно быстро.


Спорный вопрос. Я не наблюдал такого процесса.

> kilkennycat ©   (14.04.17 15:28) [318]


> сишарп полностью удовлетворяет.

главный недостаток C# это .NET, как это ни странно звучит.

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

А если стартап легко поместится в веб, то Delphi процентов на 99,99 вообще не будет учавствовать как вариант.
(мои 5 коп.)

>>Kerk ©   (14.04.17 14:51) [317]
 Если не будет сочтено за оффтопик, хотелось бы понять, что такого прорывного случилось за последние 20 лет в технике программирования, ради чего стоило бы "выглядывать из окна"? Я вот кроме web-технологий и модной последнее время кроссплатформенности ничего не заметил, кроме рюшечек. Те же дженереки я использовал в C++ еще в 98-ом, если мне память не изменяет, как раз скоро 20 лет будет. Понимаю, что это не совсем те же дженерики, но не суть. Странный пример, просто.

> ухты ©   (14.04.17 17:15) [324]

Конечно.

> Внук ©   (14.04.17 17:15) [325]
>
> Я вот кроме web-технологий и модной последнее время кроссплатформенности
> ничего не заметил, кроме рюшечек.

А этого мало? Nosql, облака, бигдата всякая. Не, понятно, что все это было еще при наших дедушках, но в мейнстрим пришло лишь недавно.

> Те же дженереки я использовал в C++ еще в 98-ом, если мне
> память не изменяет, как раз скоро 20 лет будет. Понимаю,
>  что это не совсем те же дженерики, но не суть. Странный
> пример, просто.

Пример как раз хорош тем, что он очень показателен. Впервые дженерики появились чуть ли не в 60е, но так как в паскале и Delphi их долго не было их и не заметили. До сих пор много Delphi-программистов считают дженерики да лямбды не полезными частями языка, а рюшечками ненужными.

Не мало. Просто это вещи, которые не всем нужны.

> А ему оно надо?


Оно компании надо.


> Я не наблюдал такого процесса.


Я видел несколько раз.


> главный недостаток C# это .NET


Согласен.


> Но в России это обычно выбор между C++, Java, C# и торрентами


Лазаря можно еще вспомнить. Местами мне нравится больше Делфи. Вполне годная и бесплатная среда. Главный минус - отладтик на троечку. Можно в связке со стартером использовать. Я так у себя делал, основная отладка - винда, делфи, специфичиские вещи на линуксе, на лазаре. На одном коде, с минимумом телодвижений.


> Nosql, облака, бигдата всякая.


Частично в делфи уже есть, частично покрывается компонентами. Но и двигаться Эмбе/Идере есть еще куда, пусть работают.

Внук ©   (14.04.17 18:37) [327]


> Просто это вещи, которые не всем нужны.


Это да. Я лично не могу себе представить, где в повседневной жизни мне нужны дженерики. Понятно, что во всяких библиотечных классах они удобны, но многие ли из нас разрабатывают библиотечные классы, кроме тех, которые уже разработаны, и так ли они нужны... ?

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

Дмитрий Белькевич ©   (14.04.17 19:55) [328]


> Я видел несколько раз.


Даже у нас с тобой разный опыт, боюсь, что твое обобщение преждевременно. Нет, я не спорю, можно переучиться с С++ на Паскаль (и наоборот), но это небыстро, чтобы начать думать на Паскале должно пройти сколько-то времени.

> Дмитрий Белькевич ©   (14.04.17 19:55) [328]
>
> > А ему оно надо?
>
> Оно компании надо.

Компании надо доступ к квалифицированному рынку труда. Брать С++ников, чтоб они писали на делфи конечно можно. Но хотелось бы без этого :)

> > Nosql, облака, бигдата всякая.
> Частично в делфи уже есть, частично покрывается компонентами.
>  Но и двигаться Эмбе/Идере есть еще куда, пусть работают.

Не спорю. Вопрос только в запаздывании. Если оно тебе нужно сегодня, то деваться не куда. При этом я отлично осознаю, что на большинстве делфи-проекто все это нафиг не сдалось.


> Игорь Шевченко ©   (14.04.17 20:25) [329]
> Это да. Я лично не могу себе представить, где в повседневной
> жизни мне нужны дженерики. Понятно, что во всяких библиотечных
> классах они удобны, но многие ли из нас разрабатывают библиотечные
> классы, кроме тех, которые уже разработаны, и так ли они
> нужны... ?

Это все равно что "не представляю зачем нужен полиморфизм тем, кто не пишет библиотечные классы" :) Дженерики - это ведь всего-лишь второй тип полиморфизма из двух. Ну или первый, я не помню уже хронологию.

а что значит библиотечные?
вот у нас во вполне себе не библиотечном проекте есть много всяких мест где применили дженерики,
например клиенту в работе надо часто делать запросы на нттп сервер, ну вот все запросы сделали "хоть и безобразно зато единообразно" )), т.е. через дженерики.
типа httphelper.get<T>, httphelper.getasync<T>, httphelper.post<T>, httphelper.postasync<T>, ну просто чтобы было хорошо ) и никаких библиотек

> Kerk ©   (14.04.17 21:02) [330]

В самом деле, зачем,
если время написания узкоспециализированных классов под конкретный проект с нуля вряд ли составляет более 5% от всего проекта?
Причем это время не зависит от использования (не использования) дженериков.

> Но хотелось бы без этого :)


Кто бы спорил, хочется быть богатым и здоровым. И, желательно, бесплатно :)

Дженерики у нас не более чем сахар, исключительно в разных TList'ах. Удобно, меньше захламляет код. Но сказать, что бы они были критичными - то нет.
Лямбды, скорее, критичны. Есть мест штук 20 распараллеливания кода, удобно лямбдами делать.
А из-за отсутствия reference to procedure в лазаре пришлось довольно много всего переписывать - контексты передавать.

> ухты ©   (14.04.17 21:10) [331]

Жизненный и понятный пример.

---

Простой и гибкий инструмент, позволяющий обобщить код и усилить статическую типизацию одновременно. Не, не нужен. Там, где раньше жонглировали указателями и напрямую приводили типы, теперь все строго проверяет компилятор. Да зачем нам эти глупости? Это этот, как его - creeping featurism :)

Kerk ©   (14.04.17 21:02) [330]


> "не представляю зачем нужен полиморфизм тем, кто не пишет
> библиотечные классы"


Полиморфизм полиморфизму рознь. Дженерики позволяют выполнить идентичные действия над разными типами данных, полиморфизм в ООП позволяет использовать  интерфейс объекта, не зная о его структуре.
Мне за длинную программистскую жизнь второе приходилось использовать гораздо чаще, чем первое.

> Дженерики позволяют выполнить идентичные действия над разными
> типами данных


а без дженериков это никак?

> Игорь Шевченко ©   (14.04.17 23:17) [337]
>
> Полиморфизм полиморфизму рознь. Дженерики позволяют выполнить
> идентичные действия над разными типами данных, полиморфизм
> в ООП позволяет использовать  интерфейс объекта, не зная
> о его структуре.

Не, Игорь, ты сказал одно и то же разными словами :)

Полиморфизм в ООП точно так же позволяет выполнить идентичные действия над разными типами данных. Как в том хрестоматийном примере, где ты вызываешь метод Draw, не зная с каким конкретно классом имеешь дело - квадратом или кругом.

Понятно, что есть в этой логике и существенные различия. Но иначе это был бы один тип полиморфизма, а не два :)

> Мне за длинную программистскую жизнь второе приходилось
> использовать гораздо чаще, чем первое.

Мне тоже, чего уж там.

> Kilkennycat ©   (14.04.17 23:29) [338]
>
> > Дженерики позволяют выполнить идентичные действия над разными
> > типами данных
>
> а без дженериков это никак?

Почти ничто в программировании не является необходимым :)

> Почти ничто в программировании не является необходимым :)

кроме мозгов :)

Бывает, и без них обходятся :))

Kerk ©   (14.04.17 23:44) [339]


>  одно и то же разными словами


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

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

Хотя если подумать, то и цели одинаковые, просто подход к ним разный :)

свежие новости с полей FMX. наткнулся на вот такую проблему сейчас

https://community.embarcadero.com/answers/tokyo-10-2-rad-studio-not-compiling-to-ios-for-app-store,-error-e0776-xcrun-error-unable-to-find-utility-packageapplication-,-not-a-developer-tool-or-in-path

почти месяц прошел, кроме как предложения установить старый xcode ничего нет.
за месяц строку сложно было поправить в paserver'е? бежать надо с этого FMX, причем быстро.

> Eraser ©   (28.04.17 19:35) [346]
> свежие новости с полей FMX. наткнулся на вот такую проблему
> сейчас

Тю, разве это ошибка, вот я на глобальный катарсис вылез на вызове NtQueryObject, который с верно выставленными параметрами прямая дырка для иньекции шеллкода. Оть это было здорово, причем наткнулся ядром защиты - которая незная чем ей это грозит эксплуатировала данную уязвимость.

Всем привет. Возможно будет интересен блог:

https://blog.grijjy.com/page/3/

Working with big data databases in Delphi – Cassandra, Couchbase and MongoDB
Expand your Collections collection – a generic set, a generic ring buffer
Cross Platform Text-to-Speech
Scalable HTTP/S and TCP client sockets for the cloud
Unit Testing Generic Types
Using the Google Cloud Platform APIs
Sending iOS (and Android) remote push notifications from your Delphi service with the HTTP/2 protocol
Using Facebook SDK native framework for iOS and Android
Efficient and easy-to-use JSON and BSON library
Receiving push notifications from Apple’s Push Notification and Google’s Firebase Cloud Messaging services
Binary Serialization with Google Protocol Buffers
Roll your own lightweight, scalable backend using ZeroMQ

Многое с полными исходниками. Может пригодится.

> Eraser ©   (28.04.17 19:35) [346]


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

Говорят, что Крюков (тот самый, что стоял у истоков FMX) разрабатывает новую перспективную платформу

Так уже и ссылки кидали вроде?

http://crossvcl.com/

его же:

http://fmxlinux.com/

> Кто б сомневался ©   (05.05.17 14:08) [349]
>
>
> Сейчас интересные заказы с хорошими деньгами идут на мультиплатформенные
> программы


Если не секрет, вы фрилансер?

И если не секрет, то какие это заказы? Деталей не нужно. Хотя бы общие черты.

Германн ©   (07.05.17 02:22) [353]

Да фрилансер.

Заказы все разные.
В основном мобильные приложения под Android (иногда + iOS).

От простого SMS планировщика, или баркод сканера или звонилки с базой данных для флота одной судоходной компании до рации для автомастерской и приложения для ресторанного моб. девайса типа Ziosk с возможностью распечатать на принтере..

> Кто б сомневался ©   (07.05.17 19:39) [354]

Понял.
Спасибо за ответ.

Новый roadmap https://community.embarcadero.com/article/news/16519-rad-studio-roadmap-may-2018

Стабильно возникают одни и те же вопросы :)
http://pda.delphimaster.net/?id=1495269750&n=3

Роман, по поводу сторонних сервисов:

https://habrahabr.ru/company/everydaytools/blog/329282/