とあるOS [ToAruOS] ~ A Learning Project
Re: とあるOS [ToAruOS] ~ A Learning Project
Been working on my IP stack, but also added some UI features including some simple tiling. Used my older window decoration theme for these screenshots as it looks better with the tiling.
Left-right tiling:
Quarter-tiling:
Prettied up the (kernel-mode) IRC client:
Left-right tiling:
Quarter-tiling:
Prettied up the (kernel-mode) IRC client:
Re: とあるOS [ToAruOS] ~ A Learning Project
Built and tested. It's even better than screenshots
I just noticed that closing the session of the current user programs still run. Shouldn't they be killed?
I just noticed that closing the session of the current user programs still run. Shouldn't they be killed?
Re: とあるOS [ToAruOS] ~ A Learning Project
Oh? Let me know what apps aren't closing when the session ends - they need to respond to a message from the window server to do that correctly, otherwise they will linger, and I probably missed some.Karlosoft wrote:Built and tested. It's even better than screenshots
I just noticed that closing the session of the current user programs still run. Shouldn't they be killed?
Re: とあるOS [ToAruOS] ~ A Learning Project
Snow, gears, fractals. Others like terminal have been closed.
Re: とあるOS [ToAruOS] ~ A Learning Project
Ah, right, of course I forgot the little demos. I'll get those fixed up!Karlosoft wrote:Snow, gears, fractals. Others like terminal have been closed.
- Combuster
- Member
- Posts: 9301
- Joined: Wed Oct 18, 2006 3:45 am
- Libera.chat IRC: [com]buster
- Location: On the balcony, where I can actually keep 1½m distance
- Contact:
Re: とあるOS [ToAruOS] ~ A Learning Project
Wouldn't that be something that would better be handled by default in an UI library?
Re: とあるOS [ToAruOS] ~ A Learning Project
All of the apps speak the raw protocol at the moment. When I get an actual toolkit built on top of it, that'll handle the session-end message. Also, eventually, the system should be able to gracefully handle apps getting killed and close their windows appropriately, but that depends on some major work I have yet to do; once that happens, logout can kill anything that's still left.Combuster wrote:Wouldn't that be something that would better be handled by default in an UI library?
Re: とあるOS [ToAruOS] ~ A Learning Project
I've been working on a couple of things (that are unfortunately not networking).
1. Nested display server.
2. Loading desktop shortcuts from a file (something I should have been doing from the start).
3. Added refcounts to my VFS and finally implemented proper Unix pipes - now bash can happily run pipelines like this simple grep:
My shell still doesn't support pipelines, but I'll look into adding it - its parser is a bit esoteric.
1. Nested display server.
2. Loading desktop shortcuts from a file (something I should have been doing from the start).
3. Added refcounts to my VFS and finally implemented proper Unix pipes - now bash can happily run pipelines like this simple grep:
My shell still doesn't support pipelines, but I'll look into adding it - its parser is a bit esoteric.
Re: とあるOS [ToAruOS] ~ A Learning Project
Added something I had in mind for a while now - window shaping.
I'm piggy-backing off of a window's alpha channel, though only upon request at the moment. A window can request to have its alpha channel (with a tolerance of ~0.5) set as its window shape, and update that as it pleases (or disable it). (These screenshots are from a debug mode that renders the window and then renders (at 0.7 opacity) a semi-unique color in the shape of the window shape on top of it. This means, if the window shape doesn't quite cover the whole of the window, some of the window will show through - the actual select-buffer will have the underlying window in those locations.)
This allows the Gears app to accept clicks only where a gear is present:
The reason I made it so a window has to request a these updates is because generating the 1-bit alpha map has a performance hit that I'm still trying to work around, and thus I don't want a window updating its shape constantly. For the gears app, this means updating occasionally for the sake of testing (though really it's not all that necessary to change the shape of the gears window in most cases). This usually leads to the select-buffer being slightly behind from rendering:
This screenshot is from an earlier version of the debug mode, and shows how multiple gears windows can overlap, without actually overlapping:
I was also playing around with some box blurring for eventual use in possible "glass" effects and with server-side dynamic window shadows, but no screenshots of that, it's all still very experimental and slow.
I'm piggy-backing off of a window's alpha channel, though only upon request at the moment. A window can request to have its alpha channel (with a tolerance of ~0.5) set as its window shape, and update that as it pleases (or disable it). (These screenshots are from a debug mode that renders the window and then renders (at 0.7 opacity) a semi-unique color in the shape of the window shape on top of it. This means, if the window shape doesn't quite cover the whole of the window, some of the window will show through - the actual select-buffer will have the underlying window in those locations.)
This allows the Gears app to accept clicks only where a gear is present:
The reason I made it so a window has to request a these updates is because generating the 1-bit alpha map has a performance hit that I'm still trying to work around, and thus I don't want a window updating its shape constantly. For the gears app, this means updating occasionally for the sake of testing (though really it's not all that necessary to change the shape of the gears window in most cases). This usually leads to the select-buffer being slightly behind from rendering:
This screenshot is from an earlier version of the debug mode, and shows how multiple gears windows can overlap, without actually overlapping:
I was also playing around with some box blurring for eventual use in possible "glass" effects and with server-side dynamic window shadows, but no screenshots of that, it's all still very experimental and slow.
Re: とあるOS [ToAruOS] ~ A Learning Project
Added some quick shebang support. I don't know if I'm doing it all to the letter, but it works for bash scripts and Python scritps
I apparently have neglected to write a chmod binary - despite having had the syscall and library function for over a year now. I had to hop into a Python repl and run os.chmod to set the execute bit on the Python script after writing it.
I apparently have neglected to write a chmod binary - despite having had the syscall and library function for over a year now. I had to hop into a Python repl and run os.chmod to set the execute bit on the Python script after writing it.
Re: とあるOS [ToAruOS] ~ A Learning Project
Did a bunch of cleanup in my `ls`, and implemented a fancy `pstree` using my procfs:
Re: とあるOS [ToAruOS] ~ A Learning Project
You know that thing on my panel that says "Applications"? It's been a dummy label until now:
Still needs some styling, but it's functional, disappears when you click out of it, and takes a config file same as the desktop.
Still needs some styling, but it's functional, disappears when you click out of it, and takes a config file same as the desktop.
Re: とあるOS [ToAruOS] ~ A Learning Project
somebody can link me an iso, please?
Operating system for SUBLEQ cpu architecture:
http://users.atw.hu/gerigeri/DawnOS/download.html
http://users.atw.hu/gerigeri/DawnOS/download.html
-
- Posts: 5
- Joined: Mon Jul 25, 2016 7:09 pm
Re: とあるOS [ToAruOS] ~ A Learning Project
i tried. when i run ./install.sh
it show an error.
Build failed. Please check the logs above to see what went wrong.
this is the whole error
Configuring in ./binutils
configure: loading cache ./config.cache
configure: error: `YACC' has changed since the previous run:
configure: former value: `/home/shashwat/Downloads/ponyos-master/toolchain/tarballs/binutils-2.22/missing bison -y'
configure: current value: `bison -y'
configure: error: in `/home/shashwat/Downloads/ponyos-master/toolchain/build/binutils/binutils':
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and start over
Makefile recipe for target 'configure-binutils' failed
make[1]: *** [configure-binutils] Error 1
make[1]: Leaving directory '/home/shashwat/Downloads/ponyos-master/toolchain/build/binutils'
Makefile:838: recipe for target 'all' failed
make: *** [all] Error 2
Build failed. Please check the logs above to see what went wrong.
it show an error.
Build failed. Please check the logs above to see what went wrong.
this is the whole error
Configuring in ./binutils
configure: loading cache ./config.cache
configure: error: `YACC' has changed since the previous run:
configure: former value: `/home/shashwat/Downloads/ponyos-master/toolchain/tarballs/binutils-2.22/missing bison -y'
configure: current value: `bison -y'
configure: error: in `/home/shashwat/Downloads/ponyos-master/toolchain/build/binutils/binutils':
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and start over
Makefile recipe for target 'configure-binutils' failed
make[1]: *** [configure-binutils] Error 1
make[1]: Leaving directory '/home/shashwat/Downloads/ponyos-master/toolchain/build/binutils'
Makefile:838: recipe for target 'all' failed
make: *** [all] Error 2
Build failed. Please check the logs above to see what went wrong.