Re: Proposal: make squash-merging the default behavior for gitlab MRs

On Friday, 2 October 2020 19:39:37 CEST Nate Graham wrote: > Thoughts? Like others have said, please, no. Squashed commits are the worst things to have in a git history. They make it hard to use git blame, they make it hard to read the history... And the whole argument about making life easier

Re: Git merge workflow: reverse it?

On Wednesday, 26 August 2020 10:32:24 CEST Ingo Klöcker wrote: > Boud, please don't look with your Krita glasses on other projects. Well, this goes two ways, and when people argue for a certain workflow as the KDE workflow, then I'll have to note that that workflow only is fine for

Re: Git merge workflow: reverse it?

On Tuesday, 25 August 2020 23:16:52 CEST Elvis Angelaccio wrote: > Now: > * Test the fix on stable > * Push to stable > * Merge stable to master > > After: > * Test the fix on master > * Push to master > * Test the fix on stable > * Cherry-pick to stable > > In the second model I need to test

Re: Git merge workflow: reverse it?

On Tuesday, 25 August 2020 23:44:02 CEST you wrote: > Or you can merge stable to master and be sure you won't forget anything. > Of course if master changed a lot you can't (easily) do that. But we > have a lot of repos that don't change very often and merging stable to > master works very well

Re: newer version of create_tarbar_kf5.rb?

On Tuesday, 28 July 2020 09:08:02 CEST Alexander Semke wrote: > On Dienstag, 28. Juli 2020 08:23:39 CEST Boudewijn Rempt wrote: > > One problem is that releaseme takes a branch and tags it, instead of working > > with a given tag. That alone makes release me unusable fo

Re: newer version of create_tarbar_kf5.rb?

On Tuesday, 28 July 2020 00:44:29 CEST Albert Astals Cid wrote: > El dilluns, 27 de juliol de 2020, a les 22:34:48 CEST, Kåre Särs va escriure: > > Hi, > > > > On måndag 27 juli 2020 kl. 23:01:06 EEST Alexander Semke wrote: > > > Hi all, > > > > > > the version of the script on

Re: Discontinuing legacy infrastructure

On dinsdag 23 juni 2020 13:38:59 CEST Ben Cooksley wrote: > On Tue, Jun 23, 2020 at 10:58 PM Boudewijn Rempt wrote: > > > > Hi, > > Hi Boud, > > > > > Did this have any consequences for kde-comm...@kde.org? I'm not getting > > commit mails except for

Re: Discontinuing legacy infrastructure

Hi, Did this have any consequences for kde-comm...@kde.org? I'm not getting commit mails except for translations at the moment. Boud On donderdag 11 juni 2020 11:11:48 CEST Ben Cooksley wrote: > Hi all, > > As previously announced by Sysadmin, following the Gitlab migration we > would be

Re: Context information needed for isolated words

On zaterdag 2 mei 2020 14:46:12 CEST David Hurka wrote: > > On 2 May 2020 12:02 Friedrich W. H. Kossebau wrote: > > And yes, most of the code written in recent years seems to have missed to > > add > > context in the i18n calls. The older among us have failed here to properly > > teach the new

Re: Fixing QNetworkAccessManager use

On woensdag 19 februari 2020 14:09:06 CET Friedrich W. H. Kossebau wrote: > Am Mittwoch, 19. Februar 2020, 08:05:01 CET schrieb Ben Cooksley: > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause wrote: > > > It would also help to know where specifically we have that problem, so we > > > can actually

Re: Banning QNetworkAccessManager

On woensdag 19 februari 2020 13:38:55 CET Johnny Jazeix wrote: > Hi, > > as Volker said, without any alternative, we can't just ban QNAM. > And even with one, we would need time to implement it (for example, > for GCompris, this part of the code was written by someone who is less > active now, so

Re: I need help fixing krita's flatpak build on binary factory

e file is that points to the yaml files. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.

Re: Blacklisting of PIM from the CI system

I still understand why so many > repostitories for Kontact. > For frameworks it makes sense, but I don't get it for applications -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.

I need help fixing krita's flatpak build on binary factory

/Krita_nightly_flatpak/packaging/linux/flatpak/org.kde.krita-nightly.yaml': :1:6: Parse error: unexpected identifier `app-id', expected value Was there a recent change that disabled support for yaml files and should those be rewritten as json files? -- Boudewijn Rempt | https://www.valdyas.org | https

D25119: KF5::BreezeIcons shared library to have all breeze/breeze-dark icons and default to breeze icons set

rempt added a comment. It sounds like it would be something very useful and easy to use. Right now, we package all icons Krita uses in rc files that are compiled in as well. Also, our icon loading has kind of evolved and we've got a bit of code for switching between dark and light icons

Re: Can we agree to change gitlab default behaviour from merge to fast-forward merge for all repos?

ee/user/project/merge_requests/fast_forward_merge.html > > Opinions? > We made that the default for Krita as well. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.

Re: Work Branches

ne with this proposal. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.

Re: Portability of KDE Applications

ns, we have special code so that gets found relative to the exe; same for resources we cannot package in a qrc file. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.

Re: Portability of KDE Applications

computers, used for education. Are you only targeting Linux, or also other operating systems? For Linux, appimage probably is the best solution since it is the simplest for the end user. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org signature.asc Description: This is a digitally signed message part.

D22577: Remove unused pnm.desktop file

rempt created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. rempt requested review of this revision. REVISION SUMMARY Looks like this file isn't used, so let's remove it. REPOSITORY R287 KImageFormats REVISION DETAIL

Re: Tipping the apple cart?

On dinsdag 2 juli 2019 13:07:02 CEST Ben Cooksley wrote: > I assume this means most of your new users are people who have never > worked with Github/Gitlab before in that case... I don't know; it might mean that, but I cannot be sure. I can only report the reactions from my newbies :-) > So in

Re: Tipping the apple cart?

On maandag 1 juli 2019 09:10:59 CEST Valorie Zimmerman wrote: > > This tells me that Gitlab can be worse, which is not surprising. > > And can it be better? Will some folks who have a good experience with this > on Gitlab speak up? > > This is something that all of us want and need to know. >

Re: How is the Font DPI Scale stored?

On woensdag 12 juni 2019 08:01:19 CEST Elias Mårtenson wrote: > I am a developer for the McCLIM graphics > toolkit, and I would like it to be able to integrate better with KDE. > > Currently, McCLIm has a hardcoded font scale which is problematic when on a >

Re: EBN Still Needed?

Speaking for myself, I think I stopped looking at EBN years ago when it broke down; I had not known it had been revived. On dinsdag 26 maart 2019 21:15:31 CET Allen Winter wrote: > I was notified today that the Krazy runs on the EBN have been stuck (due to a > stale lockfile) > for over 3

Re: lgtm integration (automated detection of bugs and problems for programming languages)

It does look kind of interesting... But why doesn't it realize that there's some C++ in Krita? On donderdag 21 maart 2019 10:04:29 CET Tomaz Canabrava wrote: > Hello kdevelopers, > > I'v come to know the lgtm.com this week and started to enjoy it quite > a bit. It provides code analisys for

Re: Gitlab Evaluation & Migration

On woensdag 13 maart 2019 09:21:25 CET Eike Hein wrote: > In this thread there have been some qualms on "is GitLab maybe harder on > newbie devs", but this doesn't take into account the extremely awkward > dance we currently do where we ask people if they have dev access or not > and if they

Re: Fuzzing KDE software

On woensdag 6 maart 2019 20:20:03 CET alcinos wrote: > Are any other projects in KDE using that technique? We don't do that for Krita. I've often wanted to do that, but have never been able to figure out how to make it work properly. -- https://www.valdyas.org | https://www.krita.org

Re: Gitlab Evaluation & Migration

On zaterdag 23 februari 2019 12:08:05 CET Boudewijn Rempt wrote: > * Is there anything we can have that can replace tasks and workboards? We > usually have some very long-running tasks that get a lot of sub-tasks and > that basically document our development process. One thing I'v

Re: Gitlab Evaluation & Migration

On maandag 25 februari 2019 09:12:47 CET Eike Hein wrote: > > I'm aware of several projects who would like to incubate with KDE.org > (e.g. Kaidan and Spectral, both new-breed Kirigami apps with new > contributor ecosystems) but are waiting for the outcome of this > decision, because they

Re: Gitlab Evaluation & Migration

On zaterdag 23 februari 2019 18:58:46 CET ste...@derkits.at wrote: > "A lot" is probably a bit exaggerated, e.g. I don't really know where to > upload patches to Phabricator or create a pull request there, but do > understand how GitLab works. I was talking about the Krita community, which

