Re: [Kicad-developers] Hotkeys Editor

[Thomas Kindler]

On Thu, January 11, 2018 09:37, Andrey Kuznetsov wrote:
> I wonder if "Undo All" is more appropriate if all the changes during that
>  session are undone, as opposed to just the last one.
>

That's very similar to "Cancel" then. Perhaps, we can remove the Undo
button entirely in this case.


> On Thu, Jan 11, 2018 at 12:35 AM, Thomas Kindler
> <mail_ubu...@t-kindler.de>
> wrote:
>
>
>>
>> On Thu, January 11, 2018 02:07, Seth Hillbrand wrote:
>>
>>> I feel that there is a usability issue with the current hotkeys
>>> editor that is a regression from the 4.0.7 hotkeys editor.
>>>
>>> I've attached images for both to this message.  The current editor
>>> opens with a tree view that hides the hotkeys below "Common".  Users
>>> would be forgiven for not realizing that there were additional hotkeys
>>> specific to each application -- see current_hotkeys.png
>>>
>>> Previously, the hotkeys were displayed in tabs that were, I think,
>>> more clear -- see prev_hotkeys.png.
>>>
>>> I don't recall when this change happened but I'd like any feedback on
>>>  whether folks are adverse to reverting to the 4.0.7 tabbed layout
>>> while keeping the "Reset" and "Defaults" buttons, that I think are
>>> really good additions.
>>
>> What's the difference between "Reset" and "Defaults"?
>>
>>
>> I think "Undo" and "Defaults" would be much better.
>>

___
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] Hotkeys Editor

[Thomas Kindler]

On Thu, January 11, 2018 02:07, Seth Hillbrand wrote:
> I feel that there is a usability issue with the current hotkeys editor
> that is a regression from the 4.0.7 hotkeys editor.
>
> I've attached images for both to this message.  The current editor opens
> with a tree view that hides the hotkeys below "Common".  Users would be
> forgiven for not realizing that there were additional hotkeys specific to
>  each application -- see current_hotkeys.png
>
> Previously, the hotkeys were displayed in tabs that were, I think, more
> clear -- see prev_hotkeys.png.
>
> I don't recall when this change happened but I'd like any feedback on
> whether folks are adverse to reverting to the 4.0.7 tabbed layout while
> keeping the "Reset" and "Defaults" buttons, that I think are really good
> additions.

What's the difference between "Reset" and "Defaults"?

I think "Undo" and "Defaults" would be much better.

-- 
Thomas Kindler <m...@t-kindler.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

Re: [Kicad-developers] [REQUEST] Default library install location

[Thomas Kindler]

On Thu, November 9, 2017 00:12, easyw wrote:
>> I think it's a far more risky that a user makes accidental changes to
>> the bundled library. Simple users should not need to touch it, and
>> should rather copy or make a new part.
>
> so if a user wants to add a missing parts to his/her library he/her needs
> to save it to a different location, close the i.e. fp editor, copy with
> administrative privileges the fp to the Admin folder and restart the sw to
> use it? I don't think other sw are using this procedure...

No, the workflow would be as follows:

1. User opens a bundled library from /usr/share

  * editor shows "read only"
  * so user knows he can't edit this library directly


2. User uses "Save as.." to save a modifiable copy either in the project
folder or in his ~/.kicad/library folder (or on the company file server if
configured in the path).

  * Editor can now edit and save the file because it's not read-only anymore
  * KiCad will use the search path to let the newly saved library override
the bundled one.


So no admin-privileges or restarts required. It's a pretty normal
workflow.. no KiCAD dialogs or assistants are required. It's like unix
config files -- don't like the defaults of /etc/bashrc? just copy it to
~/.bashrc and edit away!

-- 
Thomas Kindler

___
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] Default library install location

[Thomas Kindler]

On Wed, November 8, 2017 23:17, easyw wrote:
>> This is even worse.. that way co-workers could (even accidentally)
>> change the library without any notice.
>
> different point of view in working strategies... IMO something that I can
> change with i.e. the component editor and not save unless copied to a
> different location is a wrong way of working... but as I said there are
> many working habits...
>

