Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 17 Aug 2018, 23:33
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Refitting .xinitrc from the bottom up.
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 3 [34 Posts]   Goto page: 1, 2, 3 Next
Author Message
musher0


Joined: 04 Jan 2009
Posts: 12569
Location: Gatineau (Qc), Canada

PostPosted: Thu 04 Jan 2018, 15:07    Post subject:  Refitting .xinitrc from the bottom up.
Subject description: This could open up Puppy to more WMs and taskbars
 

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.php?p=979231&sort=lastpost#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:
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!!! Wink 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:
# (...)
### 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###

_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)

Last edited by musher0 on Sat 06 Jan 2018, 22:09; edited 1 time in total
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1579
Location: Japan

PostPosted: Thu 04 Jan 2018, 22:01    Post subject: Re: Refitting the end of .xinitrc
Subject description: This could open up Puppy to more WMs and taskbars
 

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:
#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...
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12569
Location: Gatineau (Qc), Canada

PostPosted: Fri 05 Jan 2018, 00:18    Post subject: Re: Refitting the end of .xinitrc
Subject description: This could open up Puppy to more WMs and taskbars
 

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:
#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:
Quote:
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? Laughing

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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
bigpup


Joined: 11 Oct 2009
Posts: 10867
Location: Charleston S.C. USA

PostPosted: Fri 05 Jan 2018, 01:36    Post subject:  

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

_________________
I have found, in trying to help people, that 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 Shocked
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12569
Location: Gatineau (Qc), Canada

PostPosted: Fri 05 Jan 2018, 05:56    Post subject:  

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:
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.
.xinitrc.musher0.zip
Description  Please back-up your current .xinitrc before testing this one. Use at your own risk.
Unpack in /root and make executable.
zip

 Download 
Filename  .xinitrc.musher0.zip 
Filesize  3.44 KB 
Downloaded  56 Time(s) 

_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
MochiMoppel


Joined: 26 Jan 2011
Posts: 1579
Location: Japan

PostPosted: Fri 05 Jan 2018, 09:02    Post subject:  

musher0 wrote:
I did a test by adding this line
Code:
echo blabla > /root/blabla
below the first WM launcher line,

So your test setup reads
Code:
`which $CURRENTWM`
echo blabla > /root/blabla # is not written.
right?

Quote:
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

Quote:
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.

Quote:
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:
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 Rolling Eyes
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 Laughing
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12569
Location: Gatineau (Qc), Canada

PostPosted: Fri 05 Jan 2018, 15:34    Post subject:  

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. Wink

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
.xinitrc.musher0.revised.zip
Description  Same words of caution as above.
zip

 Download 
Filename  .xinitrc.musher0.revised.zip 
Filesize  3.53 KB 
Downloaded  48 Time(s) 

_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)

Last edited by musher0 on Mon 08 Jan 2018, 03:04; edited 1 time in total
Back to top
View user's profile Send private message 
mistfire

Joined: 04 Nov 2008
Posts: 922
Location: PH

PostPosted: Sat 06 Jan 2018, 07:10    Post subject:  

@musher0 X-Slacko Slim has a modified .xinitrc which was edited by myself. It supports almost major Desktop Environments. You can check it out
Back to top
View user's profile Send private message 
Smithy


Joined: 12 Dec 2011
Posts: 909

PostPosted: Sat 06 Jan 2018, 08:58    Post subject:  

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?
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12569
Location: Gatineau (Qc), Canada

PostPosted: Sat 06 Jan 2018, 21:57    Post subject:  

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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12569
Location: Gatineau (Qc), Canada

PostPosted: Sat 06 Jan 2018, 22:00    Post subject:  

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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
Smithy


Joined: 12 Dec 2011
Posts: 909

PostPosted: Sun 07 Jan 2018, 07:32    Post subject:  

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

Code:
#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
tint-panel-xinitrc.zip
Description 
zip

 Download 
Filename  tint-panel-xinitrc.zip 
Filesize  2.74 KB 
Downloaded  52 Time(s) 
Back to top
View user's profile Send private message 
battleshooter


Joined: 14 May 2008
Posts: 1381
Location: Australia

PostPosted: Sun 07 Jan 2018, 19:38    Post subject:  

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

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.

_________________
LMMS 1.0.2, Ardour 3.5.389, Kdenlive 0.9.8
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12569
Location: Gatineau (Qc), Canada

PostPosted: Mon 08 Jan 2018, 03:17    Post subject:  

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

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
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
musher0


Joined: 04 Jan 2009
Posts: 12569
Location: Gatineau (Qc), Canada

PostPosted: Tue 09 Jan 2018, 01:20    Post subject:  

Smithy?

Is this line ok:
Code:
# (...)
   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.
.xinitrc.musher0.rev2.zip
Description 
zip

 Download 
Filename  .xinitrc.musher0.rev2.zip 
Filesize  3.66 KB 
Downloaded  48 Time(s) 

_________________
musher0
~~~~~~~~~~
Siempre será canción nueva... (V. Jara, Manifiesto)
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 3 [34 Posts]   Goto page: 1, 2, 3 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1102s ][ Queries: 12 (0.0120s) ][ GZIP on ]