[Kicad-developers] Bug #1773638: The origins of 6.0 (pun intended)

[Reece R. Pollack]

Rene pointed out that my work on display origin transforms is really a fix for 
Bug #1773638, thus the retitling.

I'm making good progress, but I need a bit of guidance before proceeding 
further.

The code I've developed allows the user to select the origin for the display of X and Y 
coordinates, rather than the origin always being the upper left corner of the surrounding 
"page" frame. There is no change to the underlying board file or internal 
coordinate representation. This is purely a change the way coordinates are displayed to 
the user and entered by the user in dialog boxes.

The user gets three configuration options:

 * The absolute display origin: Page (default), Aux, or Grid.
 * The direction of the positive Y-axis: Down (default) or Up.
 * The direction of the positive X-axis: Right (default) or Left.

I've attached patch diffs for review and experimentation. The patches will apply cleanly to the 
current "eemodern" branch (commit 6137921), the 5.1.2 tag with one trivial merge error, 
and probably the "master" branch. It's not ready for merging, though. It lacks a UI for 
configuration, and configuration isn't saved or loaded from the user preferences file. For testing 
the config defaults to Aux origin and Y-axis Up. Obviously these deficiencies will have to be 
addressed before a merge.

Now for my request for guidance:

1. The user configuration options are currently in the PCB_DISPLAY_OPTIONS 
class. I'd like some confirmation that this is the correct place before I code 
the preferences file save and restore.
2. Where should the config UI go? I expect this will be a set-and-forget thing for most 
users. I'm thinking on the Pcbnew Preferences -> Preferences -> Pcbnew -> 
Display Options dialog, if there's room. But this panel seems to be half-shared with 
other apps and is getting kind of full. Perhaps another panel instead of Display Options?
3. The last time I did UI work was when the TRS-80 was hot stuff (I'm a Linux 
kernel guy). Can someone recommend an approach for developing the UI changes, 
and perhaps a pointer to a relevant how-to?
4. The dx/dy (relative coordinate) part of the status line isn't being 
transformed yet because of commit e6a200b. I posted a question regarding that 
earlier today but haven't received any replies yet.
5. Have I missed any dialog boxes that present absolute coordinates to the 
user? There's a list in the commit log.
6. Should this be extended to the footprint editor? Eeschema? Anywhere else?

Thanks for the help, folks!

-Reece


>From 4c9c94a1364397809741590eb952a1f79aac944b Mon Sep 17 00:00:00 2001
From: "Reece R. Pollack" 
Date: Fri, 3 May 2019 09:43:11 -0400
Subject: [PATCH 1/2] RRP: Common changes to support Display Origin Transforms

This commit contains the changes to common files to support Display
Origin Transforms. This will allow the user to change the origin
of the displayed coordinates in status lines and dialog boxes to be
relative to a user-selected origin.

The origin may be selected as one of the following:
  * The upper left corner of the surrounding page frame
  * The Auxilliary origin (aka Drill or Manufacturing origin)
  * The Grid origin

The defined transforms are:
  * A null (or identity) transform
  * X-axis origin and sign transform for absolute coordinates
  * Y-axis origin and sign transform for absolute coordinates
  * X-axis sign transform for relative coordinates
  * Y-axis sign transform for relative coordinates

The default transform is the null transform, and is supplied by
the EDA_DRAW_FRAME class. These transforms may be overridden by
derived classes, such as the PCB_BASE_FRAME class.
---
 common/widgets/unit_binder.cpp | 29 -
 include/common.h   | 15 +++
 include/draw_frame.h   | 10 ++
 include/widgets/unit_binder.h  | 15 ++-
 4 files changed, 63 insertions(+), 6 deletions(-)

diff --git a/common/widgets/unit_binder.cpp b/common/widgets/unit_binder.cpp
index 4e7b7ab..e5c7c1f 100644
--- a/common/widgets/unit_binder.cpp
+++ b/common/widgets/unit_binder.cpp
@@ -35,11 +35,14 @@ wxDEFINE_EVENT( DELAY_FOCUS, wxCommandEvent );
 
 UNIT_BINDER::UNIT_BINDER( EDA_DRAW_FRAME* aParent,
   wxStaticText* aLabel, wxWindow* aValue, wxStaticText* aUnitLabel,
-  bool aUseMils, bool allowEval ) :
+  bool aUseMils, bool allowEval, ORIGIN_XFORMS aOriginXform ) :
+m_parent( aParent ),
 m_label( aLabel ),
 m_value( aValue ),
 m_unitLabel( aUnitLabel ),
