SpiderTop Junk ======================= Phase 0: Name - Rejected names: - Hydrox (Sounds like chemicals and knockoff oreos) - BusyBee (Would have been perfect, but in use on AUR by obscure messaging library) - Possible Names: - MagicWin (Eegh. Too cheesy and NEXTStep-esque.) X SpiderTop (I mean, it's unique. Manages a lot of stuff with its arms. Cool logo. Also I totally have Spider Dance stuck in my head, but...) - Mosaic (It's a jumble of parts like the UNIX philosophy. But also historical web browser.) Phase I: Files - Store file type in extended attributes - user.mime_type - Turns out there's no cross-platform libraries for this. Shoot. - Let's *start* with Linux, at the very least. - Windows also has NTFS alternate streams, but that's only NTFS. - Store last modified date for MIME in ext. attrib. - Let's call this user.mime_date Phase II: File Associations - Have multiple "actions" per MIME type, associated with programs Every one of these actions requires an input and an output. EX: Rotate is image/png -> image/png EX: Count Words is text/plain -> text/plain (?) Okay. This would have to come with a caveat. Some actions are designed to write back. (rotate, scale, edit) Some actions are designed to create a new file (analyze, download) Some actions don't create files at all! (print, view) Guess what else has to deal with this? Functional programming. Let's model our commands after OCaml of F# or something. EX: Rotate: image/png -> image/png EX: Analyze: text/plain -> NEW application/spreadsheet EX: Print: application/postscript -> NULL I'd imagine the format for storing these things would look something like this: { MIME: "image/png", Name: "Portable Network Graphics", Category: "Image", Attributes: [ "lossless", ... ], Commands: [ ] } (Yeah, we're re-inventing file(1). file(1) sucks.) - Make command that opens file using command's program Phase III: File Tree - Define MIMEs extended from other MIMEs (octet-stream -> zip -> jar) This is already a freedesktop spec! No it isn't! That's for specialized directories, probably! (That being said... that's not a bad idea. Music directories. Git directories...) And besides, it's not like anyone uses that bit of the standard! Actually, it's already there! - Edit open program to search further down chain for more actions Say we have a LibreOffice document. We should have the usual stuff possible (Edit, Print, etc.) However, because an odt is a zip, we should be able to unzip it too. And because a zip is a bin, we should be able to hexedit it. - Edit open program to support "open as (lower MIME)" This filters, ex: edit, print to actions only possible in a lower mime. For example, print text/x-c might print it in full color with line numbers. print text/x-c as text/plain would print it in monochrome, then. - Shove all the above into some sort of file. (A /usr/deepmagic, if you will) - /usr/filetree is probably a good, not silly name. - Make some sort of super-file(1) that go along tree children and tests different subtypes. The idea here is that we can get rid of a LOT of redundant checking. For instance, if we know he have a text file, don't check any of the binary types. Also, semi-related, file is both really great and really awful. The problem is that all it can do is simple string matching. This leads to a lot of false positives (my text file is a postscript?) Proposal: Instead of specifying what the file contains, instead specify a program to run that very quickly (within milliseconds, preferably) checks whether the given file is a valid file of that type. For simple types, it can be a simple shell script that compares bytes to bytes. For complicated things (C files, etc) you'll probably have to compile it with no output. Slow? Sure. Effective. Yeah. (Or you could use a BNF validator.) The way this works is that we start at the bottom of the tree, [file]. We test whether or not this is a application/octet-stream or an inode/*. When we get a hit, we go down that branch. If we went down to a leaf, we stop and return the leaf's contents. Otherwise, we scan the branch's children again until we get a hit. We continue testing and going down until we hit a leaf. Also, it'd make sense to do this all in parallel, if possible. Also also, sort the commands by speed. (ex: a regex is faster than a compile) Phase IV: File Conversion - Create list of MIME to MIME conversion programs EX: ffmpeg for avi -> mov, imagemagick for png -> jpg, etc. - Include (un)preserved attributes (text, formatting, etc) in list EX: [png -> jpg] | preserved: image (lossy) | lost: metadata - Edit open program to search lossless conversions This is going to get complicated, fast. Take the LibreOffice example again. We've established that we can edit, print, and unzip it. (Hex-editing would require an open-as application/octet-stream) However, because it can be converted to text, we can also, say, format it with troff, sort it's lines, count words, etc. And, because we can convert a text file to a png, we should also be able to filter it, count colors, crop it, rotate it, etc. And, because we can use OCR to convert the png back to text... It gets messy real fast. I mean, you could rotate your LibreOffice document, but why would you possibly do that? So the question is this: where do we draw the line? -Proposed solution no. 1: Supertypes- You know how MIME tyes have [supertype]/[subtype]? Let's do something like that for implicit conversion. Obviously, MIME types are rather broken (everything's either text/* or application/*) so we'd need to roll our own. We'd need some sort of sensical classification of filetypes anyways if the user has any hope of creating a new file ever. (I want a photograph, not an Amstrad CPC tape archive!) -Proposed Solutuion No. 2: Read-only Implicit Conversion- There are two types of conversion: explicit (convert this MIME to that MIME) and implicit (do this command on this MIME by treating it as that MIME) Now, some of these actions would involve writing a file back (ex: rotate, crop, etc) Because doing that would destroy the original file, we should ban those actions. (No, that's an awful idea. Only ban if it writes back _in a different format_. Otherwise we'd be unable to edit anything. And that would suck.) If an action does NOT write back, uh, I guess that's what proposal 1 is for. Phase V: File Tagging - Okay. Now we know what format it's stored in. But... what's in it? There's quite a difference between, say, a finance spreadsheet and a scientific one Or between a master's thesis and a novel. - User should be able to tag manually. I'd imagine this would simply be a case of setting user.spidertop.tags to something. (EX: novel;long;sci-fi) - We coooould also try to do this automatically for some stuff (EX: Id3 tags, EXIF metadata, etc?) - And take educated suggestions on more abstract stuff - EX: PhD thesises probably contain "PhD Thesis" somewhere on the first page. - EX: Images of text will probably survive a trip through OCR and be coherent - EX: Pictures of a dog will resemble other pictures? (Now we're stretching...) (PUBLIC RELEASE would be really cool right about now) Phase VI: Explorer - Make edit of Ranger (or w/e) that opens files with open program - Allow file conversion, tagging from interface - Include way to open "tools" (apps that don't work with files) - Probably a Mac OSX-style "Applications" folder will do Phase VII: PoC Desktop - Edit that simple Wayland window manager (swc, or the other one?) - This might kind of suck, but you know, it's something - Each "window" knows it's location in the file system at all times - Each window is a seperate process (or group of) - Each process should (if not a tool) support a DBus interface - org/spidertop:org.spidertop.file.path - org/spidertop:org.spidertop.file.action - Add compability file somewhere for programs that already export this in different namespaces - EX: Calligra Suite - file.path -> org.kde.calligra.document.url (on Sheets, anyways) - Not Krita, though. Which kinda sucks. - Use IE-Shell like interface for navigation - Specifically, for non-tool windows the WM should add a navigation bar and file mode switcher between the window and the titlebar. - Clicking on these commands will send DBus commands to the window in question. - If process determines such an action would require using another program, it should let the WM know. The WM will then send a WM_CLOSE (whatever the POSIX version of that is) signal to the process and open the appropriate process in place. This should all be transparent to the user. - I will sooo become Nathan Lineback's arch nemesis. :^) - Allow switching between allowed commands for file - When the mode is switched via the navbar, - Allow switching to explorer for directory-like things - EX: Blender could switch to explorer to list objects in scene - Add mouse support (of course) - Use Windows 1.x style window management (tiling, but by mouse!) - I don't really want to make floating windows an option. It's needlessly complicated - Add API to indicate document switch to WM, include in Explorer Phase VIII: Workspaces - "Taskbar" at right side of screen - Tree-style, Workspace -> Documents - Should act like "folder bar" from old Chicago builds. Except be a task bar too. The tiling makes this a lot easier. - Allow hiding documents from view to sidebar ala Windows 1.x - Give each document a grippy thing that can be dragged around to move doc. - Keep appearence consistent regardless of position - Let each monitor show a different workspace - Have multiple "views" per workstation to quickly switch active documents (PUBLIC RELEASE) Phase IX: Multi-Document Editing - Allow multiple documents to occupy one window - EX: layers in Krita as "documents". Go to "browse" mode to select a couple to edit at the same time. - EX: Any diff program. Sorta... required, eh? Phase X: Preference Editor - Automatically generate forms from a list of every config file like Visual Studio Code. - Generate from man pages? Can we do that? - Figure out how to search/categorize these things - Get files to open in apps depending on path/location - Wait, why? I mean, we could, but why? (PUBLIC RELEASE) Phase XI: Multi-User Collaboration - Somehow figure out a way so that a document can be edited by multiple users/processes and updated live on every open view. - Then figure out how to do that securely over the internet. - Then figure out how to handle connections drops and merging. - I'm thinking memory mapped files and some sort of changed signal, but that's just me not knowing anything Phase XII: Multi-View Documents - Take the multi-collab, and make the "second user" another window on the desktop. - This may be laggy. Shouldn't, because it's on the same system, but may. Figure that out. - How will this work with storage bar? Maybe just grey out windows in use? - What is difference interface wise between "switch to open window", "move window" and "create new view"? - (Possibly) indicate "linked" windows in obvious manner (color coding?) Phase XIII: Enhanced Multi-Monitor Support - Map each monitor to a workspace - Here's the "enhanced part": we totally can map the same workspace to multiple monitors. - Treat every monitor as a new client: rerender windows in new processes as if from a remote machine (using multi-collab stuff) - Reason for this is so if the other monitor is at a different resoultion/DPI, it'll look native for that screen. - Also what the heck are we going to do about games and stuff that don't support multi-view? - Keep them same resolution and scale it/everything else accordingly. Throw in spacers if needed, too.