Boudewijn Rempt | 1 Jul 2012 07:02

Using userbase for manuals

I'm actually not sure kde-core-devel is the right list... But the e.V. mailing list certainly isn't, and we
don't seem to have any place for discussions that affect KDE as a whole.

In any case, Ingo Malchow said in his blog (http://blog.neverendingo.de/?p=125)

"We have a great userbase.kde.org but developers don’t use it that much, nor is there any links from
applications towards Userbase."

Well, actually we have. I replaced the offline help documentation in Krita with a link to the manual on
userbase. I have done this for two reasons:

* I couldn't maintain the offline manual anyway after the change to 2.0
* this way the user gets sent right to the place where they can contribute to the manual (and I've got users
contributing to it now)

I'm not concerned that users cannot access the help when they are off-line. That's a vanishingly rare
situation these days, the big thing is that it gets users right where they can fix the manual (Except on
windows, where the browser invocation seems broken).

After yesterday's discussion where David said that for frameworks/qt5 the help center invocation is
actually one of the trickier things, I'm giving this out for consideration for other app developers...

--

-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl

Albert Astals Cid | 1 Jul 2012 09:21
Picon
Favicon
Gravatar

Re: Using userbase for manuals

El Diumenge, 1 de juliol de 2012, a les 08:02:28, Boudewijn Rempt va escriure:
> I'm actually not sure kde-core-devel is the right list... But the e.V.
> mailing list certainly isn't, and we don't seem to have any place for
> discussions that affect KDE as a whole.
> 
> In any case, Ingo Malchow said in his blog
> (http://blog.neverendingo.de/?p=125)
> 
> "We have a great userbase.kde.org but developers don’t use it that much, nor
> is there any links from applications towards Userbase."
> 
> Well, actually we have. I replaced the offline help documentation in Krita
> with a link to the manual on userbase. I have done this for two reasons:
> 
> * I couldn't maintain the offline manual anyway after the change to 2.0
> * this way the user gets sent right to the place where they can contribute
> to the manual (and I've got users contributing to it now)
> 
> I'm not concerned that users cannot access the help when they are off-line.
> That's a vanishingly rare situation these days

I disagree, as a matter of fact, I don't have internet connection in the room 
in my hostel, so if i had a need to use krita I'd need to read its manual 
(since my painting/drawing skills are null) and i'd be not happy to discover I 
can't read the manual.

Cheers,
  Albert

> the big thing is that it
(Continue reading)

Kevin Ottens | 1 Jul 2012 09:43
Picon
Favicon

Re: Using userbase for manuals

Hello,

On Sunday 1 July 2012 08:02:28 Boudewijn Rempt wrote:
> I'm actually not sure kde-core-devel is the right list... But the e.V.
> mailing list certainly isn't, and we don't seem to have any place for
> discussions that affect KDE as a whole.

Well, I think nowadays the name of kde-core-devel is confusing. The customs 
made its focus evolve over time, I think nowadays it's really the forum where 
the different KDE teams meet. It's really "kde-townhall" IMO. Anyway... I'm 
sidetracking a bit. :-)

> In any case, Ingo Malchow said in his blog
> (http://blog.neverendingo.de/?p=125)
> 
> "We have a great userbase.kde.org but developers don’t use it that much, nor
> is there any links from applications towards Userbase."
> 
> Well, actually we have. I replaced the offline help documentation in Krita
> with a link to the manual on userbase. I have done this for two reasons:
> 
> * I couldn't maintain the offline manual anyway after the change to 2.0
> * this way the user gets sent right to the place where they can contribute
> to the manual (and I've got users contributing to it now)

I think that would be a great improvement. The current way we deal with user 
documentation just doesn't scale. Trying to foster at this easier to 
contribute even from users documentation would help greatly with that. If we 
can get more user engagement that'd be a win for our community.

(Continue reading)

Kevin Ottens | 1 Jul 2012 09:49
Picon
Favicon

Re: Using userbase for manuals

On Sunday 1 July 2012 09:21:08 Albert Astals Cid wrote:
> El Diumenge, 1 de juliol de 2012, a les 08:02:28, Boudewijn Rempt va 
escriure:
> > I'm actually not sure kde-core-devel is the right list... But the e.V.
> > mailing list certainly isn't, and we don't seem to have any place for
> > discussions that affect KDE as a whole.
> > 
> > In any case, Ingo Malchow said in his blog
> > (http://blog.neverendingo.de/?p=125)
> > 
> > "We have a great userbase.kde.org but developers don’t use it that much,
> > nor is there any links from applications towards Userbase."
> > 
> > Well, actually we have. I replaced the offline help documentation in Krita
> > with a link to the manual on userbase. I have done this for two reasons:
> > 
> > * I couldn't maintain the offline manual anyway after the change to 2.0
> > * this way the user gets sent right to the place where they can contribute
> > to the manual (and I've got users contributing to it now)
> > 
> > I'm not concerned that users cannot access the help when they are
> > off-line.
> > That's a vanishingly rare situation these days
> 
> I disagree, as a matter of fact, I don't have internet connection in the
> room in my hostel, so if i had a need to use krita I'd need to read its
> manual (since my painting/drawing skills are null) and i'd be not happy to
> discover I can't read the manual.

It's all very hypothetical isn't it? :-)
(Continue reading)

Andras Mantia | 1 Jul 2012 10:14
Picon
Favicon

Re: Using userbase for manuals

On Sunday, July 01, 2012 09:21:08 AM Albert Astals Cid wrote:
> I disagree, as a matter of fact, I don't have internet connection in the
> room  in my hostel, so if i had a need to use krita I'd need to read its
> manual (since my painting/drawing skills are null) and i'd be not happy to
> discover I can't read the manual.

I agree with you. Another situation is when traveling or when you are in a 
country with roaming phone connection. There might also be closed down network 
with KDE application, where you don't have full internet access.

Andras

Albert Astals Cid | 1 Jul 2012 10:17
Picon
Favicon
Gravatar

Re: Using userbase for manuals

El Diumenge, 1 de juliol de 2012, a les 09:49:11, Kevin Ottens va escriure:
> On Sunday 1 July 2012 09:21:08 Albert Astals Cid wrote:
> > El Diumenge, 1 de juliol de 2012, a les 08:02:28, Boudewijn Rempt va
> 
> escriure:
> > > I'm actually not sure kde-core-devel is the right list... But the e.V.
> > > mailing list certainly isn't, and we don't seem to have any place for
> > > discussions that affect KDE as a whole.
> > > 
> > > In any case, Ingo Malchow said in his blog
> > > (http://blog.neverendingo.de/?p=125)
> > > 
> > > "We have a great userbase.kde.org but developers don’t use it that much,
> > > nor is there any links from applications towards Userbase."
> > > 
> > > Well, actually we have. I replaced the offline help documentation in
> > > Krita
> > > with a link to the manual on userbase. I have done this for two reasons:
> > > 
> > > * I couldn't maintain the offline manual anyway after the change to 2.0
> > > * this way the user gets sent right to the place where they can
> > > contribute
> > > to the manual (and I've got users contributing to it now)
> > > 
> > > I'm not concerned that users cannot access the help when they are
> > > off-line.
> > > That's a vanishingly rare situation these days
> > 
> > I disagree, as a matter of fact, I don't have internet connection in the
> > room in my hostel, so if i had a need to use krita I'd need to read its
(Continue reading)

Friedrich W. H. Kossebau | 1 Jul 2012 10:22
Picon
Favicon

Re: Using userbase for manuals

Hi,

Am Sonntag, 1. Juli 2012, 09:21:08 schrieb Albert Astals Cid:
> El Diumenge, 1 de juliol de 2012, a les 08:02:28, Boudewijn Rempt va 
escriure:
> > In any case, Ingo Malchow said in his blog
> > (http://blog.neverendingo.de/?p=125)
> > 
> > "We have a great userbase.kde.org but developers don’t use it that much,
> > nor is there any links from applications towards Userbase."
> > 
> > Well, actually we have. I replaced the offline help documentation in Krita
> > with a link to the manual on userbase. I have done this for two reasons:
> > 
> > * I couldn't maintain the offline manual anyway after the change to 2.0
> > * this way the user gets sent right to the place where they can contribute
> > to the manual (and I've got users contributing to it now)
> > 
> > I'm not concerned that users cannot access the help when they are
> > off-line.
> > That's a vanishingly rare situation these days
> 
> I disagree, as a matter of fact, I don't have internet connection in the
> room in my hostel, so if i had a need to use krita I'd need to read its
> manual (since my painting/drawing skills are null) and i'd be not happy to
> discover I can't read the manual.

+1

There are lot of nice places on this planet where there is no (good or cheap) 
(Continue reading)

Albert Astals Cid | 1 Jul 2012 11:11
Picon
Favicon

Review Request: Do not leave dangling pointers in KToolbar when xml clients die

This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105399/

Review request for kdelibs and David Faure.
By Albert Astals Cid.

Description

If we add xmlclients to ktoolbar when plugging them in we should remove them when unplugging them

Testing

The crash is gone as described in the steps in the bug to reproduce
Bugs: 296622

Diffs

  • kdeui/widgets/ktoolbar.h (c78263f)
  • kdeui/widgets/ktoolbar.cpp (c6bd200)
  • kdeui/xmlgui/kxmlguifactory_p.cpp (083ddf5)

View Diff

Andras Mantia | 1 Jul 2012 11:15
Picon
Favicon

Re: Fwd: Re: Kontact Crashes at Startup for One User Only

James Booth wrote:

> For future reference for anyone else that has this problem, Andras's
> suggestion worked. Thanks!

Sorry, I forgot to send to the list (didn't check the To field).

Did you make a bug report?

Andras

David Faure | 1 Jul 2012 11:14
Picon
Favicon
Gravatar

Re: Review Request: remove KEncodingDetector from tier1/kcodecs

This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/105392/

Great work! I noticed a few things though: * in your initial analysis, you said KEncodingDetector had code to detect the encoding from the html/xml and http headers. Is this functionality lost during this port, in khtml? * you deleted the KEncodingDetector unittest, but apparently KEncodingProber has no unittests. Could you port the old unittest to KEncodingProber, in order to at least validate it a bit, and ideally could you extend the unittest for things that only the prober can do? * rather than deleting KEncodingDetector, please move it to kde4support (in a separate commit, possibly), so that source compatibility is preserved (just in case there is some application out there that uses it).

- David


On June 30th, 2012, 11:01 a.m., Hui Ni wrote:

Review request for kdelibs, Kevin Ottens and David Faure.
By Hui Ni.

Updated June 30, 2012, 11:01 a.m.

Description

hi, this is my first contribution to kde frameworks. This patch removes KEncodingDetector class from tier1/kcodecs and ports all related bits in kdelibs to KEncodingProber class. proposal raised at http://mail.kde.org/pipermail/kde-frameworks-devel/2012-June/000738.html KEncodingDetector is actually KEncodingProber + encoding priority list + QTextDecoder, and the later two things are used only in khtml. things removed: enum KEncodingDetector::EncodingChoiceSource -> removed KEncodingDetector::setEncoding -> removed, implement it in khtml code KEncodingDetector::encodingChoiceSource -> removed KEncodingProber::encodingName -> removed, avoid potential memory leak one to one changes: enum KEncodingDetector::AutoDetectScript -> enum KEncodingProber::ProberType KEncodingDetector::encoding -> KEncodingProber::encoding KEncodingDetector::visuallyOrdered -> check KEncodingProber::encoding is hebrew or not KEncodingDetector::autoDetectLanguage -> KEncodingProber::proberType KEncodingDetector::setAutoDetectLanguage -> KEncodingProber::setProberType KEncodingDetector::decode -> KEncodingProber::feed + QTextCodec::codecForName(prober.encoding())->toUnicode KEncodingDetector::decodeWithBuffering -> KEncodingProber::feed, feed, feed + check KEncodingProber::state + QTextCodec::codecForName(prober.encoding())->makeDecoder KEncodingDetector::decodedInvalidCharacters -> QTextCodec::codecForName(prober.encoding())->makeDecoder + hasFailure KEncodingDetector::resetDecoder -> KEncodingProber::reset KEncodingDetector::flush -> KEncodingProber::feed, feed, feed + QTextCodec::codecForName(prober.encoding())->toUnicode KEncodingDetector::scriptForName -> KEncodingProber::proberTypeForName KEncodingDetector::nameForScript -> KEncodingProber::nameForProberType KEncodingDetector::hasAutoDetectionForScript -> if (proberType == KEncodingProber::None) ... else ...

Diffs

  • kdeui/actions/kcodecaction.h (627d770)
  • kdeui/actions/kcodecaction.cpp (97a8a90)
  • khtml/ecma/xmlhttprequest.h (7eb2012)
  • khtml/ecma/xmlhttprequest.cpp (11bcc46)
  • khtml/khtml_part.h (340ece1)
  • khtml/khtml_part.cpp (d9d1250)
  • khtml/khtmlpart_p.h (d46d254)
  • khtml/test_regression.cpp (8b2fa15)
  • khtml/xml/dom_docimpl.h (71bc13f)
  • khtml/xml/dom_docimpl.cpp (5e34d18)
  • khtml/xml/xml_tokenizer.cpp (f65be63)
  • tier1/kcodecs/autotests/CMakeLists.txt (9ce6f85)
  • tier1/kcodecs/autotests/kencodingdetectortest.h (a9eedec)
  • tier1/kcodecs/autotests/kencodingdetectortest.cpp (d54fcef)
  • tier1/kcodecs/src/CMakeLists.txt (e58c438)
  • tier1/kcodecs/src/guess_ja.cpp (0631815)
  • tier1/kcodecs/src/guess_ja_p.h (e34d986)
  • tier1/kcodecs/src/kencodingdetector.h (e6a0444)
  • tier1/kcodecs/src/kencodingdetector.cpp (1d64bdd)
  • tier1/kcodecs/src/kencodingprober.h (da4b958)
  • tier1/kcodecs/src/kencodingprober.cpp (42beac0)
  • tier1/kcoreaddons/src/text/kstringhandler.h (b9b6c2e)

View Diff


Gmane