Re: Gitorious going offline

On 03/16/2015 05:28 PM, Ivan Čukić wrote: > From www.gitorious.org >> System notice: Gitorious is being acquired by GitLab and >> gitorious.org will shut down end of May. Please import your >> repositories to > We still have a few projects on there. One notable being Grantlee (at > least, my kdesrc

Re: Gitorious going offline

On 03/16/2015 05:28 PM, Ivan Čukić wrote: > From www.gitorious.org >> System notice: Gitorious is being acquired by GitLab and >> gitorious.org will shut down end of May. Please import your >> repositories to > We still have a few projects on there. One notable being Grantlee (at > least, my kdesrc

Re: Syncing ECM release number with KF5

28/03/15 03:48, Alex Merry wrote: >> On Wednesday 25 March 2015 22:35:24 Stephen Kelly wrote: >>> Hello, >>> >>> ECM release numbers are in sync with KF5 release numbers, except for the >>> major component. >>> >>> This means that if you

Re: Distros and QtWebEngine

Lisandro Damián Nicanor Pérez Meyer wrote: >> Fair enough. One of them starts in [0], but there was another thread in >> which even Lars participated. So far I haven't been able to find it, I'll >> keep trying. >> > Found the other one! FYI, if you provide a gmane link, you provide the whole thr

Re: Review Request 124824: [OS X] FindKDE4Internal.cmake : reintroduce a cmake_minimum_required statement

build? Add cmake_minimum_required(VERSION 2.8.9) there. - Stephen Kelly On Aug. 19, 2015, 5:41 p.m., René J.V. Bertin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.

Re: Review Request 124824: [OS X] FindKDE4Internal.cmake : reintroduce a cmake_minimum_required statement

> On Aug. 19, 2015, 6:03 p.m., Jeremy Whiting wrote: > > Ship It! Don't ship it :). - Stephen --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/124824/#review84061

Re: Review Request 124824: [OS X] FindKDE4Internal.cmake : reintroduce a cmake_minimum_required statement

> On Aug. 19, 2015, 6:06 p.m., Stephen Kelly wrote: > > This patch is not correct. > > > > What repo were you trying to build? Add cmake_minimum_required(VERSION > > 2.8.9) there. Why did this review go quiet? Did you pull and realize that line was already th

Re: Review Request 124824: [OS X] FindKDE4Internal.cmake : reintroduce a cmake_minimum_required statement

> On Aug. 19, 2015, 6:06 p.m., Stephen Kelly wrote: > > This patch is not correct. > > > > What repo were you trying to build? Add cmake_minimum_required(VERSION > > 2.8.9) there. > > Stephen Kelly wrote: > Why did this review go quiet? Did you pull

Re: Fwd: Required VS compiler

Dominik Haumann wrote: > I still see QStringLiteral fixes from time to time on the commit > mailing list. Given MSVC 2015 Community Edition is available > just like v2013, and it seems to work I believe that committing > such fixes does not make sense, in fact, it often makes code > worse. If the

Re: [Kde-bindings] A new attempt on PyKDE5 binding generation

Albert Astals Cid wrote: > So my suggestion would be renaming pykde5.git to pykf5.git, and that means > *only* KDE Frameworks 5 bindings would go in there, any other repo that > wants to provide python bindings (say okular, marble or krita) should do > somewhere else, ideally their own repo so the

Re: [Kde-bindings] A new attempt on PyKDE5 binding generation

Albert Astals Cid wrote: > El divendres, 8 d’abril de 2016, a les 0:29:57 CEST, Stephen Kelly va > escriure: >> Albert Astals Cid wrote: >> > So my suggestion would be renaming pykde5.git to pykf5.git, and that >> > means *only* KDE Frameworks 5 bindings would go

Submitting Grantlee as a KF5 Framework

Hello, I have been developing Grantlee for over 10 years with contributions from a community of others mostly connected with KDE. https://github.com/steveire/grantlee I have not been able to maintain a reasonable release cadence of Grantlee in the last few years (last release 3 years ago)

Re: Submitting Grantlee as a KF5 Framework

On 08/12/2019 10:12, laurent Montel wrote: Le dimanche 8 décembre 2019, 10:52:19 CET Volker Krause a écrit : Hi, very happy to see Grantlee "coming home" :) Technically I think it's largely in line with Frameworks requirements already, and it has been reliably powering e.g. KMail's message v

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

On 21/12/2019 21:33, Volker Krause wrote: * Attracting external components and having them opt to move under the Frameworks umbrella is a sign that we are doing things right IMHO. So let's make this easy for people and avoid scaring off their users by forcing a larger migration on them when joi

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

On 21/12/2019 19:12, Friedrich W. H. Kossebau wrote: Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly: Great, Grantlee is now available at g...@git.kde.org:grantlee.git. I've pushed a few commits to make it depend on ECM etc. Once the review period is finished it c

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote: Perhaps joining the "Release Service" (formerly known as "KDE Applications") is a better place then, it also contains a set of libraries already. That would serve the purpose of having releases happening regularly. The goals of making Gran

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

On 22/12/2019 16:08, Stephen Kelly wrote: On 21/12/2019 23:55, Friedrich W. H. Kossebau wrote: Perhaps joining the "Release Service" (formerly known as "KDE Applications") is a better place then, it also contains a set of libraries already. That would serve the purpos

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote: Why are you proposing to do a step back instead to the old state, which everyone including you considered not that satisfying? Because it's a temporary situation. We still have a way forward in KF6 (which will open in a few months). Gen

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

On 30/12/2019 08:55, Dominik Haumann wrote: Hi, Stephen Kelly mailto:steve...@gmail.com>> schrieb am So., 29. Dez. 2019, 15:03: On 28/12/2019 23:30, Friedrich W. H. Kossebau wrote: > Why are you proposing to do a step back instead to the old state, which &

Re: CMake config & target challenges on moving to KF5 namespace; dir structure & API dox (Re: Submitting Grantlee as a KF5 Framework)

On 30/12/2019 10:55, Christoph Cullmann wrote: Hi, With my KTextEditor hat on: KF6:TextDocument implies somehow a link to QTextDocument or KF6:TextEditor, which both is incorrect, right? QTextDocument is exactly what it's about, which makes the name KF6::TextDocument fully appropriate and c

Re: Regression in CMake breaking builds

Alexander Neundorf wrote: > It looks like it is related to using imported targets in try_compile(): > > -- Enabling c++0x support for unordered map > CMake Error at cmTryCompileExec236800853Targets.cmake:96 (add_library): > add_library cannot create imported target "Qt4::QtGui" because another >

Re: Review Request 112756: KLinkItemSelectionModel: Do not change current index of mapped model if the mapped one is invalid

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112756/#review40705 --- Ship it! Ship It! - Stephen Kelly On Sept. 16, 2013, 1:56

Re: kde-workspace master becomes Qt5-based

Sebastian Kügler wrote: > We're planning to merge the frameworks-scratch branch of kde-workspace > into master next Monday. I tried building the branch. It requires qimageblitz, which I didn't see a Qt 5 version for, and soprano which has a non-building qt5_port branch. Do you have local workin

Re: Review Request 113139: Try to export include targets for Plasma as well

/plasma/CMakeLists.txt <http://git.reviewboard.kde.org/r/113139/#comment30269> The if-else shouldn't be needed. INSTALL_INTERFACE should already check if ${INCLUDE_INSTALL_DIR} is absolute. - Stephen Kelly On Oct. 7, 2013, 8:13 a.m., Ben Coo

Re: Review Request 113139: Try to export include targets for Plasma as well

ul as it seems camelcase headers are > installed by KF5::plasma into include/KDE/Plasma/ Odd. I tried to add this dir, but seem to have hit a bug I'll look into. Patch looks good for now I think, thanks! - Stephen Kelly On Oct. 7, 2013, 8:13 a.m., Be

Re: Review Request 113139: Try to export include targets for Plasma as well

> On Oct. 7, 2013, 9:35 a.m., Stephen Kelly wrote: > > src/plasma/CMakeLists.txt, line 173 > > <http://git.reviewboard.kde.org/r/113139/diff/1/?file=199605#file199605line173> > > > > The if-else shouldn't be needed. INSTALL_INTERFACE should already c

[kdelibs/KDE/4.11] cmake/modules: Only create and install man pages if using CMake < 3.0

Git commit 804d35394c3667ae4e9fe20321b6365cd8467e7d by Stephen Kelly. Committed on 18/10/2013 at 15:33. Pushed by skelly into branch 'KDE/4.11'. Only create and install man pages if using CMake < 3.0 CMake documentation changes in CMake 3.0.0 such that running cmake --help-cust

Re: Review Request 113503: make dbus dependency optional in JobWidgets

tier2/kjobwidgets/src/CMakeLists.txt <http://git.reviewboard.kde.org/r/113503/#comment30904> Indent. - Stephen Kelly On Oct. 30, 2013, 10:08 a.m., Sune Vuorela wrote: > > --- > This is an automatically generated e-mail.

Re: Less time for KDE... :-)

Alexander Neundorf wrote: > Hi, > > for very happy personal reasons (since Tuesday, named David :-) ) Awesome, congratulations! Steve.

Re: frameworks build instructions wrong / won't work with kubuntu 14.04

Harald Sitter wrote: > xnox was nice enough to look into this in detail and identified the > problem as having a much smaller scope than I had originally thought. 1) What is the problem? 2) Why does the package creation result in broken cmake files generated from the Qt tarball? Thanks, Stev

Re: frameworks build instructions wrong / won't work with kubuntu 14.04

On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote: >> > 2) Why does the package creation result in broken cmake files generated >> > from the Qt tarball? > The package creation does not result in broken cmake files generated > from the Qt tarball. Great. > It's just there is no clean way to over

Re: frameworks build instructions wrong / won't work with kubuntu 14.04

On 12/19/2013 07:45 PM, Dimitri John Ledkov wrote: > I am also not sure yet, if > a cross-moc is required or whether a native moc binary can be re-used. > It's one of the open questions that I still have, and need to > investigate the actual code generator / code generated. Even if the code genera

Submitting KTextTemplate for KF6

Hello, The Qt 5 based Grantlee libraries were depended on by some KDE applications. For Qt 6, I've created a separate repo for KTextTemplate for one of the Grantlee libraries. The other library is separate and can be dealt with separately. Currently the code lives here: https://github.com

Re: Submitting KTextTemplate for KF6

On 26/02/2022 10:38, Volker Krause wrote: On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote: Hello, The Qt 5 based Grantlee libraries were depended on by some KDE applications. For Qt 6, I've created a separate repo for KTextTemplate for one of the Grantlee libraries. The

Re: Submitting KTextTemplate for KF6

On 05/03/2022 18:16, Ben Cooksley wrote: On Sun, Mar 6, 2022 at 6:00 AM Stephen Kelly wrote: On 26/02/2022 10:38, Volker Krause wrote: > On Sonntag, 20. Februar 2022 16:02:59 CET Stephen Kelly wrote: >> Hello, >> >> The Qt 5 based Grantlee librarie

i18n infrastructure for Grantlee templates

Hi, I'm ready to release the next version of Grantlee, which is the first version with i18n features. The aim is to mark strings as translatable inside the template files instead of in C++. Before I release it I'd like to make sure it can fit into the KDE i18n infrastructure. The test case fo

Re: i18n infrastructure for Grantlee templates

Albert Astals Cid wrote: > A Dijous, 20 de gener de 2011, Stephen Kelly va escriure: >> Hi, >> >> I'm ready to release the next version of Grantlee, which is the first >> version with i18n features. The aim is to mark strings as translatable >> ins

