systemVersion and Linux

[richmond62]

put the systemVersion

returns

Linux 3.5.0-26-lowlatency

on my UbuntuStudio setup

which is not very useful beyond 'Linux'.

Things would be more useful if the Linux family from which a distro is derived were listed (in my case 'Debian')
as different Linux families have different characteristics.

[FourthWorld]

With the shell function you can learn just about any specific details you want, e.g.:

get shell("cat /etc/*-release")

[richmond62]

Indeed:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.10
DISTRIB_CODENAME=quantal
DISTRIB_DESCRIPTION="Ubuntu 12.10"
NAME="Ubuntu"
VERSION="12.10, Quantal Quetzal"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu quantal (12.10)"
VERSION_ID="12.10"

HOWEVER, that means to get system details one has to jump through 2 hoops rather than one:

1. First determine if one is running LInux using systenVersion,

2. Run the shell command.

[wsamples]

It may be even more complicated than that. There are several commands which can be used to return such information, but not all distros offer all of them, and they don't all necessarily return the information in a uniform way. This means you'd have to think hard about which command to use and how you parse the reslut in order to get the information you want. Richard's example "cat /etc/*-release" returns this on my system:

NAME=openSUSE
VERSION="12.2 (Mantis)"
VERSION_ID="12.2"
PRETTY_NAME="openSUSE 12.2 (Mantis) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:12.2"
openSUSE 12.2 (x86_64)
VERSION = 12.2
CODENAME = Mantis

Some other options are:

cat /etc/issue
lsb_release -a
cat /etc/*-version (not available on openSUSE systems)

Getting distro info is something that people ask frequently. You can readily find info on the internet.

What kind of differences are you planning on accommodating? Maybe you'd do just as well checking those scenarios directly?

[richmond62]

I am the developer of 'Devawriter' [ http://andregarzia.on-rev.com/richmond/dwriterpro.html ] which, as yet, is only available for Windows XP and Macintosh.

There are a couple of unfortunate problems delaying a Linux release:

1. Something to do with displaying Unicode text in fields (and I have a solution to this one already).

2. As Macintosh 10 (all versions) has a uniform desktop which features a menubar running along the top of it which is 44 pixels fat, it is dead easy to make sure the Devawriter stack has its top always 45 pixels
from the top of the desktop.

3. As standard Windows XP installs have no menbar at the top of the desktop that is, again, dead easy.

4. Linux distros are, in this case, a pain in the bum. Consider my 2 machines:

4.1. UbuntuStudio 12.10 running XFCE 4.10 with a 32 pixel menubar along the top [which I can remove or expand or contract as many pixels as I like].

4.2. Elementary OS with NO menubars whasoever [ I have mucked it around so that I access everything I need via a 64 pixel Avant Window Navigator dock at the bottom of the screen ].

AND, in my EFL school:

4.3. 8 ill-assorted Pentium 4 machines running a wide variety of Debian derivative distros with a wide variety of window managers hacked about in a variety of ways for the purposes I need them.

SO . . . in an ideal world (cough, cough, cough) information that I would like to have access to on Linux machines really relates to the nature of the end-user's GUI rather than the distro as such.

One thing that would be lovely would be some sort of Livecode thing where one could do something like this:

on openStack
get the usableDesktop
end openStack

but that ain't going to happen anytime soon as far as I can tell; particularly because on Linux there are a plethora of menubars, taskbars and so forth "out there" and Livecode probably cannot be expected to
be able to probe an OS for all of them.

[jacque]

As mentioned on the mailing list, it's already been implemented and the "effective working screenrect" is what you want. It was introduced in LiveCode 5.5.3.

[wsamples]

'effective working screenrect' doesn't quite work reliably under KDE 4.10. It seems to only take into account a panel at the bottom of the screen. The 'effective working screenrect' does not change when I add panels at the top or sides of the screen. If I move my panel from the bottom of the screen to the top, it returns the full screen resolution. The 'effective working screenrect' does respond to changing the height of the bottom panel as well as changing panel visibility settings from "Always visible" to one of the other options.

[mwieder]

get shell("cat /etc/*-release") on my system returns

Fedora release 16 (Verne)
Fedora release 16 (Verne)
Fedora release 16 (Verne)

(yes, that's three times)

and "the effective working screenrects" returns
0,0,1280,800
1280,0,3200,1080
which is the same as "the screenrects".

Just to make sure that "screenrects" doesn't interfere with "screenrect", "the effective working screenrect" returns
0,0,1280,800
which is the same as "the screenrect"

[shaosean]

Does the screenRect update when you make changes to your setup when LiveCode is running? If you add the panels to the sides and then launch LiveCode does it show the correct dimensions?

[wsamples]

Does the screenRect update when you make changes to your setup when LiveCode is running? If you add the panels to the sides and then launch LiveCode does it show the correct dimensions?

There is no need to relaunch LiveCode to register changes made to the bottom panel. No, panels on the top or sides are simply invisible to LiveCode in KDE Plasma Desktop 4.10 on my machine.

[richmond62]

In an ideal world . . . again . . .

. . . no panels or other desktop furniture, regardless of the Windowing environment / Desktop manager, should be invisible to Livecode.

What is needed is a list of desktop managers, their inbuilt panels and so on, other furniture they can sport (docks and so on)
and whether Livecode 'sees' them or not.

I know that Livecode sees AWN when it is at the top of the desktop via "set the top of stack "XXX" to 0, regardless of which desktop environment is being used.

I don't know about things such as Cairo dock.

[wsamples]

A little clarification... setting the top of the stack to 0 does correctly position a window directly under a top located panel here. However, the "effective working screenrect" does not take the height of that panel into account in the result it returns.

[mwieder]

Maximizing a stack (with the maximize button on the title bar) does set the stack's rect to the usable screen space.
Unfortunately, I don't think that's possible from a script. Otherwise you could just say

Code: Select all

function UsableScreenRect
  put the rect of this stack into tSavedRect
  -- maximize this stack
  put the rect of this stack into tUsableScreenRect
  -- restore the stack size
  set the rect of this stack to tSavedRect
  return tUsableScreenRect
end UsableScreenRect