No announcement yet.

My "everything" app

  • Filter
  • Time
  • Show
Clear All
new posts

  • My "everything" app

    As you can see, work on my "everything" app is coming along great. This is not a joke. My "everything" app allows you to open/view/edit/save/delete a shit load of filetypes. A TON of work has been put into the GUI and navigation/use is incredibly intuitive. It is so intuitive that the only thing that is ever visible is whatever it is that you need to use. That's why my image is black. Here is where you need to use some imagination. Imagine you are working on (ex) an image. The window bar, file explorer, menus, etc are all there (like they are really there right now) but none of that shit is in your way. If you need one of those things simply move your mouse to the point on the screen where you would expect it to come from and *magic* it appears for you to use. For instance, the window bar with close/restore/minimize buttons and the drag bar is right there in my image. You just have to move the mouse close to the top of the screen to see it and then simply move away from it by a small buffer of pixels to make it go away again.

    The next time I post here the image will not be black. It's black because I have not created any interfaces for the various applications that will allow you to do the things I claimed in the above paragraph. That's the whole imagination part stated above. Imagine the tools that are specific to what you are actually doing being visible (in the black), while the generic shit that every app uses is hanging out in invisible land until you "request" it by moving your mouse very close to the appropriate edge of the window. EVERYTHING scales and resizes with german-like precision. There is no weird glitchy jump-around, overlappy, fighting, jerky bullshit. It's all very smooth and very aware of the visible state of sibling components. Most of the more complex components I have made so far are also aware of what you intend to do and work very smoothly to provide you with that action before you have a chance to do it yourself. Here is an example.

    If you are using my file explorer (document tree) and you go to open a folder that is close to the bottom of the viewable area AND it's content will overflow the viewable area all of it's contents will scroll into view for you. If the contents are bigger than the entire viewable area it's parent folder is scrolled to the top of the viewable area. I have components doing other such things like this. I know some people will claim "intuitive stuff sucks, it is always doing something I don't want it to do.". Mine won't. SImply because I also know that intuitive stuff sucks and I didn't try to make my stuff so intuitive that it would generally be wrong. Like in my example above. If you expand a folder and can't see its contents it's about 100% accurate to assume you are going to scroll those contents into view so, my app does it for you. That's actually kind of a rule with this ~ if I have an idea for an intuitive feature it only gets included if it is pretty much 100% the only logical next step. Whether or not you click things you did not mean to click is not my problem or fault.

  • #2
    Originally posted by MadGypsy View Post
    That's why my image is black
    Sounds like you've finally created something that is a good approximation of your level of experience.

    Originally posted by MadGypsy View Post
    Here is where you need to use some imagination.
    My imagination of your version 2 is also a black image. - Being exactly one-half good and one-half evil has advantages. When a portal opens to the antimatter universe, my opposite is just me with a goatee.

    So while you guys all have to fight your anti-matter counterparts, me and my evil twin will be drinking a beer laughing at you guys ...


    • #3
      I'll give you another example of how much thought was put into my interface.

      Let's say you "requested" the file explorer and then let's say for whatever reason you maximized the window. Normally, that would mean upon maximize completion your mouse would be far enough away from the file explorer for it to auto-close. However, I have to assume that if you had it open then simply maximizing the window means you still want it open so, what actually happens is... when you click maximize the file explorer is pinned and event is set on the file explorer that waits for a mouse over (cause it is assumed if you had it open you will be touching it again). When you mouse over it, it becomes unpinned and reverts back to it's natural behavior (collapsing) when you have completely left it by an amount greater than the pixel buffer I have set. However, you can also manually pin it and it will stay pinned until you unpin it.

      Basically the point here is to add some intelligence. It would be easy for me to leave a component stupid and it will most of the time do something that wasn't necessary or desired based on some other simple function (like maximizing/restoring the window). Maybe you request the file browser and realize you want some more real estate in the viewable area. If I left it stupid you would have to request it again after maximize.

      There are numerous examples similar to this one implemented throughout the app. I am giving 110% on things being there when you want them and going away when you dont, and all in a way that is really smooth.


      • #4
        Hello everyone
        I wanna know about my everything app . what is this , how this works ?
        Kind regards
        Technical assistant at dissertation proposal writing in UK.


        • #5
          My everything app (actually named Ark) is simply a way to view/edit "everything". It is built on top of an sqllite database and utilizes numerous professional command line tools for various tasks. My command line interface is exposed, allowing any command line tool to be easily injected into the app. It has a learning feature which attempts to construct a working GUI for command line executables on the fly.

          Ark is beyond a smart GUI for command line tools, though. Command line tools are only used in cases where I haven't written my own scripts and it would be too ridiculous to do so. FFMPEG and SQLLite come to mind as good examples.

          I'm currently reconsidering the core object system to be more robust and versatile.

          Ark was basically born out of 6 years of learning numerous things and auditing their possibilities with POC projects. I'm at a point where I have all the info and connections to put it all into one mega app... just like I decided I would almost 10 years ago.

          @ Baker - please go fuck yourself. Thanks.
          Last edited by MadGypsy; 09-01-2017, 10:02 AM.


          • #6
            MadGypsy , i thnk that was a bot..


            • #7
              "John Smith". LOL. Totally a bot.


              • #8

                You guys may be right. It however posted a question relevant to the topic, so I answered it.


                • #9
                  While we're at the topic, I think that the concept of this program is interesting. Tools and windows on demand.


                  • #10
                    I wish the dickheads that write these bots would make them sound less retarded.

                    Anyways, any progress on Ark?
                    'Replacement Player Models' Project


                    • #11
                      Oh, right, one technical question:
                      Which file formats are supported and are being planned? Imagine working on a Quake map with that.


                      • #12
                        Admer456 - Which file formats are supported and are being planned?

                        all image formats, all video formats, all audio formats, 7z, lzma, cab, zip, gzip, bzip2, Z, tar, rar, obj, mdl, md2, md3, wad, bsp (29,2,q3), txt, odt, xml, json, pdf, swf, db, pls, m3u

                        I know I am forgetting some. The idea is sort of to be able to open and work with anything. This is possible in a lot of ways due to command line tools like FFMPEG, SQLLite, 7ZA, UNRAR, ImageMagick but not entirely due to those things. I have written plenty of parsers and functionalities on my own. I can also open files with whatever you registered as the default program. And actually you can open ANYTHING you have a registered program for right now. If you opened my doument tree and hovered an item you can just click the "open native" icon and it will always open whatever it is as long as you have a program registered for it.

                        Dutch Anyways, any progress on Ark?

                        Lots of it but, some of it has gone backwards. My idea is solid but my foundation for the idea was lackluster and a bit weak. I had to rewrite my object compiler and I almost done. There is just one very tricky situation I want to handle and I should be able to move forward with a much more solid foundation than I had.

                        For the record, numerous things are happening because of command line tools but it is not obvious at all. No cmd shells popping up all over the place or long laggy waits for data to complete. If I didn't tell you that much of this is provided by command line tools you probably would never know or guess. Also, you don't personally have to know anything about how to use any of the command line tools. Its all black-boxed for you nice and tight so you can work with simple interfaces.

                        For all command line tools except ImageMagick, SQLite and FFMPEG creating interfaces was easy as pie. For the 3 i just mentioned it is very complicated. It CAN be simple if I was just going to provide a pic, audio or video but, I intend to actually GUI the entire command line tool. I don't want to do it in a way that is just command line line labels with input boxes though. A bunch of this is going to require a lot of thought on how to make it more like actions you are performing rather than just running a command line.

                        Currently the main app I have created is a text editor. You can add a bunch of file types to my list above due to this because I also have numerous code compilers plugged into my text editor. Actually at this point it can barely be called a text editor because as it sits right now you can program and compile in it.

                        My app also talks to you but, you can turn it off. I currently have it programmed to help you get familiar with the environment but it also fucks with you a little. For instance if you maintain what my system considers "work" for 1 hour (ie not idle) you will hear "Oh my! you are getting so much done!" in a british female voice. It says other things based on other stuff. It may even offer you tea and crumpetts if it feels like you deserve some. It utilizes TTS for these operations.

                        Random fact: The way I utilize SQLite is 35% faster than using the filesystem. Yes this means I can load and search certain things 35% faster than the way your OS does it. You do and will have options that allow you to decide whether you want to store things on the filesystem or in a database. Its a simple decision. If you only intend to use my app to work on something then store it in the database til you are finished (or forever). If you intend to use other programs store it in the filesystem. There is an extra bonus to this. You can share entire gzipped databases with other users instead of compiling archives with numerous "loose" files. They can open the database and it will be really no different than opening a zip except it's faster, encrypted and probably other stuff that I can't think of right now.
                        Last edited by MadGypsy; 09-05-2017, 12:43 PM.


                        • #13
                          Hmm, nice. I'm looking forward to it. =)


                          • #14
                            It will be some time. I have a date set for a beta release and I think it's a realistic date but that date is next year. I have double the work to do. I know from experience that I can lay down impressive amounts of code in AS3 in a very short amount of time and I can even go back and severely change that code very quickly. So, I program everything in AS3 and port to haxe. Considering the scope of this project I intend to program the entire thing in AS3 before I port even one line to haxe. I intend to release this as a standalone air application at first and eventually completely replace it with native executables for every operating system.

                            It will arguably take longer to port than it did to invent because I already know of 4 or 5 major portions that have to be done a completely different way in Haxe. In some cases the ported script will be much simpler but in others it will require me to spend some time creating mini APIs to work with.

                            All of the stuff I am doing is stuff I have done before and either did not complete due to it becoming incredibly boring or I completed it in a more bare bones fashion. Much of my work is actually auditing a bunch of code that I already wrote and considering how it can be made better. In a lot of ways, I am simply putting everything I have ever done into one thing and polishing the shit out of it.

                            I also want it to be fun. I play a lot of android games. I may download 5 or 6 a day and check them out. I have noticed a lot of things about android games that could be reused in more of an application environment that would make the experience more engaging. I want to bring some of these concepts to my app. I want my app to be more than something that can open, edit and save everything. I want it to have personality, be really really smart and to some degree reward you for getting a bunch of things done.
                            Last edited by MadGypsy; 09-05-2017, 02:27 PM.


                            • #15
                              Sounds pretty juicy. It's always nice to re-use old projects/experiences into a larger vision. Kind of gives all that time spent some purpose outside of it being purely educational.
                              'Replacement Player Models' Project