Re: [fpc-pascal] Freevision etc.
On 04/05/17 20:30, Mark Morgan Lloyd wrote: The record that Dialedit generates to represent initial or extracted dialogue box values has alignment and/or packing problems. There's a comment in the source that the FreeVision sources expect dwords while the author using a debugger believed that words were correct. I was able to get things working adequately by assuming that the correct type for a RadioButton was a byte, and that the CheckBoxes the followed it were..., well something larger but I'm still not sure what. In case anybody ever digs more deeply into Dialedit, I've got dialogs working fairly well by making sure that LineEdit controls have strings that are multiple of 8 bytes (i.e. lengths 15, 31 and so on). RadioButtons values appear to be a byte, CheckBoxes possibly a word. Working on ARM, i386, x86_64; part-working on SPARC which I think indicates an endianness issue somewhere, untested on PPC and MIPS. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freevision etc.
On 04/05/17 11:30, Mark Morgan Lloyd wrote: Is anybody currently using Freevision dialog(ue)s? I've got some very odd problems transferring initial values onto the screen and getting stuff back, at least some of which appears to be platform-specific (comparing x86_64, i386 and arm, all Linux). For example, the checkboxes in a group appear to be numbered $10, $20 instead of $01 etc., and I've not yet found how to interface with radiobuttons: only 0 works. The record that Dialedit generates to represent initial or extracted dialogue box values has alignment and/or packing problems. There's a comment in the source that the FreeVision sources expect dwords while the author using a debugger believed that words were correct. I was able to get things working adequately by assuming that the correct type for a RadioButton was a byte, and that the CheckBoxes the followed it were..., well something larger but I'm still not sure what. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freevision etc.
On 2017-05-04 13:52, Michael Van Canneyt wrote: > All this fails if the needed libraries are not available You are indeed correct of course. Below is the output as seen on a server that has no X11 related libraries installed. $./osmail -h Shared object "libXft.so.2" not found, required by "osmail" $ Having two binaries also has other benefits. Your "launch binary" can do checks for a GUI environment, but it can also be used for over-the-wire binary updates. eg: You can't overwrite a running binary under Windows, but with a two binary setup the update can be done before launching the real application executable. Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freevision etc.
On Thu, 4 May 2017, Graeme Geldenhuys wrote: On 2017-05-04 13:21, Mark Morgan Lloyd wrote: text-mode console or over something really crude like telnet... and I hope you're doing that for fpGUI since you keep telling us how good it is :-) As I said, I do that often in my own (and commercial) applications that use fpGUI. The fpGUI framework itself also has some extra checks in to see if a GUI environment is available, and will exit gracefully with a error message if such an environment doesn't exist. All this fails if the needed libraries are not available, and they are compiled in statically for X. home: >ldd fpguidemo linux-vdso.so.1 => (0x7fffbfbdb000) libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6 (0x7ff823a12000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7ff8236d8000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7ff8234c5000) libXft.so.2 => /usr/lib/x86_64-linux-gnu/libXft.so.2 (0x7ff8232b) libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1 (0x7ff82306d000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7ff822e68000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7ff822a9f000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7ff822885000) libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x7ff82265f000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7ff82243d000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x7ff822233000) libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x7ff822009000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7ff821dec000) /lib64/ld-linux-x86-64.so.2 (0x562638a98000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7ff821ae3000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7ff8218de000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7ff8216d8000) We have lots of headless server instances where the X libs are simply not installed. So the binary will not even start, and there will be no fallback to text either. The only solution for this situation are 2 binaries. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freevision etc.
On 2017-05-04 13:21, Mark Morgan Lloyd wrote:
> text-mode console or over something really crude like telnet... and I
> hope you're doing that for fpGUI since you keep telling us how good it
> is :-)
As I said, I do that often in my own (and commercial) applications that
use fpGUI. The fpGUI framework itself also has some extra checks in to
see if a GUI environment is available, and will exit gracefully with a
error message if such an environment doesn't exist.
The usual remote functionality of X11 also works perfectly with fpGUI
applications. ie: run a app here, but it displays on a different server.
> initialisation block, but it would mean splitting out e.g. text-mode
> --help and graphics-mode --about into separate places.
With my applications, I normally implement a reusable initialize.inc
file which sits before the fpgApplication.Initialize() call.
This include file does command line parameter handling and in case of
database applications, initialised tiOPF for me. When it comes to
command line parameters, I check if I need to handle anything (eg: -h or
--help) then do a IF IsConsole THEN ELSE and that is it. Quite
simple.
Here is the code for the application output I showed earlier.
// Help
if gCommandLineParams.IsParam(['h', 'help']) then
begin
if IsConsole then
begin
writeln(Format(cAppNameFormatStr, [ApplicationName,
cMajorVersion, cMinorVersion, uiVersionBuild, cBuildVersion]));
writeln('Compiled on ' + cCompileDateTime);
writeln('');
writeln('The following parameters are available:');
writeln('');
writeln(' h, helpShows this help');
writeln(' lc Logs debug information to the
console');
writeln(' lv Logs debug information to a visual
screen');
writeln(' ls Logs debug information to debug
server');
writeln(' l Logs debug information to a file');
writeln(' style Applies a custom style to the
application. Available');
writeln(' options are: ' +
fpgStyleManager.StyleTypesAsString);
writeln('');
writeln('NOTE: This program requires a graphical windowing
environment to function.');
Exit;
end
else
begin
fpgApplication.Initialize;
tiShowString(
Format(cAppNameFormatStr, [cAppName, cMajorVersion,
cMinorVersion, uiVersionBuild, cBuildVersion])
+ LineEnding + 'Compiled on ' + cCompileDateTime
+ LineEnding + ''
+ LineEnding + 'The following parameters are available:'
+ LineEnding + ''
+ LineEnding + ' h, helpShows this help'
+ LineEnding + ' lc Logs debug information to the
console'
+ LineEnding + ' lv Logs debug information to a
visual screen'
+ LineEnding + ' ls Logs debug information to
debug server'
+ LineEnding + ' l Logs debug information to a file'
+ LineEnding + ' style Applies a custom style to the
application. Available'
+ LineEnding + ' options are: ' +
fpgStyleManager.StyleTypesAsString
, 'Quick Help', False);
fpgApplication.Run;
Exit;
end;
end;
// activate application logging code here
// apply user defined fpGUI style here
// activate tiOPF initialisation code here
Regards,
Graeme
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/
My public PGP key: http://tinyurl.com/graeme-pgp
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freevision etc.
On 04/05/17 12:00, Graeme Geldenhuys wrote: On 2017-05-04 12:03, Mark Morgan Lloyd wrote:>> I've not used Freevision/Turbovision before, but am experimenting with>> James Clarke's DialEdit as an experiment to see whether I can create a>> fallback user interface for use if an interactive program is running in>> a shell session. The Lazarus side of things isn't a problem, I know from>> the past how to break out before the GUI is initialised and so on.> I was mistaken, this can't be done easily so there's no advantage in > trying to build a single program for both GUI and text modes.> And it wouldn’t be right if I didn’t offer up an alternative. Agreed, such as --help or --version output. However it looks as though it's important to check anything that attempts this on e.g. the system text-mode console or over something really crude like telnet... and I hope you're doing that for fpGUI since you keep telling us how good it is :-) So as you can see, what you want to do is possible. Maybe LCL just needsmore work around its initialization code - being less eager toinitialize its GUI. ;-) I think it could probably be done by slipping a unit in just before cthreads, provided that this terminated aggressively. That's actually less intrusive that the editing I've been doing in the .lpr initialisation block, but it would mean splitting out e.g. text-mode --help and graphics-mode --about into separate places. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freevision etc.
On 2017-05-04 12:03, Mark Morgan Lloyd wrote: >> I've not used Freevision/Turbovision before, but am experimenting with >> James Clarke's DialEdit as an experiment to see whether I can create a >> fallback user interface for use if an interactive program is running in >> a shell session. The Lazarus side of things isn't a problem, I know from >> the past how to break out before the GUI is initialised and so on. > I was mistaken, this can't be done easily so there's no advantage in > trying to build a single program for both GUI and text modes. > And it wouldn’t be right if I didn’t offer up an alternative. fpGUI based applications can indeed do what you want. I do this all the time for command line handling. If a GUI program is run from a terminal (no X11 server), it will still output to the console telling the user what program it is, version info, command line parameters and importantly, that it requires a GUI to function. In a GUI environment (eg: MS Windows) it will display a dialog with all the same information, if the -h command line parameter was passed in. Here is such output of one of my programs (run from the login terminal - no X11): === $ ./osmail -h Opensoft Mail & News v1.00 (build 18) Compiled on 2017/05/01 11:09:41 The following parameters are available: h, helpShows this help lc Logs debug information to the console lv Logs debug information to a visual screen ls Logs debug information to debug server l Logs debug information to a file style Applies a custom style to the application. Available options are: "auto", "Win2000", "Motif", "Carbon", "Plastic Dark", "Plastic Dark Gray", "Plastic Medium Gray", "Plastic Light Gray" NOTE: This program requires a graphical windowing environment to function. $ === So as you can see, what you want to do is possible. Maybe LCL just needs more work around its initialization code - being less eager to initialize its GUI. ;-) Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freevision etc.
On 13/04/17 10:00, Mark Morgan Lloyd wrote: I've not used Freevision/Turbovision before, but am experimenting with James Clarke's DialEdit as an experiment to see whether I can create a fallback user interface for use if an interactive program is running in a shell session. The Lazarus side of things isn't a problem, I know from the past how to break out before the GUI is initialised and so on. I was mistaken, this can't be done easily so there's no advantage in trying to build a single program for both GUI and text modes. My first problem is that there's a name clash between the Freevision and LCL variants of some units. With two separate programs this ceases to be a problem, Lazarus or a straight FPC compilation works. Is anybody currently using Freevision dialog(ue)s? I've got some very odd problems transferring initial values onto the screen and getting stuff back, at least some of which appears to be platform-specific (comparing x86_64, i386 and arm, all Linux). For example, the checkboxes in a group appear to be numbered $10, $20 instead of $01 etc., and I've not yet found how to interface with radiobuttons: only 0 works. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Freevision etc.
On 13/04/17 10:00, Mark Morgan Lloyd wrote:
My first problem is that there's a name clash between the Freevision and
LCL variants of some units. I appear to be able to use something like
uses Objects, Views in
'/usr/local/lib/fpc/3.0.2/units/arm-linux/fv/views', Dialogs in
'/usr/local/lib/fpc/3.0.2/units/arm-linux/fv/dialogs';
but is it possible to do something like setting up an alias for that
directory name which will track versions etc.? I'd prefer to not assume
that there's any predictable relative positioning of the source and unit
directories.
I've got something working after a fashion, but had to make a local copy
of FreeVision with some changed unit names to avoid clashes with stuff
from the LCL. I'd appreciate any insights on how to do the job properly.
My second problem is that the Pascal file generated by the dialogue
editor gives me something like
{ TBDTestBlockDeviceDialogue }
typePTBDTestBlockDeviceDialogue = ^TTBDTestBlockDeviceDialogue;
TTBDTestBlockDeviceDialogue = object(TTestBlockDeviceDialogue)
constructor Init;end;
and it's unclear where the TTestBlockDeviceDialogue type is defined.
I'm pretty sure that's a bug in the dialog editor.
If I can get this working I'm hoping to make the source available as a
demonstrator somewhere, so I'd very much appreciate suggestions which
would make this happen.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
