[sugar] Journal Object Picker in Read

[Tomeu Vizoso]

On Wed, Oct 8, 2008 at 2:15 PM, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> 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?

I was referring to the DS D-Bus API, the Journal D-Bus API makes use
of it, so if we grow functionality on the journal api, we'll be
growing the dependency on the DS API. Most probably the new DS API
will support all this and more, but I would prefer not to increase the
pressure on the DS because that has worked very bad for us till now.
If we can keep things simple for now, I'd rather do it.

Regards,

Tomeu