---

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!

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.



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

Even better!

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?

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!

Sounds Pretty Fun! Hopefully the iron toolchain will be using Oxygen when it comes out!

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

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.

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.

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.



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".



Thanks for the for the feedback it's all been very useful! I feel like you come off concerning which is perfectly fine.

Hello Cemetech!



Oxygen Alpha Release!

Oxygen has entered Alpha testing! After 3 years, I've been working on developing documentation for some time now, which should help out a lot! I have started to rewrite the code for the widget system. As we speak, this should be done in the beta version. There aren't many examples for the widget functions yet, but check out the `oxy_gui.h` and `oxy_gfx.h` files.

Github: https://github.com/Overload02/Oxygen

I also plan to rewrite Hydra to make it more developer-friendly! Keep a look out for the update

Full disclosure to anyone who tries to use this library in the future and finds it unavailable that it's likely because of a DMCA takedown request that I submitted against it through Github--please see this issue. I am unable to continue trying to work this out through Github because the issue was closed without an agreement being reached and I have been blocked from opening any further issues. The Oxygen source clearly takes significant portions of its codebase from my own OPTIX 3 and VYSION without complying with the GPL3 licenses that either of these projects have.

Tried to resolve this in a civil way and I'd still like to, but my efforts as of yet have been unsuccessful. Really didn't want to have it come to this but my hand has been forced.

Hey Epsilon5, You reached out to me about this issue, and we came to the conclusion that you should make a pull request and give yourself any credit you deem necessary. Previous versions of the Oxygen Oxygen Demo's used Optix as a benchmark and kept persisting in making a claim by that, I guess you mean this. After we talked, we came to a conclusion, which is why the issue was closed. Again, please make a pull request where you deem credit to be necessary. You have yet to do so.

You've been making the same claim about all the libraries I've released from Hydra, Notify, and now Oxygen. You reported an issue within hours of releasing it.

I have reason to believe you are participating in unfair competition when it comes to my libraries. I have no choice but to leave this up to the Cemetech administrators.

"We" didn't come to any conclusion, you refused to listen to me.


Maybe there's a reason for that...

Usually if a person has violated a license, it's up to them to fix it, not the person who owned the original code. This isn't an issue to be left up to the Cemetech administrators, and it's up to you to read the license and make sure you comply with it. Regardless of competition, when you are complying with the license set by the owner, they should not have a right to be upset with you, and when you are not, it's within their power to handle that the way they feel is necessary.

If you're unsure about what steps need to be made, GitHub shows you what requirements a project's license has if you click on it. I'd make sure to follow those:


It's a shame that there should be a conflict like this, and I hope that it is able to be resolved respectfully between both parties.

I did bring up that summary on Github in our conversation earlier, but I'm sure that there are people here that can explain it better than I can if there's any further misunderstanding.

The relevant section from the GPL3 (as I understand it), as present on gnu.org:
Code:


As I've said throughout this disagreement, I continue to want to reach a friendly conclusion here. Please let me know if you have any further questions about the license agreement or why I think that a violation is present here.