Christian Henz wrote: Qt can also be developed using a WYSIWYG style editor called QtDesigner. If you go ahead and compile QtDesigner with the KDE classes, you can use the KDE widgets for that style of editing as well. Christian is right - Qt beats MFC hands down. MFC was a nightmare for me to learn and I never got that far with it. Qt was a piece of cake, the class interfaces kind of remind me of Java Swing. Although you may not like Java, Swing is a breeze to write GUIs with.

On Thu, May 08, 2003 at 09:00:22 -0400, nickt wrote: Have you looked at eclipse? http://eclipse.org/ its an IDE, witten in java but supports other languages via plugins. I imagine it must have c++ support. A bloke from IBM came to demo it at my lab. Its open/free, I can't remember what licence offhand. It has some impressive features, but for me nothing comes close to make+vi+ctags. For the UI stuff, have you tried glade? The previous version was a bit dodgy, but glade-2 (for GTK 2.x) done us pretty well for working on JAM. - Steve

On Thursday 08 May 2003 21:00, nickt wrote: Speaking personally, I guess two main things have kept me away from it. I tried installing it from an RPM supplied with one of the recent SuSE distros (8.0, I think it was), and the first thing it wanted to do after initial startup was take me to a web site to fill out a huge registration form for Borland before it would mail me a license file to permit it to run. The requirement to check in with Big Brother was in and of itself enough to keep me from going any further with it. Then there are the dependencies. The version I tried (2.x, I think) used wine extensively, meaning that any apps built in it are essentially Win32 binaries that run on top of an emulation layer. In addition to all the performance implications, it means dependencies on some rather exotic libraries, libraries not commonly found in many distros. Wine itself has been a WIP for years as it chases after the ever-mutating Win32 "standard", so stability could be problematical as well. All in all, I much prefer Qt's approach to cross-platform support, where the widgets are ported to directly call the underlying windowing system, be it X11, Win32, OS-X or whatever. Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Salem Radio Labs | | Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 | | FAX: 1-(540)-341-7176 | Warrenton, VA 20188 | |-------------------------------------------------------------------------| | The number of arguments is unimportant unless some of them are correct. | | -- Ralph Hartley | |-------------------------------------------------------------------------|

On Thursday 08 May 2003 20:53, nickt wrote: http://doc.trolltech.com/3.1/index.html See in particular the tutorial. It got me up and running very quickly. There's also a rather active mailing list (qt-interest) for general developer questions. See: http://lists.trolltech.com/ Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Salem Radio Labs | | Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 | | FAX: 1-(540)-341-7176 | Warrenton, VA 20188 | |-------------------------------------------------------------------------| | Machines should work. People should think. | | -- IBM Pollyanna Principle | |-------------------------------------------------------------------------|

On Fri, May 09, 2003 at 09:36:25AM +0200, Richard Spindler wrote: same with me for python/glade i cant think of more RAD... but i can not imagine how one can use an IDE (i dont know any IDE with a text editor) -- torben Hohn http://galan.sourceforge.net -- The graphical Audio language

On Fri, 2003-05-09 at 03:36, Richard Spindler wrote: I love Python but I need C++. C/C++ isn't a good RAD language, but you can do RAD/Visual GUI work with it. Borland C++ Builder was the best tool I ever used for doing this. I don't need RAD so much as a I need an intelligent GUI design tool with an IDE I can build with it. Qt-designer would work. I need to be able to do things I am finding hard with FLTK. With Kylix it has an API that is really easy to use. I think I am going to take the Qt plunge and find out how it works. Qt would be better because it's widely available to many people. But Kylix uses Qt underneath the API.

Fred Gleason writes: i like the GNU autotools very much, but that book is not really fun to start with, IMHO... unfortunetaly i don't know another tutorial or so... BTW: the whole kylix thread: OT or nOT? martin -- martin voelkel (ptiger(a)gmx.de) /* home is where your home directory is */

