Re: Review Request 126231: Fix a small artifact of kratingwidget on hidpi

[Christoph Feck]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126231/#review89145
---

Ship it!


Ship It!

- Christoph Feck


On Dec. 3, 2015, 8:37 a.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126231/
> ---
> 
> (Updated Dec. 3, 2015, 8:37 a.m.)
> 
> 
> Review request for KDE Frameworks, Christoph Feck and David Edmundson.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> The other half of star size is wrong when calling drawPixmap. This change 
> makes the size arguments same as other drawPixmap calls.
> 
> 
> Diffs
> -
> 
>   src/kratingpainter.cpp 1a4378a 
> 
> Diff: https://git.reviewboard.kde.org/r/126231/diff/
> 
> 
> Testing
> ---
> 
> To reproduce the problem, try to set rating to 5 / 10 and make hover rating 
> to be 6.
> Now it draws correctly.
> 
> 
> File Attachments
> 
> 
> Demonstrate the problem
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2015/12/03/5fd4f10d-cc2a-49f4-b6b1-ac5ac1d1e9e5__screenshot24.png
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126223: Fix date filter used by timeline:/

[Xuetian Weng]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126223/
---

(Updated Dec. 6, 2015, 5:18 a.m.)


Status
--

This change has been marked as submitted.


Review request for Baloo and Vishesh Handa.


Changes
---

Submitted with commit 2813599eadfedeabd34569cbeb1d8de76adcb9cc by Weng Xuetian 
to branch master.


Repository: baloo


Description
---

timeline:/ doesn't return correct result for month 1 or day 1, this is because 
date filter always takes 1 as whole month or whole year. 0 should be used in 
such case.


Diffs
-

  src/lib/searchstore.cpp 11fbd3f 

Diff: https://git.reviewboard.kde.org/r/126223/diff/


Testing
---

timeline://2015-12/2015-12-01 now returns correct result.


Thanks,

Xuetian Weng


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Review Request 126227: Fix incomplete or duplicate search result with mtime

[Xuetian Weng]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126227/
---

(Updated Dec. 6, 2015, 5:29 a.m.)


Review request for Baloo and Vishesh Handa.


Changes
---

Move the sort and unique call to mtimedb


Repository: baloo


Description
---

Test with
- baloosearch 'modified=>...' -d $HOME
- baloosearch 'modified=>...'

This two queries should return same result since I only index home folder. But 
they are not, because result from mtimedb is not sorted.

In some other rare case (On my machine, regularly happens to torrent downloaded 
files), it could also return duplicate result. not sure if this should be 
considered as a indexer bug.

Sort and remove duplication from the result in VectorPostingIterator when 
requesting first result with next().


Diffs (updated)
-

  src/engine/mtimedb.cpp f7283b5 

Diff: https://git.reviewboard.kde.org/r/126227/diff/


Testing
---

No more duplicate result or missing result.


Thanks,

Xuetian Weng


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

[Chusslove Illich]

