Re: Review Request 127033: Add /../share/hunspell/ to dictionary search path

[David Faure]

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


Fix it, then Ship it!





src/plugins/hunspell/hunspelldict.cpp (line 48)


should be QFile::encodeName(QCoreApplication::applicationDirPath()), for 
symmetry.



src/plugins/hunspell/hunspelldict.cpp (line 63)


Simpler: dirPath.chop(1)

But wouldn't it be simpler to make "dic" not have a trailing slash, and add 
+'/' in the composeDictName function?


- David Faure


On Feb. 22, 2016, 8:59 p.m., Kåre Särs wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127033/
> ---
> 
> (Updated Feb. 22, 2016, 8:59 p.m.)
> 
> 
> Review request for KDE Frameworks, Laurent Montel and Martin Tobias Holmedahl 
> Sandsmark.
> 
> 
> Repository: sonnet
> 
> 
> Description
> ---
> 
> The default search path for hunspell dictionaries is /usr/share/hunspell/, 
> but that is not a very common directory on windows ;)
> 
> For Windows and Mac there are some extra search paths defined in side 
> #ifdefs, but they are hardcoded to the LibreOffice dictionary directories. 
> Unfortunately the extra Windows path points to a 32bit LibreOffice 5 on a 64 
> bit Windows directory. This patch adds /../share/hunspell/ to the 
> search path in case the default is not found. 
> 
> If wanted I can add a CMake define for specifying the path relative to the 
> application directory.
> 
> 
> Diffs
> -
> 
>   src/core/guesslanguage.cpp e8deb90 
>   src/plugins/hunspell/hunspellclient.cpp 3da7219 
>   src/plugins/hunspell/hunspelldict.cpp bc5c314 
> 
> Diff: https://git.reviewboard.kde.org/r/127033/diff/
> 
> 
> Testing
> ---
> 
> Compiled Sonnet and Kate on Windows and got spelling to work :)
> 
> It is now possible to add dictionaries to a relocatable  dir>/../share/hunspell/ and get spelling to work without depending on 
> LibreOffice installation on Windows.
> 
> 
> Thanks,
> 
> Kåre Särs
> 
>

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

Re: Review Request 127111: kurlnavigator: add new signal selectParentOfPreviousUrl

[Frank Reininghaus]

> On Feb. 20, 2016, 7:46 p.m., David Faure wrote:
> > src/filewidgets/kurlnavigator.h, line 428
> > 
> >
> > Signal names usually end with "ed", they reflect a state change or an 
> > action change.
> > 
> > "select" here is what you want the app to do (now that I read the bug 
> > report; otherwise it was very unclear just from the API docs), but you have 
> > no guarantee that the app will do that.
> > 
> > void urlChangedToParent(const QUrl &ancestorOfPreviousUrl)
> > 
> > ?
> > 
> > An alternative is to let the app do the "finding the immediate child" 
> > logic by just emitting
> > 
> > void urlChangedToParent(const QUrl &oldUrl, const QUrl &newUrl)
> > 
> > It seems to me that this is a better signal, because it's more generic. 
> > On the other hand, if you are afraid that multiple apps would then need to 
> > implement the "first child" logic, then this could be done by a helper 
> > method in this class. But at least the signal has a much more generic 
> > purpose than being geared towards this specific feature,
> > which increases the chances that it is useful for other things later.

I also thought first that something like urlChangedToParent(QUrl) would be a 
good signal name, but it might make people think that this signal will always 
be emitted when navigating from a URL to its (possibly indirect) parent.

