It is difficult to tell from the readme (or the repo path, or the gh-pages site) if it is an official project, or unofficial, or not-yet-official but maybe planned to be.
Maybe that should be noted?
222 karma · joined January 7, 2017
feepish at google’s free email domain.
It is difficult to tell from the readme (or the repo path, or the gh-pages site) if it is an official project, or unofficial, or not-yet-official but maybe planned to be.
Maybe that should be noted?
Location: San Luis Obispo, CA
Remote: Preferred
Willing to relocate: Yes
Technologies: Mostly Python, 20 years
Résumé/CV: On request
Email: feepish at gmail
Looking for automated testing/QA position.
Language/framework/toolkit not important. If the testing tools are fun, I'll give it a shot.Contact me, I'll send a cover letter and resume.
thanks, rusty
Location: San Luis Obispo, CA
Remote: Preferred
Willing to relocate: Yes
Technologies: Mostly Python, 20 years
Résumé/CV: On request
Email: feepish at gmail
Looking for automated testing/QA position.Language/framework/toolkit not important. If the testing tools are fun, I'll give it a shot.
Contact me, I'll send a cover letter and resume.
thanks, rusty
Very nice after a quick look. Too bad it's not as common as `make`.
11 years ago "Show and Tell YC: Built a webapp in ~14 hours":
But if they added extensions (which mobile Chromium doesn't support at all), they're not shy about divergence.
Not meant as a comment on the proposal or FF vs Chromium.
This (v3) proposal, and the slick rewrite of Mozilla's stuff probably means I will be off of Chromium for mobile and desktop some time in the hazy future.
I think there are more. But I don't remember which ones.
Worst decision browsers made was allowing third-party Javascript.
Easy to blacklist it on Android.
Brave has an easy JS toggle on Android. Brent is iOS, don't know if iOS has the toggle.
I block third-party JS with uBlock on desktop. If there was a better toggle available, I'd blacklist all by default.
It has always bothered me as a fan.
I know one of the riders, and I know of the other. They both seem like good people.
Well-written story about aftereffects, and a reconciliation of sorts.
The AppleScript support was there maybe even before Illustrator was available for Windows.
Not going to look at either API. And, I don't have a current Illustrator.
...but I can guess with certainty that the javascript API gets more attention within Adobe. And that it has a more solid future.
AppleScript may never disappear from Illustrator or macOS. But it _does not_ have a bright, vibrant future.
It has pretty good AppleScript coverage (from looking at the dictionary) but I've never used most of it.
Mostly used AppleScript to call 'do javascript'.
It was super handy for that sort of thing.
Sort of miss it, in a maybe-masochist kind of way.
Open tools to HTML are much nicer. And much less bizarre.
If anyone has some hairy InDesign or Quark or Illustrator thing they need automated, let me know.
...
...personally? lots of useful hotkeys.
But the shit keyboards finally drove me away. Linux on a XPS13 now.
I don't miss AppleScript the language. But I do miss the fact that it was sorta built into everything by default.
No. It should not.
But that’s completely unfair. Xi does not even claim to be beta. I haven’t touched it in months. But when I did, it was a good (start of) a Mac frontend that was clearly not finished.
The only people I imagine using it now probably use it to dogfood the backend and piece together a solid plugin API.
I would prefer Xi-style win the mind share. Native front ends that tie to a common solid backend that a large community can share to build strong plugin support.
I’ll settle for xray-style, a better cross-platform frontend that doesn’t redraw large portions of the DOM quite so often. Javascript is fast enough. A good (heh) extension language. The drawing layer is what makes Electron a slow, bloated choice for a text editor.
Since Atom came out, I have had a backgrounded dream that once things settled, they would write a faster front end for the text. But that is difficult to do if your API is “can you do it in the DOM with javascript?
But they are atom.io. They can change their API if they need to.
VS Code, with its well-bounded API is a much better candidate. And I would love to be surprised by a Microsoft skunkworks non-Electron release.
Xi, is a solid idea. Don’t know if they can build a community out of nothing. I am worried that an API of ”here is a JSON firehose, hook up whatever you want to it” will fragment the backend.
I think Xi would be well served by saying “Here is your firehose, but, the official way is our VS Code emulation plugin.” Or something solid and well-defined.
It is unclear where Xi is going so far, that may happen.
I want this to work.
Also excited to see the discussion and possible cross-pollination with Xi[1] and raphlinus.
I will see what I can do about it this weekend.
The Eudaemonic Pie — Thomas A Bass
No theory, just a fascinating history.
edit:
More of a pre-history. It seems that amazon says nothing about Farmer and what he went on to do.
One of the characters: https://en.wikipedia.org/wiki/J._Doyne_Farmer
I’ve done this for 13 years (Mostly Quark instead of InDesign, but the same tools and tricks).
Let me know if you want to work together.
rusty
[you can email, feepish @ google’s free email]