Our software is not patent cucumbered
{ Monthly Archives }
wingo, “I see no beastly problem here”. Instead, I see area filled with several, resonably well defined problems, each of reasonable size and complexity. Think Unix, dude (hint: CORBA isn’t Unix, CORBA thinking isn’t Unix thinking)
salmoni: wrong. Very, very wrong. Google is by no means cross platform, it has one, well defined platform: the web. The fact that you are able to host Google’s target platform (that is, $browser) on multiple OS’s / GUIs doesn’t make it cross platform. It’s the same kind of portability that Swing does — “we look equally foreign everywhere”. If you still think Google does any kind of x-platform UI, answer these simple questions: What are the platforms Google looks (and feels) native on, besides browsers? Does it have standard Win32 UI? Does it conform to GNOME HIG? Does it employ Aqua guidelines? Is it integrated in any way with KDE? Does Google use ROX UI metaphors? In any case, the answer is negative, ergo Google is not cross platform.
e8johan: That’s probably because:
Now, why bring Java on table at all? Because, whether you like it or not, Java or Mono/.NET are the platform for great majority of corporate users. Which means in-house development. Which means real majority of apps used, but invisible to the outside. I hear that Java-GNOME is particularly strong in this invisible development. But then, Mono is visible in the wild, which means newcomers, evaluating one of platforms to pick up for future development, are more likely to stumble on GTK# than Java-GNOME, and conversely, use it as in-house platform of choice. So, in the end, Java-GNOME being so little visible outside internal corporate usage can hurt it in that internal corporate world.
And finally, (WARNING: totally subjective opinion follows) Mono/.NET is nicer than Java, so it gains new users on the expense of Java followers. How is it better? Delegates, built in events, x-language support, little things here and there. Also, quite surprisingly for MS platform, it has less marketing fuss in it than Java. Noone tries to convince us that platform and language are one, versioning is quite sane (did someone say Java 1.5? I mean, Java2, that is, Java 5.0), etc.
Now, having said that, the most popular non-C language in GNOME development is almost certainly Python / PyGTK. And there’s a reason to that — it’s one insanely great language with insanely great bindings set :)
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.
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.
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.
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?
I did new version of wingo’s WP-advogato crossposter plugin. Now it includes support for categories (ie., you can export only posts that are in certain categories, as well as specifically exclude some categories from being posted, even if post would otherwise match exported ones. You can also fallback to old behavior and simply export everything).
Disclaimer: While I tried to test it as much as possible, I take no responsibility for it being bug-free or for that matter, working at all. If that post shows up on advogato, it’s at least a sign that something works :)
TODO:
- include comments link in exported posts
- convert WP’s title into text inlined in posts as published on advogato