> On Дец. 4, 2015, 10:35 пре п., Chusslove Illich wrote:
> > The KI18N_INSTALL macro is also used by KI18n itself, to install its own 
> > translations. And so do other higher-tier frameworks. So I'm not sure when 
> > this no-Gettext/no-Python build is supposed to be useful. When one wants to 
> > omit translations?
> 
> Boudewijn Rempt wrote:
> I _never_ install translations. Where would I install them from? Running 
> "make install" in ki18n doesn't install translations, as far as I can see? I 
> thought translations get installed by the distribution, or I package them 
> manually for Windows and OSX. 
> 
> So, when I build Krita on OSX or Windows, I first need to build the 
> dependencies, and ki18n is one of them, but because it mixes up translation 
> management with providing the translation framework an application uses. So 
> why should I build Python and Gettext and QtQML for parts of this framework 
> that never get executed?
> 
> Chusslove Illich wrote:
> For me "make" does build translations using msgfmt, and builds some other 
> translation-related files using a Python script, and "make install" installs 
> those built files.
> 
> Something is definitely going wrong if QtQML is seen as dependency. What 
> is needed is QtScript, and that is a real dependency, used at runtime by 
> translations. It can be disabled, but that will cause degradation in quality 
> of some translations.
> 
> Chusslove Illich wrote:
> Hm, where do you fetch the frameworks to build from? If from the Git 
> repositories, there are no translations there. But the release tarballs do 
> contain translations.
> 
> Only Applications are released with separate translation packages. (Which 
> I think is not a good thing, but hell...)
> 
> Boudewijn Rempt wrote:
> Always from git.
> 
> Chusslove Illich wrote:
> If you are fetching and installing translations manually by taking only 
> PO files, that will leave any scripted translations not working. Nothing will 
> crash, but lower quality fallbacks will be used. If you want to support also 
> scripted translations, you should fetch and install any modules from script/ 
> subdirectories of translations in the repository.
> 
> Regarding this patch, I don't see it as appropriate, since it would 
> basically allow for broken treatment of translations when building release 
> tarballs. Better just add it to be applied in your build setup. I know, not 
> nice when something changes and the patch needs to be updated, but it's the 
> less bad alternative.
> 
> Aleix Pol Gonzalez wrote:
> @Chusslove, that might make it harder for people to port applications to 
> Windows though. (Or Android for that matter)
> 
> Maybe we can find an in-between compromise solution? In the end building 
> translations is something that only happens when you're about to release.
> 
> Kåre Särs wrote:
> I did a compile Kate on Windows exercise this summer and fall (hoping I 
> will get to the installer soon :) I was expecting _some_ hurdles but I was 
> shocked about how hard it was to compile KDE Frameworks 5 on Windows without 
> using emerge. This basically means that big parts of frameworks just was not 
> a realistic alternative for third-party Windows applications. With changes 
> that have flown in during this fall the building of frameworks on Windows has 
> become _much_ easier and is soon a real alternative for Windows Qt projects.
> 
> The gettext and python dependencies are probably the biggest hurdles. My 
> build script uses a trick inherited from emerge that just downloads a 
> pre-built binary package for the gettext tools and I had to rename some of 
> the include directories found in the Python installation because they clashed 
> with the rest of the build. Requiring python and downloading random packages 
> from SF is probably not something that any of my colleges at work would like 
> to add to their Qt projects.
> 
> Translations are really important and needs to be taken care of. I would 
> like it to be possible to split out the utilities somehow so that I could 
> compile the application without installing the utilities needed for the 
> compilation. The parts requiring Python/Gettext would be like CMake a 
> separate tool and not like Autotools a part of the package.
> 
> @Chusslove: This patch only disables the tools. What would it take to 
> split the tools out into a separate build?
> 
> Chusslove Illich wrote:
> If you don't have Gettext tools and Python, then you cannot properly 
> build translation files, of KI18n and other packages using it, no matter how 
> you do it.
> 
> But I don't follow what's going on there for Windows, so better not 
> bother anyone explaining it. Then, maybe have an explicit option to switch to 
> a no-op version of the ki18n_install macro, say:
> 
>   option(DROP_TRANSLATION_BUILDS "Replace CMake macros for building and 
> installing 

Re: Scope of framework integration plugin?

[René J . V . Bertin]

Boudewijn Rempt wrote:

From what I recall from KDE4, there was at least a KDE -> X resources path in 
systemsettings

> without any kde integration available, and I noticed that Qt 5.6 doesn't seem
> to pick up the Gnome font hinting settings.

Re-reading this I'd say there must be a default setting in Qt if it doesn't 
respect the X resource values on your Gnome-only system. I take it you checked 
if Qt-only applications have the same behaviour?

What Freetype and Fontconfig versions does that OpenSuse Leap system have? I 
seem to recall mention of things not getting picked up with the latest version 
of Bohoomil's infinality-ultimate project, which could be related (it's based 
on 
very recent Freetype and Fontconfig versions).

R.

>> That mostly comes from X resources.
>> 
>> can you run:
>> xrdb -q | grep  Xft
>> 
>> on both?
> 
> I have finally had a chance to sit down at the computer at home:
> 
> On the opensuse leap gnome-only system:
> 
> boud@linux-jw8m:~> xrdb -q | grep -i xft
> Xft.dpi:96
> Xft.antialias:  1
> Xft.hinting:0
> Xft.hintstyle:  hintnone
> Xft.rgba:   rgb
> 
> On the kde plasma 5 system:
> 
> 
> Xft.dpi:120
> Xft.antialias:  1
> Xft.hinting:0
> Xft.hintstyle:  hintnone
> Xft.rgba:   none
> 
>> 
>> startkde has a bunch of scripts to set these from your kde settings, but it's
>> somewhat archaic so I can see why Gnome might have ported away.



