Linux Mint or Linux Ubuntu for Livecode

[mwieder]

Warren, Paul-

Attaching mplayer to at stack using its windowid isn't a problem. The problem is that a video will then take over the entire stack real estate. A player object by itself doesn't have a windowid - it's basically just bitmapped onto the stack. As far as the OS goes, there's no there there.

If you can deal with having the controls on your stack and having videos launching in a separate window centered on your stack then there's a solution. What I'd like, of course, is what bogs tried: set the filename of the player object and use the player controls.

[richmond62]

Frankly, my experience with attempts to play Music or Films with LiveCode
on Linux has just led me to abandon any attempts to get those up and running.

The last time I managed to play sound files on Linux was with RunRev 2 (Free version for Linux) in 2005,
and at that point I had to slow down all the sound files to double length so RR could play them correctly.

[mwieder]

Paul-

lnxmplayer.cpp is the place to start. What LC does is create a new gdk window for the player and remap stdin, stderr, and stdout to the parent stack. This is clever, but the new window's id is not exposed at the scripting level.

The player's windowid could be accessed by
x11::Window t_xid = x11::gdk_x11_drawable_get_xid(m_window);
which would at least solve the problem of gluing the player control to the stack.
But the m_window property isn't exposed publicly and that would require either modifying lnxmplayer.h or more likely a getter function in lnxplayer.cpp to access it.

Update: wait - there *is* a getter function for m_window (getwindow). So maybe it just needs to be elevated to a property of the player control.

[PaulDaMacMan]

Paul-

lnxmplayer.cpp is the place to start. What LC does is create a new gdk window for the player and remap stdin, stderr, and stdout to the parent stack. This is clever, but the new window's id is not exposed at the scripting level.

The player's windowid could be accessed by
x11::Window t_xid = x11::gdk_x11_drawable_get_xid(m_window);
which would at least solve the problem of gluing the player control to the stack.
But the m_window property isn't exposed publicly and that would require either modifying lnxmplayer.h or more likely a getter function in lnxplayer.cpp to access it.

Update: wait - there *is* a getter function for m_window (getwindow). So maybe it just needs to be elevated to a property of the player control.

Interesting, I have yet to even try any LCB on Linux, not even the ones I've already built, the LCB FluidSynth wrapper (which I expect should work), nor the LCB HIDAPI (not so sure about that) ... and I've coincidently just been repurposing the carcasses of some old laptops (early Core i3/i5) for use as set-top-HDTV boxes (Pi3B+ loaner inspired mods).

So the GTK Window LC creates is a separate window entirely? And LC just pipes commands via STDIN/OUT to the mPlayer running in that window?
I think the way LCB widgets work is they have a "native view"port object that's created in the widget's stack window and the widget is drawn into it?
Of course any LCB based solution would exclude the Raspberry Pi due to no Pi ARM LC builds with LCB (8.x+).

Maybe just use Shell() with a CLI to play videos full screen if I want to play videos.
So what do you do? Have a stack with play controls on it but is also transparent on layer above the actual player window?
I'll have to look into the way this works on Linux, I haven't settled on any distros yet.

Patching the player code in the Linux LC engine itself is C++ territory and outa my league.

[PaulDaMacMan]

Maybe libVLC (which has bindings for all sorts of languages already) could be tapped with LCB?
https://wiki.videolan.org/LibVLC/

[bogs]

I may have to revise my recomendation about distro's to run, if your looking to run 9.6.x.

I found all kinds of wierd anomalies trying to use 9.6.2 on it, for instance, the only way I could place a player on a stack was to go to the object menu, for some reason just dragging one off the tool palette didn't work on TDE, KDE Plasma, Gnome, or Cinnamon. Has the basic functionality of the IDE deteriorated that far that simple tasks don't work? That is bizarre.

*Edit 1 - I just answered my own question, kind of. I couldn't drag a player object from the tool palette on Ubuntu using 9.6 either And people wonder why I stick to the older IDEs. Sheesh.

*Edit 2 - I had to drop all the way back to 8.1.10 just to be able to drag a player object off of the tools palette and onto a stack. I haven't run any more rigorous testing than that at this point, but that just blows my mind.

*Edit 3 - after a little more testing (and some hard crashes), It appears that getting the player from the tool palette to the stack was just the beginning of this adventure. I am now all the way down to 8.1.4 in testing. From here to 8.1.10 you *can* drag the player to the stack, but I have been unable to get anything other than the sample movie to play, even changing the source through the property inspector does nothing.

I am through for sure, as I will be starting a new job tomorrow, and will have to concentrate on things other than programming play time. I wish you all the best of luck, and hope that you all keep yourselves well.

[bogs]

Apparently, 7.1.4 is the last version that works as expected (with a player object, can start / stop etc). From 8.x up, not so much. That really is all the time I had to play with this heh, good luck.

[mwieder]

Well, it's been a *long* time since I've had to use the tools palette, but I just pulled PowerTools out of my system to try this out.

Yep.
You can't drag a player control out of the revTools palette the way you can with PowerTools <nudge.wink>
You end up with an error ("Error: can't set this property") trying to set the "mirrored" of the player object in handler revCreateObject of the revidelibrary stack.
And indeed you can't set the mirrored of a player object. Not from the message box either. I guess nobody's tried it recently.
That seems worthy of a bug report.

Here's the error as reported by PowerDebug:

[mwieder]

Bug report filed:
https://quality.livecode.com/show_bug.cgi?id=23252

[bogs]

Nice figuring that one out Mark, I doubt I would have gotten there heh.

Well, it's been a *long* time since I've had to use the tools palette, but I just pulled PowerTools out of my system to try this out.

been probably about that long for me too since I'm usually in Mc, but when I'm testing (as was my intention here) i make sure I'm using a default install without extensions or any enhancements to see what your average "new to Lc" person would see.

Oh well, Try to keep the ship afloat while I'm gone

[AxWald]

Hi,

quick report for Linux Mint 20.1 Mate 64-bit:

Trying to install LC 9.6.2 fails:

Unable to create required folder at '/opt/livecode/ ...'

No matter if for "you only" or "all users". Installing elsewhere (here: '/home/User/Documents') works, though.
Still, having checked "Lauch Livecode" at the end of the installation does nothing.

When started, it freezes when trying to drag a button from the tools palette to a stack window. Trying again, it freezes shortly after dismissing the nag screen (the sad LC beggar doll with the collecting tin) :/

Some days later:
Installing LC 8.1.10 behaves the same as above, only it doesn't freeze when doing something. Seems to work.
Surprise: The previously installed 9.6.2 seems to work now, too :)

Checking Development/PlugIns/GoLiveNet shows a Link of the day: An Unofficial Guide to LiveCode Server
This looks interesting, there's few enough information for LC Server after all! But:

ATBot is not the bot you are looking for.

is the only result ...

This doesn't look good. A curious new potential customer ready to check out the LC promises from the web site may run, screaming.

Hint: Last supported Ubuntu is 16.04 - that's from 2016, and "general support" for it has ended already!

Have fun!

[bogs]

quick report for Linux Mint 20.1 Mate 64-bit:

Trying to install LC 9.6.2 fails:

Unable to create required folder at '/opt/livecode/ ...'

No matter if for "you only" or "all users". Installing elsewhere (here: '/home/User/Documents') works, though.
Still, having checked "Lauch Livecode" at the end of the installation does nothing.

On testing this out, I was unable to reproduce it AxWald, so I have to ask you when you ran the installer, did you remember to run it from either ...

1. the command line using sudo or...
2. the root acount

/opt/ is a system folder, and to write to it requires root or elevated permission. In other words, if you want to install for all users, the easiest way would be from the terminal. Assuming you have made the installer executable, the command should look something like ~



The only way I was able to have the opt folder install fail was when I tried to do it as a regular user.

I also wasn't able to reproduce the button freezing thing, that seemed to work smoothly anyway heh.

[AxWald]

Oh sh...

I was spending the week finishing the installer for my business suite on Windows - so when the task "start an installer" came up I just didn't think of that it's not "me & Win" but "RunRev & Linux".

When I'm on Linux Mate (not often, admitted) I'm so used to be asked for my password over & over I thought it may meanwhile recognize itself when it needs permission, and just ask for ...

And since a LC StandAlone on Windows can care for this comfortably (if the dev thinks about the correct settings), I didn't think that RunRev would make a graphical installer, but then require it's started from the cmd line ...

Why do I need admin permission for "Install for me only" at all? Isn't this strange? Or is is just a wrong path from the installer?

Anyways. About the freezes - well, no idea what it is.
Seems to be gone, now. But I found another funny thing:
First opening of the properties palette displayed it right atop the tools palette. So I dragged it aside. Choosing another properties tab makes it jump back. Ouch.
After some more opening & closing this erratic behavior is gone. The properties palette stays where I put it. Only when I choose the "Effects" tab it jumps back to the last position ... At least it doesn't freeze anymore. :)

Have fun!

[mwieder]

That's definitely bizarre behavior you're running into.

I realize this won't help your situation, but I don't have any of those problems on linux Mint 20.

I stopped installing "for all users" some time ago because I had a boot drive fail a while back and it took the /opt directory with it. Since I'm the only user on my machine installing just for me made sense. Installing and uninstalling for all users requires sudo to gain elevated privileges. That does make sense, but requesting authorization isn't baked into the graphical installer, so it has to be done from a command line. I'm not holding my breath waiting for this to change.

The only thing that comes to mind at the moment is that possibly you still have versions stored in /opt and they're taking precedence over the newly installed versions in your home directory (~/.runrev/components to be exact). Uninstalling has to be done from a commandline and the (un)installer doesn't report if it can't completely remove all components.

...and <sigh> officially the company only "supports" ubuntu 16. The circular reasoning is that there are so many things that don't work on linux they are reluctant to say they support anything modern. For fun, look in quality.livecode.com and search for "linux installer"

[Update]: Also, don't use sudo to install for just a single user. I've been down that road.

[bogs]

Why do I need admin permission for "Install for me only" at all? Isn't this strange? Or is is just a wrong path from the installer?

You don't need admin permissions to install for you only, in this case, the problem was that you were trying to install it into the 'opt' folder. What Mark alluded too was that normally, when you install for "you only", by default the installer will install it to '/home/userName/.runrev/components/LcVersion', which looks like this...



...which you kinda found out for yourself.

...(here: '/home/User/Documents') works, though.

Your 'home' folders you have full access to as a user, but system folders like 'opt' are out of your reach. It makes good sense, if you think about it, you don't want (on a multi user system) Joe Average screwing up the entire system do you? Even on a single user system, it prevents a good deal of the problems that would require a complete reinstall of the OS. Instead, the Root user can simply either fix the problem that user is having, or set up another home directory for them.

As Mark also points out, you don't need to use any elevation (root, sudo, gksu, etc) to install for just you, you can either accept the defaults, or install it anywhere you want in the home directory (custom install).

Btw, if you have one version you use all the time, you don't even have to install it, just copy it to a portable drive and run it from there. I have one version I setup like that with the Lin and Win executable files sitting in the main dir, and I just run it from there. Works a charm, far as I can tell the stack files are the same (although you might have issues with the browser components, which I never use, but it certainly should work up to say 7.1.4).

An alternative would be to copy the folder from windows, and throw the Lin exe in it, since you can't use the browser on Lin anyway hahhah.

The only thing that comes to mind at the moment is that possibly you still have versions stored in /opt and they're taking precedence over the newly installed versions in your home directory (~/.runrev/components to be exact). Uninstalling has to be done from a commandline and the (un)installer doesn't report if it can't completely remove all components.

Not necessarily, all you really have to do is navigate to the folder and hit the '.setup.x86' (older 32 bit versions) or 'setup.x86_64' (64 bit versions) and it will take out all of the install far as I know. Of course, if you *did* install "for all users", you'd need to either launch the file manager with sudo, or switch user to root and launch it from the /opt/ folder.

Once the uninstaller runs out, you can just delete whatever is left if there is anything left, I've only seen it leave something twice, both times it was only a folder.