Hi,
I was wondering what would be the best way to program a simple window manager in C. I am in 320x200 graphics mode, and I can draw a simple window and move it around with the arrow keys and resize it, but I would like a better system. I am in 32 bit pmode.
Thankyou in advance,
Stephen
Implementing a simple window manager
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:Implementing a simple window manager
Well... good... hm, I think, that's ok.
So you want to write your own GUI(tm).
First, you need memory management - especially heap memory management. we will put the book keeping info into the heap to avoid limit ourselves in static arrays.
Then you build a structure which holds info about:
id of the window, to whom the window belongs,
x position, y position, width, height, pointer in the z-order list, pointers into the tree organization of windows (where also the hidden ones are listed)
You chain the window object together in two different structures. One is the tree (can be used for mdi-stuff), the other one is the z order list (which tells the order in which windows are to be drawn - from bottom to top)
from the z order ist you need to calculate your clipping: i e per window list of rectangles: the visible area/s of the window.
An other approach is to keep a map of integers as large in resolution as your screen. in this map you keep the information to which window a region of the screen belongs to - per pixel. this means that for each pixel you are about to set inside a given window you need to look into this map first to check if the pixel belongs to the window in question.
It might be intrigueing to check out a mixture of the two of these approaches.
As you are already moving/resizing a window I don''t think I have to rant about this too much.
Just keep in mind, that for the move, you have to repaint what 's been beneath the window. I've buildt a buggy version of checking who's been covered: I'm redrawing everything beneatch which even MIGHT intersect with the moving window - althou it's totally obscured. Nonsense this is and performance stealing.
Best Hint gathered so far: paint the window to drag into an offscreen buffer and paint this one to the main offscreen buffer (ere blitting to screen after all the other operations). This one 's by Pype. Second HInt I can give: think about a way to avoid background redrawing too.Upon dragging, with stored away window: first clip the background without the dragged window. Redraw, what's been beneath. Blit that to screen. Then blit the window to screen. Change of position. Blit background to screen. Blit window to new position on screen. Don't know, if that wouldn't flicker like Hell. Haven't tried it yet.
stay safe and hth.
So you want to write your own GUI(tm).
First, you need memory management - especially heap memory management. we will put the book keeping info into the heap to avoid limit ourselves in static arrays.
Then you build a structure which holds info about:
id of the window, to whom the window belongs,
x position, y position, width, height, pointer in the z-order list, pointers into the tree organization of windows (where also the hidden ones are listed)
You chain the window object together in two different structures. One is the tree (can be used for mdi-stuff), the other one is the z order list (which tells the order in which windows are to be drawn - from bottom to top)
from the z order ist you need to calculate your clipping: i e per window list of rectangles: the visible area/s of the window.
An other approach is to keep a map of integers as large in resolution as your screen. in this map you keep the information to which window a region of the screen belongs to - per pixel. this means that for each pixel you are about to set inside a given window you need to look into this map first to check if the pixel belongs to the window in question.
It might be intrigueing to check out a mixture of the two of these approaches.
As you are already moving/resizing a window I don''t think I have to rant about this too much.
Just keep in mind, that for the move, you have to repaint what 's been beneath the window. I've buildt a buggy version of checking who's been covered: I'm redrawing everything beneatch which even MIGHT intersect with the moving window - althou it's totally obscured. Nonsense this is and performance stealing.
Best Hint gathered so far: paint the window to drag into an offscreen buffer and paint this one to the main offscreen buffer (ere blitting to screen after all the other operations). This one 's by Pype. Second HInt I can give: think about a way to avoid background redrawing too.Upon dragging, with stored away window: first clip the background without the dragged window. Redraw, what's been beneath. Blit that to screen. Then blit the window to screen. Change of position. Blit background to screen. Blit window to new position on screen. Don't know, if that wouldn't flicker like Hell. Haven't tried it yet.
stay safe and hth.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:Implementing a simple window manager
BTW: for the window moving and window resizing: you will want to have dedicated controls setting the window_drag or window_resize state in the state machine of the gui subsystem (well, I do so - have the controls change states inside their event handlers)
You might have a look at
www.distantvoices.org ->blueillusion os->design considerations.
I've collected some thoughts about drawing, clipping and sorta near the end of that page - even with some neat pictures .
You might have a look at
www.distantvoices.org ->blueillusion os->design considerations.
I've collected some thoughts about drawing, clipping and sorta near the end of that page - even with some neat pictures .
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image
Re:Implementing a simple window manager
double buffering is usually a good idea too...unless you'd like to have your eyeballs poping off your head one day.
Re:Implementing a simple window manager
Hi,
I'm pretty sure I don't have heap memory management, as I just have malloc() and stuff.
So the structure is set up like this, right?
Then do I need structures for the z-order and the tree organisation lists too?
Stephen
I do use double buffering already.double buffering is usually a good idea too...unless you'd like to have your eyeballs poping off your head one day.
I'm pretty sure I don't have heap memory management, as I just have malloc() and stuff.
So the structure is set up like this, right?
Code: Select all
struct window[max_windows] {
int id;
int x;
int y;
int length;
int height;
int* z_order; // or char*
int* tree };
Stephen
-
- Member
- Posts: 1600
- Joined: Wed Oct 18, 2006 11:59 am
- Location: Vienna/Austria
- Contact:
Re:Implementing a simple window manager
malloc() & free() are the essentials of heap management. You also have a call to the kernel to request more heap memory if needed?
well ... here's what I'd propose:
that's the basics which I use to manage windows.
You gonna need tree list management and double linked list management but this all is to your liking. you can manage them in your own way. The above is merely a proposal.
well ... here's what I'd propose:
Code: Select all
typedef struct window{
int id;
int x;
int y;
int width;
int height;
int listener_pid;//process this window belongs to
int listener_tid;//id of the listener - can also be the process
struct window *z_next; //for z-order list
struct window *z_prev; //dito
struct window *head;
struct window *tail;
struct window *next;
}window_t;
window_t *z_list_head;
window_t *z_list_tail;
window_t *windows;
You gonna need tree list management and double linked list management but this all is to your liking. you can manage them in your own way. The above is merely a proposal.
... the osdever formerly known as beyond infinity ...
BlueillusionOS iso image
BlueillusionOS iso image