Как нам обустроить Lazarus?

поп ит

Поп IT - это же Столлман.

Лазарус, дельфи, да и формошлёпсто на нативных кутэ/гтк - не нужно. Это - дерьмо из нулевых, хватит уже дрочить на него, закопайте в могилу и оставьте в покое. Веб макаки показали вам, что фронт нужно делать и деплоить быстрее, чем вы это делаете в своём иде. Поэтому самая прогрессивная модель - это нативный «браузер» (который может быть хромиумом или теми же биндингами к этим вашим кутэ) + скриптуха. «Браузер» должен быть самым всратым и работать не обновляясь по 10 лет, а всё приложения доставляться в виде исходников, углифицированных, если вам угодно, но за такое вас натурально подвесят за яйца, четвертуют, расстреляют и отправят на 20 лет пилить лес, когда Столяров придёт к власти.

Вопросы явно не ко мне. Я лишь говорю, что утверждение про обязательный Lazarus для расширения Double Commander - неверное.

Я лишь говорю, что утверждение про обязательный Lazarus для расширения Double Commander - неверное.

Да, но не суть. Тут плясяли от гуя, а от гуя писать не нужно, это всё заканчивается тем, что автоматизируешь всё каким-нибудь xdotool, вот о чём я толкую.

Реквестирую примеры гуя, которые от гуя не плящут. Для саморазвития.

Не очень много будет примеров. Я хотел эмулятор терминала, который бы плясал не от окошек - и то не нашел.
Есть вим, который не совсем гуй, есть git gui, который построен именно что от консольного гита. На крысе еще есть genmon и с ним можно много чего делать, но далеко не всё. В гноме со скриптухой делают расширение, но я в них палкой не тыкал. Добавил бы еще i3, но я слышал о нём только краем уха.

Ну запиши такое же видео под окошки

Lazarus сам себя пересобирает за 1 минуту на i3, не то что ваши IDE на C++, Java и т.д. Как нам обустроить Lazarus? (комментарий)

Lazarus сам себя пересобирает

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

Lazarus так устроен, чтобы добавить пакеты/фишки он пересобирается полностью, что кстати не совсем хорошо, но хорошо что очень быстро.

Хорошо. Где можно посмотреть примеры работы с базой данных через компоненты Lazarus, доступные на палитре компонентов. Желательно с сервером Firebird 2.5.

https://wiki.lazarus.freepascal.org/Firebird/ru
Чтобы быстро - в Lazaruse [вкладка] - [готовые компоненты(классы)]:

• SQLdb - IBConnection, TSQLTransaction, TSQLQuery и т.д.
• Data Access - TDataSource
• Data Controls - TDBGrid, TDBNavigator и т.д.

Приложение должно отражать структуру данных. Чтобы пользователь ощущал, с чем реально работает.

ы/ощущал, с чем реально работает/поел говна/
fixed ftgj!
Ну и зачем пользователю любоваться, например, на наш eav или сырые ID? Ему это не нужно. Ему надо, чтобы с данными было удобно работать, а ты такой, ну ок, гриды, так гриды и топишь за то, чтобы он страдал. Лул. Нормальный вообще?

Но какие-то необходимые связанные таблицы он может обозреть и даже поработать с ними

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

И тут формы с визуальными компонентами позволяют отказаться от услуг JavaScript/HTML-кодеров

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

Дизайн GUI делается тут же в среде программирования.

Ты не можешь жить без конструктора формочек? В этом всё дело?

Тут же всё тестируется и всё одним человеком. Это быстро.

Жсники тоже бывают фуллстак и некоторые тоже умеют быстро шлёпать вебчик на своих реактах. В чём профит?

Какую такую «инфраструктуру обновления формочек» - вывести значок запуска приложения толстого клиента на Рабочие столы сотрудникам это так трудно? LOL

Над чем ты тут лолируешь? Обновлять твой толстый хрен тебе вдруг стало не надо, я понимаю? Один раз собрал и всё?

Готовые утилиты как примеры подойдут? https://wiki.freepascal.org/Projects_using_Lazarus_-_Databases_and_Tools

yyk

Да буден ОН!!! ))

ВОИСТИНУ НЕ СМОТРЯ НИ НА ЧТО!

тоже много лучше, чем наслоения фабрик на мидле и фронте…

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

А обратное бывает только от желания обеспечить себя смузи тёплым местом с непыльной работой при полном отсутствии ответственности «Это не я, это мой фреймворк!..» ))

Ладно, ладно, перегиб засчитываю.

Доо, все жирные клиенты только и могут что раком стоять…

А что им еще делать, если бд лагает? Она не очень быстрая.

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

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

И это всё на js-е….

Так-то жс не такой уж и тормозной, как вы все про него говорите.

После Eclipse и NetBeans хочу освоить Lazarus хотя бы на уровне знаний Delphi 3…7, с которых начинал.

Мсье знает толк в садомазозоокопрофилии.

Рекомендую также поставить Kylix на малинку.

Ну и зачем пользователю любоваться, например, на наш eav или сырые ID? Ему это не нужно. Ему надо, чтобы с данными было удобно работать, а ты такой, ну ок, гриды, так гриды и топишь за то, чтобы он страдал. Лул. Нормальный вообще?

В Delphi (и в Lazarus) есть невизуальный компонент TDataSet, который можно настроить на работу с определёнными полями записей выбранной таблицы (не UI-грид!) БД или сформированного SQL-набора данных.

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

И этот невизуальный компонент обязательно нужно класть на визуальную форму. По сути это экземпляр ORM / толстой модели, прибитый гвоздями к SQL и реляционной базе данных.

А двухсторонние привязки к любым объектам есть и во Vue, и в Angular.

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

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

В Delphi (и в Lazarus) есть невизуальный компонент TDataSet, который можно настроить на работу с определёнными полями записей выбранной таблицы (не UI-грид!) БД или сформированного SQL-набора данных.

Это типа достижение? Массив объектов с произвольным набором полей есть, наверное, везде. Где угодно можно брать данные из бд и делать с ними что хочешь. Кто руками будет тебе на дельфи гонять данные из датасета в грид и обратно в бд? Это часто требует нетривиальных телодвижений, на которые никто не пойдёт, ибо зачем и так сожрут.

Где угодно можно брать данные из бд и делать с ними что хочешь.

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

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

Алло. У тебя компоненты - это такой фреймворк или не фича языка? Чья бы корова, лул.

Это VCL (или как там в Lazarus аналог называется).

А вот Java JDK такого целостного фреймворка не имеет - только в Java EE для Web и сторонних библиотеках для формошлёпства. И NetBeans, например, не содержит в поставке ничего подобного для создания толстых клиентских приложений для работы с БД.

А вот Java JDK такого целостного фреймворка не имеет

А должен?

И NetBeans, например, не содержит в поставке ничего подобного

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

А должен?

Вообще - да.

Там можно делать тоже самое хоть на свинге.

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

Вообще - да.

Кому должен?

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

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

Библиотечный код пишется один раз.

Кто бы спорил. Вот в Delphi написали порядка 250 визуальных и невизуальных компонентов для языка Objet Pascal. В JBuilder были похожие «компоненты» для неотягощённого формошлёпства. Теперь и в Lazarus есть. Осталось только брать и решать поставленные задачи. А кто-то будет в сотый раз писать TableModel для грида, чтобы загнать датасет в него.

А кто-то будет в сотый раз писать TableModel для грида, чтобы загнать датасет в него.

Тот, кто в сотый раз его пишет делает это от чего? Просто по фану? От того, что настолько тупой, что не может взять свой старый код? Или может ему просто каждый раз нужно что-то немного другое и ему не подходит его грид?

Есть разные причины не оформлять свой код в отдельную библиотеку. Например, занятость. Или «за это мне не платят».

Или «за это мне не платят».

Не платят за то, что приходится 100500 раз подряд делать для каждого нового заказчика? Шта?

Шта?

И ещё кросс-лицензирование, раскрытие исходников — вот это всё.

И ещё кросс-лицензирование, раскрытие исходников — вот это всё.

И еще 100500 способов легально положить на это хер.

Для тех, кто хочет сделать docked editor под форточками. Проблема оказалась в пакете chmhelppkg. Не знаю кто из них кривой, пакеты для docking или chmhelppkg. Удаление последнего помогло поставить все нужные пакеты и пересобрать IDE успешно.