Easiest way to build Qt/Gtk interfaces for Ada programs

Easiest way to build Qt/Gtk interfaces for Ada programs

[alb348]

I am a interested in creating GUI applications with Ada, using either Qt or Gtk (it must be one of these two, because these are the only toolkits that provide full BiDi support).
I was happy to find that the Ada bindings are available for both Qt and Gtk, but I was disheartened when I saw the code of the example programs. Lots of code! Lines and lines of dense code, barely comprehensible. Honestly, I don't know if I would be able to write a GUI by manually writing so much code.

My question is: is there any GUI builder, either for Qt or for Qt, which will allow me to graphically design the widgets, and which will then generate Ada code?
If not, what would be the easiest way to create the Qt/Gtk interfaces I need and use them in Ada? (I dread having to write everything manually!)

Thanks

Alby

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Dmitry A. Kazakov]

On Fri, 28 Dec 2012 06:51:01 -0800 (PST), alb348@gmail.com wrote:

> I am a interested in creating GUI applications with Ada, using either Qt
> or Gtk (it must be one of these two, because these are the only toolkits
> that provide full BiDi support).

One important thing, which implies the obvious consequences. There is no
easy way of building GUI as well as no way of adding GUI to an existing
application.

Ignoring casual applications, it is unfortunately so, that whatever
framework you use, and what the application is supposed to do functionally,
you have to build it around the GUI.

> I was happy to find that the Ada bindings are available for both Qt and
> Gtk, but I was disheartened when I saw the code of the example programs.
> Lots of code! Lines and lines of dense code, barely comprehensible.
> Honestly, I don't know if I would be able to write a GUI by manually
> writing so much code.

It is only the tip of the iceberg. When you start writing a real-life GUI
the amount of code explodes. In order to maintain the complexity you need
to refactor and reuse, start building customized widgets on top of the
existing ones etc. Much of software design, not easy, not very rewarding,
because the code still looks ugly, but at least becomes a bit maintainable.

> My question is: is there any GUI builder, either for Qt or for Qt, which
> will allow me to graphically design the widgets, and which will then
> generate Ada code?

Wasting time, but you won't believe me anyway. So take any, it is actually
no matter. Once you have it behind you, you can make a fresh start and
begin working productively.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[alb348]

>> My question is: is there any GUI builder, either for Qt
>> or for Qt, which will allow me to graphically design the
>> widgets, and which will then generate Ada code?

> Wasting time, but you won't believe me anyway. So take 
> any, it is actually no matter. Once you have it behind
> you, you can make a fresh start and begin working 
> productively.

Could you please elaborate a little as to why, in your opinion, GUI builders are a waste of time? Is it because the quality of the generated code is unsatisfactory? Or because they are too complex to use?

Also, in case I decide to write all the GUI code manually, which path do you advise me to take: Gtk or Qt? (I only need basic edit windows, dialogs and forms). And are there good tutorials that explain how to do it in an easy way?

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Dmitry A. Kazakov]

On Fri, 28 Dec 2012 09:30:04 -0800 (PST), alb348@gmail.com wrote:

>>> My question is: is there any GUI builder, either for Qt
>>> or for Qt, which will allow me to graphically design the
>>> widgets, and which will then generate Ada code?
> 
>> Wasting time, but you won't believe me anyway. So take 
>> any, it is actually no matter. Once you have it behind
>> you, you can make a fresh start and begin working 
>> productively.
> 
> Could you please elaborate a little as to why, in your opinion, GUI
> builders are a waste of time? Is it because the quality of the generated
> code is unsatisfactory? Or because they are too complex to use?

Because it is impossible to separate GUI from functional code, especially
when the GUI uses low-level libraries not written in Ada. Even if the
library were written in Ada, I doubt that a decent GUI builder would be
possible to make. You should ask Randy, who is an author of Claw.

The only purpose a builder might have (apart from casual applications) is
for creating a prototype for the customer, and for later, as a kind of
specification for the production GUI.

> Also, in case I decide to write all the GUI code manually, which path do
> you advise me to take: Gtk or Qt? (I only need basic edit windows, dialogs
> and forms). And are there good tutorials that explain how to do it in an
> easy way?

AFIAK, both frameworks are more or less equivalent in their capacities [and
ugliness]. You should probably toss a coin.

I don't advocate for Gtk, I took Gtk simply because AdaCore did and because
there always has been some shadow of suspicion regarding Qt licensing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Yannick Duchêne (Hibou57)]

Le Fri, 28 Dec 2012 16:32:09 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Fri, 28 Dec 2012 06:51:01 -0800 (PST), alb348@gmail.com wrote:
>
>> I am a interested in creating GUI applications with Ada, using either Qt
>> or Gtk (it must be one of these two, because these are the only toolkits
>> that provide full BiDi support).
>
> One important thing, which implies the obvious consequences. There is no
> easy way of building GUI as well as no way of adding GUI to an existing
> application.
>
> Ignoring casual applications, it is unfortunately so, that whatever
> framework you use, and what the application is supposed to do  
> functionally,
> you have to build it around the GUI.

On the opposite, this is the least recommended way to do. One should  
create the UI around the application. The cleanest in my opinion, is to go  
for a Model View Presenter (MVP), preferably with a passive view. The  
presenter is the glue between the application and the view, and is also a  
model of the view's behaviour. The view, if passive, only receive display  
request, along with the data (which it does not fetch itself, to be  
independent from the application), and transmit events and user gestures  
to the presenter. This has some advantages, including easier separate  
design and easier testing (if the communication between the presenter and  
the view is correctly specified before).

The hard part is the presenter, but the UI may be an hard part too, if you  
have ergonomic requirements. The UI may be made of anything, and has its  
own and separate specification. The presenter is less independent, and is  
related to the application. You have to figure a way to setup a  
communication channel between all three parts: between the application and  
the presenter (both way), and between the UI and the presenter (both way  
too).

