Re: Re : Re: Volunteering

[Cody Long]

Reconstructor looks good, but I saw somehthing about a payment of $5 USD for "Unlimited Usage"... I wonder what that is about.

With getting webian to be able to access hardware controls we would have to mod and extend the chromeless project. I am working on just trying to figure out what is going on with the chromeless code. I thought it would be a lot of python but that is only the xulrunner part and a few other things. The main part of chromeless is abstracted with javascipt. I do not know much about javascript so I am reading a book and *trying* to figure out where things are and what is going on.

2011/8/4 Jono <jzelda...@gmail.com>

A minimal Debian install with twm-kiosk and a few custom config files
should do it. Maybe Reconstructor for the build? I've never used it,
but it sounds good - anyone got an opinion?
What I dont know is how hardware controls could be added to a
Chromeless-based ui ... You might have to mod the code of firefox
itself or get into dbus communication? Anyone more learned than me
that could recommend a way to do it?

(btw sorry if any of my points have already been brought up, I haven't
caught up with the wiki or anything as yet ...)

[Jono]

Hmm, long time since I've been there apparently ... last time I looked
it was free :(

I'm surprised theyve bothered with JavaScript to be honest - I would
have thought it would be easier to just link python methods in. Ive
been doing a fair bit of JavaScript recently so I'll take a look at it
over the weekend. Do you know what API they use to call python or
whatever from JavaScript, or if it's in-house?

[Ben Francis]

On Fri, Aug 5, 2011 at 11:30 AM, Jono <jzelda...@gmail.com> wrote:

 Do you know what API they use to call python or

whatever from JavaScript, or if it's in-house?

I think they use JSc types https://wiki.mozilla.org/JSctypes

e.g. https://github.com/mozilla/chromeless/tree/0.3/examples/jsctypes

It's mentioned in the 0.3 blog post http://mozillalabs.com/chromeless/2011/05/12/chromeless-0-3/

Ben

--
Ben Francis
http://tola.me.uk

[Jono]

Cool, a direct interface to C should make things more straightforward.
I see the ubuntu sound menu at least is c, and I assume that a c-based
networking indicator of some kind exists. If we deleted all the UI
code and (somehow, I'm a bit hazy with gcc) compiled it into a .so
with all the necessary functions ... Shouldn't be too hard.
I'm pretty busy atm with my latest art assignment, but I'll try and
make time to fork indicator-sound and see how it works.

[Sam Black]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/08/11 11:42, Jono wrote:
> Cool, a direct interface to C should make things more straightforward.
> I see the ubuntu sound menu at least is c, and I assume that a c-based
> networking indicator of some kind exists.

By the looks of indicator-sound it's function is not only to control the
sound card but also the applications using the sound card. I think this
is overkill for what we need, so I'd suggest using something much
lighter, like xfce4-mixer as the basis instead of indicator-sound.

Network wise, NetworkManager comes with a CLI client that could provide
a reasonable base to work from.

- --
Thanks,

Sam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk49LzMACgkQHLRhmt89eyJbLACeN+g+VBYGY6FC8+/8Dq/1IqD8
tFoAnjmKbSvKA2Oly9OIhnNMkDWNTheS
=mJzD
-----END PGP SIGNATURE-----

[Jono]

Yeah, I didn't think of xfce's mixer. I've just been looking at the
volume control code from both indicator-sound and another simpler
volume icon (Ubuntu uses PulseAudio as a server, I'm not sure what the
backend is and whether we need PA on top?)

As I said, I don't know much about shared libraries so I'm wondering:
Can shared libraries have the notion of state (if you have a function
which sets up a global variable and call it from a .so, will the
global variable be available in future calls of different functions
from that file)? And if they do, are there tradeoffs of using global
variables that would be significant for Webian/Chromeless?

I wonder whether it would be better to have just a shared library or a
daemon with a dbus interface that connects to a shared library or
whether Chromeless itself can communicate using dbus (or could be
modded to).

[Sam Black]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/08/11 05:14, Jono wrote:
> Yeah, I didn't think of xfce's mixer. I've just been looking at the
> volume control code from both indicator-sound and another simpler
> volume icon (Ubuntu uses PulseAudio as a server, I'm not sure what the
> backend is and whether we need PA on top?)
>

It would probably be ALSA for the backend. I suggested xfce4-mixer as
its simpler and uses gstreamer to control the volume; gstreamer can talk
straight to ALSA, thus cutting out PA entirely.

> As I said, I don't know much about shared libraries so I'm wondering:
> Can shared libraries have the notion of state (if you have a function
> which sets up a global variable and call it from a .so, will the
> global variable be available in future calls of different functions
> from that file)? And if they do, are there tradeoffs of using global
> variables that would be significant for Webian/Chromeless?
>

I'm not sure. Generally though, global variables are a Bad Idea (TM).
I'm also not sure why you would need global variables, could you
elaborate a bit please?

> I wonder whether it would be better to have just a shared library or a
> daemon with a dbus interface that connects to a shared library or
> whether Chromeless itself can communicate using dbus (or could be
> modded to).

I think that using dbus maybe a good way to go, especially as a lot of
stuff (NetworkManager, firewalld, systemd, upower, etc) use dbus for
control. We could add a simple jsctypes wrapper around dbus-send and
send dbus stanzas directly from the shell.

- --
Thanks,

Sam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4+Wu0ACgkQHLRhmt89eyL5xACeM8MADTqpIu5mz0/IfFt6NM9S
hFkAnRrqeGx053eLPEmOLFBWkVDBJODp
=dSNL
-----END PGP SIGNATURE-----

[Ben Francis]

On Sun, Aug 7, 2011 at 10:29 AM, Sam Black <samww...@lapwing.org> wrote:

I suggested xfce4-mixer as

its simpler and uses gstreamer to control the volume; gstreamer can talk
straight to ALSA, thus cutting out PA entirely.

+1 for gstreamer

I think that using dbus maybe a good way to go, especially as a lot of
stuff (NetworkManager, firewalld, systemd, upower, etc) use dbus for
control. We could add a simple jsctypes wrapper around dbus-send and
send dbus stanzas directly from the shell.

+1 for dbus via jcstypes

Ben

[Jono]

> I suggested xfce4-mixer as
> its simpler and uses gstreamer to control the volume; gstreamer can talk
> straight to ALSA, thus cutting out PA entirely.

Ah, I'd forgotten about gstreamer. But that still brings me to ...

> I'm also not sure why you would need global variables, could
> you elaborate a bit please?

Because all the mixers I've looked at have to set up a connection to
ALSA/PulseAudio/gstreamer (at least, that's what it looks like) -
there's no simple set_volume(int). It would be stupid to connect every
time the volume is changed (or whatever), so the connection would be
stored in a global variable. Correct me if I'm wrong, I haven't looked
very hard at the code.

> We could add a simple jsctypes wrapper around dbus-send and
> send dbus stanzas directly from the shell.

Yes, good idea! That way we can minimise the amount of C and use the
same library for any OS stuff we need.