There's been some discussion on the kde-core-devel list this week about whether or not the KDE classes should be renamed for KDE 4.0. Should the class KMainWindow become MainWindow inside a KDE:: namespace for instance? Some people preferred it, and others thought it was a bad idea.
For the perl and ruby bindings we've already gone ahead and renamed the K* classes, and the Qt classes such as QWidget are similarly renamed as Qt::Widget. Here is an example top level using the fully qualified names:
about = KDE::AboutData.new("knotifywidgetbase", "KNotifyWidgetBase", "0.1")
KDE::CmdLineArgs.init(ARGV, about)
a = KDE::Application.new
w = KNotifyWidgetBase.new
a.setMainWidget(w)
w.show
a.exec
Or does this look better?
include KDE
...
about = AboutData.new("knotifywidgetbase", "KNotifyWidgetBase", "0.1")
CmdLineArgs.init(ARGV, about)
a = Application.new
w = KNotifyWidgetBase.new
a.setMainWidget(w)
w.show
a.exec
If you use both 'include Qt' and 'include KDE' you need to fully qualify Application, to disambiguate between QApplication and KApplication. I hadn't actually tried using 'include' with ruby until this morning, but I think it does make the code look clearer and prettier once you've got used to it.
Syndicate Blogs
Re: signals and slots
How does this work with signals and slots and the naming used there?
Good point - at the moment you have to use C++ types when you declare slots like this:
slots 'goToURL(const QString&)', 'openURL(const KURL&)' ... def goToURL(url) url = "http://#{url}" unless url =~ /^\w*:/ openURL KDE::URL.new(url) end def openURL( url ) puts "in openURL #{url}" @part.openURL url @history.unshift url unless url == @history[0] end ... Qt:: Object::connect( doc.browserExtension, SIGNAL("openURLRequest(const KURL&, const KParts::URLArgs&)"), ph, SLOT("openURL(const KURL&)" )It's a bit ugly, although the slots themselves are just normal ruby methods. So it would be nice to have a more rubylike syntax for slot type declarations:
slots ':goToURL String', ':closeURL URL'But a ruby include statement or slots declaration is a 'compile time' feature. Whereas types inside connect statements are evaluated at run time, so I expect they will always need to be fully qualified with Qt:: or KDE:: like this:
Qt:: Object::connect( doc.browserExtension, SIGNAL(":closeURLRequest KDE::URL, KParts::URLArgs"), ph, SLOT(":closeURL KDE::URL" )PS: It would be nice if the kdedevelopers 'auto-smiley' feature didn't work in text marked with a 'pre' tags. It didn't like :openURL, oops..
Now imagine that Qt became namespace'd too
Now imagine that Qt became namespace'd too - those who'd been using the using directive to deal with the KDE namespace suddenly have a problem - if they use it Qt as well they now have 2 Applications. So, of course you need to make it KDE::KApplication and Qt::QApplication to handle this. Now things look ugly for those who don't use using.
'Prettiness' is not a good enough reason to do something in a real-world project like KDE. It is fine for an accademic project, but that is not what KDE is about.
Actually...
Actually that's one thing that I really like about namespaces -- it makes it easy to construct logical "is a" relationships.
i.e. in TagLib I have:
TagLib::File
-> TagLib:: MPEG::File
-> TagLib:: Ogg::File
-> TagLib:: Ogg::Vorbis::File
-> TagLib:: Ogg::FLAC::File
(Sorry for the spaces between "::" and "Ogg" -- otherwise it gets turned into an emoticon.
)
Now if you actually had to refer to the whole qualified name that would of course be tiresome. But almost always you're working in a context that implies one of the specific "File"s. In the cases where you're not having such a clear distinction is quite nice.
So i.e. in an implementation file you might have something like:
using namespace TagLib; using namespace MPEG; // ID3v2 implementation ID3v2::Tag::Tag(File *f) : Tag(f) { // ... }But then:
using namespace TagLib; using namespace std; static void printStuff() { MPEG::File mp3("foo.mp3"); Ogg::Vorbis::File ogg("bar.ogg"); cout << mp3.tag()->title() << endl; cout << ogg.tag()->title() << endl; }It really gives the programmer more control over how much information he wants to pack into the name.
You also seem to be forgetting that it's not necessary to import an entire namespace with the using directive. You can import just the members that you're actually using and then resolve ambiguities by using qualified names.
On the whole I'm not convinced that it's the way to go, but the people making cases against namespaces really seem to be making pretty bad arguments.
Re: Now imagine that Qt became namespace'd too
‘Prettiness’ is not a good enough reason to do something in a real-world project like KDE. It is fine for an accademic project, but that is not what KDE is about.
Well, I'm talking about the ruby bindings and 'prettiness' is certainly a reason for doing those for me - it is a beautiful language. I hope Free Software hackers are allowed to find things 'pretty'
. In ruby you have Qt::Application and KDE::Application, which doesn't look bad like Qt::QApplication and KDE::KApplication.
On the other hand, with C++ I agree the core developers should certainly do the most practical pragmatic thing they can. Things like backwards compatibility are more important in the real world.
What are the trolls planning?
I don't want different practices for KDE and Qt. If Qt gets namespace'd, KDE should too. Otherwise, just K it.
Re: What are the trolls planning?
No change in Qt4 as far as I know - I think they're splitting Qt up into libraries, but not namespaces. I would be very surprised if Trolltech ever dropped the Q from their class names as it would break too much code. I expect the most likely thing is we'll end up with QWidget inside a Qt:: namespace, and KApplication in a KDE:: namespace, and the classnames unchanged.
But backward compatiblity cou
But backward compatiblity could be easily maintaned:
typedef Q::Widget QWidget;
Well, at least source compatiblity (because typedefs are "aliases" and I think in a lib this would expand to Q::Widget).
Signals and slots
How does this work with signals and slots and the naming used there?