Older blog entries for lkcl (starting at number 682)

GUI Builder Panel

Pyjamas Equivalent of Glade goes recursive…

well, i decided that just having a dynamic GUI-instatiator based on a text file wasn't enough, but that what was needed was both a widget (single dynamic instance instantiator) and a panel (subclass of that but then with an "add" method that can take the name of the widget-group to be created).

so, the UI text file contains a widget-group with a panel type in it (e.g. a Grid) called "builderpanel", and it also contains a widget-group with a… something - a row, for example, named "builderrow" in the UI text file. also in the widget-group with the panel is a button, named "add".

then, the button has the name of a callback in the UI text file, called "onAddClicked", and this function has to occur in the app, and is linked to the button. surprise-surprise, the action associated with this button is to create an instance of builderrow and to add it to the panel:

    def onAddClicked(self, sender):
        grid = self.app.bp.getPanel()
        row = grid.getRowCount() + 1
        grid.resize(row, 1)
        self.app.bp.add("builderrow", row, 0)

the weird thing is that at no time, in any code written, do you actually get to see what "the panel" is, because its layout is specified in the UI text file. also, nor do you see, in "python code", any of the widgets that are added as a row: there could be 50 widgets in that "row" being added, but you don't manually create them.

i think that's just wicked, and although i was originally deeply unimpressed with the idea of writing widget layouts using an application editor, i'm now completely converted to the dark side and will pretty much be doing nothing _but_ writing pyjamas applications with this method from now on.

Syndicated 2010-08-23 20:57:46 from blog/lkcl

pyjamas dynamic in-app GUI builder

dynamic creation of pyjamas GUI apps

kees bos a few months ago developed PyJsGlade which is an identical concept to wxwidgets "wxg"; glade with GtkBuilder for pygtk and qtGui for pyqt4. the basic principle is that you have a GUI-based "widget editor" tool, you edit a nice pretty app, you save it (usually as XML) and then you either auto-generate the entire app as a stub starting-point or you pass the file into a "builder" at run-time and it creates the GUI there-and-then

in python-wxwidgets there is as i understand it a bit of a problem: there is no runtime builder, but other than that, everything's hunky-dory. pyjamas, being the newcomer here, didn't have PyJsGlade until a few months ago, and kees didn't quite grok the run-time builder concept. for various reasons, i added it yesterday. ok, this morning, to be precise.

for various other reasons i'm going to make some enhancements to the concept, to effectively turn the builder class into the beginnings of an editor front-end. in other words, if you have an existing instance (which you'd like to keep), and you modify the GUI file, you can *reapply* the builder process on the existing instance and have it update properties, change positions etc. etc. instead of throwing it away.

neat, huh?

Syndicated 2010-08-15 11:38:58 from blog/lkcl

HL7

just announced an HL7 python importer, which is going to be used in gnumed. HL7 is a data exchange format for the medical profession. typically used to transfer information about patients, treatments, clinical lab reports and so on, it's _very_ comprehensive and has been through five revisions on the XML HL7 v3 specification, already.

HL7 basically stores typed hierarchical information in a flat file. it was created before XML came around, and now someone's added an XML wrapper on top of it.

there's an application called Mirth and unfortunately it's implemented in java. it's _big_ and therefore painful. for example, if you want to do something other than what mirth can cope with by default, you have to create a java extension or, even worse, a javascript one! connect the dots, with python and gnumed (which uses postgresql) and if you want to use mirth to transfer clinical lab data into gnumed, you have to know _eight_ separate programming technologies.

so i decided to look for some existing code in python, and adapt it. seems to be going well.

moinmoin jsonrpc at europython2010

ok, as part of the series of transitions to python-based technology for pyjamas, i was looking to convert the wiki at some point. it turns out that the moinmoin developers are here at europython2010, so i picked their brains and they helped me create a JSONRPC interface to moinmoin 2.0-dev. with adding page create and page load, the job's pretty much done in 150 lines of code (hooray!).

so the next thing is to add in git support, and then the existing wiki (ikiwiki) miight be convertible to a full pyjamas app (hooray!)

Syndicated 2010-07-20 22:26:26 from blog/lkcl

multitask cooperative single-process http server

egads, mouthful for a subject let alone a title of a wiki page. for various reasons i needed to create a single-process cooperative multitasking HTTP server. it seems, bar one small tolerable bug, that i succeeded in using it to create a special kind of HTTP proxy.

the problem is illustrated by http://gnumed.org being a desktop-based application and using role-based access control on the PostgreSQL database. they want to convert it to a web application, by popular demand, and tried picking random web server frameworks. unfortunately, virtually all web server frameworks assume that the SQL database is to be used for anonymous session cookie management, assume a single (global) username/password and so on.

for gnumed, such assumptions are completely unacceptable: this is confidential patient data, and there's no way that gnumed are going to redesign the database middleware to REMOVE password security.

so i came up with something that will frighten the bejabbers out of any normal web developer: a proxy which is capable of keeping a remote connection permanently open to its upstream target, as long as that upstream HTTP server supports HTTP Connection "keep-alive".

it's… well, i've been yapping about it enough, and so have the gnumed developers: http://lists.gnu.org/archive/html/gnumed-devel/2010-07/msg00326.html

one of the problems with creating such a proxy is that you can't do it with a threaded or a forking architecture: you need to analyse the HTTP stream (check a session cookie and insert one if there isn't one) BEFORE you pass it on to the proxy, but most HTTP proxies are designed to fork first, think later.

the design also has several other uses, one of which is that it solves the issue that pyjamas-web faces. pyjamas-web is the version of pyjamas that actually executes a pyjamas app server-side and translates it into HTML. immediately you can see the problem, there, if you know that HTTP is stateless: how do you re-associate the actual in-memory running python application with the correct browser, when the application is sufficiently large that it is impractical to serialise it to disk?

Syndicated 2010-07-15 20:25:46 from blog/lkcl

mailing list transferred

hooray, another task done - sort-of. it appears that some messages were lost, leaving people wondering what the heck was going on, where's the "digest" mode (there isn't one in lamson, because zed always finds that people abuse it by replying "Re: Digest Volume 3.1415926")

had a bit of a fight with lamson: messages were bouncing from somewhere, causing multiple repeats i _cannot_ tell where from, so may end up fronting exim4 onto lamson despite my wishing not to do that. as i had to create a lists.pyjs.org, the problem with redirecting to a remote queue goes away (exim doesn't redirect to 127.0.0.1 properly, even if you change the SMTP port: there's supposed to be an option you can set to say "yes do it anyway" but…)

i'm getting people still saying "why are you doing this? why waste time reinventing mailing list software? why reinvent it with software that's _worse_ than [proprietary and] much better offerings? why not just use google groups" and i have to gently remind them - again - that their questions hold the answers: the alternatives are proprietary, and they're not pyjamas applications.

i stated that i'm going to uphold a principle - to use free software and to do pyjamas front-end apps - and to stop doing what i'm doing, even if it's "not as good right now" would be breaking that principle. i'm absolutely going to stick to my free-software-driven principles, because i can, and because i choose to, and that's really all there is to say.

if anyone wants to _help_ improve the software, now, they can. whereas, with the source code to groups.google.com, they can't. but we know this already: i just think people find it a bit unusual for someone to jump train _and_ "rip up the tracks" on a running project and start pumping on a cheap but 100% Cooperative-owned hand-driven railway cart, because they don't like the fact that the train and the carriages are all run by a big corporation.

i think… perhaps it's worthwhile mentioning the phrases "bitkeeper vs git" and "linus vs tridge" - not entirely accurate but i think you get the picture.

Syndicated 2010-07-06 15:43:11 from blog/lkcl

new mailing list almost done

ouch. lots done today. managed to delete pyjs.org apache config, had to recreate it. had to create lists.pyjs.org due to conflicts with WSGI apache configs, i am _not_ going to try doing rewrite rules. almost got lists.pyjs.org done: only need to do an email enable/disable feature and then i'm done: bye bye googlegroups.

Syndicated 2010-07-04 23:36:17 from blog/lkcl

great old hat

Django Piston

I found a great django framework extension, by virtue of accidentally searching for "django oauth":

http://bitbucket.org/jespern/django-piston/wiki/Documentation#oauth

If i didn't know pyjamas, I would be terribly excited by this extension. as it is, it's pretty good anyway (because of the json emitter for example, and the bandwidth throttling decorators).

but i find myself feeling… terribly sad, and strangely looking in pity on these excellent pieces of work, because they just look like so much damn hard work to make use of. generating pages server-side that mix data with the display mechanism is so… old! no matter how exciting and fresh the framework and the ideas and thought that goes into the framework, the technique is still "old" and inconvenient.

i feel very strange for having to point this out.

Syndicated 2010-07-04 10:46:33 from blog/lkcl

pyjamas lamson replacement for google groups

Pyjamas and Lamson Mailing list viewer and poster

as part of the "eat dogfood" mantra, and the lovely lamson mailing list software having been chosen, i did an archive viewer a couple of days ago, which used the json-formatted archive created by lamson, because that's far easier to pick up (and less cpu-intensive) and turn into python than a Maildir.

what was missing was the means to post messages.

so, in order to do that, i've had to add openid support to the pyjamas app. then, having got that to work, it was no good on its own so i had to add a way for lamson to send out "is this person who they claim to be" messages, by which the openid could be associated with the email address.

haven't added that into the GUI yet - have to add a "preferences" box. hmm…

anyway: that was quite a lot of fun, working out how to create a state machine in lamson. it took me hours to work out what was going on, but i now should also be able to turn lamson into a "proper" email service, by supporting simple relaying of postmaster@pyjs.org and so on to me, which lamson *doesn't* do on its own.

but then, the next step is to allow posting of messages. that proved also challenging: in the end i chose to use the lamson.server.Relay, connecting over 127.0.0.1 and faking up the "From" and "To".

there's still quite a bit to do, but once it gets to the "useable" state i'm simply going to chop pyjamas-dev googlegroups.com off at the knees. i'll add a reply button, i'll make sure there's a "compose" button… and… errr… attachments? nope. viewing attachments? nope. showing message "reply" threads? nnnope. well, ok, maybe. might have to see how that goes, see if it's easy to do.

about the only thing i migggght see if i can do is to add support for google oauth / openid, because most of the users duh being on googlegroups use google for authentication duh.

but - again, have to see how it goes: once a certain aaabsolute minimum threshold of functionality is achieved, it's bye bye google groups, and one less web site being used which is _not_ a pyjamas application goes out the window.

Syndicated 2010-07-03 22:46:46 from blog/lkcl

diary syndicated to advogato

The lovely Advogato

I like the fact that people can reply / discuss using ikiwiki, if they want to, whereas advogato has a single-stream of consciousness / diarrhoea. so i'm syndicating the pyjamas diary to there, let's see if it works…

Syndicated 2010-07-03 09:34:07 from blog/lkcl