golly-test Mailing List for Golly

Brice:

> I'd say choose nedit if you find it on your system too.

Unfortunately it doesn't exist anywhere on my vanilla Debian system.
Given that an initial guess is likely to be wrong on Linux I think
I might initialize it to an empty string so the first time you
right/ctrl-click on a file you'll get a dialog asking you to choose
your preferred text editor.

Thanks for all the info Brice -- very useful!

Andrew

Brice:

> I did a quick google and the alt-click "feature" can be turned off in both  
> the KDE and Gnome control centers... somewhere. I think this "feature" is  
> probably used about once every time someone does it accidentally and  
> wonders why the hell their window is moving! So I'd say it's fair game.

Okay, that's somewhat comforting to hear.  I found where to disable it
in my Gnome system: Applications > Dekstop Preferences > Windows.
(It doesn't actually let you disable it, but you can change the key.
I chose Super, which means the command key on my Mac.)

Andrew

On Mon, 28 Apr 2008 10:06:15 -0400, Brice Due <bri...@gm...> wrote:

> I'd say choose nedit if you find it on your system too.

...and I doubt you need to prefix it with a path. Distros can vary in  
their directory structures. I can type nedit at any command line and it  
pops right up. If it's installed it will likely be on the PATH.

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Mon, 28 Apr 2008 09:53:22 -0400, Brice Due <bri...@gm...> wrote:

> And everyone is anal about their text editor prefence, so your guess is  
> likely to be wrong most of the time.

My system doesn't even have gedit installed... and it's Xandros -- an  
out-of-the-box easy linux desktop. Every distro is going to be different.  
But...

Another google yielded this: NEdit, the universal editor of the Unix world  
( http://www.linuxfocus.org/English/March2000/article138.shtml ). It's a  
bit rambling so don't bother reading the link.

But it seems nedit is likely a better choice for a universal default than  
gedit -- which is probably the gnomer's port to their beloved desktop  
framework, when nedit will run just fine under Gnome as is. Whatever. I  
can't wait till they finish the project which claims it will unify the  
underlying frameworks behind Gnome and KDE!!!

I'd say choose nedit if you find it on your system too.

-brice

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Mon, 28 Apr 2008 08:38:54 -0400, Andrew Trevorrow  
<an...@tr...> wrote:

>> Is there a single hotkey that can toggle Hand and Pointer modes?
>
> One problem with this sort of UI design is that you can quickly run
> out of modifier key combos!

There's always the third mouse button! :) (ha ha! that's a linux joke --  
real operating systems have *three* mouse buttons... groan.)

> A couple of Linux questions while I have your attention...
>
> 1. On my Debian system, alt-clicking seems to be reserved for dragging
> the entire window regardless of where you click in the window.
> Is that standard on all Linux flavors?  If so, it's a real pity --
> one less click modifier available!

By default the KDE desktop assigns this action. I dunno about Gnome, which  
is the other major desktop. But the underlying X windows system is ultra  
flexible (but not ultra friendly), so you can assign any action you like  
to any event combo.

I did a quick google and the alt-click "feature" can be turned off in both  
the KDE and Gnome control centers... somewhere. I think this "feature" is  
probably used about once every time someone does it accidentally and  
wonders why the hell their window is moving! So I'd say it's fair game.  
Most people who will be serious Golly users will have no issues with  
turning off this "feature" -- they may not even know it exists!

On my KDE control center it's found under General Settings / Window  
Behavior / Actions, In the Inner Window box you can pick a modifier key  
and then the actions associated with modifier-{each mouse button}. To  
inactivate the alt-click drag "feature" just change the left click action  
to nothing and leave the modifier selection as Alt. The even should then  
get passed through to the active app. I just did this on my system and it  
works.

FYI: A nifty X program is xev, which shows you a detailed trace of X  
events as they are being generated. I passes the events through so you can  
run it while working on another prog. This might be useful on systems  
where people have remapped their keymaps and/or their mouse behaviors at a  
low level (i.e. before X boots). If you ever have the pleasure of working  
on such a system, xev can help you understand what's going on. Plus it's  
neat!

> 2. I've added some code to allow opening a pattern/script file in
> your preferred text editor by right-clicking or ctrl-clicking on
> a file in the navigation panel.  The Prefs > File dialog has a new
> button that lets you select your preferred text editor, but I'd like
> to make a good initial guess at this.  On Linux I check to see if
> the VISUAL environment var is defined, then EDITOR.  If neither is
> defined then I default to /usr/bin/gedit.  Does that sound sensible?
> Neither var is defined on my Debian system so I'm curious to know if
> they are defined on your system.

This one's a toughy. VISUAL and EDITOR are used by console windows and  
non-windowed terminal sessions. So it's not surprising it's not set on  
distros that are primarily used as grapical desktops. I tried a quick  
google for info about determining the default editor under both KDE and  
Gnome, and didn't find any simple solution. My impression is that this is  
handled by the file managers as filetype associations. If you were looking  
for an award, you could track down the Gnome way and the KDE way and try  
both. I'd say it would be a waste of your time. Again, any linux Golly  
user serious enough to be using a text editor will have no problem setting  
up the link. And everyone is anal about their text editor prefence, so  
your guess is likely to be wrong most of the time.