Review Request: Add extraction scripts for translatable strings from Grantlee templates

--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6405/ --- Review request for kdelibs, Pino Toscano and Chusslove Illich. Summary -

Re: Review Request: Add extraction scripts for translatable strings from Grantlee templates

--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6405/ --- (Updated Jan. 23, 2011, 1:24 p.m.) Review request for kdelibs, Pino Toscano

Re: Review Request: Add extraction scripts for translatable strings from Grantlee templates

--- This is an automatically generated e-mail. To reply, visit: http://svn.reviewboard.kde.org/r/6405/ --- (Updated Jan. 23, 2011, 8:01 p.m.) Review request for kdelibs, Pino Toscano

Re: Review Request: Add extraction scripts for translatable strings from Grantlee templates

xtractor.py, > > line 386 > > <http://svn.reviewboard.kde.org/r/6405/diff/2/?file=1#file1line386> > > > > This means that first the shell will glob the arguments, and then the > > script will glob for the second time? Now that's

Re: Review Request: Add extraction scripts for translatable strings from Grantlee templates

nteed that the order of messages in the output file is > > exactly the same as the order in the template file? > > Stephen Kelly wrote: > Yes. > > Additionally, the output file contains the concatenated results from > multiple output files. I'

Re: Usefulness of Subject-header of git commit mails

Thomas Lübking wrote: > Am Sun, 23 Jan 2011 20:43:42 +0100 > schrieb Milian Wolff : > >> Recently, the format of the subject of git commit emails was adapted >> to use the old SVN format. This sucks in my opinion and I want to >> have it changed. > > To me, this would be the driving question. >

Re: Review Request: Add extraction scripts for translatable strings from Grantlee templates

c(), n_() for i18np(), and pn_() for i18ncp(). > > > > (Just to be sure, are translations fetched later really through KDE > > i18n calls? Only then should calls have i18n*() names.) > > > > Stephen Kelly wrote: > Well, there is no i18n() functio

Re: i18n infrastructure for Grantlee templates

Albert Astals Cid wrote: >> >> > * I'm not giving you EXTRACT_TEMPLATE_STRINGS, at most >> > >> > EXTRACT_GRANTLEE_TEMPLATE_STRINGS if you want ;-) >> >> That'll do :) >> >> >> Will that be a problem? Can I coordinate that with someone? >> > >> > With the KDE i18n coordinator (me) Ok, the sc

Re: i18n infrastructure for Grantlee templates

Albert Astals Cid wrote: >> Is there something else that needs to be done? > > grep for EXTRACTQML and do the same ;-) > How about this? Index: update_translations === --- update_translations (revision 1216049) +++ update_translati

Re: i18n infrastructure for Grantlee templates

Albert Astals Cid wrote: > A Dilluns, 24 de gener de 2011, Stephen Kelly va escriure: >> Albert Astals Cid wrote: >> >> Is there something else that needs to be done? >> > >> > grep for EXTRACTQML and do the same ;-) >> >> How about this? >

Fwd: ABI breaking between kdelibs 4.5 and 4.6

Original Message Subject:ABI breaking between kdelibs 4.5 and 4.6 Date: Tue, 8 Feb 2011 23:51:00 +0100 From: José Manuel Santamaría Lema To: Stephen Kelly Hi, while I was developing debian packages for KDE 4.6, I realized that a public symbol was removed. The symbol in que

Re: proposal: remove KTextEditor interface from kdelibs repository

Aaron J. Seigo wrote: > On Tuesday, February 1, 2011, Harri Porten wrote: >> On Tue, 1 Feb 2011, Aaron J. Seigo wrote: >> > we could end up with a "new kdelibs" module that contains just the core >> > stuff such as kdecore, kdeui, kio .. there could be requirements in >> > there about allowable de

Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Hi, K_GLOBAL_STATIC predates Q_GLOBAL_STATIC as far as I know, but with Q_GLOBAL_STATIC in Qt, should we port to that wherever K_GLOBAL_STATIC features are not needed? This is part of reducing dependencies of kde-libraries on KGlobal and other platformyness. All the best, Steve.

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Thiago Macieira wrote: > Q_GLOBAL_STATIC is not public API. Don't use it. Would it be an option to make it public API by documenting it or is that out of the question?

A Qt replacement for KGlobal::ref and deref

Hi, KGLobal::ref and KGLobal::deref are used in KDE instead of QApplication::setQuitOnLastWindowClosed(true). The reason for this is that with the (de)ref solution * KJobs which were not finished before the last window was closed will be completed before the app exits * KRun completes its tas

Re: A Qt replacement for KGlobal::ref and deref

Christoph Feck wrote: > On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote: >> KJob would be a Qt only library > > ? KJob is not a library, but a class in kdecore. I should have been more clear I guess. When I wrote kjob there I meant a library for asynchronou

Re: proposal: remove KTextEditor interface from kdelibs repository

Alexander Neundorf wrote: > On Wednesday 09 February 2011, Stephen Kelly wrote: >> Aaron J. Seigo wrote: >> > On Tuesday, February 1, 2011, Harri Porten wrote: >> >> On Tue, 1 Feb 2011, Aaron J. Seigo wrote: >> >> > we could end up with a "new k

Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

(Creating a new thread) Albert Astals Cid wrote: > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: >> You seem to be >> challenging the idea that less internal dependencies in kdelibs is a good >> thing, but I think that's for a separate thread anyway.

Re: A Qt replacement for KGlobal::ref and deref

Christoph Feck wrote: > I am all for splitting KDE libraries, but I wasn't aware that we are > "already" doing it; it looked like KDE 5 material to me. Well, there is the Platform 11 sprint to get people together thinking about kdelibs modularisation. That's this summer, so we're already thinkin

Re: A Qt replacement for KGlobal::ref and deref

Dawit A wrote: > On Wed, Feb 9, 2011 at 3:29 PM, Stephen Kelly wrote: >> Christoph Feck wrote: >> >>> On Wednesday 09 February 2011 21:01:09 Stephen Kelly wrote: >>>> KJob would be a Qt only library >>> >>> ? KJob is not a library, but a c

Re: Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

Albert Astals Cid wrote: > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: >> (Creating a new thread) >> >> Albert Astals Cid wrote: >> > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure: >> >> You seem to be >> >> c

Re: Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

