Skip to main content

Ralsina.Me — Roberto Alsina's website

Posts about kde (old posts, page 15)

Data aware widgets in KDE

Well, read­ing in plan­etkde about how nice da­ta aware wid­gets would be, I have to say this:

  • Da­­ta aware wid­gets are great

  • Da­­ta aware wid­gets in C++ are not the best pos­si­ble so­lu­­tion

Us­ing a high­er lev­el lan­guage, and specif­i­cal­ly a more dy­nam­ic lan­guage makes lots of things much sim­pler.

As a tiny, lame ex­am­ple, please check the lit­tle thing I wrote about da­ta aware wid­gets in python here.

I am sure that some of our bet­ter pro­gram­mers (or more cre­ative thinker­s) can come up with awe­some stuff if they di­vorce from C++ in this sub­ject :-)

Pissed off at SSH

Ok, not re­al­ly, since SSH has made my life much sim­pler than it would be oth­er­wise, but re­al­ly, it has some us­abil­i­ty is­sues.

And I mean re­al us­abil­i­ty is­sues, not the usu­al crap.

  • It can't be in­­te­­grat­ed in­­­to kde­wal­let

While there is a mech­a­nism to have a GUI ask­ing the pass­word, this helper app (askpass) does­n't get any ses­sion in­fo, so it's mean­ing­less, un­les you are try­ing to di­rect­ly start a X app over ssh.

Which you prob­a­bly aren't.

  • Fin­ger­print man­age­­ment suck­­s.

Sup­pose you have a fire­wal­l. You keep port 22 as a way to log in­to it, and for­ward port 23 to a mail serv­er in the DMZ. Well, it will com­plain and print huge, scary warn­ings each time you lo­gin in­to one or the oth­er, de­pend­ing on which one you used first.

Or, it can sim­ply refuse to con­nec­t.

And that's just the easy two.

What can be done?

  • Take the drop­bear client (not openssh, drop­bear code seems sim­­pler), and put a put­­ty-­­like UI in­­­to it. Use the kon­­sole kpart for dis­­­play.

  • Take the GTK ver­­sion of Put­­ty and hack it in­­­to KDE shape, put kde­wal­let in it. I don't quite like the idea of hav­ing a sea­­parate, dif­fer­­ent ter­mi­­nal app for re­­mote ses­­sion­s.

I would prob­a­bly go the drop­bear route if:

  1. I had a work­ing PyKDE (maybe some­­day)

  2. The idea of delv­ing in­­­to some­one else's C code did­n't make me nau­seous. (prob­a­bly af­ter I sur­gi­­cal­­ly re­­move my sense of taste).

KDE at Software Libre2005

I will be speak­ing at the Soft­ware Li­bre 2005 even­t, June 7 at 2P­M, at the Sher­a­ton Re­tiro, Buenos Aires.

I'd in­vite ev­ery­one, but it costs some mon­ey, so I will just say that I prom­ise to buy a beer for ev­ery­one men­tion­ing this blog. (Lim­it 10 beer­s, on­ly na­tion­al ones al­lowed)

For more in­fo, click on "read more"


Voy a dar una char­la en Soft­ware Li­bre 2005, el 7 de Ju­nio a las 14 ho­ras, en el Sher­a­ton Re­tiro, Buenos Aires.

In­vi­taria a to­do el mundo, pero cues­ta dinero, asi que so­la­mente los in­vi­to con una cerveza si men­cio­nan es­ta pag­i­na. (Lim­ite 10 cerveza­s, so­lo na­cionales)

Para mas datos, click en "Read more"

Linux: a not-unix-like OS.

Well, I am still ex­per­i­ment­ing with my con­cep­t-dis­tro.

I am now up to a run­ning PyQt us­ing uClibc, which I thought un­like­ly ;-)

I com­plete­ly re­moved all the sysv init stuff, and re­placed it with runit, which has an in­ter­est­ing ef­fec­t:

It boots to a graph­i­cal lo­gin in about 15 sec­ond­s. In­side qe­mu. In a 900Mhz duron. In­clud­ing ker­nel load­ing.

Of course the trick is that you have the lo­gin while stuff is still load­ing, but I am work­ing on that, too.

