golly-test Mailing List for Golly

Golly 1.4 has been released on sourceforge.
No changes to the candidate versions.

Andrew

Here are release candidates for Golly 1.4:

ftp://ftp.trevorrow.com/beta/golly-1.4-win.zip       (Windows 2K+)
ftp://ftp.trevorrow.com/beta/golly-1.4-gtk.tar.gz    (Linux/GTK+ i386)
ftp://ftp.trevorrow.com/beta/golly-1.4-x11.tar.gz    (Linux/X11 i386)
ftp://ftp.trevorrow.com/beta/golly-1.4-mac.zip       (Mac OS 10.4+)
ftp://ftp.trevorrow.com/beta/golly-1.4-mac1039.zip   (Mac OS 10.3.9)

Changes:

- I think I've fixed all the problems Dave reported.

- The Win app's initial python_lib string is python25.dll.
  This should avoid the Vista problems Tom encountered.

If no problems are reported in the next few days then I'll put
these files on sf.

I know I said I wasn't in a hurry to release 1.4 but I want to
get it out the door so I can start work on some exciting changes.
Tom has been working on an implementation of John von Neumann's
29-state CA.  This is working outside Golly so now we want to
integrate it into Golly.  This means some significant GUI changes.
We need to support more than 2 algos and more than 2 cell states.
Hopefully more news about this over the next few weeks.  I'm really
looking forward to watching JvN's self-reproducing machine running
in Golly!

Andrew

> I tried the current version from CVS, and it is considerably improved:
>  there's no problem with expanding and collapsing tree nodes now.
> However, the old problem still resurfaces if you accidentally click in
> any useless location -- below the list, or in the empty space to the
> left or right of a folder or filename.

Aargh!  Yep, I see that too, and similar problem if you double-click
anywhere (other than on a folder icon).  I think I know the solution
so I'll try it out tomorrow.

Andrew

> No prob -- I think I've found a work around.  I hope to release a new
> build later today.  (Or else try building from latest cvs -- I've committed
> the change.)

I tried the current version from CVS, and it is considerably improved:
 there's no problem with expanding and collapsing tree nodes now.
However, the old problem still resurfaces if you accidentally click in
any useless location -- below the list, or in the empty space to the
left or right of a folder or filename.

Keep the cheer,


Dave

Excellent, you are right, GollyPrefs was there.  I edited it, changed
python24 to python25, and now Python scripts work.

I still wonder where it picked up the python24 string from.

Oh, gosh, I just found it:

TVTPYDIR=C:\Program Files (x86)\Common Files\Lenovo\Python24

Apparently the Lenovo "extra" junk comes with Python24.  I hate all
this extra junk these machines always come from, yet I'm not brave
enough to try a from-scratch installation of the OS.

