Re: Improvement to locating font directories
Posted by
dxli on
URL: https://forum.librecad.org/Improvement-to-locating-font-directories-tp5706774p5706778.html
Hi bgoodr,
The patch is quite good.
If you have a github repository, you can simply send in pull request to the main tree: LibreCAD/LibreCAD.git. If you still want me to apply the patch manually, please let me know.
I hope we can review the folder handling at this time, to make sure it works without copying over files manually, for example,
Best Regards,
Dongxu
On Sat, Jun 16, 2012 at 10:40 AM, bgoodr [via LibreCAD]
<[hidden email]> wrote:
Thanks very much, Dongxu!
Could you clarify what you mean by "building shadowed"? I've not
heard that phrase before, but perhaps you mean path search
functionality that is similar the goal underlying my LibreCAD source
patch (see "<bg>" below).
That patch I posted is not checked into Git as of right now (Sat Jun
16 06:29:38 PDT 2012). I am holding back for two reasons (a) I would
like to receive some feedback about whether or not the change is a
good one, and (b) I do not yet know what the process is for obtaining
approval to check into Git and into what branch. I should have
clarified that in my original post.
Allow me to elaborate in detail what my change does so that we can
decide if it is a good one, or if it needs further improvement, before
requesting checkin (For the record, see the references section
detailing my current install of Debian Linux in [1]):
After building and installing LibreCAD and copying the files into a
Autoconf-like directory structure [2], I invoked the tool and tried to
add text objects, but no such object was added (and the font list
pulldown did not show any font names at all). I debugged the problem
and discovered that RS_System::getDirectoryList hardcodes paths to
/usr for the tool-supplied fonts, hatches, plugins, etc. To fix the
directory lookup logic so that the fonts and other files supplied with
the LibreCAD sources are properly found at runtime, I added the code
shown marked as "<bg>" below:
,----
| // Unix home directory, it's old style but some people might have stuff there.
| dirList.append(getHomeDir() + "/." + appDirName + "/" + subDirectory);
|
| ...
|
| //local (application) directory has priority over other dirs:
| if (!appDir.isEmpty() && appDir!="/" && appDir!=getHomeDir()) {
| if( appDir != getCurrentDir() && subDirectory != QString("plugins")) {// 17 Aug, 2011, Dongxu Li, do not look for plugins in the current folder, we should install plugins to system or ~/.LibreCAD/plugins/
| dirList.append(appDir + "/" + subDirectory);
| }
| }
|
| <bg> // share directory relative to the bin directory in the installation directory:
| <bg> QFileInfo fileinfo(QCoreApplication::applicationDirPath());
| <bg> QString finalDir(fileinfo.dir().path() + "/share/" + appDirName + "/" + subDirectory);
| <bg> dirList.append(finalDir);
|
| // Ubuntu
| dirList.append("/usr/share/doc/" + appDirName + "/" + subDirectory);
|
| // Redhat style:
| dirList.append("/usr/share/" + appDirName + "/" + subDirectory);
`----
Here is what I believe the "<bg>" code snippet does:
1. Get the runtime directory of where librecad is installed
(QCoreApplication::applicationDirPath()), which should be a "bin"
directory.
2. Find the parent directory of that "bin" directory (fileinfo.dir().path()).
3. Construct the file name via "<parent_dir>/share/<appDirName>/<subDirectory>".
The effects of that code change should be:
1. It doesn't matter where the application lives. It could be in
/usr/bin/librecad, could be in
/home/joeblo/install/something_os_specific_here/bin/librecad,
etc., which allows for locally built installations.
2. It should not interfere with users putting their own additions
relative to their own $HOME/ directory as the code above in "old
style but some people might have stuff there" will supercede the
"<bg>" change.
3. It should not interfere with what Debian package maintainers are
doing today in their build infrastructure as it conforms nicely
with an expected directory structure [2].
If we find the "<bg>" change acceptable as is, then I also believe we
should delete the "Redhat style" code shown below: The "<bg>" code
yeilds the same results when the "bin" directory is "/usr/bin":
,----
| // Redhat style:
| dirList.append("/usr/share/" + appDirName + "/" + subDirectory);
`----
Do you think that a good enough fix for this use case? If so, then
I'll need to find out what the checkin process is and formally submit
the change.
Thanks,
bg
--------------------------------------------------------------------------------
Detailed reference material that most folks probably can ignore:
--------------------------------------------------------------------------------
[1] My current system info and state:
My Debian system /etc/apt/sources.list file contains the following:
,----
| #
|
| # deb cdrom:[Debian GNU/Linux wheezy-DI-a1 _Wheezy_ - Official Snapshot amd64 NETINST Binary-<a href="tel:1%2020120512-00" value="+12012051200" target="_blank">1 20120512-00:39]/ wheezy main
|
| #deb cdrom:[Debian GNU/Linux wheezy-DI-a1 _Wheezy_ - Official Snapshot amd64 NETINST Binary-<a href="tel:1%2020120512-00" value="+12012051200" target="_blank">1 20120512-00:39]/ wheezy main
|
| deb http://ftp.us.debian.org/debian/ wheezy main
| deb-src http://ftp.us.debian.org/debian/ wheezy main
|
| deb http://security.debian.org/ wheezy/updates main
| deb-src http://security.debian.org/ wheezy/updates main
`----
The /proc/version on this system shows:
,----
| Linux version 3.2.0-2-amd64 (Debian 3.2.17-1) ([hidden email]) (gcc version 4.6.3 (Debian 4.6.3-5) ) #1 SMP Sat May 12 23:08:28 UTC 2012
`----
The /etc/debian_version on this system shows:
,----
| wheezy/sid
`----
Executing:
,----
| apt-cache show librecad
`----
shows:
,----
| Package: librecad
| Version: 1.0.2+nolibs-1
| Installed-Size: 4116
| Maintainer: Debian Science Maintainers <[hidden email]>
| Architecture: amd64
| Depends: libc6 (>= 2.4), libdxflib-2.2.0.0 (>= 2.2.0.0), libgcc1 (>= 1:4.1.1), libmuparser2 (>= 2.1.0), libqt4-help (>= 4:4.5.3), libqt4-qt3support (>= 4:4.5.3), libqt4-sql (>= 4:4.5.3), libqtcore4 (>= 4:4.7.0~beta1), libqtgui4 (>= 4:4.6.1), libstdc++6 (>= 4.4.0), librecad-data (= 1.0.2+nolibs-1), libqt4-sql-sqlite
| Description-en: Computer-aided design (CAD) system
| LibreCAD is an application for computer aided design (CAD) in two
| dimensions (2D). With LibreCAD you can create technical drawings such as
| plans for buildings, interiors, mechanical parts or schematics and
| diagrams.
| Homepage: http://www.librecad.org/
| Description-md5: d9135c95b7b340a7d52e6f02c873080e
| Tag: interface::x11, role::program, scope::application, uitoolkit::qt,
| x11::application
| Section: graphics
| Priority: optional
| Filename: pool/main/libr/librecad/librecad_1.0.2+nolibs-1_amd64.deb
| Size: 2081116
| MD5sum: ee732b724508b0439e25412924bed946
| SHA1: 9327c71b2f15f86558937a64d6d1e6caaf258d25
| SHA256: 329cdadec72dae3aa3b4e8d3a03d98af94731e15919447aa9a6862f70c1b7479
`----
Executing:
,----
| dpkg --list librecad\*
`----
shows:
,----
| No packages found matching librecad*.
`----
just to show that I am not currently running a mixed environment
(e.g., librecad installed in both /usr/bin and also installed into my
local built-from-source directory).
The version of LibreCad sources as revealed by the Help/About menu
shows (grrr! librecad --help is not implemented <sigh>):
,----
| Version: master
| SCM Revision: 2.0.0alpha3-158-g0a6f3a0
`----
[2] I reverse-engineered what the Debian package maintainers did when
constructing the librecad Debian package, and then used that info
to make guesses about how to lay out my locally built installation
of LibreCAD in my own build script. This implements what should (IMO)
have been done in LibreCAD's "make install" logic. Below,
$INSTALL_DIR is identical to GNU Autoconf's "prefix" concept
described at:
http://www.gnu.org/prep/standards/html_node/Directory-Variables.html):
,----
| PrintRun ()
| {
| echo
| echo "COMMAND: $*"
| set -e
| $*
| set +e
| }
|
| .
| .
| .
|
| PrintRun make
|
| # "make install" does nothing as of Thu Jun 14 06:59:30 PDT 2012:
| ### PrintRun make install
|
| # So I have to handle that myself here:
| # I downloaded and examined the Debian source package at
| # http://packages.debian.org/source/sid/librecad to see what they do
| # to install it. Inside ~/librecad_1.0.2+nolibs-1.debian.tar.gz we see
| # the debian/librecad-data.install file which contains:
| #
| # support/fonts /usr/share/librecad
| # unix/resources/library /usr/share/librecad
| # unix/resources/patterns /usr/share/librecad
| # unix/resources/qm /usr/share/librecad
| #
| # And inside ~/librecad_1.0.2+nolibs-1.debian.tar.gz we see the
| # debian/librecad.install file which contains:
| #
| # unix/librecad /usr/bin
| # debian/librecad.xpm /usr/share/pixmaps
| # debian/librecad.png /usr/share/icons/hicolor/48x48/apps/
| # debian/librecad.svg /usr/share/icons/hicolor/scalable/apps/
| # debian/librecad.desktop /usr/share/applications
| #
| # So simulate most/all of that:
| MyInstall ()
| {
| if [ -d "$1" ]
| then
| PrintRun mkdir -p "$2"
| fi
| PrintRun rsync -a -v -u --progress "$1" "$2"
| }
| MyInstall librecad/support/fonts/ $INSTALL_DIR/share/librecad/fonts/
| MyInstall unix/resources/library/ $INSTALL_DIR/share/librecad/library/
| MyInstall unix/resources/patterns/ $INSTALL_DIR/share/librecad/patterns/
| MyInstall unix/resources/qm/ $INSTALL_DIR/share/librecad/qm/
| MyInstall unix/librecad $INSTALL_DIR/bin/librecad
| # And I added this because I am guessing the .so's are plugins:
| MyInstall unix/resources/plugins/ $INSTALL_DIR/share/librecad/plugins/
| # And I added this because it was an executable. Seems like Debian excluded it??
| MyInstall unix/ttf2lff $INSTALL_DIR/bin/ttf2lff
|
`----
--
Dongxu Li, Ph.D.
www.librecad.org