2014-09-15 13:11 GMT+02:00 Sebastian Kügler se...@kde.org:
Minutes Plasma Hangout, 15-9-2014
[cut]
Martin G:
- will add a dependency on Frameworks 5.3 (will be out in time for Plasma 5.1)
- ambiguity with window states, working on fix (debugging / writing unit
tests)
- Will travel to XDC
On Wednesday 17 September 2014 08:36:53 Pier Luigi Fiorini wrote:
2014-09-15 13:11 GMT+02:00 Sebastian Kügler se...@kde.org:
Minutes Plasma Hangout, 15-9-2014
[cut]
Martin G:
- will add a dependency on Frameworks 5.3 (will be out in time for Plasma
5.1) - ambiguity with window
On Tuesday 16 September 2014 14:19:44 Marco Martin wrote:
right now all the classes are still under the Plasma namespace, and should
probably be renamed and cmakes to be cleaned up (especially because it would
be used by plasma too to the two identically named classes, new and
deprecated would
On Wednesday 17 September 2014 10:40:35 Marco Martin wrote:
On Tuesday 16 September 2014 14:19:44 Marco Martin wrote:
right now all the classes are still under the Plasma namespace, and should
probably be renamed and cmakes to be cleaned up (especially because it
would be used by plasma too
On Wednesday 17 September 2014 11:06:50 Martin Gräßlin wrote:
Is the name ok for everybody? potential name clashes?
as it used to be namespaces before, what about using a namespace KPackage
and just call the classes:
KPackage::Package
KPackage::PackageStructure
KPackage::PackageTrader
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120235/#review66724
---
src/plasmaquick/dialog.cpp
Martin GräßlinOn Wednesday 17 September 2014 08:41:49 wrote:
I'll split out my code from kwin using git-filter branch. I think that's the
only sane approach to have the complete history and in the end do a
relicence commit.
Just did the split and pushed the code to a new repository at [1].
On Wednesday, September 17, 2014 11:20:10 Marco Martin wrote:
On Wednesday 17 September 2014 11:06:50 Martin Gräßlin wrote:
Is the name ok for everybody? potential name clashes?
as it used to be namespaces before, what about using a namespace KPackage
and just call the classes:
2014-09-17 13:31 GMT+02:00 Martin Gräßlin mgraess...@kde.org:
Martin GräßlinOn Wednesday 17 September 2014 08:41:49 wrote:
I'll split out my code from kwin using git-filter branch. I think that's
the
only sane approach to have the complete history and in the end do a
relicence commit.
On Wednesday 17 September 2014 14:05:07 Pier Luigi Fiorini wrote:
2014-09-17 13:31 GMT+02:00 Martin Gräßlin mgraess...@kde.org:
Martin GräßlinOn Wednesday 17 September 2014 08:41:49 wrote:
I'll split out my code from kwin using git-filter branch. I think that's
the
only sane
On Sept. 17, 2014, 11:24 a.m., Vishesh Handa wrote:
src/plasmaquick/dialog.cpp, line 922
https://git.reviewboard.kde.org/r/120235/diff/1/?file=312579#file312579line922
I'm really not sure what is going to happen in this case -
We set the resizeOrigin to Window, call
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120235/
---
(Updated Sept. 17, 2014, 2:32 p.m.)
Review request for Plasma.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120235/#review66744
---
The following tests are broken -
1. dialog_positioning.qml
On Tue, Sep 16, 2014 at 2:19 PM, Marco Martin notm...@gmail.com wrote:
right now all the classes are still under the Plasma namespace, and should
probably be renamed and cmakes to be cleaned up (especially because it
would
be used by plasma too to the two identically named classes, new and
On Sept. 17, 2014, 2:54 p.m., Vishesh Handa wrote:
The following tests are broken -
1. dialog_positioning.qml
2. dialog_positioning2.qml - The animation seems incorrect. Maybe that was
always different and I did not notice?
3. dialog_visualParentChange.qml
1 and 3 were casued by
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120235/
---
(Updated Sept. 17, 2014, 4:03 p.m.)
Review request for Plasma.
On Sept. 17, 2014, 2:54 p.m., Vishesh Handa wrote:
src/plasmaquick/dialog.cpp, line 301
https://git.reviewboard.kde.org/r/120235/diff/2/?file=312805#file312805line301
Would this actually do anything?
resizeOrigin = MainItem;
// do stuff which changes the size and
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120235/#review66756
---
Do all of the tests now pass?
src/plasmaquick/dialog.cpp
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120235/
---
(Updated Sept. 17, 2014, 4:53 p.m.)
Review request for Plasma.
On Sept. 17, 2014, 4:28 p.m., Vishesh Handa wrote:
Do all of the tests now pass?
yes.
also without resizeorigin but by disconnecting/reconnecting (i tend to like
more using a variable as semaphore rather than have to manually rebuild the
connection status as it being actually more error
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120141/
---
(Updated Sept. 17, 2014, 5:48 nachm.)
Status
--
This change has
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120248/
---
Review request for Plasma.
Repository: plasma-desktop
Description
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120248/#review66766
---
hmm, not sure is the correct way, setting implicitsizes
On Sept. 17, 2014, 6:35 p.m., Marco Martin wrote:
hmm, not sure is the correct way, setting implicitsizes should be expected
to work correctly and not be rewrittten by the component.
maybe it should check at componentcomplete if at that point impolicitWidth
has been set by the user
On Sept. 17, 2014, 6:35 p.m., Marco Martin wrote:
hmm, not sure is the correct way, setting implicitsizes should be expected
to work correctly and not be rewrittten by the component.
maybe it should check at componentcomplete if at that point impolicitWidth
has been set by the user
On Sept. 17, 2014, 6:35 p.m., Marco Martin wrote:
hmm, not sure is the correct way, setting implicitsizes should be expected
to work correctly and not be rewrittten by the component.
maybe it should check at componentcomplete if at that point impolicitWidth
has been set by the user
On Sept. 17, 2014, 6:35 p.m., Marco Martin wrote:
hmm, not sure is the correct way, setting implicitsizes should be expected
to work correctly and not be rewrittten by the component.
maybe it should check at componentcomplete if at that point impolicitWidth
has been set by the user
On Sept. 17, 2014, 6:35 p.m., Marco Martin wrote:
hmm, not sure is the correct way, setting implicitsizes should be expected
to work correctly and not be rewrittten by the component.
maybe it should check at componentcomplete if at that point impolicitWidth
has been set by the user
On 15.09.2014 13:11, Sebastian Kügler wrote:
Announcement:
Freeze coming up: https://techbase.kde.org/Schedules/Plasma_5
[...]
Marco:
[...]
- will send email about freeze and -related process
Just for clarification: There seems to be some confusion
over whether the freeze for 5.1
On Wed, Sep 17, 2014 at 09:20:49PM +0200, Eike Hein wrote:
On 15.09.2014 13:11, Sebastian K?gler wrote:
Announcement:
Freeze coming up: https://techbase.kde.org/Schedules/Plasma_5
[...]
Marco:
[...]
- will send email about freeze and -related process
Just for clarification:
30 matches
Mail list logo
