On Sunday 10 November 2013 04:32:12 Friedrich W. H. Kossebau wrote:
Input welcome.
Once upon a time those interfaces were invented to enable KPilot (yes, those
times) to be able to use the hexedit widget I did then, without having
these rather specific widget in kdelibs or having kdepim
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113670/#review43321
---
tier4/kde4support/src/CMakeLists.txt
On Nov. 9, 2013, 12:47 a.m., David Faure wrote:
staging/kio/CMakeLists.txt, line 34
http://git.reviewboard.kde.org/r/113723/diff/1/?file=212052#file212052line34
Why? KDED doesn't provide a library.
Àlex Fiestas wrote:
It provides a DBus interface (.xml) that is installed and
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113260/#review43323
---
Ship it!
OK. I only meant don't remove existing code that
Aaron?
Anyone from the plasma team?
I would appreciate input on this (see precise question at the end),
it's preventing KF5 from moving forward with KModifierKeyInfo.
Please CC kde-frameworks-devel, I'm not on plasma-devel.
On Wednesday 16 October 2013 09:56:03 David Faure wrote:
We are still
On Sunday 10 November 2013 09:47:41 David Faure wrote:
On Sunday 10 November 2013 04:32:12 Friedrich W. H. Kossebau wrote:
Input welcome.
Once upon a time those interfaces were invented to enable KPilot (yes,
those times) to be able to use the hexedit widget I did then, without
having
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113260/#review43331
---
Ship it!
Ship It!
- John Layt
On Oct. 22, 2013, 4:49 p.m.,
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113696/#review43332
---
Ship it!
No change was needed in CMakeLists.txt, therefore
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113704/#review43334
---
tier1/kguiaddons/src/plugins/imageformats/eps.cpp
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113705/#review43335
---
Ship it!
I trust that you compared them and they had the same
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113708/#review43336
---
Ship it!
Ship It!
- David Faure
On Nov. 7, 2013, 3:36
Hello!
It looks like keystate applet which was removed from KDE4 was(?) the
user of keystate dataengine. If we bring back this applet in Plasma2
then this DataEngine will be used. And this applet is necessary for
disabled people, See https://bugs.kde.org/show_bug.cgi?id=165402
Thanks!
On Sun,
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113730/#review43337
---
Ship it!
Ship It!
- David Faure
On Nov. 9, 2013, 10:54
On Nov. 10, 2013, 11:33 a.m., David Faure wrote:
I trust that you compared them and they had the same features?
Qt's version is better in every way, as far as I can tell.
- Alex
---
This is an automatically generated e-mail. To
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113705/#review43342
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113705/
---
(Updated Nov. 10, 2013, 1:51 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113731/#review43344
---
Ship it!
Ship It!
- David Faure
On Nov. 9, 2013, 11:18
On Saturday 09 November 2013 11:47:16 David Faure wrote:
On Friday 08 November 2013 22:45:33 Jeremy Whiting wrote:
Could we move the dbus interface into
kdeaccessibility/jovie and install it only when jovie is installed,
This would create a compile-time dependency on kdeaccessibility,
in
On Saturday 09 November 2013 15:18:36 Ivan Čukić wrote:
On Friday 08 November 2013 18:04:08 Stefanie Dargel wrote:
kde-workspace fails, because it requires QImageBlitz, which is not being
compiled. I didn't manage to add the Subversion repo to
kf5-qt5-build-include. Ho can I do it?
You
On Sunday 10 November 2013 11:15:58 Dominik Haumann wrote:
On Sunday 10 November 2013 09:47:41 David Faure wrote:
On Sunday 10 November 2013 04:32:12 Friedrich W. H. Kossebau wrote:
So from my point of view, especially given the idea of KF5, I see no
more need for interfaces/khexedit.
On Nov. 10, 2013, 9:50 a.m., David Faure wrote:
tier4/kde4support/src/CMakeLists.txt, line 293
http://git.reviewboard.kde.org/r/113670/diff/3/?file=212165#file212165line293
Why was this line removed?
Everything else looks fine to me, this remove seems unrelated though.
On Sunday 10 November 2013, David Faure wrote:
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
To build karchive itself, they would need cmake + tier0-kf5 + ECM
Which is exactly what I want to avoid.
You wrote To build software using karchive with cmake, they still need
On Sunday 10 November 2013, Alexander Neundorf wrote:
On Sunday 10 November 2013, David Faure wrote:
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
To build karchive itself, they would need cmake + tier0-kf5 + ECM
Which is exactly what I want to avoid.
You wrote To
On Sunday 10 November 2013 16:27:06 Alexander Neundorf wrote:
On Sunday 10 November 2013, Alexander Neundorf wrote:
On Sunday 10 November 2013, David Faure wrote:
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
To build karchive itself, they would need cmake + tier0-kf5 +
On Oct. 21, 2013, 11:22 a.m., Kevin Ottens wrote:
To get in this patch would benefit from being based on the frameworks
branch and go into kdeclarative.
Any chance for an update?
- Kevin
---
This is an automatically generated
On Sept. 23, 2013, 10:37 a.m., Kevin Ottens wrote:
I'm surprised it doesn't use qt5_wrap_ui. It seems to reinvent it at least
partly.
Jeremy Whiting wrote:
well, qt5_wrap_ui wasn't around when this was created (as
kde4_add_ui_files iirc). All I did was copy it and rename it.
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113631/
---
(Updated Nov. 10, 2013, 3:46 p.m.)
Review request for KDE Frameworks,
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113657/#review43351
---
Ship it!
I think that's fine to keep the modules private,
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113506/#review43353
---
Please someone with more cmake-fu than myself look at it. It's
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113731/
---
(Updated Nov. 10, 2013, 3:53 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113730/#review43354
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113730/
---
(Updated Nov. 10, 2013, 3:53 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113731/#review43355
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113711/#review43357
---
Ship it!
Ship It!
- Kevin Ottens
On Nov. 7, 2013, 6:57
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113695/#review43360
---
Ship it!
Ship It!
- Kevin Ottens
On Nov. 7, 2013, 12:38
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113693/#review43361
---
Ship it!
After adjusting the comment it can go in indeed.
-
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113712/#review43362
---
Ship it!
Ship It!
- Kevin Ottens
On Nov. 8, 2013, 12:12
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113694/#review43363
---
Ship it!
Ship It!
- Kevin Ottens
On Nov. 7, 2013, 1:04
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113696/#review43364
---
Ship it!
Ship It!
- Kevin Ottens
On Nov. 6, 2013, 7:17
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113708/#review43365
---
Ship it!
Ship It!
- Kevin Ottens
On Nov. 7, 2013, 3:36
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113670/#review43366
---
Ship it!
Ship It!
- Kevin Ottens
On Nov. 8, 2013, 9:04
On Sunday 10 November 2013, Kevin Ottens wrote:
On Sunday 10 November 2013 16:27:06 Alexander Neundorf wrote:
On Sunday 10 November 2013, Alexander Neundorf wrote:
On Sunday 10 November 2013, David Faure wrote:
On Sunday 03 November 2013 14:05:32 Alexander Neundorf wrote:
To build
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding folders in
header files.
I think there's an aspect missing in your proposal. There's the convention we
want for #include and where we install. That's in the end two
Hello,
Since there's been several times discussions about having a kind of Tier 0
for building our frameworks containing what is right now in ECM kde-modules
directory, but the idea was never really on the table because of the extra
dependency it'd bring, I looked a bit at the git submodule
On Sunday 10 November 2013 17:30:23 Alexander Neundorf wrote:
On Sunday 10 November 2013, Kevin Ottens wrote:
Now I guess we could do it for both, but it looks tricky for something
which would have a separate release cycle like ECM. While for the tier0
the release cycle would be tied to the
On 2013-11-10, Kevin Ottens er...@kde.org wrote:
Since there's been several times discussions about having a kind of Ti=
er 0=20
for building our frameworks containing what is right now in ECM kde-mod=
ules=20
directory, but the idea was never really on the table because of the ex=
tra=20
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113711/#review43370
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113711/
---
(Updated Nov. 10, 2013, 5:23 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113713/#review43371
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113713/#review43373
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113712/#review43372
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113713/
---
(Updated Nov. 10, 2013, 5:23 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113712/
---
(Updated Nov. 10, 2013, 5:23 p.m.)
Status
--
This change has been
On Sunday 10 November 2013 17:12:02 Sune Vuorela wrote:
Why move it out of e-c-m ?
To make e-c-m a neutral ground again, not something purely for KDE needs. I
can understand that positioning.
And if a distribution need to patch whatever is in the 'submodule', they
have a enormous useless
On Oct. 21, 2013, 11:22 a.m., Kevin Ottens wrote:
To get in this patch would benefit from being based on the frameworks
branch and go into kdeclarative.
Kevin Ottens wrote:
Any chance for an update?
Yes I will finish it, when have time. There are many pre-exams in university.
-
On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote:
Now back to the submodules sha-1 update... The only thing I see to easily
overcome that for our developers, is to have a hook, which would update the
submodules for all the frameworks every time someone pushes in the tier 0
repository.
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113704/
---
(Updated Nov. 10, 2013, 6:16 p.m.)
Review request for KDE Frameworks.
On Nov. 10, 2013, 11:20 a.m., David Faure wrote:
tier1/kguiaddons/src/plugins/imageformats/eps.cpp, line 300
http://git.reviewboard.kde.org/r/113704/diff/1/?file=211396#file211396line300
isn't there a better method to call than pid()?
You're right; I missed the state() method last
On 2013-11-10, Kevin Ottens er...@kde.org wrote:
--===3596639883239406900==
Content-Type: multipart/signed; boundary=nextPart1424144.VkBYIHTjbs;
micalg=pgp-sha1; protocol=application/pgp-signature
--nextPart1424144.VkBYIHTjbs
Content-Transfer-Encoding: quoted-printable
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113704/#review43380
---
Ship it!
One more thing, but if this isn't possible, then
On Sunday 10 November 2013, David Faure wrote:
On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote:
Now back to the submodules sha-1 update... The only thing I see to easily
overcome that for our developers, is to have a hook, which would update
the submodules for all the frameworks
On Nov. 10, 2013, 6:39 p.m., David Faure wrote:
tier1/kguiaddons/src/plugins/imageformats/eps.cpp, line 246
http://git.reviewboard.kde.org/r/113704/diff/2/?file=212428#file212428line246
My suggestion was simply QImageReader ppmReader(io, ppm), to let it
read directly from the
On Sunday 10 November 2013 18:23:33 Sune Vuorela wrote:
DCMAKE_BUILD_TYPE=Debug is building with -O2
Oh wow, I always thought this was cmake's doing, but you're right, it's not.
This is an historical bit from the automake/unsermake times.
We had debug (-O2 -g) and debugfull (no optimization,
On Sunday 10 November 2013 19:42:46 Alexander Neundorf wrote:
this would mean that the 3 KDE* files from ecm plus the KF5 umbrella
Config.cmake file would be used within KF5 as a git submodule.
Users of KF5 can get access to it via using the installed KF5 umbrella
package, or not if they
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113704/#review43386
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113704/#review43385
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113704/
---
(Updated Nov. 10, 2013, 7:05 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113704/#review43387
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113704/#review43388
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113704/#review43389
---
Ship it!
tier1/kguiaddons/src/plugins/imageformats/eps.cpp
On Sun, November 10, 2013 17:57:00 Kevin Ottens wrote:
Now back to the submodules sha-1 update... The only thing I see to easily
overcome that for our developers, is to have a hook, which would update the
submodules for all the frameworks every time someone pushes in the tier 0
repository. Is
On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:
I would highly recommend doing something similar to what was done for
strigi when it was split into 5 git modules.
I think you misunderstood the issue?
A super-repo might help automating building all of KF5, but it doesn't solve
the
Hi,
currently, http://community.kde.org/Frameworks/Epics/Modularization shows a
list of modules in the respective Tiers. It does not, however, show whether
it's functional, integration or a solution.
Imo if would be good to have this as column, too. Since then a quick look
allows us (for
On Sunday 10 November 2013 17:57:00 Kevin Ottens wrote:
Hello,
Since there's been several times discussions about having a kind of Tier 0
for building our frameworks containing what is right now in ECM kde-modules
directory, but the idea was never really on the table because of the extra
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113670/
---
(Updated Nov. 10, 2013, 11:42 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113670/#review43394
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113670/#review43395
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113657/
---
(Updated Nov. 11, 2013, 12:21 a.m.)
Review request for KDE Frameworks,
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113657/#review43396
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113657/
---
(Updated Nov. 11, 2013, 12:25 a.m.)
Status
--
This change has been
On Sun, Nov 10, 2013 at 9:58 PM, Dominik Haumann dhaum...@kde.org wrote:
Hi,
currently, http://community.kde.org/Frameworks/Epics/Modularization shows
a
list of modules in the respective Tiers. It does not, however, show whether
it's functional, integration or a solution.
Imo if would be
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113792/
---
Review request for KDE Frameworks.
Repository: kdelibs
Description
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/113723/
---
(Updated Nov. 11, 2013, 3:23 a.m.)
Review request for KDE Frameworks.
On Nov. 9, 2013, 12:47 a.m., David Faure wrote:
staging/kio/CMakeLists.txt, line 30
http://git.reviewboard.kde.org/r/113723/diff/1/?file=212052#file212052line30
already listed 6 lines above
I had to add it because it's a dependency-of-a-dependency. I'll add a comment
about that.
On Sun, November 10, 2013 20:11:07 David Faure wrote:
On Sunday 10 November 2013 13:44:09 Michael Pyne wrote:
I would highly recommend doing something similar to what was done for
strigi when it was split into 5 git modules.
I think you misunderstood the issue?
A super-repo might help
On Monday, November 11, 2013 02:22:43 Aleix Pol wrote:
On Sun, Nov 10, 2013 at 9:58 PM, Dominik Haumann dhaum...@kde.org wrote:
Hi,
currently, http://community.kde.org/Frameworks/Epics/Modularization shows
a
list of modules in the respective Tiers. It does not, however, show
whether
86 matches
Mail list logo
