Re: libkonq release? I'm missing the favicons interface

[Robby Stephenson]

On Sat, Feb 6, 2016 at 10:21 AM, David Faure  wrote:

> Unaware of this discussion (no time to read kde-devel), I have done exactly
> this during January. KIO (starting from 5.19) now has a KIOGui library
> with a
> FavIconRequestJob, which removes the dependency on the kded module
> provided by libkonq (I'll kill it soon, since it wasn't released).
> KIO::favIconForUrl(), which you mention in your mail, now uses the cache
> where FavIconRequestJob stores icons. Please port tellico to
> FavIconRequestJob and report any problems to me (or on the
> kde-frameworks-devel list, or in bugzilla).


FavIconRequestJob works great. I do see a behavioral regression in
KIconLoader::loadIcon(). In KDE4, the favicon icon name started with
"favicons/" and KIconLoader would use it as an overlay for a larger pixmap.
The code in KIconLoader::loadIcon() checks that the icon name starts with
"favicons/". With the current state, the icon name is an absolute path so
the overlay doesn't work.

> // Special case for absolute path icons.
> if (name.startsWith(QLatin1String("favicons/"))) {
>   favIconOverlay = true;
>   name =
QStandardPaths::writableLocation(QStandardPaths::GenericCacheLocation) +
'/' + name + ".png";
> }

Not a big deal at all and easy enough to compensate for. I'm not sure what
the appropriate fix is. Perhaps changing KIconLoader to check for an
absolute path that includes "favicons/" ?

Thanks again for FavIconRequestJob in 5.19, David.

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

Re: Review Request 126740: Add a script for optimizing svgs

[Aleix Pol Gonzalez]

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

(Updated Feb. 16, 2016, 3:02 a.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

Fixes the issues pointed out by Alexander Richardson, who seems to have a 
bash-fu over 9000.

Furthermore, it also includes a check to make sure that the generated file 
isn't too different to the new one (by rendering them with inkscape and 
comparing), if that's the case it leaves the tmp file and continues with the 
rest.


Repository: breeze-icons


Description
---

Dirk's review (https://git.reviewboard.kde.org/r/126738/) gave me the idea that 
right now we're serving right away the svg's from inkscape and there's room for 
improvement, potentially.

This patch just introduces a script that optimizes the svg's using `svgo`.

More could be done, like using gzip files, we can look into that if anyone's 
interested. In fact, we used to use svgz for the icons, I wonder why that 
changed. 

This will change the files in-place rather than as a build step, which is what 
I considered first. The process to run svgo on every file was about 30 minutes 
to 1h on my system, so I doubt it's really desirable.

A reduced file size is important because it will greatly reduce disk IO, which 
is a bottle-neck we have.


Diffs (updated)
-

  optimize.svg.sh PRE-CREATION 

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


Testing
---

```
kde-devel@oliver:~/frameworks/breeze-icons (master)$ du -sh icons icons-dark/
32M icons
32M icons-dark/

#run the script

kde-devel@oliver:~/frameworks/breeze-icons (master)$ du -sh icons icons-dark/
17M icons
17M icons-dark/
```


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 127060: Potentially fix 347962

[Aleix Pol Gonzalez]

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

