A much shorter article, if it were to exist: Reviving a 16-year-old Windows App
Reviving a 16-year-old Mac App
71–80 of 108 posts
Re: Reviving a 16-year-old Mac App
#72The image in the default file is something like whisk-outline. Can't find that anywhere inside the app. Where is that coming from? It specifies a relative path, not an absolute one. Did a find for the image from the command line. Can't find it anywhere. Nothing in preferences for a source of files.
Ran the app a second time--the default file is gone. Where did it go? Not in recent files.
Dragged my own image in a new file. Got an outline box and the alt text, but no image. Put the image in "watched files" in the right pane, still no image. Where is the file root? Where is the image root?
When I try a piece of software I instantly look for the thing I thing will be hardest. Your app displays all the HTML and styles great, no worries, but where's the root in the filesystem? Where's the image root path against which your relative paths are specified?
Went through all the docs--nothing about images. Not in the video, not anywhere else I can find.
I just don't understand where the HTML root is or how I insert resources in your app or where the relative paths point to or how to specify relative or absolute paths. Nothing seems to work.
I read about sandboxing in the docs. Is this a sandboxing problem? No dialogs pop up as described in the docs. Checked settings--nothing there.
All I want to do is write a couple of lines of HTML to specify an image and have it displayed. This simple task is not working and not addressed in your documentation.
Honestly, this sort of thing makes me feel like I'm losing my mind. How is it that specification of path and resource roots is not one of the first and most prominent things in the docs? How is it not there anywhere? How does the developer and every user not go, "Wow, I wrote an img src= line and it doesn't display the image?"
Re: Reviving a 16-year-old Mac App
#73I still use Tumult's Hype 3 (Pro, I think) to do HTML5 animations - it's pretty great, even if moving to 4/Pro for the (very few) features I'd like to have seems a bit steep at $99.
Whisk appeals to me because I _know_ it's going to be a polished, lightweight app, but with VS Code having quite usable previews I don't see the value of its current price point (to me).
Re: Reviving a 16-year-old Mac App
#74> In 2020, distributing requires learning the intricacies of certificates, code signing, provisioning profiles, hardening, notarization, .dmg creation, gatekeeper, and paying a $99 per year fee. I had to manually create, sign, and notarize a Mac app the other day and it was total madness. It took multiple tabs of Apple documentation ( new documentation, I might add, created this year because everyone complained last…
This may be a question you get a lot, and I apologize in advance if it is, but: Why use Mac, if it makes so simple of things difficult?
For me it's simple: it runs all the software Linux does, but also runs all the software Linux doesn't. I can use those familiar and powerful CLI tools, but I also have real Office and real Photoshop when I need it.
While things have certainly taken a tumble in the last few years with the faulty keyboards and slipping software quality, I am still yet to find a better laptop than a MacBook Pro, when considered as a complete package.
Re: Reviving a 16-year-old Mac App
#75> In 2020, distributing requires learning the intricacies of certificates, code signing, provisioning profiles, hardening, notarization, .dmg creation, gatekeeper, and paying a $99 per year fee. I had to manually create, sign, and notarize a Mac app the other day and it was total madness. It took multiple tabs of Apple documentation ( new documentation, I might add, created this year because everyone complained last…
It’s so frustrating that automation and command-line is treated as almost second-class citizenship on macOS. You know how I log into a remote server securely without ever entering my password? I enter the command "ssh" and the server name. Why the hell isn’t notarization implemented, effectively, as "notarize appname.app" where all the details are resolved securely, just as magically, to your developer keys? Yet if y…
> It’s so frustrating that automation and command-line is treated as almost second-class citizenship on macOS.
Sure, they're horrible, but I look at it as Apple generously creating jobs for engineers. I had a full-time job as a build engineer specializing in navigating the Lovecraftian nightmare of iOS build automation. Sure, they could've made it easy, but instead they chose to help transfer large sums of money from my family-friendly multinational megacorp employer to me. I returned the favor by using some of that money to buy their products.
Re: Reviving a 16-year-old Mac App
#76The 99$ annual fee is ridiculous. Big companies don't talk about it because it is a regressive tax. It hurts hobbyist more than anyone else.
I don’t think Apple want hobbyist apps in the store. They want apps that will create revenue and the fee creates a filter of sorts.
It would be good to be able to side load hobby apps, but that’s never happening.
The fee does also get you 2 tech support requests, which should connect you with their engineers if you need help (never needed this, can’t say how extensive it is).
Also, I did read somewhere that they waive the fee for some nonprofit/education institutions.
Re: Reviving a 16-year-old Mac App
#77Earlier quoted context omitted.
It’s so frustrating that automation and command-line is treated as almost second-class citizenship on macOS. You know how I log into a remote server securely without ever entering my password? I enter the command "ssh" and the server name. Why the hell isn’t notarization implemented, effectively, as "notarize appname.app" where all the details are resolved securely, just as magically, to your developer keys? Yet if y…
> It’s so frustrating that automation and command-line is treated as almost second-class citizenship on macOS. Try automating signing a windows driver. It's all GUI. At least the mac code signing tools are command-line.
No, it's one well documented command line tool called signtool. I've used it quite extensively and it has never failed me in an unexpected way.
I can't report much good about the Apple signing side. In the end we put that into a VM because different xcode versions will produce vastly different signatures for no obvious reason, and the older ones were more widely compatible.
Re: Reviving a 16-year-old Mac App
#78Cool story. In a way I'm surprised one would try to adapt the old code after so much time has passed, rather than just starting fresh. It can definitely be interesting, just more... frustrating.
Re: Reviving a 16-year-old Mac App
#79Cool story. In a way I'm surprised one would try to adapt the old code after so much time has passed, rather than just starting fresh. It can definitely be interesting, just more... frustrating.
I imagine in the end not much old code was left, but if his initial code was well structured I can also see how it helps to not start from a blank slate. The structure you see in the names of files, classes etc. can make it easier to keep a mental model of the app that you’re building.
Re: Reviving a 16-year-old Mac App
#80Every modern web framework has auto reload, so this is an app that’s only targeting people who know HTML well enough to hand write a page but don’t know about modern web development. Good luck, but I can’t imagine it’s a growing market.
I build my website with Jekyll 4 and use livereload, but have actually found some use out of this tool for writing small snippets. Seeing your CSS come to life with every keystroke in real time (without having to press CMD+S in your IDE) is surprisingly useful. The main use-case where this tool has been useful, though, is when I'm working on my Mac app that uses WKWebView and Javascript pretty extensively. It's much…
Jekyll is kind of slow :(