Re: Weakness of Ada is expensive / security / etc. ? Anything else?

[NiGHTS <nights@unku.us>]

> Label text wrapping may depend on the widget size requisition. So you
> should set the label size explicitly. It could be a GTK bug as well,
> because it is highly unlikely that anybody would use that for text
> rendering, there is Gtk_Text_View for that. And because GTK 3 reworked most
> of widget sizing.

It affects things like tooltips (built in) and various other things that inherently use labels. I've explicitly set widths to all inherited widgets including the label itself and this had no effect. I made sure Word wrapping was enabled and followed all correct guidelines on the subject. Again it works in Windows, just not in Linux.


> GTK is full of bugs, especially GTK 3. But that has nothing to do with Ada.

I am not blaming Ada. Its a beautiful language. I merely suspect that GtkAda's thick bindings have something to do with it. I am not dismissing the possibility that GTK 3 is also at fault, but in my mind I feel that the GTK core library is probably more tested than GTKAda (A misconception maybe? I would love to be wrong about this.)


> Style is much more than colors. All widget style properties can be changed.
> 

Well you were talking about "themes", and no doubt styles involve both color and structure. On that note I am quite disappointed by how limited the GTK CSS support is with regards to things like setting margins and other structural parameters. They simply don't work. I can only use the CSS to define colors, fonts, and backgrounds. I've been forced to hard code structural things like margins which I feel is bad form as it should belong in the style sheet.


> There is GtkAda mail list.
> 

I've looked and couldn't find it. I would love to know what the address is if you don't mind me asking.


> I cannot tell anything for that, I never used it. I dropped using
> DB-specific bindings a decade ago. ODBC does the job. There is no serious
> reasons to use DB-specific bindings.

GNATCOLL's database library was not designed to be DB-Specific. From what I understand of their design philosophy is that they are offering an strongly-typed Ada-esque approach to work with SQL queries and other common database tasks using a common seamless API. They only support two databases currently but it was designed to support whatever database is needed for the job. If done correctly you should be able to switch databases without changing code in GNATCOLL. It would have been nice to have added support for ODBC, but the GNATCOLL is designed to facilitate interfacing to anything including ODBC.

I fell in love with the GNATCOLL SQL philosophy. Unfortunately the designers have not done a good job of generating interest in the project. In my case I can't get any support whatsoever with using that library and it seems like no one here takes it seriously. Its a shame.