___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

GCI tasks needed

[Bhushan Shah]

Hello,

As you guys may already know we are participating in Google code in
2015 like previous years. This years contest is starting on 7th
December. And we are running very low on tasks this year.. We need
total 75 tasks before Monday when contest starts..

If you have small tasks in your project, please head over to
https://codein.withgoogle.com and add your tasks.

There are total 5 categories in which you can add your tasks:

- Code
- User interface
- Documentation/Training
- Quality Assurance
- Outreach/Research

If you are not yet signed up as mentor of the KDE organization, please
ping either me, valorie or Nightrose in the #kde-soc channel with your
Gmail or Google sign-in enabled email address and we will invite you
then you will be able to add the tasks in the Google code-in website.

Thanks!

-- 
Bhushan Shah

http://bhush9.github.io
IRC Nick : bshah on Freenode

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Sprint: Reorganize the wikis

[Vishesh Handa]

Hey Olivier

I'm so happy to see someone bring this up.

On Thu, Dec 3, 2015 at 12:10 AM, Olivier Churlaud  wrote:
> Hi,
>
> I'm coming here with this observation: the wiki are quite a mess. And very
> often KDE4 and KF5 things are mixed.
> That everyone do it at their scale is impossible. That's why I have a
> proposition. (I've thought about it for a while)
>
> It would be easier to do this like in a sprint, in team.
>
> 1) Define what structure the wiki should have: What is techbase? What is
> Community? Are the manuals in Userbase or on doc? and so on
> 2) then take each page and order => Archive KDE4 | Mess | KF5 | To remove
> 3) Do a list of what is missing and what should be tidied.
> 4) Write to the corresponding teams so that they take care of it.
> 5) Remove what should be
>

Perhaps also -

6) Are wikis the ideal way to present documentation? The have pros and
cons, and perhaps we can be more flexible on different approaches and
see what works out. We seem to have documentation in git repos [1],
wikis, and even a book or two.

[1] https://github.com/KDE/baloo/blob/master/docs/user/searching.md

> What I mean in 2) is: for example there are N pages about how to configure
> Git. We take the good one, put the other in a namespace "To remove"
>
> What I mean in 4) is: for example in https://community.kde.org/Sonnet, it's
> very old, and not much documented (sorry if some of you are reading this, I
> pick it randomly), so we can put a mail on the ML and tell them 'well we saw
> that...'
>
> Basically this is my vision of what could be done.
>
> Since I don't always know what is old what is still usable and so on, people
> with this knowledge would be required.
>
> I think we should plan it very carefully, to have a battle plan, and then
> go.
>
> What do you think?
> Would people be interested to give a hand?
> How and when do we begin?

I would definitely be interested.

However, I doubt I have the time to take time off work and travel for
this, so remotely, rather than physically.

--
Vishesh Handa

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Scope of framework integration plugin?

[Boudewijn Rempt]

On Mon, 30 Nov 2015, David Edmundson wrote:




On Mon, Nov 30, 2015 at 1:17 PM, Boudewijn Rempt  wrote:
  Sort of related question... Is this also the module that picks up the 
font hinting
  settings and applies it to KDE applications? I setup a gnome-only dev env 
to see
  what Krita 3 looks like on that platform, without any kde integration 
available,
  and I noticed that Qt 5.6 doesn't seem to pick up the Gnome font hinting 
settings.

 
That mostly comes from X resources.

can you run:
 xrdb -q | grep  Xft

on both?


I have finally had a chance to sit down at the computer at home:

On the opensuse leap gnome-only system:

boud@linux-jw8m:~> xrdb -q | grep -i xft
Xft.dpi:96
Xft.antialias:  1
Xft.hinting:0
Xft.hintstyle:  hintnone
Xft.rgba:   rgb

On the kde plasma 5 system:


Xft.dpi:120
Xft.antialias:  1
Xft.hinting:0
Xft.hintstyle:  hintnone
Xft.rgba:   none



startkde has a bunch of scripts to set these from your kde settings, but it's 
somewhat archaic so I can see why
Gnome might have ported away.

David


  And that gives horrible spindly fonts, so I was thinking of ways to fix 
that setting...

  On Mon, 30 Nov 2015, Aleix Pol wrote:

On Mon, Nov 30, 2015 at 1:15 PM, Martin Graesslin 
 wrote:
  On Monday, November 30, 2015 1:02:01 PM CET Aleix Pol wrote:
On Mon, Nov 30, 2015 at 12:48 PM, Martin Graesslin


  wrote:
> Hi all,
>
> there is currently a review request to add OSX 
specific changes
to
> framework integration plugin [1].
>
> This seems wrong to me. I think our framework 
integration plugin
is about
> integration Qt applications into the Plasma 
workspace. In my
opinion it
> should not be used anywhere else. Not on GNOME, not 
on Windows
and not on
> OSX. The idea of integration is that applications 
look native on
the
> desired platform. The plugin defines the native look 
on Plasma
and by
> that using it on other platforms is automatically 
breaking the
> integration.
>
> Now I understand that some people don't like the 
native look of
their
> platform and would prefer using Plasma. Sorry I don't 
have an
answer to
> that. Unfortunately I think it's completely out of 
scope for the
> integration platform to be considered outside Plasma.
>
> Given that: if people agree with my view that the 
framework
integration is
> only about Plasma, I suggest that we move the 
framework
integration to
> kde/
> workspace to release it together with Plasma instead 
of
frameworks.
>
> Opinions?

Hi,
I agree with you, I've proposed the same thing as you 
in the past,
although there's some issues that would then need to be 
sorted.

What you actually want is, IMHO, to move the 
QPlatformTheme plugin
together with Plasma, but frameworksintegration is not 
entirely
about
that nowadays: it has code that integrates different 
frameworks
with
each other:
- FrameworkIntegrationPlugin: this doesn't really 
belong in
plasma,
integrates KMessageBox with KNotifications.


  agree, does it belong into framework integration, though?


Well, yes. It's the very reason for the framework to exist.

Arguably nothing else belongs in the repository though... ;)


- infopage: this is used by applications as well as 
plasma


  same question: does this belong into framework integration?

- KStyle: Plasma can provide styles, but this seems 
more like a
QStyle
creation framework.


  maybe we need a dedicated kstyle framework?

- platformtheme: Plasma integration. There I agree.


  yep, that's what I actually was thinking 

Review Request 126249: Fix apidoc format

[Frederik Schwarzer]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126249/
---

Review request for kdelibs.


Repository: kio


Description
---

A full-stop within the first sentence (short description) breaks the line 
there. See e.g. 
http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/namespaceKIO.html#a17631774b47cddb0127d8a3c1fc2315c


Diffs
-

  src/core/storedtransferjob.h 3f267c9 
  src/core/transferjob.h 6d78793 

Diff: https://git.reviewboard.kde.org/r/126249/diff/


Testing
---


Thanks,

Frederik Schwarzer

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

[Boudewijn Rempt]

> On Dec. 4, 2015, 9:35 a.m., Chusslove Illich wrote:
> > The KI18N_INSTALL macro is also used by KI18n itself, to install its own 
> > translations. And so do other higher-tier frameworks. So I'm not sure when 
> > this no-Gettext/no-Python build is supposed to be useful. When one wants to 
> > omit translations?
> 
> Boudewijn Rempt wrote:
> I _never_ install translations. Where would I install them from? Running 
> "make install" in ki18n doesn't install translations, as far as I can see? I 
> thought translations get installed by the distribution, or I package them 
> manually for Windows and OSX. 
> 
> So, when I build Krita on OSX or Windows, I first need to build the 
> dependencies, and ki18n is one of them, but because it mixes up translation 
> management with providing the translation framework an application uses. So 
> why should I build Python and Gettext and QtQML for parts of this framework 
> that never get executed?
> 
> Chusslove Illich wrote:
> For me "make" does build translations using msgfmt, and builds some other 
> translation-related files using a Python script, and "make install" installs 
> those built files.
> 
> Something is definitely going wrong if QtQML is seen as dependency. What 
> is needed is QtScript, and that is a real dependency, used at runtime by 
> translations. It can be disabled, but that will cause degradation in quality 
> of some translations.
> 
> Chusslove Illich wrote:
> Hm, where do you fetch the frameworks to build from? If from the Git 
> repositories, there are no translations there. But the release tarballs do 
> contain translations.
> 
> Only Applications are released with separate translation packages. (Which 
> I think is not a good thing, but hell...)
> 
> Boudewijn Rempt wrote:
> Always from git.
> 
> Chusslove Illich wrote:
> If you are fetching and installing translations manually by taking only 
> PO files, that will leave any scripted translations not working. Nothing will 
> crash, but lower quality fallbacks will be used. If you want to support also 
> scripted translations, you should fetch and install any modules from script/ 
> subdirectories of translations in the repository.
> 
> Regarding this patch, I don't see it as appropriate, since it would 
> basically allow for broken treatment of translations when building release 
> tarballs. Better just add it to be applied in your build setup. I know, not 
> nice when something changes and the patch needs to be updated, but it's the 
> less bad alternative.
> 
> Aleix Pol Gonzalez wrote:
> @Chusslove, that might make it harder for people to port applications to 
> Windows though. (Or Android for that matter)
> 
> Maybe we can find an in-between compromise solution? In the end building 
> translations is something that only happens when you're about to release.
> 
> Kåre Särs wrote:
> I did a compile Kate on Windows exercise this summer and fall (hoping I 
> will get to the installer soon :) I was expecting _some_ hurdles but I was 
> shocked about how hard it was to compile KDE Frameworks 5 on Windows without 
> using emerge. This basically means that big parts of frameworks just was not 
> a realistic alternative for third-party Windows applications. With changes 
> that have flown in during this fall the building of frameworks on Windows has 
> become _much_ easier and is soon a real alternative for Windows Qt projects.
> 
> The gettext and python dependencies are probably the biggest hurdles. My 
> build script uses a trick inherited from emerge that just downloads a 
> pre-built binary package for the gettext tools and I had to rename some of 
> the include directories found in the Python installation because they clashed 
> with the rest of the build. Requiring python and downloading random packages 
> from SF is probably not something that any of my colleges at work would like 
> to add to their Qt projects.
> 
> Translations are really important and needs to be taken care of. I would 
> like it to be possible to split out the utilities somehow so that I could 
> compile the application without installing the utilities needed for the 
> compilation. The parts requiring Python/Gettext would be like CMake a 
> separate tool and not like Autotools a part of the package.
> 
> @Chusslove: This patch only disables the tools. What would it take to 
> split the tools out into a separate build?
> 
> Chusslove Illich wrote:
> If you don't have Gettext tools and Python, then you cannot properly 
> build translation files, of KI18n and other packages using it, no matter how 
> you do it.
> 
> But I don't follow what's going on there for Windows, so better not 
> bother anyone explaining it. Then, maybe have an explicit option to switch to 
> a no-op version of the ki18n_install macro, say:
> 
>   option(DROP_TRANSLATION_BUILDS "Replace CMake macros for building and 
> installing 

contribute to kde

[Sukant Kumar]

Hi Developers,
i am sukant kumar pursuing B.tech from Bhagalpur college of engineering.
i want to contribute for KDE community.
i have a prior knowledge of c , c++ , java and QT.
i have no prior experience in contributing to open source development.
can any one please guide me for contributing to the community.
expecting a positive reply.

thank you,
with regard.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Review Request 126253: kxmlgui.xsd add Separator append attribute

[Allen Winter]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126253/
---

(Updated Dec. 5, 2015, 9 p.m.)


Review request for kdelibs and Martin Walch.


Changes
---

don't need to set default=true for this attribute


Bugs: 356134
https://bugs.kde.org/show_bug.cgi?id=356134


Repository: kxmlgui


Description
---

Add an append attribute to the Separator Element of the kxmlgui.xsd


Diffs (updated)
-

  src/kxmlgui.xsd da1d155 

Diff: https://git.reviewboard.kde.org/r/126253/diff/


Testing
---


Thanks,

Allen Winter

Re: Sprint: Reorganize the wikis

[Valorie Zimmerman]

On Wed, Dec 2, 2015 at 3:10 PM, Olivier Churlaud  wrote:
> Hi,
>
> I'm coming here with this observation: the wiki are quite a mess. And very
> often KDE4 and KF5 things are mixed.
> That everyone do it at their scale is impossible. That's why I have a
> proposition. (I've thought about it for a while)
>
> It would be easier to do this like in a sprint, in team.
>
> 1) Define what structure the wiki should have: What is techbase? What is
> Community? Are the manuals in Userbase or on doc? and so on
> 2) then take each page and order => Archive KDE4 | Mess | KF5 | To remove
> 3) Do a list of what is missing and what should be tidied.
> 4) Write to the corresponding teams so that they take care of it.
> 5) Remove what should be
>
> What I mean in 2) is: for example there are N pages about how to configure
> Git. We take the good one, put the other in a namespace "To remove"
>
> What I mean in 4) is: for example in https://community.kde.org/Sonnet, it's
> very old, and not much documented (sorry if some of you are reading this, I
> pick it randomly), so we can put a mail on the ML and tell them 'well we saw
> that...'
>
> Basically this is my vision of what could be done.
>
> Since I don't always know what is old what is still usable and so on, people
> with this knowledge would be required.
>
> I think we should plan it very carefully, to have a battle plan, and then
> go.
>
> What do you think?
> Would people be interested to give a hand?
> How and when do we begin?
>
>
> Cheers
> Olivier

Sounds good to me! And I certainly would be willing to help, whether
remotely or at a physical sprint.

Valorie

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

[Aleix Pol Gonzalez]

> On Dec. 4, 2015, 10:35 a.m., Chusslove Illich wrote:
> > The KI18N_INSTALL macro is also used by KI18n itself, to install its own 
> > translations. And so do other higher-tier frameworks. So I'm not sure when 
> > this no-Gettext/no-Python build is supposed to be useful. When one wants to 
> > omit translations?
> 
> Boudewijn Rempt wrote:
> I _never_ install translations. Where would I install them from? Running 
> "make install" in ki18n doesn't install translations, as far as I can see? I 
> thought translations get installed by the distribution, or I package them 
> manually for Windows and OSX. 
> 
> So, when I build Krita on OSX or Windows, I first need to build the 
> dependencies, and ki18n is one of them, but because it mixes up translation 
> management with providing the translation framework an application uses. So 
> why should I build Python and Gettext and QtQML for parts of this framework 
> that never get executed?
> 
> Chusslove Illich wrote:
> For me "make" does build translations using msgfmt, and builds some other 
> translation-related files using a Python script, and "make install" installs 
> those built files.
> 
> Something is definitely going wrong if QtQML is seen as dependency. What 
> is needed is QtScript, and that is a real dependency, used at runtime by 
> translations. It can be disabled, but that will cause degradation in quality 
> of some translations.
> 
> Chusslove Illich wrote:
> Hm, where do you fetch the frameworks to build from? If from the Git 
> repositories, there are no translations there. But the release tarballs do 
> contain translations.
> 
> Only Applications are released with separate translation packages. (Which 
> I think is not a good thing, but hell...)
> 
> Boudewijn Rempt wrote:
> Always from git.
> 
> Chusslove Illich wrote:
> If you are fetching and installing translations manually by taking only 
> PO files, that will leave any scripted translations not working. Nothing will 
> crash, but lower quality fallbacks will be used. If you want to support also 
> scripted translations, you should fetch and install any modules from script/ 
> subdirectories of translations in the repository.
> 
> Regarding this patch, I don't see it as appropriate, since it would 
> basically allow for broken treatment of translations when building release 
> tarballs. Better just add it to be applied in your build setup. I know, not 
> nice when something changes and the patch needs to be updated, but it's the 
> less bad alternative.
> 
> Aleix Pol Gonzalez wrote:
> @Chusslove, that might make it harder for people to port applications to 
> Windows though. (Or Android for that matter)
> 
> Maybe we can find an in-between compromise solution? In the end building 
> translations is something that only happens when you're about to release.
> 
> Kåre Särs wrote:
> I did a compile Kate on Windows exercise this summer and fall (hoping I 
> will get to the installer soon :) I was expecting _some_ hurdles but I was 
> shocked about how hard it was to compile KDE Frameworks 5 on Windows without 
> using emerge. This basically means that big parts of frameworks just was not 
> a realistic alternative for third-party Windows applications. With changes 
> that have flown in during this fall the building of frameworks on Windows has 
> become _much_ easier and is soon a real alternative for Windows Qt projects.
> 
> The gettext and python dependencies are probably the biggest hurdles. My 
> build script uses a trick inherited from emerge that just downloads a 
> pre-built binary package for the gettext tools and I had to rename some of 
> the include directories found in the Python installation because they clashed 
> with the rest of the build. Requiring python and downloading random packages 
> from SF is probably not something that any of my colleges at work would like 
> to add to their Qt projects.
> 
> Translations are really important and needs to be taken care of. I would 
> like it to be possible to split out the utilities somehow so that I could 
> compile the application without installing the utilities needed for the 
> compilation. The parts requiring Python/Gettext would be like CMake a 
> separate tool and not like Autotools a part of the package.
> 
> @Chusslove: This patch only disables the tools. What would it take to 
> split the tools out into a separate build?
> 
> Chusslove Illich wrote:
> If you don't have Gettext tools and Python, then you cannot properly 
> build translation files, of KI18n and other packages using it, no matter how 
> you do it.
> 
> But I don't follow what's going on there for Windows, so better not 
> bother anyone explaining it. Then, maybe have an explicit option to switch to 
> a no-op version of the ki18n_install macro, say:
> 
>   option(DROP_TRANSLATION_BUILDS "Replace CMake macros for building and 
> installing 

Re: Review Request 126230: Make python, gettext and Qt5::QML optional for ki18n

[Chusslove Illich]

> On Дец. 4, 2015, 10:35 пре п., Chusslove Illich wrote:
> > The KI18N_INSTALL macro is also used by KI18n itself, to install its own 
> > translations. And so do other higher-tier frameworks. So I'm not sure when 
> > this no-Gettext/no-Python build is supposed to be useful. When one wants to 
> > omit translations?
> 
> Boudewijn Rempt wrote:
> I _never_ install translations. Where would I install them from? Running 
> "make install" in ki18n doesn't install translations, as far as I can see? I 
> thought translations get installed by the distribution, or I package them 
> manually for Windows and OSX. 
> 
> So, when I build Krita on OSX or Windows, I first need to build the 
> dependencies, and ki18n is one of them, but because it mixes up translation 
> management with providing the translation framework an application uses. So 
> why should I build Python and Gettext and QtQML for parts of this framework 
> that never get executed?
> 
> Chusslove Illich wrote:
> For me "make" does build translations using msgfmt, and builds some other 
> translation-related files using a Python script, and "make install" installs 
> those built files.
> 
> Something is definitely going wrong if QtQML is seen as dependency. What 
> is needed is QtScript, and that is a real dependency, used at runtime by 
> translations. It can be disabled, but that will cause degradation in quality 
> of some translations.
> 
> Chusslove Illich wrote:
> Hm, where do you fetch the frameworks to build from? If from the Git 
> repositories, there are no translations there. But the release tarballs do 
> contain translations.
> 
> Only Applications are released with separate translation packages. (Which 
> I think is not a good thing, but hell...)
> 
> Boudewijn Rempt wrote:
> Always from git.
> 
> Chusslove Illich wrote:
> If you are fetching and installing translations manually by taking only 
> PO files, that will leave any scripted translations not working. Nothing will 
> crash, but lower quality fallbacks will be used. If you want to support also 
> scripted translations, you should fetch and install any modules from script/ 
> subdirectories of translations in the repository.
> 
> Regarding this patch, I don't see it as appropriate, since it would 
> basically allow for broken treatment of translations when building release 
> tarballs. Better just add it to be applied in your build setup. I know, not 
> nice when something changes and the patch needs to be updated, but it's the 
> less bad alternative.
> 
> Aleix Pol Gonzalez wrote:
> @Chusslove, that might make it harder for people to port applications to 
> Windows though. (Or Android for that matter)
> 
> Maybe we can find an in-between compromise solution? In the end building 
> translations is something that only happens when you're about to release.
> 
> Kåre Särs wrote:
> I did a compile Kate on Windows exercise this summer and fall (hoping I 
> will get to the installer soon :) I was expecting _some_ hurdles but I was 
> shocked about how hard it was to compile KDE Frameworks 5 on Windows without 
> using emerge. This basically means that big parts of frameworks just was not 
> a realistic alternative for third-party Windows applications. With changes 
> that have flown in during this fall the building of frameworks on Windows has 
> become _much_ easier and is soon a real alternative for Windows Qt projects.
> 
> The gettext and python dependencies are probably the biggest hurdles. My 
> build script uses a trick inherited from emerge that just downloads a 
> pre-built binary package for the gettext tools and I had to rename some of 
> the include directories found in the Python installation because they clashed 
> with the rest of the build. Requiring python and downloading random packages 
> from SF is probably not something that any of my colleges at work would like 
> to add to their Qt projects.
> 
> Translations are really important and needs to be taken care of. I would 
> like it to be possible to split out the utilities somehow so that I could 
> compile the application without installing the utilities needed for the 
> compilation. The parts requiring Python/Gettext would be like CMake a 
> separate tool and not like Autotools a part of the package.
> 
> @Chusslove: This patch only disables the tools. What would it take to 
> split the tools out into a separate build?
> 
> Chusslove Illich wrote:
> If you don't have Gettext tools and Python, then you cannot properly 
> build translation files, of KI18n and other packages using it, no matter how 
> you do it.
> 
> But I don't follow what's going on there for Windows, so better not 
> bother anyone explaining it. Then, maybe have an explicit option to switch to 
> a no-op version of the ki18n_install macro, say:
> 
>   option(DROP_TRANSLATION_BUILDS "Replace CMake macros for building and 
> installing 

Review Request 126253: kxmlgui.xsd add Separator append attribute

[Allen Winter]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126253/
---

Review request for kdelibs and Martin Walch.


Bugs: 356134
https://bugs.kde.org/show_bug.cgi?id=356134


Repository: kxmlgui


Description
---

Add an append attribute to the Separator Element of the kxmlgui.xsd


Diffs
-

  src/kxmlgui.xsd da1d155 

Diff: https://git.reviewboard.kde.org/r/126253/diff/


Testing
---


Thanks,

Allen Winter

Jenkins-kde-ci: kwidgetsaddons master kf5-qt5 » Linux,gcc - Build # 43 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwidgetsaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/43/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 06 Dec 2015 02:34:17 +
Build duration: 4 min 39 sec

CHANGE SET
Revision 100f8a3a63d5326176ff7355e1adb2133a748ed2 by wengxt: (Fix a small 
artifact of KRatingWidget on hi-dpi.)
  change: edit src/kratingpainter.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 11 test(s), Skipped: 0 test(s), Total: 
11 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 60/133 (45%)CLASSES 60/133 (45%)LINE 3127/13366 
(23%)CONDITIONAL 1172/1913 (61%)

By packages
  
autotests
FILES 21/21 (100%)CLASSES 21/21 (100%)LINE 1021/1022 
(100%)CONDITIONAL 506/986 (51%)
src
FILES 39/112 (35%)CLASSES 39/112 (35%)LINE 2106/12344 
(17%)CONDITIONAL 666/927 (72%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: kwidgetsaddons master kf5-qt5 » Linux,gcc - Build # 43 - Fixed!

[no-reply]

GENERAL INFO

BUILD SUCCESS
Build URL: 
https://build.kde.org/job/kwidgetsaddons%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/43/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Sun, 06 Dec 2015 02:34:17 +
Build duration: 4 min 39 sec

CHANGE SET
Revision 100f8a3a63d5326176ff7355e1adb2133a748ed2 by wengxt: (Fix a small 
artifact of KRatingWidget on hi-dpi.)
  change: edit src/kratingpainter.cpp


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 11 test(s), Skipped: 0 test(s), Total: 
11 test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 60/133 (45%)CLASSES 60/133 (45%)LINE 3127/13366 
(23%)CONDITIONAL 1172/1913 (61%)

By packages
  
autotests
FILES 21/21 (100%)CLASSES 21/21 (100%)LINE 1021/1022 
(100%)CONDITIONAL 506/986 (51%)
src
FILES 39/112 (35%)CLASSES 39/112 (35%)LINE 2106/12344 
(17%)CONDITIONAL 666/927 (72%)___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126231: Fix a small artifact of kratingwidget on hidpi

[Xuetian Weng]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126231/
---

(Updated Dec. 6, 2015, 2:33 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Christoph Feck and David Edmundson.


Changes
---

Submitted with commit 100f8a3a63d5326176ff7355e1adb2133a748ed2 by Weng Xuetian 
to branch master.


Repository: kwidgetsaddons


Description
---

The other half of star size is wrong when calling drawPixmap. This change makes 
the size arguments same as other drawPixmap calls.


Diffs
-

  src/kratingpainter.cpp 1a4378a 

Diff: https://git.reviewboard.kde.org/r/126231/diff/


Testing
---

To reproduce the problem, try to set rating to 5 / 10 and make hover rating to 
be 6.
Now it draws correctly.


File Attachments


Demonstrate the problem
  
https://git.reviewboard.kde.org/media/uploaded/files/2015/12/03/5fd4f10d-cc2a-49f4-b6b1-ac5ac1d1e9e5__screenshot24.png


Thanks,

Xuetian Weng

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel