Re: [Kicad-developers] eeschema modular kicad work

2014-08-20 Thread yann jautard 

just FYI, 5084 does not compile any more.

/home/yann/kicad_sources/kicad.bzr/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp: 
In member function ‘virtual void 
DIALOG_MODULE_BOARD_EDITOR::OnCancelClick(wxCommandEvent)’:
/home/yann/kicad_sources/kicad.bzr/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp:185:1: 
error: expected primary-expression before ‘’ token

  TREE
 ^
/home/yann/kicad_sources/kicad.bzr/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp:185:3: 
error: expected primary-expression before ‘’ token

  TREE
   ^

and at least 50 more lines similar to this one.

looking at the problematic file, found some pretty strange syntax wich I 
guess it is not c++ :


void DIALOG_MODULE_BOARD_EDITOR::OnCancelClick( wxCommandEvent event )
{
 TREE
EndQuasiModal( -1 );
===
ENDQUASIMODAL( -1 );
 MERGE-SOURCE
}



looks like some patching as not finished properly or something similar.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-20 Thread Tomasz Wlostowski 

On 20.08.2014 14:44, yann jautard wrote:

just FYI, 5084 does not compile any more.
void DIALOG_MODULE_BOARD_EDITOR::OnCancelClick( wxCommandEvent event )
{
 TREE
 EndQuasiModal( -1 );
===
 ENDQUASIMODAL( -1 );
  MERGE-SOURCE
}


Hi guys,

Sorry for asking dumb questions, but what is this whole QuasiModal stuff 
for?


Tom

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-20 Thread Brian Sidebotham 
On 20 August 2014 13:44, yann jautard brico...@free.fr wrote:
 just FYI, 5084 does not compile any more.

 /home/yann/kicad_sources/kicad.bzr/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp:
 In member function ‘virtual void
 DIALOG_MODULE_BOARD_EDITOR::OnCancelClick(wxCommandEvent)’:
 /home/yann/kicad_sources/kicad.bzr/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp:185:1:
 error: expected primary-expression before ‘’ token
   TREE
  ^
 /home/yann/kicad_sources/kicad.bzr/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp:185:3:
 error: expected primary-expression before ‘’ token
   TREE
^

 and at least 50 more lines similar to this one.

 looking at the problematic file, found some pretty strange syntax wich I
 guess it is not c++ :

 void DIALOG_MODULE_BOARD_EDITOR::OnCancelClick( wxCommandEvent event )
 {
  TREE
 EndQuasiModal( -1 );
 ===
 ENDQUASIMODAL( -1 );
 MERGE-SOURCE
 }



 looks like some patching as not finished properly or something similar.

Hi Yann,

There's nothing wrong with the source, see:
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp

You have a locally unresolved conflict because you've had some local
changes that BZR cannot resolve without your help. See
http://doc.bazaar.canonical.com/beta/en/user-guide/resolving_conflicts.html

You can check the status to see the unresolved conflicts by using the
bzr status command.

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-20 Thread Brian Sidebotham 
 Hi guys,

 Sorry for asking dumb questions, but what is this whole QuasiModal stuff
 for?

 Tom

Hi Tom,

No question is dumb.

See Yann's description (from earlier in this thread) of the problem
below, to which Quaimodal is a good solution.

Best Regards,

Brian.

---


Hi Dick, and all the others involved in the modular design.

I noticed something regarding the modular kicad apps :

When you have some modal window opened in one of the app, eg the
module properties window in pcbnew, all the kicad modules are frozen
until you close that window.

It's not a big deal, but rather boring, when you need to check
something in eeschema when editing module properties, you can't launch
eeschema with the button in the kicad main window as it is not
responding. And if eeschema was alredy opened you can't even scroll
the schematic.

I don't know if it is technically possible to change this behaviour,
but I think it could be a great improvement.

Just my two cents.

regards,

yann

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-20 Thread Dick Hollenbeck 
On 08/20/2014 08:14 AM, Brian Sidebotham wrote:
 Hi guys,

 Sorry for asking dumb questions, but what is this whole QuasiModal stuff
 for?

 Tom
 
 Hi Tom,
 
 No question is dumb.
 
 See Yann's description (from earlier in this thread) of the problem
 below, to which Quaimodal is a good solution.
 
 Best Regards,
 
 Brian.


Additional information is found by grepping for

Quasi-Modal Mode Explained:

in the source.

Its genesis was the unsightly wxSemaphore noise sprinkled about.

You could also grep the bzr log for quasi modal, back up one or two versions 
from its
first mention, then check out that version and look for wxSemaphore.

It currently serves two distinct purposes.




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-20 Thread yann jautard 


Le 20/08/2014 15:12, Brian Sidebotham a écrit :


Hi Yann,

There's nothing wrong with the source, see:
http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/view/head:/pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp

You have a locally unresolved conflict because you've had some local
changes that BZR cannot resolve without your help. See
http://doc.bazaar.canonical.com/beta/en/user-guide/resolving_conflicts.html

You can check the status to see the unresolved conflicts by using the
bzr status command.

Best Regards,

Brian.


Woops. Sorry for the noise. I forgot I had previously applied Dick's 
patch, and that is the source of my problem. Not enough familiar with bzr...


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-18 Thread Nick Østergaard 
Hello Dick

I see a bug in your commit 5072 (also present in latest commit 5079).
In that commit; when opening a schematic, then all connections are
showed as not connected (with the square green box around the end
nodes). When drawing a new wire they all look connected again. See the
attached image for how it look.

Not knowing the internals of this, it seems that a calculation of this
is not made when opening the sheet.

Regards
Nick Østergaard

2014-08-04 18:05 GMT+02:00 Dick Hollenbeck d...@softplc.com:
 On 07/29/2014 02:02 PM, Wayne Stambaugh wrote:
 On 7/27/2014 1:33 PM, Dick Hollenbeck wrote:
 Gentlemen:

 In the course of trying to load the schematic editor directly under 
 kicad.exe, by-passing
 eeschema top frame itself, I was exposed to a range of issues in the design 
 of eeschema.

 Firstly, I discovered the most excellent work by Wayne Stambaugh regarding 
 the schematic
 library containers.

 Thanks Dick.  I wasn't really expecting any credit.  I was just one of
 those things that needed fixed so I fixed it.  I knew that that only way
 to move Eeschema forward was to fix the underlying library containers.
 I wish I had the time to finish the SCHEMATIC object and come up with a
 better way to handle sheet hierarchies.  With those two pieces of the
 puzzle in place, we could start moving towards the new file format and
 other enhancement that we have discussed over the years.


 There are a long chain of dependencies here.  LIB_EDIT_FRAME, to come up 
 first, needs the
 libraries.  That is obvious in words.  But SCH_EDIT_FRAME typically loads 
 the libraries
 before popping up LIB_EDIT_FRAME.  You have a similar discussion about 
 LIB_VIEW_FRAME.

 (I believe I solved all these similar problems for PCBNEW.)  So now I went 
 to solve them
 for EESCHEMA and produced an 11,000 line patch in 2.5 days.  Remember that 
 about only
 1/7th of a patch line count are actual changed lines.

 The eeschema libraries were global, even if hidden behind a static class 
 function, they
 were global.  This would not dovetail into the notion of multiple open 
 projects, each
 having its own set of libraries.  So in the course of moving libraries into 
 a project
 specific container, lots of changes were needed.  First among those was to 
 park the
 libraries container in the PROJECT.  It was a necessary but insufficient 
 solution for
 multiple open projects.  One remaining issue is the fact that with multiple 
 open projects
 you'd still have the same library open twice.  Its hard to have the same 
 problem in
 PCBNEW, (would have to duplicate project specific libraries) and even if 
 you did, most of
 the plugins react to a change on disk and will re-cache if one of the 
 copies is edited.

 We now have the libraries container in the PROJECT at least, and it is 
 loaded on demand,
 by any _eeschema.kiface KIWAY_PLAYER that needs it.

 For 5 years or more no one questioned the terminology I introduced in the 
 SWEET
 distributed library design regarding the definition of  PART and a 
 COMPONENT.  The time to
 object was 5 years ago.  So I went with those original terms per that prior 
 design.
 LIB_COMPONENT is now LIB_PART.  SCH_COMPONENT remains.

 Works for me.  I've always thought that LIB_COMPONENT and SCH_COMPONENT
 naming was confusing.


 SCH_COMPONENT uses a link to a LIB_PART.  That link was previously done by 
 a library
 search on every Draw() call.  This was easy since the library container was 
 global, and
 the SCH_COMPONENT had access to the global container.  Not so now.

 I seem to remember some other global variables used by the Draw()
 functions.  The color table and possibly some visibility settings come
 to mind.  I don't know if these have any context per project but it may
 be one of those things you want to look out for just in case.


 This also introduced an avoidable performance hit, which is avoided if a 
 link to the
 LIB_PART is retained across SCH_COMPONENT redraws.

 You can pretty much now tell where this took me.  Squarely into 
 boost::shared_ptr and it
 companion class boost::weak_ptr.

 I will get it working in another half day and push it to its own branch, 
 and would like
 folks to use EESCHEMA for a couple of days in that branch.

 My son and I are doing a very complex board
 together.

 And you can load the part editor and footprint editors directly from 
 kicad.exe, for a
 single project now.

 Awesome work Dick!  I'll try to do some testing as soon as I see the
 branch on launchpad.

 Wayne


 I pushed an early branch of this work to milestoneB.

 See the commit log for some of the details.

 The shared_ptr turned out to be a can of worms.  No, several cans of worms, 
 all stacked
 like a 2 miles of dominos.

 So I used a single one per LIB_PART according to this link here, and saved us 
 all a lot of
 gray hairs.  This is a very elegant solution which cherry picks not one IOTA 
 more than
 what we needed:

Re: [Kicad-developers] eeschema modular kicad work

2014-08-18 Thread yann jautard 


Le 18/08/2014 01:04, Dick Hollenbeck a écrit :

Patch solved the issue, seemed to work like a charm... But induced another 
issue. Step to
reproduce :

1 - open kicad, then open eeschema and pcbnew
2 - in pcbnew, open the module properties dialog on any part you want.
3 - go back to eeschema, wich is now responding normally, and open  the 
component
properties dialog, on the same part or another one (doesn't matters).
4 - go back to pcbnew, close the dialog, either with OK or Cancel -- dialog 
closes, but
pcbnew is frozen and also can't be closed in any normal way.
eeschema still works, you can close the dialog and use it normally. Kicad main 
window
works also.
Eeschema can be closed normally, kicad main window also, but when closing main 
window,
pcbnew window closes too, but the kicad process is still there and you need to 
kill it.

I thought I will modify eeschema in the same way to test if it does something 
else, and so
I noticed the eeschema component properties dialog was alredy a QuasiModal one.

And obviously the same test starting with eeschema instead of pcbnew leads to 
to opposite
result : eeschema stuck, pcbnew working.
And again, the need to kill kicad process after closing the main window.


Excellent job testing, yann.

This will take some time to look into and I started last night.

Achieving platform independent and wx version independent results looks very 
difficult at
this point.



Yann,

This is now fixed to the best degree I know how in 5089.  But you need to use 
wx3.x for it
to work.

It it not perfect, but quasimodal is a graft on top of the wx API, and without 
going to
the platform API for further experimentation, we're limited.  Still way ahead 
of where we
started I would say.

It's good enough for me, anyways.

Dick



Good news !

thanks Dick !

but where is that 5089 version ? I just ran the install script and it 
updated to 5081. May be it was 5079 ?




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-18 Thread Dick Hollenbeck 

 Good news !
 
 thanks Dick !
 
 but where is that 5089 version ? I just ran the install script and it 
 updated to 5081. May be it was 5079 ?

Yes.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-18 Thread Dick Hollenbeck 
On 08/18/2014 05:37 AM, Nick Østergaard wrote:
 Hello Dick
 
 I see a bug in your commit 5072 (also present in latest commit 5079).
 In that commit; when opening a schematic, then all connections are
 showed as not connected (with the square green box around the end
 nodes). When drawing a new wire they all look connected again. See the
 attached image for how it look.
 
 Not knowing the internals of this, it seems that a calculation of this
 is not made when opening the sheet.
 
 Regards
 Nick Østergaard


Jean-Pierre graciously agreed to look into this.  I'm only fixing bugs that 
bother me
personally a lot this week.  I need to get other work done.


Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-18 Thread Nick Østergaard 
2014-08-18 19:39 GMT+02:00 Dick Hollenbeck d...@softplc.com:
 On 08/18/2014 05:37 AM, Nick Østergaard wrote:
 Hello Dick

 I see a bug in your commit 5072 (also present in latest commit 5079).
 In that commit; when opening a schematic, then all connections are
 showed as not connected (with the square green box around the end
 nodes). When drawing a new wire they all look connected again. See the
 attached image for how it look.

 Not knowing the internals of this, it seems that a calculation of this
 is not made when opening the sheet.

 Regards
 Nick Østergaard


 Jean-Pierre graciously agreed to look into this.  I'm only fixing bugs that 
 bother me
 personally a lot this week.  I need to get other work done.


 Dick

Hello, I can confirm that it works now with the commit 5081 by
Jean-Pierre. Thank you.

Nick

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-18 Thread Brian Sidebotham 
On 4 August 2014 17:05, Dick Hollenbeck d...@softplc.com wrote:

 I pushed an early branch of this work to milestoneB.

 See the commit log for some of the details.

 The shared_ptr turned out to be a can of worms.  No, several cans of worms, 
 all stacked
 like a 2 miles of dominos.

 So I used a single one per LIB_PART according to this link here, and saved us 
 all a lot of
 gray hairs.  This is a very elegant solution which cherry picks not one IOTA 
 more than
 what we needed:

 http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/sp_techniques.html#weak_without_shared


 I pushed this to branch milestoneB and would appreciate some testing help.

 There are some TODO items in my section of TODO.txt for this block of work.  
 Most notable
 is moving the Color loading into the eeschema KIFACE::OnKifaceStart().

 Also, the libraries are loaded more often than they should be, I think 
 SCH_EDIT_FRAME
 needs to quit deliberately loading them and simply use the data on demand 
 technique.  You
 can see schematic editor loading libraries even if you load the lib editor 
 first.  This is
 trivial to fix.

 I will fix those TODO items along with any bug reports and get 'em done soon.

 I also saw a segfault somewhere as I was leaving the room.  Need to track 
 perhaps a couple
 of these down.

 All in all, kicad is more modular, and there's lot to like here I think.

 Dick

Hi Dick,

Thanks so much for your conitnuing work - it doesn't go unnoticed -
I'm sorry I've not had to time to say thanks more often. In this
commit you fixed something that was on my list - creating a project
from a template was broken in KiCad-Winbuilder. You happened to fix
this in your commit, so I got to cross if off my list! Perfect, well
done with all this work and seeing things like running the module
editor and library editor from KiCad directly is a great example of
what you've been heading towards - I had failed to see what real
advantage we were going to end up with.

Thanks again, take it easy!

Best Regards,

Brian.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-17 Thread Dick Hollenbeck 

 Patch solved the issue, seemed to work like a charm... But induced another 
 issue. Step to
 reproduce :

 1 - open kicad, then open eeschema and pcbnew
 2 - in pcbnew, open the module properties dialog on any part you want.
 3 - go back to eeschema, wich is now responding normally, and open  the 
 component
 properties dialog, on the same part or another one (doesn't matters).
 4 - go back to pcbnew, close the dialog, either with OK or Cancel -- dialog 
 closes, but
 pcbnew is frozen and also can't be closed in any normal way.
 eeschema still works, you can close the dialog and use it normally. Kicad 
 main window
 works also.
 Eeschema can be closed normally, kicad main window also, but when closing 
 main window,
 pcbnew window closes too, but the kicad process is still there and you need 
 to kill it.

 I thought I will modify eeschema in the same way to test if it does 
 something else, and so
 I noticed the eeschema component properties dialog was alredy a QuasiModal 
 one.

 And obviously the same test starting with eeschema instead of pcbnew leads 
 to to opposite
 result : eeschema stuck, pcbnew working.
 And again, the need to kill kicad process after closing the main window.
 
 
 Excellent job testing, yann.
 
 This will take some time to look into and I started last night.
 
 Achieving platform independent and wx version independent results looks very 
 difficult at
 this point.
 


Yann,

This is now fixed to the best degree I know how in 5089.  But you need to use 
wx3.x for it
to work.

It it not perfect, but quasimodal is a graft on top of the wx API, and without 
going to
the platform API for further experimentation, we're limited.  Still way ahead 
of where we
started I would say.

It's good enough for me, anyways.

Dick


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-17 Thread Jean-Paul Louis 
Dick,
Did you mean BZR5079? I cannot find 5089.

Jean-Paul
AC9GH


On Aug 17, 2014, at 7:04 PM, Dick Hollenbeck d...@softplc.com wrote:

 
 Patch solved the issue, seemed to work like a charm... But induced another 
 issue. Step to


 
 Achieving platform independent and wx version independent results looks very 
 difficult at
 this point.
 
 
 
 Yann,
 
 This is now fixed to the best degree I know how in 5089.  But you need to use 
 wx3.x for it
 to work.
 
 It it not perfect, but quasimodal is a graft on top of the wx API, and 
 without going to
 the platform API for further experimentation, we're limited. Still way ahead 
 of where we
 started I would say.
 
 It's good enough for me, anyways.
 
 Dick
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-16 Thread Барановский Константин 


Dick Hollenbeck:

I don't see this bug when I use:  A) new code from last night + B) wx3.x.  I 
see bug with
wx2.8.


I'm built kicad with wx3 (from ubuntu's repository) and this bug is gone.

Dick Hollenbeck:

I don't know for sure whether using wx3.x alone will fix this, but you could 
try.  If not
rest assured a fix is in hand, but one that depends on wx3.x.

So problem in wx2.8 compatibility.

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-15 Thread yann jautard 


Le 15/08/2014 02:31, yann jautard a écrit :




I updated my source tree to latest bzr to test with that revision, but 
I did a mistake and I need to recompile the whole stuff. As I have 
only my netbook now, it will take one hour or more, so I will test 
that tomorow



Exact same thing with bzr5074.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-15 Thread Dick Hollenbeck 
On 08/14/2014 07:31 PM, yann jautard wrote:
 
 Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
 I don't know if it is technically possible to change this behaviour, but 
 I think it could be a great improvement.

 :
 yann

 Hopefully QuasiModal is not a monster.

 For significant dialogs (ones which tend to be open for a while) using the 
 QuasiModal
 support in DIALOG_SHIM might be a solution to this.  It disables the window 
 which invokes
 the dialog, but nothing more.

 Without the QuasiModal support, the behaviour is platform specific.  On 
 linux, I *CAN*
 open the schematic editor while viewing footprint properties and scroll, but 
 I cannot
 close the schematic window.  So that behaviour is arguably worse, since it 
 looks like a
 bug.  (It is not a bug that I would respond to.  Let's register it as 
 folklore.)
 
 Hi Dick,
 
 This sounds pretty strange : I'm on linux too, and I can't. Kicad main window 
 frozen when
 dialog opened in pcbnew.
 

 Remember if you cannot close a major KIWAY_PLAYER using system window 
 decorations, this
 might be because you have a dialog window opened elsewhere on linux.

 Please see if this patch fixes the sample issue for you.  The QuasiModal 
 support was
 something I came up with using only the wxWindows API, not a platform 
 specific approach.
 I don't know that its been tested enough across all platforms.  Bad news is 
 that there may
 not be anything I can do except for Linux to fix it, should it not work 
 wonderfully on all
 platforms.
 
 
 
 Patch solved the issue, seemed to work like a charm... But induced another 
 issue. Step to
 reproduce :
 
 1 - open kicad, then open eeschema and pcbnew
 2 - in pcbnew, open the module properties dialog on any part you want.
 3 - go back to eeschema, wich is now responding normally, and open  the 
 component
 properties dialog, on the same part or another one (doesn't matters).
 4 - go back to pcbnew, close the dialog, either with OK or Cancel -- dialog 
 closes, but
 pcbnew is frozen and also can't be closed in any normal way.
 eeschema still works, you can close the dialog and use it normally. Kicad 
 main window
 works also.
 Eeschema can be closed normally, kicad main window also, but when closing 
 main window,
 pcbnew window closes too, but the kicad process is still there and you need 
 to kill it.
 
 I thought I will modify eeschema in the same way to test if it does something 
 else, and so
 I noticed the eeschema component properties dialog was alredy a QuasiModal 
 one.
 
 And obviously the same test starting with eeschema instead of pcbnew leads to 
 to opposite
 result : eeschema stuck, pcbnew working.
 And again, the need to kill kicad process after closing the main window.


Excellent job testing, yann.

This will take some time to look into and I started last night.

Achieving platform independent and wx version independent results looks very 
difficult at
this point.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-15 Thread Wayne Stambaugh 
On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
 On 08/14/2014 07:31 PM, yann jautard wrote:

 Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
 I don't know if it is technically possible to change this behaviour, but 
 I think it could be a great improvement.

 :
 yann

 Hopefully QuasiModal is not a monster.

 For significant dialogs (ones which tend to be open for a while) using the 
 QuasiModal
 support in DIALOG_SHIM might be a solution to this.  It disables the window 
 which invokes
 the dialog, but nothing more.

 Without the QuasiModal support, the behaviour is platform specific.  On 
 linux, I *CAN*
 open the schematic editor while viewing footprint properties and scroll, 
 but I cannot
 close the schematic window.  So that behaviour is arguably worse, since it 
 looks like a
 bug.  (It is not a bug that I would respond to.  Let's register it as 
 folklore.)

 Hi Dick,

 This sounds pretty strange : I'm on linux too, and I can't. Kicad main 
 window frozen when
 dialog opened in pcbnew.


 Remember if you cannot close a major KIWAY_PLAYER using system window 
 decorations, this
 might be because you have a dialog window opened elsewhere on linux.

 Please see if this patch fixes the sample issue for you.  The QuasiModal 
 support was
 something I came up with using only the wxWindows API, not a platform 
 specific approach.
 I don't know that its been tested enough across all platforms.  Bad news is 
 that there may
 not be anything I can do except for Linux to fix it, should it not work 
 wonderfully on all
 platforms.



 Patch solved the issue, seemed to work like a charm... But induced another 
 issue. Step to
 reproduce :

 1 - open kicad, then open eeschema and pcbnew
 2 - in pcbnew, open the module properties dialog on any part you want.
 3 - go back to eeschema, wich is now responding normally, and open  the 
 component
 properties dialog, on the same part or another one (doesn't matters).
 4 - go back to pcbnew, close the dialog, either with OK or Cancel -- dialog 
 closes, but
 pcbnew is frozen and also can't be closed in any normal way.
 eeschema still works, you can close the dialog and use it normally. Kicad 
 main window
 works also.
 Eeschema can be closed normally, kicad main window also, but when closing 
 main window,
 pcbnew window closes too, but the kicad process is still there and you need 
 to kill it.

 I thought I will modify eeschema in the same way to test if it does 
 something else, and so
 I noticed the eeschema component properties dialog was alredy a QuasiModal 
 one.

 And obviously the same test starting with eeschema instead of pcbnew leads 
 to to opposite
 result : eeschema stuck, pcbnew working.
 And again, the need to kill kicad process after closing the main window.
 
 
 Excellent job testing, yann.
 
 This will take some time to look into and I started last night.
 
 Achieving platform independent and wx version independent results looks very 
 difficult at
 this point.

There may be no way to completely fix this without coming up with a
really clever way of processing events between the dialog and the frame
that launched the dialog.  Modal dialogs in wxWidgets by design steal
the event queue from the current process.  Now that all of the top level
frames run in the same process, every open frame will be blocked any
time a modal dialog is run.  If you have Pcbnew and Eeschema open at the
same time, a modal dialog opened in Eeschema will prevent the Pcbnew
frame from receiving events and vice versa until the dialog is closed.
Modeless dialogs would be one possible solution except for one glaring
problem.  AFAIK every dialog (except the Eeshchema find dialog) in KiCad
directly handles the affirmative button event (typically ID_OK) and
calls EndModal() directly without checking to see if the dialog is
modal.  This design is flawed.  I hate to sound like a broken record but
wxValidators should have be used to transfer data between the control
and the data structure (decoupling) instead of directly handling this in
a button event.  This way dialogs could be either modal or modeless
without any changes.  Fixing this now would be a massive undertaking.
I'm not sure there will be a good solution to resolve this issue.



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-15 Thread Барановский Константин 

I'm catched the bug where the window of the eeschema freezes.

To reproduce do the next:
1) start kicad and opens some project (with existing schematic);
2) from kicad's panel start eeschema;
3) for some component in context menu (right click) select Edit 
component - Edit;

