On 13-04-24 04:56 PM, Andrej N. Gritsenko wrote: > I hope PCMan will answer this shortly. But what I heard from him is > Qt is a lot better in both API stability and variability. And in regard > of debugging - C++ isn't syntetic language but Vala is therefore should > be a much easier to debug C++ applications than Vala (Vala is just a hell > to debug). But I have almost zero experience with C++ and Qt so cannot > tell you much.
I'm not concerned about the API stability. My time as an enthusiast KDE user has made it clear how much both Qt and KDE value API stability. New APIs can be added, but old ones can't be broken in Qt or kdelibs without incrementing the major version and, as has been mentioned, Qt5 isn't a gigantic break from Qt4. I can definitely agree that debugging will be better than in Vala (and it'll be nice to have an officially-supported IDE that's neither Eclipse nor MonoDevelop for a language where Vim just isn't quite enough) but, as someone who normally programs in Python, PHP, JavaScript, or shell script, I can't usually justify the time cost of dropping to a level lower than languages like Vala and C#. (I don't count Java. They botched it too much.) It also worries me that, while I haven't fully kept up with Qt news, it seems that using QML/Quick as a glue language for building native desktop UIs won't be an officially-supported option until at LEAST Qt 5.1 (See https://qt-project.org/wiki/QtDesktopComponents). > Porting GTK+ applications to Qt shouldn't be too much hard but it > will require at least two things: > 1) if the application has own GTK classes those API interface should be > completely rewritten because in C++ classes have public and private > methods but in GTK each method is just a separate API (because it's C > after all); > 2) all calls to GTK APIs should be replaced with appropriate Qt calls, > also every GTK object should be replaced with appropriate Qt object. I > don't know yet if some list of appropriations ever exists. > Naturally. It only makes sense that, if you're porting to another language, you should do your best to follow the conventions and idioms of that language. Every Python programmer can probably name at least one case where they've had to put up with a wrapper for a C library that didn't do much more than exposing the C functions and constants to Python. I can definitely see how a list of equivalent classes and methods would help though. Maybe six months ago, on a whim, I decided to see look up the Qt equivalent of using asynchronous callback to incrementally load an image into a GDKPixBuf and it took a lot longer than it should to figure out what keywords Google wanted of me. > There may be some problems with the transition in case if Qt object > has no method appropriate to some method for similar GTK object. But also > opposite is right - some GTK parts may be simplified in transition if > Qt object has convenient method which is absent in GTK. True. For example, I believe Qt does a better job than Vala+GObject Introspection at providing a reasonably high-level API for various things. On the other hand: 1. Last I heard, GTK+ had integrated GIO so the GNOME-specific GVFS plugins could Just Work™ if dropped in at runtime while I don't think QNetworkRequest and KIOSlaves share the same level of runtime hot-swappability. (I may be wrong) 2. If you're doing something where 3D isn't just a gimmick, Qt has had support for embedding widgets in an OpenGL scene, complete with Wayland-style input transformation, for years while the GTK+ community was all excited when they arrived late to the party with Compiz-esque display-only 3D widget compositing. (That's why you can't do a full knock-off of OSX's Exposé in Compiz. It's apparently huge job to retrofit X11 to figure out what your mouse is actually pointing to in a composited desktop where transformations have been applied) > You're not the one who will need to learn it. But it seems we have no > other choice because GTK3 is a way to nowhere and we decided to not try > to support it because it require too big efforts without any benefits. Qt > seems to be a lot better alternative due to much more stable API. I'm a programmer, whether it's PySide, Qt Quick, or the bare C++ API, I'll have to learn it if I don't want to stick to writing PyGTK and Vala apps. (I'm part of that old/sane school of thought that web apps should be limited to things that inherently depend on the presence of a layout engine and/or network access. For example, TiddlyWiki.) ...though I'm currently in a bit of a "rock and a hard place" situation since there are plenty of GTK+-only desktops and PyGTK isn't too rare a thing to find already installed but few Qt-only ones and fewer with PySide installed, so I've been coding loosely-coupled GTK+ apps to minimize the potential for pulling in dependencies. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Pcmanfm-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pcmanfm-develop
