[Desktop_architects] klik+autopackage: klik slides in ASCII (was: Notes from autopackage author)

2005-12-31 Thread Kurt Pfeifle
I received a mail from someone who said that the klik slides (as PDF) are no longer retrievable from the OSDL website. So I'll now provide an ASCII copy of these (only 4 pages) of slides, for the sake of this discussion. Sli

[Desktop_architects] klik+autopackage: More info about the example packages (was: Notes from autopackage author)

2005-12-31 Thread Kurt Pfeifle
> A few suggested applications to test klik with: > --- > (I'll post some more extended descriptions in one of my next mails) In my last mail I suggested a mix of klik-ified applications to play with, in order to gain an overview about klik's current s

[Desktop_architects] klik+autopackage: Overview (was: Notes from autopackage author)

2005-12-31 Thread Kurt Pfeifle
On Sunday 27 November 2005 16:58, Bryce Harrington wrote: > On Sun, Nov 27, 2005 at 01:09:54PM +0100, Martin Konold wrote: > > Am Freitag, 25. November 2005 08:29 schrieb Bryce Harrington: > > > another have some trouble getting a given rpm installed on their > > > system, due to dependency, glibc

Re: [Desktop_architects] Re: Desktop Services

2005-12-31 Thread Michael Sweet
Aaron J. Seigo wrote: ... note that such a customization effort would almost certainly move ahead quickest if driven by ISVs with custom data formats as we in the open source desktop world don't have a lot of motivation here. in other words, this wold be a great open source project for ISVs to

Re: [Desktop_architects] Printing dialog and GNOME

2005-12-31 Thread Dan Kegel
On 12/31/05, Aaron J. Seigo <[EMAIL PROTECTED]> wrote: > note that this doesn't replace X/Qt/Gtk+/whatever APIs, but rather wraps them > in a common IPC layer for those who can't, don't want to or simply won't > write directly to those APIs but who also wish for their app to integrate > nicely with

Re: [Desktop_architects] Re: Desktop Services

2005-12-31 Thread Aaron J. Seigo
On Saturday 31 December 2005 10:24, Michael Sweet wrote: > Sigh. Nothing should prevent a custom dialog from using the base > services to grab the preview image, etc. for a file. I.e. there should > be a common set of APIs, not specific to a particular toolkit, which > provide access to this stuf

Re: [Desktop_architects] Printing dialog and GNOME

2005-12-31 Thread Aaron J. Seigo
On Saturday 31 December 2005 10:51, Dan Kegel wrote: > My impression is that he wants to replace all of the > current set of X / gnome / qt APIs with a new one based > on web services. i'm not involved with RUDI myself, but i have listened to what has been said by those who are and the goal and p

Re: [Desktop_architects] Printing dialog and GNOME

2005-12-31 Thread Dan Kegel
On 12/31/05, Michael Sweet <[EMAIL PROTECTED]> wrote: > >> The goal, I thought, was for RUDI to provide access to a common set of > >> dialogs (file and print have been suggested so far) and not to suddenly > >> become a system-level library providing all common services and UIs. > > > > Actually t

Re: [Desktop_architects] Printing dialog and GNOME

2005-12-31 Thread Michael Sweet
Martin Konold wrote: Am Montag, 19. Dezember 2005 14:00 schrieb Michael Sweet: Hi Michael, The goal, I thought, was for RUDI to provide access to a common set of dialogs (file and print have been suggested so far) and not to suddenly become a system-level library providing all common services

[Desktop_architects] Re: Desktop Services

2005-12-31 Thread Michael Sweet
Martin Konold wrote: Am Dienstag, 20. Dezember 2005 20:25 schrieben Sie: Hi Michael, E.g. KDE offers a file open dialog with preview capabilities. This capability is build into the dialog without a call back to the application calling the dialog. I should be more careful with my wording. Wit