<br><br><div class="gmail_quote">On Sat, Jan 16, 2010 at 10:48 PM, Milian Wolff <span dir="ltr"><<a href="mailto:mail@milianw.de">mail@milianw.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Andreas Pakulat, 16.01.2010:<br>
<div class="im">> On 16.01.10 22:19:44, David Nolden wrote:<br>
> > Am Samstag 16 Januar 2010 20:57:14 schrieb Andreas Pakulat:<br>
> > > So apparently people are happy with freezing. That would mean complete<br>
> > > feature freeze in a bit above 2 weeks (if my calendar is correct). I'll<br>
> > > announce it on monday on the list (unless someone objects)<br>
> ><br>
> > A total feature freeze in 2 weeks is ok, but only if UI tweaks, like<br>
> > making stuff more consistent or renaming it, are not put into the<br>
> > "feature" category.<br>
><br>
> Either we have a feature freeze, which means no new features whatsoever<br>
> only bugfixes or we don't do it yet. We can certainly delay the<br>
> string-freeze until after the sprint.<br>
<br>
</div>What about we continue as we are doing these days? We all polish and fix what<br>
we can and no one gets the idea to push some fancy new stuff in. I personally<br>
think that in the past weeks not a single new feature was implemented. All<br>
these things were just polishing of existing features. A tooltip here or a<br>
context menu there is - to me - not really something we should forbid during<br>
<div class="im">the sprint.<br>
<br>
> > Apart from that, there is 2 important mini-features I think that are<br>
> > still missing:<br>
> > - Path-specific source-formatter settings (you wanted to work on it this<br>
> > weekend, so might not be a problem)<br>
><br>
> I might actually not get around to that, kinda sick over here<br>
> unfortunately :(<br>
<br>
</div>Get well soon!<br>
<div class="im"><br>
> > - A blacklist for project-items, so we can finally get the "*~", ".bak",<br>
> > ".rej" etc. crap out of quickopen and the project tree.<br>
><br>
> That just needs to be moved from the generic-manager into a utility<br>
> class that all managers can use. (I've pondered already quite some times<br>
> about basing the cmake manager on the generic one class-wise, but not<br>
> something for 1.0).<br>
<br>
</div>Imo the GenericManager is only generic by name and the files it supports, not<br>
in it's Class architecture. Esp. the hoops it jumps to support remote files is<br>
something CMake should not bother with. Extract the features you need and put<br>
them into the BaseClass or a Utility, but don't make CMake extend the<br>
GenericManager (imo).<br></blockquote><div>+1<br><br>Actually the shared code wouldn't be that much i think. But well, of course we should share the most.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<div><div></div><div class="h5">--<br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de">mail@milianw.de</a><br>
<a href="http://milianw.de" target="_blank">http://milianw.de</a><br>
</div></div><br>--<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
<br></blockquote></div><br>Aleix<br>