~mwcampbell

Recent activity

Re: Creating an iOS application 3 months ago

From Matt Campbell to ~eliasnaur/gio

Hi Christophe,

While I'm sure it's possible to register the bundle ID through Xcode, 
that's not the only way to do it. You can also register it through the 
developer.apple.com site. Assuming you have already signed up for the 
iOS Developer Program, you can sign into your account on 
developer.apple.com, and somewhere under the section called something 
like "Certificates, Identifiers, and Provisioning Profiles", you can 
register your bundle ID. I don't have step-by-step instructions with 
screenshots, but I hope that helps.

Matt

Re: Gio and accessibility 3 months ago

From Matt Campbell to ~eliasnaur/gio

On 6/15/2021 8:18 AM, Elias Naur wrote:

> I don't think the Go linker can handle MSVC object files. However,
> because AccessKit is meant to be used on other platforms, won't you need
> gcc/clang support anyway?
The AccessKit libraries for other C-based platforms will certainly 
compile with GCC and clang. (The Android one will be all Java, and the 
web one will be all JavaScript or TypeScript.) But I haven't yet decided 
about the Windows library. Yes, each platform will have its own library; 
the one thing they will all have in common is the message schema 
(probably using Protobuf). The libraries for C-based platforms may also 
export the same C ABI; I haven't decided on that yet.
> Or Gio could upgrade its CI :) 
I didn't want to get into an argument over what I thought might be an

Re: Gio and accessibility 3 months ago

From Matt Campbell to ~eliasnaur/gio

On 6/14/2021 10:17 AM, Elias Naur wrote:

> Not an insurmountable problem. If possible, you may have success in
> compiling AccessKit to an object file and embed it as a self-contained
> .syso file in which case you can avoid the extra DLL.
Would this require the AccessKit Windows library to be compilable with a 
GNU toolchain (meaning mingw-w64)? Or can the Go linker handle .obj 
files produced by MSVC?

Also, I see that Gio's CI uses Wine to run Windows tests on Linux. For 
what it's worth, Wine's implementation of UI Automation, the current 
Windows accessibility API, is only a stub. And it's implementation of 
Active Accessibility, the legacy accessibility API, is also very 
incomplete. So this means that the AccessKit Windows library can't make

Re: Gio and accessibility 3 months ago

From Matt Campbell to ~eliasnaur/gio

One more question for now: The Gio architecture document briefly 
mentions that Gio has a "zero allocation" design. How stringent is this 
requirement? Have you written more about it somewhere else?

My AccessKit project is still in the early design phase, so I want to 
make sure that it will be usable for Gio and other similar toolkits.

Thanks,
Matt

Re: Gio and accessibility 3 months ago

From Matt Campbell to ~eliasnaur/gio

On 6/14/2021 9:45 AM, Elias Naur wrote:

> Well, beggars can't be choosers :) More seriously, I think your plan
> sounds great, and support for multiple toolkits will make your project
> better and spread the maintenance burden. In fact, the issues in
> accessibility support sound similar to what we face to implement support
> for complex text scripts. We have the #ui-text-rendering Gopher Slack
> channel and the beginning of a shared library at
> https://github.com/go-text/shaping. I encourage you to initiate
> something similar for accessibility and bring in the Fyne people.
Thanks. To be clear though, I want my AccessKit project to be 
language-independent, not just for Go. That's why I propose using a 
Protobuf schema as the glue between the cross-platform toolkit code (Gio 
in this case) and the platform-specific accessibility implementations,

Re: Gio and accessibility 3 months ago

From Matt Campbell to ~eliasnaur/gio

On 6/14/2021 7:56 AM, Elias Naur wrote:

> I think you have a better chance arriving at a design that fits the 
> platforms
> APIs for acccessibility. I'm happy to review what you come up with.
Agreed.

One problem we're going to encounter with implementing platform 
accessibility APIs is that it will require much more cross-language glue 
than you have had to implement so far. The Windows UI Automation API 
requires you to not merely consume COM interfaces, but implement them. 
Likewise for Cocoa with Objective-C, and Android with Java. I'm guessing 
that doing all of this in a Go project would be quite tedious.

Re: Gio and accessibility 3 months ago

From Matt Campbell to ~eliasnaur/gio

Elias, you mentioned the issue with Tailscale for Android. I mistakenly 
opened a duplicate of that issue yesterday, and on my issue, someone 
mentioned that they were planning a UI rewrite, likely using native 
widgets [1]. Do you know anything about this? Of course, accessibility 
in Gio is important for more than just Tailscale.

Would you rather design Gio's accessibility support yourself and have me 
review it, or vice versa?

Thanks,
Matt

[1]: 
https://github.com/tailscale/tailscale/issues/2118#issuecomment-860240140

Re: Gio and accessibility 3 months ago

From Matt Campbell to ~eliasnaur/gio

Hi Elias,

I wonder if you have any plans to implement accessibility in Gio in the 
near future. I'll be happy to help, especially with the Windows 
implementation (BTW, I'm no longer at Microsoft). But this will require 
some design work, which you'll obviously need to at least approve. I 
like your earlier idea of emitting accessibility-specific operations 
during widget layout.

Gio is now being used in a couple of Android applications that I'd like 
to be able to use (Tailscale and Wormhole William). And I depend on the 
TalkBack screen reader when using my Android phone. So I now have a more 
concrete interest in seeing this gap filled.