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 :-)
The Motley Fool | Senior PHP/WordPress Developer | REMOTE - SEE LISTING FOR STATE LIST | https://www.fool.com/
We are looking for a savvy, talented WordPress/PHP developer to join the Global Tech Team at The Motley Fool.
Our mission on the Global Tech Team: Helping people invest their hard-earned cash more effectively and profitably all around the world. We are the team that builds and maintains www.fool.com.au, www.fool.ca, www.fool.co.uk, and www.fool.de. We run our sites on WordPress Multisite and write a lot of custom code around customer acquisition, e-commerce, analytics, and user experience using modern PHP and Vue.js, often integrating with 3rd-party systems via APIs.
I would stress this the most: support your team. Give your team the technical and emotional support they need to do their jobs well and have fun doing it.
Some things I've noticed that had the largest impact on employee engagement:
-
1. Poorly defined development processes heavily impacts morale. Define your code standards, your process for picking a library to use, how you handle versioning of code (and which methodologies), how your team should escalate problems, and expectations of individual team members. Document this in a place where anyone on the team can view it.
2. All projects require documentation on how to setup a build. If that doesn't exist, developers ramped up on the project will loathe the project from the start (and in some cases, the team lead). From scratch, setup a project before handing it off. Document everything you had to do.
3. Onboarding of new team members: make yourself or someone you appoint available at all times for the first week or so. Document and fix anything the new team member needed help with. Onboarding is hard, this will be an ongoing process.
4. Setup one-on-one meetings. Once every couple of weeks seems ideal in my experience. Don't have an agenda, but have a few questions you resort to for filling in quiet spots for the more introverted types. Don't be afraid to ask hard questions (did you have a problem with Robert in accounting last week? are you happy with your salary? what would make you happier?). This meeting is key to employee retention and team happiness.
5. Allow for an open discussion on all major decisions. Have a tool in place where anyone can raise problems. If someone can post anonymously to start a topic, that's ideal. That is where some of the best business growth will take place.
6. Read a book on mentorship. Mentor your team. If someone surpasses your skillset on the team, you've succeeded. I've not read all of Maxwell's books, but he has some really great insight in the couple I've read: http://www.amazon.com/John-C.-Maxwell/e/B001H6NROC/
7. Become known as an advocate/mediator for those on your team and the higher-ups. Fight for your team when you need to, and fight for upper management decisions when you need to. Finding a balance is important, but never lose trust of those you lead.
-
In many cases, becoming a technical lead also means you are expected to learn the business side of things. It wouldn't hurt to read business-oriented books. Anything by Jim Collins is great (Good to Great is a must-read):
http://www.amazon.com/Jim-Collins/e/B001H6GSHK
Best of luck, and congratulations on your learning opportunity!
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.