Le Fri, 15 Apr 2011 15:18:47 -0400,
Colin Walters walt...@verbum.org a écrit :
On Mon, Mar 28, 2011 at 4:07 AM, Martyn Russell mar...@lanedo.com
wrote:
Sounds like a god idea.
I try to be modest, but it's hard to turn down deification...
At this point, I would like to just mention
On Sun, Mar 27, 2011 at 4:20 AM, Vincent Untz vu...@gnome.org wrote:
But we still want the merge logic to build menus. So it sounds to me
that what you want is to make gnome-menus use a mmaped file.
Well, what I think a simple first step is for gnome-menus to just
categorize the results of
Hi Martin,
On Fri, Mar 25, 2011 at 2:55 PM, Martin Pitt martin.p...@ubuntu.com wrote:
Just for the record I would like to explain the approach that we have
had in Ubuntu since December 09. It might not be too useful any more,
but can perhaps at least give some pointers. Vincent didn't like
On Mon, Mar 28, 2011 at 4:07 AM, Martyn Russell mar...@lanedo.com wrote:
Sounds like a god idea.
I try to be modest, but it's hard to turn down deification...
At this point, I would like to just mention that Tracker already mines
applications and it is REALLY fast at this.
My first reaction
Hi guys, I had to give DBUS a try, so I went and modified the gdbus test
to get some numbers.
Running a thousand transactions takes about 1.5 seconds and there is no
big difference if the we transfer 50 bytes or 4 kbytes.
Here is the output of the test on my machine (Athlon 64 x2 5600+ with
DDR2
Le Wed, 30 Mar 2011 15:46:03 -0300,
Juan Pablo Ugarte juanpablouga...@gmail.com a écrit :
Hi guys, I had to give DBUS a try, so I went and modified the gdbus
test to get some numbers.
Running a thousand transactions takes about 1.5 seconds and there is
no big difference if the we transfer
Le mercredi 30 mars 2011 à 22:01 +0300, Adrien Bustany a écrit :
Note that for big data transfers, using FD passing and a socket is
quite faster, but probably overkill here.
This is what we use for file transfer in Telepathy.
regards,
Nicolas
signature.asc
Description: This is a digitally
My point is, using dbus to transfer desktop entries is not a bad idea because
of speed issues.
Besides this would be desktop agnostic and not a gnome custom implementation.
Cheers
Juan Pablo
Enviado desde mi iPhone
El 30/03/2011, a las 17:25, Nicolas Dufresne nicolas.dufre...@collabora.co.uk
On 25/03/11 03:22, Colin Walters wrote:
Bugzilla is down or I'd write this there, and it's a bit lengthy to
fit in the SoC wiki page, so I'll just post here and link from the
wiki.
Hi,
== Kill gnome-menus ==
gnome-menus is the library which reads all this stuff presently, and
it has one
On Mon, 28 Mar 2011 09:07:36 +0100, Martyn Russell wrote:
On 25/03/11 03:22, Colin Walters wrote:
Bugzilla is down or I'd write this there, and it's a bit lengthy to
fit in the SoC wiki page, so I'll just post here and link from the
wiki.
Hi,
== Kill gnome-menus ==
gnome-menus is the
Le vendredi 25 mars 2011, à 21:52 +, Bastien Nocera a écrit :
On Sat, 2011-03-26 at 03:11 +0530, Nirbheek Chauhan wrote:
snip
I was thinking that this is the kind of problem that has cross-desktop
implications, and so I wondered how KDE solves this problem. We should
probably take
Le jeudi 24 mars 2011, à 23:22 -0400, Colin Walters a écrit :
== Kill gnome-menus ==
gnome-menus is the library which reads all this stuff presently, and
it has one serious drawback:
* It is entirely synchronous
This especially hurts since we have to read applications from
gnome-shell,
On Sun, 2011-03-27 at 10:17 +0200, Vincent Untz wrote:
Le vendredi 25 mars 2011, à 21:52 +, Bastien Nocera a écrit :
On Sat, 2011-03-26 at 03:11 +0530, Nirbheek Chauhan wrote:
snip
I was thinking that this is the kind of problem that has cross-desktop
implications, and so I wondered
Bastien Nocera [2011-03-25 21:52 +]:
I wouldn't want the code to live in update-desktop-database (which is in
shared-mime-info), but we can certainly add support for launching
scripts in a specific directory whenever it's called.
Or just call it update-desktop-caches and stay a separate
Hey Colin,
On Thu, Mar 24, 2011 at 11:22 PM, Colin Walters walt...@verbum.org wrote:
The next question is how does the cache get rebuilt? I think we
basically need a system service with an inotify (GFileMonitor) watch
on all those directories, and it takes care of rebuilding it.
Sounds good,
On Fri, Mar 25, 2011 at 6:11 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
There are multiple ways to approach this, but I think by far the
simplest is just an mmap'able file containing all .desktop files found
in the desktop paths.
This depends. First comment on the shell is man pthreads,
On Fri, Mar 25, 2011 at 5:03 AM, David Zeuthen zeut...@gmail.com wrote:
Sounds good, but we really want a session-service [0] instead of a
system-service
I would say system *and* session service. But honestly I'm not too
concerned right now about overhead of apps installed in ~/.local,
since
mmap MAP_SHARED also makes dealing with external updating really
interesting because if the file shrinks you need to handle signal
exceptions from touching pages that no longer exist.
Not if the cache is replaced with rename(), no?
If the sequence is
build new cache
On Fri, Mar 25, 2011 at 7:43 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote:
then the existing users will continue to see the old file which will only
vanish completely on the last close.
Right, hence the inotify watch. Though actually, this makes me notice
we aren't monitoring the GTK+ icon
On Fri, 2011-03-25 at 11:43 +, Alan Cox wrote:
mmap MAP_SHARED also makes dealing with external updating really
interesting because if the file shrinks you need to handle signal
exceptions from touching pages that no longer exist.
Not if the cache is replaced with rename(), no?
Hi!
After reading Alan's and David's comment it occurs to me that it could
be way simpler to have a dbus-service handling the desktop files and
anybody wanting to access the desktop files in a fast way can use that
service (through a library wrapper).
This would make all the cache problems much
On Fri, Mar 25, 2011 at 11:12 AM, Johannes Schmid j...@jsschmid.de wrote:
Hi!
After reading Alan's and David's comment it occurs to me that it could
be way simpler to have a dbus-service handling the desktop files and
anybody wanting to access the desktop files in a fast way can use that
On Thu, 2011-03-24 at 23:22 -0400, Colin Walters wrote:
Bugzilla is down or I'd write this there, and it's a bit lengthy to
fit in the SoC wiki page, so I'll just post here and link from the
wiki.
If it's important for 3.2, it shouldn't be a Google Summer Of Code
project. The SoC isn't about
Hello all,
Colin Walters [2011-03-25 12:18 +0100]:
== Desktop File Cache ==
There are multiple ways to approach this, but I think by far the
simplest is just an mmap'able file containing all .desktop files found
in the desktop paths. Don't try to implement all the merge logic,
etc.
I'm
Hey everyone,
On Sat, Mar 26, 2011 at 12:25 AM, Martin Pitt martin.p...@ubuntu.com wrote:
Colin Walters [2011-03-25 12:18 +0100]:
== Desktop File Cache ==
There are multiple ways to approach this, but I think by far the
simplest is just an mmap'able file containing all .desktop files found
On Sat, 2011-03-26 at 03:11 +0530, Nirbheek Chauhan wrote:
snip
I was thinking that this is the kind of problem that has cross-desktop
implications, and so I wondered how KDE solves this problem. We should
probably take their feedback on this?
On the other hand, I think there is a way to do
Bugzilla is down or I'd write this there, and it's a bit lengthy to
fit in the SoC wiki page, so I'll just post here and link from the
wiki.
== Desktop File Cache ==
Because GNOME doesn't have an application installation story, a lot of
OS creators simply ship with a lot of apps. An app here is
27 matches
Mail list logo
