Review Request: Using KWallet to store Cookies

--- 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

Re: Review Request: Allow KWidgetItemDelegate::createItemWidgets to know what index corresponds to the widgets

> 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:

Re: Review Request: Allow KWidgetItemDelegate::createItemWidgets to know what index corresponds to the widgets

--- 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 havin

Re: Kcmgrub2

In data martedì 26 aprile 2011 23:13:29, Albert Astals Cid ha scritto: > A Tuesday, April 26, 2011, Alberto Mattea va escriure: > > In data sabato 23 aprile 2011 05:03:22, Raphael Kubo da Costa ha scritto: > > > Alberto Mattea writes: > > > > Hi, kcmgrub2 has been under review for two weeks now. I

Re: Review Request: First part of fixes for password caching in KIO: SlaveBase::openPaswordDialog

--- 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

Re: Kcmgrub2

A Tuesday, April 26, 2011, Alberto Mattea va escriure: > In data sabato 23 aprile 2011 05:03:22, Raphael Kubo da Costa ha scritto: > > Alberto Mattea 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

Re: Review Request: fix wrong file extension for kmplot

--- 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 afcfaab2b2eef000e9b7

Re: Kcmgrub2

In data sabato 23 aprile 2011 05:03:22, Raphael Kubo da Costa ha scritto: > Alberto Mattea 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) to extragear

Re: Review Request: fix wrong file extension for kmplot

--- 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 b8ec6652f8b518bd4704

Re: Git Feature Branch Naming Policy

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. > > S

Re: [Kde-accessibility] Re: Accessibility content

On Tue, Apr 26, 2011 at 12:22 PM, Olaf Schmidt-Wischhöfer wrote: > [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

Re: [Kde-accessibility] Re: Accessibility content

[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

Re: [Kde-accessibility] Re: Accessibility content

On Tue, Apr 26, 2011 at 11:35 AM, Olaf Schmidt-Wischhöfer 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 side, just a

Re: Git Feature Branch Naming Policy

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 t

Re: Git Feature Branch Naming Policy

>> 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// Probably don't need subproject, since the branch name will probably/should tell

Re: Git Feature Branch Naming Policy

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// > > > > e.g. in kdelibs.git h

Re: Replacement for Qt's Undo Framework

2011/4/26 Aaron J. Seigo : > 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. > >

Re: Git Feature Branch Naming Policy

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 mana

Re: Replacement for Qt's Undo Framework

2011/4/26 Albert Astals Cid : >> I kept the arguments of UndoCommand() the same, but now if you put >> something like "Create a document|-|creation of a document" as the >> "text" into the constructor (or translate it with a similar string >> with "|-|"), you'll get "Create a document" as the name

Re: Accessibility content

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 wrote: > Hey all, > > In preparation for kdeaccessibility moving to git w

Re: Git Feature Branch Naming Policy

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// > > e.g. in kdelibs.git have "origin/gsoc2011/kdecore/astronomical-calendars" What if a stu

Git Feature Branch Naming Policy

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 http://community.kde.org/20110213_GitWorkflowAgenda

Re: Replacement for Qt's Undo Framework

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 issue

Re: Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves

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, http://ervin.ip

Request: Inclusion of kio-upnp-ms to kde-runtime KIO slaves

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 UPnP

Re: Replacement for Qt's Undo Framework

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 kd

Re: Deploying new kdelibs classes

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 > kdelib

Re: Replacement for Qt's Undo Framework

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 comb

Re: Replacement for Qt's Undo Framework

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

Re: Replacement for Qt's Undo Framework

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

Re: Replacement for Qt's Undo Framework

- 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 kdelib

Re: Replacement for Qt's Undo Framework

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