What is oxygen?

Oxygen is an additional graphical library for the CE toolchain that allows you to develop GUI-intensive programs faster! “are you tired of programming the bare bones of a simple program?!” Don’t worry, just use oxygen. Oxygen used to be for Xenon only, but I saw the desperate need of new developers wanting to develop powerful graphical programs.

With the growing popularity of cursors being used in programs on CE calculators, Oxygen comes with a built-in cursor system and, of course, a widget system. Oxygen comes with a bundle of features. You can read about them below.

Features
  • Cursor System: “I want to use a mouse rather than keys to navigate”
    • Moveable Mouse.
    • Customizable Key logs.


  • Widget System: “I want a menu and slider in it!”
    • Based on GTK.
    • Customizable Colors.
    • Works with other systems.
    • Tons of widgets to use.


  • Graphical Functions: “I want rounded rectangle or experiential shapes (Curved lines)!”
    • Different Shapes
    • Color Conversions.


  • Developer Insights: “Hey! What’s going on with my program??”
    • Compile with “make debug” to view debug information in CEmu.
    • Comments everywhere.
    • Compatible with C++!


  • GUI System: “How do I create a text input? I want my user to choose a color!”
    • Battery indicator and Clock.
    • Customizable colors.
    • Text input.
    • Color Selector.


  • Saving System: “I don’t know how to save my data from Oxygen!”
    • Automatic Appvar Saving!
    • ...



Examples: "Oxygen has been in development for a while here are a few examples of what oxygen can do."


Oxygen was used to develop Xenon CL, a command line shell!


Oxygen was used to create Xenon a power graphical shell! (Not completed)


Oxygen was used to create a frog pet simulator Demo!


An early version Oxygen version was used in Scratch CE!


Oxygen was used to create a simple Simon says demo!

Documentation (Under Development): https://alvajoy.slite.com/api/s/_fJsK_ZwIdXyCh/Oxygen
Github: Releasing very soon!

My end goal is to develop something very useful for new developers that want to develop quick graphical programs/projects!

What do you think about Oxygen? Feel free to a reply!
Hey, Alvajoy! Although I won't be able to contribute to this amazing idea. I honestly think it'll be pretty nice. Two suggestions though, first the site that you have linked doesn't scroll so you have to zoom out in order view the whole page, secondly the GitHub link in that site to the library is not a valid link. As such, I can't really comment about the libraries. However, as I have been doing something similar with my own shell (GrannySmithOS), I can say that this is an EXTREMELY great idea. Oftentimes, new developers (like me) end up wasting time coming up with simple routines such as inputing text/numbers while in gfx. So I really think that this will be a super handy idea that will really take off! Can't wait to see all the new functions!
ProgrammerBobSmith wrote:
Hey, Alvajoy! Although I won't be able to contribute to this amazing idea. I honestly think it'll be pretty nice. Two suggestions though, first the site that you have linked doesn't scroll so you have to zoom out in order view the whole page, secondly the GitHub link in that site to the library is not a valid link.


Hey Bob, this isn't an idea this is a work in progress almost ready for pre-alpha ... I also haven't linked a GitHub page whatsoever, I also won't be posting anything on GitHub publicly until the first release. The documentation site seems to work just fine for everyone else.

ProgrammerBobSmith wrote:
As such, I can't really comment about the libraries. However, as I have been doing something similar with my own shell (GrannySmithOS), I can say that this is an EXTREMELY great idea. Oftentimes, new developers (like me) end up wasting time coming up with simple routines such as inputing text/numbers while in gfx. So I really think that this will be a super handy idea that will really take off! Can't wait to see all the new functions!


I think the library would be very useful for you! Thanks for the support!
Alvajoy123 wrote:

Hey Bob, this isn't an idea this is a work in progress almost ready for pre-alpha ... I also haven't linked a GitHub page whatsoever, I also won't be posting anything on GitHub publicly until the first release. The documentation site seems to work just fine for everyone else.


Even better! Very Happy
Someone should create a project named Iron that can be used with Oxygen so we can get Rust support.
DrDnar wrote:
Someone should create a project named Iron that can be used with Oxygen so we can get Rust support.


lol would love to someone create a program called iron! isn't there already rust support on the CE?
Alvajoy123 wrote:
DrDnar wrote:
Someone should create a project named Iron that can be used with Oxygen so we can get Rust support.


0x5 would love to someone create a program called iron! isn't there already rust support on the CE?


I'll make an Iron toolchain from the stuff I have made that I use for GrannySmithOS! lol, that's such a greatly funny idea! Razz
ProgrammerBobSmith wrote:
Alvajoy123 wrote:
DrDnar wrote:
Someone should create a project named Iron that can be used with Oxygen so we can get Rust support.


0x5 would love to someone create a program called iron! isn't there already rust support on the CE?


I'll make an Iron toolchain from the stuff I have made that I use for GrannySmithOS! 0x5, that's such a greatly funny idea! Razz


Sounds Pretty Fun! Hopefully the iron toolchain will be using Oxygen when it comes out! Razz
Update: I know it has been a while since I posted about Oxygen but currently working on development, documentation, and trying to make Oxygen super easy to find on Github.

Please let me know if you have any questions about Oxygen!
This sounds like a great project!

I think you should add 2 hydrogen next
Michael2_3B wrote:
This sounds like a great project!

I think you should add 2 hydrogen next


Thanks! Believe it or not, Oxygen used to be called hydrogen before I changed it to oxygen because everyone needs oxygen to survive.
Hello Cemetech, It's been a while. Razz