Albert Astals Cid wrote: > KLineEdit is integrated with KDE, QLineEdit is not, we can discuss this > all you want, but not using KLineEdit gives your users a poorer user > experience. Ok. I'm not sure what that integration is and why it's not possible to have a KLineEdit that doesn't depend on K

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Thiago Macieira wrote: > It should have been in a qglobalstatic_p.h. We might even do that -- and > intentionally break applications that are abusing the API. > A quick grep says that would break akonadi, grantlee, qca, phonon, qxt and a couple of places in KDE that use it already (presumably t

Re: A Qt replacement for KGlobal::ref and deref

Thiago Macieira wrote: > Well, first of all, Thiago is not the highest authority in Qt. You just > had my opinion, not of all people. Sure. I'd call a 'no' from any troll a veto. The only repsonse I got was a no on #qt-labs. That's the only way I have of reaching 'all people' until open governa

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Thiago Macieira wrote: > On Thursday, 10 de February de 2011 21:08:05 Stephen Kelly wrote: >> Thiago Macieira wrote: >> > It should have been in a qglobalstatic_p.h. We might even do that -- >> > and intentionally break applications that are abusing the API. >>

Re: splitting up kdebase in git

Alexander Neundorf wrote: > Maybe something has to be done in git ? > (basically all tools which get introduced to KDE have a fixing/feature > addition phase initially ;-) > > Alex Yes, this issue comes up on the git mailing list from time to time. http://thread.gmane.org/gmane.comp.version-con

Re: A Qt replacement for KGlobal::ref and deref

Aaron J. Seigo wrote: > On Wednesday, February 9, 2011, Stephen Kelly wrote: >> http://techbase.kde.org/Projects/KDELibsModifications > > good to see people thinking about these things. however: > > this page belongs on commuity.kde.org. it's already l

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Michael Pyne wrote: > On Thursday, February 10, 2011 16:35:20 Stephen Kelly wrote: >> Thiago Macieira wrote: >> > On Thursday, 10 de February de 2011 21:08:05 Stephen Kelly wrote: >> >> Thiago Macieira wrote: >> >> > It should have been in a qglobalsta

Re: Use Q_GLOBAL_STATIC where K_GLOBAL_STATIC is not needed?

Thiago Macieira wrote: > QBasicAtomicPointer is a base class of the public class QAtomicPointer. I see. That does make it harder to remove anyway.

Re: A Qt replacement for KGlobal::ref and deref

Alexander Neundorf wrote: > On Monday 14 February 2011, Stephen Kelly wrote: >> Aaron J. Seigo wrote: >> > On Wednesday, February 9, 2011, Stephen Kelly wrote: >> >> http://techbase.kde.org/Projects/KDELibsModifications >> > >> > good to

Re: A Qt replacement for KGlobal::ref and deref

Alexander Neundorf wrote: > On Monday 14 February 2011, Stephen Kelly wrote: >> Aaron J. Seigo wrote: >> > On Wednesday, February 9, 2011, Stephen Kelly wrote: >> >> http://techbase.kde.org/Projects/KDELibsModifications >> > >> > good to

Re: Moving stuff upstream

John Layt wrote: > Anyway, I've started a page to document such things at > http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there. > David Jarvie, could you add something to the KDateTime entry? > > Cheers! > I added some links to time zone related bug reports. Surprisingly t

Re: git workflow draft

Aaron J. Seigo wrote: > Open questions / topics for further discovery: > > * documenting best practices for keeping a topic branch in sync with > master, keeping in mind that later a merge from the topic branch to master > needs to be done and the git history sould be kept as clean as possible A

Re: git workflow draft

Michael Pyne wrote: > An easy way to solve duplicates is to disable sending commit mails for > branches other than master, but I personally dislike that solution as it > would result in mailing lists like #kde-commits not receiving any emails > until the branch is fully landed on master. (I hate t

Re: Moving stuff upstream (was: A Qt replacement for KGlobal::ref and deref)

John Layt wrote: > On Monday 14 February 2011 22:35:13 Stephen Kelly wrote: >> You might think in terms of how much a typical KDE application ends up >> using, but I'm thinking in terms of how much a typical Qt application >> ends up using. Gregory is not going to en

Re: Moving stuff upstream (was: A Qt replacement for KGlobal::ref and deref)

David Jarvie wrote: >> >> Anyway, I've started a page to document such things at >> http://community.kde.org/KDE_Core/QtMerge , feel free to add stuff there. >> David Jarvie, could you add something to the KDateTime entry? > > Done. I hope it contains enough explanation - if you think it needs mo

Re: A Qt replacement for KGlobal::ref and deref

Aaron J. Seigo wrote: > On Tuesday, February 15, 2011, Stephen Kelly wrote: >> http://steveire.com/kdelibs-modular.png >> >> * It's broad at the base - Qt developers can pick and choose what they >> want. There are less interdependencies - you can use the itemvie

Re: git workflow draft

Ben Cooksley wrote: > > Ah, you clearly have no understanding of the damage a "flood" or > "email bomb" causes. Correct :) > Prior to git.kde.org being made available for mainstream use, in the > 1st generation of hooks, a flood occurred. > > This flood completely filled ktown's email queue, pr

Re: git workflow draft

Michael Pyne wrote: > >> People who are interested in ksslsocket will see the commits. > > You're thinking of CommitFilter. I'm thinking of the kde-commits mailing > list (i.e. people who didn't *know* they were interested in ksslsocket > until they saw a "strange" commit). I wasn't really. It's

Re: git workflow draft

Sorry, knode fails me again. Some keyboard shortcut must be too close to ctrl+v for me... Stephen Kelly wrote: >> Either way is an assumption, but only one of these assumptions involves >> deliberately discarding data. ;) If noise is data, you would have a good point. >> &g

Re: git workflow draft

Michael Jansen wrote: > >> mjansen might just have been following a 'never rebase public branches' >> philosphy, but that really doesn't work for me. It was a complicated >> feature requiring lots of refactoring. > > Hehe ... as the one doing the code i would say it was more like > > mjans

Re: git workflow draft

Johannes Sixt wrote: > Am 2/16/2011 22:10, schrieb Stephen Kelly: >> As one of the people asked to describe my idea of the workflow (which >> should >> focus on rebasing, not merging) I put write up here: >> >> http://community.kde.org/20110213_GitWork

Re: A Qt replacement for KGlobal::ref and deref

Stefan Majewsky wrote: > On Wed, Feb 16, 2011 at 5:31 PM, Aaron J. Seigo wrote: >> which begs the question: "is KConfig (as ane exmple) platform or app >> dev"? fun conversations to be had and digging to be done :) > > From my experience, KConfig is actually two things at once: > > 1. framework

Re: git workflow draft

Johannes Sixt wrote: > I'm tired aguing, so I'll leave it at that. Just one point (because I > don't want to be called silly): Just for clarity I wasn't calling you silly :). I think we're just victims of low-bandwidth communication. All the best, Steve.

Re: Review Request: KListWidgetSearchLine: filter items that are inserted or changed

David Faure wrote: > kdeui/itemviews/klistwidgetsearchline.cpp > > > topLeft.parent().isValid() || bottomRight.parent().isValid() > > > - David Actually topLeft.parent() == bottomRight.parent(), so you only need one.

Re: Review of the branch plasma/declarative in kdelibs

Marco Martin wrote: > Hi all, > in kdelibs there is since some time a branch called plasma/declarative > that contains a new little library, that depends at the moment on kdecore > and kdeui (probably is possible to make it depend only from kdecore) that > is meant to be used in QML applications.

KWallet changes between 4.4 and 4.6?

Hi, Distros are still shipping KDEPIM 4.4 with their next release along with kde{,pim}libs 4.6. I'm testing it and getting errors like http://starsky.19inch.net/~jr/tmp/kmail1.png and then this one in a dialog: "There have been repeated failed attempts to gain access to a wallet. An applic

Re: KWallet changes between 4.4 and 4.6?

Rolf Eike Beer wrote: > Am Montag, 4. April 2011, 16:30:04 schrieb Stephen Kelly: >> Hi, >> >> Distros are still shipping KDEPIM 4.4 with their next release along with >> kde{,pim}libs 4.6. >> >> I'm testing it and getting errors like >>

Re: Adding a dependency on libkonq to Gwenview

Aurélien Gâteau wrote: > On 07/05/2011 10:43, Aurélien Gâteau wrote: >> Hi, >> >> As part of my work on the image comparison feature in Gwenview, I want >> to make it possible to restore trashed images from within Gwenview (in >> case the user trashes the wrong image while comparing). >> >> In t

Backwards compatibility for shared desktop ontologies?

Hi, = Executive Summary = The new Shared Desktop Ontologies version 0.7 changes in a backwards incompatible way compared to version 0.6. kdelibs master already depends on SDO 0.7. kdepim-runtime master also now depends on SDO 0.7. kdepim4.4 still builds, because it happens to not use the bac

Backwards compatibility for shared desktop ontologies?

Hi, = Executive Summary = The new Shared Desktop Ontologies version 0.7 changes in a backwards incompatible way compared to version 0.6. kdelibs master already depends on SDO 0.7. kdepim-runtime master also now depends on SDO 0.7. kdepim4.4 still builds, because it happens to not use the bac

Re: Backwards compatibility for shared desktop ontologies?