-m_eval( aParent->GetUserUnits(), aUseMils )
+m_eval( aParent->GetUserUnits(), aUseMils ),
+m_originXform( aOriginXform ),
+m_allowOriginXform( aOriginXform != ORIGIN_XFORM_NONE )
 {
 // Fix the units (to the current units) for the life of the binder
 m_units = aParent->GetUserUnits();
@@ -168,7 +171,11 @@ bool UNIT_BINDER::Validate( int aMin, int aMax, bool setFocusOnError )
 
 void 

Re: [Kicad-developers] eemodern merge request

[Nick Østergaard]

Hello Jeff,

I ran my "evaluate" script on your branch and there are a couple of
commits that are not buildable, see
https://jenkins.simonrichter.eu/job/windows-kicad-msys2-evaluate/107/artifact/build-report.txt

As usual the builds logs are available on the jenkins job if you need
them. (You may want to "save as" the plain text build log if you wan
it)

Nick

On Sat, 4 May 2019 at 18:18, Jeff Young  wrote:
>
> OK, my re-factor is in.
>
> > On 4 May 2019, at 16:03, Jeff Young  wrote:
> >
> > Give me a bit to merge first, though.  I’ve re-arranged a bunch of code in 
> > preparation for sharing some of it with libedit.
> >
> >
> >
> >> On 4 May 2019, at 16:01, Jeff Young  wrote:
> >>
> >> Hi Tom,
> >>
> >> I didn’t even notice it was missing.  If you want to have a crack at it, 
> >> that would be great.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>
> >>> On 4 May 2019, at 15:56, Tomasz Wlostowski  
> >>> wrote:
> >>>
> >>> On 02/05/2019 15:51, Jeff Young wrote:
>  The eeschema modern toolset is “finished”.
> 
>  It can be found at origin/eemodern.  A bit of testing before merging 
>  might be in order….
> >>>
> >>> Hi Jeff,
> >>>
> >>> I noticed eemodern it's missing mouse drag action (i.e. dragging a
> >>> selected wire/component/etc. just starts drawing another selection
> >>> rectangle). Are you planning to add it (I can also contribute this
> >>> feature - long flight tomorrow should be enough to code it ;-)
> >>>
> >>> 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] kicad_pcb, kicad_mod format change for daily build?

[Kevin Cozens]

On 2019-04-21 12:46 p.m., Jeff Young wrote:

KiCad will read them in either way (quoted or un-quoted).

KiCad has always written them out with quotes if they had spaces in them (so 
other tools have always needed to handle quotes).

Were just being more consistent now as theres no justification 
for ???saving a few characters??? in this day and age (and going 
forward it will make things easier).

[snip]

(layers
(0 F.Cu signal)
(31 B.Cu signal)

(layers
(0 "F.Cu" signal)
(31 "B.Cu" signal)


Thanks for the reply, Jeff. I'll check whether my Perl scripts include the 
quotes. I'm also going to bump the file format version I'm outputting to the 
files I generate and hope there aren't any undocumented changes that will 
give KiCad a problem when it tries to read the schematic and/or library file.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   | "Nerds make the shiny things that
https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
| that's why we're powerful"
Owner of Elecraft K2 #2172  |
#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

Re: [Kicad-developers] Unfolding a bus....

[Jeff Young]

Hi Jon,

I must have overlooked this in my email.  I’ll get these patched up tomorrow.

Cheers,
Jeff.


> On 3 May 2019, at 01:31, Jon Evans  wrote:
> 
> Hi Jeff,
> Thanks for cranking through all these features!  It's quite impressive seeing 
> the progress :-)
> 
> I gave bus unfolding a try and noticed a few issues:
> 
> 1) It looks like in your branch, bus unfolding is only possible while already 
> in the "draw bus" tool.  It was originally intended to be something that you 
> could trigger from a selected bus, just like the other immediate commands 
> (move/rotate/etc)
> 
> 2) When I start unfolding a bus, I get the following assertion when I place 
> the bus label:
> eeschema/tools/sch_line_drawing_tool.cpp(561): assert "aType == LAYER_WIRE" 
> failed in doDrawSegments().
> I think this is because the doDrawSegments() of the "draw bus" tool is still 
> called even after the unfold starts (and another doDrawSegments is running to 
> place the unfolded wires)
> 
> 3) The keyboard shortcut doesn't seem to do anything anymore, I can only 
> unfold from the context menu.  Does it work for you?
> 
> Unfortunately I don't have time tonight to look more closely at any of these 
> issues, but I can look at them tomorrow if you don't find them first.
> 
> I like your implementation of BUS_UNFOLD_MENU to handle the dynamic checks -- 
> this pattern will probably be useful for other things in the future!
> 
> Best,
> Jon
> 
> On Thu, May 2, 2019 at 4:05 PM Jeff Young  > wrote:
> Bits pushed.
> 
> Main parts are now in sch_line_drawing_tool.cpp.  BUS_UNFOLD_MENU starts on 
> line 96, it’s added to the context menu at line 222, and the commands are 
> dispatched starting at line 674.
> 
> BTW: there are some synthetic KICAD_T types that can be used for fishing out 
> sub-types of KICAD_T.  Of interest will be SCH_LINE_LOCATE_BUS_T and 
> SCH_LINE_LOCATE_WIRE_T.  (There have been similar ones for reference, value, 
> footprint and datasheet SCH_FIELD_Ts for some time.)
> 
> Cheers,
> Jeff.
> 
>> On 2 May 2019, at 20:41, Jeff Young mailto:j...@rokeby.ie>> 
>> wrote:
>> 
>> (I also got my simple test working by renaming my bus label from "D0..31" to 
>> "D[0..31]”.)
>> 
>>> On 2 May 2019, at 20:39, Jeff Young >> > wrote:
>>> 
>>> Ha!  Works right out of the box.
>>> 
>>> I’ll push it to origin/eemodern shortly so you can have a look.
>>> 
>>> Cheers,
>>> Jeff.
>>> 
>>> 
 On 2 May 2019, at 20:07, Jon Evans >>> > wrote:
 
 Hi Jeff,
 You can test unfolding using one of the demo projects that uses buses (for 
 example: video)
 
 -Jon
 
 On Thu, May 2, 2019 at 2:57 PM Jeff Young >>> > wrote:
 Hi Jon,
 
 I’ve moved the bus unfolding menu to the modern toolkit and I’m trying to 
 test it.  How do I give a bus connections?  I tried a wire2bus entry with 
 a label on the wire, and connecting the wire to an annotated component, 
 and giving the bus a label of “D0..D31”, but none of those worked.  (Or 
 one of them did but I’ve got a bug somewhere.)
 
 Thanks,
 Jeff.
 ___
 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] Project annuouncement.

[Wayne Stambaugh]

Nick,

Thanks.  I will actually have spare time now which I plan to use doing
things outside of KiCad.  Prior to the new job, there really wasn't any
free time to speak of.

Cheers,

Wayne

On 5/4/19 4:16 PM, Nick Østergaard wrote:
> Congratulations Wayne. That sounds like good news for everyone. But
> remember not to burn yourself out, just the opportunity to take a
> break from kicad in your "spare" time then :)
> 
> On Sat, 27 Apr 2019 at 20:05, Wayne Stambaugh  wrote:
>>
>> For those you who haven't heard yet, I made the announcement yesterday
>> at KiCon that I am now work for WIT and I will be working full time on
>> KiCad.  I really excited about the possibilities for KiCad going
>> forward.  Here is the moment when I made the announcement at KiCon.
>>
>> https://www.facebook.com/dfustini/posts/10219431437645036?notif_id=1556317416870013_t=mention
>>
>> 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] Project annuouncement.

[Nick Østergaard]

Congratulations Wayne. That sounds like good news for everyone. But
remember not to burn yourself out, just the opportunity to take a
break from kicad in your "spare" time then :)

On Sat, 27 Apr 2019 at 20:05, Wayne Stambaugh  wrote:
>
> For those you who haven't heard yet, I made the announcement yesterday
> at KiCon that I am now work for WIT and I will be working full time on
> KiCad.  I really excited about the possibilities for KiCad going
> forward.  Here is the moment when I made the announcement at KiCon.
>
> https://www.facebook.com/dfustini/posts/10219431437645036?notif_id=1556317416870013_t=mention
>
> 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] eeSchema V6 - any thoughts as to tabbed schematics?

[Nick Østergaard]

It looks like there is an issue with the patch builds, the kicad
binaries are not included in the installer, only some dependencies...
So don't use that build.

On Fri, 3 May 2019 at 16:00, Nick Østergaard  wrote:
>
> I have uploaded a build of the eemodern branch on
> https://jenkins.simonrichter.eu/job/windows-kicad-msys2-patch/lastSuccessfulBuild/artifact/out/pack-x86_64/kicad-patched-330-5.1.0-437-gc807783d7-x86_64.exe
>
>
> On Fri, 3 May 2019 at 14:06, Brian Piccioni  
> wrote:
> >
> > Hello Devs
> >
> >
> >
> > This is well beyond my capabilities, but I have been wondering if having 
> > tabbed schematics is a viable feature for eeSchema?
> >
> >
> >
> > Currently you have to open another instance of eeSchema or click through to 
> > sheets in order to see other sheets. Tabs would be more convenient than 
> > clicking on a sheet (or multiple levels of sheets), backing out, etc., at 
> > least in many circumstances. So, rather than leaving the current sheet when 
> > clicking down one would open a tab.
> >
> >
> >
> > In terms of implementation, although, again, this is well beyond my 
> > abilities it seems to me tabbed sheets would mostly be an issue of 
> > selecting which to render and to treat as “on top” or in focus. eeSchema 
> > files are tiny so memory would likely not be an issue.
> >
> >
> >
> > Anyhow I thought I’d suggest it.
> >
> >
> >
> > Also, I see lots of talk about the “modern eeSchema”. Since I have a few 
> > boards to lay out I’d like to test it, but I don’t know where the download 
> > is. I am on Windows and I can build from source.
> >
> >
> >
> >
> >
> > Brian Piccioni
> >
> >
> >
> >
> >
> > ___
> > 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] eemodern merge request

[Jeff Young]

OK, my re-factor is in.

> On 4 May 2019, at 16:03, Jeff Young  wrote:
> 
> Give me a bit to merge first, though.  I’ve re-arranged a bunch of code in 
> preparation for sharing some of it with libedit.
> 
> 
> 
>> On 4 May 2019, at 16:01, Jeff Young  wrote:
>> 
>> Hi Tom,
>> 
>> I didn’t even notice it was missing.  If you want to have a crack at it, 
>> that would be great.
>> 
>> Cheers,
>> Jeff.
>> 
>> 
>>> On 4 May 2019, at 15:56, Tomasz Wlostowski  
>>> wrote:
>>> 
>>> On 02/05/2019 15:51, Jeff Young wrote:
 The eeschema modern toolset is “finished”.
 
 It can be found at origin/eemodern.  A bit of testing before merging might 
 be in order….
>>> 
>>> Hi Jeff,
>>> 
>>> I noticed eemodern it's missing mouse drag action (i.e. dragging a
>>> selected wire/component/etc. just starts drawing another selection
>>> rectangle). Are you planning to add it (I can also contribute this
>>> feature - long flight tomorrow should be enough to code it ;-)
>>> 
>>> 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

Re: [Kicad-developers] eemodern merge request

[Jeff Young]

Give me a bit to merge first, though.  I’ve re-arranged a bunch of code in 
preparation for sharing some of it with libedit.



> On 4 May 2019, at 16:01, Jeff Young  wrote:
> 
> Hi Tom,
> 
> I didn’t even notice it was missing.  If you want to have a crack at it, that 
> would be great.
> 
> Cheers,
> Jeff.
> 
> 
>> On 4 May 2019, at 15:56, Tomasz Wlostowski  wrote:
>> 
>> On 02/05/2019 15:51, Jeff Young wrote:
>>> The eeschema modern toolset is “finished”.
>>> 
>>> It can be found at origin/eemodern.  A bit of testing before merging might 
>>> be in order….
>> 
>> Hi Jeff,
>> 
>> I noticed eemodern it's missing mouse drag action (i.e. dragging a
>> selected wire/component/etc. just starts drawing another selection
>> rectangle). Are you planning to add it (I can also contribute this
>> feature - long flight tomorrow should be enough to code it ;-)
>> 
>> 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

Re: [Kicad-developers] eemodern merge request

[Jeff Young]

Hi Tom,

I didn’t even notice it was missing.  If you want to have a crack at it, that 
would be great.

Cheers,
Jeff.


