Wm, what way?

[roelforg]

Hello,
I saw what you guys have for wm's and then i saw that i can't get futher then a square with a border being moved by a mouse...

So i was wondering how those great gui's work...
There's little documentation about it.

How do your gui's work???
I've seen many ways, i tried a array containing the window data, but that won't work...

Share the inner secrets of your gui's with us!

Although the wm is nowhere nere complete,
I do have a very fast, double bufferd VGA-driver (it has an system to make sure it only writes the bytes from buffer to vidmem which changed):
Eg.

Code: Select all

unsigned char vidmem[320][200]; //lets say this is our vidmem, i know the real mem work diffrent but this is easyer to read, the real driver has this corrected
unsigned char buffer[320][200]; //buffer[x][y]
unsigned char bufferb[320][200]; //the secret weapon, it keeps track of the last buffer so only the changed pixels are written, although more cpu and less mem, cpu is faster than mem, speeding the proces and being improved upon double buffering

void updatevga() //syncs buffer with vidmem
{
for (int x = 0; x < 320; x++)
for (int y = 0; y < 200; y++)
{
if (buffer[x][y] != bufferb[x][y])
{
vidmem[x][y] = buffer[x][y];
bufferb[x][y] = buffer[x][y]; //just as the vidmem, only changed pixels are updated
}
}
}

void initvga() //inits driver
{
for (int x = 0; x < 320; x++)
for (int y = 0; y < 200; y++)
{
buffer[x][y] = 0x00;
bufferb[x][y] = 0x00;
}
//...init the vga driver, this can be found online
}

I shared my visual secret (hope its helpfull), now it's your turn!

Short: I want to know how you think a wm should look/be programmed.

[Combuster]

Short: I want to know how you think a wm should look/be programmed.

What is your religion of choice?

Graphics in kernel, Graphics in a server, Window manager in kernel, Window manager in a server, No windowing at all, Custom protocol, X windows, Tabs, Viewports, Taskbars, Multihead, Single user, Multiuser, Acceleration, Compositing, Standard interaction components, Gnome, KDE. There are just too many alternatives to go past them all.

And as far as implementation goes, first make a choice regarding the features above, then let loose your software architecture skills (Take a course where necessary. If you can't implement a proper MVC without resorting to internet when you read this, that course is a mandatory one).

[roelforg]

All right:
wm in kernel
no server (all direct video driver calls)
multiwindow
Oh, and i meant that i want to know if there are some special techniques i need to know,
One of them is how you create a window stack where the window is movable in the stack (eg bring to front)

But i've been busy reading books on wm design and now have an idea of how an window will be made up (just to give an idea on how i'm gonna print a window):

Code: Select all

struct window_t {
unsigned int x, y, w, h; //self explaining, w=width drawable area, h=height drawable area
char *title; //this too
unsigned char *data[]; //will hold the drawable area of the window, window.data[x+y*window.w];
//some more things will follow (an extra buff for the speed, extra configs, etc)
};

That window will be drawn at (x,y) with w+2 and h+19.
The width is +2 due to 1px border
The height is +19 due to the borders and the top bar
Topbar, borders are drawn by the main wm_refresh()
The data property is just what the app want's to print, borders, topbar, etc are drawn around it.

What i'm still wondering is how the windowstack works,
i want to know how you make an window that's moveable in the windowstack?

Ps. That principle for a faster driver is free to use under MIT licence, i'm not responsible for damage).

[Brendan]

Hi,

Stop reading those books - they're probably old/obsolete "text mode user interface" stuff!

Some random thoughts:

Code: Select all

struct window_t {
    struct window_t *next;            // Pointer to the next window in the stack (NULL if none)
    unsigned int x, y, w, h;          // self explaining, w=width drawable area, h=height drawable area
    unsigned int topSize, bottomSize; // The sizes of the window decoration
    unsigned int leftSize, rightSize; // The sizes of the window decoration
    unsigned int attributes;          // If it's hidden/minimised, visible, currently selected (has focus), etc
    uint32_t *title;                  // Title, in UTF32
    VIDEO_COMMAND_LIST *windowTop;    // List of commands to send to video driver/s to redraw window decoration
    VIDEO_COMMAND_LIST *windowLeft;   // List of commands to send to video driver/s to redraw window decoration
    VIDEO_COMMAND_LIST *windowRight;  // List of commands to send to video driver/s to redraw window decoration
    VIDEO_COMMAND_LIST *windowBottom; // List of commands to send to video driver/s to redraw window decoration
    VIDEO_COMMAND_LIST *windowData;   // List of commands to send to video driver/s to redraw window's main data area
};