Sebastian Trüg wrote: > First off: I think the system does work. IMHO I am not the only one only > thinking about these dates shortly before they arrive. Thus, the hard > freeze is there to have time to fix issues like these. But that is just > my personal opinion. Yes, the freeze is there to res

Re: Git Worflow, branch creation.

Ben Cooksley wrote: > Second you are heavily advocating rebasing. This shouldn't be done in > public repositories as it: > - Inflates the size of the repository. I thought git gc which runs periodically would mean that the repo size is not inflated? > - Requires some Git magic to recover if the

Re: Backwards compatibility for shared desktop ontologies?

Sebastian Trüg wrote: > Like I already said: patching rcgen seems like the best solution to me > and that is so trivial I can have finished it today. > The beta tagging is due to happen today. As far as I know this hasn't been addressed. Was it more complex than expected or you just didn't have

Re: Git Worflow, branch creation.

Ben Cooksley wrote: > Doesn't apply to KDE repositories, as performing a rebase involves a > force push, which initiates the damage prevention area of our hooks. > This triggers creation of a "backup ref" protecting the contents of > the old ref from being affected by a gc, and ensures they are al

Re: Backwards compatibility for shared desktop ontologies?

On 05/20/2011 09:35 PM, Dirk Mueller wrote: On Thursday 19 May 2011, Stephen Kelly wrote: The beta tagging is due to happen today. As far as I know this hasn't been addressed. Was it more complex than expected or you just didn't have time? I propose that we revert the dependency bum

Re: A Qt replacement for KGlobal::ref and deref

Thiago Macieira kde.org> writes: > so just to be painfully clear (it's a monday morning here, i worked > > all weekend and i still have house packing to do, please excuse my > > obtuseness ;): IF a refcoutning patch is offered which ties all window > > visibility (setQuitOnLastWindowClosed, QSyst

Re: grantlee-0.1.8 build failed on arm7

Sune Vuorela wrote: > On 2011-06-04, ?? ?? wrote: >> Hello. I am using Gentoo on the Beagleboard-Xm. >> When I try to compile kde-4.6.80, I stoped on the grantlee build phase. >> This is a full log. >> http://paste.ubuntu.com/618234 > I don't remember how to make my

Re: Plan to transition to KDE Frameworks

David Faure wrote: > On Tuesday 07 June 2011 01:43:44 David Faure wrote: >> Once the 4.7 branch is created, the plan is to do the following: >> >> - application developers can work in master as usual, no change there. >> >> - we create a new branch in kdelibs (say, "frameworks") for the work on

Re: Plan to transition to KDE Frameworks

Albert Astals Cid wrote: > On Diumenge 07 Agost 2011 12:45:12 Stephen Kelly wrote: >> David Faure wrote: >> > On Tuesday 07 June 2011 01:43:44 David Faure wrote: >> >> Once the 4.7 branch is created, the plan is to do the following: >> >> >> &

Re: Plan to transition to KDE Frameworks

Good point well made. I think what you propose makes a lot of sense. On 8/7/11, Michael Jansen wrote: >> It might make sense to unfreeze master. >> >> $ git log --pretty=oneline master.. >> 4f0d3e Remove KGlobal::locale warning for pure Qt applications >> 88836f add missing file >> 63b8ad Implem

How to create libraries in KDE Frameworks 5

Hi, I've just pushed an update to the frameworks branch in kdelibs.git. I moved some classes from kdeui/itemviews to tier1/itemmodels/ and added them to the buildsystem in a library. Just for the need of starting somewhere I created a top-level directory called tier1 to hold the library. As w

Re: How to create libraries in KDE Frameworks 5

Stephen Kelly wrote: > After using kde4_add_library the macro generate_export_header should be > used. > > kde4_add_library(itemmodels ...) > generate_export_header(itemmodels > DEPRECATED_NAME KDE_DEPRECATED > ) Just fyi, Instead of this, use only kf5_add_library. I'v

  1   2   >