[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
The status of this bug should really be set to high or critical, as Human should be considered broken by this. That Human didn't set out to replace every stock icon is not a good excuse, and this is why: 1) STOCK_OPEN and STOCK_DIRECTORY are very similar on the one hand, and often both will be used in the same application, so they should look similar. 2) On the other hand, they are *not* interchangeable semantically. If an application has a button that opens a folder, it will use STOCK_DIRECTORY. If an application has a button that opens a file, it will use STOCK_OPEN. This lack of interchangeability is especially true in the case of a gtk.Button(stock=STOCK_WHATEVER), where the application is also utilizing the internationalized text associated with the stock item. In this second case, something is really broken, as this screenshot shows. icon.set_from_stock() is at least working, despite not loading an icon that matches the theme. ** Attachment added: "Screenshot-stock_directory.py.png" http://librarian.launchpad.net/5286671/Screenshot-stock_directory.py.png -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
Here is a simple Python test script that demonstrates the problem, from which the screenshot was taken. ** Attachment added: "stock_directory.py" http://librarian.launchpad.net/5286684/stock_directory.py -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Tags added: hal -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Please retain state of Open > All Files / All Text Files
Public bug reported: Okay, maybe I'm one of very few who actually uses gedit for coding, but here's my workflow problem: 1) I need to open another source file, so I Open... 2) gedit nicely displays the contents of the last directory I've open anything from, which often contains several dozen source files. 3) But only on very rare occasions am I interested in a ".py~" file, and I've never felt the need to open a ".pyc" file, so I select "All Text Files" instead of "All Files" so I can more quickly find the ".py" file I'm looking for. 4) 53 seconds later, I feel the need to open some other ".py" file, but to my constant annoyance, gedit has reverted to "All Files", so I must select "All Text Files" again. 5) Repeat. I'm not much of a C hacker and am swamped with another project at the moment, so I wont be able fix this myself anytime soon. That being said, I know beggars can't be choosers, but here is my plea for how this should be implemented: At the very least the All Files / Text Files state should persist during a given session, but please don't bother doing it this way if you do anything at all: save it permanently with gconf key. Persistence of state always makes an application easier to learn and quicker to use. I also think that "All Text Files" should be the default. As gedit (or gtk or nautilus or whatever) obviously does something more intelligent than just check file extensions, I think that very seldom would gedit hide something that the user wished to open (for example, you can still open '/etc/network/interfaces' in the "Text Files" mode). Remember, novice users don't tend to be "power" users of text editors anyway. I'm not sure if this can be changed easily or is instead set in the gtk file chooser whatever widget, but please replace the ComboBox with two RadioButtons. It's silly to use a drop-down when there are only two options. It's better always to show the user the selected state and the alternate state. Lastly, I think this phrasing is clearer (for the English anyway): "Text Files Only" and "All Files". Again, please make "Text Files Only" the default. Thanks! Or maybe I'll have time to do it myself in the not so distant future. ;) ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62140] Pleave remove Insert (INS) / Overwrite (OVR) modes
Public bug reported: I must have tripped up onto my interface soapbox tonight... ;) So here is another gedit interface opinion: the Insert/ Overwrite modes should be removed and gedit should always behave as if it is in what was formerly known as the Insert mode. Here is my rational: 1) The INS/OVR mode is just that... a mode, always questionable if not bad in interface design, something which should never be included without a very good reason. 2) The INS/OVR mode is apparently totally worthless, certainly not passing the exception above. I've never found it even moderately useful to use OVR, nor have I ever observed anyone else doing so. If someone has a compelling case otherwise, I'm all ears. 3) On most keyboards, the INS key is near the HOME, END, PAGE UP, and PAGE DOWN keys, which are all used fairly frequently. I code with gedit, and it seems that at least a few times an hour I hit INS by mistake, type over a good number of characters that I did not intent to, realize that I'm now in *that* mode, and then waste time yell obscenities and correcting my mistake. 4) We can take a good lead from Apple who uses this key as something potentially useful: the HELP key. I think the INS/OVR modes are crufty leftovers anyway and not something people actually expect to be there, just something that annoys and confuses them if they switch to OVR by mistake. Firefox, which I'm writing this with, doesn't do any such nonsense... and I doubt anyone has ever complained about this lack of "functionality". Thanks! Happy hacking! ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Pleave remove Insert (INS) / Overwrite (OVR) modes https://launchpad.net/bugs/62140 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Re: Please retain state of Open > All Files / All Text Files
Although I would prefer Text Files Only to be the default, http://bugzilla.gnome.org/show_bug.cgi?id=329291 is a different bug than what I'm discussing here. Perhaps there are enough problems with the mime types that making Text Files the default isn't a good idea... but the real bug, in my opinion, is that the state the user has selected isn't retained. If this were fixed, I wouldn't particularly care what the default was because I could effectively set my own. -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54684] Re: High CPU usage
I'm experiencing the same problem using Thoggen under Edgy. It isn't necessary to hit refresh to trigger this. Simply opening nautilus to a directory containing a file that is being updated, and then immediately closing the nautilus window or changing to anther directory (like home) does the same thing... the CPU usage will shoot up to near 100% and will stay there till the process is killed (with "killall nautilus" or the like). -- High CPU usage https://launchpad.net/bugs/54684 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Seek on DVD not performed relative to title
Public bug reported: I'm running under Edgy, using gstreamer0.10-plugins- ugly-0.10.4-0ubuntu3. With totem-gstreamer, if I do something like this: totem dvd://2 And then seek, I will get bumped back into title 1. Also, if I do a large seek (say 30 minutes or more), sometimes totem will hang and never complete the seek. I know this isn't a totem bug because I have the exact results with the player in the gstreamer-based DVD ripper I've been developing. Thanks! ** Affects: gst-plugins-ugly0.10 (Ubuntu) Importance: Undecided Status: Unconfirmed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've filed an upstream bug about this: http://bugzilla.gnome.org/show_bug.cgi?id=372797 I know what the problem is and am working on a patch. I'd don't know quite how the updates policy works for universe... will it be possible to get a fix for this into Edgy? -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've submitted a patch for this upstream, but it was written starting from what was in cvs. http://bugzilla.gnome.org/show_bug.cgi?id=372797 I'll test a patch for Edgy and then submit that too. -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
After reading https://wiki.ubuntu.com/StableReleaseUpdates I expect that this is not a fix that would be allowed into Edgy anyway, but I'll still put a patch together. After working on the dvdreadsrc element quite a bit, I started to become frustrated with its readability problems and general cruftiness, so I've started a rewrite from scratch. I have the code for my new element in a Bazaar repository at https://launchpad.net/people/jderose/+branch/kungfu/dvdsrc My new dvdsrc element is now mostly usable as a drop-in replacement for dvdreadsrc. Currently I'm trying to decide whether it makes sense to combine the functionality of dvdnavsrc and dvdreadsrc. My feeling is that is probably does make sense, and so I'm planing to add Nav support to my new element. My goal is to trying to get this finished in time to get it into Feisty, so that full DVD functionality is available under gstreamer0.10. I could definitely use help on this, if anyone is interested! -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Here is the patch. In summary, it: * Fixes gst_dvd_read_src_get_sector_from_time(). Now only the correct tmap is used instead of the silly iteration through all tmaps in the title_set. * Fixes title starts at sector zero assumption in gst_dvd_read_src_goto_sector(). * Fixes title starts at sector zero assumption gst_dvd_read_src_goto_chapter(). I've testing this under Totem, Thoggen, and KungFu, and have found no regressions. ** Attachment added: "Fixes "Seek on DVD not performed relative to title"" http://librarian.launchpad.net/5240232/02_dvd-seek-fix.patch -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Oh, the patch also: * Improves gst_dvd_read_src_get_time_for_sector(), which now only iterates through the correct tmap instead of every tmap in the title_set. My gstreamer bug report has all sorts of details about my progress on this bug, some of which was wrong at first, but here is the most important bit: """ Again, the big problem with dvdreadsrc currently is that it doesn't properly handle cases where the title_set has more than one title. Here's a summary of how things work with libdvdread, as far as I understand: * The title number is mapped to the title_set number with tt_srpt->title[title].title_set_nr * For feature movies, the feature title is usually the only title in its title_set, which is why dvdreadsrc generally worked. But for, say, TV serials with several episodes per DVD, all the episodes usually belong to a single title_set, including the "play all" title that many DVDs have. In these cases, dvdreadsrc is "super extra broken". * ifoOpen and DVDOpenFile take the title_set_nr as an argument; they always open a title_set, not a single title (although as above, for movies the feature title is usually the only title in the title_set). * DVDReadBlocks works relative to the title_set, not the title. A wrong assumption made in many places in dvdreadsrc is that a title always starts at sector zero. In fact, it seems this assumption can't even be made for a title_set with one title. * cell_playback[cell].first_sector and cell_playback[cell].last_sector are relative to the title_set, not the title. This is why, by chance anyway, a multi-title title_set would at least start playing the correct title for title > 1. * If a title_set has a vts_tmapt, it will have exactly one tmap per title in the title_set. As far as I can tell, (tt_srpt->title[title].vts_ttn - 1) gives the index for the correct tmap for the title, but I need someone to verify this. (** After testing this on lots of DVDs, I'm now very confident that this is correct. **) * The times in the tmap are best dealt with relative to the title (which is what we want to do), but the sectors in tmap.map_ent[] are relative to the title_set. This "just works" as long as you are using the correct tmap. In this respect, gst_dvd_read_src_get_sector_from_time() was horibly broken. The original author(s) thought a nested iteration through vts_tmapt->tmap[i].map_ent[j] would somehow give the correct sector, which is utterly wrong, not to mention silly. It seems they got the idea from ifoPrint_VTS_TMAPT(), but didn't take the time to understand the meaning of the data structures. This is part of the reason why seeking is so broken. """ -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
** Changed in: gst-plugins-ugly0.10 (Ubuntu) Assignee: (unassigned) => Jason Gerard DeRose ** Changed in: gst-plugins-ugly0.10 (Ubuntu) Status: Unconfirmed => Fix Committed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Attachment added: "Python test script that demonstrates this bug." http://librarian.launchpad.net/5251721/hal_test.py -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Missing mandatory properties on volume.disc
Public bug reported: I'm running under Edgy, hal 0.5.7.1-0ubuntu17. Some mandatory volume.disc properties aren't availably for some discs. In particular, is_vcd, is_svcd, and is_videodvd are missing for blank CDR discs, audio CDs, and probably others that I haven't tested yet. Here are some examples: Blank CDR: volume.disc.type = cd_r volume.disc.has_audio = False volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = True volume.disc.is_rewritable = False Audio CD: volume.disc.type = cd_rom volume.disc.has_audio = True volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False Video DVD: volume.disc.type = dvd_rom volume.disc.has_audio = False volume.disc.has_data = True volume.disc.is_vcd = False volume.disc.is_svcd = False volume.disc.is_videodvd = True volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False ** Affects: hal (Ubuntu) Importance: Undecided Status: Unconfirmed -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54684] Re: High CPU usage
I'm experiencing the same problem using Thoggen under Edgy. It isn't necessary to hit refresh to trigger this. Simply opening nautilus to a directory containing a file that is being updated, and then immediately closing the nautilus window or changing to anther directory (like home) does the same thing... the CPU usage will shoot up to near 100% and will stay there till the process is killed (with "killall nautilus" or the like). -- High CPU usage https://launchpad.net/bugs/54684 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Seek on DVD not performed relative to title
Public bug reported: I'm running under Edgy, using gstreamer0.10-plugins- ugly-0.10.4-0ubuntu3. With totem-gstreamer, if I do something like this: totem dvd://2 And then seek, I will get bumped back into title 1. Also, if I do a large seek (say 30 minutes or more), sometimes totem will hang and never complete the seek. I know this isn't a totem bug because I have the exact results with the player in the gstreamer-based DVD ripper I've been developing. Thanks! ** Affects: gst-plugins-ugly0.10 (Ubuntu) Importance: Undecided Status: Unconfirmed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've filed an upstream bug about this: http://bugzilla.gnome.org/show_bug.cgi?id=372797 I know what the problem is and am working on a patch. I'd don't know quite how the updates policy works for universe... will it be possible to get a fix for this into Edgy? -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've submitted a patch for this upstream, but it was written starting from what was in cvs. http://bugzilla.gnome.org/show_bug.cgi?id=372797 I'll test a patch for Edgy and then submit that too. -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
After reading https://wiki.ubuntu.com/StableReleaseUpdates I expect that this is not a fix that would be allowed into Edgy anyway, but I'll still put a patch together. After working on the dvdreadsrc element quite a bit, I started to become frustrated with its readability problems and general cruftiness, so I've started a rewrite from scratch. I have the code for my new element in a Bazaar repository at https://launchpad.net/people/jderose/+branch/kungfu/dvdsrc My new dvdsrc element is now mostly usable as a drop-in replacement for dvdreadsrc. Currently I'm trying to decide whether it makes sense to combine the functionality of dvdnavsrc and dvdreadsrc. My feeling is that is probably does make sense, and so I'm planing to add Nav support to my new element. My goal is to trying to get this finished in time to get it into Feisty, so that full DVD functionality is available under gstreamer0.10. I could definitely use help on this, if anyone is interested! -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Here is the patch. In summary, it: * Fixes gst_dvd_read_src_get_sector_from_time(). Now only the correct tmap is used instead of the silly iteration through all tmaps in the title_set. * Fixes title starts at sector zero assumption in gst_dvd_read_src_goto_sector(). * Fixes title starts at sector zero assumption gst_dvd_read_src_goto_chapter(). I've testing this under Totem, Thoggen, and KungFu, and have found no regressions. ** Attachment added: "Fixes "Seek on DVD not performed relative to title"" http://librarian.launchpad.net/5240232/02_dvd-seek-fix.patch -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Oh, the patch also: * Improves gst_dvd_read_src_get_time_for_sector(), which now only iterates through the correct tmap instead of every tmap in the title_set. My gstreamer bug report has all sorts of details about my progress on this bug, some of which was wrong at first, but here is the most important bit: """ Again, the big problem with dvdreadsrc currently is that it doesn't properly handle cases where the title_set has more than one title. Here's a summary of how things work with libdvdread, as far as I understand: * The title number is mapped to the title_set number with tt_srpt->title[title].title_set_nr * For feature movies, the feature title is usually the only title in its title_set, which is why dvdreadsrc generally worked. But for, say, TV serials with several episodes per DVD, all the episodes usually belong to a single title_set, including the "play all" title that many DVDs have. In these cases, dvdreadsrc is "super extra broken". * ifoOpen and DVDOpenFile take the title_set_nr as an argument; they always open a title_set, not a single title (although as above, for movies the feature title is usually the only title in the title_set). * DVDReadBlocks works relative to the title_set, not the title. A wrong assumption made in many places in dvdreadsrc is that a title always starts at sector zero. In fact, it seems this assumption can't even be made for a title_set with one title. * cell_playback[cell].first_sector and cell_playback[cell].last_sector are relative to the title_set, not the title. This is why, by chance anyway, a multi-title title_set would at least start playing the correct title for title > 1. * If a title_set has a vts_tmapt, it will have exactly one tmap per title in the title_set. As far as I can tell, (tt_srpt->title[title].vts_ttn - 1) gives the index for the correct tmap for the title, but I need someone to verify this. (** After testing this on lots of DVDs, I'm now very confident that this is correct. **) * The times in the tmap are best dealt with relative to the title (which is what we want to do), but the sectors in tmap.map_ent[] are relative to the title_set. This "just works" as long as you are using the correct tmap. In this respect, gst_dvd_read_src_get_sector_from_time() was horibly broken. The original author(s) thought a nested iteration through vts_tmapt->tmap[i].map_ent[j] would somehow give the correct sector, which is utterly wrong, not to mention silly. It seems they got the idea from ifoPrint_VTS_TMAPT(), but didn't take the time to understand the meaning of the data structures. This is part of the reason why seeking is so broken. """ -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
** Changed in: gst-plugins-ugly0.10 (Ubuntu) Assignee: (unassigned) => Jason Gerard DeRose ** Changed in: gst-plugins-ugly0.10 (Ubuntu) Status: Unconfirmed => Fix Committed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Attachment added: "Python test script that demonstrates this bug." http://librarian.launchpad.net/5251721/hal_test.py -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Missing mandatory properties on volume.disc
Public bug reported: I'm running under Edgy, hal 0.5.7.1-0ubuntu17. Some mandatory volume.disc properties aren't availably for some discs. In particular, is_vcd, is_svcd, and is_videodvd are missing for blank CDR discs, audio CDs, and probably others that I haven't tested yet. Here are some examples: Blank CDR: volume.disc.type = cd_r volume.disc.has_audio = False volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = True volume.disc.is_rewritable = False Audio CD: volume.disc.type = cd_rom volume.disc.has_audio = True volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False Video DVD: volume.disc.type = dvd_rom volume.disc.has_audio = False volume.disc.has_data = True volume.disc.is_vcd = False volume.disc.is_svcd = False volume.disc.is_videodvd = True volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False ** Affects: hal (Ubuntu) Importance: Undecided Status: Unconfirmed -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
The status of this bug should really be set to high or critical, as Human should be considered broken by this. That Human didn't set out to replace every stock icon is not a good excuse, and this is why: 1) STOCK_OPEN and STOCK_DIRECTORY are very similar on the one hand, and often both will be used in the same application, so they should look similar. 2) On the other hand, they are *not* interchangeable semantically. If an application has a button that opens a folder, it will use STOCK_DIRECTORY. If an application has a button that opens a file, it will use STOCK_OPEN. This lack of interchangeability is especially true in the case of a gtk.Button(stock=STOCK_WHATEVER), where the application is also utilizing the internationalized text associated with the stock item. In this second case, something is really broken, as this screenshot shows. icon.set_from_stock() is at least working, despite not loading an icon that matches the theme. ** Attachment added: "Screenshot-stock_directory.py.png" http://librarian.launchpad.net/5286671/Screenshot-stock_directory.py.png -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
Here is a simple Python test script that demonstrates the problem, from which the screenshot was taken. ** Attachment added: "stock_directory.py" http://librarian.launchpad.net/5286684/stock_directory.py -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Tags added: hal -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Please retain state of Open > All Files / All Text Files
Public bug reported: Okay, maybe I'm one of very few who actually uses gedit for coding, but here's my workflow problem: 1) I need to open another source file, so I Open... 2) gedit nicely displays the contents of the last directory I've open anything from, which often contains several dozen source files. 3) But only on very rare occasions am I interested in a ".py~" file, and I've never felt the need to open a ".pyc" file, so I select "All Text Files" instead of "All Files" so I can more quickly find the ".py" file I'm looking for. 4) 53 seconds later, I feel the need to open some other ".py" file, but to my constant annoyance, gedit has reverted to "All Files", so I must select "All Text Files" again. 5) Repeat. I'm not much of a C hacker and am swamped with another project at the moment, so I wont be able fix this myself anytime soon. That being said, I know beggars can't be choosers, but here is my plea for how this should be implemented: At the very least the All Files / Text Files state should persist during a given session, but please don't bother doing it this way if you do anything at all: save it permanently with gconf key. Persistence of state always makes an application easier to learn and quicker to use. I also think that "All Text Files" should be the default. As gedit (or gtk or nautilus or whatever) obviously does something more intelligent than just check file extensions, I think that very seldom would gedit hide something that the user wished to open (for example, you can still open '/etc/network/interfaces' in the "Text Files" mode). Remember, novice users don't tend to be "power" users of text editors anyway. I'm not sure if this can be changed easily or is instead set in the gtk file chooser whatever widget, but please replace the ComboBox with two RadioButtons. It's silly to use a drop-down when there are only two options. It's better always to show the user the selected state and the alternate state. Lastly, I think this phrasing is clearer (for the English anyway): "Text Files Only" and "All Files". Again, please make "Text Files Only" the default. Thanks! Or maybe I'll have time to do it myself in the not so distant future. ;) ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62140] Pleave remove Insert (INS) / Overwrite (OVR) modes
Public bug reported: I must have tripped up onto my interface soapbox tonight... ;) So here is another gedit interface opinion: the Insert/ Overwrite modes should be removed and gedit should always behave as if it is in what was formerly known as the Insert mode. Here is my rational: 1) The INS/OVR mode is just that... a mode, always questionable if not bad in interface design, something which should never be included without a very good reason. 2) The INS/OVR mode is apparently totally worthless, certainly not passing the exception above. I've never found it even moderately useful to use OVR, nor have I ever observed anyone else doing so. If someone has a compelling case otherwise, I'm all ears. 3) On most keyboards, the INS key is near the HOME, END, PAGE UP, and PAGE DOWN keys, which are all used fairly frequently. I code with gedit, and it seems that at least a few times an hour I hit INS by mistake, type over a good number of characters that I did not intent to, realize that I'm now in *that* mode, and then waste time yell obscenities and correcting my mistake. 4) We can take a good lead from Apple who uses this key as something potentially useful: the HELP key. I think the INS/OVR modes are crufty leftovers anyway and not something people actually expect to be there, just something that annoys and confuses them if they switch to OVR by mistake. Firefox, which I'm writing this with, doesn't do any such nonsense... and I doubt anyone has ever complained about this lack of "functionality". Thanks! Happy hacking! ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Pleave remove Insert (INS) / Overwrite (OVR) modes https://launchpad.net/bugs/62140 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Re: Please retain state of Open > All Files / All Text Files
Although I would prefer Text Files Only to be the default, http://bugzilla.gnome.org/show_bug.cgi?id=329291 is a different bug than what I'm discussing here. Perhaps there are enough problems with the mime types that making Text Files the default isn't a good idea... but the real bug, in my opinion, is that the state the user has selected isn't retained. If this were fixed, I wouldn't particularly care what the default was because I could effectively set my own. -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54684] Re: High CPU usage
I'm experiencing the same problem using Thoggen under Edgy. It isn't necessary to hit refresh to trigger this. Simply opening nautilus to a directory containing a file that is being updated, and then immediately closing the nautilus window or changing to anther directory (like home) does the same thing... the CPU usage will shoot up to near 100% and will stay there till the process is killed (with "killall nautilus" or the like). -- High CPU usage https://launchpad.net/bugs/54684 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Seek on DVD not performed relative to title
Public bug reported: I'm running under Edgy, using gstreamer0.10-plugins- ugly-0.10.4-0ubuntu3. With totem-gstreamer, if I do something like this: totem dvd://2 And then seek, I will get bumped back into title 1. Also, if I do a large seek (say 30 minutes or more), sometimes totem will hang and never complete the seek. I know this isn't a totem bug because I have the exact results with the player in the gstreamer-based DVD ripper I've been developing. Thanks! ** Affects: gst-plugins-ugly0.10 (Ubuntu) Importance: Undecided Status: Unconfirmed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've filed an upstream bug about this: http://bugzilla.gnome.org/show_bug.cgi?id=372797 I know what the problem is and am working on a patch. I'd don't know quite how the updates policy works for universe... will it be possible to get a fix for this into Edgy? -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've submitted a patch for this upstream, but it was written starting from what was in cvs. http://bugzilla.gnome.org/show_bug.cgi?id=372797 I'll test a patch for Edgy and then submit that too. -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
After reading https://wiki.ubuntu.com/StableReleaseUpdates I expect that this is not a fix that would be allowed into Edgy anyway, but I'll still put a patch together. After working on the dvdreadsrc element quite a bit, I started to become frustrated with its readability problems and general cruftiness, so I've started a rewrite from scratch. I have the code for my new element in a Bazaar repository at https://launchpad.net/people/jderose/+branch/kungfu/dvdsrc My new dvdsrc element is now mostly usable as a drop-in replacement for dvdreadsrc. Currently I'm trying to decide whether it makes sense to combine the functionality of dvdnavsrc and dvdreadsrc. My feeling is that is probably does make sense, and so I'm planing to add Nav support to my new element. My goal is to trying to get this finished in time to get it into Feisty, so that full DVD functionality is available under gstreamer0.10. I could definitely use help on this, if anyone is interested! -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Here is the patch. In summary, it: * Fixes gst_dvd_read_src_get_sector_from_time(). Now only the correct tmap is used instead of the silly iteration through all tmaps in the title_set. * Fixes title starts at sector zero assumption in gst_dvd_read_src_goto_sector(). * Fixes title starts at sector zero assumption gst_dvd_read_src_goto_chapter(). I've testing this under Totem, Thoggen, and KungFu, and have found no regressions. ** Attachment added: "Fixes "Seek on DVD not performed relative to title"" http://librarian.launchpad.net/5240232/02_dvd-seek-fix.patch -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Oh, the patch also: * Improves gst_dvd_read_src_get_time_for_sector(), which now only iterates through the correct tmap instead of every tmap in the title_set. My gstreamer bug report has all sorts of details about my progress on this bug, some of which was wrong at first, but here is the most important bit: """ Again, the big problem with dvdreadsrc currently is that it doesn't properly handle cases where the title_set has more than one title. Here's a summary of how things work with libdvdread, as far as I understand: * The title number is mapped to the title_set number with tt_srpt->title[title].title_set_nr * For feature movies, the feature title is usually the only title in its title_set, which is why dvdreadsrc generally worked. But for, say, TV serials with several episodes per DVD, all the episodes usually belong to a single title_set, including the "play all" title that many DVDs have. In these cases, dvdreadsrc is "super extra broken". * ifoOpen and DVDOpenFile take the title_set_nr as an argument; they always open a title_set, not a single title (although as above, for movies the feature title is usually the only title in the title_set). * DVDReadBlocks works relative to the title_set, not the title. A wrong assumption made in many places in dvdreadsrc is that a title always starts at sector zero. In fact, it seems this assumption can't even be made for a title_set with one title. * cell_playback[cell].first_sector and cell_playback[cell].last_sector are relative to the title_set, not the title. This is why, by chance anyway, a multi-title title_set would at least start playing the correct title for title > 1. * If a title_set has a vts_tmapt, it will have exactly one tmap per title in the title_set. As far as I can tell, (tt_srpt->title[title].vts_ttn - 1) gives the index for the correct tmap for the title, but I need someone to verify this. (** After testing this on lots of DVDs, I'm now very confident that this is correct. **) * The times in the tmap are best dealt with relative to the title (which is what we want to do), but the sectors in tmap.map_ent[] are relative to the title_set. This "just works" as long as you are using the correct tmap. In this respect, gst_dvd_read_src_get_sector_from_time() was horibly broken. The original author(s) thought a nested iteration through vts_tmapt->tmap[i].map_ent[j] would somehow give the correct sector, which is utterly wrong, not to mention silly. It seems they got the idea from ifoPrint_VTS_TMAPT(), but didn't take the time to understand the meaning of the data structures. This is part of the reason why seeking is so broken. """ -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
** Changed in: gst-plugins-ugly0.10 (Ubuntu) Assignee: (unassigned) => Jason Gerard DeRose ** Changed in: gst-plugins-ugly0.10 (Ubuntu) Status: Unconfirmed => Fix Committed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Attachment added: "Python test script that demonstrates this bug." http://librarian.launchpad.net/5251721/hal_test.py -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Missing mandatory properties on volume.disc
Public bug reported: I'm running under Edgy, hal 0.5.7.1-0ubuntu17. Some mandatory volume.disc properties aren't availably for some discs. In particular, is_vcd, is_svcd, and is_videodvd are missing for blank CDR discs, audio CDs, and probably others that I haven't tested yet. Here are some examples: Blank CDR: volume.disc.type = cd_r volume.disc.has_audio = False volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = True volume.disc.is_rewritable = False Audio CD: volume.disc.type = cd_rom volume.disc.has_audio = True volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False Video DVD: volume.disc.type = dvd_rom volume.disc.has_audio = False volume.disc.has_data = True volume.disc.is_vcd = False volume.disc.is_svcd = False volume.disc.is_videodvd = True volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False ** Affects: hal (Ubuntu) Importance: Undecided Status: Unconfirmed -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
The status of this bug should really be set to high or critical, as Human should be considered broken by this. That Human didn't set out to replace every stock icon is not a good excuse, and this is why: 1) STOCK_OPEN and STOCK_DIRECTORY are very similar on the one hand, and often both will be used in the same application, so they should look similar. 2) On the other hand, they are *not* interchangeable semantically. If an application has a button that opens a folder, it will use STOCK_DIRECTORY. If an application has a button that opens a file, it will use STOCK_OPEN. This lack of interchangeability is especially true in the case of a gtk.Button(stock=STOCK_WHATEVER), where the application is also utilizing the internationalized text associated with the stock item. In this second case, something is really broken, as this screenshot shows. icon.set_from_stock() is at least working, despite not loading an icon that matches the theme. ** Attachment added: "Screenshot-stock_directory.py.png" http://librarian.launchpad.net/5286671/Screenshot-stock_directory.py.png -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
Here is a simple Python test script that demonstrates the problem, from which the screenshot was taken. ** Attachment added: "stock_directory.py" http://librarian.launchpad.net/5286684/stock_directory.py -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Tags added: hal -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Please retain state of Open > All Files / All Text Files
Public bug reported: Okay, maybe I'm one of very few who actually uses gedit for coding, but here's my workflow problem: 1) I need to open another source file, so I Open... 2) gedit nicely displays the contents of the last directory I've open anything from, which often contains several dozen source files. 3) But only on very rare occasions am I interested in a ".py~" file, and I've never felt the need to open a ".pyc" file, so I select "All Text Files" instead of "All Files" so I can more quickly find the ".py" file I'm looking for. 4) 53 seconds later, I feel the need to open some other ".py" file, but to my constant annoyance, gedit has reverted to "All Files", so I must select "All Text Files" again. 5) Repeat. I'm not much of a C hacker and am swamped with another project at the moment, so I wont be able fix this myself anytime soon. That being said, I know beggars can't be choosers, but here is my plea for how this should be implemented: At the very least the All Files / Text Files state should persist during a given session, but please don't bother doing it this way if you do anything at all: save it permanently with gconf key. Persistence of state always makes an application easier to learn and quicker to use. I also think that "All Text Files" should be the default. As gedit (or gtk or nautilus or whatever) obviously does something more intelligent than just check file extensions, I think that very seldom would gedit hide something that the user wished to open (for example, you can still open '/etc/network/interfaces' in the "Text Files" mode). Remember, novice users don't tend to be "power" users of text editors anyway. I'm not sure if this can be changed easily or is instead set in the gtk file chooser whatever widget, but please replace the ComboBox with two RadioButtons. It's silly to use a drop-down when there are only two options. It's better always to show the user the selected state and the alternate state. Lastly, I think this phrasing is clearer (for the English anyway): "Text Files Only" and "All Files". Again, please make "Text Files Only" the default. Thanks! Or maybe I'll have time to do it myself in the not so distant future. ;) ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62140] Pleave remove Insert (INS) / Overwrite (OVR) modes
Public bug reported: I must have tripped up onto my interface soapbox tonight... ;) So here is another gedit interface opinion: the Insert/ Overwrite modes should be removed and gedit should always behave as if it is in what was formerly known as the Insert mode. Here is my rational: 1) The INS/OVR mode is just that... a mode, always questionable if not bad in interface design, something which should never be included without a very good reason. 2) The INS/OVR mode is apparently totally worthless, certainly not passing the exception above. I've never found it even moderately useful to use OVR, nor have I ever observed anyone else doing so. If someone has a compelling case otherwise, I'm all ears. 3) On most keyboards, the INS key is near the HOME, END, PAGE UP, and PAGE DOWN keys, which are all used fairly frequently. I code with gedit, and it seems that at least a few times an hour I hit INS by mistake, type over a good number of characters that I did not intent to, realize that I'm now in *that* mode, and then waste time yell obscenities and correcting my mistake. 4) We can take a good lead from Apple who uses this key as something potentially useful: the HELP key. I think the INS/OVR modes are crufty leftovers anyway and not something people actually expect to be there, just something that annoys and confuses them if they switch to OVR by mistake. Firefox, which I'm writing this with, doesn't do any such nonsense... and I doubt anyone has ever complained about this lack of "functionality". Thanks! Happy hacking! ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Pleave remove Insert (INS) / Overwrite (OVR) modes https://launchpad.net/bugs/62140 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Re: Please retain state of Open > All Files / All Text Files
Although I would prefer Text Files Only to be the default, http://bugzilla.gnome.org/show_bug.cgi?id=329291 is a different bug than what I'm discussing here. Perhaps there are enough problems with the mime types that making Text Files the default isn't a good idea... but the real bug, in my opinion, is that the state the user has selected isn't retained. If this were fixed, I wouldn't particularly care what the default was because I could effectively set my own. -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Please retain state of Open > All Files / All Text Files
Public bug reported: Okay, maybe I'm one of very few who actually uses gedit for coding, but here's my workflow problem: 1) I need to open another source file, so I Open... 2) gedit nicely displays the contents of the last directory I've open anything from, which often contains several dozen source files. 3) But only on very rare occasions am I interested in a ".py~" file, and I've never felt the need to open a ".pyc" file, so I select "All Text Files" instead of "All Files" so I can more quickly find the ".py" file I'm looking for. 4) 53 seconds later, I feel the need to open some other ".py" file, but to my constant annoyance, gedit has reverted to "All Files", so I must select "All Text Files" again. 5) Repeat. I'm not much of a C hacker and am swamped with another project at the moment, so I wont be able fix this myself anytime soon. That being said, I know beggars can't be choosers, but here is my plea for how this should be implemented: At the very least the All Files / Text Files state should persist during a given session, but please don't bother doing it this way if you do anything at all: save it permanently with gconf key. Persistence of state always makes an application easier to learn and quicker to use. I also think that "All Text Files" should be the default. As gedit (or gtk or nautilus or whatever) obviously does something more intelligent than just check file extensions, I think that very seldom would gedit hide something that the user wished to open (for example, you can still open '/etc/network/interfaces' in the "Text Files" mode). Remember, novice users don't tend to be "power" users of text editors anyway. I'm not sure if this can be changed easily or is instead set in the gtk file chooser whatever widget, but please replace the ComboBox with two RadioButtons. It's silly to use a drop-down when there are only two options. It's better always to show the user the selected state and the alternate state. Lastly, I think this phrasing is clearer (for the English anyway): "Text Files Only" and "All Files". Again, please make "Text Files Only" the default. Thanks! Or maybe I'll have time to do it myself in the not so distant future. ;) ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62140] Pleave remove Insert (INS) / Overwrite (OVR) modes
Public bug reported: I must have tripped up onto my interface soapbox tonight... ;) So here is another gedit interface opinion: the Insert/ Overwrite modes should be removed and gedit should always behave as if it is in what was formerly known as the Insert mode. Here is my rational: 1) The INS/OVR mode is just that... a mode, always questionable if not bad in interface design, something which should never be included without a very good reason. 2) The INS/OVR mode is apparently totally worthless, certainly not passing the exception above. I've never found it even moderately useful to use OVR, nor have I ever observed anyone else doing so. If someone has a compelling case otherwise, I'm all ears. 3) On most keyboards, the INS key is near the HOME, END, PAGE UP, and PAGE DOWN keys, which are all used fairly frequently. I code with gedit, and it seems that at least a few times an hour I hit INS by mistake, type over a good number of characters that I did not intent to, realize that I'm now in *that* mode, and then waste time yell obscenities and correcting my mistake. 4) We can take a good lead from Apple who uses this key as something potentially useful: the HELP key. I think the INS/OVR modes are crufty leftovers anyway and not something people actually expect to be there, just something that annoys and confuses them if they switch to OVR by mistake. Firefox, which I'm writing this with, doesn't do any such nonsense... and I doubt anyone has ever complained about this lack of "functionality". Thanks! Happy hacking! ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Pleave remove Insert (INS) / Overwrite (OVR) modes https://launchpad.net/bugs/62140 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Re: Please retain state of Open > All Files / All Text Files
Although I would prefer Text Files Only to be the default, http://bugzilla.gnome.org/show_bug.cgi?id=329291 is a different bug than what I'm discussing here. Perhaps there are enough problems with the mime types that making Text Files the default isn't a good idea... but the real bug, in my opinion, is that the state the user has selected isn't retained. If this were fixed, I wouldn't particularly care what the default was because I could effectively set my own. -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54684] Re: High CPU usage
I'm experiencing the same problem using Thoggen under Edgy. It isn't necessary to hit refresh to trigger this. Simply opening nautilus to a directory containing a file that is being updated, and then immediately closing the nautilus window or changing to anther directory (like home) does the same thing... the CPU usage will shoot up to near 100% and will stay there till the process is killed (with "killall nautilus" or the like). -- High CPU usage https://launchpad.net/bugs/54684 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Seek on DVD not performed relative to title
Public bug reported: I'm running under Edgy, using gstreamer0.10-plugins- ugly-0.10.4-0ubuntu3. With totem-gstreamer, if I do something like this: totem dvd://2 And then seek, I will get bumped back into title 1. Also, if I do a large seek (say 30 minutes or more), sometimes totem will hang and never complete the seek. I know this isn't a totem bug because I have the exact results with the player in the gstreamer-based DVD ripper I've been developing. Thanks! ** Affects: gst-plugins-ugly0.10 (Ubuntu) Importance: Undecided Status: Unconfirmed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've filed an upstream bug about this: http://bugzilla.gnome.org/show_bug.cgi?id=372797 I know what the problem is and am working on a patch. I'd don't know quite how the updates policy works for universe... will it be possible to get a fix for this into Edgy? -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've submitted a patch for this upstream, but it was written starting from what was in cvs. http://bugzilla.gnome.org/show_bug.cgi?id=372797 I'll test a patch for Edgy and then submit that too. -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
After reading https://wiki.ubuntu.com/StableReleaseUpdates I expect that this is not a fix that would be allowed into Edgy anyway, but I'll still put a patch together. After working on the dvdreadsrc element quite a bit, I started to become frustrated with its readability problems and general cruftiness, so I've started a rewrite from scratch. I have the code for my new element in a Bazaar repository at https://launchpad.net/people/jderose/+branch/kungfu/dvdsrc My new dvdsrc element is now mostly usable as a drop-in replacement for dvdreadsrc. Currently I'm trying to decide whether it makes sense to combine the functionality of dvdnavsrc and dvdreadsrc. My feeling is that is probably does make sense, and so I'm planing to add Nav support to my new element. My goal is to trying to get this finished in time to get it into Feisty, so that full DVD functionality is available under gstreamer0.10. I could definitely use help on this, if anyone is interested! -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Here is the patch. In summary, it: * Fixes gst_dvd_read_src_get_sector_from_time(). Now only the correct tmap is used instead of the silly iteration through all tmaps in the title_set. * Fixes title starts at sector zero assumption in gst_dvd_read_src_goto_sector(). * Fixes title starts at sector zero assumption gst_dvd_read_src_goto_chapter(). I've testing this under Totem, Thoggen, and KungFu, and have found no regressions. ** Attachment added: "Fixes "Seek on DVD not performed relative to title"" http://librarian.launchpad.net/5240232/02_dvd-seek-fix.patch -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Oh, the patch also: * Improves gst_dvd_read_src_get_time_for_sector(), which now only iterates through the correct tmap instead of every tmap in the title_set. My gstreamer bug report has all sorts of details about my progress on this bug, some of which was wrong at first, but here is the most important bit: """ Again, the big problem with dvdreadsrc currently is that it doesn't properly handle cases where the title_set has more than one title. Here's a summary of how things work with libdvdread, as far as I understand: * The title number is mapped to the title_set number with tt_srpt->title[title].title_set_nr * For feature movies, the feature title is usually the only title in its title_set, which is why dvdreadsrc generally worked. But for, say, TV serials with several episodes per DVD, all the episodes usually belong to a single title_set, including the "play all" title that many DVDs have. In these cases, dvdreadsrc is "super extra broken". * ifoOpen and DVDOpenFile take the title_set_nr as an argument; they always open a title_set, not a single title (although as above, for movies the feature title is usually the only title in the title_set). * DVDReadBlocks works relative to the title_set, not the title. A wrong assumption made in many places in dvdreadsrc is that a title always starts at sector zero. In fact, it seems this assumption can't even be made for a title_set with one title. * cell_playback[cell].first_sector and cell_playback[cell].last_sector are relative to the title_set, not the title. This is why, by chance anyway, a multi-title title_set would at least start playing the correct title for title > 1. * If a title_set has a vts_tmapt, it will have exactly one tmap per title in the title_set. As far as I can tell, (tt_srpt->title[title].vts_ttn - 1) gives the index for the correct tmap for the title, but I need someone to verify this. (** After testing this on lots of DVDs, I'm now very confident that this is correct. **) * The times in the tmap are best dealt with relative to the title (which is what we want to do), but the sectors in tmap.map_ent[] are relative to the title_set. This "just works" as long as you are using the correct tmap. In this respect, gst_dvd_read_src_get_sector_from_time() was horibly broken. The original author(s) thought a nested iteration through vts_tmapt->tmap[i].map_ent[j] would somehow give the correct sector, which is utterly wrong, not to mention silly. It seems they got the idea from ifoPrint_VTS_TMAPT(), but didn't take the time to understand the meaning of the data structures. This is part of the reason why seeking is so broken. """ -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
** Changed in: gst-plugins-ugly0.10 (Ubuntu) Assignee: (unassigned) => Jason Gerard DeRose ** Changed in: gst-plugins-ugly0.10 (Ubuntu) Status: Unconfirmed => Fix Committed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Attachment added: "Python test script that demonstrates this bug." http://librarian.launchpad.net/5251721/hal_test.py -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Missing mandatory properties on volume.disc
Public bug reported: I'm running under Edgy, hal 0.5.7.1-0ubuntu17. Some mandatory volume.disc properties aren't availably for some discs. In particular, is_vcd, is_svcd, and is_videodvd are missing for blank CDR discs, audio CDs, and probably others that I haven't tested yet. Here are some examples: Blank CDR: volume.disc.type = cd_r volume.disc.has_audio = False volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = True volume.disc.is_rewritable = False Audio CD: volume.disc.type = cd_rom volume.disc.has_audio = True volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False Video DVD: volume.disc.type = dvd_rom volume.disc.has_audio = False volume.disc.has_data = True volume.disc.is_vcd = False volume.disc.is_svcd = False volume.disc.is_videodvd = True volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False ** Affects: hal (Ubuntu) Importance: Undecided Status: Unconfirmed -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
The status of this bug should really be set to high or critical, as Human should be considered broken by this. That Human didn't set out to replace every stock icon is not a good excuse, and this is why: 1) STOCK_OPEN and STOCK_DIRECTORY are very similar on the one hand, and often both will be used in the same application, so they should look similar. 2) On the other hand, they are *not* interchangeable semantically. If an application has a button that opens a folder, it will use STOCK_DIRECTORY. If an application has a button that opens a file, it will use STOCK_OPEN. This lack of interchangeability is especially true in the case of a gtk.Button(stock=STOCK_WHATEVER), where the application is also utilizing the internationalized text associated with the stock item. In this second case, something is really broken, as this screenshot shows. icon.set_from_stock() is at least working, despite not loading an icon that matches the theme. ** Attachment added: "Screenshot-stock_directory.py.png" http://librarian.launchpad.net/5286671/Screenshot-stock_directory.py.png -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
Here is a simple Python test script that demonstrates the problem, from which the screenshot was taken. ** Attachment added: "stock_directory.py" http://librarian.launchpad.net/5286684/stock_directory.py -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Tags added: hal -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Please retain state of Open > All Files / All Text Files
Public bug reported: Okay, maybe I'm one of very few who actually uses gedit for coding, but here's my workflow problem: 1) I need to open another source file, so I Open... 2) gedit nicely displays the contents of the last directory I've open anything from, which often contains several dozen source files. 3) But only on very rare occasions am I interested in a ".py~" file, and I've never felt the need to open a ".pyc" file, so I select "All Text Files" instead of "All Files" so I can more quickly find the ".py" file I'm looking for. 4) 53 seconds later, I feel the need to open some other ".py" file, but to my constant annoyance, gedit has reverted to "All Files", so I must select "All Text Files" again. 5) Repeat. I'm not much of a C hacker and am swamped with another project at the moment, so I wont be able fix this myself anytime soon. That being said, I know beggars can't be choosers, but here is my plea for how this should be implemented: At the very least the All Files / Text Files state should persist during a given session, but please don't bother doing it this way if you do anything at all: save it permanently with gconf key. Persistence of state always makes an application easier to learn and quicker to use. I also think that "All Text Files" should be the default. As gedit (or gtk or nautilus or whatever) obviously does something more intelligent than just check file extensions, I think that very seldom would gedit hide something that the user wished to open (for example, you can still open '/etc/network/interfaces' in the "Text Files" mode). Remember, novice users don't tend to be "power" users of text editors anyway. I'm not sure if this can be changed easily or is instead set in the gtk file chooser whatever widget, but please replace the ComboBox with two RadioButtons. It's silly to use a drop-down when there are only two options. It's better always to show the user the selected state and the alternate state. Lastly, I think this phrasing is clearer (for the English anyway): "Text Files Only" and "All Files". Again, please make "Text Files Only" the default. Thanks! Or maybe I'll have time to do it myself in the not so distant future. ;) ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62140] Pleave remove Insert (INS) / Overwrite (OVR) modes
Public bug reported: I must have tripped up onto my interface soapbox tonight... ;) So here is another gedit interface opinion: the Insert/ Overwrite modes should be removed and gedit should always behave as if it is in what was formerly known as the Insert mode. Here is my rational: 1) The INS/OVR mode is just that... a mode, always questionable if not bad in interface design, something which should never be included without a very good reason. 2) The INS/OVR mode is apparently totally worthless, certainly not passing the exception above. I've never found it even moderately useful to use OVR, nor have I ever observed anyone else doing so. If someone has a compelling case otherwise, I'm all ears. 3) On most keyboards, the INS key is near the HOME, END, PAGE UP, and PAGE DOWN keys, which are all used fairly frequently. I code with gedit, and it seems that at least a few times an hour I hit INS by mistake, type over a good number of characters that I did not intent to, realize that I'm now in *that* mode, and then waste time yell obscenities and correcting my mistake. 4) We can take a good lead from Apple who uses this key as something potentially useful: the HELP key. I think the INS/OVR modes are crufty leftovers anyway and not something people actually expect to be there, just something that annoys and confuses them if they switch to OVR by mistake. Firefox, which I'm writing this with, doesn't do any such nonsense... and I doubt anyone has ever complained about this lack of "functionality". Thanks! Happy hacking! ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Pleave remove Insert (INS) / Overwrite (OVR) modes https://launchpad.net/bugs/62140 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Re: Please retain state of Open > All Files / All Text Files
Although I would prefer Text Files Only to be the default, http://bugzilla.gnome.org/show_bug.cgi?id=329291 is a different bug than what I'm discussing here. Perhaps there are enough problems with the mime types that making Text Files the default isn't a good idea... but the real bug, in my opinion, is that the state the user has selected isn't retained. If this were fixed, I wouldn't particularly care what the default was because I could effectively set my own. -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54684] Re: High CPU usage
I'm experiencing the same problem using Thoggen under Edgy. It isn't necessary to hit refresh to trigger this. Simply opening nautilus to a directory containing a file that is being updated, and then immediately closing the nautilus window or changing to anther directory (like home) does the same thing... the CPU usage will shoot up to near 100% and will stay there till the process is killed (with "killall nautilus" or the like). -- High CPU usage https://launchpad.net/bugs/54684 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Seek on DVD not performed relative to title
Public bug reported: I'm running under Edgy, using gstreamer0.10-plugins- ugly-0.10.4-0ubuntu3. With totem-gstreamer, if I do something like this: totem dvd://2 And then seek, I will get bumped back into title 1. Also, if I do a large seek (say 30 minutes or more), sometimes totem will hang and never complete the seek. I know this isn't a totem bug because I have the exact results with the player in the gstreamer-based DVD ripper I've been developing. Thanks! ** Affects: gst-plugins-ugly0.10 (Ubuntu) Importance: Undecided Status: Unconfirmed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've filed an upstream bug about this: http://bugzilla.gnome.org/show_bug.cgi?id=372797 I know what the problem is and am working on a patch. I'd don't know quite how the updates policy works for universe... will it be possible to get a fix for this into Edgy? -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've submitted a patch for this upstream, but it was written starting from what was in cvs. http://bugzilla.gnome.org/show_bug.cgi?id=372797 I'll test a patch for Edgy and then submit that too. -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
After reading https://wiki.ubuntu.com/StableReleaseUpdates I expect that this is not a fix that would be allowed into Edgy anyway, but I'll still put a patch together. After working on the dvdreadsrc element quite a bit, I started to become frustrated with its readability problems and general cruftiness, so I've started a rewrite from scratch. I have the code for my new element in a Bazaar repository at https://launchpad.net/people/jderose/+branch/kungfu/dvdsrc My new dvdsrc element is now mostly usable as a drop-in replacement for dvdreadsrc. Currently I'm trying to decide whether it makes sense to combine the functionality of dvdnavsrc and dvdreadsrc. My feeling is that is probably does make sense, and so I'm planing to add Nav support to my new element. My goal is to trying to get this finished in time to get it into Feisty, so that full DVD functionality is available under gstreamer0.10. I could definitely use help on this, if anyone is interested! -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Here is the patch. In summary, it: * Fixes gst_dvd_read_src_get_sector_from_time(). Now only the correct tmap is used instead of the silly iteration through all tmaps in the title_set. * Fixes title starts at sector zero assumption in gst_dvd_read_src_goto_sector(). * Fixes title starts at sector zero assumption gst_dvd_read_src_goto_chapter(). I've testing this under Totem, Thoggen, and KungFu, and have found no regressions. ** Attachment added: "Fixes "Seek on DVD not performed relative to title"" http://librarian.launchpad.net/5240232/02_dvd-seek-fix.patch -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Oh, the patch also: * Improves gst_dvd_read_src_get_time_for_sector(), which now only iterates through the correct tmap instead of every tmap in the title_set. My gstreamer bug report has all sorts of details about my progress on this bug, some of which was wrong at first, but here is the most important bit: """ Again, the big problem with dvdreadsrc currently is that it doesn't properly handle cases where the title_set has more than one title. Here's a summary of how things work with libdvdread, as far as I understand: * The title number is mapped to the title_set number with tt_srpt->title[title].title_set_nr * For feature movies, the feature title is usually the only title in its title_set, which is why dvdreadsrc generally worked. But for, say, TV serials with several episodes per DVD, all the episodes usually belong to a single title_set, including the "play all" title that many DVDs have. In these cases, dvdreadsrc is "super extra broken". * ifoOpen and DVDOpenFile take the title_set_nr as an argument; they always open a title_set, not a single title (although as above, for movies the feature title is usually the only title in the title_set). * DVDReadBlocks works relative to the title_set, not the title. A wrong assumption made in many places in dvdreadsrc is that a title always starts at sector zero. In fact, it seems this assumption can't even be made for a title_set with one title. * cell_playback[cell].first_sector and cell_playback[cell].last_sector are relative to the title_set, not the title. This is why, by chance anyway, a multi-title title_set would at least start playing the correct title for title > 1. * If a title_set has a vts_tmapt, it will have exactly one tmap per title in the title_set. As far as I can tell, (tt_srpt->title[title].vts_ttn - 1) gives the index for the correct tmap for the title, but I need someone to verify this. (** After testing this on lots of DVDs, I'm now very confident that this is correct. **) * The times in the tmap are best dealt with relative to the title (which is what we want to do), but the sectors in tmap.map_ent[] are relative to the title_set. This "just works" as long as you are using the correct tmap. In this respect, gst_dvd_read_src_get_sector_from_time() was horibly broken. The original author(s) thought a nested iteration through vts_tmapt->tmap[i].map_ent[j] would somehow give the correct sector, which is utterly wrong, not to mention silly. It seems they got the idea from ifoPrint_VTS_TMAPT(), but didn't take the time to understand the meaning of the data structures. This is part of the reason why seeking is so broken. """ -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
** Changed in: gst-plugins-ugly0.10 (Ubuntu) Assignee: (unassigned) => Jason Gerard DeRose ** Changed in: gst-plugins-ugly0.10 (Ubuntu) Status: Unconfirmed => Fix Committed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Attachment added: "Python test script that demonstrates this bug." http://librarian.launchpad.net/5251721/hal_test.py -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Missing mandatory properties on volume.disc
Public bug reported: I'm running under Edgy, hal 0.5.7.1-0ubuntu17. Some mandatory volume.disc properties aren't availably for some discs. In particular, is_vcd, is_svcd, and is_videodvd are missing for blank CDR discs, audio CDs, and probably others that I haven't tested yet. Here are some examples: Blank CDR: volume.disc.type = cd_r volume.disc.has_audio = False volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = True volume.disc.is_rewritable = False Audio CD: volume.disc.type = cd_rom volume.disc.has_audio = True volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False Video DVD: volume.disc.type = dvd_rom volume.disc.has_audio = False volume.disc.has_data = True volume.disc.is_vcd = False volume.disc.is_svcd = False volume.disc.is_videodvd = True volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False ** Affects: hal (Ubuntu) Importance: Undecided Status: Unconfirmed -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
The status of this bug should really be set to high or critical, as Human should be considered broken by this. That Human didn't set out to replace every stock icon is not a good excuse, and this is why: 1) STOCK_OPEN and STOCK_DIRECTORY are very similar on the one hand, and often both will be used in the same application, so they should look similar. 2) On the other hand, they are *not* interchangeable semantically. If an application has a button that opens a folder, it will use STOCK_DIRECTORY. If an application has a button that opens a file, it will use STOCK_OPEN. This lack of interchangeability is especially true in the case of a gtk.Button(stock=STOCK_WHATEVER), where the application is also utilizing the internationalized text associated with the stock item. In this second case, something is really broken, as this screenshot shows. icon.set_from_stock() is at least working, despite not loading an icon that matches the theme. ** Attachment added: "Screenshot-stock_directory.py.png" http://librarian.launchpad.net/5286671/Screenshot-stock_directory.py.png -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
Here is a simple Python test script that demonstrates the problem, from which the screenshot was taken. ** Attachment added: "stock_directory.py" http://librarian.launchpad.net/5286684/stock_directory.py -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Tags added: hal -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54684] Re: High CPU usage
I'm experiencing the same problem using Thoggen under Edgy. It isn't necessary to hit refresh to trigger this. Simply opening nautilus to a directory containing a file that is being updated, and then immediately closing the nautilus window or changing to anther directory (like home) does the same thing... the CPU usage will shoot up to near 100% and will stay there till the process is killed (with "killall nautilus" or the like). -- High CPU usage https://launchpad.net/bugs/54684 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Seek on DVD not performed relative to title
Public bug reported: I'm running under Edgy, using gstreamer0.10-plugins- ugly-0.10.4-0ubuntu3. With totem-gstreamer, if I do something like this: totem dvd://2 And then seek, I will get bumped back into title 1. Also, if I do a large seek (say 30 minutes or more), sometimes totem will hang and never complete the seek. I know this isn't a totem bug because I have the exact results with the player in the gstreamer-based DVD ripper I've been developing. Thanks! ** Affects: gst-plugins-ugly0.10 (Ubuntu) Importance: Undecided Status: Unconfirmed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've filed an upstream bug about this: http://bugzilla.gnome.org/show_bug.cgi?id=372797 I know what the problem is and am working on a patch. I'd don't know quite how the updates policy works for universe... will it be possible to get a fix for this into Edgy? -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
I've submitted a patch for this upstream, but it was written starting from what was in cvs. http://bugzilla.gnome.org/show_bug.cgi?id=372797 I'll test a patch for Edgy and then submit that too. -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
After reading https://wiki.ubuntu.com/StableReleaseUpdates I expect that this is not a fix that would be allowed into Edgy anyway, but I'll still put a patch together. After working on the dvdreadsrc element quite a bit, I started to become frustrated with its readability problems and general cruftiness, so I've started a rewrite from scratch. I have the code for my new element in a Bazaar repository at https://launchpad.net/people/jderose/+branch/kungfu/dvdsrc My new dvdsrc element is now mostly usable as a drop-in replacement for dvdreadsrc. Currently I'm trying to decide whether it makes sense to combine the functionality of dvdnavsrc and dvdreadsrc. My feeling is that is probably does make sense, and so I'm planing to add Nav support to my new element. My goal is to trying to get this finished in time to get it into Feisty, so that full DVD functionality is available under gstreamer0.10. I could definitely use help on this, if anyone is interested! -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Here is the patch. In summary, it: * Fixes gst_dvd_read_src_get_sector_from_time(). Now only the correct tmap is used instead of the silly iteration through all tmaps in the title_set. * Fixes title starts at sector zero assumption in gst_dvd_read_src_goto_sector(). * Fixes title starts at sector zero assumption gst_dvd_read_src_goto_chapter(). I've testing this under Totem, Thoggen, and KungFu, and have found no regressions. ** Attachment added: "Fixes "Seek on DVD not performed relative to title"" http://librarian.launchpad.net/5240232/02_dvd-seek-fix.patch -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
Oh, the patch also: * Improves gst_dvd_read_src_get_time_for_sector(), which now only iterates through the correct tmap instead of every tmap in the title_set. My gstreamer bug report has all sorts of details about my progress on this bug, some of which was wrong at first, but here is the most important bit: """ Again, the big problem with dvdreadsrc currently is that it doesn't properly handle cases where the title_set has more than one title. Here's a summary of how things work with libdvdread, as far as I understand: * The title number is mapped to the title_set number with tt_srpt->title[title].title_set_nr * For feature movies, the feature title is usually the only title in its title_set, which is why dvdreadsrc generally worked. But for, say, TV serials with several episodes per DVD, all the episodes usually belong to a single title_set, including the "play all" title that many DVDs have. In these cases, dvdreadsrc is "super extra broken". * ifoOpen and DVDOpenFile take the title_set_nr as an argument; they always open a title_set, not a single title (although as above, for movies the feature title is usually the only title in the title_set). * DVDReadBlocks works relative to the title_set, not the title. A wrong assumption made in many places in dvdreadsrc is that a title always starts at sector zero. In fact, it seems this assumption can't even be made for a title_set with one title. * cell_playback[cell].first_sector and cell_playback[cell].last_sector are relative to the title_set, not the title. This is why, by chance anyway, a multi-title title_set would at least start playing the correct title for title > 1. * If a title_set has a vts_tmapt, it will have exactly one tmap per title in the title_set. As far as I can tell, (tt_srpt->title[title].vts_ttn - 1) gives the index for the correct tmap for the title, but I need someone to verify this. (** After testing this on lots of DVDs, I'm now very confident that this is correct. **) * The times in the tmap are best dealt with relative to the title (which is what we want to do), but the sectors in tmap.map_ent[] are relative to the title_set. This "just works" as long as you are using the correct tmap. In this respect, gst_dvd_read_src_get_sector_from_time() was horibly broken. The original author(s) thought a nested iteration through vts_tmapt->tmap[i].map_ent[j] would somehow give the correct sector, which is utterly wrong, not to mention silly. It seems they got the idea from ifoPrint_VTS_TMAPT(), but didn't take the time to understand the meaning of the data structures. This is part of the reason why seeking is so broken. """ -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 71017] Re: Seek on DVD not performed relative to title
** Changed in: gst-plugins-ugly0.10 (Ubuntu) Assignee: (unassigned) => Jason Gerard DeRose ** Changed in: gst-plugins-ugly0.10 (Ubuntu) Status: Unconfirmed => Fix Committed -- Seek on DVD not performed relative to title https://launchpad.net/bugs/71017 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Attachment added: "Python test script that demonstrates this bug." http://librarian.launchpad.net/5251721/hal_test.py -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Missing mandatory properties on volume.disc
Public bug reported: I'm running under Edgy, hal 0.5.7.1-0ubuntu17. Some mandatory volume.disc properties aren't availably for some discs. In particular, is_vcd, is_svcd, and is_videodvd are missing for blank CDR discs, audio CDs, and probably others that I haven't tested yet. Here are some examples: Blank CDR: volume.disc.type = cd_r volume.disc.has_audio = False volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = True volume.disc.is_rewritable = False Audio CD: volume.disc.type = cd_rom volume.disc.has_audio = True volume.disc.has_data = False volume.disc.is_vcd: No property volume.disc.is_svcd: No property volume.disc.is_videodvd: No property volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False Video DVD: volume.disc.type = dvd_rom volume.disc.has_audio = False volume.disc.has_data = True volume.disc.is_vcd = False volume.disc.is_svcd = False volume.disc.is_videodvd = True volume.disc.is_appendable = False volume.disc.is_blank = False volume.disc.is_rewritable = False ** Affects: hal (Ubuntu) Importance: Undecided Status: Unconfirmed -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
The status of this bug should really be set to high or critical, as Human should be considered broken by this. That Human didn't set out to replace every stock icon is not a good excuse, and this is why: 1) STOCK_OPEN and STOCK_DIRECTORY are very similar on the one hand, and often both will be used in the same application, so they should look similar. 2) On the other hand, they are *not* interchangeable semantically. If an application has a button that opens a folder, it will use STOCK_DIRECTORY. If an application has a button that opens a file, it will use STOCK_OPEN. This lack of interchangeability is especially true in the case of a gtk.Button(stock=STOCK_WHATEVER), where the application is also utilizing the internationalized text associated with the stock item. In this second case, something is really broken, as this screenshot shows. icon.set_from_stock() is at least working, despite not loading an icon that matches the theme. ** Attachment added: "Screenshot-stock_directory.py.png" http://librarian.launchpad.net/5286671/Screenshot-stock_directory.py.png -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 54890] Re: The GTK_STOCK_DIRECTORY icon isn't being themed
Here is a simple Python test script that demonstrates the problem, from which the screenshot was taken. ** Attachment added: "stock_directory.py" http://librarian.launchpad.net/5286684/stock_directory.py -- The GTK_STOCK_DIRECTORY icon isn't being themed https://launchpad.net/bugs/54890 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 74540] Re: Missing mandatory properties on volume.disc
** Tags added: hal -- Missing mandatory properties on volume.disc https://launchpad.net/bugs/74540 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Please retain state of Open > All Files / All Text Files
Public bug reported: Okay, maybe I'm one of very few who actually uses gedit for coding, but here's my workflow problem: 1) I need to open another source file, so I Open... 2) gedit nicely displays the contents of the last directory I've open anything from, which often contains several dozen source files. 3) But only on very rare occasions am I interested in a ".py~" file, and I've never felt the need to open a ".pyc" file, so I select "All Text Files" instead of "All Files" so I can more quickly find the ".py" file I'm looking for. 4) 53 seconds later, I feel the need to open some other ".py" file, but to my constant annoyance, gedit has reverted to "All Files", so I must select "All Text Files" again. 5) Repeat. I'm not much of a C hacker and am swamped with another project at the moment, so I wont be able fix this myself anytime soon. That being said, I know beggars can't be choosers, but here is my plea for how this should be implemented: At the very least the All Files / Text Files state should persist during a given session, but please don't bother doing it this way if you do anything at all: save it permanently with gconf key. Persistence of state always makes an application easier to learn and quicker to use. I also think that "All Text Files" should be the default. As gedit (or gtk or nautilus or whatever) obviously does something more intelligent than just check file extensions, I think that very seldom would gedit hide something that the user wished to open (for example, you can still open '/etc/network/interfaces' in the "Text Files" mode). Remember, novice users don't tend to be "power" users of text editors anyway. I'm not sure if this can be changed easily or is instead set in the gtk file chooser whatever widget, but please replace the ComboBox with two RadioButtons. It's silly to use a drop-down when there are only two options. It's better always to show the user the selected state and the alternate state. Lastly, I think this phrasing is clearer (for the English anyway): "Text Files Only" and "All Files". Again, please make "Text Files Only" the default. Thanks! Or maybe I'll have time to do it myself in the not so distant future. ;) ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62140] Pleave remove Insert (INS) / Overwrite (OVR) modes
Public bug reported: I must have tripped up onto my interface soapbox tonight... ;) So here is another gedit interface opinion: the Insert/ Overwrite modes should be removed and gedit should always behave as if it is in what was formerly known as the Insert mode. Here is my rational: 1) The INS/OVR mode is just that... a mode, always questionable if not bad in interface design, something which should never be included without a very good reason. 2) The INS/OVR mode is apparently totally worthless, certainly not passing the exception above. I've never found it even moderately useful to use OVR, nor have I ever observed anyone else doing so. If someone has a compelling case otherwise, I'm all ears. 3) On most keyboards, the INS key is near the HOME, END, PAGE UP, and PAGE DOWN keys, which are all used fairly frequently. I code with gedit, and it seems that at least a few times an hour I hit INS by mistake, type over a good number of characters that I did not intent to, realize that I'm now in *that* mode, and then waste time yell obscenities and correcting my mistake. 4) We can take a good lead from Apple who uses this key as something potentially useful: the HELP key. I think the INS/OVR modes are crufty leftovers anyway and not something people actually expect to be there, just something that annoys and confuses them if they switch to OVR by mistake. Firefox, which I'm writing this with, doesn't do any such nonsense... and I doubt anyone has ever complained about this lack of "functionality". Thanks! Happy hacking! ** Affects: gedit (Ubuntu) Importance: Untriaged Status: Unconfirmed -- Pleave remove Insert (INS) / Overwrite (OVR) modes https://launchpad.net/bugs/62140 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
[Bug 62132] Re: Please retain state of Open > All Files / All Text Files
Although I would prefer Text Files Only to be the default, http://bugzilla.gnome.org/show_bug.cgi?id=329291 is a different bug than what I'm discussing here. Perhaps there are enough problems with the mime types that making Text Files the default isn't a good idea... but the real bug, in my opinion, is that the state the user has selected isn't retained. If this were fixed, I wouldn't particularly care what the default was because I could effectively set my own. -- Please retain state of Open > All Files / All Text Files https://launchpad.net/bugs/62132 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
