Re: [Geany-devel] GtkBuilder is in!

2011-12-18 Thread Enrico Tröger
On Sat, 10 Dec 2011 16:21:22 -0800, Matthew wrote:

Hi,

I (finally) merged the gtkbuilder branch into master.  I expect there
to be at least a few bugs, but it's been working quite well for some
time now.

Please test and report any issues.

I noticed one little weird thing:

after starting Geany and right-clicking into the editor widget to open
the editor menu, the sub-menus for Format, Search and Edit are missing.
The menu items for these three items are there but without the
sub-menus.
On a second right-click the sub-menus are there.


Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc


pgpBRSOHbRwdo.pgp
Description: PGP signature
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GtkBuilder is in!

2011-12-18 Thread Matthew Brush

On 12/18/2011 08:29 AM, Enrico Tröger wrote:

On Sat, 10 Dec 2011 16:21:22 -0800, Matthew wrote:


Hi,

I (finally) merged the gtkbuilder branch into master.  I expect there
to be at least a few bugs, but it's been working quite well for some
time now.

Please test and report any issues.


I noticed one little weird thing:

after starting Geany and right-clicking into the editor widget to open
the editor menu, the sub-menus for Format, Search and Edit are missing.
The menu items for these three items are there but without the
sub-menus.
On a second right-click the sub-menus are there.



Weird. It seems ui_utils.c:on_editor_menu_show() isn't called the first 
time the editor is right-clicked.  It must have something to do with the 
shared menu items again, since AFAIK the ones not working properly are 
shared ones and are moved from one menu to another in that callback.


I'll investigate it further soon, thanks for noticing.

Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GtkBuilder is in!

2011-12-18 Thread Matthew Brush

On 12/18/2011 08:29 AM, Enrico Tröger wrote:

On Sat, 10 Dec 2011 16:21:22 -0800, Matthew wrote:


Hi,

I (finally) merged the gtkbuilder branch into master.  I expect there
to be at least a few bugs, but it's been working quite well for some
time now.

Please test and report any issues.


I noticed one little weird thing:

after starting Geany and right-clicking into the editor widget to open
the editor menu, the sub-menus for Format, Search and Edit are missing.
The menu items for these three items are there but without the
sub-menus.
On a second right-click the sub-menus are there.



OK, it's fixed.  The editor menu had its visible property set to true in 
the Glade file and I guess if it's set to visible already, calling 
`gtk_menu_popup()` won't cause the show signal to be emitted.  The 
reason it was only the shared menu items is because they are moved from 
the main menu bar to the editor menu in a show callback handler for 
the editor menu, which obviously wasn't being called the first time.


Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GtkBuilder is in!

2011-12-13 Thread Matthew Brush

On 12/12/2011 10:14 PM, Frank Lanitz wrote:

Am 11.12.2011 01:21, schrieb Matthew Brush:

   - more testing on win32


Current nightly build of 12/12/11 did not start do to missing symbol on
my box. A screenshot from my German Windows 7:
http://frank.uvena.de/tmp/geany_error.png
Its telling: g_malloc0_n wasn't found inside libglib-2.0-0.dll.



OK, I'm pretty sure it's something with the nightly build system for 
Windows because I can successfully build and run latest geany from 
master against GTK+ 2.16.6 and 2.24.8 without any of these issues.


Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GtkBuilder is in!

2011-12-12 Thread Frank Lanitz
Am 11.12.2011 01:21, schrieb Matthew Brush:
   - more testing on win32

Current nightly build of 12/12/11 did not start do to missing symbol on
my box. A screenshot from my German Windows 7:
http://frank.uvena.de/tmp/geany_error.png
Its telling: g_malloc0_n wasn't found inside libglib-2.0-0.dll.

Cheers,
Frank



signature.asc
Description: OpenPGP digital signature
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GtkBuilder is in!

2011-12-12 Thread Matthew Brush

On 12/12/2011 10:14 PM, Frank Lanitz wrote:

Am 11.12.2011 01:21, schrieb Matthew Brush:

   - more testing on win32


Current nightly build of 12/12/11 did not start do to missing symbol on
my box. A screenshot from my German Windows 7:
http://frank.uvena.de/tmp/geany_error.png
Its telling: g_malloc0_n wasn't found inside libglib-2.0-0.dll.



I think this is the same issue that Thomas noticed[1] (before the 
gtkbuilder merge).


I'm pretty sure it's not a problem with Geany itself but rather GTK+ or 
the way Geany is built/linked for Windows.


