Другой взгляд на интерфейс, альтернатива @panel
-
konstantin_666, такое будет возможно реализовать если панели будут достаточно конфигурируемыми, что и есть главная цель обсуждаемого в данной теме проекта. А так в общем прикольно смотрится, может даже удобно)И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Ну тогда и Aston посмотрите, а вообще я привык за два года к компизовскому кубу, Alt+Ctrl+право/лево на одном столе справка, на другом среда разработки, на третьем консоль и т.д. очень удобно! Вопрос кто будет делать?
Ghost, это про рабочий стол? думаю многие хотят сделать более нормальный рабочий стол (я тоже хотел), но мешает отсутствие возможности создать приложению полноэкранное окно подо всеми.
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Я изучал/изучаю устройство оконной системы в KolibriOS. Там оконная подсистема связана с GUI. Мышь, кнопки(лучше бы их там не было), события с привязкой к процессам - всё связано. Непростая смесь. Разобраться можно, но не известно сколько на это уйдёт времени. Если делать по нормальному - это будет вообще не совместимо с текущим гуи. Вдобавок ко всему куча приложений используют системные кнопки KolibriOS...мешает отсутствие возможности создать приложению полноэкранное окно подо всеми
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Прежде чем что-либо делать необходимо написать, что ты хочешь сделать и дать описание того, что это даст. На вики можно создать страницу и там постараться изложить свое видение. Переделка ядра в большинстве случаев затронет приложения, которые необходимо будет переписать.
Полностью согласен. Я пока потихоньку(примерно 1-2 часа в неделю) изучаю устройство ядра. Сейчас хотя бы общую архитектуру понять. Отсутствие документации и постоянные практически не документированные изменения затрудняют изучение. Сначала надо понять общую схему работы каждой части из которой состоит ядро, а потом уже детализировать каждую часть. Графической документации в виде некого подобия цветных(это обязательно) блоксхем - вот чего не хватает. Ну и текста к документации конечно. Попробую восстановить блоксхему из "черного ящика" - ядра KolibriOS.Прежде чем что-либо делать необходимо написать, что ты хочешь сделать и дать описание того, что это даст.
Про устройство оконной подсистемы X server-а документации почти нет. Нашол только общие идеи. Всё остальная "документация" - это програмный код. А вот по устройству различных GUI библиотек документации полно.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
andrew_programmer
А зачем трогать то что работает? Я вот этого не понимаю. Делай себе на здоровье свою реализацию кнопок в подключаемой либе. Мне вот надо было для zSea я сделал в библиотеке BoxLib. Одно другому не мешает. Не так уж много кода можно выдрать из ядра - ИМХО овчинка выделки не стоит, работы дофига, а эффект мизер.
Вот когда стандарт на библиотеку устоится и многие программы его будут применять, вот тогда можно будет прикинуть какой код выбросить.
З.Ы.Телега должна быть позади лошади, а то лошади толкать телегу несподручно.
А зачем трогать то что работает? Я вот этого не понимаю. Делай себе на здоровье свою реализацию кнопок в подключаемой либе. Мне вот надо было для zSea я сделал в библиотеке BoxLib. Одно другому не мешает. Не так уж много кода можно выдрать из ядра - ИМХО овчинка выделки не стоит, работы дофига, а эффект мизер.
Вот когда стандарт на библиотеку устоится и многие программы его будут применять, вот тогда можно будет прикинуть какой код выбросить.
З.Ы.Телега должна быть позади лошади, а то лошади толкать телегу несподручно.
Mario
Что не так:
1)Отсутствие окон верхнего уровня не позволяет реализовать полноценное меню, выходящее за пределы окна. Можно только реализовать некое подобие этого меню. Только на слабых машинах придётся смотреть слайдшоу. Даже на современных машинах тормоза при быстром перемещении по такому меню.
По этой же причине нельзя реализовать полноценные панели, виджеты рабочего стола, Tollbar-ы.
2)Если реализовать окно "всплывающуя подсказка", то любое внезапно появившееся окно переведёт фокус ввода на себя и запросто может полностью перекрыть всплывающую подсказку. По сути это следствие пункта 1)
3)Нужно окна самого нижнего уровня для рабочего стола вместо кучи потоков Icon.
4)Если элемент управления занимает только малую часть родительского окна, то возникает проблема заливки всего остального фона окна. Если реализовать элемент управления как под окно главного окна, то таких проблем не будет. Сейчас один поток может иметь одно окно. Число потоков не более 256. А по правильному у одного потока должно быть одно главное родительское окно и множество(в пределе бесконечность) дочерних под окон, которые содержаться внутри главного окна.
5)При перемещении окон перерисовываются все нижележащие окна - это не дело. Как же тогда с перетаскиванием окна вместе с отображением его содержимого.
6)Сейчас невозможно реализовать технологию Drag & Drop. Для её реализации необходимо запрограммировать в ядре объект(смотрим объектно ориентированный подход и паттерны проектирования).
7)Невозможно реализовать менеджеры окон и декораторы окон типа Metacity, Compiz и т.д.
Работает, только не так, как надо. И возможностей для реализации полноценной работы с окнами - нет.А зачем трогать то что работает? Я вот этого не понимаю.
Что не так:
1)Отсутствие окон верхнего уровня не позволяет реализовать полноценное меню, выходящее за пределы окна. Можно только реализовать некое подобие этого меню. Только на слабых машинах придётся смотреть слайдшоу. Даже на современных машинах тормоза при быстром перемещении по такому меню.
По этой же причине нельзя реализовать полноценные панели, виджеты рабочего стола, Tollbar-ы.
2)Если реализовать окно "всплывающуя подсказка", то любое внезапно появившееся окно переведёт фокус ввода на себя и запросто может полностью перекрыть всплывающую подсказку. По сути это следствие пункта 1)
3)Нужно окна самого нижнего уровня для рабочего стола вместо кучи потоков Icon.
4)Если элемент управления занимает только малую часть родительского окна, то возникает проблема заливки всего остального фона окна. Если реализовать элемент управления как под окно главного окна, то таких проблем не будет. Сейчас один поток может иметь одно окно. Число потоков не более 256. А по правильному у одного потока должно быть одно главное родительское окно и множество(в пределе бесконечность) дочерних под окон, которые содержаться внутри главного окна.
5)При перемещении окон перерисовываются все нижележащие окна - это не дело. Как же тогда с перетаскиванием окна вместе с отображением его содержимого.
6)Сейчас невозможно реализовать технологию Drag & Drop. Для её реализации необходимо запрограммировать в ядре объект(смотрим объектно ориентированный подход и паттерны проектирования).
7)Невозможно реализовать менеджеры окон и декораторы окон типа Metacity, Compiz и т.д.
Работы много, но оно того стоит.работы дофига, а эффект мизер.
Уже сейчас прикладные программисты столкнулись с проблемой примитивности оконной подсистемы. А чем дальше в лес тем больше будет проблем. К тому же переписывать GUI библиотеки по сто раз вовсе не интересно.Вот когда стандарт на библиотеку устоится и многие программы его будут применять, вот тогда можно будет прикинуть какой код выбросить.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
andrew_programmer
Я что действительно тупо выражаюсь? В каком месте моего поста я написал, что существующая реализация очень хороша и не стоит делать альтернативу?
Сначала нужно сделать реализацию, потом выбросим код который станет не нужен.
Я что действительно тупо выражаюсь? В каком месте моего поста я написал, что существующая реализация очень хороша и не стоит делать альтернативу?
Обязательно надо сначала поломать?Mario wrote:Одно другому не мешает
Сначала нужно сделать реализацию, потом выбросим код который станет не нужен.
Согласен. Нужно отдельной веткой это делать - иначе никак.Сначала нужно сделать реализацию, потом выбросим код который станет не нужен.
Недопонимание бывает у всех. Всётаки разные люди по разному мыслят. Но после пояснения я понял, что имелось ввиду.Я что действительно тупо выражаюсь? В каком месте моего поста я написал, что существующая реализация очень хороша и не стоит делать альтернативу?
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
"3)Нужно окна самого нижнего уровня для рабочего стола вместо кучи потоков Icon." - и еще вместо ядра фон рисовать. имхо не ядреное это дело // а может это в другую ветку форума обсуждение перенести?
И мы уже давно не пешки,
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
Мы пули, мы орлы, и решки!
Война ютит бинарный код,
Умри, или иди вперед!
andrew_programmer
Я тут подумал можно сделать наследование формата функций вызова. Потом можно будет вместо вызова Int 0x40 везде прописать макрос mcall, а в самом макросе уже делать переопределение на вызов библиотеки вместо системной функции ядра. В любом случае это будет уже чисто механическая работа и совместимость с кучей программ не потеряется. А новые программы уже можно будет писать чисто на вызовы библиотеки. Ну, распухнут на 10-20% программы (и это только ассемблерные, на Си-шных вообще разница практически будет незаметна), но зато не придется тотально переписывать.
Gluk
Я тут подумал можно сделать наследование формата функций вызова. Потом можно будет вместо вызова Int 0x40 везде прописать макрос mcall, а в самом макросе уже делать переопределение на вызов библиотеки вместо системной функции ядра. В любом случае это будет уже чисто механическая работа и совместимость с кучей программ не потеряется. А новые программы уже можно будет писать чисто на вызовы библиотеки. Ну, распухнут на 10-20% программы (и это только ассемблерные, на Си-шных вообще разница практически будет незаметна), но зато не придется тотально переписывать.
Gluk
Согласен, но к сожалению модераторы на форуме только удалять хорошо умеют - выполнять другую работу стоит значительных умственных усилий.а может это в другую ветку форума обсуждение перенести?
Mario
Я тоже об этом думал. При желании перенаправлением через макрос можно избежать переписывния и добиться совместимости.
Пусть пока обсуждения подождут реальных действий, когда будет реально работающий код.
Я тоже об этом думал. При желании перенаправлением через макрос можно избежать переписывния и добиться совместимости.
Пусть пока обсуждения подождут реальных действий, когда будет реально работающий код.
KolibriOS-перспективная ос!
Kolibri is best operation system in the world!
Kolibri is best operation system in the world!
Чего здесь спорить? Нужно брать и писать.
Я уже начал работу над одной интересной программой.
Она должна будет заменить @panel, KIV(частично), icon и, возможно, несколько других программ.
И вообще, нужно все мелкие прикладные программы интегрировать в программные комплексы и в каждый такой комплекс встраивать свою библиотеку.
Преимущества: компактность, отсутствие стандартных библиотек и высокая совместимость.
Я уже начал работу над одной интересной программой.
Она должна будет заменить @panel, KIV(частично), icon и, возможно, несколько других программ.
И вообще, нужно все мелкие прикладные программы интегрировать в программные комплексы и в каждый такой комплекс встраивать свою библиотеку.
Преимущества: компактность, отсутствие стандартных библиотек и высокая совместимость.
Last edited by konstantin_666 on Wed Feb 03, 2010 5:04 am, edited 3 times in total.
Не бойтесь делать ошибок. Бойтесь ничего не делать.
Вот. http://introvert.wen.ru/Files/KDesk.zip
Как вам?
Как вам?
Last edited by konstantin_666 on Sat Jan 30, 2010 8:40 pm, edited 2 times in total.
Не бойтесь делать ошибок. Бойтесь ничего не делать.
Who is online
Users browsing this forum: No registered users and 0 guests