Review Request: Factor out and reuse the code that guesses mime-type from filename

Dawit Alemayehu adawit at kde.org
Tue Jan 3 00:28:39 GMT 2012



> On Jan. 2, 2012, 10:50 p.m., David Faure wrote:
> > kparts/browseropenorsavequestion.cpp, line 287
> > <http://git.reviewboard.kde.org/r/103617/diff/1/?file=45307#file45307line287>
> >
> >     I don't get what this call changes, here (with no  filename passed to the method). It resolves aliases? But that doesn't matter for mime->is(...). So this seems superfluous.

Ahh... We no longer store the result of doing KMimeType::mimeType(...) in the constructor and hence we do it here again to get the mime-type pointer ? KMimeType::mimeType explicitly says not to store the returned value, but this class for some reason did just that. Or is it okay to ignore KMimeType::mimeType's documentation ?


> On Jan. 2, 2012, 10:50 p.m., David Faure wrote:
> > kparts/browseropenorsavequestion.cpp, line 336
> > <http://git.reviewboard.kde.org/r/103617/diff/1/?file=45307#file45307line336>
> >
> >     I'm not generally opposed to early returns, but this one seems dangerous. It's easy to overlook it when adding new unrelated code at the end of this method. I preferred the initial if().

That is just a habit. We already did this the first time around. :) I will return it the way it was.


> On Jan. 2, 2012, 10:50 p.m., David Faure wrote:
> > kparts/browseropenorsavequestion.cpp, line 343
> > <http://git.reviewboard.kde.org/r/103617/diff/1/?file=45307#file45307line343>
> >
> >     The " mime ? " test is superflous, this code is only run when mime is not null. Should be cleaned up -- unless the goal was to use the exact same code as the other similar setText line, but then this code should be factored out, rather than duplicated.
> >     
> >     
> >     
> >     This code change shows mimetype comments rather than mimetype names, too. That's fine I suppose, it's just missing from the overall description of this change. Don't forget it in the commit log ;)

My actual intent was to make both the ctor and setSuggestedFileName guess mime-types and display the results the same way. Unfortunately, in the process I got bitten by the usual copy/paste bug here. :) Fixed. For the record this one is supposed display the raw mime-type only when mime->comment() returns empty. :)

I will also update the commit log to reflect this change.


- Dawit


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


On Jan. 2, 2012, 8:41 p.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103617/
> -----------------------------------------------------------
> 
> (Updated Jan. 2, 2012, 8:41 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> -------
> 
> * Factored out the code that is used to determine the actual mime-type from either another mime-type or a filename.
> * Avoid storing the KMimeType::Ptr returned by KMimeType::mimeType as stated in its documentation.
> 
> 
> Diffs
> -----
> 
>   kparts/browseropenorsavequestion.cpp 092198f 
> 
> Diff: http://git.reviewboard.kde.org/r/103617/diff/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120103/0286148f/attachment.htm>


More information about the kde-core-devel mailing list