See: http://martinfowler.com/eaaDev/ModelViewPresenter.html
Note: according to Martin Fowler, the “Model View Presenter” designation  
may not be relevant, but that term is still widely used, so many people  
understand it. He himself designate it under the term of “Supervising  
Controller and Passive View” instead.

> There is no easy way of building GUI

That part still remains true, and is not just applicable to UI alone.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Dmitry A. Kazakov]

On Sat, 29 Dec 2012 01:18:34 +0100, Yannick Duch�ne (Hibou57) wrote:

> Le Fri, 28 Dec 2012 16:32:09 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a �crit:
> 
>> Ignoring casual applications, it is unfortunately so, that whatever
>> framework you use, and what the application is supposed to do  
>> functionally, you have to build it around the GUI.
> 
> On the opposite, this is the least recommended way to do. One should  
> create the UI around the application. The cleanest in my opinion, is to go  
> for a Model View Presenter (MVP), preferably with a passive view.

In order to deploy MVC, you must make your application providing the "M" in
the MVC (model). The application must be designed with this in mind. This
is why you build it around the GUI.

You don't own the main task it will belong to the GUI. You have to design
all vital data structures as models compatible to the GUI framework at
hand. You have to place inspection/rollback/abort check points in all
lengthy operations to be able to add progress bars, cancel buttons etc. You
have to rework all tasks making them compatible to single-threaded GUI,
preventing events floods, event generators, deadlocking in signal handlers.
You have to decide polling vs. event-driven policies along the M-V path and
design the tasks involved correspondingly. And so on and so forth. And you
honestly believe in a tool which would allow you to do all this lazily
dragging and dropping icons? I don't.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Yannick Duchêne (Hibou57)]

Le Sat, 29 Dec 2012 10:26:04 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:

> On Sat, 29 Dec 2012 01:18:34 +0100, Yannick Duchêne (Hibou57) wrote:
>
>> Le Fri, 28 Dec 2012 16:32:09 +0100, Dmitry A. Kazakov
>> <mailbox@dmitry-kazakov.de> a écrit:
>>
>>> Ignoring casual applications, it is unfortunately so, that whatever
>>> framework you use, and what the application is supposed to do
>>> functionally, you have to build it around the GUI.
>>
>> On the opposite, this is the least recommended way to do. One should
>> create the UI around the application. The cleanest in my opinion, is to  
>> go
>> for a Model View Presenter (MVP), preferably with a passive view.
>
> In order to deploy MVC, you must make your application providing the "M"  
> in
> the MVC (model). The application must be designed with this in mind. This
> is why you build it around the GUI.
May be not: what about substituting “GUI” to “service interface”? The  
application may be better designed in term of what you can get from it and  
what you will feed it with. Can designate it as an abstract interface,  
perhaps.

> You don't own the main task it will belong to the GUI.
Not necessarily. With MVP (which is not the same as MVC), the presenter  
starts everything (it is the supervisor), and it's the presenter which own  
the main task, and it it may launch the application and the UI as two  
others distinct tasks.

> You have to design all
> vital data structures as models compatible to the GUI framework at
> hand.
You may do this way, while you are as much free to adapt the UI to an UI  
specification, a specification which specify a human interface to a  
computation or service interface.

> You have to place inspection/rollback/abort check points in all
> lengthy operations to be able to add progress bars, cancel buttons etc.
You may, if you designed the application. But you may as much have to add  
an interface to an already existing application which does not provide  
these facilities. In which case, the presenter will either not provide any  
progress data, or else will fake it or try to guess or derive it. Same  
comments for inspection, undo/redo, and others. I know that's bad, but  
that happens, and even if that features are suggested by what a user  
expects from an UI, these are not UI features, these are application  
features. The UI is just an interface to what the application provides.  
The application may be required to provide such features, but it don't do  
so to please the UI, it do so by specification, to please the user (which  
may not be human, by the way).

> You
> have to rework all tasks making them compatible to single-threaded GUI,
> preventing events floods, event generators, deadlocking in signal  
> handlers.
With the MVP, that's the presenter's job (it is the middle man responsible  
for the coordination and interpretations). As above, things may differs  
depending on whether or not you are giving an UI to an application  
designed with a good interface in mind or not. Sometime, it is not.

> You have to decide polling vs. event-driven policies along the M-V path  
> and
> design the tasks involved correspondingly.
In MVP with a passive view, there is no direct path from the model to the  
view. All paths, from the model to the view and the reverse, pass through  
the presenter (which is responsible for the interpretation of user  
gestures to the model and for the model states to the view).

> And so on and so forth. And you
> honestly believe in a tool which would allow you to do all this lazily
> dragging and dropping icons? I don't.
Me neither. But a tool can help in designing the UI, proper, as a  
standalone specific component.

I know my comments does not help a lot, and above all does not offer any  
magic recipes, I'm sorry for that :P . I also guess the MVP may not looks  
so much appealing at first sight, as it requires more work (and in some  
context, like the web, it may present challenges with communication and  
separation); but the benefit is to be more solid and more composite.  
Visiting Fowler's website (or getting a copy of its book), will learn  
more. I won't tell more on the topic (which may be subjective), and first  
wanted to give this pointer to prospective people.

Also, may be there's some confusions between application interface and  
user interface in this topic (some comments make me feel that; see above).  
I indeed tend to be disappointed with entanglement of applications matters  
and UI matters, at least as seen in some open‑source software (try to  
fix/update one, and you break the other, the same with understanding how  
it works).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Dmitry A. Kazakov]

On Sat, 29 Dec 2012 11:39:08 +0100, Yannick Duchêne (Hibou57) wrote:

> Le Sat, 29 Dec 2012 10:26:04 +0100, Dmitry A. Kazakov  
> <mailbox@dmitry-kazakov.de> a écrit:
> 
>> On Sat, 29 Dec 2012 01:18:34 +0100, Yannick Duchêne (Hibou57) wrote:
>>
>>> Le Fri, 28 Dec 2012 16:32:09 +0100, Dmitry A. Kazakov
>>> <mailbox@dmitry-kazakov.de> a écrit:
>>>
>>>> Ignoring casual applications, it is unfortunately so, that whatever
>>>> framework you use, and what the application is supposed to do
>>>> functionally, you have to build it around the GUI.
>>>
>>> On the opposite, this is the least recommended way to do. One should
>>> create the UI around the application. The cleanest in my opinion, is to go
>>> for a Model View Presenter (MVP), preferably with a passive view.
>>
>> In order to deploy MVC, you must make your application providing the "M" in
>> the MVC (model). The application must be designed with this in mind. This
>> is why you build it around the GUI.

> May be not: what about substituting “GUI” to “service interface”? The  
> application may be better designed in term of what you can get from it and  
> what you will feed it with. Can designate it as an abstract interface,  
> perhaps.

There are two different sort of interfaces the components of a GUI
application have:

1. Interfaces of its functional components

2. Interfaces of its GUI components.

These interfaces have nothing or very little in common which is why
standard means of decomposition do not work well. When you decompose having
the application domain (functionality) in mind, you lose UI, when you focus
on UI, you lose much of functionality.

>> You don't own the main task it will belong to the GUI.
> Not necessarily.

How so? Most GUI frameworks simply require this.

> With MVP (which is not the same as MVC), the presenter  
> starts everything (it is the supervisor), and it's the presenter which own  
> the main task, and it it may launch the application and the UI as two  
> others distinct tasks.

The main task runs the messages loop. Which means that it is blocked most
of the time waiting for incoming messages.

>> You have to design all
>> vital data structures as models compatible to the GUI framework at
>> hand.
> You may do this way, while you are as much free to adapt the UI to an UI  
> specification, a specification which specify a human interface to a  
> computation or service interface.

No way. If you have, say, a DB and want to show its contents in a list
control, the DB client must be a list store (the model deployed by the list
control). If the DB client was designed in a way that does not support
delivery of the result set incrementally, in portions, the UI will block
when rendering large result sets. If the DB client delivers each row
separately, that will choke the UI with a flood of events etc. You can do
nothing about it. You have to change the client [or write new list widget].

The point is, one influences another and if you consider the GUI framework
fixed, then the application must adapt = you build around the GUI.

>> You have to place inspection/rollback/abort check points in all
>> lengthy operations to be able to add progress bars, cancel buttons etc.
> You may, if you designed the application. But you may as much have to add  
> an interface to an already existing application which does not provide  
> these facilities.

It is very simple to [dis]prove your theory. Take (RM G.3.1)

function Solve (A : Real_Matrix; X : Real_Vector) return Real_Vector;

The objective is to start it on a button click, show a modeless dialog with
a progress bar and a cancel button inside.

>> You have to decide polling vs. event-driven policies along the M-V path  
>> and design the tasks involved correspondingly.

> In MVP with a passive view, there is no direct path from the model to the  
> view.

Direct or not, the model influences the view and you have to decide which
policy to deploy.

> I also guess the MVP may not looks  
> so much appealing at first sight, as it requires more work (and in some  
> context, like the web, it may present challenges with communication and  
> separation); but the benefit is to be more solid and more composite.

It just does not answer the question. It is a pattern to decompose UI.
Evidently, it is not a pattern to solve linear equations, is it?

The problem of GUI software design is how to decompose UI *and* the problem
space.

> Also, may be there's some confusions between application interface and  
> user interface in this topic (some comments make me feel that; see above).

Oh, yes. Fancy papers about GUI design consider UI the problem space. They
already took for granted that applications are built around the GUI. And
all GUI frameworks I know require no less.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Georg Bauhaus]

On 29.12.12 13:27, Dmitry A. Kazakov wrote:
> The point is, one influences another and if you consider the GUI framework
> fixed, then the application must adapt = you build around the GUI.

To build an application around a GUI is one example of
designing in accord with a given mechanism.
It is sad that there need to be so many variations of
basically the same mechanism.

Another popular given mechanism is based on web requests.
It is a technique for parallel execution just slightly
reminiscent of Paraffin.

Each request will perform part of a computation,
and will use no more than a limited amount of resources.
You therefore need to decompose a simple algorithm into
parts, assign these to request handlers, and start a
sequence of requests that trigger the handlers.

Topological order of requests and passing data is done
with the help of external storage. The latter has
transactions, and needs explicit cleanup (costly).
(This is Google's App Engine.)

For some setups, Paraffin seems simpler to use, though you'd
perhaps consider how to split the computation, and thus build
around a given mechanism.

Note that, in the US, using the specimen called MapReduce
incurs the cost of at least FUD via patent number 7,650,331.
Is the Paraffin library for Ada covered?

I suppose that you'd run into the same patent trouble (or not)
with GUIs once you start designing an application with a more
interesting UI.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Yannick Duchêne (Hibou57)]

Le Sat, 29 Dec 2012 14:07:28 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:
> Note that, in the US, using the specimen called MapReduce
> incurs the cost of at least FUD via patent number 7,650,331.
> Is the Paraffin library for Ada covered?

http://arstechnica.com/information-technology/2010/01/googles-mapreduce-patent-what-does-it-mean-for-hadoop/

The paper says:
> "Map" and "reduce" are functional programming primitives
> that have been used in software development for decades.
And its name even comes from there. Strange one can patent something  
widely known for long (luckily, this patent is probably not valid in  
Europe).


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Yannick Duchêne (Hibou57)]

Le Sat, 29 Dec 2012 13:27:56 +0100, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
>>> You have to design all
>>> vital data structures as models compatible to the GUI framework at
>>> hand.
>> You may do this way, while you are as much free to adapt the UI to an UI
>> specification, a specification which specify a human interface to a
>> computation or service interface.
>
> No way. If you have, say, a DB and want to show its contents in a list
> control, the DB client must be a list store (the model deployed by the  
> list
> control). If the DB client was designed in a way that does not support
> delivery of the result set incrementally, in portions, the UI will block
> when rendering large result sets. If the DB client delivers each row
> separately, that will choke the UI with a flood of events etc. You can do
> nothing about it. You have to change the client [or write new list  
> widget].
The presenter can handle this. Or else, a specific widget is an option  
too, indeed.

>>> You have to place inspection/rollback/abort check points in all
>>> lengthy operations to be able to add progress bars, cancel buttons etc.
>> You may, if you designed the application. But you may as much have to  
>> add
>> an interface to an already existing application which does not provide
>> these facilities.
>
> It is very simple to [dis]prove your theory. Take (RM G.3.1)
>
> function Solve (A : Real_Matrix; X : Real_Vector) return Real_Vector;
>
> The objective is to start it on a button click, show a modeless dialog  
> with
> a progress bar and a cancel button inside.
That is going too far.

>> Also, may be there's some confusions between application interface and
>> user interface in this topic (some comments make me feel that; see  
>> above).
>
> Oh, yes. Fancy papers about GUI design consider UI the problem space.  
> They
> already took for granted that applications are built around the GUI. And
> all GUI frameworks I know require no less.
These are two problem spaces, and none of both is at the centre (that's  
why it may suggest mediation).


Have an happy day


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1gda5kzj50h3l.jzmq13s0hw74.dlg@40tude.net...
> On Fri, 28 Dec 2012 06:51:01 -0800 (PST), alb348@gmail.com wrote:
>
>> I am a interested in creating GUI applications with Ada, using either Qt
>> or Gtk (it must be one of these two, because these are the only toolkits
>> that provide full BiDi support).
>
> One important thing, which implies the obvious consequences. There is no
> easy way of building GUI as well as no way of adding GUI to an existing
> application.

This I agree with...

...
>> My question is: is there any GUI builder, either for Qt or for Qt, which
>> will allow me to graphically design the widgets, and which will then
>> generate Ada code?
>
> Wasting time, but you won't believe me anyway. So take any, it is actually
> no matter. Once you have it behind you, you can make a fresh start and
> begin working productively.

...but I don't agree with this.

It's certainly possible to create a GUI Builder that does most of the 
busy-work but still allows one to write the rest of a application. We tried 
to accomplish that with the Claw builder, and we were reasonably successful. 
(All of my Claw programs [except the builder itself] have all of the menus 
and dialogs created with the builder.) The key is to take advantage of the 
easy separation that Ada provides into parts generated by the builder and 
parts written manually. Ada helps this along with separate specifications 
and bodies, and with child units. For a typical dialog, the call-back 
routines are placed in a child package and (something that we did wrong in 
the Claw builder but may fix in a future version) the specification can be 
generated based on which call-backs are needed. This way, the compiler 
clearly flags mismatched or missing call-backs, and it's clear which ones 
are needed.

We also make it possible to manually select the type names and package names 
for each generated entity, so these can be meaningful and not just some 
randomly selected thing. The result is readable code clearly separated into 
machine generated and programmer-written parts. (And of course, the 
programmer written parts can reference details of the machine generated 
code.)

If I had to lay out dialogs manually, it would take days of 
edit/compile/test/repeat loop to get a layout that doesn't look like it is 
created by an ape. At least with a GUI builder, you can reposition controls 
(widgets in GTK parlance) until the dialong looks sane.

Very complex things still need to be written by hand, but of course Claw 
makes that as easy as possible. But simply avoiding writing a huge pile of 
busywork code (it tends to be over 50% of the code total in my Claw 
programs) saves a lot of time. (Especially as that code very rarely has 
errors, as such errors are bugs in the GUI Builder.)

I suspect that most GUI builders try to take "easier" approaches, but they 
don't scale well at all. For instance, you have to be able to put the 
hand-written code under version control, be able to use your favorite IDE to 
create it, and use all of your favorite development tools on it. It *cannot* 
be written inside of the GUI builder and do any significant part of that.

                                         Randy.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Georg Bauhaus]

On 29.12.12 01:27, Randy Brukardt wrote:
> It's certainly possible to create a GUI Builder that does most of the
> busy-work but still allows one to write the rest of a application.

Perhaps it is an idea to be more specific about "GUI"?

For some, GUI means dialogs in windows, menus, text fields and various
buttons, maybe table views. For others, GUI means a responsive
drawing/symbol/model of something that is different in that it is
*not* controlled by text input, or via buttons, because it can't, really.
Rather, the GUI is more graphical: the user is watching/controlling
some 2D graph, say.
  Is designing these controls best done using what is available
in typical GUI builders? A mature CAD program would seem a more apt GUI
builder for this kind of controls. What does game production use?

For standard views, views that need not be reinvented by each GUI
programmer, I find a GUI builder a productive tool, because one just
needs to fill in the blanks to exactly meet user expectations.
It has built-in knowledge of graphic design.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Yannick Duchêne (Hibou57)]

Le Sat, 29 Dec 2012 02:02:33 +0100, Georg Bauhaus  
<rm.dash-bauhaus@futureapps.de> a écrit:

> On 29.12.12 01:27, Randy Brukardt wrote:
>> It's certainly possible to create a GUI Builder that does most of the
>> busy-work but still allows one to write the rest of a application.
>
> Perhaps it is an idea to be more specific about "GUI"?
>
> For some, GUI means dialogs in windows, menus, text fields and various
> buttons, maybe table views. For others, GUI means a responsive
> drawing/symbol/model of something that is different in that it is
> *not* controlled by text input, or via buttons, because it can't, really.
> Rather, the GUI is more graphical: the user is watching/controlling
> some 2D graph, say.
>   Is designing these controls best done using what is available
> in typical GUI builders? A mature CAD program would seem a more apt GUI
> builder for this kind of controls. What does game production use?
>
> For standard views, views that need not be reinvented by each GUI
> programmer, I find a GUI builder a productive tool, because one just
> needs to fill in the blanks to exactly meet user expectations.
> It has built-in knowledge of graphic design.

I feel your comments interesting here, in the way they talk about the UI  
as a separate entity, designed separately. Designing an UI and designing  
an application with an UI, is not the same. To design an UI, a tool à‑la  
Glade is indeed useful (while not required); but it typically won't help  
as much to design an application with an UI.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Dmitry A. Kazakov]

On Sat, 29 Dec 2012 02:02:33 +0100, Georg Bauhaus wrote:

> On 29.12.12 01:27, Randy Brukardt wrote:
>> It's certainly possible to create a GUI Builder that does most of the
>> busy-work but still allows one to write the rest of a application.
> 
> Perhaps it is an idea to be more specific about "GUI"?

Sure. GUI consisting of a bunch of modal dialogs of fixed layout is casual
now. Times you could sell that to the customer are eons ago.

> For some, GUI means dialogs in windows, menus, text fields and various
> buttons, maybe table views. For others, GUI means a responsive
> drawing/symbol/model of something that is different in that it is
> *not* controlled by text input, or via buttons, because it can't, really.

Actually, a simple tree view is usually enough for the house of cards to
collapse. But there is also another thing which makes a lot of trouble even
with buttons and dialogs. That is "horizontal" interaction of GUI elements.
Modern GUIs have multiple active elements visible. Nobody wants modal
dialogs anymore. These elements influence, constrain, control each other
outside the container-field relationship. This quickly breaks the classical
hierarchical schema based on simple callbacks.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Vadim Godunko]

On Friday, December 28, 2012 6:51:01 PM UTC+4, alb...@gmail.com wrote:
> 
> My question is: is there any GUI builder, either for Qt or for Qt, which will allow me to graphically design the widgets, and which will then generate Ada code?
> 
Both toolkits have GUI builder programs (GLADE for Gtk+ and Qt Designer for Qt), but both doesn't generate Ada code. Instead, they use intermediate representation of GUI components and load them at run-time.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[alb348]

On Friday, December 28, 2012 5:20:04 PM UTC+1, Vadim Godunko wrote:

> Both toolkits have GUI builder programs (GLADE for Gtk+
> and Qt Designer for Qt), but both doesn't generate Ada
> code. 
> Instead, they use intermediate representation of GUI
> components and load them at run-time.

Sorry, I was not able to understand the meaning of the last sentence. What I would like to understand, specifically, is whether the code generated by those "builders" could be useful, in any way, for Ada programmers. And, if so, what would be the next step to take after generating the code with the builders. 
For instance, is it possible to run some Ada "binder" on the generated code of those objects, in order to automatically create Ada bindings from them?

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Justin Time]

Le vendredi 28 décembre 2012 20:56:31 UTC+1, alb...@gmail.com a écrit :
> On Friday, December 28, 2012 5:20:04 PM UTC+1, Vadim Godunko wrote:
> 
> 
> 
> > Both toolkits have GUI builder programs (GLADE for Gtk+
> 
> > and Qt Designer for Qt), but both doesn't generate Ada
> 
> > code. 
> 
> > Instead, they use intermediate representation of GUI
> 
> > components and load them at run-time.
> 
> 
> 
> Sorry, I was not able to understand the meaning of the last sentence. What I would like to understand, specifically, is whether the code generated by those "builders" could be useful, in any way, for Ada programmers. And, if so, what would be the next step to take after generating the code with the builders. 
> 
> For instance, is it possible to run some Ada "binder" on the generated code of those objects, in order to automatically create Ada bindings from them?

Glade does not generate Ada code but a XML file that contains descriptions of 
GTK widgets/windows (size, packing, signals, etc ...).

From this XML file you can get a code prototype using a code sketcher.
Code sketcher are available for different languages :

See section "Code sketching" in article http://en.wikipedia.org/wiki/Glade_Interface_Designer

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[alb348]

On Friday, December 28, 2012 9:38:09 PM UTC+1, Justin Time wrote:

> Glade does not generate Ada code but a XML file that contains descriptions of 
> 
> GTK widgets/windows (size, packing, signals, etc ...).
> 
> From this XML file you can get a code prototype using a code sketcher.
> 
> Code sketcher are available for different languages :
> 
> See section "Code sketching" in article http://en.wikipedia.org/wiki/Glade_Interface_Designer

Thanks. That is what I was looking for!! So, the workflow seems to be: creating the widjets with Glade, then using Gate3 to generate Ada code, then using the generated code in Ada programs.

Anyway, I will keep in mind Dmitry's warnings and if I find myself wasting too much time, I will consider learning how to code them manually.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Randy Brukardt]

<alb348@gmail.com> wrote in message 
news:49ad97eb-fac1-49f0-a4ea-2dd79fa803d0@googlegroups.com...
...
> Thanks. That is what I was looking for!! So, the workflow seems to be: 
> creating the widjets with Glade, then using Gate3 to generate Ada code, 
> then using the generated code in Ada programs.

I suspect that this workflow is the problem that Dmitry is referring to. It 
doesn't mesh well with incremental, agile development, where you are 
constantly tweaking both the GUI and the code that supports it.

I realize that this makes it possible for one "front-end" to support many 
different code generation schemes (and that code generation is the "easy" 
part of a GUI builder), but it is just too far from the sort of control 
needed to make real, living applications. The Claw Builder (for instance), 
supports specifying how the package specification corresponding to a dialog 
box will look, whether it is just a single subprogram call (for a dialog 
that does all of its work in call-backs), a subprogram call that returns a 
visible  record (of the data specified by the box), or whether the dialog 
type is also visible (so that multiple instances can be created). These 
sorts of decisions can't be productively made by the software alone, and 
only generating a single template is never going to have the flexibility 
needed for these things.

Of course, the other approach is a heck of a lot of work, one reason why the 
Claw Builder's development has stalled...

                                           Randy.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Blady]

Le 29/12/12 01:48, Randy Brukardt a �crit :
> <alb348@gmail.com> wrote in message
> news:49ad97eb-fac1-49f0-a4ea-2dd79fa803d0@googlegroups.com...
> ....
>> Thanks. That is what I was looking for!! So, the workflow seems to be:
>> creating the widjets with Glade, then using Gate3 to generate Ada code,
>> then using the generated code in Ada programs.
>
> I suspect that this workflow is the problem that Dmitry is referring to. It
> doesn't mesh well with incremental, agile development, where you are
> constantly tweaking both the GUI and the code that supports it.
>
> I realize that this makes it possible for one "front-end" to support many
> different code generation schemes (and that code generation is the "easy"
> part of a GUI builder), but it is just too far from the sort of control
> needed to make real, living applications. The Claw Builder (for instance),
> supports specifying how the package specification corresponding to a dialog
> box will look, whether it is just a single subprogram call (for a dialog
> that does all of its work in call-backs), a subprogram call that returns a
> visible  record (of the data specified by the box), or whether the dialog
> type is also visible (so that multiple instances can be created). These
> sorts of decisions can't be productively made by the software alone, and
> only generating a single template is never going to have the flexibility
> needed for these things.
>
> Of course, the other approach is a heck of a lot of work, one reason why the
> Claw Builder's development has stalled...
>
>                                             Randy.
>
>
Hello, I don't know about Claw, I use GtkAda for the same reason as Dmitry.
The question is why not Qt or else... Claw.
I aim building GUI native apps for Mac in Ada, maybe Cocoa without 
success up to now.
Well, the link http://en.wikipedia.org/wiki/Glade_Interface_Designer 
given by Justin show a very interesting chart at the end : Ada is not 
present. It's really amazing ;-)
Ada programmers should'nt any more ask themselves the question : which 
GUI Ada API for my program?
What about of standardized graphic Ada specification packages?
Compiler providers could then map the specifications to any underlying 
graphic toolkit or native system API.
In this way GUI Ada program will be source code portable as the aim of Ada.
Ada 2012 is born this month, an idea for future Ada 202x?

Happy New Year 2013, Pascal.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Yannick Duchêne (Hibou57)]

Le Sat, 29 Dec 2012 11:23:30 +0100, Blady <p.p11@orange.fr> a écrit:
> What about of standardized graphic Ada specification packages?
If it's a simple one, it will please just a few people, and many people  
will wish there own things (just think that some Ada standard packages may  
already not please everyone, like Text_IO, some containers, … things would  
just be worst with graphics and UIs).

If it's intended to try to please everyone, it would be bulky, and would  
easily consume 95% of the work on the Ada standard, which would be hardly  
acceptable (and this would efficiently prevent standard Ada compilers to  
be created), for something which is not the first Ada concern.

Better choose already existing standards when there are some, and make Ada  
applications use it (either via bindings or implementations), at every  
one's discretion. Defining what standard graphic/GUI/TUI services should  
be, is not an Ada concern anyway.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Justin Time]

Le samedi 29 décembre 2012 01:48:37 UTC+1, Randy Brukardt a écrit :
> wrote in message 


> I suspect that this workflow is the problem that Dmitry is referring to. It 
> doesn't mesh well with incremental, agile development, where you are 
> constantly tweaking both the GUI and the code that supports it.
> 
>                                            Randy.

The gate3 tool is not intented for incremental development.
It just ouputs a sketch (with stubs for the callbacks).
It is almost stupid but saves time of typing repetitive code.
For complete newbies, they can get a prototype very quickly.

And the advantage of Gtkbuilder is the good decoupling between UI
and code. One can modify the XML/glade file for layout and re-run the app
without any recompilation

The perfect tool does not exist, but if you have one stupid tool that saves you
3 hours on a 3-day project that's not bad. On a 1 man-year project,
you don't care.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

"Justin Time" <francois_fabien@hotmail.com> wrote in message 
news:4f9f0be9-7c11-4499-8c6d-1a56ed6e4f3c@googlegroups.com...
Le samedi 29 d�cembre 2012 01:48:37 UTC+1, Randy Brukardt a �crit :
> wrote in message
...
>> I suspect that this workflow is the problem that Dmitry is referring to. 
>> It
>> doesn't mesh well with incremental, agile development, where you are
>> constantly tweaking both the GUI and the code that supports it.
>>
>The gate3 tool is not intented for incremental development.
>It just ouputs a sketch (with stubs for the callbacks).
>It is almost stupid but saves time of typing repetitive code.
>For complete newbies, they can get a prototype very quickly.

IMHO, all projects need incremental development. The number of times that 
you know exactly what you want beforehand is vanishingly small.

>And the advantage of Gtkbuilder is the good decoupling between UI
>and code. One can modify the XML/glade file for layout and re-run the app
>without any recompilation

Sure, but that only works if you know exactly what windows/controls you want 
the first time. That's hardly likely.

>The perfect tool does not exist, but if you have one stupid tool that saves 
>you
>3 hours on a 3-day project that's not bad. On a 1 man-year project,
>you don't care.

I'd rather use a smarter tool that scales well, because I don't have time to 
learn a dozen tools for different sized projects. (If saving your 3 hours 
requires a six hour learning curve -- which is optimistic -- what are you 
gaining.) This is the same reason that I use Ada for virtually all of my 
programming - even for throwaways (because it's not that unusual for the 
throwaways to get used more than you think and need to be modified).

Anyway, tools choices are a fairly personal thing.

                                  Randy.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Justin Time]

