Re: GSoC proposal: First draft
On Tue, Mar 15, 2011 at 1:52 AM, Hayri Bakici wrote: > I think it's pretty good. You pointed out the reasons of your doings, > which imo are really important. Last year, I wrote two use cases in my > proposal, however I don't know if something like that really fits in > yours. > > Well, the plasmoids are already existent, so use cases are pretty much defined and well-known by user. So I don't think that's required here. Thanks for the comments, btw :) Cheers, Viranch ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Rework KMix DBus API and add KMix plasma dataengine
> On March 14, 2011, 7:06 p.m., Diego Casella wrote:
> > Ok, sorry again for my late reply :(
> > Services are working great, however, I think you should refactor the way
> > the 'mixer' DataEngine works, because it doesn't completely performs what
> > it is supposed to.
> > Let me explain better: when you invoke the "mixer" DataEngine, you get only
> > the audio cards names, and nothing more. You have to query() the
> > DataEngine, passing one of those names, to receive further infos about the
> > specific control of that audio card (this is what I, and I think other
> > people does, expect when using this DataEngine).
> > And this is kinda bad because, since the DataEngine doesn't automatically
> > updates when the volume changes level/state (see my previous comment), I
> > have to call a query() every N milliseconds and then, for each control,
> > check is something has changed and do a manual update of the plasmoid if
> > needed.
> > Long story short: instead of returning a "Mixers" datasource, with key set
> > to "Mixers" again, you should return a datasource with all the MIXER_ID's
> > and, for each of them, all their detailed infos (volume and mute state
> > included), so we can get all we need in one shot :)
> > (You could run "plasmaengineexplorer" and watch a couple of engines, such
> > as 'org.kde.activities', 'hotplug' or 'tasks' to see what I mean)
> >
> > Note that this will fix also the update() issue because, with the current
> > implementation, the plasmoid won't update unless the value of one of the
> > "Mixers" keys changes (since it contains only the audio card names, it
> > means we will be notified of changes only if an audio card has been
> > plugged/removed).
> >
> > Anyways, these are my two cent: Aaron, what do you think about it?
I thought that the 'dataUpdated' signal is emitted every time data changes
(even from inside the dataengine - in our case, I update the mute/volume by
DBus signals from inside the dataengine, and it updates automatically in
plasmaengineexplorer), and there is no need to poll the dataengine.
The other problem is that actually the plasmoid needs information only about
few controls (one or a bit more sliders in plasmoid). So is there a need to set
ALL the controls (by default)?
And again, what is the difference between adding these sources by default and
querying it, for example, on plasmoid start? I guess I misunderstood something,
but don't you anyway need to poll these sources to get all changing data?
And one more issue - there are three types of datasources: one basic (called
"Mixers", provides info about available Mixers/soundcards), some for
mixers/soundcards (which provides information about its controls) and some for
controls (which provides information about all its state - volume level, mute,
etc). Should I add all these sources? And should I add it automatically add all
sources for plugged devices-sources?
Huh, I asked so many questions.. The things you are talking about are
easy-to-fix, I maybe just don't understand correctly what you need :)
- Igor
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6587/#review9984
---
On March 8, 2011, 7:01 p.m., Igor Poboiko wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6587/
> ---
>
> (Updated March 8, 2011, 7:01 p.m.)
>
>
> Review request for Plasma and Diego Casella.
>
>
> Summary
> ---
>
> This patch reworks KMix DBus API and adds a plasma dataengine+service as a
> frontend to information provided by DBus.
> New DBus structure is:
> - /Mixers
> used to get some global information, such as available mixers list and global
> master mixer
> - /Mixers/MIXER_ID
> used to get information about mixer with id=MIXER_ID. It provides such
> information as list of available controls, name of this mixer, id, etc
> - /Mixers/MIXER_ID/CONTROL_ID
> used to get and set information about control. Such information as volume
> level, mute, name of control, etc.
> It also adds a DBus signals which are emitted when new mixer/control appears,
> or volume level changes.
> It also splits all dbus-related code to separate class,
> DBus{KMix,Mixer,Control}Wrapper.
>
> The Plasma Dataengine:
> By default, the only available source is "KMix". It provides information
> global information about KMix: is KMix running, and list of available mixers.
> (its IDs)
> Source for every mixer is called by it's ID (for example,
> "ALSA::HDA_Intel:1"). This source provides such information about current
> Mixer as: it's readable name, is it opened, its balance and list of available
> controls. It also adds basic sources for every control, which prov
Re: GSoC proposal: First draft
I think it's pretty good. You pointed out the reasons of your doings, which imo are really important. Last year, I wrote two use cases in my proposal, however I don't know if something like that really fits in yours. cheers On Mon, Mar 14, 2011 at 1:51 PM, Viranch Mehta wrote: > On Mon, Mar 14, 2011 at 3:28 PM, Sebastian Kügler wrote: >> >> On Friday, March 11, 2011 19:28:13 todd rme wrote: >> > Might it be good to start with the ones that are already in-progress, >> > that way you can directly compare the the existing plasmoid code and >> > the QML code and thus, hopefully, get a feel for how to do the >> > porting? >> >> But the ones which are in progress are possibly the ones which get done, >> anyway. I don't think it's a good idea to put a GSoC student onto >> something >> people are already working on. > > I think I can look through some on-going work and possibly write some > patches for getting familiar. > Another question: All the QML plasmoids are currently in playground, right? > Viranch > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Review Request: Rework KMix DBus API and add KMix plasma dataengine
---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6587/#review9984
---
Ok, sorry again for my late reply :(
Services are working great, however, I think you should refactor the way the
'mixer' DataEngine works, because it doesn't completely performs what it is
supposed to.
Let me explain better: when you invoke the "mixer" DataEngine, you get only the
audio cards names, and nothing more. You have to query() the DataEngine,
passing one of those names, to receive further infos about the specific control
of that audio card (this is what I, and I think other people does, expect when
using this DataEngine).
And this is kinda bad because, since the DataEngine doesn't automatically
updates when the volume changes level/state (see my previous comment), I have
to call a query() every N milliseconds and then, for each control, check is
something has changed and do a manual update of the plasmoid if needed.
Long story short: instead of returning a "Mixers" datasource, with key set to
"Mixers" again, you should return a datasource with all the MIXER_ID's and, for
each of them, all their detailed infos (volume and mute state included), so we
can get all we need in one shot :)
(You could run "plasmaengineexplorer" and watch a couple of engines, such as
'org.kde.activities', 'hotplug' or 'tasks' to see what I mean)
Note that this will fix also the update() issue because, with the current
implementation, the plasmoid won't update unless the value of one of the
"Mixers" keys changes (since it contains only the audio card names, it means we
will be notified of changes only if an audio card has been plugged/removed).
Anyways, these are my two cent: Aaron, what do you think about it?
- Diego
On March 8, 2011, 7:01 p.m., Igor Poboiko wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6587/
> ---
>
> (Updated March 8, 2011, 7:01 p.m.)
>
>
> Review request for Plasma and Diego Casella.
>
>
> Summary
> ---
>
> This patch reworks KMix DBus API and adds a plasma dataengine+service as a
> frontend to information provided by DBus.
> New DBus structure is:
> - /Mixers
> used to get some global information, such as available mixers list and global
> master mixer
> - /Mixers/MIXER_ID
> used to get information about mixer with id=MIXER_ID. It provides such
> information as list of available controls, name of this mixer, id, etc
> - /Mixers/MIXER_ID/CONTROL_ID
> used to get and set information about control. Such information as volume
> level, mute, name of control, etc.
> It also adds a DBus signals which are emitted when new mixer/control appears,
> or volume level changes.
> It also splits all dbus-related code to separate class,
> DBus{KMix,Mixer,Control}Wrapper.
>
> The Plasma Dataengine:
> By default, the only available source is "KMix". It provides information
> global information about KMix: is KMix running, and list of available mixers.
> (its IDs)
> Source for every mixer is called by it's ID (for example,
> "ALSA::HDA_Intel:1"). This source provides such information about current
> Mixer as: it's readable name, is it opened, its balance and list of available
> controls. It also adds basic sources for every control, which provides only
> information about its readable name
> Sources for controls are called by 'MIXER_ID/CONTROL_ID' (for example,
> "ALSA::HDA_Intel:1/Master:0"). If you request this source, it will provide
> such information as its readable name, is it muted and its volume level
> (which are updates automatically, using DBus signals).
> There is a service available for controls sources. It provides such methods
> as setVolume() and setMute().
>
> It doesn't close bug 171287, but it becomes one step closer to its solving :)
>
> And, I'm not very familiar with CMake, but it would be great idea to make
> plasma part optional.
>
>
> This addresses bug 171287.
> https://bugs.kde.org/show_bug.cgi?id=171287
>
>
> Diffs
> -
>
> /trunk/KDE/kdemultimedia/kmix/CMakeLists.txt 1223808
> /trunk/KDE/kdemultimedia/kmix/apps/kmix.cpp 1223808
> /trunk/KDE/kdemultimedia/kmix/core/mixdevice.h 1223808
> /trunk/KDE/kdemultimedia/kmix/core/mixdevice.cpp 1223808
> /trunk/KDE/kdemultimedia/kmix/core/mixer.h 1223808
> /trunk/KDE/kdemultimedia/kmix/core/mixer.cpp 1223808
> /trunk/KDE/kdemultimedia/kmix/dbus/dbuscontrolwrapper.h PRE-CREATION
> /trunk/KDE/kdemultimedia/kmix/dbus/dbuscontrolwrapper.cpp PRE-CREATION
> /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixerwrapper.h PRE-CREATION
> /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixerwrapper.cpp PRE-CREATION
> /trunk/KDE/kdemultimedia/kmix/dbus/dbusmixsetwrapper.h PRE-CREAT
Re: Plasmate: some files miss licenses
On Mon, Mar 14, 2011 at 6:55 PM, Sebastian Kügler wrote: > Hi all, > > [If you're in the CC: of this email explicitely, please reply to it in any > case.] > > The short version: > >Are you OK with changing the license in the unlicensed files you > have >worked on in Plasmate to GPLV2+ and KDE e.V. approved licenses? > > Yes I am fine with it. Thanks for paying attention :) > Longer version: > > Over the weekend, I've had a closer look at Plasmate, to fix some bugs and > improve it here and there. It struck me that the licensing is currently > incomplete -- some files are missing a licensing header. If we want to > release > Plasmate at some point, that's something we'll need to work out. > > I started on this by streamlining the copyright headers (some used a short > form to refer to the GPLv2+, I've replaced those with the advised text at > http://techbase.kde.org/Policies/Licensing_Policy#GPL_Header > > There are still some files unlicensed at this point, though. I've asked > Paul > Adams to help me a bit to sort out the people who have written or > contributed > to these files, and thanks to grep, uniq, sort and svn log, I've compiled a > list of people per file that are the copyright holders according to svn > log. > > The list is: > > *snip* -- > > packagemodel.h >aseigo >asouza >casella >sandroandrade >shantanu >yuenlim > packagemodel.cpp >aseigo >asouza >casella >mart >sandroandrade >shantanu >yuenlim > sidebaritem.cpp >aseigo >casella > sidebartablewidget.cpp >casella >mlaurent > sidebartablewidget.h >casella >mlaurent > editors/editpage.h >asouza >mlaurent >shantanu >yuenlim > editors/editpage.cpp >aseigo >asouza >mlaurent >sandroandrade >shantanu >yuenlim > savesystem/tabledelegate.cpp >casella > savesystem/tabledelegate.h >casella > savesystem/tablewidget.cpp >casella > savesystem/tablewidget.h >casella > savesystem/timeline.cpp >aseigo >casella >coles >ilic >yuenlim > savesystem/timeline.h >aseigo >casella >yuenlim > savesystem/timelineitem.cpp >aseigo >casella > savesystem/timelineitem.h >aseigo >casella > > *snip* -- > > (I've *NOT* looked at the commits themselves, because I'm not in the > position > to judge if a patch is too trivial or should include the author in the > file's > copyright. A las, if you think your contribution to some file is trivial, > let > me know and I'll not include your name in the copyright header. Otherwise, > please let me know if you're OK with changing the files you have been > working > on to the GPLv2 or later, including the clausule > > In order to protect your copyright in the future, please also consider > signing > the KDE e.V.'s fiduciary licensing agreement, which is a safe construct to > keep copyright of KDE code intact and workable in case you are not > available > for eventual licensing changes, should that ever become necessary. > (Different > topic though.) > > Please (ideally) send me an "I am OK with the licensing changes you > propose.", > or in case you're not OK with it, let me know that as well and I'll see > what > we can do about it. I kind of expect this to be an administrative thing, > but > needs to happen nevertheless. > > Thanks for your attention on this boring topic. :-) > > Cheers, > -- > sebas > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma dataengine question
On Tuesday, March 15, 2011, Farhad Hedayati-Fard wrote:
> Hi!
> I've written a translation dataengine... It needs 3 arguments to initialize
> the translator object ( plugin name, source language and destination
> language). I've put a Q_ASSERT on args.size() in dataengine's constructor
> but now I can't test my dataengine using plasmaengineexplorer because it
> crashes on the Q_ASSERT (no argument is passed to the constructor):
>
> TranslatorEngine::TranslatorEngine(QObject* parent, const QVariantList&
> args): DataEngine(parent, args)
> {
>Q_ASSERT(args.size() >= 3);
>QString from = args[0].toString();
>QString to = args[1].toString();
>QString name = args[2].toString();
>translator = new Translator((QWidget*)this, from, to, name);
>
> }
>
> What should I do to get this working??
the args passed in are currently always empty for the DataEngine constructor.
perhaps the misunderstanding here is that there is only ever one instance of
the DataEngine loaded, and that one engine hosts multiple sources of data.
information such as the to/from language should be encoded in the source name,
e.g. "en:de:flower" (which might have as its data: "Blume"). the DataEngine
would process these requests in sourceRequestEvent.
--
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 Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
plasma dataengine question
Hi!
I've written a translation dataengine... It needs 3 arguments to initialize
the translator object ( plugin name, source language and destination
language). I've put a Q_ASSERT on args.size() in dataengine's constructor but
now I can't test my dataengine using plasmaengineexplorer because it crashes
on the Q_ASSERT (no argument is passed to the constructor):
TranslatorEngine::TranslatorEngine(QObject* parent, const QVariantList& args):
DataEngine(parent, args)
{
Q_ASSERT(args.size() >= 3);
QString from = args[0].toString();
QString to = args[1].toString();
QString name = args[2].toString();
translator = new Translator((QWidget*)this, from, to, name);
}
What should I do to get this working??
Thanks in advance :)
Farhad
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmate: some files miss licenses
"I am OK with the licensing changes you propose." :) Jason "moofang" Lim Yuen Hoe http://yuenhoe.co.cc/ On Mon, Mar 14, 2011 at 9:25 PM, Sebastian Kügler wrote: > Hi all, > > [If you're in the CC: of this email explicitely, please reply to it in any > case.] > > The short version: > >Are you OK with changing the license in the unlicensed files you > have >worked on in Plasmate to GPLV2+ and KDE e.V. approved licenses? > > Longer version: > > Over the weekend, I've had a closer look at Plasmate, to fix some bugs and > improve it here and there. It struck me that the licensing is currently > incomplete -- some files are missing a licensing header. If we want to > release > Plasmate at some point, that's something we'll need to work out. > > I started on this by streamlining the copyright headers (some used a short > form to refer to the GPLv2+, I've replaced those with the advised text at > http://techbase.kde.org/Policies/Licensing_Policy#GPL_Header > > There are still some files unlicensed at this point, though. I've asked > Paul > Adams to help me a bit to sort out the people who have written or > contributed > to these files, and thanks to grep, uniq, sort and svn log, I've compiled a > list of people per file that are the copyright holders according to svn > log. > > The list is: > > *snip* -- > > packagemodel.h >aseigo >asouza >casella >sandroandrade >shantanu >yuenlim > packagemodel.cpp >aseigo >asouza >casella >mart >sandroandrade >shantanu >yuenlim > sidebaritem.cpp >aseigo >casella > sidebartablewidget.cpp >casella >mlaurent > sidebartablewidget.h >casella >mlaurent > editors/editpage.h >asouza >mlaurent >shantanu >yuenlim > editors/editpage.cpp >aseigo >asouza >mlaurent >sandroandrade >shantanu >yuenlim > savesystem/tabledelegate.cpp >casella > savesystem/tabledelegate.h >casella > savesystem/tablewidget.cpp >casella > savesystem/tablewidget.h >casella > savesystem/timeline.cpp >aseigo >casella >coles >ilic >yuenlim > savesystem/timeline.h >aseigo >casella >yuenlim > savesystem/timelineitem.cpp >aseigo >casella > savesystem/timelineitem.h >aseigo >casella > > *snip* -- > > (I've *NOT* looked at the commits themselves, because I'm not in the > position > to judge if a patch is too trivial or should include the author in the > file's > copyright. A las, if you think your contribution to some file is trivial, > let > me know and I'll not include your name in the copyright header. Otherwise, > please let me know if you're OK with changing the files you have been > working > on to the GPLv2 or later, including the clausule > > In order to protect your copyright in the future, please also consider > signing > the KDE e.V.'s fiduciary licensing agreement, which is a safe construct to > keep copyright of KDE code intact and workable in case you are not > available > for eventual licensing changes, should that ever become necessary. > (Different > topic though.) > > Please (ideally) send me an "I am OK with the licensing changes you > propose.", > or in case you're not OK with it, let me know that as well and I'll see > what > we can do about it. I kind of expect this to be an administrative thing, > but > needs to happen nevertheless. > > Thanks for your attention on this boring topic. :-) > > Cheers, > -- > sebas > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmate: some files miss licenses
On Mon, Mar 14, 2011 at 2:25 PM, Sebastian Kügler wrote: > Hi all, > > [If you're in the CC: of this email explicitely, please reply to it in any > case.] > > The short version: > > Are you OK with changing the license in the unlicensed files you have > worked on in Plasmate to GPLV2+ and KDE e.V. approved licenses? +1 from here Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasmate: some files miss licenses
Hi Sebas, I'm ok ... Thanks for reporting this, Cheers, Sandro On Mon, Mar 14, 2011 at 10:25 AM, Sebastian Kügler wrote: > Hi all, > > [If you're in the CC: of this email explicitely, please reply to it in any > case.] > > The short version: > > Are you OK with changing the license in the unlicensed files you have > worked on in Plasmate to GPLV2+ and KDE e.V. approved licenses? > > Longer version: > > Over the weekend, I've had a closer look at Plasmate, to fix some bugs and > improve it here and there. It struck me that the licensing is currently > incomplete -- some files are missing a licensing header. If we want to release > Plasmate at some point, that's something we'll need to work out. > > I started on this by streamlining the copyright headers (some used a short > form to refer to the GPLv2+, I've replaced those with the advised text at > http://techbase.kde.org/Policies/Licensing_Policy#GPL_Header > > There are still some files unlicensed at this point, though. I've asked Paul > Adams to help me a bit to sort out the people who have written or contributed > to these files, and thanks to grep, uniq, sort and svn log, I've compiled a > list of people per file that are the copyright holders according to svn log. > > The list is: > > *snip* -- > > packagemodel.h > aseigo > asouza > casella > sandroandrade > shantanu > yuenlim > packagemodel.cpp > aseigo > asouza > casella > mart > sandroandrade > shantanu > yuenlim > sidebaritem.cpp > aseigo > casella > sidebartablewidget.cpp > casella > mlaurent > sidebartablewidget.h > casella > mlaurent > editors/editpage.h > asouza > mlaurent > shantanu > yuenlim > editors/editpage.cpp > aseigo > asouza > mlaurent > sandroandrade > shantanu > yuenlim > savesystem/tabledelegate.cpp > casella > savesystem/tabledelegate.h > casella > savesystem/tablewidget.cpp > casella > savesystem/tablewidget.h > casella > savesystem/timeline.cpp > aseigo > casella > coles > ilic > yuenlim > savesystem/timeline.h > aseigo > casella > yuenlim > savesystem/timelineitem.cpp > aseigo > casella > savesystem/timelineitem.h > aseigo > casella > > *snip* -- > > (I've *NOT* looked at the commits themselves, because I'm not in the position > to judge if a patch is too trivial or should include the author in the file's > copyright. A las, if you think your contribution to some file is trivial, let > me know and I'll not include your name in the copyright header. Otherwise, > please let me know if you're OK with changing the files you have been working > on to the GPLv2 or later, including the clausule > > In order to protect your copyright in the future, please also consider signing > the KDE e.V.'s fiduciary licensing agreement, which is a safe construct to > keep copyright of KDE code intact and workable in case you are not available > for eventual licensing changes, should that ever become necessary. (Different > topic though.) > > Please (ideally) send me an "I am OK with the licensing changes you propose.", > or in case you're not OK with it, let me know that as well and I'll see what > we can do about it. I kind of expect this to be an administrative thing, but > needs to happen nevertheless. > > Thanks for your attention on this boring topic. :-) > > Cheers, > -- > sebas > > http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasmate: some files miss licenses
Hi all, [If you're in the CC: of this email explicitely, please reply to it in any case.] The short version: Are you OK with changing the license in the unlicensed files you have worked on in Plasmate to GPLV2+ and KDE e.V. approved licenses? Longer version: Over the weekend, I've had a closer look at Plasmate, to fix some bugs and improve it here and there. It struck me that the licensing is currently incomplete -- some files are missing a licensing header. If we want to release Plasmate at some point, that's something we'll need to work out. I started on this by streamlining the copyright headers (some used a short form to refer to the GPLv2+, I've replaced those with the advised text at http://techbase.kde.org/Policies/Licensing_Policy#GPL_Header There are still some files unlicensed at this point, though. I've asked Paul Adams to help me a bit to sort out the people who have written or contributed to these files, and thanks to grep, uniq, sort and svn log, I've compiled a list of people per file that are the copyright holders according to svn log. The list is: *snip* -- packagemodel.h aseigo asouza casella sandroandrade shantanu yuenlim packagemodel.cpp aseigo asouza casella mart sandroandrade shantanu yuenlim sidebaritem.cpp aseigo casella sidebartablewidget.cpp casella mlaurent sidebartablewidget.h casella mlaurent editors/editpage.h asouza mlaurent shantanu yuenlim editors/editpage.cpp aseigo asouza mlaurent sandroandrade shantanu yuenlim savesystem/tabledelegate.cpp casella savesystem/tabledelegate.h casella savesystem/tablewidget.cpp casella savesystem/tablewidget.h casella savesystem/timeline.cpp aseigo casella coles ilic yuenlim savesystem/timeline.h aseigo casella yuenlim savesystem/timelineitem.cpp aseigo casella savesystem/timelineitem.h aseigo casella *snip* -- (I've *NOT* looked at the commits themselves, because I'm not in the position to judge if a patch is too trivial or should include the author in the file's copyright. A las, if you think your contribution to some file is trivial, let me know and I'll not include your name in the copyright header. Otherwise, please let me know if you're OK with changing the files you have been working on to the GPLv2 or later, including the clausule In order to protect your copyright in the future, please also consider signing the KDE e.V.'s fiduciary licensing agreement, which is a safe construct to keep copyright of KDE code intact and workable in case you are not available for eventual licensing changes, should that ever become necessary. (Different topic though.) Please (ideally) send me an "I am OK with the licensing changes you propose.", or in case you're not OK with it, let me know that as well and I'll see what we can do about it. I kind of expect this to be an administrative thing, but needs to happen nevertheless. Thanks for your attention on this boring topic. :-) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC proposal: First draft
On Mon, Mar 14, 2011 at 3:28 PM, Sebastian Kügler wrote: > On Friday, March 11, 2011 19:28:13 todd rme wrote: > > Might it be good to start with the ones that are already in-progress, > > that way you can directly compare the the existing plasmoid code and > > the QML code and thus, hopefully, get a feel for how to do the > > porting? > > But the ones which are in progress are possibly the ones which get done, > anyway. I don't think it's a good idea to put a GSoC student onto something > people are already working on. > I think I can look through some on-going work and possibly write some patches for getting familiar. Another question: All the QML plasmoids are currently in playground, right? Viranch ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: GSoC proposal: First draft
On Friday, March 11, 2011 19:28:13 todd rme wrote: > Might it be good to start with the ones that are already in-progress, > that way you can directly compare the the existing plasmoid code and > the QML code and thus, hopefully, get a feel for how to do the > porting? But the ones which are in progress are possibly the ones which get done, anyway. I don't think it's a good idea to put a GSoC student onto something people are already working on. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