However, this is not the case - the new signal will only be emitted if the URL 
change of the KUrlNavigator was triggered by a call of setLocationUrl(const 
QUrl&). If the URL change was caused by invoking the goBack() or goForward() 
slots, then the signal will not be emitted. The reason is that the user of 
KUrlNavigator will try to restore the view state (using the result from 
KUrlNavigator's locationState() function) then, and selecting any parents would 
interfere with that (see the discussion in 
https://git.reviewboard.kde.org/r/123253/ ).

So the idea is that the new signal is only emitted if no history action was 
responsible for the URL change. This makes it possible for Dolphin and other 
users of KUrlNavigator to behave like some other file managers, which also 
select the parent of the previous URL, unless the URL change was caused by 
back/forward. So anything with 'changed' is not really accurate, because a 
change is not sufficient to emit this signal.

Still, it might make sense to have an 'ed' in the name. 'requested' appears 
often in signals which are not so much about state changes, but have the 
purpose to make the receiver do something. How about

urlSelectionRequested(const QUrl &) ?


- Frank


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


On Feb. 18, 2016, 9:53 p.m., Gregor Mi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127111/
> ---
> 
> (Updated Feb. 18, 2016, 9:53 p.m.)
> 
> 
> Review request for Dolphin, KDE Frameworks, Emmanuel Pescosta, and Frank 
> Reininghaus.
> 
> 
> Bugs: 335616
> https://bugs.kde.org/show_bug.cgi?id=335616
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> Moved logic from https://git.reviewboard.kde.org/r/123253 to here.
> 
> Provides a signal to implement bug 
> https://bugs.kde.org/show_bug.cgi?id=335616: "Dolphin: Navigate to parent 
> folder selects child folder".
> 
> 
> Diffs
> -
> 
>   src/filewidgets/kurlnavigator.h 4ffe56acf9ef7a80ba27ba3a08327e363f98fb0d 
>   src/filewidgets/kurlnavigator.cpp 64d2a6d1d5cf8ca2e0aaa61d00ac1ffb1a9866b3 
>   src/filewidgets/urlutil.h PRE-CREATION 
>   tests/CMakeLists.txt dc88ce9fd5c5ae6ad135b72785370c0094969b5c 
>   tests/urlutiltest.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127111/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Gregor Mi
> 
>

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

Re: Review Request 127033: Add /../share/hunspell/ to dictionary search path

[Kåre Särs]

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

(Updated Feb. 22, 2016, 8:59 p.m.)


Review request for KDE Frameworks, Laurent Montel and Martin Tobias Holmedahl 
Sandsmark.


Changes
---

Add a static function to compose the dictionary name from the path and language
Use the static function
Replace QFileInfo(dic).exists() with QFileInfo::exists(dic)


Repository: sonnet


Description
---

The default search path for hunspell dictionaries is /usr/share/hunspell/, but 
that is not a very common directory on windows ;)

For Windows and Mac there are some extra search paths defined in side #ifdefs, 
but they are hardcoded to the LibreOffice dictionary directories. Unfortunately 
the extra Windows path points to a 32bit LibreOffice 5 on a 64 bit Windows 
directory. This patch adds /../share/hunspell/ to the search path in 
case the default is not found. 

If wanted I can add a CMake define for specifying the path relative to the 
application directory.


Diffs (updated)
-

  src/core/guesslanguage.cpp e8deb90 
  src/plugins/hunspell/hunspellclient.cpp 3da7219 
  src/plugins/hunspell/hunspelldict.cpp bc5c314 

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


Testing
---

Compiled Sonnet and Kate on Windows and got spelling to work :)

It is now possible to add dictionaries to a relocatable /../share/hunspell/ and get spelling to work without depending on 
LibreOffice installation on Windows.


Thanks,

Kåre Särs

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

Taking a (semi-)break

[Alex Merry]

Hi all,

A combination of a serious illness in the family and some of the heated 
discussions taking place on other KDE mailing lists has led to me 
burning out on the KDE front. As a result, I'm taking a step back (some 
of you may have noticed this already). I expect to get back into the 
swing of things when I've recovered my energy, but I don't know how long 
that will be.


The reason I'm telling you (mailing lists) this is that I maintain 
several frameworks, plus ECM. So far, I've just been keeping half an eye 
on review requests and skimming email subjects for things I think I 
should comment on. I can continue to do this, but it means that they are 
not getting the love I feel they deserve.


If anyone is willing to take over or share maintainership on any of 
these, let me/the list know. I'm more than happy to mentor someone in 
this role if they don't feel like jumping straight in the deep end 
without armbands.


For reference, this is what I currently maintain:

* extra-cmake-modules
* KApiDox
* KImageFormats
* KDesignerPlugin
* KMediaPlayer (part of Porting Aids)

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

Re: Review Request 127046: Move popup menu image actions into a submenu

[Jonathan Marten]

