[Kicad-developers] A few issues with new OS X bundles
Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the sub-application, leaving you with a KiCad application menu as it switched back the the main app. Not really a huge issue but is can be confusing and if you’re not paying attention you can accidentally quit your main app. Not cool. The additional things I’m seeing with the new bundling is that now the applications the previously did launch as separate applications, even when launched from the main app, now have no icon of their own. They get the icon of the main kicad.app. So if I launch, say, gerbview and pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which one belongs to which application. I have to play icon roulette to find out. With the new CMakeLists.txt changes for these applications it seems there’s no way to go back to building individual application bundles for them without hacking and slashing. Any chance we can get back the ability to make bundles for these? I’d go so far as to recommend that the bundles be included wholesale in an Applications directory int the main bundle, but I’d at least like the option of building them as bundles separately. Thanks in advance, Garth smime.p7s Description: S/MIME cryptographic signature ___ 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] A few issues with new OS X bundles
Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the sub-application, leaving you with a KiCad application menu as it switched back the the main app. Not really a huge issue but is can be confusing and if you’re not paying attention you can accidentally quit your main app. Not cool. The additional things I’m seeing with the new bundling is that now the applications the previously did launch as separate applications, even when launched from the main app, now have no icon of their own. They get the icon of the main kicad.app. So if I launch, say, gerbview and pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which one belongs to which application. I have to play icon roulette to find out. With the new CMakeLists.txt changes for these applications it seems there’s no way to go back to building individual application bundles for them without hacking and slashing. Any chance we can get back the ability to make bundles for these? I’d go so far as to recommend that the bundles be included wholesale in an Applications directory int the main bundle, but I’d at least like the option of building them as bundles separately. Thanks in advance, Garth___ 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] A few issues with new OS X bundles
Right. I get that for the loadable bundles the application is still KiCad, but for those applications there’s no second icon, which is probably better behavior. Then you only have the problem of them having a Quit menu item that does not quit the application but just unloads the bundle, which I’d argue will be surprising behavior for most mac users. The new issue that is bundle related is that for the applications that don’t do this, the ones that launch a separate process, the new bundling deprives them of their icon and they look indistinguishable from the main application. These, I think, should have their icons back until such time as they are integrated in the same way as eeschema and pcbnew (or can dynamically change their icon). I’d just like to be able to build bundles for these so that I can integrate them into my bundle in a different way. They don’t have to build bundles by default, but it’d be nice if I could build a separate target. Garth On Oct 4, 2014, at 1:26 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the sub-application, leaving you with a KiCad application menu as it switched back the the main app. Not really a huge issue but is can be confusing and if you’re not paying attention you can accidentally quit your main app. Not cool. The additional things I’m seeing with the new bundling is that now the applications the previously did launch as separate applications, even when launched from the main app, now have no icon of their own. They get the icon of the main kicad.app. So if I launch, say, gerbview and pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which one belongs to which application. I have to play icon roulette to find out. With the new CMakeLists.txt changes for these applications it seems there’s no way to go back to building individual application bundles for them without hacking and slashing. Any chance we can get back the ability to make bundles for these? I’d go so far as to recommend that the bundles be included wholesale in an Applications directory int the main bundle, but I’d at least like the option of building them as bundles separately. Thanks in advance, Garth___ 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 smime.p7s Description: S/MIME cryptographic signature ___ 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] A few issues with new OS X bundles
Hi again, again for the “dock roulette”… IMHO this is just an inconsistency between how pcbnew/eeschema and gerbview/other apps are started from KiCad launcher. For pcbnew/eeschema no individual icon in the dock is created, but for the others. For the other apps you also see a message “kicad.app/Contents/MacOS/pl_editor opened [pid=89027]” in KiCad launcher (even being a .kiface module), you don’t see that for eeschema/pcbnew. I guess it should be the same for all apps/modules except bitmap2component, which currently doesn’t have a kiface. Regards, Bernhard On 04.10.2014, at 10:26, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the sub-application, leaving you with a KiCad application menu as it switched back the the main app. Not really a huge issue but is can be confusing and if you’re not paying attention you can accidentally quit your main app. Not cool. The additional things I’m seeing with the new bundling is that now the applications the previously did launch as separate applications, even when launched from the main app, now have no icon of their own. They get the icon of the main kicad.app. So if I launch, say, gerbview and pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which one belongs to which application. I have to play icon roulette to find out. With the new CMakeLists.txt changes for these applications it seems there’s no way to go back to building individual application bundles for them without hacking and slashing. Any chance we can get back the ability to make bundles for these? I’d go so far as to recommend that the bundles be included wholesale in an Applications directory int the main bundle, but I’d at least like the option of building them as bundles separately. Thanks in advance, Garth___ 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 ___ 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] A few issues with new OS X bundles
I’m sure it will get there. I certainly prefer the approach you are taking of eliminating these as standalone application bundles. There really isn’t a need for them with the kicad launcher. It’s just introduced a couple of minor usability nits for me, which I’m sure will be cured over time. I’ll poke at it tomorrow and see if I can get things to work for me without resorting to building bundles for them. Failing that, I will just patch the CMakeLists for the time being. Garth On Oct 4, 2014, at 2:00 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi again, again for the “dock roulette”… IMHO this is just an inconsistency between how pcbnew/eeschema and gerbview/other apps are started from KiCad launcher. For pcbnew/eeschema no individual icon in the dock is created, but for the others. For the other apps you also see a message “kicad.app/Contents/MacOS/pl_editor opened [pid=89027]” in KiCad launcher (even being a .kiface module), you don’t see that for eeschema/pcbnew. I guess it should be the same for all apps/modules except bitmap2component, which currently doesn’t have a kiface. Regards, Bernhard On 04.10.2014, at 10:26, Bernhard Stegmaier stegma...@sw-systems.de wrote: Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the sub-application, leaving you with a KiCad application menu as it switched back the the main app. Not really a huge issue but is can be confusing and if you’re not paying attention you can accidentally quit your main app. Not cool. The additional things I’m seeing with the new bundling is that now the applications the previously did launch as separate applications, even when launched from the main app, now have no icon of their own. They get the icon of the main kicad.app. So if I launch, say, gerbview and pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which one belongs to which application. I have to play icon roulette to find out. With the new CMakeLists.txt changes for these applications it seems there’s no way to go back to building individual application bundles for them without hacking and slashing. Any chance we can get back the ability to make bundles for these? I’d go so far as to recommend that the bundles be included wholesale in an Applications directory int the main bundle, but I’d at least like the option of building them as bundles separately. Thanks in advance, Garth___ 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 smime.p7s Description: S/MIME cryptographic signature ___ 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
[Kicad-developers] FOSDEM 2015 EDA devroom
Dear all, Good news: my request for an EDA devroom in FOSDEM 2015 was accepted! I will send out an official call for contributions in the next week or two, but I wanted to give you a heads up so that you can start thinking about coming and joining the fun. I think this is a very good opportunity to meet your online friends face to face, and it can be very good for KiCad as a project too. It is also a good chance to discuss with the people working on other EDA projects and see if there is something we can share. Please do not hesitate to announce your intention to attend. The case for others will become more compelling that way. It would be great if, in addition to a general EDA meeting, this were also the opportunity for a big KiCad family meet-up! Tomasz, Orson and I will be there for sure. I look forward to meeting many of you in Brussels early next year. Cheers, Javier ___ 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] VRML export.
On 10/3/2014 8:15 PM, Cirilo Bernardo wrote: On Sat, Oct 4, 2014 at 5:33 AM, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: I've been trying use Pcbnew the VRML export for a board a work and discovered some serious design issues with the way file names are manipulated which broke exporting the model files on windows. I fixed those and while digging around in the VRML export code, I noticed a few things that didn't make any sense to me. Why are only .x3d file names embedded inside the board VRML file and not .wrl files? Why are the .x3d file names embedded even when they are copied to the 3D model path? Why wouldn't you either embed all the footprint models in the board file or copy all of the footprint model files to the 3D model path? It seems to me it should be one or the other not both. The use relative paths in the board VRML file option does nothing as far as I can tell. I'm willing to fix this but we need to define what this behavior should be because what we have now is rather chaotic. My initial feeling is that the embedded code should be removed until we can embed all supported 3D model file formats. Anyone else have any thoughts on this? One more note. Please use wxFileName instead of wxString when manipulating file names and paths. I've probably fixed a dozen or so places over the years where this same wxString path manipulation code has been used and has caused nothing but grief. Please keep in mind that we are a cross platform application. If you need Posix path separators for saving paths and/or file name in files, use wxFileName::GetFullPath(wxPATH_UNIX). This will convert the separators from \ to / and still allow you to use native paths for file operations internally which is more reliable. Thanks, Wayne Hi Wayne, I'll find some time to have a look at the issues. I don't get what you mean by the x3d file names being embedded and not the wrl files. I always thought it was the other way around. The X3D model data is written to the output VRML file but the VRML data is retained as separate files and only the names are put into the output VRML file. Embedding the X3D model date assures VRML2 compatibility; a VRML2 browser will not necessarily be able to parse and display the contents of an x3d file. I didn't realize the x3d models were being copied to the path as well; that's just wrong. Cirilo, Please don't fix anything just yet until I commit my changes. Otherwise we will have clashes in the code. You may be correct about the x3d files but I don't have any of them to test the code. Looking at the code, the output of the x3d to vrml conversion is being added to the board vrml file not to a separate model file in the 3D model path which is where I would expect it to go. I also fixed a memory leak for every x3d parser that is created. If you happen to have an x3d model of a component, please send it to me so I can test/fix this code path. Before I rewrote much of the VRML exporter, it always used file references to the models, never the actual model data. It is the introduction of the X3D code which changed this a bit. What I'd like to do is to put all the VRML model data in a single file as well, but this is not a simple task. For me, the ideal is to create a model management object which implements caching and other tricks to minimize the memory footprint. These object models should be able to export data in VRML2 format as the X3D code currently does (though admittedly in a very inefficient way). I'd also like the output to use DEF/USE to keep the file as small as possible. It's all possible; the IDF tool 'idf2vrml' can create VRML files which reuse objects and it also has an option not to reuse objects so that the output can in turn be used an an input model to KiCad. Of course if we improved the VRML loader for KiCad so that it handled DEF/USE better that would simplify some things and allow many detailed models to be more compact (for example we don't have hundreds of 1206 models, or 64 pin models on each TQFP64). It makes sense to only have one copy of each unique model embedded in the vrml file. I'm guessing that each model definition in a vrml file can be referenced more than once. Until you have a chance to make the changes to embed the models in the board vrml file, I will fix the current code so it properly converts and copies x3d files to the 3D model path. I will also fix the 3D model file copying so it doesn't overwrite the same model file for each time a model is used on the board. I'll probably use the source file modification time stamp and only copy the file when the destination file doesn't exist or the modification time has changed since the last copy. So changes are planned, but at the moment they're on hold pending the ongoing work
Re: [Kicad-developers] FOSDEM 2015 EDA devroom
Javier, Great job and thank you for your efforts. Barring anything unexpected, I will be attending FOSDEM. I'm looking forward to meeting as many of you as possible and collaborating with the other EDA projects. If you can, please try to make it to FOSDEM. It sounds like it will be a great time and it's always nice to put faces with the names. Once I have my travel arrangements in place, I will let you know. Hopefully there will be some free time in the evening to stop at a pub and enjoy some fine Belgium malted beverages. I'm looking forward to seeing you at FOSDEM. Cheers, Wayne On 10/4/2014 8:00 AM, Javier Serrano wrote: Dear all, Good news: my request for an EDA devroom in FOSDEM 2015 was accepted! I will send out an official call for contributions in the next week or two, but I wanted to give you a heads up so that you can start thinking about coming and joining the fun. I think this is a very good opportunity to meet your online friends face to face, and it can be very good for KiCad as a project too. It is also a good chance to discuss with the people working on other EDA projects and see if there is something we can share. Please do not hesitate to announce your intention to attend. The case for others will become more compelling that way. It would be great if, in addition to a general EDA meeting, this were also the opportunity for a big KiCad family meet-up! Tomasz, Orson and I will be there for sure. I look forward to meeting many of you in Brussels early next year. Cheers, Javier ___ 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] A few issues with new OS X bundles
On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote: Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. KiCad no longer launches executables that run in a separate process. Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually child windows of the KiCad application. Eeschema, Pcbnew, etc. are also a stand alone programs but they don't get called from KiCad any longer. Some users prefer to run the individual applications this way so it would be nice if we could provide a separate icon and shortcut (or whatever it's called on OSX) so that the stand alone applications could be launched. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the sub-application, leaving you with a KiCad application menu as it switched back the the main app. Not really a huge issue but is can be confusing and if you’re not paying attention you can accidentally quit your main app. Not cool. The additional things I’m seeing with the new bundling is that now the applications the previously did launch as separate applications, even when launched from the main app, now have no icon of their own. They get the icon of the main kicad.app. So if I launch, say, gerbview and pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which one belongs to which application. I have to play icon roulette to find out. With the new CMakeLists.txt changes for these applications it seems there’s no way to go back to building individual application bundles for them without hacking and slashing. Any chance we can get back the ability to make bundles for these? I’d go so far as to recommend that the bundles be included wholesale in an Applications directory int the main bundle, but I’d at least like the option of building them as bundles separately. Thanks in advance, Garth___ 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 ___ 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] A few issues with new OS X bundles
There are 2 possibilities as far as I can see: (1) One single application bundle - like it is now. There are probably still some cosmetic issues as Garth told, but I think these are just minor inconsistencies that could be sorted out. From an efficiency point of view it is no difference… 2 clicks this way to start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the same for the “old” approach (one click to open KiCad folder, second to start pcbnew). Positive: No space wasted Positive: No dependency problems, it just is self-contained and completely relocatable Negative: May break with users habits (Apple does this all the time, so nothing new for OSX users… :) ) (2) A KiCad-fodler with one application bundle per “executable” - from a users point of view how it was before. Again, two options: (2a) Self-contained bundles You have to pull every dependency into every bundle. Especially, you also have to duplicate all the *.kifaces into the kicad bundle for the launcher (and maybe also into other bundles e.g. if you want/could launch pcbnew from eeschema - don’t know if that is possible). If you don’t do it like that (as it was before using symlinks between bundles), it looks like it is a normal OSX application you can move around where you want, but actually you can’t because you break inter-bundle dependencies. Maybe it is not a regular use-case to pull e.g. pcbnew out of the KiCad folder, but nobody forbids that… so maybe someone likes to drag pcbnew to his desktop because then it’s only one click to start... Positive: Everything is individually self-contained Negative: Space wasted for duplicating things - especially pcbnew with scripting pulls in all the wxPython stuff that will be contained at least twice then... (2b) App-Folder + Individual Bundles + Common-Folder All the dependencies and the *.kifaces are put into the common folder, the bundles itself are linked in a way to use things from the common folder. Positive: No space wasted Negative: Inter-Bundle dependencies as explained in (2a). Negative: Just a cosmetic issue, but you always see that common folder in the dock launcher One thing to note is that even in (1) you could start, e.g., pcbnew from command line as “standalone” binary. I must confess, I am not an OSX bundle guru. If anybody has a nice other solution, I’ll be glad to hear. Regards, Bernhard On 04.10.2014, at 15:17, Wayne Stambaugh stambau...@verizon.net wrote: On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote: Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. KiCad no longer launches executables that run in a separate process. Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually child windows of the KiCad application. Eeschema, Pcbnew, etc. are also a stand alone programs but they don't get called from KiCad any longer. Some users prefer to run the individual applications this way so it would be nice if we could provide a separate icon and shortcut (or whatever it's called on OSX) so that the stand alone applications could be launched. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the sub-application, leaving you with a KiCad application menu as it switched back the the main app. Not really a huge issue but is can be confusing and if you’re not paying attention you can accidentally quit your main app. Not cool. The additional things I’m seeing with the new bundling is that now the applications the previously did launch as separate applications, even when launched from the main app, now have no icon of their own. They get the icon of the main kicad.app. So if I launch, say,
Re: [Kicad-developers] A few issues with new OS X bundles
One additional note on (1): You can create an alias pointing to, e.g., the pcbnew executable inside the kicad bundle and put it where you want. Therewith, you can start pcbnew directly by clicking on it - only downside is that since pcbnew executable looks like a command line binary for OSX a terminal is started in which then pcbnew is executed. Regards, Bernhard On 04.10.2014, at 15:56, Bernhard Stegmaier stegma...@sw-systems.de wrote: There are 2 possibilities as far as I can see: (1) One single application bundle - like it is now. There are probably still some cosmetic issues as Garth told, but I think these are just minor inconsistencies that could be sorted out. From an efficiency point of view it is no difference… 2 clicks this way to start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the same for the “old” approach (one click to open KiCad folder, second to start pcbnew). Positive: No space wasted Positive: No dependency problems, it just is self-contained and completely relocatable Negative: May break with users habits (Apple does this all the time, so nothing new for OSX users… :) ) (2) A KiCad-fodler with one application bundle per “executable” - from a users point of view how it was before. Again, two options: (2a) Self-contained bundles You have to pull every dependency into every bundle. Especially, you also have to duplicate all the *.kifaces into the kicad bundle for the launcher (and maybe also into other bundles e.g. if you want/could launch pcbnew from eeschema - don’t know if that is possible). If you don’t do it like that (as it was before using symlinks between bundles), it looks like it is a normal OSX application you can move around where you want, but actually you can’t because you break inter-bundle dependencies. Maybe it is not a regular use-case to pull e.g. pcbnew out of the KiCad folder, but nobody forbids that… so maybe someone likes to drag pcbnew to his desktop because then it’s only one click to start... Positive: Everything is individually self-contained Negative: Space wasted for duplicating things - especially pcbnew with scripting pulls in all the wxPython stuff that will be contained at least twice then... (2b) App-Folder + Individual Bundles + Common-Folder All the dependencies and the *.kifaces are put into the common folder, the bundles itself are linked in a way to use things from the common folder. Positive: No space wasted Negative: Inter-Bundle dependencies as explained in (2a). Negative: Just a cosmetic issue, but you always see that common folder in the dock launcher One thing to note is that even in (1) you could start, e.g., pcbnew from command line as “standalone” binary. I must confess, I am not an OSX bundle guru. If anybody has a nice other solution, I’ll be glad to hear. Regards, Bernhard On 04.10.2014, at 15:17, Wayne Stambaugh stambau...@verizon.net wrote: On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote: Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. KiCad no longer launches executables that run in a separate process. Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually child windows of the KiCad application. Eeschema, Pcbnew, etc. are also a stand alone programs but they don't get called from KiCad any longer. Some users prefer to run the individual applications this way so it would be nice if we could provide a separate icon and shortcut (or whatever it's called on OSX) so that the stand alone applications could be launched. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the
[Kicad-developers] Macro expansion in module text
Sorry about the delay, we had the automechanika fair and related stuff to handle :P In fact the patch is quite simple (I already did the biggest changes...) It handles % sequences in user text primitives inside modules (usefulness already debated); now it recognizes: %% for a plain % %R inserts the reference %V inserts the value Obviously it can be extended to insert other stuff (has to be available from the module class, however). The only issue is repainting, since it insert a dependency between unrelated fields: when you change reference or value the user fields using them are not updated until the next redraw. Shouldn't be a big problem, however. Extensive testing is, as usual, appreciated. Have fun -- Lorenzo Marcantonio Logos Srl ___ 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] A few issues with new OS X bundles
Since this doesn't effect me, I don't have a preference one way or another. Although option 2B makes the most sense to me. OSX users please weigh in so we can get this right. You might want to get some input from the user group on Yahoo. There may be more OSX users than developers and their input may be useful..Thanks again Bernhard for all of your hard work. On 10/4/2014 10:10 AM, Bernhard Stegmaier wrote: One additional note on (1): You can create an alias pointing to, e.g., the pcbnew executable inside the kicad bundle and put it where you want. Therewith, you can start pcbnew directly by clicking on it - only downside is that since pcbnew executable looks like a command line binary for OSX a terminal is started in which then pcbnew is executed. Regards, Bernhard On 04.10.2014, at 15:56, Bernhard Stegmaier stegma...@sw-systems.de mailto:stegma...@sw-systems.de wrote: There are 2 possibilities as far as I can see: *(1) One single application bundle - like it is now.* There are probably still some cosmetic issues as Garth told, but I think these are just minor inconsistencies that could be sorted out. From an efficiency point of view it is no difference… 2 clicks this way to start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the same for the “old” approach (one click to open KiCad folder, second to start pcbnew). Positive: No space wasted Positive: No dependency problems, it just is self-contained and completely relocatable Negative: May break with users habits (Apple does this all the time, so nothing new for OSX users… :) ) *(2) A KiCad-fodler with one application bundle per “executable” - from a users point of view how it was before.* Again, two options: *(2a) Self-contained bundles * You have to pull every dependency into every bundle. Especially, you also have to duplicate all the *.kifaces into the kicad bundle for the launcher (and maybe also into other bundles e.g. if you want/could launch pcbnew from eeschema - don’t know if that is possible). If you don’t do it like that (as it was before using symlinks between bundles), it looks like it is a normal OSX application you can move around where you want, but actually you can’t because you break inter-bundle dependencies. Maybe it is not a regular use-case to pull e.g. pcbnew out of the KiCad folder, but nobody forbids that… so maybe someone likes to drag pcbnew to his desktop because then it’s only one click to start... Positive: Everything is individually self-contained Negative: Space wasted for duplicating things - especially pcbnew with scripting pulls in all the wxPython stuff that will be contained at least twice then... *(2b) App-Folder + Individual Bundles + Common-Folder* All the dependencies and the *.kifaces are put into the common folder, the bundles itself are linked in a way to use things from the common folder. Positive: No space wasted Negative: Inter-Bundle dependencies as explained in (2a). Negative: Just a cosmetic issue, but you always see that common folder in the dock launcher One thing to note is that even in (1) you could start, e.g., pcbnew from command line as “standalone” binary. I must confess, I am not an OSX bundle guru. If anybody has a nice other solution, I’ll be glad to hear. Regards, Bernhard On 04.10.2014, at 15:17, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote: Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. KiCad no longer launches executables that run in a separate process. Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually child windows of the KiCad application. Eeschema, Pcbnew, etc. are also a stand alone programs but they don't get called from KiCad any longer. Some users prefer to run the individual applications this way so it would be nice if we could provide a separate icon and shortcut (or whatever it's called on OSX) so that the stand alone applications could be launched. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com mailto:gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline
Re: [Kicad-developers] A few issues with new OS X bundles
I’m afraid that’s not true in this case. It does launch separate processes for some some of the applications, gerbview for instance. They show up in ps and as Bernhard pointed out, the launcher even shows you the pid when it launches them. If it isn’t supposed to do this then perhaps just solving this issue makes the rest go away. Garth On Oct 4, 2014, at 6:17 AM, Wayne Stambaugh stambau...@verizon.net wrote: On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote: Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. KiCad no longer launches executables that run in a separate process. Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually child windows of the KiCad application. Eeschema, Pcbnew, etc. are also a stand alone programs but they don't get called from KiCad any longer. Some users prefer to run the individual applications this way so it would be nice if we could provide a separate icon and shortcut (or whatever it's called on OSX) so that the stand alone applications could be launched. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the sub-application, leaving you with a KiCad application menu as it switched back the the main app. Not really a huge issue but is can be confusing and if you’re not paying attention you can accidentally quit your main app. Not cool. The additional things I’m seeing with the new bundling is that now the applications the previously did launch as separate applications, even when launched from the main app, now have no icon of their own. They get the icon of the main kicad.app. So if I launch, say, gerbview and pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which one belongs to which application. I have to play icon roulette to find out. With the new CMakeLists.txt changes for these applications it seems there’s no way to go back to building individual application bundles for them without hacking and slashing. Any chance we can get back the ability to make bundles for these? I’d go so far as to recommend that the bundles be included wholesale in an Applications directory int the main bundle, but I’d at least like the option of building them as bundles separately. Thanks in advance, Garth___ 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 ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ 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] A few issues with new OS X bundles
Yes, but some of the problems seem to be no OSX specific issues. E.g. pl_editor is run this way (kicad/mainframe.cpp): Execute( this, PL_EDITOR_EXE ); while eeschema/pcbnew related things are run this way: KIWAY_PLAYER* frame = Kiway.Player( FRAME_PCB, true ); I don’t know if it is done like this on purpose, or if it just has been missed when introducing the kiface modularization. The other question is why gerbview or pl_editor do have a kiface, but bitmap2component doesn’t (IMHO all of them don’t have a relation to a single project like maybe eeschema or pcbnew have). Although I am also pretty emotionless about which way to go, for my taste the one single bundle fits better the modular idea of the kifaces (given that it is done consistently for all applications). There is one thing that also makes things a bit complicated when doing it the individual apps way: The usual wxWidgets ::GetDataDir(), etc. methods return something like ~/Library/Application Support/appname. So, if you start pcbnew via KiCad launcher it will point to ~/Library/Application Support/kicad, but if you start it via its own bundle it will point to ~/Library/Application Support/pcbnew. Some new code would have to be added so that everything is found consistently independent from how you launch, e.g., pcbnew. If have seen this being a problem at least on OSX, according to the wxWidgets docs for ::GetUserDataDir() it should/could be the same problem on other OSes: Unix: ~/.appinfo Windows: C:\Documents and Settings\username\Application Data\appinfo Mac: ~/Library/Application Support/appinfo Regards, Bernhard On 04.10.2014, at 19:21, Garth Corral gcor...@abode.com wrote: I’m afraid that’s not true in this case. It does launch separate processes for some some of the applications, gerbview for instance. They show up in ps and as Bernhard pointed out, the launcher even shows you the pid when it launches them. If it isn’t supposed to do this then perhaps just solving this issue makes the rest go away. Garth On Oct 4, 2014, at 6:17 AM, Wayne Stambaugh stambau...@verizon.net wrote: On 10/4/2014 4:26 AM, Bernhard Stegmaier wrote: Hi, most of your observations are as far as I can see not a problem of the bundles itself, but of the KiCad modular concept (kiface). When you launch pcbnew et al. from KiCad launcher the correct “application” is only loaded as a module, so the main application is still kicad launcher and I guess that’s why you for example see the same name, they do not have their own icon, etc. KiCad no longer launches executables that run in a separate process. Since the kiway work was completed, Eeschema, Pcbnew, etc. are actually child windows of the KiCad application. Eeschema, Pcbnew, etc. are also a stand alone programs but they don't get called from KiCad any longer. Some users prefer to run the individual applications this way so it would be nice if we could provide a separate icon and shortcut (or whatever it's called on OSX) so that the stand alone applications could be launched. For the “dock roulette” there is possibly a way to set the application icon of window dynamically using wxWidgets. Something to try… I guess behavior is the same on Linux/Windows, so the might als benefit. Regards, Bernhard On 04.10.2014, at 09:30, Garth Corral gcor...@abode.com wrote: Hi all, I finally had a chance to build and try out the new all-inclusive OS X application bundles and I’ve encountered a couple of issues that tend to reduce the usability a bit for me. First, an observation unrelated to the new bundles. I noticed with mainline builds on OS X, some of the subsidiary applications, specifically eeshcema and pcbnew, no longer have their own name in the application menu. Instead they have the name of the main application, KiCad. This is fine and I assumed it’s part of an effort to improve integration between the applications. On OS X, though, it’s a bit weird because the application menu still has an entry to “Quit pcbnew” and selecting that or Cmd-Q will indeed quit the sub-application, leaving you with a KiCad application menu as it switched back the the main app. Not really a huge issue but is can be confusing and if you’re not paying attention you can accidentally quit your main app. Not cool. The additional things I’m seeing with the new bundling is that now the applications the previously did launch as separate applications, even when launched from the main app, now have no icon of their own. They get the icon of the main kicad.app. So if I launch, say, gerbview and pcb_calculator, I’ve now got three KiCad icons in my dock with no idea which one belongs to which application. I have to play icon roulette to find out. With the new CMakeLists.txt changes for these applications it seems there’s no way to go back to building individual application bundles for them without
Re: [Kicad-developers] A few issues with new OS X bundles
Hi, Bernhard I think that the direction you are heading with the single application bundle is the right one. I think a single draggable application install will be a huge win for OS X users compared to the way it was before. It seems like you are almost there, but just a couple somewhat minor issues that might be confusing to Mac users. If what Wayne says it true, and these are not supposed to launch the way they do, then perhaps this can be dealt with outside of bundling and you’re done. As for whether users want to be able to launch the other applications separately, I can’t really say. I used to, but eventually just got into the habit of using the launcher; a bit more convenient. What about a hybrid of 1 and 2b? For each bundle that launches a separate process (and only those), create a bundle for that application and set up the main kicad bundle something like this: /kicad.app Contents Applications gerbview.app pcb_calculator.app etc. MacOS kicad pcbnew eeschema *.kiface Frameworks etc. Then put just a single set of libraries in the Frameworks directory of the top-level bundle and use install_name_tool to fix up the binaries to point to those as you allude to in 2b. That would mean the the kicad.app application bundle would be relocatable to anywhere, but the sub applications would not be relocatable outside the main bundle. Of course this would not solve the *.kiface issue that you mentioned. The symlink thing sort of offends me, too, but hopefully it would just be temporary, and the sub-applications wouldn’t be relocatable outside the bundle anyway. Then as each application is ‘fixed’, it’s bundle could be removed and it gets migrated to MacOS as now. As a side effect, these sub-applications would not be visible to to users unless they went out of their way to find them. This could be good or bad depending on your perspective. To me it’s good. It signals the intention that they will not be separate applications in the future, but allows them to behave correctly from within the main app. It also eliminates the common folder in the dock. This sort of thing is not unprecedented. Apple does it with some of their own applications. For instance: $ ls -1 /Applications/Server.app/Contents Applications Frameworks Info.plist Library MacOS PkgInfo PlugIns Resources They also do this in Xcode, but that’s probably not an example you’d want to show anyone. :-) I currently have a bundle that I built using your new build changes, but I repackaged it to put the libraries in a Frameworks directory within the bundle and also compiled with scripting support on and put the python site-packages in there as well (don’t really know where these belong). I also moved the command line utilities out to SharedSupport/bin. It all works fairly well but still has the issues I mentioned in my original message on the topic. On Oct 4, 2014, at 6:56 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: There are 2 possibilities as far as I can see: (1) One single application bundle - like it is now. There are probably still some cosmetic issues as Garth told, but I think these are just minor inconsistencies that could be sorted out. From an efficiency point of view it is no difference… 2 clicks this way to start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the same for the “old” approach (one click to open KiCad folder, second to start pcbnew). Positive: No space wasted Positive: No dependency problems, it just is self-contained and completely relocatable Negative: May break with users habits (Apple does this all the time, so nothing new for OSX users… :) ) (2) A KiCad-fodler with one application bundle per “executable” - from a users point of view how it was before. Again, two options: (2a) Self-contained bundles You have to pull every dependency into every bundle. Especially, you also have to duplicate all the *.kifaces into the kicad bundle for the launcher (and maybe also into other bundles e.g. if you want/could launch pcbnew from eeschema - don’t know if that is possible). If you don’t do it like that (as it was before using symlinks between bundles), it looks like it is a normal OSX application you can move around where you want, but actually you can’t because you break inter-bundle dependencies. Maybe it is not a regular use-case to pull e.g. pcbnew out of the KiCad folder, but nobody forbids that… so maybe someone likes to drag pcbnew to his desktop because then it’s only one click to start... Positive: Everything is individually self-contained Negative: Space wasted for duplicating things - especially pcbnew with scripting pulls in all the wxPython stuff that will be contained at least twice then... (2b) App-Folder +
Re: [Kicad-developers] A few issues with new OS X bundles
Hi, yes, could be easy to do this way. Let’s see what Wayne thinks about different execution of pcbnew/eeschema vs. the other applications, then we will see how to proceed. I’m almost done with adapting scripting stuff in CMake and also found a way without explicit usage of install_name_tool to put dylibs into Framework. Regards, Bernhard On 04.10.2014, at 20:31, Garth Corral gcor...@abode.com wrote: Hi, Bernhard I think that the direction you are heading with the single application bundle is the right one. I think a single draggable application install will be a huge win for OS X users compared to the way it was before. It seems like you are almost there, but just a couple somewhat minor issues that might be confusing to Mac users. If what Wayne says it true, and these are not supposed to launch the way they do, then perhaps this can be dealt with outside of bundling and you’re done. As for whether users want to be able to launch the other applications separately, I can’t really say. I used to, but eventually just got into the habit of using the launcher; a bit more convenient. What about a hybrid of 1 and 2b? For each bundle that launches a separate process (and only those), create a bundle for that application and set up the main kicad bundle something like this: /kicad.app Contents Applications gerbview.app pcb_calculator.app etc. MacOS kicad pcbnew eeschema *.kiface Frameworks etc. Then put just a single set of libraries in the Frameworks directory of the top-level bundle and use install_name_tool to fix up the binaries to point to those as you allude to in 2b. That would mean the the kicad.app application bundle would be relocatable to anywhere, but the sub applications would not be relocatable outside the main bundle. Of course this would not solve the *.kiface issue that you mentioned. The symlink thing sort of offends me, too, but hopefully it would just be temporary, and the sub-applications wouldn’t be relocatable outside the bundle anyway. Then as each application is ‘fixed’, it’s bundle could be removed and it gets migrated to MacOS as now. As a side effect, these sub-applications would not be visible to to users unless they went out of their way to find them. This could be good or bad depending on your perspective. To me it’s good. It signals the intention that they will not be separate applications in the future, but allows them to behave correctly from within the main app. It also eliminates the common folder in the dock. This sort of thing is not unprecedented. Apple does it with some of their own applications. For instance: $ ls -1 /Applications/Server.app/Contents Applications Frameworks Info.plist Library MacOS PkgInfo PlugIns Resources They also do this in Xcode, but that’s probably not an example you’d want to show anyone. :-) I currently have a bundle that I built using your new build changes, but I repackaged it to put the libraries in a Frameworks directory within the bundle and also compiled with scripting support on and put the python site-packages in there as well (don’t really know where these belong). I also moved the command line utilities out to SharedSupport/bin. It all works fairly well but still has the issues I mentioned in my original message on the topic. On Oct 4, 2014, at 6:56 AM, Bernhard Stegmaier stegma...@sw-systems.de wrote: There are 2 possibilities as far as I can see: (1) One single application bundle - like it is now. There are probably still some cosmetic issues as Garth told, but I think these are just minor inconsistencies that could be sorted out. From an efficiency point of view it is no difference… 2 clicks this way to start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the same for the “old” approach (one click to open KiCad folder, second to start pcbnew). Positive: No space wasted Positive: No dependency problems, it just is self-contained and completely relocatable Negative: May break with users habits (Apple does this all the time, so nothing new for OSX users… :) ) (2) A KiCad-fodler with one application bundle per “executable” - from a users point of view how it was before. Again, two options: (2a) Self-contained bundles You have to pull every dependency into every bundle. Especially, you also have to duplicate all the *.kifaces into the kicad bundle for the launcher (and maybe also into other bundles e.g. if you want/could launch pcbnew from eeschema - don’t know if that is possible). If you don’t do it like that (as it was before using symlinks between bundles), it looks like it is a normal OSX application you can move around where you want, but actually you
Re: [Kicad-developers] A few issues with new OS X bundles
Anything launched by calling Execute() is a separate executable and will run in a separate process. I thought KiPlayer() runs in the same process as kicad but I could be wrong. It makes sense that pl_editor and GerbView are stand alone since they don't make sense in relation to a project. I still think the single application bundle makes the most sense. It would be nice to figure out a way to make it play nice with the OSX launcher. Maybe it's a matter of figuring out the correct magic incantation in Info.plist to make it happen. On 10/4/2014 2:44 PM, Bernhard Stegmaier wrote: Hi, yes, could be easy to do this way. Let’s see what Wayne thinks about different execution of pcbnew/eeschema vs. the other applications, then we will see how to proceed. I’m almost done with adapting scripting stuff in CMake and also found a way without explicit usage of install_name_tool to put dylibs into Framework. Regards, Bernhard On 04.10.2014, at 20:31, Garth Corral gcor...@abode.com mailto:gcor...@abode.com wrote: Hi, Bernhard I think that the direction you are heading with the single application bundle is the right one. I think a single draggable application install will be a huge win for OS X users compared to the way it was before. It seems like you are almost there, but just a couple somewhat minor issues that might be confusing to Mac users. If what Wayne says it true, and these are not supposed to launch the way they do, then perhaps this can be dealt with outside of bundling and you’re done. As for whether users want to be able to launch the other applications separately, I can’t really say. I used to, but eventually just got into the habit of using the launcher; a bit more convenient. What about a hybrid of 1 and 2b? For each bundle that launches a separate process (and only those), create a bundle for that application and set up the main kicad bundle something like this: /kicad.app Contents Applications gerbview.app pcb_calculator.app etc. MacOS kicad pcbnew eeschema *.kiface Frameworks etc. Then put just a single set of libraries in the Frameworks directory of the top-level bundle and use install_name_tool to fix up the binaries to point to those as you allude to in 2b. That would mean the the kicad.app application bundle would be relocatable to anywhere, but the sub applications would not be relocatable outside the main bundle. Of course this would not solve the *.kiface issue that you mentioned. The symlink thing sort of offends me, too, but hopefully it would just be temporary, and the sub-applications wouldn’t be relocatable outside the bundle anyway. Then as each application is ‘fixed’, it’s bundle could be removed and it gets migrated to MacOS as now. As a side effect, these sub-applications would not be visible to to users unless they went out of their way to find them. This could be good or bad depending on your perspective. To me it’s good. It signals the intention that they will not be separate applications in the future, but allows them to behave correctly from within the main app. It also eliminates the common folder in the dock. This sort of thing is not unprecedented. Apple does it with some of their own applications. For instance: $ ls -1 /Applications/Server.app/Contents Applications Frameworks Info.plist Library MacOS PkgInfo PlugIns Resources They also do this in Xcode, but that’s probably not an example you’d want to show anyone. :-) I currently have a bundle that I built using your new build changes, but I repackaged it to put the libraries in a Frameworks directory within the bundle and also compiled with scripting support on and put the python site-packages in there as well (don’t really know where these belong). I also moved the command line utilities out to SharedSupport/bin. It all works fairly well but still has the issues I mentioned in my original message on the topic. On Oct 4, 2014, at 6:56 AM, Bernhard Stegmaier stegma...@sw-systems.de mailto:stegma...@sw-systems.de wrote: There are 2 possibilities as far as I can see: *(1) One single application bundle - like it is now.* There are probably still some cosmetic issues as Garth told, but I think these are just minor inconsistencies that could be sorted out. From an efficiency point of view it is no difference… 2 clicks this way to start e.g. pcbnew (first click opens kicad launcher, second pcbnew), the same for the “old” approach (one click to open KiCad folder, second to start pcbnew). Positive: No space wasted Positive: No dependency problems, it just is self-contained and completely relocatable Negative: May break with users habits (Apple does this all the time, so nothing new for OSX users… :) ) *(2) A
[Kicad-developers] Finally!
After years of struggling to get KiCad to build with the wxPython scripting enabled with mingw on Windows, I've finally managed to pull it off. Take a look at the attached screenshot. You'll notice that all of the major KiCad features are enabled. This is due in large part to the excellent work of the msys2 project. I still have to send them a patch for their package of Boost 1.56 (thanks Tom) and then all of the dependencies are already packaged. No more building dependencies from source on mingw, yeah!!! They all ready have a skeleton package set up for kicad so it shouldn't take long to a have a packaged version of a fully functional build of KiCad for windows. Once this is in place, it should be fairly easy for someone to create an autobuilder to provide up to date mingw64 and mingw32 packages for testing. It should be possible to roll up all of the dependencies and create a windows installer as well. This would greatly aid in testing. On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. 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] A few issues with new OS X bundles
On 10/4/2014 4:57 PM, Bernhard Stegmaier wrote: Then we should go the way Garth proposed using bundles in bundles (yes, even Xcode does it this way, I was not aware of doing it this way). Inside the single app bundle everything is kept as a single copy, default is the kicad launcher. Individual app bundles for everything are created inside the main bundle. If somebody likes to use an application directly he can do some links on his own (links could even be already done in the .dmg - you could choose to only copy kicad bundle or the whole folder as you wish). The only thing to take care then is the path stuff I mentioned below, but it shouldn’t be that hard to map every path ending with something other than “kicad” to kicad to always use the same configurations. I’ll finish current things, then I will adapt things this way if there are no objections. Regards, Bernhard On 04.10.2014, at 22:37, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: Anything launched by calling Execute() is a separate executable and will run in a separate process. I thought KiPlayer() runs in the same process as kicad but I could be wrong. It makes sense that pl_editor and GerbView are stand alone since they don't make sense in relation to a project. I still think the single application bundle makes the most sense. It would be nice to figure out a way to make it play nice with the OSX launcher. Maybe it's a matter of figuring out the correct magic incantation in Info.plist to make it happen. On 10/4/2014 2:44 PM, Bernhard Stegmaier wrote: Hi, yes, could be easy to do this way. Let’s see what Wayne thinks about different execution of pcbnew/eeschema vs. the other applications, then we will see how to proceed. I’m almost done with adapting scripting stuff in CMake and also found a way without explicit usage of install_name_tool to put dylibs into Framework. Regards, Bernhard On 04.10.2014, at 20:31, Garth Corral gcor...@abode.com mailto:gcor...@abode.com mailto:gcor...@abode.com wrote: Hi, Bernhard I think that the direction you are heading with the single application bundle is the right one. I think a single draggable application install will be a huge win for OS X users compared to the way it was before. It seems like you are almost there, but just a couple somewhat minor issues that might be confusing to Mac users. If what Wayne says it true, and these are not supposed to launch the way they do, then perhaps this can be dealt with outside of bundling and you’re done. As for whether users want to be able to launch the other applications separately, I can’t really say. I used to, but eventually just got into the habit of using the launcher; a bit more convenient. What about a hybrid of 1 and 2b? For each bundle that launches a separate process (and only those), create a bundle for that application and set up the main kicad bundle something like this: /kicad.app Contents Applications gerbview.app pcb_calculator.app etc. MacOS kicad pcbnew eeschema *.kiface Frameworks etc. Then put just a single set of libraries in the Frameworks directory of the top-level bundle and use install_name_tool to fix up the binaries to point to those as you allude to in 2b. That would mean the the kicad.app application bundle would be relocatable to anywhere, but the sub applications would not be relocatable outside the main bundle. Of course this would not solve the *.kiface issue that you mentioned. The symlink thing sort of offends me, too, but hopefully it would just be temporary, and the sub-applications wouldn’t be relocatable outside the bundle anyway. Then as each application is ‘fixed’, it’s bundle could be removed and it gets migrated to MacOS as now. As a side effect, these sub-applications would not be visible to to users unless they went out of their way to find them. This could be good or bad depending on your perspective. To me it’s good. It signals the intention that they will not be separate applications in the future, but allows them to behave correctly from within the main app. It also eliminates the common folder in the dock. This sort of thing is not unprecedented. Apple does it with some of their own applications. For instance: $ ls -1 /Applications/Server.app/Contents Applications Frameworks Info.plist Library MacOS PkgInfo PlugIns Resources They also do this in Xcode, but that’s probably not an example you’d want to show anyone. :-) I currently have a bundle that I built using your new build changes, but I repackaged it to put the libraries in a Frameworks directory within the bundle and also compiled with scripting support on and put the python site-packages in there as well (don’t really
Re: [Kicad-developers] A few issues with new OS X bundles
Oops. Fat finger a send on that last reply :). Thank you for taking care of this Bernhard and thank you Garth for the input. Send me the patch when it is ready. Cheers, Wayne On 10/4/2014 4:57 PM, Bernhard Stegmaier wrote: Then we should go the way Garth proposed using bundles in bundles (yes, even Xcode does it this way, I was not aware of doing it this way). Inside the single app bundle everything is kept as a single copy, default is the kicad launcher. Individual app bundles for everything are created inside the main bundle. If somebody likes to use an application directly he can do some links on his own (links could even be already done in the .dmg - you could choose to only copy kicad bundle or the whole folder as you wish). The only thing to take care then is the path stuff I mentioned below, but it shouldn’t be that hard to map every path ending with something other than “kicad” to kicad to always use the same configurations. I’ll finish current things, then I will adapt things this way if there are no objections. Regards, Bernhard On 04.10.2014, at 22:37, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: Anything launched by calling Execute() is a separate executable and will run in a separate process. I thought KiPlayer() runs in the same process as kicad but I could be wrong. It makes sense that pl_editor and GerbView are stand alone since they don't make sense in relation to a project. I still think the single application bundle makes the most sense. It would be nice to figure out a way to make it play nice with the OSX launcher. Maybe it's a matter of figuring out the correct magic incantation in Info.plist to make it happen. On 10/4/2014 2:44 PM, Bernhard Stegmaier wrote: Hi, yes, could be easy to do this way. Let’s see what Wayne thinks about different execution of pcbnew/eeschema vs. the other applications, then we will see how to proceed. I’m almost done with adapting scripting stuff in CMake and also found a way without explicit usage of install_name_tool to put dylibs into Framework. Regards, Bernhard On 04.10.2014, at 20:31, Garth Corral gcor...@abode.com mailto:gcor...@abode.com mailto:gcor...@abode.com wrote: Hi, Bernhard I think that the direction you are heading with the single application bundle is the right one. I think a single draggable application install will be a huge win for OS X users compared to the way it was before. It seems like you are almost there, but just a couple somewhat minor issues that might be confusing to Mac users. If what Wayne says it true, and these are not supposed to launch the way they do, then perhaps this can be dealt with outside of bundling and you’re done. As for whether users want to be able to launch the other applications separately, I can’t really say. I used to, but eventually just got into the habit of using the launcher; a bit more convenient. What about a hybrid of 1 and 2b? For each bundle that launches a separate process (and only those), create a bundle for that application and set up the main kicad bundle something like this: /kicad.app Contents Applications gerbview.app pcb_calculator.app etc. MacOS kicad pcbnew eeschema *.kiface Frameworks etc. Then put just a single set of libraries in the Frameworks directory of the top-level bundle and use install_name_tool to fix up the binaries to point to those as you allude to in 2b. That would mean the the kicad.app application bundle would be relocatable to anywhere, but the sub applications would not be relocatable outside the main bundle. Of course this would not solve the *.kiface issue that you mentioned. The symlink thing sort of offends me, too, but hopefully it would just be temporary, and the sub-applications wouldn’t be relocatable outside the bundle anyway. Then as each application is ‘fixed’, it’s bundle could be removed and it gets migrated to MacOS as now. As a side effect, these sub-applications would not be visible to to users unless they went out of their way to find them. This could be good or bad depending on your perspective. To me it’s good. It signals the intention that they will not be separate applications in the future, but allows them to behave correctly from within the main app. It also eliminates the common folder in the dock. This sort of thing is not unprecedented. Apple does it with some of their own applications. For instance: $ ls -1 /Applications/Server.app/Contents Applications Frameworks Info.plist Library MacOS PkgInfo PlugIns Resources They also do this in Xcode, but that’s probably not an example you’d want to show anyone. :-) I currently have a bundle that I built using your new build changes, but I
Re: [Kicad-developers] Finally!
On 5 October 2014 10:09, Wayne Stambaugh stambau...@verizon.net wrote: On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Hi Wayne, Not being a Windows user I can't speculate as to the need for the customisation, but CMakeModules/FindPythonInterp.cmake and CMakeModules/FindPythonLibs.cmake were added by Brian Sidebotham in rev 4268 [1] and haven't been changed since [2]. It might be that the stock file which ships with newer versions of CMake has been improved so that the custom one isn't needed anymore. Nice work getting this working. Blair [1] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4268 [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes?filter_file_id=findpythonlibs.cmake-20130804200613-h34h9txoq48ewiaw-4 ___ 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] Finally!
The MSYS2 file layout is configured very much like Linux so that is probably why the stock version worked. The if(MINGW) code in our custom version broke finding the include file path. The MSYS2 version of cmake is 3.0.2 so they are keeping things up to date. On 10/4/2014 5:23 PM, Adam Wolf wrote: With regards to Linux, my FindPythonLibs changes have been accepted into Cmake proper for a while, and the official bug was marked resolved last week, so I don't think there's any necessity for a custom module for Linux anymore. Adam Wolf On Oct 4, 2014 4:10 PM, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: After years of struggling to get KiCad to build with the wxPython scripting enabled with mingw on Windows, I've finally managed to pull it off. Take a look at the attached screenshot. You'll notice that all of the major KiCad features are enabled. This is due in large part to the excellent work of the msys2 project. I still have to send them a patch for their package of Boost 1.56 (thanks Tom) and then all of the dependencies are already packaged. No more building dependencies from source on mingw, yeah!!! They all ready have a skeleton package set up for kicad so it shouldn't take long to a have a packaged version of a fully functional build of KiCad for windows. Once this is in place, it should be fairly easy for someone to create an autobuilder to provide up to date mingw64 and mingw32 packages for testing. It should be possible to roll up all of the dependencies and create a windows installer as well. This would greatly aid in testing. On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto: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] Finally!
Thanks for the input. I give Brian and chance to reply. It may have been something just for the kicad-winbuilder so I may have to find an alternate solution that works in both cases. On 10/4/2014 6:21 PM, Blair Bonnett wrote: On 5 October 2014 10:09, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Hi Wayne, Not being a Windows user I can't speculate as to the need for the customisation, but CMakeModules/FindPythonInterp.cmake and CMakeModules/FindPythonLibs.cmake were added by Brian Sidebotham in rev 4268 [1] and haven't been changed since [2]. It might be that the stock file which ships with newer versions of CMake has been improved so that the custom one isn't needed anymore. Nice work getting this working. Blair [1] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4268 [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes?filter_file_id=findpythonlibs.cmake-20130804200613-h34h9txoq48ewiaw-4 ___ 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] Finally!
Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. I'm away from my keyboard at the moment so I'll have a look at this tomorrow when I'm back at the keyboard. Best Regards, Brian. On 4 Oct 2014 23:32, Wayne Stambaugh stambau...@verizon.net wrote: Thanks for the input. I give Brian and chance to reply. It may have been something just for the kicad-winbuilder so I may have to find an alternate solution that works in both cases. On 10/4/2014 6:21 PM, Blair Bonnett wrote: On 5 October 2014 10:09, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Hi Wayne, Not being a Windows user I can't speculate as to the need for the customisation, but CMakeModules/FindPythonInterp.cmake and CMakeModules/FindPythonLibs.cmake were added by Brian Sidebotham in rev 4268 [1] and haven't been changed since [2]. It might be that the stock file which ships with newer versions of CMake has been improved so that the custom one isn't needed anymore. Nice work getting this working. Blair [1] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4268 [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes?filter_file_id=findpythonlibs.cmake-20130804200613-h34h9txoq48ewiaw-4 ___ 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] Macro expansion in module text
Hi Lorenzo, Thanks for sorting this out, it'll make a great difference for my next board! Best Regards, Brian. On 4 Oct 2014 16:26, Lorenzo Marcantonio l.marcanto...@logossrl.com wrote: Sorry about the delay, we had the automechanika fair and related stuff to handle :P In fact the patch is quite simple (I already did the biggest changes...) It handles % sequences in user text primitives inside modules (usefulness already debated); now it recognizes: %% for a plain % %R inserts the reference %V inserts the value Obviously it can be extended to insert other stuff (has to be available from the module class, however). The only issue is repainting, since it insert a dependency between unrelated fields: when you change reference or value the user fields using them are not updated until the next redraw. Shouldn't be a big problem, however. Extensive testing is, as usual, appreciated. Have fun -- Lorenzo Marcantonio Logos Srl ___ 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] Finally!
Here is a another teaser of the mingw64 version of kicad showing the wxPython shell so it appears to be working. On 10/4/2014 5:09 PM, Wayne Stambaugh wrote: After years of struggling to get KiCad to build with the wxPython scripting enabled with mingw on Windows, I've finally managed to pull it off. Take a look at the attached screenshot. You'll notice that all of the major KiCad features are enabled. This is due in large part to the excellent work of the msys2 project. I still have to send them a patch for their package of Boost 1.56 (thanks Tom) and then all of the dependencies are already packaged. No more building dependencies from source on mingw, yeah!!! They all ready have a skeleton package set up for kicad so it shouldn't take long to a have a packaged version of a fully functional build of KiCad for windows. Once this is in place, it should be fairly easy for someone to create an autobuilder to provide up to date mingw64 and mingw32 packages for testing. It should be possible to roll up all of the dependencies and create a windows installer as well. This would greatly aid in testing. On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. 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] Finally!
No hurry. Let me know when you have it sorted out. Please send me a patch so I can verify it on msys2. Thanks, Wayne On 10/4/2014 7:12 PM, Brian Sidebotham wrote: Hi Wayne, I can't check right now, but I'm sure it is to find python-a-mingw-us for kicad-winbuilder. I expect the answer is to remove the custom findpython cmake module and replace it with a findpythonamingwus module instead. Please let me introduce the latter before we remove the former; Sorry it caused you grief. I'm away from my keyboard at the moment so I'll have a look at this tomorrow when I'm back at the keyboard. Best Regards, Brian. On 4 Oct 2014 23:32, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: Thanks for the input. I give Brian and chance to reply. It may have been something just for the kicad-winbuilder so I may have to find an alternate solution that works in both cases. On 10/4/2014 6:21 PM, Blair Bonnett wrote: On 5 October 2014 10:09, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net mailto:stambau...@verizon.net mailto:stambau...@verizon.net wrote: On that note, I had to remove our custom FindPythonLib.cmake in order to get it to work properly. There are some questionable if( MINGW ) blocks in our custom version that don't make sense to me. Would who ever modified the stock CMake version and added to our source please let me know why these changes are necessary so I can figure out a solution. If I don't hear from you over the next few days, I'm removing our custom version of FindPythonLib.cmake. Hi Wayne, Not being a Windows user I can't speculate as to the need for the customisation, but CMakeModules/FindPythonInterp.cmake and CMakeModules/FindPythonLibs.cmake were added by Brian Sidebotham in rev 4268 [1] and haven't been changed since [2]. It might be that the stock file which ships with newer versions of CMake has been improved so that the custom one isn't needed anymore. Nice work getting this working. Blair [1] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/4268 [2] http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/changes?filter_file_id=findpythonlibs.cmake-20130804200613-h34h9txoq48ewiaw-4 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net mailto: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] VRML export.
On Sat, Oct 4, 2014 at 10:52 PM, Wayne Stambaugh stambau...@verizon.net wrote: On 10/3/2014 8:15 PM, Cirilo Bernardo wrote: On Sat, Oct 4, 2014 at 5:33 AM, Wayne Stambaugh stambau...@verizon.net mailto:stambau...@verizon.net wrote: I've been trying use Pcbnew the VRML export for a board a work and discovered some serious design issues with the way file names are manipulated which broke exporting the model files on windows. I fixed those and while digging around in the VRML export code, I noticed a few things that didn't make any sense to me. Why are only .x3d file names embedded inside the board VRML file and not .wrl files? Why are the .x3d file names embedded even when they are copied to the 3D model path? Why wouldn't you either embed all the footprint models in the board file or copy all of the footprint model files to the 3D model path? It seems to me it should be one or the other not both. The use relative paths in the board VRML file option does nothing as far as I can tell. I'm willing to fix this but we need to define what this behavior should be because what we have now is rather chaotic. My initial feeling is that the embedded code should be removed until we can embed all supported 3D model file formats. Anyone else have any thoughts on this? One more note. Please use wxFileName instead of wxString when manipulating file names and paths. I've probably fixed a dozen or so places over the years where this same wxString path manipulation code has been used and has caused nothing but grief. Please keep in mind that we are a cross platform application. If you need Posix path separators for saving paths and/or file name in files, use wxFileName::GetFullPath(wxPATH_UNIX). This will convert the separators from \ to / and still allow you to use native paths for file operations internally which is more reliable. Thanks, Wayne Hi Wayne, I'll find some time to have a look at the issues. I don't get what you mean by the x3d file names being embedded and not the wrl files. I always thought it was the other way around. The X3D model data is written to the output VRML file but the VRML data is retained as separate files and only the names are put into the output VRML file. Embedding the X3D model date assures VRML2 compatibility; a VRML2 browser will not necessarily be able to parse and display the contents of an x3d file. I didn't realize the x3d models were being copied to the path as well; that's just wrong. Cirilo, Please don't fix anything just yet until I commit my changes. Otherwise we will have clashes in the code. You may be correct about the x3d files but I don't have any of them to test the code. Looking at the code, the output of the x3d to vrml conversion is being added to the board vrml file not to a separate model file in the 3D model path which is where I would expect it to go. I also fixed a memory leak for every x3d parser that is created. If you happen to have an x3d model of a component, please send it to me so I can test/fix this code path. No problem, I'll wait until you've committed your changes. I'll keep people informed on any progress on my wishlist. Developments with STEP would be of particular interest to people and it's no small job so we definitely want to avoid duplication there. I'm currently looking into using 'StepCode' (formerly STEP Class Library) because I want a well structured assembly as an output. I've discarded OpenCascade since it cannot produce an assembly that I would ever care to work with in MCAD; pretty much every feature of every component is a 'part' in one big flat 'product' and no MCAD user wants to waste time with such a thing. - 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
[Kicad-developers] [RFC]: Make hotkey editor polished
Hi, I've been poking with KiCAD for awhile and decided to contribute. Using Bazaar was the first hurdle, thankfully I gave up and used the git bridge. I otherwise have no idea how development goes. I've always thought the hotkey editor was a bit unpolished so I'm submitting patches to make it pretty. Of course that is subjective but I recommend applying the patches to see the difference. Changes. 1. No longer open fixed at max screen height. You need to visually scan through the list of items to find what you want regardless, making it max height doesn't necessarily make this any easier than scrolling. Put action buttons at the bottom. Increase base width and height of window to compensate. Logic added to expand column headers automatically to match width of window. 2. Add logic to fix bug #706361. It will now ask if you want to reuse the key. The old assignment gets set to 0 which currently causes unknown to display but does disable the action. I don't see the harm in a hotkey action not being binded to anything since it's a users choice anyway. 3. Section headers are bolded to stand out 4. Selection cell, cursor hidery. This was annoying because wxGrid itself is annoying and lacking in options. So I disguised things properly that these unused features are never seen. 5. Add descriptive text to at least mention that right click gives you more options. Got to be a little newb friendly here as that isn't obvious to everyone. I've pushed my changes to https://code.launchpad.net/~mark-roszko/kicad/kicad -- Mark ___ 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
