Re: [Geany-Devel] multiterm should be disabled if no valac is found
On 14-04-27 05:39 AM, Dimitar Zhekov wrote: $ ./autogen.sh ... checking for valac... valac configure: WARNING: no proper vala compiler found configure: WARNING: you will not be able to compile vala source files ... Plugins: MultiTerm: yes $ make ... make[3]: Entering directory `/home/build/projects/plugins/testing/multiterm/src' VALAC multiterm_la_vala.stamp /bin/bash: valac: command not found make[3]: *** [multiterm_la_vala.stamp] Error 127 I fetched a clean git, just to be sure there's no some older configuration left. Yeah I guess AM_PROG_VALAC() just issues those warnings instead of failing as I'd have expected. In a perfect world, the generated *.[ch] files would be distributed and when compiling (from tarball at least) no Vala compiler would be required. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] multiterm should be disabled if no valac is found
On 14-04-27 01:08 PM, Colomban Wendling wrote: Le 27/04/2014 21:24, Matthew Brush a écrit : On 14-04-27 05:39 AM, Dimitar Zhekov wrote: $ ./autogen.sh ... checking for valac... valac configure: WARNING: no proper vala compiler found configure: WARNING: you will not be able to compile vala source files ... Plugins: MultiTerm: yes $ make ... make[3]: Entering directory `/home/build/projects/plugins/testing/multiterm/src' VALAC multiterm_la_vala.stamp /bin/bash: valac: command not found make[3]: *** [multiterm_la_vala.stamp] Error 127 I fetched a clean git, just to be sure there's no some older configuration left. Yeah I guess AM_PROG_VALAC() just issues those warnings instead of failing as I'd have expected. In a perfect world, the generated *.[ch] files would be distributed and when compiling (from tarball at least) no Vala compiler would be required. That's the very reason why the absence of valac doesn't trigger a failure (hence disabling the plugin): because tarballs include the C sources, and then valac isn't required unless you want to change the Vala source. I'm not sure what we can do here… maybe magically detect it's not a tarball and then require valac? Not sure. One not great option would be to check-in the generated source. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Python question
On 14-04-26 12:50 AM, Pavel Roschin wrote: It should be in the current library (not sure correct term), like if it was C, you would call `dlopen(NULL, ...)`. I'm not familiar enough with ctypes to say exactly but if it had a function like `load_library()` I'd expect you would pass `None` where it expects a filename. Alternatively, you might try `geany.document.__file__` to pickup the C module's filename where the symbol lives, if that works. It works great, now I can access to all internal geany binary functions. But I can't access to geanypy.so functions :( e.g. lib.utils_remove_ext_from_filename _FuncPtr object at 0x27dc120 lib.Document_create_new_from_geany_document Traceback (most recent call last): File input, line 1, in module File /usr/lib64/python2.7/ctypes/__init__.py, line 378, in __getattr__ func = self.__getitem__(name) File /usr/lib64/python2.7/ctypes/__init__.py, line 383, in __getitem__ func = self._FuncPtr((name_or_ordinal, self)) AttributeError: ./src/geany: undefined symbol: Document_create_new_from_geany_document I tried another way: using document_close from geany binary: def doc_close(self, doc): ptrValue = int(str(doc)[13:-1], 16) lib.document_close(ctypes.cast(ptrValue, ctypes.c_void_p).value) Now I have segfault :) Is it possible that `GPointer` is a `PyCapsule` (or `PyCObject`) and not an actual `void*` pointing directly to a `GeanyDocument*`? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Python question
On 14-04-26 12:50 AM, Pavel Roschin wrote: It should be in the current library (not sure correct term), like if it was C, you would call `dlopen(NULL, ...)`. I'm not familiar enough with ctypes to say exactly but if it had a function like `load_library()` I'd expect you would pass `None` where it expects a filename. Alternatively, you might try `geany.document.__file__` to pickup the C module's filename where the symbol lives, if that works. It works great, now I can access to all internal geany binary functions. But I can't access to geanypy.so functions :( Another (untested) hack that might work: def geanypy_path(): import geany, os path = os.path.dirname( os.path.dirname(os.path.dirname(geany.__file__))) return os.path.join(path, geanypy.so) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Python question
On 14-04-24 09:44 PM, Pavel Roschin wrote: I'm played with GeanyPy plugin and faced with a problem. Here is the source code I created to get current document from sidebar: def press(self, widget, event, data=None): if event.button != 2: return mod, it = widget.get_selection().get_selected() doc = mod.get(it, 2)[0] According to sidebar.c, mod.get(it, 2) should return pointer to Document. This isn't supported/recommended to do in either Geany plugin API or GeanyPy, but see below. But Python doesn't know that this is document and doc variable in this example has type GPointer. How can I access to this document from python plugin? P.S. I tried to use ctypes.cast, no success. Currently I'm addressing document with a file path but it is a hack and isn't working for symlinks. If you really want to, maybe try to call the C function `Document_create_new_from_geany_document()` (in src/geanypy-document.[ch]) which is used by GeanyPy internally, but should be callable somehow from Python. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Python question
On 14-04-24 11:35 PM, Matthew Brush wrote: On 14-04-24 09:44 PM, Pavel Roschin wrote: I'm played with GeanyPy plugin and faced with a problem. Here is the source code I created to get current document from sidebar: def press(self, widget, event, data=None): if event.button != 2: return mod, it = widget.get_selection().get_selected() doc = mod.get(it, 2)[0] According to sidebar.c, mod.get(it, 2) should return pointer to Document. This isn't supported/recommended to do in either Geany plugin API or GeanyPy, but see below. But Python doesn't know that this is document and doc variable in this example has type GPointer. How can I access to this document from python plugin? P.S. I tried to use ctypes.cast, no success. Currently I'm addressing document with a file path but it is a hack and isn't working for symlinks. If you really want to, maybe try to call the C function `Document_create_new_from_geany_document()` (in src/geanypy-document.[ch]) which is used by GeanyPy internally, but should be callable somehow from Python. ... Unless all you want to do is get the current/active document, in which case just call `geany.document.get_current()` from Python. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Python question
On 14-04-25 10:18 AM, Pavel Roschin wrote: On 14-04-24 09:44 PM, Pavel Roschin wrote: I'm played with GeanyPy plugin and faced with a problem. Here is the source code I created to get current document from sidebar: def press(self, widget, event, data=None): if event.button != 2: return mod, it = widget.get_selection().get_selected() doc = mod.get(it, 2)[0] According to sidebar.c, mod.get(it, 2) should return pointer to Document. This isn't supported/recommended to do in either Geany plugin API or GeanyPy, but see below. But how can I do this in native way? I just want to implement simplest feature I proposed in PR #172 which seems will take forever to accept. I just meant it's not recommended for plugins to rely on the tree view implementation stuff like which tree model columns have various things packed in them and such just because it's undocumented and could change anytime. Anyway, you are of course free to do anything you want, and if that's the only way, what else can you do? :) If you really want to, maybe try to call the C function `Document_create_new_from_geany_document()` (in src/geanypy-document.[ch]) which is used by GeanyPy internally, but should be callable somehow from Python. How can I call this function? I could try to use ctypes to load library but I didn't find native way to get full path to geanypy library. It should be in the current library (not sure correct term), like if it was C, you would call `dlopen(NULL, ...)`. I'm not familiar enough with ctypes to say exactly but if it had a function like `load_library()` I'd expect you would pass `None` where it expects a filename. Alternatively, you might try `geany.document.__file__` to pickup the C module's filename where the symbol lives, if that works. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Geanypy bug
On 14-04-24 12:44 PM, Pavel Roschin wrote: I copied console.py in my home config dir (~/.config/geany/geanypy/plugins) and forgot to rename it (but file content and plugin name was changed). After that I had doubled plugin set in Python Plugin Manager:) What is the expected behaviour? Should it silently ignore the 2nd plugin? Auto-number them maybe? In short if you have two plugins with same file name in /usr and in ~/.config you will get this bug. Can you open a report on the bug tracker? https://github.com/codebrainz/geanypy/issues FWIW, if you think it should de-dupe the list and you like coding in Python, I'm pretty sure this is where would need changing: https://github.com/codebrainz/geanypy/blob/master/geany/loader.py#L77 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Any votes for a Project-Tree plugin?
On 14-04-17 04:43 AM, Frank Lanitz wrote: Am 17.04.2014 13:40, schrieb Lex Trotman: On 17 April 2014 21:17, Frank Lanitz fr...@frank.uvena.de wrote: Am 17.04.2014 12:59, schrieb Oly: yeah, i also have a snippet plugin and a python code checker plugin on my launchpad and there is a ppa for them as well, i am just not that good at promoting them, i just use them for work :) Maybe you can spread it a little? Maybe we could add at least some to g-p project? Matthew ... how would be the best way doing this btw? I just said to Oly on IRC: Frank would get heartburn trying to figure out how to manage Geanypy plugins in geany-plugins :) ;) Well yepp... Maybe not direct ading to geany-plugins, but having a good way to distribute them. I think _RPG_ was also asking for something like that earlier. Autotools has support for Python built-in, likely all that's needed is to somehow declare a dependency in the make file that each Python plugin depends on libgeanypy.la. In normal Automake, it might look like this for a plugin foo: fooplugin_PYTHON = foo.py bar.py etc.py fooplugindir = $(pkgdatadir)/geanypy/plugins #fooplugin_LDADD = $(top_builddir)/geanypy/src/libgeanypy.la I'm not sure about the last line, but presumably there's a way in Automake to say these files depend on that other file, install them both. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Windows binaries for testing (was: Re: Geany 1.23 Waf install under win32)
On 14-04-13 02:10 AM, Frank Lanitz wrote: On Sun, 13 Apr 2014 02:07:28 -0700 Matthew Brush mbr...@codebrainz.ca wrote: Python might be similar except that there is a official installer available which is easy to use. Though I think we should skip GeanyPy for this release but definitely should think about including in future releases. Sounds good. I've added it to [my] list of goals for 1.25 at ¹ I updated it a bit, feel free to revert :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] GeanyLaTeX segfault
On 14-04-09 01:15 PM, Frank Lanitz wrote: On Wed, 9 Apr 2014 23:57:49 +0400 Pavel Roschin ros...@scriptumplus.ru wrote: On Wed, 9 Apr 2014 23:17:02 +0400 Pavel Roschin ros...@scriptumplus.ru wrote: On Wed, 9 Apr 2014 20:48:35 +0200 Frank Lanitz fr...@frank.uvena.de wrote: Hi, Thanks for the work, bad for putting all together in one big blob. On Wed, 9 Apr 2014 21:58:59 +0400 Pavel Roschin ros...@scriptumplus.ru wrote: - geanylatex at close segfault (see Gist for backtrace and IRC for investigation) Will not search backlog of IRC. To much noise. What did you do to get this? Even I see what might could be the cause, I cannot reproduce it. I need more details please. Cheers, Frank This not actually reproducible. I enabled all plugins, after time Geany started to crash sometimes at exit. This is IRC history about this bug: https://gist.github.com/scriptum/10304696 In short: devhelp + geanylatex = crash at exit I assume it only happens, when a TeX file having focus on closing? I think for some reasons, and this is what b4n also mention on IRC, devhelp is destroying/changing the doc-pointer at some point. Not sure. It happens even with empty (few *.c files) Geany. But who knows what happens internally. I do not use Geany for TeX, so probably it crashes without TeX documents (probably because I don't remember all details). Currently I have all plugins disabled and crashes didn't appear. I had some crash with devhelp at booth at CLT when I wanted to show somebody some feature. But wasn't able to reproduce. Maybe some timing thing? Devhelp plugin shouldn't change document pointer, it only reparents the document notebook into another notebook, but it doesn't change its name and ui_lookup_widget() can still find it and such. Actually the concept is mostly copied from SplitWindow plugin which does something quite similar, so if you are running SplitWindow + Devhelp, I can almost guarantee some problems (although it really shouldn't *crash*, but rather spew assertion failures to terminal and just not work correctly). The geanylatex bug I looked at from pastebin on IRC the other day looked to me like Scintilla's notification was firing after the GeanyEditor, GeanyDocument or GeanyFiletype was destroyed/re-used/whatever and it was dereferencing a NULL or invalid pointer. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] 'shiftcolumn' plugin - keyboard shortcut conflict
On 14-03-25 04:19 PM, Shankhoneer Chakrovarty wrote: Thanks Lex. It is actually preferable that plugins do not have default keybindings. It is not known what combination plugins will be loaded and so it is not known what combination of keybindings might clash, and it is not known what keybindings a user might define themselves that can clash. So I would recommend that default keybindings be removed from plugins. I understand, I would remove the default keybindings. The problem is this plugin doesnt have its own preference page in the Plugin Manager window. Activating this plugin will mean the user has to go to Edit-Preference (not the Plugin preferences)-Keybindings to set the keybindings for this plugin which is a lot of clicks. What I would suggest is that plugin should have its own preference page and a way to tell the user how to set the keybindings and the recommended keys. One of the ways could be putting all those things in plugin description. What do you think? I think this is the normal way though, I don't think (m)any plugins provide own keybindings preferences outside of the main one. There was a fairly recent commit which added a Keybindings button into the Plugin Manager dialog that jumps directly to the keybindings group for the selected plugin. IMO, this is not too hard. I agree that the plugin could/should tell the user how to configure/use it though, either in the README file or wherever. In the case of Shift Column plugin, I think the README file should be more explicit about what the plugin actually does. When I tried it the other day, I had no clue what it should do as move blocks of text horizontally could mean several different things, and the most obvious one is built into the editor already just using the Tab/ShiftTab keybindings (to indent/dedent). If you're looking to get started contributing to Geany-Plugins, a couple simple things could be to make two separate pull requests on github, one to replace the default Shift Column keybindings with 0s (no default binding), and then a separate pull request to improve its README/docs. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Hello!
On 14-03-19 10:51 AM, Federico Reghenzani wrote: Thank you! I decided to start writing some code for geany-plugins (first I think codenav plugin), but I have two question: 1) a problem, I try to ./autogen.sh for geany-plugins and: configure: error: Package requirements (geany = 1.24) were not met: Requested 'geany = 1.24' but version of Geany is 1.23.1 but: $ geany --version geany 1.24 (git = 854993e) (built on 2014-03-11 with GTK 2.24.22, GLib 2.38.2) You might have Geany installed into some other prefix, you can check by running `which geany` and removing the last part, for example to assign it to a variable: $ PREFIX=`which geany | sed 's|/bin/geany||'` Then do like this: $ cd geany-plugins $ ./configure --prefix=$PREFIX --with-geany-libdir=$PREFIX/lib $ make install If you haven't run `autogen.sh` yet, you can pass those same options to `autogen.sh` instead of `configure` the first time (and then use just `configure` with those options after). I don't know what the reason of `--with-geany-libdir` but it seems to help the build system to find the lib directory even though it's just `$PREFIX/lib`. 2) I'm new on github, what is the correct method to send my code? Create a fork repository and issue a pull request? It's the best way, yep. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Hi!
On 14-03-18 03:28 PM, Shankhoneer Chakrovarty wrote: Thanks Matthew and Dimitar. Can you please tell me what is SF and PR? Also, can you please assign me a bug or a feature request? I know I can pick anything from the list but since I am new to this project, I think it will be better for me not to chose by myself any bug/feature thats too complicated for me to implement and mess up the code. You can also check the sister project Geany-Plugins which is likely to need more love than Geany core. If I remember correctly there are at least several plugins without maintainers, and we are also trying to get all plugins to build with GTK3, as well as probably loads of bugs and feature requests on the bug tracker (linked from geany.org bugs page). Can you please tell me one such plugin? There are so many plugins that its very tough to get an idea which plugins are still alive and has a maintainer and which not. In the MAINTAINERS file, there's a field 'S' (for status), any with 'Orphan' are for sure orphaned, others may be as well, but just not officially or updated in that file. If you meant for porting to GTK3, I'm not sure if there's an official list of unported ones, but it should be reasonably simple to look inside the build/*.m4 file for the plugin to see if it has GTK3 build system support yet. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [geany/geany] 71b48b: Regenerate 16x16 Geany icon to be not cutoff
On 14-03-16 05:20 AM, Enrico Tröger wrote: Branch: refs/heads/master Author: Enrico Tröger enrico.troe...@uvena.de Committer: Enrico Tröger enrico.troe...@uvena.de Date:Sun, 16 Mar 2014 12:20:05 UTC Commit: 71b48bd6fb2e499e3352ad70c3e2cfa567ef667b https://github.com/geany/geany/commit/71b48bd6fb2e499e3352ad70c3e2cfa567ef667b Log Message: --- Regenerate 16x16 Geany icon to be not cutoff For some reason, the icon was cutoff in the upper left corner. From the GIT history, I can't find any real reference for the reason, so I guess this was just a mistake when convertig the 32x32 icon to 16x16. If anyone knows better, please tell me. I remember the rationale was explained here: http://sourceforge.net/p/geany/bugs/1010/ And from looking at Git, it's always been like that since your commit 5 years ago: https://github.com/geany/geany/commit/8abccc9bea0ac29cdc1adf3821ea4cec507c7cae Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Win32 color chooser dialog removal, concerning the Pull Request #215
On 14-03-05 12:14 PM, Enrico Tröger wrote: On 04/03/14 16:41, Matthew Brush wrote: On 14-03-04 06:57 AM, Steven VALSESIA wrote: Hi everybody ! I copy-paste a code that belong to Peter Scholtens that add an apply button to the color chooser. But to make that code useful to windows users, and make the code more maintainable, I choose to remove the Win32 API window dialog and put the Gtk's one ! As long as it's not the new toy GTK3 dialog made for exclusively for smart phones, it's really really terrible. Does someone know why that dialog has been used for ? Does somebody feel that move disrespectful ? :P IMO, it should follow the use_win32_native_dialogs (or whatever) preference at least, like the other native win32 dialogs. But, I see no point in completely removing it while leaving all the other win32 native dialogs in there, it seems kind of an arbitrary change. Agreed. @Steven: the reason for the native win32 dialogs is simply that people requested it. And I think it's not that bad in general to have native dialogs while it is also good to have GTK dialogs which are also somewhat native, just to GTK. It's just the win32 API which is horrible. Yeah, and its interaction with the GTK+ event/drawing loop (or lack thereof) that causes craziness like this: http://codebrainz.ca/images/geany-native-no-redraw.png Also the dialogs are somewhat inconsistent, in that from the main menu View-Set Font always uses the native win32 font-chooser dialog on Windows regardless of the use native dialogs setting, and inversly in the preferences dialog Interface-Fonts never use native dialogs, irrespective of that option (due to using GtkFontChooserButton). Also the colour chooser should be in a plugin too IMO, not mixed-in to core code, but I guess that's a different subject :) Yes. IIRC there is somewhere a TODO floating around suggesting this. Don't remember where it was (code, file TODO, my head, ...). I actually moved it into a plugin before, I'm sure it's around somewhere buried in a branch in my backups, if anyone cares enough I can try to find it. IIRC the main barriers were; feature regression due to inability to have a plugin enabled by default; not integrated into the toolbar customization stuff; some of needed win32 API functions were not exposed (rightly so). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Win32 color chooser dialog removal, concerning the Pull Request #215
On 14-03-04 06:57 AM, Steven VALSESIA wrote: Hi everybody ! I copy-paste a code that belong to Peter Scholtens that add an apply button to the color chooser. But to make that code useful to windows users, and make the code more maintainable, I choose to remove the Win32 API window dialog and put the Gtk's one ! As long as it's not the new toy GTK3 dialog made for exclusively for smart phones, it's really really terrible. Does someone know why that dialog has been used for ? Does somebody feel that move disrespectful ? :P IMO, it should follow the use_win32_native_dialogs (or whatever) preference at least, like the other native win32 dialogs. But, I see no point in completely removing it while leaving all the other win32 native dialogs in there, it seems kind of an arbitrary change. Also the colour chooser should be in a plugin too IMO, not mixed-in to core code, but I guess that's a different subject :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Hello!
On 14-03-03 07:52 AM, Federico Reghenzani wrote: Hi all, I'm an italian student in Engineering of Computer Systems, and I'd like to contribute to Geany. My first (and for now only) contribution is a simple pull request about shortcuts. I hope to be helpful for this project! Welcome! Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Plugins Quality Check
On 14-02-21 06:30 AM, Colomban Wendling wrote: Le 21/02/2014 03:16, Lex Trotman a écrit : [...] Well, the same as for code written by humans, the C compiler warning is telling us something *might* be wrong with the code. The Vala compiler may have bugs, so such things need checking the same as manual code, to avoid possible UB. If, as in these cases, it seems to be ok, then its just noise, but unless you check you don't know. IMO, we should just disable warnings on Vala's generated code altogether and rely only on the Vala warnings. Anything else is a Vala bug and not our problem. I would've done this long ago but I'm not sure how to properly/portably disable warnings for a particular target in Autotools. Whilst I don't agree totally (see above), thats probably better, but I dunno how to do it either, Autotools experts please assist. Per-target flags are easy, they are target_CFLAGS, target_LDFLAGS and so on. Thought, note this is per *target*, so if you mix C and Vala in the same target, obviously those flags will apply to all use of the C compiler, linker, etc. for this target. To disable warnings, there are 2 solutions: 1) don't add the warning flags; 2) add flags to disable the warnings. Solution 1) seems reasonable, but it won't be able to remove user-set warnings in CFLAGS -- and we just *cannot* ignore user CFLAGS, there may be include paths and stuff. Also, with the current setup it seems easier to just add flags than remove existing ones, because currently they are added automatically in vars.build.mk. Adding them conditionally may be tricky, because AFAIK make conditionals are unportable (e.g. BSD make and GNU make aren't compatible). Maybe Loong Jin knows better? Even if we go with solution 2), we have 2 ways to apply it: overriding some user warnings flags or not. Overriding user warning flags would allow for users to have stricter warnings for real C code while not being flooded by Vela-generated ones, but again, it may be considered harmful. OTOH, if we don't override it basically only benefit people not having a custom CFLAGS defined (even if it is set to the same value as our default). Attached are 2 examples of solution 2), not overriding and overriding. Just toy patches for now, but it should work. OK, I didn't think it was OK to assume GCC was the compiler, so I wasn't sure how you'd portably (across compilers) tell the compiler flags without doing a bunch of configure checks to see whether the compiler accepted such flags or something. My GCC/Clang-specific idea was to maybe just use something like `-Xcc=-w` or whatever in one of the VALAFLAGS variables to disable all warnings related to Vala code, though I'm not sure if Autotools invokes the C compiler via Valac or independently. [...] The GTK2 Vala binding is deprecated, same as the GTK2 C API/library. There is a compiler flag for Valac to make it disable the deprecation warnings, if that is desirable. Is there really a flag to only disable deprecated warnings? IIRC there is only --disable-warnings, and IIUC it removes everything not an error? I believe Valac's --disable-deprecated option will disable it warning about deprecated annotations in the VAPI files. I'd have to test it to be sure though. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Plugins Quality Check
On 14-02-21 11:54 AM, Lex Trotman wrote: On 22 February 2014 04:50, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Fri, 21 Feb 2014 16:52:51 +0100 Colomban Wendling lists@herbesfolles.org wrote: [...] OK, I didn't think it was OK to assume GCC was the compiler, It isn't, indeed. Although well, to be fair we probably have no idea what happens if it's not GCC-like. Or maybe I even remember there was problems with MSVC? I guess it would be the same result as passing something like `-Wl,--export-dynamic` on platforms that don't support it (ie. compilation/linking failure). Even a GCC-clone like Clang has some different options, for example to limit errors is `-fmax-errors=N` on GCC and `-ferror-limit=N` on Clang (at least last time I tried). So I guess even if a compiler is GCC-like, passing an invalid `-Wfoo` might be bad, if not fatal. MSVC is a totally different story WRT to flags of course :) We disabled MSVC some time ago (see geany-plugins fail to build with msvc). In short, cl recognices template as C keyword :) I thought Matthew fixed that so we could use C++ plugins. Only in the headers, if 'template' is still used in source files it would choke a compiler that thought it was a C keyword. and the CFLAGS / LDFLAGS obtained from pkg-config under win~1 are suitable for gcc, not MSVC. pkg-config on Windows supports an option called `--msvc-syntax` which presumably outputs CL-compatible flags. But that is indeed a problem, presumably because things like gtk binaries have been cross compiled for win, not with msvc. Also is it It shouldn't matter, C has a defined ABI AFAIK. still true that g++ and msvc++ binaries can't be linked? I think just because of C++ not having a defined ABI and compilers choosing to implement name-mangling and such differently. I don't think it matters for Geany though since nothing external would be linked with C++ symbols, even Scintilla's exposed stuff is plain/extern C AFAIK. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] modification of fullscreen behaviour
On 14-02-20 10:54 AM, Colomban Wendling wrote: Hi, Le 19/02/2014 06:23, Flynn Milligan a écrit : So far as I can tell, you're an acceptable person to contact about this matter; if not, I'll try to find a better place to submit it. It's acceptable, but you should rather ask development question on the devel@lists.geany.org mailing list (that I just CC'd), so any developer can see, answer and comment ;) The current fullscreen behaviour, as you know, is to keep the menu bar and tabs visible when fullscreen mode is activated. It seems to me that it would be more logical to hide these elements in fullscreen mode. I'm not well-versed in C, but I'd like to change this. What's the best way to go about doing so? As I think Lex already mentioned on IRC, we already have means to hide some extra elements, they just aren't triggered when entering fullscreen. But anyway, the way to go is to extend ui_utils.c function ui_set_fullscreen() to do any additional job needed. Also, such behavior needs to be configurable -- you find that entering fullscreen should hide other stuff, but not everyone might agree, so it should be a setting. It also needs to be smart enough to record what widgets were visible before entering fullscreen so that when fullscreen is left, it can properly restore the regular widgets. There should also probably be an escape hatch like an item in the editor context menu or somewhere not in the menu/toolbar to exit fullscreen for weird windows managers (maybe windows or odd-ball *nix ones) that don't support the keybinding or it gets re-bound or whatever. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Plugins Quality Check
On 14-02-20 12:07 AM, Lex Trotman wrote: Hi All, On the off chance that we might be converging on a release I did a compile of the plugins with the usual options (-Wall -Wextra -Wno-unused-paratemers). This was on GTK2 since many still don't work for GTK3. The results are not too bad really :) To summarise, other than deprecations which will be discussed below: codenav - 2 unused variables debugger - 1 warning, useless test, probably inconsequential geanygendoc - 2 warnings, extra switch case may be consequential, unused function geanysendmail - 3 const discarded warnings multiterm - unused variable warnings in code generated by the valac, and const discarded warnings Unused functions and variables are probably inconsequential, unless they are the result of a typo in the code meant to use them, they need a quick check and correct. Extra switch case may indicate a typo, needs checking. Discarded const potentially is a problem, it may indicate that something may try to modify literal strings, which may have undefined behaviour. Sometimes library headers use char* when they should have const char*, this is annoying, but it can usually be worked around. But must be checked, including the ones generated by the Vala compiler. No it mustn't :) I won't check or fix warnings in Vala's generated code, at least not as part of the Geany project. If it helps you out, just pretend the generated C code is like GCC's generated ASM code and that you assembled this code with very strong warnings and someone suggested you sift through GCC's generated assembler to verify each warning. I'm not opposed to any patches you provide though, if you'd like to read through the generated code and provide patches upstream and if they require changes in the plugin, apply them. IMO, we should just disable warnings on Vala's generated code altogether and rely only on the Vala warnings. Anything else is a Vala bug and not our problem. I would've done this long ago but I'm not sure how to properly/portably disable warnings for a particular target in Autotools. The details are at http://pastebin.geany.org/76dfx/ Since this is with GTK2 there are no GTK deprecation warnings (except in Vala, which seems to have decided that the whole of GTK2 is deprecated), [snip] The GTK2 Vala binding is deprecated, same as the GTK2 C API/library. There is a compiler flag for Valac to make it disable the deprecation warnings, if that is desirable. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Scribble Font
On 14-01-31 03:04 PM, Steven Blatnick wrote: Is there any way to adjust the Scribble font? I think it should use a monospace font :-/ I believe it's called textview_scribble and is a GtkTextView if you'd like to theme it using gtkrc/gtkcss. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Scribble Font
On 14-01-31 03:47 PM, Steven Blatnick wrote: I think gtkcss only works on GTK3 and Linux Mint Debian Edition is still using GTK 2.24.20 Should I write a little patch to make it use Monospace in the code and submit it? (Is there interest to anyone else in such a patch?) Or is there another way short of editing the code that I'm missing? You can use gtkrc files for gtk2, I think Geany even comes with it's own for some custom themed stuff. http://www.gtk.org/api/2.6/gtk/gtk-Resource-Files.html. I don't know much about it but it seems totally reasonable that you could match the Scribble textview either by gtkbuilder/glade name or class/hierarchy and change its font. If it's not possible, probably the best approach would be to extend what's documented here: http://www.geany.org/manual/current/index.html#defining-own-widget-styles-using-gtkrc-2-0 for the relevant Scribble widget, so you can match it by GtkWidget name in the gtkrc file (see main.c:L282). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Plugin Advice
On 14-01-15 07:02 PM, Peter O'Malley wrote: [snip] 3) In the actual folding code I used sci_get_fold_level (and a couple other scintilla wrappers) which aren't in the plugin API so I gather my plugin may break at some point. There doesn't seem to be a way around this for what I want to do. Is this ok? You can just use the exposed Scintilla API, like: scintilla_send_message(sci, SCI_GETFOLDLEVEL, line, 0); Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] A direction for Geany
On 13-12-15 11:01 PM, Steven Blatnick wrote: I agree on scintilla being better. I don't know if this is because of gtksourceview or not, but loading large files or files with long lines freezes up gedit2/pluma, which uses gtksourceview. I used to prefer gtksourceview, but I think I prefer scintilla more now. My experience is exactly the opposite (not with Gedit though). GSV works incrementally while pumping the GUI loop, Scintilla completely blocks it. I could have just lacked experience, but navigating the code to add background color or select regions didn't seem as easy with gtksourceview. Their iterators, marks, and other anchor/location-types seemed to be unintuitively mixed and would become stale data quickly without even the text changing. My experience is exactly opposite. GSV feels natural in GTK+ since most of its API is directly inherited from the existing GtkTextView widget and the rest of its API is very idiomatic. Scintilla's GTK+ backend, without going into a huge rant, has quite possibly the worst, most foreign API to ever be unleashed on the world. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] small bug in utils_strtod()
On 13-12-01 04:34 PM, Lex Trotman wrote: On 2 December 2013 09:45, Matthew Brush mbr...@codebrainz.ca wrote: On 13-12-01 01:26 PM, Lex Trotman wrote: Hi, **gint** utils_strtod()?? Sheesh. s/b renamed utils_hexcolor() or similar, thats what it does. As for end, the original strtod() and friends used it to extract several whitespace separated strings from the one string by just passing end to the next call, but if we don't use it and its wrong anyways we might as well drop it when we change the name to utils_hexcolor(). Agree the name is bad, and also the colour parsing isn't very robust. I meant to improve it when adding the named_colors support but never got around to it. Attached patch uses GDK colour parsing instead of own-rolled thing which supports more colour specification formats as well as cleans up some related code while remaining compatible with legacy colour notation and GTK2 and GTK3 builds. If nobody objects, I can commit the patch. Untested, but looks ok, except it has changes not directly related to parsing colour like highlighting.c:698, s/b separate commit IMHO. That is using the new/re-written function, just like all the other changes. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] g_spawn_command_line_async result in the message tab
On 13-11-16 11:08 AM, Francesco OpenCode Apruzzese wrote: Hi all, I'm try to create a new Geany plugin with this documentation (http://www.geany.org/manual/reference/) and the examples in this repo (https://github.com/geany/geany-plugins) This is the plugin i'm developing: https://github.com/OpenCode/geany-python-good-code I'm using g_spawn_command_line_async to launch a tool with the current file as parameter. I want know if is possibile to read the command output and show it in the messages. The functions related to this are here: http://www.geany.org/manual/reference/msgwindow_8h.html Also, if you like to write it in Python, GeanyPy[1] allows to make Geany plugins using Python. Cheers, Matthew Brush [1]: http://codebrainz.github.io/geanypy/ ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] spawning rewrite - RFC
On 13-11-16 02:20 PM, Steven Blatnick wrote: I'm not familiar with what this is about? I'm away from my computer to look at the code. Is this a plugin to run/spawn external programs and capture output? If so, you may want to check out my external-tools plugin: https://github.com/sblatnick/geany-plugins/tree/external-tools/external-tools/src It's an on-going effort to improve the situation with process spawning on Win32 in Geany core for stuff like Send Selection To and running build commands and such. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] A direction for Geany
On 13-11-14 10:56 AM, Dimitar Zhekov wrote: On Tue, 12 Nov 2013 17:47:26 -0800 Matthew Brush mbr...@codebrainz.ca wrote: On 13-11-12 10:43 AM, Dimitar Zhekov wrote: On Mon, 11 Nov 2013 01:31:35 -0800 Matthew Brush mbr...@codebrainz.ca wrote: 1. An architecture that allows multi-threading to be used for non-GUI tasks. Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since [...] and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff). We don't even have a proper saving with all GIO/GFile/whatever levels, because some people haven't completed even one level properly. I didn't understand what this means? We have several options to save a file in different ways, because all GLib stuff is either unreliable or has side effenct (owner and permissions change). So fix GLib instead of adding a bunch of different workarounds to Geany. Geany's code isn't the place to work around bugs in the *open source*, supposedly cross-platform toolkit we use, it completely defeats the purpose of using such a library in the first place. If we can fix it Geany, we can just as easily contribute the fixes to GLib instead. If the fixes are too hackish or not good enough to be accepted in GLib, why would we want them in Geany's code? Slightly off-topic but Vala makes the async/GIO file stuff insanely easy and short to write as it has support for it built right into the language syntax. GLib-based, right? Well, at least we'll have only one (GIO) set of problems to worry about. Yes, and see above. (works fine for me though, YMMV) 2. Language specific assistance, such as indentation, or dynamic error marking and intelligent autocompletes. [...] A way for plugins to handle certain filetypes so that plugins can be loaded/unloaded as a filetype is used in a document and unload when no documents currently use it or something. Nice idea, but why? It's not like they eat a lot of resources, and constantly (un)loading plugins has it's cost too. So they don't have to connect to every single document and notebook signal and only activate themselves when a specific filetype is opened/closed/saved/etc and de-activate themsleves when the tab switches and stuff. Don't worry, gtk+3 will waste more time than all the current plugins together. What's more it would/could provide some form of conflict resolution over which plugins are handling which filetypes and stuff. This is especially useful since we're talking about language support plugins, not run-of-the-mill existing Geany plugins which just (can) stomp all over each other and Geany anyway :) We'll be lucky if these _future_ plugins provide so much functionality as to have conflicts over specific file types. They definitively won't with all this completely counter-productive hating on the library we use, holding back any type of useful progress so you can vent your frustrations about something that is completely outside of our control. The last time I checked, Geany + Scintilla with GTK+3 flickered on my machine. By the time they fix this, GTK+3 may drop or deprecate so many non-GNOME-3 features that I'll simply switch to Qt-based GUI. It works fine here with Scintilla, FWIW. You forgot the obligatory YMMV. Should I make a video clip and post it? :) I don't doubt it, I just said it works for me. I know of at least a few other users and devs also using it without such problems. GTK3 overall definitively feels a little slower and some of the new touch friendly dialogs and stuff are kind of annoying, but I mean barring completely switching toolkits (unlikely) or writing our own cross-platform wrapper toolkit (infeasible), it's what we're stuck with for the future, so why fight it kicking and screaming? Because it's slower and annoying? Because we don't know what funny thing the gtk+ devs will do tommorow? The more I think about it, the more a transision to KDE seems a good idea. OK, but barring a switch to Qt, it's not at all useful gripe about how much it sucks and cling to it in desperation, hoping some magical free software gnome will come along and revert years worth of commits, made on a corporation's dime, by people who seem to like the changes. Lots of users actually *want* Geany to move to Gtk3, for various reasons such as using the same theme as the rest of their desktop (see what Gtk version the top 3 Linux distros are using) or to get better/any Wayland or support, or for various other reasons. So they shouldn't get proper support for their environment because you hate change, refuse to acknowledge the inevitable and want to stick to a deprecated version of our toolkit for a couple more years until it's completely dead and gone and we are left with a big crusty hairball of obsolete, unmaintainable source with more #ifdef's than actual lines of code? 5. Drop Scintilla
Re: [Geany-Devel] Let's use Vala
On 13-11-13 08:21 AM, Steven Blatnick wrote: Wow, you found the article :-) From what I've seen of geany, the code looks much better than some code I've seen. It didn't take as long to familiarize myself with the basic structure since the code files are well named and the directory structure is far from deep ;-) One of the reasons I felt so comfortable writing plugins for it is how much easier the code was to read. At least you don't have perl code mixed with java, etc ;-) To be clear, I don't think Geany's code is actually bad on the whole, it just needs to be ruthlessly cleaned up/re-factored in some places. It's overall layout is good, the individual units/functions are thoughtfully/carefully coded inside, etc. I just think that after many years of no one being able to make major refactorings/changes to the code (90% due to plugin API breakage, I suspect), there's a lot of weird globals and one-off-structures mixed into the code, used to patch functionality onto stuff (for ex. if you change a function to add a parameter, you break the plugin API and/or have to update a bunch of other code, so just add a global shared between two functions), or code that belongs in one file is in another file, and stuff like this. In addition, there's a lot of lost opportunities to use things which are provided by our toolkit already, that we either don't use because we didn't originally use (GObjects), or that we roll ourselves still or just avoid alltogether because these things weren't available 5 years ago when the toolkit version we need to support was current version. I'm a bit wishy-washy on my positions in these threads. Part of me is still healing from the Gnome disaster, and part of me likes moving forward. I hope at least it's good food for thought. The difference here is everyone agrees that Geany's UI is awesome and no ones really talking about significant changes on the face, just in the code. It would be more akin to the GTK+2 to 3 transition happening without GNOME-shell in the picture (ie. if GNOME2 just got upgraded to GTK3). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's use Vala
On 13-11-11 11:48 PM, Steven Blatnick wrote: That sounds pretty good. Is that a lot like python and gtk? I get the impression its better since I don't think python compiles to equivolent c code? If by better you mean faster, leaner, and more compatible with existing C code, yep. It literally outputs (fairly) readable GObject/GTK-style C code just like you'd write by hand. With Python not only is it not easily callable from C code, but it's interpreted, and I think the PyGObject/Introspection stuff makes it go through another layer of foreign function interface stuff (libffi I guess) to actually call the GObject C code rather than directly through a CPython extension (could be mistaken on this). You might like an intro like this video: http://www.youtube.com/watch?feature=player_detailpagev=6QrGmA_RR4E#t=2214 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's use Vala
On 13-11-12 07:50 AM, Frank Lanitz wrote: I cannot add much to the vala yes/no question, as the only part of ala I've seen by know are Matthews's plugin in g-p. Two or maybe three things are important to me, in case of: - Geany needs to keep its small memory footprint Yes, I don't think there'd be an appreciable[1] extra amount of memory, it uses all existing libraries we have loaded in memory anyway, and Vala has special annotations and stuff to tailor the generated C code for when you need to optimize for special cases. - Created code needs to run on all plattforms Geany currently is running on -- At least I know of *BSD, Solaris,, MacOS X, Windows, Linux and we need to stay compatible with curent stable versions of SLES, RHEL etc. which means at least RHEL 5.x and SLES 10. Also at least for the next year we need to keep on running on Debian Squeeze also. Yep, it's just GObject code, so anywhere GTK+/GObject runs, the code compiled out of Vala should run just the same. - There needs to be a final, let's call it C-only-release (well, having 1.24 in some would be a good idea anyway) +1. - g-p should keep on running: We got a lot of badly maintained, but good used plugins. If a major rewrite is needed for them, I doubt it will be done for a huge number of. Not strictly related to Vala but more to the other thread, I doubt this is feasible/possible with upsetting the plugin API to some degree, given the scope of the changes being discussed there[2]. On the bright side, with the possibility of exposing the plugin API to higher-level, more user-friendly languages (via generatable bindings and such) we could see a boon of nice new plugins, written in much more maintainable languages, by a more diverse class of developers, and much less ability to bring Geany down to a crashing halt with one little pointer mishap :) Cheers, Matthew Brush [1]: Of course this is subjective but even just something like using GTK+3 build probably dwarves anything introduced by some additional GObjects generated out of Vala. [2]: Since so much of Geany's guts/implementation is exposed directly, it'd most likely be impossible to make any non-trivial changes/re-factorings without disturbing the plugin API. And even if we aimed to keep the plugin API mostly stable during the changes, we'd probably end up with maintenance nightmare of all kinds of old backwards compatibility wrappers and such. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Gtk2 vs Gtk3 (was. Re: A direction for Geany)
On 13-11-12 03:48 PM, Lex Trotman wrote: Why to switch to other toolkits?! I not understand what don't good in GTK+. And also - why to keep GTK+ 2? GTK+ 3 avilable in all distro, also in older distro, it also work in Windows and also in Mac. this because GTK+ 3 released before almost three years. Because many distros are more than 3 years old and still supported. Geany has users (and developers) in commercial and academic environments which will often be constrained to older (but still supported) versions of Red Hat, Scientific Linux, Suse etc. Its fine for hobbyists to want to play with the latest, we only have one PC to change over, but institutions often have hundreds or thousands and have all sorts of specific software to ensure still works when they upgrade. That's a fair[1] argument *if* those old distros aren't shipping GTK3 binaries/libraries (I can't say whether they are or not), otherwise it's a bogus point because then we're only talking about a very very small number of users who (all of these must apply, not just some): - Use an old, nearly end-of-life enterprise distro - Don't have admin rights or clout enough to get admins to install newer versions of stuff - Need to compile Geany from source, from the absolutely bleeding edge head of Git, rather than using the version they're supposed to as available from their distro and supported by their IT personnel - Refuse to take a few hours to compile newer GTK+ stack in $HOME - Can't or don't want to run a virtual machine, bootstick or live distro to get access to more modern software Cheers, Matthew Brush [1]: Well not completely fair, because they're making Geany development harder and holding back progress/improvements for the sake of having to use latest Geany releases instead of older, stable and supported versions, and even then still need to be able compile from source code and permissions to install development packages and such which I imagine are unlikely to be pre-installed for them by their sysadmins. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Gtk2 vs Gtk3 (was. Re: A direction for Geany)
On 13-11-12 04:23 PM, Lex Trotman wrote: On 13 November 2013 10:53, Yosef Or Boczko yosef...@gmail.com wrote: I not understand, you mean have some old version of some distro isn't support GTK+ 3 and them always with older version of all package - so why Geany need to be the last in them distro? Several reasons: 1. we don't have the resources to backport bug fixes to old versions, the only bug fix versions are the latest release of Geany. Their sysadmins and distro vendors are supposed to take care of that aren't they? And anyway, most users wouldn't even be able to get a newer Geany installed from source on such a restricted system. 2. The users on old distros have the same use-cases as those on new distros, so they need the new features as much as anyone else. Restricting the features available disenfranchises that group of users. Older versions of Geany are still really good, and supported by their sysadmins and distro vendors, and it's not like major huge changes have happened since say 0.18 or something. What's more, it's not like it's actually Geany disenfranchising them, it's almost every single FOSS program that exists and even more so their IT people/sysadmins. 3. IIUC some of the Geany devs are in that situation, they clearly will not contribute to changes that they can't use. I think Pavel said he's in this situation at work, but it's not like it's insurmountable, just more of a pain in the butt. Anyone else? Geany need to go forward, and older distro will keep the old version of Geany same them keep the old version of GTK+ 2 and not support GTK+ 3 yet. Geany 1.24 and also Geany 0.21 it realy good software, but we can't to bog becausw have some older distor. Going forward is adding features that are useful to users, such as those suggestions being gathered in the direction for Geany thread. It's painful writing new, pre-deprecated code against dead dependency version and not being able to use newer or improved APIs, though. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] A direction for Geany
On 13-11-11 02:42 AM, Thomas Martitz wrote: Am 11.11.2013 10:31, schrieb Matthew Brush: [snip] * GtkSourceView completely integrates into our GUI toolkit, using native (not custom drawn like Scintilla) widgets inside and interacts properly with stuff like scrolling, focus, DnD, key-bindings, etc. With ScintillaGTK it also interacts properly, doesn't it? It impements GtkWidget and can act as such. Not really, I mean it is technically a subclass of GtkWidget, but it draws its own text instead of using GtkTextView, it uses its own scrollbars instead of using GtkScrollable/GtkScrolledWindow, it has problems with focus (see related functions in Geany's source), it hijacks keybindings completely outside of GTK+, it provides only a single crazy signal for every possible thing, it hasn't any GTK+ properties or style properties, it hasn't any methods/functions/API but a single weird mandatory function thing (scintilla_send_message) that requires to constantly be doing casts on its parameters since they try to accept every type through long/ulong, it doesn't use any G* types for anything (ex. enums, function parameters, colours, images, etc) and so on. [snip] All of these points read like whine. Some of them also apply to GtkSourceView (GSV) and you haven't shown how GSV improves things. I can read that you don't like Scintilla but how is GSV better and what do we gain? Perhaps you could summarize the nice things about GSV? Note that I have done nothing with it and therefore no idea how it works or what APIs it provides. But I also do not know why you would chose it over Scintilla or even convert an existing Scintilla-based project to it. It's probably easier to list the things that are worse in GSV since there's only one point I can think of where Scintilla beats it hands-down: * No code folding (promised since forever, not sure when it ever comes). Anyway, it will be added to any list of big potential changes and we can discuss on the wiki or wherever this might eventually end up if it goes anywhere, I guess this isn't really the thread to be getting as detailed as I did or continue such detailed discussions (ping me on IRC if you want). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's use Vala
On 13-11-11 05:37 AM, Thomas Martitz wrote: Am 10.11.2013 21:04, schrieb Matthew Brush: Maybe it's something specific to that Gist, so I re-pasted it in a new one: https://gist.github.com/codebrainz/7403171 Impressive. Unfortunately only a tiny fraction of Geany's code can be vala'fied like this, right? So trivially, yes. There's a few other GObjects that would be nearly as easy (but frankly are some Geany's nicest code already :), but the rest of the code would actually require writing real logic and stuff into Vala. Although what I was driving at in general wasn't just porting Geany's code 1:1 into Vala but re-factoring/re-writing/re-organizing, and using Vala to do it (same as I've talked about before WRT GObject on the list/IRC), so it's not really super important how much code can be directly 1:1 ported or vala-fied like that, I just wanted to give a little taste of the LOC/complexity reductions we could expect with Vala :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's use Vala
On 13-11-10 02:00 AM, Pavel Roschin wrote: Maybe, rewriting some parts of boating complicated leaky code (e.g. build.c:) isn't bad idea and suitable in this situation. You don't need much bindings for editor and Vala shouldn't be a pain. But AFAIK Geany don't use GObject and writing on Vala may cause deep refactoring that will take your time. Many things in Geany could be rewritten, simplified and improved and it's definitely going to be refactoring while using Vala. To improve maintainability pure C code could be pre-generated before release for faster and easier build without vala. Yep, this is the default for the Autotools built-in support as well, so no extra work to do it. From the other side you could scare good C programmers... True, but I suspect good C programmers will have little trouble with a simple language like Vala. About RHEL: defenitely can say that Vala 0.20 works. And some things could be easily compiled. Cool, good to know. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's use Vala
On 13-11-10 07:40 AM, Colomban Wendling wrote: Le 10/11/2013 05:44, Matthew Brush a écrit : 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. [...] Well… it's a little complicated. I agree that features from a higher-level language could help, it being C++, Vala or something. It's definitely shorter to write some things in those languages than in C, and memory management is definitely easier. I see one advantage in Vala over C++: that it actually is C ([1]), just like our current code. I agree that Vala would help if we want to port the code to something more OOP-style -- since obviously the language supports it by itself. I agree it's probably a good idea. But the port won't happen magically. Agreed, but one of the reasons I created this thread is to get agreement that we *can* use Vala and then when we do any refactoring, it makes it that much easier. I'm sure you already know I'm bringing this topic up because I'm willing to do a lot of the work :) The problem I see is that using C from Vala requires a more or less manual interfacing, even if quite easy to write. This adds actual complexity. We could try by porting leaf modules to Vala and see (maybe utils?) -- since calling Vala API from C is native --, but it's probably not the modules that would benefit the most from the language. This was my same thought. There are lots of modules in Geany that could benefit from re-factorings, but even starting with some of the low hanging fruit like utils, uiutils, any of the existing GObjects, including geanyobject.c which as a demo, I converted to Vala reducing the lines of code count from around 400+ to around 40: Before: https://gist.github.com/codebrainz/7274867 After: https://gist.github.com/codebrainz/7274865 And the C code that uses it needn't even change one bit in this case. To sum up, my point is that having more than one language might add too much of a glue layer for it not to weight down the idea. It really depends how it's done. The type of refactorings I'm envisioning (and obviously volunteering to do) wouldn't require much glue as they would clean up individual modules(files) leaving the outside world more or less the same (aside from tweaking the existing C code for slightly different calling conventions/parameters or whatever). Sorry Matthew, but it's kind of an I like Vala but I don't know :) Basically what I'm asking is; if someone volunteered to cleanup a bunch of the code, make it automatically bindable for plugins, much easier to maintain/read, and did it without adding a bunch of glue (which you actually already wrote a bunch of :), would they be wasting their time and have it blocked just because it's not C, or can we get a basic agreement, in principle, that in this case, we would be open to allowing some Vala in new/re-factored code? * 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). Not to mention bugfixes in bindings, that are much less frequent today but weren't rare a dozen months ago or something. Indeed, although if we did hit some bugs in the bindings (as you said less and less likely as Vala progresses), it's quite easy to fix them and contribute the patch upstream like we do with CTags and Scintilla. * 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). I think Vala supports targeting a particular GLib version for what it itself generates (vs. what API you explicitly use in your own code), so it may not be an issue. And I think e.g. GTK is just a lib to Vala's eyes, so you just have to use the part of it that match your preferred version, just like we already do. That's good to know, should be taken off the cons list and moved to the pros list then :) And yes GTK is just another lib, any of the stuff in the .vapi binding that isn't used from Vala won't be put into the generated C code, so you're right about that too. [1] so allows to keep full C compatibility without only using an uninteresting subset of the language, unlike the C++ discussion suggested, which was basically use C++ but nothing in headers that's not C compatible, so excluding classes, and much of the interesting stuff in C++. In addition, you literally *can't* mix Vala and C code in the same file, so there's no weirdness about exceptions, GTypes vs C++/stdlib types, and confusion about which language is being used in a given function. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's use Vala
On 13-11-10 11:45 AM, Thomas Martitz wrote: Am 10.11.2013 20:27, schrieb Matthew Brush: On 13-11-10 07:40 AM, Colomban Wendling wrote: Le 10/11/2013 05:44, Matthew Brush a écrit : 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. [...] Well… it's a little complicated. I agree that features from a higher-level language could help, it being C++, Vala or something. It's definitely shorter to write some things in those languages than in C, and memory management is definitely easier. I see one advantage in Vala over C++: that it actually is C ([1]), just like our current code. I agree that Vala would help if we want to port the code to something more OOP-style -- since obviously the language supports it by itself. I agree it's probably a good idea. But the port won't happen magically. Agreed, but one of the reasons I created this thread is to get agreement that we *can* use Vala and then when we do any refactoring, it makes it that much easier. I'm sure you already know I'm bringing this topic up because I'm willing to do a lot of the work :) The problem I see is that using C from Vala requires a more or less manual interfacing, even if quite easy to write. This adds actual complexity. We could try by porting leaf modules to Vala and see (maybe utils?) -- since calling Vala API from C is native --, but it's probably not the modules that would benefit the most from the language. This was my same thought. There are lots of modules in Geany that could benefit from re-factorings, but even starting with some of the low hanging fruit like utils, uiutils, any of the existing GObjects, including geanyobject.c which as a demo, I converted to Vala reducing the lines of code count from around 400+ to around 40: Before: https://gist.github.com/codebrainz/7274867 After: https://gist.github.com/codebrainz/7274865 Error 500 :( Yeah, same here, I was hoping it would be back up by the time people visited or wasn't down for them :) I'm sure it'll come back online soon. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's use Vala
On 13-11-10 01:44 AM, Lex Trotman wrote: [...] Not what it says here https://wiki.gnome.org/Vala/Manual/Errors and anything that can throw through C code can cause leaks since the C code doesn't clean up. Same as C++, you can't use exceptions mixed with C code. Trust me, I generated lots of C code from Vala, when you throw an exception, in the CCode it throws on a GError out/result argument as you'd expect in C Code. Yes, I understand how the throws are implemented in vala, but as I said, the existing C code isn't designed to handle that. Much of the existing code uses GError-style errors, and any existing C code that was made to to call Vala generated code would do the same, no biggie. It's not like we'd throw an exception from a re-written function without updating the caller code, that wouldn't even work, the compiler would have a fit about missing (GError) parameter (unlike with C++ exceptions). Maybe I misunderstand your point still? [...] Yeah, but its a binary which includes Glib and GTK IIUC, so we have to match those. I agree its not much worse than we have now but its not very comforting that the last binaries are 2011 vala version 0.12 when even LTS Linux distros have 0.18. We could compile own if we need to embeded release, otherwise using something like https://wiki.gnome.org/Vala/Win32CrossBuildSample or billions of other possibilities for creating cross-platform code as well as we do now. Sure we *can* do anything, but somebody has to do it and maintain it. I'm volunteering. We keep saying somebody has to do it, and I'm proposing a way that seems the most sane/best and least time-wasting to do it, and being the somebody in this case (although I'm hardly a build system expert). [...] Nope, I propose *new* Geany release will only work on *new* dependencies, which are release in *new* distros, which are using *non-deprecated* APIs. So you want the extra work of backporting bugfixes, or just forget about older platforms? I guess (according to Columban's message) this is a non-issue, we can target same versions of stuff as before, and even RHEL supports recent Valac, so it should be same old (in theory at least). [...] Said the fellow who have never programmed a line of Vala code in his life and who likes a language like C++ which is basically the equivalent to Vala for C/Gobject based applictaions. Ad hominem attacks have no place in this discussion list. I didn't mean as an attack, just pointing out the irony that of all people, surprisingly, you seem to be against it the most, being someone who is a strong proponent of a quite similar language, good programming paradigms, and good language design in general :) Is it fair to consider Lex to be a +/-1 for the sake of keeping discussions on-track? I would have thought that no above was obvious. Is that no because you want to focus on re-design and not getting an in principle agreement on a good language to use? Or you honestly don't think Vala is a good fit at all for new/re-written parts of Geany code? To be clear, tinkering with what language is used to tack more bandages on to the current Geany design is a waste of time. Choosing a better language to implement a better design might be worthwhile. That's the idea; choose a better language, agree it can be used, and then start working on the re-factoring/re-design stuff using it. If we get bogged down at this point with deep design discussions and stuff, instead of just agreeing on a language that volunteers (ex. me) are happy/willing[1] to use to roll-out said re-factorings/re-designs, we'll not move forward at all[2]. P.S. Sorry if I was snarky/sarcastic in the last message, it's only because I know roughly your sentiments on the subject from our previous discussions, and could insert any topic for Vala and you'd find some points to disagree about (see most/all RFCs in ML archives) :) I just get frustrated because you're generally against every idea anyone (especially me) has, and it's hard to tell if you're being genuine or just disagreeing for the sake of disagreeing, or you think I'm too stupid to understand what I'm talking about or something. Cheers, Matthew Brush [1]: I'd also be willing to do in plain GObject/C but it'd be a lot more boring/long/bug-prone and would result in the exact same code as Valac would generate (or likely worse), and then you'd be pointing out about how it's too much churn, boilerplate, or how G*/C sucks, etc. [2]: Yes, the design part is fairly independent of the language part, of course we could do it ASM if we wanted, but certain tools make things a lot easier to express/organize, especially when you can type 20 lines of clean readable Vala code instead of 200 lines of organized but boring GObject code, or 150 lines of unstructured, bug/leak-prone, hard-to-follow plain C code[3]. [3]: And yes, it is possible to write structured, non-buggy
Re: [Geany-Devel] Let's use Vala
On 13-11-10 03:02 PM, Lex Trotman wrote: [...] Yes, I understand how the throws are implemented in vala, but as I said, the existing C code isn't designed to handle that. Much of the existing code uses GError-style errors, and any existing C code that was made to to call Vala generated code would do the same, no biggie. It's not like we'd throw an exception from a re-written function without updating the caller code, that wouldn't even work, the compiler would have a fit about missing (GError) parameter (unlike with C++ exceptions). Maybe I misunderstand your point still? No, you said it exactly right, the concern is we can't use Vala exceptions without changing the existing C code, which somewhat negates the benefits of Vala. True, but it's not exactly difficult to update/add an argument on a C function, I think the compiler will kindly (or rudely :) even point out all the places that were missed. [...] Or you honestly don't think Vala is a good fit at all for new/re-written parts of Geany code? Not yet convinced, and TBH not really convinced about a progressive change to C++ either (my original mention that sparked the thread was meant to be a sarcastic throwaway comment :). I understand your desire to keep the discussion high level, but the devil is in the annoying little details for languages, and their implementations, so you can't make a decision without examining those details. I agree about C++, however much of a better language it is, it's not a great fit in Geany as it stands (although could probably be workable using GTKmm). IMO, Vala is the simplest way to get the most bang with least amount of friction with existing code/framework and all of the output C code from Vala is quite readable and for the most part maps 1:1 to what we (at least me) would've wrote anyway. To be clear, tinkering with what language is used to tack more bandages on to the current Geany design is a waste of time. Choosing a better language to implement a better design might be worthwhile. That's the idea; choose a better language, agree it can be used, and then start working on the re-factoring/re-design stuff using it. If we get bogged down at this point with deep design discussions and stuff, instead of just agreeing on a language that volunteers (ex. me) are happy/willing[1] to use to roll-out said re-factorings/re-designs, we'll not move forward at all[2]. As I said, choosing the language first is putting the cart before the horse. As I said in reply to Colomban, I'll start a different thread about the way we want to move, lets see where that goes. If you're going to renovate a house, it helps to know whether you're going to use lumber or concrete before you start designing the structure :) I don't think it's putting the cart before the horse, but I agree the two things aren't directly related, either one could happen in either order, just that if we chose to use Vala before any major changes/redesigning, we'd save a lots of pain in the process (to use above metaphor, we could save driving nails into concrete, or pouring lumber into concrete molds :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [PATCH geany 2/2] gtkcompat: Add gtk_widget_get_allocation
On 13-11-05 07:21 AM, Quentin Glidic wrote:
From: Quentin Glidic sardemff7+...@sardemff7.net
Signed-off-by: Quentin Glidic sardemff7+...@sardemff7.net
---
src/gtkcompat.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gtkcompat.h b/src/gtkcompat.h
index 9cfc50b..325fd93 100644
--- a/src/gtkcompat.h
+++ b/src/gtkcompat.h
@@ -23,6 +23,7 @@
#ifndef GTK_COMPAT_H
#define GTK_COMPAT_H
+#include string.h
#include gtk/gtk.h
#if GTK_CHECK_VERSION(3, 0, 0)
# include gdk/gdkkeysyms-compat.h
@@ -94,6 +95,8 @@ G_BEGIN_DECLS
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))
+# define gtk_widget_get_allocation(widget, alloc) \
- memcpy((alloc), (GTK_WIDGET(widget)-allocation));
+ do { \
+ GtkAllocation *al = (alloc); \
+ GtkWidget *wid = (widget); \
+ g_warn_if_fail(al GTK_IS_WIDGET(wid)); \
+ memcpy(al, (GTK_WIDGET(wid)-allocation), \
+ sizeof(GTK_WIDGET(wid)-allocation)); \
+ } while (FALSE)
#endif
#if ! GTK_CHECK_VERSION(2, 20, 0)
# define gtk_widget_get_mapped(widget)GTK_WIDGET_MAPPED(widget)
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Segmentation fault when auto-close plug-in is enable [patch]
On 13-10-24 12:23 AM, Thomas Martitz wrote: Am 24.10.2013 04:09, schrieb Matthew Brush: On 13-10-23 11:36 AM, Thomas Martitz wrote: [snip] Regarding that pattern we discussed previously and used in this AutoClose code for attaching data to a document, I'd be interested whether you or anyone thinks this branch (last/top two commits) would be useful to plugins: https://github.com/codebrainz/geany/commits/document-datalist IMO it'd be better to make GeanyDocument an actual GObject and get the data lists for free, but at least this is sort of a step in the same direction. I agree with that. I also agree with your general idea of per-document data lists. However, I'm not seeing the point of the new code you added because each doc has already a ScintillaObject, which is a GObject. I would suggest that the document_set_data() and friends wrap around g_object_set_data(doc-editor-sci). This way things are prepared for when GeanyDocument becomes a GObject but without the need to duplicate the glib interface in Geany. Unless I missed anything that requires the datalist in GeanyDocument directly? There isn't (or rather shouldn't be) a 1:1 correspondence between a GeanyDocument and the view that's showing it. Consider say a split view where the same document is shown in multiple views, or in two windows or whatever. But you're right, with the way the code is currently, you could just wrap the Scintilla data list, it's just not very future-proof (at least this was my thinking). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] On document pointer recycling
On 13-10-24 02:51 PM, Lex Trotman wrote: On 25 October 2013 04:04, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Thu, 24 Oct 2013 19:22:34 +1100 Lex Trotman ele...@gmail.com wrote: Unfortunately there is an accessor document_index() in the plugin interface that uses the index into the array. Switching to a list means that there needs to be a change everywhere in Geany and the plugins that the array index is used instead of a pointer. I don't see anywhere where the index is used inside Geany but I may have missed somewhere. I don't know how often its used by plugins. But again its use could be deprecated and a temporary map (eg g_tree) from an int to the pointer could be used until plugins are modified. From what I see, document_index() is used in the plugins: - inside foreach_document(i), which makes zero sense - in a similar loop in codenav, where the number of documents is copied in a local variable, without an obvious reason, and there is no is_valid check - in geanypy, to implement a Python document_index() function. Thanks. That being said, just how is a list better than a GPtrArray? True, its the fact that the index is held constant because it might be stored and re-used that stops the array from being shrunk. Getting rid of the use of indexes is the necessary pre-condition for shrinking the array, or using a list or whatever. We could use GHashTable as a Set to contain the documents internally afterwards. It doesn't make much sense to have a particular document instantiated more than once anyway and the only order we care about for documents here is maybe the order/time they were opened, which is better solved with a open timestamp or something, IMO. My two cents Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] On document pointer recycling
On 13-10-24 08:34 PM, Lex Trotman wrote: [...] We could use GHashTable as a Set to contain the documents internally afterwards. It doesn't make much sense to have a particular document instantiated more than once anyway and the only order we care about for documents here is maybe the order/time they were opened, which is better solved with a open timestamp or something, IMO. The current index does not depend on opening order since it recycles the document structs, so there can be no dependency on the current order that makes sense. I don't follow. I didn't mean to imply the current way cares about the index order, I'm just saying since we don't care, a good data structure for that is a set, which in GLib is done with GHashTable. What would you use as the key to the hash/set, and why? A simple list or array is all thats needed to hold pointers to open documents and iterate them. I'd use it, as mentioned, as a set data structure (unique unordered collection, like std::unordered_set in C++ or set() in Python) where the key is the document and value is the document (GHashTable has special case for use as a set like this to avoid extra memory allocation IIRC). It's definitively not complicated and the GHashTable API is quite nice, IMO. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Segmentation fault when auto-close plug-in is enable [patch]
On 13-10-23 05:29 AM, n@sk0 wrote:
Before read : Keep in mind that i am *not* C/C++ native developer, and
all message below can be just rant.
After little testing and debugging, i found that :
In on_editor_notify() function, user_data is not a valid pointer :
on_editor_notify(GObject *obj, gint scn, SCNotification *nt, gpointer
user_data)
{
AutocloseUserData *data = user_data;
...
}
After I playing for a while with this and reading demoplugin.c source, i
found that in the autoclose.c, PluginCallback[] (line:829) is missing
the definition for editor-notify event,so i added it, recompile plugin
and now all seems to work correctly.
It's connected on line 812 inside a callback for when the document is
activated. There's a few problems with this; the data allocated on L810
is going to leak, once for each time a document is activated (has tab
switched to). The other thing is the plugin_signal_connect() is going to
stack up signal handlers, so if you activated a document,
on_editor_notify is going to get called on every single scintilla
notification (keypress, cursor blink, etc.), for every number of times
that document was activated.
The final problem is that, as Lex mentioned, it's not checking
`DOC_VALID()` (or doc-is_valid) but just that data-doc != NULL, so if
any document that was ever activated is closed, this is going to explode
when the document pointer is dereferenced (for reasons I never
understood, Geany recycles documents, so it's entirely possible to
have a document pointer that is neither NULL nor valid).
Cheers,
Matthew Brush
P.S.: I add the patch file as attachment to this mail, becouse for now i
do not have any expiriance in commiting patches on GitHub, but tonight i
will fix this big mistake :)
On 23/10/13 13:00, Lex Trotman wrote:
Looking at the line that failed, first guess would be failure to check
doc is valid before using it.
Cheers
Lex
On 23 October 2013 20:20, n@sk0 arrted...@gmail.com
mailto:arrted...@gmail.com wrote:
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)
___
Devel mailing list
Devel@lists.geany.org mailto:Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Segmentation fault when auto-close plug-in is enable [patch]
On 13-10-23 09:13 PM, Lex Trotman wrote: [...] I said it specifically to avoid getting into deep design discussions or code reviews, I just want a general +1 or -1 whether anyone thinks the general concept is useful and whether it's worth looking at implementing something similar. If not one else really cares, it's not worth getting into details about. Agree that if nobody wants it then going further is not worthwhile, but the world of software design is not black and white. A software design suggestion on a mailing list cannot be summarised by a Farcebook like/dislike count. Suggestions of different interfaces or approaches can change a don't see the point into an aha!, I could use that. Stymieing discussion is not going to get to that point. I'm not stymieing anything, I'm trying to ask some people who are using this exact pattern whether they (or anyone else using it) has any interest in this general concept, while trying to avoid getting into implementation details or deep design discussions. For that, a new thread should be started. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Segmentation fault when auto-close plug-in is enable [patch]
On 13-10-23 08:39 PM, Lex Trotman wrote: On 24 October 2013 13:09, Matthew Brush mbr...@codebrainz.ca wrote: On 13-10-23 11:36 AM, Thomas Martitz wrote: [snip] Regarding that pattern we discussed previously and used in this AutoClose code for attaching data to a document, I'd be interested whether you or anyone thinks this branch (last/top two commits) would be useful to plugins: https://github.com/codebrainz/**geany/commits/document-**datalisthttps://github.com/codebrainz/geany/commits/document-datalist IIUC several plugins already use various methods of storing data for different documents and other Geany data structures. Having a common way of doing that which cleans up when the Geany struct is destroyed is a good idea. But it seems a pity to have to duplicate the glib interface for each structure that offers the facility, can we just return the GData and let the plugins use the normal g_datalist functions? Heh, I forgot to respond to this part. In my experience the other structures are often used in terms of the documents, or the Scintilla which already has this because it's a GObject or the UI widgets, which are also GObjects. On the other hand, we could just make all the important structures GObjects and get the data lists for free, and all the other goodness that comes with GObjects, but I digress. IMO it'd be better to make GeanyDocument an actual GObject and get the data lists for free, but at least this is sort of a step in the same direction. [snip] 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. We could just use the usual idiom (in G*) and use objects that have destruction signals and reference counting and such stuff that is useful for this type of scenario. IMO it'd be more useful to just treat GeanyDocuments like other stuff, and maybe having an _is_open() or _is_closed() function or something to see if the document you have a reference on is still open (if you didn't want to connect to its open/close signals it could emit). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Ping on Bug #943 - windows build command
On 13-10-16 12:04 PM, Dimitar Zhekov wrote: [snip] Actually, I finished most of it, what remains is mainly blocking Geany while the new async tools execution is running. Sync spawning is not good, because I'm using the Geany message loop for async I/O (somewhat similar to g_main_context_add_poll), not real Win32 events and threads as GLib does. Locking the file, as Matthew suggested, will not be sufficient: one can still close it, reload it, and of course change the selection (SCI docs assume close/reload are be blocked for background saving). Yeah, in a program like Geany where it doesn't use Actions to make it easy to control the multiple widgets that represent the same action, it's certainly less trivial. That's why I said Assuming re-writing more of the code isn't actually a bad thing... :) For example, if Geany was made to use actions, you could disable closing and reloading as simple as two calls like: gtk_action_set_sensitive(actionClose, false); gtk_action_set_sensitive(actionReload, false); or some document-specific variation of that. In the case of my little editor I was writing, I had the Qt actions and also the translucent overlay (mentioned but not shown) which prevented the user from interacting with the Scintilla view while locked. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Interested making a patch to add QML support
On 13-10-16 12:53 PM, Tory Gaurnier wrote: Just found a bug where when you have a JS function like 'function myFunct()' it was only displaying 'function' in the symbol list, that's fixed now, so it'll show 'myFunct' as it should. Not sure if anyone is even trying out my QML support yet, but figured I'd update anyone who cares ;) If anyone does try it out I'd like some feedback, thanks. You might want to poke the users list to see if any other people are interested in testing too. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Ping on Bug #943 - windows build command
On 13-10-15 10:05 AM, Dimitar Zhekov wrote: On Tue, 15 Oct 2013 11:29:17 +1100 Lex Trotman ele...@gmail.com wrote: [snip] Basically the whole spawning thing needs to be looked at critically, especially those uses that do i/o to the child process. A working version of each permutation sync/async, reads/writes/both needs to be put in utils and all of Geany should then use that implementation and the callbacks use known good idioms. Blocking the GTK+ message loop (aka Geany) to avoid document changes and using blocking pipe I/O are two different things, and we don't need the later AFAIK. A good blocking without rewriting the current code is by displaying a small modal dialog Running FOO... with a Cancel button. The keyboard and mouse events are redirected to it, keeping the documents fair, and there's a way to stop a slow process which intentionally blocks Geany. Assuming re-writing more of the code isn't actually a bad thing, a good way for Scintilla is the way recommended in the docs[1] for background saving/loading, and I think you said Scope does it too, is to just make the affected document(s) read-only while the task executes. I did something quite similar in an editor I was working on a while I ago and still have a video on my site[1] that shows a possible UI for something like this. The actual program also dimmed the document with a semi-transparent black overlay over the document and underneath the progress bar to make it more obvious that that particular document was locked, but it wasn't implemented when the video was recorded. Cheers, Matthew Brush [1]: http://codebrainz.ca/screencasts/Loading300MBFile.avi [2]: http://www.scintilla.org/ScintillaDoc.html#BackgroundLoadSave ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Segmentation fault
On 13-10-13 11:38 PM, n@sk0 wrote: Hi all, i have enabled geanyprj plugin, i found this when : 1. Open Geany with no-documents opened. 2. Click Tools - Project - Preferences It's likely because Geany allows no documents open by default (see `Preferences-Various-new_document_after_close`), so all plugins that don't check for this every single time will explode when there's no documents open. It might be a workaround until the plugin (or plugin API) is fixed to check this option. P.S. Better to post this to the bug tracker to avoid it getting lost in mailing list archives: https://sourceforge.net/p/geany-plugins/bugs/ Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] splitwindow2
On 13-10-11 02:23 AM, Thomas Martitz wrote:
Am 11.10.2013 07:01, schrieb Matthew Brush:
notebooks. 99% of the now hardcoded places will work fine, e.g. I'm
using gtk_widget_get_parent(sci) to get a doc's notebook and implement a
foreach_notebook() macro. So this should make it really trivial to
support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla
will be packed directly into a notebook. Plugins can easily break this
assumption by reparenting the Scintilla widget, and even my
document-messages branch moved each Scintilla into a VBox inside each
tab so it could pack a GtkInfo bar above it. I think we could get rid
of this assumption by designing the code better.
Okay, I have written a function that walks the tree to find the parent
notebook. So this assumption is no more. Thanks for the hint.
You don't need to walk any tree's, if you need to notebook from the
scintilla, just store a pointer to the notebook in the scintilla, ex.
using g_object_set_data() or more painfully by subclassing it.
Please don't write another foreach_ macro. Lets make it so we can use
normal C code. If you need a macro like foreach_notebook() it's
probably because the code it's hiding is crappy underlying code, IMO.
I like foreach_*, and many other people do. I guess it's subjective.
Plus it will make the transition from main and secondary notebook to
array of N notebooks easier.
What's the problem with just using C code?
for (size_t i=0; i notebooks_arr-len; i++) {
// just normally use elements in the GPtrArray (as example)
}
Such macros not only make for weird APIs but also do weird stuff with
arguments since it's just textual replacements.
But still, I personally don't have a need for more than 2 notebooks.
Plus I see it will be difficult to support, because you need to nest
GtkPaneds. Since you suggest arbitrary splits you can do this only
programmatically which sounds like a major headache to me (especially
w.r.t. saving/restoring state). For now I want to concentrate on lifting
the hardcoded single notebook without ending up in the same situation
for two ones and without worrying about the heavy case of arbitrary
notebook placing. Then we can continue from there on with more
sophisticated stuff.
However if you have already successfully implemented this in a toy
editor I welcome you to join the fun.
Just to be clear, regarding the split window feature in my toy editor,
I only coded the UI logic, not any of the storing config of what panes
were open or what documents they had in them and more complicated
stuff like this. But the UI was indeed quite neat. SublimeText also
has a similarly flexible split pane system.
Okay, so you stopped ater the easy parts :P
Yep :)
All of those functions in document_ module shouldn't care the least
about GTK+ or even notebooks, IMO. This is the type of stuff I want to
cleanup.
There are also many direct uses of main_widgets.notebook, changing these
might (or might not) affect plugins.
IMO, if you're going to break the plugin API anyway, I say make it
good and we'll fixup core and GP plugins and make a message on the
mailing list for other users to know what broke and how to fix it in
their own personal plugins.
It's not yet clear to me how bady (or if at all) the API is going to
break..
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.
IMO, least amount of changes is not necessarily a virtue, and can even
lead to further gluing of the code together making future changes even
harder.
But it's better than not getting the job done at all because people want
to much at once.
Yeah, but I wonder. Sometimes just patching on more changes adds to the
number of bugs and code weirdness at least as much as just refactoring
the code being patched on to. Of course if you just want to tack on a
quick feature this is desirable, but if you want to improve the overall
code quality, it's arguable.
So, any opinions?
It sounds like you already are planning some of this, but it would be
nice to cleanup a lot of the assumptions/hardcoded stuff/weirdness
while making these fairly intrusive changes. For example:
- The relationship between documents and notebooks they're in, as you
discussed. As Lex mentioned, it would be nice to not make too much new
hard-coded assumptions about other documents only being allowed in
another notebook, but rather making it extensible to support multiple
windows in the future. Also as I mentioned, it would be nice to not
make any hard-coded assumptions about only having two split
notebooks[1].
gtk_widget_get_parent(doc-editor-sci) without hardcoding. I'm using
this where possible.
You're still hardcoding, just a different assumption as mentioned above.
The notebook of a doc can be retrieved via - The relationship
between documents
Re: [Geany-Devel] splitwindow2
On 13-10-11 03:29 AM, Thomas Martitz wrote:
Am 11.10.2013 12:07, schrieb Matthew Brush:
On 13-10-11 02:23 AM, Thomas Martitz wrote:
Am 11.10.2013 07:01, schrieb Matthew Brush:
notebooks. 99% of the now hardcoded places will work fine, e.g. I'm
using gtk_widget_get_parent(sci) to get a doc's notebook and
implement a
foreach_notebook() macro. So this should make it really trivial to
support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla
will be packed directly into a notebook. Plugins can easily break this
assumption by reparenting the Scintilla widget, and even my
document-messages branch moved each Scintilla into a VBox inside each
tab so it could pack a GtkInfo bar above it. I think we could get rid
of this assumption by designing the code better.
Okay, I have written a function that walks the tree to find the parent
notebook. So this assumption is no more. Thanks for the hint.
You don't need to walk any tree's, if you need to notebook from the
scintilla, just store a pointer to the notebook in the scintilla, ex.
using g_object_set_data() or more painfully by subclassing it.
That pointer needs to be updated properly when the doc is moved. I
Yep, but it's one single place this could happen.
rather save that and walk the tree, it's cheap enough.
(g_object_get_data() is a hash-table lookup which isn't exactly free
either)
O(1) is pretty OK to me :)
I actually don't think they use hash table for GObject data lists
though, rather it's probably some type of binary tree or such but it's
still relatively cheap lookup.
Please don't write another foreach_ macro. Lets make it so we can use
normal C code. If you need a macro like foreach_notebook() it's
probably because the code it's hiding is crappy underlying code, IMO.
I like foreach_*, and many other people do. I guess it's subjective.
Plus it will make the transition from main and secondary notebook to
array of N notebooks easier.
What's the problem with just using C code?
for (size_t i=0; i notebooks_arr-len; i++) {
// just normally use elements in the GPtrArray (as example)
}
Such macros not only make for weird APIs but also do weird stuff with
arguments since it's just textual replacements.
There is no notebooks_arr in the current code. Instead there is a
macro which makes it easy to transition to such an array later on.
? I mean to just literally use a real GPtrArray of notebooks, instead of
just toggling between a fixed two of these containers.
Seriously, if foreach_* macros are so frowned upon, why is Geany still
full of them? I'm literally just following existing Geany-style with
that macro.
I personally like these macros, they are easy to understand and nicely
short. I've also seen them used in other projects.
I don't doubt it, but what really does it gain over just putting the
literal C code? If you are repeating it so much, refactor your code,
otherwise, it's just normal part of C. Mutilating C with the
preprocessor quite often does not improve the clarity of usability of code.
The notebook of a doc can be retrieved via - The relationship
between documents (models) and Scintilla (views),
they should be almost completely independent. There shouldn't need to
have document-editor-scintilla, the document needn't care what view
it's in, only the reverse. I have no idea where GeanyEditor fits into
this, I've never understood why it exists; it's not a view, it's
not a
model, and it's not really a controller either, it's like part
wrapper
over Scintilla, part extension of GeanyDocument or something like
this
I guess?
Sorry, I think this item is out of scope for this work. FWIW, I don't
quite understand the deal about GeanyEditor either.
It's not out of scope, but it is way more work than I think you're
personally prepared to do. It's basically the reason no one fixed the
split window before or worked to moving it into core, because it was
too much work with the current way it's coded. If this kind of stuff
gets cleaned up first, the split window thing becomes trivial (as well
as multi-window, etc). I would've fixed up split window myself 10x by
now if I didn't morally have to cleanup all this code to do it
correctly.
See, if you make this kind of cleanup a hard requirement that no
progress is going to happen, for the reasons you mention. Can't we just
progress with managable portions of cleanups/workload, considering our
already heavily limited developer manpower?
Yep, that's why my previous message, I'll try not to interfere here
too much since no one is interested in the type of stuff I'm talking
about probably (cleanup up the code en masse).
I would still love to collaborate with you and other devs, even if I'm
not going to make the uncertain (for me, anyway) big cleanup personally.
Yeah, the big cleanup is more of a pipe/future dream for me I guess, so
I'll just contribute and help out normally rather than get too
Re: [Geany-Devel] Drop GtkStock and use symbolic icons
On 13-10-10 04:43 PM, Colomban Wendling wrote: Le 11/10/2013 01:24, Yosef Or Boczko a écrit : Hi all, Hi. I won't be much available this WE so I'm dropping a quick reply. 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. Why would it be more clean and modern? OK, GTK guys seem to think that having a non-uniform desktop experience by dropping one of the greatest features GTK had (stock items) is a good idea, so we probably s/GTK guys/a GNOME designer/ What's more, it's not just stock items affected, if you look at the Git log, it's actually about 25-50 different incidental APIs that got deprecated by him without any prior public/open discussion or thoughtfulness on the amount of work, breakage and crappy code that it would introduce, or the fact that most GTK+[1] applications are not part of the GNOME project. /gnome rant Cheers, Matthew Brush [1]: GTK = GIMP Toolkit = GNU Image Manipulation Program Toolkit, *not* GNOME Toolkit as the GNOME design team seems to think :( ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Drop GtkStock and use symbolic icons
On 13-10-10 05:14 PM, Yosef Or Boczko wrote: On Fri, Oct 11, 2013 at 2:43 AM, Colomban Wendling lists@herbesfolles.org wrote: Le 11/10/2013 01:24, Yosef Or Boczko a écrit : [snip] Also, in GNOME 3.10 the Stock items is drop [1], and UI with Stock is look outdated. How does the UI look outdated? Using named icons won't change a thing, in the end they all use the theme's icons. The icons in the menus and in the buttons in the dialogs isn't add any information. I not think the 'OK' icon is add information there isn't in the string „Save”. So why have anything that doesn't add information? We could use text-only toolbar, force off user's theme choice and use plain/stock theme, remove choice of syntax highlighting colours, remove icons from the symbols tree, hard-code the font family and size to the Geany developers preference, etc... In reality it doesn't matter what we think, or what the GNOME design team thinks, such stuff is extremely subjective and personal and the only apps that need to care about GNOME design manifesto are GNOME applications themselves. P.S. As you can tell this subject is extremely controversial outside of GNOME-land (or at least inside of Geany-land), please don't mistake rants for anything personal against your own valid opinions :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Drop GtkStock and use symbolic icons
On 13-10-10 05:47 PM, Yosef Or Boczko wrote: On Fri, Oct 11, 2013 at 3:27 AM, Matthew Brush mbr...@codebrainz.ca wrote: On 13-10-10 05:14 PM, Yosef Or Boczko wrote: On Fri, Oct 11, 2013 at 2:43 AM, Colomban Wendling lists@herbesfolles.org wrote: Le 11/10/2013 01:24, Yosef Or Boczko a écrit : [snip] Also, in GNOME 3.10 the Stock items is drop [1], and UI with Stock is look outdated. How does the UI look outdated? Using named icons won't change a thing, in the end they all use the theme's icons. The icons in the menus and in the buttons in the dialogs isn't add any information. I not think the 'OK' icon is add information there isn't in the string „Save”. So why have anything that doesn't add information? We could use text-only toolbar, force off user's theme choice and use plain/stock theme, remove choice of syntax highlighting colours, remove icons from the symbols tree, hard-code the font family and size to the Geany developers preference, etc... In reality it doesn't matter what we think, or what the GNOME design team thinks, such stuff is extremely subjective and personal and the only apps that need to care about GNOME design manifesto are GNOME applications themselves. It not right, you not adds things without any reason. In the toolbar there isn't place to text, so use icons with a tooltip instead. In button in dialog have a place to text, so not need a icon and a tooltip. Syntax Highlighting colours is for **highlighting** the code, and the icons in the symbols tree is for distinguish between kinds of symbols (yes, is not matter what is the icons in the symbols tree, it just need to be different), etc - for each thing in the UI have any reason! As a real-life analogy since I'm quite bored right now... I'm not sure how they are in all different parts of the world but I assume it's similar everywhere, traffic lights have at least 3 different round lamps in them, one is green which means go, one is yellow which means go faster or else you'll have to wait for a while, and one red which means stop, unless nobody is looking. The reason such seemingly superfluous icons are useful in GUI elements is the same reason the traffic lights don't just display the words proceed, prepare to stop, and stop in monochromatic lettering. The other reason the they are useful is because GUI widgets like traffic lights are not always in the same location, position, orientation, or size. Having those same 3 colours consistently everywhere permits drivers from different places to know what those differently sized and positioned traffic lights means. Just consider the little disk, stop sign, or check-marks icons that the user learns as traffic lights for the user interface. For common actions, the text is actually redundant and the icon becomes more important (to those not using screen readers anyway). Having both is fine since some icons and themes are not very understandable or are even missing icons[1] and sometimes you do need to read the labels since not all actions are common[1] and need descriptions, and also for accessibility purposes. I don't see a problem with a toolkit-wide option to disable those icons if the user requests, but it seems presumptuous to assume that they are not useful or wanted by many people. P.S. As you can tell this subject is extremely controversial outside of GNOME-land (or at least inside of Geany-land), please don't mistake rants for anything personal against your own valid opinions :) Before GNOME 3.10 I was used the icons in the buttons and in the menus, but I see is realy ugly and not useful. It's so subjective though, I happen to think the exact opposite. I use XFCE, Win7 and MacOS Lion too, so it's not like I'm just not used to the different takes on this. This is precisely what user preferences are good for. Cheers, Matthew Brush [1]: Although I think with stock icons at least there was a sane fallback built into GTK+, not sure if that's deprecated too. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] splitwindow2
be useful to sort this out as well, since GeanyEditor is closely intertwined with GeanyDocument and Scintilla view, which is exactly what should be cleaned up to make stuff like split view or separate windows easier to write. - The lifetimes of documents. I don't see any reason to recycle a fairly small structure like GeanyDocument, especially since we basically set it up and tear it down each time anyway. I doubt the overhead of freeing an old GeanyDocument structure and allocating a new one later is worth the contortions it causes in code and the weirdness in the plugin API. The idea sounds correct, not sure just how much it takes to change it. If split-window doesn't need to change it, it isn't *that* big an issue IMHO. But anyway its not part of split-window. As above. - This follows with above, document_get_current() should *never* return NULL. It makes absolutely no sense to me to allow having Geany open without a document open. It'd be like having Firefox open with no tabs/webpages open. Either it should open a blank untitled document when the last one closes (this option exists already IIRC) or Geany itself should just close (probably too annoying :) These last two would get rid of weirdness like doc-is_valid, DOC_VALID(), documents macro wrapping documents_array, foreach_document() macro to iterate documents, etc. Nice idea, provided its semantics work for multiple views. Does each view get its own untitled or what? Anyway should be completely separate change set, its not actually part of split-windows. If it makes split-windows significantly easier, then do it first as a separate thing. As above. We're touching all this code anyway, lets clean it up and make it better while doing such changes. Otherwise we'll just have more stuff stacked ontop of this making it even harder to fix up and causing more big-ish breaks in the future. - Encapsulating the GeanyDocument so that plugins can't mess with read-only members. For example, it makes no sense to allow plugins to change doc-read_only, or doc-file_name (one of them actually does this). It would be nice to make the API consistent here, like we have document_set_text_changed() to mark the document as ditry/clean, but there's no getter like document_get_text_changed(), which is inconsistent and it allows plugins to seriously break Geany if they aren't careful. This one is of course fairly off-topic and could be attacked separately afterwards, I just thought it was worth mentioning since you talked about needing to break the plugin API, it might be useful to improve it during the breakage. Restrictions on the plugins should only be applied to preserve invariants that Geany actually depends on, otherwise we are just pretending we can anticipate all the uses a plugin might need. And if as you say, one plugin is already using those settings, then I guess we missed that use-case :) It goes a long way to make an API consistent though, the mismatch between document_set_text_changed() and doc-changed from an API POV is not very nice, and being able to do `doc-changed = FALSE;` in a plugin might even be dangerous, if not only make the UI inconsistent with it's backing data structure. Also, when you have something like document_get_text_changed(), you can later re-write to ask Scintilla if it's model has unsaved changes rather than synchronizing them manually. You can also do all kinds of other interesting stuff inside the getters, but you can't do it later if you just expose direct access to the structure's members, as I'm sure you know. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] splitwindow2
On 13-10-10 05:03 PM, Thomas Martitz wrote: Am 11.10.2013 00:55, schrieb Matthew Brush: On 13-10-10 03:03 AM, Thomas Martitz wrote: 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 can actually change which document it shows by using the little drop-down button at the top. Still, real notebooks would be nicer. Yea, right. I worded it badly. I meant the other view can only hold one document and you can swap that one only using non-standard methods. Yeah, it's a kind of weird interface, although it works not bad considering. - you cannot undo/redo: you need to select the tab in the main notebook to do that You can undo using the builtin Scintilla right-click context menu, but still would be great to have full keybindings+edit menu functionality. Oh, I wasn't aware of that. Still crap :) It was somewhat recent-ish. At first we didn't have it because it didn't integrate into gettext translation stuff, so we couldn't translate the menu items, but IIRC it was later decided that it was such a needed feature being able to copy/paste/undo/etc, that at least having a minimal non-translated menu is better than nothing. - 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. I think this is intended and I find it useful personally. I don't think it should be taken out, IMO. - you cannot toggle between the views with a keybinding (e.g. ctrl+tab) - weird focus behavior - more... ...Basically all edit keybindings, the edit/context menu and also auto-indentation and similar features implemented inside Geany. My plan is to reimplement splitwindow using a different approach: by having two real, independemt notebooks, one primary and one seconary. Why limit it to two? Even if it ends up being the default/primary mode of operation, IMO it'd be a shame to make another hard-coded assumption.[1] Well, first: I'm not going to be hardcode two notebooks (except where necessary and trivial extend, e.g. for my current toggle this between This sounds good. notebooks. 99% of the now hardcoded places will work fine, e.g. I'm using gtk_widget_get_parent(sci) to get a doc's notebook and implement a foreach_notebook() macro. So this should make it really trivial to support even more than 2 notebooks. gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla will be packed directly into a notebook. Plugins can easily break this assumption by reparenting the Scintilla widget, and even my document-messages branch moved each Scintilla into a VBox inside each tab so it could pack a GtkInfo bar above it. I think we could get rid of this assumption by designing the code better. Please don't write another foreach_ macro. Lets make it so we can use normal C code. If you need a macro like foreach_notebook() it's probably because the code it's hiding is crappy underlying code, IMO. But still, I personally don't have a need for more than 2 notebooks. Plus I see it will be difficult to support, because you need to nest GtkPaneds. Since you suggest arbitrary splits you can do this only programmatically which sounds like a major headache to me (especially w.r.t. saving/restoring state). For now I want to concentrate on lifting the hardcoded single notebook without ending up in the same situation for two ones and without worrying about the heavy case of arbitrary notebook placing. Then we can continue from there on with more sophisticated stuff. However if you have already successfully implemented this in a toy editor I welcome you to join the fun. Just to be clear, regarding the split window feature in my toy editor, I only coded the UI logic, not any of the storing config of what panes were open or what documents they had in them and more complicated stuff like this. But the UI was indeed quite neat. SublimeText also has a similarly flexible split pane system. 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 As mentioned above, this is actually a feature and IMO it should be kept unless there is some serious technical reason that makes it impossible. Scintilla can easily be showing the same document in two views and it keeps them in sync (see SCI_SETDOCPOINTER and friends). Do you edit on both views or just read on one part of the doc while editing
Re: [Geany-Devel] Ping on Bug #943 - windows build command
On 13-10-09 07:42 AM, Nick Treleaven wrote: On 09/10/2013 01:50, Matthew Brush wrote: [snip] GTK+ 2.22 is over 3 years old by now, FWIW. I'm using 2.22 under win~1 too, and don't think it will have any problems with async exec, but we'll see. Yeah, just pointing it out because 3 years is a lot of code churn for a project like GTK+. There's been ~15.5 thousand commits[1] since the 2.22.0 tag :) g_spawn isn't gtk. gspawn[,-win,-win-helper].c don't seem to have any significant fixes. I could be wrong, but it doesn't look hopeful. Yeah, sorry, I was speaking more generally (ie. OT) about using an older GTK+ bundle with there being so many changes in each GTK+ release, not specifically about the thread topic/GSpawn stuff. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Improving FiF
On 13-10-09 07:15 PM, Lex Trotman wrote: [...] 3. For non-recursive searches, grep does not allow a directory to be specified instead of file. To work around that, we read the directory, back-parse all --include=*.x patterns, and match them manually. Proposition: grep -rl --include=*.c --exclude-dir=[^.]* --exclude-dir=.?* void . :) We pass our Directory as a workind directory to spawn, and the recursive search already uses . as a grep FILE argument. --exclude-dir is supported since more than 5 years. Is there any reason we cannot just walk the directory/subdirectories ourselves and search the files using GRegex stuff? The pattern syntax would then be the exact same as the other search dialogs and it would save having to not only spawn a subprocess but also remove the dependency on grep (only a problem on Windows). Also, as a future optimization, if any of the files to search are open in Geany, we could search their document buffer directly from memory rather than having to do any file IO for them. GIO/GFile has all the stuff needed to walk a directory tree and open files both asynchronously and portably IIRC. *Technically* the only issue I know of is that last time I looked PCRE was much less optimised than grep (partly because PCRE is more general) so searching a big tree of big files may be noticeably slower. But this is more code that needs to be written, debugged and maintained. Pull requests (with an ongoing support pledge) are welcome. I'll gladly write and help maintain it if I don't have to bikeshed over using stupid old versions of GIO which might not have the features needed[1] to implement it properly without dirty hacks or #ifdef stuff :) The benefits of control and consistency (and as you pointed out on IRC to search the buffers not the files for open documents) may not outweigh the cost of doing it. Cheers, Matthew Brush [1]: I haven't investigated deeply, the docs don't list since versions for some of the functions that would be used. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Ping on Bug #943 - windows build command
On 13-10-08 10:28 AM, Dimitar Zhekov wrote: On Mon, 07 Oct 2013 12:28:49 -0700 Matthew Brush mbr...@codebrainz.ca wrote: [...] Any chance you could find time to review and test Geany's implementation to see if anything looks fishy? I can simply test FiF with regex = ., which will generate a lot of output quite fast. Without the SYNC_SPAWN patches, build.c and search.c async executions are identical (except that build checks if the returned pid after successful spawn async is 0, but still sets the channels if it's not - I wonder why). Can you get grep to write a lot of stuff to both stdout and stderr in the same run though? What about wrapping grep in a shell script that uses `tee` (or equivalent) to dump the output to both streams? GTK+ 2.22 is over 3 years old by now, FWIW. I'm using 2.22 under win~1 too, and don't think it will have any problems with async exec, but we'll see. Yeah, just pointing it out because 3 years is a lot of code churn for a project like GTK+. There's been ~15.5 thousand commits[1] since the 2.22.0 tag :) OT: Do you have any idea how to make g_spawn_async_with_pipes() to not open a Command Prompt window on Windows? My new plugin filters the document text through a subprocess very often and the popup console windows are super annoying :) [snip] Last, you can create a small GUI subsystem wrapper which runs your console application with CreateProcess(), and use either the creation flags or the startup information to hide or minimize it. Hmm, this is probably the best and easiest solution, thanks for the idea! Cheers, Matthew Brush [1]: According to `git rev-list 2.22.0^..HEAD | wc -l`, not sure if that's the right way, my gitfu is weak. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Ping on Bug #943 - windows build command
On 13-10-07 08:31 AM, Nick Treleaven wrote: On 05/10/2013 15:40, Matthew Brush wrote: On 13-10-05 07:06 AM, Nick Treleaven wrote: On 05/10/2013 14:59, Nick Treleaven wrote: 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. It was last year, but I think it wasn't just with dmd, although that triggered it the most, and it only happened when dmd wrote more than a certain amount to stderr (cascading errors). It was very suspicious that the custom spawn code works until there are too many errors, at least with dmd. One person reported it on the devel list. See: http://lists.geany.org/pipermail/devel/2011-July/004845.html Unfortunately I missed that mail at the time, but I tried the provided fix before committing my system() change, and I remember it didn't fix all the issues with blocking and/or hanging Geany I had. That was going to be my guess for the deadlock, once the buffers fill up they have to be drained or else can't keep writing to input. The same issue should apply to any spawning method we use probably (ie. GSpawn). Did we get deadlock with g_spawn? I'm only aware of missing output. It sounded like what was described by Josh in your link: The problem seems to be that pipes are only 4kb buffered by default, so any process needing to write more than this would block while writing to stdout and Geany would kill it, as it wasn't reading the pipes until after the process exited. So with the pull request adding system() as a fallback/hidden preference, maybe we could just drop the win32 API code altogether, switch back to using the same codepath as all platforms (ie. GLib async spawning) and if people experience issues, we can use as further data points to troubleshoot GLib async spawning and we can recommend they try the system() option[1] as a workaround? system() is *synchronous*, so we couldn't remove the SYNC_SPAWN code and have it as an option. I mean to remove the win32_spawn function (as it existed before the system() hack), the one that was left orphaned in win32.c and renamed it to broken_win32_spawn() that uses the win32 API rather than GLib spawning or system(). IMO, any function in our code base prefixed with _broken, that no one wants to touch, and looses platform-independence for our code, should just be deleted[2] :) I thought you said it was most important to fix the common case, that's why I made the PR. I imagine the most common case would be that g_spawn_async_with_pipes() works. I've used it a number of times on Windows without issues and I've not found online or encountered any issues with lost output that's being claimed as the reason for all these work-arounds for it. BTW, did you try undefining SYNC_SPAWN lately to see if async spawning still doesn't work for you now? If so and it doesn't, what Windows version and GLib versions do you have? I just tried it. Running build on a C file: gcc -Wall -c build.c (in directory: C:\git\geany\src) Compilation failed. gcc: error: build.c: Invalid argument gcc: fatal error: no input files compilation terminated. No idea why gcc says that, also tried for another file in parent directory. Running build on a D file just says 'Compilation failed' without reporting the line compilation fails on. Windows Vista. GTK 2.22.0, GLib 2.26.0. GTK+ 2.22 is over 3 years old by now, FWIW. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Interested making a patch to add QML support
On 13-10-07 12:01 PM, Tory Gaurnier wrote: Well I've run into quite a strange bug, and I'm wondering if anyone has had a similar issue. It's working as expected when you first open a QML file, it finds all the tags and places them in a hierarchy/tree structure in the symbol list, however, when you do something that causes it to refresh (like deleting a bracket or something else), then it suddenly removes a whole bunch of the tags from the symbol list and it doesn't add them back no matter what. Doesn't it rerun your whole filetype.c file every time it refreshes the symbol list? At first I thought it could be a memory corruption because I didn't yet have all my malloced values being freed, but I've fixed that, every bit of memory I allocate is freed now, so it's not that. What scenarios could possibly cause something like this? I've no clue specifically, but if you suspect memory corruption, you might find some interesting stuff by running Valgrind and checking for any invalid read or invalid write messages. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Ping on Bug #943 - windows build command
On 13-10-07 09:13 AM, Dimitar Zhekov wrote: On Sun, 6 Oct 2013 11:02:07 +1100 Lex Trotman ele...@gmail.com wrote: On 6 October 2013 06:06, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Sat, 05 Oct 2013 07:40:15 -0700 Matthew Brush mbr...@codebrainz.ca wrote: So with the pull request adding system() as a fallback/hidden preference, maybe we could just drop the win32 API code altogether, switch back to using the same codepath as all platforms (ie. GLib async spawning) and if people experience issues, we can use as further data points to troubleshoot GLib async spawning and we can recommend they try the system() option[1] as a workaround? Scope uses g_spawn_async_with_pipes() on Win~1 to both read from and write to gdb without any problems that I know of. Could be because of the specially written event source, or simply my ignorance. Also can't remember whether I specially tested stderr. Or possibly works because its just short messages, IIRC one of the problems only showed up with lots of data. Unlikely. It's fully async, and even reentrable for the most part, so the message size should not matter. And since the win~1 was custom, I tested the *** thing with the order of megabytes while developing it. BTW, I re-checked stderr, and it works fine. Any chance you could find time to review and test Geany's implementation to see if anything looks fishy? OT: Do you have any idea how to make g_spawn_async_with_pipes() to not open a Command Prompt window on Windows? My new plugin filters the document text through a subprocess very often and the popup console windows are super annoying :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Plugin development questions
On 13-10-07 01:06 PM, Thomas Martitz wrote:
Am 07.10.2013 21:53, schrieb Thomas Martitz:
Am 07.10.2013 12:27, schrieb v01d:
Hi,
I'm writing a simple plugin for geany (which I will call LiveDiff)
which allows for having
indicators inside the editor for changed/added/modified lines, which
is updated as you type. The base for comparing
the buffer can be either the version of the file on disk or (which I
will soon attempt to add) the latest version from the git repository,
if the file is versioned so.
This resembles what netbeans does (one something I really liked). So
far it works OK but there are some quirks.
I'm doing this out of spare time so dont expect a pretty serious
commitement to it. I will however make it available on github.
I wanted to ask regarding the ScitillaObject handling. Currently my
plugin needs to define RGBA markers (which are used to indicate the
diff results per-line).
What it is not really clear to me is that there appears to be one
ScintillaObject associated with each GeanyDocument. However, some
messages sent to the ScintillaObject (like changing the margin or
defining markers) appear to be global across all instances (unless I'm
mistaken). Is this so? What would be the proper handling? Is it ok to
repeat the definition of the markers for each editor?
Moreover, I'm not sure how to handle correctly the size of the RGBA
markers since it depends on the font size of the editor. I tried to
set the marker scale using the text_height to image height ratio, but
the marker still appears to be a bit taller than the line and this
creates some visual artifacts.
Hello,
[1] might be of interest for you. It does something very similar.
Regarding your other question, are you talking about the
editor-notify signal? Yes, that's not really per-document, I came
across this recently. The solution is to connect to sci-notify of
ScintillaObject directly, this will give a proper per-document signal
(the document-specific ScintillaObject pointer). However you need to
get the GeanyDocument pointer elsewhere. See how I did it here[2].
Some might consider this as a defect in Geany.
[1]: http://lists.geany.org/pipermail/devel/2010-June/002584.html
[2]:
https://github.com/kugel-/geany-plugins/commit/7f19c3035abf6f8a7fa66c7b4c1efe0851cb2f83
I need to correct myself. editor-notify is correctly per-document and
you can get the GeanyDocument pointer via the GeanyEditor pointer passed
to it. What I meant to say is that you cannot use editor-notify if you
need to attach user_data on a per-document basis. The user_data pointer
passed to plugin_signal_connect(editor-notify, ...) will be
overwritten on each successive all. My suggested workaround works for
this case. With sci-notify you can attach user_data on a per-document
basis.
As long as the Scintilla view doesn't switch document models, like some
view recycling optimizations or split/multi view magic or something. I
don't think anything actually does this at present, but it could in
theory, without breaking the API, or it could even be done by another
plugin.
Last time I needed to do this, I made a hash table that used
g_direct_hash on the GeanyDocument pointer as the key, and the value was
my custom/user data structure. Then I had a function that effectively
did this:
void *document_get_context(GeanyDocument *doc) {
return g_hash_table_lookup(global_hash, doc);
}
Then to keep it sync, I used code like this:
http://pastebin.geany.org/Y1O3d/
Where the dm_*() calls are keeping the hash table consistent with the
current set of documents. It's kind of a lot of boiler-plate to attach
data to a document, but it seems to work quite well :)
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Intro
On 13-10-05 03:12 AM, Mark Robinson wrote: Hi Lex, Thanks for the welcome. Yes, I read the HACKING doc., and followed it to the letter. I have the new lexer up and working on a private link from a GIT extract. The plugin seems to be working as well, so my C skills are getting better (I think). The idea is to take the snippets in snippets.conf and allow the user to select them (double click to insert snippet) from a scroll window in the side-bar rather than have to remember the keyword (I'm old as well, so memory is an issue :)). The new filetype I want to add has over 500 functions in its library, so you (I) can't remember the snippet keyword for all of them. It occurred to me that this should work for any snippets, and it does. Oliver Marks made a GeanyPy plugin that sounds very similar to this. I can't find the Github repo anymore but you can see the Google+ posting about it here[1] and the Ubuntu PPA is here[2]. Just thought I'd mention it since it sounds so similar. Cheers, Matthew Brush [1]: https://plus.google.com/108080448324780364479/posts/5KTLneQbxyG [2]: https://launchpad.net/~oly/+archive/geany ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] On Deprecation of Platforms
On 13-10-02 10:25 PM, Steven Blatnick wrote: [...] Do we know how many people on Windows use Geany, users specifically and not geany devs? It's impossible to know[1] but if I had to guess[2], I'd say at least 25% of users are on Windows. In addition, I believe several of the core developers and contributors use Geany on Windows on a regular basis. Cheers, Matthew Brush [1]: I don't think our server tracks download statistics, could be wrong. Source Forge downloads haven't been updated since 0.19. [2]: Based on gut-feeling given recollection of mailing list, IRC and bug tracker activity. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Ping on Bug #943 - windows build command
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/a3664fae9ece396952d732cc937e63192d8c6f76 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 ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] On Deprecation of Platforms
On 13-10-03 07:37 AM, Lex Trotman wrote: On 3 October 2013 23:19, Colomban Wendling lists@herbesfolles.orgwrote: [...] Anyway, although I agree the Windows version isn't as good as it should right now, I don't really see the problem it causes to the rest of Geany. And if we indeed clean some things up a little like Matthew suggests, it could even be just fine (Windows dialogs, come on). Again, the issue is, without anybody to do it, all that happens is that the rest of Geany gets less love. I'll do it, as long as it doesn't involve endless bikeshedding on the mailing list over minute details of each change ... which I guess means I won't do it :) Lots of people over the years have put forward suggestions, but none of them have even dropped a PR or patch, let alone assisted with maintenance. Its not nice to cut off a platform, but if everybody expects others to do the work, then we may have no choice or the whole project will collapse. The end is nigh! :) I'm not saying delete anything inside #ifdef OS_WIN32 tomorrow. But also in fairness some warning that platform specific code is not being maintained adequately needs to be given to Windows users, and their help sought, and this is one way I can think of that makes it clear. Other suggestions are welcome :) We should delete as much #ifdef G_OS_WIN32 code as possible as soon as possible, IMO. All of that code is superfluous since we use a (reasonably) cross-platform toolkit, all it does is adds more places for bugs to hide, more work to maintain it, and as mentioned none of the developers even wants to touch it. Aside from the build/release process, which does need some love currently, there should be next to no extra work involved in having Geany work on supported platforms. My $0.02 P.S. Out of curiosity, if you had to guess, how many of those 10% of Windows bugs on the tracker are related to special win32 code vs. regular old cross-platform code-paths that we all use on other platforms daily? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Interested making a patch to add QML support
On 13-09-22 01:09 AM, Tory Gaurnier wrote: [...] One thing I notice is I don't see line numbers on output, is there an option I have to run ctags with to show the line numbers maybe? --excmd=number Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] RFC: Policy for Glade File Updates
On 13-09-18 09:07 AM, Nick Treleaven wrote: On 12/09/2013 01:38, Matthew Brush wrote: P.S. Are we all still agreed to using old 3.8.1 version of Glade? I think this idea of using same version sounds good, at least we won't be causing additional noise in diffs due to different versions writing stuff out in different ways. One might hope so, but 3.8.1 causes massive noise, see: http://lists.geany.org/pipermail/devel/2012-January/006418.html Yeah, that's why I was saying maybe we should do like we (ideally) do with the geany.txt file; make the changes and commit the text changes, and then as a separate commit, generate the HTML and commit the noisy one. If we did this, at least we could be sure that it won't be the next person who edits the file's job to figure out if saving the file will break it (like it will at present if anyone tries to edit it with any version of Glade). I've just seen 3.14.2 is available for windows though. In my experience, after Glade 3.8(.X) it got *much* worse; very very much slower with big files like geany.glade, and crashing so much I had to get into the habit of saving after every single action. I think I only tested up to 3.10 though, so it might've stabilized since the massive GTK3 disruptions in its code base. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99
On 13-09-04 09:20 AM, Nick Treleaven wrote:
On 01/09/2013 02:36, Matthew Brush wrote:
I would even go so far as to say it's silly to not use C++11 since it's
[...]
Just for fun I wrote some theoretical code that could be used in a
program like Geany to compare styles between various C's and C++'s
(note: none of it tested).
http://pastebin.geany.org/gYFMO/
My C89 C++ version:
guint i;
foreach_document(i) {
GeanyDocument *doc = documents[i];
// do stuff with every valid doc
}
While this code is short, it's actually sort of nuts too (and also not
very C++-ish).
1. You should include the definition of the custom macro used and the
definitions of the two other non-obvious macros used inside the first
macro for a fair comparison, since none of them are standard or even
well-known like the pasted examples.
2. The code does not loop over the windows like the pasted code, so
you'd need another outer loop which would likely have a 2nd style of
iteration wrapped around the existing loop.
3. It's somewhat unclear what type should be passed in looking at the
macro without the doc comments (I always forget and have to RTFM each
time I see it since we often use gint where we mean guint).
4. The argument is not only assigned to but also evaluated multiple
times (what if you pass `--i` or something weird as argument). I guess
assigning might be good here since the compiler would catch it rather
than flying off the end of the array when it hits `(guint)-1` (UINT_MAX)
on underflow.
5. It's fairly tricky to debug misuses of the macro (better with Clang).
6. The implicit check in the loop (failure first) indexes into a macro
wrapper around a whole other type using a hard cast from the result of
another function-like macro cast thing off in another file, and is
dereferenced without any NULL check (although probably safe in this
case, unless a plugin or something re-assigns the global variable or
redefines any macro aliases of it).
7. It forces you to define an indexing variable outside of the loop into
the wrong scope (C89-style, even if used in C99 plugin code).
8. Even though slightly dirtier, it would be more useful to iterate over
document pointers than document indexes (what are those? tab pages?
order of opening? arbitrary array indices?), for example (untested, C99
or GNU89 probably):
#define foreach_doc(doc) \
for (unsigned z_=0; z_ documents_array-len; z_++) \
if ( !((doc) = documents_array-pdata[z_]) || \
!(doc)-is_valid ) { continue; } else
...
GeanyDocument *doc;
foreach_doc(doc) {
// every valid doc
}
9. I personally find it annoying to use API's that have all their own
versions of things that are really common and not that hard anyway; it's
difficult to learn them all, and also all the stuff mentioned above when
they are macros. Consider this slightly longer example that uses no
macro madness and common C looping idiom:
guint i;
for (i = 0; i documents_array-len; i++) {
GeanyDocument *doc = documents_array-pdata[i];
// do stuff with every *should be* (but isn't) valid doc
}
Assuming the API didn't have the weirdness about documents being invalid
but still sticking around for whatever reason, it's the same number of
lines as the macro version and no magic.
10. The macro should be named `foreach_document_index()`.
/macro-hate
I don't think we should rewrite Geany's API in C++, or maintain a C++
wrapper for the C one, except for any cases which are particularly
bug-prone.
An idiomatic C++ binding would be quite useful for a plugin written in
normal C++. In my current C++ plugin I'm working on, I'm actually
wrapping up a few parts of Geany's API it uses to avoid scattering the
weird C code containing lots of raw pointers, miscellaneous allocators,
different string/collection types, and so on, throughout the normal C++
code.
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99
On 13-09-05 02:26 AM, Nick Treleaven wrote: On 01/09/2013 02:36, Matthew Brush wrote: On 13-08-29 05:08 AM, Nick Treleaven wrote: On 29/08/2013 02:39, Matthew Brush wrote: [...] If we were to use C++, I think it'd be pointless to limit it to CFront/CwithClasses-style 1980's C++. We should use common/standard stuff like standard library containers, inheritance (maybe not multipl-inheritance), the class keyword, templates (where it makes sense), exceptions, etc. The issues/limits being discussed in this thread are issues long since considered resolved or non-issues for a long time for desktop software (and since a *long* time even before Geany's first line of code was written :). The style of code I read on the net and in talks and books and stuff is modern (ie. = C++98) style C++ and I'd expect that's what the bulk of C++-using contributors would be used to using. Idiomatic C++ takes a *lot* of learning and experience to get right for someone coming from C. Do you think there's more C-only programmers out there contributing to desktop application projects than C++ programmers? I honestly don't know but my instinct says there isn't. If you mean open source projects, then yes. Somewhat difficult to measure, but some (possibly flawed) stats: Here C has at least twice the share of C++: http://lang-index.sourceforge.net/ In terms of noise on the web, here C also has approaching twice that of C++: http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html It would be better (but even harder to measure) to compare desktop applications, as I mentioned, like Geany since this is an area where C++ makes a lot of more sense compared to C, and there's a lot of excellent C++ GUI toolkits like Qt, WxWidgets, FLTK, FOX, GTKmm, WTL, etc. Compared to C, where GTK+ is about the only actually good toolkit I've ever come across. Also even if there were more C++ programmers, it would still be much easier for a C++ programmer to write C than vice versa. Yeah maybe, although if you learned C++ first, using C is fairly foreign and weird I'm sure. Also all of the other languages that support modern/more programming paradigms would probably make an easier transition to C++ than C. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [geany/geany-plugins] 6c2b0c: Debugger: Prevent crash when re-loading plugin
On 13-09-01 10:57 AM, Dimitar Zhekov wrote: On Sat, 31 Aug 2013 20:33:50 - Matthew Brush git-nore...@geany.org wrote: Debugger provides own GtkCellRenderer GTypes so its module must remain resident + plugin_module_make_resident(geany_plugin); + Note that when a resident module is unloaded and then reloaded (uncheck then check [] Debugger), the global variables are not re-initialized. So, if debugger contains any global [static] type variable = value, or relies on globals being 0, they must be initialized explicitly. Thanks for mentioning, I'll check. That might good information to add as a @note in the API docs for `plugin_module_make_resident`. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99
On 13-08-31 07:42 PM, Lex Trotman wrote:
[...]
Just for fun I wrote some theoretical code that could be used in a program
like Geany to compare styles between various C's and C++'s (note: none of
it tested).
http://pastebin.geany.org/**gYFMO/ http://pastebin.geany.org/gYFMO/
As discussed on IRC here's another way of doing the C++98/03, marked with
+es. http://pastebin.geany.org/AzbMV/
Or alternatively in c++11 :)
for_each(begin(App::instance().windows()),
end(App::instance().windows()),
[] (Window win) {
for_each(begin(win.documents()),
end(win.documents(),
[] (Document doc) {
// do stuff with each document
}
);
}
);
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99
On 13-08-31 07:05 AM, Nick Treleaven wrote: On 29/08/2013 06:47, Lex Trotman wrote: [...] Nick has offered that C++ might attract him to contribute more, I might have time at the end of my current contract, unless I get another quickly, I guess Colomban is out, Matthew? anybody else? I'm happy to manage/co-ordinate the transition to C++ (at a slowish pace), should we decide we want that. IMO, step #1 is to create a separate branch for this topic. I'm sure Colomban won't mind a separate branch if it's not affecting master and it would provide a hacking playground for everyone interested. If it proves fruitful, we could eventually look to merge/replace Geany code from this branch, even if we have to maintain separate branches for some time. I think starting with a core plugin is a good idea. The Class Builder plugin has lots of gnarly C string copying/formatting/etc, it might be a good candidate for hackage, as per your suggestion. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Let's move to C++98 - Re: Lets move to C99
On 13-08-31 04:37 PM, Lex Trotman wrote: On 1 September 2013 00:05, Nick Treleaven nick.trelea...@btinternet.comwrote: On 29/08/2013 06:47, Lex Trotman wrote: [...] On using gtkmm, personally I think it is *way* better than the C interface to GTK, but I don't know if it can be mixed with C GTK easily, and changing *everything at once* would be a big job. I don't know either, but gtkmm is much better than GObject boilerplate. Although I don't think we need custom objects that often. Funnily enough, since subclassing widgets is trivial with gtkmm, they start to be used more often in my experience :) Yeah, there's lots of cases for Geany; geany::MainWindow, geany::Toolbar, geany::PrefsDialog, geany::Scintilla, geany::StatusBar, geany::SymbolsView, geany::EditorMenu, and even the existing GObject subclasses, not to mention geany::Filetype or geany::Document and friends. Anywhere you want to extend/customize the behaviour of another class or widget or such. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Scope/VTE size bug
On 13-08-30 01:00 PM, Dimitar Zhekov wrote: On Thu, 29 Aug 2013 17:50:52 -0700 Matthew Brush mbr...@codebrainz.ca wrote: There was a bug report about message window sizing issues that seems to be caused by the Scope plugin: https://sourceforge.net/p/geany/bugs/988/ I'm not sure how to move the ticket to the Geany-Plugins bug tracker so I'm just sending it here. Thanks. If I recall correctly from writing MultiTerm, there's a bug in VTE library where it doesn't size itself properly (maybe something related to using width in characters instead of pixels) and it goes super-huge by default. Not huge, but certainly wider than a normal side panel. I simply haven't tested that. I didn't even know the option existed before that report, what a nice surprise! For MultiTerm, I remember I had to perform an explicit gtk_widget_set_size_request(wid, N, N) where N was any arbitrary size smaller than expected (I think I chose 100 or 10 or something). Also, I'm not positive, but the VTE widget might also need to be placed in a GtkFrame or similar, and then into an GtkHBox with a GtkVScrollbar (using the VTE's adjustment) next to the VTE into the GtkHBox. Mine is a scrolled window instead of frame/hbox/scrollbar, but the more likely reason is that I don't set fake initial sizes. The problem is, unlike the terminals, Scope's Program Terminal and Debug Console may emit a lot of text before being focused by the user. With fake sizes, this text is ugly wrapped, due to the small width, and scrolled up outside the window, due to the small height. I'll try to find something satisfactory, and leave a comment at this bug report when finished. Cool. FYI, a similar problem seems to exist in Debugger plugin[1], even though it seems to use same workarounds as Geany VTE and IIRC copied by MultiTerm plugin, that don't cause the issue for whatever reason. Cheers, Matthew Brush [1] https://sourceforge.net/p/geany/bugs/991/ ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Scope/VTE size bug
Hi, There was a bug report about message window sizing issues that seems to be caused by the Scope plugin: https://sourceforge.net/p/geany/bugs/988/ I'm not sure how to move the ticket to the Geany-Plugins bug tracker so I'm just sending it here. If I recall correctly from writing MultiTerm, there's a bug in VTE library where it doesn't size itself properly (maybe something related to using width in characters instead of pixels) and it goes super-huge by default. For MultiTerm, I remember I had to perform an explicit gtk_widget_set_size_request(wid, N, N) where N was any arbitrary size smaller than expected (I think I chose 100 or 10 or something). Also, I'm not positive, but the VTE widget might also need to be placed in a GtkFrame or similar, and then into an GtkHBox with a GtkVScrollbar (using the VTE's adjustment) next to the VTE into the GtkHBox. I probably just copied how Geany did it, I don't remember for sure, but it works anyway. I could be completely wrong on the cause of the bug, I just wanted to mention since I remember fighting VTE for same issue. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Geany using standard types
On 13-08-19 10:33 AM, Dimitar Zhekov wrote: On Sun, 18 Aug 2013 03:56:01 -0700 Matthew Brush mbr...@codebrainz.ca wrote: My concern here with stdint.h was that if CHAR_BIT 8 then C99 forbids an implementation from defining int8_t and if int8_t isn't defined then uint8_t can't be defined. And if this is true [citation needed], and you couldn't rely on (u)int8_t, then might as well just stick to portable GLib typedefs. In POSIX and Windows, CHAR_BIT is always 8, and we don't really support anything else. CHAR_BIT may be 8 if the system can not address 8-bit values, but in that case, no 8-bit integer type will exist, and GLib will be unable to define a gint8 either. Which is not a problem, since GLib (as of 2.37) supports only G_OS_BEOS, G_OS_UNIX and G_OS_WIN32... Thanks for the info, good to know! I'm still +1 for using the standard types over the weird G* types, but I'll stop annoying everyone about it if others like them (for reasons I didn't understand). Maybe I'll ask again about it maybe once we're ready to switch to C11 in a decade or so :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [PATCH] Add GLib version chechk around g_thread_init() call
On 13-04-25 01:23 AM, n@sk0 wrote: Hi, my name is Atanas Beloborodov, developer from Bulgaria [small country on east europe :)] and i use Geany for my everyday work, so i decide to help with development as i can. Here is a small patch for main.c, that checks for GLib version and avoid call of g_thread_init() if GLlib version 2.32 since this function is deprecated in GLib 2.32 Hello and welcome, I applied the patch in commit `a3da046` with purely aesthetic changes. Thanks, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Don't pop-up messages/steal focus when in terminal
On 13-04-20 09:52 AM, Nick Treleaven wrote: On 20/04/2013 16:06, Matthew Brush wrote: On 13-04-20 05:59 AM, Harold Aling wrote: On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman ele...@gmail.com wrote: Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20. I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany? It is rumored that some percentage (remember 0 is a percent :) of users are apparently stuck on ancient enterprise distros at work, need to use the latest bleeding edge Geany at all times, and are able install it but not GTK+ from source into $HOME. Or so the story goes :) I imagine building newer GTK/GLib from source with only old dependencies would be a pain in the arse, having to grab and build all the newer dependencies too. It's also a pain for most users to install and manage multiple versions of libraries. Geany is actually very easy to build as it only requires Gtk/GLib. It is a pain, but I'm more skeptical about what percentage of users are in this situation. Just thinking about the specific criteria you'd have to meet to be in this minority of users: * Running old but still supported enterprise distro * No ability/access to install a separate system GTK+ * Aren't satisfied with the Geany in the repos * Need to run the absolute latest Geany from release or Git * Aren't willing to compile/install GTK+ stack into $HOME but are for Geany, but not for most other popular GTK+ software which requires newer GTK+. Or, in the case of Windows: * Need to run absolute latest Geany from release or Git * Required to have a specific old system-wide GTK+ * Unable to install a newer GTK+ specifically for Geany or * Unwilling to used the bundled GTK+ that comes with Geany * Not using lots of other GTK+ software that requires newer GTK+ So for some possibly insignificant number of Geany users (possibly even approaching 0 users), who still technically have a path to use latest Geany, albeit with some hassle (building GTK stack), we (contributors/developers) have to: * Quadruple check every GTK+ function we call, referring to out of date documentation in some cases, to ensure we don't use API from the last 4 years or * Ensure all new code using API from the last 4 years is #if'd-out so that they work with both latest and ancient GTK+. * Maintain more stuff in the gtkcompat.h header to fake out a bunch of core and plugin code so we can also build against latest GTK+. * Have a separate old GTK+ on our dev. machines besides modern ones to test all changes against (although I don't do this personally). IMO, the benefits to current and potential contributors and users of updating to a relatively modern min. GTK+ 2 version outweighs the negatives to some unknown small percentage of users. Even Puppy Linux has had GTK+ 2.24 for the last two releases[1]. /rant Cheers, Matthew Brush [1] http://distrowatch.com/table.php?distribution=puppy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Don't pop-up messages/steal focus when in terminal
On 13-04-20 04:20 PM, Lex Trotman wrote: My experience based on my consulting customers is that they run old versions or Red Hat mostly, with only security updates added. Even point releases are viewed with suspicion, that is likely to mean they have to hire me to re-compile their crusty old business apps to new libraries since their own devs don't understand them. :) On 21 April 2013 05:13, Matthew Brush mbr...@codebrainz.ca wrote: On 13-04-20 09:52 AM, Nick Treleaven wrote: On 20/04/2013 16:06, Matthew Brush wrote: On 13-04-20 05:59 AM, Harold Aling wrote: On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman ele...@gmail.com wrote: Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20. I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany? Yes It is rumored that some percentage (remember 0 is a percent :) of users are apparently stuck on ancient enterprise distros at work, need to use the latest bleeding edge Geany at all times, and are able install it but not GTK+ from source into $HOME. Or so the story goes :) Nobody knows how, let alone is allowed, to modify such fundamental software, even in their own home dir. IIUC on Unix-ey systems, your home directory is completely writable by you and using the environment you can compile, install and run any software you want. I'm no sys-admin though. I imagine building newer GTK/GLib from source with only old dependencies would be a pain in the arse, having to grab and build all the newer dependencies too. It's also a pain for most users to install and manage multiple versions of libraries. Geany is actually very easy to build as it only requires Gtk/GLib. It is a pain, but I'm more skeptical about what percentage of users are in this situation. Just thinking about the specific criteria you'd have to meet to be in this minority of users: * Running old but still supported enterprise distro tick Tick what? Let me get this straight... you are running an old but still supported enterprise distro... * No ability/access to install a separate system GTK+ tick, tick And you don't have root/admin rights... * Aren't satisfied with the Geany in the repos 0.18 or older, no way, tick And you can't run any release of Geany from 0.00 to present that uses GTK+ some proposed newer version... * Need to run the absolute latest Geany from release or Git Release yes, tick And arbitrarily need to run bleeding edge Geany... * Aren't willing to compile/install GTK+ stack into $HOME but are for Geany, but not for most other popular GTK+ software which requires newer GTK+. You already said that, tick again And aren't able to compile a series of dependencies that takes maybe an afternoon for the first time... [...] * Not using lots of other GTK+ software that requires newer GTK+ Whats a GTK? That library that the GIMP and Pidgin and many other more popular programs use which you'd have to install a newer GTK+ library to use. For windows there is less of a problem since we, and every other app, supply a bundle including GTK. So the windows release can go to 2.24 (the new recommended release) without too much pain. So for some possibly insignificant number of Geany users (possibly even approaching 0 users), who still technically have a path to use latest Geany, albeit with some hassle (building GTK stack), we (contributors/developers) have to: The path of building GTK does not exist in corporate, it is not allowed, and web app designers don't know how to do it. If you can't build GTK+ in $HOME it's unlikely you can build Geany there. And why, if you're a web-app designer do you need to install the absolute latest Geany release, heck, you're probably running OSX if you are one, and IIRC macports and friends stay pretty current on GTK+ versions. * Quadruple check every GTK+ function we call, referring to out of date documentation in some cases, to ensure we don't use API from the last 4 years or tick Tick what? It's a PITA, some old API functions don't even have a since version. * Ensure all new code using API from the last 4 years is #if'd-out so that they work with both latest and ancient GTK+. tick Tick what? It's a huge pain to write stuff twice, once for ancient GTK+ and once for regular GTK+. * Maintain more stuff in the gtkcompat.h header to fake out a bunch of core and plugin code so we can also build against latest GTK+. tick Tick what? It's already caused troubles and is only a band-aid for the inevitable. * Have a separate old GTK+ on our dev. machines besides modern ones to test all changes against (although I don't do this personally). no, but the nightly does for us, Which makes Enrico
Re: [Geany-Devel] Don't pop-up messages/steal focus when in terminal
On 13-04-20 05:48 PM, Lex Trotman wrote: [...] I definitively agree that there's someone/a few people out there, in this strange self-imposed situation that are mentioned above, but I'd bet good money it's a such a small minority of Geany's users, possibly even less than 1%, to be worth bending over backwards for. The real problem is none of us knows how many actual users there are in any particular system configuration. I am only going on my experience, which as a contractor at least includes a spread of companies. In the past its always been me introducing Geany, but recently I have been pleasantly surprised to find a few customers already using it on Red Hat. Hence my concern to keep support for at least the Red Hat version that is still in primary support. But if they're your customers, given your deep familiarity with Geany's source and your likely influence on installed versions of it, could you not backport critical fixes and improvements of which there are very few or run a release closer to the year in which their corporate OS vendor offers support up to for other packages? Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Don't pop-up messages/steal focus when in terminal
On 13-04-20 06:12 PM, Matthew Brush wrote: On 13-04-20 06:02 PM, Lex Trotman wrote: On 21 April 2013 10:56, Matthew Brush mbr...@codebrainz.ca wrote: On 13-04-20 05:48 PM, Lex Trotman wrote: [...] I definitively agree that there's someone/a few people out there, in this strange self-imposed situation that are mentioned above, but I'd bet good money it's a such a small minority of Geany's users, possibly even less than 1%, to be worth bending over backwards for. The real problem is none of us knows how many actual users there are in any particular system configuration. I am only going on my experience, which as a contractor at least includes a spread of companies. In the past its always been me introducing Geany, but recently I have been pleasantly surprised to find a few customers already using it on Red Hat. Hence my concern to keep support for at least the Red Hat version that is still in primary support. But if they're your customers, given your deep familiarity with Geany's source and your likely influence on installed versions of it, could you not backport critical fixes and improvements of which there are very few or run a release closer to the year in which their corporate OS vendor offers support up to for other packages? Well as I said, some have already installed it before I came along, that means that there are more that have Geany and are not my customers. They are the ones I'm talking about supporting. But really, they have Geany latest, can't install new software, have a really old GTK+ version, need features from bleeding edge Geany and can't get you to update them from source or do it themselves? This sounds like either a completely fictitious or insignificant group of users to me. If they can't make due with older Geany versions, can't update their GTK+ environment, but *can* install Geany from sources, I'd say they're either schizophrenic, lazy, liars or in the 0.001% of total users. In all cases, IMO, they aren't worth serving for free on my buck. Just to be clear, I'm fine with hacking on behalf of the other 99.9..% of users for free on my buck, I just hate wasting hack-time for pointless historical nonsense that affects 0.0n% of legacy users. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Don't pop-up messages/steal focus when in terminal
On 13-04-18 05:16 AM, Thomas Martitz wrote: Am 17.04.2013 16:49, schrieb Steven Blatnick: I've always thought the dialogs should be embedded anyway, which doesn't steal focus. What I mean is like gedit does, where at the top of the document a box appears before line 1 and says This file has been modified. Then, people wouldn't have to press it until they wanted to since it would be associated with the document directly. Thanks, You will find many people on this list that agree with you (including me). We've had proposals and even a prototype implementation (IIRC) for this but nothing ended up in Geany mainline. But your use case is a strong argument in favor of this. I too find the popup highly annoying. If anyone wants to pick up where I left off and run the bikeshed gauntlet, the branch is still in the Geany repo (document-messages). It should be trivial to update it with the master branch. You'll probably want to check the mailing list archives for reference of what the issues were. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] I'm thinking I like Geany...
On 13-03-08 09:51 PM, Steven Blatnick wrote: Thrawn, Guess what I've been working on :-) I've got a nearly complete plugin I call quick-opener written in C. I hope you like it. I'm not terribly knowledgeable at build files, so if anyone wants to help me figure out how to add it to the autogen.sh and make process for geany-plugins, that would be great. Let me know what I have to do. Here is the code: https://github.com/sblatnick/geany-plugins/tree/9ce0a19b39e90ae107621606aa37ffa8cc8dec44/quick-opener Can you explain what it does? It kind of sounds like one of the things the Commander plugin does, but I can't tell having not tested it yet. Looking back as far as Thunderbird takes me on this thread, it's not clear on the term Snap Open that the OP used. The make script just does the minimum to get it working. You run it with ./make (it's a bash script). Having looked briefly at your coding skills, I can assure you that it's fully within your grasp to understand how proper GNU Make files go, it's just a little weird at first. I don't mean to say you should understand the full Geany-Plugins build system(s), but I mean in general you shouldn't have any problem writing a basic Make file. For example: quick-opener.so: quick-opener.o $(CC) -o $@ $^ `pkg-config --libs geany` quick-opener.o: quick-opener.c $(CC) -c -fPIC `pkg-config --cflags geany` -o $@ $ install: cp quick-opener.so ~/.config/geany/plugins/ clean: rm -f *.o *.so Not that it matters, I just say for your own interest because I remember writing such a shell script as you have made before, not realizing how simple a basic Make file could be. When I say nearly complete, I mean that you can't configure the plugin yet with directories/files to exclude. It already excludes hidden directories, certain binary extensions, and starts at the project's working directory. I haven't made a pull request yet because I don't have the packaging stuff done (documentation, build stuff I need help with). Come ask on IRC or here on devel-list with questions. If you can write reasonable C code, then the rest is just crusty old m4 nonsense. I think everyone has problems groking Autotools and/or Waf, at least at first. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [geany/geany-plugins] 4cc119: Scope: Fix mismatched allocator/deallocator
On 13-03-07 11:06 AM, Dimitar Zhekov wrote:
On Mon, 04 Mar 2013 22:30:40 -
Colomban Wendling git-nore...@geany.org wrote:
Log Message:
---
Scope: Fix mismatched allocator/deallocator
These are not mismatched, I'm using strdup() instead of strdup() for
strings that must never be NULL. Unless we have a policy to always
use g_strdup(), or there is a real g_/strdup vs. g_/free mismatch
somewhere, I'm going to revert them.
I don't see any mismatch either but strdup() is not in C standard (at
least C89/99) but rather POSIX or some other one AFAIK.
If you really don't like the g_strdup() behaviour, you could always
write something like:
char* scope_strdup(const char *s)
{
char *n;
size_t len;
if (s == NULL)
g_error(NULL string passed to scope_strdup());
len = strlen(s) + 1;
n = malloc(len);
memcpy(n, s, len);
return n;
}
Then at least there's some hint of what went wrong rather than just
bringing down the entire program with a mysterious segfault (assuming
the above code I didn't test doesn't do that itself :).
Personally I prefer offensive programming: if something goes wrong, let
it crash and burn, get a proper backtrace and fix it.
Note to self: don't use Scope plugin until all files are saved :)
Cheers,
Matthew Brush
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] codesubmit plugin
On 13-02-28 01:12 PM, Mayank Jha wrote: thanx a lot for ur feedback. I could not get a few things clearly: 1. Is this readme not OK? https://github.com/mjnovice/geany-plugins/blob/master/codesubmit/README You need to compile it with doc-utils/rst2html to be sure. Also you should copy other plugins to know what is commonly put in there. 2. #include config.h (check other plugins for it if needed) couldn't get what do we need to do here? If you have the plugin inside Geany-Plugins source tree, it shouldn't be a problem. As above, best is to copy other plugins to see how they do it. 3. Do I need to provide a separate text file which contains the licensing, won't the comment in the codesubmit.c do the job? You probably should, since other plugins do (see the pattern? :). 4. Provide a proper patch against geany-plugins including all files how to do this? Basically the exact opposite of your last pull request :) It means that your pull request should meet all of the criteria mentioned in your last pull request's comments, the mailing list responses, the HACKING file and those that are implied from fitting in with other plugins. The Pull Request should contain a complete integration of your plugin, including all required files, no unnecessary files, updates to both build systems to make it compile, and no obvious bugs, crashers, leaks, hardcoded paths, embedded Python source code, improper indentation, etc. If you make commit messages like blah blah again, I can almost guarantee your pull request will get closed immediately :) Here are some pretty good examples of integrating a new plugin: https://github.com/geany/geany-plugins/commit/6c93e9513935820e7919e24722d622506e183b8a https://github.com/kugel-/geany-plugins/commit/8eb52e74d399736152030d5b9ef0ef3ab292c681 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] codesubmit plugin
On 13-02-26 03:43 PM, Lex Trotman wrote: On 27 February 2013 10:26, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 27.02.2013 00:08, schrieb Mayank Jha: To all esteemed developers Frank Lanitz, Matthew Brush. Kindly review my code which i have modified according to your suggestions. Shall we guess what your plugin does? Regarding the embedded python script. I don't think you actually need to write it out to a file, you should be able to pass it to the interpreter from memory (see [1]). Yep, much better way to do it, but for reasons mentioned below. Plugins should not embed Python since it can only be done once, if two plugins both do it it fails. There have already been problems with trying to use two plugins which both embed python. On the basis that the only likely solution is having a shared Python, nobody should embed Python in their plugins until Geanypy is sorted. +1 What's the status of the python plugin? ping codebrainz :) Except for needed work on sharing keybindings between the Python plugins, it's pretty stable in my experience. Only big thing is to get it integrated into the GP build systems (and as usual API docs[1] are incomplete). rant I still really wish I could keep the code synced in it's own repo on Github, but due to restrictions on Git submodules in GP and the proprietary build system, it seems like I'll have to stop being able to provide stand-alone distribution (and way better Github Issue tracker and such). Suggestions would be very welcome if there's a way I could do this without double-maintaining repos, I'm neither a Git nor Autotools expert. /rant Cheers, Matthew Brush [1] https://geanypy.readthedocs.org ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [was: Geany-Pluigns: Feature freeze]
On 13-02-21 09:35 AM, Dimitar Zhekov wrote: On Sun, 17 Feb 2013 13:22:08 Frank Lanitz fr...@frank.uvena.de wrote: We are currently planning a new release for Geany as well as for Geany-Plugins. How about sf bug tracker ID 3522755 then? The order is still wrong, and I altered the fix as suggested by Colomban several months ago. https://sourceforge.net/tracker/?func=detailaid=3522755group_id=153444atid=787791 In case anyone hates SF.net search/filter UI as much as me :) Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Feature: editor tab width
On 13-02-14 10:10 PM, Steven Blatnick wrote: I didn't see an easy way of separating the pull requests after the fact. It didn't occur to me to separate the changes into branches without pulling into master until upstream did, so sorry about that. I should have based the changes on separate branches both from geany's original master rather than all of my updates being pulled into master. You can just make the appropriate branches and then cherry-pick the good commits into them. Another way is to format-patches and apply them onto your new branches. A couple more general things: Don't merge master into your pull request branch unless you have a good reason, it just makes a bunch of useless noise and those merge commits would end up in Geany's official history or the committer has to strip them out. Also, whenever adding settings and keybindings you should update the manual (geany.txt) to reflect the new/changed stuff. As a side note, I've noticed that the keyboard shortcut to focus the bottom pane/panel doesn't work correctly. I have to essentially focus something specifically (like Compiler/Messages/VTE) and then Ctrl+Pg_Up/Ctrl+Pg_Down on them. IMO, it'd be nice to make Geany not steal 'CtrlTab' when focus is not in the documents, then you could use the Switch to Message Window keybinding to focus the message window area and use the standard 'CtrlTab' to rotate between the tab pages down there. That being said, I didn't look into why Geany overrides 'CtrlTab' everywhere in the UI, maybe there's a reason I don't see. Just my 2¢ Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] [geany-plugins] [Debugger] Windows port for geany's debugger plugin
On 13-02-06 02:31 PM, vadim kochan wrote: Hi, Can someone please take a look at this? https://github.com/geany/geany-plugins/pull/83 Hi, I looked when it was submitted, didn't see any commit message details, 10 files and 900+ lines changed, Windows-specific, Win32 API-using and that it's not one of the plugins I maintain, and ran away screaming like a little girl :) Did you get in touch with Alexander Petukhov (cesspit) the plugin maintainer at all? He's probably gonna be your best bet for getting these changes in (or at least find out if he's inclined/has time to review/test/merge and/or minds if someone else does). Until word from him, probably nobody is going to get too involved, especially with whispers of a new release coming in the quite near future. From a quick glance at the pull request (not code review): - Needs more commit message details (lots more) - Maybe it would be better as a few smaller commits, maybe - What replaces the guarded-out VTE/pty/etc code on Windows? - Why another build system instead of Waf and/or Autotools? * I don't think other plugins does this and it misses one of the benefits of Geany-Plugins project (shared build/release infrastructure). Better would probably be to making it build with Waf on Windows so that it gets released/distrubuted on Windows platform. - Why? * https://github.com/vkochan/geany-plugins/commit/fda45f31d11fcc73ddefc06ca3e2d38eace5d802#L6R41 * https://github.com/vkochan/geany-plugins/commit/fda45f31d11fcc73ddefc06ca3e2d38eace5d802#L5L474 * https://github.com/vkochan/geany-plugins/commit/fda45f31d11fcc73ddefc06ca3e2d38eace5d802#L1R45 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] GTK 2.16 build error in Markdown plugin
On 13-01-31 10:09 AM, Enrico Tröger wrote: Hey Matthew, the Markdown plugin currently does not compile on GTK 2.16, more specific with GLib 2.26. See http://nightly.geany.org/misc/build_gtk216_plugins_stderr.log for details. One issue is that uint (conf.c:245) is not defined. I guess this is just a typo and should be guint. I just don't understand why this works on other systems, like the nightly build environment for ArchLinux. Anyway, changing it to guint is probably good enough. Not sure exactly where it comes from, but I did mean guint :) Fixed. Though there is another issue: g_object_class_install_properties is first available in GLib 2.26 (used in conf.c:372). So maybe this plugin needs a higher GLib requirement. I made a little wrapper function that uses that function on new versions and some alternate code if not. It should be OK now I think, although I don't have GLIB 2.26 to be 100% sure. Let me know if it causes any more issues. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] GTK 2.16 build error in Markdown plugin
On 13-01-31 10:17 AM, Colomban Wendling wrote: Le 31/01/2013 19:09, Enrico Tröger a écrit : Hey Matthew, the Markdown plugin currently does not compile on GTK 2.16, more specific with GLib 2.26. See http://nightly.geany.org/misc/build_gtk216_plugins_stderr.log for details. One issue is that uint (conf.c:245) is not defined. I guess this is just a typo and should be guint. I just don't understand why this works on other systems, like the nightly build environment for ArchLinux. Anyway, changing it to guint is probably good enough. I guess the newer GTK include a system header that defines the uint type or something like this. Also Matthew, markdown_config_get_uint_key() have a default_value argument (the one with type uint), but the default used is hard-coded as 12, it doesn't look so legitimate ;) Hehehe. I think that was a copy and paste error from a function that returned a default font size of 12pt for config file key, in case you were curious :) Fixed. Though there is another issue: g_object_class_install_properties is first available in GLib 2.26 (used in conf.c:372). So maybe this plugin needs a higher GLib requirement. Or simply not use this function, or emulate it. I think it's easy enough not to use the cheap and mean solution of higher dep for this. Agreed. I made a little wrapper function to do it. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Python filetype 2 or 3 or both?
On 13-01-22 09:17 PM, Lex Trotman wrote: Hi All, We have only one Python filetype, but Python has two versions. There are some differences between them in terms of keywords and builtins. For example exec, nonlocal, True, False and None are not keywords for Python 2 but are for 3. And print is a keyword for 2 but not for 3. There are similar changes to the builtins. At the moment True, False and None are in the keyword list but exec and nonlocal are not. There is a PR to remove True, False and None. Since Python 3 is gaining ground I suggest that it would be better to have an aggregate of both Pythons for both keywords and builtins. Whilst that is wrong for both, I think missing keywords is worse than extras. +1 What do other Python users think? My 2¢ as a themer and Python user is that True, False, None, and nonlocal should be in 'primary' keywords list and 'print' and 'exec' should go should into 'identifiers' keywords list (with other built-in functions). Even if it's Py3 way, it works fine for Py2 as well. I made a little script to automate this merging of the keyword lists, if we want to use it I could update the keywords lists in 'filetypes.python', and possibly put the script in the 'scripts' directory in the source tree for future use. Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] GEANY - New behaviour of close document action to close only tabs
On 13-01-22 12:15 AM, Thomas Young wrote: (As an aside, for myself, I'm managed to hack something up that uses libClang to lookup references, that doesn't need know about the whole set of project files in order to work. It actually just executes the corresponding compile command within libClang each time you click 'lookup reference', and so fits in quite nicely with the 'no list of files in project' paradigm..) Sure, if you only want to lookup references in the same translation unit or any included header files that happen to be in the search path, but to really make full use, LibClang essentially needs a project to support it (include paths, defines, other translation units/files, etc). Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Accessing argv from plugins
Hi, I want to write a plugin that requires some command line options passed to it (through geany). Is there a way to make it so Geany will accept arbitrary arguments and then I can pick them out of /proc/PID/cmdline or something[1]? I tried but Geany currently errors out if it sees an option it does not recognize itself. Assuming this is not possible currently, is there any sane way to pass arguments to plugins, maybe something like how you can pass `-Wl` to GCC to pass-through linker args or `-X` to valac to pass-through compiler args? Cheers, Matthew Brush [1] I'm not opposed to hacks or Linux-specific workarounds. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
