Search options (Page 24 of 31)

Hello paulomt9b,

a possible explanation:
Not all texts in QET may be translated to your language, so QET falls back to the "Standard"-language in that place.

At that point you can help to improve QET:
Translate the "missing" texts to your language.
We would be happy if we could take over your texts! 

PS:
If you don't know if your question was asked before in this forum: Use Forum-Search.
In this case "language" would be the "magic word"!

Salut Jerome,

Bitte beachte:
der Element-Editor führt manchmal "ein Eigenleben" - auch in der aktuellen Version.

Manchmal kommt es vor, dass beim Speichern die Position des zuletzt bearbeiteten Teils verschoben wird oder die Z-Positionen durcheinandergewürfelt werden.

Deswegen habe ich es mir angewöhnt, nach dem Speichern des Bauteils im Element-Editor, das Teil noch einmal neu in den Element-Editor zu laden, um zu sehen, ob beim Speichern alles gut gegangen ist.

-----

Please note:
The element editor sometimes has a "life of its own" - even in the current version.

Sometimes, when saving, the position of the last edited part is moved or the Z positions are jumbled up.

That's why I've got into the habit of reloading the part into the element editor after saving it in the element editor to see if everything went well when saving.

-----

Veuillez noter que :
l'éditeur d'éléments a parfois une "vie propre" - même dans la version actuelle.

Il arrive parfois que lors de l'enregistrement, la position de la dernière pièce traitée soit déplacée ou que les positions Z soient mélangées.

C'est pourquoi j'ai pris l'habitude, après avoir enregistré la pièce dans l'éditeur d'éléments, de charger à nouveau la pièce dans l'éditeur d'éléments pour voir si tout s'est bien passé lors de l'enregistrement.

Hello rvamerongen,

your SVG cannot be converted to DXF because most of it is an integrated Bitmap!

There is only one rect as outline of the Battery and the six smaller white rects is one big path.
You can even see that when you open SVG in a Text-Editor (see attachment).

If you open your SVG in Inkscape and look at the "Ebenen und Objekte"-Tab (opened with via Menu) you'll see what's inside your SVG: Most of it is a Bitmap that cannot be converted by any DXF-converter.

You can even see that when you open SVG in a Text-Editor (see attachment).

Such "simple" Symbols can be drawn very quick and easy with QET's Element-Editor:
Only rects that can be duplicated by <Ctrl>-C <Ctrl>-V

Salut Laurent!

I don't get this error on my Debian Unstable.
Maybe there's something missing in helpers.cpp?

Try to add
"#include <string>" or
"#include <sstream>"
at line 30 in helpers.cpp

Line-Endings for SVG-Output are implemented now! 
Additionally: Line-widths and the dotted and dashed lines were slightly "adjusted".

On https://github.com/plc-user/QET_ElementScaler you find a new pre-release.

In the attachment you see an example: SVG on the left; QET-Element-Editor on the right.
The blue rects in the background show the positions of x-values of the lines and the distances "length1" and "length2" of the Line-Endings.
For me the lines left/right look very similar!

We get closer to a first "non-beta" release.
The next great step will be texts with line-breaks. More on this: later.

Best regards
  plc-user

Hello Erik, (and all others!)

on https://github.com/plc-user/QET_ElementScaler you'll find a new version of QET_ElementScaler in which the handling of line-width and line-style for SVG-output is re-worked.

Here you see an example in the picture (top: SVG, bottom: Element-Editor) and in Element- and SVG-file.
Additionally your example with the re-worked styles is also attached.

I guess I found a quite usable solution...

Please test the new version with your "favorite" elements!
Thanks in advance! 

Best regards
  plc-user

I still can't see what exactly goes wrong!

The DXF-to-Element-converter has nothing to do with the Python terminal plug-in or the TerminalBlock-Generator. These are different applications.

If you have an element-file from DXF-converter that you can edit with QET-Element-Editor, the converter works!

The qet_tb_generator is not necessary to use when converting a dxf to elmt.

Please use the forum-search to find hints on where to download the DXF-converter and how to use it.
Maybe you'll find out that this would be the better place to ask about importing dxf to elmt:
https://qelectrotech.org/forum/viewforum.php?id=12

Hello brutaldeth,

if I understand you correctly, you are looking for a battery charge monitor.

Here is the QElectroTech forum, which is all about drawing electrical schematics...

Best regards
  plc-user

Hello Erik,

Thanks for your hints, but I already use the principle of how it should work with the line ends for the terminals.

If you look at the screenshot, you might realise why I'm still hesitating to implement anything: I want it to look at least similar to QET!

The lines in the image all have the same X values for start and end. The actual lines as you see them have different lengths depending on which line-ending is chosen.

Of course, I could also make the lines in the SVG the same length and place the ends over them. But then you can see the line shining through at ends without filling! In the screenshot you see a yellow rectangle behind the lines.

The complexity doesn't get any less if we think of four possible line widths, for which the "real" line length must then of course be adapted to the line width, the line-endings and the values for length...

Hello everybody!

I decided to cancel the project "QET_Element2SVG"! 

Instead I added SVG-Output-Support to QET_ElementScaler!

In this context the order of commandline-parameters for QET_ElementScaler had to be adjusted!
So please:
Read the Readme and the scripts and batches provided on the github-page:
https://github.com/plc-user/QET_ElementScaler

In the Release-Section there are binaries for Debian GNU Linux (unstable), ReactOS (32bit) and Win10 (64bit) available, but you should be able to compile the sources on other platforms.

The software is re-written in great parts and may contain errors!

So:
Test the software and report errors, inconsistencies, or simply praise!

Best regards
  plc-user

Hello everyone!

For open or closed polygon / polyline I found a solution!

Let's get back to "dynamic_text": Can someone please confirm or explain this:

I have created a test element with three "dynamic_text" and set the horizontal alignment to left, centre or right. I notice that the texts still remain in almost the same X position.

When I apply the attribute left, centre or right to SVG-text, exactly what I expect to happen happens: the reference point of the text is at the specified X position.

That is what I would expect in QET, too...

EDIT:
There is no change in Text-Positions, even when I change Vertical Alignment to Center or Bottom.

Salut Joshua!

Thank you for your hints, links and explanations!

I love the sentence: "For historical reasons..." 
It always explains, why there are so many ugly workarounds.

But be sure: Most of the software I wrote in the past would NOT look the same if I wrote it now again!

In the moment I think I could make a great step ahead, if I knew how to calculate the bottom-left-corner of the dynamic_text in it's boundingRect.
As you can see in the attached elmt-file I put a dynamic_text at Position x=0, y=5. The boundingRect is positioned exactly there (blue rect). But the text is placed in another position the green rect.

Maybe I find an explanation in QT-documentation from the link how to calculate the "missing values". I have to read.
After that it should be possible to move and rotate the text in SVG to the right position using trigonometry...

Of course you can re-use my code for QET in further versions: That's why we support OpenSourceSoftware!
For now the sources are in a state I would like not to publish. I'll do it later on my GitHub-Account ... promised!

Best regards
  plc-user