date:20110905

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"
> action.

Gah - this causes fun and games. I turns out that we only missed our own
save action modifications to the PCB file because of the stupid place I
hooked up the code. (It cancelled and re-attached the file-monitor right
after any menu action - including File->Save of course).

I've pushed a few preliminaries (HID API) to git HEAD to allow the core
to notify us around a SavePCB() call, and to tell us if the filename of
the PCB has changed (e.g. File->SaveAs).

Unfortunately, I can't make it work for the SaveAs case. I'm sure I must
be missing something simple, but I just can't get the file monitors to
ignore changes to the new PCB file despite tracing the fact that we
delete the old file monitor, save the PCB (in the new filename), THEN
hook up the new file change monitor.

I'm _guessing_ that either the saved changes don't hit the disk
immediately, or GLib / GIO is helpfully caching the directory state from
before I hooked up the file monitor - then falsely detecting a change
(as we hook up the new file-monitor right after we wrote to the file).

Anyway, I'm not quite sure how to fix it. It might come down to not
disconnecting the file-change monitor, but adding a flag somewhere to
make the callback ignore the next change we get notified about (after a
save).

Anyway - if you fancy figuring out just what I'm doing wrong, the patch
(work in progress) against git HEAD is attached.

> We could consider splitting that action into "PCBChanged" and
> "PCBReverted" actions (or add arguments to the former), so the GUI can
> do different levels of UI resetting for load and revert.

I added a "revert" parameter to the PCBChanged action, so that should be
a good start for you looking into this. It appears there will be some
special casing in the HID to do, and possibly a bit of work in the core
to make sure it doesn't wipe out more state than it needs as it reloads
the board.

Obviously we need to be careful that we don't get PCB into an
inconsistent state reloading a changed board from disk whilst trying to
keep "some" view settings. Remember that we could notionally change
_anything_ in the PCB file we revert to.

Best wishes,

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
From b3bf8f798e7daf4d9bbf4dac9d0c5725ac6ac911 Mon Sep 17 00:00:00 2001
From: Peter Clifton 
Date: Mon, 5 Sep 2011 22:18:16 +0100
Subject: [PATCH] hid/gtk: Connect up the file-change monitor in a more
 sensible place

I must have had a brain-fail when I hooked it up in the call which sets
the window title. NB: That also gets called after every menu operation!

Hook up the connection in the ghid_sync_with_new_layout() function,
which looks to be a much more appropriate place, however changing this
alone revealed another issue - we now get notified for changes WE make
to the files.

We were avoiding those events as the file-monitor was being reset before
it could pop up, at the end of the menu action which invoked the save).

Hook up to the new HID API (added in the previous commit) which allows
us to temporarily disconnect the file-monitor when PCB's core is saving
to the PCB file.
---
 src/file.c   |1 +
 src/hid/gtk/gtkhid-main.c|3 +
 src/hid/gtk/gui-top-window.c |  271 --
 src/hid/gtk/gui.h|2 +
 4 files changed, 159 insertions(+), 118 deletions(-)

diff --git a/src/file.c b/src/file.c
index be7f6a5..d31b157 100644
--- a/src/file.c
+++ b/src/file.c
@@ -358,6 +358,7 @@ SavePCB (char *file)

   gui->notify_save_pcb (file, false);
   retcode = WritePipe (file, true);
+  printf ("File changes hitting disk now\n");
   gui->notify_save_pcb (file, true);

   return retcode;
diff --git a/src/hid/gtk/gtkhid-main.c b/src/hid/gtk/gtkhid-main.c
index 89d50be..a855aa7 100644
--- a/src/hid/gtk/gtkhid-main.c
+++ b/src/hid/gtk/gtkhid-main.c
@@ -2170,6 +2170,9 @@ hid_gtk_init ()
   ghid_hid.flush_debug_draw = ghid_flush_debug_draw;
   ghid_hid.finish_debug_draw= ghid_finish_debug_draw;

+  ghid_hid.notify_save_pcb  = ghid_notify_save_pcb;
+  ghid_hid.notify_filename_changed  = ghid_notify_filename_changed;
+
   hid_register_hid (&ghid_hid);
 #include "gtk_lists.h"
 }
diff --git a/src/hid/gtk/gui-top-window.c b/src/hid/gtk/gui-top-window.c
index 73bada5..1277da0 100644
--- a/src/hid/gtk/gui-top-window.c
+++ b/src/hid/gtk/gui-top-window.c
@@ -262,6 +262,130 @@ void ghid_hotkey_cb (int which)
   (gpointer) ghid_hotkey_actions[which].node)

Re: gEDA-user: Fwd: Re: [OH Updates] How can you help solve the proprietary tool problem?

