Re: Hunspell offering Hebrew by default

2011-12-02 Thread Kevin Kofler
Steven Sroka wrote:
> Why does Hunspell install the Hebrew dictionary by default? I'm
> running Chakra and I noticed that I had the option in System
> Settings->Locale->Spell Checker to use Hebrew even though I couldn't
> find a Hebrew package installed. Later I found out that the main
> Hunspell package offered the Hebrew dictionary.

I suspect that the Hebrew dictionary you're seeing is probably not from 
Hunspell, but from Hspell, which is Hebrew-specific. Hunspell does have a 
Hebrew dictionary available, but it is not installed by default.

Kevin Kofler



Review Request: Fix compilation error in nepomuk kioslave

2011-12-02 Thread Romário Rios

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

Review request for KDE Runtime.


Description
---

This patch fixes a compilation error on line 103 of file 
nepomuk/kioslaves/search/kdedmodule/searchurllistener.cpp (class 
Nepomuk::Resource has no member named resourceUri).


Diffs
-

  nepomuk/kioslaves/search/kdedmodule/searchurllistener.cpp 2333e38 

Diff: http://git.reviewboard.kde.org/r/103312/diff/diff


Testing
---

Now it compiles normally here and I don't see how this one-line could go wrong.


Thanks,

Romário Rios



Re: Review Request: Fix Date Display in dolphin info panel

2011-12-02 Thread Commit Hook

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103300/#review8663
---


This review has been submitted with commit 
21c198a312abcdf3bad0bc72c02f175f32b439b5 by Weng Xuetian to branch frameworks.

- Commit Hook


On Nov. 30, 2011, 9:17 p.m., Xuetian Weng wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103300/
> ---
> 
> (Updated Nov. 30, 2011, 9:17 p.m.)
> 
> 
> Review request for kdelibs and Nepomuk.
> 
> 
> Description
> ---
> 
> The date in dolphin info panel is passed by kfilemetadatareader directly. So 
> all the localization work should be done at the kfilemetadatareader side.
> There are two problems.
> 1. date given by nepomuk is stored as UTC time, needed to convert to 
> localtime.
> 2. date localization will not work without a KComponentData.
> 
> 
> Diffs
> -
> 
>   nepomuk/utils/utils.cpp e81615a 
>   kio/kfile/kfilemetadatareaderprocess.cpp 03ff887 
> 
> Diff: http://git.reviewboard.kde.org/r/103300/diff/diff
> 
> 
> Testing
> ---
> 
> Works for me.
> 
> 
> Thanks,
> 
> Xuetian Weng
> 
>



Re: Review Request: Proper password caching when opening remote directories in KFileDialog

2011-12-02 Thread Commit Hook

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103226/#review8664
---


This review has been submitted with commit 
b39253a8f907a999500068c89f340907b9c96094 by Dawit Alemayehu to branch 
frameworks.

- Commit Hook


