Bugs: Browse | Submit New | Admin
With alexandria 0.6.4.1 A. - First remove ~/.alexandria - Launch alexandria, then * Currently only one library (named "My Library" in C locale) exists. Add one book on the library * Create another library and add a book on the newly created library Then currently 2 libraries exist. Each library contains one book entry. - Then once close alexandria B. After A: - Launch alexandria again. At this stage one library is already selected on the left pane - On the selected library on the left pane, click right button. Then 3 items including "Delete" appears. This is okay - Next choose another library (on the left pane), and click right button !!! Here "Delete" item is hidden in shadow. I guess this is a bug. - Again choose the first library and click right button !!! Here "Delete" item is hidden again. C. After B: - Choose one library - Click right button and choose "Rename", and actually change the library name. - Then on the renamed library (on the left pane), again click right button. This time "Delete" item appears (!!), so delete this library. At this stage only one library is left. - Then choose the left library (on the left pane), again click right button, choose "Rename" and actually change the library name - Then again on the renamed library, again click right button and choose "Delete". !!! Then alexandria crashes: ----------------------- Alexandria just crashed ----------------------- Timestamp: Mon Mar 30 21:44:29 +0900 2009 Message: no libraries Backtrace: /usr/lib/ruby/site_ruby/1.8/alexandria/smart_library.rb:164:in `refilter' /usr/lib/ruby/site_ruby/1.8/alexandria/smart_library.rb:155:in `update' /usr/lib/ruby/1.8/observer.rb:185:in `notify_observers' /usr/lib/ruby/1.8/observer.rb:184:in `each' /usr/lib/ruby/1.8/observer.rb:184:in `notify_observers' /usr/lib/ruby/site_ruby/1.8/alexandria/models/library.rb:700:in `notify' /usr/lib/ruby/site_ruby/1.8/alexandria/models/library.rb:675:in `remove_library' /usr/lib/ruby/site_ruby/1.8/alexandria/ui/ui_manager.rb:1147:in `undoable_delete' /usr/lib/ruby/site_ruby/1.8/alexandria/ui/callbacks.rb:214:in `on_delete' /usr/lib/ruby/site_ruby/1.8/alexandria/ui.rb:51:in `call' /usr/lib/ruby/site_ruby/1.8/alexandria/ui.rb:51:in `main' /usr/lib/ruby/site_ruby/1.8/alexandria/ui.rb:51:in `start_gtk' /usr/lib/ruby/site_ruby/1.8/alexandria/ui.rb:57:in `main' /usr/lib/ruby/site_ruby/1.8/alexandria.rb:40:in `main' /usr/bin/alexandria:29 Release: 0.6.4.1(0.6.4.1) Uname -a: Linux localhost.localdomain 2.6.27.21-170.2.56.fc10.i686 #1 SMP Mon Mar 23 23:37:54 EDT 2009 i686 i686 i386 GNU/Linux -- Please report this dump to 'alexandria-list@rubyforge.org' with some additional information, such as the description of the crash and the steps to reproduce it (if it's possible).
Add A Comment:
Date: 2010-06-22 00:40 Sender: Cathal Mc Ginley Fixed in Alexandria 0.6.6
Date: 2009-04-06 20:46 Sender: Mamoru Tasaka Okay, now rev 1072 works as you and I expect, thank you! I think that it is worth writing a note that at least one library should exist.
Date: 2009-04-06 19:50 Sender: Cathal Mc Ginley Ack!! I'm really beginning to wonder about this section of code, it's become so 'crufty' that any change introduces a new bug! :^) Thanks for sticking with this issue for so long. Should work in SVN r1072. Should the "expected behaviour" I mentioned earlier be documented? Perhaps it's not obvious that there must be at least one real Library. It may be worth a note in the manual, perhaps...
Date: 2009-04-06 19:39 Sender: Mamoru Tasaka Thanks you. Now I tried rev 1071 and then: 1) > Any Smart Library should be deletable, all the time. - With rev 1071, when one "real" library is left, smart libraries don't seem to be deletable: ----------------------------------------------------- W, [2009-04-07T04:31:57.203360 #28440] WARN -- <Obj Alexandria::UI::UIManager>: Attempted to delete last library, fix GUI W, [2009-04-07T04:32:00.229590 #28440] WARN -- <Obj Alexandria::UI::UIManager>: Attempted to delete last library, fix GUI ------------------------------------------------------- 2) and 3) work as you expect.
Date: 2009-04-06 19:03 Sender: Cathal Mc Ginley I'm not sure if we're getting different behaviour here, or if we have different expectations of how Alexandria should behave. I wasn't getting the shadowed-out Delete item except when expected with r1070, but after changing a the name of the last real Library, "My Library", the Delete item was NOT shadowed out as I expected. (I'm using ruby-gnome2 version 0.18.1 on x86_64). Anyway, the expected behaviour for Alexandria is: 1) Any Smart Library should be deletable, all the time. 2) When there is more than one real Library, any one of them should be deletable. 3) When there is only ONE real Library, it should NOT be deletable. (This is why Alexandria starts off by creating the default "My Library" - it expects there to be at least one real Library all the time). Anyway, I applied your patch, but then saw a small flaw in the definition of sensitize_library concerning the "Delete" action - it was always set to true. It turns out that this method is called (via refresh_libraries) when a Library is renamed (sidepane.rb line 77). So that explains the crash from of the original report, and it should be fixed now in SVN r1071. Let me know if it now behaves as I describe.
Date: 2009-04-05 20:16 Sender: Mamoru Tasaka Then after I rename the library name, debug message shows: --------------------------------------------------------- D, [2009-04-06T04:27:54.446768 #17662] DEBUG -- <Obj Alexandria::UI::UIManager>: selected_library D, [2009-04-06T04:27:54.447223 #17662] DEBUG -- <Obj Alexandria::UI::UIManager>: sensitize_library: smartlibrary = false D, [2009-04-06T04:27:54.447757 #17662] DEBUG -- <Obj Alexandria::UI::UIManager>: sensitize_library delete: true ------------------------------------------------------- This seems to be related (to make "Delete" item correctly appear). I tried to call sensitize_library on on_library_button_press_event and this seems to work for me (please see the attached proposal patch)
Date: 2009-04-05 20:12 Sender: Mamoru Tasaka Well, even in your case it doesn't seem to work perfectly (e.g. after deleting "More Books" library). I tried to debug what is happening when "Delete" item is in shadow (on rev 1070). Please see the log attached. As I said before when I - change the library name - and tried to delete the library its name just changed now Then this action succeeds (additional comments follow)
Date: 2009-04-05 19:25 Sender: Cathal Mc Ginley I don't get this behaviour any more - using r1070 on my system, the delete item is enabled in the circumstances you describe. I've attached a screencast (ogv made with gtk-recordMyDesktop) that shows the behaviour I get. The clicks to change between libraries are a random mix of left-clicks and right-clicks: the first right-click selects the library, the second pops up the menu with "Delete" enabled as expected.
Date: 2009-04-05 16:25 Sender: Mamoru Tasaka Well, my problem is that (with rev 1070) - launch alexandria - click one library on the left pane by left button (i.e. select the library explicitly) - Then on the clicked point click the right button Even this "Delete" menu is still in shadow (i.e. I cannot delete the library) Screenshot attached. The bottom bar shows "Library 'My Library' selected".
Date: 2009-04-04 21:34 Sender: Cathal Mc Ginley Worked around the second part of the problem in SVN r1070. The menu item for Delete is still enabled immediately after you rename a library (unfortunately), but Alexandria will silently refuse to delete the last library. It's not an ideal solution here either, but it does prevent the crash. In any case, it's a rare case that the user would 1) rename the sole regular Library and 2) immediately try to delete it. If the user clicks anywhere else before right-clicking the renamed library, the menu item will behave as it should. So I think silently ignoring the request is an acceptable compromise. The two issues from the original report DO seem to be related; they are both a matter of when the "Delete" Action (from the UIManager's ActionGroups) has its 'sensitive' property modified to reflect the selected Library correctly. Unfortunately, I'm not so familiar with this part of GTK+ that I can figure out what's going wrong. Hence these two workarounds.
Date: 2009-04-04 20:58 Sender: Cathal Mc Ginley I've worked around the first (easier) problem in SVN r1069. Now, right clicking on a Library that isn't selected just causes it to be selected; only right-clicking on a selected Library will pop up a menu. This is awkward, but I couldn't find any other way around this inconsistency; even attempting to delay the UI between the selection and popping up the menu (tried in SVN r1068 using a timeout_add) didn't work - after the popup appeared, clicking on Delete either had no effect, or attempted to Delete the wrong Library. This behaviour might be confusing for users though, so it might change again before the next release. Any pointers to a GTK+ guide on how best to handle this case would be great :^)
Date: 2009-03-30 15:51 Sender: Cathal Mc Ginley Confirmed. I can make a few observations already. These seem to be two separate bugs; the first is a simple snag, the second is a real problem. First, the shadowed-out 'Delete' menu item seems to happen if you right-click on a Library which is not already selected. This is a fault somewhere in the GUI code (the code which builds the context menu should select the Library first). Secondly, it should not be possible to delete the last remaining Library. (Try deleting 'My Library' after a fresh installation of Alexandria!) This bug shows that the user can 'work around' this restriction by renaming the last library directly before deleting it. This needs to be fixed. I'll look into this further later.
