Portable compositing window manager

[trolly]

Hi,

i'm working on a window manager for my os. it's written in freebasic (the langage isn't so important, since i dont use runtime functions for this, else for the demo app wich is a windows app)

I decided to make it as portable as possible, so everyone can reuse it for his os. to achieve this, all system dependent method are placed in a separate file (arg.bas) and the developper only have to modify a few functions to alocate/realocate/free memory, read file contents, returns mouse position , screen resolution, and graphic framebuffer address

note: it's a compoziting window manager, this mean, that each control has is own buffer (24BPP) where it draw into, then the parent control put this buffer inside his own buffer, etc... until the root of the tree. after that, it copies the root's framebuffer to the video framebuffer.

for now, i did the button, checkbox, window, scrollviewer and label. the windows are moveable, button are clickable etc...

if you are interested to work on this project with me, or to reuse it into your kernel, let me know.

there is a screenshot:

[Jezze]

Nice job!

Could you tell me a bit about how you designed it? How do you do inter-process communication/events like keyboard/mouse presses etc?

[klange]

Hello, trolly.

I have a few questions:

- Since you're using 24-bit buffers for all of your elements, I assume you don't support transparency? Since you're using subwindows for GUI elements, I imagine that's pretty limiting for designs.
- Does your API support resizing windows, and if so could you describe your method for negotiating a resize?
- What does the API for clients look like? How are mouse events and keyboard events received? What sort of IPC / shared memory requirements are there? Do you use damage events to flag regions for screen updates?
- Are you using any sort of accelerated methods for blitting windows, eg. SSE?

[trolly]

Could you tell me a bit about how you designed it? How do you do inter-process communication/events like keyboard/mouse presses etc?

it's designed in OOP; the root of all classes is "UIElement";
an uielement contains the base information of the object (position, size, buffer address, etc...) and a binary tree (children/parent/next child/prev child)
there is 3 layers where the controls are drawn:
the root (it's where the window are drawn)
the TopRoot (wich is a binding to the root, it mean, that it has it's own tree, but shares the same buffer than the root) ; there is where the top menu bar, and the modal dialogs will be drawn
the Screen (like an UIElement, else than the buffer points to the LFB, it's to have a direct access to the screen layer)

the mouse Pointer is also an UIElement but it'snt the child of any parent; it's simply blitted on the screen element when a refresh occurs

an element is redrawn only if any of one of its child has to be update (by example, if i colapse the window, i call this.Invalidate() wich will set the "RedrawNeeded" flag to true; and call "Parent.Invalidate()" if there is a parent;

when a refresh of the root or of the TopRoot is done; it copy the buffer to the lfb then it blit the mouse cursor to the screen.

Al primitives are implemented inside the UIElement (setpixel, getpixel, drawline, drawrectangle,fillrectangle,fillrectangle gradient,fill rectangle alpha, etc...) and modify only the uielement buffer

for the mouse events, you have to fill the functions GetMouseX(), GetMouseY(), GetMouseB() according to your architecture (else you poll the mouse register, if you dont use interrupt, else you return the last value updated by the interrupt)
the main loop will use it to detect a change in the mouse coordinate or mouse button status; and handle it

the main loop can be called in you choice:

• *by the os main loop;
  *an irq handler (mouse or keyboard)
  *the sheduler (kernel idel)
  *when a syscall that updates the window (create/add/remove/update control/etc...) occured

- Since you're using 24-bit buffers for all of your elements, I assume you don't support transparency? Since you're using subwindows for GUI elements, I imagine that's pretty limiting for designs.

well , altought it uses 24 bit buffer, it support transparency, i defined the black (&h000000) as the transparent color

- Does your API support resizing windows, and if so could you describe your method for negotiating a resize?

window resizing, is not yet handled , but it will esay to do it, like for the window draging; then when the window is resized, it will "invalidate" it, and all parents, so it will be redrawn the next time; the children will not be redraw, but theyr buffer are blitted to the window's buffer
and also; when you create the window, you can set the OnResized pointer, it will be called when the SetSize(x,y) is called (if the pointer is set); it's usefull to update chidlren position/size; etc... or to inform the user process...
ps: for now, it supports "window colapse" when you right click on the title bar

- What does the API for clients look like? How are mouse events and keyboard events received? What sort of IPC / shared memory requirements are there? Do you use damage events to flag regions for screen updates?

it doesnt provide api for the client, because tas os specific, mouse events are used as described bellow;
you could incorporate it in an user process; then you will have to define yourself the way to comunicate with it (IPC/shared memory/etc...)
or you could incorporate it in the kernel; then you will have to define yourself the syscall for the users processes that will interface with it
in the both case; i think the solution, is to pass as parameter , or as return value a handle for the object (by example his pointer) and do a cast to get the object

- Are you using any sort of accelerated methods for blitting windows, eg. SSE?

nope, because it's platform independant, my goal, is to port it to my future os for rhaspbery pi; but i think we can optimize the blitt method according to the target platform

PS: i did a first test, and this window manager has been successfully ported to my os, without any modification else than the "arch.bas" file wich contains the platform dependant code.

if you want to participate in the development of it, you can contact me by mail at [email protected]

In attachement a new capture, it's the port of the windows manager to my os (there is no process; only a demo interface that define window and button; all are handled by the wm itself) ; as you can see; it also supports alpha blending (look in the clicked menu item; or the drop shadow in the windows or the menu)