(In reply to Charles from comment #142) > (In reply to Wayne Mery (:wsmwk) from comment #141) > > Surprisingly I'm pretty much liking the addon. One nit is if I filter on X > > in tab A and then on Y in tab B, that Y is shown in tab A when I go back to > > A. Even though A is still filtered on X. > > Well, again, since I don't use tabs, I would never have encountered those > issues... most likely Iago can fix them though if you report it to him... > > > That said, this bug seems to have gone off the rails, starting in comment > > 115 - 117, and 124. Let me point out that *Blake didn't start this*, and the > > direction wasn't brought back in focus by anyone back then, until ~comment > > 129, that the addon doesn't focus on what you (Charles) want. > > Not sure what you mean... the addon totally fulfills this bug request. We - > users - are often told that an Addon is a good way to get a feature > implemented, because then the code is already written, and thus, the Unified > Search Addon was born.
Perhaps there is a misunderstanding. because a) I said nothing about not doing an addon, and b) your bug summary says nothing about reunification > > STM the current addon focused on reunification > > No, initially, the Addon focused precisely on fulfilling my original > request, as hammered out in the mockups so artfully done by Thomas D. The > 'unification' aspect (unifying the Global Search etc) was added > *afterwards*... > > > and it's conversation should probably go in a different bug. Not that it > > will > > change the direction of the addon - which seems clear enough to me - but it > > may help get this bug back on topic. How quickly it progresses is a > > different > > matter. > > Again, I don't follow. This addon *totally* fulfills my request, so please I > wish you guys would stop telling me that it doesn't - I should know, I made > it, and am using (and now totally dependent on), and that is why I'm now > asking for the Unified Search addon to be incorporated into the core code > (since that would be the last step in fulfilling this bug request). then apparently I have goofed, and am happy to say so. it would help please to change your bug title/summary so one doesn't have to read 100+ comments to understand the basics of the bug, and get summarily blasted when we make seemingly useless comments. maybe even resummarize the goal. Bear in mind, if you conflate multiple goals, the patch is much more complex, and less likely to be accepted into core - addon or no addon. big kudos to Iago and all for working to improve Tbird. W. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to thunderbird in Ubuntu. https://bugs.launchpad.net/bugs/691380 Title: Quick Search Filter should be moveable Status in Mozilla Thunderbird Mail and News: Confirmed Status in “thunderbird” package in Ubuntu: Triaged Status in “thunderbird” source package in Lucid: Triaged Bug description: Binary package hint: thunderbird Today I updated lucid 3.0.4 TB to 3.1.7 from security. I never liked the new "smart" search feature but relied mostly on filtering on To, CC and recipient. I had put the search field for that on the menu bar so no further screen real estate was used on my netbook. 3.1.7 now introduces a UI regression in that that search field is used solely for the dumb "smart" search that opens a tab to waste even more screen space. To use the search that I care about I have to use the quick search bar, more lost screen space. And when I actually use it it opens another bar to filter and by then I can't even see my messages any longer. Seriously, netbooks are here to stay. What were the UI devs thinking looking at their 28" TFT display all day? To manage notifications about this bug go to: https://bugs.launchpad.net/thunderbird/+bug/691380/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
