Now updated to 1.11. You can check the changelog in the original post.
gamax92, on 24 March 2013 - 07:47 AM, said:
I will thank you for not putting a startup screen. Many people who put this in their "operating system" just do it for the fun.
Yeah, my personal preference is not to have a startup screen. That being said, some people (such as the post above yours) seem to enjoy having one or having the ability to log in as different users. If I ever added one it'd be completely optional (probably disabled by default) so that the user can choose which they prefer.
gamax92, on 24 March 2013 - 07:47 AM, said:
Pressing Ctrl-T at the main screen says Terminated and some lines on screen get scrolled, but then the clock keeps going.
Just noticed that... this issue should be caused by the new widget update (1.1). What happens is you are terminating the clock widget, so it displays the "Terminated" text. Since I only update/redraw certain parts of the screen at certain times, only the clock will redraw since that's the only thing changing. To counter this now, I make sure that all widgets cannot be terminated by adding "os.pullEvent=os.pullEventRaw" to the first line of a widget's code before running it. You can now get this change by updating (now at version 1.11). I'm a bit worried of some other bugs added by the 1.1 update because new things are running in parallel with Jupiter, so we'll see if any other issues come up.
One thing to note is that "widgets" are not supposed to print to the terminal, otherwise it'll interfere with Jupiter's drawing and make things look weird. The intention of a widget is to run in the background and display stuff on monitors or provide functionality other than drawing to the screen. You can set a program that writes to the terminal as a widget, but I'd advise against that because it will obviously cause issues.
gamax92, on 24 March 2013 - 07:47 AM, said:
It also doesn't protect its files. Anyone with this could just run the lua prompt, use shell.run("/rom/programs/shell") and delete startup.
Not all things are idiot-proof, and I'm sure there are other ways to break stuff. However, if the user wants to exit Jupiter and delete important files, I don't see that as my problem. I'd prefer to have too little security than to limit too much what can be done, and I feel that security outside of the Jupiter interface is not my concern. That being said, I do provide some protection through my file browser, where you should be prevented from deleting anything within the 'jupiterOS' folder or 'rom' folder. Because the file browser is part of my interface and is designed to be user-friendly, I obviously want some security there, so it is implemented in these kinds of places. I'm sure I missed some holes and safety protection in some areas, so it's probably not perfect yet.
gamax92, on 24 March 2013 - 07:47 AM, said:
The clock will read 12AM as 0AM
I've seen that, I should probably get to fixing that soon.
gamax92, on 24 March 2013 - 07:47 AM, said:
The screen tends to flicker quite a lot when updating, do you not only update screen changes?
Oh, I definitely agree. I need to make more optimizations and perhaps add some sort of screen buffer. Some things that require redrawing most of the screen at a relatively fast pace (such as scrolling) can be difficult to do without some degree of flickering, so we'll see what I can do about that. Screen changes should be the only time things are updated, but it's not all perfect yet, and there may be bugs that cause issues with this.
gamax92, on 24 March 2013 - 07:47 AM, said:
When there is no disk drive, the DJ will flash a message about No music disk, but will disseaper instantly.
Currently Jupiter automatically refreshes after a program ends, so programs that return instantly currently aren't the emphasis on what should be ran on the home screen. If you try running a program in the file browser, you'll notice I pause and wait for keyboard input to refresh the screen ("press any key to continue"), which is very convenient for reading error messages and running programs that instantly return. What I could do is have an option to wait for keyboard input before redrawing (like with file browser) for each homescreen shortcut (a true/false similar to the 'arguments' option for homescreen apps), so that programs like DJ could wait for a key to be pressed before returning to the home screen.
gamax92, on 24 March 2013 - 07:47 AM, said:
Also, I see the task bar at the bottom, but running a program doesn't make the task bar stay, instead the program takes over the screen.
I've never thought of it as a 'task' bar before, even though it looks a lot like Windows' task bar. That's mainly meant to be a menu bar for the home screen, and currently drawing that over a program would be difficult to do. Good suggestion, though, so I may look into it in the future. I probably want to redo how programs are drawn/run for screen buffer and multitasking functionality anyways (probably not right now, but eventually), so perhaps that may be an option in the future.
gamax92, on 24 March 2013 - 07:47 AM, said:
This really just seems like a Graphical shell at the moment, but this is some nice progress and work.
It is just a graphical shell. I thought OS sounded more appealing and everyone else seems to call their graphical shells an "OS", so that's what I did as well.
NonstopGamer, on 24 March 2013 - 08:45 AM, said:
Wow, this is possibly the best OS I've seen.
Suggestion: in the post, put spaces in between the pictures so it is easier to tell apart.
Thanks! There should be some spaces between the pictures now, hope that helps.