On Wed, Oct 8, 2008 at 1:30 PM, Bert Freudenberg <[EMAIL PROTECTED]> wrote: > Am 08.10.2008 um 12:03 schrieb Tomeu Vizoso: > >> On Wed, Oct 8, 2008 at 11:10 AM, Bert Freudenberg <[EMAIL PROTECTED] >> > 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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
