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 <sliedes@cc.hut.fi> 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/

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 ideal.

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

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.

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/

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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 <cwryu@debian.org>

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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org