[sugar] [PATCH] Add indications for empty journal and empty search results

[Eben Eliason]

I realized that my check for an empty Journal wasn't strong enough,
since it only checked for a null query (ignoring the filters).  Here's
the critical change within the refresh() method:

        if self._result_set.length == 0:
            logging.debug(self._query)
-            if self._query.has_key('query'):
+            if self._query.has_key('query') or \
+                   self._query.has_key('mime_type') or \
+                   self._query.has_key('mtime'):
                self._show_message(NO_MATCH)
            else:
                self._show_message(EMPTY_JOURNAL)
        else:
            self._clear_message()

- Eben


On Wed, Jun 18, 2008 at 3:58 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> Looks great, thanks!
>
> Tomeu
>
> On Wed, Jun 18, 2008 at 2:46 AM, Eben Eliason <eben.eliason at gmail.com> wrote:
>> A cleaner attempt.  Thanks.
>>
>> - Eben
>>
>>
>> On Tue, Jun 17, 2008 at 11:08 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>>> On Tue, Jun 17, 2008 at 4:33 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
>>>> On Tue, Jun 17, 2008 at 9:18 AM, Eben Eliason <eben.eliason at gmail.com> wrote:
>>>>> On Tue, Jun 17, 2008 at 3:36 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
>>>>>> What about creating the empty_box in a method? We don't really need to
>>>>>> hold a reference to it in ListView, right? You could then pass the
>>>>>> string as a parameter to that method, thus avoiding multiple repeated
>>>>>> instances of translatable strings, that is something quite bad.
>>>>>
>>>>> We could use a method.  I want to keep the door open to allowing other
>>>>> changes apart from the string, in the future.  For instance, as the
>>>>> commit message indicates, the different cases may have buttons with
>>>>> different icons/actions in the future.  Perhaps I should just make
>>>>> separate methods for the two states. What do you think?  Perhaps add
>>>>> another to clear the message and restore the list as well?
>>>>
>>>> Oh, as a side note, implementing this as a single method doesn't take
>>>> care of the repeated translatable strings, as we'd need to pass the
>>>> translated string from each location we called the method from.  I
>>>> suppose you could store a reference to the translated strings in init
>>>> or something, and then pass those, but that doesn't seem like a good
>>>> solution to me.
>>>
>>> Well, being a separate method or class allows you to add a constant
>>> parameter/property that signals to use one or the other string.
>>>
>>> Thanks,
>>>
>>> Tomeu
>>>
>>
>