Am 08.10.2008 um 13:49 schrieb Tomeu Vizoso: > 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.
Well, the chooser is Journal API not DS API. And how would activities communicate with Sugar if not by D-Bus? - Bert - _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
