From david at rapidcharting.com  Mon Feb  4 18:38:31 2008
From: david at rapidcharting.com (david)
Date: Mon, 04 Feb 2008 18:38:31 -0500
Subject: [Glade-devel] migration on an old 0.5.9 glade application
Message-ID: <1202168311.23011.1.camel@dpace.dpace>

Is there a way to migrate.

I tried loading the x.glade file and it failed.

I used glade 2 and glade 3

and I might try glade 1 if I can compile it soon.

I suspect it is a GTK-1.2 versus GTK 2 issue.

I've been out of the programming loop for a while.

David





From tvb at gnome.org  Thu Feb  7 08:00:32 2008
From: tvb at gnome.org (Tristan Van Berkom)
Date: Thu, 7 Feb 2008 11:00:32 -0200
Subject: [Glade-devel] migration on an old 0.5.9 glade application
In-Reply-To: <1202168311.23011.1.camel@dpace.dpace>
References: <1202168311.23011.1.camel@dpace.dpace>
Message-ID: <560259cb0802070500j7c78a685q5028dd63ffb8c6f3@mail.gmail.com>

On Feb 4, 2008 9:38 PM, david <david at rapidcharting.com> wrote:

> Is there a way to migrate.
>
> I tried loading the x.glade file and it failed.
>
> I used glade 2 and glade 3
>
> and I might try glade 1 if I can compile it soon.
>
> I suspect it is a GTK-1.2 versus GTK 2 issue.


That is correct, glade format has changed as well as
the toolkit api - there was a script available in glade-2
package to convert the glade file that might help you.

-Tristan




>
>
> I've been out of the programming loop for a while.
>
> David
>
>
>
>
> _______________________________________________
> Glade-devel maillist  -  Glade-devel at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/glade-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/glade-devel/attachments/20080207/0677808c/attachment.html 

From dkasak at nusconsulting.com.au  Mon Feb 18 17:24:27 2008
From: dkasak at nusconsulting.com.au (Daniel Kasak)
Date: Tue, 19 Feb 2008 09:24:27 +1100
Subject: [Glade-devel] Feature Request: find duplicate widget names
Message-ID: <1203373467.5615.13.camel@dkasak.nusconsulting.com.au>

Hi all.

With large complex forms, it's easy to accidentally name a widget the
same as another widget. Would it be possible to add a function that
checks the widget tree and notifies you of duplicate widget names? This
could happen on saving, or better yet when the widget name is set.

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2
9922 7989
email: dkasak at nusconsulting.com.au
website:
http://www.nusconsulting.com.au





From tvb at gnome.org  Wed Feb 20 19:47:07 2008
From: tvb at gnome.org (Tristan Van Berkom)
Date: Wed, 20 Feb 2008 21:47:07 -0300
Subject: [Glade-devel] Feature Request: find duplicate widget names
In-Reply-To: <1203373467.5615.13.camel@dkasak.nusconsulting.com.au>
References: <1203373467.5615.13.camel@dkasak.nusconsulting.com.au>
Message-ID: <560259cb0802201647r256136c6sb623a53624869054@mail.gmail.com>

On Mon, Feb 18, 2008 at 7:24 PM, Daniel Kasak <dkasak at nusconsulting.com.au>
wrote:

> Hi all.
>
> With large complex forms, it's easy to accidentally name a widget the
> same as another widget. Would it be possible to add a function that
> checks the widget tree and notifies you of duplicate widget names? This
> could happen on saving, or better yet when the widget name is set.



sorry for the delayed reply, yes its possible, we see this more as a bug
than a feature ;-) there is a module in glade that is used to bookkeep the
availability of widget names in a project, were just not using it properly,
as specially wrt what happens when you copy paste widgets, transfer
them across projects etc.

it would be nice though to simply dissallow input of duplicate names.

Cheers,
                 -Tristan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/glade-devel/attachments/20080220/ac79dd28/attachment.html 

From marcodiegomesquita at gmail.com  Fri Feb 22 13:31:34 2008
From: marcodiegomesquita at gmail.com (=?ISO-8859-1?Q?Marco_Diego_Aur=E9lio_Mesquita?=)
Date: Fri, 22 Feb 2008 15:31:34 -0300
Subject: [Glade-devel] [PATCH] Implement preview feature in glade-3
Message-ID: <2863ba060802221031k4d30505cyd3fcdb5e69a71784@mail.gmail.com>

Hi, this is my first message to glade-devel.

I wrote the attached simple (and is somewhat a quick and dirty hack)
to implement a preview feature in glade-3. The patch is against the
svn revision 1693.

It is still not ready for inclusion, but I would like to hear feedback
from developers and users about how to do it right.

There are currently some issues:
 * The currently seen project is saved in /tmp/temp.glade
 * The project must have a toplevel widget called window1
 *...

Feedback would be welcome, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: preview.diff
Type: text/x-patch
Size: 5200 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/glade-devel/attachments/20080222/10bf042a/attachment.bin 

From nathanr at nathanr.net  Tue Feb 26 07:48:17 2008
From: nathanr at nathanr.net (Nathan Robertson)
Date: Tue, 26 Feb 2008 06:48:17 -0600
Subject: [Glade-devel] Glade and GObject introspection
Message-ID: <20080226124817.GA19547@miller.lesmills.net.au>

Hi,

I've been looking at the Glade source code for the last few days, as I'm
trying to get GObject introspection working, and I knew that Glade would be
a good example to look at for how to do this. Basically, in Java I would do:

Class sc = Class.forName("java.lang.String").getSuperclass();
System.out.println("Superclass is: " + sc.getName());

After a bit of reading the documentation and GTK+, libglade and Glade source
code I've so far come up with:

GType button_type, parent_type;
gtk_init(&argc, &argv);
button_type = g_type_from_name("GtkButton");
parent_type = g_type_parent(button_type);
printf("%s, %s\n", g_type_name(button_type), g_type_name(parent_type));

Now, I'm guessing that Glade reads in gtk+.xml, and looks up the name=""
types for each of the <glade-widget-class> entries, and then looks up the
GType from the name. However, the above code returns NULL on line 3 unless I
put before it:

button_type = GTK_TYPE_BUTTON;

So obviously I'm missing some initialization that reads in all the types,
which is what the documentation for g_type_from_name() hints at.

My question is what is this missing initialization code? I've been looking
through the Glade source code and must have missed it, and I'd appreciate
if someone could point me in the direction of the code that implements it in
Glade.

Many thanks,
Nathan.

From vincent.geddes at gmail.com  Tue Feb 26 16:33:35 2008
From: vincent.geddes at gmail.com (Vincent Geddes)
Date: Tue, 26 Feb 2008 23:33:35 +0200
Subject: [Glade-devel] [PATCH] Implement preview feature in glade-3
In-Reply-To: <2863ba060802221031k4d30505cyd3fcdb5e69a71784@mail.gmail.com>
References: <2863ba060802221031k4d30505cyd3fcdb5e69a71784@mail.gmail.com>
Message-ID: <1204061615.6358.38.camel@ubuntu>

Hi!

The patch seems to require a dependency on libglade. We don't want to
use libglade in glade3 for various reasons. This library has also just
been deprecated in favour of the new GtkBuilder API in GTK 2.10.

How about changing your implementation to use GtkBuilder instead? When
you are done with that, please post your patch on Bugzilla [1]. That's
where we organise and discuss new patches. 

Note, right now glade3 cannot save in the GtkBuilder format, so your
patch will have to temporarily work around that for the time being. The
GTK tool 'gtk-builder-convert' is able to do a conversion from the
libglade format into the new one.

Some comments on the patch:

* There should be a menu item corresponding to the item in the
  toolbar. It would best to put it under the "View" menu.

* Please use a more helpful error message such as:
  "Cannot create preview: unable to save temporary file"

* we need that icon "preview.png" included alongside your patch.
  Store it in the data/icons directory in the glade3 package. Remember
  to edit data/icons/Makefile.am so that the icon will be installed
  along with the others.

Good work so far. Thanks for your interest in Glade!

Vincent

1. <http://bugzilla.gnome.org/enter_bug.cgi?product=glade3>



From tvb at gnome.org  Tue Feb 26 22:43:54 2008
From: tvb at gnome.org (Tristan Van Berkom)
Date: Wed, 27 Feb 2008 00:43:54 -0300
Subject: [Glade-devel] [PATCH] Implement preview feature in glade-3
In-Reply-To: <1204061615.6358.38.camel@ubuntu>
References: <2863ba060802221031k4d30505cyd3fcdb5e69a71784@mail.gmail.com>
	<1204061615.6358.38.camel@ubuntu>
Message-ID: <560259cb0802261943q394156feg4cf8951c65c35bfb@mail.gmail.com>

On Tue, Feb 26, 2008 at 6:33 PM, Vincent Geddes <vincent.geddes at gmail.com>
wrote:

> Hi!
>
> The patch seems to require a dependency on libglade. We don't want to
> use libglade in glade3 for various reasons. This library has also just
> been deprecated in favour of the new GtkBuilder API in GTK 2.10.


Hi,
    thanks for the interest Marco and also the comments Vincent.

About libglade and GtkBuilder, GtkBuilder is definitly more of a priority
but I'm not sure its healthy for us to work around it and make conversions
on a preview feature.

To make things a little more clear, while libglade is indeed being
depricated
in favour of new technology, libglade support in the Glade tool is still a
requirement for years to come since libglade will take a while to phase
out completely. So our goal is to load and save in both formats, in which
case
we should have a preview for projects that are libglade based and for
projects that are
GtkBuilder based.

Now, having libglade as a dependency for the tool is not such a bad thing,
although linking it into the executable has caused conflicts in the past,
also I
think it may be unwise to run a preview in the exec space of
glade/libgladeui,
as specially since it could be running from anjuta or another embedding app
(consider that libglade/gtkbuilder will be dlsym looking for callbacks
specified
in glade files, which shouldnt but may conflict with symbols in
glade/anjuta/other).
running previews in a separate execution space also eases the possibiliy of
adding themes/gtkrc files to the preview without effecting glade.

So, to recap the two big problems with this approach to preview feature are:
   - Should be running preview from its own main(), an executable that will
     alone be linking against libglade.
   - Needs to be implemented in libgladeui and not solely in glade-window.c
    (I think this should be a feature of glade-project.c, and used from the
frontend)
    otherwise the feature will not be available in anjuta or other
embedders.

Sorry if thats a bit vague and still needs some discussion

Cheers,
                  -Tristan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/glade-devel/attachments/20080227/464140cd/attachment.html