Re: 25+2 packages with (Glade) generated C source files without the source
Others have explained why this is not a critical bug in this specific case. (Although as an aside it seems quite incomprehensible to me that these projects, and Gnome in general, have effectively thrown away the source!) But there was one misunderstanding here which I think is important to correct: Manterola writes (Re: 25+2 packages with (Glade) generated C source files without the source): On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes [EMAIL PROTECTED] wrote: [ stuff ] No. .c files are still source code. This is not correct. `Source code' means (in the words of the GPL) the preferred form for modification. In many programs the .c code is automatically generated from some other input in the source tree. Compilers for some languages even work by translating the source code to C and feeding it to a C compiler. The output from code generators and language translators is not source, even though it may be in C (or some other language that humans sometimes write). So Sami was right to suspect that there was a serious problem here and to investigate. Whether something is source or not cannot be determined simply by looking at which language it is written in. The question is: if we wanted to edit this, which file would we need to change ? If someone somewhere still has the input file, and is generating new versions of the output, then the input file is still the preferred form for modification. If the input file is completely lost, or the output file has been directly edited to the point where the input file is no longer relevant, then the output file has become the source code. I would say that _at the time when these projects were first shipped_ in this state, it _was_ a clear violation (both of our principles and of the GPL) to do so. If we had noticed at the time that the source was missing, and insisted that it was provided and that the package should be built from it, the source would not now be lost. We might ask authors to include their .glade files, IF they still have them (if they don't, then the .c files have already become the actual source code). If the .glade files can still be found, and the glade2 translator resurrected and plumbed back into the build system of these programs, we would be in a much better position. As Sami says, many of these programs are effectively immutable because editing the autogenerated C is impractical. But that's a lot of work. I'm not sure it can be done sensibly in time for lenny. If such changes _can_ be made in time then they're probably pretty safe. After all the output from glade2's code generator can be compared with the current manually-edited files. I'm not sure if the RMs would agree :-). Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 25+2 packages with (Glade) generated C source files without the source
su, 2008-09-07 kello 19:29 +0100, Ian Jackson kirjoitti: I would say that _at the time when these projects were first shipped_ in this state, it _was_ a clear violation (both of our principles and of the GPL) to do so. As far as I understand, when most of those projects first shipped, the C files really were the source. It is true that the C files were initially generated by glade, but they were then subsequently modified by hand. Having the original .glade file would mean that you could re-generate the C sources, but then all your manual modifications to them were lost. As a result, the hand-modified C files were the preferred form of modification. Indeed, some people did not ever save the .glade file, they just used glade to generate a skeleton application. (This has been said already, but bears repeating: All right-thinking developers switched to not generating code from glade, but load the .glade file at application run time instead, originally using libglade, but that's now been incorporated into gtk proper.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 25+2 packages with (Glade) generated C source files without the source
Le dimanche 31 août 2008 à 04:17 +0300, Sami Liedes a écrit : I went through some of these and checked them by hand, and generally couldn't find the glade project anywhere in the source tarball (it might be in the diff, I didn't check for that - would that BTW be OK, to have source code in diff only?). The only questionable case I found by this sampling is dia, where the file is generated by Glade and then hand-coded to make GNOME optional and add the underline for accelerated buttons. I’m pretty sure many of the list are in similar cases. Now loading the UI directly into the application is the standard, but not so long ago people generated template code with glade and then edited it by hand. The .glade file was removed simply because it has become irrelevant. Cheers, -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: 25+2 packages with (Glade) generated C source files without the source
On Sat, 2008-08-30 at 23:19 -0300, Margarita Manterola wrote: On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes [EMAIL PROTECTED] wrote: The only questionable case I found by this sampling is dia, where the file is generated by Glade and then hand-coded to make GNOME optional and add the underline for accelerated buttons. And what's there to question, then? This is exactly the case I was talking about. Some people might use glade to generate a .c as a starting point, and then continue editing the file (or not, but just keep the .c file, once it's been generated). This is perfectly fine, and we do NOT need the .glade files used. (Especially when glade-3 does not actually support generating any C code or updating the C source code files output by glade-2.) Any bugs filed so far should be closed forthwith. The comment is old, it relates to a function of Glade that was removed by Glade upstream and whether the .glade file is distributed or not, the C can no longer be generated with the current version of glade. All this process has really shown is that upstream teams are commonly lazy about removing old comments. Yawn. Sorry, Sami, but this was a waste of effort. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: 25+2 packages with (Glade) generated C source files without the source
On Sun, Aug 31, 2008 at 09:12:34AM +0200, Josselin Mouette wrote: I’m pretty sure many of the list are in similar cases. Now loading the UI directly into the application is the standard, but not so long ago people generated template code with glade and then edited it by hand. The .glade file was removed simply because it has become irrelevant. Ok, my bad then. I admit I'm not too familiar with glade, although I did know that the newest glade does not generate source code (but what argument is that, this code was obviously generated with glade, the existence of the newer version wouldn't magically make this the preferred form of modification, would it!?). Although I do wonder, since this seems to mean that the interfaces are (or at least seem to me) quite immutable. For example, take a look at http://www.hut.fi/~sliedes/interface.c which is from the package lopster. It has a number of functions like create_window() and create_options_win() which still at least look quite repulsive for any attempts to make any real or substantive edits to the interface. For example, the variable declarations in those functions: create_window() has 541 local variables named like pixmap57, hbox419, label547, hseparator49, frame 384. create_options_win() has 496. The code (4710 lines in case of create_window()) doesn't look much more editable either. But I do trust you when you say that the do not edit note is obsolete, I just wonder since after a cursory inspection this code definitely doesn't look like anything I would want to touch to edit a complex UI :) Of course if they are edited anyway, that might make them the preferred form of modification. Thanks for clarifying that, anyway, and sorry for the noise. Sami -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 25+2 packages with (Glade) generated C source files without the source
On Sun, 2008-08-31 at 15:08 +0300, Sami Liedes wrote: On Sun, Aug 31, 2008 at 09:12:34AM +0200, Josselin Mouette wrote: I’m pretty sure many of the list are in similar cases. Now loading the UI directly into the application is the standard, but not so long ago people generated template code with glade and then edited it by hand. The .glade file was removed simply because it has become irrelevant. Ok, my bad then. I admit I'm not too familiar with glade, although I did know that the newest glade does not generate source code (but what argument is that, this code was obviously generated with glade, the existence of the newer version wouldn't magically make this the preferred form of modification, would it!?). Of course it does! Once the functionality is dropped, there is no way to continue working on the project without editing the C files. Developers cannot continue using the old version of glade (it doesn't support some of the stuff that you can do with glade). You are confusing the two elements of Glade (v2) and the main functionality retained in Glade v3. Glade is about creating an interface (as an XML file, not C). Glade v2 allowed that interface to be easily converted into C code but could not cope with any manual alterations to the C code - once you started editing support.c, interface.c, callbacks.c etc., you were on your own. (Trust me, it was nearly always better if you did edit the C files too.) If you tried to re-generate, you lost all your own changes. Not good. Gladev3 takes a more sensible approach - you create whatever C files you need (no longer confined to particular file names) and load the Glade XML file with a library call. Or, if you want an interface in C or you don't want to depend on libglade, use Glade to get an idea of what kind of interface might work and then code that in C yourself. I didn't like this at first - it seemed to add more burden to the C programming - but I view it differently now. The generated code is quite awful to review later and makes project management a lot harder in the long term. Short term convenience causing long term logjam. Although I do wonder, since this seems to mean that the interfaces are (or at least seem to me) quite immutable. Sorry, that is just tosh. If you want to load the glade file via Glade, you keep the XML, depend on libglade and call libglade at runtime. If you designed the interface in Gladev2, you have the option to use the existing C files to continue improving the interface and you don't have to package the Glade file or depend on libglade. Yes, it might look like more work than editing stuff in the GUI or in the XML but in the long term it is the only sane option. To the point that I've virtually stopped working on any other projects that tried to generate C code, after working through the Glade migration. There are downsides to generating C code - bloat for one. It has a number of functions like create_window() and create_options_win() which still at least look quite repulsive for any attempts to make any real or substantive edits to the interface. WTF? It's actually fairly good code in most cases. One of the ideas behind generating code is that you gain from the experience of others and avoid common pitfalls. The limitation is that the generated C code is too generalised which can be wasteful. For example, the variable declarations in those functions: create_window() has 541 local variables named like pixmap57, hbox419, label547, hseparator49, frame 384. create_options_win() has 496. The code (4710 lines in case of create_window()) doesn't look much more editable either. That is the choice of the developers - if the developer is lazy and designs in glade rather quickly, the number suffixes remain but glade does/did allow developers to choose more sensible names, if the developer takes the time to edit the properties of the widget. But I do trust you when you say that the do not edit note is obsolete, I just wonder since after a cursory inspection this code definitely doesn't look like anything I would want to touch to edit a complex UI :) Of course if they are edited anyway, that might make them the preferred form of modification. That is something for upstream to review and, from personal experience, I can say that, at some point, upstream will be *forced* to review all that code and redesign it - when we get Gtk3 if not before. Projects where the original Glade design was lazy or rushed will find it hard to port the old generated C code but that is their choice and their problem. Like it or not, those rushed C files are the only modifiable form of the source code that are available for usage. Either edit those files or remove them and replace the entire interface with one entirely done in glade and then depend on libglade with no generated C code. It is also possible for projects using libglade to still define some widgets or windows in various C files but that is probably not
Re: 25+2 packages with (Glade) generated C source files without the source
On Sun, 2008-08-31 at 15:27 +0200, Josselin Mouette wrote: Le dimanche 31 août 2008 à 14:13 +0100, Neil Williams a écrit : Sorry, that is just tosh. If you want to load the glade file via Glade, you keep the XML, depend on libglade and call libglade at runtime. You don’t need libglade anymore, GTK+ has integrated the functionality since 2.12. Even better - thanks for that. Is there likely to be a release goal for Lenny+1 to drop libglade completely? I find 290 packages depending on libglade2-0. http://library.gnome.org/devel/gtk/2.11/gtk-migrating-GtkBuilder.html I'll be using that for one my own upstream projects. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: 25+2 packages with (Glade) generated C source files without the source
On Sun, Aug 31, 2008 at 02:13:21PM +0100, Neil Williams wrote: Of course it does! Once the functionality is dropped, there is no way to continue working on the project without editing the C files. Developers cannot continue using the old version of glade (it doesn't support some of the stuff that you can do with glade). [...] Ok, thanks for the explanation, I now see the situation much more clearly. Heh, I'm starting to see why lawyers are generally not liked (or at least that's the cliché), especially when they eventually turn out to be mistaken, although the response to this issue has been quite nice and polite this time, and specifically I don't mean this as a criticism to any of you. I guess from a maintainer's POV it's quite easy to see efforts like this as trying to cripple the software or distribution they maintain, while I view it more like I want to help Debian maintain their self-chosen commitment to 100% freedom, since freedom is one of the issues close to my heart. (If you search for bugs reported by me, I think you'll see that not all of them are nagging for license issues :) Thanks for your efforts, all of you! Sami -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 25+2 packages with (Glade) generated C source files without the source
Le dimanche 31 août 2008 à 14:13 +0100, Neil Williams a écrit : Sorry, that is just tosh. If you want to load the glade file via Glade, you keep the XML, depend on libglade and call libglade at runtime. You don’t need libglade anymore, GTK+ has integrated the functionality since 2.12. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: 25+2 packages with (Glade) generated C source files without the source
2008-08-31 (일), 14:56 +0100, Neil Williams: On Sun, 2008-08-31 at 15:27 +0200, Josselin Mouette wrote: Le dimanche 31 août 2008 à 14:13 +0100, Neil Williams a écrit : Sorry, that is just tosh. If you want to load the glade file via Glade, you keep the XML, depend on libglade and call libglade at runtime. You don’t need libglade anymore, GTK+ has integrated the functionality since 2.12. Even better - thanks for that. Is there likely to be a release goal for Lenny+1 to drop libglade completely? I find 290 packages depending on libglade2-0. I don't think so. That work is beyond the scope of Debian packaging or distribution. Migration needs serious GTK+ programming skill. Even upstream GNOME has not decided the migration as a release goal for several releases. http://live.gnome.org/GnomeGoals/RemoveLibGladeUseGtkBuilder -- Changwoo Ryu [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
25+2 packages with (Glade) generated C source files without the source
[Note that I'm not subscribed to either d-d or d-legal so if you want to ask me something, the quickest way is to Cc: me] Hi, I grepped the source tarballs in Lenny (testing) main section for the note DO NOT EDIT THIS FILE - it is generated by Glade. which indicates the file is generated using the Glade UI editor. Then I checked if these packages have any *.glade* files, which would be the Glade projects, i.e. the source code (at least in the GPL sense, preferred form of modification) for these. For those of these packages for which this is not a false alarm, I believe this would fail DFSG #2, and for those being licensed under GPL, it would probably make them non-distributable. I went through some of these and checked them by hand, and generally couldn't find the glade project anywhere in the source tarball (it might be in the diff, I didn't check for that - would that BTW be OK, to have source code in diff only?). The only questionable case I found by this sampling is dia, where the file is generated by Glade and then hand-coded to make GNOME optional and add the underline for accelerated buttons. I haven't filed bugs for any of these, save for tangogps which was the first case I encountered and after which I got the idea to do this. In addition to the cases I found in main, the packages easyspice and gtktrain in contrib seem suspect too (but I didn't take such a close look). Here's the list of the 25 packages and the relevant source files: bygfoot src/support.c src/misc2_interface.c src/interface.c src/misc2_interface.h src/support.h src/options_interface.c src/options_interface.h src/misc3_interface.c src/misc_interface.c src/interface.h src/misc3_interface.h src/misc_interface.h dia app/sheets_dialog.c: * DO NOT EDIT THIS FILE - it is generated by Glade and then hand-coded app/sheets_dialog.c- * to make GNOME optional and add the underline app/sheets_dialog.c- * for accelerated buttons. app/sheets_dialog.h gcompris src/boards/gtans_support.h src/boards/gtans_interface.h gcrontab gcrontab-0.8.0/src/support.c gcrontab-0.8.0/src/interface.c gcrontab-0.8.0/src/support.h gcrontab-0.8.0/src/interface.h src/support.c src/interface.c src/support.h src/interface.h *** NOTE: yes, I did report also the bug that the source is there twice ggz-gnome-client motd-editor/interface.c motd-editor/interface.h src/support.c src/profilesi.h src/support.h src/msgboxi.c src/profilesi.c src/interface.h src/msgboxi.h ggz-gtk-games chess/support.c chess/support.h combat/support.c combat/support.h dots/support.c dots/support.h hastings/support.c hastings/support.h reversi/support.c reversi/support.h gnusim8085 src/support.c src/interface.c src/support.h src/interface.h gpe-contacts support.c support.h gsetroot src/support.c src/interface.c src/support.h src/interface.h gtans interface.c interface.h support.c support.h gtkpool gtkpool/support.h gtkpool/support.cpp hf hfterm/src/support.c hfterm/src/support.h hoz hozgtk_i.c hozgtk_i.h hozgtk_s.c hozgtk_s.h kmd src/breakview.h src/breakview.c src/breaksupport.h src/breaksupport.c lopster src/support.c src/interface.c src/support.h src/interface.h lxappearance src/glade-support.c src/demo-ui.h src/main-dlg-ui.h src/demo-ui.c src/main-dlg-ui.c src/glade-support.h netmon-applet interface.c interface.h support.c support.h prismstumbler include/support.h src/support.c psemu-video-x11 src/support.c src/interface.c src/support.h src/interface.h tangogps src/support.h src/interface.h teg client/gui-gnome/interface.h timemachine src/support.c src/support.h tleenx2 src/support.c src/interface.c src/support.h src/interface.h trousers src/tspi/gtk/support.c src/tspi/gtk/interface.c src/tspi/gtk/support.h src/tspi/gtk/interface.h xwota src/support.c src/manual.c src/query.h src/station_info.h src/private_messages.h src/private_messages.c src/support.h src/default_preferences.c src/xwota_main.c src/xwota_main.h src/about.c src/private_messages_settings.h src/station_info.c src/manual.h src/query.c src/about.h src/default_preferences.h src/private_messages_settings.c And possibly in contrib: easyspice gtktrain Sami -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 25+2 packages with (Glade) generated C source files without the source
On Sat, Aug 30, 2008 at 10:17 PM, Sami Liedes [EMAIL PROTECTED] wrote: I grepped the source tarballs in Lenny (testing) main section for the note DO NOT EDIT THIS FILE - it is generated by Glade. which indicates the file is generated using the Glade UI editor. Then I checked if these packages have any *.glade* files, which would be the Glade projects, i.e. the source code (at least in the GPL sense, preferred form of modification) for these. For those of these packages for which this is not a false alarm, I believe this would fail DFSG #2, and for those being licensed under GPL, it would probably make them non-distributable. No. .c files are still source code. And even taking into account the DO NOT EDIT THIS FILE comment, it doesn't clearly mean that the author of the program necessarily has not edited it. We might ask authors to include their .glade files, IF they still have them (if they don't, then the .c files have already become the actual source code). But in any case it's not a violation of DFSG #2, since .c files are still source code. Bugs like these would be wishlist, at most. The preferred form of modification for this case is quite relative. Some people do prefer to edit .c files instead of .glade files, because you don't need a special tool for that. The only questionable case I found by this sampling is dia, where the file is generated by Glade and then hand-coded to make GNOME optional and add the underline for accelerated buttons. And what's there to question, then? This is exactly the case I was talking about. Some people might use glade to generate a .c as a starting point, and then continue editing the file (or not, but just keep the .c file, once it's been generated). This is perfectly fine, and we do NOT need the .glade files used. -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
