[Main Page] [KHello #1] [KHello #2] [KHello #3] [KHello #4] [KHello #5]

Hello World - fifth version

In this final installment of our greeting application (doesn't that sound like a machine for taking your hat off for you?), we will add a menubar. As Daniel has remarked, only a small step for a programmer, but a large step for humanity, or at least the part that uses computers.

#!/usr/bin/env python

import sys
from kdeui import KApplication, KTMainWindow, KMsgBox
from kdecore import kapp, Icon, i18n
from qt import QPushButton, QPopupMenu, SIGNAL

class khello(KTMainWindow):
  def __init__(self):
    self.quit =QPushButton("Quit",self)

    self.file.insertItem("&Hello", self.slotHello)
    self.file.insertItem("E&xit", self.slotQuit)
    self.help=kapp.getHelpMenu(1,"Hello World! Python Tutorial by Boudewijn Rempt.")
    self.menu.insertItem("&File", self.file)
    self.menu.insertItem("&Help", self.help)


    self.connect(self.hello, SIGNAL("clicked()"), self.slotHello)    
    self.connect(self.quit,SIGNAL("clicked()"), self.slotQuit)
    tb = self.toolBar() 

  def slotToolbarClicked(self,item):
    if item == khello.TOOLBAR_EXIT:
  def slotHello(self):
    KMsgBox.message(self, "Important", "Hello World!")
  def slotQuit(self):
  def closeEvent(self, QCloseEvent):
app=KApplication(sys.argv, "Hello World!")

So, what's happening here? Every menu in the menubar is a separate object, of the type QPopupMenu. Of course, as everybody knows, all applications have to have at least a file menu that can be used to close the application, and a help menu to aid the user. Another almost obligatory menu is the edit menu, but we dispense with that one, since there's little to edit in our application.

The first menu, according to the programme just laid out, is the file menu. It is defined as a QPopupmenu, and gets two members. Those items, hello and quit, are defined by the name they show in the menu, and the slot they call when clicked. The & means the following letter will be underlined and can be used as an accelerator key. That's nearly universal, by the way. The slots our menu items call have already been defined, so that won't cause any headaches. Redundant access to functionality is what a good gui is all about.

The help menu is rather interesting. This is one of those places KDE provides a real standard. Every KDE application has a help menu with an item that calls the html help, an item that calls an about box for the application and an item that calls the about box for the whole of KDE. That menuy can be retrieved by calling kapp.getHelpMenu. The first parameter, 1, is again Pythonese for TRUE, which means the menu is enabled. Try it out...

Of course, if those popupmenus don't know where they belong, they won't popup much, so we insert them into our application-wide menubar, of which there may only be one in the whole of the KTMainWindow. The KTMainWindow already provides us with access to that menubar. If you'd try the previous version of this tutorial, the one for version 0.6, you'd notice that the toolbar appeared on top of the menubar, when the menubar was instantiated as a separate item with:


If we'd be working according the rules, we'd have to define a central widget that takes the place of the the area between toolbar and statusbar (or window-bottom), and set the KTMainWindow's view to that widget. If we don't do so, we can put the buttons under the menubar. Try to give the buttons an y coordinate of 0...

And this concludes the first exercise in Python + KDE application building. I hope everybody finds it as easy going as I did, and remember - I'm just a novice, too, so what I can do, you can do too.