Re: Review Request: include KolorManager in kdegraphics

The KolorManager project has been moved to extragear/graphics .
Thanks to all who helped with that.

kind regards
Kai-Uwe Behrmann
--

-- 
www.oyranos.org

Re: Review Request: Make KAuth ready for frameworks + API Changes

Il 31 marzo 2012 21:03, Stephen Kelly <steveire <at> gmail.com> ha scritto:
>
> Now I'm confused.
>
>>> Stephen Kelly wrote:
>>>     It was rebased onto some relatively recent commit, but not the tip of
>>>     the branch.
>
> You disagreed with what I said:
>
>>  - Given that the branch was rebased on top of the last frameworks' commit
>>  (as you can see from the log),
>
> ... actually I don't see that in the log. Here's what I see:
>
> http://i.imgur.com/xhbCC.png
>
> Do we have a difference in definitions, or is something else causing the
> confusion?

gitk indeed has a screwy visualization in there. Although, if you look
at the information in the merge commit, you'll see:

Parent: 4f9bf523bdb3f274f533d1dad2657537812d8c61 (match only the first
filter, if there are several matching (fdo#48054))

Which is indeed the last commit of frameworks before the rebase happened.

>
>> - Last but not least, looking just at the merge commit shows you the full

Re: Review Request: Make KAuth ready for frameworks + API Changes

Dario Freddi wrote:
> gitk indeed has a screwy visualization in there.

You conclusion that the tool is screwy is interesting for a few reasons. 
Maybe some day you'll reconsider it.

>> More importantly though, you seem to have broken the frameworks branch.
> 
> True, sorry about that. This is fixed now.

Thanks.

Re: Review Request: Make KAuth ready for frameworks + API Changes

Il 01 aprile 2012 14:35, Stephen Kelly <steveire <at> gmail.com> ha scritto:
> Dario Freddi wrote:
>> gitk indeed has a screwy visualization in there.
>
> You conclusion that the tool is screwy is interesting for a few reasons.
> Maybe some day you'll reconsider it.

Wait - I was considering just this specific case. I rarely use gitk so
I don't judge the tool itself, but indeed here the visualization is
misleading, given the parent is clearly marked and the rebase happened
(and you can really easily verify this by looking at the history even
with a simple "git log").

Re: Hunting a memory leak in KMail

On Saturday, March 31, 2012 11:48:57 PM you wrote:
> For some time I have been experiencing a memory leak that makes KMail go up
> to 1,5Gb of ram when using it for a long period of time, Volker saw it with
> his own eyes and we even tried to valgrind it.
Just to be clear when we tried to valgrind it we were looking for a leak in 
"Loading folders" rather than "loading emails".

Oh and this email was supposed to be sent to kde-pim, sorry for the noise :/

Re: Review Request: GlobalShortcuts Plugin for ActivityManager (kamd)

Fwd: [Development] Qt 5.0 alpha released

----------  Forwarded message  ----------

Subject: [Development] Qt 5.0 alpha released
Date: terça-feira, 3 de abril de 2012, 15.01.04
From: marius.storm-olsen <at> nokia.com
To: announce <at> qt-project.org
CC: development <at> qt-project.org, releasing <at> qt-project.org, interest <at> qt-
project.org

Hi,

We are happy to announce the Qt 5.0 alpha release. This is the first major Qt 
release since the Qt Project went live, and a large amount of work and 
features have gone into this release.

Blog post: http://labs.qt.nokia.com/2012/04/03/qt-5-alpha/

Download page: http://qt-project.org/wiki/Qt-5-Alpha

Thanks a lot for all the contributions and feedback, and thanks to all the 
people who made this happen!

The Qt Project

--

Marius Storm-Olsen

Head of Qt OSS

Nokia, Qt Development Frameworks
-----------------------------------------
--

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

RFC: i18n: strict translation call-to-catalog mapping

(This is the second and the last thing I want to change in i18n for KF5,
honestly.)

At present (and since forever) it is practically indetermined from which
catalog exactly an i18n() call will fetch the translation. All loaded
catalogs in the process are tried in mostly arbitrary order, depending when
and which library loaded them, and the first one that contains the
translation is used. This leads to situations where a random piece of code
on KDE-Look.org gets for "Sun" the star the translation of "Sun" the short
for Sunday. I think this could pass under the radar so far because KDE was
rather monolithic on the organization level ("go and add context to that
conflicting message"), but it becomes untollerable in the scope of
Frameworks. So the question is how to fix this.

For C++ code, I couldn't think of a better solution than that advised for
plain Gettext, and e.g. as formalized in Glib. It would amount to having:

  #define TRANSLATION_CATALOG "foolib"
  #include "KLocalizedString"

in a "top" include file of the library. This specializes all i18n() calls in
the including sources to look only in foolib catalog and nowhere else. No
other i18n() call in the process will look in foolib catalog (unless
explicitly instructed to). Under the hood there would be no particular
magic, as i18n() calls are just wrappers for
k18n().subs()...subs().toString(), and toString() already has overload that
takes catalog name. Anyone having a better idea? Maybe something more
C++ish.

The other part are .ui files. Since tr() calls generated by uic are actually
calls directly to KDE's tr2i18n(), set via -tr option to uic, I had this in
mind. uic would be updated to recognize -tr func,catalog form as well,
generating calls func("catalog", ...). KDE4_ADD_UI_FILES CMake macro would
get optional catalog name parameter, and pass it on to uic. So, like for C++
sources, the catalog for all .ui files in the library would be stated in
only one place, in its CMakeLists.txt.

The above was all for library code, and for application code the Gettext way
is that non-catalog-specific i18n() calls, i.e. where there was no
#define TRANSLATION_CATALOG before KLocalizedString inclusion, look into the
"main" catalog only. In KDE context, this is the catalog set with KAboutData
or KLocale::setMainCatalog(). So, for normal applications this change would
be fully transparent.

--

-- 
Chusslove Illich (Часлав Илић)

Re: Review Request: Better stars rating in dolphin

Re: Review Request: Better stars rating in dolphin