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.


Reply via email to