Replies: 5 comments 46 replies
-
It is like xterm application, but instead of showing a terminal, 2 icons are visualized - one for xterm and one for nxtetris. Once an icon is clicked the app should appear in a window that can be resized, minimized or closed. |
Beta Was this translation helpful? Give feedback.
-
Hello @ghaerr
Is there a chance we can port the Nano-X window manager you mentioned before? |
Beta Was this translation helpful? Give feedback.
-
Hello @tyama501, It should be pretty straightforward to port the Nano-X window manager from later sources, as it is written using the "Gr" Nano-X API. It was initially written as a separate program but since has been added into the Nano-X server code; the same could be done for ELKS. Of course, having a window manager but no support for separate processes doesn't do much - so having UNIX/Nano-X sockets would be good to port too. I can't recall if we ever tested Nano-X socket support in ELKS, but that also should be fairly straightforward. I can help you with both when you want to get more involved. It may be easier to start with porting the Nano-X WM first, or even combined with a particular application program and all linked with the server. While this all sounds fun, there are very big issues with trying to build a window-based graphical environment on ELKS - it will likely be very slow on all but faster 386 machines, due to the EGA and VGA hardware requiring lots of bit fiddling for display. Also, sending the draw commands through a UNIX socket will be very much slower than linked with server, especially on non-386 machines. The Nano-X EGA/VGA driver isn't really built for speed, and may need to be rewritten in ASM language, much like Doom did. A typical is that a basic window display looks good, but when dragging a window to a new location, or scrolling text, the display is very slow. Thank you! |
Beta Was this translation helpful? Give feedback.
-
Maybe if GEM could be ported to Elks? |
Beta Was this translation helpful? Give feedback.
-
Are these all running? Can they run concurrently? That would be fantastic and a great test of UNIX sockets on ELKS! :)
Yes, it is OK to add at the end. You might want to check the main Microwindows repo for GrGetNextEventTimeout in both client.c and srvnet.c, just to see how it might be implemented. It could be easy as you suggested, or complications so better to look first at the working version over there. Of course, the difference between the functions is that the GrGetNextEvent function will never return until it gets an event, whereas GrGetNextEventTimeout allows for a faked-up timeout event to be returned (which allows nxtetris to continue to move blocks while waiting for the user input). IIRC the faked out timeout is prepared in the main GsSelect() function, so you might want to look there also. I am not looking at the sources, so it depends on whether the non-client/server GrGetNextEventTimeout function is already working (which I would guess it is, since nxtetris works, right?)
The timeout parameter to GrGetNextEventTimeout is an 'int', which is either BLOCK (wait forever), POLL (don't wait for any event, but return one if present else timeout), or the number of msecs to wait. So all timeout_delay() is doing is calling a function to determine the timeout, which essentially determines how fast nxtetris runs (per level, faster=harder).
Yes, the passed timeout value will have to be added to the wrapper function and passed along in the packet traveling between the UNIX sockets. Take a close look and you can determine whether a single function can always be used, which either passes BLOCK, POLL or timeout as the "timeout" value, or whether a separate function is needed. I would think a single function should work. |
Beta Was this translation helpful? Give feedback.
-
I looked into https://github.com/ghaerr/elks/blob/master/elkscmd/nano-X/demos/nterm.c
Is it possible to have a simple "desktop" on ELKS where we start X server with a Window manager and a few icons to click on. The icons will be some simple applications. It will be cool even if it will require 286 or 386 to be fast enough. The idea is to have a single executable for that "Dekstop".
I was inspired by:
What are you thoughts @ghaerr ?
Beta Was this translation helpful? Give feedback.
All reactions