Start Menu
Re:Start Menu
Come on - that's not the first time you ask this type of question:
Please be more precised - nobody is able to understand what you are trying to say.
Please be more precised - nobody is able to understand what you are trying to say.
Re:Start Menu
Please _try_ to stuff at least _some_ information in your post. It really isn't that hard. Better to write too much than, in this case, more or less nothing since no one can give a detailed answer to your questions.nuno_silva_pt wrote: How can i make a start menu for my o.s.? ???
But to your question... you can do it the way Windows do it. Create a directory/folder and display the content of it when the menu is pulled down. Actually this only covers the Program menu... but it can be used on the rest too...
It can be done in various other ways too... but unless you specify your question a bit more I can't answer more precise than this...
Re:Start Menu
Hi, firstly I am just curious: Tim Robinson, is implementing GUI done after creating OS? I mean isnt gui a kind of shell? Shouldnt it be done while ereating os? So shouldnt order be like:
1) Make OS up to GUI stuff
1-a) Implement Buttons
1-a) Implement Icons(OPTIONAL)
1-a) Implement Bar functionalty
1-b) Make a start menu
;D THanx...
1) Make OS up to GUI stuff
1-a) Implement Buttons
1-a) Implement Icons(OPTIONAL)
1-a) Implement Bar functionalty
1-b) Make a start menu
;D THanx...
Re:Start Menu
1) Make OS up to GUI stuff
1-a) Implement Buttons
1-b) Implement Icons(OPTIONAL)
1-c) Implement Bar functionalty
1-d) Make a start menu
Im sorry, I have mistaken... This is the correct form... Sorry for taking space...
1-a) Implement Buttons
1-b) Implement Icons(OPTIONAL)
1-c) Implement Bar functionalty
1-d) Make a start menu
Im sorry, I have mistaken... This is the correct form... Sorry for taking space...
Re:Start Menu
why are people so gun-ho on making GUI's? this seems like the most boring part of writing an OS
Re:Start Menu
It's the visibility factor, exactly the same principle applies when you see people wanting to get their bootloader finished and jump straight into having the kernel put something on the screen. Visual stuff, even if just text, gives you that easy to achieve boost. The more tiresome work of reading through manuals and tuning the invisible code takes a bit more imagination to get inspired by.elias wrote: why are people so gun-ho on making GUI's? this seems like the most boring part of writing an OS
Re:Start Menu
The most boring part? By no means. The GUI is how you show off your OS. Part of the appeal of MacOS (and XP, to a lesser extent) is the nice, curved look, the easy to use interface. You could write a very simple O.S. that basically will read text and write text, and slap a face on it that's beautiful, more people will want to use it than an OS that...burn CDs at twice the burners speed (impossible, I know but I can hope ) that looks ugly and is hard to use.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Start Menu
nuno_silva_pt, you're addressing the problem by the wrong edge. When you want to make a word processing program, you don't ask yourself how you will have icons for "save", "print", etc. in a bar that you can move accross your window. You first ask yourself how you will represent text, how you will implement basic operations like extracting text from one paragraph and put text into another one, how you will deal with embedded objects like pictures, etc. or how you will store your text efficiently on a file.
Now, consider back your question. You can easily make a start menu with
But what will you do with it ?
As long as you have no file system to load programs ? nor an infrastructure to give programs access to the hardware ? The very minimal steps if you want to have a "working" start menu would be:
Maybe with better protection between apps ...
Now, consider back your question. You can easily make a start menu with
Code: Select all
ytop=screen::height-(default::font::height+2*gui::padding);
xend=font::guess_size("Start")+gui::padding*2;
gui::rectangle(0,ytop, screen::width, screen::height,R_FILL,GREY);
gui::rectangle(0,ytop, xend ,screen::height, R_3D,GREY);
font::render(gui::getbuffer(0,ytop, xend, screen::height, USE_PADDING), "Start");
As long as you have no file system to load programs ? nor an infrastructure to give programs access to the hardware ? The very minimal steps if you want to have a "working" start menu would be:
- have programs loaded in memory. And provide a fs-approach to access them. It can be very easy if you use GRUB modules to map programs in memory: you just need to create a virtual directory service that will remember at which physical memory address the image of FILE.COM is located and return that address when we do open("file.com")
- have user-level programs executed when requested. The easiest approach is to create a segment for the user's code and one for its data. Then return to the program. You can even not worry about multitasking and decide every kernel operation will occur when an interrupt arise (that's how DOS works
But you will at least have 1a. implement interrupts support and 1b. implement basic segmentation support. If you're fine with ASM, load ASM programs as a first step. - have the kernel access hardware. It should at least be able to receive the keyboard datas (and translate them ?), setup video display and read mouse events. The most simple GUI at kernel level would be get_video_segment(), set_mouse_buffer(), set_keyb_buffer(). The kernel know then where it should put datas.
You can even protect your "start menu" from the user application by excluding the last lines of the display from the "video segment" you return to the application.
Required steps are 2a. video driver (get a frame buffer), 2b. mouse driver (have a cursor moving on screen) and 2c. keyboard reader (have keystrokes translated and written to some memory area) - read available programs from the virtual file system and build up the list of "start menu" with it. Ideally, this should be done by some programs external to the kernel, but let's say you do it in the kernel (at initialization) for now.
- when the start menu is clicked, popup the list. When an item is selected, start the application and freeze the currently running one. When the task bar is clicked, unfreeze the selected application. When the "user area" is clicked, defer the click to the application (send it an event).
this requires 3a. Process control: select which program is currently running and 3b. Process sleep & wakeup: let the application decide that it have nothing to do but waiting something to happen and let the kernel return to the application only when something occured.
Maybe with better protection between apps ...