Nice, I can see the appeal having familiar UI on Mac.
Even though I am not your target audience (linux i3 user myself), I would be interested in knowing how much "hacking" the macOS system is required to do this. Is it hard to get a list of running apps for your Task Bar? Is it hard to list the apps for the menu? How about keeping it all "on top" while other windows e.g. get maximized/minimized/full-screen, etc?
I could talk for days on all the peculiar bugs resolved. Once the alpha stabilizes I have drafts to publish on several topics.
You actually nailed the major pain points. Particularly window focus and state management. I've spent months solving this problem alone.
-
1. Applications data list: Getting the list is easy! Finding out which apps in that list are "real" apps isn't. Getting icons isn't. Reliably getting information on app state isn't. Finding out why something doesn't work right is as painful as can be. Doing all this in a performant way is a nightmare.
2. Applications menu renderer: Rendering the list for the menu is easy enough: the macOS app sends this data via socket. The frontend is just web sockets and web components under the hood (https://lit.dev). The difficult part was converting app icons to PNG, which is awfully slow. So a cache-warmup stage on startup finds all apps, converts their icons to png, and caches them to the app directory for read.
3. Window state: again, by far the worst and it isn't even close. Bugs galore. The biggest issue was overriding macOS core behavior on what a window is, when it's focused, and how to communicate its events reliably to the app. Although I did include a couple private APIs to achieve this, you can get pretty far by overriding Window class types in ways that I don't think were intended (lol). There is trickery required for the app to behave correctly: and the app is deceptively simple at a glance.
-
One bug, and realization, that still makes me chuckle today.. anything can be a window in macOS.
I'm writing this on Firefox now, and if I hover over a tab and a tooltip pops up - that's a window. So a fair amount of time has gone into determining _what_ these apps are doing and why. Then coming up with rules on determining when a window is likely to be a "real" window or not.
The Accessibility Inspector app comes standard on macOS and was helpful for debugging this, but it was a pain regardless.
Very nicely done. Supporting good/honest apps is important, I gave you a five-star review and I hope others do the same.
I would've enjoyed an "About" tab, or something similar. I like your basic approach to the app, but if you did want to share more with your users, I think that'd be a good thing.
If anyone feels this way and wants to try an alpha I have 1,000+ hours in.. I've implemented a Windows 10-like UI for MacOS. Similar to uBar (ubarapp.com).
The key distinction is it's built to be extended with third-party plugins (think Obsidian). I stopped using uBar because it had features I needed, but it's not actively adding features anymore last I checked. And of course, this will be fully open source.
It's in active alpha development but has all the core features you'd expect: taskbar works great, but only a basic system tray and start menu. And it'd be very much an alpha that needs feedback :-)
Explaining a difficult concept in terms anyone can understand. Great diagrams and examples. And top marks on readability UX for spacing and typography.
OP, what inspired you to create your current theme? Have you ever considered creating an engineer-focused publishing platform?
I skimmed the Readme, the What is Superstreamer? page, and features list. I still don't understand when I would use this, or when I would recommend it to someone. I'm an engineer somewhat familiar with the space.
You may consider starting with a simple unique value proposition and reworking presentation from there.
Take the first sentence of the Readme as example: "Superstreamer is a self hostable platform that aims to simplify the complexities of video delivery" - and answer questions:
1. Who is benefiting?
2. How is this better?
3. What complexity is being solved?
4. What's the tangible outcome, or CTA?
5. What well-known alternative is this related to?
ChatGPT took a stab at it. Not amazing, but something to start with:
"Superstreamer is a self-hosted platform that simplifies video delivery, giving you full control over your content without third-party dependencies. Reduce costs, customize your setup, and deliver high-quality streams with ease. Drop <competitor> today and get started in minutes."
Also simple things like defining an acronym before it's used goes a long way.
Overall presentation, UX, design, code quality, and detail is a homerun IMO. Nice work, I can tell you put a heap of passion into it.
Hey, thank you! You're not the first to mention the docs. I'll have a full rewrite of the docs planned shortly where I'll address your (& others) valid points.
Full docs rewrite is nice, but for now maybe a two-minute update to the readme to clarify these points for people coming across the project would be beneficial.
I like the looks of this as a local or internet media-streaming server.
I assume you handle a few different media formats already, and can deliver or multicast something like mp4's which theoretically anybody with Windows, Apple, or Linux will be able to play on their various open-source or proprietary media players. Using no additional software on their part that they weren't already using to play their mp4's with.
Which is one of the killer features of VLC besides being an extremely versatile media player itself. VLC can be a little complex to get going however, even though there is lots of documentation it does not concentrate on streaming and there ends up being more solutions to show-stoppers on message boards than in "current" publications. Both are somewhat weighted toward deprecated versions, but OTOH it's good to have so much information building up over the decades.
What I would do is totally benchmark against VLC, focusing only on streaming, ease-of-setup use & maintenance, and especially documentation for anything that can not be made highly discoverable [0]. Make it bone simple to point & click a few times and have your chosen media playlist be instantly streaming & available from a known IP address on your local server's network, or from there over the internet, including privately through Wireguard would be good. So all you have to do is give the clients the IP address (and port if required) of the stream source, and any private credentials or keys which can easily be communicated over the phone verbally if wanted.
The clients should then be able to tune in at their leisure from any device, privately or publicly, on isolated LAN or wide open internet, with almost any firewalls in between.
I really like the idea of sensible defaults.
OTOH, it can take some doing to get VLC right, over more than one weekend :\
But once you do, here is how it works in Windows, even though VLC was primarily made for Linux, the Windows version sets a good example of an "easy" approach for beginners:
1. Take a blank SSD or equivalent, install Windows (Server or not) and join the desired network, at least a local LAN or something.
1a. installing Windows is not exactly one-click but it is basically a unit process that is going to be done anyway. You don't need to be an administrator when you are streaming, or have any further dependencies.
2. Install VLC. Just double-click on the single standalone EXE file, and it's installed. No dependencies other than one of the various basic Windows versions that millions of other people already have. Especially no need for the PC to ever connect to the internet unless you really want to.
2a. then comes the hairy part, configuring the hundreds of VLC options so the limited number of formats which support streaming can be focused on. Eventually you get configuration down to where a small script will launch a stream, in the desired format, out the desired port of your server. So eventually you can launch a stream with a single click after powering on, and if you could skip all the confusing configuration, ideally step 2 here would be only-a-couple-clicks-to-streaming-after-installation. After a one-click installation.
3. Obtain the current numerical IP address of this media server's stream, whether fixed IP or DHCP, along with any DNS equivalent whether dynamic or not. Communicate this target address, port, and any credentials to the client users, privately if desired, even over the phone verbally. After addressing the optional requirement for users when they might need a privacy approach like Wireguard to be present at the client end. Any device possessing a player having the proper codec for that stream should then have no problem playing it. In pretty much real time.
So basically, plop down the laptop that you're going to use as a streaming media server, double-click on the desired playlist (or webcam, etc) , and some kind of worthwhile popup shows the full (but simple) information needed for the clients to connect at that particular time. While the playlist is playing, or maybe have a stream menu available for user-selection Netflix-style. Publicly or privately with virtually the same workflow.
"All you need to do" is "streamline" the whole thing until it's smoother and quicker to get going compared to VLC.
I would estimate you could get it 100x easier, so if you only made it halfway look how impressive it would be :)
I think you're on the right track if you can get it to a matter of minutes, the saner the defaults the more you can just install a single standalone offline binary, then click on a playlist, whether interactive with the ultimate-media-client or not, and your streams will be available in a format that most people can play, and traverse firewalls for those who can access your current server address properly when you intend.
In only minutes after install of a single file onto any of a majority of common everyday devices, when neither the server operator nor their clients have very much tech ability. All the server needs is a valid playlist of some kind, which can be expected to be relatively non-simple to properly craft, but well-tolerated by users of corresponding super-smooth-workflow, optimized single-purpose software.
With all the other optional settings beyond default that you wish to provide, acting as icing on the top of a default cake like that.
Maybe even on Windows someday, but right now I would look forward to testing the Superstreamer on just about any major distro of Linux. When it was simple enough to be installed and launched by following a few documented proven steps that anyone booted to a laptop having your preferred version of Linux could do. In order to quickly install to the laptop and then instantly stream a playlist already residing on that laptop, or stream from its webcam, to other devices in other places the regular way. Over the internet or not.
The simplest thing in the world is local streaming from bare metal, so this should be the easiest to document by "default" or I wouldn't be so sure it wouldn't end up with more-variables-than-necessary to get very basic things going, and VLC already has that.
Right now for me there would be prohibitively more obstacles than VLC, but I admire it highly and understand it's a work in progress :)
[0] Which means accumulation of as many features as you can before considering a release or update, therefore document review and revision can be kept to a minimum too. With VLC the features definitely got ahead of the docs and they may never catch up.
This is really neat. Well done on the UX and functionality.
I saw others already mentioned uniqueness of city names. In the US there is no guarantee a state, zip code, or even county won't have a duplicate city name. To solve this one must store the lat/lng coordinates instead. Then offer users a search list of matched cities, so they can select the right geographic location.
> This is really neat. Well done on the UX and functionality.
Thank you very much!
> To solve this one must store the lat/lng coordinates instead. Then offer users a search list of matched cities, so they can select the right geographic location.
I ended up doing this! Migrated all user and city data over to this new paradigm.
I have been working on porting concepts of the Windows 10/11 taskbar, tray, and window management, to macos. With emphasis on simplicity, speed, and function inspired by Linux Mint MATE.
It has been a wild ride. Often frustrating but rewarding. Some days I may spend 10 hours solving an API for which app is frontmost at a given second. Sure, there's a system API for that, but it doesn't even remotely cover edge cases that exist. And many times with no answers out there on how to do something, it feels like I'm the first, so finally solving it is a great endorphin rush.
Part of the complexity is I wanted the app to be completely pluggable, kind of like Obsidian. The app communicates events to a local socket server in full duplex, which enables cross-plugin communication (but also cross-app!). Plugins access the app's JavaScript system bridge API for pubsub and system calls through a Webkit interface. Edits are hot reloaded and instant, no compile time necessary. The first time I could change my "Start" menu in real time through JavaScript/CSS was quite a feeling.
Sadly, I couldn't leverage existing tools like Tauri or Electron. They don't have adequate system bridge APIs available, and would be more work to leverage instead of less. They are too general, whereas this project only builds to macos. Therefore it can be much more complicated (and useful) by design.
I originally set out to be more productive in macos. But I've also spent time making prototypes for fun. A desktop widget system, real-time system color theme set from Spotify album art, live video desktop backgrounds from Twitch/YT, a Destiny 2 macos system theme, etc.
I plan to open source it and build a community around it one day.
To some degree OS productivity is subjective based on what you grew up with. Your neural pathways form around a certain way of work management and it becomes hard to change that after ten years.
I'm naturally biased then to early Windows and MATE-esque environments. And, it's worth noting that I despise Win11 overall, so a better comparison is indeed Linux Mint MATE[1]. Part of the project inspiration is to never use Windows 11 again, actually!
Before I started the project I wrote down what I consider productivity boosters for me:
1. Fast context switching between open apps and windows, natively. All open apps are in front of me by way of the taskbar, always, and never hidden. I never have to think about where to find my immediate work. I can group apps, pin them, and create custom behavior for them.
2. System tray apps for things that you interact with often, but aren't necessarily immediately working on. Macos has something similar but it isn't really pluggable or widely used yet, and nowhere near as customizable. With Win10 I can add, remove, or hide system tray apps based on how I use my workstation best.
3. Optimized Start Menu. I press a button, I get access to things I've favorited, recent apps/files, and categories of apps I use often. It is highly customizable in Win10, while I struggle to have something as efficient in macos (even though macos global search is wonderful!).
I feel like the old UX rule of "don't make me think" applies heavily here. The macos app dock is a great example of this. You're forced to think about what you want to do with 10-20+ options glaring at you. Disabling the dock is the first thing I do on a new Mac ;)
Lastly, Win10 lets me customize my system to a high degree as my needs change. I just don't get that with macos, nor have I found apps that hit the mark for me.
I'm curious about your own experiences if you care to share :-)
The exception I have found to poor AI chatbot experiences, oddly, was Carvana.com.
I needed to resolve a highly complicated title problem I was battling two separate state DMVs over (plus a defunct lender). It was starting to seem I needed to retain a lawyer.
So I was just compiling information at the time. I asked an esoteric question about one of the private LLC names Carvana have as their lending arm in a specific state. You would only know this name reviewing a stack of paperwork, it is not public.
The chatbot responded with detailed information on what I needed to do to resolve the problem. Plus information about the LLC. And then emailed me supporting documentation automatically.
Funny enough, the handful I clicked through being prominently displayed on the Readme all had their Calendlys booked solid. One even made their Calendly private.
The killer feature for me is how extensible the software is made to be.
It truly lets you operate how you know best, making very few assumptions on how you use it.
Case in point: one of my favorite productivity plugins is a full-fledged Kanban board. It has deep integration into Obsidian features:
You might like my own note-taking app, Plume[1] that's built with Qt C++ and QML. You can integrate a Kanban board (with underlying Markdown text) right within your document[2]. It's still a work-in-progress, so this is why it's not featured yet on the website. But I'll finish implementing it very soon.
Unlike Obsidian, Plume's editor is a block-editor. That gives it the flexibility of Notion (to put advanced blocks like Kanban within the same document, to do drag & drop, etc.) with the performance of native apps by utilizing Qt C++ and QML (actually, Plume is 4x faster than the fastest native block editor on macOS - benchmarks on the website).
EDIT: Also, Plume is opinionated compared to Obsidian. That means much better ease-of-use at the cost of extensibility. I believe this is a trade-off worth to be making. I know first hand the intimidation of starting to work with something as complex as Notion or Obsidian. Plume is taking the block editor abilities of Notion with the familiar Apple Notes UX/UI while all the data is still plaintext underneath.
Plume is built on top of my open source note-taking app Notes[1]. Since Plume is based on Notes, I'll of course comply with the MPL license and release all existing files that were changed (and must stay MPL licensed).
But I recently discussed my reasoning to go close-source[2]. I've been working night and day (every day) converting 4 cups of coffee into code for the last 4.5 months to create Plume. I don't want to risk not being rewarded sufficiently for it. But, I'm 99% sure that I'll either open source the core block editor or the entire app in the future.
> But, I'm 99% sure that I'll either open source the core block editor or the entire app in the future.
Why withhold the remaining 1%? If you aren't so confident about your decision to open source, there's no need to commit to that decision now.
It's good that you are leaving the door open, but keep in mind that if some folks suddenly become successful with a service that can turn any GitHub repo into a nice looking SaaS, at the click of a button and for a super low fee, I'm pretty sure you'll be hesitant to open source all your hard work so it can harvested.
Because I'm very much still a believer in open source. And you're right, that's a horror scenario I want to avoid. I'll only open source it in a way that won't compromise the sustainability of my work. I've yet to come up with the right model, so until then, it will stay close source.
That being said, there are a great many apps with support for kanban-style boards that one could use before resorting to jira. Notion, for example, can do it.
I only recently reached an alpha - and I am looking for testers!
- Alpha screenshot: https://drive.google.com/file/d/1Wi6MqxC17iIzfSL--_nNxHxbID1...
- Rambling why I built it, plus Discord link: https://progress.compose.sh/about
reply