* Easiest way to build Qt/Gtk interfaces for Ada programs @ 2012-12-28 14:51 alb348 2012-12-28 15:32 ` Dmitry A. Kazakov ` (4 more replies) 0 siblings, 5 replies; 38+ messages in thread From: alb348 @ 2012-12-28 14:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 14:51 Easiest way to build Qt/Gtk interfaces for Ada programs alb348 @ 2012-12-28 15:32 ` Dmitry A. Kazakov 2012-12-28 17:30 ` alb348 ` (2 more replies) 2012-12-28 16:20 ` Vadim Godunko ` (3 subsequent siblings) 4 siblings, 3 replies; 38+ messages in thread From: Dmitry A. Kazakov @ 2012-12-28 15:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 15:32 ` Dmitry A. Kazakov @ 2012-12-28 17:30 ` alb348 2012-12-28 17:57 ` Dmitry A. Kazakov 2012-12-29 0:18 ` Yannick Duchêne (Hibou57) 2012-12-29 0:27 ` Randy Brukardt 2 siblings, 1 reply; 38+ messages in thread From: alb348 @ 2012-12-28 17:30 UTC (permalink / raw) Cc: mailbox >> 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? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 17:30 ` alb348 @ 2012-12-28 17:57 ` Dmitry A. Kazakov 0 siblings, 0 replies; 38+ messages in thread From: Dmitry A. Kazakov @ 2012-12-28 17:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 15:32 ` Dmitry A. Kazakov 2012-12-28 17:30 ` alb348 @ 2012-12-29 0:18 ` Yannick Duchêne (Hibou57) 2012-12-29 9:26 ` Dmitry A. Kazakov 2012-12-29 0:27 ` Randy Brukardt 2 siblings, 1 reply; 38+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-12-29 0:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 0:18 ` Yannick Duchêne (Hibou57) @ 2012-12-29 9:26 ` Dmitry A. Kazakov 2012-12-29 10:39 ` Yannick Duchêne (Hibou57) 0 siblings, 1 reply; 38+ messages in thread From: Dmitry A. Kazakov @ 2012-12-29 9:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 9:26 ` Dmitry A. Kazakov @ 2012-12-29 10:39 ` Yannick Duchêne (Hibou57) 2012-12-29 12:27 ` Dmitry A. Kazakov 0 siblings, 1 reply; 38+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-12-29 10:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 10:39 ` Yannick Duchêne (Hibou57) @ 2012-12-29 12:27 ` Dmitry A. Kazakov 2012-12-29 13:07 ` Georg Bauhaus 2012-12-29 13:09 ` Yannick Duchêne (Hibou57) 0 siblings, 2 replies; 38+ messages in thread From: Dmitry A. Kazakov @ 2012-12-29 12:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 12:27 ` Dmitry A. Kazakov @ 2012-12-29 13:07 ` Georg Bauhaus 2012-12-29 13:26 ` Yannick Duchêne (Hibou57) 2012-12-29 13:09 ` Yannick Duchêne (Hibou57) 1 sibling, 1 reply; 38+ messages in thread From: Georg Bauhaus @ 2012-12-29 13:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 13:07 ` Georg Bauhaus @ 2012-12-29 13:26 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 38+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-12-29 13:26 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 12:27 ` Dmitry A. Kazakov 2012-12-29 13:07 ` Georg Bauhaus @ 2012-12-29 13:09 ` Yannick Duchêne (Hibou57) 1 sibling, 0 replies; 38+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-12-29 13:09 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 15:32 ` Dmitry A. Kazakov 2012-12-28 17:30 ` alb348 2012-12-29 0:18 ` Yannick Duchêne (Hibou57) @ 2012-12-29 0:27 ` Randy Brukardt 2012-12-29 1:02 ` Georg Bauhaus 2 siblings, 1 reply; 38+ messages in thread From: Randy Brukardt @ 2012-12-29 0:27 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 0:27 ` Randy Brukardt @ 2012-12-29 1:02 ` Georg Bauhaus 2012-12-29 2:10 ` Yannick Duchêne (Hibou57) 2012-12-29 8:55 ` Dmitry A. Kazakov 0 siblings, 2 replies; 38+ messages in thread From: Georg Bauhaus @ 2012-12-29 1:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 1:02 ` Georg Bauhaus @ 2012-12-29 2:10 ` Yannick Duchêne (Hibou57) 2012-12-29 8:55 ` Dmitry A. Kazakov 1 sibling, 0 replies; 38+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-12-29 2:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 1:02 ` Georg Bauhaus 2012-12-29 2:10 ` Yannick Duchêne (Hibou57) @ 2012-12-29 8:55 ` Dmitry A. Kazakov 1 sibling, 0 replies; 38+ messages in thread From: Dmitry A. Kazakov @ 2012-12-29 8:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 14:51 Easiest way to build Qt/Gtk interfaces for Ada programs alb348 2012-12-28 15:32 ` Dmitry A. Kazakov @ 2012-12-28 16:20 ` Vadim Godunko 2012-12-28 19:56 ` alb348 2012-12-28 17:58 ` Justin Time ` (2 subsequent siblings) 4 siblings, 1 reply; 38+ messages in thread From: Vadim Godunko @ 2012-12-28 16:20 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 16:20 ` Vadim Godunko @ 2012-12-28 19:56 ` alb348 2012-12-28 20:38 ` Justin Time 0 siblings, 1 reply; 38+ messages in thread From: alb348 @ 2012-12-28 19:56 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 19:56 ` alb348 @ 2012-12-28 20:38 ` Justin Time 2012-12-28 20:52 ` alb348 0 siblings, 1 reply; 38+ messages in thread From: Justin Time @ 2012-12-28 20:38 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 20:38 ` Justin Time @ 2012-12-28 20:52 ` alb348 2012-12-29 0:48 ` Randy Brukardt 0 siblings, 1 reply; 38+ messages in thread From: alb348 @ 2012-12-28 20:52 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 20:52 ` alb348 @ 2012-12-29 0:48 ` Randy Brukardt 2012-12-29 10:23 ` Blady 2012-12-29 15:24 ` Justin Time 0 siblings, 2 replies; 38+ messages in thread From: Randy Brukardt @ 2012-12-29 0:48 UTC (permalink / raw) <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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 0:48 ` Randy Brukardt @ 2012-12-29 10:23 ` Blady 2012-12-29 10:51 ` Yannick Duchêne (Hibou57) 2012-12-29 15:24 ` Justin Time 1 sibling, 1 reply; 38+ messages in thread From: Blady @ 2012-12-29 10:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 10:23 ` Blady @ 2012-12-29 10:51 ` Yannick Duchêne (Hibou57) 0 siblings, 0 replies; 38+ messages in thread From: Yannick Duchêne (Hibou57) @ 2012-12-29 10:51 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 0:48 ` Randy Brukardt 2012-12-29 10:23 ` Blady @ 2012-12-29 15:24 ` Justin Time 2012-12-31 21:49 ` Randy Brukardt 1 sibling, 1 reply; 38+ messages in thread From: Justin Time @ 2012-12-29 15:24 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 15:24 ` Justin Time @ 2012-12-31 21:49 ` Randy Brukardt 2013-01-01 10:46 ` Justin Time 0 siblings, 1 reply; 38+ messages in thread From: Randy Brukardt @ 2012-12-31 21:49 UTC (permalink / raw) [-- 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-31 21:49 ` Randy Brukardt @ 2013-01-01 10:46 ` Justin Time 2013-01-01 12:24 ` Dmitry A. Kazakov 0 siblings, 1 reply; 38+ messages in thread From: Justin Time @ 2013-01-01 10:46 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2013-01-01 10:46 ` Justin Time @ 2013-01-01 12:24 ` Dmitry A. Kazakov 2013-01-01 16:55 ` Justin Time 0 siblings, 1 reply; 38+ messages in thread From: Dmitry A. Kazakov @ 2013-01-01 12:24 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2013-01-01 12:24 ` Dmitry A. Kazakov @ 2013-01-01 16:55 ` Justin Time 2013-01-02 10:00 ` Dmitry A. Kazakov 0 siblings, 1 reply; 38+ messages in thread From: Justin Time @ 2013-01-01 16:55 UTC (permalink / raw) Cc: mailbox 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). ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2013-01-01 16:55 ` Justin Time @ 2013-01-02 10:00 ` Dmitry A. Kazakov 0 siblings, 0 replies; 38+ messages in thread From: Dmitry A. Kazakov @ 2013-01-02 10:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 14:51 Easiest way to build Qt/Gtk interfaces for Ada programs alb348 2012-12-28 15:32 ` Dmitry A. Kazakov 2012-12-28 16:20 ` Vadim Godunko @ 2012-12-28 17:58 ` Justin Time 2012-12-31 8:07 ` ldries46 2012-12-29 16:40 ` leonid.dulman 2012-12-30 17:27 ` leonid.dulman 4 siblings, 1 reply; 38+ messages in thread From: Justin Time @ 2012-12-28 17:58 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 17:58 ` Justin Time @ 2012-12-31 8:07 ` ldries46 2012-12-31 20:58 ` John B. Matthews 2013-01-04 23:39 ` Brian Drummond 0 siblings, 2 replies; 38+ messages in thread From: ldries46 @ 2012-12-31 8:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-31 8:07 ` ldries46 @ 2012-12-31 20:58 ` John B. Matthews 2013-01-04 23:39 ` Brian Drummond 1 sibling, 0 replies; 38+ messages in thread From: John B. Matthews @ 2012-12-31 20:58 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-31 8:07 ` ldries46 2012-12-31 20:58 ` John B. Matthews @ 2013-01-04 23:39 ` Brian Drummond 1 sibling, 0 replies; 38+ messages in thread From: Brian Drummond @ 2013-01-04 23:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 14:51 Easiest way to build Qt/Gtk interfaces for Ada programs alb348 ` (2 preceding siblings ...) 2012-12-28 17:58 ` Justin Time @ 2012-12-29 16:40 ` leonid.dulman 2012-12-29 18:12 ` alb348 2012-12-30 17:27 ` leonid.dulman 4 siblings, 1 reply; 38+ messages in thread From: leonid.dulman @ 2012-12-29 16:40 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-29 16:40 ` leonid.dulman @ 2012-12-29 18:12 ` alb348 0 siblings, 0 replies; 38+ messages in thread From: alb348 @ 2012-12-29 18:12 UTC (permalink / raw) > 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) ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-28 14:51 Easiest way to build Qt/Gtk interfaces for Ada programs alb348 ` (3 preceding siblings ...) 2012-12-29 16:40 ` leonid.dulman @ 2012-12-30 17:27 ` leonid.dulman 2013-01-04 13:53 ` Patrick 4 siblings, 1 reply; 38+ messages in thread From: leonid.dulman @ 2012-12-30 17:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2012-12-30 17:27 ` leonid.dulman @ 2013-01-04 13:53 ` Patrick 2013-01-04 23:31 ` Brian Drummond 0 siblings, 1 reply; 38+ messages in thread From: Patrick @ 2013-01-04 13:53 UTC (permalink / raw) 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 ? ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2013-01-04 13:53 ` Patrick @ 2013-01-04 23:31 ` Brian Drummond 2013-01-05 8:57 ` Dmitry A. Kazakov 0 siblings, 1 reply; 38+ messages in thread From: Brian Drummond @ 2013-01-04 23:31 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
* Re: Easiest way to build Qt/Gtk interfaces for Ada programs 2013-01-04 23:31 ` Brian Drummond @ 2013-01-05 8:57 ` Dmitry A. Kazakov 0 siblings, 0 replies; 38+ messages in thread From: Dmitry A. Kazakov @ 2013-01-05 8:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 38+ messages in thread
end of thread, other threads:[~2013-01-05 8:57 UTC | newest] Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-12-28 14:51 Easiest way to build Qt/Gtk interfaces for Ada programs alb348 2012-12-28 15:32 ` Dmitry A. Kazakov 2012-12-28 17:30 ` alb348 2012-12-28 17:57 ` Dmitry A. Kazakov 2012-12-29 0:18 ` Yannick Duchêne (Hibou57) 2012-12-29 9:26 ` Dmitry A. Kazakov 2012-12-29 10:39 ` Yannick Duchêne (Hibou57) 2012-12-29 12:27 ` Dmitry A. Kazakov 2012-12-29 13:07 ` Georg Bauhaus 2012-12-29 13:26 ` Yannick Duchêne (Hibou57) 2012-12-29 13:09 ` Yannick Duchêne (Hibou57) 2012-12-29 0:27 ` Randy Brukardt 2012-12-29 1:02 ` Georg Bauhaus 2012-12-29 2:10 ` Yannick Duchêne (Hibou57) 2012-12-29 8:55 ` Dmitry A. Kazakov 2012-12-28 16:20 ` Vadim Godunko 2012-12-28 19:56 ` alb348 2012-12-28 20:38 ` Justin Time 2012-12-28 20:52 ` alb348 2012-12-29 0:48 ` Randy Brukardt 2012-12-29 10:23 ` Blady 2012-12-29 10:51 ` Yannick Duchêne (Hibou57) 2012-12-29 15:24 ` Justin Time 2012-12-31 21:49 ` Randy Brukardt 2013-01-01 10:46 ` Justin Time 2013-01-01 12:24 ` Dmitry A. Kazakov 2013-01-01 16:55 ` Justin Time 2013-01-02 10:00 ` Dmitry A. Kazakov 2012-12-28 17:58 ` Justin Time 2012-12-31 8:07 ` ldries46 2012-12-31 20:58 ` John B. Matthews 2013-01-04 23:39 ` Brian Drummond 2012-12-29 16:40 ` leonid.dulman 2012-12-29 18:12 ` alb348 2012-12-30 17:27 ` leonid.dulman 2013-01-04 13:53 ` Patrick 2013-01-04 23:31 ` Brian Drummond 2013-01-05 8:57 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox