Hello Dick, I would hate to see you leave the project, you are the top contributor. Thanks, Edwin van den Oetelaar
On Mon, Apr 21, 2014 at 7:30 PM, Dick Hollenbeck <[email protected]> wrote: > 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 >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
