On Mon, 17 Sep 2018 23:53:39 +0200
viverna <viverna@???> wrote:

> Steve Litt <slitt@???> il 16-09-18 22:21:11 ha
> scritto:
> > Then here's a solution that bridges all the options: Release Dario's
> > version of startx under some other name, so that Gnome/KDE people
> > can still have their "features", and everyone else can have X that
> > works and leaves the system in good shape when it terminates. Put
> > it in the same package that startx comes in. Just use Dario's patch
> > to make it, each time Debian changes startx.

> Good solution. But I think Dario's solution should be the
> default. 
> Another possibility is don't use startx and execute xinit from a
> personal shell script and (fine grained) control all parameters
> passed to xinit. This is my approach. If you are interested I write a
> simple shell script and I will be happy if it may be useful for
> someone.                                          

>

The shellscript calling xinit was my first thought. Then I put startx
in an editor. It does a WHOLE LOT of stuff I don't have the knowledge
to recreate. It's 200 lines of bash, for gosh sakes.

So, trying to prove your xinit idea couldn't possibly work, I did the
following:

xinit -- :8

Of course nothing that simplistic would work.

Oops, it came right up in Openbox, same as my normal startx initiated
vt7. Dmenu worked, gnumeric worked, Chromium didn't because it started
itself in vt7 instead of vt8, but you usually have only one X at a time.

Your idea merits more research. The "we must cover every corner case"
crowd can use startx in its Redhat-diminished state, while people like
us use a <20 line shellscript. Perhaps call it viverna.

SteveT

Steve Litt
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz