List of those that do . . .
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Livecode Opensource Backer
- Posts: 9454
- Joined: Fri Feb 19, 2010 10:17 am
- Location: Bulgaria
Re: List of those that do . . .
The "thing" is that, on a Macintosh (for the sake of argument) one can spin off a standalone for Windows
and run round the corner to one's friend with a machine running Windows and test it: and either it 'does'
or it 'doesn't', and if it 'doesn't' one has Windows 7, 8 and 10 (obviously someone at MicroSoft central is
missing their 9th finger . . .) to 'keep happy'.
BUT, with the GNU-Linux Pick-N-Mix world one cannot test one's standalone on Fred-round-the-corner's
rig and then cast it out into the wild knowing it will work as one wants on any GNU-Linux system.
- -
This is NOT me being anti-Linux: far from it: the "eco-System" (for want of any other way of describing the thing)
beats the pants off the commonly-tolerated-system as far as I am concerned.
and run round the corner to one's friend with a machine running Windows and test it: and either it 'does'
or it 'doesn't', and if it 'doesn't' one has Windows 7, 8 and 10 (obviously someone at MicroSoft central is
missing their 9th finger . . .) to 'keep happy'.
BUT, with the GNU-Linux Pick-N-Mix world one cannot test one's standalone on Fred-round-the-corner's
rig and then cast it out into the wild knowing it will work as one wants on any GNU-Linux system.
- -
This is NOT me being anti-Linux: far from it: the "eco-System" (for want of any other way of describing the thing)
beats the pants off the commonly-tolerated-system as far as I am concerned.
-
- Posts: 636
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
Re: List of those that do . . .
OK, thanks. Do you have such a work-around you could share?
If it can print to PDF OK, then you could pass that PDF file to CUPS or something to actually send it to the printer.
That reminds me, I've meant to dig out that (HyperCard) stack I made in the mid-90s. It writes raw Postscript language files. That stack then used an XCMD (actually it used quite a few Xternals), that would send the generated .PS file directly to the printer, completely bypassing the Mac Print Dialog, Chooser, and LaserWriter driver itself. I used it for formatting and printing things like generated text reports and "Font specimens" sheets (like the old "FontBook" app that was around at the time).
-
- Posts: 636
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
Re: List of those that do . . .
Right, however IT SHOULD! And I think it could, with the right delivery mechanism. MaxV it seems was going in the right direction for that about 5 years ago when he built .deb / RPM LC Community installer packages here: http://www.maxvessi.net/livecode/linux/richmond62 wrote: ↑Sat Mar 12, 2022 9:46 amBUT, with the GNU-Linux Pick-N-Mix world one cannot test one's standalone on Fred-round-the-corner's
rig and then cast it out into the wild knowing it will work as one wants on any GNU-Linux system.
It seems MaxV also figured out how to make the Browser Widget (used by parts of the IDE) functional on 32bit Linux as well:
Code: Select all
Re: Browser Widget usage examples
Quote
Post by [-hh] » Fri Apr 14, 2017 3:07 pm
Widget usage example #2a: Instructions for making the browser widget usable on linux.
The following removes also some problems on linux with the property inspector, the script editor and the dictionary.
Attached you'll find a stack that does the following interactively in two steps, may you save some time. For 'linux'-people it certainly suffices to read the following once.
____________
Instructions for the uninitiated in an extremely detailed description in case you wish to do it 'manually'. You have to do that ONCE for each LC version.
As example I use LiveCode Indy Edition 8.1.3_32bit
Replace <user> with your_login_name. Some desktop environments (e.g. Cinnamon)
may crash if you try to use tilde (~) for /home/<user>/ in the paths below:
Install LiveCode 'for this user only'.
1) Go to your home folder.
2a) If you cant see the .runrev folder then type ctrl-H.
2b) Open the folder .runrev/components/livecodeindy-8.1.3.x86
3a) RightClick to make a new text document.
3b) Type or paste
CODE: SELECT ALL
#! /bin/bash
export LC_ALL= LC_NUMERIC=C
export LIBGL_DRI3_DISABLE=1
"/home/<user>/.runrev/components/livecodeindy-8.1.3.x86/LiveCode\ Indy.x86"
[Thanks and credit: The above script was elaborated by Max Vessi ('MaxV').]
3c) Save it as "livecode.sh" and make it executable (rightClick: choose properties/permissions/execute).
4) Go to your home folder
5a) open the folder .local/share/applications
5b) RightClick the file "LiveCode Indy 8.1.3" and choose "properties"
5c) Type or paste as command (incl. the quotes):
"/home/<user>/.runrev/components/livecodeindy-8.1.3.x86/livecode.sh"
5d) Choose permissions and check "Execute".
After that launch LiveCode 8.1.3 as usual from the desktop icon or launch bar icon etc.
-
- Posts: 636
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
Re: List of those that do . . .
Right, however IT SHOULD! And I think it could, with the right delivery mechanism. MaxV it seems was going in the right direction for that about 5 years ago when he built .deb / RPM LC Community installer packages here: http://www.maxvessi.net/livecode/linux/richmond62 wrote: ↑Sat Mar 12, 2022 9:46 amBUT, with the GNU-Linux Pick-N-Mix world one cannot test one's standalone on Fred-round-the-corner's
rig and then cast it out into the wild knowing it will work as one wants on any GNU-Linux system.
It seems MaxV also figured out how to make the Browser Widget (used by parts of the IDE) functional on 32bit Linux as well:
Re: Browser Widget usage examples
Post by [-hh] » Fri Apr 14, 2017 3:07 pm
Widget usage example #2a: Instructions for making the browser widget usable on linux.
The following removes also some problems on linux with the property inspector, the script editor and the dictionary.
Attached you'll find a stack that does the following interactively in two steps, may you save some time. For 'linux'-people it certainly suffices to read the following once.
____________
Instructions for the uninitiated in an extremely detailed description in case you wish to do it 'manually'. You have to do that ONCE for each LC version.
As example I use LiveCode Indy Edition 8.1.3_32bit
Replace <user> with your_login_name. Some desktop environments (e.g. Cinnamon)
may crash if you try to use tilde (~) for /home/<user>/ in the paths below:
Install LiveCode 'for this user only'.
1) Go to your home folder.
2a) If you cant see the .runrev folder then type ctrl-H.
2b) Open the folder .runrev/components/livecodeindy-8.1.3.x86
3a) RightClick to make a new text document.
3b) Type or paste
CODE: SELECT ALL
#! /bin/bash
export LC_ALL= LC_NUMERIC=C
export LIBGL_DRI3_DISABLE=1
"/home/<user>/.runrev/components/livecodeindy-8.1.3.x86/LiveCode\ Indy.x86"
[Thanks and credit: The above script was elaborated by Max Vessi ('MaxV').]
3c) Save it as "livecode.sh" and make it executable (rightClick: choose properties/permissions/execute).
4) Go to your home folder
5a) open the folder .local/share/applications
5b) RightClick the file "LiveCode Indy 8.1.3" and choose "properties"
5c) Type or paste as command (incl. the quotes):
"/home/<user>/.runrev/components/livecodeindy-8.1.3.x86/livecode.sh"
5d) Choose permissions and check "Execute".
After that launch LiveCode 8.1.3 as usual from the desktop icon or launch bar icon etc.
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: List of those that do . . .
Paul-
From https://quality.livecode.com/show_bug.cgi?id=21131:
It seems the /tmp/tmpprintfile.ps file is not being created when printing to a physical printer.
If you print to pdf, copy and rename that pdf file into the /tmp directory, then you can print it to the printer because the print command invokes lp properly.
But also see this workaround viewtopic.php?f=7&t=33788&start=30#p189182
From https://quality.livecode.com/show_bug.cgi?id=21131:
It seems the /tmp/tmpprintfile.ps file is not being created when printing to a physical printer.
If you print to pdf, copy and rename that pdf file into the /tmp directory, then you can print it to the printer because the print command invokes lp properly.
But also see this workaround viewtopic.php?f=7&t=33788&start=30#p189182
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- Posts: 636
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
Re: List of those that do . . .
Thank You!mwieder wrote: ↑Mon Mar 21, 2022 5:47 pmPaul-
From https://quality.livecode.com/show_bug.cgi?id=21131:
It seems the /tmp/tmpprintfile.ps file is not being created when printing to a physical printer.
If you print to pdf, copy and rename that pdf file into the /tmp directory, then you can print it to the printer because the print command invokes lp properly.
But also see this workaround viewtopic.php?f=7&t=33788&start=30#p189182
I was able to create an AppImage from my fork of the LCC 9.6.3 Linux 64, I'm not sure exactly how portable it is (have to do some testing now), but it's 1.1GB and it's got chunks-o-Linux (libraries and such) included.
-
- Posts: 636
- Joined: Wed Apr 24, 2013 4:53 pm
- Contact:
Re: List of those that do . . .
OK so now that I have this 9.6.3 based AppImage I've been copying it around to different Linux installs. On a clean install of Xutbuntu 20.xx LTS I noticed that the problem with the message box being unusable / losing focus immediately was happening. This is the same AppImage that I've tested as worked fine on other Installs, so I started to dig in to try figure out this mystery. I thought it might be related to prefs so I reset those, increasing the "tool tip" delay to 9999 milliseconds seemed to slow the problem down.Then I happened to close the Tools palette and the problem went away completely. Reopen the Tools palette and the Message-box becomes unusable again!
Knowing the problem is half the battle right? So I closed the tools palette and in the message box typed: toplevel stack "revTools" and bingo, both message-box and the Tools pallette working normally! Then did: palette Stack "revTools" and the problem came back!
What I take from this, and the fact this problem is non-existent on my Ubuntu Studio install that uses KDE Plasma windowing, is that there is some incompatiblity between LC's 'Palette Stack' window type an the XFCE DE windowing. A fix could be to check for what window manager is being used and then if it's XFCE use 'toplevel stack' instead of 'palette stack' (probably can check/change it in the revIDEPaletteStack handler). There doesn't seem to be any difference, at least visual difference between a "palette" window and regular window on Linux (there's IS actually a system API level difference on macOS) so it could just check 'the platform' and if it's Linux then use 'toplevel' for IDE palettes, The 'cantModify' property is still set and therefore it still behaves as a 'palette' should,
Knowing the problem is half the battle right? So I closed the tools palette and in the message box typed: toplevel stack "revTools" and bingo, both message-box and the Tools pallette working normally! Then did: palette Stack "revTools" and the problem came back!
What I take from this, and the fact this problem is non-existent on my Ubuntu Studio install that uses KDE Plasma windowing, is that there is some incompatiblity between LC's 'Palette Stack' window type an the XFCE DE windowing. A fix could be to check for what window manager is being used and then if it's XFCE use 'toplevel stack' instead of 'palette stack' (probably can check/change it in the revIDEPaletteStack handler). There doesn't seem to be any difference, at least visual difference between a "palette" window and regular window on Linux (there's IS actually a system API level difference on macOS) so it could just check 'the platform' and if it's Linux then use 'toplevel' for IDE palettes, The 'cantModify' property is still set and therefore it still behaves as a 'palette' should,