Colin Walters wrote:
On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote:
A concurrent cache is fairly straightforward; concurrent SSL certificate
database I don't really want to think about =)
Many appologies for the awkwardly late response, but...
gnome-keyring will do this for you in 2.22
On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote:
H
Can you check out http://live.gnome.org/LibSoup/DesktopWideHttp and see
if there's anything missing?
This looks good overall.
Are there any libsoup python bindings?
By far the most important thing from my perspective is read-only
Colin Walters wrote:
On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote:
H
Can you check out http://live.gnome.org/LibSoup/DesktopWideHttp and see
if there's anything missing?
This looks good overall.
Are there any libsoup python bindings?
No, no one has ever asked about doing
On Tue, 2007-11-27 at 13:35 -0500, Dan Winship wrote:
No, no one has ever asked about doing bindings of libsoup before,
probably because every other language already has its own standard http
library. But of course, none of them have glib main loop integration and
stuff like that.
Right.
On Mon, 2007-11-26 at 10:05 -0500, Dan Winship wrote:
Havoc Pennington wrote:
I do think libsoup, gnome-vfs, neon, and curl are all bad answers
long-term for apps that want to use web APIs or download an icon. The
right answer will address among other things how to share cookies and
Hi,
Dan Winship wrote:
Havoc Pennington wrote:
I do think libsoup, gnome-vfs, neon, and curl are all bad answers
long-term for apps that want to use web APIs or download an icon.
To be clear, I wasn't trying to say here that none of these could be
made a good answer, just that they aren't
- it seems inevitable that both gnome-http-lib and Firefox would need
to rely on some type of common repository of cookies, etc. and that
this repo would be managed by some type of daemon that handled
locking and change-notification; said daemon would need to be able
to run
On Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote:
That's all very interesting, but what about a better integration
of on-line applications in the desktop environment like regular
applications? Have you seen, for instance, prism?
http://labs.mozilla.com/2007/10/prism/
I think
On Nov 22, 2007 6:40 AM, Alp Toker [EMAIL PROTECTED] wrote:
Colin Walters wrote:
On Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote:
That's all very interesting, but what about a better integration
of on-line applications in the desktop environment like regular
applications?
On Nov 21, 2007 3:40 PM, Alp Toker [EMAIL PROTECTED] wrote:
Colin Walters wrote:
On Tue, 2007-11-20 at 15:23 -0200, Pedro de Medeiros wrote:
That's all very interesting, but what about a better integration
of on-line applications in the desktop environment like regular
applications?
John Stowers wrote:
For example, the new shiny HTML5 client db stuff in webkit [2] will go
some way to allowing desktop apps to be written in HTML/JS and then
run inside a light webkit shell, but can we do better. What about
* A simple way to start a webkit browser widget associated with a
On Nov 1, 2007 7:16 PM, John Stowers [EMAIL PROTECTED] wrote:
On 11/2/07, Colin Walters [EMAIL PROTECTED] wrote:
John Stowers wrote:
But at the moment this particular 'PDA' requires a different way for
it to be connected. As I explained earlier, the other 'PDA's we
support are either
John Stowers wrote:
But at the moment this particular 'PDA' requires a different way for
it to be connected. As I explained earlier, the other 'PDA's we
support are either connected(), disconnected(), or we ask for the user
to connect them (log in) while we wait. I am interested in providing a
On 11/2/07, Colin Walters [EMAIL PROTECTED] wrote:
John Stowers wrote:
But at the moment this particular 'PDA' requires a different way for
it to be connected. As I explained earlier, the other 'PDA's we
support are either connected(), disconnected(), or we ask for the user
to connect
On Wed, 2007-10-31 at 18:55 +1300, John Stowers wrote:
Hiya
After spending some time trying to integrate Conduit with
online-desktop lately, I thought I should share my thoughts.
a)
The build provess for hippo
(http://svn.mugshot.org/dumbhippo/trunk/client) is overly complex on
account
Hi,
John Stowers wrote:
a)
The build provess for hippo
(http://svn.mugshot.org/dumbhippo/trunk/client) is overly complex on
account of things for windows and osx in there. This includes a
dependency on firefox and a huge bunch of statically built libraries.
This seems a bit excessive.
The
Hiya,
b)
There is no way to login to programatically to online desktop using
either the dbus api or another manner. This is different to many many
other web apis and makes it difficult to reliably use the api from
outside mugshot.
I don't quite understand this point. The general idea
On Thu, 2007-11-01 at 09:20 +1300, John Stowers wrote:
Hiya,
b)
There is no way to login to programatically to online desktop using
either the dbus api or another manner. This is different to many many
other web apis and makes it difficult to reliably use the api from
outside
[ excellent detailed description omitted ]
What if you don't think of online.gnome.org as a web service; what if
you think of it like a PDA someone plugged into their USB port?
Excellent!
Apologies if I mis/over-interpret your analogy but this is EXCATLY how
I think about online.gnome.org
Le lundi 29 octobre 2007 à 17:43 -0400, Owen Taylor a écrit :
This isn't a module proposal, but I wanted to start a conversation about
how we can move the online desktop work closer to the GNOME release
process and maybe get it lined up up for 2.24.
While the response to the overall idea of
Frederic Crozat wrote:
Hmm, is libcurl really needed ?
libcurl is conceptually a dependency in the online desktop application
layer (specifically a panel applet). Longer term though we should
probably replace the usage of curl here with python.
___
On Tue, 2007-10-30 at 16:22 -0400, Colin Walters wrote:
Frederic Crozat wrote:
Hmm, is libcurl really needed ?
libcurl is conceptually a dependency in the online desktop application
layer (specifically a panel applet). Longer term though we should
probably replace the usage of curl here
Hi,
Hubert Figuiere wrote:
On Tue, 2007-10-30 at 16:22 -0400, Colin Walters wrote:
Frederic Crozat wrote:
Hmm, is libcurl really needed ?
libcurl is conceptually a dependency in the online desktop application
layer (specifically a panel applet). Longer term though we should
probably
On Tue, 2007-10-30 at 16:22 -0400, Colin Walters wrote:
Frederic Crozat wrote:
Hmm, is libcurl really needed ?
libcurl is conceptually a dependency in the online desktop application
layer (specifically a panel applet). Longer term though we should
probably replace the usage of curl here
Hi,
Philip Withnall wrote:
Would we really want a potentially core part of the desktop to be
implemented in Python? :-(
Colin is talking about the mugshot stacker app, not the parts that would
be potentially core.
(Though, I do think python is questionable for tray icons and daemons,
On Tue, 2007-10-30 at 21:02 +, Philip Withnall wrote:
On Tue, 2007-10-30 at 16:22 -0400, Colin Walters wrote:
Frederic Crozat wrote:
Hmm, is libcurl really needed ?
libcurl is conceptually a dependency in the online desktop application
layer (specifically a panel applet). Longer
Hi,
jamie wrote:
(the UI frontend or applet can remain in python of course but the
interface to the online world should be C if possible)
And it is.
Havoc
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
On Ter, 2007-10-30 at 17:10 -0400, Havoc Pennington wrote:
(Though, I do think python is questionable for tray icons and daemons,
since for whatever reason each python / pygtk process is so huge.
Well, last I checked, the cpython implementation *never* releases memory
back to the OS. This is
On Tue, 2007-10-30 at 21:02 +, Philip Withnall wrote:
Would we really want a potentially core part of the desktop to be
implemented in Python? :-(
Can we please stop wasting everybody's time with
I-don't-like-your-choice-of-language discussions?
Fix the resource consumption issues if you
Rui Tiago Cação Matos wrote:
On Ter, 2007-10-30 at 17:10 -0400, Havoc Pennington wrote:
(Though, I do think python is questionable for tray icons and daemons,
since for whatever reason each python / pygtk process is so huge.
Well, last I checked, the cpython implementation *never* releases
Hiya
After spending some time trying to integrate Conduit with
online-desktop lately, I thought I should share my thoughts.
a)
The build provess for hippo
(http://svn.mugshot.org/dumbhippo/trunk/client) is overly complex on
account of things for windows and osx in there. This includes a
This isn't a module proposal, but I wanted to start a conversation about
how we can move the online desktop work closer to the GNOME release
process and maybe get it lined up up for 2.24.
While the response to the overall idea of the Online Desktop has been
very positive, both at GUADEC and the
32 matches
Mail list logo
