stefan.123 wrote:

Is there a library part for a Series Terminal Block with different Size?

Please start a new thread in an appropriate forum, when changing topic...

When this is what you mean:
Use Terminal Block-Manager or Terminal-Block-Plugin.

This thread is a continuation of the topic that started here:
https://qelectrotech.org/forum/viewtopi … 844#p20844
----------------------------

Salut Laurent !

I created a patch to set the config- and data-directories to system-specific values.

diff --git a/sources/dxf/dxftoelmt.cpp b/sources/dxf/dxftoelmt.cpp
index f2dd572d8..85ea2534f 100644
--- a/sources/dxf/dxftoelmt.cpp
+++ b/sources/dxf/dxftoelmt.cpp
@@ -21,7 +21,7 @@
 #include <QFile>
 #include <QProcess>
 #include <QMessageBox>
-#include <QDir>
+#include <QStandardPaths>
 
 /**
  * @brief dxftoElmt
@@ -71,13 +71,7 @@ QByteArray dxfToElmt(const QString &file_path)
 
 QString dxf2ElmtDirPath()
 {
-#if defined(Q_OS_WIN32) || defined(Q_OS_WIN64)
-    return (QDir::homePath() + QStringLiteral("/Application Data/qet/binary"));
-#elif defined(Q_OS_MACOS)
-    return (QDir::homePath() + QStringLiteral("/.qet/binary"));
-#else
-    return (QDir::homePath() + QStringLiteral("/.qet/binary"));
-#endif
+    return QStandardPaths::writableLocation(QStandardPaths::AppDataLocation) + "/binary";
 }
 
 /**
diff --git a/sources/main.cpp b/sources/main.cpp
index ed460609f..5eb7efca3 100644
--- a/sources/main.cpp
+++ b/sources/main.cpp
@@ -112,7 +112,8 @@ void myMessageOutput(QtMsgType type,
         txt+= context.function ? context.function : "";
         txt+=")\n";
     }
-    QFile outFile(QETApp::configDir()
+    QFile outFile(QETApp::dataDir()
+              +"/"
               +QDate::currentDate().toString("yyyyMMdd")
               +".log");
     if(outFile.open(QIODevice::WriteOnly | QIODevice::Append))
@@ -131,7 +132,7 @@ void myMessageOutput(QtMsgType type,
 void delete_old_log_files(int days)
 {
     const QDate today = QDate::currentDate();
-    const QString path = QETApp::configDir() + "/";
+    const QString path = QETApp::dataDir() + "/";
 
     QString filter("%1%1%1%1%1%1%1%1.log"); // pattern
     filter = filter.arg("[0123456789]"); // valid characters
diff --git a/sources/qet_elementscaler/qet_elementscaler.cpp b/sources/qet_elementscaler/qet_elementscaler.cpp
index 930bae333..b7e362d1e 100644
--- a/sources/qet_elementscaler/qet_elementscaler.cpp
+++ b/sources/qet_elementscaler/qet_elementscaler.cpp
@@ -22,7 +22,7 @@
 #include <QProcess>
 #include <QInputDialog>
 #include <QMessageBox>
-#include <QDir>
+#include <QStandardPaths>
 
 /**
  * @brief QET_ElementScaler
@@ -113,13 +113,7 @@ QByteArray ElementScaler(const QString &file_path, QWidget *parent)
 
 QString ElementScalerDirPath()
 {
-#if defined(Q_OS_WIN32) || defined(Q_OS_WIN64)
-    return (QDir::homePath() + QStringLiteral("/Application Data/qet/binary"));
-#elif defined(Q_OS_MACOS)
-    return (QDir::homePath() + QStringLiteral("/.qet/binary"));
-#else
-    return (QDir::homePath() + QStringLiteral("/.qet/binary"));
-#endif
+    return QStandardPaths::writableLocation(QStandardPaths::AppDataLocation) + "/binary";
 }
 
 /**
diff --git a/sources/qetapp.cpp b/sources/qetapp.cpp
index f1211bb47..e7611fd88 100644
--- a/sources/qetapp.cpp
+++ b/sources/qetapp.cpp
@@ -121,7 +121,7 @@ QETApp::QETApp() :
         tr("Chargement... Initialisation du cache des collections d'éléments",
            "splash screen caption"));
     if (!collections_cache_) {
-    QString cache_path = QETApp::configDir() + "/elements_cache.sqlite";
+    QString cache_path = QETApp::dataDir() + "/elements_cache.sqlite";
 
         collections_cache_ = new ElementsCollectionCache(cache_path, this);
         collections_cache_->setLocale(langFromSetting());
@@ -620,7 +620,7 @@ QString QETApp::customElementsDir()
             }
         }
 
-        m_custom_element_dir = configDir() + "elements/";
+        m_custom_element_dir = dataDir() + "/elements/";
         return m_custom_element_dir;
     }
 }
@@ -657,7 +657,7 @@ QString QETApp::companyElementsDir()
             }
         }
 
-        m_company_element_dir = configDir() + "elements-company/";
+        m_company_element_dir = dataDir() + "/elements-company/";
         return m_company_element_dir;
     }
 }
@@ -780,7 +780,7 @@ QString QETApp::companyTitleBlockTemplatesDir()
         return m_user_company_tbt_dir;
     }
 
-    return(configDir() + "titleblocks-company/");
+    return(dataDir() + "/titleblocks-company/");
 }
 
 /**
@@ -813,7 +813,7 @@ QString QETApp::customTitleBlockTemplatesDir()
         return m_user_custom_tbt_dir;
     }
 
-    return(configDir() + "titleblocks/");
+    return(dataDir() + "/titleblocks/");
 }
 
 /**
@@ -841,21 +841,31 @@ QString QETApp::configDir()
 #ifdef QET_ALLOW_OVERRIDE_CD_OPTION
     if (config_dir != QString()) return(config_dir);
 #endif
-#ifdef Q_OS_WIN32
-    // recupere l'emplacement du dossier Application Data
-    // char *app_data_env = getenv("APPDATA");
-    // QString app_data_str(app_data_env);
-    QProcess * process = new QProcess();
-    QString app_data_str = (process->processEnvironment()).value("APPDATA");
-    // delete app_data_env;
-    delete process;
-    if (app_data_str.isEmpty()) {
-        app_data_str = QDir::homePath() + "/Application Data";
-    }
-    return(app_data_str + "/qet/");
-#else
-    return(QDir::homePath() + "/.qet/");
-#endif
+    QString configdir = QStandardPaths::writableLocation(QStandardPaths::AppConfigLocation);
+    if (configdir.endsWith('/')) {
+        configdir.remove(configdir.length()-1, 1);
+    }
+    return configdir;
+}
+
+/**
+    @brief QETApp::dataDir
+    Return the QET data folder, i.e. the path to the folder in which
+    QET will find user-collections and user-titleblocks by default
+    specific to the current user. This directory is generally
+    C:/Users/<USER>/AppData/Roaming/<APPNAME>
+    on Windows and
+    ~/.local/share/<APPNAME>
+    under UNIX-like systems.
+    \~ @return The path of the QElectroTech data-folder
+*/
+QString QETApp::dataDir()
+{
+    QString datadir = QStandardPaths::writableLocation(QStandardPaths::AppDataLocation);
+    if (datadir.endsWith('/')) {
+        datadir.remove(datadir.length()-1, 1);
+    }
+    return datadir;
 }
 
 /**
@@ -1536,7 +1546,7 @@ void QETApp::useSystemPalette(bool use) {
                 "}"
                 );
     } else {
-        QFile file(configDir() + "style.css");
+        QFile file(configDir() + "/style.css");
         file.open(QFile::ReadOnly);
         QString styleSheet = QLatin1String(file.readAll());
         qApp->setStyleSheet(styleSheet);
diff --git a/sources/qetapp.h b/sources/qetapp.h
index 2f4cdc402..572e2c837 100644
--- a/sources/qetapp.h
+++ b/sources/qetapp.h
@@ -97,6 +97,7 @@ class QETApp : public QObject
         static QETProject *project(const uint &);
         static int projectId(const QETProject *);
         static QString configDir();
+        static QString dataDir();
         static QString languagesPath();
         static QString realPath(const QString &);
         static QString symbolicPath(const QString &);
diff --git a/sources/ui/aboutqetdialog.cpp b/sources/ui/aboutqetdialog.cpp
index b1dc0abc0..f94b62449 100644
--- a/sources/ui/aboutqetdialog.cpp
+++ b/sources/ui/aboutqetdialog.cpp
@@ -208,7 +208,7 @@ void AboutQETDialog::setLicence()
 */
 void AboutQETDialog::setLoginfo()
 {
-    const QString path = QETApp::configDir() + "/";
+    const QString path = QETApp::dataDir() + "/";
     QString filter("%1%1%1%1%1%1%1%1.log"); // pattern
     filter = filter.arg("[0123456789]"); // valid characters
     Q_FOREACH (auto fileInfo,

As already said in previous post the general configuration-file of QET and the stalefiles are completely managed by Qt-Library-functions. So they are already at system-specific locations. There is no need to touch them with these modifications!

I uploaded that patch to my fork of QET at https://github.com/plc-user/qelectrotech-source-mirror and can create a pull-request, if you wish, Laurent.

@all:
Everyone who can compile QET from sources is invited to download, compile and test the software!  nomicons/smile
But be aware:
The location of configurations, the elements-collections and the titleblocks may (will) have changed!
Please give feedback here or at github about your experience!

Thanks in advance!
  plc-user

303

(209 replies, posted in Import DXF)

Salut Laurent !

our posts overlapped in time...

scorpio810 wrote:

@plc-user:It seems like a lot of work and I don't feel up to it any more.

My health is deteriorating and I find it hard to think and organise myself.

What's more, at work I suffer from not being as fit and clear-headed as I was at 40.
Perhaps this is due to the many medications I'm taking.

Wish you all the best for your health!

Take your time to test the patch: there is no need to rush!!!

Moved post with patch to more suitable CODE-Forum:
https://qelectrotech.org/forum/viewtopic.php?id=2880

304

(209 replies, posted in Import DXF)

Salut Laurent !

scorpio810 wrote:

BTW, on Windows OS our users don't have the config file .... All config 'stored only in registry editor: regedit!! beurk!  nomicons/gne
nomicons/wink

O.k. but there will be a ConfigPath where to store some css- or json-files, I think.
Qt says on its site for win:

AppConfigLocation:
  "C:/Users/<USER>/AppData/Local/<APPNAME>"
AppDataLocation:
  "C:/Users/<USER>/AppData/Roaming/<APPNAME>"

So we need to handle the paths on all three systems!

The general configuration file of QElectroTech is completely handled by library-function "QSettings".
By default it is stored (on Linux) here:
/home/$USER/.config/$Organization/$Application.conf
So there is no need to take any action!

The stalefiles are handled by library-functions of Qt and are stored here:
/home/$USER/.local/share/stalefiles/QElectroTech/
No need to take any action!

What I found out, it should be necessary to set:

  • AppConfigLocation for:
      + style.css
      + graphics_table.json
      + element_texts_pattern
      + summary.json
      + nomenclature.json

  • AppDataLocation for:
      + LogFiles
      + elements_cache.sqlite
      + default-location for user- and company-collections
      + default-location for user- and company-titleblocks
      + additional binaries (dxf2elmt, QET_ElementScaler)

To achieve such a splitting of config and data we need to introduce a function "QETapp::dataDir()" and change the appropriate lines for the setting of Paths and Filenames.

305

(209 replies, posted in Import DXF)

scorpio810 wrote:

Remember to find KAutoSaveFile::allStaleFiles PATH also.

Where do I find those files, if they exist on the system?
Can I force QET to produce a "StaleFile"?

306

(209 replies, posted in Import DXF)

Salut Laurent !

Thank you for the reply!

Can you compile and test the code also on/for win and macos?
After some more reading:
It would be interesting to find the standard-directories on the systems for Application-Config and Application-Data.
So in my opinion we should use

QStandardPaths::writableLocation(QStandardPaths::AppConfigLocation)

for our configuration and

QStandardPaths::writableLocation(QStandardPaths::AppDataLocation)

for additional binaries, collections, titleblocks, log-files, etc.
At first sight it should be quite easy to change the default-locations for config and data.
Transition for the users might be a challenge...

307

(209 replies, posted in Import DXF)

Salut Laurent !

scorpio810 wrote:

Hallo plc-user: what do you think about this issue? . I'm think that very strange!!!
https://github.com/qelectrotech/qelectr … issues/325

Sounds very similar...

In my opinion we should use a configuration path that can be read from qt-library-functions like "QStandardPaths::AppConfigLocation" or so.
Found the information here: https://doc.qt.io/qt-6/qstandardpaths.html

Than we won't need to set the path hardcoded individually for every system.

Maybe you can test this code-fragment, Laurent?
I know you can compile for different systems... nomicons/wink

#include <QStandardPaths>

QMessageBox msgBox;
QStringList lolo = QStandardPaths::standardLocations(QStandardPaths::AppConfigLocation) ;
msgBox.setInformativeText(lolo.join("\n"));
msgBox.setText("QStringList returned by QStandardPaths::standardLocation");
msgBox.exec();

On my Debian unstable it shows this output:

QStringList returned by QStandardPaths::standardLocation

/home/ich/.config/QElectroTech/QElectroTech
/etc/QElectroTech/QElectroTech
/etc/xdg/QElectroTech/QElectroTech
/usr/share/QElectroTech/QElectroTech

EDIT:
Just found this:

QStandardPaths::writableLocation(QStandardPaths::AppConfigLocation)

It returns this:

/home/ich/.config/QElectroTech/QElectroTech

EDIT 2:
I was a bit confused about the double "QElectroTech" in the path, but reading the docs helps!
It results from the settings in main.cpp:

    QCoreApplication::setOrganizationName("QElectroTech");
    QCoreApplication::setOrganizationDomain("qelectrotech.org");
    QCoreApplication::setApplicationName("QElectroTech");

We have to keep in mind that such a modification would affect more, than just the execution of dxf2elmt and/or QET_ElementScaler!
It would be necessary to look at more parts of QET-sourcecode where the configuration directory is also used: settings, collections, titleblocks, etc.

308

(209 replies, posted in Import DXF)

lanet wrote:

good day. Even though I click on the "installation folder" to convert the dxf file, it does not open. So I created my own folder and added "binary/dxf2elmt" into it. Even though I enter the program and click on the "installation file" again with the mouse, it does not open. Can anyone help?'

In the sources of QET one can find, that the "installation folder" is this one on windows:

(QDir::homePath() + QStringLiteral("/Application Data/qet/binary"))

should resolve to:

c:/users/$YourUserName/Application Data/qet/binary

Maybe a permission-problem?

Mehrere Linien und Polygone sind kaputt und enthalten ungültige Werte! Siehe Screenshot.

$ QET_ElementScaler Metron.elmt 
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
Polygon not konsistent! 
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
 * * * Polygon-Point with invalid value!
Polygon not konsistent! 
Remove line: Value missing at index: 1
Remove line: Value missing at index: 1
Remove line: Value missing at index: 1
Remove line: Value missing at index: 1
$

Verwende QET_ElementScaler, um das zu prüfen / beheben: https://github.com/plc-user/QET_ElementScaler
In den Releases findest Du Binaries für einige Betriebssysteme.

Welche Linien und Polygone dann fehlen, ist für Dich das fröhliche Suchspiel am Morgen!  nomicons/wink


PS:
Die vier "Langlöcher" links und rechts brauchst Du nicht zusammenstückeln:
Ein Rechteck mit entsprechend gesetzten Werten für Rundung erledigen das in eins!

310

(209 replies, posted in Import DXF)

Let's not guess what might be wrong with the fonts, but wait for Vadoola's answer when he has looked at the dxf and the resulting element-file!

andrew wrote:

(...) I wonder if prev document I converted from DWG->DXF->Element was messed up (...)

I'm also not asking why you took the additional conversion route via dwg when there is a dxf available from the supplier that can be converted directly. I achieved the perfect results I described in the post above (https://qelectrotech.org/forum/viewtopi … 822#p20822) - with Vadoolas latest code and without any additional scaling!
In any case, the downloaded dxf is attached to that post, too.

311

(209 replies, posted in Import DXF)

I don't know what you are complaining about: the drawing is perfectly converted and the scale of 1mm = 2px is also correct!
And vadoola's statement is also correct: scaling of texts and their positioning still needs to be worked on.

What texts do you want to use for the front view of the element? You know the name, the part-number and the manufacturer...

312

(209 replies, posted in Import DXF)

vadoola wrote:

With the logic I added to check for circle shaped polygons and converting them to QET ellipses hopefully this will be less of an issue, but I know there is more work to be done here.

The circle was just one example: it is also about other graphic elements, such as arcs. In many cases, text and the manufacturer's logo are composed of many individual polygons, too.

vadoola wrote:

I doubt people will be importing dxf's of tiny simple drawings like a ladder diagram coil or contact. This would probably be mostly used for importing drawings of real life objects.

I agree: drawings converted from dxf are more likely to be used in the professional sector for front views (thumbnails). In my opinion, circuit diagram symbols represent the function schematically and do not look like the real part.
I would therefore refer to front views rather than schematic symbols for the conversion. And here we are not talking about small components with which an electronic circuit is built: That's what you make circuit boards for with KiCad!
We are talking about parts that are used in a domestic installation or in a control cabinet. I consider a size of 20x20mm (results in 40x40px) to be “small”: So we could also assume, for example, 50px as the minimum size, for which there would then be no need for extra scaling.

vadoola wrote:

From my testing so far there are some issues with the placement of the text due to a bigger boundary box in QET (...)

As predicted nomicons/wink :

plc-user wrote:

You will have "a lot of fun” with the text position, (...)

This is the message, when the file is broken!

QET saves it's data in XML-files and (like many others!) does not show where the problem might be, when loading fails.
Try to open a copy of that file (renamed to *.xml) with firefox: It shows the first problematic part, that you have to fix. This might have to be repeated several times, before the XML is valid.

In a CMD-Window you can also use the most recent version of QET_ElementScaler, where the first problematic part of the file will be shown:
usage:

QET_ElementScaler SchematicFile.qet

It might show something like this:

$ QET_ElementScaler filtre-à-bande.qet 
File "filtre-à-bande.qet" could not be loaded: Error parsing element attribute
Check file up to byte-offset: 1196545 -- content partly shown here:
(...)rmula="" y="-130" numsize="7" condsize="1" conductor_colo" condsize="1" freezeLabel="false" bus="" dash-size="2" y="(...)
$

You mean something like a Bus or a cable like in the attachment?

As far as I know a bus cannot be defined but sometimes I read something like "define a cable" in the forum what might be similar...
Try forum search.

315

(209 replies, posted in Import DXF)

This part really does a lot of work...

Thanks for the link to the data sheet! At least now we have specific values to discuss.

But perhaps we should move away from this specific part to find something generally valid.

The primary aim is to obtain a “respectable” QET element that we can scale in a second step if necessary. The prerequisite for an element that requires little reworking is, of course, that circles from the dxf also look like circles in the element. To achieve this, the element size must be appropriate.

Do we have the chance to determine during import whether the numerical values in the unitless dxf are so small that scaling would be necessary? Something similar to: “Values are all smaller than xx, so will be enlarged by a factor of 10 or 100!

316

(209 replies, posted in Import DXF)

Maybe it is necessary also to take the tag $MEASUREMENT into account?
In the file “05DI-AD16DIX-10.dxf” one can find this:

$MEASUREMENT
 70
     0
  0

When imported in current FreeCAD dev-version you can measure the terminal-width: 18,19 mm (see screenshot)

@scorpio810:
Do you know the manufacturer and name of that part to get the real dimensions, Laurent?

317

(209 replies, posted in Import DXF)

I have noticed that there are differences in the unitless dxf files.
The test file for 1-point polygons does not contain “INSUNITS” and the file “05DI-AD16DIX-10.dxf” (see here https://qelectrotech.org/forum/viewtopi … 379#p20379) contains the tag “INSUNITS”, but no entry “70” for the unit, but this:

INSUNITS
350
99E
  3

and so the resulting element is very small. I tried a few factors and found a suitable value, I think. An “educational guess” results in a factor of 99.0508158778 for this file - then the individual terminals have a distance of 5.08mm = 10.4px. This is a commonly used dimension for terminals.
I couldn't find out what the values in the tag stand for.

For the tests I used the current source code from January 10 2025

Neben der Frage, ob ich Dir helfen kann...
Das habe ich in einem anderen Thread so geschrieben:

Many unanswered questions before you can be helped:
Which system are you using?
Which QElectroTech version are you using? (Help -> About QElectroTech -> ‘Version’ tab)
Are there any helpful entries in the log file? (Help -> About QElectroTech -> ‘log’ tab)

... und der angesprochene Anhang fehlt auch!

You mean the overlapping texts?
Try forum-search with keyword "overlap" or read here:
https://qelectrotech.org/forum/viewtopic.php?id=2418

It's the combobox under the one for user-collection in QET-Settings.
I use Debian GNU/Linux and most recent dev-version, so the paths look different from those, you use!

Maybe the path to user-titleblocks is not writable?
Did you try to set another path to user-titleblocks?

Kurze Antwort: Nö!

Etwas längere Antwort:
Gerade bei Relais hast Du doch den Kontaktspiegel, der Dir anzeigt, welche Kontakte wo verbunden sind.

Mir sind nur zwei Möglichkeiten bekannt, wie man Kontakte miteinander verbindet:
Entweder man verbindet sie mit einer mechanischen Verbindung (gestrichelte Linie) oder man verknüpft sie als "Master-Slave".
Dein Vorgehen ist aus meiner Sicht also völlig o.k.!

Tip: Move the mouse pointer slowly over the icons in the toolbar and read the hint texts!

jns wrote:

Was ich erreichen möchte ist, ein Drucktaster mit einem Öffner und einem Schliesser, welche ich individuell platzieren kann. Gibt es da eine elegante/standart Lösung?

Wer oder was hindert Dich daran, den zweiten Kontakt frei auf einem beliebigen Folio zu plazieren und die beiden dann zu verknüpfen?