On Wed, 2011-08-31 at 11:08 +0100, Rob Spanton wrote:
On Tue, 2011-08-30 at 01:46 +0200, Kai-Martin Knaak wrote:
With a number of recommended work-flows PCB and gschem do not
return to the last saved state. Instead, they update to the
current state of the source file. The gsch2pcb
On Mon, 2011-09-05 at 12:09 +0100, Richard Barlow wrote:
On Wed, 2011-08-31 at 11:08 +0100, Rob Spanton wrote:
On Tue, 2011-08-30 at 01:46 +0200, Kai-Martin Knaak wrote:
With a number of recommended work-flows PCB and gschem do not
return to the last saved state. Instead, they update to
Richard Barlow wrote:
On Tue, 2011-08-30 at 01:46 +0200, Kai-Martin Knaak wrote:
With a number of recommended work-flows PCB and gschem do not
return to the last saved state. Instead, they update to the
current state of the source file. The gsch2pcb work-flow relies
on the ability to
I'm also planning on implementing the same behavior in gschem which
currently depends on GTK 2.10. Any arguments to upping this to 2.18 too?
Even the Windows builds use 2.20. I'd say, bump configure.ac to need
2.18 - and do nothing else - and see if anyone trips over it. Then
we'll know if
On Sep 5, 2011, at 9:34 AM, DJ Delorie wrote:
I'm also planning on implementing the same behavior in gschem which
currently depends on GTK 2.10. Any arguments to upping this to 2.18 too?
Even the Windows builds use 2.20. I'd say, bump configure.ac to need
2.18 - and do nothing else -
On Mon, 2011-09-05 at 10:38 -0700, Steven Michalske wrote:
On Sep 5, 2011, at 9:34 AM, DJ Delorie wrote:
Er, what gtk do the Mac builds use?
Macports is at 2.24.5
Fink is at 2.18.9
Homebrew is at 2.24.6
Do you happen to know if there are any builds of GTK 3.0 out there yet?
--
Peter
Macports is at 2.24.5
Fink is at 2.18.9
Homebrew is at 2.24.6
Thanks!
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
On Sep 5, 2011, at 10:49 AM, Peter Clifton wrote:
On Mon, 2011-09-05 at 10:38 -0700, Steven Michalske wrote:
On Sep 5, 2011, at 9:34 AM, DJ Delorie wrote:
Er, what gtk do the Mac builds use?
Macports is at 2.24.5
Fink is at 2.18.9
Homebrew is at 2.24.6
Do you happen to know if there
On Mon, 2011-09-05 at 12:42 +0100, Peter Clifton wrote:
On Mon, 2011-09-05 at 12:09 +0100, Richard Barlow wrote:
I've started implementing this[1] with a little help from the gedit
source. Unfortunately the info bar widget that I've used was introduced
in GTK 2.18 and PCB currently depends
On Mon, 2011-09-05 at 21:40 +0100, Richard Barlow wrote:
Sorry Richard - I beat you to it - committed to git HEAD of PCB last
night ;) I bumped PCB's GTK version requirement to 2.18.
Haha, nice. I suspected you were working on this after seeing your
commits cleaning up gui-top-window.c. I
On Tue, Sep 6, 2011 at 6:40 AM, Richard Barlow
rbar...@studentrobotics.org wrote:
I've made a couple of small modifications to the message that's
displayed to the user in the info bar[1]. It would also be good if when
reloading/reverting the file the state of the UI wasn't reset too, it's
On Mon, 2011-09-05 at 21:55 +0100, Peter Clifton wrote:
Looking at where I hooked up my code, I have hooked it up in a stupid
place - the file monitoring is cancelled and re-wired every time PCB
handles a menu action!
It probably needs to hook up so it is only called upon the PCBChanged
On Tue, 2011-08-30 at 01:46 +0200, Kai-Martin Knaak wrote:
With a number of recommended work-flows PCB and gschem do not
return to the last saved state. Instead, they update to the
current state of the source file. The gsch2pcb work-flow relies
on the ability to change the *.pcb file in the
On Wed, 2011-08-31 at 11:08 +0100, Rob Spanton wrote:
On Tue, 2011-08-30 at 01:46 +0200, Kai-Martin Knaak wrote:
With a number of recommended work-flows PCB and gschem do not
return to the last saved state. Instead, they update to the
current state of the source file. The gsch2pcb
We would probably need the g_file_monitor_file API in GLib/GIO.
Given the nature of PCB, I'd suggest tying it to the changed flag of
the loaded PCB - so if you haven't edited it yet, you see reload but
if you have unsaved changes, you see revert.
On Wed, 2011-08-31 at 19:44 -0400, DJ Delorie wrote:
We would probably need the g_file_monitor_file API in GLib/GIO.
Given the nature of PCB, I'd suggest tying it to the changed flag of
the loaded PCB - so if you haven't edited it yet, you see reload but
if you have unsaved changes, you see
Given the nature of PCB, I'd suggest tying it to the changed flag of
the loaded PCB - so if you haven't edited it yet, you see reload but
if you have unsaved changes, you see revert.
Gah, PLEASE NO.
Well, yeah, I wouldn't recommend magically changing menu buttons at
all, but it's better
On Wed, 2011-08-31 at 20:43 -0400, DJ Delorie wrote:
Given the nature of PCB, I'd suggest tying it to the changed flag of
the loaded PCB - so if you haven't edited it yet, you see reload but
if you have unsaved changes, you see revert.
Gah, PLEASE NO.
Well, yeah, I wouldn't
Peter Clifton wrote:
Picking GIMP and gedit as examples of popular, well written
applications, they both use Revert.
However, gimp is unlikely to be used like we do with *.sch and
*.pcb files. That is, use third party tools to manipulate them
and reload the result to the GUI.
gedit solves
I like doing tricks with scripts or with the text editor. Some features of
gschem are not even accesssible via the GUI. The revert action in the file
to propagate the changes to the GUI. menu. However, under these circumstances
this is not a revert in the original meaning of the term.
Proposal:
On Mon, 2011-08-29 at 19:30 +0200, Kai-Martin Knaak wrote:
I like doing tricks with scripts or with the text editor. Some features of
gschem are not even accesssible via the GUI. The revert action in the file
to propagate the changes to the GUI. menu. However, under these circumstances
this
21 matches
Mail list logo