Re: Gitlab Evaluation & Migration

On zaterdag 23 februari 2019 14:49:25 CET Konstantin Kharlamov wrote: > As someone who uses gitlab on a dayjob I can tell it's pretty easy too. > With disregard to server interface you do `git push my-fork HEAD`, > right? Now, when you push to gitlab server, you get in the git output a > link

Re: Gitlab Evaluation & Migration

On zaterdag 23 februari 2019 10:44:11 CET Ben Cooksley wrote: > https://notes.kde.org/p/gitlab-evaluation-notes A few notes on my side: * Krita has been using the mockup functionality extensively. We would miss that functionality, as we actually do UX design for our new features. * It's ages

D17044: Add FindExiv2.cmake to ECM

rempt added a comment. Wow... REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D17044 To: cgiboudeaux, apol, dfaure Cc: rempt, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D17040: Make FindExiv2.cmake work with exiv 0.27.

rempt added a comment. Hm... I guess this would be good to have in Krita, too, which also has a findExiv2.cmake REPOSITORY R260 Gwenview REVISION DETAIL https://phabricator.kde.org/D17040 To: cgiboudeaux, kde-buildsystem, kde-frameworks-devel Cc: rempt, clintmoyer, tdarboux, huoni,

D13792: Remove unused include

This revision was automatically updated to reflect the committed changes. Closed by commit R237:fa20aaadecf9: Remove unused include (authored by rempt). REPOSITORY R237 KConfig CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D13792?vs=36873=36935 REVISION DETAIL

D13792: Remove unused include

rempt created this revision. rempt added a reviewer: Frameworks. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: kde-frameworks-devel. rempt requested review of this revision. REVISION SUMMARY While trying to figure out how to make kconfig work

Re: Closing old Plasma 4 bugs

On vrijdag 8 juni 2018 22:37:56 CEST Nate Graham wrote: > This work is done; all the bugs and feature requests in the plasma4 > product have been closed. Hope all of your inboxes survived the onslaught! Nice! https://bugs.kde.org/weekly-bug-summary.cgi tells me User# Resolved n...@kde.org

Re: Changes to Phabricator review subscriptions

sional wider dev > communication, and for occasional contributors. The kimageshop list is barely used at this time, mostly only to post links to the weekly meeting notes... -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

Re: Changes to Phabricator review subscriptions

he discussion to happen on kde-community, but maybe we just have too many mailing lists. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org

Re: Python bindings using cppyy (was: An update on Python bindings)

rm is basically Autodesk telling the rest of the industry what to use, including their weird patchset for Qt... > So no, Python 2 is not dead. Not by a long shot. For VFX, it will be dead in 2019. See http://www.vfxplatform.com/ -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Python bindings using cppyy (was: An update on Python bindings)

rm is basically Autodesk telling the rest of the industry what to use, including their weird patchset for Qt... > So no, Python 2 is not dead. Not by a long shot. For VFX, it will be dead in 2019. See http://www.vfxplatform.com/ -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Application usage statistics and targeted user surveys

On Sun, 23 Apr 2017, Boudewijn Rempt wrote: > Did I just miss it -- or didn't you tell us where we can find the library? > Curiously enough, there's a gsoc proposal this year for krita that has > pretty much this as its goal... Nevermind... Found it. My eyes were scanning for a

Re: Application usage statistics and targeted user surveys

ll of this is LGPLv2+ licensed. > > Feedback obviously very welcome, in particular around privacy concerns, or > reasons that would make you enable/disable such a feature. > > Regards, > Volker > -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: karchive and QSaveFile

On Sat, 1 Apr 2017, Sune Vuorela wrote: > On 2017-03-28, Boudewijn Rempt <b...@valdyas.org> wrote: > > I'm now wondering whether to hack QSaveFile's close to just not > > abort, or add inherits("QSaveFile") checks all over KArchive -- > > or whether there's a

Re: karchive and QSaveFile (fwd)

On Sat, 1 Apr 2017, David Faure wrote: > > Oh. > > Yes I think a qobject_cast(device) might be necessary in > KArchive, in order to call commit() rather than close(). > That would work, right? > > Feel like adding a unittest for this? Sure, I'll take a look tomorr

karchive and QSaveFile (fwd)

now wondering whether to hack QSaveFile's close() to just not abort, or add inherits("QSaveFile") checks all over KArchive -- or whether there's a third, better option that I've missed... -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

