If I remember correctly this should only be enabled when some external tool is in the right place? Don’t know if this works yet on OSX?
> On 22 Sep 2016, at 17:27, Simon Wells <[email protected]> wrote: > > i am sure i have done something stupid but for me the export->STEP > option is greyed out. any hints? > > On Fri, Sep 23, 2016 at 2:45 AM, Wayne Stambaugh <[email protected]> wrote: >> >> On 9/22/2016 10:43 AM, Wayne Stambaugh wrote: >>> Simon, >>> >>> Using .mb_str() is valid. Using static_cast is more c++ish. Take a >>> look at the "Conversion to C string" section of the wxString documentation: >> >> http://docs.wxwidgets.org/3.0/classwx_string.html >> >> I'm ok either way. >> >> Sorry about the fat fingered send. >> >> Wayne >> >>> >>> >>> On 9/22/2016 10:42 AM, Simon Wells wrote: >>>> Hey wayne, >>>> >>>> the commit broke my build... >>>> >>>> in kicad2step.cpp >>>> >>>> lines 61-81 have _( "BLAH BLAH") which errors out as not convertible >>>> from wxstring to char *. I have patched it with .mb_str() and was >>>> preparing a patch but i am not sure if this is the correct way, care >>>> to comment before i send a patch? >>>> >>>> thanks >>>> >>>> Simon >>>> >>>> On Fri, Sep 23, 2016 at 2:18 AM, Wayne Stambaugh <[email protected]> >>>> wrote: >>>>> On 9/21/2016 9:17 PM, Cirilo Bernardo wrote: >>>>>> On Thu, Sep 22, 2016 at 10:07 AM, Wayne Stambaugh <[email protected]> >>>>>> wrote: >>>>>>> On 9/21/2016 7:27 PM, Cirilo Bernardo wrote: >>>>>>>> OK, I've updated the branch with the following changes: >>>>>>>> >>>>>>>> 1. removed wxT() from kicad2step and dialogs. The remaining wxT() >>>>>>>> instances are created by wxFormBuilder. >>>>>>>> >>>>>>>> 2. refined the Export STEP GUI for cases in which the exporter >>>>>>>> fails (returns an error or segfaults). >>>>>>> >>>>>>> Thanks for the fixes. I got everything merged on my computer at work so >>>>>>> I'll just pick up where I left off tomorrow. >>>>>>> >>>>>> >>>>>> No problem; thanks for testing the branch. >>>>> >>>>> I tested this and everything looked fine. I did notice in your last >>>>> commit that you used stderr. I'm not sure that has any meaning on >>>>> windows but it didn't seem to break anything. I committed you kicad >>>>> step export branch to the product repo. Great job. Thanks. >>>>> >>>>> I do have one comment. The vrml exporter includes the silk screen and >>>>> traces which results in a much more detailed board model. It would be >>>>> nice if step export had this as well. >>>>> >>>>>> >>>>>>>> >>>>>>>> It also just occurred to me that sometimes the OCE library may >>>>>>>> cause a hang. I can work on a generic dialog to launch an >>>>>>>> external app which connects to the apps stdout + stderr and >>>>>>>> which has a CANCEL button to kill the process - any comments? >>>>>>>> Should I put such a dialog into the "common" library? >>>>>>> >>>>>>> I'm wondering if you could make something abstract enough to work in all >>>>>>> the places where we run external apps. These dialogs always seem pretty >>>>>>> task specific like the netlist and bom dialogs? You could try I guess. >>>>>>> >>>>>> >>>>>> The best abstraction I can think of at the moment is to instantiate a >>>>>> dialog >>>>>> which simply has a window showing the stderr + stdout of the running app >>>>>> and a cancel button to kill the process if necessary. All other >>>>>> customizations >>>>>> should be done in a parent window. I'll come up with something and apply >>>>>> it >>>>>> to the BOM and netlist generation as well. >>>>> >>>>> Given that we've never had any issues with the bom and netlist external >>>>> processes, it may not be worth the effort although I'm not opposed to >>>>> the idea. >>>>> >>>>>> >>>>>>>> >>>>>>>> The fact that a process using OCE can hang brings up the >>>>>>>> question of whether it is better to leave kicad2step as a >>>>>>>> separate app or whether it is generally OK as a plugin and >>>>>>>> the odd crash due to bugs in OCE and/or the STEP/IGES >>>>>>>> models would be acceptable. We can stuff the plugin >>>>>>>> invocations into their own thread and check for completion, >>>>>>>> but unlike the case with a separate process, we cannot >>>>>>>> guarantee there is no memory corruption or leakage. >>>>>>>> Any thoughts? >>>>>>> >>>>>>> Ughh! You're not making me feel any better about oce. It would be nice >>>>>>> to be able to kill a rouge process though. Doesn't the oce library api >>>>>>> provide some kind of error reporting capability? >>>>>>> >>>>>> >>>>>> OCE does have an error reporting scheme but I've seen it hang >>>>>> indefinitely while performing some operations such as shape healing >>>>>> on defective STEP models. In other instances it eventually stops >>>>>> after it has hogged the maximum memory that the system would >>>>>> give it. In both cases it's not possible to get error information from >>>>>> within OCE. Unfortunately such bad behavior is not unique to OCE; the >>>>>> MCAD world in particular seems to be full of buggy libraries, but to >>>>>> be fair the tasks involved are incredibly difficult and users no doubt >>>>>> are always coming up with cases that the developers hadn't checked for. >>>>> >>>>> Are we the only project that pushes these libraries that hard? We do >>>>> seem to find our fair share of library issues. >>>>> >>>>>> >>>>>>>> >>>>>>>> Somewhat off-topic: grep shows me that the source code >>>>>>>> and headers are full of wxT(). Since wxT() had been >>>>>>>> deprecated years ago and KiCad is no longer compatible >>>>>>>> with versions of wxWidgets which required wxT(), perhaps >>>>>>>> we should ask devs to purge wxT() from the headers and >>>>>>>> sources which they touch? I think that might also get devs >>>>>>>> into the habit of not using wxT() - even I still use it without >>>>>>>> realizing it - bad habits die hard. :) >>>>>>> >>>>>>> I caught myself using wxT() while writing the legacy schematic plugin >>>>>>> several times. It will take time to get used to it but we will get >>>>>>> there. If you happen to be working on a file, please feel free to >>>>>>> remove them. I don't think we need to do the mass purge just yet. >>>>>>> >>>>>> >>>>>> OK; I might create some patches for the bits I'd worked on in the >>>>>> past like VRML export and IDF export. >>>>> >>>>> For small change sets (<= 5 commits), please send me patch sets using >>>>> format-patch or send-email. It's easier than me having to add remotes >>>>> and go through the whole pull rebase cycle. >>>>> >>>>> Cheers, >>>>> >>>>> Wayne >>>>> >>>>>> >>>>>> - Cirilo >>>>>> >>>>>>>> >>>>>>>> - Cirilo >>>>>>>> >>>>>>>> On Thu, Sep 22, 2016 at 3:04 AM, Wayne Stambaugh >>>>>>>> <[email protected]> wrote: >>>>>>>>> Cirilo, >>>>>>>>> >>>>>>>>> I just tested this since you fixed the windows extension issue. The >>>>>>>>> menu item is enabled but I always get an "Unable to create step file >>>>>>>>> whenever there are spaces in the file name and/or path." You didn't >>>>>>>>> by >>>>>>>>> chance forget to double quote the command line string did you? If you >>>>>>>>> don't, spaces in file and/or path names in command strings will fail. >>>>>>>>> >>>>>>>>> Just a couple of quick comments nothing major. wxT() macros are no >>>>>>>>> longer required in wx3 so try to remember not to use it anymore since >>>>>>>>> it's slated to be deprecated in the future. It's also not necessary >>>>>>>>> to >>>>>>>>> convert path separators in strings when you are already using >>>>>>>>> wxFileName. You can use wxFileName::GetFullPath() which will return >>>>>>>>> the >>>>>>>>> native separators no matter what you feed it with. You can also >>>>>>>>> convert >>>>>>>>> to the unix file separator for storage by using >>>>>>>>> wxFileName::GetFullPath( >>>>>>>>> wxPATH_UNIX ). This removes the need for #ifdef WINDOWS/#endif to do >>>>>>>>> the separator conversion. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Wayne >>>>>>>>> >>>>>>>>> On 9/19/2016 3:53 AM, Nick Østergaard wrote: >>>>>>>>>> Looks good, I will test it soon. But I noticed that it looks like you >>>>>>>>>> did not use the copyright template copyright.h from the root of the >>>>>>>>>> source. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Den 19/09/2016 09.46 skrev "Cirilo Bernardo" >>>>>>>>>> <[email protected] >>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>> >>>>>>>>>> The kicad-step feature branch now implements a STEP Export. The >>>>>>>>>> menu >>>>>>>>>> item may need a new icon (I lazily reused the IDF icon). Any >>>>>>>>>> testing and >>>>>>>>>> comments would be appreciated. The kicad2step utility which >>>>>>>>>> performs >>>>>>>>>> the conversion is of course dependent on OCE and is only built >>>>>>>>>> when >>>>>>>>>> KICAD_USE_OCE is defined. The "Export STEP" menu item is disabled >>>>>>>>>> if the kicad2step executable is not found in the same directory >>>>>>>>>> as the >>>>>>>>>> pcbnew executable. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+ref/kicad-step >>>>>>>>>> >>>>>>>>>> <https://code.launchpad.net/~cirilo-bernardo/kicad/+git/kicad-oce/+ref/kicad-step> >>>>>>>>>> >>>>>>>>>> - Cirilo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>>>> Post to : [email protected] >>>>>>>>>> <mailto:[email protected]> >>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>> <https://launchpad.net/~kicad-developers> >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>> <https://help.launchpad.net/ListHelp> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>> Post to : [email protected] >>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>> Post to : [email protected] >>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>> >>>>> >>>>> _______________________________________________ >>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>> Post to : [email protected] >>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
