Вопрос о совместимости Delphi и Lazarus

[IUnknown]

Ну что вы к виду прицепились

Некоторые видимо дальше делфи видеть не в состоянии, все что непривычно - то ужасно. Если уж работать с БД, то действительно луше на MSEide. Эта среда хотя бы не сыпет эксепшенами при самых тупейший операциях

[haword]

Ну что вы к виду прицепились

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

Как сказал один хороший маркетолог но очень уж ругаемый всеми Билли сначало надо сделать красивый вид а потом уже доделывать функциональность! Сдесь же отпугивающий вид с хорошим функционалом! Как видно по истории, на начальной стадии продукта стратегия Билли обычно выигрышная!
Как же тут не прицепиться, во первых вид отдаленно напоминающий какие либо боле мнее приличные контролы а во вторых изменить ихний вид или прорисовку (я не имею ввиду цвет и размер) стандартными обработчиками не изменяя сам тулкит невозможно! Это уже не дело! У лазаря и делфи все с этим делом в пордяке. Вот если бы кто нить портировал MSEGUI или LPTK в лазарь как интерфейс типа GTK или QT вот тогда бы было бы классно! Никаких доплонительных либ и возможности почти как у Делфи сделали бы из него хорошую, функциональную, совместимую с Делфи открытую IDE!

[Guest]

Для начала, лично я считаю, что огромной услугой Лазурусу стала бы "прикрутка"  JVCL3 ( не путать с JCL ) - там по части БД ( да и не только ) очень много классного сделано.

Проблема в диком нежелании ментейнеров проекта снимать зависимость от win32 кода и интерфрейсов. Этот вопрос регулярно в ньюсах пробегает и ответ тот же. Не будем! Но, если выдрать некий субсет компонентов,то вполне возможно, но тогда это будет отдельный продукт. ИМХО в JVCL3 слишком много ненужных компонентов, зачастую дублирующих друг друга.

Смотрел... Win32-специфичного там - мизер.
JCL3 ( не jVcl! ) так вобще портируется с 2-х пинков - как правило, нужно подправлять синтаксис доступа к адресам ( {$ifdef FPC}@{$endif}var ) и правильно выставлять режим совместимости компилятора ( у меня даже где-то валяется спортированная - но она не особо нужна само по себе, а просто требуется в JVCL3 ).

Сам FPC лимитирован как ЯЗЫК вообще только в паре мест, где затребованы DIspinterface & Implements, а уж Implements заменить...
Все ! Остальное - только мозгами поработать, дописать несколько функций с вызовом из WIN32 API доки ( скомбинировав несколько оных из уже готовых в лазарусе ) - и ажур... Беда, что мозги все-же толковые нужны, жаль, что у самого это не получается.

Команду JVCL3 понимаю - ведь это придется перелопатить все дерево проекта, IFDEF-ы раставить, нафига им это - за бесплатно-то ?
Так что Вы правы - надо выделить из JVCL3 имено те компоненты, которые закроют те дыры в LCL, которые врядли когда-либо будут закрыты самой LCL ввиду особой сложности реализции ( опять-таки из-за бесплатности работы ) - полноценные БД-компоненты и т.д., и попытаться-таки адаптировать...

Короче, пока нет нормальной поддержки БД - Лазарус остается красивой и тяжеловесной игрушкой ( нафига еще под Линукс софт, кроме как не для серьезной работы - БД и т.п. ??? Поэтому не понимаю людей, которым нужны хуки на процедуры вроде OnPaint, им что - нечем заняться ? ) ...

Даже "бедный" MSEGUI, хоть и мал, но удал - на нем УЖЕ можно многое делать... И свои изменения в него можно вносить с пол-пинка, потому что все - весьма прозрачно и логично, и не нужны никакие PACKAGE - потому что проще не придумаешь.. (автор даже позаботился о том, чтобы его специфичные компоненты не путались с привычными - у них есть прификс из его инициалов, пусть это и не совсем скромно выглядит ).
СпрОсите, а где сетевые компоненты - так есть отличная библиотека Synapse...

Короче, народ, хорош языком молоть в непрестанных поисках "идельной среды разработки" ( каковой не может быть по-определению ввиду многообразия задач ) - а давайте дело делать ! Мы же - рунет, любители халявы - так и надо довести халяву до ума

[STAKANOV]

Ну что вы к виду прицепились

Некоторые видимо дальше делфи видеть не в состоянии, все что непривычно - то ужасно. Если уж работать с БД, то действительно луше на MSEide. Эта среда хотя бы не сыпет эксепшенами при самых тупейший операциях

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

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

А вот для линукс (ИМХО) ничего лучше MSEgui нет.

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

Идельной кроссплатформенности не получилось. Что по-моему и невозможно.

[Гость_Haword]

Pravilno, xuki na OnPaint nenuzny kogda pises dla sebya i ne obrasaya vnimanie na interfeis, a esli ne tolko dla sebya, narod ot takogo interfeisa vorotit.

[Guest]

Pravilno, xuki na OnPaint nenuzny kogda pises dla sebya i ne obrasaya vnimanie na interfeis, a esli ne tolko dla sebya, narod ot takogo interfeisa vorotit.

Переписка кода OnPaint подразумевает детальное знание низкоупровневого GUI API. Ну если Вы = гуру в X11-рисовании под Линукс - тогда извиняюсь...

Насчет непривычного поведения - именно в тех местах, где привык до автоматизма... Тут нужно автора MSEGUI убеждать, и не типа "мне не нравится" или "а вот если бы", он - профессионал и игнорирует такие "эмоциональные" доводы.
И еще, у нас с "ними" разница менталитетов сказывается - из-за тотально использования у нас пиратского софта от практически исключительно MS$. "Там" же привыкли покупать и считать каждую копейку, и потому намного больше заказных продуктов - в которых программист все делает по своему усмотрению и затем объясняет конечному пользователю энти свои "усмотрения". Пользователь запишет на бумажке, а через неделю вообще привыкнет - и нет проблемы.
Отлично знаю этот сценарий - по своей работе, когда совершенно дремучая девушка из узбекистанской провинции - через неделю лихо переключается между 2-мя линуксовыми X11-консолями, и т.п.
Потому, во-многом понимаю идею Мартина "пользователю вообще пофигу, лишь бы пользу приносило"...

Кстати, версия "нерисующего", использующего Win32-виджеты MSEGUI - весьма интересная. Тогда, я так понял - нравится сама IDE, пусть и "перемудренная" ? Переизбыток настроек, кстати, совсем перестал напрягать - после того, как изменения от умолчаний стали отображаются выделенным шрифтом, и теперь - всегда легко вернуться, если "заблудился"...

Вообще, это классно - что даже среди open-source проектов может быть нечто вроде конкуренции, пусть и не денег, а идей и честолюбий...

[haword]

Переписка  кода OnPaint подразумевает детальное знание низкоупровневого GUI API. Ну если Вы = гуру в X11-рисовании под Линукс - тогда извиняюсь...

Не ну как бы тебе сказать то Во ВСЕХ других продуктах тоесть Лазаре и Delphi Kylix это делается проще, пишешь что то типа
procedure Paint (TMessage); message WM_PAINT; override
или для лазаря
procedure Paint (TLMessage); message LM_PAINT; override
и все, дальше дело вкуса, берешь Canvas и рисуешь рисуешь и еще раз рисуешь какие тебе нравится загугулины на интерфейсе! Думаю это не сильно сложно Куда неправильнее править прямые ссылки на прорисовку в самих виджетах Хоть бы добавил евент на перерисовку и то легче было бы потом к стандартному виду виджеты привести его!

[Guest]

Переписка  кода OnPaint подразумевает детальное знание низкоупровневого GUI API. Ну если Вы = гуру в X11-рисовании под Линукс - тогда извиняюсь...

Не ну как бы тебе сказать то Во ВСЕХ других продуктах тоесть Лазаре и Delphi Kylix это делается проще, пишешь что то типа
procedure Paint (TMessage); message WM_PAINT; override
или для лазаря
procedure Paint (TLMessage); message LM_PAINT; override
и все, дальше дело вкуса, берешь Canvas и рисуешь рисуешь и еще раз рисуешь какие тебе нравится загугулины на интерфейсе! Думаю это не сильно сложно Куда неправильнее править прямые ссылки на прорисовку в самих виджетах Хоть бы добавил евент на перерисовку и то легче было бы потом к стандартному виду виджеты привести его!

Где реально подразумевается USER-рисование (картинки,... ), хуки на процедуры = (On/Before/After)Paint доступны, причем - обратите внимание на дополнительные Before/After, то есть - мало не покажется, и в этом - преимущество перед MESSAGE-ориентированным способом вызова этих хуков ( делать сообщения для before/after = маразм ).

