inclemnet

I think the "traditional" family of tiling window managers (like ratpoison, awesome, dwm, xmonad, i3, etc) are kind of simplistic in their assumptions that 1. they can at any time force any window into any size and position, and 2. they must always force every window into some size and position.

Interestingly I like tiling window managers due to specifically the opposite perspective, that applications are often selfish in their assumption that they can display themselves wherever they like and I much prefer ignoring their (usually-wrong) assumptions about what's best. I don't mean that argumentatively, just a different preference I guess.

In this respect I even agree with the first two steps of your algorithm - it's just that "in my tiling layout" is the result of both of them!

It isn't dwm "port", rather it's an independent window manager with some inspiration from dwm but also from other places. Notably it doesn't share the minimalist design philosophy, it's designed with a powerful configuration and interaction api rather than relying on patches.

dwl[0] is closer to a port, it's explicitly trying to work the same as dwm for wayland with the same philosophy, although it's still an independent project written from scratch.

[0] https://github.com/djpohly/dwl

I've known people say that they found it "easier" combining learning touch typing with learning a new keyboard layout. It's harder moment by moment, but there's no bad muscle memory to fall back on.

Since various people are asking about xmonad-like tiling in wayland:

I wrote Vivarium[0] specifically to be a wayland compositor that behaves exactly like my (fairly simple) xmonad config, but it's a relatively new/unstable compositor and nothing like xmonad internally.

River[1] has a fantastic tiling model via user-provided executables, which makes it very flexible and probably a good fit for many people wanting something xmonad-like.

Waymonad[2] exists as a direct xmonad-like compositor, but I think development has been basically stalled for a long time. Sometimes there's discussion about reviving it though (edit: see https://news.ycombinator.com/item?id=28796909 for more up to date detail).

Japokwm[3] is another compositor with xmonad user roots, but again its own tiling model.

[0] https://github.com/inclement/vivarium

[1] https://github.com/ifreund/river

[2] https://github.com/waymonad/waymonad

[3] https://github.com/werererer/japokwm

But for the rest of us, the pre AI strategy is often better because we can't handle the complexity.

It is common to see casual players copying the AI style and digging their own grave while doing so.

I think this point is greatly overstated. Amateur go style has always been modelled on professional play even though amateurs have no idea of the subtleties of it, and this was rarely bemoaned much in the past. It's easy to find examples of amateur players getting it wrong and turning a slightly-good position into a bad one, but this is true of just about anything and I think there's a lot of confirmation bias in associating it with AI moves in particular - it doesn't in itself mean they've disadvantaged themselves by trying.

It also greatly overstates how bad it is to play the 3-3 early and not fight aggressively. Even if you don't worry about the fighting variations we're talking about a small number of points, much less than amateur games tend to swing via mistakes every few moves. This is also true about those professional-like lines that have always been mimicked but played imperfectly, and is probably a big reason the lack of amateur understanding of them never mattered too much. Plus let's not forget that both amateur players in the game are relatively bad at fighting, it's just about as hard for the defensive player to really get it right as for the offensive player to utilise their theoretical advantage.

Overall I think the modern focus on AI-like play is much more of a fashion in line with other general shifts following what's professionally popular than a mistake. Players do pay attention to how well they do and associate it with specific moves and lines they recognise they don't understand well, but AI-inspired lines don't seem to have attracted any widespread cautiousness.

Then came AI and it found out, given enough fighting power, it can mostly cancel that later game advantage.

Also worth noting that the AIs play the 3-3 invasion in a specific different way to what was the accepted human pattern, and this alone does make a big but understandable difference to how the shape commonly continues. It isn't that they only turned around the evaluation of the standard position through superhuman reading, they revealed a line that humans had undervalued but could then learn from.

Sway (the Wayland fork of I3)

Minor clarification: Sway is an i3-compatible wayland compositor written from scratch, not a fork.

If there was one thing I could wish to be revamped about Kivy it's the default widgets. There's a core of good ones, especially those that are most commonly used, but quite a few make bad design decisions like an over-reliance on images for styling. This is often much easier to work around than is probably obvious and maybe that's part of the problem, more experienced developers likely habitually sidestep the parts that don't work well. But on the other hand, it's quite a bit of work to revamp them (including documentation and dealing somehow with breaking changes it would introduce), unfortunately that has kept us from seriously addressing it so far.

The question is, who actually uses these projects? The people developing them? Hobbyists? Language diehards?

This is an interesting question, and one that (as Kivy developers) we wonder about ourselves. Others may have different perspectives, but mine is:

* Kivy is very much community built and community driven, it has no serious financial backing (though we are grateful for the donations we do get!) and a fairly small developer pool.

* Most of the commercial use of Kivy that I'm aware of is small companies using it for specific reasons that happen to make sense for them, usually involving some technical reason such as the combination of Python and a flexible drawing toolkit fitting both their dev interests and product requirements. I don't think there is a lot of commercial use, but e.g. one of the Kivy founders has been using Kivy commercially for many years in a variety of interesting projects.

* Kivy is not mobile-only or even mobile-focused, and the commercial usage reflects that. This is worth noting because people often think it was invented for mobile: it wasn't, it was invented to be very flexible, and this happened to make it mobile-ready.

* Most use of Kivy is probably from Python hobbyists, and may well be more weighted towards mobile since that's the most obvious standout feature as a Python gui toolkit (although not the only one).

I've been involved with Kivy for a long time, but never commercially - I got into it for fun while looking to make an app and strugging with an android development tutorial (turns out the instructions were just wrong for Linux...), and stayed with it for also fun. I'm most interested in the general principle that app development ought to be simple and easy for a wide range of tasks, and that in pursuit of this goal it does not have to be perfect. I like the idea that e.g. someone who has programmed a simple game or visualisation should be able to easily share it with their friends, on any platform including mobile. This is just my perspective of course, others do use it for other things.

I have a couple of my own apps that I think emphasise this perspective. Lazy Baduk (https://play.google.com/store/apps/details?id=net.inclem.laz...) is a Go analysis tool that bundles a superhuman AI: I threw it together in a weekend using some existing Python code I had lying around, because there was no Android app currently supporting the functionality I wanted. If I couldn't do that with Python, the app simply wouldn't exist. ColourBlind (https://play.google.com/store/apps/details?id=net.inclem.col...) runs the camera feed through a basic colour blindness simulation filter, I made this one just because I wanted to see what it was like and all the existing apps I could find were rubbish (in my opinion!). Even with the limitations of Python, I like mine much better than them.

As has already been said, Kivy isn't a web framework, but we're well aware the website isn't great. Unfortunately it hasn't had much love for a long time, especially as it's quite a task to seriously change it and we're both under-resourced and Python-oriented. We've been talking about various options for a long time. It's possible we might make some moves now as Kivy 2.0 was just recently released, which was a major update taking up a lot of focus.

I guess though I did find the idea of using pygame just for SDL to be kind of... blunt

Yeah, I think this was a pragmatic choice (it was before I was involved at all), but it was never that great. SDL2 has solved a lot of problems and is much easier to support.

I was actually thinking of Renpy or python-for-android.

python-for-android is Kivy's own Android build tool, which nowadays is a separate project. It supports multiple backends, but doesn't really support pygame except as a Kivy backend (which is not maintained much any more). It does support SDL2, so you can use e.g. PySDL2 to make Android apps.

I think Renpy also moved to SDL2, probably also due to issues supporting Pygame, although last I checked they use a fork of Kivy's older python-for-android toolchain.

Like how they were (didn't check if they still are) using pygame to interface with SDL to do rendering a lot of other things.

Kivy only ever used Pygame for SDL's backend management, drawing has always used OpenGL. We actually no longer use Pygame by default, having moved instead to SDL2. There are also alternative backends for almost everything, e.g. a direct X11 window backend on Linux, or the rpi window backend that does not require X.

I've seen other projects that used pygame on mobile devices that were able to do it without all of the extra complexity that Kivy layers on

Do you have any examples? I'm aware of almost none, or any active build tools for Pygame. I've been wondering if the best way to use Pygame on Android would be via pygame_sdl2 using Renpy or python-for-android, but it would be nice to find an alternative.

all of the extra complexity that Kivy layers on. Pygame isn't that hard to use, so if I know how to use it, why would I use Kivy?

I'm not sure what is meant by 'extra complexity' unless you're referring to Kivy itself being an extra module to install. Kivy isn't a Pygame wrapper, but its own toolkit with a very different, OpenGL based drawing API. It's probably also more performant, especially when optimised (e.g. KivEnt http://kivent.org/). Even ignoring performance etc., you'd want to use Kivy if you just prefer how it works (but you don't have to feel that way).

Beyond this, Kivy doesn't just have the graphics API but an entire widget toolkit. It also directly supports both Android and iOS, although as above perhaps I'm not aware of current Pygame efforts.

We've actually completely rewritten python-for-android since then, it now supports multiple bootstraps and is not tied to Kivy at all, and it should be relatively easy to use the python distribution in a native app (although this could be streamlined).

CrystaX's support is great though, and actually python-for-android uses this for Python 3 builds.

Kivy actually is completely optional, python-for-android doesn't require any particular frontend. The main supported options for guis other than Kivy are SDL2 (you can use e.g. PySDL2) or a webview, but it's designed to be easy to add more options.

but since it has evolved from a game engine,

Just to note, Kivy didn't evolve from a game engine, it began as PyMT (of which it's a spiritual successor) which was a gui toolkit targeting multitouch and NUI. In fact, the support for Android and iOS came later, and they work because the original design of the toolkit, with flexible backend providers and an opengl interface, did work out well for cross-platform use.

I think it's still generally the case that Kivy apps tend to use the default (clunky) theme or something more custom, but there has recently been some user activity around alternatives, e.g. a set material design themed widgets (https://github.com/kivymd/KivyMD). I'm not sure if any apps using this have been published on the Play store.

We've been discussing how to include more unified themeing capabilities in Kivy itself, ideally as a big new feature in the upcoming 2.0 release.

Edit: I wrote a post at http://inclem.net/2016/01/15/kivy/kivy_android_app_showcase/ about some of the best published Kivy apps including themeing considerations, although they don't aim for a standard Android UI either. I see in your edit you've already seen this though.

I'm not aware of anyone having succeeded with Jython - I think there are technical issues but I'm not sure what's the nature of the problem.

One option for interacting with java from python is to use tools like pyjnius (http://pyjnius.readthedocs.org/en/latest/) - this is what e.g. Kivy does to get system information like screen metrics.

Python indeed runs fine on Android once you can get it to compile (the interpreter needs to be patched to compile with bionic, or can be compiled without patches using the CrystaX NDK). The Kivy graphical framework has the associated python-for-android project [1] taking care of doing this plus including other components like Python modules (including complex ones like numpy) and can compile with different kinds of backend (not just Kivy). There are also other projects running Python on Android in different ways.

[1] https://github.com/kivy/python-for-android

Actually this was exactly my thinking when I wrote it, but having read this thread I'll certainly try to have some clearer introduction on every page.

It's been a long time coming, but I expect to merge python3 support into python-for-android within the next couple of days. I'll make an announcement about it at the time.

As a Kivy dev, I've thought about it before on the desktop (it's come up before and a gsoc student did some preliminary investigation for the best way to do it), but I'll admit I didn't realise the implications on Android where actually this support might be harder due to the mismatch with the normal java widget mechanisms. I do think it's important and will try to take a look at it, but it's certainly true for now that Kivy does not have much support for standard accessibility tools, probably particularly on android and ios.

It works fine, and includes things like the ability to access the Android API (with pyjnius and plyer) but there are some problems that are difficult or impossible to fix. In some cases these aren't important or you can just not care, in others they are an issue.

The major ones that come up are:

- Relatively large APKs, minimum size is about 7MB due to the size of the included python interpreter.

- Non-native widgets, Kivy draws its own widgets using OpenGL. They're quite customisable, but of course you never get behaviour quite like the native ones.

- App startup time. This is down to about a second on newer devices, but on older ones (or if the app does inefficient things before starting up) can be quite a bit longer, especially on the first run when some unpacking is performed.

I've seen some nice examples recently of apps that do a good job with Kivy itself (e.g. demonstrating more themeing than most and using android api functionality), like Kognitivo [1] and Barly [2]. I think these do a good job of showing what Kivy can do in practice. Used the right way it's also very performant for e.g. games (the low level graphics api is a cython layer over opengl), especially with the ability to add your own cython and use libraries like chipmunk. A good example for this is Boardz [3], which uses the Kivent game engine for Kivy [4].

[1] https://play.google.com/store/apps/details?id=org.kognitivo....

[2] https://play.google.com/store/apps/details?id=org.topbanana....

[3] https://play.google.com/store/apps/details?id=org.chozabu.bo...

[4] http://kivent.org/

I don't understand why scientists first pick a journal that takes their rights to their paper away and then offer it for free via "secret codes". Seems to me they are supporting the current, closed system.

The reason is that a scientist not doing this would (rightly or wrongly) have fewer publications in the 'best' journals as considered by the rest of their field and by impact and citation measurements, would therefore be less well known and well cited, and would struggle more to succeed. This is wrong and bad and so on, but it's probably widely true.

The documentation at https://docs.python.org/3/library/functions.html#locals doesn't indicate that locals is not part of the language - where is it documented that using it is a hack and that python implementations need not support it?

This is a simple example that does seem more readable (though it also would be if you explicitly added the value=value), but I think the concerns people have are about more complex examples, and the fact that readability is also impacted if allowing arbitrary code within strings themselves.

If you don't like using the empty {} (which seems fair enough), you can already use a couple of slightly more verbose but more explicit options:

    "{value} of very long text here...".format(**locals)

    "{value} of very long text here...".format(value=value)

It takes thinking to learn to use editors like this. Actually using them requires little to no thought after an acclimatisation period. This is one of the points of the article.

I've seen these arguments before, but find them very unconvincing. I've no idea how I'm supposed to comfortably press ctrl with my palm, the issues with 'now hotkeys are in bad places' are resolved by just not having capslock at all (although I don't actually have any difficulty pressing anything either way), and the pinky load/awkwardness just doesn't seem that important to me, I don't think the keyboard is particularly well calibrated to use the pinkys appropriately anyway.

I'm happy for some people to find these things important and type differently, but what is the evidence that it is actively wrong to bind caps-lock as ctrl?

Edit: There are a lot of good points in these pages and I appreciate that the author has made many customisations in pursuit of an ideal layout, and the principle of sharing load between hands equally is a good one. It's just that I'm quite unconvinced that having capslock act as ctrl is a terrible thing, especially compared to many other changes that can be made even on a normal keyboard layout.

You can change the keyboard in the settings panel. Apparently both colemak and dvorak are supported.

Ah, thanks. I suspect this is a bug related to the transition to sdl2, though I'm not sure what makes it present (it doesn't happen to everyone's android build).

If you're interested, one thing to try is (if you're using buildozer) to put 'kivy==master' in the requirements line instead of just 'kivy'. This will download the master branch, which may have a fix for this.

It not that, it's probably an issue somewhere in the python-for-android/buildozer build process, so that log would be the most interesting. If you're able to provide it that would be great, but thanks either way for reporting it.

You shouldn't in principle need to worry about the difference between the sdl2 and pygame/sdl backends on Android, since kivy's own API is the same in either case.

You don't need to install pil either (kivy preferentially uses other providers), unless directly using it in your own code, in which case you can include it in the android build by adding it to the python-for-android modules string or buildozer requirements line (just 'pil', this is the name of an internal recipe). If you have a window and text provider problem on android, that indicates that something is wrong with the android build, and we can help to debug if you provide the logs. I'm not sure offhand what problem would allow the android build to complete but give this error, but it would probably be revealed in the log.

This looks really cool, thanks for sharing it. I've seen this kind of idea talked about many times, but never any implementation, and even if at an early stage there's clearly a lot of effort in your basic structure and api (edit: and docs!).