Since us­ing runit it's pret­ty sim­ple to get a over­view of where the boot­ing process is (ser­vices have de­pen­den­cies, they sim­ply get start­ed in or­der, and in par­al­lel), I will hack a sys­tem-wide ksplash-­like thing on a side of the xdm (prob­a­bly will end up writ­ing my own what­everd­m).

Think of it as Fe­do­ra's rhg­b, on­ly you can lo­gin in­stead of get­ting bored.

I al­so switched to a root-free sys­tem Ubun­tu style. Not de­cid­ed yet on it, but it's not hard to do (or use).

Next step: hack Knop­pix HW-de­tec­tion script (or rather re­write them in a re­al lan­guage).

I un­der­stand why there are 743 Lin­ux dis­tros. It's quite a lot of fun to hack one to­geth­er.

Oh, and it needs a name. It's not go­ing to be use­ful for any­one, it's just a per­son­al toy, but it needs one.

Come on, Plan­etkde guys, throw me names for a non-u­nix like lin­ux, if you dare ;-)

Source-based distributions, the good side.

I am no fan of source-based dis­tri­bu­tion­s. I think that for most prac­ti­cal pur­pos­es, a dis­tri­bu­tion where in­stalling KDE takes over a day (I own a low­ly Duron as my fast com­put­er) is use­less.

How­ev­er, they are good for one par­tic­u­lar niche.

Cus­tom dis­tri­bu­tion­s. Weird dis­tri­bu­tion­s. Per­son­al dis­tri­bu­tion­s.

I have sev­er­al com­put­er­s. Most of them too slow and small.

As I was con­sid­er­ing re­in­stalling Lin­ux on my Li­bret­to for fun, I looked at what was in­stalled in it, and de­cid­ed that re­al­ly, 90% of it was of no use what­so­ev­er.

The prob­lem was, since it had De­bian in­stalled, it has a rather wide net­work of de­pen­den­cies that sim­ply could not be done with­out.

On a reg­u­lar com­put­er, that's not an is­sue, but in this tiny workhorse, with 16MB of RAM and a 800MB HD, it makes a lot of dif­fer­ence. The small­est I could get De­bian to be, and still have net­work, PCM­CIA and X11, was about 250M­B.

And the per­for­mance was not awe­some, ei­ther (but not ter­ri­ble).

So, what would hap­pen if in­stead of a reg­u­lar dis­tri­bu­tion it had some­thing like this:

  • uClibc in­­stead of glibc

  • runit in­­stead of SYSVinit

  • drop­bear in­­stead of OpenSSH

  • X built as kdrive (former­­ly tinyX)

  • python/qt (or maybe python/fltk) for ba­sic ad­min tools

And so on. Ba­si­cal­ly re­jig­ger the whole soft­ware se­lec­tion slant­ing it to­wards the small side, and drop­ping a bazil­lion non-­fun­da­men­tal de­pen­den­cies along the way.

Well, it can be done. It's just that it's a heck of a lot of work. But here, a source-based dis­tri­bu­tion gives you a head­start.

For ex­am­ple, I de­cid­ed to start from ucrux, a uClibc-based port of Crux. Since the na­tive toolchain in ucrux is uClibc, I don't have to wor­ry much about a whole class of mess that hap­pens when you build uClibc-based bi­na­ries on a glibc-based sys­tem (it's prac­ti­cal­ly cross-­com­pil­ing).

Qe­mu lets me in­stall ucrux and work on it some­what faster than on the tar­get P75 (if I could make KQE­mu work I'd be hap­pi­est).

Since crux's soft­ware pack­ag­ing mech­a­nism is sim­plic­i­ty it­self (a shell script that in­stalls to a fake root), al­though it's se­vere­ly un­der­pow­ered (no de­pen­den­cies), I can start from ucrux, hack the build of one pack­age at a time, then put ev­ery­thing on a CD very quick­ly.

So, if you want to hack your own dis­tri­bu­tion, Crux (or some oth­er sim­i­lar kit) is quite a nice thing.

For gen­er­al use... well, my re­quire­ments start at ap­t-get or equiv­a­lent ;-)

Now, if on­ly Tiny­CC worked for more pro­gram­s, that P75 would be a pock­et de­vel­op­ment pow­er­house!