Agreed.

The standard way would be that the editor displays a "[read-only]" tag in
the title bar, and grays out all editing commands.

That way the user wouldn't be surprised on save.

I think it's a far more risky that a user makes accidental changes to the
bundled library. Simple users should not need to touch it, and should
rather copy or make a new part. Otherwise there will be confusing bug
reports and users that downloaded an official release some time ago, but
now have a slightly broken (perhaps auto-updated) library.

On the other hand -- if a users /wants/ to make changes, he needs a proper
GIT clone anyways.


>
> On 11/8/2017 10:54 PM, Thomas Kindler wrote:
>
>> On Wed, November 8, 2017 22:18, easyw wrote:
>>
>>> the two a) and b) points are a big issue I think and this
>>> configuration is normally not present in other installer programs on
>>> windows...
>>>
>>> In windows a common User Folder is called common doc folder;
>>> the var pointing to C:\Users\Public is %PUBLIC% in recent Windows
>>> https://installmate.com/support/im9/kb/kb50038.htm#commondoc
>>> Then placing the libraries models/modules in i.e.
>>> C:\Users\Public\kicad
>>> folder, will let All Users have access read/write to these folders
>>>
>>> [..]
>>>
>>
>> This is even worse.. that way co-workers could (even accidentally)
>> change the library without any notice.
>>
>>
>> I think there are two use cases:
>>
>>
>> 1) Simple users of KiCAD
>>
>>
>> For this use case, the library should be installed in a write-protected
>>  location where only install admins can change them (like it is now).
>>
>> As a simple user I would expect stable KiCAD releases to come with an
>> official sanctioned library for that release. Eagle and most other CAD
>> packages do the same bundling.
>>
>> Auto-updaters that just update the library will confuse simple users,
>> and may cause compatibility problems if the library requires new
>> features.
>>
>> The same goes for automagic copy-on-write features - It's better to
>> just document how a library can be copied locally and how to override
>> the official one.
>>
>>
>> 2) Advanced users that want to contribute to the library
>>
>>
>> Advanced users should just clone the library using GIT. That way it's
>> possible to update and send pull requests using a normal, non-magic
>> workflow.
>>
>> An option to skip bundled library installation would be nice, but is
>> optional.
>>
>>
>> Library overrides could be done using a prioritized search path:
>>
>>
>> 1. $PROJECT/library# very useful for project-specific
>> things 2. ~/.KiCAD/library# useful for contributor work
>> 3. /usr/share/KiCAD/library# default for simple users
>>
>>
>> Of course, users could insert their own location like a company file
>> server..
>>
>> best regards,
>>
>
> ___
> 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] Default library install location

[Thomas Kindler]

I just sent a duplicate list-mail using the wrong sender address.. sorry
for the noise!


On Wed, November 8, 2017 22:18, easyw wrote:
> the two a) and b) points are a big issue I think and this configuration is
> normally not present in other installer programs on windows...
>
> In windows a common User Folder is called common doc folder;
> the var pointing to C:\Users\Public is %PUBLIC% in recent Windows
> https://installmate.com/support/im9/kb/kb50038.htm#commondoc
> Then placing the libraries models/modules in i.e. C:\Users\Public\kicad
> folder, will let All Users have access read/write to these folders
>
> [..]

This is even worse.. that way co-workers could (even accidentally) change
the library without any notice.


I think there are two use cases:

1) Simple users of KiCAD

  For this use case, the library should be installed in a write-protected
location where only install admins can change them (like it is now).

As a simple user I would expect stable KiCAD releases to come with an
official sanctioned library for that release. Eagle and most other CAD
packages do the same bundling.

Auto-updaters that just update the library will confuse simple users, and
may cause compatibility problems if the library requires new features.

The same goes for automagic copy-on-write features - It's better to just
document how a library can be copied locally and how to override the
official one.


