[sugar] Journal Object Picker in Read

Bert Freudenberg bert at freudenbergs.de
Wed Oct 8 07:30:44 EDT 2008


Am 08.10.2008 um 12:03 schrieb Tomeu Vizoso:

> On Wed, Oct 8, 2008 at 11:10 AM, Bert Freudenberg <bert at freudenbergs.de 
> > wrote:
>>
>> Am 08.10.2008 um 10:33 schrieb Morgan Collett:
>>
>>> I filed #8350 regarding adding the journal object picker to Read,  
>>> for
>>> the case when it is launched from Home View without a document.
>>>
>>> There was a recent discussion on the library list about this, since
>>> the show_launcher setting isn't relevant any more - Read appears in
>>> Home View if you star it. (If Read is installed in the software
>>> updater, it will be starred...)
>>>
>>> I have implemented this, and could release it for 8.2.1, but the
>>> journal object picker doesn't currently have any filters for an
>>> Activity to restrict the view to only relevant entries - so it  
>>> pops up
>>> with the entire journal visible - images, Write entries, Browse
>>> entries, etc where all we can handle in Read are relevant downloaded
>>> documents, and previous Read instances.
>>>
>>> Is this going to cause more problems than it's worth?
>>>
>>> I could make the object picker pop up again if the selected entry
>>> failed to load, if that helps.
>>>
>>> An alternative to using the object picker is to have a string break
>>> and add a dialog that explains that you launched Read without a
>>> document, and so it isn't useful, and make that stop Read when
>>> acknowledged.
>>
>>
>> Why not extend the object chooser to include a query parameter?
>
> I'm not 100% sure yet. How does the object chooser look when it is
> prefiltered? Can the user undo the filter? Which properties can be
> filtered? Any? Just the ones the user itself can? Can a free text
> string be provided?
>
> If we could limit the preset filter to a list of mime types, I think
> we would benefit from the simplicity. Can we do that? In which cases
> is this not enough?


I don't know - it just seems unwise to artificially limit a powerful  
API that is already exposed elsewhere, just because we cannot think of  
a use case right now.

But I'm not too hung up on that one, a simple list of mime types is  
much better than no filtering, so go for it.

How about allowing glob patterns in addition to concrete types? Though  
that might require extending the DS.

- Bert -




More information about the Sugar mailing list