karchive and QSaveFile

s all over KArchive -- or whether there's a third, better option that I've missed... -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

File overwrite warning missing?

, the Qt file dialog, the Windows file dialog and the OSX file dialog. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Finding local translations?

On Sun, 10 Apr 2016, Boudewijn Rempt wrote: On Sun, 10 Apr 2016, David Faure wrote: On Saturday 09 April 2016 22:21:59 Chusslove Illich wrote: KCatalog::catalogLocaleDir should first execute when the first translation call happens Maybe krita has some global static with an i18n() call

Re: Finding local translations?

On Sat, 9 Apr 2016, Chusslove Illich wrote: [: Boudewijn Rempt :] However, KCatalog::catalogLocaleDir is run before the main runs, and uses QStandardPaths to find the location of the translations. That's before the XDG_DATA_DIRS environment variable is set. [: Alexander Potashev :] You can

Re: Finding local translations?

in KCatalog::catalogLocaleDir to find out more. Hm, yes, that shouldn't happen! I'll check that first! -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https

Finding local translations?

); KLocalizedString::setLanguages(QStringList() << locale.bcp47Name()); And that also didn't work. See also https://quickgit.kde.org/?p=krita.git=commit=5015920f2b24d63b04c82cbf69c674de06ab8abc Is there any way to make this work? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___

Re: A new attempt on PyKDE5 binding generation

is the basis of a way forward: about 800 lines of Python code [2] which can already create 684 .sip files [3]. Oh, that's exciting! Would that tool also work to generate sip files for, say, krita, for krita's python scripting plugin? -- Boudewijn Rempt | http://www.krita.org, http

Re: Qt5 version of qimageblitz

, I'd actually suggest just taking the code into kolourpaint and dropping the library entirely. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Review Request 126675: Add .kra and .ora qimagio plugins

marked as submitted. Review request for KDE Frameworks and Alex Merry. Changes --- Submitted with commit 6934d5441778a09d157836a590236e3dc8d5a492 by Boudewijn Rempt to branch master. Repository: kimageformats Description --- These qimageio plugins originally come from krita

Re: Review Request 126675: Add .kra and .ora qimagio plugins

is found)? Fine with me. - Boudewijn --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126675/#review91821 --- On Jan. 27,

Re: Review Request 126675: Add .kra and .ora qimagio plugins

src/imageformats/kra.json PRE-CREATION src/imageformats/ora.cpp PRE-CREATION src/imageformats/ora.desktop PRE-CREATION src/imageformats/ora.h PRE-CREATION src/imageformats/ora.json PRE-CREATION Diff: https://git.reviewboard.kde.org/r/126675/diff/ Testing --- Thanks, Boudewijn

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: kconfig question

exactly what I need. I need Krita to behave differently on Windows than on Linux. On Windows, everything goes into Roaming\krita, on Linux it goes wherever it goes by default, even though that's harder to to explain to users. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optiona

-integration point of view where I am trying to build nightly packages of Krita on Linux, Windows and OSX, every extra dependency makes the process longer, complicates my build environments and is a maintenance burden. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: KCoreAddons qml plugins

-- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KCoreAddons qml plugins

is available. Huh, I might be missing something, but why are there conditionals if all the frameworks are marked as required? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org

Re: kconfig question

. Sounds like it would be a good solution indeed! -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: Review Request 126675: Add .kra and .ora qimagio plugins

/ora.cpp PRE-CREATION src/imageformats/ora.desktop PRE-CREATION src/imageformats/ora.h PRE-CREATION src/imageformats/ora.json PRE-CREATION Diff: https://git.reviewboard.kde.org/r/126675/diff/ Testing --- Thanks, Boudewijn Rempt ___ Kde

Re: kconfig question

, I can understand that application developers don't want to hardcode "krita/kritarc" everywhere... Yes... But given that I need to build kconfig on windows myself anyway, I guess I can just patch that. In the beginning I was just wondering wether this was the right behaviour. -- Boudewijn Rempt

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ul (or just dumb) > > on Windows? > > Boudewijn Rempt wrote: > I would say: most applications do not need global accelerators, so making > kglobalaccel functional on windows is not really relevant, you wouldn't want > that dependency anyway because it doesn't add functionality

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

ke (07c882f) * src/kactioncollection.cpp (9c45725) * src/kkeysequencewidget.cpp (b2e2b6a) * src/kshortcuteditwidget.cpp (670d031) * src/kshortcutseditor.cpp (99dfb3d) * src/kshortcutseditoritem.cpp (461a90c) * src/kxmlguifactory.cpp (2767e69) View Diff -- Boudewijn Rempt | http:/

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

> On Jan. 26, 2016, 6:40 p.m., Aleix Pol Gonzalez wrote: > > Hi, > > I'm a bit afraid of all these ifndef. Do you think it would make sense to > > abstract out the KGlobalAccel usage? > > > > Otherwise, would it be possible to make KGlobalAccel useful (or just dumb) > > on Windows? I would

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

On Tue, 26 Jan 2016, Andre Heinecke wrote: Hi, On Tuesday 26 January 2016 19:50:13 Boudewijn Rempt wrote: Reminds me a bit of https://git.reviewboard.kde.org/r/125530/ :-) Uh, damn, I missed this :-( I guess the intention is the same. KXmlGui is pretty important to have a "KDE Applic

Re: Review Request 126895: Make KGlobalAccel dependency in KXmlGui optional

On Tue, 26 Jan 2016, Andre Heinecke wrote: Hi, On Tuesday 26 January 2016 20:47:34 Boudewijn Rempt wrote: On Tue, 26 Jan 2016, Andre Heinecke wrote: On Tuesday 26 January 2016 19:50:13 Boudewijn Rempt wrote: Reminds me a bit of https://git.reviewboard.kde.org/r/125530/ :-) In the end, I

Re: Review Request 126675: Add .kra and .ora qimagio plugins

ttps://git.reviewboard.kde.org/r/126675/#review91179 --- On Jan. 16, 2016, 9:55 a.m., Boudewijn Rempt wrote: > > --- > This is an automatically generated e-mail. To reply, v

Re: kconfig question

Location? We'd have to be careful with that though, since it's >=5.5. I'm fine with 5.5 as a minimum for my own purposes :-). I just don't want to have to change a couple of hundred locations to explicitly pass AppConfigLocation. -- Boudewijn Rempt | http://www.krita.org,

kconfig question

those by adding two extra parameter (or writing a wrapper around kconfig, or something else...) I'd like to know why GenericConfigLocation is the default :-) -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel

Re: Review Request 126674: Add a thumbnailer for kra/ora images

marked as submitted. Review request for KDE Frameworks and David Faure. Changes --- Submitted with commit af884a8decd75b1f92ea8b9322c103e2dba60329 by Boudewijn Rempt to branch master. Repository: kio-extras Description --- KRA and ORA files are mostly the same internally, a zip

Re: Review Request 126684: fix loading of RLE compressed PSD files

can confirm the fix is correct. - Boudewijn Rempt On Jan. 9, 2016, 9:58 a.m., Wolfgang Bauer wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.

Review Request 126675: Add .kra and .ora qimagio plugins

/ora.cpp PRE-CREATION src/imageformats/ora.desktop PRE-CREATION src/imageformats/ora.h PRE-CREATION src/imageformats/ora.json PRE-CREATION Diff: https://git.reviewboard.kde.org/r/126675/diff/ Testing --- Thanks, Boudewijn Rempt ___ Kde

Review Request 126674: Add a thumbnailer for kra/ora images

://git.reviewboard.kde.org/r/126674/diff/ Testing --- Thanks, Boudewijn Rempt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

the library to build an application we shouldn't waste electicity building the tests (and the Qt5::QML dependency). Diffs - CMakeLists.txt 59917fa cmake/KF5I18NMacros.cmake 53ba812 Diff: https://git.reviewboard.kde.org/r/126230/diff/ Testing --- Thanks, Boudewijn Rempt

Re: Why is C90 enforced in KDE?

On Thu, 10 Dec 2015, Boudhayan Gupta wrote: On 10 December 2015 at 12:04, Boudewijn Rempt <b...@valdyas.org> wrote: I'm right now using msvc 2015 myself -- which gives other problems with other dependencies. Microsoft now has clang (running on the Microsoft Code Generator as well a

Re: Why is C90 enforced in KDE?

On Mon, 7 Dec 2015, Luca Beltrame wrote: Il Mon, 07 Dec 2015 13:17:53 +0100, Boudewijn Rempt ha scritto: Unfortunately, Linux distros aren't the main platform anymore for the KDE software _I_ maintain. Given you've said this multiple times, Yes, and I'll go on saying it until I feel

