On 04/21/2014 12:16 PM, Lorenzo Marcantonio wrote: > On Mon, Apr 21, 2014 at 11:26:53AM -0500, Dick Hollenbeck wrote: >> 1) I can decide where I expect to find the KIFACEs, your strategy relies on >> the OS to tell >> the loader. This is a user PITA issue, and reliability of the install. > > In the same way it finds the wx libraries, in /usr/lib[64] or whatever. > >> 2) I can set the LD_ENV_VAR environment variable programmitically in my >> program which >> tells where the libs that the KIFACEs need are. People do not know how to >> do this on >> their own. > > LD_LIBRARY_PATH, the same > >> 3) Your way, the program won't load at all if ALL the DSOs are not found >> immediately. And >> all dependencies they may have. > > Same for the wx modules if not monolithic. Also AFAIK there is no plan > of a 'partial' kicad installation. If you want to do 'eeschema without > pcb', then your approach would be the only one working. > >> 4) It will load slower, and load some KIFACEs not of interest to someone >> just wanting to >> work in schematic. > > Partially true, but it only needs to relocate, since executable paging > is on demand, but many people prelink these days. Also the UNO model in > openoffice actually slowed it down a lot, when it was introduced (but > maybe loading was not the issue there). > >> 5) You will have possible name collisions in the link process of the top >> *.exe. > > *This* would be a good thing, since these collision would happen at > runtime (probably undetected). Had many crashes from dynamically loading > a library using a different libjpeg version:P The global issue we talked > about before. In fact this is my primary reason for preferring a link instead > of a load. One process core => one symbol namespace > >> 6) It is not as flexible moving forward, the above arguments only get more >> pronounced as >> should you add additional KIFACEs. > > *If* you want to cater to 'arbitrary' interfaces (like the mozilla > plugin loader) then I agree your design is better. For the current and > near future I don't see an improvement. > >> So no, I do not agree, again. File a bug report if you have problems. >> >> Or take it up with the core development team, which is now lead by Wayne. >> >> They have conversations among themselves, and have chosen people in that >> group in part by >> how easy they are to work with. I noticed you are not in the group. > > I'm just discussing the design, not forcing opinion on how to do things.
> It's called 'reviewing' and 'suggesting'. If the core team don't want to > discuss the best way to do thing too bad for them. I'd have preferred > keeping different processes with a better IPC (M0Q, corba, soap, xmlrpc, > dcerpc, whatever) but I agree that the portability issues were serious > in that case. > > Potential problems I have on mind about the current implementation: > > - One 'window' crashes, everything go down, obviously :P of course > crashing is undesired anyway, so it's not an issue :D (even windows > explorer has the 'open window in another process' for that, but see > below for the reason) > > - SIGINT (or xkill) to eeschema pull down the associated pcbnew (or > viceversa if pcbnew gets an open schematic button), if I got this > correctly... this is not very nice (I agree it's a minor issue). In > fact I *never* use the open pcb button in eeschema or the kicad > project manager because wx messes up the process group management > creating a similar issue. > > Sadly many modern programs don't follow the 'one toplevel window for > process' guideline, too bad. I'd actually have split the > module/library viewers/editors in different processes... but then > process creation in Windows is a *very* heavy operation, while a fork > itself is lighter than opening a file. So a compromise is needed. > > - What if I open the schematic in one instance and the board in another > one? Do I lose cross probing? > > - Somewhat related to the above: what if I have two different boards > implemented for the same schematic? We do this regularly for the same > circuit for different clients... so i use circuit.sch, > circuit-c1.kicad_brd and circuit-c2.kicad_brd; if the 'open board' can't be > customized in some way (instead of always opening circuit.kicad_brd) > it would be difficult to handle. Possible workaround: a file open from > the pcbnew windows would keep the connection? I have $10,000 of my time into the design. The only thing I want to hear at this point is thank you. Re-imburse me, and we'll have the conversation. All the rest is pretty demotivating, and only that. File a fucking bug report. Click, delete. This is why I am leaving the project. A bunch of ingrates, who think software grows on trees. It only takes a few. The rest are good guys. Perfect example for the future though. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
