Open 2 ROX windows

[Lobster]

ah thanks - that makes perfect sense especially

in Xfe I have the 2 file-panels always at the same position, and can navigate very fast using the tree on the left.

In fact this was the one facility I tried to find in rox because it would indeed be useful to open two rox windows - which is often what I do.
I have a feeling it is the sort of thing that can be configured (with extra scripting)

It seems others might have similar requirements and so this will be very useful to them . . .

Thanks again

[Guest]

to open a second (or third or fourth) rox window, click a folder (or button) with the middle mouse button

[Lobster]

to open a second (or third or fourth) rox window, click a folder (or button) with the middle mouse button

I have a two button mouse

A piece of Jewish wisdom suggests:
"Of any two options - choose the third"

This might be the practical enactment of that.
In many versions of Linux the third button can be simulated (on a two button mouse) by clicking both bottons at the same time (I would have said simultaneously - but not sure I can spell it . . .)
- never found out how to do this in Puppy - I might have to try out my maverick serial wheel mouse . . . again . . .

thanks for the reminder . . .

[Guest]

you can right click a folder and click Windows, New Window or Parent, New Window

you can right click the Home or UpArrow button to open a new Home or Parent window

you need a 3 button mouse to run Linux properly

[MU]

This dotpup will run 2 Windows side by side.

Edit /usr/local/run2windows/run.sh to add your own program (default is "rox") and position/size of the windows.

Then drag this script to your desktop and click on it

The part to edit looks like this:

Code: Select all

PROG=rox

X1=0
Y1=0
W1=400
H1=700


X2=420
Y2=0
W2=400
H2=700

This also works with windows that do not have an --geometry -option.
Small example of what you can do with wxbasic which is included

** edit ** Update: the script now installs to /usr/local

Mark

[Flash]

yes.

The library is 3.3 MB, adie 150 kb, and xfe 230 kb.

XFE will run only with this library-version.
XFE oriiginally has an additional texteditor, but it is of very bad quality, so I took the fox-editor adie.

These together are one of the first things I install together on a new machine, as they build a good team.

Do you think it would be better to make separate dotpups?

Mark

No. Bundle apps together with their libraries, is what I say.

[Lobster]

I agree with Flash

- tried to get the two Rox windows working
- seems set up for wxbasic but not working with wxbasic not Rox
- the code seemed reasonably straightforward and with a couple of hours might have sorted it and learnt something

- but hey I am lazy . . .

I am sure it is working but there is something I do not understand.

The same with separate libraries - some of us go to libraries for books
- not sure what or why or how these extra libraries are called, required or whatever . . .



I must admit (in my case at least) you most assume that the end user is expecting a simplicity and ease of use that gets easier . . .

[Guest]

Lobster

When you install the run2windows.pup, you have a new folder in /my-applications called run2windows.

So to test it, open rxvt, and type:

cd /root/my-applications/run2indows
./run.sh

Now the 2 rox-windows should start.
If not, you should get an error-message, please post it here.

Mark

[MU]

yes, just tried it with a clean pup1.

The only thing that might be confusing:

By default, rox does not run a .sh -file like an executable.
So you wil have to right-click it first, -> set run-action -> sh $1

Or rename "run.sh" to "run"

Mark

[Lobster]

Thanks MU - I get easily confused.

Thanks guys got it working now . . .

[MU]

fine

I think in future dotpups I should call my scripts "run" and not "run.sh".

Mark

[GuestToo]

i think .sh files used to have /bin/sh setup as the default Run Action

in any case, i did setup the .sh file run action in my Rox 2.2.20 dotpup package ... so this can be a cause of confusion

another cause of confusion: .sh files start with a different working dir when clicked ... for example, if you create 2 files called foo and foo.sh

#!/bin/sh
xmessage `pwd`

when you click foo, the working dir will be the dir foo is in
when you click foo.sh, the working dir will be /root (or $HOME)

so for executable files you click, it is probably better not to name them with a .sh extension

i have a roxapp with an AppRun exectuable in the appdir that starts/stops Privoxy/Tor ... i use code something like:

if pidof privoxy | grep [0-9] > /dev/null
then ...

to test whether privoxy is running or not
(i use pidof instead of ps because ps won't work properly if the PATH to the executable is too long ... i use grep [0-9] because busybox's pidof does not return a true/false value ... by the way, spot and nobody can't write to /dev/null unless you change the permissions)

what's peculiar, is the test often doesn't work properly if the working dir is /root ... i'm not sure why, but a simple workaround is to cd /tmp first, or cd to any dir but /root

Puppy does not always do what you would expect, because of busybox

[Lobster]

Puppy does not always do what you would expect, because of busybox

We are using Bash instead of Ash by default in 1.0.5
How does Busybox fit in?

[MU]

GuestToo,

Thanks for the explanation.
This behavour (setting another path) reminds me of Konqueror doing the same.

For this reason I always add this to my scripts:

Code: Select all

mypath=`echo $0|sed 's/[^/]*$//'|sed 's/\/$//'`
cd $mypath

This method tries to find out the "real" path by using $0, what is the name of the script (including the path).
The following SED just cuts the script-name from $0, so there remains the path.

Without this, my scripts that run wxBasic-Programs in a subfolder /resource would not work.

Seems to work here in rox too

Mark

[GuestToo]

We are using Bash instead of Ash by default in 1.0.5
How does Busybox fit in?

ash is a program
it's a shell ... basically, you type commands like:

ls /root
cd /tmp
rm /etc/mousedevice
xwin fvwm95

and the program executes your commands ... it's what a shell does

bash is an enhanced version of ash with more features

older versions Puppy did not have bash

older versions Puppy did not have ash either ... it had a smaller, simpler version of ash in the busybox program

busybox is a executable file that has in it replacements for some of the more useful Gnu-Utilities, including a replacement for th ash executable

if you look in /bin, for example, you can see many of the programs that would normally be executable files, are just symlinks to busybox ... for example, rpm2cpio, cpio, cut, dd, df, dmesg, echo, free, head, kill, ls, mount, umount, ln, more, ping, rm, sleep, top, touch ... and so on

if you had the real gnu-util programs, they would take up 10 or 20 megs more space than busybox

but ... they are simpler versions of the real programs ... they don't have all the features that the real programs have, and they may behave a little differently

which is why you can't just start using bash and expect every bash script to work properly ... bash scripts use these gnu-utils, and may or may not work properly with the busybox replacements

[Lobster]

Ah - thanks G2 - very useful explanation . . .

So in essence if someone wanted the Full Bash they would need a 20-30 meg dotpup/pupget and this would enable all theose potential scripts

- the more careful way would be to go through the script and just include those progs / widgets and commands needed to run in Puppy . . .

. . . a lot to learn . . .

[MU]

I updated run2windows (see first page)

Now it installs to /usr/local ,and it is easier to uninstall (simply run the installer again)

Mark

[MU]

Updated it again.

Now it will set itself as a menue-entry to Puppy-wxB-Menue.