Hope this helps!

-brice

> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Golly-test mailing list
> Gol...@li...
> https://lists.sourceforge.net/lists/listinfo/golly-test



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Brice:

> Is there a single hotkey that can toggle Hand and Pointer modes?

Not at the moment, but it would be simple enough to implement.
(I'm assuming by Pointer mode you mean Selection mode; ie. the cross
cursor is active.)  We already use the shift key to toggle between
Zoom In and Zoom Out modes, so it would be nice to use the same modifier
for toggling Hand and Selection modes.  We currently use shift-clicking
in Selection mode to expand/shrink the current selection but, as I argued
earlier, I think that will have to go if we support multi-rect selections.
One problem with this sort of UI design is that you can quickly run
out of modifier key combos!

A couple of Linux questions while I have your attention...

1. On my Debian system, alt-clicking seems to be reserved for dragging
the entire window regardless of where you click in the window.
Is that standard on all Linux flavors?  If so, it's a real pity --
one less click modifier available!

2. I've added some code to allow opening a pattern/script file in
your preferred text editor by right-clicking or ctrl-clicking on
a file in the navigation panel.  The Prefs > File dialog has a new
button that lets you select your preferred text editor, but I'd like
to make a good initial guess at this.  On Linux I check to see if
the VISUAL environment var is defined, then EDITOR.  If neither is
defined then I default to /usr/bin/gedit.  Does that sound sensible?
Neither var is defined on my Debian system so I'm curious to know if
they are defined on your system.

Andrew

On Sun, 27 Apr 2008 22:13:55 -0400, Andrew Trevorrow  
<an...@tr...> wrote:

> Maybe I'm missing something, but don't we already have that capability
> via the hand cursor?  If we have a floating selection then couldn't
> the hand cursor be used to drag the selection or canvas, depending
> on which was clicked?

Oops, maybe. It's been a while since I used Golly for any editing.

Is there a single hotkey that can toggle Hand and Pointer modes? What I  
was mostly getting at was making the panning almost effortless to access  
*while* doing edit stuff. So if Hand is a hotkey away and then Point is  
another hotkey, then that's alot more keys than a modifier + click to pan,  
then release the modifier and you're back in Pointer mode. *That* would  
blow even MCell out of the water!

Thanks for wading through all my words!

-brice

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Brice:

> Hi Dave, fellow MCell zealot! Actually, one more thing MCell lacks -- and  
> which would be stupendously useful and make Golly truely GREAT -- would be  
> to add click-n-drag panning. With MCell style floating selections,  
> clicking anywhere IN a selection allows you to drag the selection around.  
> If clicking OUTSIDE the selection allowed you to drag the canvas around...  
> that would be stupendously useful! ...

Maybe I'm missing something, but don't we already have that capability
via the hand cursor?  If we have a floating selection then couldn't
the hand cursor be used to drag the selection or canvas, depending
on which was clicked?

I'm with Brice on not hiding the "MCell editing style" option in
the prefs.  Perhaps we just need a "Float Selection" flag in the Edit
menu (with maybe an equivalent toggle button in the tool bar or the new
edit bar).  When that flag is ticked we switch to a floating selection
and all editing commands (and their shortcuts) behave as in MCell.

Anyway, I'm quite happy to stay out of these decisions.  Dave, if you're
the one implementing these changes then best if you and Brice come up
with a design that makes you happy.  I'll only pipe up if I strongly
object to something. :)

> In reality, most non-trivial patterns, big and small, probably came into  
> being by way of the old adage about inspiration (1%) and perspiration  
> (99%). Some of us find it fun! ;)

And the rest of us are grateful. :)

Andrew

Dave:

> I agree about a "lasso" tool being a _very_ handy thing to have --

Yep, that would be handy.  We might need to implement a floating tool
bar with all the various edit tools (other handy ones might be an
eraser, line tool, etc).  I'm not a big fan of floating tool bars --
I get sick of moving them out of the way -- but it might be the best
solution.  Or else have another fixed-position bar somewhere:
vertical and next to the current tool bar, or horizontal and under
the layer bar.

> Golly could just create a multi-selection made of 1xN rectangles, if
> necessary.  A lasso tool is one thing that MCell doesn't have.  Adding
> that to Golly would dodge about half of the awkward spots with editing
> and rephasing, right there -- as long as the Ctrl+Space and
> Shift+Space functions will still work correctly on adjacent
> rectangular subselections, with no edge effects in the middle of a
> selected patch.

I don't think there'd be any problem.  The way to implement advancing
inside a multi-rect selection would be to copy (and clear) all the
selected rects into a new empty universe, step that universe by 1 gen,
then copy the selected rects back to the old universe.
Similar code for advancing outside a multi-rect selection.

