[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Review Request: Add "Open With" actions to KFileDialog context
From:       "David Faure" <faure () kde ! org>
Date:       2010-01-28 20:44:39
Message-ID: 20100128204439.23012.94571 () localhost
[Download RAW message or body]


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


One could wonder if the file dialog really needs to have "open with" menu items. \
After all this dialog is used to select a file (existing or to be created) for the \
current application, not for opening files into another application. It seems some \
users are starting to expect a mini-file-manager in there, which is not exactly what \
it is. Maybe the usability group could give their input about this.


/trunk/KDE/kdelibs/kfile/kdiroperator.cpp
<http://reviewboard.kde.org/r/2757/#comment3327>

    Where does it crash? This should be fixed, in any case.



/trunk/KDE/kdelibs/kfile/kdiroperator.cpp
<http://reviewboard.kde.org/r/2757/#comment3328>

    First reaction: kapp->applicationName() will crash if no kapp, you should use \
qApp instead, applicationName comes from there anyway.  
    But this isn't going to work in all cases, the desktop file and the app name \
could differ, e.g. kmail is in a KMail.desktop (case difference), and there are \
probably more cases... better than nothing, though, I guess.  
    One could use Exec != appName, but there again, the exec line could have \
additional arguments like -icon etc. It gets hairy.  
    We don't really have a way to find "the one .desktop file that runs this \
application", especially since there could be many (e.g. konqueror has 5 or so). \
Somehow for full perfection the string used here should be settable by the \
application. Could be overkill, though, at worst this app will appear in open with, \
no huge harm done.


- David


On 2010-01-28 20:32:37, Harsh J wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2757/
> -----------------------------------------------------------
> 
> (Updated 2010-01-28 20:32:37)
> 
> 
> Review request for kdelibs, Shaun Reich and David Faure.
> 
> 
> Summary
> -------
> 
> This patch proposes to use KFileItemActions class to add "Open With" actions to the \
> context menu of selected file(s) in KDirOperator (which is used by KFileDialog). 
> Some points on the implementation:
> * Added the action under the KDirOperator::FileActions flag
> * Made openWithActions (a KFileItemActions object) a member of the private KDO \
>                 class
> * Initialized the same object in setupActions() method
> 
> I suppose I must add something to KDirOperator::updatedSelectionDependentActions() \
> but I don't think its necessary as the selected items are retrieved while setting \
> up this menu itself. Would be better to add a reloader there just in case though. \
> Opinions please? 
> Also, is there a way to make the KDirOperator realize the name of the application \
> that's using it? I could use that to block itself out of the suggestions via the \
> traderConstraints. Doesn't look possible afaik. 
> 
> Diffs
> -----
> 
> /trunk/KDE/kdelibs/kfile/kdiroperator.cpp 1081124 
> 
> Diff: http://reviewboard.kde.org/r/2757/diff
> 
> 
> Testing
> -------
> 
> * Selected no items and right clicked - no submenu/separator shows.
> * Selected one item - Open With submenu and sometimes (in cases where only one can \
> open) preferred open with option shows.
> * Selected multiple items - Open With submenu and sometimes (in cases where only \
> one can open) preferred open with option shows.
> * Repeat above two with directories successfully shows the same.
> 
> 
> Screenshots
> -----------
> 
> Open With actions in KFileDialog
> http://reviewboard.kde.org/r/2757/s/305/
> 
> 
> Thanks,
> 
> Harsh
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]