Re: [opensuse] Textbook example of what is right & wrong with the kde bug reporting/fixing process

On Thursday 24 September 2009 07:01:12 David C. Rankin wrote:
On Wednesday 23 September 2009 01:49:39 am John Andersen wrote:
If nothing else this makes it patently obvious the old saw about fixing
it your self, because its open source, to be totally unworkable.
That way can not work anymore. The code base is simply not that simple.

For the right person, with intimate knowledge of the code base this was
quick and efficient. (I didn't say easy).
For Joe Random Hacker, it would be a total mess.

John,

Hi David

Thanks for the recognition earlier in the thread. From my perspective
regression fixes/features like that are the stock-in-trade of distro
specialists like myself, who are a lot closer to the real user's needs, as
opposed to the hypothetical user that most upstream developers have a vague
idea of as they code things. It might seem like it was a painful process to
get this bug fixed, but in this case it became collateral damage in a larger
skirmish between two contributors, which increased the temperature. Aside
from that the bug was triaged inside a week and fixed in 4 and a bit months.
Given the ratio of bug fixers to bug reporters I think that's quite good.

I would also not generalise from this to all KDE 4 bugs. Some components are
very actively maintained (like Plasma and knetworkmanager) whereas others
languish without a maintainer.

You hit the nail on the head. I was amazed and shocked by the new code
changes required just to get a window to appear in kde4.

I think you need to compare this tutorial with something to give your shock
some context. How many LoC are needed to do the same thing in Java? In MFC?
In Tcl?

In the simplest tutorial
http://techbase.kde.org/Development/Tutorials/First_program there are 7 lines
of code, excluding includes, split lines, whitespace and brackets and without
joining multiple statements on one line (anyone remember those old magazine
competitions to write the most elaborate program in 'one' line of BASIC?).
This buys you

* An executable with command line help, author, license, and version metadata
* A main window with caption, buttons, and graphics
* Tooltips, WhatsThis help, and internationalisation

so it's not just a window. For the record if you want "just a window" it's 4
LoC.

Then I was shocked
for a second time when I saw the executable size was 440k just to draw a
window and save and load 1 line of text.

Firstly 440k (11.1, x86_64) is from building in debug mode, the default build
type. If you add -DCMAKE_BUILD_TYPE=release to the cmake line, it slims down
to

-rwxr-xr-x 1 wstephenson users 54970 2009-09-28 21:07 ./tutorial4

That's 54k, for those that are new here. On 32 bit machines it will be even
smaller.

The difference is due to optimisation, debugging symbols, and extra strings
that are stripped out in release mode.

Secondly as well as 'just' a window and saving and loading 1 line of text, you
have

* The features above as well as

* A UI consisting of menus, toolbar and keyboard shortcuts
* Functional standard menu items, including configuration, help access, about
data, bug reporting tool
* A custom clear function with menu item and toolbar button
* A multiline UTF-8 text editor widget with spellchecking, find and replace
* UI layout defined by an XML file
* UI customisable by the user
* Querying the user for save file name
* The ability to load or save to remote or local filesystems
* File load error reporting

Finally, these tutorials aren't there to show you the most abbreviated
example or a toy application, which are all also possible in less space, but
to teach you how to write an editor that is a real KDE app, demonstrating many
of the features needed to write a useful tool.

Which in 158 lines of code (counted the lazy way) is pretty darn good. And
consider the build system needed for this is only 18 LoC.

See:
http://techbase.kde.org/Development/Tutorials#Introduction_To_KDE_4_Program
ming

Yes! Everybody! Even if fixing Plasma regressions in 200 LoC and one evening
takes a CS degree and years of hanging round people who think K stands for
Kool, there are literally thousands of low hanging fruit bugs that people like
you can fix with only a few days' practice.

and more specifically:
http://techbase.kde.org/Development/Tutorials/Saving_and_loading


The old tinkerer has no chance with kde4. I'm not so sure that is good for
opensource. Yes, the kde4 is an excellent looking desktop, but when one of
the primary desktops for Linux raises the coding barriers well above where
they there were, the pool of people that can contribute applications for
the desktop dramatically shrinks.

C++ is not the easiest language to learn, but you'll have to try harder than
that to convince me that C++ & KDE & Qt is not the easiest C or C++ platform
to write full-featured applications in. And if C++ doesn't stir your tea,
there are Python, Ruby and C# bindings to code in
(http://techbase.kde.org/Development/Languages - tutorials there also)

Going through the tutorials, basic kde4 coding is friendly enough to
understand, but from the looks of it, you will have to basically re-learn
everything related to kde programming to make use of the new kde4 tools it
is built from.

Some things changed from KDE 3 to KDE 4, but the tutorials above would be
basically identical.

The only area that your statement does hold for would be programming Plasma,
where everything did change compared to coding kicker applets, but where even
more care was made to make developing for it easier, you can use all the
languages given above, and there are already 250 plasmoids listed on kde-
look.org (I can't see how many kicker applets were submitted in 5 years of KDE
3, since kde-look.org has removed them from its navbar).

So I'm really happy you took the time to try the tutorial - I hope it is less
shocking to you now, and you stick at it.

Will

--
Will Stephenson, openSUSE Team
SUSE LINUX Products GmbH - Nürnberg - AG Nürnberg - HRB 16746 - GF: Markus Rex
--
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

Loading