201

(193 replies, posted in Import DXF)

Hello vadoola,

let's put it this way:
I created a QET-Element just with the use of element-editor.
In the attachment you see, that the texts are the same size as the height of the rectangles.

So in my opinion we do not have to use another factor than 2.0 for the "real world" size in the DXF!
When DXF says circle has a diameter of 10mm then in element it is 20.
If it says 1 inch in the DXF it will be 50.8 in the element whether it is a graphical part or a text!
It does not matter if text or anything else: There is always a "scale" of 1mm = 2px

I checked in all DXFs I have: Fits everywhere! 
If you have a DXF where the factor of 2.0 does not fit: Let me see.

Salut Laurent !

Thanks again, Laurent!
The Debian-Version is also working pretty good!

A few questions about "qet_tb_plugin":
As I understand correctly, the plugin may or even can only be started, when a project is loaded, correct?
"qet_tb_plugin" or "qet_tb_plugin.exe" is an executable file, right?
And:
Similar to dxf2elmt or QET_ElementScaler QET only starts the executable from known locations ... QET does not download python or source-code of the plugin, right?

If all three answers are "yes", some of the "spaghetti-code" in qetdiagrameditor.cpp can be simplified and "automated" similar to configDir() or dataDir().
Already making first attempts...

Salut Laurent !

Didn't find any new Debian-Packages on QET-Repo but my local created binary works very well with the latest changes!
The latest "major" changes mainly concern the ReadyToUse version for Windows and it works exactly as I know it from the “old” version ... only with more comprehensible directories for projects, exports, etc.!
The Install-Version for Windows also works as expected.

Best regards,
  plc-user

204

(193 replies, posted in Import DXF)

Hello vadoola,

vadoola wrote:

(...) A font point is defined as 1pt = 1/72 inches, which comes out to 1pt = 0.3528mm.

Based on this conversion the values that are being generated are "correct", because text height in mm would be multiplied by a factor of roughly 2.83. instead of the 2 used to convert mm to pixels.

Just to understand you correctly:
You think the calculation of the text size is correct if a text that fits well into a rectangle in the DXF is much bigger and no longer fits into the same rectangle in the converted element? And that's because it says somewhere that a px is not as big as a pt? Seriously?

Attached is another example to clarify what I mean:
A DXF file in which I have inserted an 11 mm high text into a field of about 12 mm. Next to it is the converted element file, where you can see that the text “11 mm” definitely does not fit into the same field. In addition, the element file in which I changed the text “11 mm” to the appropriate size “22” and moved it.
I am explicitly not talking about the text position here, as we both know that this does not yet fit: I'm talking about the text size!

Note:
I used dxf2elmt - sources from last weeks commit c3a5b2a.

Salut Laurent !

scorpio810 wrote:

i just published all packages, please try and check.

Thank you for the work you did with packaging! 
In my opinion they work perfectly:
For the ReadyToUse-Version the additional config (*.json, etc) and the data (elements, titleblocks, etc) are saved below one directory!

For convenience-reasons I changed some additional places in source-code, to QETApp::documentDir(), where other places were used.

But still: Location and handling of qet_tb_generator stays untouched, until we know, what we have to do to also move it to "dataDir()/binary" or so.
Or can we drop support of python-plugin at some time, when internal Terminal-Manager is ready for production-use?

This leads to the question of what is going on with Joshua: Do you have any information? How are he and his wife doing now? Can we expect to see him again in the foreseeable future? Please send him my regards: He is missing!

scorpio810 wrote:

I don't publish arm64 macOS at this time. maybe this week...

That's o.k. with me: Have no bitten fruits...  nomicons/wink

Best regards
  plc-user

206

(193 replies, posted in Import DXF)

Back to the topic:  nomicons/smile

Hello Vadoola,

I'm not quite happy with the font sizes yet.
That's why I used Inkscape to create a drawing with different font sizes. When I realized that the fonts were exported as polygons into DXF, I used LibreCAD to add some MText in different sizes.
I then converted the DXF into an element and realized that the font sizes did not fit.
If we focus on the 20 mm font:
In LibreCAD (black background) it is good to see that both texts are the same size - I expect the same for the element.
In the element (white background), the polygon 20 mm are 40px high, but the 20 mm text has a font size of 57.
So there is still a factor of about 1.4 somewhere in there that doesn't belong.
I noticed something similar with the imperial DXF from your American compatriot.

Packed all files into attached zip.

Remark #1:
The Text-Positions ...  nomicons/wink

Remark #2:
When saving the DXF from Inkscape, the bottom edge of the rectangle was lost somewhere. That shouldn't bother you!

Where did you get the screenshot from if you don't have the element?

The element is so easy to draw yourself: Two rectangles, two texts and a terminal!
I guess it took you longer to write the question than it would have taken to create the element!

Salut Laurent !

What I noticed when using the ReadyToUse version for Windows:
We haven't quite finished setting the directories for configuration and data yet.
One small detail is still missing:
A command line parameter for specifying a data directory!

