Devel

devel@lists.geany.org

1641 discussions

spawning rewrite - RFC
by Dimitar Zhekov 05 Nov '13

05 Nov '13

Hi, As some of us know, I'm writing a completely new implementation of the spawning in Geany, to fix the issues under win~1, and to provide higher level interface, thus stopping the calling modules (build, search, ...) from doing "their own thing", for example tools.c using g_shell_parse_argv() even under win~1, which is a bug. You can have a look at the latest messages for [1]. My intention is to use this thread to discuss questionable spawning issues. So the first question is: should we _completely_ disable the console for win~1 console applications? If we do that, any stdout/err output not captured by a Geany pipe will be discarded. Under *nix, when Geany is not started from a terminal, such output normally goes to ~/.xsession-errors, which is somewhat useful. I propose to always create the win~1 programs with a minimized, non-focused window. For console programs, the uncaptured output will go to the console, and will be lost when the console is auto closed by win~1, but that's better than nothing. Moreover, if a console program crashes, the console will remain on screen until you confirm the win~1 crash dialog. [1] https://sourceforge.net/p/geany/bugs/943/ -- E-gards: Jimmy

3 4

[PATCH geany 1/2] gtkcompat: Add gtk_widget_set_can_default
by Quentin Glidic 05 Nov '13

05 Nov '13

From: Quentin Glidic <sardemff7+git(a)sardemff7.net> Signed-off-by: Quentin Glidic <sardemff7+git(a)sardemff7.net> --- src/gtkcompat.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/gtkcompat.h b/src/gtkcompat.h index ca1c187..9cfc50b 100644 --- a/src/gtkcompat.h +++ b/src/gtkcompat.h @@ -92,6 +92,8 @@ G_BEGIN_DECLS compat_widget_set_flag((widget), GTK_NO_WINDOW, !(has_window)) # define gtk_widget_set_can_focus(widget, can_focus) \ compat_widget_set_flag((widget), GTK_CAN_FOCUS, (can_focus)) +# define gtk_widget_set_can_default(widget, can_default) \ + compat_widget_set_flag((widget), GTK_CAN_DEFAULT, (can_default)) #endif #if ! GTK_CHECK_VERSION(2, 20, 0) # define gtk_widget_get_mapped(widget) GTK_WIDGET_MAPPED(widget) -- 1.8.4.1

2 2

spawning rewrite - RFC
by Dimitar Zhekov 04 Nov '13

04 Nov '13

Hi again, Win~1 supports some weird command line syntaxises: "c:\some path\program.exe - without closing quote "c:\some path\program.exe"foo bar qux - runs program.exe with: argv[0] = "c:\some path\program.exe"foo (or something similar) argv[1] = bar argv[1] = qux I'm going to disallow the first syntax to be able to join a command and an argument vector, and the second syntax because it's not clear whether all CRTL-s will handle it like msvcrt (the splitting is done by the CRTL, not Windows). The supported variants will be: "c:\some path\program.exe" "c:\some path\program.exe" foo bar qux as expected by any sane person. For the arguments, the normal win~1 quoting/escaping rules will apply: "foo bar" is a single argument "foo \"bar" is a single argument containing a " "foo \\\"bar" is a single argument containing \" etc. http://msdn.microsoft.com/en-us/library/windows/desktop/bb776391.aspx -- E-gards: Jimmy

1 0

splitwindow2
by Thomas Martitz 04 Nov '13

04 Nov '13

