KDE TechBase - User contributions [en]

Projects/PIM/Akonadi/PortingStatus

2009-06-15T09:30:32Z

Exit3219:

This page lists various pieces that are being ported to Akonadi.
The intent of the page is to give a list of features and bugs.

Since many of those pieces are complete rewrites, this page lists the features that were present in the old implementation. Those need to be ported to the new Akonadi-based implementation.
The list of needed features probably will grow during development and testing, as will the bug list
It also lists optional features, which would be nice to have, but are not present in the old implementation
Also some bugs are listed.

There is also an extremely outdated todo list at [[Projects/PIM/Akonadi]]

If you have implemented a feature or fixed a bug, please strike the item out.

== Bigger Stuff ==

=== Akregator Port ===
'''Assigned to''': Frank, Dimitry

Branch for porting Akregator to [[Projects/PIM/RSS_framework_for_Akonadi]]:

$KDESVN/branches/work/akregator/akonadi-port

==== Status ====

20090611: Branch created, Porting about to start

=== KContactManager ===
'''Assigned to''': Tobias, Sebastian

==== Bugs ====
* After creating a contact group, it doesn't show up in the left pane. Should it?
* Editing contact groups: Should use auto-completion, drag&drop and a "Select..." button (similar to KMail's recipient picker)
* Editing contact groups: Gives me error message that I didn't define a name, when I only entered a mail address. Note that most people don't know the syntax for this, which is "name <nowiki><mail></nowiki>".
* "All Contacts" should be expanded and selected by default
* Crashes when clicking on "Reload" on "All Contacts"
* Deleting a contact group (and possibly a contact as well) leaves a funny empty space in the middle pane
* Switching between "All Contacts" and my addressbook folder here has a delay of > 1s, with about 150 contacts
* Ctrl+A should trigger select all, not add addressbook
* In the editor, the "Coordinates" panel is completely empty
* In the properties dialog of an address book, the "Cache" tab is way too complicated for normal users
* Changing the name of an addressbook in the properties dialog earses the name and the icon

==== Needed Features ====
* Display additional columns in the list of contacts
* LDAP
* Settings Dialog (at least it needs to be able to be disabled from the Kontact settings dialog)

=== MBOX ===
'''Assigned to''': Bertjan

==== Needed features ====
* Implement purging of deleted messages
* '''[IN PROGRESS]''' Port the resource to SingleFileResource
* '''[DONE]''' Implement itemChanged()
* Fix the MBox locking code.

=== POP3 ===
'''Assigned to''': Thomas

==== Bugs ====
* Possible mail duplication

==== Needed Features ====
* Config dialog (Igor is working on this)
* Default inbox (->LocalFolders)
* Filter on server (depends on the filter framework)
* Migration of old KMail accounts
* Abort request
* Precommands

==== Optional Features ====
* Delete on server (bug 31114)

=== IMAP ===
'''Assigned to''': Kevin

=== Kolab ===
'''Assigned to''': Andris

=== KMail Reader ===
'''Assigned to''': Andris

==== Notes ====
Needs to be ported away from KMMessage and mimelib to KMime.

==== Needed Features ====
* Loading attachments on demand when viewing and saving them
* Displaying text and image attachments inline, depending on setting (attachment strategy)
* Different header styles
* MIME part formatters (invitations, vcards, diffs etc)
* Context menu actions (shared with the message list)
* Source viewer
* MIME part tree viewer
* Separate reader main window
* Viewing only one selected MIME part / MIME sub-tree (e.g. encapsulated messages)
* Separate reader window marks the message as read after some time
* Asynchronity (reader should not block when displaying multi-megabyte mail)
* Fallback and override options for the charset encoding
* Crypto

==== Optional Features ====
* New styles based on on Grantlee. Steve says he'll eventually look at that.
* Port away from KPGP to libkleo

=== KMail Composer (non-GUI) ===
'''Assigned to''': Constantin (gsoc)

==== Notes ====
Needs to be ported from KMMessage and mimelib to KMime.

==== Needed Features ====
* Crypto
* Attachments
* Multipart/Alternative (HTML)
* Inline images
* Asynchronity (should not block on long composing tasks, like crypto)
* All kind of weird charset and encoding stuff
* Custom MIME headers from the settings
* Compose as draft and compose as sendable message mode
* Unit tests. This stuff has been very brittle in the past

==== Optional Features ====
* The composer and the composer GUI both keep a "reference message" around, which is IMHO complicated and weird. Get rid of that through refactoring

=== KMail Folder List ===
'''Assigned to''': Kevin

==== Notes ====
The current KMail folder list is unfortunately not model/view based. The new folder list should probably be based on existing Akonadi models and views.

==== Needed Features ====
* Sort by drag & drop or automatic (controlled by setting)
* Drag & drop support for copying and moving folders and messages
* Context menu with all old actions
* Total, Unread and Size column: Collapsing sums things up, unread count can be displayed with the folder name if column is hidden
* Default icons for IMAP root collections, drafts, templates, inbox etc (can be partly handled by new LocalFolders class I guess)
* Configurable item size
* Favorite folder view
* Restoring of expanded/collapsed state (and last selected folder?) after restart
* Optional quick filter edit
* Fancy tooltips
* Folder properties dialog with all the old stuff in it

==== Optional Features ====
* Right-clicking without selecting
* Multi selection for deleting multiple folders at once and a combined properties dialog

=== KMail Message List ===
'''Assigned to''': Kevin

==== Notes ====
Talk to Olivier Trichet (nive), he is in the process of porting KNode to the message list framework.

The message list is fairly well abstracted into KMail-specific parts and generic parts. For porting to Akonadi,
basically only the storage model needs to be rewritten, the model that does the actual work of threading and
grouping can be left untouched

==== Needed Features ====
* Fast loading of the message list. This can be tricky, the many indirections of Akonadi might make it too slow
* Only the headers should be fetched, not the complete message
* Setting stati and tags of mails should work

==== Optional Features ====
* Very long term: Separate threading into an own agent and store threading information as attributes

=== Mail Dispatcher Agent & Outbox interface ===
'''Assigned to''': Constantin (gsoc)

==== Notes ====
No big needed features added below, AFAIK everything is already implemented.

==== Needed Features ====
*<s>Abort requests for agents</s>
*<s>Integration into KMail</s> (more to do when the message list view is ported to Akonadi)
*retry sending and "send queued"
*move-to-sent-mail-collection (blocker: intra-resource moves)
*Polishing
*API Review

==== Optional Features ====

*Displaying the progress and status per-item in the message list with a special outbox theme would be very cool
*Sending by due date

=== KOrganizer Agenda View ===
'''Assigned to''': Sebastian

=== KOrganizer Month View ===

=== KOrganizer Timeline View ===

=== KOrganizer Todo View ===
==== Notes ====
Already model-view based in old KOrganizer

=== KResource Bridges & Migration ===
'''Assigned to''': Kevin

* KOrganizer doesn't have any resource by default for new users (unit test for this exists)
* Kontact is *very* crashy in the summary and todo list
* Hierarchical todo don't work anymore

==== Needed Features ====
* Unit tests (->Thomas)

=== Filtering System ===
'''Assigned to''': Szymon

==== Needed Features ====
* Pluggable filter actions and rules
* Nice GUI editor
* All filter actions and rules from old KMail should be implemented
* Library should be usable outside of the agent, e.g. for POP3 on-server filtering.
* Manual and automatic filtering
* Filtering should be possible on incomplete mail (headers only). When a filter rule or action detects that it needs the complete body, that should be fetched on demand
* Don't re-upload the mail when no filter action changed the mail (important for IMAP)
* Filtering should be invisible to clients
* Not all new items should trigger automatic filtering -> We might need a flag to explicitly make items filterable, otherwise items get filtered when they were manually added by the user
* Filtering must not lose messages
* Automated tests. Filtering was *very* brittle in the past, causing duplicate and lost messages
* Migration of old filters

==== Optional Features ====
* Make the sieve script editor for IMAP servers an actual GUI editor
* Maybe filter rules can be re-used for searching?

=== Search ===

==== Notes ====
Nobody really knows how this should be done (if one does, please explain here how it should work!). There are server-side searches (IMAP and LDAP) and client side searches possible.

Probably should use Nepomuk.

==== Needed Features ====
* At least local searches should be possible, like in current KMail. There should also be a search window like before.
* Virtual search folders

=== History resource ===

== Smaller Stuff ==

=== IMAP Load on Demand ===
'''Assigned to''': Andris, Kevin, Volker

==== Notes ====
Related to the reader implementation.
Might need changes in the mail serializer, KMime, the IMAP resource, the server(?)

==== Needed Features ====
* Should be possible to fetch messages without fetching the big attachments.
* When saving attachments, fetch them on demand.
* Attachments inside signatures should not be fetched on demand

==== Optional Features ====
* Disconnected IMAP with attachment load on demand (headers and message text cached, but not big attachments)
* Bonus points for zero-copy streaming when saving IMAP attachments to disk

=== Progress Reporting ===
'''Assigned to''': Constantin

==== Notes ====
The progress of the agents should be hooked up into the progress manager of libkdepim. -> AgentProgressMonitor

==== Needed Features ====

*<s>Tracking progress and status texts</s>
*<s>Abort requests</s>

=== Local Folders ===
'''Assigned to''': Constantin (gsoc)

==== Needed Features ====
* Inbox, drafts and templates
* So it probably needs to be moved out of OutboxInterface...
* Set standard items for the collections, like in KMail

==== Optional Features ====

* Option for volatile outbox (not stored on disk)
* Option for no sent-mail collection

 

=== Akonadi Resource-based Mail Transport ===

'''Assigned to''': Constantin

==== Needed Features ====

* Re-design (TransportResource is probably not needed; its job can be accomplished in ResourceBase with a signal and a D-Bus adaptor. (?))
* List transport-enabled Akonadi resources directly in transport type selector, and configure them on demand
* Scrap the wizard. Since Akonadi resources can't be configured with an embeddable widget / kpart (yet?), we'll have to stick to dialogs anyway.

Talk:Development/Tutorials/Using KParts

2008-06-18T15:38:51Z

Exit3219:

thanks for this GREAT article ! I was looking for exactly this. --[[User:Tstaerk|Tstaerk]] 07:49, 8 June 2008 (CEST)

KDE4PORTING says KLibFactory was renamed to KPluginFactory.

Development/Tutorials/Code Checking

2008-03-22T08:01:40Z

Exit3219:

==Code Checking==
There are a lot of ways to find bugs in KDE code. Increasingly, KDE developers have started to use automated tools. You can use some of those tools to improve your own code.

===The KDE 'Krazy' Checker===
KDE developers have a simple set of tests that are collectively known as "Krazy". These tests were originally developed to be run as part of a larger set of tests on a machine known as [http://www.englishbreakfastnetwork.org http://www.englishbreakfastnetwork.org], or EBN for short. You can see the results of running the various tests on EBN (at http://www.englishbreakfastnetwork.org/krazy/).

You can also run the tests yourself. To do this, you need to obtain a copy of
the code from {{path|trunk/quality/krazy}} and install them. You can then test either a single file (using the krazy application) or a whole tree, including subdirectories (using the krazyall application).

====How Krazy works====
The Krazy tests are essentially a form of static analysis - they check the
source code, but not how it runs.

Krazy exists as a framework comprising a number of different test runners, and
a set of plugins. The test runners are called krazy, krazyall, and krazyebn. The test runners just call one or more plugins on the appropriate code, and
format the results for display.

At this stage, most of the test runners are written in perl, however one is
written in C++ (using Qt) and it is quite possible to add your own tests, or
to modify a test - all sources are provided.

====Installing Krazy====
Krazy needs to be installed before use. Krazy has two different ways to be
installed - you can either modify the {{path|krazy2/install.sh}} script and
run it, or follow the instructions in the [http://websvn.kde.org/trunk/quality/krazy2/INSTALL.txt?view=markup krazy2/INSTALL.txt] file. I recommend the second.

{{Note|I had a minor problem with the plugin that is built from C++, because that plugin got installed into the wrong directory. If you are missing the passbyvalue plugin, then you may need to move it into the directory that contains the rest of your plugins.}}

====Using Krazy====
Krazy comes with a particularly good man page, which gives you the various
options and a usage example. The file is generated on installation. This is definitely recommended reading!

As noted above, there are three test runners - krazy, krazyebn and krazyall. If you are trying to check a single file, then krazy is the right tool. If you are trying to check a source tree (say, an application or a whole subversion module), then krazyall is more useful. krazyall doesn't have a man page, but
you can get a list of the options with krazyall --help. You can also use krazy to get information on the various plugins, which can help you understand more about krazyall.

krazyebn is the tool that runs over the KDE codebase on the [http://www.englishbreakfastnetwork.org EBN] and should not be run locally.
However, please see [[#Controlling Krazy on the EBN|Controlling Krazy on the EBN]] below to learn how you can control which plugins are run, and what files are processed by the krazyebn program on the EBN machine.

Remember that Krazy doesn't change your code - it only examines it. So you can safely experiment with running Krazy checks until you are confident that you understand what is happening.

Equally, that means that Krazy doesn't fix problems - it only tries to report them. Understanding what is being reported, and how to fix it, is up to you. You should also remember the KDE commit policy about not committing code that you don't understand. So fixing a spelling error in a comment is pretty safe, but blindly changing code to stop explicit constructor warnings from Krazy is not a good idea.

====In-Code directives====
The Krazy plugins support the following list of in-code directives:
* <tt>//krazy:skip</tt> - no Krazy tests will run on this file.
* <tt>//krazy:excludeall=<name1[,name2,...,nameN]></tt> - the Krazy tests ''name1'', etc will not be run on this file.
* <tt>//krazy:exclude=<name1[,name2,...,nameN]></tt> - the Krazy tests ''name1'', etc. will not be run on the line where this directive is found (see the [[#Suppressing false-positives|next section]] below for more information).

Note that these directives must be C++ style comments that can be put anywhere in the file desired (except embedded within C-style comments).

====Suppressing false-positives====
The Krazy tests are designed to minimise false positives (that is, alerts that do not represent real problems). However because most of the tests are conducted on a single line, there are some tests that might produce such a false positive. For example, code that does something like:
<code cppqt>
QString mystring;
mystring += "/";
</code>
will be flagged by the doublequote_chars checker, because it is more efficient to add a single char, as shown below:
<code cppqt>
QString mystring;
// note that we are using single quotes
// this is a char, not a char array
mystring += '/';
</code>

That same checker will produce a false positive for code that looks like:
<code cppqt>
std::string mystring;
mystring += "/";
</code>

You can suppress these false positives using a special comment format.
To exclude a particular plugin from being run on a line of code, simply add
a C++ comment containing the string "krazy:exclude=<plugin_name>". The plugins currently available can be found in the
[http://websvn.kde.org/trunk/quality/krazy/plugins repository].

Specifically, for this plugin use "krazy:exclude=doublequote_chars".
For example:
<code cppqt>
lenstr = "0" + lenstr;
</code>
becomes
<code cppqt>
lenstr = "0" + lenstr; // krazy:exclude=doublequote_chars
</code>

{{Note|Using c-style (/* */) comments will ''not'' work. You must use C++ style (//) comments when noting tests to be skipped.}}

====Controlling Krazy on the EBN====
This section describes how to use ''.krazy'' files to control the Krazy runs on the [http://www.englishbreakfastnetwork.org EBN]. The ''.krazy'' files are used to tell Krazy to skip over specific sub-directories, or files; or to disable certain plugins within those modules and sub-directories.

To ignore a sub-directory within a module, say {{path|kdepim/kmail}}, use the IGNORESUBS directory within the {{path|kdepim/.krazy}} file, like so:

<code>
IGNORESUBS kmail
</code>

Or you can ignore a set of directories by specifying a comma-separated list:

<code>
IGNORESUBS kmail,kontact,knode
</code>

To ignore files or directories within a module/subdir, specify a regular expression that matches the files to skip together with the SKIP directive.
For example, to skip the directories {{path|kdepimlibs/kcal/libical}}, {{path|kdepimlibs/kcal/versit}}, and the {{path|kdepimlibs/kcal/fred.c}} file, use this directive within the {{path|kdepim/kcal/.krazy}} file:

<code>
SKIP /libical/\|/versit/\|fred\.c
</code>

Use the EXCLUDE directive to disable a list of plugins for all files within a module/subdir:

<code>
EXCLUDE doublequote_chars,qclasses
</code>

To override the EXCLUDE directive set from a {{path|.krazy}} file up in the directory hierarchy, use the CHECK command. For example, the component level {{path|.krazy}} file may EXCLUDE the ''copyright'' and ''license'' plugins, but those plugins can be re-enabled in a module/subdir with the CHECK directive like so:

<code>
CHECK copyright,license
</code>

{{Note|Individual modules can be ignored as well, but this is an EBN administrator duty controlled by component-level ''.krazy'' files within the ''/usr/local/src'' hierarchy. See the [http://wiki.kde.org/English+Breakfast+Network English Breakfast Network wiki] for details.}}

===Compiler Warnings===
In addition to the various Krazy tools, you can also get valuable assistance from the warnings that the compiler emits, especially if you enable additional warnings (per the documentation for your compiler), and also if you test with more than one compiler (e.g. if you can test on Linux with both GCC and the Intel compiler; or on Linux with GCC and also on Windows with the Microsoft compiler).

Talk:Projects/NamingTheWiki

2007-01-24T08:47:13Z

Exit3219: /* Name Suggestions */

= Name Suggestions =

: '''TechZone''': I like this name for several reasons: They give a clue on the pages purpose, are not biased towards either devs or system integrators, and leave room to brand them (Question to Promo team: is that a good idea). Please note that we will redirect developer.kde.org to this domain, so people who are looking for this domain straight will still end up in the right place. The word ''Base'' in '''Tech''Base''''' was criticized as being meaningless plus there is already a domain called devbase.com, and I want to stay out of tm issues. --[[User:Danimo|Danimo]] 01:42, 19 January 2007 (CET)

::I agree with these ideas. Regarding not biasing articles, that imho is a particularly important idea. While the major apps/suites (KOffice, Kontact, Kolab, Kopete, etc) are taken care of, there is an incredibly vast set of vertical markets untouched by KDE. These markets are not often discussed, yet make up a rather significant developer market. Examples would be software to manage a dental office, consulting firm, accounting firm, millwork companies, etc. Those working on this won't necessarily fall into a neat and clean category, so I'd consider this advantageous. --[[User:CuCullin|CuCullin]] 16:21, 19 January 2007 (CET)

:: I don't think the word base is meaningless it all. At least for English speakers it carries both the idea of a canonical location ("home base") and solidity (base and foundation can be used interchangeably in many cases) --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:: In my opinion, TechZone sounds like it's trying to be 'cool'. The word 'zone' sounds like it describing something much less well defined than, say, 'base' and so makes it sound very vague. --[[User:Milliams|milliams]] 00:42, 20 January 2007 (CET)

: '''TechBase''': I like this name because we already call the site that elsewhere, so there's some continuity. It also is representative of the fact that this site (as i understand it) is meant to be the base of technical information for and about KDE on the interwebs. There is a company called TechBase International"KDE Technical Reference" which does things completely unrelated to KDE so maybe there's some tm issues, but I doubt it. Perhaps we might want to have a thing where the full name of the site is ''KDE Technical Base'' and we just call it ''TechBase'' for short --[[User:Mattr|Mattr]] 02:22, 19 January 2007 (CET)

:: I like the Word 'base'. For exactly the two reasons aseigo mentioned (under TechZone). Maybe officially naming the site "Technology Base" and just having the URL as techbase.kde.org? However, I'm sure that everyone would just refer to it as 'TechBase' anyway --[[User:Milliams|milliams]] 00:42, 20 January 2007 (CET)

: '''TechCenter''': Similar to TechZone and TechBase. Maybe also similar to the [http://www.qtcentre.org/ qt-centre].

: '''TechZone and TechBase ''': I feel that "tech[base|zone]"is a poor choice of name - it's a made up word and as such will age rapidly. It's a lowest common denominator, meaningless choice. The KDE project is bigger than that and would be better served by clean, functional terms such as "KDE Technical Reference", "KDE Technical Resource". If it has to be one word, "Learn" or "Platform". --[[User:Bille|Bille]] 23:18, 17 January 2007 (CET)

:: You ''feel'' it is a lowest common denominator, meaningless choice. I ''feel'' otherwise. Let's try and stay away from communicating things as if they are universal truths when they are actually subjective reflections. "Learn" might be an interesting name; "Platform" would make it confusing for me to talk about the KDE platform vs the website called Platform; "Technical Reference" would be very hard to market. One of the sides of this that I have to deal with that probably most others don't is representing it to the public during interviews, in press materials, when giving presentations at conferences, etc... So for me the marketability of the term is also important, as are the clarity and accuracy issues you raise in your comment here. --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

::: Aaron, I knew what ''feel'' means before you italicised it. I'm not enough of a solipsist to confuse my feelings with universal truths. Just sharing my subjective opinion here. Why do you feel "KDE Technical Reference/Resource" is hard to market? IMO it says exactly what the site does, has the KDE brand and can be communicated in any language. After all, what you'd be marketing is KDE, with the message that KDE has comprehensive technical resources - you'd not be marketing eg our "KDE Technical Reference" site vs. some competing "Larry's KDE Experts Forum" --[[User:Bille|Bille]] 10:23, 20 January 2007 (CET)

:::: I feel "KDE Technical Reference/Resource" is hard to market because it has about as much zing to it as a colon exam. It's not easy to say (6 syllables, even) and unless you prepend "KDE" to it it's not recognizable since it's a generic term. "Technical reference" could apply to any number of things within KDE, so this would be THE Technical Reference website. Contrast with "TechBase", "TechZone", "WallZomper", etc.. easy to say, compact, not an ambiguous noun so further qualifiers ('the', 'KDE', 'website') aren't necessary once it is introduced into the vernacular. These short names also lend to being the domain name of the site, unless technicalreference.kde.org seems like a good idea to you? Describing the site to people as the KDE technical reference is probably a clear way of doing it, but a name and a description are not the same thing --[[User:Aseigo|Aseigo]] 22:56, 20 January 2007 (CET)

: '''KDE Wiki''': ''Wiki'' is now a noun just like a ''web page''. Many of us are used to talking ''KDevelop wiki'', ''SUSE wiki'', and even below, Daniel used ''Kolab Wiki'' for Kolab. After all ''it's easy to remember'' and compatible with KISS principles... --[[User:Jstaniek|jstaniek]] 16:10, 19 January 2007 (CET)

:: The thing I don't like about this is that it ''is'' just a noun like "web page". This site has a purpose, and I think the name should promote that purpose - otherwise, there would be no limitation on any KDE content going on here. Users might add application manuals, or e.V. info could go on here, whatever. That would only create confusion imho. --[[User:CuCullin|CuCullin]] 16:21, 19 January 2007 (CET)

:: Isn't the ''KDE wiki'' wiki.kde.org? That's already taken. Besides, we still need a name on the right of the KDE logo. "KDE Technical Reference" or similar titles are better than "KDE wiki". --[[User:Dhaumann|Dhaumann]] 16:56, 19 January 2007 (CET)

::: I thought the old wiki.kde.org, now '''redundant''' (look at its TOC), is pretty much a history now when the new ''developernew'' wiki appeared, and as Mediawiki not only contains predictable hyperlinks and good interwiki and templates support, but its engine is far superior to the old one and constantly improved. At least I consider moving all of my content out of it elsewhere. There's no day when I did not have problems with its tikiwiki's configuration, html layout and speed. Application manuals? The old wiki.kde.org does not contain this kind of stuff, so history shows it's not a problem. Every larger KDE apps can host its own wiki, as we know in case of KOffice, Kexi, KDevelop, KDEWebDev family, etc. So ''Wiki'' is still my favourite term. Regarding "KDE Technical Reference", it sounds a bit serious. There's similar very popular (100x more according to google) term: '''"Knowledge Base"'''. Personally I have no problem with having wiki.kde.org (because it's as short as possible) and "Knowledge Base" title. --[[User:Jstaniek|jstaniek]] 18:54, 19 January 2007 (CET)

:::: Part of that, imho, is that wiki.kde.org (and TikiWiki) isn't as friendly as MediaWiki. Perhaps it should be wiki.kde.org, and simply have a nice listing somewhere on this site discussing what does and does not belong on here, just to direct content that may be more appropriate elsewhere. Personally, I like a more descriptive name because I think it separates this wiki from others. --[[User:CuCullin|CuCullin]] 19:49, 19 January 2007 (CET)

:::: '''Knowledge base''' is an interesting name posibility IMHO. It's a bit on the dry side but it is accurate. My concern is that it might cast the net too wide and we'd end up with scope creep, e.g. becoming a place for user information. I don't think we should try and cater to absolutely everyone with this site, and a more focussed name might help with that. --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:: "wiki" is not something I could market (see my comment to Bille's response on this matter for more on this point). "Wiki" does not speak directly to the target audiences due to being a generic noun/verb, nor does it say what is on the site since a wiki can contain anything. It's also already taken anyways =) --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:: "Wiki" only describes what it is, not what it does or what it's for. In a way wiki is synonymous with "site". And we'd never think of calling this "KDE Site" yet that conveys just as much information to the reader. --[[User:Milliams|milliams]] 00:42, 20 January 2007 (CET)

: Do you also mean platform.kde.org or reference.kde.org then? We are searching for both a readable name and a subdomain name. --[[User:Dhaumann|Dhaumann]] 16:56, 19 January 2007 (CET)

'''Conquer KDE''': The name should reflect the whole KDE project as (the way I see it) it tries to group everything KDE will be doing in the future to one wiki.

As I read on the mailing list, we are trying to promote KDE to the OSV and to the system admins as well so the Slogan would be a nice way to name the wiki.--[[User:Imagine|Imagine]] 19:11, 19 January 2007 (CET)

: While I'm pretty sure this isn't what you were trying to say, I'd like to make it clear that we're not actually trying to group ''everything'' KDE will be doing, just everything that is a) technical information and b) relevant to those who create things with KDE technology. '''Conquer KDE''' is a neat slogan, but i'm not sure if it translates to usage as a noun: "Go to conquer KDE." or "Conquer KDE is the technical information website." Maybe it would just take time to get used to using it in that fashion; perhaps it would be good to have a name that doesn't take time to get used to =) --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

::I understand what you mean and I'm sorry I got it wrong. I am following the discussion you guys had for a few days in the mailing-list but it's very confusing! --[[User:Imagine|Imagine]] 05:54, 20 January 2007 (CET)

'''Korner''': Well I was thinking about this after what Aseigo told me. I think, like Aseigo, that the name is very important when it comes to marketing. TechZone, TechData, TechBase are very good names but they fall into the normality which is a good thing and a bad thing. There is so much technical information about KDE that I think it would get confusing for everyone about what the Tech[name] would be. So that's why I tried to think out of the box and came out with the Korner.

I think this could be a nice name to market it because we get the 'K' that is referring to KDE and the word 'Corner' that specifies a gathering of information. Plus, "Go to the Korner" could be easy to get use to it.--[[User:Imagine|Imagine]] 05:55, 20 January 2007 (CET)

: "Korner" will attract confused blues guitar fans. And I'd hang on to the dictionary that specifies "Corner" as a gathering of information - it might be worth something on the rare books market. Plus, "Go to the Corner" is used to punish naughty children. --[[User:Bille|Bille]] 10:23, 20 January 2007 (CET)

'''Empower KDE''': could be used as empower.kde.org for a subdomain. Is it ok to tell people to "go to Empower KDE"? I think it gives regular users the idea that it's not for them (they just ''use'' KDE), and it gives the developers/isvs/etc. the pleasant feeling of contributing. I thought of 'power users' at first, but it didn't sound appropriate. --[[User:Exit3219|Exit3219]] 19:56, 20 January 2007 (CET)

'''KDE Workshop''' or '''KDE Workbench''' or '''KDE Garage''' or '''KDE Lab''' - fresh ideas that came by night: --[[User:Jstaniek|jstaniek]] 01:52, 24 January 2007 (CET)

: lab is so-so; garage, workbench and workshop all work for me, though. garage is kind of "cool" sounding =) --[[User:Aseigo|Aseigo]] 06:16, 24 January 2007 (CET)

'''KDE Wisdom''': (wisdom.kde.org) Isn't that what this wiki strives to become? A source of wisdom and knowledge. The long name could be ''The KDE Wisdom Wiki''. Slogan: ''Wisdom is Power.'' ;) [[User:Exit3219|Exit3219]] 09:47, 24 January 2007 (CET)

= Thoughts on the Scope of This Wiki =

= Thoughts on the Target Audiences =

:Perhaps someone could clarify what is meant by "system administrators". At the extreme this term could apply to everyone from those with root on their local desktop install to people managing a network of thousands of PCs. I suspect the first of these includes the vast majority of KDE users. I assume this is not what is intended as this is a separate site to wiki.kde.org. -- TheoSpears

::We're talking about people that administer a multitude of PCs, probably they are doing this professionally most of the time. We want to provide resources for them (howtos, scripts, pittfalls and workarounds). The wiki also gives us the unique chance that they can contribute their knowledge back (works fine e.g. on the [http://wiki.kolab.org Kolab Wiki]. --[[User:Danimo|Danimo]] 02:12, 19 January 2007 (CET)

:::Also, do we need to put this up on this site? The question being, does Sys Admin information belong? Or should it remain at http://www.kde.org/areas/sysadmin/ ? --[[User:CuCullin|CuCullin]] 18:22, 19 January 2007 (CET)

:::: Good question. That fact that pretty well nobody knows about /areas/sysadmin is telling. I'm constantly educating people about the existence of that area on our website because people don't find it on their own. The reason seems to be that it is too buried in a general purpose side (www.kde.org) to be easily findable and because it isn't promoted well. We can elevate it's visibility by putting it on the front page of the wiki and we can use marketing and promotional support applied to the wiki to increase awareness of this body of information. In other words, we can tell people all at once about this "hub of technical information" which should let us reach more people with a simpler concept (simpler because you don't have to think, "ok, sysadmin technical documents would be over here... programmer technical documents would be over on this site..."). also note that we already will have sysadmin type information here to educate programmers on topics such as Kiosk. may as well keep it all together, no? bonus points that unlike www.kde.org, the wiki is community editable and updatable. /areas/sysadmin languishes so badly because you need special privileges to make changes to it. -[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:::This is also a place where sys admins can find out more about the whole KDE community. This Wiki should be more like the very first place for anyone who wants to know what is KDE. Screenshot, announcement, the best apps(amarok, k3b, koffice, konqueror, etc.), so that the user will WANT to try this out.--[[User:Imagine|Imagine]] 19:16, 19 January 2007 (CET)

:::: I'm concerned that this scope creep would make it very hard to organize things well. We have other sites that are for user oriented information; keeping our sites focussed will make it easier to promote as well as more rewarding for visitors as they will have places "just for them". I agree we can use our web sites to market KDE better, but that is a separate topic that is IMO out of scope for this website. That said, this site should be first place people who want technical documents should think of going. --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:With such an international audience, presumably we need to think about how the name carries around the world. I know that this can sink any discussion with concerns from every country, but I wonder how well (for example) 'zone' and 'base' are understood in this context, particularly since both have more than one meaning in English. [[User:Tomchance|Tomchance]] 08:24, 19 January 2007 (CET)

:: Good point. How can we test this? Float names by people on irc or blogs or? --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

User:Exit3219

2007-01-20T19:01:02Z

Exit3219:

[http://ascending.wordpress.com/ http://ascending.wordpress.com/]

Talk:Projects/NamingTheWiki

2007-01-20T18:56:55Z

Exit3219: /* Name Suggestions */

= Name Suggestions =

: '''TechZone''': I like this name for several reasons: They give a clue on the pages purpose, are not biased towards either devs or system integrators, and leave room to brand them (Question to Promo team: is that a good idea). Please note that we will redirect developer.kde.org to this domain, so people who are looking for this domain straight will still end up in the right place. The word ''Base'' in '''Tech''Base''''' was criticized as being meaningless plus there is already a domain called devbase.com, and I want to stay out of tm issues. --[[User:Danimo|Danimo]] 01:42, 19 January 2007 (CET)

::I agree with these ideas. Regarding not biasing articles, that imho is a particularly important idea. While the major apps/suites (KOffice, Kontact, Kolab, Kopete, etc) are taken care of, there is an incredibly vast set of vertical markets untouched by KDE. These markets are not often discussed, yet make up a rather significant developer market. Examples would be software to manage a dental office, consulting firm, accounting firm, millwork companies, etc. Those working on this won't necessarily fall into a neat and clean category, so I'd consider this advantageous. --[[User:CuCullin|CuCullin]] 16:21, 19 January 2007 (CET)

:: I don't think the word base is meaningless it all. At least for English speakers it carries both the idea of a canonical location ("home base") and solidity (base and foundation can be used interchangeably in many cases) --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:: In my opinion, TechZone sounds like it's trying to be 'cool'. The word 'zone' sounds like it describing something much less well defined than, say, 'base' and so makes it sound very vague. --[[User:Milliams|milliams]] 00:42, 20 January 2007 (CET)

: '''TechBase''': I like this name because we already call the site that elsewhere, so there's some continuity. It also is representative of the fact that this site (as i understand it) is meant to be the base of technical information for and about KDE on the interwebs. There is a company called TechBase International"KDE Technical Reference" which does things completely unrelated to KDE so maybe there's some tm issues, but I doubt it. Perhaps we might want to have a thing where the full name of the site is ''KDE Technical Base'' and we just call it ''TechBase'' for short --[[User:Mattr|Mattr]] 02:22, 19 January 2007 (CET)

:: I like the Word 'base'. For exactly the two reasons aseigo mentioned (under TechZone). Maybe officially naming the site "Technology Base" and just having the URL as techbase.kde.org? However, I'm sure that everyone would just refer to it as 'TechBase' anyway --[[User:Milliams|milliams]] 00:42, 20 January 2007 (CET)

: '''TechCenter''': Similar to TechZone and TechBase. Maybe also similar to the [http://www.qtcentre.org/ qt-centre].

: '''TechZone and TechBase ''': I feel that "tech[base|zone]"is a poor choice of name - it's a made up word and as such will age rapidly. It's a lowest common denominator, meaningless choice. The KDE project is bigger than that and would be better served by clean, functional terms such as "KDE Technical Reference", "KDE Technical Resource". If it has to be one word, "Learn" or "Platform". --[[User:Bille|Bille]] 23:18, 17 January 2007 (CET)

:: You ''feel'' it is a lowest common denominator, meaningless choice. I ''feel'' otherwise. Let's try and stay away from communicating things as if they are universal truths when they are actually subjective reflections. "Learn" might be an interesting name; "Platform" would make it confusing for me to talk about the KDE platform vs the website called Platform; "Technical Reference" would be very hard to market. One of the sides of this that I have to deal with that probably most others don't is representing it to the public during interviews, in press materials, when giving presentations at conferences, etc... So for me the marketability of the term is also important, as are the clarity and accuracy issues you raise in your comment here. --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

::: Aaron, I knew what ''feel'' means before you italicised it. I'm not enough of a solipsist to confuse my feelings with universal truths. Just sharing my subjective opinion here. Why do you feel "KDE Technical Reference/Resource" is hard to market? IMO it says exactly what the site does, has the KDE brand and can be communicated in any language. After all, what you'd be marketing is KDE, with the message that KDE has comprehensive technical resources - you'd not be marketing eg our "KDE Technical Reference" site vs. some competing "Larry's KDE Experts Forum" --[[User:Bille|Bille]] 10:23, 20 January 2007 (CET)

: '''KDE Wiki''': ''Wiki'' is now a noun just like a ''web page''. Many of us are used to talking ''KDevelop wiki'', ''SUSE wiki'', and even below, Daniel used ''Kolab Wiki'' for Kolab. After all ''it's easy to remember'' and compatible with KISS principles... --[[User:Jstaniek|jstaniek]] 16:10, 19 January 2007 (CET)

:: The thing I don't like about this is that it ''is'' just a noun like "web page". This site has a purpose, and I think the name should promote that purpose - otherwise, there would be no limitation on any KDE content going on here. Users might add application manuals, or e.V. info could go on here, whatever. That would only create confusion imho. --[[User:CuCullin|CuCullin]] 16:21, 19 January 2007 (CET)

:: Isn't the ''KDE wiki'' wiki.kde.org? That's already taken. Besides, we still need a name on the right of the KDE logo. "KDE Technical Reference" or similar titles are better than "KDE wiki". --[[User:Dhaumann|Dhaumann]] 16:56, 19 January 2007 (CET)

::: I thought the old wiki.kde.org, now '''redundant''' (look at its TOC), is pretty much a history now when the new ''developernew'' wiki appeared, and as Mediawiki not only contains predictable hyperlinks and good interwiki and templates support, but its engine is far superior to the old one and constantly improved. At least I consider moving all of my content out of it elsewhere. There's no day when I did not have problems with its tikiwiki's configuration, html layout and speed. Application manuals? The old wiki.kde.org does not contain this kind of stuff, so history shows it's not a problem. Every larger KDE apps can host its own wiki, as we know in case of KOffice, Kexi, KDevelop, KDEWebDev family, etc. So ''Wiki'' is still my favourite term. Regarding "KDE Technical Reference", it sounds a bit serious. There's similar very popular (100x more according to google) term: '''"Knowledge Base"'''. Personally I have no problem with having wiki.kde.org (because it's as short as possible) and "Knowledge Base" title. --[[User:Jstaniek|jstaniek]] 18:54, 19 January 2007 (CET)

:::: Part of that, imho, is that wiki.kde.org (and TikiWiki) isn't as friendly as MediaWiki. Perhaps it should be wiki.kde.org, and simply have a nice listing somewhere on this site discussing what does and does not belong on here, just to direct content that may be more appropriate elsewhere. Personally, I like a more descriptive name because I think it separates this wiki from others. --[[User:CuCullin|CuCullin]] 19:49, 19 January 2007 (CET)

:::: '''Knowledge base''' is an interesting name posibility IMHO. It's a bit on the dry side but it is accurate. My concern is that it might cast the net too wide and we'd end up with scope creep, e.g. becoming a place for user information. I don't think we should try and cater to absolutely everyone with this site, and a more focussed name might help with that. --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:: "wiki" is not something I could market (see my comment to Bille's response on this matter for more on this point). "Wiki" does not speak directly to the target audiences due to being a generic noun/verb, nor does it say what is on the site since a wiki can contain anything. It's also already taken anyways =) --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:: "Wiki" only describes what it is, not what it does or what it's for. In a way wiki is synonymous with "site". And we'd never think of calling this "KDE Site" yet that conveys just as much information to the reader. --[[User:Milliams|milliams]] 00:42, 20 January 2007 (CET)

: Do you also mean platform.kde.org or reference.kde.org then? We are searching for both a readable name and a subdomain name. --[[User:Dhaumann|Dhaumann]] 16:56, 19 January 2007 (CET)

'''Conquer KDE''': The name should reflect the whole KDE project as (the way I see it) it tries to group everything KDE will be doing in the future to one wiki.

As I read on the mailing list, we are trying to promote KDE to the OSV and to the system admins as well so the Slogan would be a nice way to name the wiki.--[[User:Imagine|Imagine]] 19:11, 19 January 2007 (CET)

: While I'm pretty sure this isn't what you were trying to say, I'd like to make it clear that we're not actually trying to group ''everything'' KDE will be doing, just everything that is a) technical information and b) relevant to those who create things with KDE technology. '''Conquer KDE''' is a neat slogan, but i'm not sure if it translates to usage as a noun: "Go to conquer KDE." or "Conquer KDE is the technical information website." Maybe it would just take time to get used to using it in that fashion; perhaps it would be good to have a name that doesn't take time to get used to =) --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

::I understand what you mean and I'm sorry I got it wrong. I am following the discussion you guys had for a few days in the mailing-list but it's very confusing! --[[User:Imagine|Imagine]] 05:54, 20 January 2007 (CET)

'''Korner''': Well I was thinking about this after what Aseigo told me. I think, like Aseigo, that the name is very important when it comes to marketing. TechZone, TechData, TechBase are very good names but they fall into the normality which is a good thing and a bad thing. There is so much technical information about KDE that I think it would get confusing for everyone about what the Tech[name] would be. So that's why I tried to think out of the box and came out with the Korner.

I think this could be a nice name to market it because we get the 'K' that is referring to KDE and the word 'Corner' that specifies a gathering of information. Plus, "Go to the Korner" could be easy to get use to it.--[[User:Imagine|Imagine]] 05:55, 20 January 2007 (CET)

: "Korner" will attract confused blues guitar fans. And I'd hang on to the dictionary that specifies "Corner" as a gathering of information - it might be worth something on the rare books market. Plus, "Go to the Corner" is used to punish naughty children. --[[User:Bille|Bille]] 10:23, 20 January 2007 (CET)

'''Empower KDE''': could be used as empower.kde.org for a subdomain. Is it ok to tell people to "go to Empower KDE"? I think it gives regular users the idea that it's not for them (they just ''use'' KDE), and it gives the developers/isvs/etc. the pleasant feeling of contributing. I thought of 'power users' at first, but it didn't sound appropriate. --[[User:Exit3219|Exit3219]] 19:56, 20 January 2007 (CET)

= Thoughts on the Scope of This Wiki =

= Thoughts on the Target Audiences =

:Perhaps someone could clarify what is meant by "system administrators". At the extreme this term could apply to everyone from those with root on their local desktop install to people managing a network of thousands of PCs. I suspect the first of these includes the vast majority of KDE users. I assume this is not what is intended as this is a separate site to wiki.kde.org. -- TheoSpears

::We're talking about people that administer a multitude of PCs, probably they are doing this professionally most of the time. We want to provide resources for them (howtos, scripts, pittfalls and workarounds). The wiki also gives us the unique chance that they can contribute their knowledge back (works fine e.g. on the [http://wiki.kolab.org Kolab Wiki]. --[[User:Danimo|Danimo]] 02:12, 19 January 2007 (CET)

:::Also, do we need to put this up on this site? The question being, does Sys Admin information belong? Or should it remain at http://www.kde.org/areas/sysadmin/ ? --[[User:CuCullin|CuCullin]] 18:22, 19 January 2007 (CET)

:::: Good question. That fact that pretty well nobody knows about /areas/sysadmin is telling. I'm constantly educating people about the existence of that area on our website because people don't find it on their own. The reason seems to be that it is too buried in a general purpose side (www.kde.org) to be easily findable and because it isn't promoted well. We can elevate it's visibility by putting it on the front page of the wiki and we can use marketing and promotional support applied to the wiki to increase awareness of this body of information. In other words, we can tell people all at once about this "hub of technical information" which should let us reach more people with a simpler concept (simpler because you don't have to think, "ok, sysadmin technical documents would be over here... programmer technical documents would be over on this site..."). also note that we already will have sysadmin type information here to educate programmers on topics such as Kiosk. may as well keep it all together, no? bonus points that unlike www.kde.org, the wiki is community editable and updatable. /areas/sysadmin languishes so badly because you need special privileges to make changes to it. -[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:::This is also a place where sys admins can find out more about the whole KDE community. This Wiki should be more like the very first place for anyone who wants to know what is KDE. Screenshot, announcement, the best apps(amarok, k3b, koffice, konqueror, etc.), so that the user will WANT to try this out.--[[User:Imagine|Imagine]] 19:16, 19 January 2007 (CET)

:::: I'm concerned that this scope creep would make it very hard to organize things well. We have other sites that are for user oriented information; keeping our sites focussed will make it easier to promote as well as more rewarding for visitors as they will have places "just for them". I agree we can use our web sites to market KDE better, but that is a separate topic that is IMO out of scope for this website. That said, this site should be first place people who want technical documents should think of going. --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)

:With such an international audience, presumably we need to think about how the name carries around the world. I know that this can sink any discussion with concerns from every country, but I wonder how well (for example) 'zone' and 'base' are understood in this context, particularly since both have more than one meaning in English. [[User:Tomchance|Tomchance]] 08:24, 19 January 2007 (CET)

:: Good point. How can we test this? Float names by people on irc or blogs or? --[[User:Aseigo|Aseigo]] 00:15, 20 January 2007 (CET)