On Tue, Jan 31, 2012 at 10:03 AM, Colomban Wendling <[email protected]> wrote: > Le 30/01/2012 23:22, Lex Trotman a écrit : >> On Tue, Jan 31, 2012 at 5:13 AM, Dimitar Zhekov >> <[email protected]> wrote: >>> On Mon, 30 Jan 2012 14:08:59 +1100 >>> Lex Trotman <[email protected]> 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 >>> [email protected] >>> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel >> _______________________________________________ >> Geany-devel mailing list >> [email protected] >> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > > _______________________________________________ > Geany-devel mailing list > [email protected] > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel _______________________________________________ Geany-devel mailing list [email protected] https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
