KDevelop4 architecture rework

Hi!
I've started the rework of the architecture in
branches/work/kdevelop-sublime-integration today.

The goals are (as discussed previously):
- to separate interfaces from shell
- to clean up both shell and interfaces
- to review some design decisions in favor of known working
solutions 
  from KDevelop3.

At this point I've refactored Core (made it look and work
like KDevAPI
in KDevelop3), PluginController (mostly cleanups) and
MainWindow
(it's now Sublime::MainWindow and just waits for more stuff
from
Sublime library to be used).

So far the consequences are: clearer initialization
procedure, 
minimal interfaces and (still) working plugin architecture.
I'll keep you informed as the rework continues. Feel free to
contribute
to this cleanup effort, but just make sure you contacted me
at irc before
you start over.
I'd like to refactor Document/Part controllers by myself.
Also MainWindow
is my job too. But everything else needs attention as well.
For example, the
independent task would be to experiment with inter-plugin
deps and BC ideas
(see http://lists.kde.org/?l=kdevelop-devel&m
=112620787223741&w=2)
and try to make use of them in KDevelop extension interfaces
mechanism.
If everything works ok, project manager needs to be modified
so it provides
extension interfaces.

Another task would be to sort out utility stuff that still
lies everywhere 
in lib/. Take a look at Matt's reply to "useful stuff
in lib" thread for
hints.

Also there're smaller tasks. Removing unused code, checking
dependencies
between files and removing extra #include's, reformatting
the code when nesessary.


_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

This mail is primarily directed at Matt.

Unfortunately I had no time and internet in the last weeks
before the 
3.4-Release, so I wasn't able to polish a few parts of the
code-completion 
and parsing that still needed some(the fixes I did the last
days).

Is there any way to get such little fixes backported into a
stable 
kdevelop-3.4-version before the release of 3.4.1? Maybe for
example into the 
version that will be shipped with kde 3.5.6?

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Of course I meant KDevelop 3.4, not 4. 

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Saturday, 20. January 2007 23:11, David Nolden wrote:
> Is there any way to get such little fixes backported
into a stable
> kdevelop-3.4-version before the release of 3.4.1? Maybe
for example into
> the version that will be shipped with kde 3.5.6?

The version that will be shipped with KDE 3.5.6 is 3.4.
3.4.1 should be less of a problem, but that's Matt's
domain.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 20.01.07 23:23:46, Alexander Dymo wrote:
> independent task would be to experiment with
inter-plugin deps and BC ideas
> (see http://lists.kde.org/?l=kdevelop-devel&m
=112620787223741&w=2)
> and try to make use of them in KDevelop extension
interfaces mechanism.
> If everything works ok, project manager needs to be
modified so it provides
> extension interfaces.

I modified your example to test wether one can load 2
plugins that
implement the same extension and it seems to work. I attach
the source.

Andreas

-- 
Learn to pause -- or nothing worthwhile can catch up to
you.

On Saturday 20 January 2007 4:31 pm, Jakob Petsovits wrote:
> On Saturday, 20. January 2007 23:11, David Nolden
wrote:
> > Is there any way to get such little fixes
backported into a stable
> > kdevelop-3.4-version before the release of 3.4.1?
Maybe for example into
> > the version that will be shipped with kde 3.5.6?
>
> The version that will be shipped with KDE 3.5.6 is
3.4.
> 3.4.1 should be less of a problem, but that's Matt's
domain.
>

No, the version that is shipping with KDE 3.5.6 is KDevelop
3.3.6. We are 
releasing KDevelop 3.4.0 separately
-- 
Matt

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Hi,

Quoting Jakob Petsovits <jpetsogmx.at>:

> On Sunday, 21. January 2007 14:52, Roberto Raggi
wrote:
>> - The Koncrete namespace
>>
>> I know a lot of poople think that weird names for
new KDE projects is
>> cool, but if you ask me this is 100% stupid. It is
OK to have a cool
>> name for our code base(like gideon for KDevelop3),
but do we really
>> have to use these cool names in our *PUBLIC API*!
>
> Afaik, this rename was done because lib/ is
specifically _not_ only the base
> for KDevelop but at least also for Quanta, and I heard
another project based
> on it is in the works. So this was done to get rid of
the impression that
> KDevPlatform is for KDevelop only.

Just a little thing. The name of this project *is* KDevelop.
If we will 
have a platform the name of the platform will be the
KDevelop 
Platform(codename whatever you want for the release 4.0).
BTW I don't 
think Quanta will be based on KDevelop. Quanta is a great
product, with 
dedicated developers.
KDevelop4 is a broken platform that needs at least 1-2 years
of work. 
The Quanta project already has a good code base and a nice
GUI. If we 
want the Quanta guys to switch to KDevelop we have to show
that 
KDevelop is a good platform for Quanta. That means they will
*evaluate* 
the KDevelop Platform at the end of 2007.

Again, if KDevelop is not good for you then feel free to
start the 
Koncrete project. This *is* KDevelop!


ciao robe



------------------------------------------------------------
----
This message was sent using IMP, the Internet Messaging
Program.



_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

Am Sonntag, 21. Januar 2007 04:58 schrieb Matt Rogers:
> On Saturday 20 January 2007 4:11 pm, David Nolden
wrote:
>
> Are these so important that they would be considered
showstoppers or just
> bugs where we can release a new version a week or so
later? I'm waiting for
> ftpadmin to move the tarballs so that they get picked
up by the kde.org ftp
> mirrors and then we'll be releasing.
>
> We can always put out another release in two weeks or
so.

Hmm it depends. 

1.
There is that checkbox "preprocess included
headers". When that is active an 
error for the error-list is created for each missing
include-file. I've 
noticed that if you haven't set include-path correctly and
kdevelop parses 
all files of a big project, the error-list gets unbelievably
long and 
kdevelop quasi-hangs(including the user-interface) at about
10%, because all 
the time is spent handling the error-list.

That is fixed now.

2.
I finally fixed something that already caused some crashes
in the past, but at 
that time I couldn't look at it, so I only workarounded it.
It was the crash 
that was on the list with the recursive
appendNextFunction(...)-backtrace.
That same basic error was still able to cause very long
hangs in 
code-completion(See Christian Schneider's report).

That's fixed too(now at the source of the problem)

3.
When "preprocess included headers" is enabled,
namespace-imports and aliases 
from imported headers are used. A linear intersection-search
had to be done 
in the global namespace to find out what exact aliases and
imports have to be 
used in each case. I noticed that for big projects, with
many global imports, 
this search can extremely dominate the code-completion-time,
and make 
code-completion(or the navigation-menu) nearly unusable. 

I fixed that too by creating a much more efficient
intersection-search.


These were the only "real" problems of the current
code-completion 
implementation that I know.

I fear that when kdevelop 3.4 is shipped, most people will
check out the cool 
new features and also check "preprocess included
headers", and in some cases 
they may get a bad impression of kdevelop. Also long hangs
or crashes(point 
2) always look bad.

That's why I think these 3 fixes should get into stable
kdevelop as fast as 
possible.

The exact commits I'm talking about are r624879, r624975,
r625193, r625278, 
r625373, r625617, r625648 (some efforts are split across
multiple commits)

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel