name of the kconfig config file

2014-07-30 Thread kde 

Hello,


i saw that kconfig want to use kde5rc, for coherency and to not confuse 
people, shouldn't it be kf5rc ?



Regards
Nicolas Lécureuil.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Build failed in Jenkins: kde-baseapps_frameworks_qt5 #72

2014-07-30 Thread KDE CI System 
See 

Changes:

[faure] remove deprecated and unused KNewMenu, replaced with KNewFileMenu in 
kio since 4.5

--
[...truncated 499 lines...]
  KFileItem kfi(KFileItem::Unknown, KFileItem::Unknown, KUrl(startDir));
  ^
:612:19:
 warning: ‘KFileDialog’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kfiledialog.h:74)
 [-Wdeprecated-declarations]
  KFileDialog dlg( specialDir ? startDir : QString(), filter, 0 );
   ^
:622:11:
 warning: ‘KUrl’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109)
 [-Wdeprecated-declarations]
  KUrl result = dlg.selectedUrl();
   ^
:631:30:
 warning: ‘static void KRecentDocument::add(const QString&, bool)’ is 
deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kio/inst/include/KF5/KIOCore/krecentdocument.h:91)
 [-Wdeprecated-declarations]
   KRecentDocument::add(result);
  ^
:649:7:
 warning: ‘KUrl’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109)
 [-Wdeprecated-declarations]
  KUrl url;
   ^
:650:29:
 warning: ‘KDirSelectDialog’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kdirselectdialog.h:36)
 [-Wdeprecated-declarations]
  KDirSelectDialog myDialog( startDir, true, 0 );
 ^
:679:19:
 warning: ‘KFileDialog’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kfiledialog.h:74)
 [-Wdeprecated-declarations]
  KFileDialog dlg( startDir, filter, 0 );
   ^
:693:17:
 warning: ‘List’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:143)
 [-Wdeprecated-declarations]
  KUrl::List result = dlg.selectedUrls();
 ^
:699:11:
 warning: ‘KUrl’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:109)
 [-Wdeprecated-declarations]
  KUrl result = dlg.selectedUrl();
   ^
:785:25:
 warning: ‘KColorDialog’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kcolordialog.h:211)
 [-Wdeprecated-declarations]
 KColorDialog dlg((QWidget*)0L, true);
 ^
: 
In function ‘int main(int, char**)’:
:846:24:
 warning: ‘K4AboutData’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/k4aboutdata.h:199)
 [-Wdeprecated-declarations]
   K4AboutData aboutData( "kdialog", 0, ki18n("KDialog"),
^
:862:19:
 warning: ‘KCmdLineOptions’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kcmdlineargs.h:53)
 [-Wdeprecated-declarations]
   KCmdLineOptions options;
   ^
:912:16:
 warning: ‘KApplication’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kapplication.h:76)
 [-Wdeprecated-declarations]
   KApplication app;
^
:914:17:
 warning: ‘KCmdLineArgs’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kcmdlineargs.h:286

Re: Review Request 119542: create qapplication before using dbus

2014-07-30 Thread Sebastian Kügler 

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

Ship it!


Sensible.


src/kauthhelpersupport.cpp


s/ahve/have


- Sebastian Kügler


On July 30, 2014, 12:43 a.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119542/
> ---
> 
> (Updated July 30, 2014, 12:43 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kauth
> 
> 
> Description
> ---
> 
> qt doesn't take very kindly to using dbus before having a qcoreapplication,
> so move the app init before the helper proxy init (which might be using
> dbus) to avoid possible issues in the future
> 
> 
> Diffs
> -
> 
>   src/kauthhelpersupport.cpp 99868803fdfaf99283d65a8ab61e7a32fb22e708 
> 
> Diff: https://git.reviewboard.kde.org/r/119542/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

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

Re: Review Request 119542: create qapplication before using dbus

2014-07-30 Thread Harald Sitter 

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

(Updated July 30, 2014, 12:13 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kauth


Description
---

qt doesn't take very kindly to using dbus before having a qcoreapplication,
so move the app init before the helper proxy init (which might be using
dbus) to avoid possible issues in the future


Diffs
-

  src/kauthhelpersupport.cpp 99868803fdfaf99283d65a8ab61e7a32fb22e708 

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


Testing
---


Thanks,

Harald Sitter

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

Build failed in Jenkins: kde-baseapps_frameworks_qt5 #73

2014-07-30 Thread KDE CI System 
See 

Changes:

[lbeltrame] Fix build.

--
[...truncated 2242 lines...]
 const KUrl::List m_urls;
  ^
:149:51:
 warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations]
 void KFindItemModel::removeItem( const KUrl & url )
   ^
:165:51:
 warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations]
 bool KFindItemModel::isInserted( const KUrl & url )
   ^
:
 In member function ‘virtual QMimeData* KFindItemModel::mimeData(const 
QModelIndexList&) const’:
:196:16:
 warning: ‘List’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:143)
 [-Wdeprecated-declarations]
 KUrl::List uris;
^
:213:37:
 warning: ‘void KUrl::List::populateMimeData(QMimeData*, const MetaDataMap&, 
KUrl::MimeDataFlags) const’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:221)
 [-Wdeprecated-declarations]
 uris.populateMimeData( mimeData );
 ^
:
 In constructor ‘KFindTreeView::KFindTreeView(QWidget*, KfindDlg*)’:
:353:32:
 warning: ‘KAction’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kaction.h:211)
 [-Wdeprecated-declarations]
 QAction * openFolder = new KAction( KIcon("window-new"), i18n("&Open 
containing folder(s)"), this );
^
:357:25:
 warning: ‘KAction’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kaction.h:211)
 [-Wdeprecated-declarations]
 QAction * del = new KAction( KIcon("edit-delete"), i18n("&Delete"), this );
 ^
:362:27:
 warning: ‘KAction’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kaction.h:211)
 [-Wdeprecated-declarations]
 QAction * trash = new KAction( KIcon("user-trash"), i18n("&Move to 
Trash"), this );
   ^
[ 26%] 
:
 At global scope:
:397:52:
 warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations]
 void KFindTreeView::beginSearch(const KUrl& baseUrl)
^
:414:48:
 warning: ‘KUrl’ is deprecated [-Wdeprecated-declarations]
 void KFindTreeView::removeItem(const KUrl & url)
^
:
 In member function ‘void KFindTreeView::removeItem(const KUrl&)’:
:416:16:
 warning: ‘List’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kurl.h:143)
 [-Wdeprecated-declarations]
 KUrl::List list = selectedUrls();
^
:
 In member function ‘void KFindTreeView::saveResults()’:
:443:18:
 warning: ‘KFileDialog’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kfiledialog.h:74)
 [-Wdeprecated-declarations]
 KFileDialog *dlg = new KFileDialog(QString(), QString(), this);
  ^
