[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: libplasma in 4.2: binary compatibility and moving to kdelibs
From:       "=?ISO-8859-1?Q?Alexis_M=E9nard?=" <darktears31 () gmail ! com>
Date:       2008-07-29 17:04:27
Message-ID: 81941aea0807291004qdb7b5a4o6f691902bcdb6c06 () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


i'm for an another API review...Akademy is near and it can be done quickely.
Is Rob Scheepmaker comes to Akademy?

We can do another round in our lib, wait a little (2 months) and move plasma
into kdelibs. The time can be used to test our api in applets especially the
new baby : Extender.



2008/7/29 Aaron J. Seigo <aseigo@kde.org>

> hi all...
>
> so 4.2 is here and the Big Questions come with it:
>
> Binary Compatibility
> ============
>  should we break binary compatibility one last time? if so that means we
> can:
>
>        * do one more API review (though it won't be nearly as drastic as
> the one in
> 4.1)
>        * add some of the new features that are coming in 4.2 in a more
> natural way.
>
> and example of "more natural" is having a virtual initExtenderItem in
> Applet;
> that's a binary incompatible change, and the alternative is to put it in
> Extender (a new class) and make people subclass that. however, it would be
> less comfortable that, imho.
>
> Where Does It Live?
> ============
>
> moving libplasma into kdelibs was a goal we stated for 4.2 back when
> figuring
> out what 4.1 would be. i'd like to see this happen still as it would allow
> more applications to use libplasma in more interesting ways.
>
> the Package* classes may want to move into khotnewstuff ... that's
> something
> we'd need to examine.
>
> ConfigXml really ought to be in libkdeui alongside KConfigSkeleton imho.
> (kdeui
> because it uses QColor; perhaps we could manage to shove it into kdecore
> using
> QVariant cleverly? hm.)
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Trolltech
>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>

[Attachment #5 (text/html)]

<div dir="ltr">i&#39;m for an another API review...Akademy is near and it can be done \
quickely. Is Rob Scheepmaker comes to Akademy?<br><br>We can do another round in our \
lib, wait a little (2 months) and move plasma into kdelibs. The time can be used to \
test our api in applets especially the new baby : Extender.<br> \
<br>&nbsp;<br><br><div class="gmail_quote">2008/7/29 Aaron J. Seigo <span \
dir="ltr">&lt;<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>&gt;</span><br><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"> hi all...<br>
<br>
so 4.2 is here and the Big Questions come with it:<br>
<br>
Binary Compatibility<br>
============<br>
&nbsp;should we break binary compatibility one last time? if so that means we \
can:<br> <br>
 &nbsp; &nbsp; &nbsp; &nbsp;* do one more API review (though it won&#39;t be nearly \
as drastic as the one in<br> 4.1)<br>
 &nbsp; &nbsp; &nbsp; &nbsp;* add some of the new features that are coming in 4.2 in \
a more natural way.<br> <br>
and example of &quot;more natural&quot; is having a virtual initExtenderItem in \
Applet;<br> that&#39;s a binary incompatible change, and the alternative is to put it \
in<br> Extender (a new class) and make people subclass that. however, it would be<br>
less comfortable that, imho.<br>
<br>
Where Does It Live?<br>
============<br>
<br>
moving libplasma into kdelibs was a goal we stated for 4.2 back when figuring<br>
out what 4.1 would be. i&#39;d like to see this happen still as it would allow<br>
more applications to use libplasma in more interesting ways.<br>
<br>
the Package* classes may want to move into khotnewstuff ... that&#39;s something<br>
we&#39;d need to examine.<br>
<br>
ConfigXml really ought to be in libkdeui alongside KConfigSkeleton imho. (kdeui<br>
because it uses QColor; perhaps we could manage to shove it into kdecore using<br>
QVariant cleverly? hm.)<br>
<font color="#888888"><br>
--<br>
Aaron J. Seigo<br>
humru othro a kohnu se<br>
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA &nbsp;EE75 D6B7 2EB1 A7F1 DB43<br>
<br>
KDE core developer sponsored by Trolltech<br>
<br>
</font><br>_______________________________________________<br>
Plasma-devel mailing list<br>
<a href="mailto:Plasma-devel@kde.org">Plasma-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/plasma-devel" \
target="_blank">https://mail.kde.org/mailman/listinfo/plasma-devel</a><br> \
<br></blockquote></div><br></div>



_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic