Re: gnome 2.19 schedule.

[Étienne Bersac]

Hi,

In fact, imcapd is going to be a HAL add-on, but registering dbus call
in order to reclaim/release device. Donald, can you confirm that ?

Étienne.
-- 
Verso l'Alto !

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Totem branched for 2.18

[Bastien Nocera]

SSIA

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Totem branched for 2.18

[Lucas Rocha]

Hi Bastien,

What are your plans for GNOME 2.20?

--lucasr

2007/3/19, Bastien Nocera <[EMAIL PROTECTED]>:
> SSIA
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

control-center branched for 2.18

[Rodrigo Moya]

gnome-control-center module has been branched, so now there is a
gnome-2-18 branch for 2.18 development.

As for plans:
* rename the tarball at last to gnome-control-center
* capplets merging. Still in discussion, so nothing definitive yet here
* g-s-d refactoring to, at last, simplify it and reduce code duplication
-- 
Rodrigo Moya <[EMAIL PROTECTED]>

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-vfs, eel, nautilus branched for 2.18

[Alexander Larsson]

Gnome-vfs, eel and nautilus has branched for 2.18. The 2.18 development
continues on the gnome-2-18 branch.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   [EMAIL PROTECTED][EMAIL PROTECTED] 
He's an otherworldly Catholic ex-con possessed of the uncanny powers of an 
insect. She's a pregnant gypsy pearl diver who believes she is the 
reincarnation of an ancient Egyptian queen. They fight crime! 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-vfs, eel, nautilus branched for 2.18

[Lucas Rocha]

HI Alex,

What are your plans for 2.20 for gnome-vfs, eel and nautilus?

Cheers!

--lucasr


2007/3/19, Alexander Larsson <[EMAIL PROTECTED]>:
> Gnome-vfs, eel and nautilus has branched for 2.18. The 2.18 development
> continues on the gnome-2-18 branch.
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  Alexander LarssonRed Hat, Inc
>[EMAIL PROTECTED][EMAIL PROTECTED]
> He's an otherworldly Catholic ex-con possessed of the uncanny powers of an
> insect. She's a pregnant gypsy pearl diver who believes she is the
> reincarnation of an ancient Egyptian queen. They fight crime!
>
> ___
> gnome-i18n mailing list
> gnome-i18n@gnome.org
> http://mail.gnome.org/mailman/listinfo/gnome-i18n
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-vfs, eel, nautilus branched for 2.18

[Alexander Larsson]

On Mon, 2007-03-19 at 13:52 +0200, Lucas Rocha wrote:
> HI Alex,
> 
> What are your plans for 2.20 for gnome-vfs, eel and nautilus?
> 
> Cheers!

The plan is to replace gnome-vfs with gvfs.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   [EMAIL PROTECTED][EMAIL PROTECTED] 
He's a benighted sweet-toothed jungle king living undercover at Ringling Bros. 
Circus. She's a time-travelling hip-hop mercenary from aristocratic European 
stock. They fight crime! 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome 2.19 schedule.

[Donald Straney]

> In fact, imcapd is going to be a HAL add-on, but registering dbus call
> in order to reclaim/release device. Donald, can you confirm that ?

Right, it could definitely do that as a HAL addon.  Each scanner could
have ReleaseDevice and ReclaimDevice methods which would make it
temporarily close the device so another program could use it, but that
still seems like a hack.  I guess the real solution here would be to
make sure all SANE drivers can take multiple connections, but I don't
know if that's possible (maybe some hardware limits it to one
connection?).  Does anyone know more about this?

So using libusb directly would get around locking problems?  Sounds
good, but it seems like we'd end up with a bunch of duplicated driver
code, and what if a SCSI scanner or parallel-port scanner has buttons?
 It's not likely, but it seems better to keep it flexible instead of
tying it into USB.

Donald Straney
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: control-center branched for 2.18

[Elijah Newren]

On 3/19/07, Rodrigo Moya <[EMAIL PROTECTED]> wrote:
> gnome-control-center module has been branched, so now there is a
> gnome-2-18 branch for 2.18 development.

Adding gnome-doc-list and r-t to the cc list; please don't forget them
in future branching notices (complete list of who should be cc is in
bold at http://live.gnome.org/MaintainersCorner, which is linked to
from the bugzilla product overview page,
bugzilla.gnome.org/browse.cgi).

Thanks,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Totem branched for 2.18

[Elijah Newren]

On 3/19/07, Bastien Nocera <[EMAIL PROTECTED]> wrote:
> SSIA

Adding gnome-doc-list to the cc list; please don't forget them in
future branching notices (complete list of who should be cc is in bold
at http://live.gnome.org/MaintainersCorner, which is linked to from
the bugzilla product overview page, bugzilla.gnome.org/browse.cgi).

Thanks,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-vfs, eel, nautilus branched for 2.18

[Elijah Newren]

On 3/19/07, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> Gnome-vfs, eel and nautilus has branched for 2.18. The 2.18 development
> continues on the gnome-2-18 branch.

Adding gnome-doc-list to the cc list; please don't forget them in
future branching notices (complete list of who should be cc is in bold
at http://live.gnome.org/MaintainersCorner, which is linked to from
the bugzilla product overview page, bugzilla.gnome.org/browse.cgi).

Thanks,
Elijah
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome 2.19 schedule.

[Étienne Bersac]

Hi,

Does libusb allow to lock device ? Does libusb actually access a device
locked by another process ?

About usb-only. It's up to you to implement different devices and
protocols.

Étienne.
-- 
Verso l'Alto !

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Desktop sounds in Gnome

[Étienne Bersac]

Hi,

What's up on the sound system front for Gnome ? Since Marc-André Lureau
has been kidnapped by Nokia, GSmartMix development has be stopped :| The
same apply to desktop sound library.

So, will gnome 2.20 play nice sound when disk is burn, sound volume
increased, mail received/sent, new RSS item available, etc. ? Would the
system sounds be themable like icons are ?

So, aside from the pulseaudio flamewar, what to do to improve desktop
sounds in Gnome ?

Don't forget to celebrate Gnoem 2.18 before the flamewar ! ;P

Étienne.
-- 
Verso l'Alto !

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Desktop sounds in Gnome

[Richard Hughes]

On 19/03/07, Étienne Bersac <[EMAIL PROTECTED]> wrote:
> So, will gnome 2.20 play nice sound when disk is burn, sound volume
> increased, mail received/sent, new RSS item available, etc. ? Would the
> system sounds be themable like icons are ?

It would be great to theme these like we can icons.
gnome-power-manager just needs to play a "battery low" chime, and
linking to gstreamer seems very heavyweight.

I think we need three things:

* A system sounds freedesktop standard (ala, tango)
* An easier way to plug in configuration to the existing sound capplet
* A sound server that works, i.e. works with the user theme, and we
can just play ("low-power");

How many of these things already exist and are usable in one form or another?

Richard
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Desktop sounds in Gnome

[Gustavo J. A. M. Carneiro]

On Seg, 2007-03-19 at 17:48 +, Richard Hughes wrote:
> On 19/03/07, Étienne Bersac <[EMAIL PROTECTED]> wrote:
> > So, will gnome 2.20 play nice sound when disk is burn, sound volume
> > increased, mail received/sent, new RSS item available, etc. ? Would the
> > system sounds be themable like icons are ?
> 
> It would be great to theme these like we can icons.
> gnome-power-manager just needs to play a "battery low" chime, and
> linking to gstreamer seems very heavyweight.
> 
> I think we need three things:
> 
> * A system sounds freedesktop standard (ala, tango)
> * An easier way to plug in configuration to the existing sound capplet
> * A sound server that works, i.e. works with the user theme, and we
> can just play ("low-power");
> 
> How many of these things already exist and are usable in one form or another?

  We also need said sound server to not suck.  On Linux systems it must
1) use ALSA, and 2) work well with dmix and allow other applications
(e.g. flash plugin) to use ALSA directly.  Pulse Audio at least doesn't
qualify for the second point.  Esound doesn't qualify for either.

-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Desktop sounds in Gnome

[Richard Hughes]

On 19/03/07, Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> wrote:
> On Seg, 2007-03-19 at 17:48 +, Richard Hughes wrote:
> > On 19/03/07, Étienne Bersac <[EMAIL PROTECTED]> wrote:
> > > So, will gnome 2.20 play nice sound when disk is burn, sound volume
> > > increased, mail received/sent, new RSS item available, etc. ? Would the
> > > system sounds be themable like icons are ?
> >
> > It would be great to theme these like we can icons.
> > gnome-power-manager just needs to play a "battery low" chime, and
> > linking to gstreamer seems very heavyweight.
> >
> > I think we need three things:
> >
> > * A system sounds freedesktop standard (ala, tango)
> > * An easier way to plug in configuration to the existing sound capplet
> > * A sound server that works, i.e. works with the user theme, and we
> > can just play ("low-power");
> >
> > How many of these things already exist and are usable in one form or 
> > another?
>
>   We also need said sound server to not suck.  On Linux systems it must
> 1) use ALSA, and 2) work well with dmix and allow other applications
> (e.g. flash plugin) to use ALSA directly.  Pulse Audio at least doesn't
> qualify for the second point.  Esound doesn't qualify for either.

ESound is off the radar. PulseAudio is the best we've got by far, and
seems to work with most stuff I've thrown at it.

So we have a sound server. Can this play themed sounds?

Richard.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Desktop sounds in Gnome

[Étienne Bersac]

Hi,

I do fully agree with you. The problem is the implementation choice and
who will implement it. Marc-André Lureau made a proposal for a desktop
sound library for freedesktop (in C).

Can't recal the URI

Étienne.
-- 
Verso l'Alto !

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Desktop sounds in Gnome

[Richard Hughes]

On 19/03/07, Étienne Bersac <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I do fully agree with you. The problem is the implementation choice and
> who will implement it. Marc-André Lureau made a proposal for a desktop
> sound library for freedesktop (in C).

Can somebody do this as part of google summer of code? Or one of the
big distros (redhat, suse, ubuntu, etc) assign someone to this?

Richard.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Desktop sounds in Gnome

[Rodney Dawes]

On Mon, 2007-03-19 at 18:01 +, Richard Hughes wrote:
> So we have a sound server. Can this play themed sounds?

Once upon a time, I started a sound theme spec, based on the
current Icon Theme specification, and sounds implementation
in GNOME, as I have no idea how the KDE sound themes work.
When I sent this to the XDG list, it received nothing but
push back from all the KDE people on the list.

Perhaps it's time to propose such a spec again, with a little
revision, so that we can use it for both KDE and GNOME. We
can also specify some basic desktop sound events.

However, while it's great to have sounds for events in the
desktop, there are other useful configuration options as
well. I think it would be extremely useful to have an "events"
spec which would deal with the events portion, and a sound
theme spec to only deal with the sounds portion. The events
spec could define basic desktop events, and what potential
actions could be taken, such as play a sound, show a notification
bubble, or run a program.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Desktop sounds in Gnome

[Étienne Bersac]

Hi all,

Thanks to Marc-André, here is the link to his draft for a Desktop sound
API : http://etudiant.epita.fr/~lureau_m/ds-0.1/

Étienne.
-- 
Verso l'Alto !

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Desktop sounds in Gnome

[Marc-André Lureau]

Hi all,

@richard: A SoC project? why not, but there should be an agreement before
someone /waste/ time.
Tango for sound? BANGO! (http://freedesktop.org/wiki/Bango)

@rodney: I used your spec. It would be great to put it for real on fdo, with
the xml (ala http://standards.freedesktop.org/icon-theme-spec/).

@gustavo: there is a flash support for PulseAudio (
http://pulseaudio.revolutionlinux.com/PulseAudio)

@etienne: well, true, I have been kidnapped in the country of trolls, Santa
Claus, 1000 lakes (and bad-food said our actual president, especially
coffee)... how lucky I am! The sound API proposal I made is
http://etudiant.epita.fr/~lureau_m/ds-0.1/.
But this is ongoing work, the basic idea is that such API would offer
everything you need for sound except audio streaming. That means, instead of
dealing with streams, you only deal with sound objects. That is much easier
to understand and to deal with for most of us. Of course, the simple use
case of this API is ds_play ("bling"), and it will support theming. It is
very clear to me that at this point, we are not discussing the
implementation (whether the call is made to a server with dbus, or if the
sound is played in-process with dmix and some audiolib, or using PulseAudio
private protocol...). But I think it is important to provide a compatible
D-Bus API at the same time (I did it),  thus its easy to have a service on
top of the actual implementation. And it helps to define the interfaces.

Lennart P., Jean-Marc V. and Mikko L. did some preliminary work on a simple
audio/PCM streaming API for the desktop, libsydney (see
http://0pointer.de/blog/projects/foms-lca-recap.html).

Lennart would like to provide a much simpler sound API with libsydney. That
could be, of course, the final consensus. I have my own POV about libsydney,
and I hope to meet some of you in Berlin at the end of the week to discuss
it 
(http://www.kgw.tu-berlin.de/~lac2007/index.shtml).
I really hope that you can make it Lennart.

Ok now start the flame: everyone think these works  are duplicate of
something (if you look at my proposal, I really did study a lot of API).
IMHO, they are not. Somehow, for me, the goal for a sound API is similar to
DAPI (
http://lists.freedesktop.org/archives/portland/2007-January/thread.html#929)

The notification service offers some sound event API. It could be the place
where my proposal would be used. Then desktop app should only use
Notification API.
But I don't see background music in a game as a notification. Of course
GStreamer should be used then. But if you think about it, the abstraction we
need, in fact, is the GStreamer playbin API. I like Phonon for this reason.
By chance, nothing need to be changed: ds_play ("/usr/local../toto.mp3")

A better sound & PCM API is necessary to get rid of Esound correctly (
http://live.gnome.org/PulseAudio). Then GNOME will start to offer a better
sound experience and it will be time to reconsider GSmartMix again
(@etienne: the project is not dead ;)

Hopefully Gmail will not screwed up the links this time...

Cheers,

--
Marc-André Lureau, GSmartMix

On 3/19/07, Rodney Dawes <[EMAIL PROTECTED]> wrote:


On Mon, 2007-03-19 at 18:01 +, Richard Hughes wrote:
> So we have a sound server. Can this play themed sounds?

Once upon a time, I started a sound theme spec, based on the
current Icon Theme specification, and sounds implementation
in GNOME, as I have no idea how the KDE sound themes work.
When I sent this to the XDG list, it received nothing but
push back from all the KDE people on the list.

Perhaps it's time to propose such a spec again, with a little
revision, so that we can use it for both KDE and GNOME. We
can also specify some basic desktop sound events.

However, while it's great to have sounds for events in the
desktop, there are other useful configuration options as
well. I think it would be extremely useful to have an "events"
spec which would deal with the events portion, and a sound
theme spec to only deal with the sounds portion. The events
spec could define basic desktop events, and what potential
actions could be taken, such as play a sound, show a notification
bubble, or run a program.

-- dobey


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

are gnome-display-properties and gnome-keyring-manager going to be replaced?

[David Prieto]

I read in http://www.gnome.org/start/2.18/notes/C/ that seahorse is a
part of Gnome now. Since it can handle keyrings, are there plans to have
it replace gnome-keyring-manager? Will they coexist, or is seahorse just
not gonna be installed by default?

More or less the same happens with a new display configuration tool
(http://glatzor.de/node/22) that is being developed, which handles all
the option managed by gnome-display-properties and those about dual
displays and drivers. Do you find it possible that it might end up
replacing gnome-display-properties?

Regards,

David.

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: are gnome-display-properties and gnome-keyring-manager going to be replaced?

[Adam Schreiber]

On 3/19/07, David Prieto <[EMAIL PROTECTED]> wrote:
> I read in http://www.gnome.org/start/2.18/notes/C/ that seahorse is a
> part of Gnome now. Since it can handle keyrings, are there plans to have
> it replace gnome-keyring-manager? Will they coexist, or is seahorse just
> not gonna be installed by default?

http://mail.gnome.org/archives/desktop-devel-list/2007-March/msg00120.html

Cheers,

Adam
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

My work on Seahorse

[Nate Nielsen]

During the next GNOME release cycle I hope to work more on x509
certificates in GNOME. No promises, but I'd like to announce what I'm
working on so that there's no overlap with other's work and obviously if
anyone has ideas...

I'd like to make a GNOME certificate store (similar to what Windows and
Mac OSX provide) which libraries like NSS, gnutls and others plug into.
This will allow certificates to be shared between applications.

I've looked at PKCS #11 which seems is a standard for this sort of thing.

I hope to store the private keys in the user's gnome-keyring and
protected them with the keyring password. A PKCS #11 module provided by
gnome-keyring would plug into epiphany, firefox, evolution etc...

Cheers,
Nate Nielsen

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Evolution and friends branched for GNOME 2.18

[Harish Krishnaswamy]

Hi,

I've just branched evolution, evolution-data-server, GtkHTML and
evolution-exchange for GNOME 2.18.  New development will happen in the
trunk and bug fixes too (the important ones on the stable branch as
well).

Do join us for the roadmap discussions and plans for Evolution 2.12[1]
 on http://go-evolution.org.

Thanks,
Harish

[1] There is a suggestion that Evolution should synchronize its
version numbers with the GNOME release and this is up for
consideration too. So let us just call it the next Evolution
development series (unstable).

-- 
Pure in heart, like uncut jade,
he cleared the muddy water
by leaving it alone.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GNOME x509 Certificate and Key Store

[Nate Nielsen]

[Apologies for the second copy. In a classic brain fart, I used the
subject line of another email I was composing.]

During the next GNOME release cycle I hope to work more on x509
certificates in GNOME. No promises, but I'd like to announce what I'm
working on so that there's no overlap with others' work. And obviously
if anyone has concerns or ideas I'd like to hear them...

I'd like to make a GNOME certificate store (similar to what Windows and
Mac OSX provide) which libraries like NSS, gnutls and others can plug
into. This will allow certificates to be shared between applications.

I'll probably use PKCS #11 which is a standard for this sort of thing.

I hope to store the private keys in the user's gnome-keyring and
protected them with the keyring password. A PKCS #11 module provided by
gnome-keyring would plug into epiphany, firefox, evolution etc...

Cheers,
Nate Nielsen

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My work on Seahorse

[Étienne Bersac]

Wow, very nice ! Keep up the good work ;)

Étienne.
-- 
Verso l'Alto !

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome 2.19 schedule.

[David Zeuthen]

On Mon, 2007-03-19 at 10:30 -0400, Donald Straney wrote:
> > In fact, imcapd is going to be a HAL add-on, but registering dbus call
> > in order to reclaim/release device. Donald, can you confirm that ?
> 
> Right, it could definitely do that as a HAL addon.  Each scanner could
> have ReleaseDevice and ReclaimDevice methods which would make it
> temporarily close the device so another program could use it, but that
> still seems like a hack.  I guess the real solution here would be to
> make sure all SANE drivers can take multiple connections, but I don't
> know if that's possible (maybe some hardware limits it to one
> connection?).  Does anyone know more about this?
> 
> So using libusb directly would get around locking problems?  Sounds
> good, but it seems like we'd end up with a bunch of duplicated driver
> code, and what if a SCSI scanner or parallel-port scanner has buttons?
>  It's not likely, but it seems better to keep it flexible instead of
> tying it into USB.

No, device access via libusb is exclusive (as it needs!) so this is not
possible. One way around this, though, would be to modify libsane to
send a D-Bus message to the HAL add-on so it releases the device (unless
you configured libsane to not do this). That's probably not a lot of
work, I'd just patch backend/dll.c:sane_open() in sane-backends and hey
presto this should work. Getting such a (compile-time) option past the
SANE developers may be harder though, but I guess if you make a good
case for it, then it should be feasible.

Btw, looking at how sanebuttonsd does button detection, it's pretty ugly

 
http://alioth.debian.org/plugins/scmcvs/cvsweb.php/experimental/button-daemon/sanebuttonsd.c?rev=1.3;cvsroot=sane

e.g. it's polling. I don't suppose there's any way to avoid this, it
only will happen when the scanner is plugged in and powered on.

So here's what I would do

 1. Start writing the buttons addon for HAL - this would just link
with libsane and do sane_open (device_file) where you get
device_file from HAL, e.g. "/dev/bus/usb/001/002", when the
addon is launched. Make sure it emit D-Bus events when you
press buttons and this should work if the underlying sane driver
supports button presses.

 2. Make the addon export the o.fd.Hal.Device.ScannerButtonMonitor
interface with the InhibitMonitoring and AllowMonitoring that
tells the add-on to release resp. acquire the device file for
monitoring. Need to track when the caller disconnects from the
bus, see e.g. gnome-power-manager and gnome-screensaver for how
to do this. Now you can disable this from the command line and
things actually work

 3. Patch libsane's backend/dll.c sane_open() (and sane_close()!) to use
InhibitMonitoring() / AllowMonitoring() on the addon. This probably
includes things like using

 libhal_manager_find_device_string_match(hal_ctx, "scanner.device",
 "/dev/device_file");
 
to find the device object and then call InhibitMonitoring() (and
"/dev/device_file" is what the caller passed to sane_open()).

What do you think? Just ask on the HAL list if you need any help!

Hope this helps,
David


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome 2.19 schedule.

[Étienne Bersac]

Hi,

> e.g. it's polling. I don't suppose there's any way to avoid this, it
> only will happen when the scanner is plugged in and powered on.

How to do without polling in user space ?

> So here's what I would do
> [snip]
> What do you think?

That's really nice !!! Also, patching sane_get_devices () to use HAL,
then patch saned to publish through avahi, then path again
sane_get_device to use avahi and we get the trick !

SuSE is known to have some patch for HAL and SANE integration, so even
if SANE does not includes patches, we might at least integrate such
patches in distributions. However, if the changes are optionnal at
compile time, SANE people may include it. They already included fdi
generator. That's a step forward.

Donald, what do you think of that ?

>  Just ask on the HAL list if you need any help!

Right, the discussion might leave this list.

Kind regards,
Étienne.
-- 
Verso l'Alto !

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome 2.19 schedule.

[David Zeuthen]

On Mon, 2007-03-19 at 21:58 -0400, David Zeuthen wrote:
> No, device access via libusb is exclusive (as it needs!) so this is not
> possible. One way around this, though, would be to modify libsane to
> send a D-Bus message to the HAL add-on so it releases the device (unless
> you configured libsane to not do this). That's probably not a lot of
> work, I'd just patch backend/dll.c:sane_open() in sane-backends and hey
> presto this should work. Getting such a (compile-time) option past the
> SANE developers may be harder though, but I guess if you make a good
> case for it, then it should be feasible.

FWIW, I've asked for this on sane-devel

 http://lists.alioth.debian.org/pipermail/sane-devel/2007-March/018864.html

Let's hope they think it's a good idea!

 David


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome 2.19 schedule.

[David Zeuthen]

On Tue, 2007-03-20 at 03:17 +0100, Étienne Bersac wrote:
> Hi,
> 
> > e.g. it's polling. I don't suppose there's any way to avoid this, it
> > only will happen when the scanner is plugged in and powered on.
> 
> How to do without polling in user space ?

Hmm, I don't think that's possible; I haven't looked at the SANE sources
in great detail though; they do have what appears to be some mainloop
integration bits (sane_get_select_fd() for example) so perhaps that can
be used. Either way, it's an implementation detail though + people are
probably near a power point when they're using their scanners so we
don't have to worry too much about burning battery. And we'd only be
running this code when a scanner is actually attached...

But the less polling the better or so Ryan tells us :-)

> > So here's what I would do
> > [snip]
> > What do you think?
> 
> That's really nice !!! Also, patching sane_get_devices () to use HAL,
> then patch saned to publish through avahi, then path again
> sane_get_device to use avahi and we get the trick !

Yeah, that might be possible too. Beware of feedback effects though :-)

  David


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Problems using gnome-2-18 branch for evolution-data-server in jhbuild

[Harish Krishnaswamy]

Bingo, Guenther !

I *did* send the mail from GMail using my novell profile - so I could
work around the blockade the gnome list servers have imposed on mails
from my LAN [1], hoping the moderators  would fish them out from the
approval queue.

> It seems that evo stuff silently branched for GNOME 2.18.
> 
> I tried to update jhbuild moduleset to use this branch (patch
> attached),
> but it seems there are some issues against libical in
> evolution-data-server. Here is the jhbuild console log trying to
> perform
> the svn switch:

> Any idea? Please note that jhbuild is trying to get the wrong
> "directory": it should be
> svn.gnome.org/svn/libical/branches/gnome-2-18,
> not svn.gnome.org/svn/libical/gnome-2-18

Luca :

Does the tree make a noise when it falls but there is no one to hear ?
Guess you had attempted to do a check-out, some time when I had started
branching the stuff but had not been done yet.

It should be working fine now - the libical (from EDS ) had to have its
nose pointing towards the stable branch of the external module.


Thanks,
Harish


[1] This appears to be a problem with my office network, not that of the
GNOME servers- our friendly admins are working on it.


-- 
Novell, Inc. 
Software for the Open Enterprise™
http://www.novell.com


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

libtorch: an asynchronous dns resolver library

[Michael Frank]

hi all-

for a month or so I have been working on an asynchronous DNS resolver
library for GNOME (and any other application using the glib main loop),
which I call libtorch.  Currently code can be retrieved from svn here:

https://svn.syntaxjockey.com/repos/libtorch/trunk/

For resolving a domain name to network address, usage is pretty simple:

TorchHostQuery *query =
torch_host_query_new_from_hostname ("google.com.");
g_signal_connect (query, "result", G_CALLBACK (on_result), NULL);
g_signal_connect (query, "error", G_CALLBACK (on_error), NULL);

TorchResolver *resolver = torch_resolver_get_default ();
torch_resolver_execute_query (resolver, query);

For the full example, see
https://svn.syntaxjockey.com/repos/libtorch/trunk/tests/test3.c

Current plans are:

1) implement all of the well used record types in the IN class (easy)
2) client-side query recursion (will take some time to code properly)
3) implement more sub-classes of TorchQuery for other common queries,
such as MX and WKS lookups
4) caching of queries

Now after I've said all of this, my questions to you all are:

1) is this a good library to have, or is the 'problem' i'm solving small
enough that people would rather either keep using the blocking libc
calls or employ hacks like threads?

2) are there any suggestions for APIs and features that would be nice to
have in order to better fit in to code that already exists in GNOME
applications?

3) would anyone be willing to mentor this if i turned it into a google
SoC project =)  I'm thinking that a good project would be to add
asynchronous dns resolving in a few key places, like gnome-vfs, ekiga,
evolution, ...

Comments?

-- 
  .~.
Michael Frank /v\
[EMAIL PROTECTED] // \\
/(   )\
GPG Fingerprint: ^`-'^
2A44 DF32 91A5 ADA9 0E86 4F65 4051 870D 8B51 6EE0



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Cairo updated to 1.4.2

[Carl Worth]

The cairo project just released a stable, bug-fix only 1.4.2 update,
which GNOME will likely want to pick up.

Thanks,

-Carl


pgpXX6z96jO07.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list