Refitting .xinitrc from the bottom up.

Under development: PCMCIA, wireless, etc.
Message
Author
musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

Refitting .xinitrc from the bottom up.

#1 Post by musher0 »

Hello all.

Your comments and observations, please, for the following. TIA.

For the record, I broached on this subject yesterday in radky's DPupStretch-7.5
thread, here:
http://murga-linux.com/puppy/viewtopic. ... ost#979231

I always thought a bit strange that in the original .xinitrc, if you had both fbpanel and
lxpanel installed, there was a possibility that both be launched.

In this new code, I have tried to be more discriminate, through the introduction of a
$panel variable that the user would store in a small text file somewhere in the file
system. The form for this $panel variable is borrowed from what BarryK uses for the
$desktop variable at the top of the .xinitrc script.

As well, I have done a lot of work on alternative window managers, and this bash
code snippet I am suggesting expands the number of WMs Puppy can handle.
This may theoretically mean more Puppy users in the long run.

Additional problemS being that
-- some WMs come with a tray-and-task bar and some don't;
-- icewm and jwm can use an alternative tray-and-task bar if configured for it;
-- there is a variety of good tray-and-task bars available.
My suggested code tries to take those probs into account.

Also, the absolute original ending of the .xinitrc script is, IMO, like this paranoid guy
who is wearing suspenders AND a belt for fear his trousers will drop. I realize that
there needs to be some kind of net for the initial WM launch, that is documented,
but I felt we were overdoing it. Hence the simplification.

I left a couple of the original lines at the top so you can search for those to get the
exact location of the subroutine in .xinitrc. In radky's DPupStretch-7.5, e.g., it
starts at line 163. But it varies from Puppy to Puppy.

I tested this on my xenialPup-706 and it works fine with

Code: Select all

panel=bmpanel2
If some of you could also test it and provide feedback, -- if you have a couple of
minutes --, I will be most grateful. You must absolutely back-up your original
.xinitrc before testing, do I need to remind you?


There is a "DRAFT" filigree all over this snippet, even if you can't see it!!! ;) I'm
sure there are still a couple of issues with it. One I can see right away is how
do you define or detect the $panel variable, blind, I mean without knowing in
advance which one the user wants to use.

Isn't there a part of maths that can handle these situations? From my junior college
days: it was called the "theory of limits", IIRC, which is used in the shipping
industry, among other fields, to define the 3D geometry of boxes and containers,
starting with limited input data (with several unknowns). Or maybe I'm imagining
things.

TIA. TWYL, hopefully.
~~~~~~~~~~~~~~~

Code: Select all

# (...)
### Ending of script /root/.xinitrc ###