Which reminds me, I recently discovered that shift+space doesn't work
in the Linux/GTK app (due to yet another wx difference in the way
key events are handled).  I've fixed this in the latest CVS code.

> I've been working on the library end of the problem, and may yet end
> up with something incremental to contribute to the Golly 1.4 rollout
> -- if it doesn't go out too soon.

I'm in no hurry -- I'm not a fan of the "release early, release often"
school of thought.

Andrew

On Thu, 24 Apr 2008 08:00:31 -0400, Andrew Trevorrow  
<an...@tr...> wrote:

> ... but I'm not really into pattern construction (and if I was
> going to create some large artifact I'd probably write a Python script
> to do it rather than use manual editing).

On Sat, 26 Apr 2008 03:38:13 -0400, Dave Greene <dav...@gm...>  
wrote:

> For really tight spaces there is often so much customization --
> welding, substitution of different oscillator casings, moving
> reflectors around some identically-functioning subunits a different
> shape than others -- that making changes by adjusting a script would
> be fairly nightmarish.  E.g., getting gliders past each other without
> colliding often means breaking symmetry somehow, wherever there
> happens to be room to shove reflector pairs around.  Easy to do
> manually, but hard even to _find_ the right subpattern definition to
> modify in a long script...

Andrew, Dave has it exactly right here.

The bottom line is assembly by script is ONLY feasable once you know  
exactly what you want. Exactly. The big problem during assembly -- which  
is really an excercise of trying to find a way to implement an idea / goal  
-- the big problem is that you never quite know how things are going to  
fit together until you start trying. There's no way to predict what  
contortions you will have to go through to make your pattern work. (I am  
excepting patterns which are intrinsically laid out according to some  
mathematical principal.)

For my metacell I had to run scores (maybe hundreds) of gencols searches  
in order to find the pieces that would permit me to even attempt an  
assembly. I had a definite goal of maximizing the ratio of metapixel to  
metacell areas. This forced all the machinery to run in long thin strips  
along two sides of the cell. I can't tell you how many revisions those two  
strips went through before I found a construction that would fit / work.  
Hundreds.

The faster you can assemble & sketch patterns the faster you can explore  
the possibilites, and find the pitfalls you didn't foresee. Writing a  
program / script to help search for a workable packing would probably also  
be a nightmare. Although hersch might be a good starting point. But I  
think that approach is doomed to fail in all but niche cases. Real  
creative insights are often required to bridge the final gaps in an  
assembly -- something the AI people still haven't had any success in  
coding.

In reality, most non-trivial patterns, big and small, probably came into  
being by way of the old adage about inspiration (1%) and perspiration  
(99%). Some of us find it fun! ;)

-brice


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Sat, 26 Apr 2008 03:38:13 -0400, Dave Greene <dav...@gm...>  
wrote:

> A lasso tool is one thing that MCell doesn't have.  Adding
> that to Golly would dodge about half of the awkward spots with editing
> and rephasing, right there

Hi Dave, fellow MCell zealot! Actually, one more thing MCell lacks -- and  
which would be stupendously useful and make Golly truely GREAT -- would be  
to add click-n-drag panning. With MCell style floating selections,  
clicking anywhere IN a selection allows you to drag the selection around.  
If clicking OUTSIDE the selection allowed you to drag the canvas around...  
that would be stupendously useful! No more going to the scroll bars; no  
more switching the left habnd to the arrow keys and then back to the hot  
keys that are needed.... It would make Golly a hand-assembler's paradise!  
I think this would probably require a modifier key to disambiguate click  
to select from click to pan. In that case, then you could probably  
dispense with the "click outside" distinction.

Like I said (sorta), once you implement any kind of non-uniform  
selections, then lasso selections can be grafted on top of that pretty  
easily. A lot of the area decomposition algorithms floating about are  
focused on finding "the best" covering for whatever metric. For  
decomposing a lassoed area, any old covering would be fine since UI  
operations are not performance critical. As long as your algorithm  
reliably avoided pathological decompositions -- one rectangle per cell,  
etc. -- you could just ad hoc the algorithm and get your lasso pretty  
cheap (in programming sweat, that is).


> I still can't
> get along well without MCell-style floating selections, but the
> permanent selections have some definite advantages, too.  Not sure yet
> whether the two models can coexist peacefully -- a Preference setting,
> maybe, to keep it from cluttering up the regular GUI?  Or a toggle
> switch on the toolbar?

I think the best way would be a toggle between modes. Don't hide it in the  
preferences! A hotkey and a GUI button with two states should be plenty.  
This would keep the two philosophies separate. If some enterprising (or  
finiky) user wanted to blend the two ways, maybe the UI setup could let  
them assign operations from either philosophy to whatever keys & clicks  
they wanted. Sort of like creating a custom toolbar in other apps -- let  
the user create their own custom hybrid mode if they choose to. If someone  
came up with a really slick and useful blending, then maybe distribute  
that setup as an optional preferences preset.

I think designing really great UIs is way too hard to take on as a quick  
project -- these things evolve and mature rather than get engineered (or  
come to UI geniuses in revelations and reveries). So trying to blend  
Andrew's aesthetic with Mirek's would probably only result in headaches  
and bad compromises. If you can get both modes into one program, then over  
time people will find the best ways to use them both together, and maybe  
down the road a unified harmony might emerge. Or maybe not. My preference  
would be to setup both modes and let time take it's course. Unless both  
are implemented in one program, there is really no way to make any good  
judgements anyhow.

-brice

P.S. Golly is already GREAT!

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

>  Much thanks for the excellent feedback and suggestions, and for taking
>  the time to explain why you like MCell's editing capabilities.

I'll second that -- saved me a lot of time, too, since Brice wrote
just what I would have written if I hadn't been so dratted busy for
the last couple of weeks.  [Except I didn't even know about
control-click in MCell... but plain old copy/multiple-paste hasn't
been such a bad alternative all these years.]

I agree about a "lasso" tool being a _very_ handy thing to have --
Golly could just create a multi-selection made of 1xN rectangles, if
necessary.  A lasso tool is one thing that MCell doesn't have.  Adding
that to Golly would dodge about half of the awkward spots with editing
and rephasing, right there -- as long as the Ctrl+Space and
Shift+Space functions will still work correctly on adjacent
rectangular subselections, with no edge effects in the middle of a
selected patch.

>  Quite thought provoking!  The truth is that Golly's editing capabilities
>  are somewhat basic because it's just not something that excites me.
>  I admire the patience and skill needed to create such marvels as the
>  metapixel, but I'm not really into pattern construction (and if I was
>  going to create some large artifact I'd probably write a Python script
>  to do it rather than use manual editing).

For really tight spaces there is often so much customization --
welding, substitution of different oscillator casings, moving
reflectors around some identically-functioning subunits a different
shape than others -- that making changes by adjusting a script would
be fairly nightmarish.  E.g., getting gliders past each other without
colliding often means breaking symmetry somehow, wherever there
happens to be room to shove reflector pairs around.  Easy to do
manually, but hard even to _find_ the right subpattern definition to
modify in a long script... As I recall, a lot of the headaches in
writing the p1100-MWSS-gun script had to do with the broken symmetry
at the Equator.  (Should still fix that, now that RWG has pointed out
how...)

Big script-based constructions may become workable when we have a
Group / Ungroup function, a mouse tool to select groups and "drill
down" into subgroups, and an option to save the current configuration
to a script.  Maybe using a defined library of objects.  Xlife has
save-to-script functionality, but the other two would be new
territory.

I've been working on the library end of the problem, and may yet end
up with something incremental to contribute to the Golly 1.4 rollout
-- if it doesn't go out too soon.  My wife is now heading into her
last few weeks of medical school before her boards (!).  From what I
hear, the third year will be even worse, but there may be a breather
here and there before that --

Brice wrote:
> If you could blend both approaches harmoniously, or even modally,
> you would have the best damned Life editor for hand assembly ever
> created! Hands down slam dunk! Precision control when needed,
> fast sketches when desired.

Have been using the 1.4 betas off and on recently, and am getting used
to Golly's strengths in the "precision control" area.  I still can't
get along well without MCell-style floating selections, but the
permanent selections have some definite advantages, too.  Not sure yet
whether the two models can coexist peacefully -- a Preference setting,
maybe, to keep it from cluttering up the regular GUI?  Or a toggle
switch on the toolbar?

>  I've been happy to implement a basic set of editing operations, but
>  it will probably have to be someone else who will take Golly to the
>  next level and match MCell in that area.  Unfortunately, we haven't
>  seen a lot of people willing to help develop the GUI code, perhaps
>  because the hurdle of learning wxWidgets is too high.

I would still theoretically like to step up and volunteer for some of
this, since I have definite ideas about what needs doing (which mostly
match Brice's suggestions).  Still remains to be seen whether I can
escape from my piles of other projects long enough to concentrate on
it.

Should probably finish hashing out a design here before I try fiddling
with the code, though, to avoid doing anything too objectionable --

Keep the cheer,


Dave

Brice,

Much thanks for the excellent feedback and suggestions, and for taking
the time to explain why you like MCell's editing capabilities.
Quite thought provoking!  The truth is that Golly's editing capabilities
are somewhat basic because it's just not something that excites me.
I admire the patience and skill needed to create such marvels as the
metapixel, but I'm not really into pattern construction (and if I was
going to create some large artifact I'd probably write a Python script
to do it rather than use manual editing).

I've been happy to implement a basic set of editing operations, but
it will probably have to be someone else who will take Golly to the
next level and match MCell in that area.  Unfortunately, we haven't
seen a lot of people willing to help develop the GUI code, perhaps
because the hurdle of learning wxWidgets is too high.

Andrew

On Thu, 24 Apr 2008 00:45:34 -0400, Brice Due <bri...@gm...> wrote:

>> - control-click anywhere in the selection to drag the entire selection
>
>  Believe me, it is much much nicer (and more intuitively pleasing) to  
> simply click and drag selections. Someday you should play around with  
> MCell to see how his UI fits together. It's far from perfect, but there  
> are some very savvy and well thought out aspects. IMHO plain clicking to  
> drag is one of them, and selection manipulations in general.

Andrew, To drive my point home, I'll say this: as much as I admire Golly  
for both it's engines and it's GUI innovations, there is absolutely no way  
I could have assembled my metapixel/metacell base pattern using Golly's  
UI. It's too clunky and not streamlined in the right ways to facilitate  
hours and hours of copy & paste pattern rearrangements (like when I was  
searching for workable packings for various machineries). To be fair, I  
was cutting and pasting multicolored life patterns that included the full  
"envelope" of the pattern's future / history -- this made the packing  
problems tractable.

It's not just that I was already familiar with MCell - I wasn't really.  
It's that Mirek got so many cut/paste/selection things so "right" -- right  
in that nebulous sense that's so hard to define, but you know it when you  
find it. I might take a stab at it like this: Golly's UI is more precise  
and elegant, but MCell's UI (for selection manipulations) is more  
intuitive and matches creative workflows better. MCell accomodates  
impulsive actions better, whereas Golly seems biased towards  
pre-meditated, systematic assembly operations... like the ability /  
neccessity of chosing the relationship of the pasted area to the cursor.  
MCell has nothing like that -- it has no need for that since a quick drag  
and a click can accomplish the same operations as fast as you can think  
what you want.

I'm not suggesting that you should bias Golly towards impulsive workflows  
at the expense of systematic ones. I am mostly suggesting that Golly is  
"deficient" in the area of impulsive (for lack of a better word), by-hand  
pattern manipulations. MCell excells at this. If you could blend both  
approaches harmoniously, or even modally, you would have the best damned  
Life editor for hand assembly ever created! Hands down slam dunk!  
Precision control when needed, fast sketches when desired.

One of Mirek's brilliant UI things is Ctrl-click-drag on a selected area.  
This drops a copy at the start location, then drags the duplicated  
selection with the cursor. You can easily seed dozens of copies of a  
subpattern to their appropriate regions from a high level view, then zoom  
in to fine tune things individually. It's so quick and easy! And intuitive  
once you know about it. Add thumbwheel zoom and assembly can fly! Hold  
down the Ctrl and you can drop a string of patterns as fast as you can  
think about it.

When I was sketching together my metacell (feasability studies), I would  
gather large clusters of useful subpatterns which I would select and clone  
this way -- to get the functionality of a pattern pallette. It was quicker  
to pick patterns out by eye than to arrange them in some sort of  
typographical or other order, as in a dictionary clipboard. I litterally  
just grabbed what I wanted: one click-drag to select, ctrl-click drag to  
grab a copy, unclick and I was done!

And if I needed to phase the copy, I inverted the selection, which freezes  
the rest of the universe (selections don't evolve), run the pasted region  
forward, then invert the selection again for final placement. If I needed  
mirroring or rotations, those are all hotkeyed for any active selection,  
even while dragging. It's a very powerful -- and liberating -- system for  
hand-assembly. You have to try it to really understand. It's a different  
philosophy from Golly's current approach. But I feel confident Golly would  
be vastly richer if you could get both styles to play nice together.  
Someday.

But of course this is only one man's prefences, or idiosyncracies. ;)

-brice

P.S. (A small historical note that sorta fits here: the 2048sq. size of  
the metacell was actually dictated by MCell's odd size restrictions on  
universes. I had wanted to go with 4096sq to improve the ratio of  
metapixel area to machinery area, but MCell maxes out at 2500 height,  
100,000 width. Go figure?! I was so committed to MCell because I had tried  
all the other Life editors that run on linux (or under Wine) and couldn't  
imagine finishing the work any other way. The program really is that good  
in some ways.)



-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Thu, 24 Apr 2008 00:15:49 -0400, Andrew Trevorrow  
<an...@tr...> wrote:

> Instead, (and assuming the selection cursor is active) we could:
> - shift-click to add a rect to the current selection
> - alt/option-click to subtract a rect from the current selection
> Thoughts and suggestions are welcome.

The Gimp (and photoshop?) allows glomming of rects. Instead of adding more  
modifier keys to confuse the user, they add mode buttons. For the Gimp  
there are four mode buttons which act like fancy radio buttons. They  
correspond to replace selection, add to, subtract from, and intersect with  
current selection. I recall other apps have similar modal selctions where  
the mode button might display a venn diagram or a plus or minus sign, etc.

A single mode button could cycle through the modes to save UI space. Add a  
hotkey for cycling and this could be as fast and easy as using dedicated  
modifier combos. In this situation, shift modifiers would retain their  
normal meanings (union), and probably should override the selection mode  
for that selection.

If you get ambitious, and since our universe is pretty granular, you could  
also add lasso style selections on top of this kind of rect. glomming  
functionality. You only need a decomposition routine to find a covering of  
the lasso area using rectangles. And it need not be the optimal covering  
(in any sense).

> - control-click anywhere in the selection to drag the entire selection

Believe me, it is much much nicer (and more intuitively pleasing) to  
simply click and drag selections. Someday you should play around with  
MCell to see how his UI fits together. It's far from perfect, but there  
are some very savvy and well thought out aspects. IMHO plain clicking to  
drag is one of them, and selection manipulations in general. Then the  
other hotkeys can be used to perform operations on the selection before  
you drop it (rotate, mirror, clone, etc.)

If you've got a linux distro handy, MCell runs happily under Wine (both  
old and new releases), with maybe a few UI painting glitches, nothing  
consequential. This is how I always run it. (Oh, and the Undo system  
becomes flaky if your universe is greater than a certain size, which I  
forget now.)

