Higher level language to talk about software in than the programming language and a set of solutions to common problems in software engineering. Definitive book is Gamma et al book of four. They aren't algorithms, language features such as polymorphism, nor implementation patterns such as d-pointer and they aren't components such as toolkits.
You should use them because it makes you a better programmer. An experienced programmer will use them unknowingly already, by copying code or code layout from other projects or just implementing them yourself. But you probably will not have thought of this patters as a re-useable idea (nor given it a name).
KDE's DOM Implementation contains a lot of design patterns, sometimes hidden and not in their pure textual form. DOM::Document implements the factory method pattern. Almost all the DOM classes implement the Bridge pattern, also known as Handle. Unfortunatly he didn't show any UML diagrams (sell sell) so it was hard to get a clear pictures of these patterns. Node derived DOM classes implement the Composite pattern. EventListener? class implements the Observer patter, this is not usually found in KDE because of the Qt Signals/Slot mechanism. KSieve? ::Parser implements the Builder pattern, instead of construcing an explicit patse tree, it calls methods in the KSieve? ::SCriptBuilder interface, commandStart(), commandEnd() etc. This pattern could also be used for file format filters just be implementing and reusing the parser.
The null object pattern isn't yet used in KDE but can be used to stop having to check for the presence of a variable before using it.
To get your code to use design patterns you do refactoring. But that's another talk.
Some comments about whether UML would make using design pattern faster. They are independant of each other so you can use one without the other. Comment that it makes it easier to work with UML if you use patterns because you have less classes on screen. Umbrello doesn't have direct support for design patterns (nobody has asked for it either).
Design patterns aren't going to solve the world, they give you a tool but you still have to write the code and know where to use which patterns.
Accessibility is reducing the barriers of use for handicapped people. To be accessible, programmes and web sites must be useable with a reange of devices such as braille devices, screen readers, head point devices etc.
Showed us some accessibility features that can be configured from KConfig? , the setting of font sizes allows a larger font size, black and white colour themes he created - this misses out some lines because their colour can not be changed. Mouse speeds can be controlled. Keyboard sticky keys helps with pressing modified-key separately. Slow keys stops people who might accidently press a key. Bounce keys stops double presses of keys. It was pointed out that the help descriptions for these features is not very clear. Kdeaccessibility contains KMagnifier? which magnifies the screen contents and is usefull for people who need large magnifications, KMouseTool? which allows keyboard control of the mouse and KMouth? which speaks text, there are others in kdenonbeta.
KDE text to speech daemon is being developed in kdenonbeta and runs as a DCOP service. The plug in APIs? work with different systems. The API handles warnings, messages and controls for long texts which include starting, stopping and pausing the text. It was suggested that this should be integrated with KNotify? . Koolo said it would be good for reading Slashdot which he was busy getting dressed for example.
Important rules for people who use the computer slower or with different devices include not using hard coded timeout values, don't show or hide information based on the movement of the mouse pointer except tooltips. Make sure keyboard navigation is always possible including a logical tab order. There was discussion about the limitation of using tabs for dialogue navigation, ideally a keyboard would have dedicated navigation keys. Contrary all actions should be reachable by using the mouse, and make mouse targets large enough. Don't depend on having 3 mouse buttons because some accessibility mouse replacements only have one button, also think of us Mac users! Graphic attributes of widgets should never be hard coded.
KTrader? stores information on Servicetypes (such as Mimetype) and services (such as applications that handle that mimetype).
Query = ServiceType? + Constraint. A query to KTrader? will result in a list of services.
Servicetypes are defined in .desktop files with Type=ServiceType and X-KDE-ServiceType=KMyApp/Plugin
To write the plugin define a base class which implement's plugin and make it a factory using kgenericfactory which is a C++ template.
The ordering of the services can be specified by a field by the developer with a default of 1 but can be set higher. This has caused some conflicts (e.g. Karbon reading PS files). The user can also change the order of this, as you do with Konqueror file type preferences.
Very few people know how to debug trader results. ktradertest is a command line tool to run trader queries.
ServiceTypes? can have extra properties to give more information about them.
KTrader? uses ksycocoa database to quickly get its information.
Need to inherit from DCOPObject? and K_DCOP macro (make sure Q_OBJECT macro is above this not below). Best not to set all the public functions in your class as exposed by k_dcop, instead create another class MyInterface? which includes the methods you wish as pure virtual methods and exposes them all as dcop, make your class inherit this interface class.
Dynamic interfaces are possible too, these are used to export KActions? without explicitly adding all your KActions? as a real world example.
Custom DCOP types are possible but requires the header file for external applications to know about the type, this isn't possible with Python for example so it has limited uses (kaddressbook only so far).
es it much cleaner.
Scripting with DCOP means being careful about not expecting GUI elements, for example openDocument() can't call a fileOpen dialogue, so you need to separate it and create an openDocument(string filename) function that is called by openDocument() and can be used directly from a script.
Getting dcop application IDs? can be done with dcopfind, this will find the first application with that name. dcopstart will start an application for you and return a reference to it, this is more reliable because it won't interfere with your other instances of the application. DCOP services are non-GUI applications such as KDED, DCOPRSS means 5 instances of Konqueror only need download one RSS file which can be shared. DCOP Send doesn't block and calls every instance of the application running, used for shutting down KDE for example. DCOP Call is different from Send, it is not a broadcast and it gets a responce. DCOP Send and Call have been improved recently to remove the need for arguements being sent through a datastream which makes it much cleaner.
DCOP Send is not very efficient. DCOP Signals and Slots work similar to Qt signals and slots. Use k_dcop_signals: in the header file.
KScriptInterface? provides a way to embed DCOP automation into applications. Script engines provide language independence. A desktop file has data about the script including its type (shell, python etc) and a name. The type tells it which script engine to use. The desktop file also adds security because it can not easily be malitiously created.
DCOP provides GUI applications with script automation. KTextEdit? and others provide standard DCOP interfaces. It's available from popular languages such as shell and python.
Question about is there a moc equivalent for DCOP. Ian says there isn't, everything is done with calls to the DCOP server. kidl though does add some stubs, this is taken care of by the make system (blame Kulow if this doesn't work). Question about how the script knows the object name, these are typically known by the script writer beforehand. It would be nice if there was a standard DCOP interface for all media players, suggestion about a KTrader? type database that could be used to search for services. Complaints that you can't define a qt slot as a k_dcop function, moc can be confused by the order of the declarations but this should now be possible.
Using a GNOME desktop he appreciated being invided to a KDE conference. Havoc works at Red Hat on the desktop group and works on gnome-terminal. He started freedesktop.org which is mainly a mailing list and a website. It is a forum for projects to communicate. It is not a standards body and doesn't have the formal specifications method that w3c for example does. It doesn't release software. He hopes to make it into more of an open source project.
Examples of problems to be solves include a single help index, using the same URI space (for smb:// for example), more drag and drop issues, MIME associations. Some of this is at the KDE/GNOME level and some at the X level.
Platforms should be open, suitable for backends, well defined and specified, extensible and preferably allow ABI compatiblity with existing libraries. A minimal but complete philosphy is best.
This doesn't mean everyone should use the same APIs? or language. It isn't a merge of the desktop environments nor a starting from scratch approach.
An example is to see the same fonts and share font configuration. fontconfig is the answer to this and has prooved successful in being adopted. One of the reasons for its success is that one of the developers created patches for several projects. STSF is a similar project by Sun for Java Swing, because they havn't talked to other projects it has not been adopted (Sun now uses fontconfig on the back end).
A more difficult area is virtual file systems (kioslaves, gnome-vfs). gnome-vfs is too large for an API, he suggests splitting it up to have a very basic core and other features as optional interfaces.
Another example is IPC, gnome might be open to replaceing CORBA with another system or at least Havoc doesn't like it. D-BUS is a possibility, more tomorrow.
Configuration files, sysadmins should be able to configure all desktop apps in a uniform way. Gnome used GConf? . Possible idea of using LDAP.
Accessibility should work on all apps through a simple method.
The hope is to prevent fragmentation without restricting choice. Working together has produced better results than when working apart, see fontconfig or vfolder menu specification. It can also being innovation to the stagnant X server platform.
The future, a CVS server is being set up. A decision making process should be formalised. Be open to more participation
A humerous talk on Qt's development history, most of which I've forgotten because my laptop was charging at the time.
Qt 1 was released in 1996 and was quite small, it also had almost no customers. Qt 2 had styles and included the wood theme, which it was reported somebody used. Qt 2 was medium. Qt 3 was huge.
Qt 4 is smaller than Qt 3 in terms of startup speed but also the memory used. The template classes were previously a hack because Qt 1 had to use some due to lack of support for STL so future versions improved on that. Qt 4 makes them a lot better. It includes a lot of API tidying, anything deprecated is put in a compatibility module but will never be removed. The Qt library will be split up into a core "kernel" library, a widget library and several module libraries. The plan is that only a multi-threaded build will be available, although non-threaded versions might be used for debugging. It has double buffering for smooth updates on resizeing and moving windows etc. This is an admition of defeat, this feature should really be in the X server.
It's not known when Qt 4 will be available but pre-release build should be available "soon". When KDE changes to Qt 4 is not yet decided but past experience suggests as soon as possible (people were talking about after 3.2).
The reasoning for breaking binary compatibility again is that Qt must keep up with Windows Longhorn and Mac OS X for functionality.
Finally I learned that everyone seems to pronounce Qt as one word, qyoot, not qyoo-tee.
The talk on Zeroconf sounded interesting but the noble presuit of build systems came out as being more useful.
Link to the slides of this talk: http://www.blackie.dk/~dfaure/n7y/Makefile.am/index.html
Makefile.am has a complex syntax. Some of it works on tthe automake level and some is specific to KDE. To develop a new application use KDevelop? 3 (KDevelop 2 makes it messy), KAppTemplate? or attempt doing it with your bare hands (don't).
toolchain below
autoconf: configure.in -> configure }
automake: Makefile.am -> Makefile.in } Makefile.cvs does all this
KDE's am_edit: modified Makefile.in }
configure: Makefile.in -> Makefile
Makefile.am is easy to write, Makefile.in is generated but doesn't know anything about the machine paths and library locations. The above scheme is still simplified.
bin_PROGRAMS = kdialog [PROGRAMS means it's compiled, bin means it's installed in $KDEDIR/bin ]
kdialog_SOURCES = kdialog.cpp widgets.cpp
kdialog_LDADD = $(LIB_KIO) [can be -lfoo but usually just use variables]
kdialog_LDFLAGS = $(all_libraries) $(KDE_RPATH) [other arguments to the linker, $all_libraries is the -L paths to the libraries]
AM_CPPFLAGS = $(all_includes) [used to be INCLUDES, this is more generic and allows other things, this adds -I .h includes path]
lib_LTLIBRARIES = libkonq.la [I'm making a library and was it installed in the lib directory]
libkonq_la_LDFLAGS = $(all_libraries) -version-into 6:0:2 -no-undefined [version number scheme is very strange, no undefined means all symbols must be resolved, it is tested by linking into an empty main() ]
libkonq_la_LIBADD = $(LIB_KPARTS)
libkonq_la_SOURCES = popupmenu.cc knewmenu,cc
METASOURCES = AUTO
AM_CPPFLAGS = $(all_includes) [same as for binary]
Convenience Libraries
Shareing a source file between targets either put it in a convenience (static, not installed library) or a real (shared, installed) library. Don't compile it multiple times.
noinst_LTLIBRARIES = libcommon.la
libcommon_la_SOURCES = dirk.cc coolo.cc [usuallt no LIBADD or LDFLAGS]
mylib_la_LIBADD = libcommon.la
myprogram_LDADD = libcommon.la
Must contains $(all_includes), always after local -l paths
AM_CPPFLAGS = -I$(srcdir)/mylib $(all_includes)
$(srcdir) and . are always included automatically.
Can contain oter compilation flags -DNOBUGS (avoid -Wall -O2 etc)
KDE_CXXFLAGS additional compilation flags, appened /after/ the other flags KDE_CXXFLAGS = $(USE_EXCEPTIONS)
exceptions are diables by default because of the cost gcc adds for them. use KDE_CXXFLAGS rather than AM_CPPFLAGS because KDE_CXXFLAGS goes after and AM_CPPFLAGS will always disable exceptions.
include_HEADERS = foo.h [-> $(includedir) ]
kde_services_DATA = foo.desktop [->$(kde_servicesdir) ]
xdg_apps_DATA = app.desktop [-> $xdg_appsdir new menus]
directorydir = $(kde_datadir)/kbookmark
directory_DATA = directory_bookmarkbar.desktop
Global KDE dirs
KDE_ICON = AUTO
or Custom dirs
appicondir = $(kde_datadir)/myapp/icons
appicon_ICON = AUTO
Icon name in the sources is
Qt Designer UI files
foo_SOURCES = mydialog.ui
DCOP stubs and skls
.h file is in current directory
foo_SOURCES = client.stub server.skel [this will run kidl and generate the files]
if .h is in another directory
KDesktopIface? _DIR = $(top_srcdir)/kdesktop
foo_SOURCES = KDesktopIface? .stub
SUBDIRS = foo bar [ current directory is compiled last]
or
SUBDIRS = mylib . myplugins [to specify the order including current dir]
SUBDIRS = $(AUTODIRS) [adds all directories excluding CVS]
question about an $(AUTOSRC) variable to add all .cpp files etc. This doesn't exist and apparantly can't for complex reasons I missed.
Conditional subdirs - compile it only in certain cases.
if compile_KOPAINTER
KOPAINTERDIR = kopainter [name of subdirectory]
endif
SUBDIRS = foo bar $(KOPAINTERDIR)
configure.in.in can enable compile_KOPAINTER variable
AM_CONDITITIONAL(compile_KOPAINTER, ...)
For instance: test "$foo" = "yes"
A module's toplevel sibdirectories are autodetected, however ordering can be specified:
COMPILE_AFTER_kcontrol - kdm kdesktop
Or skip a directory:
DO_NOT_COMPILE = "$DO NOT COMPILE foobar"
The autodetection means you can check out and compile only one appliation from a module.
For the language of the documentation:
KDE_LANG = en
If the directories are application names:
KDE_DOCS = AUTO [man name of directory I'm in is the name of documentation directory]
KDE_DOCS = kcontrol/mouse [specify the directory to install it to]
messages:
in case of .ui or .rc files
mesages: rc.cpp
See David's Makefile.am howto
http://developer.kde.org/documentation/other/makefile_am_howto.html
http://developer.kde.org/documentation/other/developer-faq.html
Makefile.am also supports normal Makefile syntax and targets, the idea of them is to move away from them but they can be used for preprocessing needs.
Can a Makefile.am make .moc files for .cpp files, META_SOURCES = AUTO does the header files only, a manually-written Makefile rule would do it, but best to keep to only needing moc on .h files including private header files.
If $KDEDIR is set that will be used by configure, default it to /usr/local. complaint then that KDE won't find files there, thought is that people should set the configure --prefix but on the other hand other programs tend to work wherever they are installed which is why $KDEDIR exists, kde-config could be used in future for this. Also $KDEDIRS does some things.
EXTRA_DIST is used so `make dist` works, this is to make packages without any generated files. If it doesn't exist it is done automaticaly so best not to use it because it can get out of date.
Stephan is the guy who understands this magic.
Everything relies on Make, includes rules and dependencies, macro language is built in but mostly unused by KDE and it's not portable (GNU is different from BSD).
Projects have a nested directory structure, directories can be for icons documents, most directories have only one target e.g. binary or library.
Automake is what people call the build system which they hate, actually what they hate is autoconf which makes portable shell scripts.
Makefile.am should be in every directory. Uses simple variable assignments to describe targets.
Problems of automake, based on recursive make through SUBDIRS, but makes it easy to use GNU standards.
Most developers think that recursive make is the way it has to be. Describing targets on a per directory basis is easier to maintain and understand. Qt has one large Makefile for all it's directories, very hard to maintain. Recusion add huge overhead to the problem. Inter-target dependencies can only be specified through the order the subdirs are listen in, usually fine but can cause problems. Real problem of recusion is it limits parallel make, Qt can compile 30 jobs at once with teambuilder KDE however has only one directory at a time. Parallel make needs more sources in one directory which removed structure from the source. Automake advantage is that you can build only one program at a time by cd into that apps source directory and running make from there.
Recursive make considered harmful (a paper from 1997 when automake wasn't so popular). Needs to recuse through every directory starting the process again and again. All of kdecore needs to be built before kdeui starts because parts depend on static stuff in kdecore. Can't build parts without knowledge of the whole thing.
Using automake is still better than other solutions. Biggest problem is does the developers understand it. KDE is a desktop environment and not a build system however KDE specific feaures have been added because so many problems have been found.
Replaced a script called Automoc.
am_edit is a perl script which patches the automake generated files (Makefile.in) and expands things automake didn't understand e.g. METASOURCES. Effectivly we're using automake++.
He joked that George thought the system worked as: write Makefile, commit to CVS and wait for it to be fixed.
Kulow tried to re-write am_edit as python but it was too slow and almost as messy. teambuilder and distcc's increasing popularity highlight problems of recursive automake.
name is short for unser (replacement for auto)make, German (means "our"-make). The name is as bad as his meinproc he said.
Reads Makefile.am syntax but creates very different output. Creates all rules and dependencies relative to the toplevel so that make doesn't need to recurse. All dependencies are known to one run of make so parallel makes can take advantage of it. Problem was notbeing able to compile from a subdir so...
creates 3 files in each subdiretory
Makefile.in, Makefile.rules.in, Makefile.calls.in (last one for custom largets) included by each other to override variables and allows building from subdirs (hoorah!).
New feautres: make mocs, make compile (for teambuilder), make install is incremental (can be called twice and won't install anything the second time), make $KDEDIR/bin/kwin, based on plugins (because everyone uses plugins, make random to test dependencies and extra error checking for broken makefiles.
Showed some graphs which showed how unsermake is faster than automake especially on an SMP machine. Then he showed us a screen shot because everyone likes screen shots, it showed lines such as
Problem to adoption is that unsermake has strict error handling unlike automake and people keep adding Makefile.am's which break it.
He's not necessarily keen on switching immediatly but is there for those who want to use it.
unsermake makefiles havn't been tested on all possible platforms whereas Automake ones are more tested. More testing needs to be done before it can be widely adopted. It's in kdenonbeta, not in kde-common because that would make everything larger.
An extension to Object Orientatoin adding new concepts, requires new tools. It isn't a replacement for object orientation, just adding new concepts. Example of KGet? functions with debugging code in them, this is duplicated code and error prone, it's unrelated to the functionality of the method. Other examples include synchronisation, logging code, persistence and exception handling.
New entities, an aspect (the crosscutting code, e.g. logging or debugging), a Connector defines the join points e.g. all methods beggining with setX. aspect code can be inserted statically at compile time or dunamically at run-time (allows adapting existing libraries/classes without changing their source code).
Aspects are represented by a team, a collaboration of objects. Role-objects adapt the behaviour of normal objects.
AspectC? ++ is mostly normal C++, compiler weaves aspect code into the base code at compile time.
Connector defines where aspect code is put using join-point specification. Can be at method calls, method-implementations, member access (read or write), inheritance structure or control flow. Benefits include modularity, isolation, composition and reuse.
AOSD == aspect orientated software development
Still a topic of research and development, compiler is available but IDE support and debugging and modelling/designing missing.
http://www.objectteams.org
http://www.aspectc.org
Use it where it makes sense (problem is you need to find out where it makes sense).
D-BUS is an attempt to create an IPC system shared among GNOME and KDE and other frameworks. It would complement or replace ORBit? or DCOP. It has the ability to be used system wide rather than just within a desktop. Hope is to get feedback and find people willing to work on KDE wrapper for it.
Suggestion that the bus is built in two layers, libdbus allows communication between two applications directly. This is like libICE but nicer. Layer 2 is a Bus Daemon application to route messages.
Protocol is just a stream of messages. It includes a header (type, flags, method, length) including named non-fixed header fields (interface, method) and then the body which is the call arguments. Authentication is with SASL.
Implementation is done in C, has no dependencies, small size. There is a specification so it's not necessary to use this implementation.
Bus daemon is an application using only the public API of the libdbus IPC library. Unlike app-to-app communication it provides services, activation of services, broadcase, lifecycle.
Daemon can be system bus or session bus. System bus examples get IPSEC password, get bluetooth PIN, print queue changed, hotplug device messages, errors/logging. The configutation file defines security policy of what and who can connect.
Reasoning: valuable to use in base platform of all distributions, basis for shareing code in other areas such as a11y. Use the same code and same overhead for both per-session and system messaging. It would be an assumed part of the platform which every app can use from the login manager to the CUPS daemon to konqueror. Should be scaleable.
Use dbus as ICE equivalent, tunnel DCOP though dbus, sync dbus exactly to DCOP semantics and port DCOP API to map to D-BUS, write a dcop/dbus bridge layer, create a new parallel API similar to DCOP or combination of above. Timeframe would be KDE 4.
Link to the slides of this talk: http://www.blackie.dk/~dfaure/n7y/Debugging/index.html
Basics: debug output (kdDebug, printf), debugger gdb ( http://developer.kde.org/documentation/other/gdb-doc.html ), runtime backtrace printout ( http://blackie.dk/~dfaure/qbacktrace or kdBacktrace() ), traceing strace.
Valgrind finds memory management problems: use of uninitialised memory, reading/writing free'd memory and out of bounds memory, memory leaks, mismatched use of malloc/new/new[] with free/delete/delete[], some abuses of POSIX pthread API. Free Software. http://developer.kde.org/~sewardj
Valgrind is a CPU emulator, binary runs inside Valgrind. x86 only. Slows down program by factor of about 15.
int g;
int h = g; //allowed but bad practice
if (h) //uninitialised
int myArray[10]
myArray[10] = 0 //out of bounds access, not detected because it's all on the stack, can't be detected by valgrind
See what takes time to do what.
Can be done by hand by starting a QTime? and printing out how long it takes.
Cachegrind and KCacheGrind? makes valgrind log all calls happening in the program. Use as valgrind --skin=calltree
TreeMap? widget in kdenonbeta/fsview shows an area proportional to value of interest, cachegrind shows instruction count per method, konqueror can show file size.
strace traces system calls, see why you get deadlock or crash if it is caused in a system call.
ltrace shows the function call in a program, helps understanding the program execution. Pipe C++ programs though c++something which tidies up the output for c++ programs.
re-read the source and think the concepts, don't rush into a debugging tool. Then use for crashes gdb, valgrind, unsure of behaviour use valgrind and kdDebug(), for slowness use QTime? or cachegrind, understanding execution flow use kdDebug() kdBacktrace() and cachegrind which logs all method calls viewable in kcachegrind. Then fix it.
The widescreen Mac laptop confused the projector.
KWallet? is used to store secure data, passwords and cookies for example.
Wallets can store any bits of data. Wallets can easily be copied to be put on a USB key for example.
KWallet? has a simple configuration module.
Backend handles all wallet file I/O. Wallet service is the only user of the backend tracks user applications via DCOP. Provides handles to wallets.
Question and admition that malitious code could get into this. Suggestion that a log of accesses is a good idea. Features include closing idle handles or ones where the application is closed.
slides http://www.staikos.net/~staikos/
Advert for Staikos Computing Services
Slides at http://ktown.kde.org/~danimo/kastle/talk/.
Papers at http://ktown.kde.org/~danimo/kastle/talk/kontact.txt
This seems to be yet another sound server.
No talk was prepared and he had some bother with using Acrobat (well that's non-free software for you) on Red Hat (wheesh Charles, no slagging Red Hat) running GNOME (tsk tsk).
Note: make sure you don't have caps lock set when using `su`, it won't find su and your password will be displayed in very large letters on the projector. :-D
We then got some classical operatic music. MAS is reading two music files and running the mixer but uses little CPU time. A live diagram showed the units of MAS and their data processing pathways. MAS can go over a network in the same way as X can. Built on RTP to use existing standards.
MAS is a collection of modules for devices with interface conditions that are glued together. The work is in creating the data pathways through an `assemblage`.
Currently it makes sound and it distributes, it runs on Red Hat and ran on SuSE? without any problems. Also ported to solaris on Sparc and being ported to AIX and Windows. Windows version is not publicly available other versions are.
There was a demonstration of an accessibility application where menu items were read out, this application took less than a day to make.
It's not threded and runs only in one process.
This is 5 years of solid work done by 4 people. ANSI C code. Under MIT licence. A new standard from X.org reformed organisation following OSF.
His presence is sposored by X.org in the hope of closer relation between KDE and X.org. X.org is being changed so membership is at no cost and so it is easier for non-US contributors.
MAS is a small group of developers and not really an "open source" project because of lack of encouraging participation. That should change. They are activly looking for active participants in the process. X.org recognised 5 years the lack of sound and media support. MAS can also process video data but currently needs the codecs.
MAS should be like X as a common mediary. An X server extension does synchronisation.
Unlike esd (and presumably artsd but he didn't say) it doesn't "suck".
This will be shipped with X and the standardisation will be open (announcement on October 1st).
This is a sad story of two young programmers who were fed up with the Unix desktop in 1996. One was famous for Lyx and the other for the first port of StarOffice? to Linux. They had their futures infront of them. Now they qualify for the kde-oldies mailing list and became pointy haired. One of them didn't know how to use KPresenter? .
First sign of life was October 14 1996, Matthias Ettrich sent his posting to usenet. ("Does everyone still know was Usenet is? The IRC of the mid-90s"). KDE stands for Kool Desktop Environment not Kalle Dalheimer Experience.
He expected the first version to be available for December of that year, talk about bad project planning.
Matthias of course doesn't have any connections to Trolltech (other than being employed by them).
fiwi02 was the first KDE machine. fiwi is Economic Sciences, hijacked from an unrelated department because of Martin Konold. Koolo later highjacked other machines. Sirtaj Singh Kang was praised.
Three days later Kalle's son was born, KDE developers were among the first to congratulate.
Four days in the first result was a mock-up of the panel, now lost. Matthias wrote the first window manager and panel.
Kalle and Martynas wrote the first library class which was KConfig? (little changed). To instansiate KConfig? they created KApplication? .
Torben Weis and his 5 clones (Torben was so fast they believed he has some extra coders helping him) wrote kfm.
When Kalle wanted to release KConfig? and KApplication? in November he found packageing was harder than he thought (Kalle later went on holiday and temporarily gave build systems to Kulow, one of the best holidays he's had).
Before Christmas kwm and kpanel were released then kfm.
Soon the (well deserved) GPL flames came in. GNUStep? followers also complained (GNUStep will be out soon, just after they fix the Objective C compiler).
In 1997 the KDE-FreeQt contract was signed by Kalle and Matthias. This contract was signed sitting on the sick bed of the president of Qt.
First conference was in May 1997 with a talk at the Linux Kongress in Germany, a big success. Two (specially flown in) Brazillian members of Offix project declined to give their presentation after seeing how far KDE has come. The idea of a KDE meeting came from this.
In August c't published the first magazine article about KDE. About 10 people put up their hands to admit being attracted to KDE by this article. Screenshots showed KControl , panel and lots of games.
KDE One conference took place from August 28 to September 1 in an adult education institution in Germany. The local town subsidised the conference and in return they had to get a tour of the town. It was a very boring tour. An lady with an aweful hat spoke for 5 minutes and had to be translated all at once. A picture of that conference showed a dozen developers and Tux (no Konqui). The picture included a dustbin to reflect a paticularly bad flamer who ended his e-mails with KDE->dustbin. KDE e.V. was started to take the finantial risk of the next meeting away from Kalles not very large wallet.
That conference created mime-type detection, i18n (KPaint was the first i18n'd application), drag and drop stabalised, moving titles in windowbars (when Matthias was drunk). The press conference was attended by 2 local reporters, but KDE wouldn't start up because /etc was missing localhost something distributions didn't set up back them.
Meanwhile Diana Spencer died and the GNOME project started. Miguel had done mc and sparc linux port. Mattias rejected one of his patches for KDE which allowed key bindings for kwm to be changed but which didn't use KDE libraries. Miguel was so angry at the rejection that he started his own desktop environment.
Beta releasess were named after German towns (Arnsberg, Kaiserslautern) and KDE 1.0 was released on July 12 1998. KDE 1.0 contained the CORBA based KOM/OpenParts and kdm, KMain? , krn.
Corel donated some hardware and became a major player in KDE for a time. KDE 1.1 was in March 4 1999. Much better icons (even then icons were replaced with every release). That year KDE for the Innovation of the Year award at CeBIT? annoying the Virtual PC developers and some other programme from IBM.
KDE Two meeting too place in October 1999 organised by SuSE? and Caldera. Chievements were KParts? (called Kanossa), DCOP (when Matthias and Preston Brown got drunk and said they could write a better ORB in one night). arts (which had only CORBA communication so he wrote a TCP based server in one night) and sycocoa by Waldo Bastion (alternatice name was System LookUp? Table but they didn't like the abrieviation). Kulow was chosen as the voting officer for the KDE e.V. board member elections because he was from East Germany and knew best how to forge elections.
Kulow was a student at a medical university. The first CVS server was his workstation then the NFS server for 500 students which got him called to the Dean's office but on good terms because it got the university in the press. In February 2000 it was moved to sourceforge on a machine named bluemchen which Kulow chose after a 16 year old German female singer.
Kalle said that Richard Stallman ridiculed himself by saying after Qt went GPL KDE still had to beg forgiveness. This shows that KDE developers still haven't bothered to read the GNU GPL. (It's been pointed out that GNOME needs to beg forgiveness for linking against OpenSSL? but they haven't.)
In July 2000 there was a hacking session in Norway. No new feature policy led to major changes to the look, dcop command line tool and GUI clients. Cabin was chosen because it was desribed as having 2 ISDN lines and free phone calls (only one phone call was made, quite long though). Meeting was called K3B, B for beta.
In September 2000 a KOffice? meeting was held in Germany and sponsored by the German Ministry for Education, the first major commitment of the German goverment to KDE. On October 23 2000 KDE 2 was released with Konqueror, KParts? , KIO, KOffice? , artsd, themeing, XDND, DCOP. Konqueror was the first web browser to implement CSS 2. Position Release Dude was introduced (a term borrowed from Miguel de Icaza).
KDE attended several trade shows in 2001. A photo of Konqui using GNOME shocked the crowd. A photo of Martin with a belly dancer gave further shocks.
In March 2002 KDE-Three was held in Nuremberg. This held up the SuSE? release for 2 weeks.
In April 2002 KDE 3.0 was released with KDEPrint? , flash in Konqueror, JavaScript? , IMAP, KOrganiser? , kdeedu and KDE Kiosk.
In August 2002 KDE e.V. met in Hamburg. There was a hope for another KDE meeting in August 2003.
Design Patterns in KDE, Marc Mutz
KDE and Accessibility - Gunnar Schmidt
KTrader - Writing a plugin system, David Faure
Link to the slides of this talk: http://www.blackie.dk/~dfaure/n7y/Trader/index.html
DCOP scripting, Ian Geiser
Havoc Pennington, freedesktop.org
Qt: past - present - future Matthias Ettrich
How to Write a Makefile.am, David Faure
Makefile.am for a simple program
[$KDE_RPATH hard codes paths to libraries, although it will fall back if they arn't there]
METASOURCES = AUTO [Qt moc generation]
Makefile.am for a library:
More on AM_CPPFLAGS
Installing data files
Custom dirs
Icons
Other types of source files
Subdirs
Module Toplevel directories
Documentation
i18n
$(XGETTEXT) *.cc *.h -o $(podir)/libkonq.pot
[not automaticly done because there are lots of different cases]
$(EXTRACTRC) */*.rc >> rc.cpp
$(XGETTEXT) *.cpp
message generation is run every night, coolo gets all the errors from the script so test it first to not annoy him:
make -f admin/Makefile.common package-messages
Requires a patched gettext from ftp://ftp.kde.org/pub/kde/devel/gettext-kde
KDE Build system or Into Hell and Back, Stephan Kulow
am_edit
Unsermake
Unsermake recursive non-recursion
compiling ./amor/main.cpp
which is a lot cleaner than raw gcc command. It's also possible to display the gcc command line. It also shows warnings and error if there are any.
Aspect Orientated Technologies - Ready for Adoption? by Carsten Pfeiffer
D-BUS, Havoc Pennington
Approaches to adopting
Debugging howto, tips and tricks for developers, David Faure (again)
g = 2;
int* foo = new int[42];
delete foo; //should be delete[] foo
Profiling
Tracing from outside
Summary of debugging
How to write good network transparent code by David Faure
Link to the slides of this talk: http://www.blackie.dk/~dfaure/n7y/KIO/index.html
KWallet by George Staikos
Kontact, Daniel Molkentin
MAS - Media Application Server
The history of the KDE project - From fiwi02 to Kastle, Matthias Kalle Dalheimer