Update roll-up on my arsd libraries

[Adam D. Ruppe via Digitalmars-d-announce]

On Thursday, 13 April 2017 at 18:11:10 UTC, H. S. Teoh wrote:
> Hooray!  Finally!  Maybe now I can play videos over SSH (albeit
> ultra-pixelated). :-P

Hah.... though actually, my terminal emulator has support for 
outputting png images...

But truth is, this is one reason why I prefer things like 
`attach` or the new simpledisplay feature to VNC and the like - I 
can then combine programs from different computers on one 
desktop. So if I do need to play videos, I get them in the 
compressed format over whatever link and play them locally on the 
laptop.

I rarely run browsers remotely, even though sometimes I wish I 
could just because the local one tends to be much easier to use.


> And on that note, I've been playing around with my own 
> range-like abstractions over Terminal (variously called Display 
> or Canvas), that lets you treat rectangular subsets of the 
> Terminal as sub-terminals in their own right (as least as far 
> as output is concerned).

Nice. I actually thought about doing something like that 
(basically nested ScrollbackBuffers with a nicer api) too, but 
haven't gotten around to it yet.

> Now *this* really caught my eye.  I'm gonna hafta check it out 
> just for this feature alone.  It has always annoyed me that 
> although such a thing has always been *possible* for a 
> network-oriented GUI protocol like X11, hardly any programs (if 
> at all!) are written in a way that would work this way.


Indeed. So the way it works right now is there's an 
XDisconnectException that is thrown. If you want to recover, you 
must catch it OUTSIDE the event loop, then adjust the display 
string if appropriate and run 
XDisplayConnection.discardAndRecreate. If it succeeds, you can 
reenter your event loop and pick up where you left off.

Any X resources you had may need to be recreated. The library 
will automatically handle things it has inside (SimpleWindow 
right now, I'll add support to the other classes soon) but if you 
go outside it, you might have to do it yourself.

Server-side fonts, in particular, may need attention because they 
might no longer be available. But I might automate that too (keep 
a list of fallbacks inside the class).

Well, anyway, the big point is it isn't 100% automatic, you do 
need to catch the exception, possibly fix some stuff, and 
reconnect, but it is almost automatic; in simple apps, it is as 
simple as `catch(...) discardAndRecreate(); loopAgain;`

But it DOES work! :P

> Awesome!!!  I always hated those bulky toolkit libraries that 
> includes everything and the kitchen sink -- 90% of which you 
> don't actually need in your application, which usually means 
> you have a ton of dependencies that aren't actually necessary 
> and library dependency hell when you ship your binaries.

Yeah, I avoid distributing most programs because I can't stand 
having 20 MB + of stuff and the poor users have to manage that 
crap. Gah.

And I avoid *compiling* most gui programs because that's a huge 
pain too. But not with minigui, you've used my libs, you know how 
it is

dmd yourapp.d minigui simpledisplay color

Boom, it works. There's a few tweaks you can do, you might want 
some of the optional add on modules (which I am keeping each one 
strictly independent - they are not allowed to import each other 
to keep that decoupled), but the basic of it is right there.

And it builds in a fraction of a second. No meta-object compiler, 
no bindings generation, no dlls. And the generated file can be as 
small as 200 KB if you strip it right, though my test programs 
tend to hover closer to 600 on Windows, ~800 on Linux. I can 
handle that a lot easier than 20,000 KB.

Adding widgets is just newing the class. The automatic layout is 
usually ok. Custom widgets? Just subclass (actually until 
yesterday, it was all done via delegates, but subclassing is 
actually a bit easier, thanks D's anonymous classes) and 
implement paint and events. Again, no multiple files to generate 
and compile.


> I think we could write a killer app on top of this.  Say a 
> terminal that travels with you wherever you go -- migratable 
> from desktop to laptop on wifi and back, perhaps even to/from 
> your

Actually, I already have that: `attach` in the terminal emulator 
repo (it is similar to GNU screen, just my style, including 
things like scrollback, window icons, mouse support, and more).

My "IDE" tends to be an attach session running everything I want 
in the terminal tabs and I grab them by name when moving around.

That's the big reason why I have spent more time on terminal.d 
than minigui.d until now: my terminal sessions follow me on the 
laptop and such, so I wrote a LOT of terminal programs. But now, 
I can do GUI too! So we'll see how it goes.

The one problem I have with a quick migration is that the gui one 
is still somewhat bandwidth inefficient. Just rolling your mouse 
over a window generates several KB of network traffic. On a real 
connection... no big deal, but sometimes I use my laptop on a 
mobile metered connection, and I pay by the kilobyte there.

The good news though is I should be able to optimize that. I'll 
keep the api being fat by default, but have the ability to turn 
off mouse motion reporting on demand, and will optimize the 
redraws and atom querying and others (that's a reason why the 
styles are so simple btw, other people transfer big pngs over, I 
transfer over small XDrawRectangle packets).


> just resume in exactly the same state you left it on the 
> previous device.  Or ping-pong a terminal window between you 
> and a colleague for instantaneous collaboration.  Best of all, 
> the programmers only need to put in minimal effort to support 
> it.

Indeed.