New Ada portable GUI Library?
Tomek Walkuski
someone wrote about need such kind of simple, non-GPL in "The future
of Ada is at risk" thread.
In which direction should it go? Portable means: native widgets on all
platform (wxWidgets approach) or imitation of these (Swing approach)?
Do you have any other ideas? Some design suggestions?
I'm asking because I'm interested in this matter, maybe I will find
time to start hacking this :)
I'm trying to put first brick, start the discussion, maybe something
good for the community will emerge?
Martin Krischik
> In which direction should it go? Portable means: native widgets on all
> platform (wxWidgets approach) or imitation of these (Swing approach)?
> Do you have any other ideas? Some design suggestions?
I think the wxWidgets idea is the best.
Martin
--
mailto://kris...@users.sourceforge.net
Ada programming at: http://ada.krischik.com
Lucretia
wrote:
> Tomek Walkuski wrote:
> > In which direction should it go? Portable means: native widgets on all
> > platform (wxWidgets approach) or imitation of these (Swing approach)?
> > Do you have any other ideas? Some design suggestions?
>
> I think the wxWidgets idea is the best.
Yes it is. I originally started to write a binding library to
wxWidgets (http://www.archeia.com/home.html&tags=wxwidgets) but found
it incredibly hard to do.
We have just had a similar conversation on #Ada (freenode) about this.
I think the best way is to create a very thin C lib which exports a
bunch of functions for manipulating the underlying GUI lib and then
build an Ada library on top of that. These C functions could, if you
wanted, for certain platforms be another Ada library which exports to
C (for compatibility to the above layer). This then allows binding to
a GUI which already has a decent Ada port and to those which don't.
Luke.
frame...@gmail.com
> Hi,
>
> someone wrote about need such kind of simple, non-GPL in "The future
> of Ada is at risk" thread.
>
Sorry, this is not an answer to your question, but another (slightly
OT) question that yours triggered. I have an old C++ library of mine
(for computations with rings, fields and algebraic stuff). Triggered
by the discussion "future of Ada" I am thinking to rewrite it in Ada
(ok, maybe symbolic computation is not very important in business
applications, but there is where my skills live). I would like to
make the library available with an open-source licence, but not GPL
since I understand that the clause that any derivative work must be
GPLed (maybe I am not precise here, but please do not flame me ;-)
keeps professional away from GPLed library.
After such a long introduction my question finally arrives: can you
suggest any open-source licence which could be used in this case ?
(and maybe in other Ada libraries to be developed)
Thanks 16#3E8#
PS: no flame, please... :-)
Maciej Sobczak
wrote:
> After such a long introduction my question finally arrives: can you
> suggest any open-source licence which could be used in this case ?
> (and maybe in other Ada libraries to be developed)
The C++ programmers have this:
The license choice was a big issue and after lengthy consultations the
Boost community arrived at this:
http://www.boost.org/LICENSE_1_0.txt
Please read this:
http://www.boost.org/more/license_info.html
to learn the rationale for it.
There is nothing that prevents anybody from using it for other
libraries.
Whether this license is good for your particular purpose is entirely
up to you, but if you already find GPL not meeting your requirements
(too much restrictive and preventing wider adoption), then the Boost
license might be the best next match. It is similar in spirit to BSD.
--
Maciej Sobczak * www.msobczak.com * www.inspirel.com
Tomek Walkuski
> suggest any open-source licence which could be used in this case ?
> (and maybe in other Ada libraries to be developed)
>
Gautier
"do what you want but keep the license please" license was not convenient, but
they directed me towards a similar license, the MIT license:
http://www.opensource.org/licenses/mit-license.php
Maybe you'll be happy with it...
Gautier
______________________________________________________________
Gautier -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm
NB: For a direct answer, e-mail address on the Web site!
Dmitry A. Kazakov
> I would like to
> make the library available with an open-source licence, but not GPL
> since I understand that the clause that any derivative work must be
> GPLed (maybe I am not precise here, but please do not flame me ;-)
> keeps professional away from GPLed library.
Would not GMGPL be OK?
http://en.wikipedia.org/wiki/GMGPL
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Tomek Walkuski
> We have just had a similar conversation on #Ada (freenode) about this.
> I think the best way is to create a very thin C lib which exports a
> bunch of functions for manipulating the underlying GUI lib and then
> build an Ada library on top of that. These C functions could, if you
> wanted, for certain platforms be another Ada library which exports to
> C (for compatibility to the above layer). This then allows binding to
> a GUI which already has a decent Ada port and to those which don't.
>
> Luke.
I think, there is no sense to do binding to wxWidgets. There should be
"clean" implementation of something like wxWidgets.
wxWidgets (and Java's SWT) use native GUIs, like GTK on Linux (I do
not have any experience with Win32 API) which is already in C.
I think that is necessary to prepare own (Ada) abstraction to various
native toolkits.
Robert A Duff
> After such a long introduction my question finally arrives: can you
> suggest any open-source licence which could be used in this case ?
> (and maybe in other Ada libraries to be developed)
I think it's a good idea to use some widely-used license rather than
making up your own. People are scared of strange licenses that they
don't already understand.
I suggest you take a look at the GMGPL. It's similar to LGPL,
but more appropriate for Ada (C doesn't have generics!).
- Bob
Georg Bauhaus
On Sat, 2008-01-12 at 10:36 -0800, frame...@gmail.com wrote:
> . I would like to
> make the library available with an open-source licence, but not GPL
> since I understand that the clause that any derivative work must be
> GPLed (maybe I am not precise here, but please do not flame me ;-)
Deriving from GMGPLed source doesn't require GPL (or GMGPL),
hence you can distribute binary only programs produces with FSF GNAT.
Things are different when the deriving process includes changes to
the original to suit the programmer's needs.
One of the "more free" licenses that encourages collaborative
work on the licensed work is
http://www.opensource.org/licenses/ver2_eiffel.php
Lucretia
> I think, there is no sense to do binding to wxWidgets. There should be
> "clean" implementation of something like wxWidgets.
Well, this is the conclusion I have come to. wxAda is a dead project
(well to me anyway), but anyone wanted to restart to look into it
again, the source is there.
> wxWidgets (and Java's SWT) use native GUIs, like GTK on Linux (I do
> not have any experience with Win32 API) which is already in C.
>
> I think that is necessary to prepare own (Ada) abstraction to various
> native toolkits.
Like I said, a thin C layer abstraction which is then imported into an
Ada library and turned into a proper Ada GUI with native controls,
this is the best way. For example:
Ada GUI Thick bindings
------------------------
Ada GUI Thin bindings
------------------------
C abstraction layer <- Can be provided via C or Ada depending on
lowest layer
------------------------
X11 | GtkAda | QT
I know three is an X11 binding to Ada but it is old and uses
preprocessing and if you want this library to be portable, you've no
hope where that's concerned. Hence the use of a set of C calls whether
these are written in C or Ada (with export(C, ...) pragmas).
Hope that clarifies my point some more.
Luke.
Georg Bauhaus
On Sat, 2008-01-12 at 23:37 +0100, Georg Bauhaus wrote:
> Deriving from GMGPLed source doesn't require GPL (or GMGPL),
Including/Instantiating .....
Vadim Godunko
>
> Ada GUI Thick bindings
> ------------------------
> Ada GUI Thin bindings
> ------------------------
> C abstraction layer <- Can be provided via C or Ada depending on
> lowest layer
> ------------------------
> X11 | GtkAda | QT
>
license, as well as GtkAda.
Ada has bindings for both Gtk+ and Qt. Both bindings are large,
complex and stable. Which advantages will have new GUI library?
Dmitry A. Kazakov
> Like I said, a thin C layer abstraction which is then imported into an
> Ada library and turned into a proper Ada GUI with native controls,
> this is the best way. For example:
>
> Ada GUI Thick bindings
> ------------------------
> Ada GUI Thin bindings
> ------------------------
> C abstraction layer <- Can be provided via C or Ada depending on
> lowest layer
> ------------------------
> X11 | GtkAda | QT
>
> I know three is an X11 binding to Ada but it is old and uses
> preprocessing and if you want this library to be portable, you've no
> hope where that's concerned. Hence the use of a set of C calls whether
> these are written in C or Ada (with export(C, ...) pragmas).
Gtk and Qt are themselves thick bindings. It makes no sense to use them as
a low-level rendering platform. An all-Ada GUI design should IMO look like:
Ada GUI library
----------------------------------------
Ada rendering platform abstraction layer
|
Ada | Ada native bindings, engine-specific
-------- | -----------------------------
X11 | Win32 GUI API
The major problem is a good abstraction layer with a working concept of
inter-tasking signal handler composition. This is a weakness of most known
Ada GUI libraries.
Lucretia
> > ------------------------
> > X11 | GtkAda | QT
>
> Qt automatically limits you to GPL unless you have commercial Qt
> license, as well as GtkAda.
Yes, I know. I was just pointing out the way to do it.
> Ada has bindings for both Gtk+ and Qt. Both bindings are large,
> complex and stable. Which advantages will have new GUI library?
1) A nicer interface because both of these aren't pleasant.
2) A portable library, compile for many platforms - like wxWidgets.
Luke.
Lucretia
wrote:
> Gtk and Qt are themselves thick bindings. It makes no sense to use them as
> a low-level rendering platform. An all-Ada GUI design should IMO look like:
Yes, actually it does. Look at wxWidgets, they use Gtk as a base for
Linux apps to provide a native look and feel. Not many people use
direct X11 libraries for their DE.
> Ada GUI library
> ----------------------------------------
> Ada rendering platform abstraction layer
> |
> Ada | Ada native bindings, engine-specific
> -------- | -----------------------------
> X11 | Win32 GUI API
>
> The major problem is a good abstraction layer with a working concept of
> inter-tasking signal handler composition. This is a weakness of most known
> Ada GUI libraries.
No! At this level you don't need (or want) to implement tasking.
That's the whole point of using a tiny C veneer as an abstraction for
the stuff you might not be able to do with Ada easily (I'm talking
about managing the C preprocessed code here). You implement the
tasking at the higher Ada layer.
Luke.
Dmitry A. Kazakov
> On Jan 13, 8:13 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> Gtk and Qt are themselves thick bindings. It makes no sense to use them as
>> a low-level rendering platform. An all-Ada GUI design should IMO look like:
>
> Yes, actually it does. Look at wxWidgets, they use Gtk as a base for
> Linux apps to provide a native look and feel. Not many people use
> direct X11 libraries for their DE.
Gtk is slow. And after all, there is GtkAda here. If you are prepared to
buy poor performance of Gtk and its alien to Ada design concept, then you
can branch from GtkAda 2.8 which was GMGPL, or maybe 2.4, I don't remember.
(In case you will go this path let me know. I am interested in such efforts
because I maintain the GtkAda contributions project.)
The only goal of a *true* Ada GUI library, IMO, could be a library which
would have a chance to become a part of the Ada Standard Library. So Gtk is
just non-starter here. We cannot depend on third-party libraries.
>> Ada GUI library
>> ----------------------------------------
>> Ada rendering platform abstraction layer
>> |
>> Ada | Ada native bindings, engine-specific
>> -------- | -----------------------------
>> X11 | Win32 GUI API
>>
>> The major problem is a good abstraction layer with a working concept of
>> inter-tasking signal handler composition. This is a weakness of most known
>> Ada GUI libraries.
>
> No! At this level you don't need (or want) to implement tasking.
> That's the whole point of using a tiny C veneer as an abstraction for
> the stuff you might not be able to do with Ada easily (I'm talking
> about managing the C preprocessed code here). You implement the
> tasking at the higher Ada layer.
That will be too late to do with signals, and with the opposite direction
too, I mean imperative rendering commands. There is also the issue of
sharing OS rendering resources. All these things don't compose at the
tasking level. Your thin layer should have granularity of pair ms per any
primitive (with cloning non-sharable resources). Otherwise things will
block. Already rendering based on OS libraries does not satisfy this
condition. As for signal handling there is no chance to do it at all. This
implies that tasking must be present already at the bottom level of the
bindings. Otherwise, you will need to move signals to the upper levels, but
that is impossible because signals are already a part of the OS layer like
in X11 and Win32. And what would remain, SetPixel? In short, the OS layer
isn't thin enough.
Tomek Walkuski
wrote:
> The only goal of a *true* Ada GUI library, IMO, could be a library which
> would have a chance to become a part of the Ada Standard Library. So Gtk is
> just non-starter here. We cannot depend on third-party libraries.
>
"look and feel" issue, because it is important to many people.
Vadim Godunko
>
> > Ada has bindings for both Gtk+ and Qt. Both bindings are large,
> > complex and stable. Which advantages will have new GUI library?
>
> 1) A nicer interface because both of these aren't pleasant.
> 2) A portable library, compile for many platforms - like wxWidgets.
>
Both Gtk+/GtkAda and Qt/QtAda are portable. They work on UNIX/Linux,
MS Windows, Mac OS. So, this is not an advantage.
Gautier
resources there to reach your goal. And we can continue bla-bla-ting for more
years on c.l.a., it won't change anything.
I suggest something more pragmatic and feasible: develop further an existing
library that works fine on Windows (the lion's share in the market), but is kind
of frozen: GWindows ( http://sourceforge.net/projects/gnavi ).
The goals would be a series of specific improvements like:
- refresh the installer such that it works for GNAT file-based project system
- integrate the nice extensions in GWindows.Extended
- add support case-by-case, e.g., for the clipboard
- revive the GUI builder, GNAVI
When that works, you will maybe, after some time, have attracted so many
programmers that *then* you can even consider beginning the huge task of a
portable GUI system.
NB: if you are allergic to Microsoft (could happen), you still have an
open-source system compatible with Windows: http://www.reactos.org/en/index.html :-)
Tomek Walkuski:
______________________________________________________________
Martin Krischik
> Gtk and Qt are themselves thick bindings. It makes no sense to use them as
> a low-level rendering platform. An all-Ada GUI design should IMO look
> like:
>
> Ada GUI library
> ----------------------------------------
> Ada rendering platform abstraction layer
> |
> Ada | Ada native bindings, engine-specific
> -------- | -----------------------------
> X11 | Win32 GUI API
The problem here is that X11 is so very low level - too low level in fact.
We would have to provide an widget engine first.
Now I just had an idea: how about a Widget which is similar to Win32 GUI
API. But no, that would be WINE all over again.
Lucretia
wrote:
> Gtk is slow. And after all, there is GtkAda here. If you are prepared to
> buy poor performance of Gtk and its alien to Ada design concept, then you
> can branch from GtkAda 2.8 which was GMGPL, or maybe 2.4, I don't remember.
> (In case you will go this path let me know. I am interested in such efforts
> because I maintain the GtkAda contributions project.)
>
> The only goal of a *true* Ada GUI library, IMO, could be a library which
> would have a chance to become a part of the Ada Standard Library. So Gtk is
> just non-starter here. We cannot depend on third-party libraries.
I'm not saying that's how *I* would do it, just how it could be done
for the purists. I personally would sit a tiny C layer below the Ada
GUI lib and interface to that. You only need the UI stuff here.
Anything else that might be needed, file/dir notifications, other OS
stuff can also be abstracted.
If you bypass the native OS you end up with yet another GUI which
doesn't look like the native OS you are using. People don't like that.
Simple.
Luke.
Lucretia
well, because at you abstract level you can do what you like.
wxWidgets do this whith their universal UI target.
This way you have native look and feel and also for embedded targets a
UI that can look anyway you want it to.
Luke.
Lucretia
wrote:
> Dmitry A. Kazakov wrote:
> > Gtk and Qt are themselves thick bindings. It makes no sense to use them as
> > a low-level rendering platform. An all-Ada GUI design should IMO look
> > like:
>
> > Ada GUI library
> > ----------------------------------------
> > Ada rendering platform abstraction layer
> > |
> > Ada | Ada native bindings, engine-specific
> > -------- | -----------------------------
> > X11 | Win32 GUI API
>
> The problem here is that X11 is so very low level - too low level in fact.
> We would have to provide an widget engine first.
Again, see wxWidgets. They also target X11 for targets which only
support that.
Luke.
Dmitry A. Kazakov
Actually this is an independent issue. Nothing prevents us from inheriting
the look-and-feel of the target platform. The look-and-feel should/could
propagate up the layers, provided the design supports look-and-feel
management. IMO it should.
However, weighting look-and-feel and an ability to have a standard library,
I would say that I am ready to sacrifice look-and-feel. After all the
"look-and-feel" of tasking, I/O etc is not one of UNIX or Windows. I would
not shed tears about that. Further, for good or bad, there is not that many
differences as it was before. Today Linux tries to mimic Windows.
Stephen Leake
> Ada GUI Thick bindings
> ------------------------
> Ada GUI Thin bindings
> ------------------------
> C abstraction layer <- Can be provided via C or Ada depending on
> lowest layer
> ------------------------
> X11 | GtkAda | QT
GtkAda is already a thick binding. Surely you meant Win32 there?
--
-- Stephe
Pascal Obry
No, I think Luke meant Gtk+.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Pascal Obry
> Stephen Leake a écrit :
>> Lucretia <lucr...@lycos.co.uk> writes:
>>
>>> Ada GUI Thick bindings
>>> ------------------------
>>> Ada GUI Thin bindings
>>> ------------------------
>>> C abstraction layer <- Can be provided via C or Ada depending on
>>> lowest layer
>>> ------------------------
>>> X11 | GtkAda | QT
>>
>> GtkAda is already a thick binding. Surely you meant Win32 there?
>
> No, I think Luke meant Gtk+.
And the graph should be:
Ada GUI Thick bindings
------------------------
Ada GUI Thin bindings
------------------------
C abstraction layer <- Can be provided via C or Ada
<- depending on lowest layer
------------------------
X11 | Gtk+ | QT
-----------------
X11
------------------------
Michael Bode
> Actually this is an independent issue. Nothing prevents us from inheriting
> the look-and-feel of the target platform. The look-and-feel should/could
> propagate up the layers, provided the design supports look-and-feel
> management. IMO it should.
So what look-and-feel do you use on Linux? Please don't say Athena
Widgets. There are 2 major desktops: KDE (Qt) and Gnome (Gtk). If you
want some kind of 'native' look-and-feel you better choose one of them
and don't forget support for native themes. Even Swing can do that.
> However, weighting look-and-feel and an ability to have a standard library,
> I would say that I am ready to sacrifice look-and-feel.
You won't attract many GUI developers if their apps look crappy with
your lib.
--
No intelligent man has any respect for an unjust law.
He simply follows the eleventh commandment.
-- R.A. Heinlein
Dmitry A. Kazakov
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
>
>> Actually this is an independent issue. Nothing prevents us from inheriting
>> the look-and-feel of the target platform. The look-and-feel should/could
>> propagate up the layers, provided the design supports look-and-feel
>> management. IMO it should.
>
> So what look-and-feel do you use on Linux?
None. Under inheriting I mean an ability to configure look-and-feel rather
than to program it.
Is there much difference between KDE and GNOME left as they rush to embrace
MS Windows? BTW, I enjoyed OPEN LOOK mostly for its professional graphic
design.
>> However, weighting look-and-feel and an ability to have a standard library,
>> I would say that I am ready to sacrifice look-and-feel.
>
> You won't attract many GUI developers if their apps look crappy with
> your lib.
Why should they look that way? Provided the library should specify
look-and-feel. I doubt that but anyway, what prevents anybody educated in
graphic design from designing it professionally? Programmers should keep
their hands off, and everything will be OK! (:-))
Michael Bode
> Is there much difference between KDE and GNOME left as they rush to embrace
> MS Windows? BTW, I enjoyed OPEN LOOK mostly for its professional graphic
> design.
Of course. If you are running Gnome and install theme foo then all your
Gnome/Gtk apps will look fooish. Your Qt apps won't. Except maybe foo
looks like the Qt default. But then changing the Gnome theme to bar
will break that similarity. If you roll your own GUI this will work
with neither KDE nor Gnome. Since KDE and Gnome are probably the most
popular desktops you should get that working with at least one of
them. The last thing Linux needs is another inconsistent (with the rest
of the system) looking GUI. For Windows and OS X things are
easier. Steve tells you how things should look.
> Why should they look that way? Provided the library should specify
> look-and-feel.
Maybe I misunderstood. Who will draw the widgets? Either Ada (the Ada
lib) does it or you leave it to some OS specific GUI layer. Which one?
Lucretia
wrote:
No, I meant it as an option. Like I've already covered in another
post, I personally would just use Gtk and wrap it in abstract C calls
ready for the thick Ada code.
Luke.
Gary Scott
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
>
>
>>Actually this is an independent issue. Nothing prevents us from inheriting
>>the look-and-feel of the target platform. The look-and-feel should/could
>>propagate up the layers, provided the design supports look-and-feel
>>management. IMO it should.
>
>
> So what look-and-feel do you use on Linux? Please don't say Athena
> Widgets. There are 2 major desktops: KDE (Qt) and Gnome (Gtk). If you
> want some kind of 'native' look-and-feel you better choose one of them
> and don't forget support for native themes. Even Swing can do that.
>
>
>>However, weighting look-and-feel and an ability to have a standard library,
>>I would say that I am ready to sacrifice look-and-feel.
>
>
> You won't attract many GUI developers if their apps look crappy with
> your lib.
>
Doesn't seem to be hurting Java...
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Michael Bode
> Doesn't seem to be hurting Java...
They made SWT because of that. And in Java 6 Swing looks very much
like the native GUI including Gtk themes on Linux.
Gary Scott
> Gary Scott <garyl...@sbcglobal.net> writes:
>
>
>>Doesn't seem to be hurting Java...
>
>
> They made SWT because of that. And in Java 6 Swing looks very much
> like the native GUI including Gtk themes on Linux.
>
I suppose my company may be behind, but the latest GUI apps we've
developed, plus a major business app by IBM still look like crap, and
talk about sluggish response.
Dmitry A. Kazakov
> Maybe I misunderstood. Who will draw the widgets? Either Ada (the Ada
> lib) does it or you leave it to some OS specific GUI layer. Which one?
Unspecified. (Who calculates sine, Ada, OS, CPU?)
Stephen Leake
That's what GtkAda already is!
What would you be doing different?
Better to put your energy towards improving GtkAda.
--
-- Stephe
Ben
There is no way to solve all GUI problems in one fell swoop. The
language has too many applications across too many platforms. What
ever approach that is one takes will need to put blinders on to
applications outside the target solution set.
I have a radical idea that may offend a number of readers. Find a
market and create a commercial solution:`)
Ben
Dmitry A. Kazakov
> There is no way to solve all GUI problems in one fell swoop. The
> language has too many applications across too many platforms.
Well, it worked for Java, it did with Gtk and Qt. and C runs on a much
larger number of platforms. Why shouldn't it go with Ada?
> What
> ever approach that is one takes will need to put blinders on to
> applications outside the target solution set.
They will have no other choice. That's basically the MS model of doing
things... (:-))
> I have a radical idea that may offend a number of readers. Find a
> market and create a commercial solution:`)
Huh, there is no market for Ada. In modern software development it is
commercial solutions which create markets, not otherwise... (:-))
Michael Bode
> I suppose my company may be behind, but the latest GUI apps we've
> developed, plus a major business app by IBM still look like crap, and
> talk about sluggish response.
Maybe 'look like crap' is a matter of personal taste. Does this look
like crap for you:
http://www.netbeans.org/images/v6/features/gui-builder.png
or this:
http://www.netbeans.org/images/v6/features/debugger-java.png
I admit it doesn't look like Vista or MSO 2007, but I don't think it
looks like crap.
Gautier
>> market and create a commercial solution:`)
Dmitry A. Kazakov:
> Huh, there is no market for Ada.
Not so long time ago (early 1980s), there was no market for Pascal. One day a
few crazy guys made Turbo Pascal, discovered that there was a market and
developed it, and later made Delphi...
> In modern software development it is
> commercial solutions which create markets, not otherwise... (:-))
Mmmh - do you think to some software companies which are too happy to sell year
after year almost the same crap, but repackaged, to large corporations, which
even lose each year some work months at their own cost for "upgrading" ?
Dmitry A. Kazakov
> Dmitry A. Kazakov:
>
>> Huh, there is no market for Ada.
>
> Not so long time ago (early 1980s), there was no market for Pascal. One day a
> few crazy guys made Turbo Pascal, discovered that there was a market and
> developed it, and later made Delphi...
Right, they first had developed Turbo Pascal and that created a market of
IDEs. Delphi was a "self-reflection" phase when they discovered that the
market came into existence. They targeted that marked with Delphi and
Borland C, and so have ruined their business... The moral is never think,
just do it... (:-))
>> In modern software development it is
>> commercial solutions which create markets, not otherwise... (:-))
>
> Mmmh - do you think to some software companies which are too happy to sell year
> after year almost the same crap, but repackaged, to large corporations, which
> even lose each year some work months at their own cost for "upgrading" ?
This is how it works. We cannot sell Ada. We cannot sell usable software
either. Only cr*p sells well.
(Ada is a conspiracy against customers in order to do them well against
their will... (:-))
Martin Krischik
> Gtk is slow. And after all, there is GtkAda here. If you are prepared to
> buy poor performance of Gtk and its alien to Ada design concept, then you
> can branch from GtkAda 2.8 which was GMGPL, or maybe 2.4, I don't remember.
> (In case you will go this path let me know. I am interested in such efforts
> because I maintain the GtkAda contributions project.)
Try:
http://svn.eu.adacore.com/anonsvn/Dev/trunk
for GMGPL version of GtkAda.
Martin Krischik
I guess we are now at:
+--------------------------------+
| Ada GUI Thick bindings | (4)
+--------------------------------+
| Ada GUI Thin bindings | (3)
---------------------------------+
| Convention C abstraction layer | (2)
+------+--------+-------+--------+
| X11 | Gtk+ | QT | Win32 | (1)
| +--------+-------+ |
| | Win 32 / X11 | |
+-----------------------+--------+
There is just one problem here: Both Gtk+ and QT are OO libraries which
are not all that compatible with the Ada's OO way of live and this in
turn mean that layer (2) and (3) might not be as tiny as we hope for.
Martin Krischik
> I suggest something more pragmatic and feasible: develop further an
> existing library that works fine on Windows (the lion's share in the
> market), but is kind of frozen: GWindows (
> http://sourceforge.net/projects/gnavi ).
GWindows is OK - but it is missing Unix support. But maybe WINE could
help here.
Martin Krischik
> In which direction should it go? Portable means: native widgets on all
> platform (wxWidgets approach) or imitation of these (Swing approach)?
> Do you have any other ideas? Some design suggestions?
I have another suggestion: A GUI Library based on OpenStep [1].
Existing GUI Libraries tend to be rather complex with hundreds of
classes - any binding is a huge work - especially since most GUI
Libraries are OO - and binding to an OO Lib in another language is
difficult. And a job without end as all libraries are constantly extended.
Bare metal programming is only an option for Windows but not X11.
In OpenStep all GUI work is done in Objective-C or Objective-C++ -
languages which can be implemented by a pre-processor to C or C++. So
here the Idea: If we create an Objective-Ada pre-processor we are done.
And the Mac-Ada users would love it ;-).
Martin
[1] http://en.wikipedia.org/wiki/OpenStep
Ludovic Brenta
> Try:
>
> http://svn.eu.adacore.com/anonsvn/Dev/trunk
>
> for GMGPL version of GtkAda.
No. At the time when AdaCore switched licenses, I specifically asked
AdaCore what the licensing terms were for sources in the CVS server
(which is now Subversion). Robert Dewar said it was pure GPL, like
everything on the libre site, even though the source files contain the
"special exception" text. I then suggested they remove the "special
exception" from the sources to reduce confusion, but they never did.
If you don't believe me (I wouldn't take offense as IANAL :) ) then by
all means, please ask AdaCore.
There are two ways to get a GMGPL version of GtkAda nowadays: take the
last GMGPL public release, namely version 2.4, from Debian 3.1 "Sarge"
and a few other places; or ask a paying AdaCore customer for a copy
(yes, this is legal).
--
Ludovic Brenta.
Martin Krischik
> If you don't believe me (I wouldn't take offense as IANAL :) ) then by
> all means, please ask AdaCore.
No, I rather claim ignorance and go by the licence statement in the
source code ;-) .
> There are two ways to get a GMGPL version of GtkAda nowadays: take the
> last GMGPL public release, namely version 2.4, from Debian 3.1 "Sarge"
> and a few other places; or ask a paying AdaCore customer for a copy
> (yes, this is legal).
No need, I work for an AdaCore customer and I have my own gnat tracker
account :-) .
Ludovic Brenta
> I have another suggestion: A GUI Library based on OpenStep [1].
> [1] http://en.wikipedia.org/wiki/OpenStep
Do you mean a reimplementation of the OpenStep specification in Ada,
or an Ada binding to GNUstep (http://www.gnustep.org) ? The latter
would require both the Ada and Objective-C runtime libraries...
--
Ludovic Brenta.
Martin Krischik
> Martin Krischik wrote:
>> I have another suggestion: A GUI Library based on OpenStep [1].
> [...]
>> [1] http://en.wikipedia.org/wiki/OpenStep
>
> Do you mean a reimplementation of the OpenStep specification in Ada,
> or an Ada binding to GNUstep (http://www.gnustep.org) ?
The later. AFAIK GNUStep uses only a small message based dynamically
typed API with a plain C specification. Qt and Gtk+ use huge OO API's in
C++ or some kind of strange OO-C.
To make use of that API easier special languages like Objective-C and
Objective-C++ are used. Those languages can be implemented by a
preprocessor (currently they are not) so I believe creating an
Objective-Ada preprocessor should be possible - especially since Ada
does not use '[' ']' and '@' ;-).
We would not be the first: Google-ing shows that Objective-TCL [1],
Objective-Perl [2] already exists and Objective-Cobol and
Objective-Fortran are rumoured [3] - even talk about Objective-Ada isn't
new [3].
The advantage is that once we have an preprocessor the hole library
becomes available. That's unlike Gtk or Qt where we have to write a
separate binding for each class we want to use and where - forever - we
will be hobbling behind.
> The latter
> would require both the Ada and Objective-C runtime libraries...
Indeed - but that is not different from Gtk+ and Qt approach. And bare
metal is only feasible for Windows but not for X11.
Martin
[1]
http://www.usenix.org/publications/library/proceedings/tcl95/bogdanovich.html
[2] http://www.ddj.com/web-development/184416144
[3] http://lists.apple.com/archives/Cocoa-dev/2001/Sep/msg00947.html
Ludovic Brenta
> Ludovic Brenta schrieb:
>
> > Martin Krischik wrote:
>
> >> I have another suggestion: A GUI Library based on OpenStep [1].
> > [...]
> >> [1] http://en.wikipedia.org/wiki/OpenStep
> >
> > Do you mean a reimplementation of the OpenStep specification in Ada,
> > or an Ada binding to GNUstep (http://www.gnustep.org) ?
>
> The later. AFAIK GNUStep uses only a small message based dynamically
> typed API with a plain C specification. Qt and Gtk+ use huge OO API's in
> C++ or some kind of strange OO-C.
>
> To make use of that API easier special languages like Objective-C and
> Objective-C++ are used. Those languages can be implemented by a
> preprocessor (currently they are not) so I believe creating an
> Objective-Ada preprocessor should be possible - especially since Ada
> does not use '[' ']' and '@' ;-).
An "Objective-Ada" preprocessor is unnecessary because Ada is already
object-oriented, and now even has interfaces similar to Objective-C's
protocols. Therefore, one would only need a binding generator that
would produce Ada specifications with pragma Import statements from
Objective-C specifications. Of course, such a binding generator would
have to know how the particular Objective-C compiler mangles names.
The stumbling blocks would be to implement Objective-C's reflection,
dynamic typing and garbage collection in Ada. In particular,
reflection and dynamic typing are alien to Ada's philosophy.
> We would not be the first: Google-ing shows that Objective-TCL [1],
> Objective-Perl [2] already exists and Objective-Cobol and
> Objective-Fortran are rumoured [3] - even talk about Objective-Ada isn't
> new [3].
That was before Ada 95 added tagged types.
> The advantage is that once we have an preprocessor the hole library
> becomes available. That's unlike Gtk or Qt where we have to write a
> separate binding for each class we want to use and where - forever - we
> will be hobbling behind.
I don't think the preprocessor you speak of would solve anything; the
binding generator might but beware of the stumbling blocks I
mentioned.
> > The latter
> > would require both the Ada and Objective-C runtime libraries...
>
> Indeed - but that is not different from Gtk+ and Qt approach. And bare
> metal is only feasible for Windows but not for X11.
OK, Qt requires a C++ runtime like GNUstep requires an Objective-C
runtime. However, GTK+ only requires the C runtime and that's
intentional: one of the design goals of GTK+ from the onset is to
facilitate bindings to other languages.
--
Ludovic Brenta.
Martin Krischik
> Martin Krischik wrote:
>> Ludovic Brenta schrieb:
>>
>>> Martin Krischik wrote:
>>>> I have another suggestion: A GUI Library based on OpenStep [1].
>>> [...]
>>>> [1] http://en.wikipedia.org/wiki/OpenStep
>>> Do you mean a reimplementation of the OpenStep specification in Ada,
>>> or an Ada binding to GNUstep (http://www.gnustep.org) ?
>> The later. AFAIK GNUStep uses only a small message based dynamically
>> typed API with a plain C specification. Qt and Gtk+ use huge OO API's in
>> C++ or some kind of strange OO-C.
>>
>> To make use of that API easier special languages like Objective-C and
>> Objective-C++ are used. Those languages can be implemented by a
>> preprocessor (currently they are not) so I believe creating an
>> Objective-Ada preprocessor should be possible - especially since Ada
>> does not use '[' ']' and '@' ;-).
>
> An "Objective-Ada" preprocessor is unnecessary because Ada is already
> object-oriented, and now even has interfaces similar to Objective-C's
> protocols. Therefore, one would only need a binding generator that
> would produce Ada specifications with pragma Import statements from
> Objective-C specifications. Of course, such a binding generator would
> have to know how the particular Objective-C compiler mangles names.
Same for C++ - still they created Objective-C++. Read this Article to
see why a static mapping won't make any sense:
http://objc.toodarkpark.net/coreobjc.html#1522
Almost all the work is done by just one function: objc_msgSend. Mind
you, just saw a little problem here. objc_msgSend is the most important
function from OpenStep/GNUStep and it's a vararg function :-| .
> The stumbling blocks would be to implement Objective-C's reflection,
> dynamic typing and garbage collection in Ada. In particular,
> reflection and dynamic typing are alien to Ada's philosophy.
You don't - you use the objc runtime which should provide all those via
plain C functions.
>
>> We would not be the first: Google-ing shows that Objective-TCL [1],
>> Objective-Perl [2] already exists and Objective-Cobol and
>> Objective-Fortran are rumoured [3] - even talk about Objective-Ada isn't
>> new [3].
>
> That was before Ada 95 added tagged types.
:-)
>> The advantage is that once we have an preprocessor the hole library
>> becomes available. That's unlike Gtk or Qt where we have to write a
>> separate binding for each class we want to use and where - forever - we
>> will be hobbling behind.
>
> I don't think the preprocessor you speak of would solve anything; the
> binding generator might but beware of the stumbling blocks I
> mentioned.
But it will solve the biggest problem: the endless amount of methods. A
GUI lib easily got 100 classes. Defining 100 classes is doable - but
each class will have what about 20 methods. Yes 20 is realistic for GUI
lib. That would be 2000 pragma imports - endless work.
But here comes the beauty of OpenStep: all method calls are done by
objc_msgSend.
The Objective-XXX call:
[anObject setOrigin:0.0 :0.0];
becomes:
objc_msgSend (anObject, "setOrigin", 0.0, 0.0);
And yes: that is a string. And no: it's not as slow as you think - there
are caches employed to speed things up.
>>> The latter
>>> would require both the Ada and Objective-C runtime libraries...
>> Indeed - but that is not different from Gtk+ and Qt approach. And bare
>> metal is only feasible for Windows but not for X11.
>
> OK, Qt requires a C++ runtime like GNUstep requires an Objective-C
> runtime. However, GTK+ only requires the C runtime
That might have been the original idea, but soon they needed Glib2 - to
make things easier. And then a few more: ATK, Cairo, Fontconfig,
FreeType, Pango, Poppler, libPNG, libXML, libiconv, librsvg, pkg-config
as of my last counting:
http://gnuada.sourceforge.net/pmwiki.php/Main/PartnerProjects
Of course, you would not notice in Debian as those libs are all part of
the default installation - but you do on for example Solaris.
> and that's
> intentional: one of the design goals of GTK+ from the onset is to
> facilitate bindings to other languages.
Ahh, "design goals" - Well Gtk+ is full of broken promises.
Martin
Ludovic Brenta
I agree that a static mapping doesn't make sense; that's why I was
thinking about a binding generator. A preprocessor that takes Ada
sources with directives and produces Ada sources wouldn't cut it
because one would have to write the input files manually. The only
sensible input is the Objective-C specification files.
> Almost all the work is done by just one function: objc_msgSend. Mind
> you, just saw a little problem here. objc_msgSend is the most important
> function from OpenStep/GNUStep and it's a vararg function :-| .
>
> > The stumbling blocks would be to implement Objective-C's reflection,
> > dynamic typing and garbage collection in Ada. In particular,
> > reflection and dynamic typing are alien to Ada's philosophy.
>
> You don't - you use the objc runtime which should provide all those via
> plain C functions.
No, because you must export callbacks from Ada so the Objective-C
libraries can call them using dynamic typing and reflection. But Ada
does not have dynamic typing or reflection. That's the problem.
> >> The advantage is that once we have an preprocessor the hole library
> >> becomes available. That's unlike Gtk or Qt where we have to write a
> >> separate binding for each class we want to use and where - forever - we
> >> will be hobbling behind.
> >
> > I don't think the preprocessor you speak of would solve anything; the
> > binding generator might but beware of the stumbling blocks I
> > mentioned.
>
> But it will solve the biggest problem: the endless amount of methods. A
> GUI lib easily got 100 classes. Defining 100 classes is doable - but
> each class will have what about 20 methods. Yes 20 is realistic for GUI
> lib. That would be 2000 pragma imports - endless work.
That's the job of the generator.
> But here comes the beauty of OpenStep: all method calls are done by
> objc_msgSend.
>
> The Objective-XXX call:
>
> [anObject setOrigin:0.0 :0.0];
>
> becomes:
>
> objc_msgSend (anObject, "setOrigin", 0.0, 0.0);
>
> And yes: that is a string. And no: it's not as slow as you think - there
> are caches employed to speed things up.
>
> >>> The latter
> >>> would require both the Ada and Objective-C runtime libraries...
> >> Indeed - but that is not different from Gtk+ and Qt approach. And bare
> >> metal is only feasible for Windows but not for X11.
> >
> > OK, Qt requires a C++ runtime like GNUstep requires an Objective-C
> > runtime. However, GTK+ only requires the C runtime
>
> That might have been the original idea, but soon they needed Glib2 - to
> make things easier. And then a few more: ATK, Cairo, Fontconfig,
> FreeType, Pango, Poppler, libPNG, libXML, libiconv, librsvg, pkg-config
> as of my last counting:
>
> http://gnuada.sourceforge.net/pmwiki.php/Main/PartnerProjects
But that is also true of the GNUstep libraries. They call them
"frameworks" and there are several of them.
> Of course, you would not notice in Debian as those libs are all part of
> the default installation - but you do on for example Solaris.
I know. Packaging nicely for your target platforms is important.
--
Ludovic Brenta.
Gautier
> GWindows is OK - but it is missing Unix support. But maybe WINE could
> help here.
Just to make it clear: my idea is not at all to make GWindows the candidate as
the "New Ada portable GUI Library"; my point is that more effort should be given
*now* to GWindows if you want to attract *some time later* enough Ada
programmers for the much more ambitious project of an "Ada portable GUI Library"
(or any other big project, like an "Ada OS"). Such projects seem to me to need
the cooperation of a large number of people. Right now, there is not enough
forces in the Ada community. So, IMHO, for *now*, we need to concentrate on less
ambitious, more targeted and directly useful projects. Perhaps we (including
me!) should spend less time bla-bla-ting on c.l.a., it would not hurt the
progress of our projects...
Phaedrus
GUI is intended to solve? Is it a portable GUI to help professional,
seasoned developers to create portable code? Or, is it a simple, portable
GUI that will allow newbies to get consistent, pleasant results on any
platform? Personally, I'd rather see the second one created, to get more
newbies enthused about the joys of Ada. After all, wasn't someone just
asking for a simple scientific plot mechanism a few threads ago?
Hmmm, where's the requirements spec for this thing? *chuckle*
Cheers!
Brian
"Tomek Walkuski" <tomek.w...@gmail.com> wrote in message
news:6d63c543-0a35-4c39...@i3g2000hsf.googlegroups.com...
> Hi,
>
> someone wrote about need such kind of simple, non-GPL in "The future
> of Ada is at risk" thread.
>
> In which direction should it go? Portable means: native widgets on all
> platform (wxWidgets approach) or imitation of these (Swing approach)?
> Do you have any other ideas? Some design suggestions?
>
> I'm asking because I'm interested in this matter, maybe I will find
> time to start hacking this :)
>
> I'm trying to put first brick, start the discussion, maybe something
> good for the community will emerge?
Jeffrey R. Carter
> This might be a silly question, but what is the problem that this portable
> GUI is intended to solve? Is it a portable GUI to help professional,
> seasoned developers to create portable code? Or, is it a
> platform? Personally, I'd rather see the second one created, to get more
> newbies enthused about the joys of Ada. After all, wasn't someone just
> asking for a simple scientific plot mechanism a few threads ago?
It's a simple, portable GUI that will allow newbies to get consistent, pleasant,
portable results, and help professional, seasoned developers to get consistent,
pleasant, portable results :)
--
Jeff Carter
"Oh Lord, bless this thy hand grenade, that with it thou
mayst blow thine enemies to tiny bits, in thy mercy."
Monty Python and the Holy Grail
24
Phaedrus
breath will be minty-fresh, and your naughty bits will be both naughtier and
bittier...
Does it do anything about death and taxes, too?
Brian
"Jeffrey R. Carter" <spam.jrc...@acm.nospam.org> wrote in message
news:4Sbjj.37216$Ux2.22849@attbi_s22...
Randy Brukardt
news:13oqje6...@corp.supernews.com...
> And you'll get better gas mileage, and your laundry will be 40% whiter,
your
> breath will be minty-fresh, and your naughty bits will be both naughtier
and
> bittier...
Yes, that what we want (well, except for making ones naughty bits itty-bitty
;-).
> It's a simple, portable GUI that will allow newbies to get consistent,
pleasant,
> portable results, and help professional, seasoned developers to get
consistent,
> pleasant, portable results :)
Indeed, that is what we were trying to accomplish with Claw (other than
portability to non-Windows systems). Which only goes to show while it is a
good goal, it isn't easy to accomplish.
OTOH, it really should be the goal, even if it isn't going to get
accomplished. I can't imagine why anyone would want to make something that
will only work for newbies, or has unpleasant results by default, or
whatever. It's better to set the goals high, so that you at least have a
chance to get near them.
Randy.
Phaedrus
the big one. Does everything, even has a pen built in. Lots and lots of
tools, but it isn't actually a very good tool. It's heavy, and it's a
terrible knife. By trying to hit so many targets it's achieved a sort of
cult status, but I wouldn't want to have to use it for anything other than
emergencies.
Sounds to me like you're trying to hit a similar target, and I suspect
you'll have the same kind of results. If it's simple enough for newbies
it'll be much too limited for the pro's, and anything that the pro's would
appreciate would be over the head of the newbies. Remember, even having too
many packages or too many functions/procedures/types in a spec can be enough
to turn the young-un's away.
A tool should be simple and coherent in design, easily described and
intuitive to the user. That's why I suggested targeting something like the
turtle graphics of GUI, with two words you've got a clear understanding of
it. Oh, and it doesn't hurt if it's appealing to the masses, too!
(Wouldn't it be great if people thought of Ada as the EASY, PAINLESS way to
develop apps?)
Brian
"Randy Brukardt" <ra...@rrsoftware.com> wrote in message
news:fmjlg7$n36$1...@jacob-sparre.dk...
Brian May
Martin> There is just one problem here: Both Gtk+ and QT are OO libraries which
Martin> are not all that compatible with the Ada's OO way of live and this in
Martin> turn mean that layer (2) and (3) might not be as tiny as we hope for.
I am curious - in what why are they not compatible?
--
Brian May <b...@snoopy.apana.org.au>
tmo...@acm.org
> help here.
Martin Krischik
> Martin Krischik wrote:
>> Ludovic Brenta schrieb:
>>
>>> Martin Krischik wrote:
>>>> Ludovic Brenta schrieb:
>>>>
>>>>> Martin Krischik wrote:
>>>>>> I have another suggestion: A GUI Library based on OpenStep [1].
>>>>> [...]
>>>>>> [1] http://en.wikipedia.org/wiki/OpenStep
>>>>> Do you mean a reimplementation of the OpenStep specification in Ada,
>>>>> or an Ada binding to GNUstep (http://www.gnustep.org) ?
>>>> The later. AFAIK GNUStep uses only a small message based dynamically
>>>> typed API with a plain C specification. Qt and Gtk+ use huge OO API's in
>>>> C++ or some kind of strange OO-C.
> I agree that a static mapping doesn't make sense; that's why I was
> thinking about a binding generator. A preprocessor that takes Ada
> sources with directives and produces Ada sources wouldn't cut it
> because one would have to write the input files manually. The only
> sensible input is the Objective-C specification files.
I see what you mean - and probably we would need both. I might aim high
but I believe full integration should be the aim. And that means that
class B written in Objective-Ada inherits from Class A written in
Objective-C and Class C written in Objective-C++ inherits from Class B.
Now I believe neither GtkAda nor QtAda currently offer that kind of support.
>>> The stumbling blocks would be to implement Objective-C's reflection,
>>> dynamic typing and garbage collection in Ada. In particular,
>>> reflection and dynamic typing are alien to Ada's philosophy.
>> You don't - you use the objc runtime which should provide all those via
>> plain C functions.
> No, because you must export callbacks from Ada so the Objective-C
> libraries can call them using dynamic typing and reflection. But Ada
> does not have dynamic typing or reflection. That's the problem.
Neither had C or C++ - that is all done by the (now build in) preprocessor.
>> But it will solve the biggest problem: the endless amount of methods. A
>> GUI lib easily got 100 classes. Defining 100 classes is doable - but
>> each class will have what about 20 methods. Yes 20 is realistic for GUI
>> lib. That would be 2000 pragma imports - endless work.
>
> That's the job of the generator.
Yes - which might use reflection to get the data needed.
>>>>> would require both the Ada and Objective-C runtime libraries...
>>>> Indeed - but that is not different from Gtk+ and Qt approach. And bare
>>>> metal is only feasible for Windows but not for X11.
>>> OK, Qt requires a C++ runtime like GNUstep requires an Objective-C
>>> runtime. However, GTK+ only requires the C runtime
>> That might have been the original idea, but soon they needed Glib2 - to
>> make things easier. And then a few more: ATK, Cairo, Fontconfig,
>> FreeType, Pango, Poppler, libPNG, libXML, libiconv, librsvg, pkg-config
>> as of my last counting:
>>
>> http://gnuada.sourceforge.net/pmwiki.php/Main/PartnerProjects
>
> But that is also true of the GNUstep libraries. They call them
> "frameworks" and there are several of them.
Yep. I guess all of them, Gtk+, Qt, GNUstep and indeed Win32 are
Runtimes of there own. Either we use one of those - or we create our
very own all in Ada - which brings us very quickly to AdaOS ;-) .
Dmitry A. Kazakov
>>>>>> "Martin" == Martin Krischik <kris...@users.sourceforge.net> writes:
>
> Martin> There is just one problem here: Both Gtk+ and QT are OO libraries which
> Martin> are not all that compatible with the Ada's OO way of live and this in
> Martin> turn mean that layer (2) and (3) might not be as tiny as we hope for.
>
> I am curious - in what why are they not compatible?
In Gtk+ there is a notion of class (of widgets for example). The class has
properties and signals. An instance of that class inherits them from the
class. So far so good. But this types system of Gtk+ is dynamic and weakly
typed. (You can send any parameters you want)
The incompatibility is firstly dynamic/weak Gtk+ with static/strong Ada
and, secondly, it has an implementation of its own. Less important, but
also incompatible: the messaging in Gtk+ is asynchronous in its interface
while synchronous in implementation. (The worst possible combination, BTW)
In Ada's OO messaging is all synchronous, concurrency is outside Ada's OO
model.
Martin Krischik
>>>>>> "Martin" == Martin Krischik <kris...@users.sourceforge.net> writes:
>
> Martin> There is just one problem here: Both Gtk+ and QT are OO libraries which
> Martin> are not all that compatible with the Ada's OO way of live and this in
> Martin> turn mean that layer (2) and (3) might not be as tiny as we hope for.
>
> I am curious - in what why are they not compatible?
First of all: all OO systems are incompatible. Sad but true. They use
different name mangler, different class tags (also called virtual
function tables) and so on.
In detail:
Qt: is written in C++. One could use Convention => Cpp to make all those
classes available. But Convention => Cpp is not part if the RM, seldom
used (meaning: badly tested) and difficult to use - but at least the
result behaves like normal tagged types and is pragma Export capable.
Gtk+: Used some OO layer on top of C. Using C make import to Ada easier
- but just importing the functions won't make the tagged type and you
create the tagged types proxys then they won't be pragma Export capable.
Note that I am not only speaking about importing an existing class
library but also about enhancing/inheriting from it and then exporting
the new enhancements back.
Note also: I did not say "totally incompatible". With enough effort it
is possible.
You might have also noticed the OpenStep discussion. With OpenStep one
does not even try make anything compatible - OpenStep approach is to add
a 2nd dynamically typed OO system in parallel - similar to Objective-C++.
Martin Krischik
>> GWindows is OK - but it is missing Unix support. But maybe WINE could
>> help here.
> IIRC from some years ago, someone used WINE with CLAW successfully.
And WINE is quite fast these days - so that would be an option.
I. Levashew
> Both Gtk+/GtkAda and Qt/QtAda are portable. They work on UNIX/Linux,
> MS Windows, Mac OS. So, this is not an advantage.
Qt programs are aliens on Mac OS X. They differ from "normal" programs.
Currently there are two general GUI APIs on Mac OS X: Carbon and Cocoa.
Everybody favors Cocoa over Carbon. And Qt is worse than Carbon. And
GTK+ does not even run on Mac OS X directly, only in X11. X11 in Mac OS
X is even worse than Qt (which is worse than Carbon which is worse than
Cocoa). No drag&drop, no window grouping (Expose). Each X11 window
belong to X11.app. No own main menu. Neither Qt nor GTK+ provide user
experience competeable with Cocoa. Users tend to favor Cocoa
applications over Carbon, etc. based. And there is no Cocoa binding yet.
There is a good news about Cocoa. Apple started BridgeSupport project
easing interfacing Cocoa to other languages.
Thus we have 2 projects: SWIG and BridgeSupport. They cover huge amount
of code. Both ones don't support Ada currently (at least BS). But if
they will...
tmo...@acm.org
>different name mangler, different class tags (also called virtual
>function tables) and so on.
pragma Imports, a program can read a typelib (Windows) and produce
Ada code. I did that for the Google Earth API. David Botton did
that and IIRC his program is available from AdaCore.
But if you want to make something really helpful to an Ada programmer,
you need to create a thick binding design that has classes, tasks,
exceptions, etc that "fits" Ada so you aren't just writing C code in Ada
syntax, and you need to learn about the ins-and-outs-and bugs in the C
code you are going to call, so your Ada binding can be well-specified and
implement what it says it implements. It takes a lot of work, there are
more people creating new C APIs than there are Ada programmers to design
bindings for them, and there's very little market. Why do you suppose
that of the multiple Windows etc Ada thick bindings, so few are still
actively supported?
Gautier
Speaking of CLAW, I tried the demo
http://www.rrsoftware.com/html/prodinf/claw/clawintro.html
with some recent GNAT's (post-3.15p, like GPL 2006 and 2007);
the binder sees an elaboration circularity - do you know if it there is a
solution for GNAT's support in the release version ?
Randy Brukardt
news:478e5c18$1...@news.bluewin.ch...
> tmo...@acm.org wrote:
> >> GWindows is OK - but it is missing Unix support. But maybe WINE could
> >> help here.
> > IIRC from some years ago, someone used WINE with CLAW successfully.
>
> Speaking of CLAW, I tried the demo
>
> http://www.rrsoftware.com/html/prodinf/claw/clawintro.html
>
> with some recent GNAT's (post-3.15p, like GPL 2006 and 2007);
> the binder sees an elaboration circularity - do you know if it there is a
> solution for GNAT's support in the release version ?
Yes, that's fixed in the current beta version of Claw, and will be fixed
everywhere when I get a round tuit. (Unfortunately, the supply of round
tuits are very limited, and I have a lot of tasks requiring one...)
-gnatE works fine with the demo. Strictly speaking, Gnat is not an Ada
compiler without using that option, as it rejects legal Ada programs - like
the Claw demo. (But I realize that most newbie programmers aren't likely to
understand the distinction).
Randy.
I. Levashew
> I have another suggestion: A GUI Library based on OpenStep [1].
>
> Existing GUI Libraries tend to be rather complex with hundreds of
> classes - any binding is a huge work - especially since most GUI
> Libraries are OO - and binding to an OO Lib in another language is
> difficult. And a job without end as all libraries are constantly extended.
As of Leopard Apple started providing BridgeSupport XML files. It's not
an endless job now. It's a virtually one-time job.
> here the Idea: If we create an Objective-Ada pre-processor we are done.
> And the Mac-Ada users would love it ;-).
Why do we need a preprocessor? It'll hurt ability of manipulating source
code with 3rd party utilities. I'm Mac-Ada user, and I'm definitelly not
going to love it. It is opposed to Ada spirit.
I think Objective-C on Mac OS X should be dealt with the same way as COM
on Windows; on Mac OS X we'll just use BridgeSupport XML instead of IDL.
Martin Krischik
> Martin Krischik пишет:
>> I have another suggestion: A GUI Library based on OpenStep [1].
>>
>> Existing GUI Libraries tend to be rather complex with hundreds of
>> classes - any binding is a huge work - especially since most GUI
>> Libraries are OO - and binding to an OO Lib in another language is
>> difficult. And a job without end as all libraries are constantly
>> extended.
>
> As of Leopard Apple started providing BridgeSupport XML files. It's not
> an endless job now. It's a virtually one-time job.
I am not Mac user so I did did not know about BridgeSupport. Now I
looked it up and While BridgeSupport sounds good - will it work with
GNUStep as well.
Note that the Discussion is about a portable library which should work
at least on Windows/Linux/Mac.
>> here the Idea: If we create an Objective-Ada pre-processor we are done.
>> And the Mac-Ada users would love it ;-).
> Why do we need a preprocessor? It'll hurt ability of manipulating source
> code with 3rd party utilities. I'm Mac-Ada user, and I'm definitelly not
> going to love it. It is opposed to Ada spirit.
I though you would love it because it is the only proposal which will
give Mac users cocoa support. To remind you, the other options are:
GWindows: Native on Windows [1], emulated with Wine on Linux and Mac.
GtkAda: Native on Linux, emulated with MinGW in Windows, Carbon based on
Mac.
QtAda: Native on Linux and Windows [1], X11.app based Mac.
AdaStep [2]: Native on Mac (Cocoa) and Linux (GNUStep) emulated with
MinGW on Windows.
[1] Of course GNAT is based on MinGW - so MinGW will always be part of
any Windows Tool Chain - it's just the GUI which I consider native and I
might be wrong.
[2] Just invented that name ;-) .
> I think Objective-C on Mac OS X should be dealt with the same way as COM
> on Windows; on Mac OS X we'll just use BridgeSupport XML instead of IDL.
You seem to be a Mac user so I trust you on that. And parsing an XML
file should be a lot easier then anything else - which is good
considering our limited resources. Just the "Will it word with GNUStep?"
question is left.
Martin
Ivan Levashew
> I am not Mac user so I did did not know about BridgeSupport. Now I
> looked it up and While BridgeSupport sounds good - will it work with
> GNUStep as well.
>
> Note that the Discussion is about a portable library which should work
> at least on Windows/Linux/Mac.
SWIG can provide access to wxWidgets and a lot of other stuff. TASH can
also be considered. May be Visual Ada Designer can be ported to Mac OS
X. Tcl/Tk on Mac OS X has some i18n issues. The same as X11. User can't
change keyboard layout via hotkeys (Command-Space usually). The only way
to change layout in X11 apps is to use Input Menu (similar to Language
Bar in Windows). Constantly clicking while typing is inconvenient for
non-English users so X11 (and Tcl/Tk) applications are very unpopular.
But it is solveable. I've maid a patch for Apple X11 to enable hotkeys
and the same could probably be done for Wish Shell.
> I though you would love it because it is the only proposal which will
> give Mac users cocoa support.
I don't think mixing semantics is a good idea. It's OK for C languages
family to be a frankenstein, but not for Ada.
> AdaStep [2]
> [2] Just invented that name ;-) .
An absolutely blank project already exists on Google Code called Cocoa-GNAT.
> Just the "Will it word with GNUStep?" question is left.
Provided that:
a. Cocoa is a superset of OpenStep
b. BridgeSupport files are automatically generated from headers
One might try to either get a subset of Cocoa metainfo or use modified
generator on GNUStep headers.
FYI: Tiger's BridgeSupport files:
http://octagram.gorodok.net/Tiger_BS.tar.bz2 (110Kb)
Martin Krischik
>> I though you would love it because it is the only proposal which will
>> give Mac users cocoa support.
>
> I don't think mixing semantics is a good idea. It's OK for C languages
> family to be a frankenstein, but not for Ada.
;-)
>> Just the "Will it word with GNUStep?" question is left.
> Provided that:
> a. Cocoa is a superset of OpenStep
> b. BridgeSupport files are automatically generated from headers
>
> One might try to either get a subset of Cocoa metainfo or use modified
> generator on GNUStep headers.
Is the generator available as source? Or would we have to find a Mac
user to run the generator for us non-Mac-users.
> FYI: Tiger's BridgeSupport files:
> http://octagram.gorodok.net/Tiger_BS.tar.bz2 (110Kb)
I have a look
Gautier
I guess that even seasoned Ada programmers using GNAT don't wake up each morning
saying "Oh, without -gnatE, GNAT is not an Ada compiler legally speaking.
G'morning, Darling, by the way".
Cheers
Gautier
Robert A Duff
> Ah, so it was just a question of switching -gnatE !!
> I guess that even seasoned Ada programmers using GNAT don't wake up each
> morning saying "Oh, without -gnatE, GNAT is not an Ada compiler legally
> speaking. G'morning, Darling, by the way".
:-)
If you develop code from scratch, you probably don't want -gnatE.
GNAT will impose some fairly minor restrictions on you,
and in return you get a statically determined elaboration
order that will work, and you don't have to mess around
with the various elaboration control pragmas. And you
can avoid the run-time overhead of elaboration checks on
every call.
If you also want to port to non-GNAT compilers, there's an option in
GNAT that will tell you where to put those pragmas. It's nearly
impossible to do it correctly without that help!
If you have code developed on a non-GNAT compiler, then you might well
want -gnatE. On the other hand, you might want to fix the code so it
works without -gnatE, but that can be a lot of work!
If anybody is confused about elaboration, there's a long section in the
GNAT User's Guide that explains it all quite nicely (much more clearly
than the Ada RM!).
- Bob
Ivan Levashew
> Is the generator available as source?
Homepage of Tiger version:
http://trac.macosforge.org/projects/bridgesupport
It is said that releases will include generated XML files. However there
is no any release yet.
Sources (Ruby)&manpages:
http://trac.macosforge.org/projects/BridgeSupport/browser/trunk
In Leopard BridgeSupport is built-in. I don't know if it's publicly
available. It should be, it was part of RubyCocoa. Recent versions of
RubyCocoa don't include generator (gen_bridge_metadata.rb) and I don't
know where to look for newer versions online.
Martin Krischik
> Martin Krischik пишет:
>> Is the generator available as source?
> Yes, it is.
>
> Homepage of Tiger version:
> http://trac.macosforge.org/projects/bridgesupport
Wow - just a mere 2000 lines of Ruby code. I am surprised. And it comes
with a dtd as well.
tmo...@acm.org
> GNAT will impose some fairly minor restrictions on you,
> and in return you get a statically determined elaboration
> order that will work, and you don't have to mess around
> with the various elaboration control pragmas. And you
> can avoid the run-time overhead of elaboration checks on
> every call.
Robert A Duff
>> If you develop code from scratch, you probably don't want -gnatE.
>> GNAT will impose some fairly minor restrictions on you,
>> and in return you get a statically determined elaboration
>> order that will work, and you don't have to mess around
>> with the various elaboration control pragmas. And you
>> can avoid the run-time overhead of elaboration checks on
>> every call.
tmo...@acm.org writes:
> Does that mean the designers of Ada's elaboration got it wrong?
Yes.
- Bob
Pascal Obry
> tmo...@acm.org writes:
>
>> Does that mean the designers of Ada's elaboration got it wrong?
>
> Yes.
Hum not sure why! My understanding is that GNAT defaults to something
stricter and more importantly static, fine. But having a dynamic
elaboration that let's you handle more complicated cases does not hurt
to me!
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
Jerrid Kimball
I've posed myself this question: Why don't those who have a vested
(commercial) interest in Ada develop the toolkit. After all, it is
expected the relatively small group of Ada FOSS developers to untake
such a monumental project.--Not that it isn't possible, but it also
seems that with such interest in such a project, AdaCore would more
than benefit from offering support for such a project as well as
expanding the reach of Ada which, in turn, would benefit AdaCore even
more so.
Jerrid
Ludovic Brenta
What you propose has already happened: http://libre.adacore.com/GtkAda
(even the support part).
The no-cost version is under pure GPL. The commercially supported
version is under GMGPL. This is a problem for people who would like
to distribute proprietary software linked with GtkAda but are
unwilling or unable to pay AdaCore for the GMGPL version that would
allow them to do that. The whole thread was about creating an
alternative for these people.
Personally, I'm happy with GtkAda.
--
Ludovic Brenta.
Stephen Leake
> With all this interest in developing a portable GUI toolkit for Ada,
> I've posed myself this question: Why don't those who have a vested
> (commercial) interest in Ada develop the toolkit.
They are; AdaCore maintains GtkAda.
--
-- Stephe
Andre
Maybe a bit late (after reading all the messages on c.l.a.), but what
should be in such a portable GUI?
There is the basic functionality like handling windows, dialogs,
buttons, menus, etc.
But there is also a lot more which you can share under the GUI. Some
examples (note I'm Windows user and did some contributions to GWindows):
- functional dialogs like: file open, pick a directory, choose a color
- keyboard and mouse handling
- what about Human Interface Devices (HID) like joysticks
- displaying (or even loading) images
- using embeded objects like an RTF based editor, IE or firefox for
embeded HMTL and stuff like that
As soon as you need the more OS specific extended GUI functionality, the
binding (to the OS library, which is mostly C) gets more complex. And
this will be in general also not easy portable to an other OS.
So be carefull with a portable GUI, before you know you are building a
library which is a combination of all know emulators (MinGW, Wine)
Tomek Walkuski wrote:
> Hi,
>
> someone wrote about need such kind of simple, non-GPL in "The future
> of Ada is at risk" thread.
>
> In which direction should it go? Portable means: native widgets on all
> platform (wxWidgets approach) or imitation of these (Swing approach)?
> Do you have any other ideas? Some design suggestions?
>
> I'm asking because I'm interested in this matter, maybe I will find
> time to start hacking this :)
>
> I'm trying to put first brick, start the discussion, maybe something
> good for the community will emerge?
Dmitry A. Kazakov
We cannot know it, but I guess it could be no less expensive than to
develop a portable GUI from scrap. Of course I count the expenses of making
and maintaining GPS in GtkAda, rather than based on a more Ada-friendly
library.
Anyway it is too late for AdaCore now to jump out the train running at full
speed. There certainly are others who are developing GUI toolkits, alas
targeted to specific platforms and needs. It is no wonder, first when Ada
gains more audience on the main stream platforms, the situation will
change.
Robert A Duff
> Robert A Duff a écrit :
>> tmo...@acm.org writes:
>>
>>> Does that mean the designers of Ada's elaboration got it wrong?
>> Yes.
>
> Hum not sure why!
Well, there are several problems with Ada's elaboration rules.
Perhaps the biggest is that elaboration order is implementation
defined. You can have a program that works just fine on one
implementation of Ada, but it breaks when you try to port it
to another implementation. Fixing the problem is a nightmare,
because it's difficult to know where to put the various
pragmas (GNAT can help here!), and circularity messages
are confusing (in every compiler I've tried!), and every
time you add a pragma you have to recompile a whole
lot of stuff.
There are cases where languages should allow implementations to differ:
where there is some efficiency advantage to leaving things ill-defined,
or where there is some legitimate need to access hardware or other
platform-dependent details. Elaborate order is not such a case!
Another problem is that it's too complicated. All those pragmas
(Elaborate, Elaborate_All, Preelaborate, Pure, Elaborate_Body,
Preelaborable_Initialization, ... -- did I forget any?).
Another problem is that it's too restrictive. For example,
you can't say:
function Make_Symbol(X: String) return Symbol;
Empty_Symbol: constant Symbol := Make_Symbol("");
in a package visible part, because of the way elaboration works.
Another problem is efficiency: the Ada rules require a run-time check on
every call, and it's hard to optimize away those checks in cases
involving separate compilation.
>... My understanding is that GNAT defaults to something
> stricter and more importantly static, fine. But having a dynamic
> elaboration that let's you handle more complicated cases does not hurt
> to me!
The cases where the GNAT default is too restrictive, but the Ada rule
(i.e. GNAT's -gnatE switch) is not too restrictive, are rare. I think
I've run into such cases approximately twice in the last 10 years.
And I think they were related to generics (the problem is that
instance bodies are elaborate too early -- it's particularly
annoying when the generic body doesn't do anything, which is
common).
It's a trade-off, but I think the GNAT default improves on the standard
Ada model. It doesn't solve all the problems, though.
On the other hand, the standard Ada model is better than some languages,
where you can't do anything interesting at elaboration time (so you have
to complicate your interfaces with Initialize procedures). Or languages
that don't bother to detect cycles at all (you can start using data in a
class if the class initialization has _started_, not necessarily
_finished_).
Self-initializing modules is a Good Idea. But Ada got some of the
details wrong.
- Bob
Frederik Sausmikat
> I'm asking because I'm interested in this matter, maybe I will find
> time to start hacking this :)
>
Hi,
I'd like to recommend the FLTK GUI library (http://www.fltk.org) as
a good basis for such a project. It's very small in size and easy to
use. Although it is written in C++ it uses a very C-ish style and
omits the more 'advanced' C++ features which should make it easy to
create an Ada binding (given it's small size it would even be
manageable to transform it into an Ada project). It is cross
platform (runs on X11, Win32 and MacOS, no native widgets however)
and is licensed under the LGPL (modified to allow for static linking).
FLTK also comes with Fluid, a very nice GUI designer, which stores
the form data in a textual meta format, so it would be possible to
create Ada code from it (one could even teach Fluid to create Ada code).
There are some video introductions on programming with FLTK (Flash
needed):
http://seriss.com/people/erco/fltk-videos/
They are ment as tutorials for beginners but may give you an overview.
If you want to give it a test drive, be sure to grab the latest
1.1.x snapshot from the website. There has been a lot of maintenance
and bugfixing since the 1.1.7 release.
Regards, Freddy
--
Of course it runs NetBSD - http://www.netbsd.org
Lucretia
stuck with (http://wxada.tigris.org/). I thought I'd post it to the
end of this rather than start a new topic.
I thought i'd post a link here just in case there is interest. The
topic just cam up on IRC again and there are 2 main problems:
1) wxValidator is derived from wxEvtHandler which in turn is derived
from wxObject; the wxEvtHandler is a non-copyable object yet the
others are copyable.
2) The link between the C++ and the Ada side in relation to events is
dubious and can crash the app. The C++ instance needs a pointer to the
Ada instance and vice-versa.
Luke.
Gary Scott
Reccommend that people convince Bradly Assoc. to add Ada bindings for
Gino. I asked them once and they implied willingness if there was
sufficient market for it. They have bindings for C, Delphi, VB,
Fortran, and a couple of .net implementations. http://www.gino-graphics.com
--
Gary Scott
mailto:garylscott@sbcglobal dot net
Fortran Library: http://www.fortranlib.com
Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html
If you want to do the impossible, don't hire an expert because he knows
it can't be done.
-- Henry Ford
Martin
> would have a chance to become a part of the Ada Standard Library. So Gtk is
> just non-starter here. We cannot depend on third-party libraries.
I would have thought there is zip-all chance of an Ada GUI
implementation library becoming part of the standard - I just can't
imagine how that would be worded in the standard!
A slightly better chance might be to define an interface to a GUI
library.
Cheers
-- Martin
Martin Krischik
>> The only goal of a *true* Ada GUI library, IMO, could be a library which
>> would have a chance to become a part of the Ada Standard Library. So Gtk
>> is just non-starter here. We cannot depend on third-party libraries.
>
> I would have thought there is zip-all chance of an Ada GUI
> implementation library becoming part of the standard - I just can't
> imagine how that would be worded in the standard!
Indeed :-( - and sadly - after all AWT did give Java the edge. Yes, Swing
and SWT replaced it - but AWT was the door opener.
> A slightly better chance might be to define an interface to a GUI
> library.
The AWT too was/is a binding to the native GUI library. Which reminds me:
What GUI library was/is used for AWT on Unix?
Tomek Walkuski
wrote:
> The AWT too was/is a binding to the native GUI library. Which reminds me:
> What GUI library was/is used for AWT on Unix?
>