-brice

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

I've encapsulated all selection operations in a new Selection class
(defined in wxedit.h).  I haven't added any new functionality --
just shuffled code around -- but this should make it easier
to add support for arbitrarily complex selection shapes.

I'm not planning to do that any time soon, but I've been thinking
about what changes would be needed.  One obvious way to implement
arbitrary selection shapes (including non-contiguous selections)
would be to maintain a list (or dynamic array) of non-overlapping
rectangles.  This list would need to be updated whenever the user
adds a rect to (or subtracts a rect from) the current selection.

We'd probably have to scrap the current method of using shift-clicking
to modify the current selection by expanding/contracting its edges.
The results are likely to be too confusing in cases where the current
selection consists of a number of separate rectangles (eg. what do we
do if the user shift-clicks in the middle of a gap between two rects?).

Instead, (and assuming the selection cursor is active) we could:

- shift-click to add a rect to the current selection
- alt/option-click to subtract a rect from the current selection
- control-click anywhere in the selection to drag the entire selection

Thoughts and suggestions are welcome.

Andrew

Tom:

> I notice that golly is also in debian and there are a fair number of
> patches they have applied there.  I am not confident those patches
> are complete, but we should investigate them anyway.  ...

I've had a look at the patches.  Most of the non-GUI changes are
to allow 64-bit builds and so have been made redundant by your
recent changes.  Most of the GUI changes are to allow compilation
with an older version of wxGTK (probably 2.6.x).  Instead of
including those changes I'd rather try to persuade people to
upgrade to the latest stable wxGTK (any 2.8.x version) because
that will fix some nasty bugs.  Our BUILD file does recommend
wxWidgets 2.7.0 or later.

Andrew

Works great!  I ran golly with a hash memory size of 3.5GB on my
Vista 64-bit system and it worked fine (although Vista was extremely
reluctant to release that much memory).  This means that on a Vista
64-bit system, people can run golly with more than 2GB memory for
hashing, which is great.  (Indeed, a Vista 64-bit system with 8GB of
real memory should comfortably run a full 3.9GB or so golly.)

Thank you Andrew!

I notice that golly is also in debian and there are a fair number of
patches they have applied there.  I am not confident those patches
are complete, but we should investigate them anyway.  I've sent an
email inquiry to the listed maintainer, and asked him what his thoughts
are.

-tom

On Thu, Apr 17, 2008 at 10:37 PM, Tom Rokicki <ro...@gm...> wrote:
> Thanks, Andrew!  That's excellent; I will download it immediately.
>
>  Tonight got out of control, but I am looking forward to hacking on
>  golly again.
>
>  -tom
>
>
>
>  On Thu, Apr 17, 2008 at 6:12 PM, Andrew Trevorrow <an...@tr...> wrote:
>  > 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
>  >
>  >  Golly can now be installed and run in a read-only directory.
>  >  The first time Golly is run, the GollyPrefs file is saved in
>  >  the standard user-specific data directory on each platform:
>  >
>  >  On Linux:    ~/.golly/
>  >  On Mac:      ~/Library/Application Support/Golly/
>  >  On Windows:  C:\Documents and Settings\username\Application Data\Golly\
>  >
>  >  However, you can keep the GollyPrefs file in the app directory
>  >  if you prefer that option (I do because it simplifies testing, and
>  >  also allows multiple copies of Golly to have their own set of prefs).
>  >
>  >  Some scripts (goto.pl/py and metafier.py) that used to save files in
>  >  the Scripts subdir now use a new datadir() command to save their files
>  >  in Golly's user-specific data directory.
>  >
>  >  Other changes:
>  >
>  >  - The Preferences dialog can be opened from the help window by clicking
>  >   on special links (see the example in Help > Changes).
>  >
>  >  - Fixed some problems if you quit Golly while running a script.
>  >
>  >  Tom, the Win app has been built with /largeaddressaware, in case
>  >  you are having trouble building on Vista (I've added that link
>  >  option to makefile-win).
>  >
>  >  Andrew
>  >
>  >  -------------------------------------------------------------------------
>  >  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  >  Don't miss this year's exciting event. There's still time to save $100.
>  >  Use priority code J8TL2D2.
>  >  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  >  _______________________________________________
>  >  Golly-test mailing list
>  >  Gol...@li...
>  >  https://lists.sourceforge.net/lists/listinfo/golly-test
>  >
>
>
>
>  --
>  Check out golly at http://golly.sf.net/
>



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

Thanks, Andrew!  That's excellent; I will download it immediately.

Tonight got out of control, but I am looking forward to hacking on
golly again.

-tom

On Thu, Apr 17, 2008 at 6:12 PM, Andrew Trevorrow <an...@tr...> wrote:
> 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
>
>  Golly can now be installed and run in a read-only directory.
>  The first time Golly is run, the GollyPrefs file is saved in
>  the standard user-specific data directory on each platform:
>
>  On Linux:    ~/.golly/
>  On Mac:      ~/Library/Application Support/Golly/
>  On Windows:  C:\Documents and Settings\username\Application Data\Golly\
>
>  However, you can keep the GollyPrefs file in the app directory
>  if you prefer that option (I do because it simplifies testing, and
>  also allows multiple copies of Golly to have their own set of prefs).
>
>  Some scripts (goto.pl/py and metafier.py) that used to save files in
>  the Scripts subdir now use a new datadir() command to save their files
>  in Golly's user-specific data directory.
>
>  Other changes:
>
>  - The Preferences dialog can be opened from the help window by clicking
>   on special links (see the example in Help > Changes).
>
>  - Fixed some problems if you quit Golly while running a script.
>
>  Tom, the Win app has been built with /largeaddressaware, in case
>  you are having trouble building on Vista (I've added that link
>  option to makefile-win).
>
>  Andrew
>
>  -------------------------------------------------------------------------
>  This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>  Don't miss this year's exciting event. There's still time to save $100.
>  Use priority code J8TL2D2.
>  http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>  _______________________________________________
>  Golly-test mailing list
>  Gol...@li...
>  https://lists.sourceforge.net/lists/listinfo/golly-test
>



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

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

Golly can now be installed and run in a read-only directory.
The first time Golly is run, the GollyPrefs file is saved in
the standard user-specific data directory on each platform:

On Linux:    ~/.golly/
On Mac:      ~/Library/Application Support/Golly/
On Windows:  C:\Documents and Settings\username\Application Data\Golly\

However, you can keep the GollyPrefs file in the app directory
if you prefer that option (I do because it simplifies testing, and
also allows multiple copies of Golly to have their own set of prefs).

Some scripts (goto.pl/py and metafier.py) that used to save files in
the Scripts subdir now use a new datadir() command to save their files
in Golly's user-specific data directory.

Other changes:

- The Preferences dialog can be opened from the help window by clicking
  on special links (see the example in Help > Changes).

- Fixed some problems if you quit Golly while running a script.

Tom, the Win app has been built with /largeaddressaware, in case
you are having trouble building on Vista (I've added that link
option to makefile-win).

Andrew

Okay, I've figured out the link option; it's

   /link /largeaddressaware

That increases the memory space for a simple test program from 2GB
up to the total 4GB.  Yeah!

Now all I need to do is convince wxWindows to compile with this compiler
on this machine (in 32 bit mode so it shouldn't be too bad).

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

I just purchased a 64-bit Vista notebook with 4GB RAM (my old notebook
had a hinge
fail catastrophically).

So far I am underwhelmed with Vista, but that's off-topic.

I plan to make golly work with 64-bit Vista (compiled as a 64-bit
app), but first I thought
I'd see what happens with it as a 32-bit app running on 64-bit Vista.
Theoretically I'm
supposed to be able to use all 4GB of RAM.

In practice, this doesn't work; the program crashes after it has
chewed through 2GB of
RAM, and I'm very unhappy with the style of the crashes.  Once (with
the UI) I got an
empty dialog box, no message, no nothing, just saying "Golly error:" and a hang.

Second, using bgolly, I got a silent exit with no error message.

Now, admittedly, this doesn't happen all the time, but there are at
least two issues here.
First, running a 32-bit app on 64-bit Vista should enable us to use
all 4GB of RAM in one
process.  Second, golly doesn't always seem to always come down nicely
when it does
decide to die.

As long as I tell golly (the hashing part anyway) not to use more than
about 1900 MB,
things appear to work okay.

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

So far, I've only done some basic things, but it works great!  It's very cool.

It's a little odd when in random-scribble mode that occasionally you're
scribbling white instead of black, but it's pretty easy to figure out why that
is and it is consistent of course.

Andrew, great job once again!

