Re: KDE/kdevelop

On 23.04.07 21:01:24, David Nolden wrote:
> On Monday 23 April 2007 20:08:20 Andreas Pakulat
wrote:
> > On 23.04.07 19:33:44, David Nolden wrote:
> > Then why can't this be a client lib + server app
based on that library.
> > Both outside kdevplatform? This would give other
apps the possiblity to
> > benefit from the code and for now only the
teamwork plugin would have
> > the dependecy.
> 
> It is a client lib + server app(in lib/network).

Which makes it not usable for other applications that don't
want to
build on kdevplatform.

> > Well, unless we find someone who's interested in
the code you just added
> > to trunk/ I doubt this will happen. Its not really
small...
> 
> What does that have to do with the size of the code? A
lot of functionality 
> needs a lot of code.. noone would have to look at that
code to use the 
> functionality.

It needs to be maintained, we need to be able to fix
problems without
breaking binary compatibility. And first and foremost
somebody needs to
either make it optional or port it to Qt at least partly
(because as it
seems building common-c++ on Windows is a PITA with
something other than
msvc and MacOS is not even mentioned).

> Writing a plugin that uses the teamwork-framework to
communicate with a remote 
> host would be extremely simple and comfortable, all
needed would be creating 
> an own message-type, and passing that to a not yet
existing 
> teamwork-interface, along with a user the message
should be sent to. Then on 
> the other side the same type of plugin would get
notified of the message and 
> process it. Noone says that someone should implement a
plugin using it for 
> kdevelop-4.0..

This part sounds what should go into kdevplatform, i.e. the
interface
and eventually some code that it needs along with a
dependecy on the
client lib.

> Anyway, since I don't like discussing around that now
and don't think it's all 
> that important, I'll move all dependencies into the
teamwork-folder.

Would you also please make the plugin optional?

Also note: I'm not the only developer here, just the one
answering first
;)

Andreas

-- 
Don't get stuck in a closet -- wear yourself out.

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

On Monday 23 April 2007 21:23:52 Andreas Pakulat wrote:
> Which makes it not usable for other applications that
don't want to
> build on kdevplatform.

You're right. But I think it's not ready yet for use by
other applications. 
Once kdevelop-teamwork is completely ready, it hopefully
will be. In the end 
I'd like to see that stuff in a separate project, there's a
lot of code that 
for example koffice-teamwork(a summer of code project) could
profit from.. 
but It would also make building a full kdevelop as well as
development on 
kdevelop-teamwork more complicated. So it's something to do
later.

> Would you also please make the plugin optional?

I don't know how make things optional with cmake.. but it
would be ok.

My only worry with this would be that many people wouldn't
compile it because 
it is a lot to compile(and slow compiling because of all the
templates) and 
thus would not port it to their api-changes.

On Monday 23 April 2007 21:55:55 Andreas Pakulat wrote:
> As I suspected this doesn't work on windows easily, so
we definetly need
> to replace this.
>
> Andreas

http://www.hyperrealm.com/commoncpp/commoncpp-faq.html
says 
"Current platform support includes Mac OS X, POSIX
systems such as GNU/Linux 
and Solaris, and Microsoft Windows (2000 and later).",
are you sure? And 
don't you confuse it with GNU Common C++?(as seen in the
faq).

Which does not mean that I don't think that it would be
useful optionally 
using qt for that stuff, because that would increase
acceptance of the 
library for kde-development.

greetings, David

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