Le lundi 31 décembre 2012 22:49:28 UTC+1, Randy Brukardt a écrit :

 
> I'd rather use a smarter tool that scales well, because I don't have time to 
> learn a dozen tools for different sized projects. (If saving your 3 hours 
> requires a six hour learning curve -- which is optimistic -- what are you 
> gaining.) This is the same reason that I use Ada for virtually all of my 
> programming - even for throwaways (because it's not that unusual for the 
> throwaways to get used more than you think and need to be modified).
> 
> Anyway, tools choices are a fairly personal thing.
> 
> 
> 
>                                   Randy.

Tool was not the proper word. I would say it is a kind of helper.
When evaluating GTKAda/Glade3, I ended up doing a lot of cut and paste,
because the previous program for glade2 was not longer available.
Time-consuming and boring. Added Value for that = zero.
This helper is intended to replace what was existing previously and
the learning time for it should be small. 

The life-cycle of widgets in GTK is rather cryptic.
As mentionned in other posts there is no hands-on tutorial on designing
GTK applications, except for trivial ones (not specific to Ada).
So the average programmer will stick with VB for GUI applications.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Dmitry A. Kazakov]

On Tue, 1 Jan 2013 02:46:44 -0800 (PST), Justin Time wrote:

> The life-cycle of widgets in GTK is rather cryptic.

Hmm, I think any GTK tutorial mentions reference counting. There is nothing
to do/worry about widget's life-cycle. Except for dialogs all widgets are
destroyed implicitly.

> So the average programmer will stick with VB for GUI applications.

I doubt that. VB is indeed very popular among engineers. Excel is probably
even more than VB. But the average programmers would rather use C# or Java.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Justin Time]

Le mardi 1 janvier 2013 13:24:41 UTC+1, Dmitry A. Kazakov a écrit :
> On Tue, 1 Jan 2013 02:46:44 -0800 (PST), Justin Time wrote:
> 
> 
> 
> > The life-cycle of widgets in GTK is rather cryptic.
> 
> Hmm, I think any GTK tutorial mentions reference counting. There is nothing
> to do/worry about widget's life-cycle. Except for dialogs all widgets are
> destroyed implicitly.
> 
My comment was about initialization of widgets (realize/show) and its children , not their destruction.
If you have a pointer to an advanced GTK tutorial (besides RosettaCode which is basic), I think that it would interest anybody evaluating GTK (this is not specific to Ada).

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Dmitry A. Kazakov]

On Tue, 1 Jan 2013 08:55:33 -0800 (PST), Justin Time wrote:

> Le mardi 1 janvier 2013 13:24:41 UTC+1, Dmitry A. Kazakov a �crit�:
>> On Tue, 1 Jan 2013 02:46:44 -0800 (PST), Justin Time wrote:
>> 
>>> The life-cycle of widgets in GTK is rather cryptic.
>> 
>> Hmm, I think any GTK tutorial mentions reference counting. There is nothing
>> to do/worry about widget's life-cycle. Except for dialogs all widgets are
>> destroyed implicitly.
>> 
> My comment was about initialization of widgets (realize/show) and its children,

I see. I don't think that even GTK maintainers have a clear picture of the
sequence of signals, especially, for complex widgets, popups etc.

However it is clear that a tool would make the problem only worse.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Justin Time]

GtkAda is not as complicated as it seems at first glance. You have to learn the arborescence of widgets/windows(for me 2 days in learning by doing).
Using glade3 is quite helpful.
Some link that could be useful to you :
Basic stuff to use glade3 : http://wiki.ada-dk.org/building_gui_with_glade_3

GtkAda uses version 2.24 of GTK. So you need Glade3.8 and NOT Glade 3.12 which is for GTK 3.x.

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[ldries46]

The biggest problem I have with Glade 3 is the complete lack of good 
tutorials or user guides for using the glade files with Ada.
The link to http://wiki.ada-dk.org/building_gui_with_glade_3 just presents a 
simple ada program which even lacks a simple extension is how to link a 
filechooser dialog or link a Gtk_Textview to my program. Are there such 
tutorials and where can I find them.
I tried to create a filechooser to my program by only using code but I 
cannot find some explanation how to get the link to the parent.

L. Dries

"Justin Time"  schreef in bericht 
news:12019264-a08e-414b-a260-5f8aaa4adabf@googlegroups.com...

GtkAda is not as complicated as it seems at first glance. You have to learn 
the arborescence of widgets/windows(for me 2 days in learning by doing).
Using glade3 is quite helpful.
Some link that could be useful to you :
Basic stuff to use glade3 : http://wiki.ada-dk.org/building_gui_with_glade_3

GtkAda uses version 2.24 of GTK. So you need Glade3.8 and NOT Glade 3.12 
which is for GTK 3.x. 

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[John B. Matthews]

In article <50e14823$0$32188$703f8584@news.kpn.nl>,
 "ldries46" <bertus.dries@planet.nl> wrote:

> The biggest problem I have with Glade 3 is the complete lack of good 
> tutorials or user guides for using the glade files with Ada. The link 
> to http://wiki.ada-dk.org/building_gui_with_glade_3 just presents a 
> simple ada program which even lacks a simple extension is how to link 
> a filechooser dialog or link a Gtk_Textview to my program. Are there 
> such tutorials and where can I find them.
> I tried to create a filechooser to my program by only using code but 
> I cannot find some explanation how to get the link to the parent.

The examples in the testgtk folder of GTKAda may be a useful resource, 
in particular these two composite widgets:

testgtk/create_file_chooser.adb
testgtk/create_file_selection.adb

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Brian Drummond]

On Mon, 31 Dec 2012 09:07:38 +0100, ldries46 wrote:

> The biggest problem I have with Glade 3 is the complete lack of good
> tutorials or user guides for using the glade files with Ada.

Amen! There are tutorials that cover little parts of the problem but 
nothing about putting the components together to form a coherent 
application.

> The link to http://wiki.ada-dk.org/building_gui_with_glade_3 just
> presents a simple ada program which even lacks a simple extension is how
> to link a filechooser dialog or link a Gtk_Textview to my program. Are
> there such tutorials and where can I find them.
> I tried to create a filechooser to my program by only using code but I
> cannot find some explanation how to get the link to the parent.

Filechooser stumped me too for a couple of days.

As John Matthews says, there is a lot of good stuff in TestGTK, including 
a FileChooser button and a completely diffrent (and IMO ugly) style of 
file selection widget - but even then, they opened a window but didn't 
give a clue how to actually get a filename out of it!

I finally managed it to my satisfaction - still mean to write it (and 
others) up as a tutorial, but have another project on the go at the 
moment.

I also put together a little harness that lets me take any one component 
out of TestGTK and run it standalone, to see how it works in isolation 
until I can make it do my bidding. 

I keep meaning to put that up somewhere too...

- Brian

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[leonid.dulman]

On Friday, December 28, 2012 4:51:01 PM UTC+2, alb...@gmail.com wrote:
> I am a interested in creating GUI applications with Ada, using either Qt or Gtk (it must be one of these two, because these are the only toolkits that provide full BiDi support).
> 
> I was happy to find that the Ada bindings are available for both Qt and Gtk, but I was disheartened when I saw the code of the example programs. Lots of code! Lines and lines of dense code, barely comprehensible. Honestly, I don't know if I would be able to write a GUI by manually writing so much code.
> 
> 
> 
> My question is: is there any GUI builder, either for Qt or for Qt, which will allow me to graphically design the widgets, and which will then generate Ada code?
> 
> If not, what would be the easiest way to create the Qt/Gtk interfaces I need and use them in Ada? (I dread having to write everything manually!)
> 
> 
> 
> Thanks
> 
> 
> 
> Alby

You can use VAD Visual Ada Developer to build GUI quick and easy
http://users1.jabry.com/adastudio/index.html
Leonid

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[alb348]

> You can use VAD Visual Ada Developer to build GUI quick and easy
> http://users1.jabry.com/adastudio/index.html
> Leonid

I am a bit disappointed. I was expecting a GUI builder for Qt, because the same author of VAD also created the Ada bindings for Qt (both Qt 4 and Qt 5).
Instead, the VAD GUI builder is based on Tcl/tk. Still useful but... a horse of a totally different color.

Leonid, any chance you may add Qt support to VAD? At least for basic GUI functions (forms, dialogs, etc)

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[leonid.dulman]

On Friday, December 28, 2012 4:51:01 PM UTC+2, alb...@gmail.com wrote:
> I am a interested in creating GUI applications with Ada, using either Qt or Gtk (it must be one of these two, because these are the only toolkits that provide full BiDi support).
> 
> I was happy to find that the Ada bindings are available for both Qt and Gtk, but I was disheartened when I saw the code of the example programs. Lots of code! Lines and lines of dense code, barely comprehensible. Honestly, I don't know if I would be able to write a GUI by manually writing so much code.
> 
> 
> 
> My question is: is there any GUI builder, either for Qt or for Qt, which will allow me to graphically design the widgets, and which will then generate Ada code?
> 
> If not, what would be the easiest way to create the Qt/Gtk interfaces I need and use them in Ada? (I dread having to write everything manually!)
> 
> 
> 
> Thanks
> 
> 
> 
> Alby

I plane to do this, but now I want to build VTK 5.10.1 with Qt5 and rebuild my VTK5ADA system

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Patrick]

I really need to get my two projects started. I have been planning one for 4 or 5 years(This is a embarrassing confession) and the other about a year. 

I want to use Ada for everything but I just don't get GTK Ada. I am trying to decide between C Gtk and Ada Glade. 

I am thinking about trying to mix Ada glade and hand coded Ada gtk ? 

I know it would have to be one full window/dialog in one or the other.

 I could start with the simple stuff in glade and make new more flexible hand coded windows later.

Does that sound logical? Would it be good for the OP ?

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Brian Drummond]

On Fri, 04 Jan 2013 05:53:35 -0800, Patrick wrote:

> I really need to get my two projects started. I have been planning one
> for 4 or 5 years(This is a embarrassing confession) and the other about
> a year.
> 
> I want to use Ada for everything but I just don't get GTK Ada. I am
> trying to decide between C Gtk and Ada Glade.
> 
> I am thinking about trying to mix Ada glade and hand coded Ada gtk ?
> 
> I know it would have to be one full window/dialog in one or the other.
> 
>  I could start with the simple stuff in glade and make new more flexible
>  hand coded windows later.
> 
> Does that sound logical? Would it be good for the OP ?

One thing that is alleged to be possible, but so far has no good 
tutorial : having written your own GTKAda widget, how do you make it 
accessible and usable in Glade as the predefined widgets?

This would go a long way to answering your (and it's not just you!) 
questions...

- Brian

Re: Easiest way to build Qt/Gtk interfaces for Ada programs

[Dmitry A. Kazakov]

On Fri, 4 Jan 2013 23:31:03 +0000 (UTC), Brian Drummond wrote:

> One thing that is alleged to be possible, but so far has no good 
> tutorial : having written your own GTKAda widget, how do you make it 
> accessible and usable in Glade as the predefined widgets?

I have an impression that GLADE is hard-coded. GTK has some widget
introspection tools. GLADE could enumerate widget's properties, style
properties, signals and parameters of, once you have an instance of the
widget. The first problem is that one should link to GLADE, in order to
introspect and configure. That cannot be the same application as the
production code. You would have to maintain two projects instead of one.
Another problem is that custom widgets are usually loaded with semantics
which GLADE cannot know about or handle. E.g. the parameters of Gtk_New,
the discriminants of the object etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de