> On Feb. 12, 2016, 2:37 p.m., Thomas Pfeiffer wrote:
> > I wouldn't say that all actions for images are rarely used.
> > I don't see why viewing, copying or saving an image is less frequently done 
> > than the same things regarding the link. Can't we have those three still on 
> > the first level and then a "More..." option with further actions?
> 
> Jonathan Marten wrote:
> I wouldn't have said "rarely used":  certainly in my experience I use all 
> of these options occasionally, but nowhere near as often as "Open in new 
> tab", "Save link as", "Open with" etc.
> 
> Obviously any of the image options could appear at the top level instead 
> of in a submenu, but however they are arranged there will be dispute over 
> what should be where.  The only sensible options I can think of to satisfy 
> everyone would be "everything at top level" (as of now), or "everything in a 
> submenu" (which groups them all together, provides a place to show the name 
> of the image, and minimises the size of the menu).
> 
> Luigi Toscano wrote:
> What other browsers do?

Mozilla: has "View Image", "Copy Image", "Copy Image Location", (separator), 
"Save Image As", "Share this image", "Email Image", "Set as desktop 
background", "View Image Info".  Far too normal many IMHO, the menu height 
doubles over an image.

Chromium: has "Open image in new tab", "Save image as", "Copy image", "Copy 
image address", "Search Google for image".


- Jonathan


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


On Feb. 11, 2016, 6:18 p.m., Jonathan Marten wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127046/
> ---
> 
> (Updated Feb. 11, 2016, 6:18 p.m.)
> 
> 
> Review request for KDE Frameworks and KDE Usability.
> 
> 
> Repository: khtml
> 
> 
> Description
> ---
> 
> The popup menu over an image (with actions "Save Image As..." etcetera, see 
> screen shot) has in total 6 image actions which are not frequently used but 
> make the menu very long.  Moving these actions onto a submenu makes the top 
> level menu smaller and more logically grouped.
> 
> 
> Diffs
> -
> 
>   src/khtml_ext.cpp 0f522f4 
> 
> Diff: https://git.reviewboard.kde.org/r/127046/diff/
> 
> 
> Testing
> ---
> 
> Built KHTML with these changes, tested in Konqueror.
> 
> 
> File Attachments
> 
> 
> Popup menu before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/11/55c12311-73a3-472a-8a9a-6b6b9fce9de7__before.png
> Popup menu after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/11/313dbe3b-efb4-475c-bf76-8516f5bc85b4__after.png
> 
> 
> Thanks,
> 
> Jonathan Marten
> 
>

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

Re: Review Request 127046: Move popup menu image actions into a submenu

[Luigi Toscano]

> On Feb. 12, 2016, 3:37 p.m., Thomas Pfeiffer wrote:
> > I wouldn't say that all actions for images are rarely used.
> > I don't see why viewing, copying or saving an image is less frequently done 
> > than the same things regarding the link. Can't we have those three still on 
> > the first level and then a "More..." option with further actions?
> 
> Jonathan Marten wrote:
> I wouldn't have said "rarely used":  certainly in my experience I use all 
> of these options occasionally, but nowhere near as often as "Open in new 
> tab", "Save link as", "Open with" etc.
> 
> Obviously any of the image options could appear at the top level instead 
> of in a submenu, but however they are arranged there will be dispute over 
> what should be where.  The only sensible options I can think of to satisfy 
> everyone would be "everything at top level" (as of now), or "everything in a 
> submenu" (which groups them all together, provides a place to show the name 
> of the image, and minimises the size of the menu).

What other browsers do?


- Luigi


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


On Feb. 11, 2016, 7:18 p.m., Jonathan Marten wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127046/
> ---
> 
> (Updated Feb. 11, 2016, 7:18 p.m.)
> 
> 
> Review request for KDE Frameworks and KDE Usability.
> 
> 
> Repository: khtml
> 
> 
> Description
> ---
> 
> The popup menu over an image (with actions "Save Image As..." etcetera, see 
> screen shot) has in total 6 image actions which are not frequently used but 
> make the menu very long.  Moving these actions onto a submenu makes the top 
> level menu smaller and more logically grouped.
> 
> 
> Diffs
> -
> 
>   src/khtml_ext.cpp 0f522f4 
> 
> Diff: https://git.reviewboard.kde.org/r/127046/diff/
> 
> 
> Testing
> ---
> 
> Built KHTML with these changes, tested in Konqueror.
> 
> 
> File Attachments
> 
> 
> Popup menu before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/11/55c12311-73a3-472a-8a9a-6b6b9fce9de7__before.png
> Popup menu after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/11/313dbe3b-efb4-475c-bf76-8516f5bc85b4__after.png
> 
> 
> Thanks,
> 
> Jonathan Marten
> 
>

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

Re: Review Request 127046: Move popup menu image actions into a submenu

[Jonathan Marten]

> On Feb. 12, 2016, 2:37 p.m., Thomas Pfeiffer wrote:
> > I wouldn't say that all actions for images are rarely used.
> > I don't see why viewing, copying or saving an image is less frequently done 
> > than the same things regarding the link. Can't we have those three still on 
> > the first level and then a "More..." option with further actions?

I wouldn't have said "rarely used":  certainly in my experience I use all of 
these options occasionally, but nowhere near as often as "Open in new tab", 
"Save link as", "Open with" etc.

Obviously any of the image options could appear at the top level instead of in 
a submenu, but however they are arranged there will be dispute over what should 
be where.  The only sensible options I can think of to satisfy everyone would 
be "everything at top level" (as of now), or "everything in a submenu" (which 
groups them all together, provides a place to show the name of the image, and 
minimises the size of the menu).


- Jonathan


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


On Feb. 11, 2016, 6:18 p.m., Jonathan Marten wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127046/
> ---
> 
> (Updated Feb. 11, 2016, 6:18 p.m.)
> 
> 
> Review request for KDE Frameworks and KDE Usability.
> 
> 
> Repository: khtml
> 
> 
> Description
> ---
> 
> The popup menu over an image (with actions "Save Image As..." etcetera, see 
> screen shot) has in total 6 image actions which are not frequently used but 
> make the menu very long.  Moving these actions onto a submenu makes the top 
> level menu smaller and more logically grouped.
> 
> 
> Diffs
> -
> 
>   src/khtml_ext.cpp 0f522f4 
> 
> Diff: https://git.reviewboard.kde.org/r/127046/diff/
> 
> 
> Testing
> ---
> 
> Built KHTML with these changes, tested in Konqueror.
> 
> 
> File Attachments
> 
> 
> Popup menu before
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/11/55c12311-73a3-472a-8a9a-6b6b9fce9de7__before.png
> Popup menu after
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/11/313dbe3b-efb4-475c-bf76-8516f5bc85b4__after.png
> 
> 
> Thanks,
> 
> Jonathan Marten
> 
>

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

Re: Review Request 127142: Add a property indicating whether the models form a connected chain.

[Stephen Kelly]

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

(Updated Feb. 22, 2016, 4:33 p.m.)


Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

Replace existing asserts with a query and notification API.  This makes
the class more suitable for use in QML.


Diffs (updated)
-

  autotests/kmodelindexproxymappertest.cpp PRE-CREATION 
  src/kmodelindexproxymapper.h 9c4a63d7953ce3572cee47c5acc27f422c383f3b 
  src/kmodelindexproxymapper.cpp ae9e69a558f90bf498da730f96af773e3eb91901 

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


Testing
---


Thanks,

Stephen  Kelly

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

Re: Review Request 127147: KLinkItemSelectionModel: Make the linked selection model settable

[Stephen Kelly]

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

(Updated Feb. 22, 2016, 4:30 p.m.)


Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

KLinkItemSelectionModel: Make the linked selection model settable


Diffs (updated)
-

  autotests/klinkitemselectionmodeltest.h 
6e9c178cd99ed5479e2cee34492a8acd7e5a3f75 
  autotests/klinkitemselectionmodeltest.cpp 
74d72e4858dfd8bab48a71d260af86d838484d26 
  src/klinkitemselectionmodel.h c871121fa9a791b6030f5ff3a104d8d3bdcbe79d 
  src/klinkitemselectionmodel.cpp 1b676e87128d83586b62f94f9652b25111e766a5 

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


Testing
---


Thanks,

Stephen  Kelly

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

Re: Review Request 127148: KLinkItemSelectionModel: Add new default constructor.

[Stephen Kelly]

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

(Updated Feb. 22, 2016, 4:31 p.m.)


Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

