Здравствуйте, rudzuk, Вы писали:
R>Ты говоришь о бесшовной кроссплатформе, это понимать как? Я понимаю так, что берешь код написаный под старую VCL, компилируешь на новой и получаешь переносимый гуй. Так вот это фантастика.
Именно так. И никакой фантастики я в этом не вижу.
M>> А гарантированность результата... Хм... Ну я делал свой гуй как-то, Win32/WTL и wxWidgets, и у меня в одно лицо вполне получилось за несколько месяцев. VCL конечно побольше, но там в конторе и умных людей по идее побольше, чем у меня
R>Сравнил конечно... Одно дело, если бы VCL изначально проектировалась под кроссплатформу, и совсем другое, когда VCL затачивалась специально под винду
wxWidgets вообще был сделан на базе MFC, а в результате стал кроссплатформенной либой. И живет до сих пор, в отличие от VCL.
Состав контролов, и принципы работы гуя (сообщения, и их выборка из очереди сообщений, и рассылка подписчикам) — это универсально для всех систем. Только в кути пошли по своему пути, и сделали свои сигнал-слоты (в принципе, это чем-то похоже на VCL обработчики onXXX), но сделали это через свой moc-компилятор. А тот же wxWidgets остался очень похожим на MFC, и без лишних сущностей типа moc, и я не вижу проблем, почему на нём нельзя было сделать полностью совместимый VCL.
Не вижу проблем, почему с VCL нельзя было сделать аналогично. Да, в кишочках были бы изменения, но снаружи можно было сделать всё совместимое.
Можно было просто взять тот же кроссплатформенный wxWidgets в качестве GUI-бекэнда
R>и к моменту решения о кроссплатформе был накоплен гигантский объем кода у клиентов и вендоров компонент. Поэтому решение о новом гуй-фреймворке было логичным.
Только этот объём кода был, скорее всего, заточен не на винду уже, а на VCL. А если он был заточен на винду — то тогда не понятно, как создание новой CLX оставляло совместимость с этой кодовой базой и почему надо было делать CLX, а не развивать VCL
Здравствуйте, Marty, Вы писали:
M> R>Ты говоришь о бесшовной кроссплатформе, это понимать как? Я понимаю так, что берешь код написаный под старую VCL, компилируешь на новой и получаешь переносимый гуй. Так вот это фантастика.
M> Именно так. И никакой фантастики я в этом не вижу.
Ну вот смотри, простой пример. У оконных контролов есть метод CreateParams, где потомок может определенным образом модифицировать параметры окна для достижения нужного эффекта (например: Params.ExStyle := Params.ExStyle or WS_EX_...). Как такому коду обеспечивать переносимость бесшовную? Изображать внутреннюю реализацию винапи?
M> R>Сравнил конечно... Одно дело, если бы VCL изначально проектировалась под кроссплатформу, и совсем другое, когда VCL затачивалась специально под винду
M> wxWidgets вообще был сделан на базе MFC, а в результате стал кроссплатформенной либой.
Хорошо, когда ты опенсорс и у тебя нет обязательств сохранять совместимость
M> И живет до сих пор, в отличие от VCL.
Так и VCL живет.
M> Не вижу проблем, почему с VCL нельзя было сделать аналогично. Да, в кишочках были бы изменения, но снаружи можно было сделать всё совместимое.
В том и дело, что без влезания в кишочки не писался ни один серьезный компонент.
M> R>и к моменту решения о кроссплатформе был накоплен гигантский объем кода у клиентов и вендоров компонент. Поэтому решение о новом гуй-фреймворке было логичным.
M> Только этот объём кода был, скорее всего, заточен не на винду уже, а на VCL. А если он был заточен на винду — то тогда не понятно, как создание новой CLX оставляло совместимость с этой кодовой базой и почему надо было делать CLX, а не развивать VCL
Штука в том, что VCL это очень тонкая обертка над виндовыми контролами (за исключением самоотрисовывающихся контролов), поэтому чуть что и ты уже дергаешь винапи. Потому появление CLX было логичным шагом: кому не нужна кроссплатформа спокойно сидят на VCL, кому нужна, тем придется портировать свой код на новый фреймворк. Ровно та же история произошла потом и с FMX.
Здравствуйте, rudzuk, Вы писали:
R>Ну вот смотри, простой пример. У оконных контролов есть метод CreateParams, где потомок может определенным образом модифицировать параметры окна для достижения нужного эффекта (например: Params.ExStyle := Params.ExStyle or WS_EX_...). Как такому коду обеспечивать переносимость бесшовную? Изображать внутреннюю реализацию винапи?
Отремапить константы на аналогичные на другой платформе, может конечно надо немножко что-то дописать.
M>> И живет до сих пор, в отличие от VCL.
R>Так и VCL живет.
Правда, что ли?
M>> Не вижу проблем, почему с VCL нельзя было сделать аналогично. Да, в кишочках были бы изменения, но снаружи можно было сделать всё совместимое.
R>В том и дело, что без влезания в кишочки не писался ни один серьезный компонент.
Пруфов не будет?
R>Штука в том, что VCL это очень тонкая обертка над виндовыми контролами (за исключением самоотрисовывающихся контролов), поэтому чуть что и ты уже дергаешь винапи. Потому появление CLX было логичным шагом: кому не нужна кроссплатформа спокойно сидят на VCL, кому нужна, тем придется портировать свой код на новый фреймворк. Ровно та же история произошла потом и с FMX.
wxWidgets — тоже не жирная обёртка, и изначально была на MFC. Но живет как-то. Я допускаю, что писатели библиотек компонентов таки дергали винапи, а вот конечному пользователю в винапи лазать было не нужно от слова совсем. А для писателей компонентов можно было сделать некоторый слой совместимости. Всяко лучше, чем кидать всех виндовых пользователей и или создавать новую ветку компонентов
Здравствуйте, Marty, Вы писали:
M> Отремапить константы на аналогичные на другой платформе, может конечно надо немножко что-то дописать.
Если бы все было так просто...
M> R>Так и VCL живет.
M> Правда, что ли?
Всем бы так жить!
M> R>В том и дело, что без влезания в кишочки не писался ни один серьезный компонент.
M> Пруфов не будет?
Какие тебе пруфы-то нужны? Открой, какой-нибудь TBX да посмотри
M> R>Штука в том, что VCL это очень тонкая обертка над виндовыми контролами (за исключением самоотрисовывающихся контролов), поэтому чуть что и ты уже дергаешь винапи. Потому появление CLX было логичным шагом: кому не нужна кроссплатформа спокойно сидят на VCL, кому нужна, тем придется портировать свой код на новый фреймворк. Ровно та же история произошла потом и с FMX.
M> wxWidgets — тоже не жирная обёртка, и изначально была на MFC. Но живет как-то.
wxWidgets — изначально кроссплатформенный проект:
Проект под названием wxWindows (w от Windows, x от X Window System)[5] был основан в 1992 году, когда Джулиан Смарт работал в Эдинбургском Университете над инструментом диаграммирования под названием «Hardy». Вместо того, чтобы выбирать между разработкой его для рабочей станции Sun или для платформы PC, Джулиан предпочёл применить кроссплатформенный фреймворк. Поскольку мощность существующих кроссплатформенных фреймворков была ограничена, а отделение не имело необходимого бюджета для написания такового, то он решил написать его самостоятельно.
Поэтому не нужно сравнивать его с VCL, где о кроссплатформе никогда не думали.
M> Я допускаю, что писатели библиотек компонентов таки дергали винапи, а вот конечному пользователю в винапи лазать было не нужно от слова совсем.
Только если ты готов был довольствоваться тем, что предоставляла VCL. Но чуть шаг в сторону и: сделать в листбоксе несколько столбцов можно было только через винапи. Любая кастомная отрисовка сложнее паинтбокса — здравствуйте GetDC, BitBlt и т.д. Хочешь как-то по-особенному рулить ричедитом — посылаешь ему сообщения. Короче, не рассказывай мне, как оно было на VCL, я его много кушал.
Здравствуйте, rudzuk, Вы писали:
M>> Пруфов не будет?
R>Какие тебе пруфы-то нужны? Открой, какой-нибудь TBX да посмотри
Если бы я помнил/знал, что такое TBX...
M>> wxWidgets — тоже не жирная обёртка, и изначально была на MFC. Но живет как-то.
R>wxWidgets — изначально кроссплатформенный проект: R>
Проект под названием wxWindows (w от Windows, x от X Window System)[5] был основан в 1992 году, когда Джулиан Смарт работал в Эдинбургском Университете над инструментом диаграммирования под названием «Hardy». Вместо того, чтобы выбирать между разработкой его для рабочей станции Sun или для платформы PC, Джулиан предпочёл применить кроссплатформенный фреймворк. Поскольку мощность существующих кроссплатформенных фреймворков была ограничена, а отделение не имело необходимого бюджета для написания такового, то он решил написать его самостоятельно.
Вначале wxWindows был нацелен на Xview и MFC 1.0. Пользователи Borland C++, жаловавшиеся на привязку к MFC, таким образом, стали переписывать программы на чистый Win32.
R>Поэтому не нужно сравнивать его с VCL, где о кроссплатформе никогда не думали.
Да нет проблем. Но только в wxWidgets сделали, значит и в VCL можно было. Могли wxWidgets взять за бекэнд
M>> Я допускаю, что писатели библиотек компонентов таки дергали винапи, а вот конечному пользователю в винапи лазать было не нужно от слова совсем.
R>Только если ты готов был довольствоваться тем, что предоставляла VCL. Но чуть шаг в сторону и: сделать в листбоксе несколько столбцов можно было только через винапи.
По-моему, даже через WinAPI в ListBox'е нельзя было сделать несколько столбцов. Да и никогда не нужно было — были же многоколоночные ListView. А в VCL был ещё TGrid (или как-то так), у которого нет прямого аналога в Win32.
R>Любая кастомная отрисовка сложнее паинтбокса — здравствуйте GetDC, BitBlt и т.д. Хочешь как-то по-особенному рулить ричедитом — посылаешь ему сообщения.
Только не было никаких сырых винапишных GetDC и BitBlt, а были VCL обёртки для них и были VCL-методы получения этих обёрток. А обёртки над HDC, которые переносимы на другой бекэнд, помимо WinGDI, даже я делал ещё в детском садикеинституте
R>Короче, не рассказывай мне, как оно было на VCL, я его много кушал.
Я кушал не только VCL, но и много писал кроссплатформенные аппы, и сам делал совместимые обёртки. И я не на пустом месте говорю, что это не так сложно, я даже в одно лицо вполне справлялся.
Здравствуйте, Michael7, Вы писали:
M>Интересно, многие ли сейчас вообще вспомнят о существовании такого продукта, а также о dBase и Ashton-tate?
Ну я их конечно же помню — но это оттого, что у меня с них карьера началась. dBase III (точнее, РЕБУС), потом Clipper, и далее со всеми остановками.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Marty, Вы писали:
M>Поискал, кстати, MFC — mfc42.dll — больше мегабайта, но это древняя MFC, из второй половины 90ых.
Ну один мегабайт (даже в те времена) — размер небольшой. Поэтому она и легковесная.
M>При этом у MFC кроме обёрток на гуем я хз что там было, а в VCL были например супер удобные классы для доступа к СУБД.
Так ведь с этим же никто же и не спорит:
Прикладнуха (организационная, корпоративная и бухгалтерская) — VCL и C++Builder 5.0 — ну или Delphi.
Системные и околосистемные разработки — такие как SCADA, например — MSVC: MFC и WinAPI.
M>И для того, чтобы сделать по базе какой-то отчет, не надо было неделями пехаться с ручной работой с каким-нибудь ODBC,
Это вроде так, но и не так: если в библиотеке этого компонента не было — имели место проблемы.
В общем — шаг влево/вправо — расстрел.
А вот на MFC сделать свой (custom-ный) компонент. Или же приспособить какой-нибудь Active-X — было нормальной практикой.
M>Ты просто ничего другого не знал, как я понимаю.
Много чего тогда знал и пробовал. Но достойных варианотов, кроме как MFC и VCL (каждый в своей нише) — тогда просто ешё не создали.
M>Как наш Артёмка. Один снобизм...
Предлагаю не переходить на личности
M>Не распарсил, что на C#?
Ну C#; .NET; WindowsFroms — это новое, по тем временам, направление разработки настольных приложений.
Которое вскоре отодвинуло MFC и VCL далеко на задний план. Все мы стройными рядами перешли на C# в середине 2000-ных.
M>Так-то, C++Builder 5.0 — это 2000ый год, а MSVC2003 — сам понимаешь, какой год.
Ну справедливости ради, следует отметить что многие (в том числе и в нашей рабочей группе) на C++Builder 5.0 сидели до конца 2000-ных.
M>Я могу понять, что тебе мешало заниматься формошлёпством на MSVC/MFC — отсутствие там такой возможности.
Здесь не совсем так — просто на MSVC/MFC большие трудозатраты на формошлепство. Возможность — там есть, но (тут спорить не стану) — это легче на VCL.
M>Я не могу понять, что тебе мешало делать капитальные проекты на C++Builder 5.0...
Возможно, незнание VCL или ещё какая-то проблема с компетентностью
Я посмотрю на твою компетентность, когда тебе в окне SCADA системы потребуется изобразить резервуар масла с насосом и датчиками давления, температуры и т.д.
При этом — всё должно жить в динамике: насос работать (вращение ротора), датчики — показывать изменения, при переходе через threshold — аварийный сигнал...
Вот тут и окажется — что MFC/WinAPI более приспособлен для этого, нежели VCL.
Здравствуйте, Marty, Вы писали:
M>Altium Designer написан на дельфях, кстати. Капитальный проект или формошлёпство?
Мы разве рассматриваем от слова "вообще что есть на сегодня"?
Или в плане историческом: "20-25 лет назад", что было во времена популярности компании Борланд?
Вроде как все-таки второе.
В википедии насчет этого продукта: Written in: Delphi, C#, C++
Здравствуйте, AlexGin, Вы писали:
M>>Поискал, кстати, MFC — mfc42.dll — больше мегабайта, но это древняя MFC, из второй половины 90ых.
AG>Ну один мегабайт (даже в те времена) — размер небольшой. Поэтому она и легковесная.
wxWidgets тогда тоже легковесная
AG>Это вроде так, но и не так: если в библиотеке этого компонента не было — имели место проблемы.
У меня не было проблем
AG>В общем — шаг влево/вправо — расстрел.
Такое мнение сложилось от того, что на Дельфях было много слабых программистов, и всё. А так — никакого расстрела, ничего такого, что можно сделать на MFC, и нельзя на VCL, не было
AG>А вот на MFC сделать свой (custom-ный) компонент. Или же приспособить какой-нибудь Active-X — было нормальной практикой.
На VCK — тоже самое
M>>Не распарсил, что на C#?
AG>Ну C#; .NET; WindowsFroms — это новое, по тем временам, направление разработки настольных приложений. AG>Которое вскоре отодвинуло MFC и VCL далеко на задний план. Все мы стройными рядами перешли на C# в середине 2000-ных.
Я писал про WTL, откуда тут появился C#?
AG>Я посмотрю на твою компетентность, когда тебе в окне SCADA системы потребуется изобразить резервуар масла с насосом и датчиками давления, температуры и т.д. AG>При этом — всё должно жить в динамике: насос работать (вращение ротора), датчики — показывать изменения, при переходе через threshold — аварийный сигнал... AG>Вот тут и окажется — что MFC/WinAPI более приспособлен для этого, нежели VCL.
А в чем проблемы сделать подобное на VCL? Чего тут такого сложного?
Здравствуйте, AlexGin, Вы писали:
M>>Altium Designer написан на дельфях, кстати. Капитальный проект или формошлёпство?
AG>Мы разве рассматриваем от слова "вообще что есть на сегодня"? AG>Или в плане историческом: "20-25 лет назад", что было во времена популярности компании Борланд? AG>Вроде как все-таки второе.
Да
AG>В википедии насчет этого продукта: AG>Written in: Delphi, C#, C++
AG>То есть — всё таки там больше C#, нежели Delphi
С чего бы такой вывод?
Altium в своё время купила P-CAD. Чат гопота говорит:
САПР P-CAD был написан преимущественно на языке Turbo Pascal (Object Pascal).
Вот ключевые детали о его разработке:
Основной язык: Turbo Pascal (Borland Pascal / Object Pascal). Это был основной язык разработки для создания ядра системы, интерфейса пользователя и функциональных модулей P-CAD.
Операционная система: DOS (MS-DOS / PC-DOS). P-CAD был изначально разработан как 16-битное приложение для операционной системы DOS. Поздние версии (начиная примерно с P-CAD 2000) пытались работать под Windows, но часто представляли собой "оболочки" над DOS-ядром или имели гибридную архитектуру.
Среда разработки: Скорее всего, использовалась Borland Turbo Pascal (а позднее, возможно, Borland Pascal) и соответствующие инструменты для DOS.
Теперь вики:
Altium Designer — комплексная система автоматизированного проектирования (САПР) радиоэлектронных средств, разработанная австралийской компанией Altium. Ранее эта же фирма разрабатывала САПР P-CAD, который приобрёл необычайную популярность среди российских разработчиков электроники. В 2008 году фирма Altium заявила о прекращении поставки программных пакетов P-CAD, и предложила разработчикам использовать программу Altium Designer, которая появилась в 2000 году и изначально имела название Protel. В 2006 был проведён ребрендинг программного продукта и он получил текущее название, последняя версия которого называется Altium Designer 21.
С учетом того, что Протел вышел в 2000ом году (как раз на пике популярности Дельфи), что контора ранее купила и некоторое время развивала P-CAD, написанный на паскале, и того, что первый дот нет вышел в 2002ом году — есть все основания утверждать, что Altium Designer написан на дельфях.
Кстати, в Альтиуме можно писать скрипты, расширяющие функциональность, и, внезапно, они пишутся на паскале, что тоже намекает.
У нас в конторе была какая-то система ведения управления проектами, Союз-PLM, он на шарпе написан, с ним некоторые САПРы умели интегрироваться худо бедно — так, Альтиум умеет извлекать из него схемоту и либы компонентов, и вот на шарпе, я уверен, написана только эта интеграционная часть, а остальное с Паскаля никто не стал бы переписывать
Здравствуйте, Marty, Вы писали:
M> R>Какие тебе пруфы-то нужны? Открой, какой-нибудь TBX да посмотри
M> Если бы я помнил/знал, что такое TBX...
https://github.com/plashenkov/TBX
M> R>wxWidgets — изначально кроссплатформенный проект: M> R>Проект под названием wxWindows (w от Windows, x от X Window System)[5] был основан в 1992 году, когда Джулиан Смарт работал в Эдинбургском Университете над инструментом диаграммирования под названием «Hardy». Вместо того, чтобы выбирать между разработкой его для рабочей станции Sun или для платформы PC, Джулиан предпочёл применить кроссплатформенный фреймворк. Поскольку мощность существующих кроссплатформенных фреймворков была ограничена, а отделение не имело необходимого бюджета для написания такового, то он решил написать его самостоятельно.
M> Вначале wxWindows был нацелен на Xview и MFC 1.0. Пользователи Borland C++, жаловавшиеся на привязку к MFC, таким образом, стали переписывать программы на чистый Win32.
Не пойму, что ты хочешь этим сказать. Что пользователей билдера обделили вниманием?
M> Да нет проблем. Но только в wxWidgets сделали, значит и в VCL можно было. Могли wxWidgets взять за бекэнд
Зачем VCL нужен был какой-то бекэнд, когда задача ее переносимости вообще не стояла?
M> R>Только если ты готов был довольствоваться тем, что предоставляла VCL. Но чуть шаг в сторону и: сделать в листбоксе несколько столбцов можно было только через винапи.
M> По-моему, даже через WinAPI в ListBox'е нельзя было сделать несколько столбцов.
LBS_MULTICOLUMN, LB_SETCOLUMNWIDTH. Не помню в какой версии Delphi это стало поддерживаться из коробки.
M> Да и никогда не нужно было — были же многоколоночные ListView.
Все бы руководствоваться принципом "мне не нужно". В ListView каждый элемент это отдельный и довольно тяжелый объект, тогда, как в ListBox это просто строка. Это легче и ресурсов требует меньше. Кроме того, ListBox поддерживал виртуальные списки, а у ListView такой функциональности небыло.
M> R>Любая кастомная отрисовка сложнее паинтбокса — здравствуйте GetDC, BitBlt и т.д. Хочешь как-то по-особенному рулить ричедитом — посылаешь ему сообщения.
M> Только не было никаких сырых винапишных GetDC и BitBlt, а были VCL обёртки для них и были VCL-методы получения этих обёрток.
В том то и дело, что были вызовы API. Использовать обертки VCL было не всегда возможно и не всегда оправдано (кто думал о кроссплатформе-то, а?).
M> R>Короче, не рассказывай мне, как оно было на VCL, я его много кушал.
M> Я кушал не только VCL, но и много писал кроссплатформенные аппы, и сам делал совместимые обёртки. И я не на пустом месте говорю, что это не так сложно, я даже в одно лицо вполне справлялся.
Так никто и не говорит, что это сложно. Речь о том, что задачи такой небыло. А когд она появилась, было уже поздно проворачивать фарш назад.
Здравствуйте, Sinclair, Вы писали:
S> M>Интересно, многие ли сейчас вообще вспомнят о существовании такого продукта, а также о dBase и Ashton-tate?
S> Ну я их конечно же помню — но это оттого, что у меня с них карьера началась. dBase III (точнее, РЕБУС), потом Clipper, и далее со всеми остановками.
Коллега, мое почтение. dBase III, КАРАТ, FoxPro, Clipper
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
M>>>Ну вот XAML — это и есть попытка шарпистов сделать так же удобно, как было в дельфях
I>>А в какй-то версии delphi удобнее? Ну я не смотрел соотвестующую версию, значит.
M>Да в любой 1-7. Ты, видимо, Дельфи только на картинках и видел
Как минимум в университете изучал, тогда творения Borland на CD'юках было найти проще многого осталного. Как минимум до 4-й версии, если не больше, не помню средств содания списков с заданным layout элементов.
I>>>>Не помню такого. Это в awt появилис хот скол-нибудь удобные средства отображения коллекций, к примеру. И в ранних версиях android sdk было что-то похожее.
M>>>Какого ты не помнишь?
I>>Что в delph было удобного для отображения списков, например. Может, в какой-то моент появилос.
M>В дельфи были, как минимум, все виндовые контролы, только использовались они не через винапи, а гораздо удобнее. Ну и куча сторонних. Если из виндовых — то обычный ListBox — чем тебе не список?
И что там с заданным layout элементов? Хотя б уровен AWT когда был достигнут?
I>>>>Property Editor полезен, только если позабл, как что-то называется.
M>>>А если не забыл, удобнее ручками текст править (не забывая о синтаксисе этого "текста"?) M>>>То-то сейчас все делают тоже самое
I>>Разумеется.
M>Что разумеется?
Вручную редактировать удобнее, чем бесчисленные действия мышью.
I>>Я, конечно, знавал любителей клепать диаграммы баз даннх в редакторах схем, где для создания одной таблиц порой требовалос гигантское количество дейстий мышью, мне этого не понять, мне несравнимо проще написать SQL.
M>Прикинь, диаграммы баз данных иногда рисуют, чтобы понимать структуру базы данных, даже если сами таблицы были созданы текстовым SQL. А иногда даже удобно нарисовать диаграмму, а по ней автоматом сгенерить код SQL, если инструмент такой есть в наличии — просто тупо по тому, что под каждую СУБД могут быть свои нюансы этого SQL, хотя, когда используешь только одну СУБД, то обычно все нюансы уже заучил.
Если разный SQL нужен, то нужно ещё и согласованность поддерживать, тогда проще средства какого-то ORM задействовать. А иначе проще SQL написать, диаграммы при необходимости сгенерировать из созданной базы данных.
I>>Так что не искючаю и любителей всяких Property Editor, и этого мне не понять. Разве что синтаксис очен сложнй, но, к примеру в iOS storyboards я часто ради формирования id только пользуюс встроенным редактором, а в омногих случаях предпочитаю xib/storybaord поправить вручную.
M>Я, было дело, кой чо делал для андроида, а там всё в XML описывается, и есть всякие визуальные типа Property Editor. Только вот они там ужасно убогие, и только поэтому я ручками писал XML, а иногда и генерил какими-нибудь скриптами. Только это не про Дельфи — там это было супер удобно.
Мне не понять этого удобства.
I>>>>Но MFC был сделан под GDI, когда графические процессоры были ещё экзотикой.
M>>>А причем тут GDI и графические процессоры?
I>>Ну для начала неизбежны разне принципы построения UI, графический процессор быстро выполняет composing, а на центральном процессоре часто быстрее отдельные линии перерисовавть, а заполнять прямоугольные области, не особенно пользуяс полупрозрачностью. Соотвественно, ориентированность на GDI для поддержания единого стандарта.
M>Так и причем тут GDI и графические процессоры? Это проблемы нижнего слоя — рендерера, как и что рисовать. К удобству построения UI это не имеет никакого отношения, если, конечно, криворукие архитекторы не протащили подобные зависимости по разным слоям архитектуры
Современные процессоры далеко не настолько быстрее, чтоб проблемы нижнего слоя можно было игнорировать.
Здравствуйте, Ilya81, Вы писали:
M>>Да в любой 1-7. Ты, видимо, Дельфи только на картинках и видел
I>Как минимум в университете изучал, тогда творения Borland на CD'юках было найти проще многого осталного.
Значит, очень хорошо забыл
I>Как минимум до 4-й версии, если не больше, не помню средств содания списков с заданным layout элементов.
TListBox
I>И что там с заданным layout элементов? Хотя б уровен AWT когда был достигнут?
Я понятия не имею, что такое AWT
M>>Что разумеется?
I>Вручную редактировать удобнее, чем бесчисленные действия мышью.
Смотря как сделано. В Дельфи было сделано хорошо, и мышью всё делалось в несколько кликов, вместо бесконечной писанины в каком-нибудь XAML
M>>Я, было дело, кой чо делал для андроида, а там всё в XML описывается, и есть всякие визуальные типа Property Editor. Только вот они там ужасно убогие, и только поэтому я ручками писал XML, а иногда и генерил какими-нибудь скриптами. Только это не про Дельфи — там это было супер удобно.
I>Мне не понять этого удобства.
Твоя проблема
M>>Так и причем тут GDI и графические процессоры? Это проблемы нижнего слоя — рендерера, как и что рисовать. К удобству построения UI это не имеет никакого отношения, если, конечно, криворукие архитекторы не протащили подобные зависимости по разным слоям архитектуры
I>Современные процессоры далеко не настолько быстрее, чтоб проблемы нижнего слоя можно было игнорировать.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
I>>Вручную редактировать удобнее, чем бесчисленные действия мышью.
M>Смотря как сделано. В Дельфи было сделано хорошо, и мышью всё делалось в несколько кликов, вместо бесконечной писанины в каком-нибудь XAML
Вы знаете, чем заканчивается использование всех этих визуальных редакторов ("дезигнеров")?
Вот, допустим, вы обновили Visual Studio, а это неизбежно, если вы долго работаете над одним проектом в команде. И у новой версии поменялся кодо-генератор по дизайнеру форм, что тоже обычное дело. Вот вам нужно добавить кнопку, просто одну кнопку на форму. И что у нас получается?
Вот вы добавляете мелкую такую кнопку, а у вас, бах, весь код новый кодо-генератор переделал, просто напрочь все перепахал.
Кто по-сообразительнее, те обычно этот мусор весь убирают, а в текстовом редакторе меняют ровно то, что относится к вашей новой кнопке. Или даже так, генерируют новый код через дизайнер форм, а потом из такого кода руками убирают весь этот новоявленный рефакторинг так, чтобы дизайнер мог вновь подхватить сделанные вручную изменения.
В той же Visual Studio для WinForms это довольно четко было видно. То есть, грамотный коммит состоял только в том, чтобы добавить одну кнопку, потому что никто не хотел связываться с тем, а что там новый кодо-генератор навытворял в коде. Обычно какая-нибудь сущая фигня в изменениях, там окончание другое или еще что, а вот весь автоматически генерируемый код нелепо перелопачен.
Ну, и кому это счастье надо? Зачем тогда нужен визуальный редактор форм, если он вставляет палки в колеса, если с ним приходится мучаться?
И я не говорю еще о том, что случайное касание мышью может также привести к куче бессмысленно перелопаченного кода, потому что опять же изменилась версия кодогенератора.
Поэтому при работе с визуальными дизайнерами форм функция "revert" — это самая основная.
Вот для быстрого прототипирования визуальные дизайнеры хороши. Это чтобы накидать, увидеть, а потом выбросить
Здравствуйте, dsorokin, Вы писали:
M>>Смотря как сделано. В Дельфи было сделано хорошо, и мышью всё делалось в несколько кликов, вместо бесконечной писанины в каком-нибудь XAML
D>Вы знаете, чем заканчивается использование всех этих визуальных редакторов ("дезигнеров")?
D>Вот, допустим, вы обновили Visual Studio, а это неизбежно, если вы долго работаете над одним проектом в команде. И у новой версии поменялся кодо-генератор по дизайнеру форм, что тоже обычное дело. Вот вам нужно добавить кнопку, просто одну кнопку на форму. И что у нас получается?
D>Вот вы добавляете мелкую такую кнопку, а у вас, бах, весь код новый кодо-генератор переделал, просто напрочь все перепахал.
D>Кто по-сообразительнее, те обычно этот мусор весь убирают, а в текстовом редакторе меняют ровно то, что относится к вашей новой кнопке. Или даже так, генерируют новый код через дизайнер форм, а потом из такого кода руками убирают весь этот новоявленный рефакторинг так, чтобы дизайнер мог вновь подхватить сделанные вручную изменения.
D>В той же Visual Studio для WinForms это довольно четко было видно. То есть, грамотный коммит состоял только в том, чтобы добавить одну кнопку, потому что никто не хотел связываться с тем, а что там новый кодо-генератор навытворял в коде. Обычно какая-нибудь сущая фигня в изменениях, там окончание другое или еще что, а вот весь автоматически генерируемый код нелепо перелопачен.
D>Ну, и кому это счастье надо? Зачем тогда нужен визуальный редактор форм, если он вставляет палки в колеса, если с ним приходится мучаться?
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
M>>>Да в любой 1-7. Ты, видимо, Дельфи только на картинках и видел
I>>Как минимум в университете изучал, тогда творения Borland на CD'юках было найти проще многого осталного.
M>Значит, очень хорошо забыл
I>>Как минимум до 4-й версии, если не больше, не помню средств содания списков с заданным layout элементов.
M>TListBox
Может, и забыл, но не помню там средств задать произволный layout элементов.
I>>И что там с заданным layout элементов? Хотя б уровен AWT когда был достигнут?
M>Я понятия не имею, что такое AWT
Но как раз в AWT, помнится мне, я для такой возможности впервые видел стандартные средства, пусть и не самые удобные, но лучше, чем вручную клепать полностью. Что-то похожее было потом в ранних версиях Android в его стандартном SDK.
Здравствуйте, Ilya81, Вы писали:
M>>TListBox
I>Может, и забыл, но не помню там средств задать произволный layout элементов.
Что значит — произвольный?
I>>>И что там с заданным layout элементов? Хотя б уровен AWT когда был достигнут?
M>>Я понятия не имею, что такое AWT
I>Но как раз в AWT, помнится мне, я для такой возможности впервые видел стандартные средства, пусть и не самые удобные, но лучше, чем вручную клепать полностью. Что-то похожее было потом в ранних версиях Android в его стандартном SDK.
Здравствуйте, Marty, Вы писали:
M>Здравствуйте, Ilya81, Вы писали:
I>>Но как раз в AWT, помнится мне, я для такой возможности впервые видел стандартные средства, пусть и не самые удобные, но лучше, чем вручную клепать полностью. Что-то похожее было потом в ранних версиях Android в его стандартном SDK.
M>Чем тебе TListBox не угодил?
M>Или тут
M>Чего тебе не хватает?
I>>Может, и забыл, но не помню там средств задать произволный layout элементов.
M>Что значит — произвольный?
То и значит — на каждй элмент списка не одну строку, а две, одна в середине сверху, другая справа внизу, разными шрифтами, а слева внизу картинка; или наоборот во всяком смысле; в т. ч. две картинки, одна в рамке, также три строки, какие-то с линией слева, и все прочие возможне сочетания. Там есть возможность это задать?