:443:28:
 warning: ‘KFileDialog’ is deprecated (declared at 
/srv/jenkins/install/linux/x86_64/g++/kf5-qt5/frameworks/kdelibs4support/inst/include/KF5/KDELibs4Support/kfiledialog.h:74)
 [-Wdeprecated-declarations

Re: Review Request 119540: don't construct bogus KAuthAction objects

2014-07-30 Thread Luca Beltrame 

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


My question is, is KAuth being constructed with a default string ("") useful to 
anyone? IMO the issue, if any, it's there, and this looks like a workaround. 
(But I claim no expertise on the code, so feel free to flame me :P)

- Luca Beltrame


On Lug. 30, 2014, 12:32 a.m., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119540/
> ---
> 
> (Updated Lug. 30, 2014, 12:32 a.m.)
> 
> 
> Review request for KDE Frameworks, Hrvoje Senjan and Martin Bříza.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> KAuthAction(0) actually calls the QString constructor which will dispatch
> bogus polkit auth checks, polkitqt and polkitd are not terribly happy about
> those and subsequently don't want to talk to the KCM anymore, even if it
> manages to create a proper Action
> 
> creating a null Action rather than accidentally triggering the QString
> ctor ensures that we only do polkit interaction with reasonable actionids
> making sure that authentication works as expected
> 
> 
> Diffs
> -
> 
>   src/kcmodule.cpp 92e5427c121491e4ebf289addda040cc117cdd68 
> 
> Diff: https://git.reviewboard.kde.org/r/119540/diff/
> 
> 
> Testing
> ---
> 
> tested with clock kcm, succesfully can talk with the helper app if the bogus 
> actionid "" wasn't used intermediately
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

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

Build failed in Jenkins: kde-baseapps_frameworks_qt5 #74

2014-07-30 Thread KDE CI System 
See 

Changes:

[lbeltrame] Fix the build for real

--
[...truncated 2658 lines...]
[ 74%] Built target kitemlistkeyboardsearchmanagertest
[ 74%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemlistcontrollertest.dir/__/kitemviews/kitemlistwidget.cpp.o
[ 74%] Built target kfileitemlistviewtest
[ 74%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemlistcontrollertest.dir/__/kitemviews/kitemset.cpp.o
[ 74%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/information/pixmapviewer.cpp.o
[ 74%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemlistselectionmanagertest.dir/__/kitemviews/kitemlistselectionmanager.cpp.o
:53:50:
 note: #pragma message: TODO: port accessibility to Qt5
 #pragma message("TODO: port accessibility to Qt5")
  ^
:
 In member function ‘virtual void KItemListView::slotItemsChanged(const 
KItemRangeList&, const QSet&)’:
:1277:80:
 note: #pragma message: TODO: port accessibility otherwise the following line 
asserts
 #pragma message("TODO: port accessibility otherwise the following line 
asserts")

^
:
 In member function ‘virtual void KItemListView::slotCurrentChanged(int, int)’:
:1354:80:
 note: #pragma message: TODO: port accessibility otherwise the following line 
asserts
 #pragma message("TODO: port accessibility otherwise the following line 
asserts")

^
[ 74%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemlistselectionmanagertest.dir/__/kitemviews/kitemmodelbase.cpp.o
[ 74%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemlistcontrollertest.dir/__/kitemviews/kstandarditemlistview.cpp.o
[ 75%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/information/phononwidget.cpp.o
[ 76%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemlistselectionmanagertest.dir/__/kitemviews/kitemset.cpp.o
[ 76%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemlistselectionmanagertest.dir/kitemlistselectionmanagertest_automoc.cpp.o
[ 77%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemlistcontrollertest.dir/__/kitemviews/kstandarditemlistwidget.cpp.o
[ 77%] [ 77%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/places/placespanel.cpp.o
Building CXX object 
dolphin/src/tests/CMakeFiles/kitemlistcontrollertest.dir/kitemlistcontrollertest_automoc.cpp.o
[ 77%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/places/placesitem.cpp.o
[ 78%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/places/placesitemeditdialog.cpp.o
[ 78%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/places/placesitemlistgroupheader.cpp.o
Linking CXX executable kitemlistselectionmanagertest
Scanning dependencies of target kitemrangetest
[ 79%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemrangetest.dir/kitemrangetest.cpp.o
[ 79%] [ 79%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemrangetest.dir/kitemrangetest_automoc.cpp.o
Built target kitemlistselectionmanagertest
[ 79%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/places/placesitemlistwidget.cpp.o
Scanning dependencies of target kitemsettest
:121:6:
 warning: unused parameter ‘index’ [-Wunused-parameter]
 bool KStandardItemListWidgetInformant::itemIsLink(int index, const 
KItemListView* view) const
  ^
:121:6:
 warning: unused parameter ‘view’ [-Wunused-parameter]
[ 79%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemsettest.dir/kitemsettest.cpp.o
[ 79%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/places/placesitemmodel.cpp.o
[ 80%] Building CXX object 
dolphin/src/tests/CMakeFiles/kitemsettest.dir/__/kitemviews/kitemset.cpp.o
[ 81%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/places/placesitemsignalhandler.cpp.o
[ 81%] Building CXX object 
dolphin/src/CMakeFiles/kdeinit_dolphin.dir/panels/places/placesview.cpp.o
Linking CXX executable kitemlistcontrollertest
Scanning dependencies of target k

Re: Review Request 119540: don't construct bogus KAuthAction objects

2014-07-30 Thread Harald Sitter 


> On Juli 30, 2014, 2:29 nachm., Luca Beltrame wrote:
> > My question is, is KAuth being constructed with a default string ("") 
> > useful to anyone? IMO the issue, if any, it's there, and this looks like a 
> > workaround. (But I claim no expertise on the code, so feel free to flame me 
> > :P)

>From what I understand: since kauth supports multiple backends assuming that 
>an empty string necessarily represents an invalid action may well be wrong, 
>the apidox at the very least do not say anything about this. It does however 
>constitute an invalid action for polkit-qt, so there is a problem in polkit's 
>authority class in that it either should reject operations on an empty action 
>id preventing obvious errors or (somewhat more importantly I guess) recover 
>from having used an invalid action id previously. At a polkit-qt level what 
>happens is that the action results in a (IIRC) instance error which will make 
>all further requests be discarded on account of the Authority having the error 
>flag set, from that point on it does not automatically recover from. So to fix 
>this particular polkit-qt specific issue I can actually imagine two ways this 
>should work a) kauth should use clearError() before trying to do anything b) 
>polkit-qt clearing the error when a new action(id) is request
 ed. I totally do not feel comfortable saying which one it should be but from a 
convenience POV latter certainly seems best, having to clear error flags from 
outside the library is not a case I feel is often present in Qt-based libraries.

Regardless of all that, Auth(0) with 0 being implicitly cast to QString causing 
the Auth(QString&) ctor to be used certainly is not the intended initialization 
in kcmodule. So it happens to be a workaround for the Authority encountering an 
error and then refusing to do things until someone clears the error, it also 
happens to be a fix for using a wrong ctor and weirdly implict casting QString 
though ;)


- Harald


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


On Juli 30, 2014, 12:32 vorm., Harald Sitter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119540/
> ---
> 
> (Updated Juli 30, 2014, 12:32 vorm.)
> 
> 
> Review request for KDE Frameworks, Hrvoje Senjan and Martin Bříza.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> KAuthAction(0) actually calls the QString constructor which will dispatch
> bogus polkit auth checks, polkitqt and polkitd are not terribly happy about
> those and subsequently don't want to talk to the KCM anymore, even if it
> manages to create a proper Action
> 
> creating a null Action rather than accidentally triggering the QString
> ctor ensures that we only do polkit interaction with reasonable actionids
> making sure that authentication works as expected
> 
> 
> Diffs
> -
> 
>   src/kcmodule.cpp 92e5427c121491e4ebf289addda040cc117cdd68 
> 
> Diff: https://git.reviewboard.kde.org/r/119540/diff/
> 
> 
> Testing
> ---
> 
> tested with clock kcm, succesfully can talk with the helper app if the bogus 
> actionid "" wasn't used intermediately
> 
> 
> Thanks,
> 
> Harald Sitter
> 
>

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

Minimum translation percentage for frameworks release

2014-07-30 Thread Albert Astals Cid 
Hi, in the 4.x world we have something called "Essential Packages" for 
translations that is basically a set of minimum percentage of some files that 
you need to get if you want the whole translation of your language to be 
released with the 4.x SC.

For Plasma 5.x we probably are thinking on a 70% over all the files for the 
translations to be shipped.

I've been thinking about frameworks and i think it makes no sense to impose a 
minimum translation percentage.

The reason is that frameworks being a more "disperse" set of libraries (i.e. 
they can be used on a one or many basis for other projects) doing a global 
percentage is probably not a good idea (and we ship the translations 
individually anyway for each framework)

Per framework percentage is more argable if makes sense or not, but again the 
fact that let's say VLC may be using libkscreen (and in windows they would be 
shipping it themselves) means that I think it is a good idea that we let the 
downstream users be the ones that decide to include or not the translations 
(In case of linux would be the job of distros).

Opinions?

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

Re: Minimum translation percentage for frameworks release

2014-07-30 Thread Alexander Potashev 
2014-07-31 1:56 GMT+04:00 Albert Astals Cid :
> The reason is that frameworks being a more "disperse" set of libraries (i.e.
> they can be used on a one or many basis for other projects) doing a global
> percentage is probably not a good idea (and we ship the translations
> individually anyway for each framework)

Albert,

I agree with you in that doing a global percentage is bad, okay: some
3rd party applications might be happy with just KWidgetsAddons, and so
a global percentage would stop it from being translated because you
translated only kwidgetsaddons.po and not the other frameworks.

But doing per-framework percentages is no bueno, either: imagine your
app uses KService and you translated only this framework having
skipped its dependencies. Then the app might be translated very poorly
if many strings come from the dependent frameworks.

To account for dependencies we may choose "70% of strings from the
framework + its dependencies" as the per-framework criterion for
shipping a language.

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

Re: Minimum translation percentage for frameworks release

2014-07-30 Thread Aleix Pol 
On Thu, Jul 31, 2014 at 1:36 AM, Alexander Potashev 
wrote:

> 2014-07-31 1:56 GMT+04:00 Albert Astals Cid :
> > The reason is that frameworks being a more "disperse" set of libraries
> (i.e.
> > they can be used on a one or many basis for other projects) doing a
> global
> > percentage is probably not a good idea (and we ship the translations
> > individually anyway for each framework)
>

+1, I think it makes sense to let the distribution channels to decide.


>
> Albert,
>
> I agree with you in that doing a global percentage is bad, okay: some
> 3rd party applications might be happy with just KWidgetsAddons, and so
> a global percentage would stop it from being translated because you
> translated only kwidgetsaddons.po and not the other frameworks.
>
> But doing per-framework percentages is no bueno, either: imagine your
> app uses KService and you translated only this framework having
> skipped its dependencies. Then the app might be translated very poorly
> if many strings come from the dependent frameworks.
>
> To account for dependencies we may choose "70% of strings from the
> framework + its dependencies" as the per-framework criterion for
> shipping a language.
>

Read again what Albert said, he's not proposing to filter per framework.

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

Re: Review Request 119551: Fix KFilePreviewGenerator not triggering model change update when determining MIME type as byproduct of unsuccessful preview job

2014-07-30 Thread Eike Hein 

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

(Updated July 31, 2014, 6:04 a.m.)


Review request for KDE Frameworks, Bhushan Shah and David Faure.


Changes
---

Typo fix.


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


Repository: kio


Description (updated)
---

KDirModel, KDirLister and KFilePreviewGenerator interact as follows:

KDirModel uses a KDirLister as its data source. KDirLister has a boolean 
"delayed MIME types" option. When enabled, file MIME types are not determined 
automatically, but only when requested explicitly via 
KFileItem::determineMimeType(). This does not immediately cause a model update 
(dataChanged), i.e. it falls to whatever entity that decides to determine the 
MIME type to also announce a model change once the MIME type has been resolved. 
Until its MIME type has been resolved, the DecorationRole for an item in the 
model will be a generic icon.

In practice, this falls to KFilePreviewGenerator. KFilePreviewGenerator 
operates in two modes: Previews on or off. With previews off, it resolves MIME 
types and announces model updates. With previews on, it uses KIO::PreviewJobs 
to generate preview thumbnails and cause model updates to be announced.

But there's an unhandled case: When a PreviewJob does not actually generate a 
preview thumbnail for a file item (e.g. because there's no thumbnailer 
supporting the MIME type, or it's broken for whatever reason), no model change 
is announced for it. This is despite the fact that a PreviewJob implicitly 
causes the item's MIME type to be resolved (it has to, to figure out the right 
thumbnailer plugin to query), and so even though no thumbnail has been 
generated, it might now be possible to go from the generic icon to a proper 
MIME type icon (i.e. exactly what would happen if previews were off).

The patch proposed here does the following: When all outstanding preview jobs 
have finished, it loops over the still-pending items (i.e. that didn't actually 
get a preview generated) and adds those that had their MIME types resolved to 
the list the "previews off" codepath uses to track items that had their MIME 
types resolved. The dispatch method (that causes model change annoucements) is 
modified to always check this list even if previews are on.

This fixes awkard behavior in views, because determining the MIME type 
effectively causes the DecorationRole to change but this change isn't announced 
by the model via dataChanged(). With this patch, it is.


Diffs
-

  src/filewidgets/kfilepreviewgenerator.cpp 274bdf2 

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


Testing
---


Thanks,

Eike Hein

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

Review Request 119551: Fix KFilePreviewGenerator not triggering model change update when determining MIME type as byproduct of unsuccessful preview job

2014-07-30 Thread Eike Hein 

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

Review request for KDE Frameworks, Bhushan Shah and David Faure.


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


Repository: kio


Description
---

KDirModel, KDirLister and KFilePreviewGenerator interact as follows:

KDirModel uses a KDirLister as its data source. KDirLister has a boolean 
"delayed MIME types" option. When enabled, file MIME types are not determined 
automatically, but only when requested explicitly via 
KFileItem::determineMimeType(). This does not immediately cause a model update 
(dataChanged), i.e. it falls to whatever entity that decides to determine the 
MIME type to also announce a model change once the MIME type has been resolved. 
Until its MIME type has been resolved, the DecorationRole for an item in the 
model will be a generic icon.

In practice, this falls to KFilePreviewGenerator. KFilePreviewGenerator 
operates in two modes: Previews on or off. With previews off, it resolves MIME 
types and announces model updates. With previews on, it uses KIO::PreviewJobs 
to generate preview thumbnails and cause model updates to be announced.

But there's an unhandled case: When a PreviewJob does not actually generate a 
preview thumbnail for a file item (e.g. because there's no thumbnailer 
supporting the MIME type, or it's broken for whatever reason), no model change 
is announced for it. This is despite the fact that a PreviewJob implicitly 
causes the item's MIME type to be resolved (it has to, to figure out the right 
thumbnailer plugin to query), and so even though no thumbnail has been 
generated, it might noe be possible to go from the generic icon to a proper 
MIME type icon (i.e. exactly what would happen if previews were off).

The patch proposed here does the following: When all outstanding preview jobs 
have finished, it loops over the still-pending items (i.e. that didn't actually 
get a preview generated) and adds those that had their MIME types resolved to 
the list the "previews off" codepath uses to track items that had their MIME 
types resolved. The dispatch method (that causes model change annoucements) is 
modified to always check this list even if previews are on.

This fixes awkard behavior in views, because determining the MIME type 
effectively causes the DecorationRole to change but this change isn't announced 
by the model via dataChanged(). With this patch, it is.


Diffs
-

  src/filewidgets/kfilepreviewgenerator.cpp 274bdf2 

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


Testing
---


Thanks,

Eike Hein

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

Re: Minimum translation percentage for frameworks release

2014-07-30 Thread Alexander Potashev 
2014-07-31 3:51 GMT+04:00 Aleix Pol :
> On Thu, Jul 31, 2014 at 1:36 AM, Alexander Potashev 
> wrote:
>>
>> But doing per-framework percentages is no bueno, either: imagine your
>> app uses KService and you translated only this framework having
>> skipped its dependencies. Then the app might be translated very poorly
>> if many strings come from the dependent frameworks.
>
> Read again what Albert said, he's not proposing to filter per framework.

Hi Aleix,

Correct - Albert's final idea was to let the downstream decide. I'm
almost sure that won't work well, specifically most distros will
probably include all translations we ship, even very incomplete ones
because
 1. Packagers won't find out soon they need to do this filtering (i.e.
they won't notice that we've turned off filtering on our side),
because they didn't need to with KDE SC 4.x,
 2. Packagers won't spent their time to write scripts for filtering
translations in some smart way.

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