Older blog entries for mathrick (starting at number 28)

24 Oct 2004 (updated 24 Oct 2004 at 18:03 UTC) »

haruspex: *bzzzzzt*, wrong. It’s easy to wish for one, but imagining working, cross platform UI is not easy. It’s actually impossible, since every platform has its own UI, and that’s the thing users notice first. Pretending there aren’t any quirks involved in UI is cheating on yourself – UIs are almost exclusively platform specific quirks. Do I use wizards or not? Tab view or list or buttons? Button order A or B? Instant apply or explicit apply? DnD or dialogs? How to present preferences? Does platform use box model or fixed widget positioning? Are widgets themeable? Is widget set closed or extendable? Are there common dialogs for X? Does platform have Tree widget ready available or not? How are icons styled? What color palette to use? Do I use icons at all? And so on, ad infinitum.

Each of these questions you need to answer, and you can be sure you’ll get every possible answer, depending on target platform. TAINTACPUI – There Ain’t No Such Thing As Cross-Platform UI.

22 Oct 2004 (updated 22 Oct 2004 at 22:38 UTC) »
Leave The Dead To Bury The Dead

djcb: you’re falling into the same pit as Bonobo did, falling into pit created by CORBA. Bonobo & CORBA are both dead in the water, they seem like oh-so-good idea, but in the end it’s tar-pit. They both make the same basic mistake: doing everything and trying to be the be-all-end-all. We have that saying, “if somethings universal, it’s useless", although it sounds way better in Polish :).

Take CORBA for example – what exactly is that beast? IPC? But then, it’s awfully complicated, it has uber-generic GIOP protocol, which is then concretized into still needlessly generic IIOP, only over which CORBA IPC happens. Too bad that (to my knowledge) noone really implements full GIOP or IIOP, so you’re left with common enough subset instead.

So maybe CORBA is type system? Then, it’s very cumbersome (requires really high level language to hide all the complexities of it) to use, drags in useless IPC cruft and is incomplete – earlier versions (before 2.2 I think) had no standard way of implementing CORBA objects – what was there, BOA (Basic Object Adapter) was drag to use, and it lacked some crucial features, making it impossible to use without vendor extensions. Farewell portability. After BOA, there was POA (Portable OA) which replaced nightmare with hell. POA is prime example of premature optimization in action, so much that I suspect it’s really called after Prematurely Optimized Atrocity. POA trees? POA managers? POA managers factories? Activation policies? Lifetime cycle policies? Servants? Servant managers? Activation adapters? Please!

In that case, maybe it’s component system? Nah, it lacks features for that, was only equipped with additional components specification in 3.0 (434 pages, together with latest CORBA spec it’s blazing 1586 pages!), its type system is lacking and extremely cumbersome as shown above, making any attempt to use CORBA for DSO-implemented hell on Earth. Do you think implementing component would be simple matter of creating object of given (sub)class? Hah, not with CORBA, and certainly not in language like C.

Bonobo is similar – it does components, UI merging, compound documents and monikers, what have you. And all that is so complex it’s not even funny, and still doesn’t work properly. Do you think it’s coincidence everyone’s running for their lives away from Bonobo? That people throw parties to celebrate removing Bonobo code from their apps? If technology requires two layers of sugar to be barely usable, you shouldn’t be wondering if might be too complex, you should be busy making sure you’re nowhere near it.

Now, to the point – goal of DBUS isn’t to replace Bonobo. DBUS aims to be good, simple way to do IPC. Not component model, not compound document system, not $any_random_hip_idea_of_previous_20_years. It’s about Unix philosophy – do one thing, and do it well. If you need more things done, create more things doing one thing well and tie them together.

21 Oct 2004 (updated 22 Oct 2004 at 22:39 UTC) »
Now 100% CORBA_free()

wingo, you’re perfectly right, CORBA sucks big way. No, it’s not simple in basics, it never was, and will never be. CORBA is your typical 700+ vendors commitee-driven tech, meaning that it never gets below 700+ pages in spec, is never up-to-date, and is always horrendously complicated. Besides, it takes very wrong assumptions as its basis, meaning it can never be right, even in theory. And in practice, it’s also damn overengineered, introducing crack like POA, multiple inheritance in C (say hi to epv, baby), what have you, but failing to make unimportant details like CosNamingService required part of spec (what you say, that without Cos you can’t locate objects? Oh, that’s details). And yes, clever pieces of soft like PyORBit can relieve the pain by large, but that doesn’t change the fact CORBA is pure crack and fundamentally non-robust.

Bonobo (unfortunately) proves my point – it tried to make “CORBA for the rest of us", and lost all the way. It tries to hide all CORBA’s complexity behind another system built on top of it, but inevitably breaks, leaving you with pieces of Bonobo and CORBA lurking from beneath. Of all that, Bonobo::Unknown is small fry, just a name, meaning you don’t have any knowledge of given interface, besides the fact it’s an interface. It’s directly inspired by COM’s IUknown, no big deal, could be as well Bonobo::Object, if you don’t count the fact that BonoboObject is already taken for base implementation class.

Now, DBUS is great replacement for IPC part of CORBA / Bonobo, for it’s simple, well thought, and has single, well defined goal. But it should stay IPC, repeating Bonobo’s mistakes all over again by making it basis of UI embedding (which is dubious by itself, as there are very serious problems with abstracting UI enough to make it replaceable, yet integrated enough not to make it usability horror. So far, all attempts are more or less failures). You could probably have explicit mapping from DBUS to UI components, but making it default system would be wrong. For every day use better system is something along KParts’ lines, ie. based on dynamically loaded .so files.

21 Oct 2004 (updated 22 Oct 2004 at 22:41 UTC) »

Ooops, screwup. Will fix in next version of advogato.php. Move along, nothing to see here.

So, I found that dreaded bug I was chasing for several days. It was, uh, in endianness-conversion macros I ripped out of glib, and apparently did that wrong. I feel so stupid now it’s not even funny… :\

PS. Word of advice for you, lads: recalling “best of Sluggy.com” when razor-shaving is, umm, not the best idea one can get. Really ;)

Argued over why C++ sucks, and particularly why multiple inheritance is broken idea and why you should use interfaces instead for 3h straight. Never again, I’m gonna write that advo article one day and then just keep pointing people, and then life will be beautiful again.

mjw: excellent, we have just the sort of thing you need :). Using this plugin export to Advogato is trivial - just edit the source a bit supplying advogato cookie and optionally categories you want to export, drop into your WP plugins dir, activate and voilà - it works.

Update: grrreat, raph dammit, fix UTF-8 support, will ya?

2 Oct 2004 (updated 22 Oct 2004 at 22:43 UTC) »
2 Oct 2004 (updated 22 Oct 2004 at 22:43 UTC) »
2 Oct 2004 (updated 22 Oct 2004 at 22:44 UTC) »

19 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!