Где не подразумевается - кнопки, лэйблы, там и убрано из published-секций. Если есть большое желание - можете в тех виджетах, где Вам нужны (On/Before/After)Paint, подредактировать переназначение видимости этих хуков, чтобы они ушли из protected в published, и перекомпилировать MSEIDE.

Или, чтобы не редактировать файлы после каждого нового снэпшота - унаследовать без-paint-ные виджеты, назвать их THaword<Widget>, назначить в них (On/Before/After)Paint как published, добавить в палитру, перекомпилировать и радоваться жизни...

Вообще, как я понял, способ доказать что-либо автору MSEGUI - это привести пример РЕАЛЬНОЙ ( из жизни ПОЛЬЗОВАТЕЛЕЙ, А НЕ ПРОГРАММИСТОВ ) необходимости некой фичи. Так было, например, с фильтрацией LookupBuffers - человек ему привел конкретные примеры, и не прошло и 2-х дней, как фича появилась.

[haword]

Гм, я думаю маразм вместо одного события OnPaint делать два которые вызываются до и после, хм, токо гений мог до такого додуматься если я перерисую компонент как мне надо до того как он наложит свою прорисовку то после него что от моей прорисовки останется то а? И вообще то, есть такая чтука как inherited, она вызовет обработку этого события у родителя, так что его задумка по поему мнению маразм полный у него гон на почве того чтобы все делать не так как у борланда хоть как но только не как у них

[Guest]

Гм, я думаю маразм вместо одного события OnPaint делать два которые вызываются до и после, хм, токо гений мог до такого додуматься если я перерисую компонент как мне надо до того как он наложит свою прорисовку то после него что от моей прорисовки останется то а? И вообще то,  есть такая чтука как inherited, она вызовет обработку этого события у родителя, так что его задумка по поему мнению маразм полный у него гон на почве того чтобы все делать не так как у борланда хоть как но только не как у них

маразм - делать одно событие...
before - чтобы повлиять на inherited-прорисовку, изменить canvas и т.п.
во-вторых- эти хуки самому автору нужны, тогда почему бы не вынести их в public-интерфейс ?

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

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

[Иван Шихалев]

и MSEGUI делался 9 лет

Серьезно??? Тогда ж еще FPC 1.0 даже не было…

[Guest]

и MSEGUI делался 9 лет

Серьезно??? Тогда ж еще FPC 1.0 даже не было…

Я тоже удивился было А потом вспомнил и про другие, более "древние", много-платформенные паскали - VirtualPascal ( один из любимцев ), TMT,... или на Win32+ObjectPascal начинал, а потом, как FPC приблизился по фичам - переключился на него...

[STAKANOV]

и MSEGUI делался 9 лет

Серьезно??? Тогда ж еще FPC 1.0 даже не было…

Так он и не с fpc начинал. Да и наверно всетаки 6-7, а не 9.

Народ! Я что-то не понял про OnPaint. Может моя статья поможет - <a href='http://freepascal.ru/article//mse/20060205191314/' target='_blank'>http://freepascal.ru/article//mse/20060205191314/</a> ?

[haword]

маразм - делать одно событие...
before - чтобы повлиять на inherited-прорисовку, изменить canvas и т.п.
во-вторых- эти хуки самому автору нужны, тогда почему бы не вынести их в public-интерфейс ?

Ну да в одном событии это уже сделать нельзя, сначало изменить канвас потом вызвать inherited. Надо это делать в разных обработчиках млин!
Вот и я про то же, почему если он такой блин профи не вынес их в паблик? Боится что кто то его гениальный интерфейс на свой лад и вкус перерисует? Конечно бывают люди умные, но когда эти умные начинают страдать звездной белезнью это не очень хорошо заканчивается! Перестанет он делать свои добавления в каждой версии, стабилизирует хоть немного его, не в палне добавлений новых фичей а в плане утранения багов, тогда можно будет форкнуть его и попробовать придать компонентам нормалный вид

[haword]

и MSEGUI делался 9 лет

Серьезно??? Тогда ж еще FPC 1.0 даже не было…

Так он и не с fpc начинал. Да и наверно всетаки 6-7, а не 9.

Народ! Я что-то не понял про OnPaint. Может моя статья поможет - <a href='http://freepascal.ru/article//mse/20060205191314/' target='_blank'>http://freepascal.ru/article//mse/20060205191314/</a> ?

У визуальных компонентов НЕТУ это свойства в паблике! Я не могу придать приличный вид не кнопке на форме не чекбоксу не комбобоксу не гриду! Вот в чем проблема!