2) Advanced users that want to contribute to the library

  Advanced users should just clone the library using GIT. That way it's
possible to update and send pull requests using a normal, non-magic
workflow.

An option to skip bundled library installation would be nice, but is
optional.


Library overrides could be done using a prioritized search path:

  1. $PROJECT/library# very useful for project-specific things
  2. ~/.KiCAD/library# useful for contributor work
  3. /usr/share/KiCAD/library# default for simple users

Of course, users could insert their own location like a company file server..

best regards,
-- 
Thomas Kindler <mail_ubu...@t-kindler.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

Re: [Kicad-developers] [PATCH] Right click option to change layer and render color

[Thomas Kindler]

On Thu, September 21, 2017 17:25, Seppe Stas wrote:
> This patch makes it possible to change the color of layers and render
> options using the right click menu. [..]

I think having a checkbox for "High Contrast Mode" (Hotkey H) would be a
nice addition to this menu!

best regards,
Thomas

___
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] New color selector for GAL canvas, and more easy support of opacity.

[Thomas Kindler]

On Mon, July 17, 2017 19:20, jp charras wrote:
> Attached a patch which adds a new (and I hope better) color selector for
> GAL canvas, with support of opacity.

I think I found a small bug - when the opacity is changed using the "{" /
"}" hotkeys, the value in the dialog isn't updated.

best regards,
Thomas

___
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] GitHub Plugin (my nemesis)

[Thomas Kindler]

On 02.10.2017 07:00, David Godfrey wrote:
> [..]

> Don't Forget that not all of the world's internet connections are FAST.
> While it might seem a good idea from the librarians perspective to have
> everything in a single repo, IT ISN'T a good idea at all if you happen to be 
> on
> a slow internet connection.
> 
> When I say slow, I'm talking common ADSL speeds here in Australia for example.
> They are often 8mbit/s or less.
> 

8 MBit/s is not too shabby. You could download 3.6 gigabytes in one hour.

> [..]

> If the entire lib ended up being ~ 3G (a figure mentioned in other posts) that
> would Take an Unacceptably long time to download.

If you are refering to my post from 2017-09-23:

* The worst-case download size would be 650 MB for everything (history, 3D
models, etc).

* 3.8 Gigabyte is the on-disk size after decompression

As said, 90% of that size comes from generated 3D models. It might make sense to
keep them in a separate repo for people with slow computers or internet 
connections.


Here are the .git directory (i.e. download with full history) sizes:

  kicad-library (with 3D models) :  650 MB

  kicad-library (without 3D models)  : < 22 MB  (estimated)
  kicad-footprints (with all 88 submodules)  :   51 MB
  kicad-packages3D-source:   16 MB


> For this reason I would STRONGLY advise libraries remain broken up into
> manageable sized repositories

The current situation is madness. The footprints are broken into tiny,
unmanageable chunks for no apparent reason at all.

The only chunk to separate out that makes sense is the 3D models.

Even with the best scripts and tools, git submodules are a pain to work with and
a *BIG* turn-down for contributors.

> Also, keep in mind that a repository never gets smaller, it only grows as
> changes are made.
> 

Yes, but it will grow *very* slowly. Footprints and Library symbols are text
files that compress and diff great.

The generated 3D models might be another story.

> [..]

best regards,
-- 
Thomas Kindler

___
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] GitHub Plugin (my nemesis)

[Thomas Kindler]

On Sat, September 23, 2017 21:01, Simon Küppers wrote:
> [..]
>
> Maybe it would be a good way to implement two git repos, one for
> footprints and one for 3D models (and a third one for schematic symbols..).
> That is 3 repos to maintain instead of more than some dozens
> as it is right now. Then I would agree with you, I would personally be ok
> with downloading either all footprints or none and not be able to select
> the libraries to download.

I would prefer an all-or-nothing approach to symbols and footprints. They
take up very little space, and if all users have the same basic set of
libraries, it's great for support.

> And then the user can choose if 3D models
> should be pulled additionally.

Agreed. People with older computers may choose not to use them.