> On 4 May 2019, at 15:56, Tomasz Wlostowski  wrote:
> 
> On 02/05/2019 15:51, Jeff Young wrote:
>> The eeschema modern toolset is “finished”.
>> 
>> It can be found at origin/eemodern.  A bit of testing before merging might 
>> be in order….
> 
> Hi Jeff,
> 
> I noticed eemodern it's missing mouse drag action (i.e. dragging a
> selected wire/component/etc. just starts drawing another selection
> rectangle). Are you planning to add it (I can also contribute this
> feature - long flight tomorrow should be enough to code it ;-)
> 
> 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] eemodern merge request

[Tomasz Wlostowski]

On 02/05/2019 15:51, Jeff Young wrote:
> The eeschema modern toolset is “finished”.
> 
> It can be found at origin/eemodern.  A bit of testing before merging might be 
> in order….

Hi Jeff,

I noticed eemodern it's missing mouse drag action (i.e. dragging a
selected wire/component/etc. just starts drawing another selection
rectangle). Are you planning to add it (I can also contribute this
feature - long flight tomorrow should be enough to code it ;-)

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] eeSchema V6 - any thoughts as to tabbed schematics?

[mallardproductions]

 I totally love this idea. Perhaps a "bookmark" format sidebar / optional 
toolbar with icons to indicate the number of sheets in a file. Maybe even a 
simple sheet count indicator beside the current icon. To my limited use 
knowledge, there are no current "indicators" for that. Some of us mad scientist 
DIY newbs with age related short term memory issues rarely create files with 
more than one sheet, then forget where we did that. :)



 On Saturday, May 4, 2019, 2:41:41 a.m. MDT, Michael Kavanagh 
 wrote:  
 
 Making the Hierarchical Navigator modeless and dockable would be a good start, 
and is more doable in the short term.
Cheers,Michael
On Sat, 4 May 2019 at 01:41, Russell Oliver  wrote:

One thing I liked from Eagle was the list of sheets as thumbnails to
allow for visual recognition.


Regards
Russell Oliver



On Sat, 4 May 2019 at 10:20, Andrew Lutsenko  wrote:
>
> Hi Brian,
>
> There already is an easier way to navigate sheets than what you describe: 
> click "Navigate schematic hierarchy" button on top toolbar or "View -> Show 
> hierarchical navigator" which both open same view of schematic sheet tree. 
> Single click on any sheet will bring you directly to it so in your example 
> it's just two clicks (if using toolbar), regardless of level of sheet you are 
> coming from/navigating to.
>
> That said I too would love to see faster navigation via tabs, even if it's 
> just "only one tab at a time" deal.
>
> Regards,
> Andrew
>
> On Fri, May 3, 2019 at 4:49 PM Brian Piccioni  
> wrote:
>>
>> Jon
>>
>>
>>
>> My thought was simply that: a quick way of switching between sheets.
>>
>>
>>
>> Lets say I am in the main sheet and want to look at a circuit 2 levels down: 
>> I have to find the right sheet, click it, find the next sheet, click that, 
>> have a look, then backup and backup.
>>
>>
>>
>> I have found it much easier to simply open a new instance of eeSchema, 
>> however, that would present some problems if I touch any of the files due to 
>> coherency issues.
>>
>>
>>
>> It would be much easier to have a sheet list (I thought of tabs because that 
>> is the current paradigm for such things) and select click on the target 
>> sheet then click on the main sheet to return. There may be an easier way of 
>> doing so via, say, a right mouse click or something if wxWidgets is not yet 
>> up to the task.
>>
>>
>>
>> I wasn’t thinking of concurrent viewing at all, and I can see how that would 
>> complicate matters.
>>
>>
>>
>> I was ruminating on this because of my current project to renumber boards. I 
>> have made great progress and expect to start integrating it with PCBNew and 
>> eeSchema as a prototype within a few days.
>>
>>
>>
>> My utility currently caches the schematic hierarchy and it struck me that 
>> with some modification that would permit quick selection of any sheet in the 
>> hierarchy, with the resulting benefits in terms of usability.
>>
>>
>>
>> Not that I’d suggest a hack in production code but one can imagine 
>> prototyping this by essentially inserting a UI in the file open menu item, 
>> keeping track of dirty sheets, and writing the cache out when invoking a 
>> save command.
>>
>>
>>
>> Of course, this is no doubt simplistic given my lack of expertise in the 
>> matter.
>>
>>
>>
>> Brian
>>
>>
>>
>>
>>
>>
>>
>> From: Jon Evans 
>> Sent: May 3, 2019 10:52 AM
>> To: Brian Piccioni 
>> Cc: Kevin Cozens ; kicad-developers 
>> 
>> Subject: Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed 
>> schematics?
>>
>>
>>
>> If this is essentially adding a faster way to switch between sheets, it 
>> should be very straightforward.
>>
>> If instead you want to be able to view more than one sheet at a time (side 
>> by side tabs, or something), it would be more complex because currently 
>> Eeschema has a lot of code that expects only a single sheet active at a time.
>>
>>
>>
>> -Jon
>>
>>
>>
>> On Fri, May 3, 2019 at 10:45 AM Brian Piccioni  
>> wrote:
>>
>> Thanks.
>>
>> I suspect that it doesn't require much change since one would be essentially
>> changing the focus to a sheet in memory rather than reloading it.
>>
>> Brian
>>
>> -Original Message-
>> From: Kicad-developers
>> 
>> On Behalf Of Kevin Cozens
>> Sent: May 3, 2019 10:36 AM
>> To: kicad-developers 
>> Subject: Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed
>> schematics?
>>
>> On Fri, 3 May 2019 at 14:06, Brian Piccioni 
>> wrote:
>> > Currently you have to open another instance of eeSchema or click
>> > through to sheets in order to see other sheets. Tabs would be more
>> > convenient than clicking on a sheet (or multiple levels of sheets),
>> > backing out, etc., at least in many circumstances.
>>
>> That is an interesting idea. It could become an option in addition to the
>> current sheet navigation system. A new option could be added which would be
>> something like "Pin sheet to tab".
>>
>> --
>> Cheers!
>>
>> Kevin.
>>
>> http://www.ve3syb.ca/               | "Nerds make 

[Kicad-developers] Question on commit e6a200b "Pcbnew: avoid integer overflow when displaying local coordinates"

[Reece R. Pollack]

I have a question on this commit:

commit e6a200b09e9a38baac4bde53b68d3def6d2d350c
Author: jean-pierre charras 
Date:   Thu Feb 14 10:55:57 2019 +0100

Pcbnew: avoid integer overflow when displaying local coordinates.
Minor cleanup in code.

This commit changes the calculations of relative coordinates
from integer to floating-point. For example, this calculation:

int dx = GetCrossHairPosition().x - screen->m_O_Curseur.x;

became this:

double dx = (double)GetCrossHairPosition().x - 
(double)screen->m_O_Curseur.x;

There are several other such changes. I don't understand why this
is necessary, and the commit doesn't reference a bug report.  What
circumstances resulted in this commit?

The reason I ask is that bears strongly on the changes I'm working
on to display coordinates relative to a user-selected origin. To
translate coordinates from the internal origin to the user origin I
subtract the user origin coordinates from the internal coordinates.
And, of course, to translate back to the internal origin I add the
user origin coordinates to the displayed coordinates. If this is
likely to overflow then my changes might re-introduce whatever
problem this commit was intended to correct.

The internal representation is in nanometers (1e-9). A signed 32-bit
integer can therefore represent 2^31 (~2.147) meters. Subtracting one
integer coordinate from another could only overflow if the distance
between them is greater than this, which implies one value is positive
and the other is negative. Converting the operands to double before
the subtraction doesn't eliminate the problem, it only extends it to
2^32 or 4.295 meters.

Does KiCad support schematic sheets or PCBs larger than 2 meters? If
so, then we should promote the internal units to "long long" and not
hack around with half-steps like this. If not, then this commit isn't
needed.

-Reece

___
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] eeSchema V6 - any thoughts as to tabbed schematics?

[Michael Kavanagh]

Making the Hierarchical Navigator modeless and dockable would be a good
start, and is more doable in the short term.

Cheers,
Michael

On Sat, 4 May 2019 at 01:41, Russell Oliver  wrote:

> One thing I liked from Eagle was the list of sheets as thumbnails to
> allow for visual recognition.
>
>
> Regards
> Russell Oliver
>
>
>
> On Sat, 4 May 2019 at 10:20, Andrew Lutsenko  wrote:
> >
> > Hi Brian,
> >
> > There already is an easier way to navigate sheets than what you
> describe: click "Navigate schematic hierarchy" button on top toolbar or
> "View -> Show hierarchical navigator" which both open same view of
> schematic sheet tree. Single click on any sheet will bring you directly to
> it so in your example it's just two clicks (if using toolbar), regardless
> of level of sheet you are coming from/navigating to.
> >
> > That said I too would love to see faster navigation via tabs, even if
> it's just "only one tab at a time" deal.
> >
> > Regards,
> > Andrew
> >
> > On Fri, May 3, 2019 at 4:49 PM Brian Piccioni <
> br...@documenteddesigns.com> wrote:
> >>
> >> Jon
> >>
> >>
> >>
> >> My thought was simply that: a quick way of switching between sheets.
> >>
> >>
> >>
> >> Lets say I am in the main sheet and want to look at a circuit 2 levels
> down: I have to find the right sheet, click it, find the next sheet, click
> that, have a look, then backup and backup.
> >>
> >>
> >>
> >> I have found it much easier to simply open a new instance of eeSchema,
> however, that would present some problems if I touch any of the files due
> to coherency issues.
> >>
> >>
> >>
> >> It would be much easier to have a sheet list (I thought of tabs because
> that is the current paradigm for such things) and select click on the
> target sheet then click on the main sheet to return. There may be an easier
> way of doing so via, say, a right mouse click or something if wxWidgets is
> not yet up to the task.
> >>
> >>
> >>
> >> I wasn’t thinking of concurrent viewing at all, and I can see how that
> would complicate matters.
> >>
> >>
> >>
> >> I was ruminating on this because of my current project to renumber
> boards. I have made great progress and expect to start integrating it with
> PCBNew and eeSchema as a prototype within a few days.
> >>
> >>
> >>
> >> My utility currently caches the schematic hierarchy and it struck me
> that with some modification that would permit quick selection of any sheet
> in the hierarchy, with the resulting benefits in terms of usability.
> >>
> >>
> >>
> >> Not that I’d suggest a hack in production code but one can imagine
> prototyping this by essentially inserting a UI in the file open menu item,
> keeping track of dirty sheets, and writing the cache out when invoking a
> save command.
> >>
> >>
> >>
> >> Of course, this is no doubt simplistic given my lack of expertise in
> the matter.
> >>
> >>
> >>
> >> Brian
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> From: Jon Evans 
> >> Sent: May 3, 2019 10:52 AM
> >> To: Brian Piccioni 
> >> Cc: Kevin Cozens ; kicad-developers <
> kicad-developers@lists.launchpad.net>
> >> Subject: Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed
> schematics?
> >>
> >>
> >>
> >> If this is essentially adding a faster way to switch between sheets, it
> should be very straightforward.
> >>
> >> If instead you want to be able to view more than one sheet at a time
> (side by side tabs, or something), it would be more complex because
> currently Eeschema has a lot of code that expects only a single sheet
> active at a time.
> >>
> >>
> >>
> >> -Jon
> >>
> >>
> >>
> >> On Fri, May 3, 2019 at 10:45 AM Brian Piccioni <
> br...@documenteddesigns.com> wrote:
> >>
> >> Thanks.
> >>
> >> I suspect that it doesn't require much change since one would be
> essentially
> >> changing the focus to a sheet in memory rather than reloading it.
> >>
> >> Brian
> >>
> >> -Original Message-
> >> From: Kicad-developers
> >>  documenteddesigns@lists.launchpad.net>
> >> On Behalf Of Kevin Cozens
> >> Sent: May 3, 2019 10:36 AM
> >> To: kicad-developers 
> >> Subject: Re: [Kicad-developers] eeSchema V6 - any thoughts as to tabbed
> >> schematics?
> >>
> >> On Fri, 3 May 2019 at 14:06, Brian Piccioni <
> br...@documenteddesigns.com>
> >> wrote:
> >> > Currently you have to open another instance of eeSchema or click
> >> > through to sheets in order to see other sheets. Tabs would be more
> >> > convenient than clicking on a sheet (or multiple levels of sheets),
> >> > backing out, etc., at least in many circumstances.
> >>
> >> That is an interesting idea. It could become an option in addition to
> the
> >> current sheet navigation system. A new option could be added which
> would be
> >> something like "Pin sheet to tab".
> >>
> >> --
> >> Cheers!
> >>
> >> Kevin.
> >>
> >> http://www.ve3syb.ca/   | "Nerds make the shiny things that
> >> https://www.patreon.com/KevinCozens | distract the mouth-breathers, and
> >>  | that's