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@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org