OberonCore

Правильные идеи, хорошие идеи... Нужны руки, чтобы их реализовывать. Вот Калям хорошую тему поднял, да так народ и не сорганизовался. У нас в "Метасистемах" свободных ресурсов на "выплеск наружу" нет пока. Всё, что готово и полезно для внешнего использования - выкладываем.
У меня вот кроме ABF обещанного и Mt подправленной, лежит ещё готовая подсистема для научно-образовательных целей, в 9 тыс. строк - вгрохал труда с месяц, Александр Ильин видел вон... Так навалилась очередная "запарка" - и не могу добить документацию до конца уже две недели... А полуфабрикат выкладывать не привык - "воспитание не позволяет-с"

А если в Wiki выделить место и работать понемногу сообща над документацией и кодом?

Я вот думаю, как бы его реализовать под линухом, а с ним, оказывается, нужно бороться.

В Опере MDI, в BlackBox MDI... Я разрабатывал проекты на Clarion, там по умолчанию MDI, довольно-таки удобно.



Сейчас делаем небольшой проект на ББ, как раз для конечного пользователя. Одна из задач состоит в том, чтобы обрезать возможности ББ и получить среду, заточенную исключительно под запросы пользователя. Другая задача - как прозрачно для пользователя расширять систему, причём автоматически, удалённо, через сервер обновлений. Уже есть мысли по этому поводу, вот доберёмся только
Ещё есть нужда, всё нуждее и нуждее - вести ББ-проекты в самом ББ. Зашёл в ББ, открыл дерево проектов, открылись сразу нужные (последние) модули (подсистему Cpc с сохранением настроек не предлагать , нужна именно удобная навигация по проектам). Что-то подобное я делал на Clarion, потихоньку перетаскиваю в Ящик. Тут же система контроля версий.

Резюме - Ящику нужны средства конкретизации пользовательского интерфейса и автоматического обновления подсистем.

Позволю себе немного философии, частично связанной с работой на ББ, а частично с собственными наработками в другой области.

Первым делом к той теме, с которой все начиналось. Нужен ли некоторый объем пользовательнских интерфейсов в срде ББ? На мой взгляд очень нужен. Очень привлекательной кажется мысль о том, чтобы весь проект наблюдался не выходя из ящика. На данный момент, к сожалению, много чего не хватает, в частности, средств для работы с текстом и написания документации. У любого сколоко-нибудь значимого проекта этой самой документации очень много и хранить ее где-то еще крайне не удобно, кроме того очень заманчивой кажется мысль делать эту документацию интерактивной. Возможен аже такой вариант, когда основной ценностью является именно документация, а не код (скажем, в учебниках).

Вопрос второй: куда складывать документы? Уже была упомянута папка Docu. Что плохого, если я буду складывать туда любую документацию, тактаты, да хоть стихи. У нас есть папка для проекта, в ней находяться несколько стереотипных папок, в каждой из которых мы знаем что находится. Вообразим наконец крайний случай. Допустим у нас вообще нет кода, а есть только текст, возможно с интерактивными кусочками. От этого проект проектом быть не перестает и если мы используем для его обработки ББ, то вполне резонно относиться к нему так же, как и костальному. Я хочу сказать, что (на мой взгляд), нет никакой философской разницы между текстом и кодом, а так же картинками и чего угодно еще. Так же как файловая система не чувствует особой разницы от того, что именно находится в файле.

И наконец вопрос о ББ, как системе в себе. Мысль очень заманчивая, но есть одна опасность, на которой нарвались очень многие. Включая все больше различных компонент и библиотек в стандартный комплект, есть риск создать некоторого неповоротливого монстра, которого очень сложно приспособить под свои нужды. Я думаю, что различные пакеты внутри ББ должны быть максимально удалены друг от друга, то есть работать вне зависимаости от наличия друг друга и быть легко добавляемыми и удаляемыми(я бы даже предложил, чтобы различные библиотеки содержались в различных папках, как проекты). Тогда в стартовый комплект будет входить лишь базовый набор, а все остальное пользователь может укомплектовать по своему желанию. Такой подход, на мой взгляд, позволи бы создать очень гибкую систему, пригодную для большого спектра задач.