Make it possible to construct this in QML


Diffs (updated)
-

  src/klinkitemselectionmodel.h c871121fa9a791b6030f5ff3a104d8d3bdcbe79d 
  src/klinkitemselectionmodel.cpp 1b676e87128d83586b62f94f9652b25111e766a5 

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


Testing
---


Thanks,

Stephen  Kelly

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

Re: Review Request 127145: KLinkItemSelectionModel: Don't store model locally

[Stephen Kelly]

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

(Updated Feb. 22, 2016, 4:30 p.m.)


Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

The model can be changed after the constructor is run as of Qt 5.5.

At this point, the KLinkItemSelectionModel would still break if that is
attempted, so a unit test comes later.


Diffs (updated)
-

  src/klinkitemselectionmodel.cpp 1b676e87128d83586b62f94f9652b25111e766a5 

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


Testing
---


Thanks,

Stephen  Kelly

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

Re: Review Request 127139: Add unit test for KModelIndexProxyMapper.

[Stephen Kelly]

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

(Updated Feb. 22, 2016, 4:28 p.m.)


Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

Add unit test for KModelIndexProxyMapper.


Diffs (updated)
-

  autotests/CMakeLists.txt 731b83b742acf5edb93ba1420845dbdd95751f74 
  autotests/kmodelindexproxymappertest.cpp PRE-CREATION 

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


Testing
---


Thanks,

Stephen  Kelly

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

Re: Review Request 127142: Add a property indicating whether the models form a connected chain.

[Kai Uwe Broulik]

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




src/kmodelindexproxymapper.cpp (lines 105 - 106)


Braces pls

Also, be careful when using range-for on non const Qt containers: 
http://www.dvratil.cz/2015/06/qt-containers-and-c11-range-based-loops/

I'm not sure whether we're allowed to use it in Frameworks, though.



src/kmodelindexproxymapper.cpp (lines 160 - 161)


Same line


- Kai Uwe Broulik