If we want to keep the “ReadyToUse” version for Windows as a “portable” version as far as possible, in which all files are located under ONE base directory, we need the command line parameter “--data-dir” in the batch file. Otherwise, the log files and data are not stored in the directory of the ReadyToUse version, but in the standard Windows data directory.

As an additional benefit, we offer users the option of running completely separate versions on one PC! It would only need to be called with different parameters for “--config-dir” and “--data-dir” and completely different configurations and data are possible.
And this applies in particular to all macOS and Linux users:
Here the configuration is available as “QElectroTech.conf”, which is also located in the configuration directory. Win users have the disadvantage with the registry...

Will upload the changes to my fork of QET very soon ... stay tuned!  nomicons/smile


I have also noticed that we (still) supply a “QElectroTech.conf” with the ReadyToUse version, which is known not to be used on Windows. This can therefore be removed?

Perhaps because the system was installed a long time ago and has only been updated since then?

In any case: The qelectrotech.sources described above also works with Debian Bookworm.

For the record and users who run Debian GNU/Linux unstable:

apt-key is not available in Debian unstable anymore!

For a few days now, this is the way to go:

  • download key-file:
    wget -q https://debian.qelectrotech.org/qet/bui … sitory.asc
    and save (as root) to /etc/apt/keyrings

  • adjust sources-list entry for QElectroTech
    file needs the ending ".sources" as in this example:
    /etc/apt/sources.list.d/qelectrotech.sources

  • content of qelectrotech.sources:

# draw electric diagrams with QElectroTech
# 
Types:      deb
URIs:       https://debian.qelectrotech.org/qet/builds/debian/
Suites:     unstable
Components: main
Enabled:    yes
Signed-By:  /etc/apt/keyrings/Qelectrotech_Repository.asc
  • from here everything further is known:
    apt update
    apt install qelectrotech

@scorpio810:
Maybe you can update the information on QET-Homepage, Laurent?
Thanks in advance!  nomicons/smile

Salut Laurent !

A question of understanding about other storage locations:
Is there a special reason why all files (projects, export files, BOMs, etc.) are saved on the desktop by default and not in the documents directory?
I would even suggest to save nomenclatures, BOMs, etc. just beside the project-files by default.
While we're at it, we could adjust this at the same time. No user intervention would be necessary for this change!

Best regards
  plc-user

A short manual for the transition from old to new locations of config- and data-directories.

In the following blocks you find the changes, that have to be made by the user, when upgrading to the new version.
If you are missing any information or have found an error, please let us know!

Modifications on Linux:
- location of QElectroTech.conf:
  ~/.config/QElectroTech/QElectroTech.conf
  NO activity required!
- location of QET-stalefiles
  ~/.local/share/stalefiles/QElectroTech
  NO activity required!
- python-plugin "qet_tb_generator"
  binary of plugin may be moved to ~/.local/share/QElectroTech/QElectroTech/binary
  but generally: NO activity required!

