[sugar] Journal Object Picker in Read

Bert Freudenberg bert
Wed Oct 8 08:15:50 EDT 2008

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 -

More information about the Sugar-devel mailing list