After this step opens dialog window for edititg the component's props.
4) close dialog by close button (x-like button on top of the window);
5) dialog closes and eeschema frizz.
But if close dialog by Cancel button at the button - all works.

Application: kicad
Version: (2014-08-14 BZR 5074)-product Release build
wxWidgets: Version 2.8.12 (release,Unicode,compiler with C++ ABI 
1002,GCC 4.8.2,wx containers,compatible with 2.6)

Platform: Linux 3.13.0-33-generic i686, 32 bit, Little endian, wxGTK
Boost version: 1.54.0
 USE_WX_GRAPHICS_CONTEXT=OFF
 USE_WX_OVERLAY=OFF
 KICAD_SCRIPTING=ON
 KICAD_SCRIPTING_MODULES=ON
 KICAD_SCRIPTING_WXPYTHON=ON
 USE_FP_LIB_TABLE=HARD_CODED_ON
 BUILD_GITHUB_PLUGIN=ON


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-15 Thread Wayne Stambaugh 
On 8/15/2014 3:00 PM, Dick Hollenbeck wrote:
 On 08/15/2014 10:00 AM, Wayne Stambaugh wrote:
 On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
 On 08/14/2014 07:31 PM, yann jautard wrote:

 Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
 I don't know if it is technically possible to change this behaviour, but 
 I think it could be a great improvement.

 :
 yann

 Hopefully QuasiModal is not a monster.

 For significant dialogs (ones which tend to be open for a while) using 
 the QuasiModal
 support in DIALOG_SHIM might be a solution to this.  It disables the 
 window which invokes
 the dialog, but nothing more.

 Without the QuasiModal support, the behaviour is platform specific.  On 
 linux, I *CAN*
 open the schematic editor while viewing footprint properties and scroll, 
 but I cannot
 close the schematic window.  So that behaviour is arguably worse, since 
 it looks like a
 bug.  (It is not a bug that I would respond to.  Let's register it as 
 folklore.)

 Hi Dick,

 This sounds pretty strange : I'm on linux too, and I can't. Kicad main 
 window frozen when
 dialog opened in pcbnew.


 Remember if you cannot close a major KIWAY_PLAYER using system window 
 decorations, this
 might be because you have a dialog window opened elsewhere on linux.

 Please see if this patch fixes the sample issue for you.  The QuasiModal 
 support was
 something I came up with using only the wxWindows API, not a platform 
 specific approach.
 I don't know that its been tested enough across all platforms.  Bad news 
 is that there may
 not be anything I can do except for Linux to fix it, should it not work 
 wonderfully on all
 platforms.



 Patch solved the issue, seemed to work like a charm... But induced another 
 issue. Step to
 reproduce :

 1 - open kicad, then open eeschema and pcbnew
 2 - in pcbnew, open the module properties dialog on any part you want.
 3 - go back to eeschema, wich is now responding normally, and open  the 
 component
 properties dialog, on the same part or another one (doesn't matters).
 4 - go back to pcbnew, close the dialog, either with OK or Cancel -- 
 dialog closes, but
 pcbnew is frozen and also can't be closed in any normal way.
 eeschema still works, you can close the dialog and use it normally. Kicad 
 main window
 works also.
 Eeschema can be closed normally, kicad main window also, but when closing 
 main window,
 pcbnew window closes too, but the kicad process is still there and you 
 need to kill it.

 I thought I will modify eeschema in the same way to test if it does 
 something else, and so
 I noticed the eeschema component properties dialog was alredy a QuasiModal 
 one.

 And obviously the same test starting with eeschema instead of pcbnew leads 
 to to opposite
 result : eeschema stuck, pcbnew working.
 And again, the need to kill kicad process after closing the main window.


 Excellent job testing, yann.

 This will take some time to look into and I started last night.

 Achieving platform independent and wx version independent results looks 
 very difficult at
 this point.

 There may be no way to completely fix this without coming up with a
 really clever way of processing events between the dialog and the frame
 that launched the dialog.  Modal dialogs in wxWidgets by design steal
 the event queue from the current process.  Now that all of the top level
 frames run in the same process, every open frame will be blocked any
 time a modal dialog is run.  If you have Pcbnew and Eeschema open at the
 same time, a modal dialog opened in Eeschema will prevent the Pcbnew
 frame from receiving events and vice versa until the dialog is closed.
 Modeless dialogs would be one possible solution except for one glaring
 problem.  AFAIK every dialog (except the Eeshchema find dialog) in KiCad
 directly handles the affirmative button event (typically ID_OK) and
 calls EndModal() directly without checking to see if the dialog is
 modal.  This design is flawed.  I hate to sound like a broken record but
 wxValidators should have be used to transfer data between the control
 and the data structure (decoupling) instead of directly handling this in
 a button event.  This way dialogs could be either modal or modeless
 without any changes.  Fixing this now would be a massive undertaking.
 I'm not sure there will be a good solution to resolve this issue.

 
 
 Actions speak louder than words.  And since your post does not even mention 
 quasimodal, it
 will not get a verbal one from me other than this.
 
 I believe, as in faith or professional judgement, that the quasimodal support 
 can be made
 to work on any platform and wx version.  However doing all platforms and wx 
 versions is
 much work.  Still probably less work than any other path.

If it can be made to work well on all platforms than I am all for it.

 
 However, with the advent of wx3.0 in the Ubuntu package repo, I will focus on 
 getting
 quasimodal to work well on wx3.x for linux, and hope that also does the job 
 on other

Re: [Kicad-developers] eeschema modular kicad work

2014-08-15 Thread Dick Hollenbeck 
On 08/15/2014 10:26 AM, Барановский Константин wrote:
 I'm catched the bug where the window of the eeschema freezes.
 
 To reproduce do the next:
 1) start kicad and opens some project (with existing schematic);
 2) from kicad's panel start eeschema;
 3) for some component in context menu (right click) select Edit 
 component - Edit;
 After this step opens dialog window for edititg the component's props.
 4) close dialog by close button (x-like button on top of the window);
 5) dialog closes and eeschema frizz.
 But if close dialog by Cancel button at the button - all works.
 
 Application: kicad
 Version: (2014-08-14 BZR 5074)-product Release build
 wxWidgets: Version 2.8.12 (release,Unicode,compiler with C++ ABI 
 1002,GCC 4.8.2,wx containers,compatible with 2.6)
 Platform: Linux 3.13.0-33-generic i686, 32 bit, Little endian, wxGTK
 Boost version: 1.54.0
   USE_WX_GRAPHICS_CONTEXT=OFF
   USE_WX_OVERLAY=OFF
   KICAD_SCRIPTING=ON
   KICAD_SCRIPTING_MODULES=ON
   KICAD_SCRIPTING_WXPYTHON=ON
   USE_FP_LIB_TABLE=HARD_CODED_ON
   BUILD_GITHUB_PLUGIN=ON
 



I don't see this bug when I use:  A) new code from last night + B) wx3.x.  I 
see bug with
wx2.8.


I don't know for sure whether using wx3.x alone will fix this, but you could 
try.  If not
rest assured a fix is in hand, but one that depends on wx3.x.

The wx2.8 solution will be to switch back to modal for this particular dialog 
as part of a
macro that can be re-purposed.  Using the modal form of the macro on this 
dialog will also
fix the problem under wx2.8.


In your shoes, I'd start by installing wx3.x.  By either building it yourself, 
or finding
a package.  Here is how I build it:


$ ../configure --with-gtk --prefix=/opt/wx3.x-stl-release --with-expat 
--enable-html
--enable-stl --with-regex=builtin

and for a debug build:




From an out of tree build dir.

$ make -j4

$ make install

$ ldconfig


And for a debug build, run it a second time in a new out of tree build dir:

 $ ../configure --with-gtk --prefix=/opt/wx3.x-stl --enable-debug 
--enable-debug_info
--enable-debug_gdb --with-expat --enable-html --enable-stl --with-regex=builtin

$ make -j4

$ make install

$ ldconfig


It takes less than 10 minutes.

Dick



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-15 Thread Dick Hollenbeck 
On 08/15/2014 02:16 PM, Wayne Stambaugh wrote:
 On 8/15/2014 3:00 PM, Dick Hollenbeck wrote:
 On 08/15/2014 10:00 AM, Wayne Stambaugh wrote:
 On 8/15/2014 8:47 AM, Dick Hollenbeck wrote:
 On 08/14/2014 07:31 PM, yann jautard wrote:

 Le 14/08/2014 16:21, Dick Hollenbeck a écrit :
 I don't know if it is technically possible to change this behaviour, 
 but 
 I think it could be a great improvement.

 :
 yann

 Hopefully QuasiModal is not a monster.

 For significant dialogs (ones which tend to be open for a while) using 
 the QuasiModal
 support in DIALOG_SHIM might be a solution to this.  It disables the 
 window which invokes
 the dialog, but nothing more.

 Without the QuasiModal support, the behaviour is platform specific.  On 
 linux, I *CAN*
 open the schematic editor while viewing footprint properties and scroll, 
 but I cannot
 close the schematic window.  So that behaviour is arguably worse, since 
 it looks like a
 bug.  (It is not a bug that I would respond to.  Let's register it as 
 folklore.)

 Hi Dick,

 This sounds pretty strange : I'm on linux too, and I can't. Kicad main 
 window frozen when
 dialog opened in pcbnew.


 Remember if you cannot close a major KIWAY_PLAYER using system window 
 decorations, this
 might be because you have a dialog window opened elsewhere on linux.

 Please see if this patch fixes the sample issue for you.  The QuasiModal 
 support was
 something I came up with using only the wxWindows API, not a platform 
 specific approach.
 I don't know that its been tested enough across all platforms.  Bad news 
 is that there may
 not be anything I can do except for Linux to fix it, should it not work 
 wonderfully on all
 platforms.



 Patch solved the issue, seemed to work like a charm... But induced 
 another issue. Step to
 reproduce :

 1 - open kicad, then open eeschema and pcbnew
 2 - in pcbnew, open the module properties dialog on any part you want.
 3 - go back to eeschema, wich is now responding normally, and open  the 
 component
 properties dialog, on the same part or another one (doesn't matters).
 4 - go back to pcbnew, close the dialog, either with OK or Cancel -- 
 dialog closes, but
 pcbnew is frozen and also can't be closed in any normal way.
 eeschema still works, you can close the dialog and use it normally. Kicad 
 main window
 works also.
 Eeschema can be closed normally, kicad main window also, but when closing 
 main window,
 pcbnew window closes too, but the kicad process is still there and you 
 need to kill it.

 I thought I will modify eeschema in the same way to test if it does 
 something else, and so
 I noticed the eeschema component properties dialog was alredy a 
 QuasiModal one.

 And obviously the same test starting with eeschema instead of pcbnew 
 leads to to opposite
 result : eeschema stuck, pcbnew working.
 And again, the need to kill kicad process after closing the main window.


 Excellent job testing, yann.

 This will take some time to look into and I started last night.

 Achieving platform independent and wx version independent results looks 
 very difficult at
 this point.

 There may be no way to completely fix this without coming up with a
 really clever way of processing events between the dialog and the frame
 that launched the dialog.  Modal dialogs in wxWidgets by design steal
 the event queue from the current process.  Now that all of the top level
 frames run in the same process, every open frame will be blocked any
 time a modal dialog is run.  If you have Pcbnew and Eeschema open at the
 same time, a modal dialog opened in Eeschema will prevent the Pcbnew
 frame from receiving events and vice versa until the dialog is closed.
 Modeless dialogs would be one possible solution except for one glaring
 problem.  AFAIK every dialog (except the Eeshchema find dialog) in KiCad
 directly handles the affirmative button event (typically ID_OK) and
 calls EndModal() directly without checking to see if the dialog is
 modal.  This design is flawed.  I hate to sound like a broken record but
 wxValidators should have be used to transfer data between the control
 and the data structure (decoupling) instead of directly handling this in
 a button event.  This way dialogs could be either modal or modeless
 without any changes.  Fixing this now would be a massive undertaking.
 I'm not sure there will be a good solution to resolve this issue.



 Actions speak louder than words.  And since your post does not even mention 
 quasimodal, it
 will not get a verbal one from me other than this.

 I believe, as in faith or professional judgement, that the quasimodal 
 support can be made
 to work on any platform and wx version.  However doing all platforms and wx 
 versions is
 much work.  Still probably less work than any other path.
 
 If it can be made to work well on all platforms than I am all for it.


It gives you 3 tools in the toolbox, not just 2.  Nobody wants all modeless 
dialogs.
Nobody wants all modal dialogs.  Nobody wants all

Re: [Kicad-developers] eeschema modular kicad work

2014-08-15 Thread Dick Hollenbeck 
On 08/15/2014 02:05 PM, Andrew Zonenberg wrote:
 As a user of wx 2.8 on Debian I would like to ensure that, as a minimum,
 kicad continues to build on it until the next stable Debian version
 (presumably shipping wx 3.0) is released.

You have that capability.  Probably I will uninstall wx2.8 tomorrow.

There would be no reason to reject your patches on this topic, and you could 
easily make a
lot of people happy.

But don't think I was bullshitting you when I said I would not spend another 
minute on it.



 If new features can't be easily made to work on wx2.8 that's
 understandable as long as there's some graceful downgrade in
 functionality rather than a total build failure.
 
 My motive to support wx2.8 is now zilch.  The project can make its own 
 policy without my
 input on wx2.8 support, but I personally won't spend another minute on it.

 Here is my personal reasoning:  Ubuntu Trusty is free, my time is not.


 Dick




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-15 Thread Andrew Zonenberg 
Understood. I actually just found an unofficial wx 3.0 package for
Debian stable, so I may end up switching over to that as well just for
crazy_imp's antialiasing fix.

On Fri, 2014-08-15 at 15:42 -0500, Dick Hollenbeck wrote:
 On 08/15/2014 02:05 PM, Andrew Zonenberg wrote:
  As a user of wx 2.8 on Debian I would like to ensure that, as a minimum,
  kicad continues to build on it until the next stable Debian version
  (presumably shipping wx 3.0) is released.
 
 You have that capability.  Probably I will uninstall wx2.8 tomorrow.
 
 There would be no reason to reject your patches on this topic, and you could 
 easily make a
 lot of people happy.
 
 But don't think I was bullshitting you when I said I would not spend another 
 minute on it.
 
 
 
  If new features can't be easily made to work on wx2.8 that's
  understandable as long as there's some graceful downgrade in
  functionality rather than a total build failure.
  
  My motive to support wx2.8 is now zilch.  The project can make its own 
  policy without my
  input on wx2.8 support, but I personally won't spend another minute on it.
 
  Here is my personal reasoning:  Ubuntu Trusty is free, my time is not.
 
 
  Dick
 
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp

-- 
Andrew Zonenberg
PhD student, security group
Computer Science Department
Rensselaer Polytechnic Institute
http://colossus.cs.rpi.edu/~azonenberg/


signature.asc
Description: This is a digitally signed message part
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-14 Thread yann jautard 

Hi Dick, and all the others involved in the modular design.

I noticed something regarding the modular kicad apps :

When you have some modal window opened in one of the app, eg the module 
properties window in pcbnew, all the kicad modules are frozen until you 
close that window.


It's not a big deal, but rather boring, when you need to check something 
in eeschema when editing module properties, you can't launch eeschema 
with the button in the kicad main window as it is not responding. And if 
eeschema was alredy opened you can't even scroll the schematic.


I don't know if it is technically possible to change this behaviour, but 
I think it could be a great improvement.


Just my two cents.

regards,

yann


Le 04/08/2014 18:05, Dick Hollenbeck a écrit :

On 07/29/2014 02:02 PM, Wayne Stambaugh wrote:

On 7/27/2014 1:33 PM, Dick Hollenbeck wrote:

Gentlemen:

In the course of trying to load the schematic editor directly under kicad.exe, 
by-passing
eeschema top frame itself, I was exposed to a range of issues in the design of 
eeschema.

Firstly, I discovered the most excellent work by Wayne Stambaugh regarding the 
schematic
library containers.

Thanks Dick.  I wasn't really expecting any credit.  I was just one of
those things that needed fixed so I fixed it.  I knew that that only way
to move Eeschema forward was to fix the underlying library containers.
I wish I had the time to finish the SCHEMATIC object and come up with a
better way to handle sheet hierarchies.  With those two pieces of the
puzzle in place, we could start moving towards the new file format and
other enhancement that we have discussed over the years.


There are a long chain of dependencies here.  LIB_EDIT_FRAME, to come up first, 
needs the
libraries.  That is obvious in words.  But SCH_EDIT_FRAME typically loads the 
libraries
before popping up LIB_EDIT_FRAME.  You have a similar discussion about 
LIB_VIEW_FRAME.

(I believe I solved all these similar problems for PCBNEW.)  So now I went to 
solve them
for EESCHEMA and produced an 11,000 line patch in 2.5 days.  Remember that 
about only
1/7th of a patch line count are actual changed lines.

The eeschema libraries were global, even if hidden behind a static class 
function, they
were global.  This would not dovetail into the notion of multiple open 
projects, each
having its own set of libraries.  So in the course of moving libraries into a 
project
specific container, lots of changes were needed.  First among those was to park 
the
libraries container in the PROJECT.  It was a necessary but insufficient 
solution for
multiple open projects.  One remaining issue is the fact that with multiple 
open projects
you'd still have the same library open twice.  Its hard to have the same 
problem in
PCBNEW, (would have to duplicate project specific libraries) and even if you 
did, most of
the plugins react to a change on disk and will re-cache if one of the copies is 
edited.

We now have the libraries container in the PROJECT at least, and it is loaded 
on demand,
by any _eeschema.kiface KIWAY_PLAYER that needs it.

For 5 years or more no one questioned the terminology I introduced in the SWEET
distributed library design regarding the definition of  PART and a COMPONENT.  
The time to
object was 5 years ago.  So I went with those original terms per that prior 
design.
LIB_COMPONENT is now LIB_PART.  SCH_COMPONENT remains.

Works for me.  I've always thought that LIB_COMPONENT and SCH_COMPONENT
naming was confusing.


SCH_COMPONENT uses a link to a LIB_PART.  That link was previously done by a 
library
search on every Draw() call.  This was easy since the library container was 
global, and
the SCH_COMPONENT had access to the global container.  Not so now.

I seem to remember some other global variables used by the Draw()
functions.  The color table and possibly some visibility settings come
to mind.  I don't know if these have any context per project but it may
be one of those things you want to look out for just in case.


This also introduced an avoidable performance hit, which is avoided if a link 
to the
LIB_PART is retained across SCH_COMPONENT redraws.

You can pretty much now tell where this took me.  Squarely into 
boost::shared_ptr and it
companion class boost::weak_ptr.

I will get it working in another half day and push it to its own branch, and 
would like
folks to use EESCHEMA for a couple of days in that branch.

My son and I are doing a very complex board
together.

And you can load the part editor and footprint editors directly from kicad.exe, 
for a
single project now.

Awesome work Dick!  I'll try to do some testing as soon as I see the
branch on launchpad.

Wayne


I pushed an early branch of this work to milestoneB.

See the commit log for some of the details.

The shared_ptr turned out to be a can of worms.  No, several cans of worms, all 
stacked
like a 2 miles of dominos.

So I used a single one per LIB_PART according to this link here, and saved us 
all a lot

Re: [Kicad-developers] eeschema modular kicad work

2014-08-14 Thread Dick Hollenbeck 

 I don't know if it is technically possible to change this behaviour, but 
 I think it could be a great improvement.
 
:
 yann


Hopefully QuasiModal is not a monster.

For significant dialogs (ones which tend to be open for a while) using the 
QuasiModal
support in DIALOG_SHIM might be a solution to this.  It disables the window 
which invokes
the dialog, but nothing more.

Without the QuasiModal support, the behaviour is platform specific.  On linux, 
I *CAN*
open the schematic editor while viewing footprint properties and scroll, but I 
cannot
close the schematic window.  So that behaviour is arguably worse, since it 
looks like a
bug.  (It is not a bug that I would respond to.  Let's register it as folklore.)

Remember if you cannot close a major KIWAY_PLAYER using system window 
decorations, this
might be because you have a dialog window opened elsewhere on linux.

Please see if this patch fixes the sample issue for you.  The QuasiModal 
support was
something I came up with using only the wxWindows API, not a platform specific 
approach.
I don't know that its been tested enough across all platforms.  Bad news is 
that there may
not be anything I can do except for Linux to fix it, should it not work 
wonderfully on all
platforms.

If this patch works wonderfully, then someone wanting to contribute more of the 
same style
is welcome to.  Simply consider ShowModal() and EndModal() to be a matched set. 
 Replace
them with ShowQuasiModal() and EndQuasiModal() respectively.  Do not mix, keep 
the set
matched.

For me, not all dialogs are likely to be as *prominent* as others, i.e. their 
lifetimes.
In some cases we've used modeless dialogs.  That makes sense where we've used 
it, but it
requires an entirely different coding style from modal and quasimodal.  So 
injecting this
kind of quasimodal patch is easier than going full modal.

It might be prudent to introduce a couple of macros

#define ENDQUASIMODAL   EndQuasiModal
#define SHOWQUASIMODAL  ShowQuasiModal

So this can be turned off globally and revert to true modal if something bad 
gets
discovered down the line.  Then after enough testing we can do global search 
and replace
and jump off the macros.


Dick

=== modified file 'pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp'
--- pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp	2014-08-13 20:28:54 +
+++ pcbnew/dialogs/dialog_edit_module_for_BoardEditor.cpp	2014-08-14 14:00:59 +
@@ -182,7 +182,7 @@
 
 void DIALOG_MODULE_BOARD_EDITOR::OnCancelClick( wxCommandEvent event )
 {
-EndModal( -1 );
+EndQuasiModal( -1 );
 }
 
 
@@ -194,7 +194,7 @@
 m_Parent-OnModify();
 }
 
-EndModal( 2 );
+EndQuasiModal( 2 );
 }
 
 
