Другой взгляд на интерфейс, альтернатива @panel

Projects yet to be implemented in working code
  • ну насчет виджетов еще не уверен по какому принципу их делать - т.к. в текущем варианте программы должны будут в векторном формате подавать графику (для масштабируемости), а активные области (о событиях, связанных с ними (типа клика мышью) приложение-опекун виджета будет уведомляться) уже наверное как-то в процентах от площади чтоли.. в общем, с этим еще предстоит разобраться, так что хочется по этому поводу тоже услышать ваши мнения
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Я тоже свою панель делаю, примерно в таком же духе. Не в обиду будет сказано, но интерфэйс у тебя както тапорно выглядит, а в целом идея хорошая. Только я не понял, зачем нужно иконки перемещать из нижней панели в квадратики, если их можно оставить на нижней панели, а добавлять при нажатии на правую клавишу мыши на панели, после чего будет открываться меню, где можно будет выбрать нужную иконку, название и прописать путь. Так помойму удобнее и экономится место на экране для более важных вещей (например для папок, которые пока что не реализованы - тут я гляжу в будущее).
  • :o Ну и дела ^___^ недели две назад начал кодить _свою_ версию панели, на сегодняшний день(да как и неделю назад, всё никак не доползу до неё) она лишь умеет отображать запущенные программы флэт-кнопками, да рисовать время. Виджеты задумывались...
    :idea: ну что. может стоит объединить усилия, если сразу нескольким людям хочется иметь красивую современную панель и вообще рабочее окружение?

    : Повторю хотелку к кодерам ядра... Об окнах с атрибутами "Поверх всех" и "Снизу всех"..
    Очень хочется чтобы значки не перекрывали открытые окна. неправославно это как-то
  • согласен что делать 3 вещи одинаковые по сути, причем на замену уже существующей 4й, причем взаимоисключающие (ну 4 интерфейса разом я думаю никто запускать не будет)
    Давайте тогда обсудим какой она должна быть, выберем один вариант, и будем над ним работать (ибо по какому принципу бы не работали виждеты (отдельные потоки/отдельные приложения/etc), код их независим и можно их независимо же и писать).
    Rock_maniak_forever: "Только я не понял, зачем нужно иконки перемещать из нижней панели в квадратики, если их можно оставить на нижней панели, а добавлять при нажатии на правую клавишу мыши на панели, после чего будет открываться меню, где можно будет выбрать нужную иконку, название и прописать путь." - не совсем понял о каких иконках речь.. но в общем-то картинка лишь один из вариантов как панели могут выглядеть, квадраты не обязаны быть квадратами, ширина не обязана быть такой большой (только для наглядности нарисовал побольше). Например (когда проект доделан будет) дли УМПК с тачскринами (ну забудем на секунду про драйвера) удобно будет не делать нижней панели, а две боковые. Ну и все в таком духе, все настройки из конфигурационного файла брать предполагается.
    Для составления общего варианта предлагаю за основу вышеописанный, и мы все вместе его подредактируем, ну а код за основу возьмем того, кто больше всех написал =)
    не настаиваю на объединении усилий, но это было бы логичнее чем.. ну впрочем я уже в этом посте описывал уже)
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • По-хорошему если делать так, как надо, то каждый виджет должен быть отдельным плагином и/или отдельной dll, ИМХО. API плагинов - это уже другой вопрос.
    Если абстрагироваться от деталей, то в теории, как мне кажется, всё должно быть примерно так:
    панель - это что-то вроде "коробочки", которую можно двигать по экрану (а можно и закрепить к краю), причем запускать их можно сколько угодно (не обязательно от 0 до 4, можно и больше. почему бы и нет??). Панель позволяет вызвать окно настройки, из которого можно добавлять любые плагины/виджеты. Виджеты размещаются на панели и в своей области творят что хотят. Область можно ресайзить, двигать, закреплять.
    Список приложений, кнопка меню - так же виджеты. /Ну и если говорить так, как по идее нужно, то виджет "меню" должен быть настраиваемым как угодно,чтоб можно было делать какие угодно меню разных типов, тоже настраиваемые/. Виджеты, мне кажется, должны висеть как динамические библиотеки. Либо как отдельные процессы. (но первый вариант несколько проще, думаю).Что касается функций API плагинов - то их много и не нужно.. Просто сообщать плагину, где рисовать, а где рисовать нельзя, да передавать нажатия на кнопки и прочие события.
    Соответственно, все настройки плагинов и панелей стоит хранить в ini-файле.

    так вот мне кажется.
  • Sorcerer - "Если абстрагироваться от деталей, то в теории, как мне кажется, всё должно быть примерно так:
    панель - это что-то вроде "коробочки", которую можно двигать по экрану (а можно и закрепить к краю), причем запускать их можно сколько угодно (не обязательно от 0 до 4, можно и больше. почему бы и нет??). " - проблема тут имеется, панель должна быть вне рабочего пространства экрана, чтобы приложения которые "на весь экран" ее не закрывали или она не закрывала часть их окон. А реализовать это проще всего пристыковкой к краям экрана. А краев у экрана всего 4 =)
    "Либо как отдельные процессы. (но первый вариант несколько проще, думаю)." - не то чтобы намного проще, хотя несколько все-таки попроще. Тут такой вариант - включаются в программу они как файлы (не обязательно dll, можно и свой формат, попроще, и обозвать расширением .kpv (Kolibri Panel Vidget) например), но выполнять их отдельными потоками - для того чтобы в случае зависания или падения одного виджета панель не рушилась с треском (все-таки панель это очень важная часть системы).
    "Соответственно, все настройки плагинов и панелей стоит хранить в ini-файле." - согласен полностью
    "Список приложений, кнопка меню - так же виджеты." - список приложений - это в смысле запущенных приложений? тогда конечно так. А вот насчет кнопки меню не совсем согласен, можно чтобы она была просто кнопкой. Так как пространство виджетов все-таки ограничено областью панели, а кнопка просто запускает приложение.
    Еще на рисунке есть типа кнопки (игры), это очередной тип объекта панели, который раскрывает еще как бы панельку - на которой тоже могут быть кнопки (запуск конкретных игр на рисунке), или такие же раскрывающиеся вещи (например игры - аркады, стратегии, экшены). Такой вещью в принципе можно заменить имеющееся приложение @menu (ведь если сделать все достаточно настраиваемым, можно даже вид такой же сделать).
  • Gluk wrote:панель должна быть вне рабочего пространства экрана, чтобы приложения которые "на весь экран" ее не закрывали или она не закрывала часть их окон. А реализовать это проще всего пристыковкой к краям экрана. А краев у экрана всего 4 =)
    а если я захочу чтобы панель была посередине экрана? :) каприз... ну например как в ворде можно панель отцепить от верха окна.
    Gluk wrote: Еще на рисунке есть типа кнопки (игры), это очередной тип объекта панели, который раскрывает еще как бы панельку - на которой тоже могут быть кнопки (запуск конкретных игр на рисунке), или такие же раскрывающиеся вещи (например игры - аркады, стратегии, экшены). Такой вещью в принципе можно заменить имеющееся приложение @menu (ведь если сделать все достаточно настраиваемым, можно даже вид такой же сделать).
    либо же сделать виджет "меню", о чем я и говорил :)
  • "либо же сделать виджет "меню", о чем я и говорил" - то, что вылазит за пределы панели - уже не виджет. Виджет, приложение, "окно" которого находится в панели, что позволяет приложению например обрабатывать командную строку или выводить прогноз погоды, или показывать время, ну плюс еще обрабатывать нажатие (напр. жмешь на кнопку под батареей - вместо процентов показывается оставшееся время работы). Что виджет меню должен тогда отображать?
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • "а если я захочу чтобы панель была посередине экрана? каприз... ну например как в ворде можно панель отцепить от верха окна." - в ворде нет окон которые поверх него бы запускались) к тому же возникнут проблемы: поверх всех ли окон должна быть такая панель? если нет - к ней нет быстрого доступа (если панель единственная то вообще кошмар, если не единственная - то получается в другой панели надо в списке запущенных приложений все панели отображать - чтобы можно было на них переключиться - ну тоже ужас..), если да - такое окошко которое поверх всех, будет очень сильно мешаться.
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Тут такой вариант - включаются в программу они как файлы (не обязательно dll, можно и свой формат, попроще, и обозвать расширением .kpv (Kolibri Panel Vidget) например), но выполнять их отдельными потоками - для того чтобы в случае зависания или падения одного виджета панель не рушилась с треском (все-таки панель это очень важная часть системы).
    Слово widget по жизни пишется с буквой w. Поток не может рисовать в окне другого потока.
    Ушёл к умным, знающим и культурным людям.
  • "Слово widget по жизни пишется с буквой w" - я знаю. а слово vidget - с буквой v =)
    ошибся я, прошу прощения.
    "Поток не может рисовать в окне другого потока." - из второго поста видно что непосредственно выводом на экран будет заниматься сама программа-панель, а виджет - только подавать ей информацию для отрисовки, а обратно получать всякие разные события (а если и не видно, поясняю в этом посте). Впрочем из того же второго поста видно что механизм работы виджетов толком еще не разработан и является огромным знаком вопроса.. все что придумано - выложено на ваш суд
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • самое простое что можно придумать с Wиджетами - чтобы (по-прежнему не важно, просто ли это отдельные потоки или же отдельные приложения) - это давать им на вход отпущенные им ширину и высоту, а они уже как хотят, но вернут битмап нужных размеров, с нужной картинкой. Правда, это усложнит написание виджетов.. Вывод текста в битмап уже сам по себе требует вызова библиотеки, и вызывать ее для каждого Wиджета - значит слямзать всю оперативку. Поэтому все же предлагаю чтобы поток/процесс-виджет подавал информацию в некоем оговоренном бинарном формате, типа
    db 0;тип объекта - прямоугольник
    dw 10;координата (относительно верхнего левого угла Wиджета) по оси x,
    dw 10;то же самое, только размер
    dd ...; то же для оси Y
    ... ну и так далее. можно все данные подавать в том же формате в каком это будет вызываться для рисования, например
    dd 13;eax
    dd ...;ebx
    ..
    все по sysfuncr.txt. Парсить такое будет одно удовольствие, разве что к координатам добавлять поправку чтобы они были относительно верхнего левого угла Wиджета.

    сообщение несколько сумбурно, т.к. описывал варианты по ходу придумывания, но в общем считаю наиболее подходящим последний вариант. Все-таки наиболее логичным выглядит в таком случае размещение программ-виджетов в файлах имеющих расширение .kpw (спасибо diamond'у за поправку), представляющих собой бинарные файлы оговоренным заголовком (включающим в себя описание (показываемое пользователям при настройке)), они будут загружаться Панелью, им будет подаваться нужная информация (ширина/высота битмапа, адрес области данных куда виджет должен записывать рисуемое). Как вам? Если есть лучшие варианты - буду очень рад =)
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • никто не готов предоставить для каркаса свой исходный код? мне продолжать писать свой? если да - как доделаю каркас - выложу, и сможем работать все вместе =)
    И мы уже давно не пешки,
    Мы пули, мы орлы, и решки!
    Война ютит бинарный код,
    Умри, или иди вперед!
  • Gluk
    А может не стоит так вот сразу писать код? Неплохо бы для начала оформить хоть какую-то документацию по связкам компонентов приложения. Понятно дело что хочется побыстрее реализовать, но ведь из-за нестыковок будете потом на грабли наступать, в том числе и на свои. К тому же планируется участие нескольких человек, так тем более все поле будет граблями забросано. Потери времени и прочее.
    Да документация кажется ненужной, особенно когда работаешь один, но проходит пара месяцев и вот уже начинаем путаться в своем собственном коде.
  • Who is online

    Users browsing this forum: No registered users and 4 guests