[Geany-devel] debugger plugin
Hello, everybody. My name is Alexander, i'm a software developer from St.Petersburg, Russia. I started to use Geany at my job, mostly for C++ development, and only feature I was not satisfied with was debuggers support. I looked at the existing GDB plugin but it's seemed a little bit unusual for me, and next I thought about multiple debuggers support in one plugin. So I started to develop my own plugin with the foregoing in mind: - more VS, Netbeans,... likely GUI - multiple debuggers support Now i have GDB working more or less enough for using, and feel like I need some feedback. (I started to work on bashbd backend, but faced some problems and decided to postpone it, until GDB and general features will work well). So, project adress at SF is https://sourceforge.net/projects/geanydbg/ Also I've prepared a little page with a description - http://geanydbg.sourceforge.net/walkthrough.htm Waiting four your opinions and feedbacks. -- Best regards, Alexander Petukhov alexander.petuk...@mail.ru ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] debugger plugin
SF username is cesspit I'll commit code next week after finishing one bugfixing. I'll cope with autotools, note sure about Waf, never dealed with, I'll ask here if have questions One more question is about windows build, how to avoid plugin to attemt to build under win32? much effors are needed to support cross-platformin, don't have time for it now. as for GeanyGDB replacement, don't want to sound too assertive, but my one already offers more features than GeanyGDB does and from my point of view is more user friendly, Of course to get it right one definitely has to try out both of them. also I still aim to reach multiple debuggers support, to do this i wrote some kind of abstracion layer code so general name debugger looks suitable for me here also. Best regards, Alexander On Sun, 30 Jan 2011 14:09:10 +0100 Enrico Tröger enrico.troe...@uvena.de wrote: On Tue, 25 Jan 2011 14:50:17 +0300, Александр wrote: Thanks Thomas, I'll try to look at crash on non-debug modules soon, though i didn't have this bug when I tried to debug a plugin itself i.e. run geany as a debug target. To Geany-plugins mainteiners: how can i start to move source code to geany-plugins svn? First, tell us your Sourceforge username, so we can give you SVN write access. Then just commit your plugin code into trunk/geany-plugins/debugger (or whatever name you'll choose). Afterwards, you/we need to update the autotools and Waf-based build systems to get your plugin built. But this is one of the last steps. Regading plugin name, does anybody mind if the name will be simply debugger? Though GeanyGDB has this title exposed in plugins dialog, no such name is presented as a real plugin name. It definitely will confuse users but I don't know of anything better so far too :(. Can it replace the geanygdb plugin at some time? Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc -- Alexander Petukhov alexander.petuk...@mail.ru ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] debugger plugin
need more bug reports/feedbacks to make it more stable. will try to do all my best until next geany-plugins release, by the way how often do you issue plugins releases? On Sun, 30 Jan 2011 15:31:14 +0100 Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: On 30.01.2011 14:57, Alexander Petukhov wrote: as for GeanyGDB replacement, don't want to sound too assertive, but my one already offers more features than GeanyGDB does and from my point of view is more user friendly, Of course to get it right one definitely has to try out both of them. I agree with this, your plugin is a lot better and should eventually replace geanygdb. But yours is not quite stable yet (although geanygdb also isn't IIRC). Best regards ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel -- Alexander Petukhov alexander.petuk...@mail.ru ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] debugger plugin
yeah, u're right, always visible debug tabs make it hard to tell if the debugger running or not. but, if you are not on the debugger page, i.e. don't see it, you also can't guess what is going on, and the second reason for make them persistent was a bug when after several run/stop actions VTE stopped displaying input or output characters. Now I realized that it was not about it, probably it's better to change things back. As to showing debugger state, I was thinking of a toolbar button with Run or Stop image, based on debugger state, or how is itr done in most IDEs? On Sun, 30 Jan 2011 18:40:55 +0200 Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Sun, 30 Jan 2011 18:05:51 +0300 Alexander Petukhov alexander.petuk...@mail.ru wrote: need more bug reports/feedbacks to make it more stable. As of revision 36: Shows all tabs always, so I can't easily tell when a program is running (Browse and Debugger in the Target tab are disabled, so there is some indication). Applies the debug vertical scroll policy on Geany startup. Interestingly, when Geany is started and debugger is activated after that, the standard policy remains, even when debugging. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel -- Alexander Petukhov alexander.petuk...@mail.ru ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] debugger plugin
I'm done with commitimg code. Someone could probably look if it;s all right wih it, I'm rather new with svn and autotools. Regard, Alex On Sun, 30 Jan 2011 15:47:04 +0100 Enrico Tröger enrico.troe...@uvena.de wrote: On Sun, 30 Jan 2011 16:57:52 +0300, Alexander wrote: SF username is cesspit I added you to the SF geany-plugins project, so you should be able to commit to the SVN repository. I'll commit code next week after finishing one bugfixing. Cool. I'll cope with autotools, note sure about Waf, never dealed with, Don't worry. I can update the Waf stuff for you. I'll ask here if have questions One more question is about windows build, how to avoid plugin to attemt to build under win32? much effors are needed to support cross-platformin, don't have time for it now. The only working way of building the geany-plugins on Windows is to use Waf, at least I do it this way and using autotools on Windows is just a bit of pain in the a** (IMHO). So, to answer your question, I can add a check in the Waf build system to not build the debugger on Windows. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc -- Alexander Petukhov alexander.petuk...@mail.ru ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] debugger plugin
Frank, Hi. dbm_bash.c is excluded from autotools build, because it doesn't work for now. As to cast warnings, I don't have them, can guess it's about glib, cause its function are called at lines that were mentioned. Regarding build system, yeah I didn't get clear about commom autoconf and gettext package, will change it today. Best regards Alex On Sat, 5 Feb 2011 15:18:52 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Hi, On Sat, 5 Feb 2011 15:48:27 +0300 Alexander Petukhov alexander.petuk...@mail.ru wrote: I'm done with commitimg code. Someone could probably look if it;s all right wih it, I'm rather new with svn and autotools. I had a short look. If you include it to geany-plugins project you will not need to have an autogen.sh etc. inside your src tree. Maybe you can have a look at http://git.geany.org/geany-plugins/commit/?id=2aae88ad74247fb882975eec558b5ecceeafc12d as I did add a new plugin some time ago with autotools integration to geany-plugins project. However, during test for putting it into waf I found some issue which is preventing from being build on my box: [ 4/143] c: debugger/src/callbacks.c - _build_/debugger/src/callbacks.c.1.o ../debugger/src/breakpoints.c: In function ‘lookup_breakpoint’: ../debugger/src/breakpoints.c:79: warning: cast to pointer from integer of different size ../debugger/src/breakpoints.c: In function ‘handle_break_remove’: ../debugger/src/breakpoints.c:142: warning: cast to pointer from integer of different size ../debugger/src/breakpoints.c: In function ‘breaks_add’: ../debugger/src/breakpoints.c:301: warning: cast to pointer from integer of different size ../debugger/src/breakpoints.c: In function ‘breaks_is_set’: ../debugger/src/breakpoints.c:445: warning: cast to pointer from integer of different size [ 5/143] c: debugger/src/dbm_bash.c - _build_/debugger/src/dbm_bash.c.1.o [ 6/143] c: debugger/src/dbm_gdb.c - _build_/debugger/src/dbm_gdb.c.1.o ../debugger/src/dbm_bash.c: In function ‘on_read_from_bash’: ../debugger/src/dbm_bash.c:187: warning: passing argument 4 of ‘g_io_channel_read_line’ from incompatible pointer type /usr/include/glib-2.0/glib/giochannel.h:234: note: expected ‘gsize *’ but argument is of type ‘gint *’ ../debugger/src/dbm_bash.c: At top level: ../debugger/src/dbm_bash.c:514: error: ‘get_files’ undeclared here (not in a function) ../debugger/src/dbm_gdb.c: In function ‘on_read_from_gdb’: ../debugger/src/dbm_gdb.c:256: warning: passing argument 4 of ‘g_io_channel_read_line’ from incompatible pointer type /usr/include/glib-2.0/glib/giochannel.h:234: note: expected ‘gsize *’ but argument is of type ‘gint *’ ../debugger/src/dbm_gdb.c: In function ‘get_stack’: ../debugger/src/dbm_gdb.c:903: warning: cast from pointer to integer of different size Maybe you can be so kind and have a look. To be honest, I didn't ;) Cheers, Frank -- http://frank.uvena.de/en/ -- Alexander Petukhov alexander.petuk...@mail.ru ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ideas on increasing quality of plugins
If nobody mind, let me state my opinions: 1. Maintaining I believe there has to be only one maintainer who is commiting code. As for me, the amount of code in a ordinary geany plugin is not that huge, one can easily support it. Others who has patches/improvements have to send them to the maintainer and it's he, who decides what to do with them and is somehow responcible for the result. Giving commiting rights to several people can cause mess in code. If the plugin is unmaintained for a long time, lets contact a developer to learn his plans and if he hasn't time for now (or at all) and there is someone else who wants to do his job - let this man to become a new maintainer, I think little developers will reject this suggestion if they really have no time to deal with the code for now. Current active maintainer have to mentioned on the plugins web-site in order to contact him to solve problems / send patches etc 2. Documentation Support Mathew, there has to be common documentation system, maybe we can start from standartization README etc standart files 3. Different repos Here I strongly disagree, I think this will also cause kind of a mess, why not to solve problems in te common repository? 4. Removing unsupported plugins from releases what do you think about the following scheme: divide all pluging into: - supported (that are acting really well) - unsupported or bad (having problems) ? So, every geany-plugins release will contain several packages: geany-plugins, geany-plugins-bad or geany-plugins-unsupported, something like this 5. Other language bindings - don't really think it can increase plugins quality dramatically, there can be problems in any language that you have to solve in order to make your code work correctly. And one more thing, as a debian user I see that there is still 0.19 plugins version even in unstable, maybe it's a good idea to move current developing version (0.21?) to unstable / testing to make debian users to help us in bug reporting? Cheers, Alex ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SF.net SVN: geany-plugins:[2161] trunk/geany-plugins/debugger
fixed. Regards, Alex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] saving plugin settings in a project file
I would like to store debugger settings such as watches, breaks, target etc in a project file. These are not the settings that apply to a plugin in a whole but look like being related to files user is working with, i.e. a project. After looking at project signals I was 100% sure that they are intended to give a plugin a place to store its settings that apply to a project. Yesterday on IRC we talked about it and Matthew said that it's better to have a distinct file. As for me, I'd better keep all session related settings in one file, i.e. in a project and would like to ask you here what do you think about? One more question is about project signals, looks like to save settings in a project a plugin is encouraged to add a notebook tab in project_dialog_create signal handler and to save setting when this dialog is closed when processing a project_save signal. The GKeyFile that is passed in project_open signal is closed right after sending a signal, so plugins can't use it for saving data. What if I want to write settings not using project settings dialog that looks unsuitable for a debugger, is it correct to initialize and the save a new GKeyFile to geany_data-app-project-file_name? Regards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] saving plugin settings in a project file
I agree that user doesn't have to open a project to be able to use debugging and settings are better be saved between geany startups. What I wanted was to have debug settings loaded at the same time I open files I worked with last time. And I kept in mind that there can be several sessions/projects that a user would like to save debug settings for. I also decided to use project file because there is no API to store plugin data in a session, but now I realize that I can store debug settings for a session in plugins own config, where all other plugin level stuff reside and if a user works with a project - store debug settings in a project, therefore supporting both project and session modes. I believe it's the right way. Regards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] geany-plugins: Bug in translation
It looks like it's a bug. I started to do russian translation today and noticed that some strings do not appear translated whatever I do with them while others do. Further investigation showed that the only translated strings are those that reside in the main plugin file, where plugin entry points are defined. I researched addons plugin and for it it's true, only strings from addons.c are translated. Maybe some bug with PLUGIN_SET_TRANSLATABLE_INFO macro? E-gards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins: Bug in translation
with geanysendmail it's fine now, I checked recently, but there is only one source file in it, so it follows the behaviour I've described. E-gards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins: Bug in translation
Latex insert special chars submenu is fine, but the actual strings loading also happens in geanylatex.c in create_sub_menu function, while in letters.c strings as glib docs say are only marked for translation using N_ macro, by the way I have no idea what does it mean ) E-gards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins: Bug in translation
just wanted to add more info: to easily see the effect try addons plugin and it's context menu Open URI and Copy URI menu items. Until some svn update, IIRC translations of my debugger and possibly other plugins were more complete, from some point I noticed that some strings become untranslated but then I decided that it was a bug in my plugin, and didn't pay much attention to it. E-gards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Plugins README / web pages
Hi, when modifying, actually stealing from treebrowser :) a README file, I came to what if we make plugins webpages of identical format? They look a little bit careless now. If nobody minds I can do this for all plugins, treebrowser's one looks pretty suitable for me as a draft. E-gards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Plugins README / web pages
does github requires a special README format? ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Plugins README / web pages
well, I uploaded a draft of a README to svn, in two words it's structure is like this: - title - image (if applicable) - contents list - about - usage - requrements - contact info About is a short paragraph about what a plugin is. Usage is the place where main information about plugin usage, tips, issues etc are supposed to be. I thought we can avoid duplication of Installation, Downloads, Bugs / Feature requests link sections in every plugin as there are distinct pages for this stuff at a plugin web-site. Let's discuss format and after that - reformat all READMEs. p.s. GeanyLaTex and Geanylua have external links in README instead of actual text, it's ok probably but a link on Geanylua's page seems to be broken. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins: Bug in translation
06.10.2011 20:19, Frank Lanitz пишет: On Wed, 05 Oct 2011 17:30:23 +0400 Alexander Petukhovde...@apetukhov.ru wrote: just wanted to add more info: to easily see the effect try addons plugin and it's context menu Open URI and Copy URI menu items. Until some svn update, IIRC translations of my debugger and possibly other plugins were more complete, from some point I noticed that some strings become untranslated but then I decided that it was a bug in my plugin, and didn't pay much attention to it. It looks a bit like its related to position of including of geanyplugin.h. I guess I've fixed it for geany VC but needs some further investigation. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel as I discovered the point is that you have to include config.h in every file that contains translatable strings, actually #define GETTEXT_PACKAGE geany-plugins is the only line that is needed from it. Previosuly it worked without it somehow. if GETTEXT_PACKAGE is not defined, textdomain(NULL) returns NULL, i.e. there is no textdomain set, with GETTEXT_PACKAGE it returns messages while I expected to see geany-plugins here. I tried to understand how i18n is realized in Geany but I couldn't find any textdomain call in Geany sources. 2Enrico: every plugin that do not include config.h in a file with strings seems to be untranslated now. As I mentioned above it worked without it earlier so I suppose other plugins can also miss this include and therefore be untranslated but I didn't check. So two ways so far: 1. include config.h everywhere it is nessesary 2. look up what has been broken till 0.20 which one to use? E-gards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins: Bug in translation
07.10.2011 10:56, Frank Lanitz пишет: Am 06.10.2011 22:51, schrieb Enrico Tröger: On Fri, 07 Oct 2011 00:44:58 +0400, Alexander wrote: 06.10.2011 20:19, Frank Lanitz пишет: On Wed, 05 Oct 2011 17:30:23 +0400 Alexander Petukhovde...@apetukhov.ru wrote: just wanted to add more info: to easily see the effect try addons plugin and it's context menu Open URI and Copy URI menu items. Until some svn update, IIRC translations of my debugger and possibly other plugins were more complete, from some point I noticed that some strings become untranslated but then I decided that it was a bug in my plugin, and didn't pay much attention to it. It looks a bit like its related to position of including of geanyplugin.h. I guess I've fixed it for geany VC but needs some further investigation. [...] as I discovered the point is that you have to include config.h in every file that contains translatable strings, actually #define GETTEXT_PACKAGE geany-plugins is the only line that is needed from it. Previosuly it worked without it somehow. if GETTEXT_PACKAGE is not defined, textdomain(NULL) returns NULL, i.e. there is no textdomain set, with GETTEXT_PACKAGE it returns messages while I expected to see geany-plugins here. I tried to understand how i18n is realized in Geany but I couldn't find any textdomain call in Geany sources. 2Enrico: every plugin that do not include config.h in a file with strings seems to be untranslated now. As I mentioned above it worked without it earlier so I suppose other plugins can also miss this include and therefore be untranslated but I didn't check. So two ways so far: 1. include config.h everywhere it is nessesary 2. look up what has been broken till 0.20 Ah, thanks for investigation. Then this is probably caused by the change to not automatically include config.h in geany.h which happened some months ago (this was a change in Geany where it was wrong before). Plugins just used that wrong behaviour and now it shows how they are broken. So we probably need to review each plugin again for this issue. Not sure whether this is the only reasons as at my hacking session yesterday I recognized some plugins of mine which do in include config.h but didn't work. I was able to fix at least the symptomes by moving #includegeanyplugin.h around so its being included on last position. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel yep, config.h i.e. #define GETTEXT_PACKAGE have to be placed before #include geanyplugin.h otherwise it doesn't work. I just wanted to say that some plugins do not even include config.h, at least my one didn't :) E-gards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins: Bug in translation
07.10.2011 11:46, Frank Lanitz пишет: Am 07.10.2011 09:34, schrieb Alexander Petukhov: yep, config.h i.e. #define GETTEXT_PACKAGE have to be placed before #includegeanyplugin.h otherwise it doesn't work. I just wanted to say that some plugins do not even include config.h, at least my one didn't :) Ah. OK. This lights up things a bit. Well, still 1 week left to finalize cleaning up ;) Cheers Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel Frank, sorry for embarrassing, can you do strings refreeze, I've found untranslated strings in debugger, I now understand what is mark for translation ), I had such statically allocated strings but fixed it with last commit. There were no commits to po till string freeze, so it doesn't seem to break anything. I planned to do translation and check other plugins for lack of config.h side by side then. E-gards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany is on Github
07.10.2011 19:28, Matthew Brush пишет: And don't forget to give me your Github usernames cesspit ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [RFC] Geany Plugin Names
29.10.2011 09:41, Matthew Brush пишет: Hi all, Is anybody opposed to removing the geany and Geany prefix from the plugins in Geany-Plugins. I mean at least for the directory name in the source tree, README/Site, and PLUGIN_SET_INFO() name? It's always bothered me when I go into *Geany's* plugin manager and see plugin names like GeanyFooBar. Obviously the plugin is for Geany and the Geany prefix makes the plugin not ordered correctly. Same goes for the SVN/Git repository source tree directory names. For example: Geany-Zencoding plugin could be Zencoding under the directory in the repo called zencoding. This is like many plugins already, for example: addons, codenav, debugger, devhelp, gproject (sorta :), pretty-printer, shiftcolumn, spellcheck, tableconvert, treebrowser, updatechecker, webhelper, and xmlsnippets. IMO these would be reasonable renames for the others: Old Name Plugin Info Name Directory = GeanyDoc Documentation?[1] doc or geanydoc GeanyExtrasel Extra Selections extrasel Geanygdb GNU Debugger[2] gdb GeanyGenDoc Documentation Generator gendoc GeanyInsertNum Insert Numbers[3] insertnum GeanyLatex LaTeX (Addons) latex GeanyLipsum Lorem Ipsum Generator lipsum GeanyLua Lua Plugins lua GeanyMacro Macro Recorder macro GeanyNumberedBookmarks Numbered Bookmarks numberedbookmarks GeanyPg Privacy Guard pg or gpg GeanyPrj Project Manager?[4] prj or project GeanySendMail Send Mail sendmail GeanyVC Version Control vc or vcs --[coming soon]--- GeanyMultiTerm Multi-Tabbed Terminal multiterm GeanyPy Python Plugins python GeanyZencoding Zen Coding zencoding == [1] Could we merge Devhelp and GeanyDoc? [2] Could we replace in favour of Debugger? [3] Should this go in Addons? [4] Could we merge GProject and GeanyPrj or are totally different? == Anyway, just a thought to make things more consistent and less redundant. It seems like while converting and moving to Git would be an ideal time to do this. Feel free to +1, -1, comment or ignore. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel +1 was thinking of it when translating plugin names ) as to gproject and geanyprj they differs in that gproject utilizes geany built-in project support while geanyprj uses it's own, so they are unlikely to be merged. Regards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [RFC] Geany Plugin Names
29.10.2011 14:22, Lex Trotman ?: you are right that any plugin packaged*separately* should indeed have geany in the package name but that doesn't affect directory names or plugin manager names +1 package names are packaging teams buisness, as they are already named with geany- prefix (at least *.deb ones) no changes for them except new folder names. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [RFC] Geany Plugin Names
On 10/31/11 4:47 PM, Colomban Wendling wrote: Le 31/10/2011 08:37, Frank Lanitz a écrit : On Mon, 31 Oct 2011 10:20:23 +1100 Lex Trotmanele...@gmail.com wrote: [...] Although in my, probably poorly informed, opinion, gproject seems to encompass most of geanyprj Not completely. The main difference is that gproject is an extension of Geany's projects. As such, displays just single project's files in the sidebar and shares the Geany's project settings file for its settings. geanyprj on the other hand can display multiple project's files in the sidebar and has separate project settings file for every project. This is slightly messy because you have two different projects next to each other. Originally gproject was like this too but then I decided to sacrifice the multiple project ability and play more nicely with Geany. About the project name change - I don't care as long as someone is able to invent two different names for the project plugins ;-). Thanks Jiri, Based on your description, project for gproject and projects for geanyprj? I disagree. Names do not differ enough. They look pretty much the same. I agree with Frank, the user is unlikely to see the difference, and would then be confused. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel just some thoughts: 1. current gproject (if I get it right there is another branch with multiple opened project support or other features) utilizes Geany built-in project support engine, actually it shows files with project-matching extensions in a tree view, don't anybody think that it can be included in Geany and be switched off/on like files and tags list? It will eliminate the problem of renaming. 2. rename geanyprj to something project-free. The concern for this: there is a Project root item menu in Geany and some other places where a user is faced with built-in projects; if we'll have a plugin naming *project/prj* it will definitely make hard for a user to understand what project is he working with now. Regards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [RFC] Document Messages
On 11/7/11 5:12 AM, Matthew Brush wrote: Hi all, I started working on something I'm calling document messages for lack of a better name. Put another way, GtkInfoBar :) The changes add a new document function called `document_show_message()` which will either show a GtkInfoBar on top of the Scintilla widget with the message or just show a modal dialog depending if the GTK+ version supports GtkInfoBar (2.18). I've only ported `monitor_reload_file()` and `monitor_resave_missing_file()` to use the new function for now, because I needed something to test with. The commits are here: https://github.com/codebrainz/geany/commits/document-messages And a screenshot is here: https://github.com/codebrainz/misc/raw/master/screenshots/geany-document-message.png Feedback is welcome. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel looks good, isn't it possible to change find in current file UI in the same manner, as in firefox, would be pretty usable imho. Regards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Some sort of thoughts about geany-plugins-devel-git-repo
On 11/15/11 8:55 PM, Frank Lanitz wrote: Hi developers, It has been a while when I first announced a mail about my idea of process after transition of geany-plugins repository. As from my understand the only open point is to have clarified the svn-url-reference question its a good point to tell you what I'm thinking of. Currently we do have about 25 people which are allowed to commit to geany-plugins svn. Not all of them are active at the moment (and might won't get active again sometime in future), some of them are low in time or no responsive at the moment. On the other hand we do have about 30 plugins, which are mostly maintained. As you know from discussion about e.g. geanydbg/debugger and the project plugins, some of them are currently not maintained very actively and are getting obsolete. Given the changes for Python plugin support in pipeline of Geany I'm in a good mood that we will have a increasing number of contributors and plugins available for Geany. Some of the new plugins will be distributed via the geany-plugins-project for sure as well as contributors like to add maybe features, bugfixes etc. to existing code basis. Unfortunately in past we had not really some kind of a quality assurance on committing code beside authors and maybe devel users. We introduced the make check build target a couple of month ago which gave a more critical view onto code. Based on this a huge number of warnings, memory leaks and bugs has been able being removed. But still issues are left. As we will have some kind of a reset with movement to github, its a good point to rethink about the way, how patches are introduced to geany-plugins. So this is my idea how to do so: We will have one master branch where all changes intended for releasing are going in. Features and new plugins are going to be developed inside branches (more late onto this topic) and once they are in a suitable status, they are getting merged into master branch. Release are generated from master branch and are getting marked with a tag. If there is any need for some minor release as we had e.g. with 0.21.1 there will be a release branch that will include all patches going in. If they are also needed to get applied on master, we can cherry-pick them or find some other way of merging them back. We can divide contributors for plugins into 2 groups: 1: Contributors to existing plugins or general infrastructure as e.g waf/autotools 2: Contributors of new plugins Here we should set up 2 processes: Contributions of group 1 should clone the repository and sending a pull request or patch to maintainer of plugins. Once they did this, the maintainer is reviewing the changes and including them into his branch. Contributors of new plugins shall send a pull request of full diff to release team. And this is another point. I imagine to have a release team which is taking care of overall quality of geany-plugins. This is including following: If a plugin maintainer is finishing a change or a review he is sending a merge request to the release team. After they did a review based on criteria given e.g. inside HACKING they are merging it into master branch. If the patch is not hitting a minimum on quality its getting refused. Thins to be done in front if you like this change: - Defining release team - Reviewing HACKING and defining basic quality criteria - Pushing all to github ;) What do you think? Feedback is highly welcome ;) Cheers, Frnak ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel Hi there, I also vote for increasing plugins quality, but as for me Franks ideas about different branches seem a bit overcomplicated. Maybe we can use git pre-commit hook to prevent commits that breaks some quality criteria? http://book.git-scm.com/5_git_hooks.html To be honest I didn't get much into details but it seemed to me that it can handle quality check tasks. So my suggestion is still to use a single common repo for all plugins and use commit hooks to prevent unqualified code. This requires that at some point all plugins in this repo pass this quality check, and here is what I suggest - move plugins from svn one by one, checking code for quality. For those that didn't pass we can create a distinct repo under geany organization. Once a maintainer or a volunteer refine a code to fit the requirements it can be moved to a main repo. Until then it can be still available but won't be included in g-p release (maybe we can create distinct release geany-plugins-unsupported, as IIUC I already suggested once). To easily move plugins between probably it's a good idea to use submodules, IIUC this is svn externals analogue. To make every plugin compile and build independently I vote for eliminating common po catalog, that I also suggested recently, this will also help to avoid translations intersection between different plugins. Renaming
Re: [Geany-devel] push access to plugins at github
On 12/15/11 2:41 PM, Frank Lanitz wrote: Am 15.12.2011 10:46, schrieb Alexander Petukhov: Can I be given a push access to the plugins repository? github user - cesspit done. Cheers, Frank ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel Great, Thanks! Regards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] plugins.geany.org update - contents now generated from the latest Geany-Plugins release
17.12.2011 20:05, Dominic Hopf пишет: Hi together, with today's commits [1] the behavior of the gencontent.sh has changed. The script now tries getting the README files from the latest Geany-Plugins release and not from git master anymore. For you as a plugin maintainer, this now means that you'd need to create a branch exactly named as the tag of the latest release and put changes to README files there as well in case they apply for an already released version of Geany-Plugins. gencontent.sh would look for changes in that branch then and not in master. In other words: plugins.geany.org now has the content of the README files of the tag 0.21.1. If you like to improve something there, the changes must be made to a branch called 0.21.1 created from the tag. This should apply to a common work flow when fixing issues in an already released version, so I guess no big deal for anyone of you. Feel free to correct me, if you think I am wrong with this. :) Any further suggestions or improvements are welcome, feel free to fork the stuff and open pull requests. ;) Best Regards, Dominic [1] https://github.com/dmaphy/plugins.geany.org/commits/master ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel Hi Dominic, I didn't get clear how to deal with the newly created branch after a bug is fixed in it: push branch to github, merge with master and push master or whatever? Can you pls give some more details. Regards, Alex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Markers
So all we need is the initialisation, and probably a common search routine for the convenience of plugins (although that isn't absolutely needed). The smaller the patch the more likely someone has time to test it and commit it. I would vote for having utility functions that manages a list of available markers instead of letting plugins manually find those that are marked with SC_MARK_AVAILABLE. I can imagine a situation when some plugin set its markers for several documents but didn't do it for others, so when another plugin tries to set it's own markers it came to that markers idenifiers for the same markers are different in different documents that means it's another job to keep track of it. having such functions as utils_ui_get_marker(), utils_ui_free_marker() seems more clear and robust. Regards, Alex ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins tests failures
25.03.2012 21:51, Quentin Glidic пишет:
On 25/03/2012 19:40, Matthew Brush wrote:
It almost sounds like it can't see the C files compiled by Valac. Is
there C files in `multiterm/src/`?
Nothing. This plugin is disabled. If you think it should run cppcheck on
Vala generated code (I’m not sure it’s worth it), at least it shouldn’t
when it’s disabled.
For the debugger one, I’d guess it’s a new feature added in cppcheck and
not released yet.
actually that is causing warnings:
const char *gdb_commands[] = { g_strdup_printf(-stack-list-arguments 0 %i %i,
active_frame, active_frame), -stack-list-locals 0 };
.
g_free((void*)gdb_commands[0]);
Return value of allocation function g_strdup_printf is not used.
heh, how dows it know? :)
it's definately used later in the code, but np, I'll fix to avoid warnings, as
soon as I open new pool request.
Alex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] [geany-plugins] SCN_DWELLEND when cursor leaves an editor window
If a mouse pointer dwells in editor and then leaves an editor window quickly then in editor-notify I receive SCN_DWELLSTART and no SCN_DWELLEND after, and it turns out that I show a calltip even if a mouse is no longer in a scintilla window. Looks like scintilla does not allow to retrieve a mouse position and so does geany. Does anybody have any ideas how to handle this? Regards, Alexander ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
