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

Ertugrul Söylemez ertesx at gmx.de
Tue Feb 10 18:48:24 CET 2015


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

I think there doesn't have to be semantic difference between closing a
window and dropping it into a virtual drawer.  Your short-term to-dos
would be elsewhere.


>> 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.

I'm very close to a bootable system.  Allow me to arrive there first,
then we can compare and exchange ideas and code.  I will definitely let
you know, because I'm interested in your way of doing it.

Publishing a working prototype works better for me.


>> 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.

Oh, that might happen of course.


>> [...] 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.

Sure, it is great for some things, but terrible for others.  The point
is that we don't get a choice.  Everything is designed around the "files
in directories" notion.  That's why an sqlite database is completely
opaque from the point of view of the operating system.  You need special
tools with a special UI to inspect databases.


>> My vision for software in general is what I call "organic software".
>> [...]
>> 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.

I find this topic very interesting.  I believe it needs to be discussed,
but this mailing list is probably not the right place to do it.  For
lack of a better place, feel free to write me off-list, if you would
like to discuss this further.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
Url : http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150210/68a84806/attachment.bin 


More information about the nix-dev mailing list