Re: [Kicad-developers] UI policy
I've been doing some research into other good UI guideline sets and may be able to compile some constructive input when you are ready. On Feb 8, 2017 08:51, "Wayne Stambaugh" wrote: > Oh my! That wont do. I'll have to remove that from the UI policy > document. Thanks for pointing it out. As for what to replace it with, > I have no idea. I don't want to have this conversation at the moment. > I don't have the time. At some point, we will have to revisit it. > > Cheers, > > Wayne > > On 2/7/2017 10:36 AM, Chris Pavlina wrote: > > Currently our UI policy says to follow the GNOME user interface > > guidelines. > > > > ...has anybody read the GNOME HIG lately? It's really different from > > anything we have now, and generally pretty controversial. I don't think > > it's what it was back when we decided to use it. Unless we really want > > to start making everything like [1]...does anyone think maybe we should > > look for a new set of interface guidelines? > > > > [1] https://developer.gnome.org/hig/stable/patterns.html.en > > > > ___ > > 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] Custom shaped pads work. third test. Need testers.
Can we PLEASE stop with the icons everywhere? KiCad is EDA software, not a picture book for small children. http://storage1.static.itmages.com/i/17/0208/h_1486578658_7723156_809a55d70d.png On Tue, Feb 07, 2017 at 06:22:48PM +0100, jp charras wrote: > I recently reworked on custom patches, and added a few missing features. > > I am expecting to be able to commit a first experimental version of custom > pads to the master branch. > > However, before committing, more tests are needed. > The attached patch is the third (and last) test. > > After applying this patch you have to compile with option: > -DKICAD_USE_CUSTOM_PADS=ON > to enable the custom pad settings in the pad settings dialog. > > Currently: > Plot and print are working. > the DRC dialog now supports the custom pads > On the legacy canvas, the DRC now supports the custom pads during track > creation > > What is missing? > P&S does not yet support custom pads (For that, I'll need help from P&S guys) > The Pad editor does not test the validity of the pad shape (the final shape > must be equivalent to > only one polygon, not more than one) > > What needs to be defined: > What info must be added to a custom pad. > What is the shape of the clearance are in zones (currently, this is the > convex hull which has some > advantages over the exact shape) > What about thermal relief (not sure a thermal relief has meaning for a custom > pad) > Is a custom pad allowed on all copper layers, or only one layer (top or > bottom) like a SMD pad > > > But before having answers to these questions, tests must be made with this > current patch. > > Thanks. > > -- > Jean-Pierre CHARRAS ___ 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] for comment: legacy canvas in V5 release
The EEVblog forum hates everything. On Feb 8, 2017 18:32, "Andy Peters" wrote: > On Feb 8, 2017, at 3:13 PM, Mário Luzeiro wrote: > > As a technical reference, > KiCad webpage [1] it sugests as requirements a GPU with OpenGL 2.1 (btw, in one line it suggests 2.1 on other two lines it suggests 2.0 ? ) > From wikipedia [2] this standard was release in July 2006, so on the expected next release, it will be 11 yrs old. > > I understand the use of KiCad of (very) old systems (eg: on tests lab or assembly site) but I think from my "computer technology perspective" view 11 yrs is old enough. > > So as I said before, my solution for this issue on a Linux machine with 11 yrs old is to buy a second hand ($15.. $30) NVidia ( GeForce 7 .. GeForce 8..) GPU card and install the proprietary NVidia drivers (on a recent light linux distro) There was someone on the EEVblog forums complaining that “The graphic driver in my computer has OpenGL 2.0, but KiCAD needs 2.1!!! Why???” I suppose that no matter where you draw the line, someone will bitch and moan. -a ___ 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] Fwd: KiCad (pay day?)
Awesome, thanks for sharing! It's always nice to hear such things. On Thu, Feb 09, 2017 at 07:50:36AM +0100, jp charras wrote: > > > > Message transféré > Sujet : KiCad > Date :Wed, 8 Feb 2017 18:00:48 + > De : James Falbo > Pour :jean-pierre.char...@gipsa-lab.inpg.fr > > > > > Dear Jean-Pierre, > > I want to thank you for your vision with KiCAD. You should be very proud of > the platform and tool it > has become. Electronics hobbyist finally have a free limitless package they > can use to layout their > own PCB -- of a variety of sizes and layers. I lead the Electronics Club at > the University of Akron > (in Akron, Ohio in the US) and I’m going to teach the engineering students > how to use your KiCAD to > make schematics and layout their own PCBs so they can become more hands on > engineering students. > I’m not sure what “Ki” stands for but it is a nice easy name to remember. I > suspect it’s an > abbreviation of a French word. > > > I especially appreciate how most options are shown on the side bars of the > KiCad screen. That makes > it easy. Last night I made my first schematic part (a microchip part) and got > a bit confused about > how to properly save it in a new library, but it all worked out. It was quite > easy to make the part! > > > Anyhow, I just wanted to say thank you from abroad and let you know that > hobbyist in Ohio are using > your software. You may not know this but Thomas Edison was born in Ohio, > about 1.5 hours west of > here. If he was living in modern times he too would be using your KiCad! > > > James Falbo > > Agratronix > > VP of Product Development > > Electronics Cub Mentor > > > > > ___ > 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] [PATCH] fix "opening view menu changes canvas" bug
Merged. Good catch, thank you.
On Fri, Feb 10, 2017 at 08:43:54PM +0100, Julius Schmidt wrote:
> The attached patch fixes a minor bug where opening the 'View' menu
> will sometimes revert the canvas to the default canvas. The problem is
> that wxMenuItem::Check will cause a menu event when the status is changed
> even if the checkmark is being *unset*. The workaround is to only call
> Check with a true argument. This works because the menu items are radio
> buttons.
>
> aiju
>
> ---
> pcbnew/basepcbframe.cpp | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/pcbnew/basepcbframe.cpp b/pcbnew/basepcbframe.cpp
> index 569c03f..a27d9f3 100644
> --- a/pcbnew/basepcbframe.cpp
> +++ b/pcbnew/basepcbframe.cpp
> @@ -1048,6 +1048,7 @@ void PCB_BASE_FRAME::OnUpdateSwitchCanvas(
> wxUpdateUIEvent& aEvent )
> for( auto ii: menuList )
> {
> wxMenuItem* item = menuBar->FindItem( ii.menuId );
> -item->Check( ii.galType == canvasType );
> +if( ii.galType == canvasType )
> +item->Check( true );
> }
> }
> --
> 2.1.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] I'm working on a nice thing
Okay, footprint part is going to take longer than the original forecast. Bit...tricky to get a footprint render from within eeschema. Suggestions welcome for the best way to do this, code structure-wise. kiway could do it if kiway could produce individual widgets instead of only entire standalone wxFrames, but I don't think it's capable of that. And the last thing I want to do is go digging around in kiway. On Mon, Feb 06, 2017 at 09:07:16PM -0500, Chris Pavlina wrote: > Preview at g...@github.com:cpavlina/kicad branch componentchooser. > Footprint part still pending. > > On Sun, Feb 05, 2017 at 09:52:03PM -0500, Chris Pavlina wrote: > > Still very early... I call it "componentchoosernew" > > > > https://misc.c4757p.com/componentchoosernew.png > > > > -- > > Chris ___ 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] I'm working on a nice thing
I haven't tried it in this context because I'm still trying to figure out the best way to satisfy its dependencies. From what I can see it depends on BOARD and MODULE, right? I need to use this from *eeschema*. On Fri, Feb 10, 2017 at 09:34:17PM +, Tomasz Wlostowski wrote: > Hi Chris, > > The code for FOOTPRINT_PREVIEW_PANEL I've sent you already does it (including > kiway stuff). Did you try it? > > Cheers, > Tom > > > > Sent from my Samsung Galaxy smartphone. > > > Original message > From: Chris Pavlina > Date: 10/02/2017 22:08 (GMT+01:00) > To: kicad-developers@lists.launchpad.net > Subject: Re: [Kicad-developers] I'm working on a nice thing > > Okay, footprint part is going to take longer than the original forecast. > Bit...tricky to get a footprint render from within eeschema. > > Suggestions welcome for the best way to do this, code structure-wise. > kiway could do it if kiway could produce individual widgets instead of > only entire standalone wxFrames, but I don't think it's capable of that. > And the last thing I want to do is go digging around in kiway. > > On Mon, Feb 06, 2017 at 09:07:16PM -0500, Chris Pavlina wrote: > > Preview at g...@github.com:cpavlina/kicad branch componentchooser. > > Footprint part still pending. > > > > On Sun, Feb 05, 2017 at 09:52:03PM -0500, Chris Pavlina wrote: > > > Still very early... I call it "componentchoosernew" > > > > > > https://misc.c4757p.com/componentchoosernew.png > > > > > > -- > > > Chris > > ___ > 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] {PATCH] Icon tweaks
Nice, subtle improvements. I'm in favor. On Sat, Feb 11, 2017 at 05:37:53AM +0800, John Beard wrote: > Hi, > > I have a few tweaks to some icons in Pcbnew and Eeschema. These are > mostly minor tweaks that are intended to make the icons match a little > better and give a more uniform look and feel: > > https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons > > * Pixel align a few icons to make then crisper when displayed > * Redraw all the zoom icons to be crisper and flatter. The zoom to fit > (Home) icon is now a sort of reticle rather than a pair of square > brackets as text. > * Redraw console icon to be flat to match other existing icons. > * Mute some very bright colours, especially the green-legged module > icons - use the zone icons as a guide for the colour brightness. > > Attached are screen shots of pcbnew and eeschema, where you can see > some of the icons. > > I know icons and UI subjects in general are very subjective and > personal, so I'd welcome input! > > Cheers, > > John ___ 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] I'm working on a nice thing
Ah, okay. Appears I have things to learn about kiface. Ps. It's not the worst thing in this thread. Perhaps I should retitle the thread the next time I post. >_> On Fri, Feb 10, 2017 at 09:48:55PM +, Tomasz Wlostowski wrote: > Sure, it depends on Board and Module classes but they are loaded dynamically > from pcbnew.kiface when the preview panel is created (thanks to kiway). > There's no link-time dependency. > > Tom > > Ps. Sorry for top posting. > > > > Sent from my Samsung Galaxy smartphone. > > > Original message > From: Chris Pavlina > Date: 10/02/2017 22:39 (GMT+01:00) > To: Tomasz Wlostowski > Cc: kicad-developers@lists.launchpad.net > Subject: Re: [Kicad-developers] I'm working on a nice thing > > I haven't tried it in this context because I'm still trying to figure > out the best way to satisfy its dependencies. From what I can see it > depends on BOARD and MODULE, right? I need to use this from *eeschema*. > > On Fri, Feb 10, 2017 at 09:34:17PM +, Tomasz Wlostowski wrote: > > Hi Chris, > > > > The code for FOOTPRINT_PREVIEW_PANEL I've sent you already does it > > (including kiway stuff). Did you try it? > > > > Cheers, > > Tom > > > > > > > > Sent from my Samsung Galaxy smartphone. > > > > > > Original message > > From: Chris Pavlina > > Date: 10/02/2017 22:08 (GMT+01:00) > > To: kicad-developers@lists.launchpad.net > > Subject: Re: [Kicad-developers] I'm working on a nice thing > > > > Okay, footprint part is going to take longer than the original forecast. > > Bit...tricky to get a footprint render from within eeschema. > > > > Suggestions welcome for the best way to do this, code structure-wise. > > kiway could do it if kiway could produce individual widgets instead of > > only entire standalone wxFrames, but I don't think it's capable of that. > > And the last thing I want to do is go digging around in kiway. > > > > On Mon, Feb 06, 2017 at 09:07:16PM -0500, Chris Pavlina wrote: > > > Preview at g...@github.com:cpavlina/kicad branch componentchooser. > > > Footprint part still pending. > > > > > > On Sun, Feb 05, 2017 at 09:52:03PM -0500, Chris Pavlina wrote: > > > > Still very early... I call it "componentchoosernew" > > > > > > > > https://misc.c4757p.com/componentchoosernew.png > > > > > > > > -- > > > > Chris > > > > ___ > > 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] Schematic I/O plugin.
To elaborate - I get that / is forbidden because part names will be file names in the new format, but this is going to break libraries. Manufs have used all kinds of horrid symbols in part numbers. Perhaps we should make the plugin system allow each plugin to specify its own valid characters? The legacy format has always allowed / so the legacy plugin should. On Fri, Feb 10, 2017 at 03:57:11PM -0600, José Ignacio wrote: > This broke all my designs with microchip parts (which have forward slashes > in the symbol names). Sadpanda.jpg > > On Fri, Feb 10, 2017 at 8:55 AM, Wayne Stambaugh > wrote: > > > I just pushed my changes to make the schematic I/O plugin the default > > for all schematic and symbol library I/O. This is a pretty significant > > change. I tested everything I could think of but there may be some > > corner cases that I missed. I also used LIB_ID instead of wxString to > > store symbol library lookup information. For now, it behaves the same > > way it always has. Please let me know if you find any issues and I will > > try to fix them as quickly as possible. KICAD_USE_SCH_IO_MANAGER is no > > longer a build option. > > > > I'm going to try to get the symbol library table implemented in the next > > week or so. This will likely be the last of the schematic I/O changes > > before the next stable release. I am going to push the new file formats > > to the stable 6 release due to the increasing amount of time I am > > spending doing project management stuff and the equally decreasing > > amount of time I have to code. Given that none of the new features > > provided by the new file formats would have been implemented for the > > stable 5 release, I don't think this is a major setback. This will give > > us some more time to further discuss the new file formats before I > > implement them. The new file formats will be my first task after the > > stable 5 release. > > > > Cheers, > > > > 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] Schematic I/O plugin.
I still don't understand why it's an issue. Why can't LIB_ID allow /? That should be forbidden at the level of the individual plugin which has to ensure the names are valid for the format being written. On Fri, Feb 10, 2017 at 06:37:26PM -0500, Wayne Stambaugh wrote: > This is a direct result of LIB_ID which has to be used for symbol > library mapping. I could silently force slashes to underscores or some > other valid file name character. I'm sure that is not going to make > folks happy but it will have to happen when we convert the legacy symbol > libraries to the new format. We went through the same issue when we > converted the footprint libraries as well. I'll see if I can come up > with a work around for the legacy parser but this is only temporary. > > Was it our microchip libs that are the problem or someone's custom lib? > If it's a custom lib, please attach the lib causing the issues so I can > debug it. > > On 2/10/2017 5:42 PM, Nick Østergaard wrote: > > I did notice that the new io manager thing broke some libs things > > related to the microchip libs, but it also found an error in the > > official libs that I patched. But then I forgot to report the other > > issues. > > > > But yeah, it seems strange that slash'es are not allowed in footprint > > property names. > > > > 2017-02-10 22:59 GMT+01:00 Chris Pavlina : > >> To elaborate - I get that / is forbidden because part names will be file > >> names in the new format, but this is going to break libraries. Manufs > >> have used all kinds of horrid symbols in part numbers. Perhaps we should > >> make the plugin system allow each plugin to specify its own valid > >> characters? The legacy format has always allowed / so the legacy plugin > >> should. > >> > >> On Fri, Feb 10, 2017 at 03:57:11PM -0600, José Ignacio wrote: > >>> This broke all my designs with microchip parts (which have forward slashes > >>> in the symbol names). Sadpanda.jpg > >>> > >>> On Fri, Feb 10, 2017 at 8:55 AM, Wayne Stambaugh > >>> wrote: > >>> > >>>> I just pushed my changes to make the schematic I/O plugin the default > >>>> for all schematic and symbol library I/O. This is a pretty significant > >>>> change. I tested everything I could think of but there may be some > >>>> corner cases that I missed. I also used LIB_ID instead of wxString to > >>>> store symbol library lookup information. For now, it behaves the same > >>>> way it always has. Please let me know if you find any issues and I will > >>>> try to fix them as quickly as possible. KICAD_USE_SCH_IO_MANAGER is no > >>>> longer a build option. > >>>> > >>>> I'm going to try to get the symbol library table implemented in the next > >>>> week or so. This will likely be the last of the schematic I/O changes > >>>> before the next stable release. I am going to push the new file formats > >>>> to the stable 6 release due to the increasing amount of time I am > >>>> spending doing project management stuff and the equally decreasing > >>>> amount of time I have to code. Given that none of the new features > >>>> provided by the new file formats would have been implemented for the > >>>> stable 5 release, I don't think this is a major setback. This will give > >>>> us some more time to further discuss the new file formats before I > >>>> implement them. The new file formats will be my first task after the > >>>> stable 5 release. > >>>> > >>>> Cheers, > >>>> > >>>> 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 > > > > ___ > > 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] Selection tool that selects components and local connections
Can you update this again? On Fri, Feb 10, 2017 at 01:45:10PM +0100, Kristoffer Ödmark wrote: > Updated the patch to fit on current master. > > > On 2017-02-08 21:14, Kristoffer Ödmark wrote: > >I tried reverting back to master and found the same strange bugs on > >windows, so i do not think my patch causes them. > > > >example of bug: > >https://snag.gy/EesP2n.jpg > > > >On 2017-02-08 19:17, Kristoffer Ödmark wrote: > >>Hello again! > >> > >>Since my groupselection required changes to the file format to be > >>useful. I have now created a selection tool that selects all footprints > >>belonging on the same sheet or "deeper". > >> > >>It also finds all nets that only have connections between components on > >>the same or deeper sheet and selects them. > >> > >>It gives some functionality of the group selection idea and does not > >>break file format or any previous workflow. > >> > >>Tested on linux, saw some strange right-click meny errors on windows, > >>but the functionality works there as well when using the shortcut key 'P' > >> > >>Attaching patch > >> > >>Video: > >>https://www.youtube.com/watch?v=DUskyc7t_HA&feature=youtu.be > >> > >>- Kristoffer > >> > >> ___ 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] {PATCH] Icon tweaks
You use way too many icons with identical silhouettes, which makes them very difficult to tell apart at a glance. And lose the pencils, they also don't add anything for quick recognition. On Sat, Feb 11, 2017 at 09:05:55AM +0200, Константин Барановский wrote: > I'm also working on new icons for a long time. You can find them in my > branch: > https://code.launchpad.net/~baranovskiykonstantin/kicad/+git/kicad > > > 2017-02-11 1:10 GMT+02:00 Ben Hest : > > > Not entirely sure which OS you are using, but LightShot [1] is fantastic > > at being able take pictures of menus on Windows. (It works on Mac also) > > > > [1] https://app.prntscr.com/en/index.html > > > > On Fri, Feb 10, 2017 at 3:55 PM, John Beard > > wrote: > > > >> And here are the same images with the changed icons highlighted, maybe > >> not everyone loves spot-the-difference puzzles that much! > >> > >> Some icons are hidden in menus which I don't seem to be able to > >> screenshot. > >> > >> Cheers, > >> > >> John > >> > >> On Sat, Feb 11, 2017 at 5:37 AM, John Beard > >> wrote: > >> > Hi, > >> > > >> > I have a few tweaks to some icons in Pcbnew and Eeschema. These are > >> > mostly minor tweaks that are intended to make the icons match a little > >> > better and give a more uniform look and feel: > >> > > >> > https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons > >> > > >> > * Pixel align a few icons to make then crisper when displayed > >> > * Redraw all the zoom icons to be crisper and flatter. The zoom to fit > >> > (Home) icon is now a sort of reticle rather than a pair of square > >> > brackets as text. > >> > * Redraw console icon to be flat to match other existing icons. > >> > * Mute some very bright colours, especially the green-legged module > >> > icons - use the zone icons as a guide for the colour brightness. > >> > > >> > Attached are screen shots of pcbnew and eeschema, where you can see > >> > some of the icons. > >> > > >> > I know icons and UI subjects in general are very subjective and > >> > personal, so I'd welcome input! > >> > > >> > Cheers, > >> > > >> > John > >> > >> ___ > >> 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 > >> > >> > > > > > > -- > > > > -Ben > > > > ___ > > 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] Selection tool that selects components and local connections
Merged. This looks very useful. Thank you for your contribution! On Sat, Feb 11, 2017 at 01:25:24PM +0100, Kristoffer Ödmark wrote: > Sure! here comes! > > - Kristoffer > > On 2017-02-11 03:02, Chris Pavlina wrote: > >Can you update this again? > > > >On Fri, Feb 10, 2017 at 01:45:10PM +0100, Kristoffer Ödmark wrote: > >>Updated the patch to fit on current master. > >> > >> > >>On 2017-02-08 21:14, Kristoffer Ödmark wrote: > >>>I tried reverting back to master and found the same strange bugs on > >>>windows, so i do not think my patch causes them. > >>> > >>>example of bug: > >>>https://snag.gy/EesP2n.jpg > >>> > >>>On 2017-02-08 19:17, Kristoffer Ödmark wrote: > >>>>Hello again! > >>>> > >>>>Since my groupselection required changes to the file format to be > >>>>useful. I have now created a selection tool that selects all footprints > >>>>belonging on the same sheet or "deeper". > >>>> > >>>>It also finds all nets that only have connections between components on > >>>>the same or deeper sheet and selects them. > >>>> > >>>>It gives some functionality of the group selection idea and does not > >>>>break file format or any previous workflow. > >>>> > >>>>Tested on linux, saw some strange right-click meny errors on windows, > >>>>but the functionality works there as well when using the shortcut key 'P' > >>>> > >>>>Attaching patch > >>>> > >>>>Video: > >>>>https://www.youtube.com/watch?v=DUskyc7t_HA&feature=youtu.be > >>>> > >>>>- Kristoffer > >>>> > >>>> > > ___ 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] RFC: Change UX for item selection clarification
I wish I had thoughts more verbose than "yes" right now... Yeah, this is
how most tools work, and it's quite intuitive. I would be 100% in favor
of implementing it this way.
On Sat, Feb 11, 2017 at 02:21:08PM -0500, Jon Evans wrote:
> Hi all,
>
> I had been thinking about proposing this already as a UX enhancement, and
> then while looking through the starter bugs realized that lp:1154020 [1] is
> actually quite difficult to solve in a nice way due to the popup menu used
> for clarification today, so I decided to send it out now.
>
> I propose that we change the selection code to "guess" at the item the user
> wanted to select, and let the user cycle through the set of items that are
> near the last point they clicked with a hotkey (and possible a context menu
> option "Next"). This is similar to how the commercial tools I've used work.
>
> A few more ideas about this:
>
> - The currently selected item needs to be indicated somehow. Currently we
> don't highlight all items when selected (for example, fields) and so either
> highlighting which item you are selecting or showing it in the message
> panel would be required for this to be friendly.
>
> - This would tie in nicely to selection filtering stuff that other devs are
> working on. Turning on a selection filter mode ("components only", "text
> objects only", etc) would restrict the set of items that can be picked, and
> greatly increase the chance that the right item will be selected on the
> first click.
>
> - Some commercial tools have "focus" modes, which are kind of like filters,
> but they don't restrict what you can select, but rather influence what will
> be selected first. So if you are in "component focus mode" and you select
> a component with a label on top, the component will always be selected
> first.
>
> - We could map two hotkeys next to each other (for example "," and "." on
> QWERTY keyboards) and let people step forward and backward through the
> clarification list
>
> I think this change would make item selection faster, allow fixing some
> long-standing bugs, and work nicely with enhancements to selection
> filtering that are coming. The one downside is that you would no longer
> get a list of all items that are underneath the cursor, but I can't see the
> value in that information.
>
> Any thoughts on this?
>
> Best,
> Jon
>
> [1] https://bugs.launchpad.net/kicad/+bug/1154020
___
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] RFC: Change UX for item selection clarification
Very nice. I only think it needs to be a bit more obvious how to do it.
On Sat, Feb 11, 2017 at 05:49:05PM -0500, Jon Evans wrote:
> Proof of concept: https://www.youtube.com/watch?v=JfnXPosOHcY
> (when you see the selection changing, I'm hitting the new hotkey I made for
> cycling through items)
>
> On Sat, Feb 11, 2017 at 2:24 PM, Chris Pavlina
> wrote:
>
> > I wish I had thoughts more verbose than "yes" right now... Yeah, this is
> > how most tools work, and it's quite intuitive. I would be 100% in favor
> > of implementing it this way.
> >
> > On Sat, Feb 11, 2017 at 02:21:08PM -0500, Jon Evans wrote:
> > > Hi all,
> > >
> > > I had been thinking about proposing this already as a UX enhancement, and
> > > then while looking through the starter bugs realized that lp:1154020 [1]
> > is
> > > actually quite difficult to solve in a nice way due to the popup menu
> > used
> > > for clarification today, so I decided to send it out now.
> > >
> > > I propose that we change the selection code to "guess" at the item the
> > user
> > > wanted to select, and let the user cycle through the set of items that
> > are
> > > near the last point they clicked with a hotkey (and possible a context
> > menu
> > > option "Next"). This is similar to how the commercial tools I've used
> > work.
> > >
> > > A few more ideas about this:
> > >
> > > - The currently selected item needs to be indicated somehow. Currently
> > we
> > > don't highlight all items when selected (for example, fields) and so
> > either
> > > highlighting which item you are selecting or showing it in the message
> > > panel would be required for this to be friendly.
> > >
> > > - This would tie in nicely to selection filtering stuff that other devs
> > are
> > > working on. Turning on a selection filter mode ("components only", "text
> > > objects only", etc) would restrict the set of items that can be picked,
> > and
> > > greatly increase the chance that the right item will be selected on the
> > > first click.
> > >
> > > - Some commercial tools have "focus" modes, which are kind of like
> > filters,
> > > but they don't restrict what you can select, but rather influence what
> > will
> > > be selected first. So if you are in "component focus mode" and you
> > select
> > > a component with a label on top, the component will always be selected
> > > first.
> > >
> > > - We could map two hotkeys next to each other (for example "," and "." on
> > > QWERTY keyboards) and let people step forward and backward through the
> > > clarification list
> > >
> > > I think this change would make item selection faster, allow fixing some
> > > long-standing bugs, and work nicely with enhancements to selection
> > > filtering that are coming. The one downside is that you would no longer
> > > get a list of all items that are underneath the cursor, but I can't see
> > the
> > > value in that information.
> > >
> > > Any thoughts on this?
> > >
> > > Best,
> > > Jon
> > >
> > > [1] https://bugs.launchpad.net/kicad/+bug/1154020
> >
> >
___
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] Component selector (was: I'm working on a nice thing)
This bit is not in the branch yet, but here's a little preview... https://misc.c4757p.com/i-can-footprint.png Thanks Tom! On Mon, Feb 06, 2017 at 09:07:16PM -0500, Chris Pavlina wrote: > Preview at g...@github.com:cpavlina/kicad branch componentchooser. > Footprint part still pending. > > On Sun, Feb 05, 2017 at 09:52:03PM -0500, Chris Pavlina wrote: > > Still very early... I call it "componentchoosernew" > > > > https://misc.c4757p.com/componentchoosernew.png > > > > -- > > Chris ___ 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] Component selector
Sure! The specific arrangement of the dialog makes it feel a bit cramped; I find that resizing things a bit shows it works quite well even at a small size. I'm going to have to tweak the exact placement of things in that dialog. On Sat, Feb 11, 2017 at 08:44:24PM -0500, Wayne Stambaugh wrote: > Very nice but will it fit on my 640 X 480 display ;) > > On 2/11/2017 8:25 PM, Oliver Walters wrote: > > Nice work, this is looking very professional Chris > > > > On 12 Feb 2017 12:12, "Chris Pavlina" > <mailto:pavlina.ch...@gmail.com>> wrote: > > > > This bit is not in the branch yet, but here's a little preview... > > > > https://misc.c4757p.com/i-can-footprint.png > > <https://misc.c4757p.com/i-can-footprint.png> > > > > Thanks Tom! > > > > On Mon, Feb 06, 2017 at 09:07:16PM -0500, Chris Pavlina wrote: > > > Preview at g...@github.com:cpavlina/kicad branch componentchooser. > > > Footprint part still pending. > > > > > > On Sun, Feb 05, 2017 at 09:52:03PM -0500, Chris Pavlina wrote: > > > > Still very early... I call it "componentchoosernew" > > > > > > > > https://misc.c4757p.com/componentchoosernew.png > > <https://misc.c4757p.com/componentchoosernew.png> > > > > > > > > -- > > > > Chris > > > > ___ > > Mailing list: https://launchpad.net/~kicad-developers > > <https://launchpad.net/~kicad-developers> > > Post to : kicad-developers@lists.launchpad.net > > <mailto:kicad-developers@lists.launchpad.net> > > 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 : 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] Component selector (was: I'm working on a nice thing)
And, it's in the branch now, temporarily gated by build option KICAD_FOOTPRINT_SELECTOR. At the moment it is VERY rudimentary, by which I mean it doesn't work - the preview is stuck showing one particular footprint permanently, and it's one you probably don't have in your libraries... Hopefully this will be fixed tomorrow. Wayne, my current goal is this: tomorrow, I will have footprint preview working completely, but still no footprint *selection*. At this point, I'd really like to push what I have, so that the footprint preview and the other GUI improvements in the component selector get further testing. Then, I will work on adding footprint selection, followed by 3D preview, both of which can be merged as separate patches. Have you had a chance to review yet? On Sat, Feb 11, 2017 at 08:12:17PM -0500, Chris Pavlina wrote: > This bit is not in the branch yet, but here's a little preview... > > https://misc.c4757p.com/i-can-footprint.png > > Thanks Tom! > > On Mon, Feb 06, 2017 at 09:07:16PM -0500, Chris Pavlina wrote: > > Preview at g...@github.com:cpavlina/kicad branch componentchooser. > > Footprint part still pending. > > > > On Sun, Feb 05, 2017 at 09:52:03PM -0500, Chris Pavlina wrote: > > > Still very early... I call it "componentchoosernew" > > > > > > https://misc.c4757p.com/componentchoosernew.png > > > > > > -- > > > Chris ___ 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] rename of kiface to so
Please!!: - Move .kiface into $PREFIX/lib on linux, and the equivalent place on other systems - Rename them from _foo.kiface to foo.so on linux and osx and foo.dll on windows - Stop installing them with the executable bit set on linux! Presumably osx too. It's totally unnecessary for shared libs, and ESPECIALLY bad if they're in $PREFIX/bin. On Mon, Feb 13, 2017 at 07:49:36AM +1300, Simon Wells wrote: > As the kifaces are just shared objects/libraries is there any reason > they must be named .kiface instead of .so (or other name used on > system for dynamic libs), It seems to just be making things more > difficult and confusing when people see .kiface and have no ideaa what > it means. > > These should really not be place in bin/ on linux systems either as > its really not designed for that sort of thing > > ___ > 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] rename of kiface to so
Can you explain why you think installing them as .so to /usr/lib changes in any way our responsibility for library versioning vs installing them as .kiface to /usr/bin? They still get installed with the whole package, reinstalled on upgrade, uninstalled on package removal, etc... On Mon, Feb 13, 2017 at 09:21:26AM -0500, Wayne Stambaugh wrote: > I'm not opposed to this but once we head down this path, we will forever > be responsible for library versioning and any implications it has with > regard to multiple installed versions of kicad. I'm not sure we are > ready to open that can of worms just yet. Keep in mind that .kifaces > are not generic libraries, they can only be linked to a specific kicad > app. Link to the wrong .kiface and your sure to have issues. > > On 2/12/2017 2:01 PM, Chris Pavlina wrote: > > Please!!: > > > > - Move .kiface into $PREFIX/lib on linux, and the equivalent place on > > other systems > > > > - Rename them from _foo.kiface to foo.so on linux and osx and foo.dll on > > windows > > > > - Stop installing them with the executable bit set on linux! Presumably > > osx too. It's totally unnecessary for shared libs, and ESPECIALLY bad > > if they're in $PREFIX/bin. > > > > On Mon, Feb 13, 2017 at 07:49:36AM +1300, Simon Wells wrote: > >> As the kifaces are just shared objects/libraries is there any reason > >> they must be named .kiface instead of .so (or other name used on > >> system for dynamic libs), It seems to just be making things more > >> difficult and confusing when people see .kiface and have no ideaa what > >> it means. > >> > >> These should really not be place in bin/ on linux systems either as > >> its really not designed for that sort of thing > >> > >> ___ > >> 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 ___ 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] rename of kiface to so
rpath? Load by absolute path based on compile prefix? Relative (../lib/foo based on the current exe path)? Seems to me standard library versioning isn't the right way to handle this anyway, since these aren't *libraries* per se but just object bundles. On Mon, Feb 13, 2017 at 09:35:59AM -0500, Wayne Stambaugh wrote: > When multiple versions of kicad are installed in different install > paths, library versioning has to be correct or it's possible that the > wrong kiface gets linked. I'm thinking more of users or developers who > build and install from source rather than packaged installs. On linux, > I could install the stable version of kicad in /usr and my dev build in > /usr/local or /home. If _pcbnew.so (kiface) exists in multiple ldconfig > paths with no or identical version information, how does ld know which > _pcbnew.so to use? > > On 2/13/2017 9:30 AM, Chris Pavlina wrote: > > Can you explain why you think installing them as .so to /usr/lib changes > > in any way our responsibility for library versioning vs installing them > > as .kiface to /usr/bin? They still get installed with the whole package, > > reinstalled on upgrade, uninstalled on package removal, etc... > > > > On Mon, Feb 13, 2017 at 09:21:26AM -0500, Wayne Stambaugh wrote: > >> I'm not opposed to this but once we head down this path, we will forever > >> be responsible for library versioning and any implications it has with > >> regard to multiple installed versions of kicad. I'm not sure we are > >> ready to open that can of worms just yet. Keep in mind that .kifaces > >> are not generic libraries, they can only be linked to a specific kicad > >> app. Link to the wrong .kiface and your sure to have issues. > >> > >> On 2/12/2017 2:01 PM, Chris Pavlina wrote: > >>> Please!!: > >>> > >>> - Move .kiface into $PREFIX/lib on linux, and the equivalent place on > >>> other systems > >>> > >>> - Rename them from _foo.kiface to foo.so on linux and osx and foo.dll on > >>> windows > >>> > >>> - Stop installing them with the executable bit set on linux! Presumably > >>> osx too. It's totally unnecessary for shared libs, and ESPECIALLY bad > >>> if they're in $PREFIX/bin. > >>> > >>> On Mon, Feb 13, 2017 at 07:49:36AM +1300, Simon Wells wrote: > >>>> As the kifaces are just shared objects/libraries is there any reason > >>>> they must be named .kiface instead of .so (or other name used on > >>>> system for dynamic libs), It seems to just be making things more > >>>> difficult and confusing when people see .kiface and have no ideaa what > >>>> it means. > >>>> > >>>> These should really not be place in bin/ on linux systems either as > >>>> its really not designed for that sort of thing > >>>> > >>>> ___ > >>>> 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 ___ 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] [PATCH] Prevent segfault when aOutline has no vertices.
Thank you for your contribution.
We're generally pretty strict about the coding style for new code; it
can be found at Documentation/development/coding-style-policy.md in the
source tree. If you don't see what the problem is, pay particular
attention to spacing around parentheses, and to the placement of braces
{}. I'd normally just fix this myself on such a small patch, but since
Wayne has taken this thread I'll let him wait for you to submit a fixed
patch. Just thought I'd explain in a bit more detail.
--
Chris
___
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] patch to fix Bug #1626278
Merged. Thank you. On Thu, Feb 09, 2017 at 08:26:48PM +, Mário Luzeiro wrote: > There is no propose to use mm_alloc at this moment so I changed it to the > regular malloc. > (This also should make the Raspberry PI users happier and use KiCad! :O ) > > Mario ___ 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] [PATCH] Prevent segfault when aOutline has no vertices.
Thank you both. I pushed the fixed patch, crediting hauptmech as the
original author and leaving Clemens' signoff.
On Mon, Feb 13, 2017 at 10:07:56PM +0100, Clemens Koller wrote:
> Well...
>
> I had a look at this for my very own training pleasure and updated the patch
> from Hauptmechto to suit the coding style AFAICT.
> (attached)
>
> Regards,
>
> Clemens
>
> On 2017-02-13 21:09, hauptmech wrote:
> > Thanks for the heads up Chris.
> >
> > Respectfully to the developers, I don't have time. If this does not
> > match your coding style then consider it bug report.
> >
> > -Hauptmech
> >
> > On 14/02/17 04:00, Chris Pavlina wrote:
> >> Thank you for your contribution.
> >>
> >> We're generally pretty strict about the coding style for new code; it
> >> can be found at Documentation/development/coding-style-policy.md in the
> >> source tree. If you don't see what the problem is, pay particular
> >> attention to spacing around parentheses, and to the placement of braces
> >> {}. I'd normally just fix this myself on such a small patch, but since
> >> Wayne has taken this thread I'll let him wait for you to submit a fixed
> >> patch. Just thought I'd explain in a bit more detail.
> >>
> >> -- Chris
> >
> >
> >
> > ___
> > 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] Component selector
On Mon, Feb 13, 2017 at 06:57:07PM -0500, Wayne Stambaugh wrote: > Chris, > > I had a chance to review the new footprint selector. I like it so far > although it does seem a bit cramped with both preview window. I'm not > sure there is much you can do about that. I'm fine with you pushing > what you have done so far. I am going to play with the dialog layout a bit more. The default layout does feel cramped, but I think I can fix that. I'm not going to push it immediately. I realized that when working with the default kicad libs, it takes much longer to load now, and I like to be able to pop it up very quickly when putting a schematic together. Going to take some time to investigate what is slowing things down. > > I do have one comment. It it necessary to open the symbol viewer on a > left click in the symbol panel? My initial instinct was to click on the > panel to set the focus to zoom and/or pan the symbol in the panel to get > a better view. Maybe launching the symbol viewer should occur on a > double click. Just food for thought. I still have to fix the event binding, which got a bit messed up when I switched tree list control types. I meant to have that done by now but got sidetracked. Again, won't push until that's done. It shouldn't be bound to left-click. > > I didn't get a chance to review the code but one thing I want to make > sure is that you are not adding UI code to any of the symbol or > footprint library objects. The recent progress dialog patch added UI > code to the PART_LIBS object. We (I) spent a lot of time uncoupling the > symbol library code from all things UI and now that has been undone. > I'll fix this when I implement the symbol library table. Nope, nothing added to data objects, the UI code is in UI classes only. Apologies for pushing the progress dialog patch then - I didn't notice it did that. Looking at it now, I should have rejected it in this state. > > Cheers, > > Wayne > > On 2/11/2017 9:07 PM, Chris Pavlina wrote: > > And, it's in the branch now, temporarily gated by build option > > KICAD_FOOTPRINT_SELECTOR. At the moment it is VERY rudimentary, by which > > I mean it doesn't work - the preview is stuck showing one particular > > footprint permanently, and it's one you probably don't have in your > > libraries... > > > > Hopefully this will be fixed tomorrow. Wayne, my current goal is this: > > tomorrow, I will have footprint preview working completely, but still no > > footprint *selection*. At this point, I'd really like to push what I > > have, so that the footprint preview and the other GUI improvements in > > the component selector get further testing. Then, I will work on adding > > footprint selection, followed by 3D preview, both of which can be merged > > as separate patches. Have you had a chance to review yet? > > > > On Sat, Feb 11, 2017 at 08:12:17PM -0500, Chris Pavlina wrote: > >> This bit is not in the branch yet, but here's a little preview... > >> > >> https://misc.c4757p.com/i-can-footprint.png > >> > >> Thanks Tom! > >> > >> On Mon, Feb 06, 2017 at 09:07:16PM -0500, Chris Pavlina wrote: > >>> Preview at g...@github.com:cpavlina/kicad branch componentchooser. > >>> Footprint part still pending. > >>> > >>> On Sun, Feb 05, 2017 at 09:52:03PM -0500, Chris Pavlina wrote: > >>>> Still very early... I call it "componentchoosernew" > >>>> > >>>> https://misc.c4757p.com/componentchoosernew.png > >>>> > >>>> -- > >>>> Chris > > > > ___ > > 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] {PATCH] Icon tweaks
On Thu, Feb 16, 2017 at 11:47:27AM +0100, Fabrizio Tappero wrote: > Hi Guys, > I totally agree with you John. If you think you want to go ahead and review > Konstantin icons and submit small groups of new and improved icons, I think > that would be a terrific idea. > > I just would like you to be a little "sensitive" on the fact that whatever > improvement on kiCad looks is totally welcome but it would be great if it > could come gradually. The KiCad documentation (in all its languages) is not > really ready for a totally new icon look. The documentation build system really needs to have an automated way to pull bitmaps for icons directly from the source repository... > > I think it would be totally great if we could first go ahead with the > submission of this > https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons > > plus the icon in attachment. > > this is just my 2c. > > Cheers > Fabrizio > > > On Tue, Feb 14, 2017 at 6:35 PM, John Beard wrote: > > > Hi, > > > > I think Konstantin's icons are a more complete and homegenous set - > > I'd rather see those go in first. If there is still any use for my > > icons after that, I can rebase on top of that. > > > > He and I have talked about rebasing his branch into a simpler set of > > smaller patches (eg. just zoom icons) for easier review, since I think > > icons can easily attracts lots of comment, and getting bogged down in > > talking about colours of vias when the zoom icons are fine would be > > frustrating! > > > > Cheers, > > > > John > > > > On Wed, Feb 15, 2017 at 12:37 AM, Fabrizio Tappero > > wrote: > > > Hi Wayne, > > > John metion that his changes are on the tip of this branch: > > > > > > https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons > > > > > > Also, would you please be so kind to include this icon in attachment. I > > have > > > some problem is generating the patch for it. > > > > > > thank you > > > Fabrizio > > > > > > > > > > > > On Tue, Feb 14, 2017 at 3:39 PM, Wayne Stambaugh > > > wrote: > > >> > > >> Where do we stand on this? I think these changes should be committed. > > >> If there are no objections, please send a patch to the dev list so I can > > >> merge it. > > >> > > >> On 2/10/2017 4:37 PM, John Beard wrote: > > >> > Hi, > > >> > > > >> > I have a few tweaks to some icons in Pcbnew and Eeschema. These are > > >> > mostly minor tweaks that are intended to make the icons match a little > > >> > better and give a more uniform look and feel: > > >> > > > >> > https://code.launchpad.net/~john-j-beard/kicad/+git/kicad/+ref/icons > > >> > > > >> > * Pixel align a few icons to make then crisper when displayed > > >> > * Redraw all the zoom icons to be crisper and flatter. The zoom to fit > > >> > (Home) icon is now a sort of reticle rather than a pair of square > > >> > brackets as text. > > >> > * Redraw console icon to be flat to match other existing icons. > > >> > * Mute some very bright colours, especially the green-legged module > > >> > icons - use the zone icons as a guide for the colour brightness. > > >> > > > >> > Attached are screen shots of pcbnew and eeschema, where you can see > > >> > some of the icons. > > >> > > > >> > I know icons and UI subjects in general are very subjective and > > >> > personal, so I'd welcome input! > > >> > > > >> > Cheers, > > >> > > > >> > John > > >> > > > >> > > > >> > > > >> > ___ > > >> > 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 > > > > > ___ 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] rename of kiface to so
On Thu, Feb 16, 2017 at 09:18:10AM -0500, Wayne Stambaugh wrote: > I had to relearn what I forgot about why the kifaces are installed along > side the executables. The reason is kiface is short for KICad interFACE > files. They are the face of KiCad and are program files that happen to > be in a form that is loadable from start up. The allows kicad to > operate in both the integrated and stand alone modes without linking the > interFACE part in both modes. The kiface changes frequently and is not > a great candidate for a typical shared object. As reasons for installing them in /usr/bin go, this is "I can count to potato" levels of silly. THAT'S NOT WHERE SHARED OBJECTS GO, typical or atypical. /usr/bin is ONLY for executables with a valid entry point. > > The original goal was to split libcommon (and possibly more granular > libpcbcommon and libschcommon) to actual shared objects in the > traditional fashion because this code does not change frequently like > the interFACE part of kiface does. I don't know if the libcommon > objects are sufficiently decoupled from the kiface objects yet to build > a libcommon shared object. If they are, I would be more than happy > accommodate that patch. For now, I would prefer to keep things the way > they are in the vein of "if it ain't broke don't fix it". > > Cheers, > > Wayne > > On 2/13/2017 4:54 PM, Cirilo Bernardo wrote: > > If my memory's not too bad, these objects are loaded using hard-coded paths. > > They are not objects which are automatically resolved and loaded by the > > linker-loader. This makes any versioning trivial - so long as we *do* > > provide some > > version numbers so that the files have different names, kicad can still > > load the > > correct blobs. The closest example of related code in kicad would be the 3D > > plugins - in that case the plugin loader searches a number of given paths > > and > > loads whatever files it can. In the case of the kiface blobs we can > > have a similar > > flow of searching paths, though the actual file names of the blobs to be > > loaded > > may be set at compile time. Actually, the 3D plugin system does require an > > auto-loaded library; that library does not currently have a version number > > in > > its name although internally there are in fact version checks. > > > > - Cirilo > > > > > > On Tue, Feb 14, 2017 at 1:45 AM, Chris Pavlina > > wrote: > >> rpath? Load by absolute path based on compile prefix? Relative > >> (../lib/foo based on the current exe path)? Seems to me standard library > >> versioning isn't the right way to handle this anyway, since these aren't > >> *libraries* per se but just object bundles. > >> > >> On Mon, Feb 13, 2017 at 09:35:59AM -0500, Wayne Stambaugh wrote: > >>> When multiple versions of kicad are installed in different install > >>> paths, library versioning has to be correct or it's possible that the > >>> wrong kiface gets linked. I'm thinking more of users or developers who > >>> build and install from source rather than packaged installs. On linux, > >>> I could install the stable version of kicad in /usr and my dev build in > >>> /usr/local or /home. If _pcbnew.so (kiface) exists in multiple ldconfig > >>> paths with no or identical version information, how does ld know which > >>> _pcbnew.so to use? > >>> > >>> On 2/13/2017 9:30 AM, Chris Pavlina wrote: > >>>> Can you explain why you think installing them as .so to /usr/lib changes > >>>> in any way our responsibility for library versioning vs installing them > >>>> as .kiface to /usr/bin? They still get installed with the whole package, > >>>> reinstalled on upgrade, uninstalled on package removal, etc... > >>>> > >>>> On Mon, Feb 13, 2017 at 09:21:26AM -0500, Wayne Stambaugh wrote: > >>>>> I'm not opposed to this but once we head down this path, we will forever > >>>>> be responsible for library versioning and any implications it has with > >>>>> regard to multiple installed versions of kicad. I'm not sure we are > >>>>> ready to open that can of worms just yet. Keep in mind that .kifaces > >>>>> are not generic libraries, they can only be linked to a specific kicad > >>>>> app. Link to the wrong .kiface and your sure to have issues. > >>>>> > >>>>> On 2/12/2017 2:01 PM, Chris Pavlina wrote: > &
Re: [Kicad-developers] rename of kiface to so
On Fri, Feb 17, 2017 at 07:36:17AM +1300, Simon Wells wrote: > The Filesystem Heirachy Standard v2.3 specifies: > > for /usr/bin: > "This is the primary directory of executable commands on the system." > > and for /usr/lib: > "/usr/lib includes object files, libraries, and internal binaries that > are not intended to be executed directly by users or shell scripts." > > FHS v3.0 > > /usr/bin: > "This is the primary directory of executable commands on the system." > > /usr/lib: > "/usr/lib includes object files and libraries. [21] On some systems, > it may also include internal binaries that are not intended to be > executed directly by users or shell scripts. [22] > > Applications may use a single subdirectory under /usr/lib. If an > application uses a subdirectory, all architecture-dependent data > exclusively used by the application must be placed within that > subdirectory. [23]" > > /usr/libexec (optional): > "/usr/libexec includes internal binaries that are not intended to be > executed directly by users or shell scripts. Applications may use a > single subdirectory under /usr/libexec. > > Applications which use /usr/libexec in this way must not also use > /usr/lib to store internal binaries, though they may use /usr/lib for > the other purposes documented here." > > - > > As the kifaces are NOT directly executable from command line it seems > that bin/ is not an appropriate place for them. Do you know any other > software that places non-executable support files into bin/? > > I see libexec being used for a binary that is run from an executable > but itself still executable from the command line by a user. Also as > its optional it also doesn't seem the best choice. > > Therefore to follow the FHS on linux it seems the most sane place for > the kiface files to be in /lib and most likely under a > subdirectory as while they are not strictly data they are not > "libraries" nor are they "exectuables" and as such the most > appropriate term for them might be data > > If they are continued to be treated as exectuables like they currently > are then there should be a bug report filed that they segfault when > you try to run them THIS. If we are going to continue to stick them in /usr/bin like fools then we should consider it a bug that they do not run their respective applications when executed. Our install script even sets them +x! > > > Simon > > > > On 17 February 2017 at 03:18, Wayne Stambaugh wrote: > > I had to relearn what I forgot about why the kifaces are installed along > > side the executables. The reason is kiface is short for KICad interFACE > > files. They are the face of KiCad and are program files that happen to > > be in a form that is loadable from start up. The allows kicad to > > operate in both the integrated and stand alone modes without linking the > > interFACE part in both modes. The kiface changes frequently and is not > > a great candidate for a typical shared object. > > > > The original goal was to split libcommon (and possibly more granular > > libpcbcommon and libschcommon) to actual shared objects in the > > traditional fashion because this code does not change frequently like > > the interFACE part of kiface does. I don't know if the libcommon > > objects are sufficiently decoupled from the kiface objects yet to build > > a libcommon shared object. If they are, I would be more than happy > > accommodate that patch. For now, I would prefer to keep things the way > > they are in the vein of "if it ain't broke don't fix it". > > > > Cheers, > > > > Wayne > > > > On 2/13/2017 4:54 PM, Cirilo Bernardo wrote: > >> If my memory's not too bad, these objects are loaded using hard-coded > >> paths. > >> They are not objects which are automatically resolved and loaded by the > >> linker-loader. This makes any versioning trivial - so long as we *do* > >> provide some > >> version numbers so that the files have different names, kicad can still > >> load the > >> correct blobs. The closest example of related code in kicad would be the 3D > >> plugins - in that case the plugin loader searches a number of given paths > >> and > >> loads whatever files it can. In the case of the kiface blobs we can > >> have a similar > >> flow of searching paths, though the actual file names of the blobs to be > >> loaded > >> may be set at compile time. Actually, the 3D plugin system does require an > >> auto-loaded librar
Re: [Kicad-developers] [RFC] Future of GitHub libraries
On Fri, Feb 17, 2017 at 11:51:36AM -0700, Andy Peters wrote: > > > On Feb 17, 2017, at 8:31 AM, Clemens Koller wrote: > > > > > > > > And: In the long-term we might also think about using git for project and > > design management and versioning. (We could even store undo's and redo's in > > git?) > > Except that not everyone likes or uses git. I use Subversion for my projects. Not everybody likes red bikesheds either, but at some point sometimes you have to shut up and pick a color. > > -a > ___ > 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] Component selector
On Mon, Feb 13, 2017 at 07:08:43PM -0500, Chris Pavlina wrote: > On Mon, Feb 13, 2017 at 06:57:07PM -0500, Wayne Stambaugh wrote: > > Chris, > > > > I had a chance to review the new footprint selector. I like it so far > > although it does seem a bit cramped with both preview window. I'm not > > sure there is much you can do about that. I'm fine with you pushing > > what you have done so far. > > I am going to play with the dialog layout a bit more. The default layout > does feel cramped, but I think I can fix that. > > I'm not going to push it immediately. I realized that when working with > the default kicad libs, it takes much longer to load now, and I like to > be able to pop it up very quickly when putting a schematic together. > Going to take some time to investigate what is slowing things down. Update: I'm going to push this tonight after cleaning up what remains to be cleaned up, in spite of the performance hit. I've narrowed down what the performance hit is: populating wxTreeListCtrl in the way the previous wxTreeCtrl was populated is just dog slow. I think it may be traversing the list several times for each insertion. I'll probably have to rewrite that bit, but it's not enough of a performance hit to sacrifice having other people's testing eyeballs on it. If anyone else wants to look, the relevant section is COMPONENT_TREE_SEARCH_CONTAINER::UpdateSearchTerm(), which takes a hefty fraction of a second after a naive replacement of wxTreeCtrl with wxTreeListCtrl. > > > > > I do have one comment. It it necessary to open the symbol viewer on a > > left click in the symbol panel? My initial instinct was to click on the > > panel to set the focus to zoom and/or pan the symbol in the panel to get > > a better view. Maybe launching the symbol viewer should occur on a > > double click. Just food for thought. > > I still have to fix the event binding, which got a bit messed up when I > switched tree list control types. I meant to have that done by now but > got sidetracked. Again, won't push until that's done. It shouldn't be > bound to left-click. > > > > > I didn't get a chance to review the code but one thing I want to make > > sure is that you are not adding UI code to any of the symbol or > > footprint library objects. The recent progress dialog patch added UI > > code to the PART_LIBS object. We (I) spent a lot of time uncoupling the > > symbol library code from all things UI and now that has been undone. > > I'll fix this when I implement the symbol library table. > > Nope, nothing added to data objects, the UI code is in UI classes only. > Apologies for pushing the progress dialog patch then - I didn't notice > it did that. Looking at it now, I should have rejected it in this state. > > > > > Cheers, > > > > Wayne > > > > On 2/11/2017 9:07 PM, Chris Pavlina wrote: > > > And, it's in the branch now, temporarily gated by build option > > > KICAD_FOOTPRINT_SELECTOR. At the moment it is VERY rudimentary, by which > > > I mean it doesn't work - the preview is stuck showing one particular > > > footprint permanently, and it's one you probably don't have in your > > > libraries... > > > > > > Hopefully this will be fixed tomorrow. Wayne, my current goal is this: > > > tomorrow, I will have footprint preview working completely, but still no > > > footprint *selection*. At this point, I'd really like to push what I > > > have, so that the footprint preview and the other GUI improvements in > > > the component selector get further testing. Then, I will work on adding > > > footprint selection, followed by 3D preview, both of which can be merged > > > as separate patches. Have you had a chance to review yet? > > > > > > On Sat, Feb 11, 2017 at 08:12:17PM -0500, Chris Pavlina wrote: > > >> This bit is not in the branch yet, but here's a little preview... > > >> > > >> https://misc.c4757p.com/i-can-footprint.png > > >> > > >> Thanks Tom! > > >> > > >> On Mon, Feb 06, 2017 at 09:07:16PM -0500, Chris Pavlina wrote: > > >>> Preview at g...@github.com:cpavlina/kicad branch componentchooser. > > >>> Footprint part still pending. > > >>> > > >>> On Sun, Feb 05, 2017 at 09:52:03PM -0500, Chris Pavlina wrote: > > >>>> Still very early... I call it "componentchoosernew" > > >>>> > > >>>> https://misc.c47
Re: [Kicad-developers] [PATCH] kicad: tree_project_frame: fixup drawframe style
On Sat, Feb 18, 2017 at 11:04:57PM +0100, Nick Østergaard wrote: > Well, one thing is ofc to bring down the burden to make a comitter > understand your patch. This is a small patch and probably easy to > comprehend, for some people. > > But I don't really understand what problem this patch tries to fix, > this means that I can't not really help testing it on a potentially > different platform. wx border styles are being used that are incompatible with each other and it's causing Yet Another Wx Resize Bug. > > Well, waiting a week to poke is brobably fine for this sort of thing. > > It is the responsibility of the contributor to nurse the patch. IMHO. Yeah, since we don't have any better patch management system you're just gonna have to bump in a week or so. Things do get lost. I'll push this shortly, it's simple enough. Thank you. > > 2017-02-18 22:31 GMT+01:00 Clemens Koller : > > Hello mergers! > > > > I don't see my patch in master. It was neither merged nor commented. > > How long are devs expect to wait until it's okay to bump it? > > How can we make sure that no patches get lost on the way... especially when > > they are so subtle. > > > > Regards, > > > > Clemens > > > > On 2017-02-08 22:13, Clemens Koller wrote: > >> wxNO_BORDER and wxSW_3D seem incompatible and the border flickers > >> when the tree frame gets resized. Using KICAD_DEFAULT_DRAWFRAME_STYLE > >> avoids this. > >> > >> Signed-off-by: Clemens Koller > >> > >> > >> > >> ___ > >> 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 ___ 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] Pushed new component selector
I just pushed the revamped component selector. Thanks to Tomasz for the kiface-compatible footprint preview pane! The following changes are added in this revision: - Most obviously: add footprint preview to the eeschema component selector. Currently, this only works if the symbol has a value in the Footprint field in the library. - Upgrade tree widget in the component selector to a wxTreeListCtrl, removing the columns previously simulated using monospace font and spacing. - Factor out customized two-column wxTreeListCtrl previously used in the hotkey list. This subclass fixes a column sizing bug that wxTreeListCtrl has. - Add more information to the info display in the selector, using a wxHtmlWindow to display formatting. Part of this has already been pushed to master recently, though I figured I'd mention it again. Beyond the changes that were pushed last week, I also linkified the datasheet URL so it can be directly clicked within the component selector and launch a browser. UPCOMING: - Footprint selection in this dialog. The user will be able to choose from whatever is prepopulated in the Footprint field, anything matching the footprint filters, and "Other..." which calls up the footprint browser. - 3D footprint preview, we need to show off our sexy renderer ;) - Hide fields in the symbol preview (or maybe just hidden fields?). They are redundant now that they're also displayed in the info box, so clean up the preview. KNOWN BUGS: - Dialog layout isn't optimal, it still looks a bit cramped. I'll tweak this later. - Loads slowly, this is due to differences in populating wxTreeListCtrl vs the old wxTreeCtrl. I'll rewrite the method that populates this list. Please, test thoroughly. This is an 1800 line commit, it probably has some bugs. Particularly I'm looking for testing on OSX - I think I got the commit pushed in time for the build of tonight's OSX nightly, so you shouldn't have to build yourself, just want until tomorrow. -- Chris ___ 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] PANEL_PREV_3D_B
In panel_prev_model.h, there is this line: #define PANEL_PREV_3D_B PANEL_PREV_3D After this, "PANEL_PREV_3D_B" is used in the code in place of "PANEL_PREV_3D". ...WHY? Really...why?? I don't see any explanation for this bizarre substitution. It's performed by the preprocessor, so should be exactly equivalent to just writing PANEL_PREV_3D. Can someone please explain what this is and why it's here? -- Chris ___ 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] PANEL_PREV_3D_B
On Sun, Feb 19, 2017 at 09:33:56AM +0100, jp charras wrote: > Le 19/02/2017 à 04:25, Chris Pavlina a écrit : > > In panel_prev_model.h, there is this line: > > > > #define PANEL_PREV_3D_B PANEL_PREV_3D > > > > After this, "PANEL_PREV_3D_B" is used in the code in place of > > "PANEL_PREV_3D". > > ...WHY? > > > > Really...why?? > > > > I don't see any explanation for this bizarre substitution. It's > > performed by the preprocessor, so should be exactly equivalent to just > > writing PANEL_PREV_3D. Can someone please explain what this is and why > > it's here? > > > > This is a mistake. > > I used it temporary during a debug session, and forgot to remove it. > > It is now fixed. Haha, okay. No offense meant, it just seemed a bit funny. Thanks for removing it. > > -- > Jean-Pierre CHARRAS > > ___ > 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
[Kicad-developers] diodes.lib
It looks like eeschema/diodes.lib was committed accidentally. Does anyone know for sure if this is the case? -- Chris ___ 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] [Request for Tests] Experimental icon options in Kicad
On Tue, Feb 21, 2017 at 02:57:18PM +0100, jp charras wrote: > [snip] > > After changing an option, you have to quit and restart Kicad, to take in > account the icon settings. I don't have time to test this right now, but... for me, this is unacceptable. No option should require a restart. The functions that populate the menus claim to be able to repopulate them, you should make use of that, and fix it if it doesn't work right. > > I need to know: > * If the look of large icons is good with HDPI monitors (standards icons are > just scaled) > * If it is useful with monitors having only a vertical size of 800 pixels > (choose "small icons") > * If HDPI monitors are correctly detected (the Kicad/preferences/Icons > Options shows in HDPI > SysScale menu the scaling factor returned by wxWidgets for the monitor in use > to display the Kicad > manger. > * If it makes sense to have an option to enable/disable icons in menus at run > time, especially for > OSX users. OSX cannot display icons in menus, so hide the option for them. Why can't we just kill menu icons entirely? Very few other applications use them, and those that do use them sparingly, only for things users need to find very quickly. KiCad is the only one I've seen that puts a bloody huge icon on every single menu item. > > Attached the patch to test this experimental feature. > Thanks. > > -- > Jean-Pierre CHARRAS ___ 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] [PATCH] Fix layer color swatches in Linux
On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh wrote: > My only issue with this change is that the tooltip letting the user know > that a left button double click or a middle button click would allow > them to change the color is gone. Other than that, it looks great. I > like the use of Bind instead of Connect. Bind has a much cleaner > interface than Connect and according to the wx folks is the proper way > to handle events. The tooltip is useless, nobody is going to hover over them for long enough to see it. I was just talking to someone this morning who never found the tooltip because he was too busy clicking on the buttons to make them work. Every other color well in every other application opens its selection dialog with a single left click. Why can't ours? > > On 2/21/2017 8:04 AM, John Beard wrote: > > Hi, > > > > These patches fix the layer/render widget swatches in Linux under new > > GTK+ toolkits. Fix for: https://bugs.launchpad.net/kicad/+bug/1605411 > > > > The patches remove the "button" nature of the swatches, since they > > weren't actually actuated by a single click, so the button affordance > > was misleading anyway. Also on OSX, the button was invisible, so it > > just looked like a flat swatch anyway. > > > > * Linux as it was: > > https://drive.google.com/file/d/0BxVhl5qZbpYoZlZPeXV1Q0ttT2s/view > > * OSX as it was: > > https://launchpadlibrarian.net/274428737/Screen%20Shot%202016-07-22%20at%2019.40.14.png > > * Linux after this patch: see attachment > > > > This is followed by a refactor to pull the swatch logic out of the > > layer widget into common, where it can be used by other clients, for > > example the eeschema display color dialog, if wanted. > > > > Patch #3 is a simple replacement of old WX Connect with Bind for > > consistency in that file. > > > > Cheers, > > > > John > > > > > > > > ___ > > 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] [Request for Tests] Experimental icon options in Kicad
On Tue, Feb 21, 2017 at 04:30:11PM +0100, jp charras wrote: > Le 21/02/2017 à 16:05, Chris Pavlina a écrit : > > On Tue, Feb 21, 2017 at 02:57:18PM +0100, jp charras wrote: > >> [snip] > >> > >> After changing an option, you have to quit and restart Kicad, to take in > >> account the icon settings. > > > > I don't have time to test this right now, but... for me, this is > > unacceptable. No option should require a restart. The functions that > > populate the menus claim to be able to repopulate them, you should make > > use of that, and fix it if it doesn't work right. > > Chris, you have missed something: it is an *experimental* feature. > Therefore I need to known is it is working or useful. > > I do not want spend my time to repopulate the toolbars, if this feature does > not work fine on HDPI > monitors, and if is is never added to Kicad. > > Therefore it is perfectly acceptable, for an experimental test. Sure, I just mean it won't be acceptable if the experimental feature is turned into a real feature ;) > > > > > >> > >> I need to know: > >> * If the look of large icons is good with HDPI monitors (standards icons > >> are just scaled) > >> * If it is useful with monitors having only a vertical size of 800 pixels > >> (choose "small icons") > >> * If HDPI monitors are correctly detected (the Kicad/preferences/Icons > >> Options shows in HDPI > >> SysScale menu the scaling factor returned by wxWidgets for the monitor in > >> use to display the Kicad > >> manger. > >> * If it makes sense to have an option to enable/disable icons in menus at > >> run time, especially for > >> OSX users. > > > > OSX cannot display icons in menus, so hide the option for them. > > > > Why can't we just kill menu icons entirely? Very few other applications > > use them, and those that do use them sparingly, only for things users > > need to find very quickly. KiCad is the only one I've seen that puts a > > bloody huge icon on every single menu item. > > > >> > >> Attached the patch to test this experimental feature. > >> Thanks. > >> > >> -- > >> Jean-Pierre CHARRAS > > > > > > > -- > Jean-Pierre CHARRAS > > ___ > 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] [PATCH] Fix layer color swatches in Linux
Sent to wrong recipient. On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote: > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote: > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit : > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh wrote: > > >> My only issue with this change is that the tooltip letting the user know > > >> that a left button double click or a middle button click would allow > > >> them to change the color is gone. Other than that, it looks great. I > > >> like the use of Bind instead of Connect. Bind has a much cleaner > > >> interface than Connect and according to the wx folks is the proper way > > >> to handle events. > > > > > > The tooltip is useless, nobody is going to hover over them for long > > > enough to see it. I was just talking to someone this morning who never > > > found the tooltip because he was too busy clicking on the buttons to > > > make them work. > > > > > > Every other color well in every other application opens its selection > > > dialog with a single left click. Why can't ours? > > > > First you have to decide if the main purpose is to select the active layer > > or to change the color layer. > > The answer will give also the answer to "Why can't ours". > > > > For me the answer is not obvious, but my opinion is: > > the primary purpose of the layer manager is to select the working layer. > > Therefore the single left click should change the layer, whatever you are > > clicking. > > > > If the primary purpose of the layer manager is to select the color, then a > > single left click should > > open the color dialog. > > This isn't "the layer manager", it's a color well IN the layer manager. > > > > > If the single left click opens the dialog, be sure many times, when > > clicking inside the layer > > manager, you will open the dialog, instead of changing the active layer, > > especially if you are too > > busy clicking on the window to verify the exact position of the mouse. > > (It frequently happened to me when the single click was opening the dialog) > > > > A wise decision is never obvious. > > (A reason like "other applications do that" is not necessary a good reason. > > Each application has its constraints and its compromises) > > YES IT IS. Consistency is the single most important way to make an > interface understandable. A box containing a color is a color well, and > color wells behave the exact same way in everything that isn't kicad. > > Next you'll tell me "File->Open opening a file in other applications is > not a good reason it shouldn't display a photo of a llama in KiCad". > > > > > > > > >> > > >> On 2/21/2017 8:04 AM, John Beard wrote: > > >>> Hi, > > >>> > > >>> These patches fix the layer/render widget swatches in Linux under new > > >>> GTK+ toolkits. Fix for: https://bugs.launchpad.net/kicad/+bug/1605411 > > >>> > > >>> The patches remove the "button" nature of the swatches, since they > > >>> weren't actually actuated by a single click, so the button affordance > > >>> was misleading anyway. Also on OSX, the button was invisible, so it > > >>> just looked like a flat swatch anyway. > > >>> > > >>> * Linux as it was: > > >>> https://drive.google.com/file/d/0BxVhl5qZbpYoZlZPeXV1Q0ttT2s/view > > >>> * OSX as it was: > > >>> https://launchpadlibrarian.net/274428737/Screen%20Shot%202016-07-22%20at%2019.40.14.png > > >>> * Linux after this patch: see attachment > > >>> > > >>> This is followed by a refactor to pull the swatch logic out of the > > >>> layer widget into common, where it can be used by other clients, for > > >>> example the eeschema display color dialog, if wanted. > > >>> > > >>> Patch #3 is a simple replacement of old WX Connect with Bind for > > >>> consistency in that file. > > >>> > > >>> Cheers, > > >>> > > >>> John > > >>> > > >>> > > >>> > > >>> ___ > > >>> Mailing list: https://launchpad.net/~kicad-developers > > >>> Post to : kicad-developers@lists.launchpad.net > > &g
Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux
By the way. https://forum.kicad.info/t/developer-feedback-poll-layer-manager/5421 Feel free to add your own responses. The results look pretty conclusive right now ;) On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote: > Sent to wrong recipient. > > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote: > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote: > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit : > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh wrote: > > > >> My only issue with this change is that the tooltip letting the user > > > >> know > > > >> that a left button double click or a middle button click would allow > > > >> them to change the color is gone. Other than that, it looks great. I > > > >> like the use of Bind instead of Connect. Bind has a much cleaner > > > >> interface than Connect and according to the wx folks is the proper way > > > >> to handle events. > > > > > > > > The tooltip is useless, nobody is going to hover over them for long > > > > enough to see it. I was just talking to someone this morning who never > > > > found the tooltip because he was too busy clicking on the buttons to > > > > make them work. > > > > > > > > Every other color well in every other application opens its selection > > > > dialog with a single left click. Why can't ours? > > > > > > First you have to decide if the main purpose is to select the active > > > layer or to change the color layer. > > > The answer will give also the answer to "Why can't ours". > > > > > > For me the answer is not obvious, but my opinion is: > > > the primary purpose of the layer manager is to select the working layer. > > > Therefore the single left click should change the layer, whatever you are > > > clicking. > > > > > > If the primary purpose of the layer manager is to select the color, then > > > a single left click should > > > open the color dialog. > > > > This isn't "the layer manager", it's a color well IN the layer manager. > > > > > > > > If the single left click opens the dialog, be sure many times, when > > > clicking inside the layer > > > manager, you will open the dialog, instead of changing the active layer, > > > especially if you are too > > > busy clicking on the window to verify the exact position of the mouse. > > > (It frequently happened to me when the single click was opening the > > > dialog) > > > > > > A wise decision is never obvious. > > > (A reason like "other applications do that" is not necessary a good > > > reason. > > > Each application has its constraints and its compromises) > > > > YES IT IS. Consistency is the single most important way to make an > > interface understandable. A box containing a color is a color well, and > > color wells behave the exact same way in everything that isn't kicad. > > > > Next you'll tell me "File->Open opening a file in other applications is > > not a good reason it shouldn't display a photo of a llama in KiCad". > > > > > > > > > > > > >> > > > >> On 2/21/2017 8:04 AM, John Beard wrote: > > > >>> Hi, > > > >>> > > > >>> These patches fix the layer/render widget swatches in Linux under new > > > >>> GTK+ toolkits. Fix for: https://bugs.launchpad.net/kicad/+bug/1605411 > > > >>> > > > >>> The patches remove the "button" nature of the swatches, since they > > > >>> weren't actually actuated by a single click, so the button affordance > > > >>> was misleading anyway. Also on OSX, the button was invisible, so it > > > >>> just looked like a flat swatch anyway. > > > >>> > > > >>> * Linux as it was: > > > >>> https://drive.google.com/file/d/0BxVhl5qZbpYoZlZPeXV1Q0ttT2s/view > > > >>> * OSX as it was: > > > >>> https://launchpadlibrarian.net/274428737/Screen%20Shot%202016-07-22%20at%2019.40.14.png > > > >>> * Linux after this patch: see attachment > > > >>> > > > >>> This is followed by a refactor to pull the swatch logic out of the > > > >>> layer widget into common, where it can be use
Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux
Yup. I'd probably consider moving the elements around a bit so that "Select working layer" isn't broken into two sections. On Tue, Feb 21, 2017 at 12:54:51PM -0500, Jon Evans wrote: > FWIW, this is what my expecations were as a new user when I started with > KiCad (for what would happen with a single left-click) based on how things > work in other applications with layer managers I have used (ECAD, graphics, > etc): > > http://i.imgur.com/Euh2Gjwl.png > > -Jon > > On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina > wrote: > > > By the way. > > > > https://forum.kicad.info/t/developer-feedback-poll-layer-manager/5421 > > > > Feel free to add your own responses. The results look pretty conclusive > > right now ;) > > > > On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote: > > > Sent to wrong recipient. > > > > > > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote: > > > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote: > > > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit : > > > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh wrote: > > > > > >> My only issue with this change is that the tooltip letting the > > user know > > > > > >> that a left button double click or a middle button click would > > allow > > > > > >> them to change the color is gone. Other than that, it looks > > great. I > > > > > >> like the use of Bind instead of Connect. Bind has a much cleaner > > > > > >> interface than Connect and according to the wx folks is the > > proper way > > > > > >> to handle events. > > > > > > > > > > > > The tooltip is useless, nobody is going to hover over them for long > > > > > > enough to see it. I was just talking to someone this morning who > > never > > > > > > found the tooltip because he was too busy clicking on the buttons > > to > > > > > > make them work. > > > > > > > > > > > > Every other color well in every other application opens its > > selection > > > > > > dialog with a single left click. Why can't ours? > > > > > > > > > > First you have to decide if the main purpose is to select the active > > layer or to change the color layer. > > > > > The answer will give also the answer to "Why can't ours". > > > > > > > > > > For me the answer is not obvious, but my opinion is: > > > > > the primary purpose of the layer manager is to select the working > > layer. > > > > > Therefore the single left click should change the layer, whatever > > you are clicking. > > > > > > > > > > If the primary purpose of the layer manager is to select the color, > > then a single left click should > > > > > open the color dialog. > > > > > > > > This isn't "the layer manager", it's a color well IN the layer manager. > > > > > > > > > > > > > > If the single left click opens the dialog, be sure many times, when > > clicking inside the layer > > > > > manager, you will open the dialog, instead of changing the active > > layer, especially if you are too > > > > > busy clicking on the window to verify the exact position of the > > mouse. > > > > > (It frequently happened to me when the single click was opening the > > dialog) > > > > > > > > > > A wise decision is never obvious. > > > > > (A reason like "other applications do that" is not necessary a good > > reason. > > > > > Each application has its constraints and its compromises) > > > > > > > > YES IT IS. Consistency is the single most important way to make an > > > > interface understandable. A box containing a color is a color well, and > > > > color wells behave the exact same way in everything that isn't kicad. > > > > > > > > Next you'll tell me "File->Open opening a file in other applications is > > > > not a good reason it shouldn't display a photo of a llama in KiCad". > > > > > > > > > > > > > > > > > > > > >> > > > > > >> On 2/21/2017 8:04 AM, John Beard wrote: > > > > > >>> Hi,
Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux
Maybe. I kinda like how it looks now though. Though I /would/ like the color squares to be made flat - mainly just because the little buttons clash with some gtk themes and look butt ugly. On Wed, Feb 22, 2017 at 07:02:37AM +1300, Simon Wells wrote: > could just turn it into a real table and use a highlight for selected row > > On 22 February 2017 at 06:56, Chris Pavlina wrote: > > Yup. I'd probably consider moving the elements around a bit so that > > "Select working layer" isn't broken into two sections. > > > > On Tue, Feb 21, 2017 at 12:54:51PM -0500, Jon Evans wrote: > >> FWIW, this is what my expecations were as a new user when I started with > >> KiCad (for what would happen with a single left-click) based on how things > >> work in other applications with layer managers I have used (ECAD, graphics, > >> etc): > >> > >> http://i.imgur.com/Euh2Gjwl.png > >> > >> -Jon > >> > >> On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina > >> wrote: > >> > >> > By the way. > >> > > >> > https://forum.kicad.info/t/developer-feedback-poll-layer-manager/5421 > >> > > >> > Feel free to add your own responses. The results look pretty conclusive > >> > right now ;) > >> > > >> > On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote: > >> > > Sent to wrong recipient. > >> > > > >> > > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote: > >> > > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote: > >> > > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit : > >> > > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh wrote: > >> > > > > >> My only issue with this change is that the tooltip letting the > >> > user know > >> > > > > >> that a left button double click or a middle button click would > >> > allow > >> > > > > >> them to change the color is gone. Other than that, it looks > >> > great. I > >> > > > > >> like the use of Bind instead of Connect. Bind has a much > >> > > > > >> cleaner > >> > > > > >> interface than Connect and according to the wx folks is the > >> > proper way > >> > > > > >> to handle events. > >> > > > > > > >> > > > > > The tooltip is useless, nobody is going to hover over them for > >> > > > > > long > >> > > > > > enough to see it. I was just talking to someone this morning who > >> > never > >> > > > > > found the tooltip because he was too busy clicking on the buttons > >> > to > >> > > > > > make them work. > >> > > > > > > >> > > > > > Every other color well in every other application opens its > >> > selection > >> > > > > > dialog with a single left click. Why can't ours? > >> > > > > > >> > > > > First you have to decide if the main purpose is to select the > >> > > > > active > >> > layer or to change the color layer. > >> > > > > The answer will give also the answer to "Why can't ours". > >> > > > > > >> > > > > For me the answer is not obvious, but my opinion is: > >> > > > > the primary purpose of the layer manager is to select the working > >> > layer. > >> > > > > Therefore the single left click should change the layer, whatever > >> > you are clicking. > >> > > > > > >> > > > > If the primary purpose of the layer manager is to select the color, > >> > then a single left click should > >> > > > > open the color dialog. > >> > > > > >> > > > This isn't "the layer manager", it's a color well IN the layer > >> > > > manager. > >> > > > > >> > > > > > >> > > > > If the single left click opens the dialog, be sure many times, when > >> > clicking inside the layer > >> > > > > manager, you will open the dialog, instead of changing the active > >> > layer, especially if you are too > >> > > > > busy clicking
Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux
On Tue, Feb 21, 2017 at 01:18:51PM -0500, Wayne Stambaugh wrote: > I can just hear users howling already when they left click the color > swatch thinking that they are selecting the layer and then have to > dismiss the color select dialog to continue working. If we cannot come > up with a better solution, it may be best to leave sleeping dogs lie. I > wonder how many of the 75% of voters in the poll would response to > having to dismiss the color selection dialog every time they > inadvertently left clicked the color button? This may be a case of > ignorance being bliss. Pfft, you always hear users howling. :P Did you see the suggestion in the thread to move the color boxes to the other side to avoid accidental clicks? FWIW I don't think I've ever accidentally clicked one of them. > > On 2/21/2017 12:54 PM, Jon Evans wrote: > > FWIW, this is what my expecations were as a new user when I started with > > KiCad (for what would happen with a single left-click) based on how > > things work in other applications with layer managers I have used (ECAD, > > graphics, etc): > > > > http://i.imgur.com/Euh2Gjwl.png > > > > -Jon > > > > On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina > <mailto:pavlina.ch...@gmail.com>> wrote: > > > > By the way. > > > > https://forum.kicad.info/t/developer-feedback-poll-layer-manager/5421 > > <https://forum.kicad.info/t/developer-feedback-poll-layer-manager/5421> > > > > Feel free to add your own responses. The results look pretty conclusive > > right now ;) > > > > On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote: > > > Sent to wrong recipient. > > > > > > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote: > > > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote: > > > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit : > > > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh wrote: > > > > > >> My only issue with this change is that the tooltip letting > > the user know > > > > > >> that a left button double click or a middle button click > > would allow > > > > > >> them to change the color is gone. Other than that, it > > looks great. I > > > > > >> like the use of Bind instead of Connect. Bind has a much > > cleaner > > > > > >> interface than Connect and according to the wx folks is the > > proper way > > > > > >> to handle events. > > > > > > > > > > > > The tooltip is useless, nobody is going to hover over them > > for long > > > > > > enough to see it. I was just talking to someone this morning > > who never > > > > > > found the tooltip because he was too busy clicking on the > > buttons to > > > > > > make them work. > > > > > > > > > > > > Every other color well in every other application opens its > > selection > > > > > > dialog with a single left click. Why can't ours? > > > > > > > > > > First you have to decide if the main purpose is to select the > > active layer or to change the color layer. > > > > > The answer will give also the answer to "Why can't ours". > > > > > > > > > > For me the answer is not obvious, but my opinion is: > > > > > the primary purpose of the layer manager is to select the > > working layer. > > > > > Therefore the single left click should change the layer, > > whatever you are clicking. > > > > > > > > > > If the primary purpose of the layer manager is to select the > > color, then a single left click should > > > > > open the color dialog. > > > > > > > > This isn't "the layer manager", it's a color well IN the layer > > manager. > > > > > > > > > > > > > > If the single left click opens the dialog, be sure many times, > > when clicking inside the layer > > > > > manager, you will open the dialog, instead of changing the > > active layer, especially if you are too > > > > > busy clicking on the window to verify the exact position of > > the m
Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux
On Tue, Feb 21, 2017 at 01:26:17PM -0500, Jon Evans wrote: > Yeah, this is going to be a problem any time there is a situation where > KiCad does it differently than "the standard", but has been doing it that > way forever. No easy fix that pleases both the old users and the new > users. Other open source software has had this problem too (GIMP, etc) A part of me really wants to fork KiCad, spend a year or so removing ALL these silly KiCadisms that "users will howl about", and release it as a new de-crustified project with the understanding that everything will be different because everything was stupid before. I bet *checks sofa* $3.24 that users would flock to it. Sadly, that part of me lives in a fantasy world where days have 48 hours and I get paid megabucks to sit on my butt. > > My own thoughts on the matter are that I want to never have to change layer > using the layer picker, and always have it hidden. Based on the behavior > of other tools I have used, I think that it is possible to greatly reduce > the need to manually change layers, and especially to do so with the mouse > rather than a hotkey. > > -Jon > > On Tue, Feb 21, 2017 at 1:18 PM, Wayne Stambaugh > wrote: > > > I can just hear users howling already when they left click the color > > swatch thinking that they are selecting the layer and then have to > > dismiss the color select dialog to continue working. If we cannot come > > up with a better solution, it may be best to leave sleeping dogs lie. I > > wonder how many of the 75% of voters in the poll would response to > > having to dismiss the color selection dialog every time they > > inadvertently left clicked the color button? This may be a case of > > ignorance being bliss. > > > > On 2/21/2017 12:54 PM, Jon Evans wrote: > > > FWIW, this is what my expecations were as a new user when I started with > > > KiCad (for what would happen with a single left-click) based on how > > > things work in other applications with layer managers I have used (ECAD, > > > graphics, etc): > > > > > > http://i.imgur.com/Euh2Gjwl.png > > > > > > -Jon > > > > > > On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina > > <mailto:pavlina.ch...@gmail.com>> wrote: > > > > > > By the way. > > > > > > https://forum.kicad.info/t/developer-feedback-poll-layer- > > manager/5421 <https://forum.kicad.info/t/developer-feedback-poll-layer- > > manager/5421> > > > > > > Feel free to add your own responses. The results look pretty > > conclusive > > > right now ;) > > > > > > On Tue, Feb 21, 2017 at 11:40:05AM -0500, Chris Pavlina wrote: > > > > Sent to wrong recipient. > > > > > > > > On Tue, Feb 21, 2017 at 11:38:43AM -0500, Chris Pavlina wrote: > > > > > On Tue, Feb 21, 2017 at 05:24:14PM +0100, jp charras wrote: > > > > > > Le 21/02/2017 à 16:07, Chris Pavlina a écrit : > > > > > > > On Tue, Feb 21, 2017 at 09:35:34AM -0500, Wayne Stambaugh > > wrote: > > > > > > >> My only issue with this change is that the tooltip letting > > > the user know > > > > > > >> that a left button double click or a middle button click > > > would allow > > > > > > >> them to change the color is gone. Other than that, it > > > looks great. I > > > > > > >> like the use of Bind instead of Connect. Bind has a much > > > cleaner > > > > > > >> interface than Connect and according to the wx folks is the > > > proper way > > > > > > >> to handle events. > > > > > > > > > > > > > > The tooltip is useless, nobody is going to hover over them > > > for long > > > > > > > enough to see it. I was just talking to someone this morning > > > who never > > > > > > > found the tooltip because he was too busy clicking on the > > > buttons to > > > > > > > make them work. > > > > > > > > > > > > > > Every other color well in every other application opens its > > > selection > > > > > > > dialog with a single left click. Why can't ours? > > > > > > > > > > > > First you have to decide if the main purpose is to select the > > > active l
Re: [Kicad-developers] [PATCH] Fix layer color swatches in Linux
This is why I work on KiCad, I figure if I spend enough time on this I'll never make it to old age >:) On Tue, Feb 21, 2017 at 06:45:10PM -0500, Wayne Stambaugh wrote: > It's hell getting old! :) > > On 2/21/2017 6:43 PM, Simon Wells wrote: > > haha your advanced life experience must be getting to you you even > > commented on it when it was last bought up on the list > > https://lists.launchpad.net/kicad-developers/msg23387.html > > > > On 22 February 2017 at 12:39, Wayne Stambaugh wrote: > >> Why don't I remember that? It must not have been that way for very > >> long. In any event, I'm actually fine with changing it to a single left > >> click. We could always undo it if user's absolutely hate it. > >> > >> On 2/21/2017 1:43 PM, Simon Wells wrote: > >>> there was a time where it was single click changes colour and there > >>> were no complaints that i saw. JP changed it without consultation or > >>> comment on the list > >>> > >>> On 22 February 2017 at 07:30, Chris Pavlina > >>> wrote: > >>>> On Tue, Feb 21, 2017 at 01:26:17PM -0500, Jon Evans wrote: > >>>>> Yeah, this is going to be a problem any time there is a situation where > >>>>> KiCad does it differently than "the standard", but has been doing it > >>>>> that > >>>>> way forever. No easy fix that pleases both the old users and the new > >>>>> users. Other open source software has had this problem too (GIMP, etc) > >>>> > >>>> A part of me really wants to fork KiCad, spend a year or so removing ALL > >>>> these silly KiCadisms that "users will howl about", and release it as a > >>>> new de-crustified project with the understanding that everything will be > >>>> different because everything was stupid before. I bet *checks sofa* > >>>> $3.24 that users would flock to it. > >>>> > >>>> Sadly, that part of me lives in a fantasy world where days have 48 hours > >>>> and I get paid megabucks to sit on my butt. > >>>> > >>>>> > >>>>> My own thoughts on the matter are that I want to never have to change > >>>>> layer > >>>>> using the layer picker, and always have it hidden. Based on the > >>>>> behavior > >>>>> of other tools I have used, I think that it is possible to greatly > >>>>> reduce > >>>>> the need to manually change layers, and especially to do so with the > >>>>> mouse > >>>>> rather than a hotkey. > >>>>> > >>>>> -Jon > >>>>> > >>>>> On Tue, Feb 21, 2017 at 1:18 PM, Wayne Stambaugh > >>>>> wrote: > >>>>> > >>>>>> I can just hear users howling already when they left click the color > >>>>>> swatch thinking that they are selecting the layer and then have to > >>>>>> dismiss the color select dialog to continue working. If we cannot come > >>>>>> up with a better solution, it may be best to leave sleeping dogs lie. > >>>>>> I > >>>>>> wonder how many of the 75% of voters in the poll would response to > >>>>>> having to dismiss the color selection dialog every time they > >>>>>> inadvertently left clicked the color button? This may be a case of > >>>>>> ignorance being bliss. > >>>>>> > >>>>>> On 2/21/2017 12:54 PM, Jon Evans wrote: > >>>>>>> FWIW, this is what my expecations were as a new user when I started > >>>>>>> with > >>>>>>> KiCad (for what would happen with a single left-click) based on how > >>>>>>> things work in other applications with layer managers I have used > >>>>>>> (ECAD, > >>>>>>> graphics, etc): > >>>>>>> > >>>>>>> http://i.imgur.com/Euh2Gjwl.png > >>>>>>> > >>>>>>> -Jon > >>>>>>> > >>>>>>> On Tue, Feb 21, 2017 at 12:04 PM, Chris Pavlina > >>>>>>> >>>>>>> <mailto:pavlina.ch...@gmail.com>> wrote: > >>>>>>> > >>>>>>> By the way. > >&
Re: [Kicad-developers] [PATCH] Change from EDA_COLOR_T to COLOR4D and arbitrary color support
I'll have a look at MacOS build tonight if Diogo doesn't figure it out first. On Feb 22, 2017 1:57 PM, "Jon Evans" wrote: > Hi Diogo, > > Unfortunately I cannot test on Mac OS at all, and can't test on any > platform this minute. > But, I think you have to change that line to: > > wxPen pen( GetParent()->GetGridColor().ToColour(), h ); > > -Jon > > On Wed, Feb 22, 2017 at 1:05 PM, Diogo Condeço > wrote: > >> Hi Jon, >> >> Your patch 0001 on this thread introduced a bug which makes kicad unable >> to build... >> >> a52250a91e24733ce798ad8baa4597032d49d11e this was the commit. >> >> kicad/common/draw_panel.cpp:757:15: error: no matching constructor for >> initialization of 'wxPen' >> wxPen pen( GetParent()->GetGridColor(), h ); >> >> >> This is on a macos machine with clang. >> >> Thanks, >> >> Diogo >> >> >> On Wed, Feb 22, 2017 at 4:56 PM, Maciej Sumiński > > wrote: >> >>> Great, so now they are in the master repository. Thank you for the >>> patches. >>> >>> Regards, >>> Orson >>> >>> On 02/22/2017 02:10 PM, Jon Evans wrote: >>> > Yes, they are ready to merge. >>> > >>> > Best, >>> > Jon >>> > >>> > On Feb 22, 2017 03:37, "Maciej Sumiński" >>> wrote: >>> > >>> >> I got a response from Wayne saying he is ok with the changes (I >>> suppose >>> >> the mail was meant to be sent here). Do you think the patches ready to >>> >> be merged? They seem complete to me, but I just want to confirm. >>> >> >>> >> Regards, >>> >> Orson >>> >> >>> >> On 02/20/2017 06:55 PM, Jon Evans wrote: >>> >>> Thanks Orson, no I don't mind changing to static consts! >>> >>> >>> >>> Best, >>> >>> Jon >>> >>> >>> >>> On Mon, Feb 20, 2017 at 12:50 PM, Maciej Sumiński < >>> >> maciej.sumin...@cern.ch> >>> >>> wrote: >>> >>> >>> Hi Jon, >>> >>> I have just tested the patch, and I really like it. I just need to >>> test >>> it a bit longer, as there are numerous changes, but I am in favor of >>> merging the patch. >>> >>> I also applied one more patch changing a few defines (UNSPECIFIED, >>> BLACK, WHITE) to static consts, I hope you do not mind. >>> >>> If there are other people interested in testing, I have rebased the >>> changes [1] on the current master. There are also a few minor code >>> formatting fixes. >>> >>> Regards, >>> Orson >>> >>> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/c >>> olors >>> >>> On 02/18/2017 09:24 PM, Jon Evans wrote: >>> > Hi all, >>> > >>> > Attached is a follow-up patch to the COLOR4D change above -- I >>> reverted >>> > from using wxColourPickerCtrl back to wxBitmapButton in the >>> eeschema >>> color >>> > config, because I finally got my Windows 10 testing environment >>> set up, >>> and >>> > found out that for some reason wxColourPickerCtrl looks really >>> ugly in >>> > Windows 10. >>> > >>> > Best, >>> > Jon >>> > >>> > On Fri, Feb 10, 2017 at 8:43 PM, Jon Evans >>> wrote: >>> > >>> >> Hi all, >>> >> >>> >> Attached is a (rather large!) patch that changes the internal >>> color >>> >> representation to COLOR4D across the codebase (except for places >>> that >>> >> directly deal with wx, where wxColour is used). >>> >> >>> >> This patch also enables arbitrary color selection for schematic >>> and >>> symbol >>> >> library editor, as well as pcbnew in the GAL canvas. GerbView and >>> pcbnew >>> >> legacy canvas still use the old color picker. Colors will be >>> coerced >>> into >>> >> the legacy palette when switching from GAL to legacy, in a way >>> that >>> tries >>> >> to preserve the hue and value. >>> >> >>> >> Colors are serialized to the settings in CSS format, because it >>> >> supports >>> >> alpha and represents color components the same way COLOR4D does >>> (as >>> >> floating-point values from 0 to 1) >>> >> >>> >> Tested on Linux. Can't test on Windows or Mac yet, sorry. >>> >> I realize this is a large changeset and might take a while to >>> review, >>> >> so >>> >> just ping me if it stops applying on master and I'll update it. >>> >> >>> >> Best, >>> >> Jon >>> >> >>> > >>> > >>> > >>> > ___ >>> > 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] [PATCH] Change from EDA_COLOR_T to COLOR4D and arbitrary color support
Thank you, Diogo - I've got this patch and am currently looking over the other MacOS build errors related to this. I'll push both this and anything else I come up with when I'm done. On Wed, Feb 22, 2017 at 07:11:03PM +, Diogo Condeço wrote: > Hi Jon, > > Thanks that was the issue... > > Attached is a patch for this issue... Please credit Jon with it... > > Thanks, > Diogo > > On Wed, Feb 22, 2017 at 7:01 PM, Jon Evans wrote: > > > Thanks Chris. > > That line was hidden inside an #if block that only compiles for Mac, so > > it's possible there are others that also need to be fixed -- anywhere > > expecting a wxColour will now get COLOR4D and needs the ".ToColour()" > > added. Unfortunately I can't search through the code right now, but will > > also be more available in ~6 hours > > > > -Jon > > > > On Wed, Feb 22, 2017 at 1:59 PM, Chris Pavlina > > wrote: > > > >> I'll have a look at MacOS build tonight if Diogo doesn't figure it out > >> first. > >> > >> On Feb 22, 2017 1:57 PM, "Jon Evans" wrote: > >> > >>> Hi Diogo, > >>> > >>> Unfortunately I cannot test on Mac OS at all, and can't test on any > >>> platform this minute. > >>> But, I think you have to change that line to: > >>> > >>> wxPen pen( GetParent()->GetGridColor().ToColour(), h ); > >>> > >>> -Jon > >>> > >>> On Wed, Feb 22, 2017 at 1:05 PM, Diogo Condeço > >>> wrote: > >>> > >>>> Hi Jon, > >>>> > >>>> Your patch 0001 on this thread introduced a bug which makes kicad > >>>> unable to build... > >>>> > >>>> a52250a91e24733ce798ad8baa4597032d49d11e this was the commit. > >>>> > >>>> kicad/common/draw_panel.cpp:757:15: error: no matching constructor for > >>>> initialization of 'wxPen' > >>>> wxPen pen( GetParent()->GetGridColor(), h ); > >>>> > >>>> > >>>> This is on a macos machine with clang. > >>>> > >>>> Thanks, > >>>> > >>>> Diogo > >>>> > >>>> > >>>> On Wed, Feb 22, 2017 at 4:56 PM, Maciej Sumiński < > >>>> maciej.sumin...@cern.ch> wrote: > >>>> > >>>>> Great, so now they are in the master repository. Thank you for the > >>>>> patches. > >>>>> > >>>>> Regards, > >>>>> Orson > >>>>> > >>>>> On 02/22/2017 02:10 PM, Jon Evans wrote: > >>>>> > Yes, they are ready to merge. > >>>>> > > >>>>> > Best, > >>>>> > Jon > >>>>> > > >>>>> > On Feb 22, 2017 03:37, "Maciej Sumiński" > >>>>> wrote: > >>>>> > > >>>>> >> I got a response from Wayne saying he is ok with the changes (I > >>>>> suppose > >>>>> >> the mail was meant to be sent here). Do you think the patches ready > >>>>> to > >>>>> >> be merged? They seem complete to me, but I just want to confirm. > >>>>> >> > >>>>> >> Regards, > >>>>> >> Orson > >>>>> >> > >>>>> >> On 02/20/2017 06:55 PM, Jon Evans wrote: > >>>>> >>> Thanks Orson, no I don't mind changing to static consts! > >>>>> >>> > >>>>> >>> Best, > >>>>> >>> Jon > >>>>> >>> > >>>>> >>> On Mon, Feb 20, 2017 at 12:50 PM, Maciej Sumiński < > >>>>> >> maciej.sumin...@cern.ch> > >>>>> >>> wrote: > >>>>> >>> > >>>>> >>>> Hi Jon, > >>>>> >>>> > >>>>> >>>> I have just tested the patch, and I really like it. I just need > >>>>> to test > >>>>> >>>> it a bit longer, as there are numerous changes, but I am in favor > >>>>> of > >>>>> >>>> merging the patch. > >>>>> >>>> > >>>>> >>>> I also applied one more pa
[Kicad-developers] [PATCH] Fix MacOS coroutine segfault
Hi,
pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
dereference in the coroutine code:
coroutine.h
408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* aArgsPtr
)
409{
410const auto& args = *aArgsPtr;
411auto* cor = args.destination;
aArgsPtr is null and I don't understand WHY. However, I was able to make
things appear to work by short-circuiting this function if the argument
is null.
Patch attached. It Works For Me™, but I'd like someone who knows the
coroutine code to look and make sure I haven't made a mess of things.
--
Chris
>From 872d6aa16cb027dfc04da18daab85168da40fa71 Mon Sep 17 00:00:00 2001
From: Chris Pavlina
Date: Wed, 22 Feb 2017 20:09:22 -0500
Subject: [PATCH] Fix MacOS coroutine segfault
---
include/tool/coroutine.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/tool/coroutine.h b/include/tool/coroutine.h
index 36171a757..231e47a2a 100644
--- a/include/tool/coroutine.h
+++ b/include/tool/coroutine.h
@@ -407,6 +407,9 @@ private:
/* real entry point of the coroutine */
static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS* aArgsPtr )
{
+if( !aArgsPtr )
+return std::move( caller );
+
const auto& args = *aArgsPtr;
auto* cor = args.destination;
--
2.11.1
___
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] [PATCH] Fix MacOS coroutine segfault
Backtrace attached. Boost is 1.63.0.
On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> Hi Chris,
>
> Would you give more details about the problem? Boost version, backtrace?
>
> Regards,
> Orson
>
> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
> > Hi,
> >
> > pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
> > dereference in the coroutine code:
> >
> > coroutine.h
> > 408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS*
> > aArgsPtr )
> > 409{
> > 410const auto& args = *aArgsPtr;
> > 411auto* cor = args.destination;
> >
> > aArgsPtr is null and I don't understand WHY. However, I was able to make
> > things appear to work by short-circuiting this function if the argument
> > is null.
> >
> > Patch attached. It Works For Me™, but I'd like someone who knows the
> > coroutine code to look and make sure I haven't made a mess of things.
> >
> >
> >
> > ___
> > 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
> >
>
>
(lldb) bt
* thread #1: tid = 0x4fa9, 0x00010ea6aaf1 _pcbnew.kiface`COROUTINE::callerStub(caller=(fctx_ = 0x7fff5fbfc3d0),
aArgsPtr=0x) + 17 at coroutine.h:411, queue =
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
* frame #0: 0x00010ea6aaf1 _pcbnew.kiface`COROUTINE::callerStub(caller=(fctx_ = 0x7fff5fbfc3d0),
aArgsPtr=0x) + 17 at coroutine.h:411 [opt]
frame #1: 0x00010ea6ae13
_pcbnew.kiface`std::__1::enable_if::INVOCATION_ARGS*>
(*)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>::type>::value),
std::__1::result_of::INVOCATION_ARGS*> (*&&
(boost::context::execution_context::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*&&))(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>::type>::type
boost::context::detail::invoke::INVOCATION_ARGS*> (fn=, args=,
args=)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*), boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*>(boost::context::execution_context::INVOCATION_ARGS*>
(*&&)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*), boost::context::execution_context::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*&&) + 35 at invoke.hpp:41 [opt]
frame #2: 0x00010ea6ad4d
_pcbnew.kiface`boost::context::detail::record::INVOCATION_ARGS*>,
boost::context::basic_protected_fixedsize_stack,
boost::context::execution_context::INVOCATION_ARGS*> (*)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>::run(boost::context::detail::transfer_t) [inlined]
decltype(fn=)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>(fp)std::get<0ul,
1ul>(std::forward::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*> >(fp0
boost::context::detail::apply_impl::INVOCATION_ARGS*>
(*)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*),
std::__1::tuple::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*>, 0ul,
1ul>(boost::context::execution_context::INVOCATION_ARGS*>
(*&&)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*),
std::__1::tuple::INVOCATION_ARGS*>&&, COROUTINE::INVOCATION_ARGS*>&&, boost::context::detail::index_sequence<0ul, 1ul>)
+ 45 at apply.hpp:46 [opt]
frame #3: 0x00010ea6ad44
_pcbnew.kiface`boost::context::detail::record::INVOCATION_ARGS*>,
boost::context::basic_protected_fixedsize_stack,
boost::context::execution_context::INVOCATION_ARGS*> (*)(boost::context::execution_context::INVOCATION_ARGS*>, COROUTINE::INVOCATION_ARGS*)>::run(boost::context::detail::transfer_t) [inlined]
_ZN5boost7context6detail5applyIPFNS0_17execution_contextIJPN9COROUTINEIiRK10TOOL_EVENTE15INVOCATION_ARGSSB_SA_ENSt3__15tupleIJOSB_SA_EDTcl10apply_implclsr3stdE7forwardIT_Efp_Eclsr3stdE7forwardIT0_Efp0_EcvNS1_19make_index_sequenceIXsr3std10tuple_sizeINSE_5decayISJ_E4typeEEE5valueEEEilEEEOSI_OSJ_(fn=)
at apply.hpp:59 [opt]
frame #4: 0x00010ea6ad44
_pcbnew.kiface`boost::context::detail::record::INVOCATION_ARGS*>,
boost::context::basic_protected_fixedsize_stack,
boost::context::execution_context::INVOCATION_ARGS*> (*)(boost::context::ex
Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault
Heh, okay, I should have tested more. Seems GAL is quite completely
broken after this patch, do not apply :P
On Thu, Feb 23, 2017 at 06:38:39AM -0500, Chris Pavlina wrote:
> Backtrace attached. Boost is 1.63.0.
>
> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> > Hi Chris,
> >
> > Would you give more details about the problem? Boost version, backtrace?
> >
> > Regards,
> > Orson
> >
> > On 02/23/2017 02:23 AM, Chris Pavlina wrote:
> > > Hi,
> > >
> > > pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
> > > dereference in the coroutine code:
> > >
> > > coroutine.h
> > > 408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS*
> > > aArgsPtr )
> > > 409{
> > > 410const auto& args = *aArgsPtr;
> > > 411auto* cor = args.destination;
> > >
> > > aArgsPtr is null and I don't understand WHY. However, I was able to make
> > > things appear to work by short-circuiting this function if the argument
> > > is null.
> > >
> > > Patch attached. It Works For Me™, but I'd like someone who knows the
> > > coroutine code to look and make sure I haven't made a mess of things.
> > >
> > >
> > >
> > > ___
> > > 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
[Kicad-developers] Coroutines, in general
Hi, Just out of curiosity, I'm not sure what the reasoning is here and nobody on IRC really knew last night --- can anyone explain why we use boost::context with our own coroutine implementation on top, rather than using boost::coroutine? Seems the latter has a much more stable API, is it missing something we require? -- Chris ___ 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] Stable release 4.0.6
In the future we should probably look into making our releases a bit more coordinated. https://forum.kicad.info/t/4-0-6-for-ubuntu-is-out/5441 On Tue, Feb 14, 2017 at 09:26:21AM -0500, Wayne Stambaugh wrote: > Are there any outstanding issues to prevent rolling out a 4.0.6 stable > release? If not, I will set the version string and tag that commit as > 4.0.6. How much time do our source translators, doc devs, and library > devs need to have everything ready? > > Thanks, > > 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] Coroutines, in general
Fair enough. Has coroutine really been as bad as context though? Seems we've had to resort to using some internal API functions in context, which really seems to be screwing us over.. :P On Thu, Feb 23, 2017 at 02:27:59PM +0100, Tomasz Wlostowski wrote: > On 23.02.2017 14:17, Chris Pavlina wrote: > > boost::coroutine? Seems the latter has a much more stable API, is > > it missing something we require? > > Hi Chris, > > I can't agree that either boost::context or boost::coroutine have stable > APIs, that's why have our own wrapper on top... > > Cheers, > Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Torrents for KiCad distribution
No plans currently. Do you think enough people would use them for it to really work? On Feb 23, 2017 9:06 AM, "Ingo Kletti" wrote: > Hello, > > currently the stable releases are distributed as direct downloads from > kicad- > pcb.org. Are there any plans for distributing the stable releases as > torrents? > > Regards, > > Ingo > > -- > --- > > HTWG Konstanz > Hochschule Technik, Wirtschaft und Gestaltung > > Fakultät Elektrotechnik und Informationstechnik > Dipl.-Ing. (FH) Ingo Kletti > > Alfred-Wachtel-Strasse 8 > 78462 Konstanz > Germany > > Telefon: +49 (0)7531/206-263 > Fax: +49 (0)7531/206-87263 > E-Mail: ikle...@htwg-konstanz.de > URL: http://www.htwg-konstanz.de > > > ___ > 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] Optimization flags in 3d-viewer
On Thu, Feb 23, 2017 at 11:45:40AM -0500, Mark Roszko wrote: > Does -O3 really have that much of an improvement though? I assume the > only thing cpu bound thing in the 3d viewer is the raytracing. Even on CPU-bound things -O3 tends not to be too much of an improvement on both gcc and clang. -O2 is already very good. > > > If you really want speed you would throw in PGO :P. > > ___ > 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] Torrents for KiCad distribution
On Thu, Feb 23, 2017 at 08:02:55PM +0100, Ingo Kletti wrote: > Am Donnerstag, 23. Februar 2017, 09:49:41 schrieben Sie: > > No plans currently. Do you think enough people would use them for it to > > really work? > > I have no idea and, as far as I understood the concept of torrents, you could > not tell the number of downloads, just a sum of Bytes transferred (provided > the tracker server keeps a record of this). > > Using torrents to distribute KiCad was an idea that came up today since the > next stable release is only a few days away and providing torrents could > probably remedy the hammering of the server during the first days. Agreed, if people would actually use them it'd be a decent way to lighten the server's load. I wouldn't mind it myself, certainly, but then I'm not a packager > > Regards, > > Ingo > > ___ > 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] Optimization flags in 3d-viewer
On Thu, Feb 23, 2017 at 03:48:39PM +, Mário Luzeiro wrote: > Yes I added it, because for 3D we need *speed* :P Things like this are speed holes. https://youtu.be/whnms4CLJys?t=42 *Please* do not add speed holes. If your code is not faster, add optimizations you understand, and remove them after testing if they do not show a marked improvement. This just makes the build messy... > > What kind of warnings it is causing? O_o > > Mario > > From: Kicad-developers > [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of > Simon Richter [simon.rich...@hogyros.de] > Sent: 23 February 2017 15:25 > To: KiCad Developers > Subject: [Kicad-developers] Optimization flags in 3d-viewer > > Hi, > > in 3d-viewer/CMakeLists.txt we have > > set( CMAKE_C_FLAGS_RELEASE "-O3" ) > set( CMAKE_CXX_FLAGS_RELEASE "-O3" ) > > Is that intentional? > > - it seems to be unused in the Make based builds > - it overwrites any existing flags in these variables > - it causes warnings on MSVC > >Simon > > > ___ > 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] Optimization flags in 3d-viewer
It's okay if you paint the code red though. That really does make it go faster. Stripes are dope too. On Thu, Feb 23, 2017 at 10:27:36PM +, Mário Luzeiro wrote: > I am *sorry* > > Mario > > ____ > From: Chris Pavlina [pavlina.ch...@gmail.com] > Sent: 23 February 2017 22:06 > To: Mário Luzeiro > Cc: Simon Richter; KiCad Developers > Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer > > On Thu, Feb 23, 2017 at 03:48:39PM +, Mário Luzeiro wrote: > > Yes I added it, because for 3D we need *speed* :P > > Things like this are speed holes. https://youtu.be/whnms4CLJys?t=42 > > *Please* do not add speed holes. If your code is not faster, add > optimizations you understand, and remove them after testing if they do > not show a marked improvement. This just makes the build messy... > > > > > What kind of warnings it is causing? O_o > > > > Mario > > > > From: Kicad-developers > > [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf of > > Simon Richter [simon.rich...@hogyros.de] > > Sent: 23 February 2017 15:25 > > To: KiCad Developers > > Subject: [Kicad-developers] Optimization flags in 3d-viewer > > > > Hi, > > > > in 3d-viewer/CMakeLists.txt we have > > > > set( CMAKE_C_FLAGS_RELEASE "-O3" ) > > set( CMAKE_CXX_FLAGS_RELEASE "-O3" ) > > > > Is that intentional? > > > > - it seems to be unused in the Make based builds > > - it overwrites any existing flags in these variables > > - it causes warnings on MSVC > > > >Simon > > > > > > ___ > > 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] Optimization flags in 3d-viewer
Keep it up, your eye candy is excellent :D On Thu, Feb 23, 2017 at 10:43:54PM +, Mário Luzeiro wrote: > I will! That's my style... That's why I bring the "eye candy wow! factor" to > the KiCad's 3D viewer! > ________ > From: Chris Pavlina [pavlina.ch...@gmail.com] > Sent: 23 February 2017 22:31 > To: Mário Luzeiro > Cc: Simon Richter; KiCad Developers > Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer > > It's okay if you paint the code red though. That really does make it go > faster. Stripes are dope too. > > On Thu, Feb 23, 2017 at 10:27:36PM +, Mário Luzeiro wrote: > > I am *sorry* > > > > Mario > > > > > > From: Chris Pavlina [pavlina.ch...@gmail.com] > > Sent: 23 February 2017 22:06 > > To: Mário Luzeiro > > Cc: Simon Richter; KiCad Developers > > Subject: Re: [Kicad-developers] Optimization flags in 3d-viewer > > > > On Thu, Feb 23, 2017 at 03:48:39PM +, Mário Luzeiro wrote: > > > Yes I added it, because for 3D we need *speed* :P > > > > Things like this are speed holes. https://youtu.be/whnms4CLJys?t=42 > > > > *Please* do not add speed holes. If your code is not faster, add > > optimizations you understand, and remove them after testing if they do > > not show a marked improvement. This just makes the build messy... > > > > > > > > What kind of warnings it is causing? O_o > > > > > > Mario > > > > > > From: Kicad-developers > > > [kicad-developers-bounces+mrluzeiro=ua...@lists.launchpad.net] on behalf > > > of Simon Richter [simon.rich...@hogyros.de] > > > Sent: 23 February 2017 15:25 > > > To: KiCad Developers > > > Subject: [Kicad-developers] Optimization flags in 3d-viewer > > > > > > Hi, > > > > > > in 3d-viewer/CMakeLists.txt we have > > > > > > set( CMAKE_C_FLAGS_RELEASE "-O3" ) > > > set( CMAKE_CXX_FLAGS_RELEASE "-O3" ) > > > > > > Is that intentional? > > > > > > - it seems to be unused in the Make based builds > > > - it overwrites any existing flags in these variables > > > - it causes warnings on MSVC > > > > > >Simon > > > > > > > > > ___ > > > 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
[Kicad-developers] Attn Wayne: Optimizing SCH_PLUGIN for component selection
Hi all and Wayne, Since the addition of SCH_PLUGIN, enumerating all symbols (done by the component selector) has become dog slow on Windows and macOS. I've tracked this down to the excursion from an alias list to a list of strings and back to an alias list, because the only functions SCH_PLUGIN provides to access the aliases are by name. This is why the component selector now takes literally five seconds to appear on Windows. I have a patch in progress that adds parallels to these API functions that directly populate a list of LIB_ALIASes rather than their names. I'm in the process of testing it on all three platforms. It is a fairly minor addition, but I don't want to touch SCH_PLUGIN without permission since Wayne is working on it. Wayne, are you okay with a patch that adds SCH_LEGACY_PLUGIN:: EnumerateSymbolLib( std::vector&, ... )? This is the only place it touches the plugin API, plus a couple places in PART_LIB and several in the component chooser. -- Chris ___ 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] Attn Wayne: Optimizing SCH_PLUGIN for component selection
On Fri, Feb 24, 2017 at 11:38:26AM -0500, Wayne Stambaugh wrote: > On 2/24/2017 11:29 AM, Chris Pavlina wrote: > > Hi all and Wayne, > > > > Since the addition of SCH_PLUGIN, enumerating all symbols (done by the > > component selector) has become dog slow on Windows and macOS. I've > > tracked this down to the excursion from an alias list to a list of > > strings and back to an alias list, because the only functions SCH_PLUGIN > > provides to access the aliases are by name. > > > > This is why the component selector now takes literally five seconds to > > appear on Windows. > > > > I have a patch in progress that adds parallels to these API functions > > that directly populate a list of LIB_ALIASes rather than their names. > > I'm in the process of testing it on all three platforms. It is a fairly > > minor addition, but I don't want to touch SCH_PLUGIN without permission > > since Wayne is working on it. > > > > Wayne, are you okay with a patch that adds SCH_LEGACY_PLUGIN:: > > EnumerateSymbolLib( std::vector&, ... )? This is the only > > place it touches the plugin API, plus a couple places in PART_LIB and > > several in the component chooser. > > > > If it temporarily resolves this issue, then I'm OK with it. It would be > nice to be able to limit the exposure of this plugin call for just the > current PART_LIBS implementation which will have to remain forever to > support legacy symbol lookup. Once symbol lookup by path goes away with > the symbol library table (in progress), this will not be necessary since > there will always be a one to one mapping of the symbol to a given > library. In other words there will be no symbol lookup. All symbol > access will be done by a full qualified LIB_ID. I'm not sure if I understand what you mean, but okay thanks, I'll push it soon :) How does symbol access "by a fully qualified LIB_ID" help for enumerating an entire library, such as what a component selector has to do in order to filter and sort and search through the library? Is there some sort of wildcard LIB_ID that returns a collection of symbols? > > > ___ > 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] Stable release 4.0.6
Yeah - my general impression from a number of inconsistencies in the file format vs. the spec is that KiCad's file format really should be considered implementation-defined. In order to have a _proper_ file format spec, it seems to be that two things need to be done: 1. Put the format spec _in the repository_ 2. Version it, and require anybody changing the format in the code to: a. Update the MMDD version that gets written to the file (technically we already require this, but I've seen a couple changes go in without doing this...) b. Make a new format spec version and document the change Until we do that, it's implementation-defined with a wannabe spec :P On Fri, Feb 24, 2017 at 11:23:42PM +0100, Nick Østergaard wrote: > Normally when we speak of "the docs" we are not talking about the > fileformat specs, but the stuff in https://github.com/KiCad/kicad-doc > > 2017-02-24 23:22 GMT+01:00 Kevin Cozens : > > On 2017-02-23 01:29 AM, Nick Østergaard wrote: > >> > >> The docs are not quite ready yet, > > > > > > Documentation is (almost) always the last thing to get written or updated. I > > was making use of the file formats document while working on a project of > > mine to convert schematics from another program in to one that can be read > > by Kicad. I found a lot of issues with the docs. > > > > I was told Wayne maintains that document. I'll be emailing him to find out > > what the procedure is for providing information about the changes needed. > > > > -- > > Cheers! > > > > Kevin. > > > > http://www.ve3syb.ca/ |"Nerds make the shiny things that distract > > Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're > > | powerful!" > > #include | --Chris Hardwick > > > > > > ___ > > 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] Stable release 4.0.6
On Sat, Feb 25, 2017 at 11:04:46AM -0500, Wayne Stambaugh wrote: > On 2/24/2017 5:22 PM, Kevin Cozens wrote: > > On 2017-02-23 01:29 AM, Nick Østergaard wrote: > >> The docs are not quite ready yet, > > > > Documentation is (almost) always the last thing to get written or > > updated. I was making use of the file formats document while working on > > a project of mine to convert schematics from another program in to one > > that can be read by Kicad. I found a lot of issues with the docs. > > > > I was told Wayne maintains that document. I'll be emailing him to find > > out what the procedure is for providing information about the changes > > needed. > > > > I do not maintain nor did I write any of the file format documents. I > believe JP wrote them and maintains them. I will try to do a better job > when I implement the new schematic and symbol library file formats but I > cannot promise anything. I fully intended on writing the new board and > footprint library file formats but I just couldn't find the time so JP > graciously stepped up and wrote them for me. Now that I am project > leader, I have even less time for such endeavors. I still think you should just put them in the repo with the code, and start requiring people to edit them when they change anything about the format. Much easier for you than having to maintain them yourself. Just require proper versioning so that there is a format document version corresponding to every format version. > > Cheers, > > 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] Stable release 4.0.6
On Sat, Feb 25, 2017 at 11:52:28AM -0500, Wayne Stambaugh wrote: > On 2/25/2017 11:28 AM, Chris Pavlina wrote: > > On Sat, Feb 25, 2017 at 11:04:46AM -0500, Wayne Stambaugh wrote: > >> On 2/24/2017 5:22 PM, Kevin Cozens wrote: > >>> On 2017-02-23 01:29 AM, Nick Østergaard wrote: > >>>> The docs are not quite ready yet, > >>> > >>> Documentation is (almost) always the last thing to get written or > >>> updated. I was making use of the file formats document while working on > >>> a project of mine to convert schematics from another program in to one > >>> that can be read by Kicad. I found a lot of issues with the docs. > >>> > >>> I was told Wayne maintains that document. I'll be emailing him to find > >>> out what the procedure is for providing information about the changes > >>> needed. > >>> > >> > >> I do not maintain nor did I write any of the file format documents. I > >> believe JP wrote them and maintains them. I will try to do a better job > >> when I implement the new schematic and symbol library file formats but I > >> cannot promise anything. I fully intended on writing the new board and > >> footprint library file formats but I just couldn't find the time so JP > >> graciously stepped up and wrote them for me. Now that I am project > >> leader, I have even less time for such endeavors. > > > > I still think you should just put them in the repo with the code, and > > start requiring people to edit them when they change anything about the > > format. Much easier for you than having to maintain them yourself. Just > > require proper versioning so that there is a format document version > > corresponding to every format version. > > I'm OK with that as long as we can reformat them to markdown to match > our current developer documentation. This way it gets automatically > generated and uploaded to the website. I'll happily convert them to Markdown. Send me the most recent versions just to make sure I've got the right documents. > > > > >> > >> Cheers, > >> > >> 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] Ubuntu build commit IDs
*Please*. I'm tired of people asking for support and making me figure out what "7735" is. We left bzr a long time ago now. On Sun, Feb 26, 2017 at 11:46:09PM +0800, John Beard wrote: > Hi, > > Would it be possible to get the ubuntu builds tagged with a commit > hash? Version strings like 201702251416+7735~57~ubuntu16.10.1 are not > very useful if you want to know exactly which commit a build relates > to. > > The exact commit is very useful when looking at a bug report from a > nightly. If a regression arises between one nightly and the next, the > date only approximately tells you where to start bisecting. > > The Bzr-style rev number is almost entirely useless especially when > the build is also tagged with a date, and Bzr is dead and gone. > Date+git rev give you both an incrementing number for quick > comparisons of age of build, and the git commit is an unambiguous > pointer to the exact commit. > > Nearly all "nightly" and "git tracker" pacakges (PPA, AUR, etc) put > the git hash in the build number, pretty much for this exact reason. > > Cheers, > > John > > ___ > 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
[Kicad-developers] Standalone mode.
Hi, There are a few problems with "standalone mode" that I see. One of the biggest is demonstrated [1] - kiway services aren't available. In my opinion this really is detrimental to the function of the software - e.g. eeschema shouldn't be missing features just because it was started in standalone. Another problem is the awkwardness of packaging/install on systems that expect applications to be discrete units, like macOS. There's some foreshadowing on the bug tracker of trouble wrt. signed packages, which I couldn't immediately dig up. I'd really like if we could change this. I don't think standalone mode the way we implement it is necessary. It is necessary that one can open a pure schematic file, or a pure PCB file, outside of the context of a project -- but I do NOT think this should require starting the individual application separately from the project manager. What if the project manager simply understood the concept of single files as well as projects? [1] https://bugs.launchpad.net/kicad/+bug/1668157 -- Chris ___ 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] New addition to the lead developer team.
Congrats, Tomasz! Here, you earned it: https://qph.ec.quoracdn.net/main-qimg-513ddac3314cb35edf042fc728e850d1-c On Mon, Feb 27, 2017 at 04:52:06PM -0500, Wayne Stambaugh wrote: > I have just given product and stable branch commit privileges to Tomasz > Wlostowski. Please join me in congratulating him for his promotion to > the lead development team. For those who don't know, Tom is responsible > for the P&S router, tool framework, and other significant pieces of > KiCad. Thank you Tom for all of your contributions to KiCad and welcome > aboard. > > Cheers, > > 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] [PATCH] Fix MacOS coroutine segfault
I am in favor of this.
On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote:
> I will do my best, but I really cannot promise any time slot for looking
> into the issue. Perhaps it is the time to revisit Tom's libcontext [1]?
> The number of #ifdefs in tge current coroutine code makes eyes pop out,
> and I am afraid with the new issue we would be forced to add "#ifdef
> __APPLE__" to this horrible mess.
>
> This way we should be immune to future boost::context changes. The
> drawback is, we are on our own if there is a new architecture to
> support. On the other hand, how often a new architecture becomes popular
> enough to care about it?
>
> To sum up: I would switch to libcontext and stop worrying.
>
> Regards,
> Orson
>
> 1. https://github.com/twlostow/libcontext
>
> On 02/23/2017 02:07 PM, Wayne Stambaugh wrote:
> > This is a known issue. I believe the last valid version of boost that
> > doesn't cause a crash is 1.61. Anything after that causes this issue on
> > all platforms not just osx. @Orson or @Tom, any chance you could take a
> > look at this to see what boost changed in the context library?
> >
> > Cheers,
> >
> > Wayne
> >
> > On 2/23/2017 6:49 AM, Simon Wells wrote:
> >> just fyi
> >>
> >> https://bugs.launchpad.net/kicad/+bug/1658249
> >>
> >> On 24 February 2017 at 00:38, Chris Pavlina
> >> wrote:
> >>> Backtrace attached. Boost is 1.63.0.
> >>>
> >>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> >>>> Hi Chris,
> >>>>
> >>>> Would you give more details about the problem? Boost version, backtrace?
> >>>>
> >>>> Regards,
> >>>> Orson
> >>>>
> >>>> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
> >>>>> Hi,
> >>>>>
> >>>>> pcbnew is segfaulting on launch on my MacOS Sierra build, due to a null
> >>>>> dereference in the coroutine code:
> >>>>>
> >>>>> coroutine.h
> >>>>> 408static CONTEXT_T callerStub( CONTEXT_T caller, INVOCATION_ARGS*
> >>>>> aArgsPtr )
> >>>>> 409{
> >>>>> 410const auto& args = *aArgsPtr;
> >>>>> 411auto* cor = args.destination;
> >>>>>
> >>>>> aArgsPtr is null and I don't understand WHY. However, I was able to make
> >>>>> things appear to work by short-circuiting this function if the argument
> >>>>> is null.
> >>>>>
> >>>>> Patch attached. It Works For Me™, but I'd like someone who knows the
> >>>>> coroutine code to look and make sure I haven't made a mess of things.
> >>>>>
> >>>>>
> >>>>>
> >>>>> ___
> >>>>> 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
> >>
> >
> > ___
> > 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] [PATCH] Fix MacOS coroutine segfault
Wayne *please* tell me you won't block something that fixes macOS
support and eliminates future boost API problems (which we've had
SEVERAL problems with in the past) because of a lack of support for
bloody *SPARC and PPC*. If there is a single user using KiCad on these
platforms I would like to see them.
Now, the lack of support for aarch64 is a disappointment, but it looks
like boost currently doesn't support that either.
On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote:
> On 01.03.2017 15:58, Wayne Stambaugh wrote:
> > I am in favor of this if and only if we have equivalent or better
> > architecture coverage compared to the boost context library. If not,
> > than I am opposed to it.
> >
> Hi Wayne,
>
> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not
> test the sparc/PPC ports for obvious reasons. I could add linux
> sparc/PPC support but without testing, since I don't have a suitable
> machine.
>
> For the moment, libcontext works on every OS/CPU we officially support.
>
> Cheers,
> Tom
>
>
> > On 3/1/2017 9:32 AM, Chris Pavlina wrote:
> >> I am in favor of this.
> >>
> >> On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote:
> >>> I will do my best, but I really cannot promise any time slot for looking
> >>> into the issue. Perhaps it is the time to revisit Tom's libcontext [1]?
> >>> The number of #ifdefs in tge current coroutine code makes eyes pop out,
> >>> and I am afraid with the new issue we would be forced to add "#ifdef
> >>> __APPLE__" to this horrible mess.
> >
> > This probably could have been hidden using cmake. It typically takes
> > more effort to do it this way but it results in cleaner source code.
> >
> >>>
> >>> This way we should be immune to future boost::context changes. The
> >>> drawback is, we are on our own if there is a new architecture to
> >>> support. On the other hand, how often a new architecture becomes popular
> >>> enough to care about it?
> >>>
> >>> To sum up: I would switch to libcontext and stop worrying.
> >>>
> >>> Regards,
> >>> Orson
> >>>
> >>> 1. https://github.com/twlostow/libcontext
> >>>
> >>> On 02/23/2017 02:07 PM, Wayne Stambaugh wrote:
> >>>> This is a known issue. I believe the last valid version of boost that
> >>>> doesn't cause a crash is 1.61. Anything after that causes this issue on
> >>>> all platforms not just osx. @Orson or @Tom, any chance you could take a
> >>>> look at this to see what boost changed in the context library?
> >>>>
> >>>> Cheers,
> >>>>
> >>>> Wayne
> >>>>
> >>>> On 2/23/2017 6:49 AM, Simon Wells wrote:
> >>>>> just fyi
> >>>>>
> >>>>> https://bugs.launchpad.net/kicad/+bug/1658249
> >>>>>
> >>>>> On 24 February 2017 at 00:38, Chris Pavlina
> >>>>> wrote:
> >>>>>> Backtrace attached. Boost is 1.63.0.
> >>>>>>
> >>>>>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote:
> >>>>>>> Hi Chris,
> >>>>>>>
> >>>>>>> Would you give more details about the problem? Boost version,
> >>>>>>> backtrace?
> >>>>>>>
> >>>>>>> Regards,
> >>>>>>> Orson
> >>>>>>>
> >>>>>>> On 02/23/2017 02:23 AM, Chris Pavlina wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> pcbnew is segfaulting on launch on my MacOS Sierra build, due to a
> >>>>>>>> null
> >>>>>>>> dereference in the coroutine code:
> >>>>>>>>
> >>>>>>>> coroutine.h
> >>>>>>>> 408static CONTEXT_T callerStub( CONTEXT_T caller,
> >>>>>>>> INVOCATION_ARGS* aArgsPtr )
> >>>>>>>> 409{
> >>>>>>>> 410const auto& args = *aArgsPtr;
> >>>>>>>> 411auto* cor = args.destination;
> >>>>>>>>
> >>>>>>>> aArgsPtr is null and I don't understand WHY. However, I was able to
> >>&g
Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault
Ah, crap. Missed that. Don't think I have one lying about anymore to volunteer... :( On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote: > On 01.03.2017 16:19, Chris Pavlina wrote: > > Wayne *please* tell me you won't block something that fixes macOS > > support and eliminates future boost API problems (which we've had > > SEVERAL problems with in the past) because of a lack of support for > > bloody *SPARC and PPC*. If there is a single user using KiCad on these > > platforms I would like to see them. > > > Hi Chris, > > Boost does support aarch64, I just lack a compiler/machine to test that... > > Cheers, > T. > > Now, the lack of support for aarch64 is a disappointment, but it looks > > like boost currently doesn't support that either. > > > > On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote: > >> On 01.03.2017 15:58, Wayne Stambaugh wrote: > >>> I am in favor of this if and only if we have equivalent or better > >>> architecture coverage compared to the boost context library. If not, > >>> than I am opposed to it. > >>> > >> Hi Wayne, > >> > >> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not > >> test the sparc/PPC ports for obvious reasons. I could add linux > >> sparc/PPC support but without testing, since I don't have a suitable > >> machine. > >> > >> For the moment, libcontext works on every OS/CPU we officially support. > >> > >> Cheers, > >> Tom > >> > >> > >>> On 3/1/2017 9:32 AM, Chris Pavlina wrote: > >>>> I am in favor of this. > >>>> > >>>> On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote: > >>>>> I will do my best, but I really cannot promise any time slot for looking > >>>>> into the issue. Perhaps it is the time to revisit Tom's libcontext [1]? > >>>>> The number of #ifdefs in tge current coroutine code makes eyes pop out, > >>>>> and I am afraid with the new issue we would be forced to add "#ifdef > >>>>> __APPLE__" to this horrible mess. > >>> > >>> This probably could have been hidden using cmake. It typically takes > >>> more effort to do it this way but it results in cleaner source code. > >>> > >>>>> > >>>>> This way we should be immune to future boost::context changes. The > >>>>> drawback is, we are on our own if there is a new architecture to > >>>>> support. On the other hand, how often a new architecture becomes popular > >>>>> enough to care about it? > >>>>> > >>>>> To sum up: I would switch to libcontext and stop worrying. > >>>>> > >>>>> Regards, > >>>>> Orson > >>>>> > >>>>> 1. https://github.com/twlostow/libcontext > >>>>> > >>>>> On 02/23/2017 02:07 PM, Wayne Stambaugh wrote: > >>>>>> This is a known issue. I believe the last valid version of boost that > >>>>>> doesn't cause a crash is 1.61. Anything after that causes this issue > >>>>>> on > >>>>>> all platforms not just osx. @Orson or @Tom, any chance you could take > >>>>>> a > >>>>>> look at this to see what boost changed in the context library? > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Wayne > >>>>>> > >>>>>> On 2/23/2017 6:49 AM, Simon Wells wrote: > >>>>>>> just fyi > >>>>>>> > >>>>>>> https://bugs.launchpad.net/kicad/+bug/1658249 > >>>>>>> > >>>>>>> On 24 February 2017 at 00:38, Chris Pavlina > >>>>>>> wrote: > >>>>>>>> Backtrace attached. Boost is 1.63.0. > >>>>>>>> > >>>>>>>> On Thu, Feb 23, 2017 at 11:36:02AM +0100, Maciej Sumiński wrote: > >>>>>>>>> Hi Chris, > >>>>>>>>> > >>>>>>>>> Would you give more details about the problem? Boost version, > >>>>>>>>> backtrace? > >>>>>>&
Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault
I know I've suggested this before and been shot down, but I'm still pretty convinced a coroutine library could be made that makes use of native threading support. This would be totally portable to all platforms! I don't have the time to POC it myself, I already have a kicad todo list miles long. But it seems to me that if we were to spawn a thread for each coroutine, lock them all to the same core via CPU affinity to avoid any caching issues, and use a global lock and simple scheduler to interleave the coroutines (i.e. when a coroutine yields, it really sets a lock and waits for it to unlock), it should work just fine.. On Wed, Mar 01, 2017 at 11:16:10AM -0500, Wayne Stambaugh wrote: > That's the one is was thinking about! AArch64 is coming fast so we only > do ourselves a disservice by not supporting it. In fact, there is now a > aarch64 device available designed with KiCad. It would be ironic if > KiCad couldn't run on it due to lack of support. SPARC and PPC may not > be main stream but if we can support them by using an already vetted > library, than that is my preference. > > On 3/1/2017 10:25 AM, Chris Pavlina wrote: > > Ah, crap. Missed that. Don't think I have one lying about anymore to > > volunteer... :( > > > > On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote: > >> On 01.03.2017 16:19, Chris Pavlina wrote: > >>> Wayne *please* tell me you won't block something that fixes macOS > >>> support and eliminates future boost API problems (which we've had > >>> SEVERAL problems with in the past) because of a lack of support for > >>> bloody *SPARC and PPC*. If there is a single user using KiCad on these > >>> platforms I would like to see them. > >>> > >> Hi Chris, > >> > >> Boost does support aarch64, I just lack a compiler/machine to test that... > >> > >> Cheers, > >> T. > >>> Now, the lack of support for aarch64 is a disappointment, but it looks > >>> like boost currently doesn't support that either. > >>> > >>> On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote: > >>>> On 01.03.2017 15:58, Wayne Stambaugh wrote: > >>>>> I am in favor of this if and only if we have equivalent or better > >>>>> architecture coverage compared to the boost context library. If not, > >>>>> than I am opposed to it. > >>>>> > >>>> Hi Wayne, > >>>> > >>>> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not > >>>> test the sparc/PPC ports for obvious reasons. I could add linux > >>>> sparc/PPC support but without testing, since I don't have a suitable > >>>> machine. > >>>> > >>>> For the moment, libcontext works on every OS/CPU we officially support. > >>>> > >>>> Cheers, > >>>> Tom > >>>> > >>>> > >>>>> On 3/1/2017 9:32 AM, Chris Pavlina wrote: > >>>>>> I am in favor of this. > >>>>>> > >>>>>> On Wed, Mar 01, 2017 at 02:03:37PM +0100, Maciej Sumiński wrote: > >>>>>>> I will do my best, but I really cannot promise any time slot for > >>>>>>> looking > >>>>>>> into the issue. Perhaps it is the time to revisit Tom's libcontext > >>>>>>> [1]? > >>>>>>> The number of #ifdefs in tge current coroutine code makes eyes pop > >>>>>>> out, > >>>>>>> and I am afraid with the new issue we would be forced to add "#ifdef > >>>>>>> __APPLE__" to this horrible mess. > >>>>> > >>>>> This probably could have been hidden using cmake. It typically takes > >>>>> more effort to do it this way but it results in cleaner source code. > >>>>> > >>>>>>> > >>>>>>> This way we should be immune to future boost::context changes. The > >>>>>>> drawback is, we are on our own if there is a new architecture to > >>>>>>> support. On the other hand, how often a new architecture becomes > >>>>>>> popular > >>>>>>> enough to care about it? > >>>>>>> > >>>>>>> To sum up: I would switch to libcontext and stop worrying. > >>>>>>> > >>>>&g
Re: [Kicad-developers] [PATCH] Add missing header
C++ standard library headers have no extension. On Wed, Mar 01, 2017 at 12:26:51PM -0500, Kevin Cozens wrote: > On 2017-03-01 10:40 AM, Simon Richter wrote: > > On the attached patch it says: > +#include > + > > That looks like a typo. I think that should be > > -- > Cheers! > > Kevin. > > http://www.ve3syb.ca/ |"Nerds make the shiny things that distract > Owner of Elecraft K2 #2172 | the mouth-breathers, and that's why we're > | powerful!" > #include | --Chris Hardwick > > ___ > 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] [PATCH] Fix MacOS coroutine segfault
My point is that threading could be used to implement a *drop-in replacement*...not that the tool framework should be structured around them, but that it continues to use coroutines, and we make a coroutine library that is implemented using threads... :P On Wed, Mar 01, 2017 at 04:32:39PM -0500, Wayne Stambaugh wrote: > We all have our preferred solutions the problem at hand. I personally > didn't see any reason to not use events. I have a sneaking suspicion > that the context switching was done to isolate the coder from having to > deal with events directly which on the surfaces seems like a good idea > but causes it's own set of design issues when executed within an event > driven application. My preference would have been to have the tool > objects be derived from wxEventHandler (or abstracted out to work with > different event systems) and inserted between the canvas and the main > window event handler on the wxWidgets event handler stack. Since no one > else stepped up to resolve the issues, the person who resolved them wins. ;) > > On 3/1/2017 12:01 PM, Chris Pavlina wrote: > > I know I've suggested this before and been shot down, but I'm still > > pretty convinced a coroutine library could be made that makes use of > > native threading support. This would be totally portable to all > > platforms! > > > > I don't have the time to POC it myself, I already have a kicad todo list > > miles long. But it seems to me that if we were to spawn a thread for > > each coroutine, lock them all to the same core via CPU affinity to avoid > > any caching issues, and use a global lock and simple scheduler to > > interleave the coroutines (i.e. when a coroutine yields, it really sets > > a lock and waits for it to unlock), it should work just fine.. > > > > On Wed, Mar 01, 2017 at 11:16:10AM -0500, Wayne Stambaugh wrote: > >> That's the one is was thinking about! AArch64 is coming fast so we only > >> do ourselves a disservice by not supporting it. In fact, there is now a > >> aarch64 device available designed with KiCad. It would be ironic if > >> KiCad couldn't run on it due to lack of support. SPARC and PPC may not > >> be main stream but if we can support them by using an already vetted > >> library, than that is my preference. > >> > >> On 3/1/2017 10:25 AM, Chris Pavlina wrote: > >>> Ah, crap. Missed that. Don't think I have one lying about anymore to > >>> volunteer... :( > >>> > >>> On Wed, Mar 01, 2017 at 04:21:56PM +0100, Tomasz Wlostowski wrote: > >>>> On 01.03.2017 16:19, Chris Pavlina wrote: > >>>>> Wayne *please* tell me you won't block something that fixes macOS > >>>>> support and eliminates future boost API problems (which we've had > >>>>> SEVERAL problems with in the past) because of a lack of support for > >>>>> bloody *SPARC and PPC*. If there is a single user using KiCad on these > >>>>> platforms I would like to see them. > >>>>> > >>>> Hi Chris, > >>>> > >>>> Boost does support aarch64, I just lack a compiler/machine to test > >>>> that... > >>>> > >>>> Cheers, > >>>> T. > >>>>> Now, the lack of support for aarch64 is a disappointment, but it looks > >>>>> like boost currently doesn't support that either. > >>>>> > >>>>> On Wed, Mar 01, 2017 at 04:06:51PM +0100, Tomasz Wlostowski wrote: > >>>>>> On 01.03.2017 15:58, Wayne Stambaugh wrote: > >>>>>>> I am in favor of this if and only if we have equivalent or better > >>>>>>> architecture coverage compared to the boost context library. If not, > >>>>>>> than I am opposed to it. > >>>>>>> > >>>>>> Hi Wayne, > >>>>>> > >>>>>> Libcontext currently supports x86/x86_64/ARM32 on all OSes. I could not > >>>>>> test the sparc/PPC ports for obvious reasons. I could add linux > >>>>>> sparc/PPC support but without testing, since I don't have a suitable > >>>>>> machine. > >>>>>> > >>>>>> For the moment, libcontext works on every OS/CPU we officially support. > >>>>>> > >>>>>> Cheers, > >>>>>> Tom > >>>>>> > >>>>>> > >>>>>>> On 3/1/2017 9:32 A
Re: [Kicad-developers] [PATCH] Fix MacOS coroutine segfault
On Thu, Mar 02, 2017 at 10:15:36AM +0100, "Torsten Hüter" wrote: > Hi Chris, > > please read the mail archive (Jan 2016), I've already tried this and > experimented with different coroutine implementations. I've tested of course > a variant based on pthreads too. > > The major showstopper was, that's not recommended to use threads for GUI > work, please read: > http://docs.wxwidgets.org/3.1/overview_thread.html > > "[..] When writing a multi-threaded application, it is strongly recommended > that no secondary threads call GUI functions. [..]" > > This would be very restrictive and can't be guaranteed. With a proper implementation this should be indistinguishable from coroutines, including to wx. > > If you're still interested, I could upload this implementation on launchpad > again. I've stopped working on this, because Tom proposed his libcontext and > with the bugfixes it was working so far well on Windows. > > -- > > In my opinion I'd drop coroutines entirely - they are nice if they're a > build-in language concept (like Modula-2 coroutines), but C++ has not yet the > best support for that. Alternatives are simple FSMs, sure that makes the code > a bit bulkier, but would work on every machine without having to maintain > assembler code. The disadvantage is the work that you have to invest there > (I have not much time to develop KiCad code anymore). > > Thanks, > Torsten > > Sorry for the double post, forgotten to switch to plain text. > > >> My point is that threading could be used to implement a *drop-in > >> replacement*...not that the tool framework should be structured around > >> them, but that it continues to use coroutines, and we make a coroutine > >> library that is implemented using threads... :P > > ___ > 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] [PATCH] Fix MacOS coroutine segfault
Good point about GDI, I wasn't aware about that restriction. Windows does have fibers which are basically coroutines - I wonder if a separate Windows implementation could use those. I don't see any such restriction for fibers. On Thu, Mar 02, 2017 at 03:58:01PM +0100, "Torsten Hüter" wrote: > Chris: > >> With a proper implementation this should be indistinguishable from > >> coroutines, including to wx. > > This is your opinion not mine, I'm not sure. Again, read the paragraph about > secondary threads: > http://docs.wxwidgets.org/3.1/overview_thread.html > > "[..] under Win32 a thread can only access GDI objects such as pens, brushes, > device contexts created by itself and not by the other threads [..]" > > One of the reasons why they strongly recommend "no secondary threads call GUI > functions". > > -- > > However, if you can ensure that the coroutines never call GUI functions, > threads should be a nice alternative. I remember Orson has written, that this > should be possible. Maybe he can answer the question if this restriction is > still acceptable. Then I could rescue my implementation from my backups. > > Thanks, > Torsten > > ___ > 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] Selection tool that selects components and local connections
Nice! Looks good, and works perfectly here. Merged, thank you :) On Fri, Mar 03, 2017 at 09:14:33AM +0100, Kristoffer Ödmark wrote: > Found some coding style errors that were fixed in this. > > And in accordance with previous patches/features ive sent a youtube vid is > now attached. > > https://youtu.be/fISB7S5YFvo > > - Kristoffer > > On 2017-03-03 00:52, Kristoffer Ödmark wrote: > >Hello > > > >These two patches adds crossprobing to the schematic sheet in the same > >way that crossprobing behaves when selecting components in eeschema. Ie > >it selects all items that are only present on a specific sheet. > > > >I have only tested on linux for now. > > > >-Kristoffer > > > >On 2017-02-11 13:36, Chris Pavlina wrote: > >>Merged. This looks very useful. Thank you for your contribution! > >> > >>On Sat, Feb 11, 2017 at 01:25:24PM +0100, Kristoffer Ödmark wrote: > >>>Sure! here comes! > >>> > >>>- Kristoffer > >>> > >>>On 2017-02-11 03:02, Chris Pavlina wrote: > >>>>Can you update this again? > >>>> > >>>>On Fri, Feb 10, 2017 at 01:45:10PM +0100, Kristoffer Ödmark wrote: > >>>>>Updated the patch to fit on current master. > >>>>> > >>>>> > >>>>>On 2017-02-08 21:14, Kristoffer Ödmark wrote: > >>>>>>I tried reverting back to master and found the same strange bugs on > >>>>>>windows, so i do not think my patch causes them. > >>>>>> > >>>>>>example of bug: > >>>>>>https://snag.gy/EesP2n.jpg > >>>>>> > >>>>>>On 2017-02-08 19:17, Kristoffer Ödmark wrote: > >>>>>>>Hello again! > >>>>>>> > >>>>>>>Since my groupselection required changes to the file format to be > >>>>>>>useful. I have now created a selection tool that selects all > >>>>>>>footprints > >>>>>>>belonging on the same sheet or "deeper". > >>>>>>> > >>>>>>>It also finds all nets that only have connections between > >>>>>>>components on > >>>>>>>the same or deeper sheet and selects them. > >>>>>>> > >>>>>>>It gives some functionality of the group selection idea and does not > >>>>>>>break file format or any previous workflow. > >>>>>>> > >>>>>>>Tested on linux, saw some strange right-click meny errors on > >>>>>>>windows, > >>>>>>>but the functionality works there as well when using the shortcut > >>>>>>>key 'P' > >>>>>>> > >>>>>>>Attaching patch > >>>>>>> > >>>>>>>Video: > >>>>>>>https://www.youtube.com/watch?v=DUskyc7t_HA&feature=youtu.be > >>>>>>> > >>>>>>>- Kristoffer > >>>>>>> > >>>>>>> > >>>> > >> ___ 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] [RFC] Logo Consolidation
I mostly like this. I'm really not keen on the white outline around the letters though, and it really needs to be adjusted so that the "Ki" and the "CAD" share a baseline - it feels rough to read otherwise. On Sat, Mar 04, 2017 at 01:48:44AM +1100, Oliver Walters wrote: > Here is a revised version: > > http://imgur.com/a/DysJm > > On Thu, Mar 2, 2017 at 6:41 PM, Ingo Kletti > wrote: > > > Hi, > > > > I like the use of the schematic/pcb elements. > > > > It also looks much better at small scales > >> > > > > I tried the scaling and made a mockup at icon resolutions from 16x16 to > > 64x64 with 8 pixel steps (16, 24, 32, etc.), see attachment. Scaling works > > good IMO, but cannot avoid bike-shedding: > > > > On the sizes 16x16 to 32x32, the white border around the 'i' looks muddy > > due to the scaling. Maybe using a brighter orange tone might suffice so > > that the border can be omitted completely without losing contrast. > > > > Cheers, > > > > Ingo > > > > ___ > > 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] [RFC] Logo Consolidation
Honestly, I need to reply again here - the more I look at this, the less I like it. I really don't want to be too negative about this, but there is a lot about this logo that just doesn't work. - Really bad typography makes it slow to read: - Inconsistent tracking - K iC A D - Inconsistent letter baseline - The K looks crooked - upper diagonal arm shorter than lower, and the lower one dips under the baseline - Capitalization is wrong, "CAD" might be the correct acronym but we've pretty consistently spelled our name "KiCad" for a long time - An anonymous IRCer points out that the lower diagonal arm on the K looks a bit...rude. He's not the only one who sees this. I quite like the original logo, to be entirely honest. Maybe it could be improved slightly by changing to a fully sans serif font, but I really don't think anything else on it needs to be changed. On Fri, Mar 03, 2017 at 10:01:05AM -0500, Chris Pavlina wrote: > I mostly like this. I'm really not keen on the white outline around the > letters though, and it really needs to be adjusted so that the "Ki" and > the "CAD" share a baseline - it feels rough to read otherwise. > > On Sat, Mar 04, 2017 at 01:48:44AM +1100, Oliver Walters wrote: > > Here is a revised version: > > > > http://imgur.com/a/DysJm > > > > On Thu, Mar 2, 2017 at 6:41 PM, Ingo Kletti > > wrote: > > > > > Hi, > > > > > > I like the use of the schematic/pcb elements. > > > > > > It also looks much better at small scales > > >> > > > > > > I tried the scaling and made a mockup at icon resolutions from 16x16 to > > > 64x64 with 8 pixel steps (16, 24, 32, etc.), see attachment. Scaling works > > > good IMO, but cannot avoid bike-shedding: > > > > > > On the sizes 16x16 to 32x32, the white border around the 'i' looks muddy > > > due to the scaling. Maybe using a brighter orange tone might suffice so > > > that the border can be omitted completely without losing contrast. > > > > > > Cheers, > > > > > > Ingo > > > > > > ___ > > > 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
[Kicad-developers] Update on component chooser
Hi, Just thought I'd provide a quick update on what's going on with the component chooser. Things have been pretty delayed - I've had more issues than expected, and I'm trying to work around my school schedule too - but I'm still moving along (and I have almost a full week off now, most of which will be spent on this). Currently, I'm working on resolving a macOS performance issue that causes updates to cost about 0.5s per keystroke for large library sets. I'm looking at two possible solutions: - Implement my own wxDataViewModel, reimplementing most or all of COMPONENT_TREE_SEARCH_CONTAINER in the process and making the component tree a model/view architecture. This is very much preferable, but I'm not 100% sure if this will give the desired performance boost. I'll do this first as it's a useful refactoring anyway. - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This would populate the underlying list only with visible items, intercepting "expand" events and populating the parents with their children on demand. This is an ugly hack and I'd like not to resort to this. When I'm done with this, I want to make a couple more changes before proceeding, based on user feedback: - Make the component info box collapsible. - Also display component info in a rich tooltip - Add a resizable splitter between footprint and symbol display Once all of this is done, the next steps are: - Add footprint filtering and selection - Add 3D preview Please, feel free to file bug reports even on minor UI quirks - I don't always notice or remember them. -- Chris ___ 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] [PATCH/RFC] Pcbnew initial startup user experience
Only read through this quickly as I'm pretty busy, but it looks good to me. There's another issue I've had in mind with the pcbnew OOBE: now that I'm adding footprint preview to eeschema, the pcbnew init routines happen on the first run of the eeschema component selector... I was thinking about consolidating the whole thing into one big KiCad init routine. Thoughts? On Sun, Mar 05, 2017 at 07:01:03AM +0800, John Beard wrote: > Hi, > > Here is a (proposed) patchset to modify the "user experience" (to use > a buzzword) of Pcbnew and cvPcb when the user loads it for the first > time with no fp-library-table. > > The current behaviour is quite unfriendly, as it doesn't get the user > to consent to an action when initialising the library, it does one of > two actions (cpopy default table, or create empty table - which one > depends on various conditions) which means that users click the OK > button not fully knowing what just happened. > > Furthermore, if they click though that dialog without reading it, they > will then be frustrated by the lack of libraries later, which > manifests as an error or an empty footprint chooser. Bear in mind, as > far as users are concerned, the libraries are installed (e.g. > /usr/share/kicad has content), but as far as KiCad is concerned, they > are not necessarily configured (empty or default fp-lib-table in > user's home). > > This has caused several people to struggle with getting started with > KiCad, and people asking how to proceed is a semi-regular occurence on > IRC. > > This patch changes to the following process: > > * If user fp-lib-table is found and it has at least one library, > everything is normal > and the user isn't disturbed. > * If fp-lib-table is missing: > * On Pcbnew/Cvpcb start, pop up a dialog saying this and giving > these options: > * Quit - exit Pcbnew/cvPcb witohut attempting to create > fp-lib-table. Users can then make their own arrangements. > * Copy default table - attempt to copy the default table. If > this fails, return to the choice dialog. > * Create empty table - if this fails return to the dialog. > * In no case did the user get an fp-lib-table they didn't ask for. > * If a blank or default table is created, a second dialog appears, > informing the user that the library table might need configuration. > This provides three options: > * Cancel - user doesn't want to configure the table now, table > is unchanged > * Open Manual - the manual referenced in the dialog message is > opened so the user can read about library configuration > * Open FP Library Manager - go directly to the library > manager, rather than expecting the user to cancel the dialog and find > it themselves. The wizard is accessible from the manager dialog. > * If fp-lib-table is found, but it's empty when the user goes to use > it (e.g. on a keyword search for footprints), the > Cancel/Manual/Manager dialog is shown again, but it's a warning rather > than informational, as it was before. > > The aim here is to ensure that the configuration is "management by > consent" and that the user is: > > * Not surprised by "secret" configuration behind the scenes > * Informed of and consenting to specific actions > * Guided though configuration with dialogs that give access to > mentioned tools, rather than a block of text and an OK/Cancel button, > after which they are on their own. > > Technically speaking, this is done by moving the global fp-lib-table > loading into common, and invoking it only when the frame is shown > (rather than prior to the kiface load). The reason for this is so that > the followup dialog can access the manager. Also, it reduces special > casing before kiface load. > > The on-show invocation is done by a small class subscribed to the > frame's wx "Show" event, and once the event is received, the class > unsubscribes itself (so it's a one-shot), and executes a lits of > startup actions. The class is such that you can add multiple startup > actions, any of which can "veto" startup if needed. > > Sorry for the long email: the change is not really that complex, but > the configuration process has several paths. As the first thing a new > user to Pcbnew sees, I think this is a fairly important thing to get > right. > > Cheers, > > John ___ 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] Update on component chooser
Thanks. Could I have a bit more information so I can reproduce these? And it would be nice if they were in the bug tracker, for... tracking. On Mar 5, 2017 02:17, "Eldar Khayrullin" wrote: > Hello. You do good work. > I see UI issues: > - the window struct breaks on resize the window > - some components doesn't show symbol > - some components doesn't show fields > > kicad@24a9003 > Daily PPA. > OS: Ubuntu 16.10 > > В Суббота, 4 мар. 2017 в 9:38 , Chris Pavlina > написал: > > Hi, Just thought I'd provide a quick update on what's going on with the > component chooser. Things have been pretty delayed - I've had more issues > than expected, and I'm trying to work around my school schedule too - but > I'm still moving along (and I have almost a full week off now, most of > which will be spent on this). Currently, I'm working on resolving a macOS > performance issue that causes updates to cost about 0.5s per keystroke for > large library sets. I'm looking at two possible solutions: - Implement my > own wxDataViewModel, reimplementing most or all of > COMPONENT_TREE_SEARCH_CONTAINER > in the process and making the component tree a model/view architecture. > This is very much preferable, but I'm not 100% sure if this will give the > desired performance boost. I'll do this first as it's a useful refactoring > anyway. - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. > This would populate the underlying list only with visible items, > intercepting "expand" events and populating the parents with their children > on demand. This is an ugly hack and I'd like not to resort to this. When > I'm done with this, I want to make a couple more changes before proceeding, > based on user feedback: - Make the component info box collapsible. - Also > display component info in a rich tooltip - Add a resizable splitter between > footprint and symbol display Once all of this is done, the next steps are: > - Add footprint filtering and selection - Add 3D preview Please, feel free > to file bug reports even on minor UI quirks - I don't always notice or > remember them. > -- > Chris ___ 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] Update on component chooser
Ongoing refactor of COMPONENT_TREE_SEARCH_CONTAINER into a model-view-adapter architecture is at [1] (componentchooser branch of my dev repo). The code is seriously cleaner now and significantly faster. Should be done later today. [1] https://github.com/cpavlina/kicad/tree/componentchooser On Sat, Mar 04, 2017 at 01:38:37PM -0500, Chris Pavlina wrote: > Hi, > > Just thought I'd provide a quick update on what's going on with the > component chooser. Things have been pretty delayed - I've had more > issues than expected, and I'm trying to work around my school schedule > too - but I'm still moving along (and I have almost a full week off now, > most of which will be spent on this). > > Currently, I'm working on resolving a macOS performance issue that > causes updates to cost about 0.5s per keystroke for large library sets. > I'm looking at two possible solutions: > > - Implement my own wxDataViewModel, reimplementing most or all of >COMPONENT_TREE_SEARCH_CONTAINER in the process and making the >component tree a model/view architecture. This is very much >preferable, but I'm not 100% sure if this will give the desired >performance boost. I'll do this first as it's a useful refactoring >anyway. > > - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This >would populate the underlying list only with visible items, >intercepting "expand" events and populating the parents with their >children on demand. This is an ugly hack and I'd like not to resort >to this. > > When I'm done with this, I want to make a couple more changes before > proceeding, based on user feedback: > > - Make the component info box collapsible. > - Also display component info in a rich tooltip > - Add a resizable splitter between footprint and symbol display > > Once all of this is done, the next steps are: > > - Add footprint filtering and selection > - Add 3D preview > > Please, feel free to file bug reports even on minor UI quirks - I don't > always notice or remember them. > > -- > Chris ___ 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] Standalone mode.
On Sun, Mar 05, 2017 at 12:36:20PM -0500, Wayne Stambaugh wrote: > On 3/4/2017 8:11 PM, Cirilo Bernardo wrote: > > On Sun, Mar 5, 2017 at 10:29 AM, Wayne Stambaugh > > wrote: > >> On 2/27/2017 11:28 AM, Chris Pavlina wrote: > >>> Hi, > >>> > >>> There are a few problems with "standalone mode" that I see. One of the > >>> biggest is demonstrated [1] - kiway services aren't available. In my > >>> opinion this really is detrimental to the function of the software - > >>> e.g. eeschema shouldn't be missing features just because it was started > >>> in standalone. > >>> > >>> Another problem is the awkwardness of packaging/install on systems that > >>> expect applications to be discrete units, like macOS. There's some > >>> foreshadowing on the bug tracker of trouble wrt. signed packages, which > >>> I couldn't immediately dig up. > >>> > >>> I'd really like if we could change this. I don't think standalone mode > >>> the way we implement it is necessary. It is necessary that one can open > >>> a pure schematic file, or a pure PCB file, outside of the context of a > >>> project -- but I do NOT think this should require starting the > >>> individual application separately from the project manager. > >>> > >>> What if the project manager simply understood the concept of single > >>> files as well as projects? > >> > >> I honestly don't know how this will work out. Regardless of how the > >> editors are launched, the project configuration is very much in play and > >> there is currently no support for multiple projects open simultaneously. > >> I don't know how you will open a single schematic in a manner which > >> will wreak havoc on the symbol library lists. Boards are a different > >> story since their footprints are embedded so it's probably less of an > >> issue. Once the new schematic file format is in play than the symbol > >> library issue is no longer in play. I'm not opposed to you trying but I > >> don't think we are any where near ready to attempt to head down that > >> path any time soon. > >> > > > > I think the idea is to have a single executable which can act as the > > standalone launcher for all the kiway blobs rather than have N > > installed versions of what is essentially the same launcher. Kicad > > should still work as expected: if it opens a *.pro file then eeschema > > and pcbnew can talk to eachother and if it opens a *.sch/*.kicad_pcb > > file or what not then the program invoked acts like the standalone. > > > > Although it would be nice to have standalone instances of eeschema, > > pcbnew and so on magically talk to eachother, we all know that would > > require a well-planned IPC based mechanism and that's not what's > > being proposed here. > > This should be transparent unless someone changed it. When launched in > stand alone mode, the kiway messaging falls back to the legacy sockets > implementation for message passing. The problem becomes how to handle > the IPC when you open the schematic from one project and the board from > a different project in stand alone mode. You don't. What's wrong with just not having IPC between standalone instances? They shouldn't need to pass anything amongst themselves. At some point it would be nice to be able to pass clipboard items between instances, but this can be handled by wxClipboard. > > > > > - Cirilo > > > >>> > >>> [1] https://bugs.launchpad.net/kicad/+bug/1668157 > >>> > >> > >> > >> ___ > >> 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] Standalone mode.
On Sun, Mar 05, 2017 at 01:03:34PM -0500, Wayne Stambaugh wrote: > On 3/5/2017 12:39 PM, Chris Pavlina wrote: > > On Sun, Mar 05, 2017 at 12:36:20PM -0500, Wayne Stambaugh wrote: > >> On 3/4/2017 8:11 PM, Cirilo Bernardo wrote: > >>> On Sun, Mar 5, 2017 at 10:29 AM, Wayne Stambaugh > >>> wrote: > >>>> On 2/27/2017 11:28 AM, Chris Pavlina wrote: > >>>>> Hi, > >>>>> > >>>>> There are a few problems with "standalone mode" that I see. One of the > >>>>> biggest is demonstrated [1] - kiway services aren't available. In my > >>>>> opinion this really is detrimental to the function of the software - > >>>>> e.g. eeschema shouldn't be missing features just because it was started > >>>>> in standalone. > >>>>> > >>>>> Another problem is the awkwardness of packaging/install on systems that > >>>>> expect applications to be discrete units, like macOS. There's some > >>>>> foreshadowing on the bug tracker of trouble wrt. signed packages, which > >>>>> I couldn't immediately dig up. > >>>>> > >>>>> I'd really like if we could change this. I don't think standalone mode > >>>>> the way we implement it is necessary. It is necessary that one can open > >>>>> a pure schematic file, or a pure PCB file, outside of the context of a > >>>>> project -- but I do NOT think this should require starting the > >>>>> individual application separately from the project manager. > >>>>> > >>>>> What if the project manager simply understood the concept of single > >>>>> files as well as projects? > >>>> > >>>> I honestly don't know how this will work out. Regardless of how the > >>>> editors are launched, the project configuration is very much in play and > >>>> there is currently no support for multiple projects open simultaneously. > >>>> I don't know how you will open a single schematic in a manner which > >>>> will wreak havoc on the symbol library lists. Boards are a different > >>>> story since their footprints are embedded so it's probably less of an > >>>> issue. Once the new schematic file format is in play than the symbol > >>>> library issue is no longer in play. I'm not opposed to you trying but I > >>>> don't think we are any where near ready to attempt to head down that > >>>> path any time soon. > >>>> > >>> > >>> I think the idea is to have a single executable which can act as the > >>> standalone launcher for all the kiway blobs rather than have N > >>> installed versions of what is essentially the same launcher. Kicad > >>> should still work as expected: if it opens a *.pro file then eeschema > >>> and pcbnew can talk to eachother and if it opens a *.sch/*.kicad_pcb > >>> file or what not then the program invoked acts like the standalone. > >>> > >>> Although it would be nice to have standalone instances of eeschema, > >>> pcbnew and so on magically talk to eachother, we all know that would > >>> require a well-planned IPC based mechanism and that's not what's > >>> being proposed here. > >> > >> This should be transparent unless someone changed it. When launched in > >> stand alone mode, the kiway messaging falls back to the legacy sockets > >> implementation for message passing. The problem becomes how to handle > >> the IPC when you open the schematic from one project and the board from > >> a different project in stand alone mode. > > > > You don't. > > > > What's wrong with just not having IPC between standalone instances? They > > shouldn't need to pass anything amongst themselves. > > This is the legacy behavior which was preserved. There are still users > who prefer stand alone mode and expect the IPC to continue to work as it > did before the kiway work was done. This somewhat drove the kiway > design decisions. We can always decide to do away with the stand alone > mode and go fully single app but I'm sure there will be a fairly large > group of users who will not be happy about that decision. I have no > idea how large this group will be but given passed responses to such > suggestions I would guess this is a larger group than you would expect.
Re: [Kicad-developers] Update on component chooser
Ready for testing, I'll merge tomorrow since it mostly only touches my parts. This is a pretty significant improvement, and solves some wxTreeListCtrl quirks as well. On Sun, Mar 05, 2017 at 05:02:10PM +0100, Nick Østergaard wrote: > Please report back when it is ready for testing... > > 2017-03-05 15:04 GMT+01:00 Chris Pavlina : > > Ongoing refactor of COMPONENT_TREE_SEARCH_CONTAINER into a > > model-view-adapter architecture is at [1] (componentchooser branch of my > > dev repo). The code is seriously cleaner now and significantly faster. > > Should be done later today. > > > > [1] https://github.com/cpavlina/kicad/tree/componentchooser > > > > > > On Sat, Mar 04, 2017 at 01:38:37PM -0500, Chris Pavlina wrote: > >> Hi, > >> > >> Just thought I'd provide a quick update on what's going on with the > >> component chooser. Things have been pretty delayed - I've had more > >> issues than expected, and I'm trying to work around my school schedule > >> too - but I'm still moving along (and I have almost a full week off now, > >> most of which will be spent on this). > >> > >> Currently, I'm working on resolving a macOS performance issue that > >> causes updates to cost about 0.5s per keystroke for large library sets. > >> I'm looking at two possible solutions: > >> > >> - Implement my own wxDataViewModel, reimplementing most or all of > >>COMPONENT_TREE_SEARCH_CONTAINER in the process and making the > >>component tree a model/view architecture. This is very much > >>preferable, but I'm not 100% sure if this will give the desired > >>performance boost. I'll do this first as it's a useful refactoring > >>anyway. > >> > >> - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This > >>would populate the underlying list only with visible items, > >>intercepting "expand" events and populating the parents with their > >>children on demand. This is an ugly hack and I'd like not to resort > >>to this. > >> > >> When I'm done with this, I want to make a couple more changes before > >> proceeding, based on user feedback: > >> > >> - Make the component info box collapsible. > >> - Also display component info in a rich tooltip > >> - Add a resizable splitter between footprint and symbol display > >> > >> Once all of this is done, the next steps are: > >> > >> - Add footprint filtering and selection > >> - Add 3D preview > >> > >> Please, feel free to file bug reports even on minor UI quirks - I don't > >> always notice or remember them. > >> > >> -- > >> Chris > > > > ___ > > 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] Update on component chooser
On Tue, Mar 07, 2017 at 11:58:27AM +1300, Simon Wells wrote: > I wonder whether it is worth making this a policy that no new > components can use wxTreeListCtrl as the performance on OSX is abysmal > and there are alternatives, granted they are slightly more complicated > but a much better long term solution (not only in osx performance) but > in code structure as well. I agree. wxTreeCtrl is fine, but if you need more sophisticated data or display you should go straight to wxDataViewCtrl. I'm 100% in favor of making it policy. > > On 6 March 2017 at 17:00, Chris Pavlina wrote: > > Ready for testing, I'll merge tomorrow since it mostly only touches my > > parts. This is a pretty significant improvement, and solves some > > wxTreeListCtrl quirks as well. > > > > > > On Sun, Mar 05, 2017 at 05:02:10PM +0100, Nick Østergaard wrote: > >> Please report back when it is ready for testing... > >> > >> 2017-03-05 15:04 GMT+01:00 Chris Pavlina : > >> > Ongoing refactor of COMPONENT_TREE_SEARCH_CONTAINER into a > >> > model-view-adapter architecture is at [1] (componentchooser branch of my > >> > dev repo). The code is seriously cleaner now and significantly faster. > >> > Should be done later today. > >> > > >> > [1] https://github.com/cpavlina/kicad/tree/componentchooser > >> > > >> > > >> > On Sat, Mar 04, 2017 at 01:38:37PM -0500, Chris Pavlina wrote: > >> >> Hi, > >> >> > >> >> Just thought I'd provide a quick update on what's going on with the > >> >> component chooser. Things have been pretty delayed - I've had more > >> >> issues than expected, and I'm trying to work around my school schedule > >> >> too - but I'm still moving along (and I have almost a full week off now, > >> >> most of which will be spent on this). > >> >> > >> >> Currently, I'm working on resolving a macOS performance issue that > >> >> causes updates to cost about 0.5s per keystroke for large library sets. > >> >> I'm looking at two possible solutions: > >> >> > >> >> - Implement my own wxDataViewModel, reimplementing most or all of > >> >>COMPONENT_TREE_SEARCH_CONTAINER in the process and making the > >> >>component tree a model/view architecture. This is very much > >> >>preferable, but I'm not 100% sure if this will give the desired > >> >>performance boost. I'll do this first as it's a useful refactoring > >> >>anyway. > >> >> > >> >> - Implement an optimizing adapter that wraps TWO_COLUMN_TREE_LIST. This > >> >>would populate the underlying list only with visible items, > >> >>intercepting "expand" events and populating the parents with their > >> >>children on demand. This is an ugly hack and I'd like not to resort > >> >>to this. > >> >> > >> >> When I'm done with this, I want to make a couple more changes before > >> >> proceeding, based on user feedback: > >> >> > >> >> - Make the component info box collapsible. > >> >> - Also display component info in a rich tooltip > >> >> - Add a resizable splitter between footprint and symbol display > >> >> > >> >> Once all of this is done, the next steps are: > >> >> > >> >> - Add footprint filtering and selection > >> >> - Add 3D preview > >> >> > >> >> Please, feel free to file bug reports even on minor UI quirks - I don't > >> >> always notice or remember them. > >> >> > >> >> -- > >> >> Chris > >> > > >> > ___ > >> > 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] [PATCH] [RFC] Get rid of boost::context
Looks good! Wish I had time to test it on OSX or Windows. I'm sure you know already but it seems to work perfectly on Linux/x86_64 :) On Tue, Mar 07, 2017 at 02:36:03PM +0100, Tomasz Wlostowski wrote: > Hi, > > The attached patch removes boost::context dependency by introducing a > single-file libcontext that automatically detects the compiler & > platform and provides a stable API, contrary to the Boost libs. If you > have some spare time, please test it, in particular on Windows and OSX. > > I verified the library (outside Kicad) on > Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and > Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC > platforms. If anyone here pops up willing to test the Sparc/PPC support, > I can add it. > > I hope this will sort out the boost issues for good. > > Cheers, > Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] [PATCH] [RFC] Get rid of boost::context
How thoroughly? I can build it on macOS and poke around a bit, but I don't have time to spend a day doing layout with it right now. On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote: > It needs to be tested on osx before we commit the patch. > > On 3/7/2017 9:24 AM, Maciej Sumiński wrote: > > Brief testing with Win7 x86_64 gives positive results. I really hope > > this is the end of the boost::context nightmare. > > > > Cheers, > > Orson > > > > On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote: > >> Hi, > >> > >> The attached patch removes boost::context dependency by introducing a > >> single-file libcontext that automatically detects the compiler & > >> platform and provides a stable API, contrary to the Boost libs. If you > >> have some spare time, please test it, in particular on Windows and OSX. > >> > >> I verified the library (outside Kicad) on > >> Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and > >> Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC > >> platforms. If anyone here pops up willing to test the Sparc/PPC support, > >> I can add it. > >> > >> I hope this will sort out the boost issues for good. > >> > >> Cheers, > >> Tom > >> > >> > >> > >> ___ > >> Mailing list: https://launchpad.net/~kicad-developers > >> Post to : kicad-developers@lists.launchpad.net > >> Unsubscribe : https://launchpad.net/~kicad-developers > >> More help : https://help.launchpad.net/ListHelp > >> > > > > > > > > > > ___ > > 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] [PATCH] [RFC] Get rid of boost::context
Tested, works fine. By the way, the following commit breaks the build on macOS, and probably also Linux+clang. I had to revert it to get a successful build: commit d1550b0cdb990ba1f4f32220e110f8ff6331a5f1 Author: Maciej Suminski Date: Mon Mar 6 11:41:06 2017 +0100 Renamed VIEW_CONTROLS::SETTINGS to VC_SETTINGS. Because nested types cannot be forwarded. On Tue, Mar 07, 2017 at 09:40:04AM -0500, Wayne Stambaugh wrote: > I'm thinking a valid build and a quick check that the P&S router doesn't > crash should be adequate. > > On 3/7/2017 9:32 AM, Chris Pavlina wrote: > > How thoroughly? I can build it on macOS and poke around a bit, but I > > don't have time to spend a day doing layout with it right now. > > > > > > On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote: > >> It needs to be tested on osx before we commit the patch. > >> > >> On 3/7/2017 9:24 AM, Maciej Sumiński wrote: > >>> Brief testing with Win7 x86_64 gives positive results. I really hope > >>> this is the end of the boost::context nightmare. > >>> > >>> Cheers, > >>> Orson > >>> > >>> On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote: > >>>> Hi, > >>>> > >>>> The attached patch removes boost::context dependency by introducing a > >>>> single-file libcontext that automatically detects the compiler & > >>>> platform and provides a stable API, contrary to the Boost libs. If you > >>>> have some spare time, please test it, in particular on Windows and OSX. > >>>> > >>>> I verified the library (outside Kicad) on > >>>> Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and > >>>> Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC > >>>> platforms. If anyone here pops up willing to test the Sparc/PPC support, > >>>> I can add it. > >>>> > >>>> I hope this will sort out the boost issues for good. > >>>> > >>>> Cheers, > >>>> Tom > >>>> > >>>> > >>>> > >>>> ___ > >>>> Mailing list: https://launchpad.net/~kicad-developers > >>>> Post to : kicad-developers@lists.launchpad.net > >>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>> More help : https://help.launchpad.net/ListHelp > >>>> > >>> > >>> > >>> > >>> > >>> ___ > >>> 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] [PATCH] [RFC] Get rid of boost::context
On Tue, Mar 07, 2017 at 04:35:44PM +0100, Maciej Sumiński wrote: > I use Linux+clang (3.9) and here the compiler does not complain. What is > the error message? Error dump attached. > Does it really build if you revert only this > particular commit? I also reverted the one directly after it because they looked connected. The build on macOS takes long enough that I didn't want to have to try twice. > > Cheers, > Orson > > On 03/07/2017 04:15 PM, Chris Pavlina wrote: > > Tested, works fine. > > > > By the way, the following commit breaks the build on macOS, and probably > > also Linux+clang. I had to revert it to get a successful build: > > > > commit d1550b0cdb990ba1f4f32220e110f8ff6331a5f1 > > Author: Maciej Suminski > > Date: Mon Mar 6 11:41:06 2017 +0100 > > > > Renamed VIEW_CONTROLS::SETTINGS to VC_SETTINGS. > > > > Because nested types cannot be forwarded. > > > > > > > > On Tue, Mar 07, 2017 at 09:40:04AM -0500, Wayne Stambaugh wrote: > >> I'm thinking a valid build and a quick check that the P&S router doesn't > >> crash should be adequate. > >> > >> On 3/7/2017 9:32 AM, Chris Pavlina wrote: > >>> How thoroughly? I can build it on macOS and poke around a bit, but I > >>> don't have time to spend a day doing layout with it right now. > >>> > >>> > >>> On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote: > >>>> It needs to be tested on osx before we commit the patch. > >>>> > >>>> On 3/7/2017 9:24 AM, Maciej Sumiński wrote: > >>>>> Brief testing with Win7 x86_64 gives positive results. I really hope > >>>>> this is the end of the boost::context nightmare. > >>>>> > >>>>> Cheers, > >>>>> Orson > >>>>> > >>>>> On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote: > >>>>>> Hi, > >>>>>> > >>>>>> The attached patch removes boost::context dependency by introducing a > >>>>>> single-file libcontext that automatically detects the compiler & > >>>>>> platform and provides a stable API, contrary to the Boost libs. If you > >>>>>> have some spare time, please test it, in particular on Windows and OSX. > >>>>>> > >>>>>> I verified the library (outside Kicad) on > >>>>>> Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and > >>>>>> Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC > >>>>>> platforms. If anyone here pops up willing to test the Sparc/PPC > >>>>>> support, > >>>>>> I can add it. > >>>>>> > >>>>>> I hope this will sort out the boost issues for good. > >>>>>> > >>>>>> Cheers, > >>>>>> Tom > >>>>>> > >>>>>> > >>>>>> > >>>>>> ___ > >>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> ___ > >>>>> 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 > >
Re: [Kicad-developers] [PATCH] [RFC] Get rid of boost::context
Lol, it's a pretty major thing if you look at what std::deque was trying to do...I don't see any way for the compiler to resolve this with the implementation of std::deque it was using ;) Thanks for the quick fix. On Tue, Mar 07, 2017 at 05:24:14PM +0100, Maciej Sumiński wrote: > Thank you Chris, now it should build fine on OSX as well. I really love > compilers screaming so much about such minor things. > > Regards, > Orson > > On 03/07/2017 04:51 PM, Chris Pavlina wrote: > > On Tue, Mar 07, 2017 at 04:35:44PM +0100, Maciej Sumiński wrote: > >> I use Linux+clang (3.9) and here the compiler does not complain. What is > >> the error message? > > > > Error dump attached. > > > >> Does it really build if you revert only this > >> particular commit? > > > > I also reverted the one directly after it because they looked connected. > > The build on macOS takes long enough that I didn't want to have to try > > twice. > > > >> > >> Cheers, > >> Orson > >> > >> On 03/07/2017 04:15 PM, Chris Pavlina wrote: > >>> Tested, works fine. > >>> > >>> By the way, the following commit breaks the build on macOS, and probably > >>> also Linux+clang. I had to revert it to get a successful build: > >>> > >>> commit d1550b0cdb990ba1f4f32220e110f8ff6331a5f1 > >>> Author: Maciej Suminski > >>> Date: Mon Mar 6 11:41:06 2017 +0100 > >>> > >>> Renamed VIEW_CONTROLS::SETTINGS to VC_SETTINGS. > >>> > >>> Because nested types cannot be forwarded. > >>> > >>> > >>> > >>> On Tue, Mar 07, 2017 at 09:40:04AM -0500, Wayne Stambaugh wrote: > >>>> I'm thinking a valid build and a quick check that the P&S router doesn't > >>>> crash should be adequate. > >>>> > >>>> On 3/7/2017 9:32 AM, Chris Pavlina wrote: > >>>>> How thoroughly? I can build it on macOS and poke around a bit, but I > >>>>> don't have time to spend a day doing layout with it right now. > >>>>> > >>>>> > >>>>> On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote: > >>>>>> It needs to be tested on osx before we commit the patch. > >>>>>> > >>>>>> On 3/7/2017 9:24 AM, Maciej Sumiński wrote: > >>>>>>> Brief testing with Win7 x86_64 gives positive results. I really hope > >>>>>>> this is the end of the boost::context nightmare. > >>>>>>> > >>>>>>> Cheers, > >>>>>>> Orson > >>>>>>> > >>>>>>> On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote: > >>>>>>>> Hi, > >>>>>>>> > >>>>>>>> The attached patch removes boost::context dependency by introducing a > >>>>>>>> single-file libcontext that automatically detects the compiler & > >>>>>>>> platform and provides a stable API, contrary to the Boost libs. If > >>>>>>>> you > >>>>>>>> have some spare time, please test it, in particular on Windows and > >>>>>>>> OSX. > >>>>>>>> > >>>>>>>> I verified the library (outside Kicad) on > >>>>>>>> Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and > >>>>>>>> Linux/Aarch64. Compared to boost, there is no support for Sparc and > >>>>>>>> PPC > >>>>>>>> platforms. If anyone here pops up willing to test the Sparc/PPC > >>>>>>>> support, > >>>>>>>> I can add it. > >>>>>>>> > >>>>>>>> I hope this will sort out the boost issues for good. > >>>>>>>> > >>>>>>>> Cheers, > >>>>>>>> Tom > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> ___ > >>>>>>>> Mailing list: https://launchpad.net/~kicad-developers > >>>>>>>> Post to : kicad-developers@lists.launchpad.net > >>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers > >>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> ___ > >>>>>>> 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 > >>> > >> > >> > > > > > > > > ___ 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] [PATCH] [RFC] Get rid of boost::context
C++ error messages are _awful_, really. OT: I wish the language/compiler had a mode to declare certain classes and templates "opaque", where the compiler would only provide error messages up to the point where you interact with an object and not messages from inside it. Alternatively I'd love a way to restrict types more. The Rust language has a way to specify all sorts of restrictions on template parameters via its "trait" system. For example, if you are making a container class, you can explicitly declare that its contained type must bear the "Sized" trait, and if you try to use a non-sized type the compiler will very clearly complain that you passed a non-sized type to a container requiring Sized. Hell, you could even provide an alternative implementation of the container for non-sized types that looks up the size dynamically at runtime and allocates storage on the heap. C++ needs this. On Tue, Mar 07, 2017 at 05:31:48PM +0100, Maciej Sumiński wrote: > I realize what was the problem. What I meant is the verbosity of the > error message that could be shortened to 'incomplete type information', > but perhaps a lengthy explanation is sometimes necessary. > > On 03/07/2017 05:26 PM, Chris Pavlina wrote: > > Lol, it's a pretty major thing if you look at what std::deque was trying > > to do...I don't see any way for the compiler to resolve this with the > > implementation of std::deque it was using ;) > > > > Thanks for the quick fix. > > > > On Tue, Mar 07, 2017 at 05:24:14PM +0100, Maciej Sumiński wrote: > >> Thank you Chris, now it should build fine on OSX as well. I really love > >> compilers screaming so much about such minor things. > >> > >> Regards, > >> Orson > >> > >> On 03/07/2017 04:51 PM, Chris Pavlina wrote: > >>> On Tue, Mar 07, 2017 at 04:35:44PM +0100, Maciej Sumiński wrote: > >>>> I use Linux+clang (3.9) and here the compiler does not complain. What is > >>>> the error message? > >>> > >>> Error dump attached. > >>> > >>>> Does it really build if you revert only this > >>>> particular commit? > >>> > >>> I also reverted the one directly after it because they looked connected. > >>> The build on macOS takes long enough that I didn't want to have to try > >>> twice. > >>> > >>>> > >>>> Cheers, > >>>> Orson > >>>> > >>>> On 03/07/2017 04:15 PM, Chris Pavlina wrote: > >>>>> Tested, works fine. > >>>>> > >>>>> By the way, the following commit breaks the build on macOS, and probably > >>>>> also Linux+clang. I had to revert it to get a successful build: > >>>>> > >>>>> commit d1550b0cdb990ba1f4f32220e110f8ff6331a5f1 > >>>>> Author: Maciej Suminski > >>>>> Date: Mon Mar 6 11:41:06 2017 +0100 > >>>>> > >>>>> Renamed VIEW_CONTROLS::SETTINGS to VC_SETTINGS. > >>>>> > >>>>> Because nested types cannot be forwarded. > >>>>> > >>>>> > >>>>> > >>>>> On Tue, Mar 07, 2017 at 09:40:04AM -0500, Wayne Stambaugh wrote: > >>>>>> I'm thinking a valid build and a quick check that the P&S router > >>>>>> doesn't > >>>>>> crash should be adequate. > >>>>>> > >>>>>> On 3/7/2017 9:32 AM, Chris Pavlina wrote: > >>>>>>> How thoroughly? I can build it on macOS and poke around a bit, but I > >>>>>>> don't have time to spend a day doing layout with it right now. > >>>>>>> > >>>>>>> > >>>>>>> On Tue, Mar 07, 2017 at 09:23:30AM -0500, Wayne Stambaugh wrote: > >>>>>>>> It needs to be tested on osx before we commit the patch. > >>>>>>>> > >>>>>>>> On 3/7/2017 9:24 AM, Maciej Sumiński wrote: > >>>>>>>>> Brief testing with Win7 x86_64 gives positive results. I really hope > >>>>>>>>> this is the end of the boost::context nightmare. > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Orson > >>>>>>>>> > >>>>>>>>> On 03/07/2017 02:36 PM, Tomasz Wlostowski wrote: > >>>
[Kicad-developers] Ubuntu Unity repaint issues - anyone seen this?
I'm currently dealing with this bug: https://bugs.launchpad.net/kicad/+bug/1670705 Under certain conditions (which I really have not been able to identify), wx stops firing paint events for certain widgets, only under Ubuntu Unity. The same exact system switched to GNOME does not have the issue. Has anyone seen an issue like this? I'm totally stumped. -- Chris ___ 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] [PATCH] [RFC] Get rid of boost::context
On Tue, Mar 07, 2017 at 08:04:17PM +0100, Simon Richter wrote: > Hi, > > Am 07.03.2017 um 14:36 schrieb Tomasz Wlostowski: > > > The attached patch removes boost::context dependency by introducing a > > single-file libcontext that automatically detects the compiler & > > platform and provides a stable API, contrary to the Boost libs. If you > > have some spare time, please test it, in particular on Windows and OSX. > > Queued as > > http://ci.kicad-pcb.org/job/windows-kicad-msys2-patch/665/ > > http://ci.kicad-pcb.org/job/windows-kicad-msvc-patch/10/ > > > I verified the library (outside Kicad) on > > Win32/Win64/Linux-i386/Linux-x86/64, OSX/x86_64, Linux/ARM and > > Linux/Aarch64. Compared to boost, there is no support for Sparc and PPC > > platforms. If anyone here pops up willing to test the Sparc/PPC support, > > I can add it. > > Debian is definitely unhappy when packages drop release architectures, > so it should be possible to rouse someone there. Honestly, as far as I'm concerned, Debian can sit and spin if they're displeased that we've dropped PPC. They're welcome to step up and provide the testing and support themselves. > >Simon > ___ 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] Ubuntu Unity repaint issues - anyone seen this?
Bleh, found it. Misuse of Freeze()/Thaw(). On Tue, Mar 07, 2017 at 12:39:24PM -0500, Chris Pavlina wrote: > I'm currently dealing with this bug: > https://bugs.launchpad.net/kicad/+bug/1670705 > > Under certain conditions (which I really have not been able to > identify), wx stops firing paint events for certain widgets, only under > Ubuntu Unity. The same exact system switched to GNOME does not have the > issue. > > Has anyone seen an issue like this? I'm totally stumped. > > -- > Chris ___ 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] [PATCH] Show the busy cursor while loading libraries
Hi, This patch enables display of the "busy" cursor while schematic libraries are being loaded. Tested on Linux, Windows 10, and macOS 10.12. -- Chris >From 4003d34cccfea0b88def73169038fa192a94f85f Mon Sep 17 00:00:00 2001 From: Chris Pavlina Date: Wed, 8 Mar 2017 15:10:35 -0500 Subject: [PATCH] Show the busy cursor while loading libraries --- eeschema/class_library.cpp | 2 ++ 1 file changed, 2 insertions(+) diff --git a/eeschema/class_library.cpp b/eeschema/class_library.cpp index 22b4a6fbe..0a35a6123 100644 --- a/eeschema/class_library.cpp +++ b/eeschema/class_library.cpp @@ -49,6 +49,7 @@ #include #include #include +#include #define DUPLICATE_NAME_MSG \ _( "Library '%s' has duplicate entry name '%s'.\n" \ @@ -554,6 +555,7 @@ void PART_LIBS::LoadAllLibraries( PROJECT* aProject, bool aShowProgress ) wxStringfilename; wxStringlibs_not_found; SEARCH_STACK* lib_search = aProject->SchSearchS(); +wxBusyCursorbusy_while_loading; #if defined(DEBUG) && 0 lib_search->Show( __func__ ); -- 2.12.0 ___ 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] [PATCH] Show the busy cursor while loading libraries
That's why I submitted such a trivial patch to the list first, I figured someone would say something ;) It does make sense to me, because the GUI is blocked. The busy cursor says to me "yes, the GUI is supposed to be blocked right now, it's not frozen". Even with a progress bar, it can seem unresponsive - particularly if 1) the progress bar ends up obscured, as can happen with 'weird' window managers sometimes, or 2) if a single library takes a particularly long time to load, which I'm sure will only get worse if we eventually allow loading them over the internet like for footprint libs. On Wed, Mar 08, 2017 at 03:55:10PM -0500, Wayne Stambaugh wrote: > Does showing a progress dialog and a busy cursor at the same time make > sense? > > On 3/8/2017 3:36 PM, Chris Pavlina wrote: > > Hi, > > > > This patch enables display of the "busy" cursor while schematic > > libraries are being loaded. Tested on Linux, Windows 10, and macOS > > 10.12. > > > > > > > > ___ > > 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] [PATCH] Show the busy cursor while loading libraries
On Wed, Mar 08, 2017 at 04:33:06PM -0500, Wayne Stambaugh wrote: > On 3/8/2017 4:08 PM, Chris Pavlina wrote: > > That's why I submitted such a trivial patch to the list first, I figured > > someone would say something ;) > > > > It does make sense to me, because the GUI is blocked. The busy cursor > > says to me "yes, the GUI is supposed to be blocked right now, it's not > > frozen". Even with a progress bar, it can seem unresponsive - > > particularly if 1) the progress bar ends up obscured, as can happen with > > 'weird' window managers sometimes, or 2) if a single library takes a > > particularly long time to load, which I'm sure will only get worse if we > > eventually allow loading them over the internet like for footprint libs. > > It's the old belt and suspender method. Users have got to quit using > those 'weird' window managers. It causes way too much grief. I'm not sure displaying a busy cursor while the GUI is frozen is grief. I've always considered it correct behavior, to be honest, regardless of the presence or absence of a weird window manager. The busy cursor has been used for _years_ to indicate a GUI that cannot be interacted with, so users expect it - not displaying it sends conflicting messages; you are saying by the absence of such a standard item that the GUI is ready to use. > I'm > surprised that a single library load takes long enough to need a busy > cursor but I'm not opposed to the patch. Does the progress bar in > wxWidgets have a continuous mode? That doesn't solve the hidden > progress window issue though. There is a continuous mode, though I'm not sure what the benefit of using it would be, and it's a bit strange (you have to "poke" it pretty continuously or it freezes). I wouldn't use it. I'm not sure why library loading got so slow suddenly. I'd profile it but I don't have time. > > > > > > > On Wed, Mar 08, 2017 at 03:55:10PM -0500, Wayne Stambaugh wrote: > >> Does showing a progress dialog and a busy cursor at the same time make > >> sense? > >> > >> On 3/8/2017 3:36 PM, Chris Pavlina wrote: > >>> Hi, > >>> > >>> This patch enables display of the "busy" cursor while schematic > >>> libraries are being loaded. Tested on Linux, Windows 10, and macOS > >>> 10.12. > >>> > >>> > >>> > >>> ___ > >>> 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] [PATCH] Show the busy cursor while loading libraries
On Thu, Mar 09, 2017 at 09:46:54AM +1100, Oliver Walters wrote: > > > > Slow? I have noticed that the library loading slowness appeared with > > the new IO manager thing. Although I don't have any proff to quanify > > that. > > > I can also attest that (at least on Windows) the more recently nightlies > (corresponding to the new IO plugin, approximately) take ~10s to load a > library set that was previously < 1s. > > Once the libraries are loaded, eeschema takes an additional length of time > (~10s) to open, whereas previously it opened "instantly" I've noticed this too. Funny enough it doesn't seem to happen for all projects for me. I wonder if it's something only being done sometimes, or a polynomial time explosion. Either way someone needs to point the business end of a profiler at the library loader. > > On Thu, Mar 9, 2017 at 8:54 AM, Nick Østergaard wrote: > > > 2017-03-08 22:33 GMT+01:00 Wayne Stambaugh : > > > On 3/8/2017 4:08 PM, Chris Pavlina wrote: > > >> That's why I submitted such a trivial patch to the list first, I figured > > >> someone would say something ;) > > >> > > >> It does make sense to me, because the GUI is blocked. The busy cursor > > >> says to me "yes, the GUI is supposed to be blocked right now, it's not > > >> frozen". Even with a progress bar, it can seem unresponsive - > > >> particularly if 1) the progress bar ends up obscured, as can happen with > > >> 'weird' window managers sometimes, or 2) if a single library takes a > > >> particularly long time to load, which I'm sure will only get worse if we > > >> eventually allow loading them over the internet like for footprint libs. > > > > > > It's the old belt and suspender method. Users have got to quit using > > > those 'weird' window managers. It causes way too much grief. I'm > > > surprised that a single library load takes long enough to need a busy > > > cursor but I'm not opposed to the patch. Does the progress bar in > > > wxWidgets have a continuous mode? That doesn't solve the hidden > > > progress window issue though. > > > > > > > I like the non-continous mode. > > > > Slow? I have noticed that the library loading slowness appeared with > > the new IO manager thing. Although I don't have any proff to quanify > > that. > > > > >> > > >> > > >> On Wed, Mar 08, 2017 at 03:55:10PM -0500, Wayne Stambaugh wrote: > > >>> Does showing a progress dialog and a busy cursor at the same time make > > >>> sense? > > >>> > > >>> On 3/8/2017 3:36 PM, Chris Pavlina wrote: > > >>>> Hi, > > >>>> > > >>>> This patch enables display of the "busy" cursor while schematic > > >>>> libraries are being loaded. Tested on Linux, Windows 10, and macOS > > >>>> 10.12. > > >>>> > > >>>> > > >>>> > > >>>> ___ > > >>>> 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 > > > > ___ > > 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
