You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
tdebase/kpersonalizer
Timothy Pearson 77cbe84cb6
Rename additional header files to avoid conflicts with KDE4
12 years ago
..
pics [kdebase] initial cmake support 14 years ago
CMakeLists.txt Rename a number of libraries and executables to avoid conflicts with KDE4 12 years ago
Makefile.am Rename a number of libraries and executables to avoid conflicts with KDE4 12 years ago
README Rename kwin to twin (part 1 of 2) 13 years ago
TODO Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. 15 years ago
cr16-app-kpersonalizer.png Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. 15 years ago
cr32-app-kpersonalizer.png Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. 15 years ago
kcountrypage.cpp Rename additional header files to avoid conflicts with KDE4 12 years ago
kcountrypage.h TQt conversion fixes 14 years ago
kcountrypagedlg.ui Remove additional unneeded tq method conversions 13 years ago
keyecandypage.cpp Rename additional header files to avoid conflicts with KDE4 12 years ago
keyecandypage.h Rename KCModule, KConfig, KIO, KServer, and KSocket to avoid conflicts with KDE4 12 years ago
keyecandypagedlg.ui Rename a number of classes to enhance compatibility with KDE4 12 years ago
kfindlanguage.cpp Rename additional header files to avoid conflicts with KDE4 12 years ago
kfindlanguage.h Trinity Qt initial conversion 14 years ago
kospage.cpp Rename additional header files to avoid conflicts with KDE4 12 years ago
kospage.h Rename KCModule, KConfig, KIO, KServer, and KSocket to avoid conflicts with KDE4 12 years ago
kospagedlg.ui Update kpersonalizer style string 13 years ago
kpersonalizer.cpp Rename additional header files to avoid conflicts with KDE4 12 years ago
kpersonalizer.desktop Branding: KDE->TDE 13 years ago
kpersonalizer.h Rename common header files for consistency with class renaming 12 years ago
krefinepage.cpp Rename additional header files to avoid conflicts with KDE4 12 years ago
krefinepage.h Trinity Qt initial conversion 14 years ago
krefinepagedlg.ui Branding cleanup: K menu -> TDE menu. 13 years ago
kstylepage.cpp Rename additional header files to avoid conflicts with KDE4 12 years ago
kstylepage.h Rename KStyle to TDEStyle to avoid conflicts with KDE4 12 years ago
kstylepagedlg.ui Rename KStyle to TDEStyle to avoid conflicts with KDE4 12 years ago
ksysinfo.cpp Remove additional unneeded tq method conversions 13 years ago
ksysinfo.h TQt conversion fixes 14 years ago
main.cpp Rename additional header files to avoid conflicts with KDE4 12 years ago
stylepreview.ui Enable compilation with TQt for Qt4 3.4.0 TP2 14 years ago
stylepreview.ui.h Fix a number of runtime object identification problems which led to an even larger array of minor glitches 14 years ago
uninstall.desktop Copy the KDE 3.5 branch to branches/trinity for new KDE 3.5 features. 15 years ago

README

KPersonalizer - Whitepaper
===================

Questions & Answers:

Torsten Rahn <torsten@kde.org>
Carsten Wolff <wolff@kde.org>
Ralf Nolden <nolden@kde.org>
Daniel Molkentin <danimo@kde.org>


Aim:
-----
When the user starts KDE for the very first time the very first impression is
 critical and will decide whether the user likes or dislikes KDE. While this
 might not sound very"fair" or "logical" it's the way people think and perceive
 their environment.

The aim of KPersonalizer is to provide the pleasant look & feel the user expects
 on the very first startup. To determine which look and feel the user prefers he
 is guided through a minimal set of steps.

What Kpersonalizer is _not_ about:
--------------------------------------------

Kpersonalizer is not a wizard which configures your hardware, mount-points or
any other distribution-related stuff. KPersonalizer is only meant to deal with
the Look & Feel KDE provides. As soon as we would touch distribution-related
stuff we risk that distributions might disable KPersonalizer. To encourage
distributions to make use of it it should easily be possible to extend or change
the behaviour of KPersonalizer.

KPersonalizer is not meant to be part of KControl
KControl is rather a graphical registry where you can change every little
detail in a hierarchically arranged order. One really has to know about the
details when changing stuff and one only changes things one by one.
KPersonalizer on the other hand asks the user very basic questions
that don't require much background-knowledge and tries to guess a set
of configuration-settings which fit the users needs best.

Layout: KPersonalizer consists of a window which is not set fullscreen.
This has the advantage that the user sees on the fly which settings he has
changed and can step back as he sees that something doesn't fit.
On the left of each dialog there is a decorative 170x430-pixel-bitmap which
sort of describes the step in a graphical manner.

Step 1:
=====
Introduction:
The Introduction should give the user a warm welcome. It should explain
what KPersonalizer will do during the next step and that the user will be able
to refine the settings  afterwards in the last step using kcontrol.

Most distributions I am aware of generally set one language for all users as a
first default. In certain situations the user might not speak the language
of the default installation which was done by the Sysadmin.
Therefore it makes sense to prompt the user for "his" country.
Judging from the country Kpersonalizer will make all settings according to that
country (language, currency, etc.).
As distributions might take care of this step it should stay easy to disable
that part of the dialog.

Step 2:
=====
Here the user is asked for the way his computer should act like in the future.
Once again this step only deals with the way the computer works - not with the
look.

Depending on the radiobutton which is enabled you get a description which
lists the feautres of each setting:

KDE (default):

The default-setting which you would get if you would disable
KPersonalizer.

Microsoft Windows (TM):

- Double Click
- Busy Cursor
- Windows keyboard scheme
- use 2 clipboards for c&p (keyboard/mouse) (default)
- Window-Behavior -> Focus on click
- Titlebar doubleclick -> Maximize
- WindowList-menu on MMB
- Walk trough windows mode: KDE
- NOT underline IconText
- NOT change pointer shape over an icon

UNIX (TM):
- Single Click
- No busy-cursor
- UNIX -keyboard-scheme.
- synchronize clipboards
- Window-Behavior -> Focus follows mouse
- Titlebar doubleclick -> Shade
- Application-menu on MMB like in FVWM
- Walk trough windows mode: CDE
- NOT underline IconText
- NOT change pointer shape over an icon

MacOS:
- Single Click
- No Busy Cursor
- Mac- Keyboard-Scheme
- use 2 clipboards for c&p (keyboard/mouse) (default)
- Window-Behavior -> Focus on click
- Titlebar doubleclick -> Shade (for now. MacOS X has Minimize but this isn't offered by twin yet)
- Menubar on top
- WindowList-menu on MMB
- Walk trough windows mode: KDE
- NOT underline IconText
- change pointer shape over an icon

Step 3: Eyecandy-O-Meter
===================
The most prominent part the user should see is a big slider. Using this slider
he can easily choose the level of eyecandy. Some people prefer to have a Fast &
Lean environment with small desktop-items and other prefer a Big, Beautiful and
resource-wasting behaviour.

To give the advanced user still some control over what is being changed all
items affected are being displayed in a small listview below. In front of each
listview-item there is a checkbox.
These items are being checked or unchecked depending on the position of the
slider. "Big & Beautiful" means that all items are checked, Fast and Lean means
that all items are unchecked.
As soon as the user touches the checkbox of one of the items directly the
state of that particular checkbox is not being changed by the position of the
slider anymore. Pressing a "Reset"-button will put all items back into the
position/state where the dialog started from.

Features which are affected by the slider are being mentioned in the
following list of Levels:


Level 0 (No Eyecandy):

- No animations, no eyecandy, nothing :)

Level 1:

- Show Wallpaper
- Animate Shading, Minimize & Restore (window effects)
- Display content in moving/resizing windows

Level 2:

- Show Konqueror/Kicker-backgrounds

Level 3:

- Show Iconeffects (Highlightning)
- Icon Zooming (ONLY MAC)

Level 4 (Default for slow machines):

- Icon Animations (mng)
- Desktop-Iconsize = 48 (if  Resolution >= 1024x768) (ONLY MAC/CDE)
- Panel- Iconsize = 56  (if Resolution >= 1280x1024) (ONLY MAC/CDE)

Level 5:

- Enable Image-Previews

Level 6:

- Enable Animated Combo boxes

Level 7 (default for fast machines): 

- Enable Antialiased Fonts
- Enable Fade tool tips
- Enable Fade menus

Level 8: 

- Enable Text-Previews
- Icon Zooming (ALL SELECTIONS)
- Desktop-Iconsize = 48 (if  Resolution >= 1024x768) (ALL SELECTIONS)
- Panel- Iconsize = 56  (if Resolution >= 1280x1024) (ALL SELECTIONS)

Level 9 (Maximum Eyecandy):

- Enable Icons on PushButtons
- Enable all kinds of File-Previews
- Enable Sound

(The number of events which offer a sound corresponds  directly to the
"eyecandy-level".)

Idea for the future: The default-position of the slider might depend on the
measured performance/resources of the computer.

Step 4: Theme-Selection
=================
The user can choose from 4-5 themes each of them representing a look and feel
which is very different from each other and might correspond with the choice
made in Step 2 a bit :-)
Basically this changes Icons, the widgetstyle, the WM-decoration, the
Colourscheme, tiles and Wallpapers.

There is a preview for each theme.

Step 5: Refinement
==============
The user is told how he can start KPersonalizer again if the user changes his
mind on a certain setting later and the advanced user may launch kcontrol to
refine certain settings.


EOF