>>> Да никто не борется уважаемый.
Значит или показалось или ТЕ ещё не отошли после 8 марта - не проснулись :)
На деньги M$ я не расчитываю. Это грязные деньги! Зелёные, да и висят высоко :)

>>> Какие претензии в смысле "негуевости" к Блэкбоксу?
"Не смешно, зато больно" - на Дельфи не похоже.

"Мозгу у пришельцев килограмм примерно шесть,
а у наших предков - только челюсти да шерсть".
Если Вам всё просто и понятно в ББ, то нормальным людям :) непривычно.

Сделать бы лазейку - западёнку в ББ в виде проекта
"сунь дельфист пальчик - там сидит зайчик".
Или это мост от Маниловки до Санкт-Питербурга?

Сходив по Вашей ссылке на форуме ББ правильный ли я сделал вывод,
что если так приспичило создать мини-Дельфи в ББ (или мини Lazarus)
в плане бросания кнопок, текстовых боксов, картинок и гридов(?),
то в своём проекте реально создать панель инструментов и их бросать
для компоновки простого GUI. (Есть соответствующие обработчики).

Другое дело - привязывание простейших событий Click, MouseDown
к тексту программы. Или тут тоже есть решения?

Общий вопрос - какие принципиальные технические сложности создания
элементарной квазидельфи в ББ?

И частный - как с гридами? Что-то не пойму есть ли они? Или я плохо искал?

Ещё вопросик по той же ссылке на форуме. Вы писали
>>> кладем несколько отображений-форм (FormViews),
>>> на них накидываем графики (я кинул из Excel
Excel как поддерживается - по OLE или на манер OpenOffice?

>>> Структура VCL плохо воспроизводима в Обероне
>>> VCL - чисто ООП продукт
Я тут про "поубивать наследование", про устаревший VCL, понимаешь ...
Почему визуальные контролы могут быть только чисто ООП? Не вижу причин.

Ответ на »сообщение 3100« (Илья Ермаков)
___________________________

Здравствуйте, Илья.
Прошу прощения за некоторый оффтопик.
Вы где-то говорили, что пытаетесь использовать BlackBox
под wine, появлялись разные проблемы и в конце концев
Вы остановились на дистрибутиве ASP Linux Ладога.
Вы не пробовали Linux XP Desktop?

С уважением,

>>>Ну, нет изобилия готовых контролов - дописывать надо, кто спорит? Народ и
>>>дописывает, пока в основном под себя... Но больше и больше. А количество,
>>>как извествно, со временем переходит в качество.
Мне кажется, что многие критики оберонов забывают о главном в  их идеологии - об идеологии модульно-компонентного подхода. Что такое каркас Блэкбокса? Это МИНИМАЛЬНО необходимый набор компонентов. Минимальный - значит "без рюшечек". Хотите рюшечки - пишите компоненты. И тогда у Вас будет своя "а-ля VCL" над каркасом ББ. Не хуже, чем у Delphi. А может и лучше за счет более надежной и продуманной общей архитектуры системы. Проблема не в том, чтобы написать компоненты-рюшечки. Проблема в том, кто и на какие средства будет это делать. И про якобы нежелание обероновцев заниматься такими вещами - это все миф. Может такие обероновцы-ортодоксы и есть, но я их не встречал в природе. Я бы, например, вовсе не отказался иметь для Оберона такую же IDE и Component Library, как в Delphi или VS. Естественно при полном сохранении идеологии Оберона. В общем, если перефразировать кота Матроскина: ум у нас есть - средств не хватает.

Ответ на »сообщение 3101« (Geniepro)
___________________________

И как же определить эту меру? Что для Вас чрезмерно, возможно, для меня (или любого другого) - недостаточно. И наоборот...

Мера определяется не так уж сложно: на одной чаше весов трудозатраты (время, люди, финансы и др. ресурсы), на другой -- функционал и эргономика/эстетика(сервисы, рюшечки и т.д. и т.п.).

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

Ответ на »сообщение 3095« (Как слышно? Приём!)
___________________________
>>>Тем не менее, ощущается очень отчетливое отторжение этих инструментов
со стороны адептов Оберона.
Тут должен возразить.
Структура VCL плохо воспроизводима в Обероне вовсе не из снобизма. VCL - чисто ООП продукт. С этим связаны ее сильные и слабые стороны.
В Обероне наработаны свои интерфейсы пользователя, основанные на другом подходе. Они не похожи на VCL и не могут быть похожи. То, что по Вашему мнению они менее развиты, вовсе не означает, что разработчики оберонов не считают это нужным.

Ответ на »сообщение 3097« (Руслан Богатырев)
___________________________

Эстетика и удобство пойдут только на пользу, если цена за них не будет чрезмерной.

И как же определить эту меру? Что для Вас чрезмерно, возможно, для меня (или любого другого) - недостаточно. И наоборот...

Ответ на »сообщение 3095« (Как слышно? Приём!)
___________________________

Ответ на »сообщение 3091« (Руслан Богатырев)
___________________________
Почему реализация хотя бы простейших кнопок, таблиц в стиле Дельфи
(с исходниками, показывающими как это сделать и соответственно развить)
противоречит духу Оберона? Снижение порога вхождения вредно?
Требуется закалка воли и разума или повышение сноровки во владении клавиатурой
опосредовано, как у детей 3-х летнего возраста, благотворно влияет на развитие
нужных участков мозга неокрепшего программиста?

Ну уважаемый, что Вы ерунду-то говорите... Напомните, кто когда и где отвергал эти вещи...
Какие претензии в смысле "негуевости" к Блэкбоксу? Framework там по архитектуре мощнее VCL, на задачах, требующих не самих по себе "рюшечек", а именно содержательной графики (научной, отчеты и т.п.) это весьма заметно (см. например http://forum.oberoncore.ru/viewtopic.php?t=241). Для работы с форматированными текстами вы долго поищете удобный аналог в Дельфе, это я Вам тоже говорю точно.
Мультимедиа-энциклопедия тиражная на нашем движке на базе Блэкбокса вышла и пользуется успехом, ни одной претензии не было (см. http://djone.ru. Если интересно глянуть демку - черкните личным сообщением, дам ссылку). Аналогичные вещи на Дельфе из винегрета HTML, Java, Flash и т.п. компонент - знаем, видали. В итоге получается нечто загружающееся с минуту (наша энциклопедия - считанные мгновения) с различными "побочными эффектами" на стыке разных компонент.
Ну, нет изобилия готовых контролов - дописывать надо, кто спорит? Народ и дописывает, пока в основном под себя... Но больше и больше. А количество, как извествно, со временем переходит в качество.

Ответ на »сообщение 3095« (Как слышно? Приём!)
___________________________
В Обероне это борьба с рюшечками, компонентокидательством и т.п.
Да никто не борется уважаемый.
Денег нет на рюшечки. MS не спонсирует :))
Ну а то что некоторые оберонисты при этом почему то яростно кидаются хаять эти рюшечки, дык это как Крылов обьяснил, рекация лисы на недостижимый виноград :))

Ответ на »сообщение 3096« (Как слышно? Приём!)
___________________________
>>>И мышь, видимо, придумали для совращения неокрепших умов, а не для повышения производительности труда программистов.

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

Ответ на »сообщение 3095« (Как слышно? Приём!)
___________________________

Речь об акценте, режущем слух при разговорах о "настоящих профессионалах".

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

В Обероне это борьба с рюшечками, компонентокидательством и т.п.

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

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

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

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

Лепить побольше компонентов? Само по себе компонентостроительство -- достаточно тупиковый путь. Небезызвестный Батлер Лэмпсон (лауреат премии Тьюринга 1992 г., участник проектов Alto/Mesa и Cedar, "прообразов" Lilith/Modula-2 и Ceres/Oberon, один из ведущих экспертов в Microsoft Research; кстати, почетный доктор наук в ETH Zurich) в 1999 г. выступил на одной конференции с весьма интересным докладом ("Software Components: Only The Giants Survive"). Он задался вопросом, почему отдача от reusability в отношении компонентов работает слабовато? По мнению Лэмпсона, причины разные: отсутствие вразумительной бизнес-модели, высокая стоимость в понимании устройства и работы компонентов, а также конфликт между компонентами с точки зрения их "мировосприятия" (типы данных, потребление ресурсов, обработка исключений и т.п.). Проблема состоит в том, что при необходимости переработки компонента проще прибегать к вычленению части готовой системы и ее превращению в компонент, нежели осуществлять переделку готового компонента, сделанного неизвестно кем.

А как же COM, CORBA и иже с ними? Это способ запуска компонентов, но не сами компоненты. "Они играют роль компоновщика и соглашений о вызовах для распределенных систем",-- говорит Лэмпсон. Но это не компоненты. Главная проблема –- кто контролирует согласованность и концептуальную целостность компонентов. Если они идут от одного производителя, то ситуация облегчается. Но если от разных...

Какой напрашивается вывод? Есть компоненты black-box, есть grey-box, есть white-box. Для reusability в понимании разработчиков нужен доступ не к кнопкам "старт-стоп", не к интерфейсам-контрактам и не просто к голым исходникам, а к идейному нутру, к каркасам-полуфабрикатам, в которых можно разобраться самостоятельно и без стаканА. Можно идти и другим путем: де-факто задать жесткую инфраструктуру (тот же .NET), с которой не свернешь, как бы потом не хотелось.