[sugar] Journal Object Picker in Read

[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.

Regards,

Tomeu