On Tue, 2007-03-20 at 13:58 -0400, Martin Owens wrote:
> > with HAL and I don't blame you for not being :-)
>
> Have you checked out some of the interesting comments made in the past?
>
> Will this patch provide a way for programs using HAL to call standard
> methods such as scan or will it be as
On Tue, 2007-03-20 at 13:51 -0400, m. allan noah wrote:
> ok, i think i understand the distinction between 5 and 6, you cross
> the system to gui gap using dbus signals between two processes?
That's correct.
> 1. does udev signal HAL on every change to any device in the system,
> or only certain
On 3/20/07, David Zeuthen wrote:
> On Tue, 2007-03-20 at 13:03 -0400, m. allan noah wrote:
> > > > > i would rather see a more general, non-linux specific method of
> > > > > handling buttons. how about a daemon that runs, gets the sane device
> > > > > list in the normal way, and then monitors ea
On Tue, 2007-03-20 at 13:03 -0400, m. allan noah wrote:
> > > > i would rather see a more general, non-linux specific method of
> > > > handling buttons. how about a daemon that runs, gets the sane device
> > > > list in the normal way, and then monitors each of the found devices
> > > > for button
> > > i would rather see a more general, non-linux specific method of
> > > handling buttons. how about a daemon that runs, gets the sane device
> > > list in the normal way, and then monitors each of the found devices
> > > for button presses as regular sane options.
>
> That's essentially what I
On 3/20/07, ?tienne Bersac wrote:
> Hi allan,
>
> > it would be nice if some of the linux gnome devels would engage in
> > SANE discussions on the SANE lists. they might learn something about
> > the hardware they are trying to support :) button handling comes up
> > here quite a bit, you should s
> 1. you need a piece of code that understands the button-reading
> protocol for every scanner that sane supports. you will end up
> replicating a fair bit of code that is already (hopefully) in
> sane-backends, esp. for devices that require a bit of initialization
> before they can communicate.
A
David Zeuthen wrote:
>> Looks good to me, as long as the added code in SANE is properly
>> #ifdef'd out etc. Let's try not to turn SANE into a Linux-specific
>> piece of code :)
>
> Yeah, it would all be #ifdef'ed out (btw, HAL runs on Solaris and
> FreeBSD too these days)
I know, but I doubt it
> What would be the impact in terms of:
> - added code
> - added library dependencies (and here I'm especially worried about
>bringing in the infamous GLib for the DBus stuff in dll.c, so if we
>could avoid it, that'd be nice)
Just my $0.02: D-BUS doesn't need GLib - it's got its own low
On 3/20/07, David Linker wrote:
> Strange. I thought that it would allocate the memory at the pointer.
>
> In any case, I have tried allocating memory (64 bytes), and then
> passing the pointer to the memory, and that also fails, with the
> pointer reset to NULL.
perhaps you mis-understand point
On Tue, 2007-03-20 at 12:17 -0400, m. allan noah wrote:
> of course, now that i think about it, this idea has the same problem
> of device ownership/locking. i suppose you could change every backend
> to lock open devices (plustek does this already?), and every front-end
> would have to send/accept
On Tue, 2007-03-20 at 09:01 -0500, m. allan noah wrote:
> it would be nice if some of the linux gnome devels would engage in
> SANE discussions on the SANE lists. they might learn something about
> the hardware they are trying to support :) button handling comes up
> here quite a bit, you should se
On Tue, 2007-03-20 at 12:18 +0100, Julien BLACHE wrote:
> David Zeuthen wrote:
>
> Hi,
>
> > So I'm curious if a) you think this is a good idea; and b) whether such
> > a patch would be able to go into mainline SANE? Thanks for considering!
>
> Looks good to me, as long as the added code in SAN
of course, now that i think about it, this idea has the same problem
of device ownership/locking. i suppose you could change every backend
to lock open devices (plustek does this already?), and every front-end
would have to send/accept signals based on lock ownership? sounds
ugly...
allan
On 3/20
Strange. I thought that it would allocate the memory at the pointer.
In any case, I have tried allocating memory (64 bytes), and then
passing the pointer to the memory, and that also fails, with the
pointer reset to NULL.
Any ideas or suggestions for further testing welcome.
David
On Mar
pls ignore.
"Donald Straney" wrote:
> Just my $0.02: D-BUS doesn't need GLib - it's got its own low-level C
> API in libdbus, and it would take maybe 20 lines of code (if not less)
> to get a D-BUS connection, call the appropriate method (a method would
I know that, but most people use GLib for that, for wh
--
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070320/6c0c7d66/attachment.htm
From kitno...@gmail.com Tue Mar 20 15:01:39 2007
From: kitno...@gmail.com (m. allan noah)
Date: Tue Mar 20 14:01:47 2007
Subject: [sane-devel] Re: [PATCH] genera
David Zeuthen wrote:
Hi,
> So I'm curious if a) you think this is a good idea; and b) whether such
> a patch would be able to go into mainline SANE? Thanks for considering!
Looks good to me, as long as the added code in SANE is propery
#ifdef'd out etc. Let's try not to turn SANE into a Linux-s
===
== Neuer Eintrag
===
---
-- Formular: 'adddev'
---
1. Your email address:
'greg.john...@saltaire.com.au'
2. Manufacturer
On Sun, 2007-03-18 at 10:31 +0100, Julien BLACHE wrote:
> David Zeuthen wrote:
>
> Hi,
>
> > Is it possible anyone can apply / comment on this? Thanks!
>
> It's in.
Great, thanks a lot! Another thing; one of the things we're looking at
in GNOME is making the buttons on the scanners work; there
21 matches
Mail list logo
