Основная претензия властей ЕС к Telegram - зашифрованные сообщения
Среди возможных обвинений: терроризм, наркотики, соучастие, мошенничество, отмывание денег, сокрытие данных, контент с педофилие
Как общение третьих лиц (зашифрованное или нет не суть) на платформе может превратиться в данные список обвинений? Типа я открыл клуб и если в нем торгуют наркотиками третьи лица то меня обвинят в торговле наркотиками?
Тем не менее, логика статьи мне кажется всё равно актуальной. Зачем писать:
Итак давайте все же начнем сначала, когда мы пишем код выше то значит что мы априори подразумеваем что нам не надо управлять varOfRectangle самостоятельно а чтобы он присвоился автоматически из item.varOfItem. Т.е. биндинг по природе своей подразумевает что мы отдаем присвоение какой-то переменной некому автоматическому механизму. Если Вы сделали так то зачем начали присваивать его вручную? Если Вам необходимо делать вручную или Вас не устраивает как работает биндинг то никто не мешает написать например так:
У меня есть ListView внутри Loader-а, который грузится какое то время, и есть currentIndex из файла конфигурации, который тоже грузится не сразу. И мне как то надо их свести вместе :)
Если интересно вот тут можете посмотреть как реализовано https://github.com/anilibria/anilibria-winmaclinux/blob/master/src/Views/OnlinePlayer.qml#L164 нечто похоже по описанию как Вам требуется.
readonly используется для кейсов где свойство инициализируется каким-то значением и в дальнейшем не может быть изменено. Удобно им пользоваться для случаев когда создается свой компонент и надо вытащить наружу какие-то свойства но извне их менять запрещено. Например я частенько вытаскиваю размер шрифта который используется внутри моего компонента наружу но менять его извне бессмысленно.
Если хочется забиндить свойства внутреннего компонента в другой компонент то проще всего сделать это через alias который создает bi-directional binding c и в целом решает полностью описанную Вами проблему.
Это ответ, ради ответа. Сути ни какой не несёт, банальная попытка оправдать себя.
Мой тезис: режим редактирования формы в редакторе обладает небольшим функционал (даже сравнивая с редактором Object Pascal) а также не интегрирован с режимом дизайнера, Object Inspector прочими вещами, и предназначен не для полноценного написания кода форм с нуля (что подтвердили и Вы и Ваши коллега в соседней ветке) а для правок в разных случаях когда дизайнер не может загрузить форму или просто разных небольших правок.
Ваш тезис: ну редактор формы есть значит в нем все можно делать и если я не могу там что-то делать то дело не в нем (в том что там мало функционала) а во мне.
Ни Lazarus ни Delphi не обязаны использовать тот же функционал, что используется в других языках. Ни один язык не пошёл по стопам Паскаля, и это их выбор.
Причем тут Паскаль? Я говорю исключительно о среде разработки и декларативном языке описания форм.
то есть вы подтверждаете, что вы не читаете что вам пишут? Я конкретно сказал, что можно делать так, как захочешь, если умеешь это делать!
А Вы подтверждаете что не читаете что я Вам пишу и уже повторил один и тот же тезис кучу раз но Вы его не видите?
Что именно не нравится в ответе? Что мешает редактировать, при том что маловероятно этим будешь заниматься?
Если инструмент нужен для того чтобы иногда что-то там подредактировать а не пользоваться постоянно то и функционала в нем будет соответственным образом а значит пользоваться им на постоянной основа будет неудобно.
lfm-файл спокойно редактируется вручную и зная все свойства компонентов мы можем полностью собрать всю форму вручную.
Очень маловероятно что этим будет пользоваться кто-то ещё, ведь в основном это нужно только для редактирования вещей, которые вызывают ошибку в данном модуле и должно это произойти из-за файла *.lfm.
Дак "спокойно редактируется" или "Очень маловероятно что этим будет пользоваться кто-то ещё" ?
Я же уже написал, данный дизайнер содержит практически все настройки, которые уже не надо прописывать вручную, а можно просто установить.
Еще раз, моя мысль следующая - в аналогичных средах разработки (каких уже упоминал в первом сообщении) если выбор когда я могу делать все через дизайнер или делать все через код (не код OP! а декларативный код). Т.е. мы можем использовать дизайнер или код и эти способы разработки равнозначны и полностью взаимозаменяемы. Т.е. у меня есть выбор либо я пишу код, либо я использую дизайнер, не исключена комбинация в любых пропорциях. В Delphi/Lazarus выбора нет, Вы либо используете дизайнер либо используете дизайнер. Да можно, но можно != удобно и функционально, редактировать код формы но сейчас это выглядит как режим пришитый сбоку.
Просто для информации. Подход code-first это когда я могу проводить 100% времени в текстовом редакторе формы и мне ни разу не понадобится ни для одной вещи открывать дизайнер.
lfm-файл спокойно редактируется вручную и зная все свойства компонентов мы можем полностью собрать всю форму вручную.
Можем, вот по лично Вашему опыту, сколько раз Вы и/или Выши знакомые разработчики так делали? Т.е. является ли это просто опциональным режимом или же это мейнстрим подход разработки?
И кстати в Lazarus в редакторе формы есть автоподстановка, чего нет даже в Delphi. За это респект авторам Lazarus.
Гениальный вывод. Железная логика. Браво. Полагаю что когда Вам нечего ответить но вроде как надо да еще и остаться в парадигме "Delphi круто, остальное фигня" вполне можно сделать какие угодно выводы, апеллировать к каким угодно вещам. Вы так делаете уже 5 сообщений подряд вместо аргументов высказываете информационный шум. Наша дискуссия закончена, не вижу смысла ее продолжать все равно толку от нее никакой.
Ооо, замечательное окно. И где удобнее? В RAD или в VS?
Поставьте студию и сравнивайте
А поиск компонента по названию, уж смешно) Он и в дизайнере есть
Сквозной поиск по названию (чего угодно), значению и любых их сочетаний, использование регулярных выражений причем как в одном файле так и нескольких, плюс все выше перечисленное можно использовать для замены. Все это есть в дизайнере?:)
Нет нельзя, те же бинды там делаются исключительно в xaml
Редактор есть, пиши. Нет функций - запроси. Никто не требовал их, их не создали
Я уже не понимаю или Вы действительно не понимаете о чем я пишу либо Вы троль. К слову я писал запросы на эту 12 лет назад и не один. Сделали?
Перевожу ваш "короткий путь" в реальный:В xaml надо вначале перейти в xaml если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новое значение.
Нажал Ctrl-F ввел title в поисковое поле нажал Enter, сразу оказался где надо и даже сам title уже введен что позволяет удалить его просто начав писать.
Наконец-то мы вышли на одну волну. Итак теперь давайте пойдем прочитаем мое самое первое сообщение в этом треде.
Самая большая проблема Delphi/Lazarus в том что для создания интерфейса необходимо использовать визуальный редактор и нет возможности набирать визуальную часть руками т.е. в виде подхода code-first.
И имел я в виду не вот это:
Именно по этому никто не запрашивает проверки ошибок или подсказки. Возможность зайти и что-то исправить текстом - есть, а больше ничего не нужно.
А полноценное создание/редактирование форм через код с полной интеграцией этого процесса в среде разработки. И этого в Delphi нет, что значит что я указал не на "выдуманное преимущество" а на реальную проблему. Что также значит что все мои тейки дальше полностью корректны. Спасибо что подтвердили это.
Если вы в WPF не можете всё сделать в дизайнере, то в Delphi абсолютно всё можно сделать в дизайнере. От и до.
В WPF также можно сделать все с нуля только в дизайнере.
Всё, абсолютно всё, можно сделать в дизайнере и сделать это на порядок быстрее.
Если сравнивать редактирование текста (с автоподсветкой, автоподстановкой и прочими фичами) и использование дизайнера, то редактирование текста будет почти всегда быстрее. Сравниваем: надо поменять title у компонента. В редакторе коде просто переходим на нужную позицию в тексте и пишем новый. В дизайнере надо вначале перейти в дизайнер если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новый. Просто даже по количеству действий второй подход уже проигрывает.
И всё работает в дизайнтайм, в отличие от WPF (даже биндинги, они тут тоже есть и работают "на горячую").
Окей не для разогрева спора и не для "выдумывания" давайте тогда более предметно говорить. Скачал триал Delphi, версия ниже на скрине:
Который ты можешь редактировать, даже не открывая дизайнер. С подсветкой синтаксиса и всем прочим.
Я правильно понимаю что Вы говорите вот об этом? Если перейти в этот режим (назовем "режим dfm" а обратный "режим формы") то да открывается dfm файл и в нем есть подсветка синтаксиса. Авто дополнение не работает (пробовал Ctrl+Enter/Ctrl+Space/Ctrl+Shift+C). Ошибки не подсвечиваются в тексте, и проверяются ошибки только если перейти обратно в режим формы. Сообщения об ошибках отображаются только внутри диалогового окна. Ну и самое главное а куда девается визуальная форма и почему содержимое Structure и Object Inspector куда-то исчезает? Т.е. остается активным только текстовый редактор с dfm.
Итак теперь давайте просто сравним с чем-то другим ну потому что мы тут про сравнения же. Итак вот как тоже самое выглядит где-то еще:
Тут у меня открыто редактирование разметки и это полноценный редактор с автодополнением "и прочим", и да ошибки прямо в коде подсвечиваются. При этом и визуальный дизайнер доступен и Toolbox (тоже самое что Object Inspector), можно и через него добавлять и через код и оно синхронизируется. Если я в коде что-то добавляю то сразу вижу изменение в визуальном представлении.
Итак что у нас в сухом остатке:
Авто дополнения нет
Подсветка ошибка в коде нет, вместо этого необходимость для проверки переходить в режим формы и читать ошибки в диалоговом окошке
Просмотр изменений в визуальном редакторе сразу после изменения текста нет, для просмотра каждый раз надо переходить в режим формы
Пользоваться Structure и Object Inspector нельзя
Я допускаю что возможно можно что-то настроить чтобы что-то из выше перечисленного начало работать (укажите где я еще раз посмотрю) или возможно чего-то не хватает из-за того что триал версия.
И в любой момент ты можешь просто взять и посмотреть код твоей формы. Изменять, удалять и создавать новые элементы.
Уж простите но как это не вяжется с
Но с нуля форму писать текстом нет никакого смысла. Гуглить каждый класс контрола, писать вручную все его свойства. Накой черт этим заниматься, если можно просто выбрать из списка, увидеть все доступные свойства и изменить на свой вкус?
Т.е. ничего создавать и изменять Вы не сможете без дизайнера. И более того все значения всех свойств Вы тоже не знаете что сводит смысл в каком-либо редактировании этого текста на нет (ну кроме каких-то минимальных вещей).
И при этом я не имею никаких ограничений, который ты выдумываешь.
Редактирование формы через блокнот смахивает на ограничение. Уж простите но вообще то среда разработки должна иметь средство редактирования таких файлов внутри себя, иметь подсветку синтаксиса, подсветку ошибок а также автодополнение имен классов и свойств и этого всего в RAD Studio нет. Просто Вы занимаетесь странными вещами что-то там редактируя через блокнот и просто не видите что это является проблемой. Возможно для Вас это не проблема конечно но со стороны это выглядит странно.
Вот это можешь скопировать и нажать Ctrl+V на форме или любом контроле
Images = ImageList24
Что это такое? и что я получу скопировав это? У меня нет этого компонента:)
"построить интерфейс в рантайме" если Вы про то что можно просто кодом создавать компоненты то нет простите это еще менее удобней. Давайте я Вам на примере покажу, вот допустим я решил скинуть своему тиммейту кусочек дизайна страницы как пример решения
Теперь проверните такой трюк с Delphi/Lazarus/RAD Studio... Сделаете скриншот Object Inspector? Сделаете скриншот Structure? Сделаете скриншот Form Designer? Или всего сразу?
Тоже самое касается документации в которой нет кода, там сплошные скриншоты вышеупомянутых окошек. Это относиться к таким моментам что нельзя открыть на гите и понять что у тебя там на форме без RAD Studio (нельзя сделать фикс в блокноте или любом другом текстовом редакторе за пределами RAD Studio) и много других казалось бы маленьких моментов из-за которых удобство убивается. Еще раз я не говорю что язык плохой, среда плохая и в целом инструмент плохой и все это не развивается, я говорю что конкретно этот аспект остался таким каким был еще со времен Delphi 5 (когда я впервые начал на нем разрабатывать) и не менялся чуть более чем полностью. Подход "редактируем дизайн только в дизайнере" это уже устаревший подход. Сейчас программисты для дизайна используют декларативные языки а если прям есть настоящие дизайнеры в команде то для них есть специальный отдельный продукт где да все редактируется в визуальных дизайнерах, такое есть и в Visual Studio(Blend) и в Qt(Design Studio) и много где еще.
Самая большая проблема Delphi/Lazarus в том что для создания интерфейса необходимо использовать визуальный редактор и нет возможности набирать визуальную часть руками т.е. в виде подхода code-first. Я когда в свое время с большим бекграундом Pascal/Delphi перешел в Web и на другие desktop платформы понял что визуальное представление скорее мешает чем помогает в разработке. Все более современные на тот момент платформы разработки уже перешли на вариант когда ты описываешь визуальный интерфейс в виде HTML/XML/CSS/JSON/YAML/.. декларативного кода. В Delphi/Lazarus тоже есть такой вариант в виде dfm/lfm/fmx файлов но средства для адекватного редактирования этих файлов в среде разработки нет. На мой взгляд добавление такого средства или добавления декларативного языка помогло бы языку стать более современным средством разработки.
А почему для описания не использовать .ui файлы? или вообще QML? Портянки кода для создания виджетов выглядят жирными и не читаемыми.
Как общение третьих лиц (зашифрованное или нет не суть) на платформе может превратиться в данные список обвинений? Типа я открыл клуб и если в нем торгуют наркотиками третьи лица то меня обвинят в торговле наркотиками?
В Готике тоже была настоящая ночь и без факела или заклинания свет не видно было буквально ничего.
Итак давайте все же начнем сначала, когда мы пишем код выше то значит что мы априори подразумеваем что нам не надо управлять varOfRectangle самостоятельно а чтобы он присвоился автоматически из item.varOfItem. Т.е. биндинг по природе своей подразумевает что мы отдаем присвоение какой-то переменной некому автоматическому механизму. Если Вы сделали так то зачем начали присваивать его вручную? Если Вам необходимо делать вручную или Вас не устраивает как работает биндинг то никто не мешает написать например так:
Таким образом можно сделать биндинг просто кодом.
Если интересно вот тут можете посмотреть как реализовано https://github.com/anilibria/anilibria-winmaclinux/blob/master/src/Views/OnlinePlayer.qml#L164 нечто похоже по описанию как Вам требуется.
readonly используется для кейсов где свойство инициализируется каким-то значением и в дальнейшем не может быть изменено. Удобно им пользоваться для случаев когда создается свой компонент и надо вытащить наружу какие-то свойства но извне их менять запрещено. Например я частенько вытаскиваю размер шрифта который используется внутри моего компонента наружу но менять его извне бессмысленно.
Если хочется забиндить свойства внутреннего компонента в другой компонент то проще всего сделать это через alias который создает bi-directional binding c и в целом решает полностью описанную Вами проблему.
High tech. Low life.
Мой тезис: режим редактирования формы в редакторе обладает небольшим функционал (даже сравнивая с редактором Object Pascal) а также не интегрирован с режимом дизайнера, Object Inspector прочими вещами, и предназначен не для полноценного написания кода форм с нуля (что подтвердили и Вы и Ваши коллега в соседней ветке) а для правок в разных случаях когда дизайнер не может загрузить форму или просто разных небольших правок.
Ваш тезис: ну редактор формы есть значит в нем все можно делать и если я не могу там что-то делать то дело не в нем (в том что там мало функционала) а во мне.
Причем тут Паскаль? Я говорю исключительно о среде разработки и декларативном языке описания форм.
А Вы подтверждаете что не читаете что я Вам пишу и уже повторил один и тот же тезис кучу раз но Вы его не видите?
Если инструмент нужен для того чтобы иногда что-то там подредактировать а не пользоваться постоянно то и функционала в нем будет соответственным образом а значит пользоваться им на постоянной основа будет неудобно.
Дак "спокойно редактируется" или "Очень маловероятно что этим будет пользоваться кто-то ещё" ?
Еще раз, моя мысль следующая - в аналогичных средах разработки (каких уже упоминал в первом сообщении) если выбор когда я могу делать все через дизайнер или делать все через код (не код OP! а декларативный код). Т.е. мы можем использовать дизайнер или код и эти способы разработки равнозначны и полностью взаимозаменяемы. Т.е. у меня есть выбор либо я пишу код, либо я использую дизайнер, не исключена комбинация в любых пропорциях. В Delphi/Lazarus выбора нет, Вы либо используете дизайнер либо используете дизайнер. Да можно, но можно != удобно и функционально, редактировать код формы но сейчас это выглядит как режим пришитый сбоку.
Просто для информации. Подход code-first это когда я могу проводить 100% времени в текстовом редакторе формы и мне ни разу не понадобится ни для одной вещи открывать дизайнер.
Можем, вот по лично Вашему опыту, сколько раз Вы и/или Выши знакомые разработчики так делали? Т.е. является ли это просто опциональным режимом или же это мейнстрим подход разработки?
И кстати в Lazarus в редакторе формы есть автоподстановка, чего нет даже в Delphi. За это респект авторам Lazarus.
Гениальный вывод. Железная логика. Браво. Полагаю что когда Вам нечего ответить но вроде как надо да еще и остаться в парадигме "Delphi круто, остальное фигня" вполне можно сделать какие угодно выводы, апеллировать к каким угодно вещам. Вы так делаете уже 5 сообщений подряд вместо аргументов высказываете информационный шум. Наша дискуссия закончена, не вижу смысла ее продолжать все равно толку от нее никакой.
Поставьте студию и сравнивайте
Сквозной поиск по названию (чего угодно), значению и любых их сочетаний, использование регулярных выражений причем как в одном файле так и нескольких, плюс все выше перечисленное можно использовать для замены. Все это есть в дизайнере?:)
Я уже не понимаю или Вы действительно не понимаете о чем я пишу либо Вы троль. К слову я писал запросы на эту 12 лет назад и не один. Сделали?
Нажал Ctrl-F ввел title в поисковое поле нажал Enter, сразу оказался где надо и даже сам title уже введен что позволяет удалить его просто начав писать.
Наконец-то мы вышли на одну волну. Итак теперь давайте пойдем прочитаем мое самое первое сообщение в этом треде.
И имел я в виду не вот это:
А полноценное создание/редактирование форм через код с полной интеграцией этого процесса в среде разработки. И этого в Delphi нет, что значит что я указал не на "выдуманное преимущество" а на реальную проблему. Что также значит что все мои тейки дальше полностью корректны. Спасибо что подтвердили это.
В WPF также можно сделать все с нуля только в дизайнере.
Если сравнивать редактирование текста (с автоподсветкой, автоподстановкой и прочими фичами) и использование дизайнера, то редактирование текста будет почти всегда быстрее. Сравниваем: надо поменять title у компонента. В редакторе коде просто переходим на нужную позицию в тексте и пишем новый. В дизайнере надо вначале перейти в дизайнер если еще не в нем, далее находим нужный компонент, находим нужное свойство и пишем новый. Просто даже по количеству действий второй подход уже проигрывает.
Все работает в design time и в WPF.
Окей не для разогрева спора и не для "выдумывания" давайте тогда более предметно говорить. Скачал триал Delphi, версия ниже на скрине:
Я правильно понимаю что Вы говорите вот об этом? Если перейти в этот режим (назовем "режим dfm" а обратный "режим формы") то да открывается dfm файл и в нем есть подсветка синтаксиса. Авто дополнение не работает (пробовал Ctrl+Enter/Ctrl+Space/Ctrl+Shift+C). Ошибки не подсвечиваются в тексте, и проверяются ошибки только если перейти обратно в режим формы. Сообщения об ошибках отображаются только внутри диалогового окна. Ну и самое главное а куда девается визуальная форма и почему содержимое Structure и Object Inspector куда-то исчезает? Т.е. остается активным только текстовый редактор с dfm.
Итак теперь давайте просто сравним с чем-то другим ну потому что мы тут про сравнения же. Итак вот как тоже самое выглядит где-то еще:
Тут у меня открыто редактирование разметки и это полноценный редактор с автодополнением "и прочим", и да ошибки прямо в коде подсвечиваются. При этом и визуальный дизайнер доступен и Toolbox (тоже самое что Object Inspector), можно и через него добавлять и через код и оно синхронизируется. Если я в коде что-то добавляю то сразу вижу изменение в визуальном представлении.
Итак что у нас в сухом остатке:
Авто дополнения нет
Подсветка ошибка в коде нет, вместо этого необходимость для проверки переходить в режим формы и читать ошибки в диалоговом окошке
Просмотр изменений в визуальном редакторе сразу после изменения текста нет, для просмотра каждый раз надо переходить в режим формы
Пользоваться Structure и Object Inspector нельзя
Я допускаю что возможно можно что-то настроить чтобы что-то из выше перечисленного начало работать (укажите где я еще раз посмотрю) или возможно чего-то не хватает из-за того что триал версия.
Уж простите но как это не вяжется с
Т.е. ничего создавать и изменять Вы не сможете без дизайнера. И более того все значения всех свойств Вы тоже не знаете что сводит смысл в каком-либо редактировании этого текста на нет (ну кроме каких-то минимальных вещей).
Редактирование формы через блокнот смахивает на ограничение. Уж простите но вообще то среда разработки должна иметь средство редактирования таких файлов внутри себя, иметь подсветку синтаксиса, подсветку ошибок а также автодополнение имен классов и свойств и этого всего в RAD Studio нет. Просто Вы занимаетесь странными вещами что-то там редактируя через блокнот и просто не видите что это является проблемой. Возможно для Вас это не проблема конечно но со стороны это выглядит странно.
Что это такое? и что я получу скопировав это? У меня нет этого компонента:)
Моя форма может быть меньше/больше переданных размеров то что тогда?
Что если на моей форме уже есть Button1?
"построить интерфейс в рантайме" если Вы про то что можно просто кодом создавать компоненты то нет простите это еще менее удобней. Давайте я Вам на примере покажу, вот допустим я решил скинуть своему тиммейту кусочек дизайна страницы как пример решения
В случае допустим XAML я скину следующее:
В случае QML я скину следующее:
В случае HTML я скину следующее:
Теперь проверните такой трюк с Delphi/Lazarus/RAD Studio... Сделаете скриншот Object Inspector? Сделаете скриншот Structure? Сделаете скриншот Form Designer? Или всего сразу?
Тоже самое касается документации в которой нет кода, там сплошные скриншоты вышеупомянутых окошек. Это относиться к таким моментам что нельзя открыть на гите и понять что у тебя там на форме без RAD Studio (нельзя сделать фикс в блокноте или любом другом текстовом редакторе за пределами RAD Studio) и много других казалось бы маленьких моментов из-за которых удобство убивается. Еще раз я не говорю что язык плохой, среда плохая и в целом инструмент плохой и все это не развивается, я говорю что конкретно этот аспект остался таким каким был еще со времен Delphi 5 (когда я впервые начал на нем разрабатывать) и не менялся чуть более чем полностью. Подход "редактируем дизайн только в дизайнере" это уже устаревший подход. Сейчас программисты для дизайна используют декларативные языки а если прям есть настоящие дизайнеры в команде то для них есть специальный отдельный продукт где да все редактируется в визуальных дизайнерах, такое есть и в Visual Studio(Blend) и в Qt(Design Studio) и много где еще.
Самая большая проблема Delphi/Lazarus в том что для создания интерфейса необходимо использовать визуальный редактор и нет возможности набирать визуальную часть руками т.е. в виде подхода code-first. Я когда в свое время с большим бекграундом Pascal/Delphi перешел в Web и на другие desktop платформы понял что визуальное представление скорее мешает чем помогает в разработке. Все более современные на тот момент платформы разработки уже перешли на вариант когда ты описываешь визуальный интерфейс в виде HTML/XML/CSS/JSON/YAML/.. декларативного кода. В Delphi/Lazarus тоже есть такой вариант в виде dfm/lfm/fmx файлов но средства для адекватного редактирования этих файлов в среде разработки нет. На мой взгляд добавление такого средства или добавления декларативного языка помогло бы языку стать более современным средством разработки.