On Feb. 22, 2016, 3:34 nachm., Stephen  Kelly wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127142/
> ---
> 
> (Updated Feb. 22, 2016, 3:34 nachm.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kitemmodels
> 
> 
> Description
> ---
> 
> Replace existing asserts with a query and notification API.  This makes
> the class more suitable for use in QML.
> 
> 
> Diffs
> -
> 
>   autotests/kmodelindexproxymappertest.cpp PRE-CREATION 
>   src/kmodelindexproxymapper.h 9c4a63d7953ce3572cee47c5acc27f422c383f3b 
>   src/kmodelindexproxymapper.cpp ae9e69a558f90bf498da730f96af773e3eb91901 
> 
> Diff: https://git.reviewboard.kde.org/r/127142/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Stephen  Kelly
> 
>

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

Re: Review Request 127148: KLinkItemSelectionModel: Add new default constructor.

[Kai Uwe Broulik]

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




src/klinkitemselectionmodel.h (line 108)


explicit? Also, Q_NULLPTR



src/klinkitemselectionmodel.cpp (line 95)


We cannot use nullptr in Frameworks, use Q_NULLPTR


- Kai Uwe Broulik


On Feb. 22, 2016, 3:34 nachm., Stephen  Kelly wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127148/
> ---
> 
> (Updated Feb. 22, 2016, 3:34 nachm.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kitemmodels
> 
> 
> Description
> ---
> 
> Make it possible to construct this in QML
> 
> 
> Diffs
> -
> 
>   src/klinkitemselectionmodel.h c871121fa9a791b6030f5ff3a104d8d3bdcbe79d 
>   src/klinkitemselectionmodel.cpp 1b676e87128d83586b62f94f9652b25111e766a5 
> 
> Diff: https://git.reviewboard.kde.org/r/127148/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Stephen  Kelly
> 
>

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

Re: Review Request 127147: KLinkItemSelectionModel: Make the linked selection model settable

[Kai Uwe Broulik]

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



Bunch of coding style nitpicks.


src/klinkitemselectionmodel.h (lines 109 - 110)


Coding style: QItemSelectionModel *, space between name and asterisk



src/klinkitemselectionmodel.cpp (line 40)


Perhaps new connext syntax with lambda?



src/klinkitemselectionmodel.cpp (line 64)


Q_NULLPTR



src/klinkitemselectionmodel.cpp (line 82)


Coding style: no space after asterisk



src/klinkitemselectionmodel.cpp (lines 116 - 117)


Coding Style: Put on same line


- Kai Uwe Broulik


On Feb. 22, 2016, 3:34 nachm., Stephen  Kelly wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127147/
> ---
> 
> (Updated Feb. 22, 2016, 3:34 nachm.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kitemmodels
> 
> 
> Description
> ---
> 
> KLinkItemSelectionModel: Make the linked selection model settable
> 
> 
> Diffs
> -
> 
>   autotests/klinkitemselectionmodeltest.h 
> 6e9c178cd99ed5479e2cee34492a8acd7e5a3f75 
>   autotests/klinkitemselectionmodeltest.cpp 
> 74d72e4858dfd8bab48a71d260af86d838484d26 
>   src/klinkitemselectionmodel.h c871121fa9a791b6030f5ff3a104d8d3bdcbe79d 
>   src/klinkitemselectionmodel.cpp 1b676e87128d83586b62f94f9652b25111e766a5 
> 
> Diff: https://git.reviewboard.kde.org/r/127147/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Stephen  Kelly
> 
>

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

KItemModels review requests

[Stephen Kelly]

Hi,

I just pushed a bunch of reviewboard review requests for kitemmodels.

These have been reviewed by two colleagues here at Ableton. For your 
convenience you can find them as a git branch here:


 https://github.com/ske-ableton/kitemmodels/commits/master

I can of course rebase and merge these myself after review/shipit, but 
the reviews are useful to establish some sort of 'certificate of 
origin', ie, that it's coming from Ableton from a copyright POV, not 
from me.


Thanks,

Steve.

--
Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Management Board: Gerhard Behles, Jan Bohl
Chair of the Supervisory Board: Uwe Struck
Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838

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

Review Request 127144: KSelectionProxyModel: Fix iteration bug

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

Two bugs in one line of code.  This exists since the class was introduced, and
can result in an incomplete selection mapping, and strange behavior.


Diffs
-

  autotests/kselectionproxymodeltest.cpp 
b9f1277f1469970195dfb1fd0be68c6e8411fb23 
  src/kselectionproxymodel.cpp 428b849eedd0c4f187be30a5879b72e0df268c5a 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127140: KModelIndexProxyMapper: Add some asserts

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

KModelIndexProxyMapper: Add some asserts


Diffs
-

  src/kmodelindexproxymapper.cpp ae9e69a558f90bf498da730f96af773e3eb91901 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127139: Add unit test for KModelIndexProxyMapper.

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

Add unit test for KModelIndexProxyMapper.


Diffs
-

  autotests/CMakeLists.txt 731b83b742acf5edb93ba1420845dbdd95751f74 
  autotests/kmodelindexproxymappertest.cpp PRE-CREATION 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127142: Add a property indicating whether the models form a connected chain.

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

Replace existing asserts with a query and notification API.  This makes
the class more suitable for use in QML.


Diffs
-

  autotests/kmodelindexproxymappertest.cpp PRE-CREATION 
  src/kmodelindexproxymapper.h 9c4a63d7953ce3572cee47c5acc27f422c383f3b 
  src/kmodelindexproxymapper.cpp ae9e69a558f90bf498da730f96af773e3eb91901 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127141: KModelIndexProxyMapper: Simplify logic of connected check

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

KModelIndexProxyMapper: Simplify logic of connected check


Diffs
-

  src/kmodelindexproxymapper.cpp ae9e69a558f90bf498da730f96af773e3eb91901 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127145: KLinkItemSelectionModel: Don't store model locally

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

The model can be changed after the constructor is run as of Qt 5.5.

At this point, the KLinkItemSelectionModel would still break if that is
attempted, so a unit test comes later.


Diffs
-

  src/klinkitemselectionmodel.cpp 1b676e87128d83586b62f94f9652b25111e766a5 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127146: KLinkItemSelectionModel: Handle changes to the selectionModel model

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

KLinkItemSelectionModel: Handle changes to the selectionModel model


Diffs
-

  autotests/klinkitemselectionmodeltest.h 
6e9c178cd99ed5479e2cee34492a8acd7e5a3f75 
  autotests/klinkitemselectionmodeltest.cpp 
74d72e4858dfd8bab48a71d260af86d838484d26 
  src/klinkitemselectionmodel.cpp 1b676e87128d83586b62f94f9652b25111e766a5 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127143: Reset KSelectionProxyModel state when needed

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

When the model of the selectionModel is changed, it is necessary to
reset the proxy and clear any selection state.

This amends commit v5.9.0~5 (KSPM: Connect properly to the source model if it
is changed., 2015-03-12)


Diffs
-

  autotests/kselectionproxymodeltest.cpp 
b9f1277f1469970195dfb1fd0be68c6e8411fb23 
  src/kselectionproxymodel.cpp 428b849eedd0c4f187be30a5879b72e0df268c5a 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127148: KLinkItemSelectionModel: Add new default constructor.

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

Make it possible to construct this in QML


Diffs
-

  src/klinkitemselectionmodel.h c871121fa9a791b6030f5ff3a104d8d3bdcbe79d 
  src/klinkitemselectionmodel.cpp 1b676e87128d83586b62f94f9652b25111e766a5 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127147: KLinkItemSelectionModel: Make the linked selection model settable

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

KLinkItemSelectionModel: Make the linked selection model settable


Diffs
-

  autotests/klinkitemselectionmodeltest.h 
6e9c178cd99ed5479e2cee34492a8acd7e5a3f75 
  autotests/klinkitemselectionmodeltest.cpp 
74d72e4858dfd8bab48a71d260af86d838484d26 
  src/klinkitemselectionmodel.h c871121fa9a791b6030f5ff3a104d8d3bdcbe79d 
  src/klinkitemselectionmodel.cpp 1b676e87128d83586b62f94f9652b25111e766a5 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127149: KLinkItemSelectionModel: Test the effect of separate object network

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

Create, use and destroy an additional network of objects mapping selection
to verify the effect on the original selection.


Diffs
-

  autotests/klinkitemselectionmodeltest.h 
6e9c178cd99ed5479e2cee34492a8acd7e5a3f75 
  autotests/klinkitemselectionmodeltest.cpp 
74d72e4858dfd8bab48a71d260af86d838484d26 

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


Testing
---


Thanks,

Stephen  Kelly

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

Review Request 127150: KLinkItemSelectionModel: Test clearing the selection

[Stephen Kelly]

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

Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

KLinkItemSelectionModel: Test clearing the selection


Diffs
-

  autotests/klinkitemselectionmodeltest.h 
6e9c178cd99ed5479e2cee34492a8acd7e5a3f75 
  autotests/klinkitemselectionmodeltest.cpp 
74d72e4858dfd8bab48a71d260af86d838484d26 

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


Testing
---


Thanks,

Stephen  Kelly

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

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

[Albert Astals Cid]

> On feb. 22, 2016, 9:55 a.m., Albert Astals Cid wrote:
> > I'd prefer if you could fix this at the Qt level, why would 
> > nativeLanguageName ever return empty?
> 
> Andre Heinecke wrote:
> I've just checked. It's a Windows thing. qlocale_win calls windows API 
> getLocaleInfo(LOCALE_SNATIVELANGUAGENAME) ( 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dd373863%28v=vs.85%29.aspx
>  ). So Qt Developers would probably (and rightly) say "This is a Windows bug" 
> and Indeed this might be fixed at some point in the far Future in Windows.
> 
> But my Observation is Qt does not (and for Windows apparently can not) 
> guarantee that QLocale::nativeLanguageName is not Empty. So KXmlGui should 
> try to handle this. As I don't know how this is for other platforms and it 
> only adds a tiny overhead I also don't think this should be Ifdefed for 
> Windows.

well, reading the documentation of the function never mentions it can be empty, 
and given all languages probably have a way to call themselves I as an api user 
find it surprising it returns empty. 

sure I can agree it is a Windows bug, but why workaround it in every single 
call to nativeLanguageName instead of inside Qt code? 

I mean, we probably even have this problem in other KDE code.

And sure, Qt takes a while to update/release so temporarily we may want this 
workaround committed so our users get the fix earlier but I would really 
appreciate if you could create a MR for Qt that either documents that 
nativeLanguageName can return empty or one that makes sure it is not empty by 
doing the same fallback we do here.


- Albert


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


On feb. 22, 2016, 9:52 a.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> ---
> 
> (Updated feb. 22, 2016, 9:52 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there 
> were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
> Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as 
> a fallback. The idea is that a non native Name is better then no name (and a 
> blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I 
> think this fallback makes sense.
> 
> 
> Diffs
> -
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> ---
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and 
> after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> 
> 
> Dialog before the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

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

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

[Andre Heinecke]

> On Feb. 22, 2016, 9:55 a.m., Albert Astals Cid wrote:
> > I'd prefer if you could fix this at the Qt level, why would 
> > nativeLanguageName ever return empty?

I've just checked. It's a Windows thing. qlocale_win calls windows API 
getLocaleInfo(LOCALE_SNATIVELANGUAGENAME) ( 
https://msdn.microsoft.com/en-us/library/windows/desktop/dd373863%28v=vs.85%29.aspx
 ). So Qt Developers would probably (and rightly) say "This is a Windows bug" 
and Indeed this might be fixed at some point in the far Future in Windows.

But my Observation is Qt does not (and for Windows apparently can not) 
guarantee that QLocale::nativeLanguageName is not Empty. So KXmlGui should try 
to handle this. As I don't know how this is for other platforms and it only 
adds a tiny overhead I also don't think this should be Ifdefed for Windows.


- Andre


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


On Feb. 22, 2016, 9:52 a.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> ---
> 
> (Updated Feb. 22, 2016, 9:52 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there 
> were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
> Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as 
> a fallback. The idea is that a non native Name is better then no name (and a 
> blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I 
> think this fallback makes sense.
> 
> 
> Diffs
> -
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> ---
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and 
> after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> 
> 
> Dialog before the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

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

Re: Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

[Albert Astals Cid]

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



I'd prefer if you could fix this at the Qt level, why would nativeLanguageName 
ever return empty?

- Albert Astals Cid


On Feb. 22, 2016, 9:52 a.m., Andre Heinecke wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127136/
> ---
> 
> (Updated Feb. 22, 2016, 9:52 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kxmlgui
> 
> 
> Description
> ---
> 
> While packaging Kleopatra's translations for Gpg4win I've noticed that there 
> were blank entries in the Switchlanguagedialog.
> Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
> Windows).
> 
> This patch handles this and uses the non native QLocale::languageToString as 
> a fallback. The idea is that a non native Name is better then no name (and a 
> blank entry in the dialog) at all.
> 
> Ideally every language would have a native name but until this is the case I 
> think this fallback makes sense.
> 
> 
> Diffs
> -
> 
>   src/kswitchlanguagedialog_p.cpp 039daea 
> 
> Diff: https://git.reviewboard.kde.org/r/127136/diff/
> 
> 
> Testing
> ---
> 
> See attached screenshots of Kleopatra's switchlanguage dialog before and 
> after the patch. Low German is an example where the native name was empty.
> 
> 
> File Attachments
> 
> 
> Dialog before the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
> Dialog after the patch
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png
> 
> 
> Thanks,
> 
> Andre Heinecke
> 
>

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

Review Request 127136: XmlGui: Use non native Language name as fallback in KSwitchlangaugeDialog

[Andre Heinecke]

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

Review request for KDE Frameworks.


Repository: kxmlgui


Description
---

While packaging Kleopatra's translations for Gpg4win I've noticed that there 
were blank entries in the Switchlanguagedialog.
Apperantly QLocale::nativeLanguageName can return an Empty string (Qt 5.5 on 
Windows).

This patch handles this and uses the non native QLocale::languageToString as a 
fallback. The idea is that a non native Name is better then no name (and a 
blank entry in the dialog) at all.

Ideally every language would have a native name but until this is the case I 
think this fallback makes sense.


Diffs
-

  src/kswitchlanguagedialog_p.cpp 039daea 

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


Testing
---

See attached screenshots of Kleopatra's switchlanguage dialog before and after 
the patch. Low German is an example where the native name was empty.


File Attachments


Dialog before the patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/a6a31417-1ad6-432e-bee9-65a367fac28d__languages_before.png
Dialog after the patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/02/22/762062c5-ff18-47da-aeb0-93b16ca28883__languages_after.png


Thanks,

Andre Heinecke

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