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

[Lukas F. <fli...@gm...>]

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...> 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...]
> *Sent:* Thursday, August 15, 2019 7:16 AM
> *To:* GLE discussion <glx...@li...>
> *Cc:* Laurence Abbott <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...>
> 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...>
> Department of Chemistry,
> University of York,
> YO10 5DD, UK
> _______________________________________________
> Glx-general mailing list
> Glx...@li...
> https://lists.sourceforge.net/lists/listinfo/glx-general
>