On Thu, Apr 3, 2008 at 11:13 PM, Andrew Trevorrow <an...@tr...> wrote:
> The following 1.4 beta versions now allow editing and most other
>  operations while a pattern is generating.  Please give them a try
>  and let me know of any problems.  Golly is now much less modal,
>  so thanks to Dave for encouraging me to look at this.
>
>  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
>
>  I wrote:
>
>  > However, I doubt it will ever be sensible to allow running a script
>  > while generating.  How do we know if the user wants to stop generating
>  > (eg. by running a script like bricklayer.py that creates a pattern)
>  > or continue after modifying the selection (eg. via shift.py)?
>
>  This wasn't all that hard to solve.  If you run a script while a
>  pattern is generating then generating will stop (after the script
>  finishes) only if the script called any of the following commands:
>
>  - new        (eg. bricklayer.py, gun-demo.py, etc...)
>  - open/load  (eg. slide-show.py)
>  - run/step   (eg. oscar.p*, goto.p*)
>  - reset      (eg. goto.p*)
>  - setgen
>
>  If the script didn't call those commands (eg. shift.p*, density.p*,
>  invert.p*, etc...) then generating automatically restarts after
>  the script has finished.  The results seem to be quite sensible.
>
>  I've also made a few other minor changes:
>
>  - If a bad rule string is detected when loading a pattern file then
>   a suitable warning dialog will appear, but it won't stop the
>   pattern data being loaded.  I think this is the safest approach.
>
>  - A comma at the end of an RLE rule string is ignored (this caters
>   for those files that specify color info after the rule).
>
>  - Added support for reading WinLifeSearch output (such patterns
>   always seem to start with "#P ...").
>
>  Andrew
>
>  -------------------------------------------------------------------------
>  Check out the new SourceForge.net Marketplace.
>  It's the best place to buy or sell services for
>  just about anything Open Source.
>  http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>  _______________________________________________
>  Golly-test mailing list
>  Gol...@li...
>  https://lists.sourceforge.net/lists/listinfo/golly-test
>



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

Wow, how did you do that?  That's amazing!  Congratulations!

I gotta check this out.

On Thu, Apr 3, 2008 at 11:13 PM, Andrew Trevorrow <an...@tr...> wrote:
> The following 1.4 beta versions now allow editing and most other
>  operations while a pattern is generating.  Please give them a try
>  and let me know of any problems.  Golly is now much less modal,
>  so thanks to Dave for encouraging me to look at this.
>
>  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
>
>  I wrote:
>
>  > However, I doubt it will ever be sensible to allow running a script
>  > while generating.  How do we know if the user wants to stop generating
>  > (eg. by running a script like bricklayer.py that creates a pattern)
>  > or continue after modifying the selection (eg. via shift.py)?
>
>  This wasn't all that hard to solve.  If you run a script while a
>  pattern is generating then generating will stop (after the script
>  finishes) only if the script called any of the following commands:
>
>  - new        (eg. bricklayer.py, gun-demo.py, etc...)
>  - open/load  (eg. slide-show.py)
>  - run/step   (eg. oscar.p*, goto.p*)
>  - reset      (eg. goto.p*)
>  - setgen
>
>  If the script didn't call those commands (eg. shift.p*, density.p*,
>  invert.p*, etc...) then generating automatically restarts after
>  the script has finished.  The results seem to be quite sensible.
>
>  I've also made a few other minor changes:
>
>  - If a bad rule string is detected when loading a pattern file then
>   a suitable warning dialog will appear, but it won't stop the
>   pattern data being loaded.  I think this is the safest approach.
>
>  - A comma at the end of an RLE rule string is ignored (this caters
>   for those files that specify color info after the rule).
>
>  - Added support for reading WinLifeSearch output (such patterns
>   always seem to start with "#P ...").
>
>  Andrew
>
>  -------------------------------------------------------------------------
>  Check out the new SourceForge.net Marketplace.
>  It's the best place to buy or sell services for
>  just about anything Open Source.
>  http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
>  _______________________________________________
>  Golly-test mailing list
>  Gol...@li...
>  https://lists.sourceforge.net/lists/listinfo/golly-test
>



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

The following 1.4 beta versions now allow editing and most other
operations while a pattern is generating.  Please give them a try
and let me know of any problems.  Golly is now much less modal,
so thanks to Dave for encouraging me to look at this.

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

I wrote:

> However, I doubt it will ever be sensible to allow running a script
> while generating.  How do we know if the user wants to stop generating
> (eg. by running a script like bricklayer.py that creates a pattern)
> or continue after modifying the selection (eg. via shift.py)?

This wasn't all that hard to solve.  If you run a script while a
pattern is generating then generating will stop (after the script
finishes) only if the script called any of the following commands:

- new        (eg. bricklayer.py, gun-demo.py, etc...)
- open/load  (eg. slide-show.py)
- run/step   (eg. oscar.p*, goto.p*)
- reset      (eg. goto.p*)
- setgen

If the script didn't call those commands (eg. shift.p*, density.p*,
invert.p*, etc...) then generating automatically restarts after
the script has finished.  The results seem to be quite sensible.

I've also made a few other minor changes:

- If a bad rule string is detected when loading a pattern file then
  a suitable warning dialog will appear, but it won't stop the
  pattern data being loaded.  I think this is the safest approach.

- A comma at the end of an RLE rule string is ignored (this caters
  for those files that specify color info after the rule).

- Added support for reading WinLifeSearch output (such patterns
  always seem to start with "#P ...").

Andrew