Cheers,
Matthew Brush

[1] http://www.mail-archive.com/geany@uvena.de/msg04587.html
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GtkBuilder is in!

2011-12-12 Thread Frank Lanitz
Am 13.12.2011 07:22, schrieb Matthew Brush:
 On 12/12/2011 10:14 PM, Frank Lanitz wrote:
 Am 11.12.2011 01:21, schrieb Matthew Brush:
- more testing on win32

 Current nightly build of 12/12/11 did not start do to missing symbol on
 my box. A screenshot from my German Windows 7:
 http://frank.uvena.de/tmp/geany_error.png
 Its telling: g_malloc0_n wasn't found inside libglib-2.0-0.dll.

 
 I think this is the same issue that Thomas noticed[1] (before the
 gtkbuilder merge).
 
 I'm pretty sure it's not a problem with Geany itself but rather GTK+ or
 the way Geany is built/linked for Windows.

I just updated from nightly zip so I don't think its a Gtk 2.24 issue alone.

Cheers,
Frank




signature.asc
Description: OpenPGP digital signature
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] GtkBuilder is in!

2011-12-12 Thread Matthew Brush

On 12/12/2011 10:27 PM, Frank Lanitz wrote:

Am 13.12.2011 07:22, schrieb Matthew Brush:

On 12/12/2011 10:14 PM, Frank Lanitz wrote:

Am 11.12.2011 01:21, schrieb Matthew Brush:

- more testing on win32


Current nightly build of 12/12/11 did not start do to missing symbol on
my box. A screenshot from my German Windows 7:
http://frank.uvena.de/tmp/geany_error.png
Its telling: g_malloc0_n wasn't found inside libglib-2.0-0.dll.



I think this is the same issue that Thomas noticed[1] (before the
gtkbuilder merge).

I'm pretty sure it's not a problem with Geany itself but rather GTK+ or
the way Geany is built/linked for Windows.


I just updated from nightly zip so I don't think its a Gtk 2.24 issue alone.


In the thread he says it happens on 2.16 IIRC.

Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] gtkbuilder branch and ui_lookup_widget functions

2011-10-31 Thread Nick Treleaven

On 19/10/2011 08:47, Matthew Brush wrote:

On 11-10-17 05:22 AM, Nick Treleaven wrote:

Hi Matthew,
I'm a bit concerned about the changed ui_lookup_widget (and hookup)
functions - these are in the plugin API and can be used independently
from Glade. (plugin) API function behaviour should not normally change,
but it seems the owner parameter is now ignored. If we are caching
lookups this is probably wrong as the widget may get destroyed.


OK! I got this more or less fixed up and working like it used to. The
one exception is some items from the editor menu and maybe a few other
menu items. I think it's related to some hackery somewhere in the
existing code that moving around menu items to share the same widgets in
more than one menu.


IMO it is necessary because there are often popup menu submenus that 
need to be identical, and maintaining duplicate menu items with Glade is 
a pain.


If your code does what Glade 2's interface.c did then I'm not sure why 
there would be incompatibilites.



I'm hoping someone more familiar with this part of the code can help me
out here.

You can see the changes here:

https://github.com/codebrainz/geany/commits/gtkbuilder2/

There's still a few FIXME's and it needs to be cleaned up, but if you
don't mind having a look to see if overall this is fixing the issues you
raised.


Could you move that branch into the geany repo? It would be easier to 
look at.

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] gtkbuilder branch and ui_lookup_widget functions

2011-10-19 Thread Matthew Brush

On 11-10-17 05:22 AM, Nick Treleaven wrote:

Hi Matthew,
I'm a bit concerned about the changed ui_lookup_widget (and hookup)
functions - these are in the plugin API and can be used independently
from Glade. (plugin) API function behaviour should not normally change,
but it seems the owner parameter is now ignored. If we are caching
lookups this is probably wrong as the widget may get destroyed.

I haven't looked at the new implementation but perhaps you could help
explain the changes.



OK!  I got this more or less fixed up and working like it used to.  The 
one exception is some items from the editor menu and maybe a few other 
menu items.  I think it's related to some hackery somewhere in the 
existing code that moving around menu items to share the same widgets in 
more than one menu.


I'm hoping someone more familiar with this part of the code can help me 
out here.


You can see the changes here:

https://github.com/codebrainz/geany/commits/gtkbuilder2/

There's still a few FIXME's and it needs to be cleaned up, but if you 
don't mind having a look to see if overall this is fixing the issues you 
raised.


Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] gtkbuilder branch and ui_lookup_widget functions

