Godot on iPad, Toolbars, Importers, Embedding, Debugger
blog.la-terminal.net
blog.la-terminal.net
And if the targeted usage is "iPad with a keyboard on a desk" well, at this point it's mostly a laptop anyway so as a developer why even bother getting a tablet in the first place?
You are correct, but I think efforts like this are an important part of discovering how we can make the tablet form factor useful for more types of productivity. Software design is an evolutionary process, and I think professional tablet software is still pretty stunted in that department. Largely down to Apple's endless resistance against allowing the iPad to be used as a computer rather than a media appliance.
The more stuff we get like this, the sooner we can collectively work out how to work around the shortcomings (no guaranteed keyboard, poor feature discoverability of touch-first UIs) and lean into the positives (handheld, ultraportable, direct manipulation).
It's crazy that we've had the iPad for 14 years and tablet computers in general much longer than that but we seemingly still haven't worked it out yet. It still feels like the only options are scaled up phone software (iOS, Android) or desktop software with a touch layer awkwardly bolted on (Windows).
Maybe there's nothing to work out? At least for activities like this
Similarly people said that for desktop sculpting but many artists now use Nomad, plus there’s ZBrush for iPad coming out.
How do you we know it’s not worth working out unless someone tries?
And even if it doesn’t work out, just look at some of the UI learnings here that could be valuable to apply backwards.
Did phones with styluses mean they’d lost? It’s an optional, removable attachment.
Good game though for fun.
1. By porting the frontend to SwiftUi, they’re actually making it more native for all Apple platforms. He hints at it, but this is a great first step to having Godot native on visionOS where they can iterate on their games natively in device.
2. A lot of creators (not necessarily developers) have switched to the iPad as a primary creation device. Perhaps not a majority by any means, but a sizeable amount.
Concept artists are on iPad. Recently the character designer for Blue Eye Samurai did most of their work in Procreate.
3D sculptors are picking it up as well with Nomad sculpt and I think the soon to be released ZBrush for iPad (September 10th apparently).
So if you’re on the more visual side of things, and you’ve already got your workflow on iPad, this lets you continue that workflow.
From what I can tell, there isn't even a version of Roblox Studio available. Scratch seems to work though.
I’ve noticed most of the people we hire these days for dev roles have no idea how computers or operating systems work. I’ll have someone with a pretty impressive title reach out to me with a basic OS question, and I wonder how they got to where they are without this foundational knowledge. Most of this stuff I learned on my own when I got my first computer.
I have no idea if they really never learn and wing it until they become managers or become great cloud engineers who simply scale up instead of running strace.
I dislike that the two are conflated.
Firstly, Mac and Windows both offer a very mature command line interface.
But also, I don’t think knowing Linux should require you to know the command line either. If other operating systems don’t require it, neither should Linux.
If you’re focusing on “developer tools”, even then, what tools do most devs need that can’t be done from a UI? I live a lot of my time in the terminal but there’s very little that can’t actually be wrapped in a UI
But I think they can also obscure functionality the same way as a GUI tool.
Take git for example, it’s much easier to visualize how it works from a GUI. Squashing is also faster in a GUI. But some other operations are clearer when you’re giving every flag yourself.
Ultimately I think it comes down to the UX of something regardless of the form of UI it’s presented in.
I’m very familiar with Linux. My day job for years was Linux based and I honestly do not think one needs to know it, or any other OS specifically , unless your job specifically requires it.
Assuming the discussion is about a typical developer that runs code that is deployed to “the cloud”, and the cloud is basically 99% Linux, yes. You absolutely need to know enough about how Linux actually works to be effective at your job. Otherwise you’ll fall into the sort of trap zillions of “big data” engineers fall into, where you spend countless hours writing custom code that takes up terabytes of RAM that could have been a simple sed/awk/grep pipeline that uses a handful of kilobytes.
It doesn’t specify a job and that’s exactly what I’m calling out.
Even your response assumes that a “typical” developer is one who deploys to the cloud , but what is that based off of? And how many of those need to interact with the cloud infrastructure itself?
Your second point about taking up terabytes of RAM doesn’t really matter if it’s on the cloud or not, and certainly doesn’t matter if it’s Linux . It’s also assuming that you can’t have a UI frontend that just calls the necessary efficient code or CLI commands behind the hood.
So my question remains: what percentage of jobs actually require you to know Linux specifically?
We can apply the principle of charity and assume that because OP was making this complaint at all, it was probably in the context of jobs where ostensibly there is plenty of value in learning Linux. You don’t need to ask for qualification here, it’s just assumed by context that, for OP’s point, these were probable roles that really should have Linux knowledge.
But you turn that around and say “but why would you need Linux knowledge??!”, taking the least-charitably-possible interpretation of OP’s comment, as if they’re talking about janitors or something, challenging them to prove why the majority of jobs (!!??!!??) needs Linux knowledge.
I dunno man, maybe because in their head they’re referring to a category of people for whom working Linux knowledge really should be expected, and it’s assumed that readers of their comment will probably understand that, and that they’re not going to be prompted to qualify every last thing they say.
But sure. Yeah. Linux technically refers only to a Kernel and not the whole OS so people shouldn’t say “learning Linux” if they only mean a CLI and a basic unix-like environment. You’re very smart, thank god you’re here to clarify all of this for us.
I need to stop with HN for a while, the level of pedantry has gotten absolutely out of control and I’m getting angry just reading this shit.
The phrasing is exactly
> There are people here on this forum openly admitting they don’t see how ‘knowing Linux’ is useful
That could literally apply to any job, especially as a developer.
And then the rest of your inane rant is about something I didn’t say. I didn’t say anything about linux being limited to the CLI, in fact my other comments say Linux is much more than the CLI.m. So now you’re just inventing your own argument to be angry about.
So maybe take your own advice, and give a charitable reading instead of getting angry because you’re unable to make a point. Because not only did you take the least charitable version of what I said, you invented arguments I didn’t make.
And maybe you should take a break from the internet if things make you this angry this easily.
Now, talking about people who actually deploy code to backends... these are the folks I had in mind. I imagine most of them don't deploy to Windows Server and they sure aren't deploying to any macos backends.
Why would a frontend dev need to know how to configure a http server beyond what node or wamp/lamp gives them?
The number of full stack people is very low compared to dedicated backend and frontend folks. People focus on the needs of their job, and if their job doesn’t require wearing both hats they usually don’t go out of their way to do it.
Even at many companies that deploy things to the cloud, they’ll have dedicated folks for that because the people writing the code to run are busy writing the code.
That it eventually runs on Linux is not very meaningful to most devs unless their app needs special compiling configurations or libraries.
> Even at many companies that deploy things to the cloud, they’ll have dedicated folks for that because the people writing the code to run are busy writing the code.
And this is the root of the problem. A week's worth of coding sure saves them a day of configuring their host systems, not to mention optimizing their cloud spend up. The folks who actually know how the system works and how to diagnose when it doesn't are in short supply and are also effin busy.
> That it eventually runs on Linux is not very meaningful to most devs unless their app needs special compiling configurations or libraries.
This is true only until it isn't. There can be times of coasting and then the dreaded base image version bump comes and 90% of the organization has no clue if they're impacted or how to check if they are.
And all the stuff you mentioned can be done by learning those skills on windows or Mac. Linux doesn’t really need to factor in, and now you’re saying to learn an entirely new operating system in addition to a new skillset.
You’re trying to say they should be more than what they are, but for a scenario they can’t predict coming up? In which case any number of other things might happen too, and there is likely already a team of people better suited to handle those issues. What would the sales pitch be to have someone learn it?
I think there’s an impedance mismatch between what you expect to provide value to someone as a hypothetical future goal and what they actually need to achieve their objectives.
Linux is important if that's what the backend deploys to. If it is, it's a part of the operational envelope - I am saying engineers should have familiarity with what production is running on. I don't particularly care where those skills are being picked up as long as you know that on the production box there's strace instead of dtruss and you know how to check what the D state process is waiting for or whatever interesting issue arises which only happens under load, with networked storage and with at least a couple dozen cpus. (This is also why I don't care for frontend devs to 'know Linux', but having some knowledge about HTTP and their production HTTP servers would be beneficial, as would be knowing that networks aren't magic...)
It's great because we as parents can give our kids a huge boost by guiding them to learn on their own. Look up 'learned helplessness'
The last part is making sure we teach our kids never to work for less than twice as much as everyone else.
Unfortunately, like you point out, the iPad is not actually usable as a laptop replacement, sadly.
At the same time, some “developer” might like to stay in one Env. Sadly there is no dual Env for mac, and windows tablet mode …
Ok, but this “and” thinking doesn’t help me do what I said: get rid of laptop, save money.
Exactly, it's mostly a laptop, so it's my main driver when at home. No inconvenient keyboard in the way when consuming media on the couch, but very productive when coupled with a (mechanical) keyboard, mouse and external display. Getting my ipad is no bother, getting my laptop is.
Lots of schools give all their students ipads.
Also lots of kids have iPads but not laptops (my girlfriend's daughter does not have a laptop that could do Godot development, but has an iPad).
My assumption is it's more about introducing people to development than professional developers moving to iPad.
iPad Pros have a very capable (and expensive) keyboard which doubles as a great stand. BLE keyboards and mice can be paired with an iPad. Wired keyboards also work.
I think my tech life would be more simple if I could use an iPad as my computer, but I can’t see a path there. I’d have to give up too much.
There are power users out in the world that never use a terminal because that's not their line of work. I use the Affinity suite of apps, most notable Affinity Publisher for layout and design work. I regularly design annual reports, newsletters, any number of print materials ranging from brochures, posters, banners, bookmarks, etc. All of it. And I do it all with the iPad and whatever input I want/need at the moment. No problem.
Additionally I use the iPad along with Textastic to code websites the old fashioned way, basic html and css. I started experimenting using the iPad for those particular jobs in 2010. When I sold my MacBook Pro in 2017 I switched to the iPad for all of my new website set-ups as well as website updates for existing sites. Textastic is great for that and I've had no problem.
Last, I do spreadsheet work for a client who runs a retreat center. I process thousands of records per year, managing contacts, retreat signups, mailings, etc all from the iPad and with no problem.
When I want a break or at the end of the day I set the keyboard to the side but within reach.
Another point worth mentioning that I think often goes overlooked by those that don't use the iPad is the variety of interesting set-ups that can be created with it. Because it's not attached permanently to a keyboard it can be easily attached to a multi-arm stand and swiveled to different angles and heights. Just one example. I've enjoyed experimenting with all sorts of different useful arrangements.
The iPad obviously isn't for everyone or every task. But it's kinda bonkers how many people who don't have a use for it themselves just assume that no one else could possibly put it to use.
I was thinking more about people who solely use the iPad docked with the keyboard and trackpad.
I’ve had 6 or 7 iPads. They all end up sitting around with a dead battery after a while, because all I ever want is a keyboard and mouse, and at that point, the laptop is easier to deal with.
When people were confused by the keyboard, Jobs said that death would take care of that. When it came to files, he saw that as a problem that needed to be solved in the system, but I think it is more confusing on the iPad than macOS.
People have had to use files, moving them to floppy disks, burning them to CDs, copying them to flash drives, and now dealing with them with services like Dropbox. I would think files and folders in a home directory would be something people understand now. I think the modern smartphone and tablets made a lot of people regress, and the youngest simply aren’t learning it. The less it’s used directly, the abstract the idea becomes, and that makes systems harder to use, because at the need of the day it’s still files and folder. Avoiding that has so far created confusing layers of abstraction that haven’t worked so well.
I completely agree, and I think this is probably iOS' single biggest design mistake. In trying to hide away difficulties non-power users face managing a filesystem, they've managed to make things both more confusing for novice users and just plain annoying for power users.
I think the issue is that most computer users do understand at least a little about filesystems. They might lose things or accidentally delete or overwrite things, but I think many many people are reasonably okay with the concept "my things are in files, my files are in a folder".
But the app-centric model iOS uses becomes unnecessarily difficult when you need to do anything with a file that extends beyond viewing it in the software that created it. Emailing or copying a file is an incredibly common thing to need to do, yet some of the most technophobic people I know can manage it just fine on a PC because the process is the same for any and every file. The hardest part for them is usually just remembering where they put it.
That one problem is solved by an app-centric file model, but introduces a much bigger problem in that the mechanism to share or copy a file is different for every app! It might be under an "export" option, or it might be under a little abstract picture of a square with an upwards pointing arrow—because of course, everyone universally understands that square-with-upwards-arrow is how you email this to Steve in accounts...
(Yes the share icon is fairly standard across iOS apps, but it could be and is located all over the place, and I'm not convinced it's intuitive that step one of "emailing a document" is "open Word").
I regularly manage thousands of files in nested folders of website projects as well as Affinity Publisher documents in nested project folders, each with hundreds of linked asset files. And this also includes regular use of local network drives, external drives and sftp accounts for websites.
And many apps are now much more flexible in terms of opening and saving files in locations other than the default. It's not identical to the Mac Finder and there are occasional oddities but in my experience it is very capable. But it's nothing like what it was 10 years ago.
Contrast that to how iOS just generally leaves applications to "own" their own data and present them however makes most sense, with only a few exceptions (the most notable being the Photos app, which sorts and displays photos by things that make sense for photos). The place where you'll find the thing you were working on is actually just in the app where you were working on it, which is, unsurprisingly, far easier to explain. Plenty of people get on perfectly fine without knowing or caring about "files" and are not really worse off for it.
The format topic is also something that I see causing frustration, but it is not complicated to understand, as long as someone is familiar with the concept of incompatibility (screwdrivers, human languages, etc.)
In my opinion at this day and age is more an issue of “never needed to learn / cared to” than that of “it is difficult to learn”.
However—at least in my own experience—if you're carrying the keyboard/mouse/trackpad around with the iPad all the time, I found it robs the device of what makes it compelling to begin with (being ultraportable and handheld).
For a stint I was using an iPad Pro with the keyboard/trackpad case, and it made it a far worse tablet. The case almost doubled the total weight and thickness, which made using it much more like to a laptop, but it isn't nearly as capable as my MacBook (nor is it any cheaper).
More power to you if that setup works for you, but I came to the conclusion that I'd just assembled myself a second, worse laptop (which I think was OP's overall point).
If you're going to use the iPad with a keyboard, why not just use a laptop?
I suppose the use case here is iOS game developers who don't want to use their MacBooks, but iPad+keyboard doesn't seem like a fun way to write complex software to me.
But you gotta sell MacBooks AND iPads, amirite?
I remember at one of the Apple events Steve Jobs was saying the one area of complexity that still hung people up was the filesystem, so iOS (and as an extension, iPadOS) hid it away from the user. Files were locked to apps. As the platform evolved, people wanted/needed to operate in multiple apps with one file, so this concept of duplicating files in multiple apps came to be. This was a mess when it came to file versioning. It was also very difficult and confusing, and required apps to support it.
Eventually they added the Files app, but it is a very slow road to change over from an app based system to a file based system. Even today, it’s a crap shoot and some apps work better with the Files app than others, and it seems this aspect is still much more confusing than macOS from this perspective.
This was a huge miss that no one really talks about.
I do use it for development after a fashion (OpenSCAD, https://pythonscad.org/ and sometimes https://www.blockscad3d.com/editor/ or OpenSCAD Graph Editor, usually using TeXWorks for Literate Programming), but also for drawing/sketching and note-taking and annotating PDFs.
I was looking into tablets recently and there is a dearth of options - a quick search in a local eshop aggregator has ~20 2024 tablets after i filter out the sucky specs and ~72 2024 laptops (including some larger ones), again after filtering the sucky specs. Meanwhile there are ~276 2024 phones after sucky spec filtering and that is with greater specs than the tablet ones (because the aggregator had no filters matching the tablet specs - even the minimum specs in phones were higher than the high specs in tablets).
All these give me the impression that we're long past the hype days of tablets.
https://www.lincplustech.com/products/lincstudio-s1-drawing-...
(if I hadn't panicked and bought a spare Samsung Galaxy Book 3 Pro 360, I'd be trying one)
We don’t need to talk about the OS!
One way this could be addressed can be borrowed from video games: animated pie charts, growing as you hold down the button, activating the secondary function only after the pie completes a full circle.
https://developer.apple.com/app-store/review/guidelines/#2.5...
I believe this app would fall under this clause, much like apps like Pythonista and of course Swift Playgrounds (not that Apple even pretends to follow its own rules).
https://apps.apple.com/us/app/gdevelop-game-maker/id16636757...
I'd give my interest in Hell for Apple to develop HyperCard or AppleScript Studio for the iPad.
And for caring about the UX.
There’s obviously room for polish left but this looks so well thought out already.
I am interested in how this might find its way back to Godot proper. Would the team be willing to maintain not only one more target but also an entirely different UI frontend?
I am also curious if this could become the native macOS frontend. Even if that’s behind a compile time flag, that’s a very powerful option for accessibility.
Lastly, GPL incompatibility aside, I wonder if this could inspire a similar effort for Blender. Blender on iPad would be an amazing value addition.
https://godotengine.org/article/godot-engine-was-awarded-epi...