You are probably wondering how Oxygen development has been going. Well, I've been working on Oxygen for quite some time now.

Last time, Oxygen had tons of features, including widgets, graphical shapes, file and user management, and notifications. So because Oxygen was so big, I ended up splitting some of the features and creating new libraries:

Here are the libraries:


Hydra
Hydra is the file and user system of Oxygen. You are probably wondering why I called it Hydra—because Hydra is the "beast" of all file systems! Anyway, after splitting the file system from Oxygen, I spent the past few weeks cleaning it up and fixing some issues with it. It should be ready for testing ... Here is the link to the Github. There isn't much documentation on it, but I will add some in the coming weeks. For now, you can look around and see how things work.


Notify
Notify is the notification feature of Oxygen. As you can see here, I kept the name simple: "NOTIFY". As of now, the library is still under development, but for now, you can look at the github.


That's all for now! What do you think about the new libraries?
I've had a look at Hydra on that Github page, as I think that's a bit more interesting than the notification program. Here are some of the things that I noticed:

- I have a lot of fears about the space efficiency of the program. It looks like you're allocating a massive array of structs for the files and folders, which are all excessively large, containing information that you don't need to have saved at all times, such as the program icon and archived/locked/hidden status. Additionally, it seems very unnecessary to give every single file on the calculator an entry in this filesystem which is stored on the heap (yikes) at all times.
- I'd be surprised if your saving/loading functions work at all, given that they seem to be using pointers for the file/folder locations that will almost certainly be invalid when the program is exited and then run again, restoring these pointers from the save.
- There is a lot of overlap between hydra_DetectAllFiles, hydra_RescanFileSystem, and hydra_CheckFileSystem which could cause problems later on if you modify any of these--they probably could all be combined into one function somehow.
- There is no chance that filesystem scanning can be done quickly if there are a lot of programs on the calculator, given that you're doing a search in linear time to see if every program on the calculator is present in the filesystem (probably runs in O(n^2) time at best).
- The way that this is implemented seems to mean that every file can only be in one place at a given time. If this is meant to support copy and paste later on (or just generally having copies of a file in multiple directories simultaneously), I'm not sure how that would work.
- I'm not sure why you're putting everything on the heap, but that doesn't seem like a good idea.
- Probably more minor things here, I'm bored now.

Overall, the implementation doesn't make a lot of sense to me, as it seems very inefficient and potentially buggy. Given that it seems at least somewhat similar to how I approached the filesystem in VYSION 1, and knowing how much trouble that caused me, as well as that this is even more inefficient in terms of memory, I think you probably have a lot of work to do in terms of space and performance optimization to make this a viable product. I might suggest a simpler implementation that only contains the names and types of the files, perhaps stored in a child tree.

You said that it was the "beast" of filesystems on the CE--any special features that you've implemented to warrant that? The users idea is pretty neat, but I haven't had a deep enough look at it yet to get an idea of any others.

Anyway, keep up the good work and I hope some of that feedback was useful! I don't mean to be overly negative (and apologies if it comes across that way), I just don't want you to have to spend lots of time debugging this if it turns out to be problematic later on.
epsilon5 wrote:

Overall, the implementation doesn't make a lot of sense to me, as it seems very inefficient and potentially buggy. Given that it seems at least somewhat similar to how I approached the filesystem in VYSION 1, and knowing how much trouble that caused me, as well as that this is even more inefficient in terms of memory, I think you probably have a lot of work to do in terms of space and performance optimization to make this a viable product. I might suggest a simpler implementation that only contains the names and types of the files, perhaps stored in a child tree.


Hey Epsilon, I've taken into consideration the issues you've reported.

To start, this isn't even the first version of the library; it is prone to being very "inefficient and potentially buggy". I do agree that memory management isn't as efficient because the file structures are very large at the moment but are prone to change. As for saving, it works perfectly fine even though some pointers might be NULL or not initiated; that was meant to be sorted out in the load section.

Secondly, you mentioned that the search time complexity is limited to the factor of O(n^2). I don't think there is a better way to search for files but if you do know please share.

Lastly, you mentioned that most of the data were stored on the heap, which is very true. I don't know if you've noticed the save. c hasn't been touched much, but I'll be moving to directly get data from the app var, then saving and freeing right after they've been used (don't know if that could help), or I could leave it up to the users on how they want to implement memory management.

epsilon5 wrote:
You said that it was the "beast" of filesystems on the CE--any special features that you've implemented to warrant that? The users idea is pretty neat, but I haven't had a deep enough look at it yet to get an idea of any others.


The simple answer is... that Hydra is the only filesystem library for the CE, so it is considered the "beast".

The complex answer is ... to answer that question, you have to understand what makes a filesystem good and stand out, In this case, hydra has many features like users and standard file organization. On top of that, Hydra is scalable and can be applied to many applications and projects. Whereas other programs limit their file systems to themselves, limiting the growth of new and better filesystems in the "program/development pipeline". With Hydra, there is a wide range of features that can be added to later down the line, and with the help of cemetech and users like yourself, it will overall become a "beast".

epsilon5 wrote:
Anyway, keep up the good work and I hope some of that feedback was useful! I don't mean to be overly negative (and apologies if it comes across that way), I just don't want you to have to spend lots of time debugging this if it turns out to be problematic later on.


Thanks for the for the feedback it's all been very useful! I feel like you come off concerning which is perfectly fine.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement