[Nix-dev] UI management (Was: Use Haskell for Shell Scripting)

[Michael Raskin]

>>> It's not that esoteric.  Think about the average 2013 laptop or PC
>>> with plenty of RAM.  When you're done with a certain task, you close
>>> its window, simply because you're used to that and perhaps because
>>> you draw a relationship to the physical world, where you prefer your
>>> desk to be clean and organised.
>>
>> Erm, some of the things need to know they should stop eating CPU
>> cycles and stop touching their esident working set — I do think that
>> my 8 GiBs of RAM are sometimes better used with more disk caching of
>> my active-in- brain tasks and not caching LibreOffice and
>> Firefox. Sometimes not.
>
>That's actually fairly easy to handle on Linux by using namespaces,
>sigstopping and sigconting.  There is probably also a way to force
>programs to go to swap by using cgroups.  Be patient, I'm still working
>on a DSL for this design. =)

I am not sure whether I have this, actually. 

Also, I sometimes tend to use closing unneeded windows as a way of 
keeping track of short-term TODO list.

>Unfortunately it entails removing systemd from the top of the process
>tree, which is a lot of work for a single person, but I'm highly
>motivated.  By the way, this is not my usual systemd hatred.  There are
>technical reasons to remove it from the top.

Will you share it already? I do have a bootable systemd-less system
based on NixPkgs, and would probably contribute some service definitions
to the thing you develop.

>>> So what's the solution?  Simple: Workspaces must be cheap, dynamic
>>> and extremely easy to manage.  There should not be a rigid mapping
>>> between workspaces and windows.  Windows should easily be able to
>>> belong to multiple workspaces.  A generalised xmonad could do it, but
>>> the current one can't.
>>
>> My experience says that moving towards your goal is a good idea w.r.t.
>> status quo, but halfway there you'll switch the direction.
>
>I'm not sure why.  This is not about a certain UX concept, but just
>about a window manager being sufficiently general that I could start to
>experiment.

Well, because what you said in that paragraph is close to what I tried
to do at some time, and there are hidden costs. When they become 
revealed (and they are different for different people, of course), you
will take the things you have by this time and change the direction of
development according to new data.

>> What is your vision and what is your experience on your way there?
>
>Wow, big question!  I'll try: It's twofold.
>
>A long time ago (≥ 13 years), little me was using Windows, and he always
>thought that there is something wrong with this concept of "windows on a
>desktop".  "Folders" felt unnatural, too.  Everything about my operating
>system tried to mimic the physical world.  I never really cared about
>learning curves, so I always asked myself what it would look like if we
>could use the potential of a virtual space to its full potential instead
>of locking ourselves up within the boundary of our own imagination
>("office work" means "sitting in front of a desk" to most people).
>
>A later me had already switched to Linux and discovered workspaces.  It
>was a minor improvement, because this time you have multiple virtual
>desks, so you had no reason to drop something on the floor (minimising).
>But it still felt wrong, and this feeling continues to this day.
>
>My vision for UX is that we move away from the physical world.  In the
>computer we can construct our own universe with the rules of physics
>constructed or bent to support the work we are doing, perhaps in a fun
>way.  Let's not think of the space on our screen as a virtual desk.
>It's a projection of a space that we programmers create, and we have
>complete freedom to create whatever we want!  In the same way I always
>thought that our filesystem concept is wrong.  There is no inherent
>reason to have "files in folders".  I believe that a disk should act
>more like a giant mutable variable.

At some point I saw RelFS and tried to use it for tagging files. Then
I hit its limitations and written my own QueryFS. Now I use it for many
things, but not for file tagging because hierarchical structure made it
simpler for me just to think in terms of hierarchy. 

So directory structure was a good idea for file storage, in my opinion.

>My vision for software in general is what I call "organic software".
>I'm actually writing an article about it, so let me just quote a few
>paragraphs of the section *Moronware* from that one:
>
>"View programs, especially interactive ones, as part of your team.
>Imagine that you have handwritten a bunch of documents that you would
>like me, your teammate, to review.  So you hand me a copy and I start
>reading.  Later that day you return to my office, and I'm just sitting
>there, doing nothing.  You ask what's wrong, and I point to one of the
>words in the document I were reading.  I simply couldn't decipher your
>handwriting, so I stopped and waited for your assistance instead of
>making a note and continuing.  Seems absurd, right?  No good teammate
>would do that.  That's true.  Our programs are probably not such good
>teammates.
>
>When humans act the way our programs do we like to call them morons.  We
>should do that with programs instead of humans.  They aren't self-aware
>beings (yet), so they won't be offended, and they really do act like
>morons.  I propose the term *moronware*.
>
>How can we write software that isn't moronware?  Good design and proper
>responses to exceptional circumstances can make our programs faster,
>more responsive, more flexible and less like untrained animals.  They
>make our programs *dependable* and in the end *trustworthy*, because we
>can feed tasks to our program and focus on other things or even just
>pick up a cup of coffee, because we *know* that it will do its best to
>complete as much as possible without our intervention."

Well, this vision is what I consider one of the problems of modern 
software development. It would be yet another tangent, though; do you
want to go in that direction? 

In short, I want (but don't yet know how to achieve in some cases) 
predictable transparent tools usable as IA in Engelbart speak, not 
DWIM helpers with wannabe-AI. 

I want tools that can be easily transparently wrapped to try to do as
much as possible or to stop at the first problem.