[sugar] Journal Object Picker in Read

[Bert Freudenberg]

Am 08.10.2008 um 13:49 schrieb Tomeu Vizoso:

> On Wed, Oct 8, 2008 at 1:30 PM, Bert Freudenberg  
> <bert at freudenbergs.de> wrote:
>> 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.
>
> The thing is that the D-Bus DS API is not certain to live much longer,
> so I would prefer if the minimum expectations are set, so we can move
> later to a better API with less problems for everyone.


Well, the chooser is Journal API not DS API. And how would activities  
communicate with Sugar if not by D-Bus?

- Bert -