Hi listers,

I am blind and I would like to program graphical interfaces in Freepascal. Perhaps, it sounds a little bit curious. Being blind, would I have interest in graphical interfaces? As the subject can be new for many of then, I will explain in detail what I really want.

Blinds have been programming for decades. In seventies, they have done it by means of braille lines, special hardware wich allows blind people to touch in an board and read the contents projected there. Afterwards, with the appearance of screen readers, the work has become much easier.

Elder blind programmers have produced codes for console. However, screen readers, nowadays, interact more efficiently with graphical interfaces. So, if I want to program for blind people, I need to use graphical interfaces.

But, being blind, can I program graphical interfaces? yes, but not using tform. And being blind, is it really useful to learn programming? Yes, there is a large number of blind programmers and, about acessibility subjects, they are the worriest, the most interested in promote it.

Some requirements need to be present in order to allow blind programmers to do it:

1. Accessible - Screen readers can announce all the contents shown.

2. Programable - A blind person can produce all the code needed to shown the windows and its objects.

3. Multiplataform - Blinds in Windows and Linux can access and program with the chosen interface.

Now, I present a list of interfaces and the way they fulfill these requirements:

1. tform - it fulfills the items 1 and 3. A blind person cannot program it. At first, because Lazarus environment is not accessible and a blind people prefer to use only hard code without move objects on a form. Secondly, even we adopt hard code, it's not possible to program using tform without writing codes like: button1.left := 30. The way blind people can program is not based on coordenates or dimensions, but in the automatic layout management.

2. TK - It fulfills 2 and 3. As it's not based on native components and use extensively Canvas Draw, the result is that screen readers can't interact with then.

3. GTK - In Linux, all the requirements are fulfilled and a blind program can use it. We can produce codes without indicating even one dimension or one coordenates. GTK is based on containers, so we can imagine the abstract realationsship among objects and build interfaces. Beautiful interfaces? Certainly not. However, this isn't the proposal. I can use graphical interfaces to ease the interaction with screen readers, not to present wonderful looks. If a label doesn't have enough space to receive the text, the screen reader only will read the visible words. So, although the interface won't be seen by the users, they must be organized sufficiently to allow the correct performance of screen readers.

4. FPGUI - It fulfills 1 and 3. As tform, it's coordenate based in stead of container based.

5. QT - It fulfills 2 and 3. As TK, it's not based in native components, so it inaccessible for screen readers in both systems: Windows and Linux.

6. HTML - Of course, it fulfills all the requirements in both systems. However, it's not the more suitable interface for desktop programming. In spite of that, it can be regarded as an option.

7. IUP - It fulfills all the requirements. Previous experiences using Lua and IUP, graphical tool kit developed by brazilian reseachers, shows excelent results. Graphical interfaces can be created by blind programmers, without any coordenate, using only containers. The work can be done as in Windows as in Linux. IUP seems to be the perfect solution.

However, IUP was not ported to Object Pascal and, having contacted the developers, he said this won't be done. The alternative could be to translate the C headers of IUP, producing the respective units Pascal. I have tried to do it using H2pas. But after the process, the unit contained errors. And the correction of these errors would probably require a large background in C programming.

Finally, I ask: does someone have an idea what can I do? Does someone know other interfaces container based compatible with Pascal? If I decided to port IUP to Pascal, wich kind of knowledge should I have?

IUP is available for C and Lua programmers. Perhaps, adopting C or Lua I could obtain earlier results. Yes, I regard seriously it. But if the investment was not endless, I prefer to look for a Pascal solution. If I am successful in my project, I will write a manual for blind programmers.

Regards,

Luciano de Souza

Hello FPC,

Monday, October 25, 2010, 7:12:25 PM, you wrote:

lds> 1. tform - it fulfills the items 1 and 3. A blind person cannot lds> program it. At first, because Lazarus environment is not accessible lds> and a blind people prefer to use only hard code without move objects lds> on a form. Secondly, even we adopt hard code, it's not possible to lds> program using tform without writing codes like: button1.left := 30. lds> The way blind people can program is not based on coordenates or lds> dimensions, but in the automatic layout management.

Using a TForm you can program based in a containers style using alignment and anchors (advanced anchoring, not the Delphi one).

So you can insert a panel with aligment top, and autosize on, now add a label with a caption and autosize on, now add a textbox to input data and anchor it to the left of the label and to the top of the label, so if your label is bigger the textbox is moved to the right.

