Re: Requested Moratorium on hard to build dependency bumps for KDE 5

2011-06-07 Thread Sebastian Trüg
Just as a side-note on SDO: For me SDO is very close to the KDE development process. If I had my way everyone running KDE master would also use SDO master. But for some reason that would only be acceptable if SDO were in KDE's git... On 06/06/2011 06:53 PM, Thiago Macieira wrote: On Monday, 6 de

Re: Requested Moratorium on hard to build dependency bumps for KDE 5

2011-06-07 Thread Sebastian Trüg
On 06/06/2011 10:51 PM, Ben Cooksley wrote: On Tue, Jun 7, 2011 at 8:42 AM, Martin Gräßlin mgraess...@kde.org wrote: On Tuesday 07 June 2011 08:29:51 Ben Cooksley wrote: Next KWin. It currently depends upon Mesa 7.10. I have a local revert in a private local branch which reverts the dependency

Re: Requested Moratorium on hard to build dependency bumps for KDE 5

2011-06-07 Thread Boudewijn Rempt
On Tuesday 07 June 2011 Jun, Sebastian Trüg wrote: Restricting ourselves to old versions (and as a developer anything released is old for me) means to restrict the power we have and undermines our very development model. In my opinion, almost always needing the development version of e.g. GTK

Re: Intended organization of KDE Frameworks

2011-06-07 Thread Albert Astals Cid
A Tuesday, June 07, 2011, Kevin Ottens va escriure: On Tuesday 7 June 2011 01:26:17 Albert Astals Cid wrote: A Tuesday, June 07, 2011, Kevin Ottens va escriure: Well, obviously a Tier 1 framework would have to use tr() instead of i18n() for its translation needs. Are we still going

Re: Requested Moratorium on hard to build dependency bumps for KDE 5

2011-06-07 Thread Tom Albers
- Original Message - IMHO it is out of the question to ask a developer to not implement a great new feature just because the dependancies are too young. I disagree completely. I would very much welcome a policy that states that you can only depend on stuff that is available in the

Re: Requested Moratorium on hard to build dependency bumps for KDE 5

2011-06-07 Thread Thiago Macieira
On Tuesday, 7 de June de 2011 07:53:28 Tom Albers wrote: - Original Message - IMHO it is out of the question to ask a developer to not implement a great new feature just because the dependancies are too young. I disagree completely. I would very much welcome a policy that states

Re: Requested Moratorium on hard to build dependency bumps for KDE 5

2011-06-07 Thread Alexander Neundorf
On Tuesday, June 07, 2011 09:32:09 AM Boudewijn Rempt wrote: On Tuesday 07 June 2011 Jun, Sebastian Trüg wrote: Restricting ourselves to old versions (and as a developer anything released is old for me) means to restrict the power we have and undermines our very development model. In my

Re: Rules to be approved as part of KDE Frameworks

2011-06-07 Thread Tom Albers
- Original Message - On Tuesday, June 07, 2011 02:00:20 AM Aaron J. Seigo wrote: On Monday, June 6, 2011 19:41:15 Maksim Orlovich wrote: * all new features will be developed using the recommended git workflow (pending publication; Cornelius is working on that one);

Re: Intended organization of KDE Frameworks

2011-06-07 Thread Aaron J. Seigo
On Tuesday, June 7, 2011 08:39:58 Inge Wallin wrote: So a well defined API that applications could use, and a well isolated way to include a set of implementations would be nice. We are dealing with the best way to make this happen is to create a concrete plan and propose it. for

Re: Rules to be approved as part of KDE Frameworks

2011-06-07 Thread Alexander Neundorf
On Tuesday, June 07, 2011 10:11:59 AM Tom Albers wrote: - Original Message - ... a documented git workflow is new, but needed. Yes, yes, yes. 100 %. We really need that. For git newbies (like me) and to avoid total chaos. And so that it stays possible to contribute to any

Native gettext support for Qt (was: Intended organization of KDE Frameworks)

2011-06-07 Thread Manuel Sput Nickschas
On Tuesday 07 June 2011 08:46:54 Albert Astals Cid wrote: This means that if you want Tier 1 frameworks to be translatable you need either to teach Qt to understand gettext files natively or to make Tier 1 frameworks use pure based Qt/Linguist solutions which does not fit either in what

Re: Native gettext support for Qt (was: Intended organization of KDE Frameworks)

2011-06-07 Thread Andreas Pakulat
On 07.06.11 11:51:29, Manuel Sput Nickschas wrote: On Tuesday 07 June 2011 08:46:54 Albert Astals Cid wrote: This means that if you want Tier 1 frameworks to be translatable you need either to teach Qt to understand gettext files natively or to make Tier 1 frameworks use pure based

Re: Intended organization of KDE Frameworks

2011-06-07 Thread John Layt
On Tuesday 07 Jun 2011 00:38:58 Kevin Ottens wrote: Right, however there's also a plan ATM to get the settings between KLocale and QLocale shared. John is working on that right now, so it depends a bit on the outcome, in any cases the situation is likely to improve on that particular point.

Re: Native gettext support for Qt (was: Intended organization of KDE Frameworks)

2011-06-07 Thread John Layt
On Tuesday 07 Jun 2011 10:51:29 Manuel Sput Nickschas wrote: On Tuesday 07 June 2011 08:46:54 Albert Astals Cid wrote: This means that if you want Tier 1 frameworks to be translatable you need either to teach Qt to understand gettext files natively or to make Tier 1 frameworks use pure

Re: Requested Moratorium on hard to build dependency bumps for KDE 5

2011-06-07 Thread Thiago Macieira
On Tuesday, 7 de June de 2011 10:14:43 Alexander Neundorf wrote: On Tuesday, June 07, 2011 08:21:02 AM Sebastian Trüg wrote: Just as a side-note on SDO: For me SDO is very close to the KDE development process. If I had my way everyone running KDE master would also use SDO master. But for

Re: Native gettext support for Qt (was: Intended organization of KDE Frameworks)

2011-06-07 Thread Albert Astals Cid
A Tuesday, June 07, 2011, John Layt va escriure: We discussed translation briefly at Platform 11 and Qt moving to or supporting .po is something we really want to push for at QCS. I really hope we have some people knowledgable about translation at QCS able to argue the point, otherwise please