2011-09-05 Thread Stephen Ecob

2011/9/6 Kai-Martin Knaak :
> Steven Michalske wrote:
>
>> +1 to bundling plugins with pcb sources..
>
> +1 to merging plug-ins into the main project. There is no point in keeping
> useful features outside. The necessity to compile and keep distinct plugins
> for different versions of PCB is a pain. Also, they tend to bit-rot and break
> when the main source moves on.

+1 also

If you are the author of a PCB plugin -
Next time you do some maintenance on your plugin, please consider
incorporating it into git head.
Your plugin will benefit more people, and you'll no longer have to
deal with the bit rot by yourself.

Stephen Ecob
Silicon On Inspiration
Sydney Australia
www.sioi.com.au
$39 Spartan 6 board with 32MB DDR DRAM ?
http://www.sioi.com.au/shop/product_info.php/products_id/47

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"

2011-09-05 Thread Stephen Ecob

On Tue, Sep 6, 2011 at 6:40 AM, Richard Barlow
 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
> quite annoying for all of the layers to be re-enabled if you're in the
> middle of routing. I'll look into that later.

+1
Very annoying with multi layer boards and a work flow that involves
frequent changes to the PCB from gedit.

Stephen Ecob
Silicon On Inspiration
Sydney Australia
www.sioi.com.au
$39 Spartan 6 board with 32MB DDR DRAM ?
http://www.sioi.com.au/shop/product_info.php/products_id/47


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

Bob Paddock wrote:

> Outside of our group here gEDA/PCB/Et.Al. are seen as toys and hard
> to use.  Maybe we should all asks ourselves why? 

Part of the reason may be seen on youtube. Yesterday, I was surprised
to see a number of geda/PCB tutorials there. I watched only a few. All 
of them made schematic capture look difficult and an enduring task. It
was not that the commentator directly sad so, but because there were 
so many steps involved before a result was visible. There were major 
misconceptions, too. E.g., one author insists, you have to be root to 
change symbols in the lib...

Looks like, the lesson to be learned here is: Us power users should engage
and write better tutorials and make them visible. Upload videos on youtube 
blog about it, write articles in Make Magazine, etc.

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
increasingly unhappy with moderation of geda-user

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"

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 see you've made a load more
> modifications today bringing the code up to date, nice work.

Yes - mostly taking advantage of the GTK 2.18 version bump to get rid of
some deprecated APIs and other issues. (One day we'll be able to compile
with GTK 3.0d!)

> I've made a couple of small modifications to the message that's
> displayed to the user in the info bar[1].

Note that if you hit the revert button, and PCB will still prompt you
for further confirmation if you had unsaved changes.

I deliberately copied the message text straight from gedit in order to
try and keep it consistent with the rest of the desktop, but I'm not
completely against changing it, so long as the new message still fits on
the small-ish screens without undue wrapping/

> It would also be good if when reloading/reverting the file the state of the 
> UI wasn't reset too, it's
> quite annoying for all of the layers to be re-enabled if you're in the
> middle of routing. I'll look into that later.

That would be handy.

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"
action.

We could consider splitting that action into "PCBChanged" and
"PCBReverted" actions (or add arguments to the former), so the GUI can
do different levels of UI resetting for load and revert.

> > > I'm also planning on implementing the same behavior in gschem which
> > > currently depends on GTK 2.10.
> ...
> > Please feel free to take any of the code I wrote to help you on the way
> > with a gschem / gattrib version. I would love to see this consistently
> > across the tools, yet didn't have time to do the gEDA parts at the
> > moment.
> 
> Cool, thanks.

I asked Ales and DJ on IRC earlier, and we have a consensus that bumping
the version requirement to GTK 2.18 is OK.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)

signature.asc
Description: This is a digitally signed message part

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo


> The patch-maintainer does not have to cherry pick anything.

So what you're asking for is a release manager.  Ok, put up some money
to hire one, because we don't have anyone to do that at the moment.

Meanwhile, please stop suggesting changes that require more man-power.
We don't have any to spare.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo


> > The fall back option is to use a release.
> 
> It won't be an option once file format changes kick in. 

Always true for any new feature you want to use.  Wait until there's a
stable release with that feature, then migrate forward.

> In 2005 Debian had 1200 maintainers for 8400 packages.

Maintaining someone else's package in a distro is not the same as
developing those packages in the first place.  And 1200 people is WAY
BIGGER than the geda developer community.

> That is, on avarage every maintainer handles 6.3 packages.

And nine women can have a baby in a month, but the math just isn't
relevent.  The raw ratio of packages to maintainers has nothing to do
with how hard it is for a tiny team to manage multiple release/test
repositories.