It is not exactly the same as GTK or other container oriented interfaces but it is doable.

Anyway this should be more Lazarus/LCL related.

It's really interesting. After looking for so libraries, it would be fantastic to find a solution with tform. But, regarding everything needs to be created only writing codes, without opening the inaccessible interface of Lazarus, do you believe can it be done?

I give you an example using Lua.

require('iuplua')

label1 = iup.label{title = 'This is the text of label 1'} button1 = iup.button{title = 'Button 1')
button2 = iup.button{title = 'Button 2')
button3 = iup.button{title = 'Button 3')
list1 = iup.list{'Option 1', 'Option 2', 'Option 3'; multiple = 'NO', dropdown = 'YES', value = 2}

box = iup.vbox
{
iup.hbox{label1; border = 'NO'},
iup.hbox{list1; border = 'NO'},
iup.hbox{button1, button2, button3; border = 'NO'} }

dlg = iup.dialog{box; title = 'Example of IUP library', gap = 5, size = 'HALFxTHIRD'}
dlg:showxy(iup.CENTER, iup.CENTER)
iup.MainLoop()

function button1:action()
return iup.CLOSE
end

This code defines a pannel with a vertical box in wich is set three horizontal boxes. The first one, with a label, the second, with a combobox, and the third with three buttons. Some attributes were defined and a callback for button1 click is also defined. And everything only typing codes.

This is only an example. A sintax for C is also available and if it was ported to Pascal, certainly the C sintax would prevail.

My question is: is it possible to create all the interface with tform without using the Lazarus interfaces, in other words, only typing codes in a text editor?

2010/10/25, Josι Mejuto :

2010/10/25 luciano de souza :

[snip] My question is: is it possible to create all the interface with tform without using the Lazarus interfaces, in other words, only typing codes in a text editor?

Yes, but you will write more in Pascal than with IUP.

Marcos Douglas

2010/10/25 luciano de souza

Yes, everything you can do in the form designer can be done in code too.

Take a look at all examples in lazarus\examples, (but not in the subdirectories) that don't use the form designer.

All the other examples could be converted to code-only, without .lfm file created by the designer.

Vincent

Marcos, it's not exactly a problem. My example in Lua is supplied only to show the hard code styly needed to my targets.

Even if more code is required, it's always possible to enclose the complexity in classes. I really like Pascal and I expect to find a solution using only Pascal.

I don't know how to test this idea. What is the best reference for tform?

I use Ubuntu 10.04 and FPC 2.4.0. To install Lazarus, is it sufficient to do "sudo apt-get install lazarus", after uninstalling FPC?

Vincent, You got the point. When I came across LFMs, I thought a hard code focus could not be used.

But, I can imagine another problem. Lazarus interface is unbelievably worse. So I would like to compile my projects only doing: fpc project.pp. Using this method, could I link with all units? Some time ago, I tried to compile a Lazarus project in the command line. However, almost all declared units couldn't be found.

Sorry for the excessive quantity of questions, but the subject is really new for me. I want to take a direction.

2010/10/25, Vincent Snijders :

2010/10/25 luciano de souza

That is possible, but you have to add some lcl paths to the command line options.

Sorry for the excessive quantity of questions, but the subject is really new for me. I want to take a direction.

These kind of questions are better answered on the lazarus mailing list. For more information, see:
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus

Vincent

2010/10/25 luciano de souza:

Finally, I ask: does someone have an idea what can I do? Does someone know other interfaces container based compatible with Pascal?

