On Sun, Jan 29, 2012 at 1:08 AM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
Hi,
How can I $subject?
Hi Dimitar,
At the moment you can't officially access any o fthe build system from a plugin.
Initially I exposed some of the build system (see comments starting /* * in build.h/c) but concerns were raised that this exposed the implementation so it was removed. This is no different to any other part of Geany, most of the rest of the plugin interface exposes the implementation of something. Probably it was the realisation of the possible impacts of that which caused the concern to be raised.
My attempts to proactively define an interface that does not expose any implementation structures was also rejected, so there is officially no way.
I guess you need to request the parts you need, and those will be exposed in the usual ad-hoc way.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 30 Jan 2012 14:08:59 +1100 Lex Trotman elextr@gmail.com wrote:
How can I $subject?
At the moment you can't officially access any of the build system from a plugin.
[::surprise::]
Initially I exposed some of the build system (see comments starting /*
- in build.h/c) but concerns were raised that this exposed the
implementation so it was removed.
I don't see anything starting with /**, and there are lots of /* *...
My attempts to proactively define an interface that does not expose any implementation structures was also rejected, so there is officially no way.
Hmmm... Have you tried something simple, like:
const gchar *build_get_command(ft, index, part)
Where:
ft = filetype | independent | exec index = 0, 1, ... part = label | command | workdir
rval = NULL if index is too big or some other argument is invalid.
Of course, it's not much different than the current build_get_*() functions, but doesn't expose any build structures. And I guess people will need the effective value, not some particular source.
I guess you need to request the parts you need, and those will be exposed in the usual ad-hoc way.
Some home_ft/project specific commands. They're not hard to get, but re-reading the key files is hardly the right thing.
On Tue, Jan 31, 2012 at 5:13 AM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 30 Jan 2012 14:08:59 +1100 Lex Trotman elextr@gmail.com wrote:
How can I $subject?
At the moment you can't officially access any of the build system from a plugin.
[::surprise::]
Initially I exposed some of the build system (see comments starting /*
- in build.h/c) but concerns were raised that this exposed the
implementation so it was removed.
I don't see anything starting with /**, and there are lots of /* *...
Thats because none of them are "officially" exposed, the space prevents doxygen from picking them up so they are not in the plugin doc.
My attempts to proactively define an interface that does not expose any implementation structures was also rejected, so there is officially no way.
Hmmm... Have you tried something simple, like:
const gchar *build_get_command(ft, index, part)
Where:
ft = filetype | independent | exec
existing enum GeanyBuildGroup, we shouldn't add an extra enum that can get out of step
index = 0, 1, ... part = label | command | workdir
existing enum GeanyBuildCmdEntries, as above
rval = NULL if index is too big or some other argument is invalid.
Yeah, if all you need is read-only access, I'll just change build_get_current_menu_item() to return only one field, means that you have to make three calls though. It does all the checks to return NULL already. build_get_current_menu_item() is not officially in the API and it isn't used internally so it can be changed.
Now do I return the gchar * and trust you not to write to it, or copy the string and trust you to free it? Maybe return const gchar* so you you are warned not to change it or free it.
Of course, it's not much different than the current build_get_*() functions, but doesn't expose any build structures. And I guess people will need the effective value, not some particular source.
Yeah, see above, build_get_current_menu_item gets what you call the effective value (it returns the source, but if you don't want it I won't return it).
I guess you need to request the parts you need, and those will be exposed in the usual ad-hoc way.
Some home_ft/project specific commands. They're not hard to get, but re-reading the key files is hardly the right thing.
And reading the files wouldn't get any changes the user has made this session since they are not saved until Geany closes. Does above suit you?
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Le 30/01/2012 23:22, Lex Trotman a écrit :
On Tue, Jan 31, 2012 at 5:13 AM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 30 Jan 2012 14:08:59 +1100 Lex Trotman elextr@gmail.com wrote:
How can I $subject?
At the moment you can't officially access any of the build system from a plugin.
[::surprise::]
Initially I exposed some of the build system (see comments starting /*
- in build.h/c) but concerns were raised that this exposed the
implementation so it was removed.
I don't see anything starting with /**, and there are lots of /* *...
Thats because none of them are "officially" exposed, the space prevents doxygen from picking them up so they are not in the plugin doc.
My attempts to proactively define an interface that does not expose any implementation structures was also rejected, so there is officially no way.
Hmmm... Have you tried something simple, like:
const gchar *build_get_command(ft, index, part)
Where:
ft = filetype | independent | exec
existing enum GeanyBuildGroup, we shouldn't add an extra enum that can get out of step
index = 0, 1, ... part = label | command | workdir
existing enum GeanyBuildCmdEntries, as above
rval = NULL if index is too big or some other argument is invalid.
Yeah, if all you need is read-only access, I'll just change build_get_current_menu_item() to return only one field, means that you have to make three calls though. It does all the checks to return NULL already. build_get_current_menu_item() is not officially in the API and it isn't used internally so it can be changed.
Now do I return the gchar * and trust you not to write to it, or copy the string and trust you to free it? Maybe return const gchar* so you you are warned not to change it or free it.
Yes, return const gchar *. Returning internal data as gchar * is neither a great idea nor a common idiom in Geany/GLib/GTK; and duplicating just for the fun is less handy to use for the caller and only has the real advantage that a future implementation could drop that internal representation and simply compute it. But const gchar * should be enough to tell the caller not to touch the data, if somebody actually modifies it and it cause problems, I'd say "you deserved it".
Cheers, Colomban
Of course, it's not much different than the current build_get_*() functions, but doesn't expose any build structures. And I guess people will need the effective value, not some particular source.
Yeah, see above, build_get_current_menu_item gets what you call the effective value (it returns the source, but if you don't want it I won't return it).
I guess you need to request the parts you need, and those will be exposed in the usual ad-hoc way.
Some home_ft/project specific commands. They're not hard to get, but re-reading the key files is hardly the right thing.
And reading the files wouldn't get any changes the user has made this session since they are not saved until Geany closes. Does above suit you?
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, Jan 31, 2012 at 10:03 AM, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 30/01/2012 23:22, Lex Trotman a écrit :
On Tue, Jan 31, 2012 at 5:13 AM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Mon, 30 Jan 2012 14:08:59 +1100 Lex Trotman elextr@gmail.com wrote:
How can I $subject?
At the moment you can't officially access any of the build system from a plugin.
[::surprise::]
Initially I exposed some of the build system (see comments starting /*
- in build.h/c) but concerns were raised that this exposed the
implementation so it was removed.
I don't see anything starting with /**, and there are lots of /* *...
Thats because none of them are "officially" exposed, the space prevents doxygen from picking them up so they are not in the plugin doc.
My attempts to proactively define an interface that does not expose any implementation structures was also rejected, so there is officially no way.
Hmmm... Have you tried something simple, like:
const gchar *build_get_command(ft, index, part)
Where:
ft = filetype | independent | exec
existing enum GeanyBuildGroup, we shouldn't add an extra enum that can get out of step
index = 0, 1, ... part = label | command | workdir
existing enum GeanyBuildCmdEntries, as above
rval = NULL if index is too big or some other argument is invalid.
Yeah, if all you need is read-only access, I'll just change build_get_current_menu_item() to return only one field, means that you have to make three calls though. It does all the checks to return NULL already. build_get_current_menu_item() is not officially in the API and it isn't used internally so it can be changed.
Now do I return the gchar * and trust you not to write to it, or copy the string and trust you to free it? Maybe return const gchar* so you you are warned not to change it or free it.
Yes, return const gchar *. Returning internal data as gchar * is neither a great idea nor a common idiom in Geany/GLib/GTK; and duplicating just for the fun is less handy to use for the caller and only has the real advantage that a future implementation could drop that internal representation and simply compute it. But const gchar * should be enough to tell the caller not to touch the data, if somebody actually modifies it and it cause problems, I'd say "you deserved it".
Agree.
Cheers Lex
Cheers, Colomban
Of course, it's not much different than the current build_get_*() functions, but doesn't expose any build structures. And I guess people will need the effective value, not some particular source.
Yeah, see above, build_get_current_menu_item gets what you call the effective value (it returns the source, but if you don't want it I won't return it).
I guess you need to request the parts you need, and those will be exposed in the usual ad-hoc way.
Some home_ft/project specific commands. They're not hard to get, but re-reading the key files is hardly the right thing.
And reading the files wouldn't get any changes the user has made this session since they are not saved until Geany closes. Does above suit you?
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 01/28/2012 06:08 AM, Dimitar Zhekov wrote:
Hi,
How can I $subject?
FWIW, I also have a need for this for an Android plugin I'm working on (using Eclipse is sooo painful).
So far I've found a need to both get and set the build commands for a project (and the working dir) and also to programmatically cause them to run (IIRC this is already working by a keybindings hack). My current code is basically just duplicating all the project and build stuff under it's own menu since it's not exposed, but it feels clunky and redundant.
Cheers, Matthew Brush
On Tue, Jan 31, 2012 at 10:16 AM, Matthew Brush mbrush@codebrainz.ca wrote:
On 01/28/2012 06:08 AM, Dimitar Zhekov wrote:
Hi,
How can I $subject?
FWIW, I also have a need for this for an Android plugin I'm working on (using Eclipse is sooo painful).
So far I've found a need to both get and set the build commands for a project (and the working dir) and also to programmatically cause them to run (IIRC this is already working by a keybindings hack). My current code is basically just duplicating all the project and build stuff under it's own menu since it's not exposed, but it feels clunky and redundant.
DRY
So in addition to the proposal to Dimitar, add function:
build_set_menu_item( const GeanyBuildSource src, const GeanyBuildGroup grp, const unsigned cmd, const GeanyBuildCmdEntries field, const gchar *value )
Unfortunately that will update the menu for each field you write, but I can't trust you to call build_menu_update() when you have finished, can I?
Also add function:
build_activate_menu_item( const GeanyBuildSource src, const GeanyBuildGroup grp, const unsigned cmd )
which can activate *all* the menu items, the keybinding hack can't bind other than the "well known" commands that were in Geany originally, so you can't activate them ATM.
Cheers Lex
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 01/30/2012 04:16 PM, Lex Trotman wrote:
On Tue, Jan 31, 2012 at 10:16 AM, Matthew Brushmbrush@codebrainz.ca wrote:
On 01/28/2012 06:08 AM, Dimitar Zhekov wrote:
Hi,
How can I $subject?
FWIW, I also have a need for this for an Android plugin I'm working on (using Eclipse is sooo painful).
So far I've found a need to both get and set the build commands for a project (and the working dir) and also to programmatically cause them to run (IIRC this is already working by a keybindings hack). My current code is basically just duplicating all the project and build stuff under it's own menu since it's not exposed, but it feels clunky and redundant.
DRY
So in addition to the proposal to Dimitar, add function:
build_set_menu_item( const GeanyBuildSource src, const GeanyBuildGroup grp, const unsigned cmd, const GeanyBuildCmdEntries field, const gchar *value )
Unfortunately that will update the menu for each field you write, but I can't trust you to call build_menu_update() when you have finished, can I?
Also add function:
build_activate_menu_item( const GeanyBuildSource src, const GeanyBuildGroup grp, const unsigned cmd )
which can activate *all* the menu items, the keybinding hack can't bind other than the "well known" commands that were in Geany originally, so you can't activate them ATM.
Sounds pretty good, I'll need to examine closer to be sure, but we can always make more changes after once we play with it for a bit.
Thanks, Matthew Brush
Dimitar, Matthew,
See git://github.com/elextr/geany.git, the more testing the better :)
Cheers Lex
On Tue, 31 Jan 2012 15:39:52 +1100 Lex Trotman elextr@gmail.com wrote:
Dimitar, Matthew,
See git://github.com/elextr/geany.git, the more testing the better :)
I compile Geany with -Wall -W -Wno-unused-parameter (not the normal practice) and received a few warnings:
build.c: In function 'build_get_current_menu_item': build.c:576:2: warning: enumeration value 'GEANY_BC_CMDENTRIES_COUNT' not handled in switch [-Wswitch] build.c: In function 'build_set_menu_item': build.c:620:2: warning: enumeration value 'GEANY_BC_CMDENTRIES_COUNT' not handled in switch [-Wswitch] build.c:607:9: warning: unused variable 'str' [-Wunused-variable]
These are probably harmless.
build_get_current_menu_item() works, and returns the non-expanded values (%e, %f) as I expected.
About returning NULL instead of "" for the empty fields, I'm not very sure. How do we separate a completely empty command with a valid cmd, such as the 3rd default C command, and an out-of-range cmd?
On Wed, Feb 1, 2012 at 5:20 AM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 31 Jan 2012 15:39:52 +1100 Lex Trotman elextr@gmail.com wrote:
Dimitar, Matthew,
See git://github.com/elextr/geany.git, the more testing the better :)
I compile Geany with -Wall -W -Wno-unused-parameter (not the normal practice) and received a few warnings:
Well, it should be normal practice, thats what HACKING says, I just forgot to set it with a new clean clone, oops. Actually you should add -O2 because a couple of the warnings need the dataflow computation that the optimisation does.
build.c: In function 'build_get_current_menu_item': build.c:576:2: warning: enumeration value 'GEANY_BC_CMDENTRIES_COUNT' not handled in switch [-Wswitch] build.c: In function 'build_set_menu_item': build.c:620:2: warning: enumeration value 'GEANY_BC_CMDENTRIES_COUNT' not handled in switch [-Wswitch] build.c:607:9: warning: unused variable 'str' [-Wunused-variable]
These are probably harmless.
Yes, stupid compiler can't see that there is a g_return_if_fail just before that limits fld to the range in the switch, fixed now anyway.
build_get_current_menu_item() works, and returns the non-expanded values (%e, %f) as I expected.
About returning NULL instead of "" for the empty fields, I'm not very sure. How do we separate a completely empty command with a valid cmd, such as the 3rd default C command, and an out-of-range cmd?
The semantics of a command (well actually the label) that is "" vs NULL is important, a "" label hides commands from a lower priority source without showing itself in the menu, a NULL does not. So a for example a project that isn't using make could override the first make command with whatever it is using and hide the other two unused default make commands by setting the labels to "".
Unfortunately there isn't anthing else besides NULL that is sensible to return to indicate out of range.
So I've exposed build_get_group_count() as well so you can get the count and then its your fault if you pass an out of range index :).
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 1 Feb 2012 11:24:01 +1100 Lex Trotman elextr@gmail.com wrote:
On Wed, Feb 1, 2012 at 5:20 AM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 31 Jan 2012 15:39:52 +1100
I compile Geany with -Wall -W -Wno-unused-parameter (not the normal practice) and received a few warnings:
Well, it should be normal practice, thats what HACKING says, I just forgot to set it with a new clean clone, oops. Actually you should add -O2 because a couple of the warnings need the dataflow computation that the optimisation does.
I only listed the warnings, -O2 is a sine qua non (albeit -Os -freorder-blocks is better for some systems).
The semantics of a command (well actually the label) that is "" vs NULL is important, a "" label hides commands from a lower priority source without showing itself in the menu, a NULL does not. [...]
Unfortunately there isn't anthing else besides NULL that is sensible to return to indicate out of range.
So returning "" for COMMAND is possible...
So I've exposed build_get_group_count() as well so you can get the count and then its your fault if you pass an out of range index :).
...but a count is fine too. :) Let's hope BuildFuncs makes it into the plugin interface, the current lack of build access is weird.
On Thu, Feb 2, 2012 at 5:10 AM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Wed, 1 Feb 2012 11:24:01 +1100 Lex Trotman elextr@gmail.com wrote:
On Wed, Feb 1, 2012 at 5:20 AM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Tue, 31 Jan 2012 15:39:52 +1100
I compile Geany with -Wall -W -Wno-unused-parameter (not the normal practice) and received a few warnings:
Well, it should be normal practice, thats what HACKING says, I just forgot to set it with a new clean clone, oops. Actually you should add -O2 because a couple of the warnings need the dataflow computation that the optimisation does.
I only listed the warnings, -O2 is a sine qua non (albeit -Os -freorder-blocks is better for some systems).
The semantics of a command (well actually the label) that is "" vs NULL is important, a "" label hides commands from a lower priority source without showing itself in the menu, a NULL does not. [...]
Unfortunately there isn't anthing else besides NULL that is sensible to return to indicate out of range.
So returning "" for COMMAND is possible...
So I've exposed build_get_group_count() as well so you can get the count and then its your fault if you pass an out of range index :).
...but a count is fine too. :) Let's hope BuildFuncs makes it into the plugin interface, the current lack of build access is weird.
Well, my intention is that when Matthew has tested writing I will add it if no other developers object in the meantime.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 02/01/2012 02:34 PM, Lex Trotman wrote:
On Thu, Feb 2, 2012 at 5:10 AM, Dimitar Zhekovdimitar.zhekov@gmail.com wrote:
On Wed, 1 Feb 2012 11:24:01 +1100 Lex Trotmanelextr@gmail.com wrote:
On Wed, Feb 1, 2012 at 5:20 AM, Dimitar Zhekovdimitar.zhekov@gmail.com wrote:
On Tue, 31 Jan 2012 15:39:52 +1100
I compile Geany with -Wall -W -Wno-unused-parameter (not the normal practice) and received a few warnings:
Well, it should be normal practice, thats what HACKING says, I just forgot to set it with a new clean clone, oops. Actually you should add -O2 because a couple of the warnings need the dataflow computation that the optimisation does.
I only listed the warnings, -O2 is a sine qua non (albeit -Os -freorder-blocks is better for some systems).
The semantics of a command (well actually the label) that is "" vs NULL is important, a "" label hides commands from a lower priority source without showing itself in the menu, a NULL does not. [...]
Unfortunately there isn't anthing else besides NULL that is sensible to return to indicate out of range.
So returning "" for COMMAND is possible...
So I've exposed build_get_group_count() as well so you can get the count and then its your fault if you pass an out of range index :).
...but a count is fine too. :) Let's hope BuildFuncs makes it into the plugin interface, the current lack of build access is weird.
Well, my intention is that when Matthew has tested writing I will add it if no other developers object in the meantime.
It will be quite a bit before the Android plugin is at the point to using this since I have a whole bunch of other stuff to do first to even get an Android project created and opened.
If you want I could probably write a little test plugin just to see if it works, but if there's no rush, I'll get this tested in due course otherwise.
P.S. Thanks for adding the feature, it will save me writing tons of documentation explaining how to configure Geany to work with the Android SDK, I can just do it automatically for users now :)
Cheers, Matthew Brush
[...]
Well, my intention is that when Matthew has tested writing I will add it if no other developers object in the meantime.
It will be quite a bit before the Android plugin is at the point to using this since I have a whole bunch of other stuff to do first to even get an Android project created and opened.
Ok, no worries.
If you want I could probably write a little test plugin just to see if it works, but if there's no rush, I'll get this tested in due course otherwise.
It would be really good if someone other than me tests it, my test plugin is rather dumb. Since its adding to the API we only want to do it once if we can (I think I've done it so it doesn't need an ABI break as well). OTOH we don't want to lock Dimitar into using the fork for too long.
P.S. Thanks for adding the feature, it will save me writing tons of documentation explaining how to configure Geany to work with the Android SDK, I can just do it automatically for users now :)
Hey, positioning Geany as direct opposition to Eclipse and Google, fair fight, anybodys game :-D
Cheers Lex
Cheers, Matthew Brush
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Thu, 2 Feb 2012 10:14:15 +1100 Lex Trotman elextr@gmail.com wrote:
It would be really good if someone other than me tests it, my test plugin is rather dumb.
I tested with the following code in plugin_init():
build_set_menu_item(GEANY_BCS_PROJ, GEANY_GBG_EXEC, 1, GEANY_BC_LABEL, "boza");
And, after I open a project and load the plugin, Set Build Commands looks like this: <<attachment>>
Tested with the previous BuildFuncs version (without group_count). Execute command #1 initially exists but with all fields empty.
--
In plugin.h BuildFuncs, void (*build_remove_menu_item), and void (*build_set_menu_item) are indented with spaces instead of tabs.
Hi Dimitar,
On Sat, Feb 4, 2012 at 6:43 AM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Thu, 2 Feb 2012 10:14:15 +1100 Lex Trotman elextr@gmail.com wrote:
It would be really good if someone other than me tests it, my test plugin is rather dumb.
I tested with the following code in plugin_init():
build_set_menu_item(GEANY_BCS_PROJ, GEANY_GBG_EXEC, 1, GEANY_BC_LABEL, "boza");
And, after I open a project and load the plugin, Set Build Commands looks like this: <<attachment>>
Thanks for testing.
I can't reproduce this, I put your line exactly in the plugin_init of demoplugin, and although it led me to a bug updating the menu that I have fixed, the project properties dialog was fine.
Can you post the problem plugin, or better reproduce the problem with demoplugin so we can eliminate other issues.
Tested with the previous BuildFuncs version (without group_count). Execute command #1 initially exists but with all fields empty.
--
In plugin.h BuildFuncs, void (*build_remove_menu_item), and void (*build_set_menu_item) are indented with spaces instead of tabs.
Fixed (why Geany decided to switch I don't understand, I just push the tab key and it does the rest :)
Cheers Lex
-- E-gards: Jimmy
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 4 Feb 2012 09:23:33 +1100 Lex Trotman elextr@gmail.com wrote:
I tested with the following code in plugin_init():
build_set_menu_item(GEANY_BCS_PROJ, GEANY_GBG_EXEC, 1, GEANY_BC_LABEL, "boza");
Can you post the problem plugin, or better reproduce the problem with demoplugin so we can eliminate other issues.
My mistake of some sort. With a clean clone (I'm using patched Geany) and the demoplugin, the problem is gone.
On 4 February 2012 22:44, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sat, 4 Feb 2012 09:23:33 +1100 Lex Trotman elextr@gmail.com wrote:
I tested with the following code in plugin_init():
build_set_menu_item(GEANY_BCS_PROJ, GEANY_GBG_EXEC, 1, GEANY_BC_LABEL, "boza");
Can you post the problem plugin, or better reproduce the problem with demoplugin so we can eliminate other issues.
My mistake of some sort. With a clean clone (I'm using patched Geany) and the demoplugin, the problem is gone.
There having been no complaints for a week, committed.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 02/03/2012 11:43 AM, Dimitar Zhekov wrote:
On Thu, 2 Feb 2012 10:14:15 +1100 Lex Trotmanelextr@gmail.com wrote:
It would be really good if someone other than me tests it, my test plugin is rather dumb.
I tested with the following code in plugin_init():
build_set_menu_item(GEANY_BCS_PROJ, GEANY_GBG_EXEC, 1, GEANY_BC_LABEL, "boza");
And, after I open a project and load the plugin, Set Build Commands looks like this:<<attachment>>
Is your Geany up to date with Git? There was a problem with the project dialog and Glade that was exactly like this not very long ago, but it should be fixed in Git now.
Cheers, Matthew Brush
On Sat, Feb 4, 2012 at 10:00 AM, Matthew Brush mbrush@codebrainz.ca wrote:
On 02/03/2012 11:43 AM, Dimitar Zhekov wrote:
On Thu, 2 Feb 2012 10:14:15 +1100 Lex Trotmanelextr@gmail.com wrote:
It would be really good if someone other than me tests it, my test plugin is rather dumb.
I tested with the following code in plugin_init():
build_set_menu_item(GEANY_BCS_PROJ, GEANY_GBG_EXEC, 1, GEANY_BC_LABEL, "boza");
And, after I open a project and load the plugin, Set Build Commands looks like this:<<attachment>>
Is your Geany up to date with Git? There was a problem with the project dialog and Glade that was exactly like this not very long ago, but it should be fixed in Git now.
This fork was made after your fix, so it should not be the problem. And it doesn't happen here :)
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Am 01.02.2012 23:42, schrieb Matthew Brush:
P.S. Thanks for adding the feature, it will save me writing tons of documentation explaining how to configure Geany to work with the Android SDK, I can just do it automatically for users now :)
Once you have something remotely usable, please show off :)
As I'm working on the android port of Rockbox (among other things) I'm also interested a android plugin. I currently use Geany for the C bits and eclipse for the java bits.
However, my situation is not that bad, since I can build the apk through "make apk" as well (after "reverse engineering" what the ADT plugin for eclise does) :) As of recently, ant works too.
Best regards,
On Mon, 30 Jan 2012 15:16:35 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
On 01/28/2012 06:08 AM, Dimitar Zhekov wrote:
Hi,
How can I $subject?
FWIW, I also have a need for this for an Android plugin I'm working on (using Eclipse is sooo painful).
So far I've found a need to both get and set the build commands for a project (and the working dir) and also to programmatically cause them to run (IIRC this is already working by a keybindings hack).
Would like to have some way to mess arround with build commands also for geanylatex for e.g. having a master document etc.
Cheers, Frank
