> On Saturday 04 January 2014 19:40:46 Christoph Cullmann wrote: > > > On Saturday 04 January 2014 19:18:56 Christoph Cullmann wrote: > > > > Hi, > > > > > > > > I cleanup the frameworks branch in kate.git to only have libktexteditor > > > > lib > > > > and the KTextEditor/ktexteditor includes to be installed as public API. > > > > > > > > Now, for 5.x, if others port over, like KDevelop, is it a good idea to > > > > keep > > > > the ktexteditor parts in kate.git, together with the applications, or > > > > shall > > > > that be split again into a khtml like framework? > > > > > > We want to make separate releases of the 3 major products: > > > frameworks, apps and workspace. > > > > > > So libs that are used by workspace and apps, should be in frameworks. > > > For libs that are only used by apps .... I guess they can either be in > > > apps > > > or > > > in frameworks. > > > > > > So IMHO the question is: is there a chance the KDE workspace will need > > > it? > > > > > > Of course the other question is: do you want to make it available as a > > > framework for non-KDE developers to use in Qt applications? > > > > > > If the answer is yes to either of these questions, then you need to split > > > it out into a framework. > > > > I am not sure if workspace apps will require it, but I doubt it, given an > > plain text editor is nothing the average application needs, guess only > > stuff like KDevelop/Kile/... will depend on it. > I think it gets used in workspace. Try KRunner and enter "desktop console". > Though I don't know what it uses in the implementation and that code is not > yet ported. I see, yeah, thats KatePart it seems to me.
Anyway, I am all for going to have a KF5 KTextEditor framework, will make it more approachable for other projects to use it. And unlike in 4.x, KTextEditor would always provide the implementation directly (KatePart merged in, internally) and some wrapper KParts for the people preferring to just load a simple part without any more tight integration. David showed me the kdeexamples/framework-template and the kdelibs-split script. Still, I have one question: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other "trick" behind I just don't see ATM? I would try to convert to framework style git in some personal repo on git.kde.org and post that here for review if I do it right ;) Greetings Christoph -- ----------------------------- Dr.-Ing. Christoph Cullmann --------- AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANY WWW: http://www.AbsInt.com -------------------------------------------------------------------- Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234 _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