@@ -204,7 +204,7 @@
 
 // Warning: m_CurrentModule was deleted by exchange module
 m_Parent-SetCurItem( NULL );
-EndModal( 0 );
+EndQuasiModal( 0 );
 }
 
 
@@ -675,7 +675,7 @@
 
 m_Parent-OnModify();
 
-EndModal( 1 );
+EndQuasiModal( 1 );
 
 if( m_DC )
 {

=== modified file 'pcbnew/editmod.cpp'
--- pcbnew/editmod.cpp	2014-05-18 15:16:59 +
+++ pcbnew/editmod.cpp	2014-08-14 13:59:27 +
@@ -59,12 +59,12 @@
 DIALOG_MODULE_BOARD_EDITOR* dialog = new DIALOG_MODULE_BOARD_EDITOR( this, Module, NULL );
 #endif
 
-int retvalue = dialog-ShowModal(); /* retvalue =
- *  -1 if abort,
- *  0 if exchange module,
- *  1 for normal edition
- *  and 2 for a goto editor command
- */
+int retvalue = dialog-ShowQuasiModal();/* retvalue =
+ *  -1 if abort,
+ *  0 if exchange module,
+ *  1 for normal edition
+ *  and 2 for a goto editor command
+ */
 dialog-Destroy();
 
 #ifdef __WXMAC__

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-14 Thread Dick Hollenbeck 
On 08/13/2014 06:40 PM, Wayne Stambaugh wrote:
 On 8/13/2014 6:23 PM, Dick Hollenbeck wrote:
 On 08/13/2014 03:43 PM, Wayne Stambaugh wrote:
 On 8/13/2014 4:37 PM, Dick Hollenbeck wrote:

 Many changes were introduced in revision 5072.

 If you are happy with your current binaries, stay where you are until the 
 pond settles.

 If you want to see if your known bugs are fixed, then take a look at it 
 and that testing
 will be appreciated.


 Thanks,

 Dick


 I did some preliminary testing over the weekend and didn't see any
 issues but my testing was limited to schematic editor.  I did not get a
 chance to test the part library editor or viewer.  I've seen that you've
 made a few changes since my initial testing so I don't if they effected
 the testing I did.  I try doing some more extensive testing over next
 few days with the latest and greatest code.  

 Thank you very much.

 This was a lot of work.


 Towards the end I was liking KiCad source code less and less.  This idea 
 that you make a
 screw driver with a hammer on the end of it was driving me nuts.  How about 
 a screwdriver
 separate from a hammer?

 Many many KiCad functions are simply too complicated, and needed to be split 
 into 2,
 sometimes 3 or more.
 
 You would have had a stroke if you looked at it before all of my
 refactoring up work that I did during the first few years I was with the
 project.  Almost all of the work I did on Eeschema (except for the find
 dialog) was code refactoring and design simplification.  Even then, I
 knew there was still plenty left to clean up.  This is some of the most
 thankless work because the only people who really appreciate it are
 other developers who can appreciate quality software design. 


Thank you Wayne.

Your help during those early years were invaluable to the viability of the 
project.

Now, you'll need all the support you can find to continue and not get 
discouraged like me.


Regards,

Dick

One man's trash is another man's treasure,
  a time travelling software engineer.






 I know it
 was difficult seeing the forest through the trees and underbrush that is
 the Eeschema code.
 


 There are still some that I cannot understand even after reading the 
 function header
 documentation.

 This is highlighting the difference between a software architect and a 
 programmer.

 Simple functions crafted together to create a complex architecture that is 
 easily
 understood is far better than complex functions crafted together to create a 
 simple
 architecture which remains incomprehensible.


 No way I go through that torture without ranting.  Good thing there was no 
 audio recording
 of it.
 
 Trust me when I tell you that I had more than a few choice adjectives
 when I was doing my refactoring.
 

 We're near the end now.



 Thank you!

 Wayne



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-14 Thread yann jautard 


Le 14/08/2014 16:21, Dick Hollenbeck a écrit :

I don't know if it is technically possible to change this behaviour, but
I think it could be a great improvement.


:

yann


Hopefully QuasiModal is not a monster.

For significant dialogs (ones which tend to be open for a while) using the 
QuasiModal
support in DIALOG_SHIM might be a solution to this.  It disables the window 
which invokes
the dialog, but nothing more.

Without the QuasiModal support, the behaviour is platform specific.  On linux, 
I *CAN*
open the schematic editor while viewing footprint properties and scroll, but I 
cannot
close the schematic window.  So that behaviour is arguably worse, since it 
looks like a
bug.  (It is not a bug that I would respond to.  Let's register it as folklore.)


Hi Dick,

This sounds pretty strange : I'm on linux too, and I can't. Kicad main 
window frozen when dialog opened in pcbnew.




Remember if you cannot close a major KIWAY_PLAYER using system window 
decorations, this
might be because you have a dialog window opened elsewhere on linux.

Please see if this patch fixes the sample issue for you.  The QuasiModal 
support was
something I came up with using only the wxWindows API, not a platform specific 
approach.
I don't know that its been tested enough across all platforms.  Bad news is 
that there may
not be anything I can do except for Linux to fix it, should it not work 
wonderfully on all
platforms.




Patch solved the issue, seemed to work like a charm... But induced 
another issue. Step to reproduce :


1 - open kicad, then open eeschema and pcbnew
2 - in pcbnew, open the module properties dialog on any part you want.
3 - go back to eeschema, wich is now responding normally, and open the 
component properties dialog, on the same part or another one (doesn't 
matters).
4 - go back to pcbnew, close the dialog, either with OK or Cancel -- 
dialog closes, but pcbnew is frozen and also can't be closed in any 
normal way.
eeschema still works, you can close the dialog and use it normally. 
Kicad main window works also.
Eeschema can be closed normally, kicad main window also, but when 
closing main window, pcbnew window closes too, but the kicad process is 
still there and you need to kill it.


I thought I will modify eeschema in the same way to test if it does 
something else, and so I noticed the eeschema component properties 
dialog was alredy a QuasiModal one.


And obviously the same test starting with eeschema instead of pcbnew 
leads to to opposite result : eeschema stuck, pcbnew working.

And again, the need to kill kicad process after closing the main window.

During that test, the following error appears some times :

(kicad:10263): Gtk-CRITICAL **: IA__gtk_widget_add_accelerator: 
assertion 'GTK_IS_WIDGET (widget)' failed



This was tested with bzr5049 :

Application: kicad
Version: (2014-08-04 BZR 5049)-product Release build
wxWidgets: Version 2.8.12 (release,Unicode,compiler with C++ ABI 
1002,GCC 4.8.1,wx containers,compatible with 2.6)

Platform: Linux 3.13.0-34-generic i686, 32 bit, Little endian, wxGTK
Boost version: 1.54.0
 USE_WX_GRAPHICS_CONTEXT=OFF
 USE_WX_OVERLAY=OFF
 KICAD_SCRIPTING=OFF
 KICAD_SCRIPTING_MODULES=OFF
 KICAD_SCRIPTING_WXPYTHON=OFF
 USE_FP_LIB_TABLE=HARD_CODED_ON
 BUILD_GITHUB_PLUGIN=ON


I updated my source tree to latest bzr to test with that revision, but I 
did a mistake and I need to recompile the whole stuff. As I have only my 
netbook now, it will take one hour or more, so I will test that tomorow


Regards,

Yann


If this patch works wonderfully, then someone wanting to contribute more of the 
same style
is welcome to.  Simply consider ShowModal() and EndModal() to be a matched set. 
 Replace
them with ShowQuasiModal() and EndQuasiModal() respectively.  Do not mix, keep 
the set
matched.

For me, not all dialogs are likely to be as *prominent* as others, i.e. their 
lifetimes.
In some cases we've used modeless dialogs.  That makes sense where we've used 
it, but it
requires an entirely different coding style from modal and quasimodal.  So 
injecting this
kind of quasimodal patch is easier than going full modal.

It might be prudent to introduce a couple of macros

#define ENDQUASIMODAL   EndQuasiModal
#define SHOWQUASIMODAL  ShowQuasiModal

So this can be turned off globally and revert to true modal if something bad 
gets
discovered down the line.  Then after enough testing we can do global search 
and replace
and jump off the macros.


Dick



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe :

Re: [Kicad-developers] eeschema modular kicad work

2014-08-13 Thread Dick Hollenbeck 

Many changes were introduced in revision 5072.

If you are happy with your current binaries, stay where you are until the pond 
settles.

If you want to see if your known bugs are fixed, then take a look at it and 
that testing
will be appreciated.


Thanks,

Dick



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-13 Thread Wayne Stambaugh 
On 8/13/2014 4:37 PM, Dick Hollenbeck wrote:
 
 Many changes were introduced in revision 5072.
 
 If you are happy with your current binaries, stay where you are until the 
 pond settles.
 
 If you want to see if your known bugs are fixed, then take a look at it and 
 that testing
 will be appreciated.
 
 
 Thanks,
 
 Dick
 

I did some preliminary testing over the weekend and didn't see any
issues but my testing was limited to schematic editor.  I did not get a
chance to test the part library editor or viewer.  I've seen that you've
made a few changes since my initial testing so I don't if they effected
the testing I did.  I try doing some more extensive testing over next
few days with the latest and greatest code.  This was a lot of work.
Thank you!

Wayne


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-13 Thread Dick Hollenbeck 
On 08/13/2014 03:43 PM, Wayne Stambaugh wrote:
 On 8/13/2014 4:37 PM, Dick Hollenbeck wrote:

 Many changes were introduced in revision 5072.

 If you are happy with your current binaries, stay where you are until the 
 pond settles.

 If you want to see if your known bugs are fixed, then take a look at it and 
 that testing
 will be appreciated.


 Thanks,

 Dick

 
 I did some preliminary testing over the weekend and didn't see any
 issues but my testing was limited to schematic editor.  I did not get a
 chance to test the part library editor or viewer.  I've seen that you've
 made a few changes since my initial testing so I don't if they effected
 the testing I did.  I try doing some more extensive testing over next
 few days with the latest and greatest code.  

Thank you very much.

 This was a lot of work.


Towards the end I was liking KiCad source code less and less.  This idea that 
you make a
screw driver with a hammer on the end of it was driving me nuts.  How about a 
screwdriver
separate from a hammer?

Many many KiCad functions are simply too complicated, and needed to be split 
into 2,
sometimes 3 or more.


There are still some that I cannot understand even after reading the function 
header
documentation.

This is highlighting the difference between a software architect and a 
programmer.

Simple functions crafted together to create a complex architecture that is 
easily
understood is far better than complex functions crafted together to create a 
simple
architecture which remains incomprehensible.


No way I go through that torture without ranting.  Good thing there was no 
audio recording
of it.

We're near the end now.



 Thank you!
 
 Wayne
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers
 Post to : kicad-developers@lists.launchpad.net
 Unsubscribe : https://launchpad.net/~kicad-developers
 More help   : https://help.launchpad.net/ListHelp
 


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-13 Thread Cirilo Bernardo 
- Original Message -

 From: Dick Hollenbeck d...@softplc.com
 To: kicad-developers@lists.launchpad.net
 Cc: 
 Sent: Thursday, August 14, 2014 6:37 AM
 Subject: Re: [Kicad-developers] eeschema modular kicad work
 
 
 Many changes were introduced in revision 5072.
 
 If you are happy with your current binaries, stay where you are until the 
 pond 
 settles.
 
 If you want to see if your known bugs are fixed, then take a look at it and 
 that 
 testing
 will be appreciated.
 
 
 Thanks,
 
 Dick
 


Thanks Dick, you're doing a great job on a huge task. Personally I didn't notice
anything break throughout the KiWay implementation. Will pull in the latest
source and test.

- Cirilo


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] eeschema modular kicad work

2014-08-13 Thread Wayne Stambaugh 
On 8/13/2014 6:23 PM, Dick Hollenbeck wrote:
 On 08/13/2014 03:43 PM, Wayne Stambaugh wrote:
 On 8/13/2014 4:37 PM, Dick Hollenbeck wrote:

 Many changes were introduced in revision 5072.

 If you are happy with your current binaries, stay where you are until the 
 pond settles.

 If you want to see if your known bugs are fixed, then take a look at it and 
 that testing
 will be appreciated.


 Thanks,

 Dick


 I did some preliminary testing over the weekend and didn't see any
 issues but my testing was limited to schematic editor.  I did not get a
 chance to test the part library editor or viewer.  I've seen that you've
 made a few changes since my initial testing so I don't if they effected
 the testing I did.  I try doing some more extensive testing over next
 few days with the latest and greatest code.  
 
 Thank you very much.
 
 This was a lot of work.
 
 
 Towards the end I was liking KiCad source code less and less.  This idea that 
 you make a
 screw driver with a hammer on the end of it was driving me nuts.  How about a 
 screwdriver
 separate from a hammer?
 
 Many many KiCad functions are simply too complicated, and needed to be split 
 into 2,
 sometimes 3 or more.

You would have had a stroke if you looked at it before all of my
refactoring up work that I did during the first few years I was with the
project.  Almost all of the work I did on Eeschema (except for the find
dialog) was code refactoring and design simplification.  Even then, I
knew there was still plenty left to clean up.  This is some of the most
thankless work because the only people who really appreciate it are
other developers who can appreciate quality software design.  I know it
was difficult seeing the forest through the trees and underbrush that is
the Eeschema code.

 
 
 There are still some that I cannot understand even after reading the function 
 header
 documentation.
 
 This is highlighting the difference between a software architect and a 
 programmer.
 
 Simple functions crafted together to create a complex architecture that is 
 easily
 understood is far better than complex functions crafted together to create a 
 simple
 architecture which remains incomprehensible.
 
 
 No way I go through that torture without ranting.  Good thing there was no 
 audio recording
 of it.

Trust me when I tell you that I had more than a few choice adjectives
when I was doing my refactoring.

 
 We're near the end now.
 
 
 
 Thank you!

 Wayne



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp