Re: [dev] mret

Hi and thanks for your comments.

> You are doing it wrong. Mixing code and data is one of the worst
> things you can do. Not only for security reasons.
[snip]
> Plan9 just disables all screen control stuff to just a serial
> communication channel. And all the graphical stuff is done on top of
> it using a different channel with a text based protoxol. Not
> executimg code, just using a simple api.

Yeah, I've considered creating a custom protocol. I think choosing to
speak Tcl directly was mostly the effect of my laziness. I'm lazy and
I love it.

And oh, just realized that as soon as you'd like to do remote work,
you either give up wishpipe or mret becomes one giant security hole.
So definitely it's not the way to go.

> Apart that depending on tcl/tk is somewhat sucky.

It's just an interactive mockup, a prototype, a testbed for ideas, not
meant for immediate consumption. But of course you're right. I just
asked myself if in 40 years I'd still like Tcl and Tk as an integral
part of my terminal.

BTW, earlier version ran on PyGtk :D

> If you want to make a decent ui design you cant expect programs
> designed in the 70's to work.

The only problem is with relying on features of 70's hardware.
Plan9's cat and Unix's cat still make the same "meow" sound.

BTW offtopic, anyone knows of a decend CLI music player that doesn't
use any freaking curses UI (like mpc/mpd) *AND* doesn't try to build a
database (like moc)? Like mh, but for tunes.

> The monster you wrote looks fun to see..

C'mon, at 200 SLOC it's smaller than Mike Wazowski.

> But I dont thunk is the way to go. Libdraw and swk are probably much
> suckless that this.. And the point is that things should be simpler.

Simpler? As in less than those 200 lines?

You know, as I said, the earlier version used PyGtk, and I'd stick
with it if it did provide the features that I wanted. Right now the
main problem is not the choice of a toolkit or language - I would
write it with C++/Qt or even Java/Swing if that'd be what I knew the
best. I had a few ideas and wanted to express them. Until I know what
to put in and what to leave out, I'm gonna stick with what is most
comfortable for me to use.

> But we need a way to describe interfaces in a nonlang/arch/backend
> specific way.

HTML? *ducks*

OK, and one serious question now. Do you think having a separate,
scriptable input buffer is better or worse than relying on every
interactive interpreter to handle its line editing by itself?

Thanks,
Kamil
Received on Wed May 25 2011 - 22:57:07 CEST