move and stretch shows a little problem with labels

[olisnr]

i want to be able to move parts without changing the connections. but in the moment it dont work for net-labels

my xschemrc have now:

set replace_key(Control-z) u        ;# undo
set replace_key(Control-y) Shift-U  ;# redo
set replace_key(z) Control-z        ;# zoom out
set unzoom_nodrift 1
set draw_crosshair 1
set persistent_command 1 #for click instead of w

set enable_stretch 1 #for preserve the connections
set connect_by_kissing 1 #for preserve the connections
set unselect_partial_sel_wires 1 #for preserve the connections

select v2 move v2 place v2

the label isnt connected anymore.

i think, that may be there should be only two options: moving parts and wire fragments and destroy the connections or moving parts and stretching wires, without destroying any connection.

it could be two different commands "move" and "drag" like in LTspice. then the options "enable stretch", "unsel parital sel..." and "auto join..." wouldent be needed anymore, because they would be set to "move and break" or "drag and preserve".

what do You think?

[StefanSchippers]

There is a nice command Tools-> Break wires at selected instance pins (! keybind). You select some components / labels (or even everything, ctrl-a) and press !.

This will allow following (stretch) move of the component to preserve label connections. see image.

I think more elaborate things can be done, but these will be deferred after 3.4.4 release.

[StefanSchippers]

Another interesting command is 'Shift-M'. This will not stretch wires, it will add new wires at the terminals when movimg a component.

[olisnr]

yes shift-m is also useful.

and all this changes are very useful for me. but some things are still strange. i think, if every pin would automatic brake the wires, the experience would be much more constant. some optionbrake_wire_on_pin like the connect_by_kissing could save the connections.

now You can have this:

draw a wire

add two parts

move one

move the other

be amazed

[olisnr]

its also possible to use cntr-a and ! every time before selecting and dragging, but...

anyway, i dont want to disturb the release of 3.4.4 and if can use help whit something may be testing...

[StefanSchippers]

Please tell me the exact setup and commands, i can't get this strange result shown above :-) (use last xschem commit)

[olisnr]

i used #define FIX_BROKEN_TILED_FILL 1 & enabled option-menue-entries: undue.... enable... unsel... autojoin... persistent...

but i think the question is if the wire ends on a pin or not. in my example the ADC-block in the north connects to a wire goes higher then the highest pin, while in the south the last pin and the endpoint of the wire are at the same point

[StefanSchippers]

I have tried again and can't see the problem.I remember there was a similar issue some days ago but it was fixed. Ensure you update your xschem workspace and rebuild the latest commit.

https://github.com/StefanSchippers/xschem/assets/69359491/8b8b833f-79e6-456a-87af-f59b7c4036b3

[olisnr]

yes , i did use the latest version (before the new GPU-fix in the menue). BUT i did use the m command, because i enabled the "enable stretch" from the option menue. and this should exchange the m and the cntr-m command. may be that is somehow broken now. i remember it was working in an older version.

[olisnr]

if i remove the "enable stretch" it also stretches the wires with the m command.

[StefanSchippers]

Sorry I can not reproduce any of these things. Without enable stretch 'm' moves the part only, if only the part is selected.

[StefanSchippers]

may be the german keyboard add some problems here.

[olisnr]

You are right. i tried the version form yesterday night without cross-hair and without the precompiler driver fix, and this didnt change anything. then i changed my keyboard from german (swiss) to english (US) and the cntr-key istnt working anymore in xschem also the zooming via the scroll-weel of the mouse.

what keyboard setting do You use?

and why did it work before? has something changed whit the key-binding code?

i will test more at the newest version (the one with the fix in the menue) later

[StefanSchippers]

I have US keyboard

[olisnr]

i can choose from 4 different us layouts :)

[olisnr]

now i downloaded the newest version, and its really strange: if i use english (us) not only the zoom scroll from the mouse dont work anymore, also the c q and m command does not work. aaaaand the right click context-menue is also missing.

may be its a problem in combination whit cinnamon... i try to test mate also. i could also try different keyboard layouts. what should i test? and what does the "debug mode"? writing some intersting log-file?

[olisnr]

the 'esc' and 'del' commands are working in the US layout

[StefanSchippers]

The only way i can mess up things that badly is if Caps-Lock is set

[olisnr]

no, You mad it very clear, if its set :)

[StefanSchippers]

if you are using an external keyboard on a laptop sometimes the external keyboard and the internal are not in sync, it happened sometimes., very rarely, i have to disconnect the usb and reset the external keyboard

[olisnr]

i will try, but a strange thing is, the external trackball also change the functionality if i change the keyboard layout

[olisnr]

i dont have an external keybord, but i can search one to test it. but that wasent what You asked for

[StefanSchippers]

Otherwise the desktop environment is messing up things in the worst possible way. I don't use desktop environments at all. All i do to change the keyboard layout is setxkbmap -layout us, setxkbmap -layout de.

[StefanSchippers]

Going gack to the original problem of garbage on the screen, can you please update xschem to latest and test again without the "fix_broken_tiled_fill"? I found a regression introduced many commits ago. Fixed now.

[olisnr]

Yes the GPU-driver-fix works great! what does the "no xcopy area ..." do?

the keyboard-layout problem has something to do whit the destktop-manager i think because, if i change the keyboard from the terminal it does whats expected: setxkbmap -layout us setxkbmap -layout de setxkbmap -layout ch all do the same (only .us exchanges Z with Y), but the rest stays working if i use the swiss-german keyboard from the keyboard dialog, or dont work if i use the english (us) layout.

do You have an idea how to debbug this? is there an event log i can enable?

[olisnr]

if i see this right, xschem gets the current pressed key in from the function callback, that gets ist from a TCL code. but who is the source file?, and where get he the key-code from?

[olisnr]

ok i found out :) the dbg enable writes to the stdout...

[olisnr]

do You have an idea why i cant redirect the log output into a file? it tryed

xschem > log
key=0 EQUAL_MODMASK=0, SET_MODMASK=0
callback(): Event:-55
key=0 EQUAL_MODMASK=0, SET_MODMASK=0
key=0 EQUAL_MODMASK=0, SET_MODMASK=0
draw_crosshair()
draw_selection

xschem did made a file named "log" but didnt use it for the output

[olisnr]

i wanted to write the file ./log and use tail and grep to filter the keys and other lines what im interested in. how do You do this?

[StefanSchippers]

For debug in a log file:

xschem -d 1 -l logfile

[StefanSchippers]

callback() gets events from tcl. Events are set in tcl with the bind instruction. See set_binding tcl procedure in src/xschem.tcl

[StefanSchippers]

For debugging events start wish (the tk interpreter), write this one line:

bind . <KeyPress> {puts "%K %s"}

and then do keypresses in the wish toplevel window. You get the key and the state (shift, alt, ...) for details: man 3tk bind

[olisnr]

an interesting thing is: the mouse events are dependent from the GUi-keybord-layout setting:

english us. zoom in zoom out:

callback(): Event:-55
callback(): ButtonPress  ui_state=0 state=8192
callback(): ButtonRelease  ui_state=0 state=10240
callback(): ButtonPress  ui_state=0 state=8192
callback(): ButtonRelease  ui_state=0 state=12288

german swiss. zoom in zoom out:

callback(): Event:-55
callback(): ButtonPress  ui_state=0 state=0
callback(): ButtonRelease  ui_state=0 state=2048
callback(): ButtonPress  ui_state=0 state=0
callback(): ButtonRelease  ui_state=0 state=4096

strange...

[StefanSchippers]

The X11 defines higher mask bits for mouse buttons. If you press a key with button1 (left) pressed you get state=256 mouse button2 gets 512 mouse button 3, (right gets 1024 mouse buttons 4 and 5 (scroll wheel) get 2048 and 4096

higher bits are not defined

in /usr/include/X11/X.h:

#define Button1Mask             (1<<8)
#define Button2Mask             (1<<9)
#define Button3Mask             (1<<10)
#define Button4Mask             (1<<11)
#define Button5Mask             (1<<12)

[StefanSchippers]

I can do an interesting thing: at the beginning of callback() function filter out all bits that are above bit 13 in the state variable...

[olisnr]

yes this could save us...

[olisnr]

state = state & 0x1fff;

seems to work in the beginning of the callback

[StefanSchippers]

Yes it is committed now

[olisnr]

but this donsnt fix the normal mode for me. m and cntr-m are dragging dont care the state of "enable stretch"

how do You this screen-video? i would like to show it

[StefanSchippers]

It seems state bits above 12 are used for the X Keyboard extension. See the protocol speciication here. I think it is used to handle multiple layout of a keyboard at the same time, for example, configuring different keyboard layouts on a per application level , instead at global system level.

[StefanSchippers]

Can you please test this: in xinit.c after including xschem.h add this line:

include <X11/XKBlib.h>

#include "xschem.h"
#ifdef __unix__
#include <pwd.h> /* getpwuid */
#endif
#include <X11/XKBlib.h>
...
...

Then after X INITIALIZATION add: XkbIgnoreExtension(True);

/*                      */
 /*  X INITIALIZATION    */
 /*                      */
 if( has_x ) {
    mainwindow=Tk_MainWindow(interp);
    if(!mainwindow) {
       fprintf(errfp, "Tcl_AppInit() err 6: Tk_MainWindow returned NULL...\n");
       return TCL_ERROR;
    }
    display = Tk_Display(mainwindow);
    XkbIgnoreExtension(True);
    ...
    ...

and see if the strange high order bits are still causing problems.

[olisnr]

it dont change anything. i think the state numbers are fixed with the bit-mask.

i made a video showing the behavior of my version of xschem:

https://github.com/StefanSchippers/xschem/assets/120017377/e780f3aa-96df-4057-ad8f-6c2b3cc6f662

[StefanSchippers]

This is all correct and as intended. When you move the right AO21 the net that lands on the bottom pin follows the instance while moving.

https://github.com/StefanSchippers/xschem/assets/69359491/4d08888f-b3f2-419d-9470-eb68086b2727

[olisnr]

i deleted my xschemrc file, and then its working as on Your video. then i found that the option: set connect_by_kissing 1 ;#for preserve the connections does change the non-strechting m command to a stretching one. or in other words, if i enable the kissing im not able anymore to move the parts non-stretching. i would think, the kissing should connect all toutching pins, but not change the standard moving command. what do You think about it?

[StefanSchippers]

Oh, thank you I will check. I think there are too many options, it is getting a bit messy :-)

[olisnr]

Yes. its really complex. basically, i would think, two would be enough: moving or dragging. moving breaks all connections and dragging non.

LTspice does this in a good way. altium is bad, virtuoso i dont know... what CAD is Your inspiration?