Linux old                         -->  Linux new
~/.qet/*.json                     -->  ~/.config/QElectroTech/QElectroTech/*.json
~/.qet/element_texts_pattern/*.*  -->  ~/.config/QElectroTech/QElectroTech/element_texts_pattern/*.*
~/.qet/*.log                      -->  ~/.local/share/QElectroTech/QElectroTech/*.log
~/.qet/elements_cache.sqlite      -->  ~/.local/share/QElectroTech/QElectroTech/elements_cache.sqlite
the following directories: including content!
~/.qet/binary                     -->  ~/.local/share/QElectroTech/QElectroTech/binary
~/.qet/elements                   -->  ~/.local/share/QElectroTech/QElectroTech/elements
~/.qet/elements-company           -->  ~/.local/share/QElectroTech/QElectroTech/elements-company
~/.qet/titleblocks                -->  ~/.local/share/QElectroTech/QElectroTech/titleblocks
~/.qet/titleblocks-company        -->  ~/.local/share/QElectroTech/QElectroTech/titleblocks-company

--------------------------------------------------------------------------------

Modifications on Windows (ReadyToUse):
- Configuration and data:
  NO activity required
- python-plugin "qet_tb_generator"
  binary of plugin may be moved to  (base-dir)\conf\binary
  but generally: NO activity required!

--------------------------------------------------------------------------------

Modifications on Windows (Installer):
- QElectroTech.conf:
  NO activity required: Registry
- QET-stalefiles
  NO activity required!
- python-plugin "qet_tb_generator"
  binary of plugin may be moved to  (+)\Roaming\QElectroTech\QElectroTech\binary
  but generally: NO activity required!

To keep line-length short:
  "(#)" means "C:\Users\<USER>\Application Data"
  "(+)" means "C:\Users\<USER>\AppData"

Windows old                        -->  Windows new
(#)\qet\*.json                     -->  (+)\Local\QElectroTech\QElectroTech\*.json
(#)\qet\element_texts_pattern\*.*  -->  (+)\Local\QElectroTech\QElectroTech\element_texts_pattern\*.*
(#)\qet\*.log                      -->  (+)\Roaming\QElectroTech\QElectroTech\*.log
(#)\qet\elements_cache.sqlite      -->  (+)\Roaming\QElectroTech\QElectroTech\elements_cache.sqlite
the following directories: including content!
(#)\qet\binary                     -->  (+)\Roaming\QElectroTech\QElectroTech\binary
(#)\qet\elements                   -->  (+)\Roaming\QElectroTech\QElectroTech\elements
(#)\qet\elements-company           -->  (+)\Roaming\QElectroTech\QElectroTech\elements-company
(#)\qet\titleblocks                -->  (+)\Roaming\QElectroTech\QElectroTech\titleblocks
(#)\qet\titleblocks-company        -->  (+)\Roaming\QElectroTech\QElectroTech\titleblocks-company

Salut Laurent !

scorpio810 wrote:

Maybe I think I made a a little mistake when merging your PR (...)

I admit, I was a bit surprised, that you accepted the PR that fast! nomicons/wink

scorpio810 wrote:

(...) the location of binary plugin collections, the path in the logs now was  wrong, and so on.

I wouldn't say the paths were wrong: Let's say the paths were different!

plc-user wrote:

Transition for the users might be a challenge...

We should at least have done a few tests to see how the change affects the various systems and how the effects can be explained and resolved. That's why I invited the other forum members to try out the changes on their systems and give feedback!
The invitation to test and give feedback is still active!

As far as I have seen on my systems, the corrections are limited to moving files from here to there. And on systems without any previous version, everything is fine!

scorpio810 wrote:

/home/laurent/.local/share/QElectroTech/QElectroTech/binary/

Yes, that's the new directory for the binaries of dxf2elmt and QET_ElementScaler on Linux
On a windows-system this directory for the additional binaries defaults to this:

C:/Users/<USER>/AppData/Roaming/QElectroTech/QElectroTech/binary

Do the path-specifications for python-plugin "qet_tb_generator" also need to be adjusted? I don't think so, because these aren't touched by the changes regarding "configDir()" or "dataDir()": They still refer to "QDir::homePath()".
(There is so much hardcoded in the sources! Maybe in another step and with the support of someone knowing, how to deal with "constrictor snakes"...)

As you said, the configuration on win is kept in the Registry, but the additional configuration files (*.json for nomenclature, etc.) are kept in this newly created path:

C:/Users/<USER>/AppData/Local/QElectroTech/QElectroTech/

For users who start QET from the command line and use the parameter “--config-dir $PATH”, nothing with configuration changes, as this is handled when the program is started, before reading system-default.

scorpio810 wrote:

Sometimes you have to demolish everything in order to rebuild better. nomicons/wink

We are on a good way to make QET even better!  nomicons/smile

Best regards,
  plc-user

214

(19 replies, posted in Terminal block generator)

thomas.martin198 wrote:

Ça veut pas me le prendre, il est trop gros.

Your Project-file is too big?
Use zip to compress and try again.

Salut Laurent !

scorpio810 wrote:

you could add a pull request?

Done!
There were overlapping changes at "machine_info.cpp" that conflicted with automatic merge at github.
EDIT:
No conflicts anymore: PR can be merged automatically!

scorpio810 wrote:

Users just want to know the PATH of stalesfiles:
https://qelectrotech.org/bugtracker/view.php?id=209

The path to stalefiles-directory seems to be:

QStandardPaths::writableLocation(QStandardPaths::GenericDataLocation)

according to info at https://doc.qt.io/qt-6/qstandardpaths.html it resolves to:

Linux:
  "~/.local/share"
windows: 
  "C:/Users/<USER>/AppData/Local"
macos:
  "~/Library/Application Support"

On my Debian - machines the stalefiles-directory for QET is this:

/home/ich/.local/share/stalefiles/QElectroTech/

Salut Laurent !

With no code-change in stale-file handling.

In the attachment: A short story of stalefiles in pictures. nomicons/wink

Salut Laurent !

Thanks for the Links!

I think we don't have to handle stalefiles in this context, because we speak of the default-location of QET-Configuration, Elements, Titleblocks, etc.

plc-user wrote:

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!

And as "KDE" says on linked site:

KAutoSaveFile wrote:

Creates and manages a temporary "auto-save" file.

Autosave files are temporary files that applications use to store the unsaved data in a file they have open for editing. KAutoSaveFile allows you to easily create and manage such files, as well as to recover the unsaved data left over by a crashed or otherwise gone process.

The stalefiles are temporary copies of the current schematics in a QET-Project.
So: There is no need to take any action with stalefiles in this context.

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

220

(193 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

221

(193 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.

222

(193 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"?

223

(193 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...

224

(193 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.

225

(193 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?