Hello, I just wanted to let you know that I'm working on a new splitwindow implementation and I would like to have early input. But, also as a warning, I'm progressing only slowly because I'm at the final phase of my master thesis which currently needs more attention that Geany hacking. Anyway, we all know about the limitations of the splitwindow plugin. They include (not a complete list): - the other view can only have one document - you cannot undo/redo: you need to select the tab in the main notebook to do that - state is not saved/restored across Geany restarts - it's completely awkward because the other view shows a doc that's also in the main view, editing in the other view will change the main view at the same time. - you cannot toggle between the views with a keybinding (e.g. ctrl+tab) - weird focus behavior - more... My plan is to reimplement splitwindow using a different approach: by having two real, independemt notebooks, one primary and one seconary. New docs will be opened in the primary one by default, but can be moved to the secondary one at will. This means that no document can be shown in both at the same time which makes it a loss less awkward. It also lets us lift the other limitations: - undo/redo will work - state can be saved across restarts (config file format will probably need some changes for this) - toggling with keybindings between views can work - you can arbitrarily assign docs to views using different methods The nice things about splitwindow that should be probably be kept: - chose between horizontal and vertical split - automatic sizing of the views - anything else? Unfortunately Geany's core is pretty hardcoded as to assume one (and only one) notebook for documents. This means that for this various changes to Geany core are necessasry, some of which may be difficult to do without breaking the plugin API/ABI. Some are gonna hate this but I'm not currently planning do this as a plugin because the core needs a lot of changes anyway for breaking the single notebook assumption. But I'm very open for discussion which is why I'm writing this early. I already have an experimental version up and running that doesn't even require all that much changes[1] and it seems to work nicely. See this[2] screenshot. So, any opinions? [1]: https://github.com/kugel-/geany/tree/splitwindow2 [2]: http://www.alice-dsl.net/simonemartitz/default/splitwindow2.png Best regards.

5 19

bug hunting with cppcheck
by Pavel Roschin 03 Nov '13

03 Nov '13

I checked the code with cppcheck (version from git). Also I created gtk config for cppcheck - if you are interested in, you could help me to fill it to improve analysis: https://gist.github.com/scriptum/7282198 cppcheck cannot check GTK programs because glib's design is not heap-friendly: most functions needs freeing memory and cppcheck doesn't know about them. In new versions you can specify glib functions in config (there is example one), but this is huge work... Geany: ./cppcheck ../geany --library=gtk `pkg-config --cflags glib-2.0` \ --max-configs=1 -j32 -q --template=gcc [../geany/src/editor.c:4866]: (error) Memory leak: f This is the one and real (return-after-malloc) bug. g_return_if_fail is danger: there should be g_goto_end_if_fail and nothing other to make sure you finished transaction. You will find similar leak in plugins. This is _very_ dangerous because it doesn't look like a macro and hides return keyword from you inside! Plugins are more interesting: https://gist.github.com/scriptum/7282262 Treebrowser bugs are false-pos. But they are appeared due to bad pattern (variable reuse): treebrowser_browse(gchar *directory, gpointer parent) ... directory = g_strconcat(directory, G_DIR_SEPARATOR_S, NULL); ... g_free(directory); Next leak markdown/src/conf.c:457 g_key_file_to_data never returns error (regarding to doc), this is false-pos but useless code could be removed Next leak ../geany-plugins/scope/src/menu.c:461 flase-pos, but it's a bad pattern using pointer after free. All others aren't false-pos and should be fixed. -- Best regards, Pavel Roschin aka RPG

3 5

Mistake in utils_invert_color
by Volodymyr Kononenko 30 Oct '13

30 Oct '13

Hi all! While playing with colors for pairtaghighlighter plugin, I saw that Scintilla is using BGR instead of normal RGB. I found existing code in Geany source to use it in my plugin. utils_invert_color from utils.c deals with replacing blue with red, but with mistake. Below are results of my testing with random color: 11111111 11001100 10011001 - input color 10011001 11001100 11111111 - result of my function (rgb2bgr) 00000000 00110011 01100110 - result of utils_invert_color A little source file is attached. If it is really mistake (maybe I don't know something), I will do commit and pull request. Any comments about this? -- Best regards, Volodymyr Kononenko http://kononenko.ws

2 2

Windows Support
by Lex Trotman 30 Oct '13

30 Oct '13

To all those who were adamant that Geany must support windows, what about providing some support to the nice man on the bug list? http://sourceforge.net/p/geany/bugs/1001/ Cheers Lex PS Matthew you are excused since you have already tried to help.

1 0

Harbour programming language
by Gmail 28 Oct '13

28 Oct '13

Hello folks, I like this nice editor and I am interested to know if it would be possible to add Harbour (www.harbour-project.org) language to it with syntax highlighting, intellisense, etc... I tried to read the “hack geany” webpage but I have to admit it was confusing to me... How can I add Harbour to it? I have a list of functions, commands and directives. Some things are like in "C" (comments, directives). Harbour is powerful wrapper from xBase to "C". Very interesting project in special for all the programmers from the Clipper and other xBase dialects that have an opportunity to make real 32 / 64 bit applications with the flexibility and easiness of xBase syntax. Example of some functions: AADD( <aArray>, <xValue> ) --> xValue ABS( <nExpression> ) –> nPositive ACHOICE( [<nTop>] , [<nLeft>] , [<nBottom>] , [<nRight>] , <acItems> , [<aSelectable>], [<cUserFunc>] , [<nFirstItem>] , [<nFirstRow>] ) --> nSelectedItem ACLONE( <aArray> ) –> aClone #include 'cFile' #declare cVar xValue etc... More examples online (CA-Clipper 5.3): http://www.itlnet.net/programming/program/reference/c53g01c/menu.html Harbour for those who doesn’t know what is: http://en.wikipedia.org/wiki/Harbour_(software) Maybe it’s easier to let you know it is an way better extension of CA-Clipper (also known as DBase, Flagship, xBase, xHarbour). It is a intuitive and powerful language. Thanks for any help. Regards, Mario Wan Stadnik Harbour programmer

1 0

On document pointer recycling
by Thomas Martitz 28 Oct '13

28 Oct '13

Am 24.10.2013 05:39, schrieb Lex Trotman: > > > PS On the recycling of doc structures and doc->is_valid, this does > have the advantage (for a structure where miscellaneous pointers to > the structure are going to exist in Geany and plugins) that doc > pointers will always point to a geanydocument struct. So the is_valid > test is always right. If the memory was returned and re-cycled into > some other struct, the old doc pointers could point to anything, and > could just as easily appear a valid document. So its safer than the > alternative, but the requirement to check is_valid really does need > more visibility since its an unusual idiom. The recycling & is_valid thing is completely bogus. It is wastes memory unnecessarily. The is_valid thing is giving false security. Because a doc becomes valid again after it was recycled you cannot be sure that the document is still the same. Yet DOC_VALID() gives a false positive here if code missed the document-swap behind the scenes. So basically code that cares about GeanyDocument cannot rely on DOC_VALID() anyway. The _only_ way to make sure things are alright is to cleanup per-document stuff in the "document-close" signal handler. If you don't connect to this signal your per-document code is broken, regardless of doc->is_valid. Even worse, this brokenness is hidden by valid doc pointers, whereas it would otherwise crash and suggest debugging the problem properly. The right way is to NULL'ify any cached document pointer in the signal-handler which makes recycling pointers unnecessary. Also, recycling the pointers is only possible because the document array never shrinks. So if you had opened a large number of documents and close many of them you waste a lot of memory. I vote for removing this idiom and transition the documents array to a GList which gives other nice advantages. Best regards.

5 21

Re: [Geany-Devel] [geany-plugins] Autoclose: v0.2 - many improvements (#114)
by Enrico Tröger 28 Oct '13

28 Oct '13

Hi all, On 10/20/13 21:01, RPG wrote: > * add removing pairing brace by Shift+BackSpace > * do not add semicolon in #define-s > * add semicolon after class and struct > * now works with GTK3+ (thanks Matthew Brush for patch http://pastebin.geany.org/r2VKS/) > * added scrollbar for settings > * improve semicolon completion > * added help > * added Tab jump to enclosed char (thanks Thomas Martitz: https://github.com/kugel-/geany-plugins/commit/7f19c3035abf6f8a7fa66c7b4c1e…) now that we have a quite feature rich auto-close plugin (I didn't test/use it but it already looks more mature than what we have in Geany core), I wonder whether we could drop the now somewhat redundant and always buggy code in Geany core which provides the same feature. Any opinions? Pavel: I guess the auto-close plugin is at least as production ready as the current buggy code in Geany and so can be used as replacement? Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc

6 9

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel