Forgot your password?
typodupeerror
Programming GUI KDE IT Technology

Qt Opens Source Code Repositories 230

Posted by timothy
from the good-news-on-a-few-fronts dept.
sobral writes "Following the announcement of the LGPL license model, since yesterday the Qt source code repositories are open to the public together with their roadmap. The contribution model is online and will enable developers from the community to submit patches through a single click process, avoiding the previous hassle of sending in signed paperwork. The code is hosted at qt.gitorious.org and an instant benefit of this launch is that Qt Software has been working together with Gitorious maintainers for the last four months to improve Gitorious and all these new features are already submitted upstream."
This discussion has been archived. No new comments can be posted.

Qt Opens Source Code Repositories

Comments Filter:
  • Qt GTK (Score:5, Interesting)

    by Anonymous Coward on Tuesday May 12, 2009 @11:41AM (#27922855)

    I hope Gnome switches to Qt one day, its so much nicer than GTK.

    • not a troll (Score:5, Insightful)

      by CarpetShark (865376) on Tuesday May 12, 2009 @01:44PM (#27924713)

      What reactionaries are modding this "troll"? It's a perfectly valid comment, for anyone who has actually sat down and compared the libraries. Also, it's a perfectly reasonable issue to consider, now that both desktops' core libraries share common licenses and have essentially become interchangeable. Yes, that interchange would involve hard work, which may lead reactionaries to reject it, but what progress doesn't involve hard work? It would at least be nice to see a study of some GNOME app re-implemented in Qt, and what the pros/cons are. I know for a fact that at least a few apps have have been ported from GNOME to Qt (Qt3, though, I think), and probably some have been ported the other way too. Even just those historical cases with Qt3, the case study would be interesting.

    • by speedtux (1307149)

      It's not going to happen. Qt makes sense if you develop in C++. Gnome is going to move gradually to Python and C# development; C++ is just not on its roadmap.

  • by master_p (608214) on Tuesday May 12, 2009 @12:08PM (#27923237)

    1) replace Qt memory management with TR1::shared_ptr (or boost).

    2) replace Qt collections with STL collections.

    3) replace Qt threads with boost::threads.

    4) replace Qt signals and slots with boost::signals.

    In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.

    • by Clith (5063) <rae@tnir.org> on Tuesday May 12, 2009 @12:12PM (#27923303) Homepage Journal
      Qt's collection classes are API compatible with STL. So I would argue that it plays nicely already. I prefer Qt containers to STL containers because Qt's classes have been optimized. STL has some issues with performance.
      • Re: (Score:3, Insightful)

        by Futil3 (931900)
        Better than STL? [google.se]

        An STL implementation has a few things going in its favor:

        STL implementations use best-of-breed algorithms.
        The designers of STL implementations are, more than likely, domain experts.
        Those domain experts were entirely focused on the mission of providing a flexible, powerful, and efficient library. This was their primary task.

        But then again. (only) You know your own usage scenario, data types and platform. That knowledge can probably offer some profound short cuts and o

        • I haven't really followed up on the recent developments of Qt or STL, but I was under the impression that Qt containers implement copy-on-write while STL ones don't. Correct me if I'm wrong.

          I don't think it's an exactly clever idea to be unnecessarily copying containers in the first place, but no matter what it makes Qt to STL migration hard if the Qt applications are filled with assumptions on copy-on-write.

      • by mzs (595629)

        shared_ptr and QPointer don't play together so nicely though. Also QPointer tends be slower than shared_ptr when I only need what shared_ptr does. To get them to work together I end-up copying things between the two or just end-up not using shared_ptr at all.

        • Re:pointer (Score:4, Informative)

          by zander (2684) on Tuesday May 12, 2009 @01:34PM (#27924553)
          the shared_ptr equivalent in Qt is QSharedPointer (surprise!) not QPointer which is something quite different. I do suggest not using shared_ptr as the Qt version has better cross-platform support and is easier to use and like most Qt things has better readability.
          • Re: (Score:3, Informative)

            by mzs (595629)

            To be fair QSharedPointer showed-up in 4.5, hence the reason I had never heard of it until now. OPointer was forced upon me due to everything being a QObject, but then there was the other non-Qt half of the code that used boost, it was not pretty.

      • Re: (Score:3, Interesting)

        by Brandybuck (704397)

        Almost, but not quite. STL containers tend to be optimized for speed, while Qt containers are optimized for size. There is an old Qt Quarterly that discussed the implementation of Qt's containers what was quite interesting. Go online and search for it.

    • by ultrabot (200914)

      1) replace Qt memory management with TR1::shared_ptr (or boost).

      2) replace Qt collections with STL collections.

      3) replace Qt threads with boost::threads.

      4) replace Qt signals and slots with boost::signals.

      In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.

      So it doesn't play nice with them right now?

      You'll be waiting for Qt5 for that kind of stuff.

      I think this will be about the time C++0x [att.com] gets mainstream. Breaking Qt source compatibility before that is just not worth it.

    • by pyrico (1034804) on Tuesday May 12, 2009 @01:06PM (#27924117)

      1) replace Qt memory management with TR1::shared_ptr (or boost).

      For the core purpose of Qt (GUIs), Qt's various memory models work very well. Every widget is a QObject and by default they fall into parent child releationships that include life-cycle management of your objects. Why would you want to mess up that clean model?

      2) replace Qt collections with STL collections.

      Another unnecessary generalization. I actually much prefer Qt's collections because A) they are implicitly shared (you can pass them around without getting deep copies) and B) they have one clean and very efficient implementation across platforms, so I don't have to worry about the memory and performance characteristics of a MSVC std::map vs a GCC std::map. Also they are much cleaner to work with and don't require hideous iterators every step of the way.

      3) replace Qt threads with boost::threads.

      Again, Qt threads will perform as good as native threads on each platform, something you can not guarantee with pthreads (with weaker windows support). Also, QThread and friends (QMutex, QSemaphore, QWaitCondition, QThreadStorage) are very C++ oriented and stylistically much cleaner than pthreads and even go beyond it in scope.

      4) replace Qt signals and slots with boost::signals.

      This is probably the most valid argument, and there is some legacy reasons why Qt had to throw a meta object compiler on top of C++ to get this to work 18 years ago. But in the mean time, that moc layer has paid off in gold. Now you the ability to get free introspection on classes of your choosing which is vital in making C++ suck less in well designed programs (i.e. can do automatic class instance serialization etc).

      In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.

      In other words, Qt is a great one-stop-shop for cross platform development and I wouldn't change a single thing you listed. In fact, if you write your C++ code in stylelistic keeping with the Qt libraries, you avoid most of C++'s warts and can even enjoy the language.

      • by master_p (608214)

        1) parent-child relationships are not enough in many cases where objects are shared across multiple domains.

        2) nowadays STL is as efficient as it gets across all major compilers - plus you'll get big speed ups with the upcoming changes in C++0x.

        3) I did not say anything about pthreads. I said 'replace Qt threads with boost threads'.

        4) Introspection has nothing to do with signals and slots. Qt signals and slots are very limited in what they can do.

    • Re: (Score:3, Interesting)

      by PerlDudeXL (456021)

      boost::thread has a different design concept than QThread. I would appreciate if Qt
      would introduce a Functor-style API for Threads.

      boost::signals doesn't work across threads (this is docuemented in the boost API).

      Throwing both Qt and boost APIs together would create an ugly mess.

      • by master_p (608214)

        Boost::signals doesn't need to work across threads because it can be made to work across threads with very little code. All that you need is a single template class which wraps the signal into a QEvent.

        No ugly mess if whatever common functionality they have is removed from Qt.

    • Re: (Score:2, Insightful)

      by harry1701 (1553093)
      The use of boost will greatly limit the amount of supported platforms and compilers. Replacing Qt collections with STL will kill the embedded branch, where code expansion counts. It'll also not be nice for the deskop - imagine loading a Visual Studio plugin while another plugin is loaded that uses another STL implementation -> boom, symbol clashes.
      • by master_p (608214)

        Qt works on Windows, Mac, Linux/X11, embedded Linux, Windows CE (according to Trollech).

        Boost works on almost any modern operating system, including UNIX and Windows variants (phrase copied and pasted from boost site).

        So I think boost works in more platforms than Qt.

    • Qt is Object Oriented through and through, with only a hint of GP. There's no need to use functors. Threads are defined by subclassing QThread, not passing in a functor. Signal/slots are implemented as GoF Publish/Subscribe, not functors wrapping a member function pointer.

      The fact of the matter is that most C++ developers just don't know function objects. I've been doing an informal survey for the past two years, asking clients about functors. My informal results seem to be that only one in twenty know what

      • by master_p (608214)

        1) functors and lambdas simplify code greatly.

        2) it's time for C++ devs to know about functors.

        3) I can't bind functors with Qt signals.

      • by ardor (673957)

        Note however that when I showed C++ coders what function objects are, they liked it every time. It is somewhat strange at the beginning, but once you grasp it fully, you never want to put function objects, bind, lambda etc. away.

    • by spitzak (4019)

      And replace the wchar_t Qt strings with stl::string!

    • Re: (Score:2, Interesting)

      by 21mhz (443080)

      In other words, make Qt play nice with STL and boost, which are the foundations for developing C++ code these days.

      In still other words, make it emit mountains of non-shared, hard to update code into every client application and dependent library, thus turning it into awful crap for purposes of mobile platforms, or just any platforms where shared libraries are anything but a joke.

      As a side-effect, force it to use C++ exceptions, which are a sick joke to anybody who knows how real exceptions work in managed environments, and introduce any number of invisible, rarely exercised paths through the application code, which cau

  • Maybe now that QT is LGPL, Mathworks will finally transition MATLAB on OS X out of X11 and make it behave like a proper OS X app. ...One can dream....
    • by guruevi (827432)

      MATLAB won't transition to anything. It's the only player in the market and is about as bad as Microsoft as far as licensing goes. Since they switched to activation for their licensing I have been looking for competitors. I've even had to crack some of their systems in order for it to keep working (some with an official crack, others with a not-so-legal crack). The Mathworks knows they have all educational institutions and a lot of engineering labs by the balls and can twist them however they want.

      Octave is

    • I reckon most of the Matlab frontend is Java. As near as I can tell, only the plotting part uses X at all on OS X. That said, the insane license manager they use for Unix-like platforms (as opposed to a very simple activation code in Windows) has led me to scipy. I have not looked back much, except for the interactive graphs they added to the newer releases.
  • TGI Git (Score:5, Interesting)

    by iluvcapra (782887) on Tuesday May 12, 2009 @12:55PM (#27923951)

    I have to say, I'm glad of this trend lately for open source projects to primarily publish their source through Git, and particularly through these very able Git hosting sites like gitorious and github [github.com]. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable. With the way Git works, and particularly with the implementations the hosting companies provide, it's very easy to fork a project, make the changes you want, and always have the power to commit to a remote repository that not only keeps track of all your commits but ALSO how all your commits relate back to the original forked project...

    Instead of downloading someone's tarball and (maybe) emailing them a diff (or just posting your own duplicate of their source with your little changes), it's like you're making a shadow copy of a projects source, where you have all the control but no information is duplicated or lost.

    • Re:TGI Git (Score:5, Interesting)

      by ultrabot (200914) on Tuesday May 12, 2009 @01:31PM (#27924523)

      have to say, I'm glad of this trend lately for open source projects to primarily publish their source through Git, and particularly through these very able Git hosting sites like gitorious and github [github.com]. If you've worked with CVS and SVN open-source projects most of your career, the experience is simply incomparable.

      However, if you've worked with mercurial before, the experience is comparable - but not really favorably for Git.

      It seems Git is this shiny thing every trend chaser is picking it up right now, but it has the overall feel of not really being ready yet. I'm glad it's having some serious competition right now, so it won't be the "obvious" choice like svn was for the previous generation. It's a mixed blessing - I'd really want us to have one obvious DVCS choice, but on the other hand I don't want it to be git as it is right now. And Git doesn't seem to be getting better fast enough, since the current users are familiar with its quirks and don't really mind that much.

      • Is there any kind of Mercurial hosting for open source projects you can recommend?

  • by Kensai7 (1005287) on Tuesday May 12, 2009 @04:53PM (#27927991)

    What can I say... Qt is becoming a dream platform thanks to Nokia's insight!

    - a powerful language/library (C++)
    - real cross-platform
    - support for embedded and mobile applications (a great alternative for the difficult Symbian C++ language)
    - open source and nice licence (LGPL)
    - exemplar own IDE but also Eclipse/VS integration
    - additional languages supported

    What else could one ask?!

The F-15 Eagle: If it's up, we'll shoot it down. If it's down, we'll blow it up. -- A McDonnel-Douglas ad from a few years ago

Working...