Re: [Geany-devel] Geany-Plugins: MAINTAINERS file
Hi >> I suggest dropping the "Paid" status altogether if no one has used it by >> the time all the plugins' info is filled in. > > I disagree. Currently there might be no plugin maintainer being paid to > work on a plugin, but: > - this might change (...) > - is something user should be able to see to resynch there demandings > with reality. > > I'm reading e.g. support@pidgin mailing list and more than once a week I > need to facepalm myself because of users don't understand they are not > talking to some paid support. I really don't want to end up on Geany > with such situation. Even if someone is paid, he will probably be paid to do something that person that is paying want (feature, bug fix), not helping random people with support. But such status will just make someone say something like: "Hey, you are being paid, DO AS I WANT AT ONCE!!!" -- Best regards, Yury Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Replacing the control socket with dbus
Hi Will Geany be able to run without dbus after this change? -- Best regards, Yury Siamashka On 31/12/2011, Arthur Skowronek wrote: > Hi, > > http://memegenerator.net/cache/instances/400x/12/12436/12734680.jpg > > with this little stupid meme I would like to start a discussion about > replacing the current control socket living "somewhere" in the > "~/.config/geany" directory space with implementing GApplication from > recent GLib versions. > > As it looks to me the current tasks of the control socket are: > * ensure some basic uniqueness (open files via the geany command >in an already running instance) > * provide ability to perform basic operations on a running Geany >instance like > - opening files > - go to a certain position in the file. > - obtain a list of documents opened in the current instance > > These tasks can be accomplished with GApplication too. On top of that we > would get rid of: > * cluttering the filesystem with sockets > * possibility of a dead lock in the doclist command > * general freeze while a client is connected to the socket. > > The downside would be that the required version for GLib would be pushed > to 2.28 and this version is not available on the stable branch for all > distributions. > > My suggestion therefore is to put this at least on the Todo list and > replace it with the planned feature to use dbus. > > On top of that I would offer my free time to work on this topic as soon > as all requirements are met, if appreciated. > > > Greetings and a happy new year, > Arthur S. > ___ > 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
Re: [Geany-devel] [geanyprj] coding style patch
Hi Sorry I didn't follow conversion to github and I am not really familiar with new workflow. So as GeanyPrj maintainer how do I commit patch to mainline? Should my github user be added to "main" geany-plugins repository or I need to create new fork with related changes and create pull request to main geany-plugins from time to time? This github stuff is a bit confusing for me. > On 12/12/2011 06:51 AM, Johann SAUNIER wrote: > > Hi there, > > > > This is a new patch for Geanyprj. It doesn't implement any functionality > > or bug fix. It's only a cosmetic patch to comply to Geany's coding > > conventions. > > > > Since geany-plugins has moved on GitHub, is there an equivalent to the > > "tracker->patches" functionality of SourceForge for sending patches ? > > > > Yep, > > In Github land it's called a "pull request". While logged in to Github, > navigate to the geany-plugins repository and click the "fork" button. > It will make a copy of the repository under your account. Create a new > branch, hack away and when it's ready, click the "Pull request" button > on Github and it will notify committers that you have something ready in > your branch to be merged. > > Of course like you did here on the ML is fine too, but it's easier to > loose track of if it's not persistent somewhere. > > Cheers, > Matthew Brush > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] How about calling the next release 1.0?
On Thu, 22 Sep 2011 15:28:21 +0200 Colomban Wendling wrote: > >> > >> What about Geany 3000? Or some kind of other stupid release name like > >> ''busel', 'verabei', 'krumkach' ... > > > > Heh, I like "krumkach", sounds in German quite funny :). > > BTW, how are Geany codenames chosen? :-' My list just uses belarussian birds names: stork(busel), sparrow(verabei), raven(krumkach) -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] How about calling the next release 1.0?
Hi But why only 1.0? GNOME 3.* KDE 4.* Scite 2.* What about Geany 3000? Or some kind of other stupid release name like ''busel', 'verabei', 'krumkach' ... Best regards, Yura Siamashka On 20/09/2011, Thomas Martitz wrote: > Am Di, 20.09.2011, 13:43 schrieb Lex Trotman: >> On 20 September 2011 21:23, Frank Lanitz wrote: >>> Hi, >>> >>> Am 20.09.2011 12:07, schrieb Ji?í Techet: >>>> just one very quick and possibly stupid idea. How about getting rid of >>>> the 0 version prefix and calling the next release 1.0? >>> >>> To make it short: As we are about two weeks ahead of next release I >>> disagree. After 0.21 release we got a lot of structural changes we might >>> could think about a 1.0 too, but I don't feel its needed at the moment. >> >> I have to disagree with you on this Frank, the version number is >> nothing to do with structural or technical issues, it is a project >> issue. Changing the version number doesn't affect translation or >> anything else that takes time to do, so it isn't going to delay the >> release. >> > > > I agree. There's no reason to wait until after the upcoming release. 1.0: > the earlier, the better. > > This release should be the most stable one ever made, so 1.0 is even more > justified. 0.X simply isn't justified anymore. It sounds like Geany was > alpha software, but it has indeed better release quality that the majority > of software out there. > > Best regards. > > ___ > Geany-devel mailing list > Geany-devel@uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > -- Best regards, Yury Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues? [PATCH]
On Mon, 28 Mar 2011 23:00:54 +0200 Colomban Wendling wrote: > > Anyway here is patch that make Geany don't parse tags when user is actively > > typing. > > I'm not sure about this patch, because it is then really easy to make > the tag list never update automatically. > E.g. if update timeout is set to 1s, just type something every 999ms and > then update will never happen, even if there is actually 1s free to do it. Please show me that energeezer that type something every second and even have time to inspect tags while doing it. :) It is quite unrealistic to me. On other hand if someone is just typing parse delay can be annoying if his file is HUGE. > > Are really the update making something unresponsive for you? Actually I was happy with Geany performance even before any related changes, so it is not very important to me, but I think it can be usefull to topic starter. > > But maybe I'm worrying too much and this only need the timeout to be > configured otherwise, I may try to tune this if you really think it's > important. > > I also plan to try to move the TagManager parsing in a separate thread > at some point, maybe it'll help (though maybe it's the UI update that > takes most of the time...). No, I suspected this first and disabled UI update during research (delay seemed the same), but maybe it is worth to make smart update. Parser report that some tags were actually changed and you call UI update only then (if it is not done already) -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues? [PATCH]
Hi On Sun, 27 Mar 2011 14:15:45 +1100 Lex Trotman wrote: > > 1) geanyprj act only on "document-open", "document-save", > > "document-activate" callbacks > > 2) geanyprj add a lot of TMWorkObject objects using > > tm_workspace_add_object() to Geany > > And tm_workspace_add_object sets the parent to be the whole workspace! Can something be done for this? > Because of item 2) above I think this will reparse all open files. I don't think it is true. I used mantisbt project to test. Initially it takes few seconds to load the project (parse all files). Delay during typing is much less then second. Anyway here is patch that make Geany don't parse tags when user is actively typing. -- Yura Siamashka update-tags-only-on-idle.patch Description: Binary data ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Performance issues?
On Wed, 23 Mar 2011 23:49:41 +1100
Lex Trotman wrote:
> Thats a bit harder, probably Yura, the plugin writer will need to take
> a look at the problem I'd say.
I looked at the problem:
1) geanyprj act only on "document-open", "document-save", "document-activate"
callbacks
2) geanyprj add a lot of TMWorkObject objects using tm_workspace_add_object()
to Geany
3) Geany call update_tags_from_buffer() very often.
I think this function somehow reparse a lot of objects because of
"update_parent" param. I am not sure what this param actualy mean but if I
change function this way performance is back to normal (I don't say we need to
change it, it is just research):
--- a/src/document.c
+++ b/src/document.c
@@ -2263,7 +2263,7 @@ static gboolean update_tags_from_buffer(GeanyDocument
*doc)
/* we copy the whole text into memory instead using a direct
char pointer from
* Scintilla because tm_source_file_buffer_update() does modify
the string slightly */
sci_get_text(doc->editor->sci, len, text);
- result = tm_source_file_buffer_update(doc->tm_file, (guchar*)
text, len, TRUE);
+ result = tm_source_file_buffer_update(doc->tm_file, (guchar*)
text, len, FALSE);
g_free(text);
#endif
return result;
--
Yura Siamashka
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ideas on increasing quality of plugins
On Sat, 12 Mar 2011 02:53:47 +0100 Colomban Wendling wrote: > Unfortunately, believe me that non-fatal warnings are use to be ignored > by unexperienced programmers, believing that if their code compile it is > then OK. > And I don't see why a warning upgraded to an error on every build would > be worst than a syntactical problem (as I described above previously)? > In a typical situation, the developer who writes the plugin should get > the warning (well, the error), see his plugin don't build, care > (hopefully :D), and then fix it directly even before committing and then > before anybody else could face the problem. > Don't you think? Sorry I have not read all thread but here is my 2 cents. Warnings as errors are bad because different compiler version can generate different compile warnings. So It can be pain for developer to find and fix all warning for all compiler versions in the world. This issue is the same for for all other validation tools (valgrind, etc). Actually such maintains bother can be enough reason to abandon geany-plugins and move plugins to somewhere else. -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] POLL: Mark developers names on plugins translateable Yes/No
On Mon, 27 Dec 2010 01:30:38 +0100 Frank Lanitz wrote: > Hi folks, > > During review of German translation of Geany-Plugins I found a number > of author's names marked as translatable. I don't see any big reason > for doing this as most likely (and from my current point of view in all > cases) it's just a copy & paste task when doing the translation. > Therefor I suggest to don't mark author's names as a translatable at > all. What do you think about? I vote to left them translatable, copy paste is simple enough, but if language uses different set of characters (for example cyrillic), English names can look weird. On other hand I don't know how to spell correctly most of the names so I leave them English. -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Hi
On Mon, 1 Nov 2010 07:54:56 +0530 shan chak wrote: > Hi, > Can anyone please help me in following things: > > 1. I believe the source control is svn? Yes > 2. Which are the libraries ( not standard C ones ) being used in geany?I > figured out gtk+ 2, are there any more libraries ? Other libraries are embedded in Geany (scintilla, tagmanager). > 3. Can anybody mentor me? Probably, no. If you have any questions about development just ask them here. > 4. There is a lot of auto-generated code in geany, can I get a stripped > source code which I can compile with plain gcc and and not use autogen.sh? > It becomes a lot easier to understand then. If you really don't like autotools you can use waf. > 5. Which is the better way to start a) try to reproduce some bugs then > create a patch or b) implement some requested feature? See what you really want to add to Geany or fix bug that annoy you. (if you start working on something you don't need enthusiasm will expire very quickly) > 6. Can I be assigned a bug or a feature request? OR is this voluntary?how > does this works? Just fix it and send a patch here. -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [ANNOUNCE] gproject - yet another geany project plugin
On Thu, 10 Jun 2010 22:31:27 +0200 Jiří Techet wrote: > I'd be happy if you tested it - you'd be the first one ;-). I tested your plugin and I really liked it, nice job. My geanyprj plugin idea about all project files located at the one basedir made bad joke of me. Lately I have to work with lot of crazy code (SDK for different embedded boards). Here is sample structure. /apps/my_app1 /apps/my_app2 /libs/common_lib /huge_external_app_sources/kernel /huge_external_app_sources/xorg When I work on "my_app1" I want to be able to use tags for "my_app1" and "common_lib", but I can't do this with one basedir. Since you have to manually open project in your plugin, I think it won't conflict with your plugin's ideology to make "basedir" as list as all other fields. So both "my_app1" and "common_lib" sources will be part of the project and big nasties as my_app2, kernel and xorg won't. -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Nightly build failed: Plugins Windows build
Hi On Wed, 9 Sep 2009 03:51:55 + (UTC) nore...@nightly.geany.org wrote: > See http://nightly.geany.org/win32/build_win32_plugins_stderr.log for details. > > Error messages: > ../../plugins_svn/codenav/src/codenavigation.c: In function > `switch_menu_item_activate': > ../../plugins_svn/codenav/src/codenavigation.c:251: warning: comparison > between signed and unsigned > ../../plugins_svn/codenav/src/codenavigation.c:315: warning: ISO C90 forbids > mixed declarations and code > ../../plugins_svn/geanylua/glspi_run.c: In function `debug_hook': > ... > ../../plugins_svn/geanyprj/src/sidebar.c:278: warning: ISO C90 forbids mixed > declarations and code > default/geanyprj/src/utils_11.o: In function `save_config': > /home/enrico/geany/_build_/plugins_win32/../../plugins_svn/geanyprj/src/utils.c:170: > undefined reference to `_utils_write_file' > collect2: ld returned 1 exit status Can anyone help me with this error? I have no idea how to fix this error. -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Plugin Keybindings (default values)
Hi
I am writting python debugger plugin which will use a lot of keys. So question:
How can I assign default shortcuts to actions like toggle breakpoint,
next command etc
so user will not have to assign a lot of keys himself.
Also please add sci_set_marker_at_line and sci_is_marker_set_at_line
to plugin API. I will need them to show breakpoints and current line
when debugging.
patch is attached
--
Best regards,
Yury Siamashka
diff --git a/plugins/geanyfunctions.h b/plugins/geanyfunctions.h
index 234961c..288690f 100644
--- a/plugins/geanyfunctions.h
+++ b/plugins/geanyfunctions.h
@@ -168,6 +168,10 @@
geany_functions->p_sci->set_target_end
#define sci_replace_target \
geany_functions->p_sci->replace_target
+#define sci_set_marker_at_line \
+ geany_functions->p_sci->set_marker_at_line
+#define sci_is_marker_set_at_line \
+ geany_functions->p_sci->is_marker_set_at_line
#define templates_get_template_fileheader \
geany_functions->p_templates->get_template_fileheader
#define utils_str_equal \
diff --git a/src/plugindata.h b/src/plugindata.h
index 42fae7b..d2c0ed2 100644
--- a/src/plugindata.h
+++ b/src/plugindata.h
@@ -50,7 +50,7 @@
enum {
/** The Application Programming Interface (API) version, incremented
* whenever any plugin data types are modified or appended to. */
- GEANY_API_VERSION = 155,
+ GEANY_API_VERSION = 156,
/** The Application Binary Interface (ABI) version, incremented whenever
* existing fields in the plugin data types have to be changed or reordered. */
@@ -341,6 +341,8 @@ typedef struct SciFuncs
void (*set_target_start) (ScintillaObject *sci, gint start);
void (*set_target_end) (ScintillaObject *sci, gint end);
gint (*replace_target) (ScintillaObject *sci, const gchar *text, gboolean regex);
+ void (*set_marker_at_line) (ScintillaObject* sci, gint line_number, gboolean set, gint marker );
+ gboolean (*is_marker_set_at_line) (ScintillaObject* sci, gint line, gint marker);
}
SciFuncs;
diff --git a/src/plugins.c b/src/plugins.c
index 395b3fe..645b0ea 100644
--- a/src/plugins.c
+++ b/src/plugins.c
@@ -171,7 +171,9 @@ static SciFuncs sci_funcs = {
&sci_get_line_end_position,
&sci_set_target_start,
&sci_set_target_end,
- &sci_replace_target
+ &sci_replace_target,
+ &sci_set_marker_at_line,
+ &sci_is_marker_set_at_line
};
static TemplateFuncs template_funcs = {
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: New Release: Geany 0.18
On Tue, 18 Aug 2009 00:05:59 +0200 Enrico Tröger wrote: > They indeed broke. I think this should be fixed now in SVN by mapping > the numpad keys to their "normal" equivalents, the code is based on the > same thing happening in Scintilla. > > If it doesn't work or breaks something else or not all necessary keys > were mapped, just tell us, as usual :). Thanks, everything works fine now. That was really fast. -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: New Release: Geany 0.18
On Sun, 16 Aug 2009 20:45:00 +0200 Enrico Tröger wrote: > we are happy to announce a new release of Geany! It seems that KP_End and KP_Home keys don't work in 0.18. End and Home key works fine. In 0.17 End, Home, KP_End and KP_Home works fine. Tested at work and at home (x86 and amd64). -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Restructuring the Geany-plugins project?
On Wed, 3 Jun 2009 20:02:07 +0200 Enrico Tröger wrote: > While discussing how a possible geany-plugins release could be done and > what's necessary, we came across the idea of changing the above idea: > give up the independence of each plugin and instead create one big > project consisting of the various plugins but with only one build > system. Following you'll find a list of pros and cons which instantly > came to my mind as some kind of rationale. I am perfectly fine with current state of things but I don't mind one big project idea too. So generally I don't care and will be fine with any decision made by people with strong opinion. -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
