Re: [GLE-general] Problems with QGLE on windows 10

[LaBella, V. <vla...@su...>]

I have several features in mind.  However I think we should just focus on getting the current code base building with the most up to date libraries and save the features for later.

One thing I had in mind was a SQL adaptor so gle could pull data from a database using a sql query.

Vincw


________________________________
From: Lukas Flierl <fli...@gm...>
Sent: Saturday, August 17, 2019 10:25 AM
To: GLE discussion
Subject: Re: [GLE-general] Problems with QGLE on windows 10

Hi Vincent,

what do you have in mind when you are talking about new features?
I personally had some ideas for new subs, like a P&ID sub, but I don't if there is a need for it.
 Best,
Lukas



LaBella, Vincent <vla...@su...<mailto:vla...@su...>> schrieb am Sa., 17. Aug. 2019, 00:42:
All:

It’s great to see a good discussion on GLE.  I use it in my group extensively here and teach all my grad students to use it.  They all find it to be the best plotting program out there.  I surveyed my faculty here on what plotting program they use once and they all use something different (mostly GUI).   And I don’t really see any other language to switch to. I teach basics of GLE plotting at my group meeting and one of my 300 level courses.  Some pick it up and some don’t.  Those that do love it.

I also use it in my intranet.  I have a WAMP server which dynamically generates the GLE code to display figures.  The student’s can then download the GLE script and data file and modify if needed, or simply copy and paste the PNG file into their PPT presentation.  I wrote a PHP class that helps with all this – I should put it on the web site…

GLE needs some updating and these are my thoughts:


1.       64 bit compilation

2.       QT5

3.       Improved site

4.       Bug fixes

5.       New features

I think 1, 2, and 3 should be a priority right now and I am happy to tackle item 1.  I want to use cmake.  I have been using it extensively for some other cross platform projects and I have a build farm setup to do win/mac/linux (Ubuntu 18x64).  So I could crank out the binaries when needed. Note that compiling for 64 bit may introduce some headaches and will need some testing but to priority is having it search for 64 bit gs and 64 bit latex. The cmake build scripts won’t interfere with the current build scripts so builders can choose which system they want to use.  In the long run cmake will be easier to maintain for cross platform builds.

Best regards,

Vince



From: Laurence Abbott via Glx-general [mailto:glx...@li...<mailto:glx...@li...>]
Sent: Thursday, August 15, 2019 7:16 AM
To: GLE discussion <glx...@li...<mailto:glx...@li...>>
Cc: Laurence Abbott <lau...@yo...<mailto:lau...@yo...>>
Subject: Re: [GLE-general] Problems with QGLE on windows 10

I'm loving that there is still interest in GLE!

:-)

On Thu, 15 Aug 2019 at 12:00, Francois Tonneau <fra...@gm...<mailto:fra...@gm...>> wrote:
A few belated comments --

1. About QGLE: I am on Debian (minimal netinst) and I could never run QGLE successfully, it always complains about not finding a Ghostscript library. This is a mismatch between ghostcript versions, QGLE looks for an older version of ghostscript than the one installed on current Debian. I guess I could fix this by downgrading my ghostscript libraries to older versions but I never went through the trouble. I think of GLE as basically a command-line application, no need for a gui.

I got qgle to work on debian (admittedly, self built rather than packaged qgle) by maually locating ghostscript as: /usr/lib/x86_64-linux-gnu/libgs.so.9

Having said that, it still falls over randomly (with ghostscript 9.27). This seems to be because of API changes that appear with this version. Quoting from https://www.ghostscript.com/doc/current/History9.htm:

the changelog for 9.27 includes:
"Incompatible changes
The process of "tidying" the Postscript name space should have removed only non-standard and undocumented operators. Nevertheless, it is possible that any integrations or utilities that rely on those non-standard and undocumented operators may stop working, or may change behaviour.

If you encounter such a case, please contact us (either the #ghostscript IRC channel, or the gs-devel mailing list would be best), and we'll work with you to either find an alternative solution.

One case we know this has occurred is GSView 5 (and earlier). GSView 5 support for PDF files relied upon internal use only features which are no longer available. GSView 5 will still work as previously for Postscript files. For PDF files, users are encouraged to look at MuPDF."

So it looks like they broke gsview with their changes too! By the sounds of it, we're using something that is undocumented or non-standard with the gs API.

The only gs calls I can find are in src/gui/glegs.cpp, src/gui/qgs.cpp and src/gui/qgslibloader.cpp so it might not be too bad to check them off against any API changes. (I might try to look over the weekend to see if anything jumps out.)

Another thing that is a little annoying under windows is that gle is only available as 32 bit and so needs 32-bit ghostscript. I had the 64-bit version of ghostscript available nicely packaged by my institution but had to go install the 32-bit version "by hand" (requiring elevated privileges).

It's a while since I've built anything under windows so I don't know whether it's simply a compiler switch to generate 32- or 64-bit code, or whether it's a lot more involved than that.

Cheers,

Laurence
--
Dr Laurence Abbott <lau...@yo...<mailto:lau...@yo...>>
Department of Chemistry,
University of York,
YO10 5DD, UK
_______________________________________________
Glx-general mailing list
Glx...@li...<mailto:Glx...@li...>
https://lists.sourceforge.net/lists/listinfo/glx-general