The default should be to clone everything though.


> However that is my opinion only. (What actually about stream compression
> for KiCad Libraries? Of course this would be a big change but could reduce
> just the disk and download size in general)
>

Download size will stay the same as git already uses compression.

.sweet and .pretty should stay uncompressed for easier diffing. But the
generated .step and .wrl files could be compressed (possibly not even
worth it, as it may make git compression worse).

> However, once the repos are pulled they need to be "tracked" somehow.
> Because I strongly disagree with everyone saying "Just do it as you do
> in software development, use the command line periodically to check for
> KiCad footprint repo changes". Just No.

As a user, I would expect the same behaviour as with commercial PCB tools:
Libraries are updated along with new software releases. That way the
libraries are guaranteed to work and are checked for compatibility.

For KiCAD, the 4.0.7 installer should check out the 4.0.7 branch initially.

For library-developers there could be a 4.0-next branch.

Nigthly versions could track master by default.


> A simple first idea I was having in mind for a long time is just a check
> on KiCad startup (by default, can be changed) what the status of the git
> remote is and _notify_ the user if something has changed and if they want
> to pull in the changes _to disk_.

KiCAD could check if the library branch matches the software version. If I
install KiCAD 4.1.0 (or so), it should offer to pull the updates and
checkout the new branch.

Extra care must be taken if the user made local modifications - we don't
want a merge or rebase here.


> Not altering any of the designs of course! This could be improved later
> to provide a more sophisticated GIT integration in KiCad (I get the warm
> fuzzy feeling when I write this :-))

A side-by-side graphical diff viewer would be nice!

-- 
Thomas Kindler

___
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] GitHub Plugin (my nemesis)

[Thomas Kindler]

Hi all!

After reading all the other messages, here are my two cents:

The KiCAD installer should just offer to do a full git clone of kicad-footprints
and kicad-libray (which will be split into 3D, templates, etc. for the 5.0
release as I understand).

A full clone takes 3.8 GB. A shallow clone takes 3.6 GB. The .git-direcotry size
is 650 MB vs 486 MB.

So it's not worth the hassle IMHO as shallow clones don't allow to generate
pull-requests without unshallowing them first.

BTW: 2 GB of that checkout is spent on the packages3d subdirectory. We could
just support loading of .wrl.gz/.step.gz to save space.

In 2017, a few gig of harddisk space, and a < 1 gig download should be OK for
everyone. All the other PCB tools, FPGA toolchains, Netflix, etc. are far 
bigger.

The other suggestions were quite surprising to me -- Github API, downloading
individual subdirectories as .zip, abusing subversion (gasp), gitslave (last
updated 2012), etc. would be a big hurdle and WTF for new KiCAD users.

So why not use git as it was supposed to be used?

best regards,
thomas


On 22.09.2017 03:21, Oliver Walters wrote:
> Hi all,
> 
> Ok, now that the website integration with the libraries is (pretty much) done,
> and the licensing issue seems to be sorted, there is one final puzzle piece to
> solve before I'm happy with the state of the libraries for a v5 release.
> 
> *Goal: *Merge all footprint library repositories into a single repo to solve 
> the
> ongoing dramas of maintaining 100+ repos.
> 
> *Problem*: The *only* thing standing in the way of just doing this is that 
> some
> users like the GitHub plugin and previous instruction is that this 
> functionality
> cannot be removed.
> 
> The GitHub plugin functions by downloading a .zip file of a .pretty repo. If 
> we
> merge all footprint libs into a single repo with multiple subdirectories, this
> will not work anymore (as GitHub dosen't allow you to download a .zip of a
> single subdirectory).
> 
> Merging the repos is the *right thing to do*. But how to proceed?
> 
> *Options:*
> *
> *
> /a) Drop github plugin feature, replace with library-download tool/
> 
> I don't think it is a good idea to live-load library data from GitHub (a lot 
> of
> other users agree too). It's slow, and a waste of bandwidth to re-download the
> libs all the time. 
> 
> We drop support for loading libraries direct from GitHub. However, we add a 
> tool
> for downloading libraries from GitHub and storing to disk. Users can update as
> they like. This can be integrated in KiCad and new users can run this tool 
> when
> they first install KICad. This means that no libs need to distributed with the
> installer and users can update to latest libs whenever they want.
> 
> /b) Improve github plugin to allow subdirectory traversal/
> 
> This is difficult and will only result in the plugin being slower. There are 
> two
> ways I can see to do this:
> 
> i. Use Git API - tools exist that use this functionality
> - https://github.com/KinoLien/gitzip
> ii. Use subversion - GitHub actually provides subversion API
> - https://www.seanw.org/blog/download-git-repo-subdirectory/
> 
> 
> *Subversion*
> 
> In either case, I think that using the subversion tool to partially download 
> the
> libraries would be a good approach (I assume quicker than using wget and the
> GitHub API).
> 
> 1. Does anyone have any experience using the C API for SVN? 
> 2. The Python bindings are pretty good - https://pypi.python.org/pypi/svn - 
> and
> much easier to use. However, can we make the library download tools dependent 
> on
> enabling the python plugin?
> 3. Is there a way to checkout a subversion remote to memory (to replicate the
> functionality of the current GitHub plugin)? If not, I'm not sure how to
> approach option b) above.
> 
> 
> Feedback appreciated. I think that it is very important especially for new 
> users
> that this is improved. The GitHub plugin is constantly causing headaches!
> 
> Cheers,
> Oliver
> 
> 
> ___
> 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] kicad right click menu corrections and few icons corrections

[Thomas Kindler]

Hi José!

On 02.06.2017 17:05, José Ignacio wrote:
> The use of "..." for menu items that show a dialog with extra options
> necessary to perform the operation has been in Microsoft's UX guidelines and
> apple's HIG since time immemorial:
> 
> https://msdn.microsoft.com/en-us/library/dn742392.aspx#usingellipses
> 
> https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/TerminologyWording.html#//apple_ref/doc/uid/2957-CH15-SW3
>
>  https://developer.gnome.org/hig/stable/writing-style.html.en#ellipses
> 
> It is a very well known and traditional convention and Kicad shouldn't break
> it. As the guidelines say, the ellipsis (...) is reserved for commands that
> need further input from the user to proceed,

Ok! Totally agree until here..

> showing a modal dialog shouldn't be enough to warrant adding the ellipsis
> (though I've seen several programs be ellipsis-happy and put it on everything
> that calls a dialog...)
>

.. but now I can't follow you.

What could be a more severe indicator of "needing further input" than showing a
/modal/ dialog box?

This is exactly what ellipses are about. They say "Click me, and I will force
you into modal interaction".

Modal interactions should be kept to a minimum.. most of the dialogs that KiCad
shows could be replaced by dockable object inspector windows (Which I think is
already on the roadmap for Version 6). Until then, ellipses should be used.

best regards,
Thomas

> On Fri, Jun 2, 2017 at 8:20 AM, Fabrizio Tappero  > wrote:
> 
> Hi JP,
> 
> thanks a lot!!
> 
> I am a little unsure about this "Save as..." three dots thing used every time
> the menu item takes you to a second window. but I will investigate about UI
> stuff a little.
> 
> cheers Fabrizio
> 
> 
> 
> 
> On Fri, Jun 2, 2017 at 12:44 PM, jp charras  > wrote:
> 
> Le 30/05/2017 à 14:54, Fabrizio Tappero a écrit :
>> Hello Wayne, In attachment you can find a good review of approx 30 icons
>> and a global simplification of approx 30 icons. I have also corrected some
>> menu labels.
>> 
>> Since there is a lot of corrected text that is very much related to 
>> English, it would be great if you could review it before submitting it. A 
>> not so fun work but I think it will make kicad a much better tool.
>> 
>> I think it would be recommendable to avoid "a" and "the" in button and
>> menu tooltips. So that it way easier to understand what the button or
>> tooltip is about. The use of singular plural is also inconsistent and I
>> tried to fix it. Please Wayne feel free to make any changes you think is
>> important.
>> 
>> I have also notices that several menus are a little inconstant. I will try 
>> work on it since I think the current kicad UI is very usable but it needs 
>> to be more consistent.
>> 
>> I have tried to fixed a lot of icons so that their meaning is more 
>> immediate to understand. I have as well started a process of
>> simplification of many redundant icons. I think it is important that we
>> begin simplifing the kicad icon set because at the moment is really too
>> large.
>> 
>> Here below a detailed description of the changes.
>> 
>> Cheers Fabrizio
> 
> 
> Hi Fabrizio,
> 
> I committed your icons. 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 
> 
> 
> 
> 
> ___ 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] 3D Mouse (Spacenavigator) support

[Thomas Kindler]

On 15.05.2017 19:10, mrkenhoff wrote:
> I would like to add support for the SpaceNavigator 3D mouse if nobody objects.
> [...]

Nice!

I think it would be best in the 3D Viewer. Altium already has this, and it's
lots of fun to fly through a PCB.

Perhaps you can take the implementation, behaviour, and settings dialog layout
from FreeCAD, so users can switch between the two applications seamlessly:

  https://www.freecadweb.org/wiki/3Dconnexion_input_devices

best regards,
thomas


___
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] [FEATURE] Component table viewer

[Thomas Kindler]

Hi Oliver!

I also tried the new component table viewer, and think that it looks very
promising! I'm switching over from Altium which makes extensive use of List and
Property dock panels, so I would like to provide some feedback:


* There should be a warning if there are uncommitted changes. Right now, it's
very easy to loose work by accidentially hitting ESC.

* The text columns should be left-aligned for readability. Numerical columns
(Quantity..) should be right-aligned (easier to compare numbers).

* The side bar takes up a lot of space on small displays. The field selection
could be replaced by a context menu, like in Windows Explorer or Nautilus.

  * This would also be a good place for "Group by this column", "Size column to
fit", and "Size all columns to fit" menu entries.

* It would be nice to be able to edit the Reference column.

* Field selection and column sizes should be saved and restored when reopening
the dialog, possibly across program restarts.

* Column reordering by dragging the column title (I don't know, if wx provides
that feature).



Also, I think making the dialog non-modal would be useful:

* No need for a custom "Apply/Cancel/Revert all Changes" workflow.
All edits could be done on the fly, and use the normal undo/redo functionality.

* Row Selection could be synchronized with sheet object selection (and vice 
versa).

* There could be a "Zoom to selected object" context menu entry.

* In Altium, the schematic list view can show all types of objects (Nets, Pins,
etc.), and also work in the library abd PCB editor. It's often possible to e.g.
select all 144 pins of a microcontroller, and set the signal names by copy and
paste from a spreadsheet.


Woohoo, a lot of points ;) I'm new on the mailing list -- is this the right way
to give feedback? I'm always afraid of sounding rude or demanding, especially
because english is not my native language.

best regards,
Thomas

On 05.05.2017 14:56, Oliver Walters wrote:
> Steven,
> 
> Unless you mean something different to what I think "custom fields" means, 
> then
> this is already the case - any extra fields (beyond REFERENCE / FOOTPRINT /
> DATSHEET / VALUE) are preesnt to be edited in the table...
> 
> On Fri, May 5, 2017 at 10:51 PM, Strontium  > wrote:
> 
> Hi Oliver,
> 
> Just had a chance to check out your component table viewer, its nice.  
> Great
> work.
> 
> Is it on your roadmap to be able to view/edit a components custom fields?
> 
> Regards,
> Steven
> 
> On 03/05/17 05:35, Oliver Walters wrote:
> 
> Wayne,
> 
> Thanks for merging!
> 
> I will address those points at some stage - there are other ideas I 
> have
> too but I thought it was better to get the first iteration done and 
> make
> incremental improvements.
> 
> Regards,
> Oliver
> 
> 
> 
> ___
> 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