On Nov. 30, 2011, 6:25 p.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103226/
> ---
> 
> (Updated Nov. 30, 2011, 6:25 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Description
> ---
> 
> The attached patch fixes the scenario outlined in bug# 179663 by making the 
> best effort to identify and use the top most window when invoking KIO 
> functions. That way any password information supplied by the user is cached, 
> even if the user did not check the "Remember password" checkbox, for the 
> duration of the application instead of just the lifetime of the file dialog. 
> 
> Right now almost all KFileDialog's KIO access does not set the widget 
> parameter. If a site then requires authentication, no window-id information 
> will be passed to it. That in turn results in the user supplied password 
> being cached for only a very very short duration, ~10 secs. Afterwards, the 
> password is removed and the user is inevitably re-prompted to supply the same 
> credentials again.
> 
> 
> This addresses bug 179663.
> http://bugs.kde.org/show_bug.cgi?id=179663
> 
> 
> Diffs
> -
> 
>   kio/kio/scheduler.cpp b4e95a5 
>   kfile/knewfilemenu.cpp ac54041 
>   kfile/kdirselectdialog.cpp 0212e58 
>   kfile/kfilewidget.cpp 09b86d4 
>   kfile/kdiroperator.cpp 4c93ac9 
> 
> Diff: http://git.reviewboard.kde.org/r/103226/diff/diff
> 
> 
> Testing
> ---
> 
> Tested with the scenario outlined in the afforementioned bug report using a 
> publicly available demo webdav server, webdav://demo.sabredav.org.
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>



Re: Review Request: Fix KDateComboBox shrinking in size after a date is entered

2011-12-02 Thread Commit Hook

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103133/#review8662
---


This review has been submitted with commit 
635c04f21fd0ae7ecefa12c365d665f4afcd0908 by David Jarvie to branch frameworks.

- Commit Hook


On Nov. 14, 2011, 10:58 p.m., David Jarvie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103133/
> ---
> 
> (Updated Nov. 14, 2011, 10:58 p.m.)
> 
> 
> Review request for kdelibs and John Layt.
> 
> 
> Description
> ---
> 
> After the user enters a date by means of the date picker or by up/down 
> arrows, the edit field in KDateComboBox shrinks so that it is too small to 
> display all the characters in the date. In addition, when first displayed, 
> the widget visibly resizes, which doesn't look particularly good. This patch 
> fixes these issues.
> 
> Note that the patch is really a workaround for the issue - I haven't managed 
> to find out exactly why the shrinkage occurs. However, it is a simple fix, so 
> unless somebody else comes up with a better way, I think it's good enough.
> 
> 
> Diffs
> -
> 
>   kdeui/widgets/kdatecombobox.cpp fc239bc 
> 
> Diff: http://git.reviewboard.kde.org/r/103133/diff/diff
> 
> 
> Testing
> ---
> 
> Tested successfully in KAlarm's alarm edit dialog.
> 
> 
> Thanks,
> 
> David Jarvie
> 
>



Re: Review Request: Add git support to kdesdk: create_tarball.rb

2011-12-02 Thread Thomas Baumgart


> On Nov. 30, 2011, 6:01 p.m., Thomas Baumgart wrote:
> > trunk/KDE/kdesdk/scripts/createtarball/create_tarball.rb, line 443
> > 
> >
> > Is there a specific reason why you don't add the doc subdirectory for 
> > stuff fetched from git?
> 
> Kåre Särs wrote:
> The git modules I have checked, have the non-translated documents in the 
> git repo and the directory already added in the CMakeLists.txt. I take it 
> that, that is the "standard" :) So the documentation should actually be built.

Apologies, you're right. KMyMoney is the culprit. We just did not update to the 
newer layout since we came into git from svn.


- Thomas


---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6842/#review10493
---


On Nov. 29, 2011, 4:42 p.m., Kåre Särs wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6842/
> ---
> 
> (Updated Nov. 29, 2011, 4:42 p.m.)
> 
> 
> Review request for kdelibs and Release Team.
> 
> 
> Description
> ---
> 
> This patch adds git support to create_tarball.rb in kdesdk. The patch adds 
> two options to the ini file. The first one (gitModule) indicates that the 
> module is located in git and the second optional parameter (gitTag) defines 
> which tag to use for creating the release. (there is no group for kdesdk or 
> extragear)
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdesdk/scripts/createtarball/config.ini 1266277 
>   trunk/KDE/kdesdk/scripts/createtarball/create_tarball.rb 1266277 
> 
> Diff: http://svn.reviewboard.kde.org/r/6842/diff/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kåre Särs
> 
>



Re: Hunspell offering Hebrew by default

2011-12-02 Thread Steven Sroka
>On 2 December 2011 18:46, Steven Sroka  wrote:
> Just a question here.
> Why does Hunspell install the Hebrew dictionary by default? I'm
> running Chakra and I noticed that I had the option in System
> Settings->Locale->Spell Checker to use Hebrew even though I couldn't
> find a Hebrew package installed. Later I found out that the main
> Hunspell package offered the Hebrew dictionary.
>
> I'm just wondering because it seems out of place for an english installation.

There's not much, but here is the bug report:
http://chakra-linux.org/bugs/index.php?do=details&task_id=375

>
> --
> Steven Sroka
> (lin-unix)



-- 
Steven Sroka
(lin-unix)


Hunspell offering Hebrew by default

2011-12-02 Thread Steven Sroka
Just a question here.
Why does Hunspell install the Hebrew dictionary by default? I'm
running Chakra and I noticed that I had the option in System
Settings->Locale->Spell Checker to use Hebrew even though I couldn't
find a Hebrew package installed. Later I found out that the main
Hunspell package offered the Hebrew dictionary.

I'm just wondering because it seems out of place for an english installation.

-- 
Steven Sroka
(lin-unix)


Re: Review Request: udev PortableMediaPlayer: read protocols from media-player-info; docs

2011-12-02 Thread Alex Fiestas

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103028/#review8653
---

Ship it!


I have asked in kde-core-devel if adding media player info as dependency is ok 
(kdelibs 4.X is freezed forever), and everybody said yes.

So for me, ship it once you've added the CMake warnings and remember to email 
the kde-packagers mailist.

Thanks and great work !

- Alex Fiestas


On Nov. 5, 2011, 4:47 p.m., Matěj Laitl wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103028/
> ---
> 
> (Updated Nov. 5, 2011, 4:47 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> This is a second attempt at implementing PortableMediaPlayer for udev
> back-end using media-player-info [3], the first attempt was [2] by
> Alex Merry and this patch is heavily based on it. This patch relates to
> a discussion at [1] and is just a first step, the second would
> be to forward PMP interface from udev backed to udisks backed somehow
> (udisks...Device interface provides NativePath attribute that links to
> sysfs path that can help - on Linux)
> 
> [1] http://mail.kde.org/pipermail/kde-hardware-devel/2011-October/001481.html
> [2] https://svn.reviewboard.kde.org/r/5853/
> [3] http://www.freedesktop.org/wiki/Software/media-player-info
> 
> Care is taken not to change existing behaviour - e.g. when udev env
> ID_MEDIA_PLAYER equals 1, behaviour is unchanged.
> 
> TODO: announce runtime-only media-player-info dependency for solid and
>   add it to build instructions. libmtp >= 1.0.4 is also needed at
>   runtime for detection of MTP devices to work. usbmuxd (dependency
>   of libimobiledevice) is needed at runtime for detection of Apple
>   iOS devices.
> TODO: what about windows support?
> 
> The patch is against kdelibs KDE/4.7 branch, please forward-port.
> 
> CCBUG: 253671  # does not solve it yet, but is a first step
> CCBUG: 269447
> CCBUG: 269451
> REVIEW: 103028
> DIGEST: groundwork for better media device player detection
> CCMAIL: amarok-de...@kde.org
> 
> 
> Diffs
> -
> 
>   solid/solid/CMakeLists.txt 1a4adfa 
>   solid/solid/backends/udev/udevdevice.cpp d6c7fb4 
>   solid/solid/backends/udev/udevmanager.cpp 55e655b 
>   solid/solid/backends/udev/udevportablemediaplayer.h e0348aa 
>   solid/solid/backends/udev/udevportablemediaplayer.cpp 32a1893 
>   solid/solid/ifaces/portablemediaplayer.h a73120a 
>   solid/solid/xdgbasedirs.cpp PRE-CREATION 
>   solid/solid/xdgbasedirs_p.h PRE-CREATION 
> 
> Diff: http://git.reviewboard.kde.org/r/103028/diff/diff
> 
> 
> Testing
> ---
> 
> 1. connect iPod
> 2. works:
> $ solid-hardware details 
> /org/kde/solid/udev/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc
> udi = 
> '/org/kde/solid/udev/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/host6/target6:0:0/6:0:0:0/block/sdc'
>   parent = '/org/kde/solid/udev'  (string)
>   vendor = 'Apple'  (string)
>   product = 'iPod'  (string)
>   description = 'Portable Media Player'  (string)
>   Block.major = 8  (0x8)  (int)
>   Block.minor = 32  (0x20)  (int)
>   Block.device = '/dev/sdc'  (string)
>   PortableMediaPlayer.supportedProtocols = {'storage', 'ipod'}  (string list)
>   PortableMediaPlayer.supportedDrivers = {'usb'}  (string list)
> 
> 3. not yet:
> $ solid-hardware details /org/freedesktop/UDisks/devices/sdc1
> udi = '/org/freedesktop/UDisks/devices/sdc1'
>   parent = '/org/freedesktop/UDisks/devices/sdc'  (string)
>   vendor = 'Apple'  (string)
>   product = 'MATOUSUV IP'  (string)
>   description = 'MATOUSUV IP'  (string)
>   Block.major = 8  (0x8)  (int)
>   Block.minor = 33  (0x21)  (int)
>   Block.device = '/dev/sdc1'  (string)
>   StorageAccess.accessible = true  (bool)
>   StorageAccess.filePath = '/media/MATOUSUV IP'  (string)
>   StorageAccess.ignored = false  (bool)
>   StorageVolume.ignored = false  (bool)
>   StorageVolume.usage = 'FileSystem'  (0x2)  (enum)
>   StorageVolume.fsType = 'vfat'  (string)
>   StorageVolume.label = 'MATOUSUV IP'  (string)
>   StorageVolume.uuid = '3141-5926'  (string)
>   StorageVolume.size = 7888957440  (0x1d637f000)  (qulonglong)
> 
> 
> Thanks,
> 
> Matěj Laitl
> 
>