Dear all,
this discussion will be devoted to some general issues and points regarding
FidoCadJ with Linux.
Some Linux users complained about a generalized slowness which is not normal
at all. If you understand italian, or if you can access the discussion via an
automatic translator, starting from message there are some timings about Linux
installation:
In some cases, the option sun.java2d.opengl has an effect, in other cases it
does not changes anything or make the situation worse. Any idea about that?
Regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear Darwinne and all of you Linux users out there,
Can't say anything about the draggy behaviour on my own box because my
BogoMips go beyond the skies limit.
But a few optimizations can do the trick.
Although some distro's let java run by double clicking them is better to
create a little shell script an put this named as fidocadj in the /usr/bin or
in the /usr/local/bin
#!/bin/sh# some realy try...notty=`tty | sed -e "s:/dev/::"|cut -c1`if["$notty"=="t"]thenecho"This Java program requires the graphical desktop environment"exit1fi# or even this...if[`which java | grep -c java` -eq 0]thenecho"No java support found, abort...."exit1fi### set the jar location to your needrunapp=/usr/share/java/fidocadj/fidocadj.jar
## sun/oracel or OpenJDK/OpenJDE if[`env |grep JAVA |grep -c openj` -eq 1]then##### OpenJD* ######## be nicer on tft screensexport_JAVA_OPTIONS=-Dawt.useSystemAAFontSettings=on
else##### Oracle crap, why: it's optimized for servers ####### ever seen a headless-server in need of opengl?, so they turned it off!export_JAVA_OPTIONS=-Dsun.java2d.opengl=truefi## check environment is properly set, else go bluntif[`env |grep -c JAVA` -eq 1]then$JAVA_HOME/bin/java -jar $runappelsejavapath=`which java`$javapath -jar $runappfi
Regards,
B.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An iconfile also on download.sourceforge as fidocadj-128.png
We can create one global linux installation shell script,
called "fidocadj-installer.sh" packed in a tar.gz,
the script should create the following steps:
Create the /usr/share/java/fidocadj/ folder compliant to linux-java
environment.
Fetch the latest jar => /usr/share/java/fidocadj/ and iconfile
Create a menu entry for both Gnome, KDE and any posix compatible desktop
environment. (+ iconfile)
Create create the global shell executable "fidocadj" in /usr/bin/
Optional we can create from a tar.gz file a global doc folder which includes:
all available languages pdf manuals, a "README" plus a "LICENCE" (gpl3 text)
and drop this to:
/usr/share/doc/fidocadj/
This implies that we also create an "all-doc-linux.tar.gz" for this purpose on
download.sourceforge
Major advantage is that we only need to update the jar and tarballs the user
can even use this script to upgrade as we can make this script to force copy
over existing files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it is best avoid to change the name of the file. In the public_betas/
directory there might be more recent Java archives, but they are preliminary
versions which can be unstable, so it is better that an automatic installer
does not uses them, while always referring to the last stable release.
I reorganized a little bit the directory structure in the SVN repository. If
you want, you might put your installation script in the trunk/OSes/linux
directory. If it is working reliably, I will upload it on SF, but I think it
is better that the name of the tarball contains "linux", such as
FidoCadJ_Linux.tar.gz.
For what it concerns the manuals, I will probably create a subdirectory where
to put them. I recently received a complaint from someone who had some
problems in understanding which files he had to download in order to install
FidoCadJ on his system (Linux Ubuntu). Having too many files might be
confusing for someone, so I will try to keep an eye on that.
Regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The script I'm writing will be complete with command line switches for --help,
--install, --update and --uninstall.
--help is Help of coarse for the script.
--install with a few checks the user must be sudo/root to install it and it
runs checks for dependancies such as wget and java.
--update just fetches the fidocadj.jar, leave this name as it is if this
remains always the latest version.
--uninstall, just removes our stuff, as far as i can tell the installer script
does not hurt any package management system.
The user must always use the --help switch on the first time to see what/how
to do and asks on critical steps for conformation to proceed.
Things to consider is that the script also downloads a tar.gz file containing
the README, VERSION, LICENCE (GPL3-text) and the ready made pdf manuals to be
placed in the folder /usr/share/doc/fidocadj/ which is a common place for
linux users to seek help and docs.
So it ends up that the user downloads and unpacks the fidocadj-
installer.tar.gz, runs the script as root/sudo and the script fetches 3 files
(icon-file,java-file and doc tarball) unpacks these in there appropiate
folders and creates an executable script that runs the jar
I will mail you a beta script from my normal email adress, hope you set the
spam-alarm bells off on me :-)
Regards,
B.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear chokewood,
I correctly received the script. It seems to me to be very nice and useful.
Feel free to put it in the subversion repository in trunk/OSes/linux and do a
commit. I cannot try it on a Linux system because I am using MacOSX which has
a different directory structure, but we can ask to some Linux users to test it
and then I will put it among the distributed files. I have a few remarks.
I see that you use echo -e for supporting the escape control characters. While
I was working to the test scripts (which btw need to be greatly improved), I
did the same, but I noticed that in another computer I have echo -e gave "echo
-e" on the screen, and the escape characters were not recognized but printed
as you type it. I have not investigated the origin of the problem, but I
noticed that using printf instead of echo -e solved the problem. If you have
an idea of why it was not working... I am interested! :-)
I saw in the code an error message: "This Java program requires the graphical
desktop environment" (-e is missing in the echo command?). Well, it depends on
the context, but this is not completely true in general, since FidoCadJ can be
run in headless mode to convert files, to obtain some information on the
drawings and so on. Some servers do that in order to integrate FidoCadJ in
their web sites:
If you type "java -jar fidocadj.jar -h", you will see that there are some
command line options available and some of them do not need a graphical
environment.
It seems to me that your script is a great job.
Best regards and thanks again,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This can happen on systems that have "echo -e" as an alias in there .bashrc or
system wide /etc/bash.bashrc than it generates an extra -e and extra -e gets
merged in the output string. Usage of " alias echo='echo -e' " is a bad
practice in general.
However you got a point there, since it's not the final script i will alter it
to set it as a variable and unset it on exit
catch up with this...
Reg,
B.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"This Java program requires the graphical desktop environment"
Is meant as a stub to stop executing /usr/bin/fidocadj in a non graphical
enviroment as an application when the user is running a real tty session
without running X, but it will execute fidocadj from a terminal emulator from
a GUI environment as usual as this returns "pty(+number)"
This is one of the things I learned in software development that is in basic
a user can do all kinds of stuppid things and as a developer you need to avoid
users of doing stuppid things.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear chokewood,
thanks for the explanation about the echo -e issue. I agree with you, using
this alias seems to be a very bad practice.
For what it concerns the error about the GUI, I propose to give the following
message:
This Java program requires the graphical desktop environment to be used interactively
It might be not very clear (feel free to improve it if you want), but the
second part of the sentence might imply that there is a way of using
FidoCadJ in a non interactive way without needing a GUI.
This is one of the things I learned in software development that is in basic
a user can do all kinds of stuppid things and as a developer you need to avoid
users of doing stuppid things.
LOL! You are right!
Best regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear chokewood,
I saw your commits, very nice work, thanks a lot!
If I understand correctly, you need maindocs.tar.gz to be stored in https://s
ourceforge.net/projects/fidocadj/files/misc/
Would not be easier to download directly the pdf manuals available in https:/
/sourceforge.net/projects/fidocadj/files/manuals/?
This would avoid to replicate essentially the same data which is already
available among the downloadable files. Data replication increases the risk of
confusion when I need to update it.
A second remark is that I see that you are using an "old"-named directory
where you are storing the previous versions of your scripts. From my point of
view, this is not useful since SVN does that for you. BTW, please make use
of the log comments, so please do commits in this way:
svn commit -m "What has been done in this commit."
If you want to keep a track of the development of the scripts, you can use a
NEWS.txt or a development_history.txt file in which you say what you have done
(and possibly the revision number of the SVN repository which correspond to to
the development stage).
If you introduce a command line shortcut to call fidocadj, make sure that the
command can accept the command line options and can be run in headless mode
(i.e. without GUI) in a server. This is quite useful and quite strategical. In
other words, if you call FidoCadJ from the command line with the script
"fidocadj", the following line should show the help mentioned in the manual:
fidocadj -h
I was thinking something about the installer. It would be possible to add a
description (for example in the help screen) where the downloaded files are
put. Nothing more that a simple list. This would make this software more self-
documenting and easier to use. I tried to write something in the commit I just
did, can you please complete and correct it if needed? If you do not like it,
feel free to revert to the previous version (btw, I did not update fidocadj-
installer-linux.tgz).
Another thing I noticed is that if I run the script in my system (where I do
not have wget) I only get an error message and it is not possible to obtain
the help screen, which would help the user understand why the script
absolutely needs wget...
Once again, thanks a lot for the wonderful work you are doing. Once the
scripts are ready, I will put the fidocadj-installer-linux.tgz tarball, as
well as mainshellscript.tar.gz among the downloadable files.
Best regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This Java program requires the graphical desktop environment to be used interactively
See the /usr/share/doc/fidocadj/README on howto run FidoCadj non interactive
Which needs som attention to of coarse. I was thinking of creating a separate
HOWTO setup fidocadj on a webserver as linux is the most likely platform to
use it on a web platform but this is more for the "PHP department".
Also now it gets help form the switch --help and -h out of the fidocadj.jar -h
help function
I noticed something else: If you run FidoCadj as GUI app from the CLI you
cannot load a file into the GUI.
Don't know about Mac but it doesn't work in "That other OS" as well, it would
be very comfortable to get double-click or open with... working.
Will do some follow up on explanations for wget issues..., Welcome to the world of distro differences, yes Ubuntu's don't install wget
by default because it is a "Click here, go there" setup unlike Archlinux which
has a "CLI here, do it right once" approach.
Best regards,
B.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear chokewood,
thanks again for your work.
I think that the launcher script should not process the command line options,
but just pass them to FidoCadJ.
For example, I created another script called fidocadj_alt which is quite
simple and which just launches the software with the command line options
given. For example, I added a few days ago an option useful to specify a given
locale, so someone might find it useful to launch FidoCadJ with the following
command:
./fidocadj -lit
in order to force it to load the italian user interface even where the system
locale is different. This is not something about servers or PHP stuff, this
might be useful to the end user.
I removed the test about the presence of a graphical environment, I am not
sure this is useful and I think Java would be complaining if the user is doing
something stupid. Also, I tried the script with MacOSX, which is a somehow
different environment from Linux, and the test fails even if you can still
launch successfully FidoCadJ from the command line. In my opinion, there is no
need to restrict the usability of the script.
For what it concerns the "launch on the double click" stuff, it is possible
that something is going wrong. What happens exactly in Linux when you double
click on a file with a FCD extension? I mean, what command is executed, and
with which parameters?
Regards,
D.
P.S. once again, please do not forget the "log" stuff when doing commits!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unlike "That other OS" linux looks to the file itself and not to the extention
so a fcd file return "UTF-8 Unicode text" and sets it to the default text
editor changing this behaviour is not that straight foreward we don't want
that linux opens all text files with FidoCadj thats why a mime-type entry must
be made and removed again on un-install
This is work in progress, let you know how we must fix this issue soon
Do we plan to implement more locales with -l option, if so lets consider to
get the locale from the enviroment and automaticly assign this to the -l
option and if unknown default to "en"
updated fidocadj you may remove fidocadj_alt
Regards,
B.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear chokewood,
I think I have not been sufficiently clear in my previous messages.
Do not process FidoCadJ command line options in the launch script. This
is both unnecessary and philosophically wrong. In the FidoCadJ Java code,
there is a certain amount of work and flexibility behind the command line
options and I plan to add new features in the future.
My previous examples about -h and -l were (as I said) just examples, but what
you can do from the command line is more complex. If you want other
information, please refer to the user manual. You can for example measure the
size of a drawing, convert it in a graphical format, specifying some external
libraries to be loaded, while measuring the time needed. I do not think that
the launch script should be touched every time a new command line option is
added to FidoCadJ.
I continue to prefer my version of the launch script, which I consider both
simpler and more reliable.
Best regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear chokewood,
I was having a look at the default.cfg file and I was thinking that for what
it concerns the locale, you probably do not need to store it in the use_locale
variable. In fact, FidoCadJ automatically tries to determine the right locale
and end users seldom need to have to specify it. Specifying a locale different
from the one which is determined by FidoCadJ is useful only when you are in a
peculiar situation in which you want to test or document a certain locale.
Try to keep the things as simple as possible (a.k.a. the simplicity rule:
"Design for simplicity; add complexity only where you must.")
BTW, the install script still refers to files/misc/maindocs.tar.gz; you can
make it point to files/manuals/fidocadj_manual_xx.pdf, where xx might be
automagically determined from the current locale obtained by the scripts. So,
here is a place where you might try to determine the locale in the scripts and
download (if available) the user manual in a language that the user will
surely understand.
Thanks again for your work and best regards,
D.
P.S. Another small detail: the correct way of writing FidoCadJ has the capital
F, the capital C and the capital J.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Quite strange. I see two different problems there:
- the locale is not recognized correctly
- everything is encoded in UTF-8 without BOM, yet the "é" of Bézier is not shown correctly.
If you force the locale to italian, with a lot of accents, or chinese via the
command line (you should probably compile the sources, and create the jar file
in order to do that) , what do you obtain? There is a possibility that I did
some errors while implementing the "-l" option. If you use the 0.24 (stable)
version of FidoCadJ, without any command line option, what do you obtain?
Best regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It happend on 0.24-stable too, that why I made the dutch translation in the
first place.
Did recompile 0.24.1 without the dutch lang file got the same result but now
forcing it to "en" the é than it turns to be out OK.
This is a fallback issue a standard fallback should be "en_US" as this is
standard on linux or any posix compliant system.
I think there is a slight difference between en_GB* and the US variant and I
don't have the GB variant installed.
I'm pretty sure that both the US an GB variants use different layout positions
for uncommon signs.
BTW would it be better to make the -l option -l with a space in between, (to
avoid infile confusion?)
*] and they do drive on the wrong side of the road!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did much rework on the installation script an the main-exec script, tested on
0.24.1 used myown server as temp-download server to do the testing.
Major changes:
added mime-type support
single tar file for the basic skeleton (usr/share/... etc) setup
offers downloaded manual in user language or default english
Main executable script:
Hold on to create an user independant .fidocadj.cfg in the users home folder.
This lets each user on a multi user machine to keep there own locale and java
opts in there own config file
without the need to tamper with the main executable shell script
Regards,
B.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear chokewood,
If the locale is not working as expected, I think this is a real bug, thanks
for pointing it out. Can you please fill a bug report on Sourceforge about it?
BTW, what you see might be depending on a problem depending on a wrong
encoding of the characters, which should be unrelated with the chosen encoding
(and evidently it is not):
I might ask you to perform some tests, but we will continue the discussion
related to this bug on the comments of the bug reports.
I have seen your commits and the install script now seems OK to me. For what
it concerns the launch script, you might proceed as follows:
1- you store in .fidocadj.cfg some command line options which would be used
each time FidoCadJ is launched via the script. In other words, you might
define a variable (such as fidocadj_options) which might be adjusted if the
user has some particular needs.
2- you grap all the command line options, you do not try to parse them, and
you just give them as they are to the FidoCadJ command line just as they are.
The point 1 ensures that you can circumvent the bug you found just by
specifying a given locale via the configuration file.
For example, if you have the following line in the .fidocadj.cfg config file:
fidocadj_options=-lnl
launching the fidocadj script will result in the following command:
In these examples, the -lnl option is not useful nor harmful. It is just
ignored. This feature adds some flexibility which can be useful in some cases.
In the meanwhile, I will try to understand where this bug comes from and
hopefully solve it.
BTW, do not make a commit for every file you modify. You might just edit all
of them, go to the trunk/OSes/linux directory and commit all of them with a
single svn commit -m "some_useful_log" command.
Best regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Did some testing the command you show above launches the gui and does not
export the png img.
however we can add a "fidocadj-cli" that looks in bare metal like this
Dear chokewood,
entia non sunt multiplicanda praeter necessitatem.
I do not see why there is a need to differentiate the command line from the
GUI, when there is the technical possibility of making everything in just one
command... Just respect the standard FidoCadJ behaviour: it is supposed to
know when there is the need of a GUI and when there is not.
Regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear chokewood,
for what it concerns the bug you found, can you please try again on the
version I just committed?
I also have some tests you can possibly do if the problem is not solved.
But in this case, please, fill a bug report and we will continue the
discussion there.
Regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear chokewood,
I saw your commits.
Fine. I uploaded the installer and the main-linux-package.tgz among the
available files. Can you please see if everything works as expected, or if I
forgot something?
I asked to some friends to test the script. When there will be an evidence
that everything is working reliably, I will make the script the default
download for Linux.
In the meanwhile, I will have a look at some Java compiler warnings.
Thanks again and best regards,
D.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Dear all,
this discussion will be devoted to some general issues and points regarding
FidoCadJ with Linux.
Some Linux users complained about a generalized slowness which is not normal
at all. If you understand italian, or if you can access the discussion via an
automatic translator, starting from message there are some timings about Linux
installation:
http://www.electroyou.it/phpBB2/viewtopic.php?f=16&t=36222
In some cases, the option sun.java2d.opengl has an effect, in other cases it
does not changes anything or make the situation worse. Any idea about that?
Regards,
D.
Dear Darwinne and all of you Linux users out there,
Can't say anything about the draggy behaviour on my own box because my
BogoMips go beyond the skies limit.
But a few optimizations can do the trick.
Although some distro's let java run by double clicking them is better to
create a little shell script an put this named as fidocadj in the /usr/bin or
in the /usr/local/bin
Regards,
B.
Proposal,
If we place a latest version as:
An iconfile also on download.sourceforge as fidocadj-128.png
We can create one global linux installation shell script,
called "fidocadj-installer.sh" packed in a tar.gz,
the script should create the following steps:
Create the /usr/share/java/fidocadj/ folder compliant to linux-java
environment.
Fetch the latest jar => /usr/share/java/fidocadj/ and iconfile
Create a menu entry for both Gnome, KDE and any posix compatible desktop
environment. (+ iconfile)
Create create the global shell executable "fidocadj" in /usr/bin/
Optional we can create from a tar.gz file a global doc folder which includes:
all available languages pdf manuals, a "README" plus a "LICENCE" (gpl3 text)
and drop this to:
This implies that we also create an "all-doc-linux.tar.gz" for this purpose on
download.sourceforge
Major advantage is that we only need to update the jar and tarballs the user
can even use this script to upgrade as we can make this script to force copy
over existing files.
Dear chokewood,
what you propose is interesting.
The current policy is to always keep here the last stable version:
I think it is best avoid to change the name of the file. In the public_betas/
directory there might be more recent Java archives, but they are preliminary
versions which can be unstable, so it is better that an automatic installer
does not uses them, while always referring to the last stable release.
I uploaded the 128x128 icon:
I reorganized a little bit the directory structure in the SVN repository. If
you want, you might put your installation script in the trunk/OSes/linux
directory. If it is working reliably, I will upload it on SF, but I think it
is better that the name of the tarball contains "linux", such as
FidoCadJ_Linux.tar.gz.
For what it concerns the manuals, I will probably create a subdirectory where
to put them. I recently received a complaint from someone who had some
problems in understanding which files he had to download in order to install
FidoCadJ on his system (Linux Ubuntu). Having too many files might be
confusing for someone, so I will try to keep an eye on that.
Regards,
D.
Dear chokewood,
I tried to rearrange the file download page in a more rational and self-
explanatory way.
Now, you find the icon there:
If you prepare the Linux install script, can you please write a few lines to
document it in the README and in the user manual?
Regards,
D.
Dear, Darwinne
The script I'm writing will be complete with command line switches for --help,
--install, --update and --uninstall.
--help is Help of coarse for the script.
--install with a few checks the user must be sudo/root to install it and it
runs checks for dependancies such as wget and java.
--update just fetches the fidocadj.jar, leave this name as it is if this
remains always the latest version.
--uninstall, just removes our stuff, as far as i can tell the installer script
does not hurt any package management system.
The user must always use the --help switch on the first time to see what/how
to do and asks on critical steps for conformation to proceed.
Things to consider is that the script also downloads a tar.gz file containing
the README, VERSION, LICENCE (GPL3-text) and the ready made pdf manuals to be
placed in the folder /usr/share/doc/fidocadj/ which is a common place for
linux users to seek help and docs.
So it ends up that the user downloads and unpacks the fidocadj-
installer.tar.gz, runs the script as root/sudo and the script fetches 3 files
(icon-file,java-file and doc tarball) unpacks these in there appropiate
folders and creates an executable script that runs the jar
I will mail you a beta script from my normal email adress, hope you set the
spam-alarm bells off on me :-)
Regards,
B.
Dear chokewood,
I correctly received the script. It seems to me to be very nice and useful.
Feel free to put it in the subversion repository in trunk/OSes/linux and do a
commit. I cannot try it on a Linux system because I am using MacOSX which has
a different directory structure, but we can ask to some Linux users to test it
and then I will put it among the distributed files. I have a few remarks.
I see that you use echo -e for supporting the escape control characters. While
I was working to the test scripts (which btw need to be greatly improved), I
did the same, but I noticed that in another computer I have echo -e gave "echo
-e" on the screen, and the escape characters were not recognized but printed
as you type it. I have not investigated the origin of the problem, but I
noticed that using printf instead of echo -e solved the problem. If you have
an idea of why it was not working... I am interested! :-)
I saw in the code an error message: "This Java program requires the graphical
desktop environment" (-e is missing in the echo command?). Well, it depends on
the context, but this is not completely true in general, since FidoCadJ can be
run in headless mode to convert files, to obtain some information on the
drawings and so on. Some servers do that in order to integrate FidoCadJ in
their web sites:
http://www.electroyou.it/darwinne/wiki/fidocadj-and-
electroyou
If you type "java -jar fidocadj.jar -h", you will see that there are some
command line options available and some of them do not need a graphical
environment.
It seems to me that your script is a great job.
Best regards and thanks again,
D.
Dear Darwinne,
This can happen on systems that have "echo -e" as an alias in there .bashrc or
system wide /etc/bash.bashrc than it generates an extra -e and extra -e gets
merged in the output string. Usage of " alias echo='echo -e' " is a bad
practice in general.
However you got a point there, since it's not the final script i will alter it
to set it as a variable and unset it on exit
catch up with this...
Reg,
B.
Dear Darwinne,
Is meant as a stub to stop executing /usr/bin/fidocadj in a non graphical
enviroment as an application when the user is running a real tty session
without running X, but it will execute fidocadj from a terminal emulator from
a GUI environment as usual as this returns "pty(+number)"
This is one of the things I learned in software development that is in basic
a user can do all kinds of stuppid things and as a developer you need to avoid
users of doing stuppid things.
Dear chokewood,
thanks for the explanation about the echo -e issue. I agree with you, using
this alias seems to be a very bad practice.
For what it concerns the error about the GUI, I propose to give the following
message:
It might be not very clear (feel free to improve it if you want), but the
second part of the sentence might imply that there is a way of using
FidoCadJ in a non interactive way without needing a GUI.
LOL! You are right!
Best regards,
D.
Dear chokewood,
I saw your commits, very nice work, thanks a lot!
If I understand correctly, you need maindocs.tar.gz to be stored in https://s
ourceforge.net/projects/fidocadj/files/misc/
Would not be easier to download directly the pdf manuals available in https:/
/sourceforge.net/projects/fidocadj/files/manuals/?
This would avoid to replicate essentially the same data which is already
available among the downloadable files. Data replication increases the risk of
confusion when I need to update it.
A second remark is that I see that you are using an "old"-named directory
where you are storing the previous versions of your scripts. From my point of
view, this is not useful since SVN does that for you. BTW, please make use
of the log comments, so please do commits in this way:
If you want to keep a track of the development of the scripts, you can use a
NEWS.txt or a development_history.txt file in which you say what you have done
(and possibly the revision number of the SVN repository which correspond to to
the development stage).
If you introduce a command line shortcut to call fidocadj, make sure that the
command can accept the command line options and can be run in headless mode
(i.e. without GUI) in a server. This is quite useful and quite strategical. In
other words, if you call FidoCadJ from the command line with the script
"fidocadj", the following line should show the help mentioned in the manual:
I was thinking something about the installer. It would be possible to add a
description (for example in the help screen) where the downloaded files are
put. Nothing more that a simple list. This would make this software more self-
documenting and easier to use. I tried to write something in the commit I just
did, can you please complete and correct it if needed? If you do not like it,
feel free to revert to the previous version (btw, I did not update fidocadj-
installer-linux.tgz).
Another thing I noticed is that if I run the script in my system (where I do
not have wget) I only get an error message and it is not possible to obtain
the help screen, which would help the user understand why the script
absolutely needs wget...
Once again, thanks a lot for the wonderful work you are doing. Once the
scripts are ready, I will put the fidocadj-installer-linux.tgz tarball, as
well as mainshellscript.tar.gz among the downloadable files.
Best regards,
D.
Dear Darwinne,
Changed the non-interactive msg:
Which needs som attention to of coarse. I was thinking of creating a separate
HOWTO setup fidocadj on a webserver as linux is the most likely platform to
use it on a web platform but this is more for the "PHP department".
Also now it gets help form the switch --help and -h out of the fidocadj.jar -h
help function
I noticed something else: If you run FidoCadj as GUI app from the CLI you
cannot load a file into the GUI.
Don't know about Mac but it doesn't work in "That other OS" as well, it would
be very comfortable to get double-click or open with... working.
Will do some follow up on explanations for wget issues...,
Welcome to the world of distro differences, yes Ubuntu's don't install wget
by default because it is a "Click here, go there" setup unlike Archlinux which
has a "CLI here, do it right once" approach.
Best regards,
B.
Dear chokewood,
thanks again for your work.
I think that the launcher script should not process the command line options,
but just pass them to FidoCadJ.
For example, I created another script called fidocadj_alt which is quite
simple and which just launches the software with the command line options
given. For example, I added a few days ago an option useful to specify a given
locale, so someone might find it useful to launch FidoCadJ with the following
command:
in order to force it to load the italian user interface even where the system
locale is different. This is not something about servers or PHP stuff, this
might be useful to the end user.
I removed the test about the presence of a graphical environment, I am not
sure this is useful and I think Java would be complaining if the user is doing
something stupid. Also, I tried the script with MacOSX, which is a somehow
different environment from Linux, and the test fails even if you can still
launch successfully FidoCadJ from the command line. In my opinion, there is no
need to restrict the usability of the script.
For what it concerns the "launch on the double click" stuff, it is possible
that something is going wrong. What happens exactly in Linux when you double
click on a file with a FCD extension? I mean, what command is executed, and
with which parameters?
Regards,
D.
P.S. once again, please do not forget the "log" stuff when doing commits!
Dear Darwinne,
Unlike "That other OS" linux looks to the file itself and not to the extention
so a fcd file return "UTF-8 Unicode text" and sets it to the default text
editor changing this behaviour is not that straight foreward we don't want
that linux opens all text files with FidoCadj thats why a mime-type entry must
be made and removed again on un-install
This is work in progress, let you know how we must fix this issue soon
Do we plan to implement more locales with -l option, if so lets consider to
get the locale from the enviroment and automaticly assign this to the -l
option and if unknown default to "en"
updated fidocadj you may remove fidocadj_alt
Regards,
B.
Dear chokewood,
I think I have not been sufficiently clear in my previous messages.
Do not process FidoCadJ command line options in the launch script. This
is both unnecessary and philosophically wrong. In the FidoCadJ Java code,
there is a certain amount of work and flexibility behind the command line
options and I plan to add new features in the future.
My previous examples about -h and -l were (as I said) just examples, but what
you can do from the command line is more complex. If you want other
information, please refer to the user manual. You can for example measure the
size of a drawing, convert it in a graphical format, specifying some external
libraries to be loaded, while measuring the time needed. I do not think that
the launch script should be touched every time a new command line option is
added to FidoCadJ.
I continue to prefer my version of the launch script, which I consider both
simpler and more reliable.
Best regards,
D.
Dear chokewood,
I was having a look at the default.cfg file and I was thinking that for what
it concerns the locale, you probably do not need to store it in the use_locale
variable. In fact, FidoCadJ automatically tries to determine the right locale
and end users seldom need to have to specify it. Specifying a locale different
from the one which is determined by FidoCadJ is useful only when you are in a
peculiar situation in which you want to test or document a certain locale.
Try to keep the things as simple as possible (a.k.a. the simplicity rule:
"Design for simplicity; add complexity only where you must.")
BTW, the install script still refers to files/misc/maindocs.tar.gz; you can
make it point to files/manuals/fidocadj_manual_xx.pdf, where xx might be
automagically determined from the current locale obtained by the scripts. So,
here is a place where you might try to determine the locale in the scripts and
download (if available) the user manual in a language that the user will
surely understand.
Thanks again for your work and best regards,
D.
P.S. Another small detail: the correct way of writing FidoCadJ has the capital
F, the capital C and the capital J.
This is the result, my locale is "nl" and FidoCadJ is using default "en" so i
get rubbisch instead of the e acute
Quite strange. I see two different problems there:
- the locale is not recognized correctly
- everything is encoded in UTF-8 without BOM, yet the "é" of Bézier is not shown correctly.
If you force the locale to italian, with a lot of accents, or chinese via the
command line (you should probably compile the sources, and create the jar file
in order to do that) , what do you obtain? There is a possibility that I did
some errors while implementing the "-l" option. If you use the 0.24 (stable)
version of FidoCadJ, without any command line option, what do you obtain?
Best regards,
D.
It happend on 0.24-stable too, that why I made the dutch translation in the
first place.
Did recompile 0.24.1 without the dutch lang file got the same result but now
forcing it to "en" the é than it turns to be out OK.
This is a fallback issue a standard fallback should be "en_US" as this is
standard on linux or any posix compliant system.
I think there is a slight difference between en_GB* and the US variant and I
don't have the GB variant installed.
I'm pretty sure that both the US an GB variants use different layout positions
for uncommon signs.
BTW would it be better to make the -l option -l with a space in between, (to
avoid infile confusion?)
*] and they do drive on the wrong side of the road!
Dear Darwinne,
Did much rework on the installation script an the main-exec script, tested on
0.24.1 used myown server as temp-download server to do the testing.
Major changes:
added mime-type support
single tar file for the basic skeleton (usr/share/... etc) setup
offers downloaded manual in user language or default english
Main executable script:
Hold on to create an user independant .fidocadj.cfg in the users home folder.
This lets each user on a multi user machine to keep there own locale and java
opts in there own config file
without the need to tamper with the main executable shell script
Regards,
B.
Dear chokewood,
If the locale is not working as expected, I think this is a real bug, thanks
for pointing it out. Can you please fill a bug report on Sourceforge about it?
BTW, what you see might be depending on a problem depending on a wrong
encoding of the characters, which should be unrelated with the chosen encoding
(and evidently it is not):
https://sourceforge.net/tracker/?group_id=274886&atid=1167996
I might ask you to perform some tests, but we will continue the discussion
related to this bug on the comments of the bug reports.
I have seen your commits and the install script now seems OK to me. For what
it concerns the launch script, you might proceed as follows:
1- you store in .fidocadj.cfg some command line options which would be used
each time FidoCadJ is launched via the script. In other words, you might
define a variable (such as fidocadj_options) which might be adjusted if the
user has some particular needs.
2- you grap all the command line options, you do not try to parse them, and
you just give them as they are to the FidoCadJ command line just as they are.
The point 1 ensures that you can circumvent the bug you found just by
specifying a given locale via the configuration file.
For example, if you have the following line in the .fidocadj.cfg config file:
launching the fidocadj script will result in the following command:
The launch script must work reliably in the following examples:
Here, the script with the above configuration script will launch the following
commands:
In these examples, the -lnl option is not useful nor harmful. It is just
ignored. This feature adds some flexibility which can be useful in some cases.
In the meanwhile, I will try to understand where this bug comes from and
hopefully solve it.
BTW, do not make a commit for every file you modify. You might just edit all
of them, go to the trunk/OSes/linux directory and commit all of them with a
single svn commit -m "some_useful_log" command.
Best regards,
D.
Dear Darwinne,
Will stick to the BTW
Did some testing the command you show above launches the gui and does not
export the png img.
however we can add a "fidocadj-cli" that looks in bare metal like this
this works.
Its not uncommon for some linux programs to have an (applicationname)-cli
version
Regards,
B.
Dear chokewood,
entia non sunt multiplicanda praeter necessitatem.
I do not see why there is a need to differentiate the command line from the
GUI, when there is the technical possibility of making everything in just one
command... Just respect the standard FidoCadJ behaviour: it is supposed to
know when there is the need of a GUI and when there is not.
Regards,
D.
Dear chokewood,
for what it concerns the bug you found, can you please try again on the
version I just committed?
I also have some tests you can possibly do if the problem is not solved.
But in this case, please, fill a bug report and we will continue the
discussion there.
Regards,
D.
Dear chokewood,
I saw your commits.
Fine. I uploaded the installer and the main-linux-package.tgz among the
available files. Can you please see if everything works as expected, or if I
forgot something?
I asked to some friends to test the script. When there will be an evidence
that everything is working reliably, I will make the script the default
download for Linux.
In the meanwhile, I will have a look at some Java compiler warnings.
Thanks again and best regards,
D.