Linux 'Native' Library

[overclockedmind]

Being a Linux Mint Cinnamon user (I find it to handle better lifting 'in the GUI' than XFCE, YMMV) my second pick is ... XFCE.

If I run XFCE, I'm probably dealing with a machine where I do the multi-GB file copies on the command line, and doing reference with the browser.

Yeah, I know, man progname... OK fine, if I haven't any Internet access.

And man, do I wish someone would update Unstoppable Copier for Linux...

That's where I'll be when Windows 10 support ends, or when I get so upset that I migrate back. One's happening, one sure could, hehe.

[OpenXTalkPaul]

The problems with saying something like 'well just stick the Linux system requirements listed by LC', or saying just target currently popular distros or desktop environments (like XFCE):

The Linux landscape is ever evolving, changes in newer distro releases could break something.
GTK 2 is no longer the standard...What's popular and common in Linuxworld now may not be two years from now.

If you ask 10 Linux users what is the best Linux to use, you'll probably get 10 different answers.

XFCE and other Linux desktops can be installed into most distros to replace the desktop environment. You might only need to switch from Wayland session to X11 session to get something working.

I think it would be more useful to list the DE's and Window Managers or dependencies that the Engine requires to be full functionality or that it has tested OK with or not. I've suggested this before, something like a compatibility list (spreadsheet) should be made.

Its not a waste of time at all for people test this on some 'FrankenlinuxOS' (or some extremely niché OS like Haiku or ReactOS ) , FrankenlinuxOS would be just as usable as whatever-buntu if you knew exactly what packages and things needed to be installed for everything to function.

I still very much like the idea of having 'OXTLinux', a JES distro tailored specifically for running OXT/OXT Lite (and maybe OpenXION too). Building a 'Just Enough OS' requires knowing exactly what 'Just Enough' for the task is, that means having a list of libraries and packages the IDE needs present.
I think I'm going to give Tom Perry's distro a whirl.
Anyway, it's our time to waste.

[overclockedmind]

I'd love, love love to see it in Haiku; I have more than one machine it would absolutely fly on.

And Haiku, in my mind is a single-user OS. A single-user OS with serious speed, serious usability... if I knew of work I could do for them, I'd be doing it after my focus moves from here (which I don't think would be anytime soon, really.)

Also, OXT Lite on my gaming laptop loads in like that-must-not-have-loaded time. I'd wager around five seconds or less the first time I ran it.

i know this has been hashed into the ground, but is there no good QT-esque (lightweight, established in stone) UI library that we could reply upon? [EDIT... Found the Topic] we might have to have it contained within, or Linux might throw a dependency fit. Maybe the installer could download it and stash it in OXT? I know, size size size...

[richmond62]

The problems with saying something like 'well just stick the Linux system requirements listed by LC'

No: that will not do.

However . . . if 5 of us could run OXT? (and that '?' is there because of the toothsucking about what the thing should be called) on a few different flavours (for want of a better word) of Linux, and then state: "Yes", "No", "Mainly . . . but" we can at least issue a list of a few Linux systems the thing DOES run on.

Until recently LC were listing Ubuntu 14. something, which is horribly out of date.

Personally, once I have committed myself to testing OXT? on Xubuntu (my Linux 'Weapon of Choice'), I shall issue a "Yes", "No', or "Mainly . . . but" as each new version of Xubuntu becomes available (they generally have a new version twice a year: April and October): this commitment does not strike me as particularly onerous.

From a selfish point of view this suits me extremely well, as the machines I use to teach xTalk to Primary children run Xubuntu: in fact I just upgraded them to last October's offering yesterday.

[overclockedmind]

The problems with saying something like 'well just stick the Linux system requirements listed by LC'

No: that will not do.

However . . . if 5 of us could run OXT? (and that '?' is there because of the toothsucking about what the thing should be called) on a few different flavours (for want of a better word) of Linux, and then state: "Yes", "No", "Mainly . . . but" we can at least issue a list of a few Linux systems the thing DOES run on.

Until recently LC were listing Ubuntu 14. something, which is horribly out of date.

Personally, once I have committed myself to testing OXT? on Xubuntu (my Linux 'Weapon of Choice'), I shall issue a "Yes", "No', or "Mainly . . . but" as each new version of Xubuntu becomes available (they generally have a new version twice a year: April and October): this commitment does not strike me as particularly onerous.

From a selfish point of view this suits me extremely well, as the machines I use to teach xTalk to Primary children run Xubuntu: in fact I just upgraded them to last October's offering yesterday.

I can let you know what it does in Linux Mint, Cinnamon... it'll take a bit.

[richmond62]

What would be extremely helpful is if someone 'professional' : Paul, Terry, Tom? were to assemble a proper "shopping list" for testers to work through.

[OpenXTalkPaul]

What would be extremely helpful is if someone 'professional' : Paul, Terry, Tom? were to assemble a proper "shopping list" for testers to work through.

Doesn't require a 'professional', and I'm not a professional programmer. This requires testers to test various distros and report the results to a central location where it can be formed into a useful Distro compatibility list.

Note: I just finished edited my last comments from last night because I had fallen asleep while editing it,

[richmond62]

Doesn't require a 'professional', and I'm not a professional programmer.

One thing I have never quite worked out is what constitutes a "professional programmer": but, certainly something more than Richmond who knocks up bits-n-bobs for his EFL school, and a couple of things for digitisation of long-dead languages. AND, No: I am not fishing for compliments.

In 2002 I worked with a music teacher in Scotland on a CD for Macintosh and Windows called 'Listen Hear', using RunRev 2.0.1.
-

81rXDP6d3zL._AC_SX679_.jpg (23.33 KiB) Viewed 5465 times

-
That's the 4th edition: I worked on the DUD 2nd edition: after the 1st edition: written with HTML (by the music teacher himself) proved a non-starter.

He provided the music segments; the texts were provided by 2 music teachers from Dundee: and I did the programming.

I wrote a list of things to look out for for Beta testers. The person who employed me (the music teacher) said he saw no reason for any beta testers: and when I told him that, as I had programmed the thing entirely on my own there were bound to be bugs in it, he laughed.

He then spent a lot of money having 5,000 of the DCs made, complete with fancy cases and so on.

The first school, who purchased a dozen of the discs, then reported a problem where, with one particular card, Windows locked up!

The music teacher blamed me: unfortunately for him, the code was examined by a company in Edinburgh (no, not our friends) who stated that, considering no Beta testing had taken place it was amazing there was only one bug in the whole thing, and that he was gyte for not having taken my advice to have it Beta tested: he lost about £15,000 ONLY because he did not Beta test the thing. I ended up getting NO money for all my 6 month's work.

As I had been hired to make the thing in RunRev I was able to run up a "shopping list" of about 25 possible problems for Beta testers to look for: that man's objections were: it would delay release of the CD, and that he would have to pay the Beta testers.

HOWEVER, as OXT Lite (or 'Heavy') is Open Source we don't, of course, have to get quite as sweaty under the oxters, but it still might be good to have some guidance, not just for Thee and Me, but for any users who decide to try/work with the thing, as to what they should look out for: and, as well, a sensible way to report any glitches they find.

[OpenXTalkPaul]

I wonder if we could get some sort of (probably php based) bug tracking system (bugzilla) going on our own site.

Someone should look into what's involved with that. We do have GitHub repo which allows for comments/reporting from other users. I haven't been using GitHub as much as I should lately.

[richmond62]

Would be a good idea.

Why do I think that FourthWorld might know all about that sort of stuff?

Comments of the type: "The colours in the Dictionary are a bit off." on these forums are likely to get either lost or disregarded.

[FourthWorld]

Why do I think that FourthWorld might know all about that sort of stuff?

If that stuff refers to bug reporting, I prefer Bugzilla but GitHub's is quite popular and already available.

If stuff refers to HaikuOS, I love the idea but can't imagine committing the resources to a port. All of the things that made BeOS exciting, and lamentable for not being picked as the successor to Mac OS when the Board went with NeXT, also make it a unique developer experience, for which relatively little tooling and expertise is available.

[tperry2x]

There is this list of known issues already:
https://www.openxtalk.org/forum/viewtopic.php?f=8&t=610

However, what I'd really appreciate - if someone finds a bug, to have a go fixing it and then paste what they've done in the bugs fixed category. We can all learn / improve bits that way.

https://www.openxtalk.org/forum/viewforum.php?f=9

[overclockedmind]

Why do I think that FourthWorld might know all about that sort of stuff?

If that stuff refers to bug reporting, I prefer Bugzilla but GitHub's is quite popular and already available.

If stuff refers to HaikuOS, I love the idea but can't imagine committing the resources to a port. All of the things that made BeOS exciting, and lamentable for not being picked as the successor to Mac OS when the Board went with NeXT, also make it a unique developer experience, for which relatively little tooling and expertise is available.

Completely expected, and honest answer. Thank you.

[OpenXTalkPaul]

I have often though about if one couldn't wrap all of the libraries that are part GNUStep (CoreFoundation) for different platforms and use that same wrapper module to do cross-platform 'Native' UI widgets on all the desktop OSes, using Extension Builder wrapped Objective C objects and so much of the same code for such a module would theoretically work across the platforms GNUStep can run on. It would use Cocoa when on macOS of course. Much of GNUStep (the FOSS NeXTstep OpenStep APIs) has intentionally maintained some parity with Apple's APIs but with different underlying implementations. CoreFoundation stuff NSFileManager, NSObject, NSWindow, NSButton, etc.

If I was going to try to port the engine to another OS entirely (which is currently the furthest from my mind) it would be for BSD distros, FreeBSD, OpenBSD, OpenIndiana/Solaris?). I would think that could be done with relatively minimal changes, because as understand it the Engine did run on UNIX OS'es such as Solaris back when it was called MetaCard.

Going Off-Topic further....
I don't know much about BeOS, I gave it a whirl when it was a candidate for the future of Mac OS. I gave HaikuOS a try maybe 5 or 6 years ago. I know a lot of creative media types liked BeOS, but I don't remember anything standing out as great or unique features, of course I never got that into it either so maybe I didn't dig deep enough?

[tperry2x]

In the LC User guide documentation, UNIX is mentioned a lot. Unless there's some wires crossed over the differences between Linux and Unix, testing would indicate that Unix support is less than brilliant currently.

[richmond62]

Way back in the days of Metacard there was a Linux executable and a UNIX executable, which is rather suggestive.

RunRev/LC have made all sorts of claims over the years: often about marginal cases, possibly knowing that the chance of anyone taking them at their word is . . .

[richmond62]

I will get an Easter holiday, and I could pull my finger out to install some sort of UNIX on one of the 12-20 PCs I have clogging up the school now I have installed ACEPC mini machines.

Ah: Easter round these parts is 5 May this year.

[overclockedmind]

At one point, Mach and its components were fully POSIX-compliant, true-blue certified Unix.
I couldn't tell ya about now.

Aside: https://hellosystem.github.io/docs/
It's in its infancy, but it rings all the right bells for me. Don't know squat regarding driver availability, probably the same boat as the BSDs (Linux having way more drivers for way more things.)

[OpenXTalkPaul]

At one point, Mach and its components were fully POSIX-compliant, true-blue certified Unix.
I couldn't tell ya about now.

Aside: https://hellosystem.github.io/docs/
It's in its infancy, but it rings all the right bells for me. Don't know squat regarding driver availability, probably the same boat as the BSDs (Linux having way more drivers for way more things.)

Yes! I love that project, so much that I even did a little work on some icons for it. It's by the dude that created the .AppImage format for Linux App portability (which was in part inspired by Apple .app bundle format).

[OpenXTalkPaul]

I guess no one really tried this out, or if they did they didn't mention to me that it was broken on Linux.
I developed and tested this with GTK2 on the macOS ( GTK is a cross-platform toolkit), and so the library names it binds to were the Mac versions (x-quartz) of GTK2, therefore it didn't work on Linuxes. I did have the correct names for the Lunx versions of GTK in binding strings, but those lines were commented out (because I was using mac instead), this version of the wrapper has both mac and Linux binding strings, with the mac handlers renamed to begine with GTKmac_...

Code: Select all

widget org.openxtalk.gtkbtn

--- some of these '#includes' are probably are not needed
	use com.livecode.canvas
	use com.livecode.widget
	use com.livecode.engine
	use com.livecode.foreign
   use com.livecode.arithmetic
   use com.livecode.array
   use com.livecode.assert
   use com.livecode.binary
   use com.livecode.bitwise
   use com.livecode.byte
   use com.livecode.char
   use com.livecode.codeunit
   use com.livecode.date
   use com.livecode.file
   use com.livecode.java
   use com.livecode.list
   use com.livecode.logic
   use com.livecode.math
   use com.livecode.mathfoundation
------------------------------------------

	metadata title is "GTK Btn (testing)"
	metadata author is "Paul McClernan for OpenXTalk"
	metadata version is "1.0.0"
	metadata platforms is "desktop,mobile"

--- If the module makes use of external code that is only
--  available on specific Operating Systems or Platforms, use the "os"
--  and/or "platforms" metadata keys.
-- code/x86-linux/library.so
-- code/x86_64-linux/library.so

--- The key piece of syntax for creating widgets that hook into native view objects is `my native layer`:
--- set my native layer to mNativeView
private variable mNativeLayer as optional Pointer
// Store references to both the plug and button
private variable mPlug as optional Pointer
private variable mNativeView as optional Pointer
private variable mGTKBtn as optional Pointer

--- When using a native layer, a widget's `OnPaint` handler is not called. However it is recommended to provide some sort of
--- placeholder `OnPaint` method to represent the widget when the native layer is not supported on the current platform.
--- It is not yet possible to write a fully functional native widget on Linux, as there are some issues with event handling and focus. This will be addressed in future releases.
--- Native views on Linux are `GtkPlug`s. A `GtkSocket` is used internally to render the view from the process in which it is running. In most instances you will want to embed a `GtkWidget` in a `GtkPlug`.
-- The following snippet shows how to bind to `gtk_button_new_with_label`, and use it to set the native layer to a suitable gtk plug id:
--  Bind to various useful functions in libgtk.
--- We need to create a GTK plug, and GTK button, add the button to the plug and then show them.

foreign handler GTK_PlugNew(in pType as CUInt) returns Pointer binds to "c:libgtk-x11-2.0.so>gtk_plug_new"
foreign handler GTKmac_PlugNew(in pType as CUInt) returns Pointer binds to "c:libgtk-quartz-2.0.dylib>gtk_plug_new"

foreign handler GTK_ButtonNewWithLabel(in pLabel as ZStringNative) returns Pointer binds to	"c:libgtk-x11-2.0.so>gtk_button_new_with_label"
foreign handler GTKmac_ButtonNewWithLabel(in pLabel as ZStringNative) returns Pointer binds to	"c:libgtk-quartz-2.0.dylib>gtk_button_new_with_label"

foreign handler GTK_ContainerAdd(in pContainer as Pointer, in pWidget as Pointer) returns nothing binds to "c:libgtk-x11-2.0.so>gtk_container_add"
foreign handler GTKmac_ContainerAdd(in pContainer as Pointer, in pWidget as Pointer) returns nothing binds to "c:libgtk-quartz-2.0.dylib>gtk_container_add"

foreign handler GTK_WidgetShow(in pWidget as Pointer) returns nothing binds to "c:libgtk-x11-2.0.so>gtk_widget_show"
foreign handler GTKmac_WidgetShow(in pWidget as Pointer) returns nothing binds to "c:libgtk-quartz-2.0.dylib>gtk_widget_show"

-- The actual native layer will be set to the plug id
foreign handler GTK_PlugGetId(in pPlug as Pointer) returns Pointer binds to "c:libgtk-x11-2.0.so>gtk_plug_get_id"
foreign handler GTKmac_PlugGetId(in pPlug as Pointer) returns Pointer binds to "c:libgtk-quartz-2.0.dylib>gtk_plug_get_id"

--- Event callbacks are pretty simple on Linux, as you can pass a (foreign) handler into `g_signal_connect_data` directly:
-- Define the callback foreign handler type
foreign handler type ClickCallback(in pWidget as Pointer, in pContext as optional Pointer) returns nothing

-- Bind to g_signal_connect_data to connect a foreign handler to a gtk signal
foreign handler GTK_SignalConnect(in pObj as Pointer, in pEvent as ZStringNative, in pHandler as ClickCallback, in pData as optional Pointer, in pNotify as optional Pointer, in pFlags as CUInt) returns CULong binds to "c:libgtk-x11-2.0.so>g_signal_connect_data"
foreign handler GTKmac_SignalConnect(in pObj as Pointer, in pEvent as ZStringNative, in pHandler as ClickCallback, in pData as optional Pointer, in pNotify as optional Pointer, in pFlags as CUInt) returns CULong binds to "c:libgtk-quartz-2.0.dylib>g_signal_connect_data"

--- Properties of Linux native views can be set using the GTK Widget API.
--- For example, to hook up the enabled property of a Linux button (called "_sensitive_" in the GTK API):
foreign handler GTK_WidgetSetSensitive(in pWidget as Pointer, in pValue as CBool) returns nothing binds to "c:libgtk-x11-2.0.so>gtk_widget_set_sensitive"
foreign handler GTKmac_WidgetSetSensitive(in pWidget as Pointer, in pValue as CBool) returns nothing binds to "c:libgtk-quartz-2.0.dylib>gtk_widget_set_sensitive"

foreign handler GTK_about_dialog_get_version() returns Pointer binds to "c:libgtk-x11-2.0.so>gtk_about_dialog_get_version"
foreign handler GTKmac_about_dialog_get_version() returns Pointer binds to "c:libgtk-quartz-2.0.dylib>gtk_about_dialog_get_version"

public handler OnOpen()
 	unsafe
	put CreateNativeView() into mNativeLayer
	set my native layer to mNativeLayer
	 end unsafe
end handler

public handler OnCreate()
-- unsafe
	-- variable tStrinPtr as optional Pointer
   ---	put CreateNativeView() into mNativeLayer
	-- put gtk_about_dialog_get_version() into tStrinPtr
	-- log [tStrinPtr]
	-- set my native layer to mNativeLayer
	-- end unsafe
end handler

public handler OnClose()
	unsafe
	set my native layer to nothing
	put nothing into mNativeLayer
	end unsafe
end handler

private handler CreateNativeView() returns Pointer
	unsafe
		// Create a new default plug
		put GTK_PlugNew(0) into mPlug
		log ["Plug",mPlug]
		// Create a button with empty label
		put GTK_ButtonNewWithLabel("TEST BUTTON") into mGTKBtn
		log ["Button",mGTKBtn]
		GTK_WidgetSetSensitive(mGTKBtn, true)
		GTK_SignalConnect(mGTKBtn, "clicked", OnButtonClick, nothing, nothing, 0)

		// Add the button to the plug
		GTK_ContainerAdd(mPlug, mGTKBtn)

		// Ensure both button and plug are visible
		GTK_WidgetShow(mGTKBtn)
		GTK_WidgetShow(mPlug)

		// Return the plug window id
		return GTK_PlugGetId(mPlug)
	end unsafe
end handler

private handler SetNativeLayer() returns nothing
	unsafe
		set my native layer to CreateNativeView()
	end unsafe
end handler

public handler OnButtonClick(in pWidget as Pointer, in pContext as optional Pointer) returns nothing
	unsafe
      log [pWidget,pContext]
		// The widget scriptObject will receive the posted message
		post "mouseUp"
		-- 're-arm' the button ????
		-- This doesn't seem to work, the button is click-able once and only once for some reason currently unknown to me:                                                                                                                                                                                                                                                              		GTK_WidgetSetSensitive(mGTKBtn, true)
		GTK_SignalConnect(mGTKBtn, "clicked", OnButtonClick, nothing, nothing, 0)
      GTK_WidgetShow(mGTKBtn)
		GTK_WidgetShow(mPlug)
		set my native layer to mNativeLayer
	end unsafe
end handler

// Actual handler that will be called when the button is clicked
public handler SignalConnect(in pButtonView as Pointer) returns nothing
	unsafe
	// Connect the foreign handler to the clicked signal. All other
	// parameters are empty/default
	GTK_SignalConnect(mGTKBtn, "clicked", OnButtonClick, nothing, nothing, 0)
	end unsafe
end handler

private handler SetEnabled(in pButtonView as Pointer) returns nothing
	unsafe
	GTK_WidgetSetSensitive(mGTKBtn, true)
	-- GTK_WidgetSetSensitive(mGTKBtn, my enabled)
	end unsafe
end handler

end widget