Еще раз повторюсь, что это сугубо мое мнение и вообще в основном философия.

По-моему, этого добра как раз навалом. Чего конкретно не хватает-то? Даже гиперссылки между документами можно делать.


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


Такой подход уже есть, базовая единица - подсистема - находится в отдельной папке, реже такой единицей выступает компонент (как в подсистеме Cpc: множество компонентов разного назначения могут быть инсталлированы независимо, хотя и принадлежат к одной подсистеме). Собственно оригинальный BlackBox содержит только базовый набор подсистем, а все остальное дописывается пользователем либо скачивается из коллекции http://www.zinnamturm.de и адаптируется для конкретных задач.

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


Из философии как из корня растет все остальное, так что не надо преуменьшать.

Я не понял, то ли вы резюмируете основные возможности BlackBox, то ли вы еще не поняли, что нашли систему своей мечты.

Понятно всё это ...

Но вопрос всё равно остаётся открытым - ЧТО ТАКОЕ ББ. К чему вся эта работа должна сойтись в пределе?
Получается что единственное както оформленное представление о развитии ББ это "как Делфи".
Сейчас ББ не IDE, не ОС - чебурашка какойто.

Моё личное видение - интегрированная платформа разработки и выполнения. Подобно Java и .NET. Это как раз и есть "чебурашки" - не среда, не ОС, а... оно самоё.
Одного не хватает для аналогии - перейти от платформонезависимости ("потенциальной кроссплатформенности") к кроссплатформенности реальной.

ББ еще далеко до "системы моей мечты", но смысл не в этом. У любой системы есть множество путей развития - некоторые из них более удачные, некоторые менее. В качестве неудачного примера можно привести ту же Delphi и ее плачевную кончину. Я лишь хочу выделить те направления в ББ, которые на мой взглдя стоит развивать и дальше. А основная философская мысль состоит в том, что на мой взяглд не стоит рассматривать ББ, как среду исключитально для программирования. Подход к ней, как к системе в себе более продуктивен. В идеале это должно выглядеть, как система, которую можно укомплектовать и сконфигурировать для оень разных задач.

Всё верно.

Я бы выделил четыре "характеристических" направления, на которых ББ эффективен и часто вообще уникален:

1) "Коробка в себе", самостоятельная высокоуровневая платформа, с перспективамипортирования. Цель по этому направлению - полностью кроссплатформенная операционная среда. Таковых немного. Тут конкуренты - Жаба и Дот, но у ББ есть очевидные преимущества в ряде случаев, особенно для средних и малых проектов.

2) Составные документы. Бизнес-ПО, медиа, тонкие клиенты... Само по себе неплохо, но при успешном развитии направления (1) можно обскакать конкурентов вдвойне. Требуется - развитие базы компонент, типовых шаблонов, решений.

3) Образование. Тянет на единую образовательную платформу. Как профильную - для программистов, так и для поддержки интерактивных мультимедиа-курсов, особенно - в технических областях (к примеру, интерактивный учебник по физике и т.п.). В совокупности с (1) рвёт всех. Требуется - литература, литература и ещё литература... Над чем бьемся урывками.

4) ... и главное, пожалуй. Как представитель Оберонов - прекрасный язык и система абстракций, на котором легко решать высокотехнологичные и исследовательские задачи, требующие гибкости. Плюс живое воплощение паттернов проектирования (например, великолепная иллюстрация к известной книге Гаммы "Паттерны ООП").

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

А SDI уже есть под Linux ?

Нужно не с MDI бороться, а с SDI. В смысле, не чтобы первого не было, а чтобы был второй.

Так об этом и речь.
А вот зачем реализовывать этот MDI в Linux-версии, SDI недостаточно?

Операционная оболочка? а последний конкурент сканчался где-то в районе 95 года? (Win3.11 )

Не уловил до конца мысли... Прошу ещё раз медленно, чтоб "дошло до жирафа"

Зачем с кем-то бороться? Должны жить оба!

Практически полноценная ОС, но для связи с железом исползуящая другую ОС.
Win3.11 запускалась только поверх ДОС и было особым шиком поправлять что она не ОС а операционная оболочка.

Судя по всему идеал развитя ББ - SDI под Линух

Судя по всему идеал развитя ББ - полноценная ОС