Re: KDE Interop [Was: D-BUS background]



Well, in the example I described, there is no communication between
embedded components, it's only communication between totally independent
apps: the file dialog would be an app in itself.


Le dim 02/03/2003 à 23:11, Chris Chabot a écrit :
> Damn, and i was trying to be so carefully keeping UI components and backend
> services seperated! ;-)
> 
> To quote from HP's "d-bus in the big picture" email:
> 
> ....
> Non-use-cases for message bus
>  - widget embedding. I don't believe we should have communication
>    between a shell such as the file manager, and embedded components
>    in the file manager, going via the message bus daemon.
>   I would tend to design widget embedding by specifying an in-process
>    component interface, and then adding some way to proxy that to an
>    IPC mechanism. The IPC may be "network transparent" or may need to
>    be explicit, if the shell is paranoid about locked-up components.
> ....
> 
> 
> 
> 
> ----- Original Message -----
> From: "Julien Olivier" <julo altern org>
> To: "Chris Chabot" <chabotc xs4all nl>
> Cc: <desktop-devel-list gnome org>
> Sent: Sunday, March 02, 2003 22:40
> Subject: Re: KDE Interop [Was: D-BUS background]
> 
> 
> > On the same idea, wold D-BUS help create a common file dialog ? Here's
> > my idea:
> >
> > There should be a file dialog daemon with chich any app (based on GTK,QT
> > or any toolkit) could communicate and ask it to display the file dialog
> > (written in GTK or QT or X or whatever), passing options to it (MIME
> > type filters for example) and getting the URI back from the file dialog.
> >
> > Do you think D-BUS could help here ?
> >
> >
> >
> 
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]