#v3.95 support fbpanel tray/taskbar...
#only launch tray for w.m. without inbuilt tray...
# Begin of refit by musher0, Jan 4. 2018
panel="`cat /root/panel_app`"
case "$CURRENTWM" in
	jwm|icewm)echo . > /dev/null
	;;
	aewm|jbwm)aepanel -b -rc /root/.wmx/complement3 # or other aemenu resource file
	;;
	echinus|openbox|waimea|wmx)
		case "$panel" in
			fbpanel)if [ -x /usr/bin/fbpanel ];then # double-check # This original part by BarryK, kept.
  #a bit of a hack: when 3builddistro runs fixmenus, which calls variconlinks,
  #which populates /var/local/icons with symlinks, /usr/local/lib/X11/pixmaps
  #is not yet populated (happens at first boot, from default icon theme)...
					[ ! -e /var/local/icons/home48.png ] && ln -fs /usr/local/lib/X11/pixmaps/* /var/local/icons/
					fbpanel &
				fi
			;;
			lxpanel)[ "$desktop" = "rox" ] && [ -x /usr/bin/lxpanel ] && lxpanel & # This original part by BarryK, kept.
			;;
			bmpanel2)[ -x /usr/bin/bmpanel2 ] && bmpanel2 --theme="Light-T" 2>/dev/null
			;;
		esac
	;;
esac # End of refit by musher0, Jan. 4 2018

# enable xorg mousekeys # This original part by BarryK, kept.
# they should be enabled by default somewhere in /etc/X11/xkb
# but who knows
setxkbmap -option keypad:pointerkeys

# Begin of refit by musher0, Jan 4. 2018
`which $CURRENTWM`
[ -x $CURRENTWM ] && exec $CURRENTWM
# [ "$desktop" = "rox" ] && exec jwm
# Association très artificielle....
# End of refit by musher0, Jan 4. 2018

###END###
Last edited by musher0 on Sun 07 Jan 2018, 02:09, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

Re: Refitting the end of .xinitrc

#2 Post by MochiMoppel »

musher0 wrote:Also, the absolute original ending of the .xinitrc script is, IMO, like this paranoid guy
who is wearing suspenders AND a belt for fear his trousers will drop. I realize that
there needs to be some kind of net for the initial WM launch, that is documented,
but I felt we were overdoing it. Hence the simplification.
The original doesn't need simplification, it needs a fix. This is the original part:

Code: Select all

#v2.11 GuestToo suggested this improvement...
which $CURRENTWM && exec $CURRENTWM
[ -x $CURRENTWM ] && exec $CURRENTWM
exec jwm
BK must have had a weak moment when he approved the suggestion by GuestToo (which you can find here).
Can anyone spot the conceptual mistake? Hint: last line of GuestToo's explanation...

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

Re: Refitting the end of .xinitrc

#3 Post by musher0 »

MochiMoppel wrote:
musher0 wrote:Also, the absolute original ending of the .xinitrc script is, IMO, like this paranoid guy
who is wearing suspenders AND a belt for fear his trousers will drop. I realize that
there needs to be some kind of net for the initial WM launch, that is documented,
but I felt we were overdoing it. Hence the simplification.
The original doesn't need simplification, it needs a fix. This is the original part:

Code: Select all

#v2.11 GuestToo suggested this improvement...
which $CURRENTWM && exec $CURRENTWM
[ -x $CURRENTWM ] && exec $CURRENTWM
exec jwm
BK must have had a weak moment when he approved the suggestion by GuestToo (which you can find here).
Can anyone spot the conceptual mistake? Hint: last line of GuestToo's explanation...
Hello MochiMoppei.

Thank you for your reply.

Judging from the contents of your posts generally, my guess is that you have at
least the training of a software engineer or of a computer scientist.

Me, I am only a self-taught enthusiast. So I will not even try to take up your
challenge!

However, viewed from the logic of language, those lines are saying the same thing
two times; three times if the chosen WM is jwm.

I think it is an error to position jwm as the fall-back position. Worse than an error,
it is like colonialism!!! Why jwm and not, for example, xfce or echinus?

From whatever little I have read on this subject, we apparently need a 2nd launcher
in the xwin/startx script saying the same thing as the 1st, in case there is a mishap
or a bug.

A computer expert tells me this, and I believe him. Still, inside of me, I think that
one line should be enough. E.g. if I type
< xwin ocewm >

# (The "o" is next to the "i" on the QWERTY keyboard, so it's easy for me to make
that mistake if I am not focusing.)

instead of

< xwin icewm >, it's ok for X/xinit to refuse to start. If my typing is wrong, let the
start of X fail. It's ok for me to stay at the initial black console. No big deal, no
offense taken, etc. I'll just put my fingers back on the keyboard and try to type
correctly: < xwin icewm >. I do not need my errors to be covered by a 2nd line.

Futhermore, when GuessToo says:
the first line starts the wm if it is found in PATH
the second line starts the wm if it is a vaild executable file, but not in the PATH
I think: "What kind of reasoning is this?" If you are simply a logical person, not
even an expert programmer, you want the executable of your window manager to be
in the path. No need for the 2nd line, IMO.

Why would I want to put one of the main pieces of my Linux, the window manager,
outside the path? That is not logical. Why would anybody sensible put the waimea
executable, e.g., in /usr/share/themes? :lol:

Also, do we know for a fact that the 2nd line is used? that the 3rd line is used?
Is there a way to monitor this?

My 2 cents. TWYL, hopefully.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
bigpup
Posts: 13886
Joined: Sun 11 Oct 2009, 18:15
Location: S.C. USA

#4 Post by bigpup »

I think the thinking on the path not path thing was that Puppy does not follow the exact placement of files as other Linux OPS do.
If someone installs a window manager package compiled for some other Linux OPS. The install may not put everything in the path locations Puppy normally uses.

▶—— Path ——◀

/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/X11R7/bin:/root/my-applications/bin:/usr/games
The things they do not tell you, are usually the clue to solving the problem.
When I was a kid I wanted to be older.... This is not what I expected :shock:
YaPI(any iso installer)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#5 Post by musher0 »

bigpup wrote:I think the thinking on the path not path thing was that Puppy does not follow the exact placement of files as other Linux OPS do.
If someone installs a window manager package compiled for some other Linux OPS. The install may not put everything in the path locations Puppy normally uses.

▶—— Path ——◀

/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin:/usr/X11R7/bin:/root/my-applications/bin:/usr/games
Hi bigpup.

Are people naive enough to think that Puppy is like another distro?
(The above sentence is not a joke.)

@all:
I did a test by adding this line

Code: Select all

echo blabla > /root/blabla
below the first WM launcher line, I recycled the Puppy from the initial black console
several times with various WMs, and file blabla is never written. This means that the
.xinitrc script ends in effect with the launching of the WM on the 1st launcher line

Conclusion: only one launcher line is needed to launch the WM.

Maybe GuessToo's three original WM launcher lines were needed 10 years ago. I do
know that Puppies have become more stable with each version number. I wouldn't
know how unstable they were then.

I'm attaching the refit I have done until now of file /root/.xinitrc. Works fine on this
xenialPup-7.0.6. Confirmation on your Pup would be appreciated. Only for
experienced users; newbies, please do NOT test this.


I have tried to indicate my edits as clearly as possible. Also some comments.
For study and feedback. TIA.

(Please back-up your current /root/.xinitrc file before testing this one. Use at your
own risk.
)

TWYL, hopefully.
Attachments
.xinitrc.musher0.zip
Please back-up your current .xinitrc before testing this one. Use at your own risk.
Unpack in /root and make executable.
(3.44 KiB) Downloaded 165 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
MochiMoppel
Posts: 2084
Joined: Wed 26 Jan 2011, 09:06
Location: Japan

#6 Post by MochiMoppel »

musher0 wrote:I did a test by adding this line

Code: Select all

echo blabla > /root/blabla
below the first WM launcher line,
So your test setup reads

Code: Select all

`which $CURRENTWM`
echo blabla > /root/blabla # is not written.
right?
I recycled the Puppy from the initial black console several times with various WMs, and file blabla is never written.
Test again. The file would always be written, no matter what
This means that the
.xinitrc script ends in effect with the launching of the WM on the 1st launcher line
In GuestToo's code it does (if launch was successful), in your test code is does not. I don't know what purpose the which command serves in your version, you don't need it, but since you enclosed $CURRENTWM in backticks your wm would start in a subshell of .xinitrc. When you exit the wm, .xinitrc continues and writes blabla.
Conclusion: only one launcher line is needed to launch the WM.
And you know what? This was exactly the way BK called the wm before GuessToo had his funny idea:

Code: Select all

exec $CURRENTWM
Simple and effective. This made sure that the file /etc/windowmanager (= $CURRENTWM) always contains a valid filename. If $CURRENTWM contains crap the user would be thrown back to the terminal and can try again.

GuessToo ignores an invalid $CURRENTWM:
GuestToo wrote:the third line starts the default wm if $CURRENTWM does not seem to make sense
His code, now found in all Puppies, simply doesn't care if /etc/windowmanager contains crap :roll:
At this point he could at least have written "jwm" to /etc/windowmanager so that $CURRENTWM finally does make sense. Many programs rely on /etc/windowmanager and of course they assume that it contains the correct name of the current wm. Latest at shutdown this can cause unpleasant surprises, which I tried to explain here. The workaround is hilarious :lol:

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#7 Post by musher0 »

Hi MochiMoppei.

You're right. Thanks for your reply.

Only one launcher needed, and in the form: < exec $CURRENTWM >.

The which command checks if an executable is in the system.

I'll talk to my shrink about why I need to check that the window manager
is in the system. ;)

Again thanks for this illuminating discussion.

TWYL, hopefully.
~~~~~~~~~~~~~~~~~~
Edit:
The attached contains MochiMoppei's recommendation.

I believe you can subtitute this .xnintrc for the old one. Still, make a proper back-up
of the old one, and rename or copy my script to < .xinitrc > (without the chevrons).

Please report here anything funny, fuzzy or fishy about it. Thanks.

Two cosmetic things I did not mention before:
1) I have included the capacity to lay a background to make conky scripts pseudo-
transparent, based on qiv (lines 127 to 132). It will stay inactive if you do not have
conky installed. And it will not work if qiv is not installed.

(I have a pet archive for conky v. 1.9.1 (non-Lua) here, and there is a tested-on-
Puppy qiv-2.2.4 deb archive here.)

You can comment this segment out if you do not want it or like it. I know you can
use feh instead of qiv, but I have no experience of feh. IIRC, forum member
belham2 has successfully used feh to achieve the same result. So please ask him.

I'm including this segment because
-- a) making conky panels pseudo-transparent is difficult (in my experience);
-- b) the doc. on how to make the conky panels transparent is hard to find;
-- c) this is an easy way.
So I thought I would include this segment to make the user's life easier.

2) Just above those lines, I have added an elif structure to make available my
ROX-panel to the left as well as BarryK's ROX-panel to the right. This is a matter of
preference, The lines do not do anything if you do not have a ROX panel named by
these names. If you do not like the names, change them, but to consistent names
in this script AND in the ROX directories.

Finally, a very important one-letter edit:
since there were no bash-specific structures or commands in .xinitrc, I changed its
interpreter from (ba)sh to ash. (See top line.) This makes it execute faster.

BFN
Attachments
.xinitrc.musher0.revised.zip
Same words of caution as above.
(3.53 KiB) Downloaded 142 times
Last edited by musher0 on Mon 08 Jan 2018, 07:04, edited 1 time in total.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#8 Post by mistfire »

@musher0 X-Slacko Slim has a modified .xinitrc which was edited by myself. It supports almost major Desktop Environments. You can check it out

User avatar
Smithy
Posts: 1151
Joined: Mon 12 Dec 2011, 11:17

#9 Post by Smithy »

Good thread on the problem!
Don't know if anyone can make a tint 2 pet? (With wm switcher)
https://packages.debian.org/stretch/tint2

I have tried and it is difficult, the network firewall ram indicators no longer poke through like they used to and I think JWM tray is still underneath!

FB Box is all well and good, but it doesn't do openbox properly (if you click on the start bar, the old grey menu appears and it has been that way since lucid, if one selects show hidden files from rox, then the menu gets all the ugly . prefixes and sizing of openbox menus is all to cock. And the icons, ugh are they from puppy 1 or something..
If some fb panel designer can get it to look as good as Radky's opening JWM stretch design then that would be progress. At least that is more or less proportional and quite attractive.

Tint 2 does openbox all the way and creates a good homogenous "experience"
I think I had to shove a fix menus .sh in root/startup old one and then newly installed apps would put themselves in the menu WITHOUT any jerking and spluttering.

Vicmz and co used to make a great set of openbox/tint2 pets back in 2013.

Tint 2 has got a nice gui editor nowadays and dumps it well to a simple tint2.conf in root config/tint2.
I still think we have to do a bit of hand crafting apps for puppy, can't just use the ppm/apt get, which is ok by me as it creates a distinctive OS.

But it is like puppy is thwarting any attempts to get stuff together these days.
Passive Passengers?

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#10 Post by musher0 »

mistfire wrote:@musher0 X-Slacko Slim has a modified .xinitrc which was edited by myself. It supports almost major Desktop Environments. You can check it out
Hello mistfire.

Could you post a copy or a zip of it here? TIA.
It may be fruitful to compare solutions.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#11 Post by musher0 »

Smithy wrote:Good thread on the problem!
Don't know if anyone can make a tint 2 pet? (With wm switcher)
https://packages.debian.org/stretch/tint2

I have tried and it is difficult, the network firewall ram indicators no longer poke through like they used to and I think JWM tray is still underneath!

FB Box is all well and good, but it doesn't do openbox properly (if you click on the start bar, the old grey menu appears and it has been that way since lucid, if one selects show hidden files from rox, then the menu gets all the ugly . prefixes and sizing of openbox menus is all to cock. And the icons, ugh are they from puppy 1 or something..
If some fb panel designer can get it to look as good as Radky's opening JWM stretch design then that would be progress. At least that is more or less proportional and quite attractive.

Tint 2 does openbox all the way and creates a good homogenous "experience"
I think I had to shove a fix menus .sh in root/startup old one and then newly installed apps would put themselves in the menu WITHOUT any jerking and spluttering.

Vicmz and co used to make a great set of openbox/tint2 pets back in 2013.

Tint 2 has got a nice gui editor nowadays and dumps it well to a simple tint2.conf in root config/tint2.
I still think we have to do a bit of hand crafting apps for puppy, can't just use the ppm/apt get, which is ok by me as it creates a distinctive OS.

But it is like puppy is thwarting any attempts to get stuff together these days.
Passive Passengers?
Smithy?

Yours is a very interesting suggestion but I'm not sure this is a good thread for it. Perhaps
open an independent thread for your idea or revive the tint2 thread opened by Vicmz?

Although tint2 definitely needs to be added to the choice of panels in this refit of .xinitrc --
and I thank you for reminding me.

But I am not familiar with tint2. I can include it as a choice in the .xinitrc script, but one with
real experience of tint2 will have to answer the "substance" of your question.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

User avatar
Smithy
Posts: 1151
Joined: Mon 12 Dec 2011, 11:17

#12 Post by Smithy »

No problem,
Here's an .xinitrc from Tint2 panel 002 pet. Maybe lines 160-162 may be of interest, maybe not.

Code: Select all

#v3.95 support fbpanel tray/taskbar... 
    #only launch tray for w.m. without inbuilt tray... 
    if [[ "$CURRENTWM" != "jwm" && "$CURRENTWM" != "icewm" && "$CURRENTWM" != "startxfce4" && "$CURRENTWM" != "startfluxbox" ]];then 
     if [ -f /usr/bin/tint2 ];then 
      tint2 & 
     elif [ -f /usr/bin/fbpanel ];then 
      #a bit of a hack: when 3builddistro runs fixmenus, which calls variconlinks, 
      #which populates /var/local/icons with symlinks, /usr/local/lib/X11/pixmaps 
      #is not yet populated (happens at first boot, from default icon theme)... 
      [ ! -e /var/local/icons/home48.png ] && ln -fs /usr/local/lib/X11/pixmaps/* /var/local/icons/ 
      fbpanel & 
     else 
     [ -f /usr/bin/lxpanel ] && lxpanel & 
     fi 
    fi
Attachments
tint-panel-xinitrc.zip
(2.74 KiB) Downloaded 162 times

User avatar
battleshooter
Posts: 1378
Joined: Wed 14 May 2008, 05:10
Location: Australia

#13 Post by battleshooter »

Following this thread with interest, also curious to see mistfire's .xinitrc rewrite :)

I wanted to give a go for a more universal .xinitrc for XFCE as currently I have to completely disable jwm/rox for XFCE to start. So hopefully if mistfire's does it all, there will be no need to reinvent the wheel.
[url=http://www.murga-linux.com/puppy/viewtopic.php?t=94580]LMMS 1.0.2[/url], [url=http://www.murga-linux.com/puppy/viewtopic.php?t=94593]Ardour 3.5.389[/url], [url=http://www.murga-linux.com/puppy/viewtopic.php?t=94629]Kdenlive 0.9.8[/url]

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#14 Post by musher0 »

battleshooter wrote:Following this thread with interest, also curious to see mistfire's .xinitrc rewrite :)

I wanted to give a go for a more universal .xinitrc for XFCE as currently I have to completely disable jwm/rox for XFCE to start. So hopefully if mistfire's does it all, there will be no need to reinvent the wheel.
Hello battleshooter,

I must say I haven't used the xfce WM on a Puppy since GrumpyWolf's
MyWolve-0.24 or thereabouts.

Theoretically, there is a condition for xfce in the current .xinitrc, lines 149-154 +/-.
If you have to disable ROX and jwm, hm... That means it's not doing its job
properly. Maybe that part has to be rewritten too.

Sorry if this sounds disrespectful, but I am getting more and more the impression
that Barry wrote this with real experience of icewm and jwm, but did something "in
the abstract" for the other WMs.

But let's wait for mistfire's input.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#15 Post by musher0 »

Smithy?

Is this line ok:

Code: Select all

# (...)
	tint2)[ -x /usr/bin/tint2 ] && tint2 -c ~/.config/tint2/tint2rc 2>/dev/null & ;; # musher0, following Smithy's suggestion. Also ref.: https://wiki.archlinux.org/index.php/Tint2
		esac ;;
# (...)
I've attached how the .xinitrc looks now, with this tint2 addition.
Constructive criticism most welcome.

@mistfire:
If you have a minute, it would be nice to see your take on the .xinitrc, with a view to
improve the launch of xfce. I don't see myself downloading an entire 350 Mb Pup
just to examine a script that's 8 Kb? TIA.
Attachments
.xinitrc.musher0.rev2.zip
(3.66 KiB) Downloaded 143 times
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

mistfire
Posts: 1411
Joined: Wed 05 Nov 2008, 00:35
Location: PH

#16 Post by mistfire »

@musher0 and @battleshooter sorry for the long wait. I will try to upload my .xinitrc. It is not a reinventing the wheel. Its just a modification. It can support almost all major desktop environment also it performs some tweaks for active desktop environment. It can also use spacefm if a desktop environment selected was has no desktop.

User avatar
Smithy
Posts: 1151
Joined: Mon 12 Dec 2011, 11:17

#17 Post by Smithy »

quote=musher0

Is this line ok:

Code: Select all

# (...)
	tint2)[ -x /usr/bin/tint2 ] && tint2 -c ~/.config/tint2/tint2rc 2>/dev/null & ;; # musher0, following Smithy's suggestion. Also ref.: https://wiki.archlinux.org/index.php/Tint2
		esac ;;
# (...)
I've attached how the .xinitrc looks now, with this tint2 addition.
Constructive criticism most welcome.

Hopefully nilsonmorales will give it the once over Musher :)

s243a
Posts: 2580
Joined: Tue 02 Sep 2014, 04:48
Contact:

#18 Post by s243a »

Well we're discussing this script can I ask that we test it on virtualbix also. There is a bit of a chicken and egg problem with using virtual box's guest services when puppy is the guest

I discuss this here:
http://www.murga-linux.com/puppy/viewto ... 358#979358

Original english at bottom of the post.

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#19 Post by musher0 »

Hello s243a.

I have read the English translation of your referenced post on the German thread:

I will try to say nothing about your virtual box being a WhineDose virtual box. :lol:
Why can you not run WhineDose as a virtual box under PuppyLinux? ;) In short I
know nothing about virtual boxes.

Another idea that came to my mind: your compatibility problem can be upriver from
the .xinitrc: in the script called "xwin" or with some utility within the initrd itself.
These are executed before .xinitrc.

About your last paragraph in that post: mistfire has designed a fantastic command
line utility that is the equivalent of Puppy Package Manager. It is called "puppy-get",
and it is up to version 1.5. You can get it here:
http://murga-linux.com/puppy/viewtopic. ... ost#970741
Perhaps it can solve that part of your troubles.

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

musher0
Posts: 14629
Joined: Mon 05 Jan 2009, 00:54
Location: Gatineau (Qc), Canada

#20 Post by musher0 »

@Smithy

Indeed, reading what nilsonmorales has to say about editing the .xinitrc would be great!
Pity he has not been around the forum much lately. (I think.)

BFN.
musher0
~~~~~~~~~~
"You want it darker? We kill the flame." (L. Cohen)

Post Reply