[Bug 653623] Re: gvfs-gphoto2 eating 100% CPU and no I/O operations
This is not only 100% CPU usage, it is also a memory problem. It looks like the copy operation wants to acquire the whole file in memory during the copy. This is not a serous problem for normal pictures under 20MB, but I just gave up copying a 2GB MOV file from a Canon 7D to Ubuntus 10.04 using USB cable. The following path was shown in Nautilus: gphoto2://[usb:001,006]/DCIM/100EOS7D Related to this bug is that the limitation in when to show preview. When you disable preview for files over 50MB, this setting is ignores for files on the digi cam. This is a problem because the transfer rate is not fast, it takes 100% CPU and takes just as much memory as the size of the file processed for preview. The only way I found to avoid this, is to disable preview of other media altogether. Workaround appears to be to take out the CF anf stuff it directly into the computer. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to gvfs in ubuntu. https://bugs.launchpad.net/bugs/653623 Title: gvfs-gphoto2 eating 100% CPU and no I/O operations -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
Re: [Bug 50318] Re: manpage rendered wrong
If I use the GUI help on Ubuntu 10.04 (upgrade to), then you see the problem in the attached image. -- -=oOOo=- Carl Friis-Hansen http://carl-fh.com/ Phone: +46 372 15033 -=oOOo=- ** Attachment added: "Screenshot-KILL.png" https://bugs.launchpad.net/bugs/50318/+attachment/1691666/+files/Screenshot-KILL.png -- manpage rendered wrong https://bugs.launchpad.net/bugs/50318 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 13983] Re: Evolution virtual trash / "real" trash on IMAP server
A note about the directory structure. As you can see on the picture, the INBOX.Trash is not iconized as trash, but is actually showing the contents of the trash folder on the server. The Trash folder on the other hand, is icinized as trash, but is outside the structure of the INBOX and is not represented on the server and is the folder where Evu. presents the deleted mail. Delete in non Evu. client: INBOX.friends ---> INBOX.Trash Delete in Evu. client: INBOX.friends ---> local-machine.Trash ** Attachment added: "Directory tree image as reference to example" http://launchpadlibrarian.net/36291486/inbox-evolution.png -- Evolution virtual trash / "real" trash on IMAP server https://bugs.launchpad.net/bugs/13983 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 13983] Re: Evolution virtual trash / "real" trash on IMAP server
It is possible that I have misunderstood how Evu works, but one thing is for certain, you misunderstood the main point and I will tell this from a more practical point of view, something reproductive. If anyone wants to try it out, I will gladly open an email account just for the research, if we kan find some way of getting in direct contact with each other, like cfriisha at jabber dot org. Main point: After deleting mail in a sub folder, this mail appears in the Evu. Trash folder and not in the server side Trash folder. Behavior: Of all the mail clients I have used, only Evu. does deletion tis way. Reproduction scenario: IMAP server = courier on Ubuntu 9.04 IMAP client = Evolution 2.28.1 on Ubuntu 9.10 IMAP account = INBOX, INBOX.Drafts, INBOX.Sent, INBOX.Trash, INBOX.friends There are a lot more folders on the actual account, but the first four are the standard ones and then I included one of my extra folders. The steps: I receive a mail in my INBOX from f...@example.com which I read, close and drag to the INBOX.friends folder. Later I highlight the email from f...@example.com in the INBOX.friends and hit the Del key. The actual result: f...@example.com does not appear in INBOX.Trash but rather in Trash. My problem with this is that the folder Trash is not anywhere to find on the server, which suggests to me that Trash is a local folder. If I want to undelete f...@example.com I will have to do it from that particular Evu. client. The expected result: (As with any other client I have ever tried) f...@example.com appear in INBOX.Trash. and I can later recover that email from any client, anywhere, at any time. Why the difference: >From what I see Sebastien and Paul write, it appears that Evu. really does >mark the mail on the server as deleted, so could it be that things doesn't >work for me and the OP because of strange behavior of the Courier IMAP server, >which I would have thought was a rather common server? -- Evolution virtual trash / "real" trash on IMAP server https://bugs.launchpad.net/bugs/13983 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 13983] Re: Evolution virtual trash / "real" trash on IMAP server
For Delete message Evolution is using: IMAPv4 EXPUNGE Command instead of \Deleted flag set For search message Evolution is using: fetch all mail, inclusive body where apply, and do a local search (The POP3 way) instead of IMAPv4 SEARCH Command Here is a fresh example why it is a problem: -- Just lost over 800 deleted emails. I had borrowed a laptop with Ubuntu 9.10, configured my usual IMAP email account in Evolution. There where practical reasons for me not to use my Squirrel mail to the same IMAP account. After deleting some 800 messages and giving the laptop back, I found that the deleted messages where nowhere on the IMAP server. -- Using many different clients over the last 10 years, this is the first time I encounter an IMAP client that totally missed the Idea with Internet Message Access Protocol. Evolution should display a clear warning, that the application does not follow the standard of the IMAP protocol or they should correct the client ASAP. This disrespect has gone on since 2005 and has been deemed wishful thinking by the otherwise so great Evolution team. We can all have different ideas about how an email client should work, but to ignore the whole purpose of the IMAP protocol is not the best way and the proprietary delete and search implementation is also a security concern and massive misuse of Internet bandwidth. In todays IMAP the "Deleted" flag and the Search command are is to be used. Flags defined in the IMAP4 protocol serves to tell weather an email is deleted or not. The IMAP server will take care of presenting a deleted email as being in the Trash folder and the server will normally also take care of expunging deleted emails after for example 7 days or so. These flags are stored on the server, so different clients accessing the same mailbox at different times can detect state changes made by other clients. Sadly it is the same issue with *Server-side searches* that is *not* offered by Evolution. Some of us have more that 10,000 emails and need at times to search through the text body of *all* the messages. Such a search takes about 5 seconds when issuing a Server-side search and the only download are the headers of the result - perfect. Such a search is impossible in Evolution, which only provide a locally implemented search. Theoretically one could wait a day or too for Evolution to download all the email bodies, but how complicated can it be to implement a real Server-side search? Most other IMAP clients use the correct way of Deleting (and Searching). I think (guess) that the problem, seen from Evolutions' standpoint, is that everything is done correctly with respect to POP3 and that the different architecture need for full blown IMAP4rev1 functionality is problematic. So my recommendations is to clearly state, in the account definition, something like this: Server type:IMAP (Partly implemented) Description:For reading and storing mail on IMAP servers. Delete and Search act in POP3 style. Until such time the RFC 3501 is implemented regarding Delete and Search. Carl Friis-Hansen Reference: http://www.rfc-archive.org/getrfc.php?rfc=3501 -- Evolution virtual trash / "real" trash on IMAP server https://bugs.launchpad.net/bugs/13983 You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a direct subscriber. -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 50318] Re: manpage rendered wrong
yelp man:convert is not rendered so nicely. All the options are listed in one long stream, thus no line breaks. A snip: Image Settings: -adjoin join images into a single multi-image file -affine matrix affine transform matrix -antialias remove pixel-aliasing -authenticate value decrypt image with this password which looks almost okay here, but not in yelp. -- manpage rendered wrong https://bugs.launchpad.net/bugs/50318 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
