Board.KolibriOS.org

konstantin_666, такое будет возможно реализовать если панели будут достаточно конфигурируемыми, что и есть главная цель обсуждаемого в данной теме проекта. А так в общем прикольно смотрится, может даже удобно)

Ну тогда и Aston посмотрите, а вообще я привык за два года к компизовскому кубу, Alt+Ctrl+право/лево на одном столе справка, на другом среда разработки, на третьем консоль и т.д. очень удобно! Вопрос кто будет делать?

Ghost, это про рабочий стол? думаю многие хотят сделать более нормальный рабочий стол (я тоже хотел), но мешает отсутствие возможности создать приложению полноэкранное окно подо всеми.

мешает отсутствие возможности создать приложению полноэкранное окно подо всеми

Я изучал/изучаю устройство оконной системы в KolibriOS. Там оконная подсистема связана с GUI. Мышь, кнопки(лучше бы их там не было), события с привязкой к процессам - всё связано. Непростая смесь. Разобраться можно, но не известно сколько на это уйдёт времени. Если делать по нормальному - это будет вообще не совместимо с текущим гуи. Вдобавок ко всему куча приложений используют системные кнопки KolibriOS...

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

Прежде чем что-либо делать необходимо написать, что ты хочешь сделать и дать описание того, что это даст.

Полностью согласен. Я пока потихоньку(примерно 1-2 часа в неделю) изучаю устройство ядра. Сейчас хотя бы общую архитектуру понять. Отсутствие документации и постоянные практически не документированные изменения затрудняют изучение. Сначала надо понять общую схему работы каждой части из которой состоит ядро, а потом уже детализировать каждую часть. Графической документации в виде некого подобия цветных(это обязательно) блоксхем - вот чего не хватает. Ну и текста к документации конечно. Попробую восстановить блоксхему из "черного ящика" - ядра KolibriOS.
Про устройство оконной подсистемы X server-а документации почти нет. Нашол только общие идеи. Всё остальная "документация" - это програмный код. А вот по устройству различных GUI библиотек документации полно.

andrew_programmer
А зачем трогать то что работает? Я вот этого не понимаю. Делай себе на здоровье свою реализацию кнопок в подключаемой либе. Мне вот надо было для zSea я сделал в библиотеке BoxLib. Одно другому не мешает. Не так уж много кода можно выдрать из ядра - ИМХО овчинка выделки не стоит, работы дофига, а эффект мизер.
Вот когда стандарт на библиотеку устоится и многие программы его будут применять, вот тогда можно будет прикинуть какой код выбросить.

З.Ы.Телега должна быть позади лошади, а то лошади толкать телегу несподручно.

Mario

А зачем трогать то что работает? Я вот этого не понимаю.

Работает, только не так, как надо. И возможностей для реализации полноценной работы с окнами - нет.
Что не так:
1)Отсутствие окон верхнего уровня не позволяет реализовать полноценное меню, выходящее за пределы окна. Можно только реализовать некое подобие этого меню. Только на слабых машинах придётся смотреть слайдшоу. Даже на современных машинах тормоза при быстром перемещении по такому меню.
По этой же причине нельзя реализовать полноценные панели, виджеты рабочего стола, Tollbar-ы.
2)Если реализовать окно "всплывающуя подсказка", то любое внезапно появившееся окно переведёт фокус ввода на себя и запросто может полностью перекрыть всплывающую подсказку. По сути это следствие пункта 1)
3)Нужно окна самого нижнего уровня для рабочего стола вместо кучи потоков Icon.
4)Если элемент управления занимает только малую часть родительского окна, то возникает проблема заливки всего остального фона окна. Если реализовать элемент управления как под окно главного окна, то таких проблем не будет. Сейчас один поток может иметь одно окно. Число потоков не более 256. А по правильному у одного потока должно быть одно главное родительское окно и множество(в пределе бесконечность) дочерних под окон, которые содержаться внутри главного окна.
5)При перемещении окон перерисовываются все нижележащие окна - это не дело. Как же тогда с перетаскиванием окна вместе с отображением его содержимого.
6)Сейчас невозможно реализовать технологию Drag & Drop. Для её реализации необходимо запрограммировать в ядре объект(смотрим объектно ориентированный подход и паттерны проектирования).
7)Невозможно реализовать менеджеры окон и декораторы окон типа Metacity, Compiz и т.д.

работы дофига, а эффект мизер.

Работы много, но оно того стоит.

Вот когда стандарт на библиотеку устоится и многие программы его будут применять, вот тогда можно будет прикинуть какой код выбросить.

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

andrew_programmer
Я что действительно тупо выражаюсь? В каком месте моего поста я написал, что существующая реализация очень хороша и не стоит делать альтернативу?

Mario wrote:Одно другому не мешает

Обязательно надо сначала поломать?
Сначала нужно сделать реализацию, потом выбросим код который станет не нужен.

Сначала нужно сделать реализацию, потом выбросим код который станет не нужен.

Согласен. Нужно отдельной веткой это делать - иначе никак.

Я что действительно тупо выражаюсь? В каком месте моего поста я написал, что существующая реализация очень хороша и не стоит делать альтернативу?

Недопонимание бывает у всех. Всётаки разные люди по разному мыслят. Но после пояснения я понял, что имелось ввиду.

"3)Нужно окна самого нижнего уровня для рабочего стола вместо кучи потоков Icon." - и еще вместо ядра фон рисовать. имхо не ядреное это дело // а может это в другую ветку форума обсуждение перенести?

andrew_programmer
Я тут подумал можно сделать наследование формата функций вызова. Потом можно будет вместо вызова Int 0x40 везде прописать макрос mcall, а в самом макросе уже делать переопределение на вызов библиотеки вместо системной функции ядра. В любом случае это будет уже чисто механическая работа и совместимость с кучей программ не потеряется. А новые программы уже можно будет писать чисто на вызовы библиотеки. Ну, распухнут на 10-20% программы (и это только ассемблерные, на Си-шных вообще разница практически будет незаметна), но зато не придется тотально переписывать.

Gluk

а может это в другую ветку форума обсуждение перенести?

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

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

Чего здесь спорить? Нужно брать и писать.
Я уже начал работу над одной интересной программой.
Она должна будет заменить @panel, KIV(частично), icon и, возможно, несколько других программ.

И вообще, нужно все мелкие прикладные программы интегрировать в программные комплексы и в каждый такой комплекс встраивать свою библиотеку.
Преимущества: компактность, отсутствие стандартных библиотек и высокая совместимость.