Re: GTK 3.0: an app developer's view
On Tue, 2008-06-17 at 10:05 +0100, Martyn Russell wrote: I just put together quickly a few lists of ALL things marked as deprecated right now. That was quite useful. We already got rid of things that caught our attention and/or have (deprecated ...) lines already in the .defs data, but this will help us make sure we're not generating unnecessary glue code. Cheers, AfC Sydney -- Andrew Frederick Cowie Managing Director Operational Dynamics Consulting, Pty Ltd http://www.operationaldynamics.com/ signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK 3.0: an app developer's view
On Thu, 2008-06-19 at 17:55 +1000, Andrew Cowie wrote: On Tue, 2008-06-17 at 10:05 +0100, Martyn Russell wrote: I just put together quickly a few lists of ALL things marked as deprecated right now. That was quite useful. We already got rid of things that caught our attention and/or have (deprecated ...) lines already in the .defs data, but this will help us make sure we're not generating unnecessary glue code. You can also just set the appropriate macro to stop these deprecated symbols from being available to your code. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK 3.0: an app developer's view
20 years ago, everyone was hand-coding assembly routines. We were? I think you are generalising slightly. 20 years ago, I would assume most programmers were happily writing Cobol, Fortran, Pascal, C, etc high-level languages. (high-level compared to machine language, that is. Of course, in the academic world, people have always been busy inventing even higher level languages. And some of them have even eventually been used for Real Work.) Today, more and more behaviour is moving into higher level constructs, softcode, bytecode interpreters, etc.. The bytecode concept (that specific term wasn't used though) was invented over 40 years ago... 30 years ago, everyone hand-picked their registers for individual assembly statements. We did? Please understand that many advanced concepts are not necessarily that new at all. People were programming in Lisp *40* years ago, at least. And Lisp surely is quite far from hand-picking registers. Smalltalk is over 30 years old. So is Prolog. Not much register hand-picking in APL, PL/1, Fortran, Pascal, Cobol or Simula either, to pick some old languages. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 3.0: an app developer's view
20 years ago, everyone was hand-coding assembly routines. We were? I think you are generalising slightly. 20 years ago, I would assume most programmers were happily writing Cobol, Fortran, Pascal, C, etc high-level languages. (high-level compared to machine language, that is. Of course, in the academic world, people have always been busy inventing even higher level languages. And some of them have even eventually been used for Real Work.) Today, more and more behaviour is moving into higher level constructs, softcode, bytecode interpreters, etc.. The bytecode concept (that specific term wasn't used though) was invented over 40 years ago... 30 years ago, everyone hand-picked their registers for individual assembly statements. We did? Please understand that many advanced concepts are not necessarily that new at all. People were programming in Lisp *40* years ago, at least. And Lisp surely is quite far from hand-picking registers. Smalltalk is over 30 years old. So is Prolog. Not much register hand-picking in APL, PL/1, Fortran, Pascal, Cobol or Simula either, to pick some old languages. --tml ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK 3.0: an app developer's view
Allin Cottrell wrote: Sorry for cross-posting, but I think this does cross gtk-devel and gtk-app-devel: it's the thoughts of a common-or-garden app developer following the dicussions on gtk-devel about what's coming with GTK 3.0. As a starting point, on June 5, in the thread Steps to get to GTK+ 3.0, Martyn Russell ([EMAIL PROTECTED]) wrote: Many applications didn't make the change [from GTK 1.2 to GTK 2] because it meant rewriting a lot of code. Unless my applications are using some evil voodoo they shouldn't be using, I don't expect the transition from GTK+ 2.x to 3.x to take much time at all. As an app developer who did take the trouble to re-write a lot of code in the transition 1.2 - 2.0, I wonder about this statement. I did too, I had several applications which had to make the transition and it wasn't a quick job. (Note: In my understanding, one key difference between GTK 2.0 and 3.0 is that all the APIs deprecated in 2.0 will be removed in 3.0; If I'm wrong about that, please tell me!) What's the status of the portion of the GTK API that was not deprecated from the get-go with GTK 2.0, but joined the deprecated list later, after 2.4? I'm thinking in particular of GtkItemFactory: if I'm remembering right, that was still kosher when GTK 2.0 appeared. I just put together quickly a few lists of ALL things marked as deprecated right now. GtkItemFactory is in that list. It will be removed (as I understand it) in 3.0 as will everything else that is marked as deprecated. These lists give you an idea of how much dead code is left in GTK+ right now and why it is so hard to maintain with it lying around. This list is in no way conclusive, it is literally those I looked up in all .h files in the gtk/ directory. There may be others. Moreover, the new code would be less efficient than the old (lots of strcmp as opposed to just looking at integer values from an enumeration). If you find the loading speed so bad that it is affecting performance of your application, please file a bug. If this is not the case, I think the benefits of a *readable* XML format outweigh the inefficiency you talk about. In addition, I'm not 100% convinced of the virtues of defining a UI in XML as opposed to via an array of C structs (having both options would be nice). Glade has been doing this for years. It is much quicker for an application developer to use Glade to define menus, windows, dialogs, etc than it is to code then *statically*. I say statically because you don't need to recompile your program to change some slight detail of the menu layout or labelling. This bears a huge advantage as far as I am concerned. Gtk-demo has an example where the UI is defined via a chunk of XML inlined as a C string. This really sucks, and would be a maintenence nightmare in any real app. What kind of real application are you talking about? I have written many in my time and I use glade for most of them (which uses an XML format for not only the menus but all window layouts). I don't find it a maintenance nightmare at all, in fact it is quite the opposite. OK, I don't want to be too negative about GtkUIManager; it surely has its advantages. But I am concerned about the possibility that GtkItemFactory will disappear: It is a certainty from what I can see. this API is not evil voodoo, IMO, and I don't suppose that mine is the only GTK 2 app that uses it rather extensively. I too have had to move from GtkItemFactory to the new GtkUIManager. It wasn't great, but it is needed. I am not saying GtkItemFactory is evil voodoo either, I am just saying there are some things in GTK+ that just need to be removed and there are some things application developers are *able* to do as a result of not sealing structures with proper APIs. I should add at this point too, that the GtkItemFactory has been marked as deprecated for some time (since GTK+ 2.4) and the documentation has explicitly said so too. So you have had plenty of time to update your application and/or bring your concerns forward about this. Please do not feel like we don't care about application developers here, many of us are application developers and know we too will have transitions to make for our software where we switch from deprecated APIs. -- Regards, Martyn gtk_about_dialog_get_name gtk_about_dialog_set_name gtk_accel_group_ref gtk_accel_group_unref gtk_accel_label_accelerator_width gtk_binding_entry_add gtk_binding_entry_add_signall gtk_binding_entry_clear gtk_binding_parse_binding gtk_button_box_get_child_ipadding gtk_button_box_get_child_size gtk_button_box_get_spacing gtk_button_box_set_child_ipadding gtk_button_box_set_child_size gtk_button_box_set_spacing gtk_calendar_display_options gtk_calendar_freeze gtk_calendar_thaw gtk_cell_renderer_editing_canceled gtk_check_menu_item_set_show_toggle GtkColorSelectionChangePaletteFunc gtk_color_selection_get_color gtk_color_selection_set_color
Re: GTK 3.0: an app developer's view
On Tue, 17 Jun 2008 10:05:28 +0100 Martyn Russell [EMAIL PROTECTED] wrote: Glade has been doing this for years. It is much quicker for an application developer to use Glade to define menus, windows, dialogs, etc than it is to code then *statically*. I say statically because you don't need to recompile your program to change some slight detail of the menu layout or labelling. This bears a huge advantage as far as I am concerned. It's a trend everyone has been making for years, and I very much support it. 20 years ago, everyone was hand-coding assembly routines. 10 years ago, C was king. Today, more and more behaviour is moving into higher level constructs, softcode, bytecode interpreters, etc.. This is a good thing. CPUs get faster all the time. Memory and hard disks get bigger and cheaper all the time. Programmers only ever get more expensive. Engineering is always about tradeoffs between resources. The resources we have are both computer, and programmer. Because the former keeps getting faster and cheaper, it makes sense every so often to have a shift of ideas, a great move where we decide the computer is good enough to take on what we now decide is the boring menial tasks we as programmers can't be bothered to do. 30 years ago, everyone hand-picked their registers for individual assembly statements. Nowadays, I bet most programmers couldn't even identify the register-colouring algorithm in their compiler; it's something that's just done for them. Who's to say what, in 20 or 30 years time, compilers and other programmer tools will be doing for us. I suspect very strongly that building UIs automatically around some description of the task to be solved, will fall under their remit. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK 3.0: an app developer's view
On Tue, 17 Jun 2008 10:05:28 +0100 Martyn Russell [EMAIL PROTECTED] wrote: Glade has been doing this for years. It is much quicker for an application developer to use Glade to define menus, windows, dialogs, etc than it is to code then *statically*. I say statically because you don't need to recompile your program to change some slight detail of the menu layout or labelling. This bears a huge advantage as far as I am concerned. It's a trend everyone has been making for years, and I very much support it. 20 years ago, everyone was hand-coding assembly routines. 10 years ago, C was king. Today, more and more behaviour is moving into higher level constructs, softcode, bytecode interpreters, etc.. This is a good thing. CPUs get faster all the time. Memory and hard disks get bigger and cheaper all the time. Programmers only ever get more expensive. Engineering is always about tradeoffs between resources. The resources we have are both computer, and programmer. Because the former keeps getting faster and cheaper, it makes sense every so often to have a shift of ideas, a great move where we decide the computer is good enough to take on what we now decide is the boring menial tasks we as programmers can't be bothered to do. 30 years ago, everyone hand-picked their registers for individual assembly statements. Nowadays, I bet most programmers couldn't even identify the register-colouring algorithm in their compiler; it's something that's just done for them. Who's to say what, in 20 or 30 years time, compilers and other programmer tools will be doing for us. I suspect very strongly that building UIs automatically around some description of the task to be solved, will fall under their remit. -- Paul LeoNerd Evans [EMAIL PROTECTED] ICQ# 4135350 | Registered Linux# 179460 http://www.leonerd.org.uk/ signature.asc Description: PGP signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GTK 3.0: an app developer's view
Sorry for cross-posting, but I think this does cross gtk-devel and gtk-app-devel: it's the thoughts of a common-or-garden app developer following the dicussions on gtk-devel about what's coming with GTK 3.0. As a starting point, on June 5, in the thread Steps to get to GTK+ 3.0, Martyn Russell ([EMAIL PROTECTED]) wrote: Many applications didn't make the change [from GTK 1.2 to GTK 2] because it meant rewriting a lot of code. Unless my applications are using some evil voodoo they shouldn't be using, I don't expect the transition from GTK+ 2.x to 3.x to take much time at all. As an app developer who did take the trouble to re-write a lot of code in the transition 1.2 - 2.0, I wonder about this statement. (Note: In my understanding, one key difference between GTK 2.0 and 3.0 is that all the APIs deprecated in 2.0 will be removed in 3.0; If I'm wrong about that, please tell me!) What's the status of the portion of the GTK API that was not deprecated from the get-go with GTK 2.0, but joined the deprecated list later, after 2.4? I'm thinking in particular of GtkItemFactory: if I'm remembering right, that was still kosher when GTK 2.0 appeared. My app has a large number of menus, across several classes of windows, and, after checking my code in the wake of the recent discussion of GTK 3.0, I find I'm very heavily invested in GtkItemFactory. I don't want to be a stick-in-the-mud, and I spent most of today working on a trial port to the GtkUIManager API of some of my GtkItemFactory code, to get a sense of the work that would be involved in eliminating all dependency on the older API. Results so far: On the one hand, I can certainly see the attraction in the newer API. Being able to define an action just once and then have it instantiated in various different UI constructions (regular menus, buttons, popups) is very nice. But from my point of view the attraction is largely counterfactual: _If_ I had originally composed my app's UIs in this way, I could have saved myself some trouble. But I didn't, and now I'd have to go to very considerable trouble to redo them. I considered the possibility of writing some sort of script or program to translate from GtkItemFactory to GtkUIManager, but fairly quickly convinced myself this was not feasible in a reasonable amount of time: the APIs are just too different. One key difference relates to the situation where you have several GUI actions that are basically similar but differ in some detail. In the GtkItemFactory API you can map all such actions to a common callback, but assign different values to the guint parameter to the callback. So far as I can tell, the callback signature for a GtkAction does not support any such (gu)int parameter. So either you have to use different callbacks for each specific action, or you have to construct a mapping from string action names to specific int action values. This is perhaps not terribly onerous if you're starting from scratch, but it's definitely inconvenient, and represents quite a major porting burden: not only would I have to rewrite all the menu code, but I'd also have to rewrite all the top-level callback code other than for simple cases where there's a one-to-one mapping from GUI action to callback function. Moreover, the new code would be less efficient than the old (lots of strcmp as opposed to just looking at integer values from an enumeration). In addition, I'm not 100% convinced of the virtues of defining a UI in XML as opposed to via an array of C structs (having both options would be nice). Gtk-demo has an example where the UI is defined via a chunk of XML inlined as a C string. This really sucks, and would be a maintenence nightmare in any real app. Reading the XML from file is preferable, but even then I'm a bit skeptical about offloading core stuff to separate files to be read at runtime. OK, I don't want to be too negative about GtkUIManager; it surely has its advantages. But I am concerned about the possibility that GtkItemFactory will disappear: this API is not evil voodoo, IMO, and I don't suppose that mine is the only GTK 2 app that uses it rather extensively. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
