On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote:
What do you think about inclusion of KUndo*2 into kdelibs?
we really don't want more duplication of code and effort between Qt and
kdelibs, and we certainly don't want forks of Qt code in kdelibs.
please work on having this fixed in
- Original Message -
On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote:
What do you think about inclusion of KUndo*2 into kdelibs?
we really don't want more duplication of code and effort between Qt
and
kdelibs, and we certainly don't want forks of Qt code in kdelibs.
Tom,
with all the due respect, improve should mean the Qt version does the job,
but you have a more specific target to meet, which is alien to Qt. I'm not
aware of Qt localization having defined Russian off target, so I'd say an
upstream bug is an upstream bug. That's unless Qt says they have no
On Tuesday, 26 de April de 2011 07:12:32 Tom Albers wrote:
- Original Message -
On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote:
What do you think about inclusion of KUndo*2 into kdelibs?
we really don't want more duplication of code and effort between Qt
and
On Tuesday, April 26, 2011 07:12:32 Tom Albers wrote:
It does sound like to me as we take the base class from Qt and
improve it for usage within KDE.
not if it can be improved directly in the classes in Qt itself, limiting the
number of classes we have, lowering the cost of learning the
On Sat, April 23, 2011 10:22 pm, Jaroslaw Staniek wrote:
Aurélien, I am writing regarding
http://agateau.wordpress.com/2011/04/21/kde-ux-2011/
One thing, about deploying the kmessagewidget (and similar things) in
kdelibs. If it's part of kdelibs 4.7 or something, apps that support
kdelibs
On Tuesday 26 April 2011, Aaron J. Seigo wrote:
we really don't want more duplication of code and effort between Qt and
kdelibs, and we certainly don't want forks of Qt code in kdelibs.
Especially after I moved the KUndoCommand/KUndoHistory classes to kde3support,
after polishing them for
Hi,
KDE SC 4.7 soft feature freeze is close, and I would like to propose
the UPnP MediaServer KIO slave
(https://projects.kde.org/projects/playground/base/kio-upnp-ms/) be
included into the set of kio slaves shipped with kde-runtime. The
slave was created as part of GSoC 2010 - Amarok and KDE
On Tuesday 26 April 2011 14:53:11 Nikhil Marathe wrote:
If there is no objection I would like to request a merge into
kde-runtime. I will edit the 4.7 feature plan for the same.
Yes! At last!
/me fairly happy to see that getting close to completion.
Regards.
--
Kévin Ottens,
A Dimarts, 26 d'abril de 2011, Olivier Goffart va escriure:
What do you think about inclusion of KUndo*2 into kdelibs?
I have not seen the details about KUndo2 yet, but what are the reasons
that keep you from improving QUndo in Qt? Is there technical reasons? or
just political issues?
Hi,
Did anything come out from discussions on feature branch naming in git? With
GSoC starting soon we'll be getting a lot of new feature branches and it would
be nice if they were consistantly named to make them easy to find and manage.
See
Ok, so nobody objected, so I migrated IconThemes/mono into
kdeartwork/IconThemes and ColorSchemes/Zion and ZionReversed into
kdeartwork/ColorSchemes just now. Enjoy.
Jeremy
On Wed, Apr 20, 2011 at 3:39 PM, Jeremy Whiting jpwhit...@kde.org wrote:
Hey all,
In preparation for kdeaccessibility
On Tuesday 26 April 2011 15.52.18 John Layt wrote:
Hi,
Did anything come out from discussions on feature branch naming in git?
With GSoC starting soon we'll be getting a lot of new feature branches and
it would be nice if they were consistantly named to make them easy to find
and manage.
2011/4/26 Aaron J. Seigo ase...@kde.org:
On Monday, April 25, 2011 22:12:55 Alexander Potashev wrote:
What do you think about inclusion of KUndo*2 into kdelibs?
we really don't want more duplication of code and effort between Qt and
kdelibs, and we certainly don't want forks of Qt code in
On Tuesday 26 Apr 2011 16:18:22 Harald Sitter wrote:
On Tuesday 26 April 2011 15:52:18 John Layt wrote:
I'd prefer to see the gsoc branches under a common prefix in the main
project repo rather than as personal branches or repos:
origin/gsoc2011/subproject/branchname
e.g. in
I'd prefer to see the gsoc branches under a common prefix in the main
project repo rather than as personal branches or repos:
I think that's a good idea too, especially given (below).
origin/gsoc2011/subproject/branchname
Probably don't need subproject, since the branch name will
On Tuesday 26 Apr 2011 17:37:47 Torgny Nyblom wrote:
Why this long name with multiple namespaces, the branches should be deleted
once merged so we won't have a collection of old soc branches around for
long?
/Regards
Torgny
Well it's based on the original naming proposal to try keep things
On Tue, Apr 26, 2011 at 11:35 AM, Olaf Schmidt-Wischhöfer ojschm...@kde.org
wrote:
Hi Jeremy,
Ok, so nobody objected, so I migrated IconThemes/mono into
kdeartwork/IconThemes and ColorSchemes/Zion and ZionReversed into
kdeartwork/ColorSchemes just now. Enjoy.
No objection from my
[Jeremy Whiting, 26.04.2011, 20:07]:
Yeah, that probably would make more sense. Actually I'm not sure what the
reason for having any of the color schemes in kdeartwork is. They aren't
exactly large. I'll move them into kde-workspace/kcontrol/colors/schemes
in a moment.
Thanks.
A related
On Tuesday 26 April 2011, John Layt wrote:
Hi,
Did anything come out from discussions on feature branch naming in git?
With GSoC starting soon we'll be getting a lot of new feature branches and
it would be nice if they were consistantly named to make them easy to find
and manage.
See
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101059/#review2903
---
This review has been submitted with commit
In data sabato 23 aprile 2011 05:03:22, Raphael Kubo da Costa ha scritto:
Alberto Mattea albe...@mattea.info writes:
Hi, kcmgrub2 has been under review for two weeks now. I've done all the
suggested changes.
Would it be possible to move it to kdemain/sysadmin or (if that's not
possible)
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101059/#review2905
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101174/#review2906
---
Looks good, just some comments.
kio/kio/slavebase.cpp
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101219/#review2913
---
Maybe I am misunderstanding the goal of the patch. I agree
On April 26, 2011, 10:08 p.m., Rafael Fernández López wrote:
Maybe I am misunderstanding the goal of the patch. I agree having this is
cool, but it is not strictly necessary. In your use case, you can return
the list of widgets in the createItemWidgets method with just one widget:
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101241/
---
Review request for kdelibs.
Summary
---
Currently cookies are stored
27 matches
Mail list logo
