On Monday 19 November 2012 17:52:39 Kevin Ottens wrote:
> * The only reason it depends on KConfig is to take a look in kdeglobals, we
> might want to do that differently (QSettings could be a contender?)
I don't think we want that. Building on top of two translation frameworks is
already going t
On Sunday 18 November 2012 20:53:36 Chusslove Illich wrote:
> > [: David Faure :]
> > Yes, please compile whatever you have ;)
>
> Ok, I pushed it.
>
> > I'm a bit surprised that ki18n depends on kservice, since kservice wants
> > to depend on i18n (automatic catalog loading). I guess ki18n uses
On Monday 19 November 2012, Sune Vuorela wrote:
> On 2012-11-18, Stephen Kelly wrote:
> > Sune Vuorela wrote:
> >> I'm currently trying to get threadweaver built separately (for qt4). and
> >> the build system is way too complicated. and way too complex. and way
> >> too wrong.
> >>
> >> I though
Hello,
On Sunday 11 November 2012 23:09:43 Valentin Rusu wrote:
> Working on splitting kdeui/dialogs to staging/kdialogs I find that
> there's also dialog in kdeui/colors, because of its dependency on
> kmessagebox.
>
> Should I also move it to staging/kdialogs or should I replace
> KMessageBox wi
On 2012-11-19, Stephen Kelly wrote:
>> I don't have a link to 'you should not inherit sonames from other
>> modules'. but it sholud kind of be common sense as we also see in
>> various areas of current KDE land where e.g. libkmailprivate from kdepim
>> 4.4 is not having a matching SONAME, but gets
Hello,
On Thursday 08 November 2012 20:28:59 Valentin Rusu wrote:
> I Just wanted you to know that I just pushed the kemoticons relocation
> to /staging.
I know I'm pushing people away from kdelibs splitting ATM, but that one should
be independent enough from the rest that splitting it should be
Hello,
On Saturday 10 November 2012 21:03:42 Valentin Rusu wrote:
> Does that mean that kdeutil/dialogs is already taken care of, despite of
> the TODO item on the July iteration on the epics page?
It got started then stalled unfortunately. See my other email, I think we
should stay away from spl
Hello mechanics[*],
Just a quick email to let you know that everyone should consider the kdelibs
splitting tasks on hold. I edited the wiki page accordyingly, but I thought
it'd be welcome to also email about that move:
http://community.kde.org/Frameworks/Epics/Splitting_kdelibs
The reasoning is
Hello,
On Wednesday 14 November 2012 20:37:53 Valentin Rusu wrote:
> I have a question about KMessage class from kdeui/dialogs.
I actually got an answer for that one only recently. :-)
> According to the epics page, kdeui/dialogs will go to tier3.
> On the other hand, kdeui/jobs will go to tier2
Sune Vuorela wrote:
> On 2012-11-18, Stephen Kelly wrote:
>> Sune Vuorela wrote:
>>> I'm currently trying to get threadweaver built separately (for qt4). and
>>> the build system is way too complicated. and way too complex. and way
>>> too wrong.
>>>
>>> I thought we earlier agreed on things lik
On 2012-11-18, Stephen Kelly wrote:
> Sune Vuorela wrote:
>> I'm currently trying to get threadweaver built separately (for qt4). and
>> the build system is way too complicated. and way too complex. and way
>> too wrong.
>>
>> I thought we earlier agreed on things like "you should not inherit
>>
On 2012-11-18, Alexander Neundorf wrote:
> On Sunday 18 November 2012, Alexander Neundorf wrote:
>> On Saturday 17 November 2012, Sune Vuorela wrote:
>> > at least the two following things (which is taken from memory, so there
>> > might be typing issues)
>> >
>> > threadweaver_LIBRARY is just "t
On Sunday 18 November 2012 22:00:32 Stephen Kelly wrote:
> David Faure wrote:
> >> Also, if you don't use the feature_summary() function from
> >> FeatureSummary.cmake, then you don't have to use
> >> set_package_properties().
> >
> > Oops, oversight.
>
> I just looked through the zip. Do you hav
13 matches
Mail list logo
