Добавь в другом формате описание проекта.

<Lrz>

Вообще OpenDocument это стандарт, и неплохо бы иметь возможность его читать. Но вот в PDF, если надо.

для чего стандарт? да и Колибри его пока не читает

Gluk
Для текстовых документов.

да и Колибри его пока не читает

Ну из Колибри и скачать-то (нормально) документ, вроде не получится. Да и разве у кого-то она стоит основной системой?

Прочитал.
vkos, тебе респект, т.к. эта идея витала в воздухе. Я и сам о таком думал, но постить такое не стал - т.к. опять сказали бы "максимализм".
Но. Проблема кроется глубже. Она идет от ядра (API, различные подсистемы, впихнутые в ядро, сеть). Не спорю, проблемы системные и прикладные - абсолютно разные, и как раз такой фремймворк решит проблему (за счет того, что фреймворк нужно будет только переписать, а не все приложения).
А вообще, мысль конечно дельная.

Она идет от ядра (API, различные подсистемы, впихнутые в ядро, сеть).

Да я знаю, но ядром лично я заниматься всё равно не буду.

А я и не предлагал Просто обострил внимание.

Особенно мне понравилась (читай задела) эта фраза:

Можно ещё упомянуть старую консоль cmd, которая уже не развивается (хотя она и функциональнее shell/console.obj)

Как для проекта Just for fun, над которым работал один разработчик (ну ладно, два - diamond тоже приложил свою руку, за что ему огромнейшее спасибо), функциональность shell'а я считаю вполне нормальной. Вспоминаются заявления кого-то из сообщества перенести его на ассемблер за 2 дня. Ну, и? Надо бы написать diamond'у, чтобы он исключил shell из дистрибутива.

Albom
Не хотел тебя обидеть, однако cmd предоставляет возможность написания осмысленных консольных приложений, а shell нет. С точки зрения пользователя shell функциональнее, но я имел ввиду с точки зрения разработчика.

Как показывает практика, одним из главных факторов популярности той или иной платформы является простота и удобство разработки. Именно по этой причине завоевали популярность Windows (ещё во времена 3.1), Java, KDE, .NET, Mono... Пользователю нужны приложения, а их количество и качество зависит от дружественности платформы к программисту. Поэтому, для развития Колибри нужно писать прежде всего не конечные приложения, а библиотеки для разработки или вспомогательные приложения.

Я не могу не прокомментировать этот текст.

В те времена, когда windows3.1 ещё под столом ползала уже существовала очень функциональная графическая операционная система NextStep. В ней было всё, что есть в современных графических операционных системах: перекрывающиеся окна, премещаемые окна с возможностью выхода за пределы экрана, технология Drag & Drop, десктоп с иконками ярлыками, меню, графическими компонентами и много чего еще(и всё это в цвете!). А разрабатывать графические приложения можно было вообще не написав ни одной строчки кода! А всё благодаря применению языка Objective-C , являющегося объектно ориентированным(ООП) расширением языка C. Был использован специальный объектно-ориентированный подход, позволяющий создавать динамические расширяемые объекты(причём расширить функциональность интерфейса можно было даже не перекомпилировав GUI библиотеки). И всё это работало на процессоре в 25Mhz и 8 MB RAM. Наверное у вас возник вопрос куда исчезла эта система. Она никуда не исчезла. Где то примерно в 1995 году компанию NextStep купила Apple. И все возможности этой системы теперь есть в Mac OS X. Часть возможностей NextStep перекопировала Microsoft в свою Windows и Visual Studio (причём кривовато), а что-то не реализовано до сих пор.
Я нашёл в интернете открытый проект-альтернативу NextStep - это OpenStep. Но проект реализован на Objective-C. Хотя gcc поддерживает Objective-C, но большая часть функциональности этого языка реализована в runtime библиотеке(то есть исполняемой библиотеке). Размер её приличный. С учётом реализации dll в KolibriOS лучше не применять её для реализации GUI. Зато я нашёл реализацию базовых возможностей языка Objective-C на C++. Используя базовый C++ класс со специальным интерфейсом(то есть специальными методами класса), можно реализовать любой абстрактный тип данных с возможностью динамического управления этими данными. Созданные на основе этих классов объекты сами будут обеспечивать свою инициализацию,доступ к данным, своё удаление. Программисту вообще незачем думать об управлении объектами. Объекты сами удаляю себя, когда становятся ненужными, выполняют все операции по работе с хранимыми данными. Используя этот базовый класс и созданные на его основе объекты можно реализовать динамически создаваемый и расширяемый GUI интерфейс. Только вот есть две проблемы:
1)Как реализовать на C++ DLL для KolibriOS.
2)Как получить доступ к методам классов в такой DLL.
Проблему 2 можно решить, если решить проблему 1.

Так же хочу напомнить, что идеи ООП, приеменяемые в NextStep неплохо было бы задействовать и реализовать на ассемблере в оконной подсистеме. По сути я работаю в направлении применения такого подхода к оконной системе и к libGUI. Для ядра это должно быть на ассемблере, а для libGUI на С++.

P.S.
Не люблю много болтать и мало делать. Но тут без обсуждения к сожалению никак не обойтись.

1. diamond сделал утиль, для конвертирования DLL в COFF-объект, которым я и пользуюсь.
2. Давно существует ABI для разделения ОО сущностьей между динамическими библиотеками (вообще их несколько), это GObject, который я и планирую переносить со временем. А как компилятор X заставить собирать классы именно в таком формате, это проблема этого компилятора. Пока есть только Vala, которая который использует GObject при создании классов, на сколько мне известно. Конечно можно работать с GObject на C (на чем он и написан) и на любом другом языке, только это будет очень странное ООП.

..bw

1. diamond сделал утиль, для конвертирования DLL в COFF-объект, которым я и пользуюсь.

И где можно скачать эту утилиту? На новом сайте diamond-а вообще ссылок стало значительно меньше, чем на старом сайте. И теперь я почти ничего там не могу найти.

Правда он посмеялся, как бэ намекая, и сделал её только для KOS :-).

..bw

andrew_programmer
Я слышал про NextStep, однако у меня есть большие подозрения, что на тогдашних PC она бы просто не запустилась. Поэтому для windows она не была конкурентом.

По поводу C++, я его точно использовать не буду. Мне он вообще не нравится и, кроме того, я не вижу больших преимуществ в отличии от C. А недостатки есть - писать универсальное API для библиотеки на C гораздо проще, чем для библиотеки на C++ (взять хотя бы кол-во языков, поддерживаемых Gtk+ и Qt).

Так же хочу напомнить, что идеи ООП, приеменяемые в NextStep неплохо было бы задействовать и реализовать на ассемблере в оконной подсистеме. По сути я работаю в направлении применения такого подхода к оконной системе и к libGUI. Для ядра это должно быть на ассемблере, а для libGUI на С++.

Ещё раз повторю, что я не хочу разделять оконную систему и графическую библиотеку. И пихать графику в ядро я тоже не хочу. А по поводу идей ООП, их конечно необходимо использовать, иначе написания фреймворка затянется на очень долгий срок..