(Updated Feb. 16, 2016, 1:17 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 24d27b9cb733f727431c64e0a7845c39152c1104 by Aleix Pol to 
branch master.


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


Repository: kdeclarative


Description
---

I couldn't reproduce, but that's what it looks like from the backtraces.


Diffs
-

  src/kdeclarative/qmlobject.cpp f3cee66 

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


Testing
---

Tests still pass.


Thanks,

Aleix Pol Gonzalez

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

Re: Review Request 127060: Potentially fix 347962

[David Edmundson]

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


Ship it!




see comment


src/kdeclarative/qmlobject.cpp (line 115)


You must be getting in here.

someone  probably has
setSource(findFile(pathThatDoesntExist));

I'd upgrade that to a warning, 
and you don't want your QPointer<> change.


- David Edmundson


On Feb. 13, 2016, 2:01 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127060/
> ---
> 
> (Updated Feb. 13, 2016, 2:01 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Bugs: 347962
> https://bugs.kde.org/show_bug.cgi?id=347962
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> I couldn't reproduce, but that's what it looks like from the backtraces.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/qmlobject.cpp f3cee66 
> 
> Diff: https://git.reviewboard.kde.org/r/127060/diff/
> 
> 
> Testing
> ---
> 
> Tests still pass.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Re: Review Request 127077: kio_http: read and discard body after a 404 with errorPage=false.

[David Faure]

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

(Updated Feb. 15, 2016, 9:17 p.m.)


Review request for KDE Frameworks, Dawit Alemayehu, Andreas Hartmetz, and Rolf 
Eike Beer.


Changes
---

Fix a bug where mimeType() was emitted twice when the error page had a content 
type set (and we are skipping the error page).


Repository: kio


Description
---

kio_http: read and discard body after a 404 with errorPage=false.

When getting a 404 error with some content, the job succeeds and returns content
(good for webbrowsers).
The metadata "errorPage" can be set to false so that the job fails instead
(useful for other cases, like favicon download, file copy etc.)
However the rest of the headers, as well as the body must still be read and
discarded, otherwise they clobber the next request (kio_http then starts
parsing in the middle of some headers and says "DO NOT WANT").

This is not a porting bug, I could reproduce it with kdelibs4 too.


Diffs (updated)
-

  autotests/http_jobtest.cpp PRE-CREATION 
  src/ioslaves/http/http.cpp e1013c8705e6588729d61ed45c43dc564415c41e 

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


Testing
---

Unittest.

Please review this patch carefully, I don't have much experience with this code 
in kio_http, and the potential for regressions in cases that I didn't test is 
likely high.


Thanks,

David Faure

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

Re: Review Request 126876: Fix QFileDialog::openUrl() for remote files

[Kåre Särs]

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

(Updated Feb. 15, 2016, 7:45 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Alex Richardson and David Faure.


Changes
---

Submitted with commit 5420b5752a30c294486fbaf967187c8a6f64fe42 by Kåre Särs to 
branch master.


Repository: frameworkintegration


Description
---

Qt does not know if the remote URL points to a file or directory. that is why 
options()->initialDirectory() returns the full URL even if it is a file.


This fix is a bit like Alex Richardson workaround in KIO 
(https://git.reviewboard.kde.org/r/126831/), but in frameworkintegration in 
stead (I did not see his/Your KIO fix before now...)

I check the remote url in setDirectory() because setDirectoy() is called from 
two places.


Diffs
-

  src/platformtheme/kdeplatformfiledialoghelper.cpp 11e7efb 

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


Testing
---

Kate now happily opens local and remote folders :)


File Attachments


firefox.desktop
  
https://git.reviewboard.kde.org/media/uploaded/files/2016/01/25/60c21962-396e-468e-add9-e7112c49d7ba__firefox.desktop


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 127079: fix uninitialised var

[Kai Uwe Broulik]

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




src/declarativeimports/platformcomponents/application_p.h (line 35)


We can't do this in Frameworks


- Kai Uwe Broulik


On Feb. 15, 2016, 5:23 nachm., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127079/
> ---
> 
> (Updated Feb. 15, 2016, 5:23 nachm.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Valgrind pointed this out whilst debugging something else.
> 
> (though I'm not sure what on the desktop creates an Application object)
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/platformcomponents/application_p.h 
> 8e690928c2a4a0d3da983cb385e50e0e9e9d66e9 
> 
> Diff: https://git.reviewboard.kde.org/r/127079/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

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

Review Request 127079: fix uninitialised var

[David Edmundson]

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

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

Valgrind pointed this out whilst debugging something else.

(though I'm not sure what on the desktop creates an Application object)


Diffs
-

  src/declarativeimports/platformcomponents/application_p.h 
8e690928c2a4a0d3da983cb385e50e0e9e9d66e9 

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


Testing
---


Thanks,

David Edmundson

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

Re: Review Request 127023: [KFileMetadata] Support Origin Email subject/sender/id

[Vishesh Handa]

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


Fix it, then Ship it!





src/propertyinfo.cpp (line 421)


I'm not too keen on indexing this unless there is a clear use case. It just 
increases the size of the index.

During the Nepomuk days we used to index and collect way too much 
information with the hope that we would be find amazing creative uses for the 
data. It did not end well.


- Vishesh Handa


On Feb. 9, 2016, 9:09 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127023/
> ---
> 
> (Updated Feb. 9, 2016, 9:09 p.m.)
> 
> 
> Review request for KDE Frameworks, KDEPIM, Daniel Vrátil, Sebastian Kügler, 
> and Vishesh Handa.
> 
> 
> Repository: kfilemetadata
> 
> 
> Description
> ---
> 
> This adds support for the user.xdg.origin.email.subject, 
> user.xdg.origin.email.sender, user.xdg.origin.email.message-id xattrs [1] to 
> KFileMetadata.
> 
> This can (should :P) be populated by KMail when you save an attachment.
> 
> Not too happy about the "displayName" I chose. Also we'll need to figure out 
> what to index and how we can relate this information and present it to the 
> user in a meaningful way. But at least let's collect the information first 
> and then we can think about ways to handle this.
> 
> [1] https://wiki.freedesktop.org/www/CommonExtendedAttributes/
> 
> 
> Diffs
> -
> 
>   src/properties.h 6ceaca5 
>   src/propertyinfo.cpp 4d1fac4 
>   src/usermetadata.h 9e10d2a 
>   src/usermetadata.cpp 5485d0e 
> 
> Diff: https://git.reviewboard.kde.org/r/127023/diff/
> 
> 
> Testing
> ---
> 
> Not really. Tests pass, though.
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

[Martin Gräßlin]

> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > Thanks for contributing the code, I'm very happy to see this happening! 
> > Sorry, that I cannot provide a good review as I'm not really into the OSX 
> > API, thus my review here might look a little bit nitpicky.
> > 
> > General comment: maybe rename the directory from "osx" to "cocoa"? After 
> > all it's more about the windowing system than the operating system.
> 
> René J.V. Bertin wrote:
> Nitpickyness is no problem here.
> 
> I have nothing against renaming the subdirectory, but it'd be something 
> I'd want to leave to the end, for convenience on my end. Also, we'd probably 
> want to remain consistent, or work toward consistency. Currently there are no 
> "cocoa" backend/plugin directories; 3 frameworks use "osx" and another uses 
> "mac". There is also the question to what extent "cocoa" still is and will 
> remain the most appropriate term in this context ... and there is the issue 
> of iOS where some frameworks might be deployed and which might or might not 
> require specific adaptations. (And I'm probably hardly more "into" the iOS 
> APIs as you are into the OS X APIs.)

sure, we can think about a more general approach to the naming. Having that 
standardized over all framework might make sense (assuming we never care about 
the difference between operating system and windowing system or it's always 
windowing system).


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, line 89
> > 
> >
> > Why is the define needed? Doesn't it make more sense to just not build 
> > the OSX backend if COCOA is disabled?
> 
> René J.V. Bertin wrote:
> That would require knowing the answer to that question in the CMake file; 
> I'd have to look into that. Is it trivial to do the equivalent of an `#ifdef 
> TOKEN` in a CMake file?

That should be defined in the cmake config for Qt5Gui. At least where I needed 
similar things in the past it was defined.


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, lines 331-342
> > 
> >
> > why support setting the current desktop if the number of desktops is 
> > hardcoded to 1?
> 
> René J.V. Bertin wrote:
> Is there an accepted way to include a kind of scrapbook with code 
> snippets that might be useful or "kinda work"?

good question. I don't know of one.


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, line 446
> > 
> >
> > what's experimental window tracking?
> > 
> > And that ifdef if enabled would not compile
> 
> René J.V. Bertin wrote:
> The whole EXPERIMENTAL_WINDOW_TRACKING feature is an experiment started 
> by someone who worked on this code before me. From what I understand, the 
> idea was to catch window creation and destruction events to maintain some 
> kind of internal database that would allow to implement a number of the 
> windowing features that aren't supported by the underlying layers. I don't 
> think the feature was ever completed, and it also uses deprecated APIs.
> 
> I left it in because I thought it could fuel more discussion about 
> whether or not such a feature could make sense to complete the feature set. 
> But it could probably play that same role when moved to the aforementioned 
> scrapbook or some other kind of "junk DNA" file.

the way it's currently I would highly recommend to remove it as it just cannot 
compile.


- Martin


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


On Feb. 14, 2016, 5:44 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126291/
> ---
> 
> (Updated Feb. 14, 2016, 5:44 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> KWindowSystem has been lacking a platform plugin for OS X. This RR presents a 
> "backport" of the modified KDE4 KWindowSystem implementation that has been 
> used in the MacPorts kdelibs4 port for the last 2 or 3 (or more) years.
> 
> I have made some initial steps to remove deprecated Carbon API calls, but 
> this is clearly a work in progress.
> 
> Open questions include
> - is there any justification to run an event handler (or Cocoa observer) to 
> keep track of running applications, possibly even listing all 

Re: Review Request 126291: initial implementation of a platform plugin for OS X (WIP)

[René J . V . Bertin]

> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > Thanks for contributing the code, I'm very happy to see this happening! 
> > Sorry, that I cannot provide a good review as I'm not really into the OSX 
> > API, thus my review here might look a little bit nitpicky.
> > 
> > General comment: maybe rename the directory from "osx" to "cocoa"? After 
> > all it's more about the windowing system than the operating system.

Nitpickyness is no problem here.

I have nothing against renaming the subdirectory, but it'd be something I'd 
want to leave to the end, for convenience on my end. Also, we'd probably want 
to remain consistent, or work toward consistency. Currently there are no 
"cocoa" backend/plugin directories; 3 frameworks use "osx" and another uses 
"mac". There is also the question to what extent "cocoa" still is and will 
remain the most appropriate term in this context ... and there is the issue of 
iOS where some frameworks might be deployed and which might or might not 
require specific adaptations. (And I'm probably hardly more "into" the iOS APIs 
as you are into the OS X APIs.)


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, line 89
> > 
> >
> > Why is the define needed? Doesn't it make more sense to just not build 
> > the OSX backend if COCOA is disabled?

That would require knowing the answer to that question in the CMake file; I'd 
have to look into that. Is it trivial to do the equivalent of an `#ifdef TOKEN` 
in a CMake file?


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, lines 111-113
> > 
> >
> > please no commented code

Will disappear from the final code, of course, but probably not as long as I 
still might need this kind of test probe ;)


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, lines 331-342
> > 
> >
> > why support setting the current desktop if the number of desktops is 
> > hardcoded to 1?

Is there an accepted way to include a kind of scrapbook with code snippets that 
might be useful or "kinda work"?


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, line 446
> > 
> >
> > what's experimental window tracking?
> > 
> > And that ifdef if enabled would not compile

The whole EXPERIMENTAL_WINDOW_TRACKING feature is an experiment started by 
someone who worked on this code before me. From what I understand, the idea was 
to catch window creation and destruction events to maintain some kind of 
internal database that would allow to implement a number of the windowing 
features that aren't supported by the underlying layers. I don't think the 
feature was ever completed, and it also uses deprecated APIs.

I left it in because I thought it could fuel more discussion about whether or 
not such a feature could make sense to complete the feature set. But it could 
probably play that same role when moved to the aforementioned scrapbook or some 
other kind of "junk DNA" file.


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, line 175
> > 
> >
> > Please use categorized logging. I suggest adding a new category for the 
> > OSX backend.

Roger.


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, lines 302-303
> > 
> >
> > then please remove the code

OK.


> On Feb. 15, 2016, 8:42 a.m., Martin Gräßlin wrote:
> > src/platforms/osx/kwindowsystem_macobjc.mm, line 447
> > 
> >
> > QObject()

Indeed.


- René J.V.


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


On Feb. 14, 2016, 5:44 p.m., René J.V. Bertin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126291/
> ---
> 
> (Updated Feb. 14, 2016, 5:44 p.m.)
> 
> 
> Review request for KDE Software on Mac OS X and KDE Frameworks.
> 
> 
> Repository: kwindowsystem
> 
> 
> Description
> ---
> 
> KWindowSystem has been lacking a platform plugin for OS X. This RR presents a 
> 

Re: Review Request 126876: Fix QFileDialog::openUrl() for remote files

[David Faure]

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


Ship it!




Yes in my opinion this is fine and in line with how KFileWidget already works.

I just realized that if we want to minimize the number of stat jobs, then maybe 
my suggestion to put this here was wrong, it will be easier to optimize it if 
we all do it together in KFileWidget rather than a bit here and a bit there. I 
wanted this "adaptation to the Qt API" not to clutter the KFileWidget API 
itself, but this could be done with a new KFileWidget::setFileOrDirectoryUrl() 
method (or something like that) that frameworkintegration calls. Anyway, can be 
done later if someone wants to tackle reducing the number of (blocking) stat 
jobs.

If setDirectory is called multiple times and if that can't be avoided, we might 
want to add a if (directory == m_directory) return; early return (with a new 
member var m_directory).

Anyhow, let's get this in, it already missed 5.19, further improvements can be 
done on top.

- David Faure


On Feb. 14, 2016, 6:25 a.m., Kåre Särs wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126876/
> ---
> 
> (Updated Feb. 14, 2016, 6:25 a.m.)
> 
> 
> Review request for KDE Frameworks, Alex Richardson and David Faure.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> Qt does not know if the remote URL points to a file or directory. that is why 
> options()->initialDirectory() returns the full URL even if it is a file.
> 
> 
> This fix is a bit like Alex Richardson workaround in KIO 
> (https://git.reviewboard.kde.org/r/126831/), but in frameworkintegration in 
> stead (I did not see his/Your KIO fix before now...)
> 
> I check the remote url in setDirectory() because setDirectoy() is called from 
> two places.
> 
> 
> Diffs
> -
> 
>   src/platformtheme/kdeplatformfiledialoghelper.cpp 11e7efb 
> 
> Diff: https://git.reviewboard.kde.org/r/126876/diff/
> 
> 
> Testing
> ---
> 
> Kate now happily opens local and remote folders :)
> 
> 
> File Attachments
> 
> 
> firefox.desktop
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/01/25/60c21962-396e-468e-add9-e7112c49d7ba__firefox.desktop
> 
> 
> 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 127004: WIP: OpenFileManagerWindowJob

[David Faure]

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




src/widgets/openfilemanagerwindowjob.cpp (line 107)


const QStringList urlsList = QUrl::toStringList(d->highlightUrls);



src/widgets/openfilemanagerwindowjob.cpp (line 117)


Looking at kstartupinfo.cpp, they are UTF-8. Although that code is probably 
broken in case gethostname returns something non latin1. I'll add a fromUtf8 
there.


- David Faure


On Feb. 7, 2016, 6:20 p.m., Kai Uwe Broulik wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127004/
> ---
> 
> (Updated Feb. 7, 2016, 6:20 p.m.)
> 
> 
> Review request for KDE Frameworks, Emmanuel Pescosta and Martin Gräßlin.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> This job uses the org.freedesktop.FileManager1 interface to highlight files 
> within a certain folder, useful for eg. downloaded files or a "open 
> containing folder" functionality.
> 
> 
> Diffs
> -
> 
>   src/widgets/CMakeLists.txt 87dac50 
>   src/widgets/openfilemanagerwindowjob.h PRE-CREATION 
>   src/widgets/openfilemanagerwindowjob.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/127004/diff/
> 
> 
> Testing
> ---
> 
> With Dolphin's org.freedesktop.FileManager1 service installed, I got a file 
> highlighted properly. Without it Dolphin opened the folder without 
> highlighting (KRun fallback).
> 
> Not sure what to do with the startup id stuff
> 
> 
> Thanks,
> 
> Kai Uwe Broulik
> 
>

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

Re: Review Request 127024: Don't filter names if we have mimetypes

[David Faure]

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


Ship it!




Ship It!

- David Faure


On Feb. 14, 2016, 11:31 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127024/
> ---
> 
> (Updated Feb. 14, 2016, 11:31 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> setMimeTypeFilters will call setNameFilter anyway, so we're not missing any 
> entries, on the other hand setMimeFilter will do some nice things using the 
> extra knowledge.
> 
> 
> Diffs
> -
> 
>   src/platformtheme/kdeplatformfiledialoghelper.cpp 11e7efb 
> 
> Diff: https://git.reviewboard.kde.org/r/127024/diff/
> 
> 
> Testing
> ---
> 
> Tested it while porting okular.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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