User-Agent: Opera/9.01 (X11; Linux i686; U; en) Build Identifier: build 22899 fails to show opendlg, no errors to terminal or in dmesg. trying to open location dlg returns immediately. Reproducible: Always Steps to Reproduce: 1.sync to cvs 22899; compile and install thunar and all dep pkgs here: http://www.xfce.org/index.php?page=documentation&lang=en 2.thunar 3.Go | Open location | Open Actual Results: returns imediately, no dlg , no mesg to terminal or dmesg Expected Results: file open dlg.
Your report is rather confusing. You are talking about the "Open Location" dialog? Or a "file open dlg" (which file open dlg)? Then, what are you trying to do? And what doesn't work exactly? Using your steps to reproduce - Go -> Open Location -> Open - does of course nothing because the folder that is preselected in the dialog is the current folder. Please try to be precise with bug reports.
OK, I see what is happening. It's just the interface I am finding rather confusing. Details you may like to think about while it's still in beta. I was expecting at some stage to get a full file open dlg like the gtk filechooser at some point. I was probably somewhat mislead in my expectations by the use of "Location": a file , a directory? It seems here it is either or both. My previous knowlege of this term is in the gtk filechoose where it seems to be used when entering a path to open a file. The icon on the open button reinforced my impression I was going to get a further dlg. In the context of the conditions I posted, "Open" effectively did nothing. Again this was confusing and gave me the impression something was supposed to happen and it was broken. Maybe the button should me greyed-out at this point. From what you say it's clear that all we get is a text input box. If this is simply a means to open a directory in the main window it is a complete duplication of the tree navigation and therefore redundant. This leads to the expectation that is does something different. In part it does, it allows to open files. I think it would be much clearer if the two functions were separated. Opening directories is already covered. Open Location would be clearer as Open file / View file / Open with / Execute program . This is well covered in the context menu but what happens when I hit Open button seems ill-defined. At least I get no indication of what will actually happen. Sorry if the original post was confusing , that was because _I was confused_. In a nutshell , I think it would be clearer if Open location only dealt with files and the actual action should be known in advance to the user. Thx.
changed title to better reflect issue, downgrade to enhancment.
I think you still may be a little confused. When you set your Location Selector to "Pathbar Style" or "Hidden", the "Open Location..." menu item does in fact bring up a dialog box. Since the toolbar provides an ever-present text entry, there is no need to bring up a dialog box when the toolbar is visible. Thunar simply gives focus to the text entry and highlights the entire path, which is, by the way, exactly the same behavior as Firefox's File->Open Location... menu option. The very idea of a file manager displaying a gtk filechooser to open a file is a bit silly. The Location dialog box/text entry provides a way to go straight to a file or directory without having to browse through the file system. There is no need to restrict it to files only.
Confused probably. I find the functionality of thunar excellent. I think I may soon adopt it as my main file manager. However I think the human interface needs some improvements. (which was the point of creating this bug report). I think there is a grave danger of mimicking one of windows big failures here: "open" is used universally to mean view, edit or EXECUTE. This is _bad_. It is one of the main ways a user can be tricked into executing (often malign) code instead of opening some file. I think it is essential to maintain a clear distinction on Linux. Windows does many things well, this is not one of them! To remidy this and make things clearer to the user I suggest splitting the functionality as follows: replace "Open location" with two entries, "Open directory" and "Open file". In the case of open file it could be dealt with in the same way as on the context menus. The single "Open" button is joined by two others : "Run" & "Open with..." If the file is executable run is enabled and the Open buttons greyed out. This makes it very clear what is happening. This is doubly important on linux where an executable can have any name (or extention, or no extention). I think this is very well designed on the context menus , it would be nice to have the same clarity here. Hope these thoughts are of use. best regards.
First of all Thunar is not Linux, and is not related to Linux in any way. Linux is just one of its supported platforms, just like Windows could be one. So comparing Linux and Windows in a Thunar related bug is really pointless, just like comparing file managers to operating systems doesn't make sense. ThunarPathEntry (the widget used for the manual entry of paths) supports both choosing folders as well as launching files, where "launch" means execute if executable otherwise open with preferred app, exactly like double-click on a file in the view, so it's exactly the same security risk as the double-click action. ThunarPathEntry also displays the mime icon for the file/folder, so unless a user is using a totally messed up icon theme, it's easy to distinguish between files and folders (the completion has folders sorted first, so that's even less a chance to accidently select a file). People would certainly be even more confused with "Open directory" and "Open file" actions. Sure one can add widgets all over the place, but as usability is the most important aspect of Thunar, that's not going to happen. You may want to update to revision 22920 and have a look at the latest UI changes. But unless there's a real security issue with the path entry (i.e. you can come up with a realistic use case where the path entry behavior introduces a security risk that is not seen in other places as well), the behavior will stay the same.
>>Linux is just one of its supported platforms, just like Windows could be one. >>So comparing Linux and Windows in a Thunar related bug is really pointless I beg you pardon for not regnising the cross platform mature of Thunar. However the comparison to malignant software using the ambiguity of "open" is not so pointless it seems. I just took a perl script and changed pl to jpg. Thunar duly changed it's icon made it look to the user like a jpeg image but "opening" it ran the script. It seems Thunar knows it is executable if I use the context menu and displays appropriate choices. It would avoid this danger (and for little effort in adding a couple of buttons) if the open dialogue was equally helpful. [as an aside I take little notice of icons in general since they are often cryptic or unclear.] Whether certain other WM/DMs that openly aim to imitate windows behaviour also do this is regrettable but somewhat irrelevant to Thunar. This "open" ambiuity is not native to Linux and maintaining a clear difference between data and code is obviously highly important. If Thunar can export this clarity to the other platforms it supports this would a commendable feature there too.
If you rename an executable shell/perl script to "test.jpg" (or whatever name), the file will be detected as JPEG image in Thunar (note that this has absolutely nothing to do with the location bar/dialog), and the user will not be allowed to execute the file even if the file has the +x bit set (atleast with recent shared mime info versions). It'll always open the default image viewer, no matter if you are double clicking the file, using the location bar/dialog, or whatever. This is a security feature in Thunar (actually in thunar-vfs and as such also for xfdesktop). If that doesn't work for you, your installation of shared mime info is probably rather outdated or you're using a different file manager. But whatever it is, this is by no means related to the location bar/dialog, but a general aspect of the file manager, and as such I'll resolve this to INVALID. If for some reason you're unable to reproduce the behavior described above, file a new bug report with steps to reproduce your problem and detailed versions of the related packages.
Hmm, I had not atticipated that it would behave differently run as user other than what is determined by system settings. The behaviour I was refering to happens as root. From what you say it seems this is in some way determined by mime-types rather than Thunar though. One undesirable side-effect of this that the permissions tab of properties misinforms to users. Viewing the file in question I see rwxr-xr-- yet permissions shows the group permissions as read only. I agree this has somewhat drifted off the orginal point although it seems your responce if more wontfix than invalid. There is ambiguity about what "open" actually means in the context of the open location dlg. That was my basic point and what the suggestions addressed. If you dont like the ideas that your privelege , it's your baby.
The permissions are displayed properly, because rwxr-xr-- means read-only for the group.
and x means execute. This is not displayed , as you may guess that is what I was trying to point out. Sorry if I could have been clearer. It seems the "program" permissions are hidden if not enabled generally , greyed out or some other positive indication would be clearer. Since clarity is the main aim of Thunar this may be worth considering. Accepting that an absence means x is turned off I reiterate the point that the permissions tab is inconsistant with the file permissions I indicated. This is an odd situation due to the security feature. User had x perms, can see it in the detailed file list perms column but permissions tab shows contradicting information. Maybe the "program" permission should be shown checked but with a note that it is disabled. (in a similar way to the note if displayed to root) This would be clear , consistant and explicative of the feature.
The "program" permissions are only visible for files types that can be executed (i.e. application/x-shellscript, application/x-executable, etc.), because everything else doesn't make sense (an executable option for jpg images would certainly confuse users). The file may of course be executable (and even displayed in the detailed list view as such), but Thunar does not allow to execute the file and hence there's no need to add a "program" permission widget to the properties dialog, whose sole purpose would then be to confuse the user.