Golly 3.3b2

[gameoflifemaniac]

wow thanks

[wildmyron]

I don't see this specific issue in my build. Built from commit c76d5f, wxWidgets v3.1.2, also 64-bit Ubuntu 16.04.

I got my version number wrong -- I use Ubuntu 12. I think the wx developers are overly optimistic about the reliability of wx 3.1! It would be worth rebuilding Golly using the latest stable version (3.0.4) to see if that fixes the various problems you've found. Unfortunately Ubuntu seems to be the flakiest flavor of Linux when it comes to writing wxGTK apps. Of the three flavors I've tried (Fedora, Mint, Ubuntu) Mint seems the most reliable.

I rebuilt Golly with wxWidgets 3.0.4. It doesn't seem to have made much difference. The borders around the cell icons are all fine and the cell state selector scroll bar still looks the same. My libgtk2 version is 2.24.30 and libGL is provided by nvidia-384.130

A separate issue I have with the Linux build is that Golly hangs when I open the About Window. A Help window pops up, titled "About Golly", but it is completely blank. Golly is using about 50% of one CPU. ...

Sounds like there is a wx 3.1 bug in the handling of the GIF animation. Try editing Help/about.html and delete the img link to images/about.gif to see if that avoids the problem.

This suggestion didn't help, and I've since discovered that the same hang occurs on opening the "Set Rule" dialog. I also experience the issue relating to "Could not set current working directory (error 2: No such file or directory)" mentioned here: viewtopic.php?f=4&t=2897&start=0 and haven't been able to resolve it by moving the golly binary into the right directory or running make install (with appropriate --prefix specified to ./configure) as suggested by marioxcc. To be honest I'm not inclined to pursue these issues much further because I don't use Golly on Linux myself, but I did want to provide this info for completeness sake. On the other hand I am willing to test any modifications suggested.

[Andrew]

I rebuilt Golly with wxWidgets 3.0.4. It doesn't seem to have made much difference.

Thanks for trying.

A separate issue I have with the Linux build is that Golly hangs when I open the About Window. A Help window pops up, titled "About Golly", but it is completely blank. Golly is using about 50% of one CPU. ...

I just remembered that this problem (which affects all modal dialogs, like Set Rule) is somehow caused by Ubuntu's global menu bar. To disable the global menu bar on my Ubuntu 12.04 system I used the following command (then rebooted):

Code: Select all

sudo apt-get remove appmenu-gtk appmenu-gtk3 appmenu-qt

You might need to use a different method on later Ubuntu versions. Details are here:
http://askubuntu.com/questions/10481/ho ... ation-menu

I also experience the issue relating to "Could not set current working directory (error 2: No such file or directory)" ...

This one has me stumped. I think it might have something to do with using the configure method to build Golly. That stuff was implemented by Maks Verver and I don't really understand the details. I prefer to use makefile-gtk included in the gui-wx folder. Very easy to use (assuming you've already built and installed wxWidgets as described in docs/Build.html):

Code: Select all

cd /path/to/golly/gui-wx
make -f makefile-gtk clean    (probably best to do this to remove any configure stuff)
make -f makefile-gtk
../golly

[wildmyron]

A separate issue I have with the Linux build is that Golly hangs when I open the About Window. A Help window pops up, titled "About Golly", but it is completely blank. Golly is using about 50% of one CPU. ...

I just remembered that this problem (which affects all modal dialogs, like Set Rule) is somehow caused by Ubuntu's global menu bar. ...

Thanks for reminding me - I've seen this mentioned several times but forgot about it. Disabling the global menu bar for golly prevents the hang from occurring when I open modal dialogs.

I also experience the issue relating to "Could not set current working directory (error 2: No such file or directory)" ...

This one has me stumped. I think it might have something to do with using the configure method to build Golly. That stuff was implemented by Maks Verver and I don't really understand the details. I prefer to use makefile-gtk included in the gui-wx folder. Very easy to use (assuming you've already built and installed wxWidgets as described in docs/Build.html):

Code: Select all

cd /path/to/golly/gui-wx
make -f makefile-gtk clean    (probably best to do this to remove any configure stuff)
make -f makefile-gtk
../golly

OK. I rebuilt with this method and no longer see the "Could not set working directory ..." error message. Thanks for the tip. All the graphical issues are (unsurprisingly) unchanged from the previous build.

[Andrew]

I rebuilt with this method and no longer see the "Could not set working directory ..." error message.

Excellent -- thanks!

All the graphical issues are (unsurprisingly) unchanged from the previous build.

For the edit bar's scroll bar issue I'm wondering if the bar needs to be wider so we see the thumb box etc. Find this line (308) in wxedit.cpp:

Code: Select all

    int scrollbarwd = 100;

Try changing the value to 200 and see if the scroll bar is then drawn correctly.

What about the gradient scroll bar in Prefs > Color for, say, the Generations algo -- is that drawn correctly?

[wildmyron]

Changing the scrollbar width had no effect on the issue. Looking closer I see that all the scrollbars are the same. I compiled and ran the scroll sample which comes with wxWidgets and it has the same issue. To clarify: the scroll arrows appear on hover - they always appear under the mouse. When they appear I can click or drag them to scroll, so everything is functional. Very occasionally the scroll arrows don't appear and then I can't scroll (this seems to be slightly worse on the state selector).