I much prefer code based designing compared to Visual Form Designing. In a similar way you can compare OpenOffice or MS-Office to LateX - where the latter does the whole layout for you, and quite offen a much better end result too. Anyway, fpGUI's Visual Form Designer actually generates code, not lfm files. But yes, it does use coordinates at the moment, so that is not suitable. Good news is that the fpGUI Form Designer was simply a stop gap even for myself. I much prefer a layout manager style of programming. I have already started work on that too, but it's not complete yet. It will take a few months to finish (I can't work on it full time yet). I am porting the MiG Layout Manager from Java to Object Pascal. This layout manager is brilliant, and very flexible. You also only need to learn one layout manager, not several like GTK, Qt or the standard Java layout manager. MiG Layout is capable enough to handle all designs by itself.

For more details on MiG Layout you can visit: http://www.miglayout.com

As for using screen readers. I have only tried them a few years back. I'll update my Ubuntu with them and try a few to see if they work with fpGUI - I have no idea what is required from a GUI framework to work with a screen reader.

I'll get back to you on this.

Regards,
  - Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net:8080/fpgui/

The include files look rather simple so far. The errors might be because of the many #define in the header files, but those could be converted manually as well. I'll try to test some of the files with h2pas by myself and see what the errors are. Then I can give you the needed knowledge for corrections, so that you can finish the headers yourself. :)

Do you want to use version 2 or 3 of IUP?

Regards,
Sven

IUP 2.x are not compatible with screen readers. The reason is the excessive usage of Canvas Draw. I did a large number of tests with IUP and Lua and I can assure IUP 3.1 and 3.2, the last version, are very good so in Linux as in Windows. For this reason, I would like to translate IUP 3.2.

Yes, we can find lots of "define", but I find a problem seeming to be more complicated.

See this declaration in C:

ihandle* IupVbox(ihandle *child, ...)

IupVbox is a vertical container wich can encompass several objects, so it's not possible to know how many arguments it will contain.

Here, an example in C. If a translation of IUP is done, the sintax will be similar.

#include <iup.h>

int main(int argc, char **argv)
{
ihandle button1, button2, button3, label1, hbox1, vbox, dlg;

IupOpen();
// Creating the controls
button1 = IupButton();
button2 = IupButton();
button3 = IupButton();
// Setting their attributes
IupSetAttribute(button1, "TITLE", "Button 1");
IupSetAttribute(button2, "TITLE", "Button 2");
IupSetAttribute(button3, "TITLE", "Button 3");
// Packing the controls into a vertical box
hbox1 = IupHbox(button1, button2, button3, null);
vbox1 = IupVbox(Iuplabel("Label 1"), hbox1, null);
// Building the window
dlg = IupDialog(vbox1);
IupSetAttribute(dlg, "TITLE", "Program for test");
IupShowXY(dlg, iup_CENTER, iup_CENTER);
IupMainLoop();
IupClose();
return 0;
}

This is a simple example. Using templates in LED (Dialog Specification Language) and other IUP features, we can reduce the quantity of code and become easier the assignment of attributes.

But you can see. "..." in C, defining a variable number of arguments is something complicated. In Pascal, we probably work with arrays. I don't know how to translate it.

Is it simple? As I told you, IUP would be the best solution since I understand it.

2010/10/26, Sven Barth :

Ok, then I'll concentrate on IUP 3.

Ok... you can translate this with FreePascal, but you must do it by hand (so you need to comment (//...) the functions in the C header).

Here's the translation (I herby assume that a type "Pihandle = ^ihandle" and a constant "libiup='libiup.so'" are defined):

Variant a:

Declaration:
function IupVbox(child: Pihandle; args: array of const): Pihandle;
cdecl; external libiup;
Calling:
IupVbox(Iuplabel("Label 1"), [hbox1, Nil]);

Variant b:

Declaration:
function IupVbox(child: Pihandle): Pihandle; cdecl; varargs; external
libiup;
Calling:
IupVbox(Iuplabel("Label 1"), hbox1, Nil);

The compiler won't do any checks on the arguments.

See also:
http://www.freepascal.org/docs-html/ref/refsu74.html#x159-16600011.9.16

Regards,
Sven

2010/10/26, Sven Barth :

I understand. After running H2pas, I had erros in all rows with "array of const". The arguments are not constants indeed. They are ihandle or pihandle as the first one is. So but when I use varargs probabibly all the arguments have the same type: pihandle. I believe the second alternative will compile.

I didn't know varargs. It's a nice feature! I will try to compile with these tips and I come back with the results.

2010/10/26, luciano de souza :

The difference between "array of const" and "varargs" (in external cdecl declarations) is
a) the way you call them (with "[...]" or without) b) that you will see in the declaration that you are able to pass additional arguments in the case of "array of const".

So I personally prefer the "array of const" notation, but they are semantically the same in this case.

Btw: "array of const" normally means a "generic" type and is used by e.g. the Format function.

See here for additional information:
http://www.freepascal.org/docs-html/ref/refsu58.html#x138-14500011.4.6

I didn't know varargs. It's a nice feature! I will try to compile with these tips and I come back with the results.

There are many nice gems in Free Pascal... one just needs to find them :D

Regards,
Sven