Devel November 2013

devel@lists.geany.org

21 participants
21 discussions

Replace & Find by default in the Replace dialog
by Pallai Roland 14 Nov '13

14 Nov '13

Hi, I made a PR: https://github.com/geany/geany/pull/189 It's not a big deal, but might come handy for some. What do you think?

1 0

Let's use Vala
by Matthew Brush 13 Nov '13

13 Nov '13

Hi all, In the spirit of the previous discussions about using C99 and C++ in Geany code with similar subject lines, I'd like to take a poll/discussion for allowing the use of Vala for new/re-written Geany code. The pros and cons likely will be slightly biased since I would obviously like to use Vala in Geany, but here they are anyway: Pros: ----- * Power of high-level OOP language using existing GObject backend with no C boilerplate required * Uses same type-system as existing C code * Automatic memory management * Clean expressive syntax (foreach, as, properties, signals, async, etc.) * Exceptions (which uses C/GError-style exceptions in generated C code) * No extra dependency for release users (generated C code can be shipped) * Can generate Gobject-Introspection bindings automatically allowing use from a bunch of cool languages like Python, JavaScript, etc (and as many other languages as support Gobject-Introspection) for plugins. * Easy to learn for anyone who's used C++, Java, C#, etc. * Uses all existing dependencies as its runtime library (ex. GLib/GIO). * Can generate C/H code that is usable from within existing C code, so no requirement to completely re-write, can just add on modular code as needed. * Can be tuned to output optimized C code, or call optimized C code quite easily * Can sometimes generate clever and/or optimized code that would be tedious to write in C. * Has Autotools and Waf support already, and using from plain GNU Make is trivial. * Actively developed and supported, and having active mailing list and IRC channels. (ex. it's easier to submit a patch to Vala language than ISO C). * AFAIK it generates C89-compliant code :) Cons: ----- * A fairly new language (since 2006). It's hard to argue against this, but also impossible to move forward without adopting new stuff at some point. * Some dark corners/bugs due to being such a new language (compared to C/C++). * Actively developed so sometimes we probably have to require specific valac versions to support certain features (ie. nothing like c89, c99, c++98, etc but not unlike supporting newer G* versions). * As with above, may require to use fairly modern/specific dependency versions of the G* C libraries (ex. might not work on RHEL or some other LTS distros). * Extra dependency (valac) for maintainers/developers. * Using non-GLib-based libraries requires to write boring but trivial binding .vapi files (not huge deal for existing Geany code). * Can sometimes generate heap-heavy or non-optimized code. * Can sometimes generate C code that causes warnings with common compiler warning flags, would require to disable some compiler warnings on generated C code to have a completely clean build (ex. use -w on all .vala code) * The documentation isn't as great as an ISO language that existed since forever. The official language specification isn't as complete or fleshed-out (ex. has TODOs) as an ISO language. There is lots of documentation out there, for example on the official Wiki, but it's still no substitude for definitive language reference and decades of books/literature on the subject. * More people know C than C++/C#/Java (ie. style of Vala). IMO, this one is untrue since people who use C nowadays are either well-versed embedded programmers who already know the higher-level stuff, C/Gobject/Gtk+ programmers who already know or can easily understand how the higher-level stuff works (ex. by looking at generated C code), high-level-only programmers who for the most part don't need to care about how the underpinnings work and already would know Vala since it's basically C#(/Java), or finally, and I believe the least likely; complete n00bs who would be much safer writing garbage in any high-level language than directly in something like C/C++ anyway. For more information about Vala, this a good starting point: https://wiki.gnome.org/Vala/Documentation If we can cleanly get more +1's than -1's (in principle, and especially from the core developers and active contributors), without wandering off into nitty-gritty details, version-specific bugs encountered that don't/won't specifically apply to Geany, stuff I have specifically accounted for in the pros/cons list, and minutia like we (especially ME) always do, then we can move forward with this and hammer-out those details later during integration, rather than stifflying the idea here in this thread as we (including ME) often do. If one or more of the things you like or dislike is already mentioned, there's no point in specifically responding to it unless you think it's unclear or inaccurate, just give your +1/-1 and see where it goes. Basically what I'm saying is that if we can keep this discussion on track and people show enthusiasm (or at least not strong distain, in principle) then I will personally volunteer my time to make it happen. If it turns into a zillion message thread about off-topic, or nitty-gritty stuff (which should occur later on, in a different thread) or hate from people who have never tried the language in earnest but still have a strong anti-opinion (especially based on old or presumed information, or general hate for the G* toolkit we already use), then I probably will just forget it, and probably no one else will move this forward. P.S. Sorry for stupid-sounding discussion rules, it's just an attempt to move something useful forward, productively, with consensus, without wasting our voluntary time discussing deep details too early-on, and based on past similar discussions on this list and knowledge I have about some poeple's existing opinions. Please don't take offense or rant about the stupid "rules", just believe I'm sincere in that I'm trying to organize the discussion more productively than usual (even if failing) :) Cheers, Matthew Brush

8 39

Please check your mail clients to support threads
by Frank Lanitz 12 Nov '13

12 Nov '13

Hi folks, Sorry for that Geany-OT posting... but please be so kind and take some second to check whether your mail client is respecting the threading when answering a post. I've got a lot of spitted up threads here and it's really annoying and time consuming to put them together again. In details: When answering a post, your mail client (or at latest yout mail server) should add a message ID to your mail. This can be checked in source of your mail and looks similar to: Message-ID: <527B726C.9070200(a)frank.uvena.de> (it's another post of myself) Also when hitting answer, your client should add the References and In-Reply-To header to new mail. Also pelase don't answer to the collection of mails. Cheers, Frank

2 2

Maintaining edit history on reload
by Arthur Rosenstein 09 Nov '13

09 Nov '13

Hi, I have a patch that adds support for maintaining the undo stack on document reload and allowing the reload operation to be reverted. Any interest in pulling this upstream? -- Cheers, Arthur

3 3

bug hunting #3
by Pavel Roschin 07 Nov '13

07 Nov '13

Moving forward to the software source code analysis. Updated more than 300 alloc-functions for GLib. Here are new results (better and better): https://gist.github.com/scriptum/7360333 Updated rules: https://github.com/scriptum/cppcheck-libs -- Best regards, Pavel Roschin aka RPG

3 2

bug hunting #2
by Pavel Roschin 07 Nov '13

07 Nov '13

Hello! Almost completed glib + Geany cppcheck config which leads to few new errors in code: http://pastebin.com/EihjrKyC I removed some false-pos. What do you think about goto-ing? Most leaks are because of return without free. Using goto instead of return and only one return at the end should be a good pattern which has no return-leaks (at least). Here is a new config (for Geany): https://gist.github.com/scriptum/7294264 Plugins update: https://gist.github.com/scriptum/7282262 -- Best regards, Pavel Roschin aka RPG

3 3

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel November 2013