Proposal to plan for "Milestone Releases" on the way to KDE4

Jaroslaw Staniek js at
Thu Jan 26 20:20:47 GMT 2006

Alexander Dymo said the following, On 2006-01-26 00:40:

> On Wednesday 25 January 2006 23:11, Adam Treat wrote:
>>Because KDevelop suffers from a terrible problem.  None of us have made
>>KDevelop our priority app.  Most of the KDevelop developers work on other
>>things or have other things/priorities going on.  It is not a good
>>situation. And I agree, KDevelop and our KDE development tools do not get
>>nearly as much attention as they require.  These apps and tools really
>>should be the best of the bunch, but they are suffering from neglect.
> I think KDevelop and development tools are suffering because they was
> not positioned correctly. Two years ago I was overenthusiastic about the
> possibility for KDevelop to become the universal IDE for all possible
> development tasks. Looks like I wasn't alone and eventually the whole
> team put a large amount of effort accomplishing those tasks.
> I personally put lots of effort into making KDevelop a development
> platform top build any kind of plugin-based applications.
> But it looks like we paid too much attention to multilingual, plugin-based 
> architecture and forgot the main goal.

Yeah, monolitic architecture has its advantages (Linux, anyone?), plugin based 
one can be also usable, unless we make it bloated "by accident". In my 
department, Kexi, though we're defining plugin interfaces and factories at 
many levels, it's more like defining interfaces and implementation using 
'black-box' theory, at least I hope it's important for us.

What we need is active user base, giving feedback after every release, so 
we're trying to release frequently. IIRC, KDevelop is much longer in the wild 
and already usable, many of it's goals have been achieved. I hope we can learn 
something from problems mentioned in this thread too.

One thing I'd note that's not necessary a good idea is 
'we-know-better-than-evil-competition-how-to-design-this-stuff' zealotry that 
sometimes ends with too many attempts for redesigning interfaces, worrying 
usability folks. I am not talking about any given project here.

This doesn't  mean we should develop 1-to-1 clones of the mainstream apps or 
interfaces (we're good at this, anyway) but looking how other stuff is 
performing shouldn't be seen as a shame. From my and (I guess) a few of us 
experience, I can admit that looking in details of how competition has 
resolved certain issues, is an usual, important part of activity in most 
for-profit (also closed) projects. In many cases, competition aleady spent 
thousand hours/dollars to resolve the issues and not always the money were 
just lost.
We, developers, don't have to like such analysis and don't need to perform 
them. What I said is that I've avoided quite a few gotchas of the interface 
design or the app behaviour.

So, a clear message to our developers/testers/users could be nice, IMO: if 
you're user (maybe former) of a different framework/interface/environment 
please tell us what you loved there and miss here. This includes all layers of 
the design up to packaging, easy installation, and support.

my 0.02 PLN

regards / pozdrawiam,
  Jaroslaw Staniek / OpenOffice Polska

  Kexi Developer: |
  Kexi Support:
  Kexi For MS Windows:
  KDE3, KDE4 Libraries For Developing MS Windows Applications:

More information about the kde-core-devel mailing list