We will see if other people encounter this issue.  (Maybe the Python
that comes with the Lenovo extra stuff doesn't have a bunch of the
extra modules and that's why I get odd errors.)

On Mon, May 19, 2008 at 9:39 PM, Andrew Trevorrow <an...@tr...> wrote:
>> Oops, just changed hash mem in prefs, saved, restarted golly, hash mem
>> change took, but is not reflected in the only GollyPrefs that find can
>> find on the system.  So I'm not sure where gollyprefs is being stored.
>
> The first time Golly is run on Windows, the GollyPrefs file should be
> saved here:
>
> C:\Documents and Settings\username\Application Data\Golly\
>
> where you just replace "username" with your login user name.
>
> To make life simple, move GollyPrefs into the same directory as the
> exe file and Golly will read it (and write it) there.
>
> This sort of confusion is one of the reasons I dislike the modern
> convention of burying prefs files in hard-to-find locations.
>
> Andrew
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out golly at http://golly.sf.net/

> Oops, just changed hash mem in prefs, saved, restarted golly, hash mem
> change took, but is not reflected in the only GollyPrefs that find can
> find on the system.  So I'm not sure where gollyprefs is being stored.

The first time Golly is run on Windows, the GollyPrefs file should be
saved here:

C:\Documents and Settings\username\Application Data\Golly\

where you just replace "username" with your login user name.

To make life simple, move GollyPrefs into the same directory as the
exe file and Golly will read it (and write it) there.

This sort of confusion is one of the reasons I dislike the modern
convention of burying prefs files in hard-to-find locations.

Andrew

Okay, I tried editing gollyPrefs.  Very strangely, when I do so, I get
the *exact*
same path (yes, I stopped golly, found the *only* gollyPrefs file on
the whole system,
edited it, restarted golly, observed the behavior, then revisited the
gollyPrefs file to
verify that it said python25 and not python24.)

There are *no* python24 files anywhere on the system; I've never
installed python24
(this is a brand new box, new installation of everything; python24
never got its nasty
bits here at all).

Oops, just changed hash mem in prefs, saved, restarted golly, hash mem
change took, but is not reflected in the only GollyPrefs that find can
find on the
system.  So I'm not sure where gollyprefs is being stored.

I do know Vista has some very strange filesystem behavior that's new;
it's trying
to "shield" users from modifications to system files from one another.  I don't
know if that's a factor here or not.  But I cannot find the golly
prefs file that golly
thinks it is working with (and it is indeed successfully working with some file
because changes are persistent across golly invocations.)

The gollyPrefs file I'm looking at is from a prior installation, as it
turns out, and
it says Python24.  But that's the only gollyprefs file I can find, and
it's in an
"ogolly" directory so it should not be visible by the current golly.  Filesearch
files no other "GollyPrefs" file anywhere on the system.

-tom

On Mon, May 19, 2008 at 5:25 PM, Andrew Trevorrow <an...@tr...> wrote:
> Tom:
>
>> When I try to run life-integer-gun-30 though I do get a Python error:
>>
>> No module named string
>>
>> from text.py.
>>
>> A different script gives
>>
>> No module named os
>>
>> So something is clearly not working 100% right in the python world.
>
> Hmm, that's a worry.  I've got Python 2.5 installed and have no problem
> running any scripts.  Try copying these lines:
>
> import golly as g
> import sys
> g.note(str(sys.path))
>
> Then select Run Clipboard -- you should get a dialog showing a list
> of all the paths that Python will search when trying to load a module.
> The last path in the list is added by Golly and should be something
> like "C:\\path\\to\\golly\\Scripts\\Python".
>
> If however you get an error like "No module named sys" then I'd say
> something is not quite right with your Python installation.
>
> Andrew
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out golly at http://golly.sf.net/

> The run-pattern-when-I-expand-dir problem exists on Vista 64-bit.  Sorry.

No prob -- I think I've found a work around.  I hope to release a new
build later today.  (Or else try building from latest cvs -- I've committed
the change.)

> Here's what I get when I run-clipboard; the import sys seems to have worked
> fine, but the path list does look rather odd.
> ...
> In particular note that the dialog box pointed to
> system32/Python-24.zip, which I do
> not have (I do have Python-25.zip), and further, that the lib and lib/plat-win
> directories point to ./ rather than anywhere they should logically point.

Try editing your GollyPrefs file and look for the python_lib setting.
I'm guessing it is "python24.dll" so try changing it to "python25.dll".
Restart Golly and see what happens.

Perhaps you have an old Python 2.4 version that wasn't fully removed
when 2.5 was installed?  That is, python24.dll still exists somewhere
and so Golly loads that but all the path info is somehow wrong
because other stuff no longer exists?

Note that if Golly can't load the given python_lib file it should prompt
you to enter a new name.  Usually you just need to enter "pythonXX.dll"
where XX matches the version installed, but I have seen cases where
I've had to enter the full path to the dll file (no idea why!).

Andrew

The run-pattern-when-I-expand-dir problem exists on Vista 64-bit.  Sorry.

Here's what I get when I run-clipboard; the import sys seems to have worked
fine, but the path list does look rather odd.

When I run Python from the command line, I get instead:

c:\work>c:\Python25-32\python.exe
Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys ;
>>> print str(sys.path) ;
['', 'C:\\Windows\\system32\\python25.zip', 'c:\\Python25-32\\DLLs', 'c:\\Python
25-32\\lib', 'c:\\Python25-32\\lib\\plat-win', 'c:\\Python25-32\\lib\\lib-tk', '
c:\\Python25-32', 'c:\\Python25-32\\lib\\site-packages']
>>>

which looks rather more reasonable.

In particular note that the dialog box pointed to
system32/Python-24.zip, which I do
not have (I do have Python-25.zip), and further, that the lib and lib/plat-win
directories point to ./ rather than anywhere they should logically point.

How does Python determine its lib path?  It's pretty clear the Python
dll is being
found (because Python scripts that don't import much run fine), but somehow
the path is getting bungled when run from within Golly (even when I run golly
from the command line) but not when Python is run directly.

-tom

On Mon, May 19, 2008 at 5:33 PM, Andrew Trevorrow <an...@tr...> wrote:
> Tom:
>
>> Okay, back on Windows XP (32-bit).  (Work.)
>>
>> The key here is to make the list larger than the current app window.  When that
>> happens, I see the behavior you describe; opening a directory so the total list
>> is larger than the window height causes the "top" pattern (in the current view)
>> to be opened, and highlighted.
>>
>> When I get home tonight I'll try it again after resizing the golly window small
>> enough here I can overflow the height.
>
> Please let us know what happens on Vista.  If no problem then it is
> probably an XP bug and I might not be able to do anything about it.
> (Apparently wxWidgets uses the native tree control on Windows
> so it might not be a wxMSW bug.)
>
> Andrew
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out golly at http://golly.sf.net/

Tom:

> Okay, back on Windows XP (32-bit).  (Work.)
> 
> The key here is to make the list larger than the current app window.  When that
> happens, I see the behavior you describe; opening a directory so the total list
> is larger than the window height causes the "top" pattern (in the current view)
> to be opened, and highlighted.
> 
> When I get home tonight I'll try it again after resizing the golly window small
> enough here I can overflow the height.

Please let us know what happens on Vista.  If no problem then it is
probably an XP bug and I might not be able to do anything about it.
(Apparently wxWidgets uses the native tree control on Windows
so it might not be a wxMSW bug.)

Andrew

Tom:

> When I try to run life-integer-gun-30 though I do get a Python error:
> 
> No module named string
> 
> from text.py.
> 
> A different script gives
> 
> No module named os
> 
> So something is clearly not working 100% right in the python world.

Hmm, that's a worry.  I've got Python 2.5 installed and have no problem
running any scripts.  Try copying these lines:

import golly as g
import sys
g.note(str(sys.path))

Then select Run Clipboard -- you should get a dialog showing a list
of all the paths that Python will search when trying to load a module.
The last path in the list is added by Golly and should be something
like "C:\\path\\to\\golly\\Scripts\\Python".

If however you get an error like "No module named sys" then I'd say
something is not quite right with your Python installation.

Andrew

Okay, now I can reproduce the bug -- as you say, it only happens
if a non-folder item is the first item visible at the top of the
tree pane.  This looks very much like a wxMSW bug (no such problem
in Mac/Linux apps) so I'll try to find a work around.

> I only noticed it with this build... but I just looked back at
> previous 1.4s and at Golly 1.3, and it happens there, too (!).

Good -- it means my latest changes haven't caused the problem.

Andrew

Okay, back on Windows XP (32-bit).  (Work.)

The key here is to make the list larger than the current app window.  When that
happens, I see the behavior you describe; opening a directory so the total list
is larger than the window height causes the "top" pattern (in the current view)
to be opened, and highlighted.

When I get home tonight I'll try it again after resizing the golly window small
enough here I can overflow the height.

Also, the Python libraries load fine here.

I'll have to dig and see if I can figure out why Vista won't load the modules.
It may be a path thing; I may not have Python on my path or something.

On Mon, May 19, 2008 at 11:10 AM, Dave Greene <dav...@gm...> wrote:
>> Odd, I don't see that here on Vista 64-bit.  At least, I don't see the
>> top script getting highlighted, and I don't see anything trying to be run.
>> I do have Perl and Python both installed, in the usual place, and both
>> Perl and Python scripts work.
>>
>> Should I tell it my Perl dll is somewhere strange, and see if it tries to load
>> the Perl dll when I +/- on the Python dir entry?
>
> Probably not necessary.  The Perl DLL search I reported originally is
> really just an incidental symptom.
>
> Instead, check for the same problem under Patterns -- hit the +'s to
> expand all the subfolders under Patterns, one after the other.  On my
> test systems, as soon as the full list gets bigger than one
> application window height, Golly starts loading the topmost visible
> treeview node with every expansion or contraction (unless a folder
> happens to be in the top position, in which case it behaves normally).
>
> If you're not seeing this, then maybe we have some sort of weird
> WinXP-specific wx bug (??)  I'm just running Golly straight out of the
> ZIP file, so the problem doesn't seem to be anything weird I'm doing
> with the settings.
>
>> When I try to run life-integer-gun-30 though I do get a Python error:
>>
>> No module named string
>>
>> from text.py.
>
> Hmm, I definitely don't get _that_ behavior, and it doesn't sound
> familiar -- I have Python 2.5 installed in C:\Python25 on both of my
> test machines, and can run all the Python scripts with no problems.
>
> Keep the cheer,
>
>
> Dave
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out golly at http://golly.sf.net/

> Odd, I don't see that here on Vista 64-bit.  At least, I don't see the
> top script getting highlighted, and I don't see anything trying to be run.
> I do have Perl and Python both installed, in the usual place, and both
> Perl and Python scripts work.
>
> Should I tell it my Perl dll is somewhere strange, and see if it tries to load
> the Perl dll when I +/- on the Python dir entry?

Probably not necessary.  The Perl DLL search I reported originally is
really just an incidental symptom.

Instead, check for the same problem under Patterns -- hit the +'s to
expand all the subfolders under Patterns, one after the other.  On my
test systems, as soon as the full list gets bigger than one
application window height, Golly starts loading the topmost visible
treeview node with every expansion or contraction (unless a folder
happens to be in the top position, in which case it behaves normally).

If you're not seeing this, then maybe we have some sort of weird
WinXP-specific wx bug (??)  I'm just running Golly straight out of the
ZIP file, so the problem doesn't seem to be anything weird I'm doing
with the settings.

> When I try to run life-integer-gun-30 though I do get a Python error:
>
> No module named string
>
> from text.py.

Hmm, I definitely don't get _that_ behavior, and it doesn't sound
familiar -- I have Python 2.5 installed in C:\Python25 on both of my
test machines, and can run all the Python scripts with no problems.

Keep the cheer,


Dave

Odd, I don't see that here on Vista 64-bit.  At least, I don't see the
top script
getting highlighted, and I don't see anything trying to be run.  I do have Perl
and Python both installed, in the usual place, and both Perl and Python scripts
work.

Should I tell it my Perl dll is somewhere strange, and see if it tries to load
the Perl dll when I +/- on the Python dir entry?

When I try to run life-integer-gun-30 though I do get a Python error:

No module named string

from text.py.

A different script gives

No module named os

So something is clearly not working 100% right in the python world.

Command-line Python can find those imports no problem.

On Mon, May 19, 2008 at 7:44 AM, Dave Greene <dav...@gm...> wrote:
>>> I did find one new oddity, though:  when I close the "Python" node of
>>> the script tree, using the "-" button, and then re-expand it with "+"
>>> -- left-clicking in either case -- Golly starts looking for
>>> perl58.dll.
>>> ...
>> Wow, I don't see that on my Win system.  Tom, do you see it on Vista?
>>
>> Does it happen immediately after starting up Golly, or do you have
>> to do some other steps first which somehow trigger the problem?
>
> Can make it happen right away.  Just tried it on a different computer
> with Perl installed, and Golly is definitely attempting to run the
> topmost visible script.
>
>> Do you see a similar problem when closing/opening subfolders under
>> Patterns?
>
> Now that you mention it, yes, it can be reproduced there, too.  If
> there's an openable item of any kind at the very top of the treeview
> pane when I expand or collapse a node lower down, Golly will attempt
> to open the item (and will move the treeview selection to it.)  If a
> folder is at the top of the treeview pane, this doesn't happen.  In
> the case of the Patterns folder, this means that expanding or
> collapsing a node sometimes loads a new pattern.
>
>> Are you saying this only started with the latest build?
>
> I only noticed it with this build... but I just looked back at
> previous 1.4s and at Golly 1.3, and it happens there, too (!).  It
> doesn't happen too often in normal use, maybe; unless several
> subfolders are expanded, you don't have more than a screenful of tree
> nodes, so a folder is always at the top and nothing bad happens.
>
>> If you are able to build Golly on that system, please try this:
>> Comment out the 4 Connect calls at the end of MainFrame::CreateDirControls().
>> That will disable the ability to ctrl/right-click, so it would be
>> useful to know if that code is causing the new problem.
>
> I guess the Golly 1.3 data point answers that one -- but yes, a trial
> build is no problem; let me know if you still want me to try it.
>
> Keep the cheer,
>
>
> Dave
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out golly at http://golly.sf.net/

>> I did find one new oddity, though:  when I close the "Python" node of
>> the script tree, using the "-" button, and then re-expand it with "+"
>> -- left-clicking in either case -- Golly starts looking for
>> perl58.dll.
>> ...
> Wow, I don't see that on my Win system.  Tom, do you see it on Vista?
>
> Does it happen immediately after starting up Golly, or do you have
> to do some other steps first which somehow trigger the problem?

Can make it happen right away.  Just tried it on a different computer
with Perl installed, and Golly is definitely attempting to run the
topmost visible script.

> Do you see a similar problem when closing/opening subfolders under
> Patterns?

Now that you mention it, yes, it can be reproduced there, too.  If
there's an openable item of any kind at the very top of the treeview
pane when I expand or collapse a node lower down, Golly will attempt
to open the item (and will move the treeview selection to it.)  If a
folder is at the top of the treeview pane, this doesn't happen.  In
the case of the Patterns folder, this means that expanding or
collapsing a node sometimes loads a new pattern.

> Are you saying this only started with the latest build?

I only noticed it with this build... but I just looked back at
previous 1.4s and at Golly 1.3, and it happens there, too (!).  It
doesn't happen too often in normal use, maybe; unless several
subfolders are expanded, you don't have more than a screenful of tree
nodes, so a folder is always at the top and nothing bad happens.

> If you are able to build Golly on that system, please try this:
> Comment out the 4 Connect calls at the end of MainFrame::CreateDirControls().
> That will disable the ability to ctrl/right-click, so it would be
> useful to know if that code is causing the new problem.

I guess the Golly 1.3 data point answers that one -- but yes, a trial
build is no problem; let me know if you still want me to try it.

Keep the cheer,


Dave

Dave:

> I did find one new oddity, though:  when I close the "Python" node of
> the script tree, using the "-" button, and then re-expand it with "+"
> -- left-clicking in either case -- Golly starts looking for
> perl58.dll.  It appears to be trying to run the topmost visible
> script, since density.pl or another Perl script at the top of the
> window is suddenly getting highlighted.
> 
> I don't have Perl installed on this machine -- will check and see
> later if Golly is really trying to run a script.  The same thing seems
> to happen if I either expand or close the glife subfolder.

Wow, I don't see that on my Win system.  Tom, do you see it on Vista?

Does it happen immediately after starting up Golly, or do you have
to do some other steps first which somehow trigger the problem?

Do you see a similar problem when closing/opening subfolders under
Patterns?

Are you saying this only started with the latest build?
If you are able to build Golly on that system, please try this:
Comment out the 4 Connect calls at the end of MainFrame::CreateDirControls().
That will disable the ability to ctrl/right-click, so it would be
useful to know if that code is causing the new problem.

Andrew

> Right-click in Vista 64-bit works properly; editor opens in front of golly
> (default editor:  notepad).  Very sweet.

And the Help Z-order problem does seem to be fixed when I click on a
script, as well.

I did find one new oddity, though:  when I close the "Python" node of
the script tree, using the "-" button, and then re-expand it with "+"
-- left-clicking in either case -- Golly starts looking for
perl58.dll.  It appears to be trying to run the topmost visible
script, since density.pl or another Perl script at the top of the
window is suddenly getting highlighted.

I don't have Perl installed on this machine -- will check and see
later if Golly is really trying to run a script.  The same thing seems
to happen if I either expand or close the glife subfolder.

Keep the cheer,


Dave

Right-click in Vista 64-bit works properly; editor opens in front of golly
(default editor:  notepad).  Very sweet.

On Sun, May 18, 2008 at 6:19 PM, Andrew Trevorrow <an...@tr...> wrote:
> Dave (or anybody else), please try this new Windows build:
>
> ftp://ftp.trevorrow.com/beta/golly-1.4-win.zip
>
> This should fix the problem with the help window not staying in front
> after clicking on a script that calls help(...).
>
> However, I'm not sure if I've fixed the problem with right-clicking
> on a script/pattern file.  I'm seeing inconsistent behavior on my
> WinXP system, possibly because it's running as a virtual machine
> on my Mac.  I only have a one-button mouse so I've set up the VM to
> emulate a right-click by doing shift-ctrl-click.  If I use this
> method to click on a file then it does open in my editor but Golly
> remains in front -- ie. the editor window opens *behind* Golly.
> However, I can also use my Mac's trackpad to emulate a right-click by
> touching the pad with two fingers while pressing the trackpad button.
> If I use that method then the editor window opens in front of Golly!
>
> So, I'd like to hear what happens when you do a real right-click
> with a multi-button mouse.  If the editor window opens in front of
> Golly then I'll leave things as they are.  If not then I think I'll
> have to give up trying to support right-clicking and we just use
> ctrl-clicking (which works fine on all platforms).
>
> Andrew
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test
>



-- 
Check out golly at http://golly.sf.net/

Dave (or anybody else), please try this new Windows build:

ftp://ftp.trevorrow.com/beta/golly-1.4-win.zip

This should fix the problem with the help window not staying in front
after clicking on a script that calls help(...).

However, I'm not sure if I've fixed the problem with right-clicking
on a script/pattern file.  I'm seeing inconsistent behavior on my
WinXP system, possibly because it's running as a virtual machine
on my Mac.  I only have a one-button mouse so I've set up the VM to
emulate a right-click by doing shift-ctrl-click.  If I use this
method to click on a file then it does open in my editor but Golly
remains in front -- ie. the editor window opens *behind* Golly.
However, I can also use my Mac's trackpad to emulate a right-click by
touching the pad with two fingers while pressing the trackpad button.
If I use that method then the editor window opens in front of Golly!

So, I'd like to hear what happens when you do a real right-click
with a multi-button mouse.  If the editor window opens in front of
Golly then I'll leave things as they are.  If not then I think I'll
have to give up trying to support right-clicking and we just use
ctrl-clicking (which works fine on all platforms).

Andrew

Dave:

> Interestingly, right-click works to open scripts in TextPad, but
> doesn't do anything for patterns.

On my Win system I can't get right-clicking to work for *any* files.
Right-clicking works fine in the Mac/Linux apps so it looks like this
is some sort of wxMSW bug.  I'll try to find a work around.


> The help command also works (in Python, anyway) but it's a little odd.
>  My first sample script just said:
> 
> import golly as g
> from time import *
> g.help("C:\lex_z.htm")
> sleep(5)
> 
> On my Windows system, a browser window shows up, but doesn't get
> populated with any contents until the sleep(5) is finished and the
> script exits.

That's to be expected -- no wx event processing is done during the
sleep call.  When running a script the only time we do event checking
is at the start of each Golly command (this is mentioned in the
"Potential problems" section of Perl/Python Scripting help).


> Anyway, once the script does exit, the Golly application window
> immediately jumps to the front as usual -- so, at least the way I have
> things set up, the browser window instantly disappears!  I have to go
> dig it out from behind the app window.

I've just noticed this happening in my Mac app as well.  It only occurs
if you click on the script file -- if you use Run Recent then the help
window stays in front.  Try copying the following 2 lines:

import golly as g
g.help(g.appdir()+"Help/changes.html")

If you select Run Clipboard then the help window should stay in front,
which is obviously far more desirable!  I think I know how to prevent
the main window moving in front so I'll try that later today.

Andrew

> Changes:
> ...
> - Right/ctrl-click on a pattern/script file to open it in a text editor.
>  Use new button in Prefs > File to select your preferred text editor.

The "Text Editor..." button worked like a charm -- even defaulted to
C:\Program Files to look for an alternate editor (I set it up to use
TextPad).  Haven't been able to pick any holes in the Reset and
Duplicate Layer buttons or the undo-ability of duplicated layers -- at
least not yet.

Interestingly, right-click works to open scripts in TextPad, but
doesn't do anything for patterns.  Control-click works on both scripts
and patterns.

The help command also works (in Python, anyway) but it's a little odd.
 My first sample script just said:

import golly as g
from time import *
g.help("C:\lex_z.htm")
sleep(5)

On my Windows system, a browser window shows up, but doesn't get
populated with any contents until the sleep(5) is finished and the
script exits.  Only the frame of the browser window even gets painted
sometimes, which causes some odd visual effects.

[Also noticed again that it's not possible to ESC out of a sleep()
call -- you tend to get a "Not Responding" message if you try to do
anything with Golly while a script is sleep()ing.  But I think that's
as designed -- if I want responsiveness I have to do something like

for i in range(50):
   sleep(.1)
   g.run(0)

-- which works just fine.]

Anyway, once the script does exit, the Golly application window
immediately jumps to the front as usual -- so, at least the way I have
things set up, the browser window instantly disappears!  I have to go
dig it out from behind the app window.  Not sure if there's anything
sensible that can be done about that.

Definitely looks like we need a new script or three to show off
golly.help() now -- might be time to start importing some interesting
search functionality.  Maybe I could try hanging a usable Golly GUI
onto one of the catalyst search programs somehow.  Any other ideas for
sample scripts?

Keep the cheer,


Dave

New 1.4 beta versions are available:

ftp://ftp.trevorrow.com/beta/golly-1.4-win.zip
ftp://ftp.trevorrow.com/beta/golly-1.4-mac.zip
ftp://ftp.trevorrow.com/beta/golly-1.4-gtk.tar.gz

Changes:

- Added help("foo.html") command to open given HTML file in the help window.
  This allows a script to write info (such as the results of an experiment)
  to a .html file and then display that info very easily.

- Pasting a pattern with an explicit rule can optionally change to that rule
  depending on new settings in Prefs > Edit.  The initial default is
  "never change rule" (ie. the current behavior).

- Added Reset button to tool bar and Duplicate Layer button to layer bar.

- A duplicated layer now starts with a copy of the original layer's
  undo/redo history.

- Right/ctrl-click on a pattern/script file to open it in a text editor.
  Use new button in Prefs > File to select your preferred text editor.

- Error message is displayed if you try to load a .jpg/.jpeg file.

- Fixed wxGTK bug that prevented using shift-space as a keyboard shortcut.

- Mac app allows option-E/I/N/U/` as keyboard shortcuts.

Andrew