Re: Why is C90 enforced in KDE?

ftware _I_ maintain. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org

Re: Scope of framework integration plugin?

On Mon, 30 Nov 2015, David Edmundson wrote: On Mon, Nov 30, 2015 at 1:17 PM, Boudewijn Rempt <b...@valdyas.org> wrote: Sort of related question... Is this also the module that picks up the font hinting settings and applies it to KDE applications? I setup a gnome-only d

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

seful. When one wants to > > omit translations? > > Boudewijn Rempt wrote: > I _never_ install translations. Where would I install them from? Running > "make install" in ki18n doesn't install translations, as far as I can see? I > thought translations get installe

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

CMakeLists.txt 59917fa > cmake/KF5I18NMacros.cmake 53ba812 > > Diff: https://git.reviewboard.kde.org/r/126230/diff/ > > > Testing > --- > > > Thanks, > > Boudewijn Rempt > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

::QML dependency). Diffs - CMakeLists.txt 59917fa cmake/KF5I18NMacros.cmake 53ba812 Diff: https://git.reviewboard.kde.org/r/126230/diff/ Testing --- Thanks, Boudewijn Rempt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

, Boudewijn Rempt ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Scope of framework integration plugin?

On Mon, 30 Nov 2015, David Edmundson wrote: On Mon, Nov 30, 2015 at 1:17 PM, Boudewijn Rempt <b...@valdyas.org> wrote: Sort of related question... Is this also the module that picks up the font hinting settings and applies it to KDE applications? I setup a gnome-only d

Re: Scope of framework integration plugin?

-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 125806: Fix build with -DDEFINE_NO_DEPRECATED=1

of 'appendTab' does not match any declaration in 'KMultiTabBar' int KMultiTabBar::appendTab(const QPixmap , int id, const QString ) ^ Diffs - src/kmultitabbar.cpp 2327748 Diff: https://git.reviewboard.kde.org/r/125806/diff/ Testing --- Thanks, Boudewijn Rempt

Re: Review Request 125806: Fix build with -DDEFINE_NO_DEPRECATED=1

marked as submitted. Review request for KDE Frameworks and Christoph Feck. Changes --- Submitted with commit 7d8b8417cbb6b8439b6689963758e2c20b091fac by Boudewijn Rempt to branch master. Repository: kwidgetsaddons Description --- With no-deprecated set, clang refuses to build

Re: Review Request 125760: Allow local embedded themes, like Qt does a default search in :/icons

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125760/#review87338 --- Ship it! Ship It! - Boudewijn Rempt On Oct. 23, 2015, 5

Re: Question about goal of Windows/Mac frameworks

On Thu, 22 Oct 2015, Christoph Cullmann wrote: If such an approach seems reasonable, we could have some helper for this in a framework. Perhaps the "breeze" framework could even just provide such an rcc and a little lib to load it that can be used for people creating bundles/installers.

Re: Question about goal of Windows/Mac frameworks

Impressive! And cool to see another project using the cmake externals approach, I can copy a lot of it for Krita 3, I think. How are you handling icons? Bundling the breeze theme, or putting the icons in resource files? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org On Thu

Re: Question about goal of Windows/Mac frameworks

On Thu, 22 Oct 2015, Christoph Cullmann wrote: Hi, Impressive! And cool to see another project using the cmake externals approach, I can copy a lot of it for Krita 3, I think. How are you handling icons? Bundling the breeze theme, or putting the icons in resource files? as I was lazy, I just

Re: Question about goal of Windows/Mac frameworks

On Wed, 21 Oct 2015, Alexander Neundorf wrote: Maybe Qt could be shared ? No, no, no. Absolutely not. Every application on Windows should bring its own dependencies and all of them. Any attempt at anything else is a misguided deviation from the platform's way of working and will bring

Re: Policy for Dependencies

On Tue, 13 Oct 2015, Albert Astals Cid wrote: I disagree, phonon and dbus are available on OSX and could be made to work so having a ECM_BUILD_FOR_OSX_APPBUNDLE that disables perfectly valid features doesn't make sense to me. But what if those things don't add any feature to a particularly

Re: Policy for Dependencies

On Tue, 13 Oct 2015, Christoph Cullmann wrote: I think we must accept, that on neither Windows nor Mac we will have all dependencies available and that for many applications not all features are needed. There is no "packagers" for that operating systems, you need to provide the stuff you use

  1   2   3   >