[Bug 84226] Fast user switch applet causes high processor load
You have been subscribed to a public bug: Binary package hint: fast-user-switch-applet On Feisty, since a recent upgrade, the fast user switch applet causes 50% processor load on my AMD64 dual core when it is added to a gnome panel. ** Affects: fast-user-switch-applet (Ubuntu) Importance: Undecided Assignee: Ubuntu Desktop Bugs Status: Triaged -- Fast user switch applet causes high processor load https://bugs.launchpad.net/bugs/84226 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 137458] Inconsistency with Nautilus dragdrop and ACL
Public bug reported: Binary package hint: nautilus I am using Nautilus in connection with Eiciel for ACL support (what is the status of Nautilus' native ACL support anyways? I heard it should be there from GNOME 2.16 on...). When I copy a directory with files from a partition that was not mounted with acl support, file permissions differ depending on whether I do this copy operation from a shell (cp -r) or via DragDrop in Nautilus. In my oppinion, the file permissions via the shell command are more sensible. -- Permissions of the source directory (not mounted with ACL support) [EMAIL PROTECTED]:~$ getfacl . # file: . # owner: hb # group: hb user::rwx group::r-x other::r-x -- Permissions of the target directory (mounted with ACL support) [EMAIL PROTECTED]:~$ cd /var/pictures/ [EMAIL PROTECTED]:/var/pictures$ getfacl . # file: . # owner: root # group: pictures user::rwx group::rwx other::--- default:user::rwx default:group::rwx default:mask::rwx default:other::--- -- Permissions of a subdirectory and a file in the subdirectory of the target directory (mounted with ACL support) that has been copied via the shell [EMAIL PROTECTED]:/var/pictures$ getfacl copy_s #this is a directory # file: copy_s # owner: hb # group: pictures user::rwx group::rwx #effective:r-x mask::r-x other::--- default:user::rwx default:group::rwx default:mask::rwx default:other::--- [EMAIL PROTECTED]:/var/pictures$ getfacl copy_s/copy_s # this is a file # file: copy_s/copy_s # owner: hb # group: pictures user::rw- group::rwx #effective:r-- mask::r-- other::--- -- Permissions of a subdirectory and a file in the subdirectory of the target directory (mounted with ACL support) that has been copied via Nautilus DragDrop [EMAIL PROTECTED]:/var/pictures$ getfacl copy_n # file: copy_n # owner: hb # group: pictures user::rwx group::rwx #effective:r-x mask::r-x other::r-x default:user::rwx default:group::rwx default:mask::rwx default:other::--- [EMAIL PROTECTED]:/var/pictures$ getfacl copy_n/copy_n # file: copy_n/copy_n # owner: hb # group: pictures user::rw- group::rwx #effective:r-- mask::r-- other::r-- Note how the permissions of other differ. I very much prefer them the way the shell does it. Since Nautilus is granting unwanted read access for world, I am marking this bug as a security vulnerability. ** Affects: nautilus (Ubuntu) Importance: Undecided Status: New ** Visibility changed to: Public -- Inconsistency with Nautilus dragdrop and ACL https://bugs.launchpad.net/bugs/137458 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for nautilus in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 95853] Re: Add an option to get a confirmation dialog before deleting files in Nautilus
@kikl: Completely unrelated to whether it's a good idea to get undo dialogs/bars on moving to trash or not, Nautilus's trash display does indeed have poor usability. No deletion date grouping, sorting or even displaying. Also, one can't really know where the files are going to be restored to. That makes it hard to navigate or even use the trash, especially when it hasn't been emptied in a while. Also, even with clean trashes, there's no way to distinguish several files with identical names etc. I put together a small Python application to have a better view of the trash (Screenshot: http://img10.imageshack.us/img10/5161/bildschirmfoto1t.png). Gnome's base libraries make that pretty easy. Maybe it'd be good to have such a display in Nautilus, or maybe even standalone started from the trash applet. Anyways, although trash usability is clearly related, this seems to be orthogonal to this very bug report. -- Add an option to get a confirmation dialog before deleting files in Nautilus https://bugs.launchpad.net/bugs/95853 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 95853] Re: Delete file in Nautlus - no warning
I think Nautilus' behaviour is correct. The behaviour is by design, and the confirm_trash option is doing what it is supposed to do: Request confirmation for the non-revertable actions Delete Trash and Delete files, but not for the revertable Move to trash. And guys, please stop speaking for the users - 10 vocal guys on a bug tracker don't represent a majority of users. That being said, I agree that a cluebar with an Undo button might be a useful _enhancement_ to Nautilus. But this whole discussion also has a downside. Nautilus is not the only program which can move files to the trash, so that option would either make the desktop more inconsistent, or it would have to be implemented in all applications that can send files to the trash. There might be another option: It's easy to monitor the trash, and act upon trash-related events, no matter which application caused it (Python code for having notification bubbles on trashing stuff would probably not be longer than this very post). So this feature would maybe better be implemented outside Nautilus. Of course, there is already an application that does exactly this: The trash applet. So one possible solution would be to provide an option to make this one more noisy, and maybe provide a trashing-diary with undo buttons. -- Delete file in Nautlus - no warning https://bugs.launchpad.net/bugs/95853 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 152879] Re: Nautilus does not warn when deleting read-only files
The bug description reveals a misunderstanding of the permissions system. File creation and deletion are operations on the _containing directory_ and are affected by the permissions set on that directory. You can create and delete files if you have +w on the parent directory. File permissions, on the other hand, don't have any influence on that. As a consequence the statement You have to be the owner of the file to do this. is wrong, too. Try it: Create a file with permissions 400 and owner root in your home directory. You will be able to delete it even as a normal user. I repeat: This is not a bug, but the way unixoid permissions work. In addition, this behavior is completely consistent with the permission display in Nautilus when the show_advanced_permissions switch is off. Now, since that seems to be a common misunderstanding, the GNU project decided to add a warning for that special case to 'rm'. However, that is clearly an enhancement request, and not a bug. -- Nautilus does not warn when deleting read-only files https://bugs.launchpad.net/bugs/152879 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 95853] Re: Add an option to get a confirmation dialog before deleting files in Nautilus
Suppose that you have 1500+ items in your trash bin. You pressed DEL without noticing which file it was. A warning for every single move-to-trash operation to fix this problematic usecase is implementing a cruel workaround instead of fixing the issues (in this case trash view usability). In fact, current Nautilus git master has trashed-on column in list view, and (irrespective of the view) sorts the trashcan by reversed deletion date by default. So, the question Which file did I just delete is pretty simple to answer, no matter how many million files you have in your trashcan: It's the topmost. -- Add an option to get a confirmation dialog before deleting files in Nautilus https://bugs.launchpad.net/bugs/95853 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 600861] Re: path location bar of Nautilus doesn't appear by default when configured so in gconf-editor, and disappears on navigation
The always_use_location_entry gconf key does not determine whether the location bar is visible or not, it just toggles between breadcrumb navigation and text entry. The visibility itself is set by View - Location Bar. -- path location bar of Nautilus doesn't appear by default when configured so in gconf-editor, and disappears on navigation https://bugs.launchpad.net/bugs/600861 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to nautilus in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 95853] Re: Add an option to get a confirmation dialog before deleting files in Nautilus
The Wastebasket has no way to sort by deleted date. If it did, then this improvement would be a lot less urgent, IMHO Please read what I wrote. Quoting myself: In fact, current Nautilus git master has trashed-on column in list view, and (irrespective of the view) sorts the trashcan by reversed deletion date by default. So, as it landed in git master, it will be in one of the next releases. -- Add an option to get a confirmation dialog before deleting files in Nautilus https://bugs.launchpad.net/bugs/95853 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 306630] Re: nautilus should copy/move smarter (queue files)
@Walter_I In my oppinion, David Siegel's remark is absolutely correct, and you are wrong. It's not as simple as you put it. Whether or not copying in parallel takes significantly longer depends on a number of factors (is target and/or source on a slow network connection, am I copying from a CD or a SSD etc). Also, sometimes I want parallel copies even if they might be slower in total, to increase reactivity. Consider the following (exaggerated) use case: I am copying a DVD image to a remote host on a slow link. ETA: 17 hours. Now, 5 hours after I initiated the file transfer, I want to copy a 12 kB ini file from /etc/ to /srv/foo. In your proposed solution, I would have to wait 12 hours for it to arrive. You can't seriously think that this would be an improvement. I fully agree that Nautilus could be smarter during file transfer management, with a smarter queuing and priority management logic. David didn't claim that it was impossible (and neither do I), but it's not trivial to implement, and certainly not a paper cut. -- nautilus should copy/move smarter (queue files) https://bugs.launchpad.net/bugs/306630 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 306630] Re: nautilus should copy/move smarter (queue files)
@Darshaka Pathirana: How can you full ACK a statement that you oppose in your very next sentence? Walter proposed to ALWAYS queue files, which is definitely not a good idea. Do something more than just always process in parallel or always queue, be it to ask the user, have some smart logic or a mixture of the two, is what I wrote about, and is in any case not a trivial change. -- nautilus should copy/move smarter (queue files) https://bugs.launchpad.net/bugs/306630 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 137458] Re: Inconsistency with Nautilus dragdrop and ACL
Submitted upstream (Bug #504049 in GNOME bugzilla) -- Inconsistency with Nautilus dragdrop and ACL https://bugs.launchpad.net/bugs/137458 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug contact for nautilus in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 442078] Re: Buttons in Eclipse not working correctly with GTK+ 2.18.1-1
Ubuntu folks can't fix bugs in software that you download from eclipse.org or zend.org. It's up to them to fix the software they offer. The Eclipse package in the repo contains the workaround, and I don't see what else could possibly be done on Ubuntu's side. -- Buttons in Eclipse not working correctly with GTK+ 2.18.1-1 https://bugs.launchpad.net/bugs/442078 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gtk+2.0 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 442078] Re: Buttons in Eclipse not working correctly with GTK+ 2.18.1-1
Patrick: Your assumption is wrong to start with. The bug is not in GTK+, but in Eclipse. Starting from 2.18 on, GTK+ changed some of its internal behaviour (google for client side windows). This change is intentional, and needed for other development. It doesn't make any difference to programs using GTK+ correctly, but it makes problems with programs that use GTK+ in weird ways, making wrong assumptions that only accidentally worked in the past. So, to ease the transition until those programs get fixed, an environment variable has been introduced to simulate the old behaviour. So it's really up to the eclipse guys to fix their code, and to make sure they set this variable as a workaround until then in their own distribution. Ubuntu doesn't have any influence on that. The only possible workaround that could be done in Ubuntu was to set that variable globally by default. That may break (correctly working) apps, just in order to work around broken ups from 3rd party sources. Doesn't seem like a good idea to me. -- Buttons in Eclipse not working correctly with GTK+ 2.18.1-1 https://bugs.launchpad.net/bugs/442078 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gtk+2.0 in ubuntu. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