2011-10-18 Thread Matthew Brush

On 11-10-18 09:05 AM, Nick Treleaven wrote:

On 18/10/2011 00:09, Matthew Brush wrote:




I didn't want to break all the existing code in core and plugins that
were using ui_lookup_widget/ui_hookup_widget() functions, so I dropped
the (now) pointless first parameter. There's no need to associate things
with a parent/owner widget since all objects are required to have unique
names in GtkBuilder (and the GHashTable).


Here I think is the problem. As I mentioned earlier, ui_[lh]ookup_widget
can be used *without* Glade or GtkBuilder! This is mentioned in the 'GUI
example' for Stash (scroll down):

http://www.geany.org/manual/reference/stash_8h.html#_details



ui_[hl]ookup_object() are not used with GtkBuilder or Glade[1], they 
access an internal hash table.  GtkBuilder is completely out of the 
picture by the end of the ui_init_builder()[2] function. 
Glade3/GtkBuilder does require unique names (as did glade 2 IIUC, since 
all the names were unique), but the only reason those two functions 
currently do also is because the names are used as the key in a hash 
table, and so must be unique.  If you look back in the history you 
should see where I started out with using a GList but eventually moved 
to a GHashTable since it's a better data structure for the purpose.



There is no reason why the owner dialog can't be destroyed, and also no
reason why plugin API users have to use globally unique names for widgets.



I still don't understand what destroying the owner dialog has to do with 
anything.  TBH I don't even know what use the owner widget parameter had 
in those functions, was it just to provide a namespace so that widget 
names didn't clash between plugins?  As for the globally unique names, I 
guess this could be a problem if some new code was using the pointless 
ui_[hl]ookup_object() functions to associate a completely arbitrary 
name with a GObject (not *it's* name like gtk_widget_set_name(), just 
*a* name - used to lookup the object in the GHashTable).



So this change breaks existing API behaviour, and in addition I think
those features are things that are good to support anyway.


It might yes, especially if different plugins were calling 
ui_hookup_widget() with clashing names (which they don't).




So I think we need to restore this behaviour for those functions.
ui_[lh]ookup_object should either be updated similarly or renamed to
something like ui_builder_lookup to be clear about the difference.



It used to be called ui_add_object() but then I renamed it :) 
ui_builder_lookup() is misleading since it's not looking up anything in 
the builder, which has long since been destroyed.  It's looking up in 
the GHashTable which is only there to provide backwards compatibility 
with old code.



I'm not 100% sure what you mean by caching lookups or widgets being
destroyed.


Hopefully I've explained this above.



Not really (I'm kinda stupid remember :)  I think I'm confused about how 
it used to work and you're confused about how it works now :)


I'm not too familiar with the stash library, but aside from it, what 
other purpose do the ui_[lh]ookup_widget() functions serve that couldn't 
be accomplished with the way plugins typically use widgets[3]?  I know 
glade generated code used to have lookup/hookup functions for some 
reason, is it to do with that?


I looked in the Geany-Plugin code, and there's no use of 
ui_hookup_widget() and most uses of ui_lookup_widget() are using a 
geany-main_widgets-foo widget as the owner, which is fine since the 
widgets that came from Geany's Glade file are guaranteed to have unique 
names.


P.S. Are you ever on IRC or IM?  It's hard to have this type of 
discussion in 1 message per day email communications :)


Cheers,
Matthew Brush

[1] here's the lifecycle of the GtkBuilder instance:
- enter the ui_init_builder() function
- initialize a gtkbuilder instance
- add the xml file to parse to the gtkbuilder
- extract all the newly parsed/initialized gobjects
- add those objects to the ghashtable
- destroy the gtkbuilder instance
- leave ui_init_builder()
[2] https://github.com/geany/geany/blob/gtkbuilder/src/ui_utils.c#L2116
[3] that is, holding a pointer and destroying the widget when the plugin 
is unloaded.

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] gtkbuilder branch and ui_lookup_widget functions

2011-10-18 Thread Matthew Brush

On 11-10-18 01:33 PM, Matthew Brush wrote:


Not really (I'm kinda stupid remember :) I think I'm confused about how
it used to work and you're confused about how it works now :)



I think I see what you're talking about, ui_hookup_widget() is attaching 
the widget to the owner Gobject's datalist.  Ok, I think to avoid fixing 
all of Geany's code that uses this, I will make the new 
ui_hookup_object() to do this same thing as well, then we can worry more 
about getting rid of what's left once we port the rest of the UI to 
GtkBuilder.


I'll report back once I've got it working and we can go from there.

Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] gtkbuilder branch and ui_lookup_widget functions

2011-10-17 Thread Matthew Brush

On 11-10-17 05:22 AM, Nick Treleaven wrote:

Hi Matthew,
I'm a bit concerned about the changed ui_lookup_widget (and hookup)
functions - these are in the plugin API and can be used independently
from Glade. (plugin) API function behaviour should not normally change,
but it seems the owner parameter is now ignored. If we are caching
lookups this is probably wrong as the widget may get destroyed.

I haven't looked at the new implementation but perhaps you could help
explain the changes.


Long story short: compatibility is the reason.

Typical short story long:

I didn't want to break all the existing code in core and plugins that 
were using ui_lookup_widget/ui_hookup_widget() functions, so I dropped 
the (now) pointless first parameter.  There's no need to associate 
things with a parent/owner widget since all objects are required to have 
unique names in GtkBuilder (and the GHashTable).


I'm not 100% sure what you mean by caching lookups or widgets being 
destroyed.  I'll try and explain how it works and hopefully we can get 
some more experienced developer's eyeballs on the code to review it 
(that's you!).


So the first function called is ui_init_builder() and what it does is to 
initialize the GtkBuilder so that it creates all of the GObjects.  Then 
it iterates over all of the objects in the GtkBuilder and stores their 
pointers into a GHashTable (also ref'ing them) using their names as the 
key.  This is basically a drop-in replacement for the old Glade 2 
generated code.  Replacing the hookup and lookup functions are the new 
ui_lookup_object() and ui_hookup_object() functions.  The former just 
does a g_hash_table_lookup() to find the GObject with the associated 
key(name).  The latter just inserts the object into the hash table using 
the name as the key (and ref'ing it).


It's my understanding that all objects that were hooked up were eternal 
until program close, though if this is not the case, we'll be leaking 
exactly 1 GObject per object that the user/plugin code destroys/unrefs 
since the GHashTable is holding a ref on it.  It would be quite trivial 
to add a function to remove objects from the hash table, but existing 
code wouldn't be using this obviously.  We could also not ref user-added 
object and only ref those from GtkBuilder if we wanted.


In a perfect world, we could drop the GHashTable and use GtkBuilder 
directly to track the objects, but it seems GtkBuilder can only add 
objects from an XML string. Actually, in a perfect world, we wouldn't be 
creating widgets outside of the GUI file at all and so we could use 
GtkBuilder to track all the objects.


So the basic plan I had thought up is to do these steps:

1. Convert the Glade 2 to Glade 3 (done)
2. Get rid of the old generated code with some compat code (done)
3. Separate out all the hard-coded GUI stuff and move it into the proper 
place, the GtkBuilder file (not even remotely done)

4. Stop adding new code that mixes UI and business logic (todo)

Only the first 2 are essential to do now to actually switch to 
GtkBuilder, the next two can be done gradually over time.


I hope this clears up somewhat how the GtkBuilder stuff is currently 
working.  If you want to review the implementation, it's quite trivial 
really, you can get a pretty clear view of the meat of it by using:


$ git diff master..gtkbuilder src/ui_utils.c

That should show pretty much only the implementation and a few other 
minor changes that have happened since.


Do let me know if you have any more questions, and feel free to hack 
away on the code as usual.  I don't think any more experienced 
developers have really actually reviewed the code in-depth, so I would 
be grateful if you get the time.  It's something that will need to 
happen before we merge into master.


In the meanwhile, I'll keep plugging away on the odd little bugs I 
notice resulting from the changes.


Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel


Re: [Geany-devel] gtkbuilder branch and ui_lookup_widget functions

2011-10-17 Thread Matthew Brush

On 11-10-17 04:09 PM, Matthew Brush wrote:

On 11-10-17 05:22 AM, Nick Treleaven wrote:

Hi Matthew,
I'm a bit concerned about the changed ui_lookup_widget (and hookup)
functions - these are in the plugin API and can be used independently
from Glade. (plugin) API function behaviour should not normally change,
but it seems the owner parameter is now ignored. If we are caching
lookups this is probably wrong as the widget may get destroyed.

I haven't looked at the new implementation but perhaps you could help
explain the changes.


Long story short: compatibility is the reason.



Lex has pointed out on IRC that in my typical fashion I haven't been 
clear enough :) so I would highly recommend just reading the code.  It's 
really not tricky or complicated at all and it's quite short.


Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel