Rename remnant files and references from kinit -> tdeinit.

1 files changed, 84 insertions, 0 deletions

diff --git a/tdeinit/README b/tdeinit/README
new file mode 100644
index 000000000..644efbaf6
--- /dev/null
+++ b/tdeinit/README
@@ -0,0 +1,84 @@
+README
+
+tdeinit is a process launcher somewhat similar to the 
+famous init used for booting UNIX.
+
+It launches processes by forking and then loading a
+dynamic library which should contain a 'main(...)'
+function. 
+
+Executive summary
+=================
+
+Using tdeinit to launch KDE applications makes starting
+a typical KDE applications 2.5 times faster (100ms 
+instead of 250ms on a P-III 500) It reduces memory 
+consumption by approx. 350Kb per application.
+
+
+How it works
+============
+
+tdeinit is linked against all libraries a standard KDE
+application needs. With this technique starting an
+application becomes much faster because now only
+the application itself needs to be linked whereas 
+otherwise both the application as well as all the libaries
+it uses need to be linked.
+
+Startup Speed
+=============
+
+Starting an application linked against libqt, libtdecore and libtdeui
+in the conventional way takes approx. 150ms on a Pentium III - 500Mhz. 
+Starting the same application via tdeinit takes less than 10ms.
+
+(application without TDEApplication constructor, the TDEApplication 
+constructor requires an extra 100ms in both cases)
+
+Memory Usage
+============
+
+An application linked against libqt, libtdecore and libtdeui started
+in the conventional way requires about 498Kb memory. 
+(average of 10 instances) If the same application is started via
+tdeinit it requires about 142Kb. A difference of 356Kb (application 
+without TDEApplication constructor) 
+
+If we take the TDEApplication constructor into account, an application
+started in the conventional way takes about 679Kb memory while the same
+application started via tdeinit requires about 380Kb. Here the difference
+is somewhat less, 299Kb. This seems to be caused by the fact that the
+dynamic linker does "lazy linking". We can force the linker to link
+everything at startup by specifying "LD_BIND_NOW=true". When tdeinit is
+started with this option on, tdeinit is back to its full efficiency, an
+application with a TDEApplication constructor now uses 338Kb of memory.
+A difference of 341Kb with the normal case.
+
+Adapting programs to use tdeinit.
+===============================
+
+The sourcecode of a program does not require any change to take advantage
+of tdeinit. Only the makefile requires an adaption, if the Makefile.am of 
+a normal program looks like this:
+
+bin_PROGRAMS = kicker   
+kicker_LDADD = $(top_builddir)/libkonq/libkonq.la
+kicker_LDFLAGS = $(all_libraries) $(KDE_RPATH)
+
+The following lines need to be added to make a library version useable 
+by tdeinit:
+
+lib_LTLIBRARIES = kicker.la
+libkicker_la_LIBADD = $(top_builddir)/libkonq/libkonq.la
+libkicker_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module                    
+
+Disadvantages
+=============
+
+The process name of applications started via tdeinit is "tdeinit". This problem
+can be corrected to a degree by changing the application name as shown
+by 'ps'. However, applications like "killall" will only see "tdeinit" as 
+process name. To workaround this, use "kdekillall", from tdesdk/scripts,
+for applications started via tdeinit.
+