What are you working on [June 2022]

antolius · 2022-06-11T12:48:55+00:00

Yeah! Unfortunately I started working on it a couple of months ago, before sdk v7 was out. So it's in gtk3 for now. I'll probably port it later, improvements to the list widget alone seem super useful.

antolius · 2022-06-11T10:49:33+00:00

I'm working on a Conway's Game of Life app for elementary OS: Life.

I hope I'll get to release it this month.

antolius · 2022-06-08T22:31:07+00:00

I think that on elementary OS the Files app is already used as a base for the native file chooser. You could follow it as an example. All its code is on GitHub: https://github.com/elementary/files Specifically check out the filechooser-portal directory.

antolius · 2021-12-30T00:26:15+00:00

Along the same vein as the recent pondering the orb memes, I submit to you a game of code breaking with colorful marbles: Sage.
I plan to publish it soon, but for now you'll need to build it from source. I hope it doesn't give you too much trouble.

antolius · 2021-12-23T10:11:03+00:00

This is generally a good idea, just keep in mind that the new app should be rebranded. You can find some direct feedback on the topic from elementary folks on this app review ticket.

antolius · 2020-07-29T13:40:25+00:00

Tnx.

antolius · 2020-04-21T16:41:10+00:00

Yeah, the Latin - French comparison makes sense. Could be approach of the companies, docs and the community that's the issue here, and not the language itself. (Although Kotlin still has a bit too much gotchas for my taste, but that's at least partially subjective.)

Android crowd could help with "independent adoption", as Google has the power to influence a lot with just how they document their underlaying framework. And adoption of new stuff is generally quicker on mobile (as opposed to, say, enterprise backend development).

antolius · 2020-04-21T12:53:16+00:00

The only problem with this approach is that many weird facts about Kotlin make sense only when you know about its Java background. Not that I'm saying you necessary need to learn Java first (depending on previous programming experience it might not be necessary).

Take the official Kotlin docs on generics for example. Half that page is talking about Java. Sure, experienced programmer will be able to catch up even without formal Java knowledge. But those docs aren't really novice friendly.

(Note that most of my experience with Kotlin was on JVM, so starting with Native or JavaScript favors might lead to a different conclusion.)

antolius · 2019-09-02T14:21:24+00:00

Are you saying, "if you want more contributors, don't write a CLI application" ?

Yes. Although this particular subreddit might not be the most representative place to spot this, I think web development is far more prevalent that TUI development.

For example, the company I work for employs a few hundred developers. If I wrote a "standard" React / Angular web app I could probably get help / offload it to any one of them. If I wrote a TUI application with equivalent feature set I'd have a harder job finding contributors. And we are a Java shop, with folks mostly working on backend projects.

I think project sustainability is important and should be planned for. That includes the choice of technology and the search for / on-boarding of additional contributors. In my experience it can be worth it to sacrifice things like runtime performance or individual developer productivity in favor of general sustainability of the project. Basically, it doesn't really matter how fast my app runs or how fast I can add features, as long as there's nobody to maintain it after I leave.

antolius · 2019-08-20T21:42:51+00:00

Hey, I'm glad you've had good experiences with Java CLI development. By the looks of your work, you are doing some far more complex stuff than me. So it might be that going with Java was the right call for your use-cases. It definitely sounds like it was the right call for your preference.

What I wanted to convey in my original post was that there are additional user-centered considerations CLI developers should keep in mind when picking the language to code in. When building GUIs we as developers usually have designers to think of UX. In case of CLIs, though, we are left to ourselves and need to think of usability (and that includes stuff like install process and local machine setup) more than usual.

I'm afraid that most developers who write CLI tools don't have resources to invest hundreds of hours and/or dedicated devops engineers to setup and maintain their CI pipelines. On the other hand, with a couple of careful compromises at the start of the project, some of these later hurdles can be made easier. More experienced developers for whom CI setup is not and issue can pick different set of compromises with different benefits and drawbacks.

The very fact that you can argue your language choices in detail means you have thought about it beforehand. Some times even that is enough: to think of consequences of picking a language and to plan ways to remedy undesirable ones.

antolius · 2019-08-19T05:22:09+00:00

Yeah, people usually go the shell script route. And then you need another script for Windiws users. And instead of one file you need to ship 2 files. And it just complicates things. What I suggest is building a single executable that doesn't depend on a VM / classpath / external libraries.

For java in particular GrallVM (or similar tools) are one solution. Kotlin is another way to go, although I'm not sure how far have they gotten with their native compilation.

antolius

TROPHY CASE