Re: [Chromium-environment] auto-starting chromium

[Brian P. <br...@tu...>]

Brian Paul wrote:
> 
> I've spent the afternoon prototyping something new.  The faker
> library now does the following:
> 
> 1. If the faker lib is able to contact the mothership, proceed normally.
>    Otherwise...
> 
> 2. Look if the CR_CONFIG env var is set.  If so, it names a desired
>    config file (ex: crdemo.conf)
> 
> 3. Otherwise, find the name of the running process (ex: city)
>    Look in ~/.crconfigs for a config for city (ex: crdemo.conf)
> 
> 4. Spawn a mothership process (ex: exec("python crdemo.conf city"))
> 
> 5. The crdemo.conf file can auto-start a crserver.
> 
> 6. An atexit() handler kills the mothership when the app exits.
> 
> 
> So, I can run city with Chromium just by typing "city <return>".
> I have symlinks from libGL.so to libcrfaker.so.
> 
> How does that sound for a first cut?

The next thing I've done now is to enhance the config files written
by the graphical configuration tool so that they'll accept command
line parameters at run time.

For example:

1. Use the graphical config tool to design a sort-first config.
    Let's call it "tile.conf".

2. Running "python tile.conf --help" prints the options:

Usage:
   tile.conf [--help] [-c columns] [-r rows] [-w tileWidth]
      [-h tileHeight] [-s servers] [program]

3. Run the config, specifying the mural size and servers:

    python tile.conf -c3 -r2 -s cr1,cr2,cr3,cr4,cr5,cr6 atlantis

    This will setup a 3x2 mural running on the named servers.


So hopefully, someone can whip up a basic sort-first, sort-last or
image reassembly configuration with the configuration tool, then be
able to fine-tune the parameters at runtime.

The next step will be to demonstrate/test this using the auto-start
system I got going yesterday...

-Brian