However much I try, I can't really give up .net and mobile dev with it, even though I'm learning flutter and exploring the apps that can be made with it. Well, though a bit more limited than x.f since it doesn't have things like xamarin.essentials, it's quite powerful I admit.
However, I came here to tell ya all that, even though .net maui is only preview, they implemented accessibility early on in the development process, so we maybe have some hope?
I didn't try it my self, have to free up some disk space, I don't have enough to install all the required things.
As a sidenote, I think I should get a tower or something, because the more I do programming, the more my laptop gets heeted and the fans grow louder, so I guess a laptop isn't really good for the kind of tooling I have to run on a daily basis when dealing with xamarin, .net, and now maui.
Anyways, for those of you who are interested, here's the link to the blog post explaining things to the newest preview maui, the one with some accessibility implemented:
https://devblogs.microsoft.com/dotnet/a … preview-3/
Well, the current version has as much as x.f had, minus a few things. That also means the code must have been ported almost directly from xamarin.forms, but at least they thought about that early on. I mean, they implemented some accessibility things even before other common controls are built, that must mean something, right? Am I too hopeful to expect they'll try to avoid the design decisions that plagued xamarin.forms, not only regarding architectural flaws, but accessibility as well?
#1 (edited by bgt lover 2021-04-16 14:41:58)
Uh? The link is for an nvda addon.
oops, had something else on my clipboard, scrue that, it's the first time it happened in all my posts lol. Guys, this happens when people don't proofread their posts, couldn't even start to guess the link was wrong rofl. Anyways, edited the first post.
I'm just going to say--don't be excited about the technologies of tomorrow. I expect that Microsoft will probably get this right. In 2 years. Don't make plans that depend on it. That's a good way to set yourself up for failure.
Be hopeful, sure. But don't delay projects and don't plan to use it without it existing. Until then it is best to treat it as if it doesn't exist.
We'll see. I really hope it will work well.
and my mother is a ripoff of my grandmother.
We're all bitching about game clones,
and by generations of generations, we're based off stolen code.
@4. Nope, I'm not doing that again, learned from my trip in the xf land. Basically, I started making an app with it, without making some demos or whatever first with all concepts I wanted to use and then ditch it as fast as possible since many things leave something to be desired in accessibility.
However, now I have an xf app that's unfinished due to the accessibility issues, and don't expect I'd be able to port it to dart soon, especially because some of the more specialised dependencies can only be found in .net as far as I know.
So nope, not relying on it anytime soon, however a bit of hope exists still.
As a sidenote, what would you do if you were in this situation? Scrap the app, continue making it despite the accessibility issues in xf, or try port it to dart?
Port it to Dart.
I'm currently working on porting a full audiogame stack to Dart. So far I've got tolk and Synthizer working. Unfortunately there's a probable bug with raw keyboard events in Flutter, so the arrow keys get reported as numpad keys, but I've reported that, and everything else just works, even without Windows accessibility yet.
As an aside, I've basically got a pure dart version of getch that runs on Windows. Using it to make games is both retro and fun!
Selling my soul to andertons.co.uk since 2012.
I'd either port to Dart or React Native. Both can do accessible UIs on the phones, though desktop is certainly meh. Surprisingly getting all 5 platforms is also meh in sighted land by all accounts, which you'd think wouldn't be the case, so at least we're not alone.
Looking at the Xamarin docs though I find myself wondering if they just fucked their examples. On at least iOS having a label separate from the textbox is actually the norm, for instance.
Frankly, I really don't buy that .net has dependencies that you need that you can't get anywhere else. What's the big deal that you can't replace? I don't know how .net ranks exactly but JS, Java, Objective-C, etc etc are all incredibly popular, and you're not at the experience level where you should be running into this problem unless you're trying to do something very unusual. It's a problem you can run into, but it's kind of hard to do.
I'll probably just use Rust when I get as far as that because self-voicing UI is annoying no matter how you slice it, so why use two languages? But I really hope we do get desktop accessibility. Rust makes writing a little JSON-based bridge stupid easy.
If you ever get multiplatform screen reader libraries working, please let me know. I hate the idea of depending on Tolk, when every other library I use is - or will be - available on all desktops platforms.
Selling my soul to andertons.co.uk since 2012.
I mean if I do that it'll probably be open source, but I thought Nolan already had something in Rust, so you could just bind that to C and call it. If I do it it will probably also be in Rust, and thus maybe not helpful to you, unless you are willing to write the C binding for mine. In general I am moving away from "produce a bunch of pieces in C that are bound to Python" and toward "produce a bunch of pieces in Rust and if someone wants to put a C library around it that's not hard". I'm finding that figuring out how to produce a bunch of libraries for everyone in the sense of being entirely language agnostic is going to be enough overhead that I'll spend forever not starting the project they're for, sadly, and as much as I value the platform I also value the project (don't worry, Synthizer isn't going anywhere; it's in C++ for other reasons to start with but also I don't intend to yank projects out from under people).
If Dart gets Windows accessibility and has live regions you're already set though. If it doesn't have live regions, it might be worth opening an issue, though resolving it is of course not likely to happen quickly
Well, I have two apps in mind, the latter isn't even begun yet, so I can consider my self lucky for that at least.
However, with this app, I intend to make programming more fun for whoever learns it for the first time, with a simple, easy to learn scripting language, lua. It's made to embed lua in as seamless a way as possible, so if you guys know of a lua interpretor that can make it so easy to embed like nlua for dart or js, I'm all ears really.
Next, due to the purpose of the app, a lua interpretor by itself isn't enough, it must be highjacked with functions and libs and other things to be able to interact with device features as to make the newly discovered skills a bit mor of a fun experience for newcommers. In xamarin land, I use xamarin.essentials to achieve this in as a cross-platform manner as possible. So, can flutter or react provide some of this?
*file picker and photo picker
You will have trouble getting this through the iOS appstore, as it enters a gray area in their guidelines about how you can't offer apps that let people make apps. I'm not sure which side of that it falls on, and they do sometimes let things like Expo just get away with blatantly breaking rules they apply to others, but you should look into whether or not this is already dead in the water.
Yes, you can get at either all or almost all of the things in your list from anything. That said, I didn't know phones offered barometers and I'm reasonably sure that on iOS your app can't send SMS because that's yet another thing they don't allow you to do. For SMS you probably have to embed Twilio or something like that; note that Twilio costs money, and that there are extra steps to let someone send texts from their own number with it. But I might be wrong and it might be possible without.
Lua runs on everything including microcontrollers and is a C codebase. All your C# library does is bind it to C#. In the absolute worst case you bind it yourself, but googling dart lua finds two packages for it on the first page of results. I can't quickly find something for React Native but you can compile Lua to asm.js I'm pretty sure, and for what you want React Native is probably a poor fit anyway. I wouldn't be focused on ergonomics of binding Lua to whatever language you choose; you have much bigger problems than that, accessible UI trumps anything anyway,and it's not like your users will be dealing with it.
Here's your real problem. All of those APIs you want to get access to on the phone are callback-based and Lua isn't threadsafe. This means either doing a bunch of stuff with lua coroutines which may very well require you to go all the way down to writing your own C binding because of how far you have to push the envelope, or it means doing a bunch of ugly stuff with threads to convert callback-based APIs into blocking APIs. If you're going to just do aREPL then maybe you can get away with half-assing it, but in practice you're actually saying "I want to rewrite React Native in Lua" plus saying you want to simplify it in ways it can't be simplified. People either have to learn coroutines which have all the downsides of threads plus not being threads, or they have to learn callbacks and async await, and at that point they can just use React or something plus Lua can't do async/await anyway (yes. Async/await is coroutines. But what makes it livable is the syntax denoting that something yields, which is a side discussion that we can have if we need to).
I'm not even convinced this can be a cross platform app at all at the moment, for what that's worth. I lean weakly toward yes, but it's not about whether you get access. It's about whether you get low enough level access to hack things that aren't going to want to be simplified into something simplified. You're kind of saying that you want to build React Native on top of React Native, or Xamarin on Xamarin, and so on, and in general you can't stack abstractions like that because the abstraction you're trying to build on has a tendency to get in the way.
It's probably worth not making this your first app (or at least, I assume it's your first app, based off the questions you've had). You should know what you're doing before you try to build complex tools to help someone else learn. In this case you should also be prepared to write your own native-level code as well. You can probably pull this off but only with an incredibly tight scope, e.g. "it's the Python repl but in Lua, and I can call these 10 functions". I think you're underestimating the difficulty by an order of magnitude, if your goal is to write something that lets people put UIs and stuff together or anything like that.
First about iOS and apple stuff, I just want iOS support to be easily implemented at a moment's notice or something, that's why I want the cross-platform toolkit to inplement it out of the box, this way there won't be major UI or architectural changes I'd have my app to undergo when or if I eventually get a mac and the required tools and the appstore interface becomes usable, as I herd appstore connect is inaccessible, or you don't need that to deploy to the appstore, I DK, but that's O.T.
About if this should be cross-platform or not, actually, that exact same question I posed my self too, that's why I created that thread about xf some time ago, then the first doughts about the framework begun to creep in, and then I suggested supporting each platform separately, even though in c#. Well, every miner change, as you said as well, would have to be transcribed to all 4 or 5 platforms, place where bugs could readily occur btw.
Well, about the callbacks and coroutines, the c# lua binding allows lua functions to be registered to a .net event, delegate, etc. So, if we take the example of winforms, we can have a lua function be called when a button is clicked. This is done by simply hooking the lua function to that event. Well, a lot of reflection happens there at runtime, behind the scenes, as well as code generation, but I think it's worth it if one has to deal with callbacks and .net events in lua very often.
Well, nope, I think I know where you're coming from, no, I'm surely not trying to port bgt to the mobile realm or something like that. OK, let me tell you now where it all started.
So, a question first, since it has a great thing to do with the story. So, have you ever played code7? If so, you must remember the muffin levels. If not, read on.
So, somewhere along the game full of fun and otherwise not really fun challenges, one of them sparked my interest, not in the fact it hasn't been done before since I think the sighted have a lot of those, but in the way it was inplemented for us.
So, there were areas in the game where you had to go down a shaft or similar to press a button, such disarming security or some other uses, like stealing data through the network traffic inside the building, etc. For that, you'd use something called muffin, it's basically a programmable drone that follows your instructions to the leter, so instead of remotes and such, you'd write a program in advance to carry out that particular task/solve the particular puzzle.
So, once you enter the shaft, you can explore the area, those twisted passages that form a labbirinth the exit of which is the successfull completion of that puzzle. As programming constructs, you don't have functions or classes or such, but you have if, while and I think that's all. So, if you have a long passage that, let's say, only curves to the right and each curve is blocked by a button that, when pressed, would reveal more of the passage, unblocking the way till the next button, you could write something like
Something like this, anyways. This is kinda simple, however things get very complicated very fast, for example the wind that spins the muffin randomly every three muffin movements, the training pits you have to go around since you can't pass through them, etc. Plus, the language actually gets kinda debugged, since sappi is speaking each line of the program as it is being executed on muffin, so you know when it went back through the while loop, when it entered an if statement and when that branch got skipped due to the condition being false, when the program ended, etc.
However, code7 is a huge game in my opinion. So, one has to learn many game-specific terminology and mechanics only to complete some of the other puzzles, adding muffin and programming to the mix won't do anything but frustrate or overload the user, that's why someone gave me their save and said, fuck it, solve it, I DK how or something like that. No wander all the solutions to the critical game muffin puzzles are publicly posted on the game's discord somewhere.
So, I thought, if this is fun even as a minigame, why not make of this idea a fullly fladged game or something, to help people to learn programming even more interactive and with more fun. I mean, sighted get scratch for free, why don't we?
So, this app isn't a kind of bgt layer abstraction or whatever else, it's more of a super interactive tutorial on the basic concepts of programming.
So, there should be exercises with various levels of difficulty, and they should be interactive too, meanning that you get points if the program is giving out right answers. The concept is explained with code examples one can run and understand at one's own pase, plus there could be line by line explanations, even linking back through the tutorial if the line refers to previously learned concepts.
Then, a bonus this does whatever to your device bit of fun is presented every chapter end, for example, this is the function that makes your device vibrate. Now, with what you learned about random numbers and variables, write a program in the interactive box that displayes a random number between 1 and 6 and then makes your device vibrate for that amount of seconds.
Now that I think more about it, the way I would imagine it being structured is kinda like the talkback tutorials, even though with a bit more music and sound effects and some other elements of fun. This is prymarely aimed towards a younger audience or one that gets impatient soon, otherwise they would start as many people did and still do, with beginner books, maybe some videos, courses and examples. However, this might appear too boring or time-consuming for some, so this is where this weird app idea will come in to play.
Now, I tryed to explain this the best I could, does it make more sense? Am I reeching too big here? I think a bit, but yeah. Should this be cross-platform, or be made for every platform I want to support specifically, what do you think? Is there even a point in attempting such a thing as I'm invisioning?
I don't know if you're reaching too big or not. There's two aspects to this.
The first aspect to this is that if whatever you come up with requires you to hook your lua functions up to delegates (as a player) then you have invented React Native, and it's going to be complicated. I'm going to just assume that you're not doing that and their program is just supposed to go top to bottom. In practice what you have to do here is delegate running the user's program to a background thread. The typical architecture for that is an SPSC queue that talks to the main thread. I wouldn't focus on "but nlua does reflection" because that doesn't matter: what you're actually doing is hooking up a small number of functions that send a cross-thread command, and whether you have to write a small amount of manual code or not isn't relevant to how fast you get it done. You probably also want to get access to the Lua debug hooks so that you can stop infinite loops from running forever, which may necessitate a lower level, depending. But in general "how do I talk to lua" isn't interesting unless you're talking about 50+ functions.
The second aspect to this is: can it be cross platform? Maybe, specifically as you describe it. But React native is almost certainly out. Dart might be out depending on how isolates work. C# seems to be out because of Xamarin accessibility, though I do sort of halfway wonder if you're just using it wrong; they wouldn't be the first GUI framework to support accessibility but then make all their examples inaccessible. If you don't have iOS then going to Java might just be your best bet; you can worry about porting later. If I had known exactly what you were doing, I would probably have been less definite about whether you could be cross platform or not.
The good news is that this is probably fine with respect to the iOS guidelines.
But you do need to restrict what you give the user access to. Specifically, it has to be something on all phones. Accelerometer is out for instance. You also really don't want to let this thing send SMS. On the one hand it's a cool program that can do cool things and sending SMS is fun. On the other hand an automated way to send SMS is a robo-calling builder toolkit that someone might figure out how to leave running on mom's cell phone. If the user gets their SMS program wrong it will also charge them money, and if you end up having to go through Twilio it will charge you money. In practice you probably want to limit this to audio and vibration, maybe some text input, some speech. It's going to be less fun than you think, in other words, and imo there's no reason to not just do this on the PC other than that everyone's got a phone these days.
Also, with respect to usefulness: the most you're going to accomplish is getting people interested in coding. There's a big gap between a game like this and doing something productive without it using proper tools. I wouldn't expect to be able to bridge that gap in any meaningful way with the resources you have if i was doing this myself, so if your motivation is to do so rather than to just produce something fun then you probably want to reevaluate.