WIP: Lock text to element #363
Conversation
|
Hallo pkess! Ich schreibe einfach mal auf Deutsch, weil ich was von "Osnabrück" gesehen habe... Ich bin begeistert, dass es inzwischen ein paar Leute gibt, die sich aktiv an der Weiterentwicklung von QET beteiligen! Das mit dem versehentlichen Verschieben von Texten eines Elements passiert mir auch sehr regelmäßig! Dafür bräuchte es keinen zusätzlicher Parameter ... |
|
Hallo @plc-user! Ja, ich wohne etwas nördlich von Osnabrück. Ich finde das Projekt hat viel Potenzial und ich nutze es bereits aktiv immer wenn ich Schaltpläne erstellen muss. Leider fehlen noch ein paar elementare Funktionen um es wirklich in professioneller Umgebung einsetzen zu können. Ich hoffe ich schaffe es hier am Ball zu bleiben und die Entwicklung voran zu treiben, aber ich kann nichts versprechen. Auf die Idee mit dem shift bin ich noch nicht gekommen. Nachdem ich den PR hier gestellt habe habe ich überlegt ob es vielleicht passender wäre, wenn man einen globalen schalter hätte mit dem man entscheiden kann ob man die Texte schieben will, oder eventuell den "objektfang" so verstelllt, dass eben nur elemente und nicht die Texte verschoben werden. Ich bin mir auch noch nicht ganz schlüssig. Wie machen es andere? Der Schaltplaneditor eagle hatte zumindest als ich es damals genutzt hatte eine Funktion "smash" und "unsmash". Damit konnte man entscheiden ob die Texte verschiebbar sind oder fest am element hängen. Mit dem gleichen Problem, dass wenn es "smashed" ist schnell die Texte verschoben werden. Das unsmash hat hier aber die möglichkeit geboten die Texte wieder zurück auf ihre sollposition zu setzen. Das wäre hier auch unter umständen noch als Erweiterung bzw. unabhängig davon interessant. Wird es zu der anderen Lösung wohl einen PR geben? Ich kann mir durchaus vorstellen, dass am Ende beide Features interessant sind. Stören dich die Attribute in der gespeicherten Datei oder der zusätzliche RAM zur Laufzeit? Zumindest für die XML-Dateien könnte man das Attribut sonst eventuell auch optional machen, sodass es nur geschrieben wird, wenn die Funktion auch genutzt werden soll. Vorteil an dieser Lösung ist noch, dass die User experience erst mal nicht direkt gestört wird, weil die Bedienung erst mal gleich ist und erst wenn man das sperren will kann der Haken gesetzt werden. |
|
Hallo pkess! Je weniger Attribute in den Element-Dateien sind, desto weniger Platz brauchen die auch im RAM, klar! Das meine ich aber gar nicht. Mir geht es darum, daß ich meine ganzen Elemente nicht modifizieren will und wir das auch den anderen Nutzern nicht aufbürden sollten. Ich glaube, das unfreiwillige Verschieben von nicht gefüllten und daher (nahezu) unsichtbaren Feldern führt sogar zu merkwürdigem Verhalten, was auch gerade im QET-Forum wieder mal beschrieben wurde: Wir sprechen hier ja auch immer noch von der "dev"-Version von QET, bei der sich auch etwas für den Benutzer ändern darf. Wie ich finde: zum Besseren, wenn "nur" eine zusätzliche Taste bei der Maus-Bewegung gedrückt werden soll. Der o.g. Commit ist inzwischen in einem separaten Branch verpackt (war vorher Teil im riesigen Qt6-Branch) und kann meiner Meinung nach direkt angewendet werden. Ich habe das jedenfalls heute ausprobiert und bin zufrieden damit! |
I often ran into the situation that in needed to move elements that were overlapping with text or i wanted to change some text and accidentally moved the text instead of changing the content only.
With this PR i added an option to the text properties that will allow to lock the current text position to the element. The whole element will then be moved instead of the text if some drag and drop is applied.
This is not fully functional at the moment (e.g. the property in the element editor is not saved and used when imported to a schematic). But comments are appreciated.
Here is a screenshot of the schematic editor:
This is the view inside the symbol editor:
