Devel October 2013

devel@lists.geany.org

20 participants
29 discussions

Plugins build warnings
by n＠sk0 28 Oct '13

28 Oct '13

Hi all, there are some build warnings in plugins, nothing serious i think, just be aware of it. Warnings are in "geanygendoc", "codenavigation", "geanylua" and "geanysendmail" plugins. Full build log can be found here : http://pastebin.geany.org/USg8M/

1 0

Fwd: Bug#727161: geany-plugin-latex: Seems to prevent window manager from working correctly
by Frank Lanitz 25 Oct '13

25 Oct '13

Hi, Is somebody of you using GeanyLaTeX with Gnoem2. If yes, can you please be so kind check the report of Julian ... I'm afraid I cannot reproduce it on my box. Cheers, Frank -------- Original-Nachricht -------- Betreff: Bug#727161: geany-plugin-latex: Seems to prevent window manager from working correctly Package: geany-plugin-latex Version: 1.23+dfsg-3 Severity: normal If I open a LaTeX document in geany, I cannot use Meta + Left arrow or Meta + right arrow in GNOME 3 to move and resize the window to occupy the left / right half of the screen. Switching to the tab of a non-LaTeX file makes the keys work again. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (980, 'unstable'), (500, 'unstable'), (100, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages geany-plugin-latex depends on: ii geany [geany-abi-69] 1.23.1+dfsg-1 ii geany-plugins-common 1.23+dfsg-3 ii libc6 2.17-93 ii libglib2.0-0 2.36.4-1 ii libgtk2.0-0 2.24.21-1

1 0

Segmentation fault when auto-close plug-in is enable
by n＠sk0 25 Oct '13

25 Oct '13

There is strange behaviour when Auto-close plug-in is enabled. Steps to reproduce : 1. open Geany 2. Enable auto-close plug-in 3. open several files for edit 4. Click Ctrl+W (close document) -- Expected result : Currently opened document is closed. -- Actual result : Segmentation fault -- See attached gdb backtrace for more info. Debug info : Geany-INFO: Geany 1.24 (git >= ef33175), en_US.UTF-8 Geany-INFO: GTK 2.24.22, GLib 2.36.3 Geany-INFO: System data dir: /usr/local/share/geany Geany-INFO: User config dir: /home/nask0/.config/geany Geany-INFO: System plugin path: /usr/local/lib/geany Geany-INFO: Added filetype CUDA (57). Geany-INFO: Added filetype Rust (58). Geany-INFO: Added filetype Scala (59). Geany-INFO: Added filetype Graphviz (60). Geany-INFO: Added filetype Cython (61). Geany-INFO: Added filetype Genie (62). Geany-INFO: Added filetype Clojure (63). Geany-INFO: Added filetype Go (64). Geany-INFO: Disabling terminal support Geany-INFO: Loaded: /usr/local/lib/geany/addons.so (Addons) Geany-INFO: Loaded: /usr/local/lib/geany/autoclose.so (Auto-close) Geany-INFO: Loaded: /usr/local/lib/geany/geanylipsum.so (GeanyLipsum) Geany-INFO: Loaded: /usr/local/lib/geany/geanyvc.so (GeanyVC) Geany-INFO: Loaded: /usr/local/lib/geany/htmlchars.so (HTML Characters) Geany-INFO: Loaded: /usr/local/lib/geany/geanyprj.so (Project) Geany-INFO: Loaded: /usr/local/lib/geany/splitwindow.so (Split Window) Geany-INFO: Loaded: /usr/local/lib/geany/treebrowser.so (TreeBrowser) Geany-INFO: Loaded: /usr/local/lib/geany/xmlsnippets.so (XML Snippets)

6 25

Lets move to C99
by Matthew Brush 20 Oct '13

20 Oct '13

Hi, Up till now we've tried to stay compatible with ANSI C89 because of GTK+-stack doing so (unless I missed the real reason?). I propose we update to allowing C99 for the following reasons: - restricted character set support in <iso646.h> (originally specifed in AMD1) - wide-character library support in <wchar.h> and <wctype.h> (originally specifed in AMD1) - restricted pointers - variable-length arrays - fexible array members - complex (and imaginary) support in <complex.h> - type-generic math macros in <tgmath.h> - the long long int type and library functions - increased translation limits - remove implicit int - the vscanf family of functions - reliable integer division - universal character names - extended identifers - binary foating-point literals and printf/scanf conversion specifers - compound literals - designated initializers - // comments - extended integer types in <inttypes.h> and <stdint.h> - remove implicit function declaration - preprocessor arithmetic done in intmax_t/uintmax_t - mixed declarations and code - integer constant type rules - integer promotion rules - vararg macros - additional math library functions in <math.h> - foating-point environment access in <fenv.h> - IEC 60559 (also known as IEC 559 or IEEE arithmetic) support - trailing comma allowed in enum declaration - %lf conversion specifer allowed in printf - inline functions - the snprintf family of functions - boolean type in <stdbool.h> - idempotent type qualifers - empty macro arguments - new struct type compatibility rules (tag compatibility) - _Prama preprocessing operator - standard pragmas - __func__ predefned identifer - VA_COPY macro - additional strftime conversion specifers - LIA compatibility annex - deprecate ungetc at the beginning of a binary file - remove deprecation of aliased array parameters (Source: list is 2nd hand from http://www.open-std.org/JTC1/sc22/wg14/www/docs/n869/) And that's just improvements since 1999 (way back when I was in high school), not to mention more recent changes in the latest C11 standard. I think for us the most likely consequences are: - Coding in the new millennium style :) - Microsoft Visual C++ compiler is not C99 conformant and plans not to ever be AFAIK (of little consequence since we don't compile with MSVC). - Allowed to use // style comments - Allowed to declare loop counter-style variable inside the for loop. - Use standard C instead of G*-portability wrappers in various place (bool, fixed-width ints, etc.). This is just sort of random, but I feel that some our code could be better if we depended less on G*-stack and more on (>10 year old) ISO standards. P.S. Sorry for the bikeshed bait. Cheers, Matthew Brush

7 33

Re: [Geany-Devel] Ping on Bug #943 - windows build command
by Matthew Brush 18 Oct '13

18 Oct '13

On 13-10-03 05:31 AM, Nick Treleaven wrote: > Moving to devel list. > > On 02/10/2013 22:58, Matthew Brush wrote: >> On 13-10-02 04:40 AM, Nick Treleaven wrote: >>> On 01/10/2013 22:28, Matthew Brush wrote: >>>> On 13-10-01 05:34 AM, Nick Treleaven wrote: >>>>> Just checked my email, was away last week. I'll have a look at it, >>>>> but I >>>>> doubt the GLib spawning has been fixed. Either way it should be >>>>> definitely be tested before reverting to the broken GLib spawn. I know >>>>> GLib spawn doesn't work with my version of GLib/gtk, which isn't that >>>>> old (1yr?). >>>>> >>>> >>>> Locally on my Win7 VM I have reverted the patch and removed all the >>>> existing SYNC_SPAWN-guarded stuff and rid of win32-specific and to just >>>> use GLib spawning same code on all platforms and it runs easily as good >>>> as it does before the changes (just did some basic testing though). >>>> It's >>>> still not nice and non-blocking like it is on Linux, but seems to be no >>>> worse-off after removing like 200 lines of code :) >>> >>> If you push your branch I'll try it. I'll need to use it for a few weeks >>> to be convinced though. I remember the problem only occurred for certain >>> things, maybe running make or non-gnu binaries or something. >>> >> >> For testing purposes it should be as simple as disabling the SYNC_SPAWN >> workaround[1]. > > I tried that a while ago, it didn't work. That was when I added the > SYNC_SPAWN macro. > "Didn't work" how? The only time it didn't work for me was with old GTK+ 2.16 binaries the gspawn-win32-helper program would crash instantly causing a Microsoft dialog to come up asking to debug the executable. It would be interesting to investigate the original original problem and maybe we can find a solution that gets rid of the other work-arounds all together. >> In the meantime, I suggest reverting the "fix" until the actual problem >> is identified and a fix is properly implemented. There's only 1 >> extremely minor conflict when reverting. > > IMO changing/breaking path quoting is far less important than having a Maybe to you, but it's very common on Windows to have spaces in the path names, it's even the default on Windows XP (Documents and Settings). To most people (ex. the bug reporters) it seems outright broken now, whereas before it worked. > spawn that doesn't block Geany or outright hang. This definitely It would be nice to figure out *why* it was hanging and fix *that* problem though, not just drop the existing workaround code and write 3rd workaround that's arguably worse[1] than the original issue. > happened very frequently when using dmd from dlang.org. See: > > https://github.com/geany/geany/commit/a3664fae9ece396952d732cc937e63192d8c6… > I don't remember seeing any bug reports for this, so it's possible it's limited to you or the specific application you were using, maybe a bug in a certain version of DMD? The commit messages doesn't explain what the actual root of the problem was or why it could not be fixed properly, or what was tried to fix it before abandoning the existing code. > > BTW the blocking and hanging was with the custom windows process > spawning code, not with GLib's spawning. GLib IME just doesn't report > the output properly, or at least not both stdout and stderr for all > binaries. What did you try to fix it before dropping asynchronous spawning? How did it improperly report its output? Did it cause the handlers for the IO channels not to always fire or something? What programs didn't it work with? What versions were tested? Can it be reproduced in a clean sample program outside of Geany? BTW, do you have a link to the upstream bug report for this issue? I googled a lot, and besides this old fixed issue[2], I don't seem to find much besides a few Geany-related things that just say "don't work" without additional details. Did anyone from Geany report the bug upstream or make note of which upstream bug is causing the original original issue? Cheers, Matthew Brush [1]: Causes a command prompt to popup, doesn't support filenames with spaces, uses a temp file, uses system(), leaves a bunch of complicated dead code, now 3rd way to spawn process, etc. [2]: https://bugzilla.gnome.org/show_bug.cgi?id=510664

5 35

Interested making a patch to add QML support
by Tory Gaurnier 17 Oct '13

17 Oct '13

I'm interested in making a patch to add QML support to Geany, but first I had a few questions. First of all, is anyone else already working on this? And if not, if I manage to get it working well would my patch be worked into the main Geany code so others could get it also? I've been learning programming for a while, but I've never patched or edited anyone else’s code, so I'm not making promises how fast I'd be able to get this done, of course from looking at the hacking page it doesn't look to complicated to add support for another language, I just wanted to ask these questions before I even attempted this. Honestly it'll probably take me longer to figure out how to create and submit the patch then it will to actually change the code in the source itself.

5 51

Re: [Geany-Devel] GeanyLiveDiff on github
by v01d 16 Oct '13

16 Oct '13

HI, since cmake actually depends on pkg-config for this one, I guess you should be able to set the PKG_CONFIG_PATH environment variable (using export) to point to the directory where the libgit2.pc file is located. After that, do (at the top level directory of the sources): mkdir build cd build cmake .. make sudo make install Matias On Tue, Oct 15, 2013 at 11:02 PM, Steven Blatnick <steve8track(a)yahoo.com>wrote: > I'd love to try this out, but I don't know much about cmake, or building > for that matter. > > I've installed libgit2 to /opt/ since I didn't see libgit2 in my repos. > How do I get cmake to see it? It complains that I don't have it installed. > > Thanks! > > Steve > > > On 10/15/2013 12:01 PM, v01d wrote: > > Hi, > I've pushed my code on github so others can use it and try it out. I'm > using it constantly and it feels really stable. > https://github.com/v01d/geany-livediff > > The plugin shows changed/modifed/added colored markers on the margin of > geany's editor windows. It currently works against the last saved version > on disk of a regular file and also against files versioned in a git > repository (using libgit). When a document is a regular file, the "old > version" reference is reset whenever the file is reloaded (either manually > or by geany). In the case of git versioned files, the diff is performed > between the editor contents and the last revision of this file on the > current branch. If the head reference changes (either by commiting or > changing a branch), the plugin recognizes this and updates the markers > accordingly (it uses a timer for this). > > The markers themselves are not pretty so if anyone wants to improve that > it would be great. > > Matias > > > _______________________________________________ > Devel mailing listDevel@lists.geany.orghttps://lists.geany.org/cgi-bin/mailman/listinfo/devel > > >

1 0

GeanyLiveDiff on github
by v01d 15 Oct '13

15 Oct '13

Hi, I've pushed my code on github so others can use it and try it out. I'm using it constantly and it feels really stable. https://github.com/v01d/geany-livediff The plugin shows changed/modifed/added colored markers on the margin of geany's editor windows. It currently works against the last saved version on disk of a regular file and also against files versioned in a git repository (using libgit). When a document is a regular file, the "old version" reference is reset whenever the file is reloaded (either manually or by geany). In the case of git versioned files, the diff is performed between the editor contents and the last revision of this file on the current branch. If the head reference changes (either by commiting or changing a branch), the plugin recognizes this and updates the markers accordingly (it uses a timer for this). The markers themselves are not pretty so if anyone wants to improve that it would be great. Matias

1 0

Drop GtkStock and use symbolic icons
by Yosef Or Boczko 15 Oct '13

15 Oct '13

Hi all, I think is good idea to make the UI more clean and modern. For this we need to port the images in the toolbar to symbol icons. Also, in GNOME 3.10 the Stock items is drop [1], and UI with Stock is look outdated. I attachad a patch and screenshot (with GTK+ 3.11.0, from git). I missing some symbols: Choose a color, Build, Search & Replace, Compile, Save All, Reverte, Close All and Quit icons. For Stock Icons I missing many places, but I started to work on this (it just search and replace). [1] https://mail.gnome.org/archives/gtk-devel-list/2013-July/msg00000.html Regards, Yosef Or Boczko

7 17

This is a test, was having issues sending to mailing list
by Tory Gaurnier 15 Oct '13

15 Oct '13

This is a test message, I kept getting error messages trying to send a reply to a thread in the mailing list, you guys didn't get a bunch of copies of the same message from me did you? If you did I apologize, my mail app kept giving an SMTP error and resending.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel October 2013