IMHO, the question to ask is: how well does it support Model-View-Controller programming? if it doesn't do it well, then its a poor choice for anything except tiny applications (see my LAD/ZKM talk about "10 things you may not have thought about ..."). my impression is that GUI toolkits derived from the windows world do a fairly poor job of this, and that RAD tools make it even more difficult. --p

On Friday May 9 2003 17:43, Paul Davis wrote: When I was listening to your talk and about the MVC part I was pretty surprised since it was one of the first things I learned when reading about Qt/KDE programming. I was under the impression, that everyone would be using it... Actually Qt supports it very well especially with the signals and slots mechanism which makes it a lot easier to make objects interact. And btw, Qt was started to create a good toolkit for UNIX which would make porting to Windows easy. -- C'ya Matthias ________________________________________________________ Matthias Kretz (Germany) <>< http://Vir.homeip.net/ MatthiasKretz(a)gmx.net, kretz(a)kde.org, Matthias.Kretz(a)urz.uni-heidelberg.de

here's a question to ask of a toolkit: can i set the depressed/raised state of a button programmatically, without implying that the user clicked it? if the answer is yes, then chances are you are using a toolkit in which MVC will be fairly easy to implement. if no, then chances are its going to be a pain. then ask the same question of value indicator widgets. etc. yes, its a widely known moniker, but its not a widely used practice. i know that in GTK+, you have to basically be willing to tolerate feedback loops between the model and the view, so that when one is changed, the other gets changed, which might change the first one again, etc. heaven help you if you suffer from rounding issues between the model and the view, because then you have no way to stop the loop without a deadful kludge. without rounding issues, you have to do lots of this sort of thing: handler_for_some_gui_event (...) { if (state_of_view != state_of_model) { change_view (); } } i've rarely seen code that looks like this when i look at open source software. maybe i'm looking for the wrong thing. --p

the signal blocking system is a bit less of a kludge. another approach, used in ardour (though less so these days) is to "sign" every state change. then the views check to see if they were the originator of the change, and ignore it if so.

On Sat, 2003-05-10 at 05:41, Paul Davis wrote: Speaking for GTK+ 2. Yes Yes I usually use signal handler blocking. An example of use would be if you have a menu radio button tied to a toggle button on a toolbar for instance. From what I have seen GTK+ will often handle this case fairly transparently, not sure how though (perhaps something to do with recursive signal invocation, or the value already set to the desired state like you mentioned). So if the menu radio button changes we want to update the toggle button and vice versa. Lets say the user changes the menu radio button, the loop would occur when in the radio button toggle handler we set the state of the toolbar toggle button, which then triggers the toolbar toggle button, which sets the menu toggle button, etc. The menu radio button toggle handler would look something like this in C (we are passing the toolbar toggle button to the signal handler using the user defined pointer): void menu_radio_item_toggled_callback (GtkWidget *radio_item, gpointer user_data) { GtkWidget *toolbar_btn = GTK_WIDGET (user_data); gboolean active; /* get state of radio menu item */ active = gtk_check_menu_item_get_active (GTK_CHECK_MENU_ITEM (radio_item)); /* block the toolbar button signal handler to prevent loop */ g_signal_handlers_block_by_func (toolbar_btn, toolbar_btn_toggled_callback, radio_item); gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (toolbar_btn), active); /* unblock */ g_signal_handlers_unblock_by_func (toolbar_btn, toolbar_btn_toggled_callback, radio_item); } In this example we blocked by callback function and data (the data is significant and must match the data when the signal is connected, the radio button in the case of the toolbar toggle button callback). You can also save the signal handler ID and use it to block the handler. I think thats what you were talking about. I wouldn't be surprised if I rambled on about something completely different though. Cheers. Josh Green

On Saturday May 10 2003 23:57, Paul Davis wrote: So for every "set-function" you would like to have a "set-internal-function" that doesn't emit signals for the changes that were done? What about if the view wants to disable some widgets when the record button gets pressed. If the view would be using such a function for setting the value when the model changes it would have to manually handle it. consider this example if Qt would have those functions: class View { public: View(); public slots: void setRecord( bool ); private: QPushButton *_button; QFrame *_frame; } View::View() { connect( _button, SIGNAL( toggled( bool ) ), _frame, SLOT( setEnabled( bool ) ) ); } void View::setRecord( bool on ) { _button->setOnInternal( on ); // does not emit signals _frame->setEnabled( !on ); } Effectively you have to duplicate the setEnabled call (I hate code duplication). Now if you don't let the widgets block but just block the whole notifications from the View (not single widgets) you can simply update the view and don't get feedback loops. You might want to create those "set-internal" functions for the View, so that you don't have to explicitly block and unblock the View's signals, though. -- C'ya Matthias ________________________________________________________ Matthias Kretz (Germany) <>< http://Vir.homeip.net/ MatthiasKretz(a)gmx.net, kretz(a)kde.org, Matthias.Kretz(a)urz.uni-heidelberg.de

On Saturday May 10 2003 14:41, Paul Davis wrote: Let's look at a QPushButton as an example. The following slots are available: void QButton::animateClick() void QButton::toggle() void QPushButton::setOn( bool ) and now some code: QPushButton * b1 = new QPushButton( this ); QPushButton * b2 = new QPushButton( this ); b1->setToggleButton( true ); b2->setToggleButton( true ); connect( b1, SIGNAL( toggled( bool ) ), b2, SLOT( setOn( bool ) ) ); connect( b2, SIGNAL( toggled( bool ) ), b1, SLOT( setOn( bool ) ) ); You might expect, that this would result in an infinite loop but actually the toggled signal is only emitted if the button was really toggled. So calling setOn( true ) on a already "on" button won't change it's state so it won't emit the according signals. This is not exactly what you asked for, but you might want to use signal blocking or disconnect a signal and slot in the case where you want to set the value of a widget without calling the code that would be called if the user had input that value. dunno. If I set the value of a "value indicator widget" nothing bad would happen, no? I have the feeling I didn't get your question :-) How about: class View { public slots: void setValue( int value ); signals: void valueChanged( int value ); private: int _value; }; class Model { public: Model(); private slots: void viewChanged( int value ); private: View *_view1, *_view2; } View::setValue( int value ) { if( _value != value ) { _value = value; emit valueChanged( _value ); } } Model::Model() { _view1 = new View(); _view2 = new View(); connect( _view1, SIGNAL( valueChanged( int ) ), this, SLOT( viewChanged( int ) ) ); connect( _view2, SIGNAL( valueChanged( int ) ), this, SLOT( viewChanged( int ) ) ); } Model::viewChanged( int value ) { // update the value of the views and don't care to handle it (since we're // already doing it ;-) ) view1->blockSignals( true ); view2->blockSignals( true ); view1->setValue( value ); view2->setValue( value ); view1->blockSignals( false ); view2->blockSignals( false ); } -- C'ya Matthias ________________________________________________________ Matthias Kretz (Germany) <>< http://Vir.homeip.net/ MatthiasKretz(a)gmx.net, kretz(a)kde.org, Matthias.Kretz(a)urz.uni-heidelberg.de

On Saturday May 10 2003 23:17, Paul Davis wrote: Ok, good. I wrote that, though... In what sense? They have to know the interface. You mean they don't have a pointer to the views? Allright. I just wanted to give a short example of how to do the "can i set the button ("view") to show some state in the model without it appearing that the user pressed the button?" with Qt. I didn't want to write a full MVC example. -- C'ya Matthias ________________________________________________________ Matthias Kretz (Germany) <>< http://Vir.homeip.net/ MatthiasKretz(a)gmx.net, kretz(a)kde.org, Matthias.Kretz(a)urz.uni-heidelberg.de

On Sat, May 10, 2003 at 10:50:00PM -0400, Paul Davis wrote: Apart from the requirement already pointed out by Paul that all widgets must be fully 'controlable' by program code and not only by user actions, there is in fact little relation between MVC and the GUI. The confusion arises in part from the fact that most toolkits try to provide a solution to two problems that better remain separated: visual presentation and program architecture. For MVC, the latter must be correct. I've been using the MVC principles quite strictly for years in our products, but it was only when I heard Paul's presentation in Karlsruhe that I knew it had a name. A typical TT&C equipment (used to send commands to satellites, to receive telemetry and measure distance) can be controlled by: 1. a technician in the equipment room 2. an operator in the ground station central control room 3. various programs running automated operational procedures 4. a satellite or operations control center at the other end of the world, 5. ... All of these are viewers and /or controllers, and in many cases there isn't even a GUI. They all use the same protocol wich is text based, so if everything else fails, you can login with telnet and control the equipment via the command line. FA

definitely not. that would require the model to know something about the view. it gets hairy because you generally can't get away with a single "changed" method if the model has any real complexity. you have to tell the views what has changed so that they don't have to do too much work. to do this properly, i believe its ideal to use some kind of anonymous callback system so that the model can signal changes, and 0 or more views can pick them up. its possible to do this in C, though its much nicer in C++ with libsigc++ (or the boost signals/slots library; i'm leaving out the Qt one because it requires a preprocessor to run over your code first, but it could be used if you insisted on it :). if we allow ourselves to peek inside the callback system, what is really happening looks something like this (to use C++ syntax): model->changed (); Model::changed () { for each registered callback { callback->execute (); } } the callback system (e.g. libsigc++) takes care of managing callback (de-) registration, lifetime management, etc. etc. --p

hehe. But Kylix also has C++ as well now. The old Kylix was pascal. I hate Pascal. I know, me too. But I really need C++ for this. I thought about making a Python module. When I did windows that is what I did. I used VB for the interface and C++ for the backend. Hmm, I think people have some sort of bias against Borland C++ Builder. Most likely they never used it. It is not a mickey-mouse tool, as so many people seem to think it is. You can do just about anything you could imagine with it. It really is very powerful, and the way it is designed blows away any other development tool I ever used. I can get slick looking stuff done with it much faster than any other blodgy tool I ever used. The thing is I just need a GUI tool like that. Qt-Designer looks really fine. I just do not like making GUIs by having to hack it all out. I like having a visual interface so I can see what I am doing and how it will look. I like to be able to click on a wigdet and edit the source code from it, and not hunt through thousands of lines of code to find it. I know Sun has a nice C++ GUI kit too, but it's not free, and they would rather have everyone program in Java (and please, do not tell me about the virtues of Java...) C++ can be a total RAD tool. The thing about object oriented programming (surprise) is something known as code reuse (grin). Once you got your classes all togethor and a solid functions you can drag-n-drop apps togethor quickly with it. The hard part of course is building the class library. The major problem is that C++ programmers want people to think C++ is an elite, difficult language, and want everyone to go to Python and Java to do 'mickey-mouse' stuff. It's not true, but why do you think C++ programmers make the big green eh? But I tell yah C++ can be a very amazing tool for RAD type of work. If people could get past the Pascal history of Borland and check out Builder they will never want to do GUIs like we are doing them now -- stone age. I am thinking I might eventually make a tool like that but instead it will interface to GCC. So far TrollTech is on the right track but they are missing out on the big oppurtunity to turn Designer into an amazing tool. In the meantime I will look into Qt and how I can get designer to work with Anjuta. Well that's my beef but seriously if you ever can just try out Kylix. You don't have to convert to it or like it, but just give it a shot. I think you will see Borland had some real innovative ideas in it's design. Maybe it's not perfect, and needs more stuff to it, but it has the potential to change things (IMHO).