Re: 4.2: the binary compatible release
Aaron J. Seigo wrote: > yes, functions or methods. not data members (which i usually shortcut to > just "members", versus "methods" ... probably what caused confusion; > sorry.) > You're right. I read methods instead of members. Sorry for the noise. Steve. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
On Tuesday 21 October 2008, Stephen Kelly wrote: > Aaron J. Seigo wrote: > > for those wondering what binary compat means for us, in a nutshell: > > > > * we can't add new members to the public classes (the dptr makes that > > unecessary in the first place, of course =) > > Are you sure about this one? positive. > Techbase says you can: > http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_D >o.27s_and_Don.27ts "You cannot... [...] add new data members to a class or change order of data members in a class (doesn't apply to static ones)." > > You can add new non-virtual functions including signals and slots and > > constructors. yes, functions or methods. not data members (which i usually shortcut to just "members", versus "methods" ... probably what caused confusion; sorry.) -- 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 Software 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
Re: 4.2: the binary compatible release
Aaron J. Seigo wrote: > for those wondering what binary compat means for us, in a nutshell: > > * we can't add new members to the public classes (the dptr makes that > unecessary in the first place, of course =) Are you sure about this one? Techbase says you can: http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++#The_Do.27s_and_Don.27ts > You can add new non-virtual functions including signals and slots and constructors. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
On Monday 20 October 2008, Ryan P. Bitanga wrote: > 2008/10/19 Aaron J. Seigo <[EMAIL PROTECTED]>: > >* Multiple action runners > > Hey sorry I disappeared completely. I spent too much time previously > working on KDE and neglecting my thesis that it ended up biting me in > the ass. Anyway, I'll be free in a week. ok. i'll come up with a draft based on your draft that gets it closer to what krunner can handle, and then we can pound on it together next week. > Do all changes have to be > merged into trunk in two weeks? yep. -- 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 Software 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
Re: 4.2: the binary compatible release
On Monday 20 October 2008, Ryan P. Bitanga wrote: > 2008/10/19 Aaron J. Seigo <[EMAIL PROTECTED]>: > > Hello =) > > > > the second thing we discussed at the meeting today was moving libplasma > > to kdelibs and guaranteeing binary compatibility starting with 4.2. > > > > here are our notes from the meeting: > > > > Binary Compatibility and kdelibs > >* The Plan > >* libplasma, in its entirety, in kdelibs for 4.2 > >* 2 weeks to go through the API and find things we should change > >* at the end of the 2 weeks it's "speak now or forever hold your > > peace" * if there are things that we feel are just Too Ugly(tm), we move > > it out of the lib for 4.2 > >* Known issues > >* Service additions > >* Multiple action runners > > Hey sorry I disappeared completely. I spent too much time previously > working on KDE and neglecting my thesis that it ended up biting me in > the ass. Anyway, I'll be free in a week. Do all changes have to be > merged into trunk in two weeks? > aaaw man, i know the feeling, exactly in the same situation (/me sighs) Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
2008/10/19 Aaron J. Seigo <[EMAIL PROTECTED]>: > Hello =) > > the second thing we discussed at the meeting today was moving libplasma to > kdelibs and guaranteeing binary compatibility starting with 4.2. > > here are our notes from the meeting: > > Binary Compatibility and kdelibs >* The Plan >* libplasma, in its entirety, in kdelibs for 4.2 >* 2 weeks to go through the API and find things we should change >* at the end of the 2 weeks it's "speak now or forever hold your peace" >* if there are things that we feel are just Too Ugly(tm), > we move it out of the lib for 4.2 >* Known issues >* Service additions >* Multiple action runners Hey sorry I disappeared completely. I spent too much time previously working on KDE and neglecting my thesis that it ended up biting me in the ass. Anyway, I'll be free in a week. Do all changes have to be merged into trunk in two weeks? >* PanelSvg name - apparently people don't like it ;) >* Tooltip API review > > this means that by October 31 we need to have all API complaints on the table > and addressed. > > i fully admit that the API will never be perfect. we could polish it forever. > this is true of pretty much any complex framework, but doubly so for something > that is trying to do something that hasn't been done a thousand times before. > > for those wondering what binary compat means for us, in a nutshell: > > * we can add new classes > * we can add new non-virtual methods to existing classes > * we can deprecate existing classes > * we can add new members to the dptrs > * we can't remove existing methods or change their signatures > * we can't add new members to the public classes (the dptr makes that > unecessary in the first place, of course =) > * we would be committed to this until KDE 5 > > moving more and more developers towards the scripting languages will make this > less of an issue, really; and app developers will be rather happy with us for > making this move. > > -- > 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 Software > > > ___ > 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: 4.2: the binary compatible release
Le Monday 20 October 2008, Aaron J. Seigo a écrit : > On Sunday 19 October 2008, Kevin Ottens wrote: > > Le Saturday 18 October 2008, Aaron J. Seigo a écrit : > > > * Known issues > > > * Service additions > > > > Hm, last time I looked at it, it was ok. Did it got much changes I > > overlooked lately? > > no, but i'll be adding hooks to "remote" a Service over Jolie, now that the > Jolie bits are done. i'm thinking of adding a publish and subscribe set of > methods so that Plasma::Service can do it all behind the back of the > Plasma::Service itself by re-routing requests based on the > publish/subscribe state in Service::startOperationCall OK, if you want we can take some time on IRC to discuss those ones when you reach this task again? I personally envision some gobby foo on some header files. :-) > > > * Multiple action runners > > > > Not sure I'm qualified to comment on this one. I'm not exactly sure which > > API got impacted by this feature. > > it's Ryan Bitanga's patch, publised on review-board. it has a number of > issues, however, and simply will not work with the current design of > KRunner. essentially, it takes AbstractRunner in a completely different > direction that is wholey incompatible with the current design: it pushes > the actual action to be trigered out of the AbstractRunner::exec and into > the Actions instead; those runners would be completely useless depending on > the UI they are used with and makes it a completely non-starter. Ow, ouch. > so i need to spend a few days really soon here to figure out exactly how to > accomplish the same end without damaging the design. Okidoki, same offer than for Plasma::Service on my side. "ervin all your API bitching needs since 1789", yeah babe. > > > * PanelSvg name - apparently people don't like it ;) > > > > Seeing the reactions we might find a better name soon. Not a good name > > (not possible for this class), but at least not a misleading one. > > > > I think we could give a try to renaming ConfigXml too. I know it's > > inheriting KConfigSkeleton, but it's not only about config. I guess this > > it isn't about config? what is about? I've been unclear here, it's that in the plasma API it's not always used for config (because of Plasma::Service), otherwise it'd be safe to claim it's about config only. It's more of a data scheme loader? > > one is missing the "loading" metaphor, we've UiLoader, it's doing a > > similar service for config descriptions. > > ConfigLoader? hm.. If we ignore the Plasma::Service use case for a minute, it's IMO a better name than ConfigXml already. Teams up nicely with UiLoader, and eludes (works in english?) the fact that it's described with some XML (which is kind of an implementation detail). Regards. -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net "Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance." 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
Re: 4.2: the binary compatible release
On Sunday 19 October 2008, Kevin Ottens wrote: > Le Saturday 18 October 2008, Aaron J. Seigo a écrit : > > * Known issues > > * Service additions > > Hm, last time I looked at it, it was ok. Did it got much changes I > overlooked lately? no, but i'll be adding hooks to "remote" a Service over Jolie, now that the Jolie bits are done. i'm thinking of adding a publish and subscribe set of methods so that Plasma::Service can do it all behind the back of the Plasma::Service itself by re-routing requests based on the publish/subscribe state in Service::startOperationCall > > * Multiple action runners > > Not sure I'm qualified to comment on this one. I'm not exactly sure which > API got impacted by this feature. it's Ryan Bitanga's patch, publised on review-board. it has a number of issues, however, and simply will not work with the current design of KRunner. essentially, it takes AbstractRunner in a completely different direction that is wholey incompatible with the current design: it pushes the actual action to be trigered out of the AbstractRunner::exec and into the Actions instead; those runners would be completely useless depending on the UI they are used with and makes it a completely non-starter. so i need to spend a few days really soon here to figure out exactly how to accomplish the same end without damaging the design. > > * PanelSvg name - apparently people don't like it ;) > > Seeing the reactions we might find a better name soon. Not a good name (not > possible for this class), but at least not a misleading one. > > I think we could give a try to renaming ConfigXml too. I know it's > inheriting KConfigSkeleton, but it's not only about config. I guess this it isn't about config? what is about? > one is missing the "loading" metaphor, we've UiLoader, it's doing a similar > service for config descriptions. ConfigLoader? hm.. > > * Tooltip API review > > This one I can probably review. cool... -- 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 Software 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
Re: 4.2: the binary compatible release
Le Saturday 18 October 2008, Aaron J. Seigo a écrit : > the second thing we discussed at the meeting today was moving libplasma to > kdelibs and guaranteeing binary compatibility starting with 4.2. > > here are our notes from the meeting: > > Binary Compatibility and kdelibs > * The Plan > * libplasma, in its entirety, in kdelibs for 4.2 > * 2 weeks to go through the API and find things we should change > * at the end of the 2 weeks it's "speak now or forever hold your peace" > * if there are things that we feel are just Too Ugly(tm), > we move it out of the lib for 4.2 +1, exactly the plan I had in mind. Sorry for the hurry during the meeting BTW, was the monthly hacking session here, and the room booking didn't allow us to stay longer... we were literally pushed out of the hacking room. :-) > * Known issues > * Service additions Hm, last time I looked at it, it was ok. Did it got much changes I overlooked lately? > * Multiple action runners Not sure I'm qualified to comment on this one. I'm not exactly sure which API got impacted by this feature. > * PanelSvg name - apparently people don't like it ;) Seeing the reactions we might find a better name soon. Not a good name (not possible for this class), but at least not a misleading one. I think we could give a try to renaming ConfigXml too. I know it's inheriting KConfigSkeleton, but it's not only about config. I guess this one is missing the "loading" metaphor, we've UiLoader, it's doing a similar service for config descriptions. > * Tooltip API review This one I can probably review. > this means that by October 31 we need to have all API complaints on the > table and addressed. I'm on it, for the coming month I'll split my time between that and scripting I guess. > i fully admit that the API will never be perfect. we could polish it > forever. this is true of pretty much any complex framework, but doubly so > for something that is trying to do something that hasn't been done a > thousand times before. +1, still we ought to make it the best possible before committing to binary compatibility, which could be prevented by the flurry of features the library got after 4.1. Luckily I think we still can make it, and the soft freeze arrives at the right time. Regards. -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net "Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance." 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
Re: 4.2: the binary compatible release
Le Sunday 19 October 2008, Sebastian Kügler a écrit : > SvgFrame? I'd say it's the best name proposed in this thread so far. BorderedSvg is probably the second contender. Regards. -- Kévin 'ervin' Ottens, http://ervin.ipsquad.net "Ni le maître sans disciple, Ni le disciple sans maître, Ne font reculer l'ignorance." 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
Re: 4.2: the binary compatible release
On Sunday 19 October 2008, Riccardo Iaconelli wrote: > On Saturday 18 October 2008 21:15:03 Ivan Čukić wrote: > > BorderSvg/BorderedSvg > > Absolutely yes, BorderedSvg is much much better than PanelSvg. > Another suggestion, FramedSvg? > > -Riccardo FrameSvg, i prefer something that describes the thing that got rendered, something that says a mostly rectangular thing that looks like a frame, a panel (not in the gui sense) a plank, a tile... and that's why it was panelsvg... but what i want really to avoid is SomeReallyLongNameSvg dunno, things like BorderedSvg seems already a bit long/convoluted to me... Cheers, Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
On Sunday, 19. October 2008. 17.08:36 Riccardo Iaconelli wrote: > On Saturday 18 October 2008 21:15:03 Ivan Čukić wrote: > > BorderSvg/BorderedSvg > > Absolutely yes, BorderedSvg is much much better than PanelSvg. I suggested the Border(something) because of Qt's Style Sheets. They have the border attribute that behaves like ours PanelSvg -- Sanity is the trademark of a weak mind. -- Mark Harrold ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
On Saturday 18 October 2008 21:15:03 Ivan Čukić wrote: > or BorderSvg/BorderedSvg Yet another one, StretchableSvg? -Riccardo -- GPG key: 3D0F6376 When encrypting, please encrypt also for this subkey: 9EBD7FE1 - Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
On Saturday 18 October 2008 21:15:03 Ivan Čukić wrote: > BorderSvg/BorderedSvg Absolutely yes, BorderedSvg is much much better than PanelSvg. Another suggestion, FramedSvg? -Riccardo -- GPG key: 3D0F6376 When encrypting, please encrypt also for this subkey: 9EBD7FE1 - Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平 Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch שלום Shanti Vrede Baris Rój Mír Taika Rongo Sulh Mir Py'guapy 평화 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
On Saturday 18 October 2008 20:15:03 Ivan Čukić wrote: > or BorderSvg/BorderedSvg +1 Alex -- Proud KDE hacker: http://www.kde.org Get KDE 4.1 - out now! 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
Re: 4.2: the binary compatible release
2008/10/19 Sebastian Kügler <[EMAIL PROTECTED]>: > On Saturday 18 October 2008 21:50:10 Aaron J. Seigo wrote: >> > or BorderSvg/BorderedSvg >> >> this is closer to the reality. >> >> personally i don't have a problem with PanelSvg, as i don't think there is >> a "good" name for it. it's an odd duck, and it'll have an odd duck name >> because of that. >> >> if those who don't like PanelSvg prefer BorderSvg, speak up now and we can >> change it immediately. > > SvgFrame? perhaps the name i prefer still unsure renaming is worth the effort but yeah... > -- > 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 > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
On Saturday 18 October 2008 21:50:10 Aaron J. Seigo wrote: > > or BorderSvg/BorderedSvg > > this is closer to the reality. > > personally i don't have a problem with PanelSvg, as i don't think there is > a "good" name for it. it's an odd duck, and it'll have an odd duck name > because of that. > > if those who don't like PanelSvg prefer BorderSvg, speak up now and we can > change it immediately. SvgFrame? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 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
Re: 4.2: the binary compatible release
2008/10/18 Aaron J. Seigo <[EMAIL PROTECTED]>: > On Saturday 18 October 2008, Ivan Čukić wrote: >> > StandardSvg (It is pretty much the default..) >> >> -1 confusing like the present one > > -1 here as well, for same reason > >> > BackgroundSvg (I don't believe its used anywhere for foreground stuffs?) >> >> +1 > > it's really not about backgrounds, though. it's just where it is often used. > >> or BorderSvg/BorderedSvg > > this is closer to the reality. > > personally i don't have a problem with PanelSvg, as i don't think there is a > "good" name for it. it's an odd duck, and it'll have an odd duck name because > of that. > > if those who don't like PanelSvg prefer BorderSvg, speak up now and we can > change it immediately. I think the main negative reaction to PanelSvg stems from the fact that at first glance it would appear to be a svg centric to the panel. Seeing it used all over the place is confusing. At the same time, I agree with your statement that its just an odd duck. I don't feel like any of my suggestions, or BorderSvg, are enough of an improvement to merit the global find/replace it would mandate. Just my 2 cents :) > > -- > 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 Software > > > ___ > 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: 4.2: the binary compatible release
On Saturday 18 October 2008, Ivan Čukić wrote: > > StandardSvg (It is pretty much the default..) > > -1 confusing like the present one -1 here as well, for same reason > > BackgroundSvg (I don't believe its used anywhere for foreground stuffs?) > > +1 it's really not about backgrounds, though. it's just where it is often used. > or BorderSvg/BorderedSvg this is closer to the reality. personally i don't have a problem with PanelSvg, as i don't think there is a "good" name for it. it's an odd duck, and it'll have an odd duck name because of that. if those who don't like PanelSvg prefer BorderSvg, speak up now and we can change it immediately. -- 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 Software 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
Re: 4.2: the binary compatible release
> StandardSvg (It is pretty much the default..) -1 confusing like the present one > BackgroundSvg (I don't believe its used anywhere for foreground stuffs?) +1 or BorderSvg/BorderedSvg Cheerio -- There is a better way of life and it's not so hard to find If you live and let the people in your world speak its mind -- Deep Purple ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: 4.2: the binary compatible release
2008/10/18 Aaron J. Seigo <[EMAIL PROTECTED]>: > Hello =) > > the second thing we discussed at the meeting today was moving libplasma to > kdelibs and guaranteeing binary compatibility starting with 4.2. > > here are our notes from the meeting: > > Binary Compatibility and kdelibs >* The Plan >* libplasma, in its entirety, in kdelibs for 4.2 >* 2 weeks to go through the API and find things we should change >* at the end of the 2 weeks it's "speak now or forever hold your peace" >* if there are things that we feel are just Too Ugly(tm), > we move it out of the lib for 4.2 >* Known issues >* Service additions >* Multiple action runners >* PanelSvg name - apparently people don't like it ;) A few possible ideas... StandardSvg (It is pretty much the default..) SegmentedSvg (kinda lame..) BackgroundSvg (I don't believe its used anywhere for foreground stuffs?) >* Tooltip API review > > this means that by October 31 we need to have all API complaints on the table > and addressed. > > i fully admit that the API will never be perfect. we could polish it forever. > this is true of pretty much any complex framework, but doubly so for something > that is trying to do something that hasn't been done a thousand times before. > > for those wondering what binary compat means for us, in a nutshell: > > * we can add new classes > * we can add new non-virtual methods to existing classes > * we can deprecate existing classes > * we can add new members to the dptrs > * we can't remove existing methods or change their signatures > * we can't add new members to the public classes (the dptr makes that > unecessary in the first place, of course =) > * we would be committed to this until KDE 5 > > moving more and more developers towards the scripting languages will make this > less of an issue, really; and app developers will be rather happy with us for > making this move. > > -- > 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 Software > > > ___ > 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
4.2: the binary compatible release
Hello =) the second thing we discussed at the meeting today was moving libplasma to kdelibs and guaranteeing binary compatibility starting with 4.2. here are our notes from the meeting: Binary Compatibility and kdelibs * The Plan * libplasma, in its entirety, in kdelibs for 4.2 * 2 weeks to go through the API and find things we should change * at the end of the 2 weeks it's "speak now or forever hold your peace" * if there are things that we feel are just Too Ugly(tm), we move it out of the lib for 4.2 * Known issues * Service additions * Multiple action runners * PanelSvg name - apparently people don't like it ;) * Tooltip API review this means that by October 31 we need to have all API complaints on the table and addressed. i fully admit that the API will never be perfect. we could polish it forever. this is true of pretty much any complex framework, but doubly so for something that is trying to do something that hasn't been done a thousand times before. for those wondering what binary compat means for us, in a nutshell: * we can add new classes * we can add new non-virtual methods to existing classes * we can deprecate existing classes * we can add new members to the dptrs * we can't remove existing methods or change their signatures * we can't add new members to the public classes (the dptr makes that unecessary in the first place, of course =) * we would be committed to this until KDE 5 moving more and more developers towards the scripting languages will make this less of an issue, really; and app developers will be rather happy with us for making this move. -- 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 Software 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