> Sigh. I thought I made it clear, that I don't expect guaranteed
> unbroken applications when testing.

Perhaps I was not clear - it doesn't matter how much testing we do,
stuff is going to break and not get found until release anyway.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"

2011-09-05 Thread Richard Barlow

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 GTK 2.12. Is there any argument
> > against upping PCBs GTK version dependency to 2.18? It was released
> > almost two years ago now (23rd Sept 2009).
> 
> 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 see you've made a load more
modifications today bringing the code up to date, nice work.

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
quite annoying for all of the layers to be re-enabled if you're in the
middle of routing. I'll look into that later.

> > I'm also planning on implementing the same behavior in gschem which
> > currently depends on GTK 2.10.
...
> Please feel free to take any of the code I wrote to help you on the way
> with a gschem / gattrib version. I would love to see this consistently
> across the tools, yet didn't have time to do the gEDA parts at the
> moment.

Cool, thanks.

Rich

[1] git://srobo.org/~rbarlow/pcb.git

signature.asc
Description: This is a digitally signed message part

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Strange user interface behavior with gschem-1.6.2.20110115

Josef Wolf wrote:

> So this feature can save at most one click? 

It provides a means to reliably hit that tiny spot of a pin point,
while zoomed out. The feature is "magnetic-mode". it is not 
"auto-complete".

> At the expense of using the undo functionality fairly often?

Well, I can't recall to have entered your szenario, ever. So I certainly
do not use undo faily often, because of it.

> In fact, I was trying to find a
> way to draw the connection in question for several hours before I
> posted to the list.

For the archive: The "correct" way is to provide one or more additional
node with a click somewhere on the empty canvas. If gschem insists on
a poin, where you don't want the net to go (hinted by the circle), then 
hold the [ctrl] key and the circle will always stay with the mouse cursor.

> IMHO, this works against user expectation. After all, the whole point
> of the circle is to signal the user where the connection would be
> done. Connecting to anything other is not exactly what the user would
> expect. 

Fair enough.

> From the perspective of the user it is totally irrelevant
> what algorithm is used internally.

But it is relevant to know, what this mode is intended for -- magnetic-
mode, not auto-complete. I am sure, you got the point now :-)

>> (Auto routing for nets would be a great, nerdy feature :-)
> 
> I tend to disagree here. It works against user expectation. It
> _would_ be a useful feature _if_ it would be disabled automatically
> in situations where it would connect to something different than the
> point where the circle is shown.

IMHO, silent denial of service would make matters worse. It would 
create a sense of uneasiness and loss of control -- "sometimes, the
tool works, sometimes it goes on strike...". A pop-up warning would
be the better choice. Text might be something along the lines 
  "Could not connect with a straight L"

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
increasingly unhappy with moderation of geda-user

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

DJ Delorie wrote:

> 
>> If additional filtering is desired: One of the "core developers"
> 
> Again, we just don't have enough "core developers" to add any burden
> to them.  We need options that *reduce* the load on developers, to
> encourage more participation.

See the "if" in my sentence. Core developers are only required if 
_additional_ filtering is desired. 


>> This wouldn't neceessarily have to be a developer. He or she just
>> has to be familiar with git and the build tools in general.
> 
> If they have commit access to the master git, they need to be a
> developer.  That's kind of our definition of "developer" - you need
> to know enough about what's going on, to make smart choices about
> which patches to pull.

All of them that have been commited by developers to the test repo
and have not been seen to break anything for a reasonable amount of 
testing time. 

The patch-maintainer does not have to cherry pick anything. He 
does not have to review code, either. Just read the bug reports and 
what devs respond. In other words: He automatically commits to git-head
unless a patch had been singled out as the cause of trouble. Of course,
changes may depend on each other. Then patches will be held back until
the blocking feature is ready for prime time.
>From the viewpoint of decision making, this is the same situation as 
now. The developer is responsible for what he commits. Period. Only 
difference is that he commits to git-test rather than to git-head. 

 
> As I said before, that's our procedure - git head *is* our testing
> repo.

It is "unstable" in the debian sense. What I am asking for, is a repo 
that is already tested but not as dated as the current releases tend to
be. Or more specifically: A repo that contains all patches and features
that have been shown to work.


>> A fixed calendar would help. I'd say two months of patching followed
>> by a month of freeze would be fine.
> 
> A fixed calendar won't work as we don't have dedicated developers.
> Our roadmap is to decide on a minimum set of features and bugfixes we
> want in the next release,

I am not talking about fixed calendar for a release. The calendar
is about the internal organization of the testing-to-head-conversion.
Note, this is the szenario without the patch-maintainer. 

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
increasingly unhappy with moderation of geda-user



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