As far as I can work out this has something to do with Ubuntu's use of GTK's overlay scrollbars.

[Andrew]

Changing the scrollbar width had no effect on the issue. ... As far as I can work out this has something to do with Ubuntu's use of GTK's overlay scrollbars.

There does seem to be a known issue with wxGTK and overlay scrollbars. So far the only solution is to disable them. It looks like you can do this globally or just for golly:

https://askubuntu.com/questions/34214/h ... scrollbars
https://askubuntu.com/questions/36448/i ... y-scrollba

Let me know if you manage to find a fix.

[wildmyron]

Changing the scrollbar width had no effect on the issue. ... As far as I can work out this has something to do with Ubuntu's use of GTK's overlay scrollbars.

There does seem to be a known issue with wxGTK and overlay scrollbars. So far the only solution is to disable them. It looks like you can do this globally or just for golly:

https://askubuntu.com/questions/34214/h ... scrollbars
https://askubuntu.com/questions/36448/i ... y-scrollba

Let me know if you manage to find a fix.

Thank you Andrew.

Yes, disabling the overlay scrollbars for golly gives me functional scrollbars throughout the application. They're visually quite different from everything else, but no matter.

I now use the following alias to run my locally built golly

Code: Select all

alias golly="UBUNTU_MENUPROXY=0 LIBOVERLAY_SCROLLBAR=0 ./golly"

A few extra details:
- An alternative to the global menus in Unity is "Locally Integrated Menus" which places the menubar in the title bar for each application (mentioned in one of the StackOverflow links). In Ubuntu 16.04 this is configurable with Settings -> Appearance -> Behavior -> Show the menus for a window -> In the window's title bar. With this setting modal dialogs in golly still hang the application in the same way as the global menu.
- Ubuntu 16.04LTS's golly package is v2.7. It has the same issues (modal dialog hangs and scrollbar behaviour)
- Ubuntu 19.04's golly package is v3.2 (from Debian stable [buster]). I haven't tested that on my Ubuntu because it requires later versions of system installed libraries (including wxWidgets).
- I should probably upgrade my Ubuntu version

[Andrew]

I now use the following alias to run my locally built golly

Code: Select all

alias golly="UBUNTU_MENUPROXY=0 LIBOVERLAY_SCROLLBAR=0 ./golly"

Much thanks! This looks to be the neatest and least-intrusive solution so I've added it to the section on Linux problems in Help > Known Problems.

[muzik]

Since there's been quite a few more bugs found in Bosco's Rule over the past couple years, should i create an updated collection of them to be added to the sample pattern files?

Also, how would I get my updated RainbowASO mashup rule included?

[dvgrn]

... how would I get my updated RainbowASO mashup rule included?

See previous response.

I spent a lot of time getting Patterns/Non-Totalistic/unit-fractions-orthogonal-spaceships pattern working right, packaged into a ZIP file with reasonable comments. The pattern that comes with RainbowASOv3.1 doesn't have comments, and also doesn't have the hyperbolic spaceship stunt-flying arrangement that calcyman suggested.

If someone re-does all that work, I'll check in the new ZIP file. Otherwise I don't really understand why the new version is an improvement over the old one. For now I'll add the link to RainbowASOv3.1 in the current pattern's comments.

[dvgrn]

I've checked in a new utility script for Golly 3.3, toChangeState.lua. For years I've kept a script around called "toChangeColors.py", which allowed me to select an existing cell and change all cells of that color in the current selection to a new state.

"toChangeColors.py" was similar to Andrew's change-state.py in the online Golly Scripts Database. Any of these scripts are basically the piece that Golly has been missing, that would let people do pattern editing in the LifeHistory rule without getting horribly annoyed by the way blue state-2 cells would gradually get littered around the pattern in all the wrong places.

When state-2 cells are handled correctly, they can be hugely useful in lining up different mechanisms in large complex patterns -- but you have to be able to get rid of them when you need to, preferably without having to change cell states 3 through 6. (The Alt+J shortcut removes state-2 cells, but only by switching the whole pattern to plain-vanilla Life. You can switch it back again with Alt+H, but then you've lost any marked cells and labels and so on, and those are also often very useful for editing purposes.)

Improvements over previous scripts:
1) This new script is in Lua, so it will Just Work without a Python install;
2) Like change-state.py, this script allows changing state-0 cells to another state. But the new script is also as fast as toChangeColors.py for non-zero cell states, because it just iterates through a cell list instead of checking every cell in the bounding box.

Bug reports welcome! Suggested improvements also somewhat welcome, especially if they come with Lua code to implement the suggestions.

Code: Select all

-- toChangeState.lua, version 1.0
--   adapted in August 2019 from change-state.py by Andrew Trevorrow,
--   and toChangeColors.py by Dave Greene
-- Switch all cells of a clicked-on color in the selected pattern to the current brush color

local g = golly()
local gp = require "gplus"
local split = gp.split
local oldsecs
local newsecs
local oldeditbar = g.setoption("showeditbar",1)

