Benjamin Meyer ben at
Mon Jun 7 01:13:50 BST 2004

Hash: SHA1

Your typical KDE application does a number of the exact same things.  The 
biggest thing that drew my attention was the Configure dialog.  Now we have 
KConfigXT which removes that from the programmers list of basic things that 
have to be re-implemented.  Every application used to manually turned on/off 
their statusbar in out of which createStandardStatusBarAction() was added in 
3.2.  The key shortcuts also was typically a one line function, but with the 
addition of  configureShortcuts in guiFactory in 3.3 this no longer needed.  
Although most application add setAutoSaveSettings() by default I still find 
applications that manually store the width/height of the window simply out of 
lack of knowledge about the function.  
	Now that we have a number of simple functions that can handle the basic 
actions we are finding that application after application have the same half 
dozen or so function calls.  Some call them have default values that are 
unnecessary and some forget one or two of the functions, but most of the time 
they are simply stuck in like stubs.
	This brings us to createStandardKWindow()  It is a simple function that I 
would like to add to KMainWindow (Yes I know this is a week late and I will 
close a dozen bugs as a penalty)  First off why shouldn't this stuff be added 
to createGUI or to the constructor?  Doing some testing with that I found 
that difficult to catch all cases.  The simples was how to know if the 
developer already had a shortcuts action.  Can't be in the constructor sense 
there are no actions than and it can't be in createGUI sense they might have 
named it something other than the standard name from stdaction.  This leaves 
adding a new function which once was finished works out really well.   
	For the typical application createStandardKWindow() replaces the line where 
createGUI() is located and also allows the removal of a bunch of others.  If 
for example you don't have a toolbar you pass in the first arg of false.  
This makes the change source compatible in the sense that it doesn't change 
anything unexpecently unless the developer makes the change.

Rather then go into detail of what it does here is the function doc

     * Configures the current windows and its actions in the typical KDE
     * fashion.  The options are all enabled by default but can be turned
     * off if desired through the params or if the prereqs don't exists.
     * Typically this function replaces createGUI().
     * @param toolbar adds action to show/hide the toolbar(s) and adds
     *        action to configure the toolbar(s).
     *        @see setStandardToolBarMenuEnabled()
     * @param keys adds action to show the key configure action if any actions
     *        are in the actionCollection() and the action 
     *        options_configure_keybinding doesn't already exists.
     * @param statusbar adds action to show/hide the statusbar if the
     *        statusbar exists.
     *        @see createStandardStatusBarAction()
     * @param save auto-save the toolbar/menubar/statusbar settings and
     *        window size using the default name.
     *        @see setAutoSaveSettings()
     * @param create calls createGUI() once all of the above params have been
     *        taken care of.
     *        @see createGUI()
     * @sinse 3.3

Some possible changes:

1) Rather than a number of bools for params have only two params.  The first 
being params disabled, and the second being enabled ones (or'd together).  
This way you can turn off one or two things you don't want, but in the future 
as new things are added they will work by default.
2) Rather than looking for options_configure_keybinding if keys is true and 
actions->count() > 0 add?
3) createStandardKWindow() Name it something else? createKMainWindow()   
createStandardKMainWindow()  createStandardWindow()  ?
2) Am I missing anything else that this function should do out of the box?

This function is entirely about creating a consistant interface for users 
(while also reducing the code developers have to implement in their 
application).  By default the window will remember where they were, their 
size, and users can configure everything action related which isn't always 
true currently. 

Feedback/comments welcome.

- -Benjamin Meyer

- -- 
Public Key:
Version: GnuPG v1.2.4 (GNU/Linux)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: diff
Type: text/x-diff
Size: 6107 bytes
Desc: not available
URL: <>

More information about the kde-core-devel mailing list