Cheers,

Brendan

[roelforg]

Brendan:
I don't get what that pointer to the next window has to do with moving the window in a stack.
And please, quit editing how the window looks/is configured,
it's my os and that you would make your wm look that way, fine, but i want it diffrently (i like em simple and easy to use/create programs for).

This thread is about how the window stack works, and what other designers idea is about yes/no taskbar, yes/no desktop icons, etc.

Oh, and brendan, those books are about designing x11 wm's, i just read them for general management and look of (edit: fixed typo) the wm, i already have that so please don't change that.

Ps. I also have code for starting the window/process:

Code: Select all

Wm:
createWin(id, 40, 40, 40, 40); //psuedo code
exec("program");
destroyWin(id); //psuedo code

Program:
int main()
{
int id = WM_getId();
WM_editWindow(id, title, x, y, w, h);
WM_setPixel(id, x, y, colour);
}

Besides this i add:
int id; //unique id for the window, not connected to drawing, just to know which window to use
char *fn; //exec filename so we can find the correct id!
To window_t

[Combuster]

One of them is how you create a window stack where the window is movable in the stack

If you can't implement a proper MVC without resorting to internet when you read this, that course is a mandatory one

IQ test failed?

[roelforg]

Who said i'm gonna use MVC???
Sorry, but i just don't like the complexity it brings.

I this principle:
App writes to buffer as if writing directly to vidmem,
Buffer is passed to wm who draws borders and topbar and put's it all in the right place and now the video driver updates the screen

Edit: just did an iq test: iq=170 (i imaging that you're doing: )
Edit2: just found results from last years iq test, it came out at 149. So i don't know which to trust, yet both pretty high scores.

[Combuster]

You avoided the question I originally asked. No matter since I have enough circumstantial evidence that you don't know your computer science basics, and on top of that you just mentioned you don't care about fixing that problem at all.

If you need to learn things the hard way, so be it. Please don't bother us.

[roelforg]

You avoided the question I originally asked. No matter since I have enough circumstantial evidence that you don't know your computer science basics, and on top of that you just mentioned you don't care about fixing that problem at all.

If you need to learn things the hard way, so be it. Please don't bother us.

I said i'm not gonna use mvc, i didn't say i wasn't going to use any model, just not mvc,
I already have an diffrent one, much simpler and just as powerfull.
If you care, probarbly not, i remove the intermediate step in mvc, the running program directly receives input from drivers (when it askes for it), any output is collected and send to the video driver only altert by the buffering sys.
Mvc has a model (the program) an ui (user mode ui) and an controller (linking both and the kernel together), but since the wm will be in the kernel, the controller and view are the same thing and are hard to seperate.

I answerd that at the top of my second post,
And be reasonable, i'm still a human, you can't expect me to know/understand everything about a subject for which most docs involve x11 which already solved that specific by itself.
Oh, i'm a programmer since 7 years ago and before that i mostly designed little robots (mostly automatic cars) and got extra money for repearing pc's. So i just wanted to know what's behind the hood of an pc, and started building an os to better understand pc internals but i started to like this and just went on and now i'm actually trying to make a fully grown os (i'm in 70% done in 3 weeks of coding and 3 weeks of theory/reading).

[roelforg]

I decided to use my own model (no mvc!!!):
I have a process and a presentor.
Process sends output to presentor who formats the data add the ui and prints it to screen using a video driver
Also the presenter gathers user input and the process can request that data and act upon it.

It's basicly mvc/mvp combined and slightly diffrent.

[gravaera]

Ps. I also have code for starting the window/process:

Code: Select all

Wm:
createWin(id, 40, 40, 40, 40); //psuedo code
exec("program");
destroyWin(id); //psuedo code

Program:
int main()
{
int id = WM_getId();
WM_editWindow(id, title, x, y, w, h);
WM_setPixel(id, x, y, colour);
}

Besides this i add:
int id; //unique id for the window, not connected to drawing, just to know which window to use
char *fn; //exec filename so we can find the correct id!
To window_t

The WM doesn't auto create a new window for every process which is executed. If a process requires a GUI setup with a window, it will bind to the WM itself, then create as many windows as it needs, etc. A process could very well run and never put a single pixel to the screen or even write to stdout.

--Peace out
gravaera

[gerryg400]

Ps. I also have code for starting the window/process:
Code:

Code: Select all

Wm:
createWin(id, 40, 40, 40, 40); //psuedo code
exec("program");
destroyWin(id); //psuedo code

Program:
int main()
{
int id = WM_getId();
WM_editWindow(id, title, x, y, w, h);
WM_setPixel(id, x, y, colour);
}

This won't work because the destroyWin is called right after the exec. The window will most likely be destroyed before the program starts.

[Brendan]

Hi,

Brendan:
I don't get what that pointer to the next window has to do with moving the window in a stack.

To have a stack of windows, you need to have some sort of order (and then some way of changing that order). A linked list of "window structures" seems the easiest way to achieve that.

And please, quit editing how the window looks/is configured,

I was only suggesting alternatives/improvements; like adding some flags/attributes to track a window's state, changing the title to Unicode so that it's not limited to crappy/obsolete ASCII and doesn't become a mess for internationalisation later, and separating the GUI's "window decoration" from the application's "window contents" so that it's easier for these entirely separate processes to handle their own responsibilities (e.g. without worrying about trashing each other's data).

The other change I suggested was discarding the fundamentally flawed "raw pixel" approach, like everyone else did several decades ago. It's unable to take advantage of 2D/3D acceleration in future, unable to handle multiple monitors elegantly, unable to handle resolution independence and colour depth independence (which makes it a pain for application developers), is much slower because processes are shifting large amounts of pixel data around (rather than much smaller lists of graphics commands), much harder to avoid wasting time drawing stuff that's obscured (e.g. underneath other windows, past the edge of the screen, etc), makes it harder/more expensive to generate thumbnails, makes it much harder to do special effects (e.g. zoom in/out, transparency, window shading, 3D effects like Microsoft's "Flip 3D" and other compositing stuff), etc.

I decided to use my own model (no mvc!!!):

MVC is an approach that application developers might use when designing the internals of an application; and the same ideas could be applied to the internal design of a GUI or a WM. However, it has nothing to do with any/all layers below that (e.g. drivers, kernel, etc) or the relationships between those lower level layers.

If you care, probarbly not, i remove the intermediate step in mvc, the running program directly receives input from drivers (when it askes for it), any output is collected and send to the video driver only altert by the buffering sys.

So, when the user clicks on a mouse button, somehow the mouse driver figures out which process owns the window that happened to be underneath the mouse pointer at the time, and sends the mouse click to that process, and then (if the window didn't have focus) somehow the GUI (that wasn't told anything) brings that window to the top of the window stack?

I can't see how that can work with a nice clean design. It sounds like pieces of the window manager have to be scattered all over the place, with no clear boundaries between the separate pieces.


Cheers,

Brendan

[roelforg]

All right:
createwin sets up the window and adds it to the refresh list

Also, exec doesn't create anew thread, so only after a finished program the destroy call is made.

Oh, the mouse driver only processes the x and y of the mouse, the wm knows what window it is

When i get on my other pc, i'll draw you a scheme of how i think it will work, as they say: "a picture tells more then a thousand words".

[roelforg]

The schemes are attached.
also, brendan, i didn't mean to hurt you, i know you meant it nice but your way of drawing borders and topbars doesn't work with my idea. thx thought

To have a stack of windows, you need to have some sort of order (and then some way of changing that order). A linked list of "window structures" seems the easiest way to achieve that.

and thanks for that, now i get it!

i'll try the new findings and idea's and post the results