Re: Review Request 127823: Allow building without strigi on Linux

2016-07-18 Thread Nicolás Alvarez


> On July 17, 2016, 6:26 p.m., Antonio Rojas wrote:
> > Ping... can someone with the appropriate powers approve and commit this? 
> > All strigi packages are being removed from KDE Applications 16.08, would be 
> > great to have the dependency removed here too for the matching kdelibs 
> > release.
> 
> Albert Astals Cid wrote:
> That's really a bad excuse, since what we're not shipping anymore is the 
> analizers, that have nothing to do with this code, and you can/should still 
> ship the analizers for your kdelibs4 users from the old version.
> 
> Antonio Rojas wrote:
> We are not going to ship unmaintained software which is unsupported 
> upstream. And once we drop the analyzers, this is the only thing that 
> prevents us from dropping strigi.

Isn't Qt4 unmaintained software which is unsupported upstream? Why are you 
still shipping it?


- Nicolás


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


On May 3, 2016, 9:06 a.m., Antonio Rojas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127823/
> ---
> 
> (Updated May 3, 2016, 9:06 a.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Now that kde-workspace is obsolete and kdelibs is only used by some still 
> unported applications, it doesn't make sense to force using strigi anymore. 
> This will allow dropping this old unmaintained library from distributions.
> 
> 
> Diffs
> -
> 
>   CMakeLists.txt e7b2bea 
> 
> Diff: https://git.reviewboard.kde.org/r/127823/diff/
> 
> 
> Testing
> ---
> 
> Builds with and without strigi, everything seems to work
> 
> 
> Thanks,
> 
> Antonio Rojas
> 
>



Re: Review Request 128471: [kio] Some fixes for KNewFileMenu.

2016-07-18 Thread Chinmoy Ranjan Pradhan

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

(Updated July 18, 2016, 4:32 p.m.)


Review request for kdelibs and David Faure.


Changes
---

Sorry, the earlier description was a mess :P . Hope this ones' clear.
(*The bug i have mentioned was reported by someone couple of months ago and is 
not confirmed yet but i can still reproduce this bug on my system even after an 
upgrade*)


Repository: kio


Description (updated)
---

This patch fixes couple of issues with KNewFileMenu.

Fix 1: When creating a new file, if a file with the default name already exist 
then a new name is suggested by *KIO::suggestName*. Now this works fine until 
the scheme of file's url is "file" but in case the scheme is "desktop" (*like 
when the url in dolphin is set to desktop:/ or "Folder View Settings > 
Location" is set to desktop:/*) then the check for file's existence fails 
because *QFile::exists* doesn't understand the "desktop" scheme. So 
*KIO::suggestName* is not called and no new filename is suggested in case a 
file with the same filename already exist. To fix this i used 
*KNewFileMenuPrivate::mostLocalUrl* in *KNewFileFileMenu::executeRealFileorDir* 
which will resolve "desktop:/" to the user's desktop path. 

Fix 2: If a user tries to create a new file and proceeds with the default 
filename then the file created will have no extension. This happens (*inside 
KNewFileFileMenu::executeRealFileorDir*) because the filename is read from the 
*Name* section of the desktop file. To fix this, read the URL from the desktop 
file, determine the file extension from there and append it in the filename.

Fix 3: Fix for the bug https://bugs.kde.org/show_bug.cgi?id=363673 . The bug 
occurs because KPropertiesDialog is initialized (*inside 
KNewFileMenuPrivate::executeOtherDesktopFile*) with path of a resource file. 
Now KPropertiesDialog only show properties if the file is a local file(i 
guess). Thats why  clicking on "Link to Application" and then clicking 'ok' 
shows an error message . To Fix this i used QTemporaryFile to copy the contents 
of the application template shipped with kio and then initialize 
KPropertiesDialog with the temporary files' path.


Diffs (updated)
-

  src/filewidgets/knewfilemenu.cpp 2e613b1 

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


Testing
---


File Attachments (updated)


linktoapplication.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/07/18/d01841f8-08e3-4609-bd82-b54ea446cdf5__linktoapplication.png
errormessage.png
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/07/18/759ea00e-a65f-4dde-a05a-d297b63c2c1b__errormessage.png
no extension and no new filename
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/07/18/fbd04e13-c2d3-4acc-a4dc-b4a9053e2cb6__newfile.png
after_patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/07/18/6cbb3f10-9513-478b-a865-9fc791c006d5__linktoapplication_afterpatch.png
after_patch
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/07/18/2e9f5fa5-eaaa-4abc-a0ac-f492fb01faa3__newfile_aftepatch.png


Thanks,

Chinmoy Ranjan Pradhan