local function savestate(filename, state)
    local f = io.open(filename, "w")
    if f then
        f:write(state)
        f:close()
    else
        g.warn("Can't save target state in filename:\n"..filename)
    end
end

local ChangeStateINIFileName = g.getdir("data").."changestate.ini"
local targetstate = "0"
local f = io.open(ChangeStateINIFileName, "r")
if f then
    targetstate = f:read("*l") or ""
    f:close()
end
if targetstate==nil then
    targetstate = "0"
    savestate(ChangeStateINIFileName, targetstate)
end

limits = "selection"
seltype = " selected"
r = g.getselrect()
if #r==0 then
    limits = "pattern's bounding box"
    seltype = ""
    r = g.getrect()
    if #r==0 then
        g.exit("No pattern to change.")
    end
end

-- set fill limits to the chosen rectangle
minx, miny, sizex, sizey = table.unpack(r)
maxx = minx + sizex - 1
maxy = miny + sizey - 1

area = g.getcells(r)
if g.numstates() == 2 then
    g.exit("Rule must be multistate.  Use 'Clear' editing tools and invert.lua for cell changes in two-state patterns.")
end

saveoldstate = g.setoption("drawingstate",targetstate)
newstate = targetstate
oldstate = newstate

-- wait for user to click a cell
g.show("Click a cell to change all" .. seltype .. " cells of that type to target state "..newstate.. 
       ". Change drawing state on Edit toolbar to adjust target state. Esc to cancel.")
while true do
    event = g.getevent()
    -- user may change drawing state at any time
    newstate = g.getoption("drawingstate")
    if newstate ~= oldstate then
        g.show("Click a cell to change all" .. seltype .. " cells of that type to target state "..newstate.. 
               ". Change drawing state on Edit toolbar to adjust target state. Esc to cancel.")
        oldstate = newstate
        savestate(ChangeStateINIFileName, newstate)
    end
 
    if event:sub(1,5)==("click") then
        -- event is a string like "click 10 20 left none"
        evt, xstr, ystr, button, mods = split(event)
        x = tonumber(xstr)
        y = tonumber(ystr)
        if x < minx or x > maxx or y < miny or y > maxy then
            g.warn("Click inside the "..limits..".  To change the region affected by the script, hit Esc to cancel, then adjust the selection.")
        else
            oldstate = g.getcell(x, y)
            if oldstate == newstate then
                g.warn("The clicked cell must have a different state\n"
                      .."from the current drawing state, "..newstate..".")
            else
                break
            end
        end
    else
        g.doevent(event)
    end
end
 
-- tell Golly to handle all further keyboard/mouse events
g.getevent(false)

if oldstate == 0 then
    -- special handling for state-0 cells, which don't show up in cell lists
    --   so they must be tested individually by scanning the entire bounding box
    changed = 0
    total = sizex * sizey
    oldsecs = os.clock()
    for row = miny, maxy do
        -- might be large pattern so show percentage done each second
        newsecs = os.clock()
        if newsecs - oldsecs >= 1.0 then
            oldsecs = newsecs
            g.show("Changing cell states: "..string.format("%.1f", 100 * (row - miny) * sizex / total).."%")
            g.update()
        end
        -- allow keyboard interaction
        g.doevent( g.getevent() )
     
        for col = minx, maxx do
            if g.getcell(col, row) == oldstate then
                g.setcell(col, row, newstate)
            end
            changed = changed + 1
        end
    end
    g.show("Changed "..changed.." state "..oldstate.." cells to state "..newstate..".")
else
    -- faster handling for changing nonzero states to another state (including zero)
    oldsecs = os.clock()
    numcellsx3 = #area
    count = 0
    for i=1, numcellsx3-2, 3 do
        -- might be large pattern so show percentage done each second
        newsecs = os.clock()
        if newsecs - oldsecs >= 1.0 then
            oldsecs = newsecs
            g.show("Changing cell states: "..string.format("%.1f",100 * i / numcellsx3).."%")
            g.update()
        end
        -- allow keyboard interaction
        g.doevent( g.getevent() )
        
        if area[i+2]==oldstate then
            g.setcell(area[i],area[i+1],newstate)
            count = count + 1
        end
    end
    g.show("Changed "..count.." state "..oldstate.." cells to state "..newstate..".")
end

-- return to previous Edit Bar setting
g.setoption("showeditbar", oldeditbar)

The script will default to a target state of 0 on its first use. With that setting, it can be used to quickly remove the blue state-2 history envelope cells from LifeHistory patterns. Select an entire pattern (or remove the selection entirely), run the script, and click on any blue cell. It can remove all cells of any other chosen state in the same way, or remove cells from just a small selected area instead of the entire pattern.

For other color-changing tasks -- e.g., changing state-1 cells in the current selection that are intended as text labels to state 5, so that the evolution of the labels won't affect the pattern -- change the current drawing state on either the Editing toolbar or the All States toolbar. This will change the script's target state, and the change will be permanent until the next such change is made. The idea is to allow a series of quick selections and color changes to be made, with the same target state every time, without having to keep re-choosing the target state.