Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

What to Expect From Qt 4 386

Posted by CmdrTaco from the kan-you-kode-what-i-kode dept.
An anonymous reader writes "A presentation given by Matthias Ettrich (director of Qt development, author of LyX, and founder of the KDE project), was given to the annual KDE Developer's Conference in Nove Hardy, Czech Republic. In this presentation, Matthias details what's going to be new in Qt 4.0, which will be used as a base for the next version of KDE after 3.2. Apparently, Qt 4.0 will not only include faster startup times and lighter memory usage, but will have sweeping architectural changes, including a splitting of Qt's GUI classes and non-GUI classes."
This discussion has been archived. No new comments can be posted.

What to Expect From Qt 4 More

What to Expect From Qt 4

Comments Filter:

  • It Sounds Nice (Score:5, Insightful)

    by Jeagoss ( 661909 ) * on Tuesday August 26, 2003 @12:31PM (#6795142) Journal
    but, is it absolutely essential? In a time where code needs to remain compatible due to the large amount of projects that are depending on that code, huge architectual changes implemented in a large number at one time will just show that the project wont get used for quite a while. It will take time for developers to start supporting the new format, which will leave end users wanting.

    • Re:It Sounds Nice (Score:5, Interesting)

      by siliconwafer ( 446697 ) on Tuesday August 26, 2003 @12:35PM (#6795188)
      The lighter memory usage and faster startup times sound very nice. Maybe not essential, but nice.
      • They're essential for me! Right now my app takes too long to start up, especially under Windows and OS/X (it's pretty snappy under Linux, hmm)

    • Re:It Sounds Nice (Score:5, Informative)

      by Coventry ( 3779 ) on Tuesday August 26, 2003 @12:36PM (#6795205) Journal
      Remember, QT is a library, and trolltech makes their money from it. I'm pretty sure that all that will be needed for most apps using current QT is a recompile with the new tools (QT has a tool used as part of the Make process). To use the new features might require changes to code, but thats a different story - you're already changing your code to add new features.

      • Re:It Sounds Nice (Score:3, Interesting)

        by sketerpot ( 454020 )
        From the article:
        Qt 4 mostly tries to preserve source-compatibility with a little search and replace and a COMPAT compilation switch. More porting will be required for styles and code that uses the meta object system directly.

        Not much Qt code uses the moc system directly, since this is deep black magic and typically a bad idea. They're preserving compatibility, and it seems like a pretty small price to pay.

    • Re:It Sounds Nice (Score:5, Interesting)

      by stratjakt ( 596332 ) on Tuesday August 26, 2003 @12:37PM (#6795216) Journal
      Qt 4 mostly tries to preserve source-compatibility with a little search and replace and a COMPAT compilation switch. More porting will be required for styles and code that uses the meta object system directly.

      Out with the old, in with the new.

      Developers can adapt or fail. It doesnt seem wise to quit working towards better systems because some guy doesnt feel like replacing his widgets.

      • Re:It Sounds Nice (Score:2, Insightful)

        by Jeagoss ( 661909 ) *
        I'm not saying change isn't good. Change is very good. The thing I see here is they aren't only implementing 5-6 new features and a small architecture change. Yes, they are trying to maintain source compatibility, but the style of coding is just far antiquated. Personally, when I write code, I implement a new feature, get it working very very well, and then move on to the next feature. This leaves room for other projects to implement the new feature, and start using it, while I then move onto the next

      • Re:It Sounds Nice (Score:5, Interesting)

        by Otter ( 3800 ) on Tuesday August 26, 2003 @01:17PM (#6795690) Journal
        Developers can adapt or fail.

        Remember, though, that we're talking about volunteer developers. If they fail, there's no one rushing in to take their customers. I remember when the KDE 3 plans were being made, there was a recognition that KDE's weakness is in the number and quality of apps and so there was a goal of keeping the APIs stable for as long as possible.

        Now, greatly improved startup time would obviously be a huge reason to switch as soon as possible. Since pure Qt apps already start much faster than KDE apps, though, I wonder how much speed KDE would really gain.

    • Re:It Sounds Nice (Score:5, Insightful)

      by Overly Critical Guy ( 663429 ) on Tuesday August 26, 2003 @12:38PM (#6795236)
      Why are Linux users so afraid of change? It's the very reason we suffer through so much legacy compability to slow things down.

      I welcome any sort of innovation. People will update their apps to meet any changes.

      • Re:It Sounds Nice (Score:2, Interesting)

        by Jeagoss ( 661909 ) *
        Besides reading my profile, what is to say I am even talking about QT for a personal use, or even QT for linux. I work for a company that uses the Professional Version of QT for development of "in house" applications which run mainly on FreeBSD. Source compatibility isn't always the best thing. A recompile of our applications isn't the quickest thing either. And after the recompile, we still have policies that say we have to test the new compiled app for 2 weeks before we push it to the network, just to

      • Backwards compatibility is important (Score:4, Insightful)

        by ZorinLynx ( 31751 ) on Tuesday August 26, 2003 @02:06PM (#6796273) Homepage
        Sigh. I really hate to say this, but I must agree with keeping API's backwards compatible across versions of libraries.

        I've been using Linux for years now, and one of the biggest annoyances is that software packages tend to be tied very closely to a specific version of a library. Without backwards compatibility, you sometimes need to have two or three different versions of the same library installed in order to use different applications.

        When a library is used by a wide variety of applications, like Qt, GTK, libc, and so on, backwards compatibility should be ensured. Yes, this means the library may be a bit more bloated than it has to be, but the bloat isn't as bad as the bloat that results from having to install an ancient version of Qt in order to run an app that hasn't had active development for a few years.

        This is coming from someone who doesn't do much software development; I just maintain a lot of systems and software libraries.

    • Faster startup times? Maybe M$ will steal the code and the world will save millions of man hours. Think of the benefits to the world economy!

      (Note: This is a joke. This is only a joke. If you didn't like the joke, then please just move on and leave me to enjoy it by myself. Thank you for your participation in this joke advisory.)

    • Re:It Sounds Nice (Score:2, Insightful)

      by ded_guy ( 698956 )
      I dunno--sometimes things have to be broken to make them easier, faster, or more flexible or to allow for future growth. Or sometimes just because there is a Better Way. Look at the breakages going on in Perl 6.

    • RTFA! (Score:3, Informative)

      by Anonymous Coward
      Paragraph 2:

      "Qt 4 mostly tries to preserve source-compatibility with a little search and replace and a COMPAT compilation switch. More porting will be required for styles and code that uses the meta object system directly."

      How much stuff do you think uses the meta object system directly, aside from the internals of KDE?

      • Re: RTFA! (Score:4, Interesting)

        by Rimbo ( 139781 ) <rimbosity@@@sbcglobal...net> on Tuesday August 26, 2003 @12:53PM (#6795415) Homepage Journal
        Jesus, I was wondering when someone was going to say this. Qt developers obviously aren't reading slashdot. other than you and me, that is :D

        I think the large number of complaints is that although source-compatibility is -basically- maintained, you still have to recompile your apps. One of the nice things Microsoft has done is that you don't have to recompile your Win32-based app to work in .NET -- well, not completely, anyhow. This does have the side effect of dirtying up the API a bit. So it's a trade-off. Backwards compatibility does make GUIs easier for people to adopt -- who wants to constantly have to download new apps to work with the latest version???
        • Windows is so big, bloated and unstable because you have great binary compatibility. I can get Visicalc, one of the first spreadsheet programs for PCs, and run it under Windows XP. Many closed source programs compiled for old version of glibc, with old gcc versions, don't run under new Linux systems, and kde programs can be even a greater pain. I know it sounds like a troll but, unless you stick with the RPMs provided by your distribution, you have difficulties to install binary software in Linux, as most
        • I think the large number of complaints is that although source-compatibility is -basically- maintained, you still have to recompile your apps. One of the nice things Microsoft has done is that you don't have to recompile your Win32-based app to work in .NET -- well, not completely, anyhow. This does have the side effect of dirtying up the API a bit. So it's a trade-off. Backwards compatibility does make GUIs easier for people to adopt -- who wants to constantly have to download new apps to work with the lat


    • I agree with you exactly, it sounds nice but why do we need to change an architectual change when the current QT architecture is the best there is?

      Why fix what isnt broken? Especially when you are ahead of the curve and on the cutting edge? Why not polish what you have? Thats the exact problem Gnome has, they keep restarting and redoing everything and they get NO WHERE.

      KDE 4.0 would be better if it were based on the current QT because it could be polished, if they instead have to rewrite alot of code for
      • A 15% reduction in memory usage is a fairly major bit of 'polish' to add to an app. Kde 4.0 is a long way off anyway (3.2 is planned for december, so h). From the sound of it, the change 3->4 is not as big as the jump was 2->3.
    • No it doesnt have to be compatible.

      Think of the benefits of sleepycat DB versions as their architectures changed, it improved across incompatible version.

      QT is nice and sweet as it is, we dont need too many changes too fast. Programmers are now getting really used to QT3, dont EXACTLY need a version 4 with a different interface to start learning.

      Of course if they're slimming it up more and making it faster (like FLTK) without adding too much other stuff, adding more database drivers and porting to more a

    • It will take time for developers to start supporting the new format, which will leave end users wanting.

      I expect I'll just do the same thing with qt4 that I did with qt3 (and gtk 2, etc.): install it, but keep older versions around until all the programs which use the library have been updated. This is the way libraries are supposed to work; you increment the major version when you've broken binary compatibility, you keep all the major versions installed that you need, and you uninstall them when you no
    • They aren't *forcing* you to use QT4 though, right? That is the great thing about open source...you don't HAVE to be forced to upgrade...so all this hand wringing over adding features/changing things is sort of pointless. If you don't like it, don't use it.
    • Faster startup and smaller size. by 6.0 stuff should start before you click on it and it should fit in less that 640k. Haven't we been promised these two things in every version so far?

      Bigger and slower is all I ever seem to get from KDE.

  • Faster? (Score:3, Interesting)

    by Kenterlogic ( 648880 ) on Tuesday August 26, 2003 @12:32PM (#6795152) Homepage
    I have alwways preffered Gnome to KDE because of speed issues (and the new Gnome is a lot prettier). But if this new base is much faster, then I may be forced to start using KDE again. Then again, my G5 should be arriving soon-- so forget Linux.
    • I am still choosing gnome over kde on my G4 and G3 machines, both running gentoo linux/PPC ... Oh, I got it! You'll get g5 which is power enough to run OSX fast enough, right? But why to switch to OSX when you can still run your beloved Linux/PPC even on G5? Or other any known problems to run Linux on G5?

  • Here's what I expect (Score:3, Informative)

    by Rosco P. Coltrane ( 209368 ) on Tuesday August 26, 2003 @12:37PM (#6795222)
    Qt is great (well, if you like C++ and you don't mind the QPL), but there's really one thing I'd like: when will it ever have a font scheme that allows me to use AA fonts together with non-truetype X11 core fonts?
    • The free version is released under both the QPL and the GPL, you only have to accept one of those two licenses to use it, not both. So if the QPL bothers you, just accept the terms of the GPL instead.
      • No no, I'm talking about the dual-licensing thing. The GPL/QPL is a bait-and-switch scheme : the more people use it under GPL, the more it'll become standard, and the more people who want to make commercial products will be compelled to use Qt as a de-facto standard and be forced to pay the Trolltech tax.

        Don't get me wrong, I like Qt and I think TT's market grabbing scheme is pretty slick and fair, from a company out to make money, but I've paid for and had to endure enough non-free (free as in beer) softw
        • You're aware that the QPL is, more-or-less, an open source license right? People didn't like it because it didn't meet the Free Software Foundations definition of free (meaning that, according to a strict interpretation of the GPL, it was illegal to distribute KDE in binary form), so Trolltech started licensing it under the GPL, leaving the option of accepting the terms of the old license instead.

          As for dual-licensing it commercially and as free software, well, I don't see how that forces anyone to do any

          • Trolltech are successfully creating and supporting free software, and managing to make money. I don't see that as something to be wary of.

            Yep, it's a great arrangement... now... as long as they're making money.

            There's nothing to stop Troll Tech from becoming unreasonable in their licensing demands... crippling all commercial KDE development. Since KDE is a desktop environment, commercial development is pretty important.

            Only GPL software development is safe under KDE.

            • "There's nothing to stop Troll Tech from becoming unreasonable in their licensing demands... crippling all commercial KDE development. Since KDE is a desktop environment, commercial development is pretty important."

              Yes there is, it's called the GPL. If TrollTech decides to do something loathsome in a future release of Qt, the previously released versions will still be there under the GPL, and anyone who wants to will be able to modify it, fork it, etc to their hearts content.

              The GPL is what ensures

      • Sure, you can choose the GPL version of Qt/X11, as long as you don't intend to use it with KDE. Essential core parts of KDE are licensed under BSD, and so cannot be used with the GPL'd Qt, only the QPL'd Qt.
    • > will it ever have a font scheme that allows me to use AA fonts together with non-truetype X11 core fonts?

      It has since Qt 3.x already. Qt 2.3 did not support doing this, however. Qt 2.2 and earlier didn't support AA fonts.
  • As you know 4% of TrollTech is owned by Canopy of SCO fame. We need to put some pressure on Trolltech to make sure that nobody from Canopy is on the board or has any saying whatsoever over Trolltech

    I have switched to Gnome until further

    • AC Comment from other Canopy Employee (Score:4, Interesting)

      by bstadil ( 7110 ) on Tuesday August 26, 2003 @02:00PM (#6796215) Homepage
      Since my comment has been modded a Troll I think you should read this [pclinuxonline.com]posting from another Canopy Company employee.

      Quote:

      As an employee of a company in the same office buildings as SCO and partly funded by Canopy Group, I strongly encourage a boycott of all companies funded by the Canopy Group.

      There was a lot of buzz about mergers a few weeks ago. It seemed that everyone was going to join into one large company called, you know it: SCO! .......

    • Moderators Suck ... (Score:2, Interesting)

      by Anonymous Coward
      Troll? Come on guys, we're not bashing Apple.
      You don't have to throw a hissy fit cuz someone's bashing your fave tool.

      from http://www.pclinuxonline.com/modules.php?mop=modl o ad&name=Forums&file=viewtopic&topic=870&forum= 37
      As an employee of a company in the same office buildings as SCO and partly funded by Canopy Group, I strongly encourage a boycott of all companies funded by the Canopy Group.

      Taking money from Ralph Yarrow (Canopy) made all of us sick to our stomachs but we held our

  • Now this is what I like about Linux; every time I think some annoying little thing about the interface/OS is really starting to annoy me, a new version comes out and something get tweaked to the way I like it.

    It's really the reason I have grown to like Linux so much: I can actually see the progress of its development moving forward. It seems in the past few years that Windows has just been moving backwards.

  • What I would like to see.. (Score:3, Interesting)

    by ErisCalmsme ( 212887 ) on Tuesday August 26, 2003 @12:56PM (#6795444) Homepage Journal
    Is more apps that require QT but not all of kde to run. That's why I use gtk apps... because most of them dont require gnome. There are gnome apps of course, and there are progs like Gaim that will give you a little somethin' extra if you have gnome installed, but you don't need it... Are there any qt apps that dont require kde to be installed?

    • Re:What I would like to see.. (Score:2, Informative)

      by Anonymous Coward
      Yes, some of the common ones include

      Opera Web browser
      LyX word processor
      SuSE's YaST.
      Scribus destkop publisher.
      The Linux 2.6 QConf
      Kylix.
      YHBT Business books
      and hundreds more.
    • There are many. One of the advantages of Qt is that it provides a common interface to X-Windows, MS Windows, and Mac OS GUI programming. Qt is entirely independent of KDE, the only reason an application would be bound to KDE is if it utilizes the KDE extensions to Qt.
      • "One of the advantages of Qt is that it provides a common interface to X-Windows, MS Windows, and Mac OS GUI programming."

        Thankfully, GTK+ also does this. Gaim/Win32 is proof of that. With the new Wimp skin, GTK+ even matches the Windows look, for the most part.

        Of course, there are also QT apps that I enjoy on Windows. MySQLAdmin, for one.

  • gcc dynamic linking? (Score:5, Interesting)

    by 4of12 ( 97621 ) on Tuesday August 26, 2003 @12:59PM (#6795478) Homepage Journal

    A couple of years ago someone on the KDE team posted [www.suse.de] a nice analysis of the performance bottlenecks associated with dynamic linking, C++, and gcc, particularly as regards Qt use.

    So I have to wonder, with Qt 4, KDE 3, gcc 3.3, how many of the performance problems remain?

    • Re:gcc dynamic linking? (Score:5, Interesting)

      by IamTheRealMike ( 537420 ) on Tuesday August 26, 2003 @04:13PM (#6797943)
      That's what all the talk about reducing number of symbols and relocs is about - KDE got hit really really hard by the way it requiries lots of fixup at startup time in the linker. In some cases it was THE biggest drain on startup time. By reducing the number of symbols in the code, you reduce the work needed to dynamically link it all, so improving the speed.

      Though, I can't help thinking that prelink is a better solution to that problem. But whatever, they are surely aware of that technology by now.

  • use of the standard library (Score:5, Interesting)

    by Eponymous Coward ( 6097 ) on Tuesday August 26, 2003 @01:04PM (#6795530)
    I'd like to see more use of the standard library. The traditional complaints of poorly conforming compilers is mostly just history. Except for support of the export keyword, most C++ compilers and standard library implementations are now quite good. Most platforms even have several excellent compiler / library combinations to choose from.

    Even though it would be hell for already existing apps, I would love to see use of standard library components rather than the re-invented QT versions. And even in those cases were the QT versions have extra features, I still think the advantages of using a library that is already familliar with most C++ programmers outweighs the disadvantages. Of course, that's just IMHO.

    ec

  • I believe someone got the name of the town wrong, it's Nove Hrady and not Nove Hardy.

  • QT4 (Score:5, Insightful)

    by SlayerDave ( 555409 ) <elddm1@gmaLAPLACEil.com minus math_god> on Tuesday August 26, 2003 @01:09PM (#6795602) Homepage
    I have recently spent a good deal of time programming with QT3. While QT is the best C++ GUI library and application framework, I think it needs some improvement. Here are my gripes, in no particular order.

    First, the signal/slot mechanism really bugs me. I am annoyed with the need to use non-ANSI C++ techniques (e.g. public slots, moc) to achieve results that could easily be done with legal C++ code. While not strictly illegal, the use of the SIGNAL and SLOT macros, along with the Q_OBJECT macro, are not very good techniques. Specifically the reliance on macros to achieve basic GUI functionality violates a key principle in Meyers' "Effective C++", namely avoiding reliance on the preprocessor.

    Second, several GUI widgets do not have a proper separation of data from view. I am thinking specifically of QTable and QListView. A better approach, from an OO design perspective, is the one taken in Java Swing. The JTable and JTree provide a nice mechanism for separating the data model from the GUI display. I find it obnoxious to have to subclass QTable and build-in data model methods to achieve results that would be cleaner under a Model-View design paradigm.

    The QT online documentation is not easy to navigate. They should take a lesson from the Java API docs and reorganize the QT docs along those lines.

    • Re:QT4 (Score:2, Insightful)

      by fault0 ( 514452 )
      > The QT online documentation is not easy to navigate. They should take a lesson from the Java API docs and reorganize the QT docs along those lines.

      Wow, I've found the Java API docs extremely hard to navigate.

      Perhaps that's because of the bloat (in terms of classes) of the Java API, though.

      • Re:QT4 (Score:3, Informative)

        by SlayerDave ( 555409 )
        That's true, the Java API has a very large number of classes. But what I like about their docs is the use of frames, which is normally quite annoying, but is well-done in the case of JavaDoc. Also, you can select a particular package to view, such as javax.swing or java.util, which greatly limits the number of classes you have to browse. Also, I like the ability to see clearly what members are new in each class and what members are inherited and/or reimplemented. Also, getters and setters are listed tog
        • > Also, I like the ability to see clearly what members are new in each class

          Yup, I'd love to see this done in Qt.. it's even marked in the source I beleive (@since 3.1, etc..)

          > what members are inherited and/or reimplemented.

          I think it already is

          > Also, getters and setters are listed together in the Java docs,

          agreed.

    • Re:QT4 (Score:3, Informative)

      by Arandir ( 19206 )
      First, the signal/slot mechanism really bugs me. I am annoyed with the need to use non-ANSI C++ techniques (e.g. public slots, moc) to achieve results that could easily be done with legal C++ code.

      There is no ISO C++ mechanism that does the same thing that signals/slots do. None. None at all.

      Now before you start talking about Boost::Signals, libsig++, gtkmm, etc., take a step back. Those things you're talking about are libraries, just the same as Qt. They are not standard mechanisms any more than gettext

  • Very nice. But they forgot one minor thing: (Score:5, Interesting)

    by master_p ( 608214 ) on Tuesday August 26, 2003 @01:19PM (#6795726)
    I don't have any major complain from Qt, as I have been using it a lot in our company and found out that it is the best.

    I only have this problem: the TreeView widget is single-linked. This a major problem for us, since our apps contains lots of trees. We have to do a lot of tricks, like keeping a pointer to the last item all the time.

    I've posted this on the Qt newsgroup but I was ignored. Although many people have complained about it, Qt engineers ignored us. I think they should fix it in version 4.

    Other than that, Qt is indeed the finest toolkit out there. It simplifies development a lot, and it fills the great void that exists in C++ libraries. It's really like the Java libraries or the .NET libraries, providing almost everything needed under the sun.

    The biggest advantage of it is that it works as expected; in other words, you just create one widget inside the other, and voila, there is the app's gui. You can even do it programmatically, without the KDesigner.

    Finally, it does C++ justice. It's the only library that shows how powerful C++ can be. After having used Qt and Java, I may safely say its up on par with Java...even better I would say, since it uses all of C++ capabilities, including the most important one: templates.
    • I use (and adore) wxWindows now, but one thing I always liked about Qt was that any widget could be it's own top-level frame - made testing custom widgets and the like much easier. Price tag was the kicker for me, but I've grown to prefer the wxWindows API anyway.
    • Then spend the time necessary and modify the QTreeView source directly, making it doubly linked. If it's really causing you that many problems, your time is well invested making the change. Also, may be able to get by with simply subclassing it. Seriously, the source is not that hard to understand and making changes to it is kind of fun :) I ended up digging around in the QRichText source so I had a better idea of how they handled the psuedo html...
    • No, the most important one (that java forgot) is the ability to resize arrays!

      (ok, ok, sorry, but that was always something about Java that just bugged the hell outta me, and I know lots of my friends agree)
    • "Other than that, Qt is indeed the finest toolkit out there. It simplifies development a lot, and it fills the great void that exists in C++ libraries. It's really like the Java libraries or the .NET libraries, providing almost everything needed under the sun."

      Very interesting it does not include everything according to Sun. What Sun needs to do with the MADHATTER is create a Java dev desktop. That would be interesting. KDE is great and yes you can is the Dev attitude. Why not have more than one desktop av

  • How about more standard C++ (Score:4, Interesting)

    by Ed Avis ( 5917 ) <ed@membled.com> on Tuesday August 26, 2003 @01:50PM (#6796089) Homepage
    Is it too much to ask that the next Qt will use the standard C++ string class instead of its own reinvention and kitchen-sink-itis that it suffers from at the moment?
  • When can we expect a stand alone HTML rendering engine properly wrapped (and supported) by QT. Yes I know they have a rich text widget that supports simple HTML rendering BUT I have a project that needs something more sophisticated. Is there a KHTML or Gecko wrap out there that would give me x-platform across Linux, Windows and the Mac for use with stand alone QT applications???

    • Re:HTML rendering (Score:3, Interesting)

      by julesh ( 229690 )
      Have you looked at this to solve your windows portability needs?

      http://kde-cygwin.sourceforge.net/

      It uses cygwin, which might mean some user confusion with filenames; if that's an issue for you you might want to forget about it. Also it'll mean you're stuck with GPL. Otherwise, I understand the results are quite impressive... if you don't want to use X, you can probably substitute the windows version of Qt, and everything should work OK. It'll be a lot of work to get it going, but after that it should

  • KDE Conference Talk Writeups (Score:3, Informative)

    by JRiddell ( 216337 ) on Tuesday August 26, 2003 @02:46PM (#6796767) Homepage

    Writeups of the talks I went to are at:

    the Nove Hrady wiki [uni-erlangen.de].

  • Qt 4 vs Qt 6 (Score:3, Funny)

    by egommer ( 303441 ) on Tuesday August 26, 2003 @03:15PM (#6797199) Homepage
    I don't know why you all are worried about QuickTime 4 f. I personally use QuickTime 6 on my iMac. Sheesh. You can't even see the latest pron and movie trailer's with Qt 4. Oh Wait... I think this is somthing else.. Damn you! you- 133t linux users fooled me again.

Slashdot Top Deals

When it is incorrect, it is, at least *authoritatively* incorrect. -- Hitchiker's Guide To The Galaxy

Close