DJ Delorie wrote:

>> If you want real world testing, provide an environment with proper
>> fall back options.
> 
> The fall back option is to use a release.

It won't be an option once file format changes kick in. 

>> Debian even has four stages (experimental, unstable, testing and
>> stable).
> 
> Debian has a huge development community.

In 2005 Debian had 1200 maintainers for 8400 packages. That is,
on avarage every maintainer handles 6.3 packages. This includes 
screening of bug reports push of new versions and maintainance of
the build scripts. Seen from that perspective, the maintainer
community of debian is not that large. 

> The reality is, stuff breaks for all sorts of reasons.  If you expect
> otherwise, you're not going to be happy unless you stick with
> official releases.

Sigh. I thought I made it clear, that I don't expect guaranteed
unbroken applications when testing. After all, the whole point 
of testing is to find things that are broken. 
So please stop suggesting otherwise.

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
increasingly unhappy with moderation of geda-user

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

2011-09-05 Thread Russell Dill

>> with one checked-out version you know
>> works, or maintain your own bugfix branch.  Git head is where
>> development happens, and when we're bringing in big changes, stuff
>> breaks.
>
> This is why other projects like KiCAD provide a dedicated testing repo.
> Debian even has four stages (experimental, unstable, testing and stable).
> By the way, stuff also breaks with small changes. See the first commits
> of the new layer selector.

gEDA PCB's developer and testing community is much smaller than
Debian's. I don't know about a size comparison to KiCAD. The only way
bugs can be fixed is by someone finding that it's broken in the first
place. I fear that not only would the developer resources be there to
maintain two separate branches, but the testing resources wouldn't be
there either. Out of all the people testing on git HEAD, I think only
you managed to find the large silk bug. This model is used with quite
a bit of success in linux kernel development with the linux-next tree,
so who knows, maybe it does have a place.

I think the only way this gets solved is the suggestion that someone
made of someone tagging "semi-stable" versions. Bug fix patches could
be back-ported to those and at some point the branch could be
abandoned for a newer semi-stable version. The nice thing about this
solution is that it can easily scale based on how many people are
willing to help maintain the various semi-stable branch points and
don't depend on the core developers doing anything. Someone with a big
enough itch to scratch could put something up on github today.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: plugins


On 09/05/2011 01:21 PM, DJ Delorie wrote:

Cursor movements have their own channel, so just re-running
all the actions you see won't duplicate what actually happened.  For
example:

Action: PointCursor()
Action: Mode(Notify)
Action: PointCursor()
Action: PointCursor()
Action: PointCursor()
Action: PointCursor()
Action: PointCursor()
Action: PointCursor()
Action: Mode(Release)

Nothing here tells you where the PointCursor() point is, or that
Mode(Notify) actually started a drag, or where it dragged to.



Oh, so pcb --verbose still needs more before it would replay to recreate
some changes to a .pcb file.  Dang. I can't dig into that right now.

If/when you get that you get scriptability equal to Cadence chip layout.

John


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: plugins


> Do you mean the resulting commands from pcb --verbose would do all
> the action command steps, but not show cursor positions that caused
> them?  That would be great.  If so, I need to try it.

Right.  Cursor movements have their own channel, so just re-running
all the actions you see won't duplicate what actually happened.  For
example:

Action: PointCursor()
Action: Mode(Notify)
Action: PointCursor()
Action: PointCursor()
Action: PointCursor()
Action: PointCursor()
Action: PointCursor()
Action: PointCursor()
Action: Mode(Release)

Nothing here tells you where the PointCursor() point is, or that
Mode(Notify) actually started a drag, or where it dragged to.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"

2011-09-05 Thread Steven Michalske


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 are any builds of GTK 3.0 out there yet?
> 
Macports has 3.0.5

Fink and homebrew do not.



> -- 
> Peter Clifton
> 
> Electrical Engineering Division,
> Engineering Department,
> University of Cambridge,
> 9, JJ Thomson Avenue,
> Cambridge
> CB3 0FA
> 
> Tel: +44 (0)7729 980173 - (No signal in the lab!)
> Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)
> 
> 
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: plugins

On 09/05/2011 12:29 PM, DJ Delorie wrote:

I think it would help a lot if the scheme or c code underlying
>  functions showed in the log window in a way that can be cut and
>  pasted to execute it again, or create a script that can be run with
>  a button.

pcb --verbose does that, but there's still some OOB stuff that doesn't
pass through the action layer, like cursor position.

Do you mean the resulting commands from pcb --verbose would do all the
action command steps, but not show cursor positions that caused them?
That would be great.  If so, I need to try it.

John

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gEDA request for volunteers


On 09/05/2011 11:55 AM, DJ Delorie wrote:

See gpleda.org for information on mailing lists


changed that.

JG


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"


> 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

Re: gEDA-user: test repo


> If additional filtering is desired: One of the "core developers"

Again, we just don't have enough "core developers" to add any burden
to them.  We need options that *reduce* the load on developers, to
encourage more participation.

> This wouldn't neceessarily have to be a developer. He or she just
> has to be familiar with git and the build tools in general.

If they have commit access to the master git, they need to be a
developer.  That's kind of our definition of "developer" - you need to
know enough about what's going on, to make smart choices about which
patches to pull.

> The difficult task is to determine, when a patch has seen enough
> testing.

This is the case whether we have a testing repo or not.

> But then again -- Currently, most patches are applied directly to
> git-head with no intermediate test repo.

As I said before, that's our procedure - git head *is* our testing
repo.

> There would be a freeze period, during whitch only bug fixes but no
> new features are applied to the test-repo.

We can already do that with git head, and often do when a release is
in the near future.

> A fixed calendar would help. I'd say two months of patching followed
> by a month of freeze would be fine.

A fixed calendar won't work as we don't have dedicated developers.
Our roadmap is to decide on a minimum set of features and bugfixes we
want in the next release, and whatever else gets in during that too.
For the next PCB release, my goals are the nanometer work and a
working windows port.  We're close.  Meanwhile, P&A are working on
modernizing the GTK gui, and some other things are getting attention.

> A mini-release could be offered as a package ready to install on the
> servers. This might draw more users into the testing boat. --> More
> eyes, more bugs spotted, more quality.

I don't mind releasing PCB more often than we do, but development just
isn't that quick.  *This* release was supposed to happen last
November.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"

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 Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)


signature.asc
Description: This is a digitally signed message part


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"

2011-09-05 Thread Steven Michalske


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 - and see if anyone trips over it.  Then
> we'll know if we need to work around it.
> 
> 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

> 
> ___
> geda-user mailing list
> geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: plugins (was: How can you help...)


> I can see a core set of plugins shipping with the source, but not all.

I can see us breaking out some of the core actions into a plugins
directory, and importing some public plugins there too.  Might be a
good way to manage our "library" of actions.

> I think it would help a lot if the scheme or c code underlying
> functions showed in the log window in a way that can be cut and
> pasted to execute it again, or create a script that can be run with
> a button.

pcb --verbose does that, but there's still some OOB stuff that doesn't
pass through the action layer, like cursor position.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo


> If you want real world testing, provide an environment with proper
> fall back options.

The fall back option is to use a release.

> Debian even has four stages (experimental, unstable, testing and stable).

Debian has a huge development community.  We have a tiny one.  Any
suggestion that involves more work for the developers is just not
going to work.

> By the way, stuff also breaks with small changes. See the first
> commits of the new layer selector.

The reality is, stuff breaks for all sorts of reasons.  If you expect
otherwise, you're not going to be happy unless you stick with official
releases.

> Obviously, some quite severe issues had passed undetected.

But many of them were found and fixed.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: gEDA request for volunteers


> See gpleda.org, ask on geda-user mailing list geda-user@moria.seul.org
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

That web page gives a different email address.  Maybe it should just
say "See gpleda.org for information on mailing lists" to future-proof
it?


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

Andrew Poelstra wrote:

> On Mon, Sep 05, 2011 at 03:21:25AM +0200, Kai-Martin Knaak wrote:
>> Proposal to tone down the impact of patches breaking important features:
>> 
>>Add a branch "test" to git. This branch would work pretty much like 
>>sid/unstable repo of debian. It would receive all the new stuff so 
>>advanced users like me can give them a test run. 
>>If a patch stands the test by same time, it will be applied to git-head.
>>
> 
> My thoughts on this:
> 
> This sounds like a good idea, but depends on developer availability
> (who will move features from testing to master?)

If additional filtering is desired: One of the "core developers"
Else, whoever commited the patch in the first place. Or someone who takes 
the job as his/her task in the project. This wouldn't neceessarily 
have to be a developer. He or she just has to be familiar with git and the 
build tools in general. 
The difficult task is to determine, when a patch has seen enough testing. 
But then again -- Currently, most patches are applied directly to git-head 
with no intermediate test repo. At worst, a premature application by the 
"patch-master" would yield the same situation as we have now. 

> , and would probably end up being of limited usefulness.

A transition like debian/testing to debian/stable would remove the necessity 
to move single patches. There would be a freeze period, during whitch only
bug fixes but no new features are applied to the test-repo. Then the test 
repo is moved wholesale to git-head. This is sort of mini-release. A fixed 
calendar would help. I'd say two months of patching followed by a month of 
freeze would be fine.
And again, the actual work of moving repo versions around does not necessarily 
have to be shouldered by devs.

> My mil-to-nm changes and Peter C's rendering/cleanup changes have both
> been so intrusive that any "minor" changes applied after-the-fact, would
> simply not apply without those changes. So they would be stuck in testing
> for as long as mil-to-nm is.

This seems like no problem to me. It does not delay development in any way 
compared to the situation now.

> So you might want to just checkout your own branch with this reverted,
> and rebase any new changes against that:

Sure, you can always go back in a git repo. But this needs informed bisection
when the critical changes occured. Also, it requires the skill to work with
git and build the application locally. A mini-release could be offered as
a package ready to install on the servers. This might draw more users into 
the testing boat. --> More eyes, more bugs spotted, more quality.

---<)kaimartin(>---
-- 
Kai-Martin Knaak  tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik  fax: +49-511-762-2211 
Welfengarten 1, 30167 Hannover   http://www.iqo.uni-hannover.de
-> not happy with moderation of geda-user mailinglist

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"


> 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 we need to work around it.

Er, what gtk do the Mac builds use?


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo


> Thanks for setting up such a service, a well kept secret until now,
> and let's keep this one quite as not to waken the wild hoards of
> windoze users ;-)

Well, I wanted a few people to try it to see if it worked, but
apparently I need to ask a wider audience to get enough testers.

If anyone wants to send me a nsi file (installer template) for gerbv
or gaf, I'll add those to the mix.  I did the pcb one manually, after
using cygcheck to list the DLL dependencies.  Mostly I want to have
the pcb windows installer ready for our next pcb release; it's been a
blocker since the last one.

> 1) I can't zoom in using "Z" or "z".

Hmmm

> 2) No transparency (GL) supported.

I suspect this just might not be supported.

> 3) When loading a layout the file selector only displays the icons for the
> top 1 or 2 files/directories and the remaining entries only when hovered
> over (having focus).

/me wonders if these are all issues with the gtk port

> 4) the big font issue ... (probably solved in tomorrows snapshot)

Yup.

> Should windoze "users" file bug reports in LP for these nightly
> windows snapshots too ?

They're no different than any other git-head-build, so sure.  Just
make sure you specify that they're from my windows builds, and which
timestamp.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: plugins (was: How can you help...)


On 09/05/2011 09:33 AM, Kai-Martin Knaak wrote:

Also, they tend to bit-rot and break
when the main source moves on.


That's why they are separate.   There is not enough
coding/testing man-or-woman-power to pull all conceivable plugins along
with core changes.  Seems obvious.  The ones that are truly wanted
will get updated.  And you can develop, customize and use them without a 
recompile cycle.

I can see a core set of plugins shipping with the source, but not all.
I don't see it as a big deal though, since if a feature is really "core"
it will be in the core, so not shipping plugins is natural.  They're not core.
functions.

Documenting them however is a big deal.  We mostly need documentation
for enlisting more users.  After that, we need a good beginner user interface
that doesn't kill any GUI or command-line functions that are currently 
customizable .

I think it would help a lot if the scheme or c code underlying functions showed
in the log window in a way that can be cut and pasted to execute it again, or
create a script that can be run with a button.

IOW, for PCB, I'd like to see all the actions commands to get the same effect
as the GUI mouse and keyboard commands listed in a command log window as they 
happen
so they could be cut and pasted to redo.

Having exact command logs would help proficient users document actions easily 
and write them up
as tutorials, videos, style references.

John


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

DJ Delorie wrote:

> 
>> If this happens too often, I may have to quit using and testing the
>> cutting edge version. After all, I still have to get my projects
>> done. I guess, other users feel the same.
> 
> This has always been the case.

No reason not to change sub optimum habits. 

> If you want a stable reliable tool, use a released version, or stick

If you want real world testing, provide an environment with proper
fall back options.

> with one checked-out version you know
> works, or maintain your own bugfix branch.  Git head is where
> development happens, and when we're bringing in big changes, stuff
> breaks.

This is why other projects like KiCAD provide a dedicated testing repo. 
Debian even has four stages (experimental, unstable, testing and stable).
By the way, stuff also breaks with small changes. See the first commits 
of the new layer selector.

>>Add a branch "test" to git.
> 
> We call this "remote repositories" like Peter's GL repo. 

This is only comparable, if there is just one such remote repo and if 
this repo is handled like Peter did. That is, frequent rebase to the
main tree and in general a slow and steady progress. If any of these
prerequisites is not met, the remote repository approach won't cut it.

> I see no
> need to have something else in the main repo that needs admin time
> when we already have a working model for it.

It is not working.
See the mil-to-nm conversion. IIRC, Andrew had a test repo set up. 
Obviously, some quite severe issues had passed undetected.

---<)kaiamrtin(>---
-- 
Kai-Martin Knaak  tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik  fax: +49-511-762-2211 
Welfengarten 1, 30167 Hannover   http://www.iqo.uni-hannover.de
-> not happy with moderation of geda-user mailinglist

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"

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 change the *.pcb file in the back of PCB. 
>> > Contrary to the meaning of the word "revert" the "revert" 
>> > action does not go back but forward.
>> 
>> When the files that evince or gedit have open are changed, they pop up a
>> bar across the top of the window with a reload button in it.  Perhaps
>> this is a solution that would fit in better.
> 
> I've started implementing this[1] with a little help from the gedit
> source. 


Nice!
Hope to see it in the repo soon.

---<)kaimartin(>---
-- 
Kai-Martin Knaak  tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik  fax: +49-511-762-2211 
Welfengarten 1, 30167 Hannover   http://www.iqo.uni-hannover.de
-> not happy with moderation of geda-user mailinglist



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: pcb gtk: Toggle buttons for route styles?

Peter Clifton wrote:

> There are also different DRC rules on certain objects on inner layers
> for some fabs IIRC.

And of course, DRC constraints depend on the thickness of the copper layer. 
This was a big deal with my big project a few weeks ago. Because the top
contains fine pitch SMD components, it could not possibly comply with the 
rules for the inner layers with 105 µm copper. (Remember my failure to make
ignore-DRC work?) In the end, I worked around it by scripted reduction of 
outer layer line thickness to 1/10 width. Then DRC the inner layers and 
finally blew up the lines on outer layers to their original width.

So, yes, DRC rules should optionally depend on layers.

---<)kaimartin(>---
-- 
Kai-Martin Knaak  tel: +49-511-762-2895
Universität Hannover, Inst. für Quantenoptik  fax: +49-511-762-2211 
Welfengarten 1, 30167 Hannover   http://www.iqo.uni-hannover.de
-> not happy with moderation of geda-user mailinglist

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: Fwd: Re: [OH Updates] How can you help solve the proprietary tool problem?

Steven Michalske wrote:

> +1 to bundling plugins with pcb sources..

+1 to merging plug-ins into the main project. There is no point in keeping 
useful features outside. The necessity to compile and keep distinct plugins 
for different versions of PCB is a pain. Also, they tend to bit-rot and break
when the main source moves on.

---<)kaimartin(>---
-- 
Kai-Martin Knaak  tel: +49-511-762-2895
Universit?0?1t Hannover, Inst. f??r Quantenoptik  fax: +49-511-762-2211 
Welfengarten 1, 30167 Hannover   http://www.iqo.uni-hannover.de
-> not happy with moderation of geda-user mailinglist



___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

2011-09-05 Thread Gareth Edwards

On 5 September 2011 15:16, Peter Clifton  wrote:
>
> First person to send me a shiny Apple laptop bought themselves that
> development work ;) (Seriously).
>

I have one, but Objective-C and Cocoa are completely alien to me,
otherwise I'd be all over it.

Gareth


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

On Mon, 2011-09-05 at 15:14 +0100, Gareth Edwards wrote:

> In fact, I'd go further and say that if we also had a native OS X
> build (not macports/fink) we'd have a pretty killer proposition for
> the open hardware community.

First person to send me a shiny Apple laptop bought themselves that
development work ;) (Seriously).

Best wishes.

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)


signature.asc
Description: This is a digitally signed message part


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

2011-09-05 Thread Gareth Edwards

On 5 September 2011 14:28, Bob Paddock  wrote:
>> Thanks for setting up such a service, a well kept secret until now
>> let's keep this one quite as not to waken the wild hoards of windoze users
>> ;-)
>
>> Should windoze "users" file bug reports in LP for these nightly windows
>> snapshots too ?
>
> Bugs are bugs, they need reported.
>
> This anti-Windows attitude is not helpful to the project, and I'm not
> trying to pick on you specifically Bert. sorry if it seems that way.
>

Well said, Bob. If we /really/ want Eagle users to move to gEDA/gaf
and PCB (and I do, because I'm sick fed up of seeing "open hardware"
being developed on Eagle), the whole pipeline needs to run (and run
well i.e. as close to native as we can get within reason) on Windows
platforms.

In fact, I'd go further and say that if we also had a native OS X
build (not macports/fink) we'd have a pretty killer proposition for
the open hardware community.

Cheers
Gareth

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

gEDA-user: gEDA request for volunteers

Original Message Subject: Re: [OH Updates] Degrees of
open-ness in EDA (and CAD in general) Date: Sat, 3 Sep
2011 18:58:40 -0400 From: phillip torrone To: updates

john,

can you write up what's needed for gEDA in a couple paragraphs? i'll post it up
on MAKE. be specific and what folks who want to
help need to do and how to contact/join the gEDA community.

1. what is geda
gEDA is a schematic editor and netlister capable of working with many open and
proprietary physical layout tools
including VLSI layout, simulation.
Handles making hierarchic schematics so elements can be repeated by schematic
page instances placed once.
The netlists it makes are a flattened hierarchy
where the netlist of a subcell has its parts repeated with different names. New netlist exporters often take only a few hours of
work. A circuit board layout tool called PCB allows user interface customization just as high end tools for chips do, where

a fast, experienced user enters keyboard shortcuts with left hand while mouse
aiming with the right hand. Newbies can use all
mouse commands. Command menus and keyboard shortcuts can be customized by
editing local project directory config files
to handle project specific or left handed or personal style wants. Footprint
libraries can be local to a project directory or
from a central library. To be sure your project is a good reference for easy
reuse,
local libraries can supercede central ones and the project directory can be set
up so that compressing it and giving it to someone
else results in a local project specific environment just as the first was when
added into another users installation.

Generation of printed schematics, netists, and bills of materials can be automated by Unix-style scripting and Makefiles. These
can thus be combined with other tools that create simulation results, programs, documentation making it easy to generate
deliverables for a complete project, not just its electrical part.

2. why it matters
Because it is an effective tool, and truly open

3. what is needed and why
More volunteers to help document gschem and PCB, and code things like a
symbol/footprint cross-tool editor and translator so
the whole OSHW(open source hardware) movement picks up pace.

4. how to join in
See gpleda.org, ask on geda-user mailing list geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: test repo

2011-09-05 Thread Bob Paddock

> Thanks for setting up such a service, a well kept secret until now

Its been discussed before.

> let's keep this one quite as not to waken the wild hoards of windoze users
> ;-)

> Should windoze "users" file bug reports in LP for these nightly windows
> snapshots too ?

Bugs are bugs, they need reported.

This anti-Windows attitude is not helpful to the project, and I'm not
trying to pick on you specifically Bert. sorry if it seems that way.

In my personal view there seems to be a fear that a bunch of people
from Windows will show up asking annoying questions.
Yet I see the same questions over-and-over from new users on
non-Windows systems, and no one gets annoyed with them.

There are two groups of people involved in using EDA tools.  Hobbyist
trying to learn and have fun, and professionals that just want to get
work done.

Those in the professional category often have no choice but to use
Windows due to IT departments or uninformed management policies.
I know of at least one person that was here for a while, who is
extremely knowledgeable in Analog Design, that left because of lack of
Windows support.
He is now quit vocal about it in other groups driving potential users,
and more importantly contributors, away.

In the hobbyist group we have to be aware of the Baby-Duck-Syndrome.
When a Baby-Duck is born, it imprints the first moving thing it sees
to be its Mother.
In software the first tool a person is exposed to is the one they may
stick with for a life time.  Do we want to be a tool that a first time
user can be productive with in a few minutes, or at least hours?
No, that does not mean things get broken for current users that like
Makefiles.  First time users and long time users can be supported by
the same tool, and constant wining about something maybe getting it
broken by a change to improve usability is no more productive for the
project than wining about Windows, and has driven off contributors.
If it gets broken, it gets fixed.

Outside of our group here gEDA/PCB/Et.Al. are seen as toys and hard to
use.  Maybe we should all asks ourselves why? [Which does not mean
that my message here needs any kind of reply telling use why, we all
know if some issue or other that needs addressed, starting an other
wining sessions is not my goal with this message.]

The attitude of 'Things would be so much better if the customers would
all just go away' and stop complaining about real usability problems
is sure to cause a long slow painful death of any project.


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: David Jones - EEVBlog on Open Hardware

On Mon, 2011-09-05 at 03:37 +0200, Kai-Martin Knaak wrote:
> Peter Clifton wrote:
> 
> > gEDA and KiCAD get a mention ;)
> > 
> > http://www.eevblog.com/2011/08/12/eevblog-195-open-source-hardware-explained/
> 
> About what point in time? 

Sorry - can't recall. He mentions the opinions on open CAD tools with
Open Hardware. Perhaps around half way in?

-- 
Peter Clifton

Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA

Tel: +44 (0)7729 980173 - (No signal in the lab!)
Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me)


signature.asc
Description: This is a digitally signed message part


___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user

Re: gEDA-user: "revert" vs "reload"