Hi Guys,
Sorry for no progress, Ive been busy finishing off work as my contract ends at the end of the month (TODAY!!!).
Now I will have time to finish what I set out to do for you since it is likely to be a while before the next contract starts.
I just committed to build-system a change to add a build commands tab to the project properties dialog to save project commands from.
To save you building the branch, I've attached a screen shot. The XXX will of course have the correct filetype when some code gets behind the dialog.
I propose to use the same for the Build menu 'set build commands' (or whatever we are calling it) dialog.
After some thought I propose to put the error regex in both because as you change the compiler it is likely that you may need to change the regex. So having one associated with each set of commands is useful.
I appreciate that there will probably be no comments til after the 0.17 release. I'll just keep plodding on.
Cheers Lex
PS Enrico, I can't help with the Addons problem since I am Autotools illiterate, I didn't even *look* in configure.in or I'd have seen the todo. Some of these build-system changes are to allow me to use alternatives to Autotools..
On Thu, 30 Apr 2009 18:11:19 +1000, Lex wrote:
Hey,
I just committed to build-system a change to add a build commands tab to the project properties dialog to save project commands from.
To save you building the branch, I've attached a screen shot. The XXX will of course have the correct filetype when some code gets behind the dialog.
I propose to use the same for the Build menu 'set build commands' (or whatever we are calling it) dialog.
After some thought I propose to put the error regex in both because as you change the compiler it is likely that you may need to change the regex. So having one associated with each set of commands is useful.
I do like it, not much more to say.
Maybe three commands for each type will be enough, or at least three for non-filetype build commands. The dialog just looks a bit big to me.
PS Enrico, I can't help with the Addons problem since I am Autotools illiterate, I didn't even *look* in configure.in or I'd have seen the
Well, I just don't know how to do it properly and I'm not really keen on spending hours on testing and reading and trying, especially because this doesn't affect most users who just install it in a default or the Geany prefix while you were setting up a pretty uncommon setup (like I have here :D). Btw, most other plugins have the same problem :(.
Regards, Enrico
Hi,
See comments below ( you're right again dammit ;-)
lex
2009/5/1 Enrico Tröger enrico.troeger@uvena.de
On Thu, 30 Apr 2009 18:11:19 +1000, Lex wrote:
Hey,
I just committed to build-system a change to add a build commands tab to the project properties dialog to save project commands from.
To save you building the branch, I've attached a screen shot. The XXX will of course have the correct filetype when some code gets behind the dialog.
I propose to use the same for the Build menu 'set build commands' (or whatever we are calling it) dialog.
After some thought I propose to put the error regex in both because as you change the compiler it is likely that you may need to change the regex. So having one associated with each set of commands is useful.
I do like it, not much more to say.
Maybe three commands for each type will be enough, or at least three for non-filetype build commands. The dialog just looks a bit big to me.
My intention was to add one spare on top of what is already used in each of the filetype and non-filetype sections giving 3 and 4 items respectively. Unfortunately while hacking with brain in neutral I added one extra on top of those...oops, I will revert to 3 and 4.
PS Enrico, I can't help with the Addons problem since I am Autotools illiterate, I didn't even *look* in configure.in or I'd have seen the
Well, I just don't know how to do it properly and I'm not really keen on spending hours on testing and reading and trying, especially because this doesn't affect most users who just install it in a default or the Geany prefix while you were setting up a pretty uncommon setup (like I have here :D). Btw, most other plugins have the same problem :(.
I apologise if it sounded like I was suggesting you should fix it, I was just noting that I don't know enough to even know where to start looking ;S
How do plugin developers do it when porting a plugin to a new Geany version, maybe one of them has the knowledge and inclination to fix it.
In the meantime it works fine on a standard install and thats all that matters.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 1 May 2009 18:00:03 +1000, Lex wrote:
PS Enrico, I can't help with the Addons problem since I am Autotools illiterate, I didn't even *look* in configure.in or I'd have seen the
Well, I just don't know how to do it properly and I'm not really keen on spending hours on testing and reading and trying, especially because this doesn't affect most users who just install it in a default or the Geany prefix while you were setting up a pretty uncommon setup (like I have here :D). Btw, most other plugins have the same problem :(.
I apologise if it sounded like I was suggesting you should fix it, I
Suggesting is fine, requesting would maybe a bit too much :).
In the meantime it works fine on a standard install and thats all that matters.
Mostly. But obviously it'd be much better if we could that fixed in whatever way. I wouldn't say a standard installation is all what matters but of course, it's the most important use case.
Regards, Enrico
Hi Guys,
In the project properties dialog, project tab, I was looking at removing the run command since it is in the new build tab with all the other build menu commands. I found that the project tab is built with manual code instead of with Glade. Is there any reason for this that I need to be careful about? (I couldn't see any but that doesn't guarantee... ;-)
I am assuming that the general intent is to do new work in Glade unless specially required to be code (for example flexible dialogs)?
Assuming this is the case do you want the project tab converted while I am there, so the whole project dialog is done with Glade?
Cheers Lex
On Sun, 3 May 2009 20:08:47 +1000, Lex wrote:
Hi Guys,
In the project properties dialog, project tab, I was looking at removing the run command since it is in the new build tab with all the other build menu commands. I found that the project tab is built with manual code instead of with Glade. Is there any reason for this that
The reason was mainly this dialog is that simple that it was easier to write manually than using Glade.
I am assuming that the general intent is to do new work in Glade unless specially required to be code (for example flexible dialogs)?
It's rather the opposite. But it's up to you. If you want creating it using Glade (remember to use 2.12), then it's ok. But I don't see any need to touch the existing code for the main tab of the dialog.
Regards, Enrico
2009/5/4 Enrico Tröger enrico.troeger@uvena.de
On Sun, 3 May 2009 20:08:47 +1000, Lex wrote:
Hi Guys,
In the project properties dialog, project tab, I was looking at removing the run command since it is in the new build tab with all the other build menu commands. I found that the project tab is built with manual code instead of with Glade. Is there any reason for this that
The reason was mainly this dialog is that simple that it was easier to write manually than using Glade.
I am assuming that the general intent is to do new work in Glade unless specially required to be code (for example flexible dialogs)?
It's rather the opposite.
Just for my understanding, why?
But it's up to you. If you want creating it using Glade (remember to use 2.12), then it's ok. But I don't see any need to touch the existing code for the main tab of the dialog.
Ok, won't touch it other than removing execute command Am already using 2.12.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 4 May 2009 10:55:30 +1000, Lex wrote:
2009/5/4 Enrico Tröger enrico.troeger@uvena.de
On Sun, 3 May 2009 20:08:47 +1000, Lex wrote:
Hi Guys,
In the project properties dialog, project tab, I was looking at removing the run command since it is in the new build tab with all the other build menu commands. I found that the project tab is built with manual code instead of with Glade. Is there any reason for this that
The reason was mainly this dialog is that simple that it was easier to write manually than using Glade.
I am assuming that the general intent is to do new work in Glade unless specially required to be code (for example flexible dialogs)?
It's rather the opposite.
Just for my understanding, why?
Glade 2.x produces deprecated code (in terms of deprecated GLib/GTK function calls) but this is not yet a real issue since we also only depend on GTK 2.8 but it might get interesting when we upgrade minimum required GTK version later. Another reason is sometimes it's messy to modify/customize the generated widgets or use own classes (not that important on Geany as we don't have much own widget classes but still). Yet another reason is to modify the generated code, you need to regenerate it, so you need again Glade, obviously.
This are all not that strong reasons and using Glade isn't anything bad at all. I just wanted to mention most often it's just easier or not more complicated to write the GUI manually. But this heavily depends on the person who writes it and this person's experience with GTK, haha.
To summarise it, just use Glade if you like but there is less need to glade-ify existing code.
Some time in the future when we can use GTK 2.12 we can/will use GtkBuilder whose XML files can be created with Glade 3 and are read directly by GTK, so we don't need libglade or generated code (and there is a conversion tool for glade XML files to GtkBuilder XML files). But this doesn't matter much for now because we require GTK 2.8 (as said before).
Regards, Enrico
Just for my understanding, why?
Glade 2.x produces deprecated code (in terms of deprecated GLib/GTK function calls) but this is not yet a real issue since we also only depend on GTK 2.8 but it might get interesting when we upgrade minimum required GTK version later.
oh :-(
Another reason is sometimes it's messy to modify/customize the generated widgets or use own classes (not that important on Geany as we don't have much own widget classes but still).
And I'm finding that it is difficult to exploit the repetitiveness within the dialog and the commonality between projects and build dialogs. Although cut & paste can generate the code reasonably efficiently you then need to hand edit it and when fixing bugs you have to repeat it lots of time ... oops I missed one ;-) This in fact is pushing me towards do it yourself. If I go that way where do you suggest that functions common to build.c and project.c should go, I don't really want to add another file?? And you can't set user_data for callbacks unless you specify something in the object field and then glade uses the connect_swapped so it comes into the callback as the widget not the user_data, messy.
Yet another reason is to modify the generated code, you need to regenerate it, so you need again Glade, obviously.
This are all not that strong reasons and using Glade isn't anything bad at all. I just wanted to mention most often it's just easier or not more complicated to write the GUI manually. But this heavily depends on the person who writes it and this person's experience with GTK, haha.
To summarise it, just use Glade if you like but there is less need to glade-ify existing code.
Ok.
Some time in the future when we can use GTK 2.12 we can/will use GtkBuilder whose XML files can be created with Glade 3 and are read directly by GTK, so we don't need libglade or generated code (and there is a conversion tool for glade XML files to GtkBuilder XML files). But this doesn't matter much for now because we require GTK 2.8 (as said before).
Yeah, as I understand it this is the way to go. Glade 3.6 supports builder xml directly, no converter needed.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 5 May 2009 12:00:46 +1000, Lex wrote:
Another reason is sometimes it's messy to modify/customize the generated widgets or use own classes (not that important on Geany as we don't have much own widget classes but still).
And I'm finding that it is difficult to exploit the repetitiveness within the dialog and the commonality between projects and build dialogs. Although cut & paste can generate the code reasonably efficiently you then need to hand edit it and when fixing bugs you have to repeat it lots of time ... oops I missed one ;-) This in fact is pushing me towards do it yourself. If I go that way where do you suggest that functions common to build.c and project.c should go,
Either in build.c or in ui_utils.c, I would tend to build.c.
Some time in the future when we can use GTK 2.12 we can/will use GtkBuilder whose XML files can be created with Glade 3 and are read directly by GTK, so we don't need libglade or generated code (and there is a conversion tool for glade XML files to GtkBuilder XML files). But this doesn't matter much for now because we require GTK 2.8 (as said before).
Yeah, as I understand it this is the way to go. Glade 3.6 supports builder xml directly, no converter needed.
Yeah, I meant just to convert our current Glade XML file into the GtkBuilder format, this is only an one-tine action.
Regards, Enrico
