[FEATURE] Add additional Drag USECASES for parts in parts tree

[auphofBSF]

In testing #8 Drag and Drop functionality in Parts Tree seemed to be missing these usecases.

USE CASE: 1. Drag a part in the tree_parts onto an line that is a Category Path
Essentially changing a parts category

USE CASE: 2. Drag a category in the tree_parts onto a line That is a Category path
Essentially changing all items to a sub category of the selected Category path

This works on the Categories Tree

see kipartman/frames/parts_frame.py
#TODO: comments 5f3a8f4

[turdusmerula]

Yes it is not yet implemented but should not be that hard as shown in your TODO.
Do you plan to implement it?

I'm also thinking of enabling multi-select for complete drag and drop use case, but this will probably also affect the REST API.

[auphofBSF]

Good idea on the multi-select. I have no pressing requirement for either. So I can look at sorting it out but will be a bit later.

I am working on the integration with schematic component selection so need to look at getting Footprints easily and correctly populated and matching with kicad standard .pretty libraries. I will raise a [FEATURE] around footprints and put forward some suggestions.

What are your thoughts around the BOM tab, I require to be able to select parts into the schematic from the curated parts list maintained in kipartman.
To achieve this I see an integration with the working 'https://github.com/Jeff-Ciesielski/Boms-Away' with Kipartman being the primary part curating tool and the schematic BOM populating/selecting able to be done in 'Boms-away'. I think it should be able to be achieved easily and have usable functionality very soon, best functionality for least effort.

I also have the import and export pluging working, just need to do some final checks and publish, That drag and drop issue sucked up to much time.

[turdusmerula]

Good idea on the multi-select. I have no pressing requirement for either.
So I can look at sorting it out but will be a bit later.

I am working on the integration with schematic component selection so need
to look at getting Footprints easily and correctly populated and matching
with kicad standard .pretty libraries. I will raise a [FEATURE] around
footprints and put forward some suggestions.

I think this is same subject as issue #4, I was imagining creating the kicad parts and footpring libraries directly from the content of kipartman bu design is yet to be thought.

What are your thoughts around the BOM tab, I require to be able to select
parts into the schematic from the curated parts list maintained in
kipartman.
To achieve this I see an integration with the working '
https://github.com/Jeff-Ciesielski/Boms-Away' with Kipartman being the
primary part curating tool and the schematic BOM populating/selecting able
to be done in 'Boms-away'. I think it should be able to be achieved easily
and have usable functionality very soon, best functionality for least
effort.

For now kipartman allows the user to match the parts inside the schematic with parts stored in kipartman, here is the workflow I use :

• on the part view I create metaparts that have general characteristics.
  For exemple a 10k 0805 packaging resistor that will match the following real existing parts (with a one to one replacement on board):
  
• on the BOM view I associate this metapart with each part from my PCB
  
• I eventually chose the real part I'm going to use on the Buy view (depending on price or availability by example):
  

There is currently no strong link with PCB, you can match a kiparman part with a kicad part wrong footprint and it will not complain. And there is also no link with the schematic, as you noticed there is things to improve there.

Can you describe more precisely the workflow you see with boms-away?

[auphofBSF]

Thanks for the great explanation. I am amending some diagrams and drawings and will post tomorrow.

[turdusmerula]

I detected a problem with drag and drop on Linux with wxPython (4.0.0b2):
When I drop an item directly on another item the target item detected is the previous upper item. Can you tell me if this behavior is the same on Windows?
Didn't investigated yet to check if the regressions comes from kipartman or wxPython.

[auphofBSF]

This workaround for a wxWidgets issue under windows will be the problem

kipartman/kipartman/helper/tree.py

Line 432 in 59d41cb

mouse_x, mouse_y = self.tree_view.ScreenToClient((mouse_x, mouse_y-25))

.
We are certainly going to have platform dependencies. Have you any recommendation how best to handle this ?

Further links to wxWidget issue ::

kipartman/kipartman/helper/tree.py

Line 420 in 59d41cb

#TODO 17W47.5 WORKAROUND for defect 17561.

[turdusmerula]

It reminds me something I read sometimes ago. There was an open issue about header columns (I don't remember where, will try to find it back), when they are shown it seems that the origin of the viewport has a wrong shift of the header height. I found this https://stackoverflow.com/questions/1854/python-what-os-am-i-running-on, having platform dependent code is not always avoidable but it seems straightforward with python.