Re: [Geany-devel] Separating session file lists from config (again)
On 12-10-01 07:43 AM, Colomban Wendling wrote: Le 10/09/2012 06:36, Lex Trotman a écrit : Hi All, Its about that time of year when we have our annual discussion on separating session data from config/project data :) By session data I mean the list of currently open files and MRU list. The advantages (that I can see): 1. Save config/project as its changed and not rushed at quit time (and the quit save doesn't happen in the absence of a working, portable, session management capability) TBH until proper multi-instance configuration sharing, I don't see what's so great with not rushing at quit time since we already also save one pref/project-prefs apply. Open your favourite project in Geany and open a specific set of files you need to work on a task, get the order of the files just right, adjust the Geany window position and size and then get your find dialogs positioned just perfect on your second screen. Now unplug your computer. You will see :) For me it takes more time to get Geany back in order (finding project file since it's not saved in the recent project list[1], finding open files related to current task, since they aren't saved in recent files list[2], etc.) than it does to restart the whole computer. P.S. My workaround (because my computer crashes a lot due to Flash) is to get everything set up how I want for the current task, and then to close Geany normally to force saving of all settings and then to reopen it :) Cheers, Matthew Brush [1] Well for favourite projects it might be saved, but not if it's a new project that hasn't experienced a closing before. [2] Unless you count the lame GTK+ open dialog recent files list which is quite useless. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
On 12-10-01 03:05 PM, Colomban Wendling wrote: Le 01/10/2012 23:15, Matthew Brush a écrit : On 12-10-01 07:43 AM, Colomban Wendling wrote: Le 10/09/2012 06:36, Lex Trotman a écrit : Hi All, Its about that time of year when we have our annual discussion on separating session data from config/project data :) By session data I mean the list of currently open files and MRU list. The advantages (that I can see): 1. Save config/project as its changed and not rushed at quit time (and the quit save doesn't happen in the absence of a working, portable, session management capability) TBH until proper multi-instance configuration sharing, I don't see what's so great with not rushing at quit time since we already also save one pref/project-prefs apply. Open your favourite project in Geany and open a specific set of files you need to work on a task, get the order of the files just right, adjust the Geany window position and size and then get your find dialogs positioned just perfect on your second screen. Now unplug your computer. You will see :) For me it takes more time to get Geany back in order (finding project file since it's not saved in the recent project list[1], finding open files related to current task, since they aren't saved in recent files list[2], etc.) than it does to restart the whole computer. P.S. My workaround (because my computer crashes a lot due to Flash) is to get everything set up how I want for the current task, and then to close Geany normally to force saving of all settings and then to reopen it :) As I read Lex's sentence, he spoke about settings, not open files. And anyway, I don't see what separating file list from the rest of the config change in that matter. It doesn't magically brings immediate/periodical saving of the file list, and we can very well save everything *including the file list* without that. So I don't see why it's an argument in favor (or against) $subject. It's an argument in favour of not rushing at quite time (ie. periodically saving the .conf file(s) instead of only on closing) since you said you didn't see what was so great about it. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Bug tracker: using group for the version closing the bug
On 12-09-17 03:07 PM, Colomban Wendling wrote: Hi guys, As you might already have noticed, I added a few groups to our tracker reflecting the Geany versions, and I'm proposing to use those to track the version in which the bug was/will be fixed. I hope this will help us to know which bugs we fixed in the current version (to help updating NEWS), and users to know in which version their bug is fixed. So, when you fix a bug, it'd be great if you could also set the group field accordingly. Or do you think it's a stupid idea? Sounds good to me. Anything that makes using the trackers (and updating NEWS) easier :) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Signal Handling
On 12-09-10 10:15 AM, Dimitar Zhekov wrote: On Sun, 09 Sep 2012 19:41:19 -0700 Matthew Brush mbr...@codebrainz.ca wrote: On 12-09-09 05:23 PM, Lex Trotman wrote: [...] just that it's why my *tests* included it. Emphasis added Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Signal Handling
On 12-09-09 05:23 PM, Lex Trotman wrote: [...] So can anyone describe a useful use-case for catching SIGTERM and potentially refusing to exit? And also for SIGINT. For SIGINT, if it's handled, it'll ask if you want to save unsaved documents before closing when Ctrl+C is used from the terminal. Not saying whether we should handle it or not, just that it's why my tests included it. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Separating session file lists from config (again)
On 12-09-09 09:36 PM, Lex Trotman wrote: Hi All, Its about that time of year when we have our annual discussion on separating session data from config/project data :) By session data I mean the list of currently open files and MRU list. I guess it could support some other stuff too like window/find dialogs geometry/position, active tab, position within the file, etc. [...] The number of session files can be left to grow like weeds, or can be trimmed to a (configurable) maximum number deleting the oldest when needed. Could add a Tools-Purge Session files or something if they're left to grow like weeds. This proposal isn't about a proper session management capability, there isn't one that works on enough platforms to be worth including. Any thoughts welcome. Generally I think it's a good idea, would be interested in testing some implementation(s). Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] SourceForge Upgrade?
Hi, Is good yeah? https://sourceforge.net/p/upgrade?search=geany @Colomban, it's the one you mentioned was in Beta before? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Squiggle pixmap
On 12-09-04 09:47 PM, Lex Trotman wrote: Hi All, Colomban has now kindly imported the latest Scintilla into HEAD. It includes Matthews alternative squiggle indicator. This improves the performance when a significant amount of squiggly underlining is present (think C++ compiles, when spell check doesn't like your words etc). I was going to make an option to select which indicator to use, but after some thought I believe its better to simply switch to always using the alternative because: 1. at least on Linux it looks as good as the original, this needs to be checked on other platforms It should be fine since it's using Cairo on all platforms anyway. 2. reduces the incidence of performance complaints due to this problem, so we don't have grumpy users in the first place, and don't have to guide them through editing the setting where ever it is located (filetypes.common probably with all the marker settings) Note that as this should not be a commonly used setting, there is no need for a GUI setting, or if it turns out to be common, that just supports my argument to use it all the time. I agree it's not worthwhile to make it a setting. The only difference as far as users is concerned is that it's just faster now. If no one has any substantive issues in the meantime I'll commit the attached patch in a couple of weeks. +1 Only thing I'd change is to add a comment explaining why it was switched from INDIC_SQUIGGLE to the faster one. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Ship with Grep on Windows?
On 12-09-03 12:57 AM, Matthew Brush wrote: Hi, It would be useful to ship the Grep binary[1] (and dependencies) with Geany for Windows. It could be added to the installer for not too much extra size[2] and would enable the Find in Files feature to work on Windows by default. Normally I wouldn't like to add more stuff to the installer but I think without it Geany is missing a very useful feature on Windows by default. Does it sound reasonable or no? Cheers, Matthew Brush [1] Probably this one? http://gnuwin32.sourceforge.net/packages/grep.htm [2] Based on above link maybe around 1-2 MB if its dependencies aren't already shipped with Geany (ex. libiconv, pcre, etc.). Just following up on myself. It seems Geany+GTK doesn't ship with iconv or PCRE, so maybe GLIB uses Windows equivalent of iconv and PCRE is compiled in statically? Just a guess. I compiled grep myself inside MSYS with this[1]: $ CFLAGS=-Os LDFLAGS=-static ./configure --enable-threads=windows --disable-nls --disable-perl-regexp --disable-rpath It creates a grep.exe that is 1.53 MB and it doesn't seem to have any DLL dependencies except for normal stuff. Using objdump and grep (since I don't have ldd on Windows), these are the DLLs it lists: DLL Name: KERNEL32.dll DLL Name: msvcrt.dll Cheers, Matthew Brush [1] Not sure if these are good options, but it's what I used. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Windows Build commands
On 12-08-27 02:38 PM, Lex Trotman wrote: Hi Enrico or some other Windows dev, Had a report on IRC from a new Windows Geany user that when they installed Geany the C compile command was gcc -m32 “%f” -o “%e.exe” which didn't work, but when they pressed the reset in the build commands dialog the command changed to the normal gcc -Wall -o %e %f which worked. Is the build command being deliberately changed on windows builds or is it something picked up from the build environment accidently? And if it is deliberate, it doesn't seem to work? On Windows 7 it's the normal command from filetypes.c or whatever, but I'm using built from Git, maybe release installer is different. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] patch: bug #3451427 - Geany align to right in Hebrew system and reversed brackets
On 12-08-12 01:30 PM, יוסף אור בוצ'קו wrote: Hi, This patch fixes bug #3451427, by making sure that the ScintillaObject is in LTR mode even when Geany's language is RTL. (See screenshot in bug report) Fix bug 3451427: http://sourceforge.net/tracker/index.php?func=detailaid=3451427group_id=153444atid=787791 Hi, Applied in: https://github.com/geany/geany/commit/e1a1c54d784c3285b536f1608bb98e1355094644 Thanks, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On 12-08-05 04:47 AM, Frank Lanitz wrote: On Sun, 5 Aug 2012 10:21:04 +1000 Lex Trotman ele...@gmail.com wrote: On 5 August 2012 03:40, Matthew Brush mbr...@codebrainz.ca wrote: On 12-08-04 09:41 AM, Colomban Wendling wrote: [...] So... maybe I got your point wrong, but I don't think it's any kind of a problem to have different dependencies from one plugin to another -- actually, I think each plugin should set it dependencies to exactly what it needs: nothing less (of course), and nothing more. You got it mostly. I just mean some way for the build system to handle multiple plugins sharing same dependencies like having webkit.m4 that enables/disables multiple plugins if not found. So when you configure, it says something like this: checking for WebKit = x.xx ... no Disabling plugins: WebHelper, Devhelp, Markdown I don't see this, the *plugin* should define what it needs, not some arbitrary external build script. My (limited) understanding of the plugin autofoo is that is how its done now by having local build scripts in each plugin. Yeah, and currently the plugins each check for the same shared dependencies, but it doesn't show what they're checking for, it just shows the plugin's name, like: checking for DEVHELP ... no What I'm asking about is to have a webkit.m4 (for example) or something that the plugins which use that dependency can make use of and so the check is only done once and if not found, it ouputs as I said previously. Of course I don't know if it's realistic/feasible, which is why I was asking. If they require different versions that might mean you get Webhelper and Devhelp but not Markdown, but your scheme won't allow that. So if the Markdown dev added some new feature that needed a higher version I can't build the other two unless I upgrade my system :( I mean they should require the same version, the same *lowest* version they can work with (even if they need some minor changes to make it possible). We should not be forcing the *highest* version needed by plugins. Not what I meant. But it's sort of what we do now if you consider building geany-plugins as a whole. I agree. But I also see the point of consolidation of dependencies. Its getting really complicated to say geany-plugins needs this dependencies, but I think its an issue we need to solve on social level, not trying to solve it with some hack. Is there any chance to get a complete list which plugins depend on which library out of autotools? What I was asking about wouldn't be a hack, it would just be to change the plugins a bit so they depend on the same version of shared libraries, and then to have Autotools do a check for the shared dependency. For a list of the dependencies, you can look through the `build` directory's .m4 files and manually extract them (like I did for some of the shared ones previously). The ones with the highest versions will be the minimum version required to build geany-plugins (as a whole). Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On 12-08-05 07:57 AM, Frank Lanitz wrote: On Sun, 5 Aug 2012 16:55:07 +0200 Frank Lanitz fr...@frank.uvena.de wrote: For a list of the dependencies, you can look through the `build` directory's .m4 files and manually extract them (like I did for some of the shared ones previously). The ones with the highest versions will be the minimum version required to build geany-plugins (as a whole). Maybe building a script doing this would be a good idea. Having checked a couple of them I found it will be hard as they differ in way defining the dependencies... Yep and most don't specify their shared dependencies (GTK, GLIB, etc.) explicitly but assume that if you have the Geany, you have what they need. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins Dependency Consolidation
On 12-08-04 09:41 AM, Colomban Wendling wrote: [...] So... maybe I got your point wrong, but I don't think it's any kind of a problem to have different dependencies from one plugin to another -- actually, I think each plugin should set it dependencies to exactly what it needs: nothing less (of course), and nothing more. You got it mostly. I just mean some way for the build system to handle multiple plugins sharing same dependencies like having webkit.m4 that enables/disables multiple plugins if not found. So when you configure, it says something like this: checking for WebKit = x.xx ... no Disabling plugins: WebHelper, Devhelp, Markdown checking for LibVTE = x.xx ... no Disabling plugins: Debugger, MultiTerm Instead of: checking for WEBHELPER ... no checking for DEVHELP ... yes checking for MARKDOWN ... no checking for DEBUGGER ... no checking for MULTITERM ... yes Plugins: WebHelper no Devhelp yes Markdownno Debuggerno MultiTerm yes Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] patch: separated session/local config
On 12-08-03 05:58 PM, Lex Trotman wrote: I thought the Git branch was Eugenes and he already said it could be removed?? See below. If my memory is right, then removing it and applying the patch to a new_sm branch would be the way to go. I pushed the libsm patch from the patch tracker to a new Git branch[1] a couple weeks ago or so, expecting to be getting emails from sf.net when the patch tracker was updated to queue me to apply the latest patch to the Git branch. IMO, it makes more sense to maintain it as a branch (or merging into the master branch) in the Git repository, even thought the patch tracker item is meticulously well documented/commented/updated. If Dimitar doesn't mind working on the Git repo instead of keeping a sf.net patch tracker item up to date, I'd be +1 for that. Cheers, Matthew Brush [1] https://github.com/geany/geany/commit/0f07b31aa866f92dcbaf29659ead7beab60a1dde ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Geany-Plugins Dependency Consolidation
Hi, Since some plugins share dependencies, is there some way to coordinate both the versions of the dependencies and the build system? For example if Debugger and MultiTerm both depend on LibVTE, to make sure they use compatible API versions and depend on the same version. I'm thinking it's not great to require LibFoo v0.01 for one plugin and LibFoo v0.02 for another, even if they (can) use common API (and probably do already). I guess it's more of a build system question, is it realistic? Common/interesting dependencies based on a quick scan of the `build` directory: * GdkPixbuf - WebHelper - v2.0 * GTK+ - Devhelp - v2.16 - GenDoc - v2.12 - MultiTerm - version unspecified - WebHelper - v2.16 * GLIB - GenDoc - v2.14 - WebHelper - v2.16 * GIO - GenDoc - v2.18 - TreeBrowser - version unspecified - WebHelper - v2.18 * GModule - GeanyLua - version unspecified * GThread - WebHelper - version unspecified * LibSoup - GeniusPaste - v2.4 - UpdateChecker - v2.4 * LibVTE - Debugger - v0.24 - MultiTerm - version unspecified * LibXML - PrettyPrinter - v2.6.27 - XMLSnippets - either doesn't use or not specified * WebKitGTK+ - Devhelp - 1.1.13 - WebHelper - v1.1.18 - Markdown (Future Plugin) - version unspecified For most of the dependencies, I think the GEANY_CFLAGS/GEANY_LIBS would cover it (gtk, glib, gio(?), gmodule, gthread, etc.). For the others maybe there could be some tweaking of versions to at least make the dependency versions the same. I know for my two plugins (DevHelp and MultiTerm) the versions of the dependencies are not very much of a concern and I mostly copied existing plugins' .m4 files. Just a few thoughts I had while mucking around with the build system. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Indicators improvement
On 12-08-01 06:08 AM, Thomas Martitz wrote: Am 01.08.2012 12:02, schrieb Lex Trotman: Matthew, Try this attachment. Cheers Lex What is this about? He's hopped up on cold medicine and sent it to the wrong address :) It's an optimized version of the error indicator that we were working on for Scintilla to speed up rendering of those little red zig-zag lines. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] About a new application icon.
Hi, I personally have no opposition to changing the icon, although I'm not sure I like that burgundy colour of the ball very much. I actually rather liked the old icon as well, but I'm aware that my taste often differs from most. P.S. It might be worthwhile to send this also to the geany-users mailing list too since AFAIK there's some web developers/designers and such there that would likely have some interesting opinions of and modifications to your icon(s). Just a thought. Cheers, Matthew Brush On 12-07-28 06:30 AM, Emanuel Palm wrote: Hey guys! I guess I'm not entirely adapted to how things are done in the open source world. I made a pull request at github, when I should have sent you all an e-mail here first. So, here is the text I wrote there with a couple of adjustments: /So, I've been exploring Geany a bit for a little while now, and I must say I enjoy the IDE quite a lot. It took me, however, a couple of tries before I finally gave it a real chance. The reason, to be very frank, is because the application icon gave me the impression that the program has a made-at-home-hack rather than a substantial IDE suited for all kinds of programming situations, which I discovered it is. So, I took the liberty of making a new Geany icon in Inkscape, made a fork and sent a pull request./ /The idea of this pull request is not necessarily for the community to merge it with no second thoughts, which I don't believe is going to happen. Rather, I would like to start a discussion on the role of the application icon. If, after the discussion, people are happy to use the icon, I'll gladly let the community use it at leisure. If this discussion leads to the community switching to another icon, then at least the community saw the validity of my point. If this leads to the original icon not being replaced, then at least there was a consideration being made./ /So, as a discussion starter, I'm here listing the roles and priorities I believe the application icon should fulfill:/ /*1. To single out the application from the crowd.*/ /The lamp and the name 'Geany' fulfill this role very well. I guess its some kind of pun referring to rubbing the magic lamp and using the genie popping out to fulfill your programming ambitions. Its a simple and distinguishable symbol./ */2. To communicate the ambition that has been, and is being put into the software./* /I don't believe there is any one programmer who wants to use software that is dying or lacks a community or company continually backing it up. By labeling a piece of software with an icon/logo which looks solid, professional, and artistic communicates that there is enthusiasm behind it. Take the Mozilla Firefox logo, as a noticeable example. Its elegant, artistic and simple./ /As of today most professional looking icons/logos are based on simple curves and/or shapes to make them explicit and harmonious. They use few, but carefully chosen, colors. The Geany icon as of today fulfills the color requirement, but lacks elegance in it's shapes and lines. My suggestion as a substitute reuses the colors of the original icon, with some slight adjustments, but strips down the lamp into more basic shapes and lines./ */3. To communicate the purpose of the application./* /The Geany icon of today fulfills this purpose very poorly, but so does a lot of other icons as well. Look at some examples with, in my opinion, well designed logos: Google Chrome (a ball with colors?), NetBeans (a cube?), FileZilla (a stamp?). The role of the icon/logo is only relevant as long as the user has no knowledge of the application, which is why I put it as the third priority/role./ So, that's what I wrote. And in order to be able to have something to talk about, I've added the .svg files I've made as an attachment. The first version already got shot down by elextr, so there is a second version here too. Somehow the second one makes me think of Disney, but I guess that's no problem. I'm not sure about the colors and the brackets visible in the second version, and should there be a disc in the background? All suggestions are helpful. If you are interested to have that much of a party, it would be fun if people started to fire up Inkscape themselves and fiddle with what I made, or conjure up things on their own. Regards, Emanuel Palm ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geanypy again query this time :)
On 12-07-24 03:14 PM, Oly wrote: Any one able to tell me why this line fails in plugin and in the interactive console. from gi.repository import Gtk as gtk,GObject as gobject,GLib as glib you can still use import gtk glib and gobject but they are being depricated in favour of the above and the current versions of glade generate xml for the new way not the old. Is it maybe using GTK+ 3? AFAIK you can't load GTK+ 3 and 2 in the same process and Geany and GeanyPy are using GTK+ 2 already. Just a guess without seeing the error messages and whatnot. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] OSX build error: ld: unknown option: --export-dynamic
On 12-07-17 02:17 PM, Colomban Wendling wrote: Le 17/07/2012 22:43, Matthew Brush a écrit : On 12-07-17 01:32 PM, Sean Felipe Wolfe wrote: Sorry to be kind of spammy today. Just ran into what looks like a build error? I cloned the git repo, ran autogen.sh, and make is giving me this error: - CC utils.o CC vte.o CXXLD geany ld: unknown option: --export-dynamic - This is on osx Lion. Any suggestions? Yep, this and your last problem were both things I had to figure out too. This export dynamic problem is because Geany doesn't deal with OSX separately and lumps it in with non-Windows in the Makefile. Unfortunately this linker flag is invalid on OSX but is needed on Linux (and others?) for Glade to connect to the signal handlers at runtime. Quick Fix: Just delete everywhere you see `-Wl,--export-dynamic` in the Makefile.am files (probably only in `src/Makefile.am`). We can't do this in Geany proper because it won't work correctly on Linux then. Real Fix: In the configure.ac, detect OSX somehow and do an AM_CONDITIONAL or something like this so that the Makefile can set the LDFLAGS differently for OSX than other Unices. If done correctly, a patch would be most welcome. I can't remember if I fixed this properly in my changes or if I just did the quick fix. ...or we could drop our flag and let GModule pkg-config flags deal with it. Fixed with commit https://github.com/geany/geany/commit/d11f9a51b939bf39c3c1676ab823147d460ede75 Nice! Still would be nice to have a way to handle OSX differently in the Makefiles though since there's a lot of OSX specific stuff needed should the changes ever be submitted/merged. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Code formatter
On 12-07-17 07:32 PM, Jacob Strohm wrote: Hello all, Does Geany have any kind of automatic code formatter, either in the core or as a plugin? Looking through the plugins project/website, I didn't see anything like it, and if not I think I'd enjoy working on it in my free time, I just wanted to double check before investing a bunch of time. Hi, I'd personally be very interested in using a plugin that can format the code precisely automatically. IIRC VisualStudio does this very well but is not flexible as to code style (or I didn't find the preferences). I suspect it would be quite difficult to write a good one that is at the same time accurate, flexible and supports multiple non-similar languages (C-style vs Python, for example). Best of luck, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] draggable tabs - current state?
On 12-07-14 04:48 AM, Matthew Brush wrote: On 12-07-14 03:59 AM, Thomas Martitz wrote: Am 14.07.2012 12:39, schrieb Lex Trotman: On 14 July 2012 20:21, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 14.07.2012 04:20, schrieb Lex Trotman: On 14 July 2012 07:07, Sean Felipe Wolfe ether@gmail.com wrote: I'd like to be able to have 2-3 columns of tabs and be able to drag + rearrange, something like Eclipse's draggable tab setup -- one of the few things I like about Eclipse. I assume this is non-trivial ... how horribly difficult would it be? Multiple columns/rows of tabs, how hard can it be? @#* hard, AFAICT you will have to change GTK, not Geany. Note drag re-ordering already works. Cheers Lex Can I at least have multiple sidebars with tabs being draggable between them (or make the message window a sidebar) ? :) Hi Thomas, Well, tabs are part of the GTK notebook that the edit window is in, so to put them in a sidebar you would be re-implementing part of GTK, maybe instead look at making the document sidebar re-orderable instead of sorted? GTK+ allows any tab to be dragged to any notebook as long as they have the same group id/name[1]. The only real limitation is the assumption Geany currently may make about certain tabs being in certain notebooks. I didn't mean document tabs. I meant the symbols, files, etc tabs in the side bar which should be draggable to a second sidebar on the right (basically split the current sidebar into two with the editor in the middle). +1. Like this: http://tinypic.com/r/dnoto8/6 Where you can choose between any of the layouts (with or without splitview enabled) and drag tabs between any same colourednotebooks. All notebooks can be hidden except for one of the blue document notebooks (the main document notebook). You can imagine also how this would be useful for plugins such as Webhelper or MultiTerm (or the builtin terminal). Like this: http://tinypic.com/r/2d1px90/6 Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] draggable tabs - current state?
On 12-07-14 11:25 AM, Sean Felipe Wolfe wrote: What does 'notebook' refer to in this context? It sounds like it refers to the windowspace of the gtk app as a whole? Or did I get that wrong? http://developer.gnome.org/gtk/2.24/GtkNotebook.html Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] More Per-Project Configuration Options
On 12-07-09 11:56 PM, Thomas Martitz wrote: Am 10.07.2012 07:37, schrieb Matthew Brush: On 12-07-09 04:57 PM, Braden Walters wrote: Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this. Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a Reset to Global button to reset that individual item so it does not appear in that project's file). I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts). Hi, What about just adding new settings to the project config file without messing with the UI? Those who need them can RTM and see what settings are available, those who are content with what exists currently can go on happily ever after. You can add as many project preferences as you care to code and document this way. I hate needing to edit config files directly. This is not user friendly. I never meant to imply it would be user friendly (ie. like something my Grandma could use), just that it would avoid messing with the UI until most of the coding is actually done. In the future some (or all) of the preferences could be moved to the GUI and we could discuss the colour of the bikeshed at that point once the code is actually working. Besides, it's not like it's unheard of for Geany (or even other editors like ST2) to make you edit config files. If a user sets something in the project config file, it overrides the global config file when that project is open, end of story, no UI tricks needed to tell her this, it's just how it is (documented). The other way(s) discussed seem like they would Eclipse the UI's usability. I actually quite like how Eclipse handles this, it should be considered for Geany too: Last time I tried it I got very confused and was overwhelmed with the sheer volume of user-interface elements I was seeing. It may be logical but it's not very simple, IMO. Each global settings tab (given it can be overridden by a project) has a line at the top saying that it can be overridden on a per-project basis. Then, for each project, each tab in the project preferences have a checkbox at the top that choose whether to inherit from global settings or override all settings in the tab. Unchecking the checkbox immediatly applies the global settings to the project. Checking the box prefills the settings with the values from the current global settings but can be changed obviously. Note that settings are grouped in tabs, so there is not one checkbox per setting, but per tab. This UI makes it easy to discover if stuff can be/is overriden by a project. It makes it easy to revert to global settings. It makes it possible without a massive amount new per-setting checkboxes to decide whether to override. PS: Eclipse's way to handle per-file settings is also quite OK IMO but I guess that's another topic. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Usability fix - saving tab state
On 12-07-10 11:20 AM, Dimitar Zhekov wrote: On Tue, 10 Jul 2012 01:41:46 +0300 Axel apeka1...@gmail.com wrote: I believe there is a usability flaw in Geany - opened documents' list is saved only if you exit the editor in 'traditional' way (by clicking exit button or so). It's completely lost, if the process's killed. This was irritating for me, as I tend not to close every program when shutting down, but rather push the 'shutdown' button and get them all killed - and get the list of opened documents lost. There is a X11 session management patch on Geany sourceforge patch tracker. Applies against 1.22, but not the newest svn. Not guaranteed to work under GNOME, they always have problems with session support. Won't ask you to save any modified files under Xfce, xfsm is buggy too. So it only works in KDE and Unity? (and maybe TWM :) Shouldn't bugs be filed against these projects (if not done yet) if they don't support the standard X/Linux session management? AFAIK they all claim to try and support the various standards floating around out there. I have no clue about SM, but it seems crazy that it cannot be done. There must be apps out there that work properly cross-desktop, maybe we can copy them? P.S. When logging out/shutting down, what order does it handle Geany instances in? Does it always make sure the first opened instance is the last to get handled so that you don't clobber the open files list for it and stuff? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Usability fix - saving tab state
On 12-07-10 11:20 AM, Dimitar Zhekov wrote: On Tue, 10 Jul 2012 01:41:46 +0300 Axel apeka1...@gmail.com wrote: I believe there is a usability flaw in Geany - opened documents' list is saved only if you exit the editor in 'traditional' way (by clicking exit button or so). It's completely lost, if the process's killed. This was irritating for me, as I tend not to close every program when shutting down, but rather push the 'shutdown' button and get them all killed - and get the list of opened documents lost. There is a X11 session management patch on Geany sourceforge patch tracker. Applies against 1.22, but not the newest svn. Not guaranteed to work under GNOME, they always have problems with session support. Won't ask you to save any modified files under Xfce, xfsm is buggy too. I pushed it to a sm branch[1] on the git repo just now. I haven't really tested it much but it builds and runs fine after a very trivial fix of the Makefile (and wscript) files. It might get more usage/testing/experimenting in a branch on the main repository compared to the sf.net tracker. Cheers, Matthew Brush [1] https://github.com/geany/geany/tree/sm ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] More Per-Project Configuration Options
On 12-07-09 04:57 PM, Braden Walters wrote: Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this. Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a Reset to Global button to reset that individual item so it does not appear in that project's file). I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts). Hi, What about just adding new settings to the project config file without messing with the UI? Those who need them can RTM and see what settings are available, those who are content with what exists currently can go on happily ever after. You can add as many project preferences as you care to code and document this way. If a user sets something in the project config file, it overrides the global config file when that project is open, end of story, no UI tricks needed to tell her this, it's just how it is (documented). The other way(s) discussed seem like they would Eclipse the UI's usability. My $0.02 Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Any suggestions where message is from?
On 12-07-06 06:25 PM, Lex Trotman wrote: Hi All, Any suggestions where the messages below come from? I've run outa time and patience. (geany:2673): Gtk-CRITICAL **: IA__gtk_tree_store_remove: assertion `VALID_ITER (iter, tree_store)' failed (geany:2673): Gtk-CRITICAL **: IA__gtk_tree_store_remove: assertion `VALID_ITER (iter, tree_store)' failed * They seem to happen when only on the first time I select a tab of filetype None so I'm guessing its something in symbols? Geany git HEAD, gtk 2.24.10 glib 2.30.2. Hi, Compile with `-DG_FATAL_WARNINGS` and then run in gdb. It'll abort and you can see where it happened. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: Windows test build for 1.22 available
On 12-07-01 01:44 AM, Enrico Tröger wrote: Hi all, I just made a test build of Geany Plugins 1.22 for Windows. A little surprisingly for me, it all worked fine on the first attempt :). I only had problems loading the Geany-Lua plugin with some strange error message which I didn't investigate yet: http://pastebin.geany.org/EUmwJ/ The error message occurs on plugin loading. I'm not sure whether it is caused by my system or something else. If anyone wants to test it, any feedback is appreciated. The installer... http://www.uvena.de/tmp/geany-plugins-1.22_setup_testbuild.exe ... requires an existing Geany 1.22 installation. Nice work! I'm not able to test on Windows for a few days, but until then, can you say which plugins are included? I'm curious about stuff like Debugger and MultiTerm that depend on VTE, or Devhelp and Webhelper that depend on (GTK)WebKit, were you able to get that going on Windows? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: Windows test build for 1.22 available
On 12-07-01 05:41 AM, Enrico Tröger wrote: On 01/07/12 12:16, Matthew Brush wrote: On 12-07-01 01:44 AM, Enrico Tröger wrote: Hi all, I just made a test build of Geany Plugins 1.22 for Windows. A little surprisingly for me, it all worked fine on the first attempt :). I only had problems loading the Geany-Lua plugin with some strange error message which I didn't investigate yet: http://pastebin.geany.org/EUmwJ/ The error message occurs on plugin loading. I'm not sure whether it is caused by my system or something else. If anyone wants to test it, any feedback is appreciated. The installer... http://www.uvena.de/tmp/geany-plugins-1.22_setup_testbuild.exe ... requires an existing Geany 1.22 installation. Nice work! I'm not able to test on Windows for a few days, but until then, can you say which plugins are included? Not really. When I boot Windows the next time, I'll have a look. OK, I was mostly wondering whether either of my two plugins would be available. I'm curious about stuff like Debugger and MultiTerm that depend on VTE, or Devhelp and Webhelper that depend on (GTK)WebKit, were you able to get that going on Windows? VTE on Windows? Not that I know of. Yeah I don't think, except for maybe on Cygwin or something. And WebkitGtk exists for Windows but I didn't include it. Last time, read at time of the last plugins' release, I tried to find a build but without success. Windows builds exist but I just didn't find them. And I'm not sure if we want to include it as it certainly would bump the installer size significantly (currently it has about 2MB, with Webkit it would be 10MB I guess) . Not sure, I know the source is available and I think there's nightly builds. I'm just remembering last release when many people were asking where is the Webhelper plugin on Windows. I don't think these people (mostly web devs probably) were really inclined to (re)build with GtkWebKit support. It's your call though, you're the one suffering through using Windows to get this built :) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] ANN: Geany-Themes 1.22 Released
Hi, I've made a tarball and zip release for Geany-Themes 1.22 file at: https://github.com/codebrainz/geany-themes/downloads Highlights: * Improved Solarized light and dark schemes (thanks Joshua Hoff) * Improved Gedit theme (thanks Jean-Philippe Fleury) * Improved Dark theme (thanks Harold Aling) * Remove Alternate (alt.conf) theme since it's shipped with Geany now * Updated credits and licensing information I'm hoping to make the releases/tarballs somewhat predictable to make it easier for distro package maintainers who want to create Geany-Themes packages. The main version number will follow Geany's and releases in between Geany releases will have a micro number like 1.22.1, 1.22.2, etc. Let me know if this format is going to work out or if there's any other files or something I need to add or re-format to simplify building packages. If anyone has any original or ported themes they want to include in Geany-Themes, make a pull request or Github or just email it to me or whatever. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On 12-06-25 12:33 PM, Dimitar Zhekov wrote: On Fri, 22 Jun 2012 13:08:22 -0700 Matthew Brush mbr...@codebrainz.ca wrote: Hi. Here is a small diff (for makefile.win32 and src/makefile.win32 only) that makes Geany 1.22 Win~1 compilation and installation independent of MSYS. Usage: C mingw32-make -f makefile.win32 C mingw32-make -f makefile.win32 install Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had to use backslashes in the install: target, and am not sure if/how MSYS make escapes them. Win~1 fully supports forward slashes internally, but the command interpreters have only partial support. Which command interpreters? AFAIK `cmd.exe` supports it fine, no? Also, on the topic of improving the win32 makefiles, we should make sure that all paths are quoted because IIRC last time I tried to use them, stuff like this[1] made it blow up when my PREFIX was (for example), `C:/Documents and Settings/...` (ie. spaces in the filename). All install: destination paths, yes. About the others - will anyone put gtk+ under C:\Documents and Settings, or something like that? IIRC mine was: %HOMEPATH%/gtk = C:/Documents and Settings/Matthew Brush/gtk But I could even imagine: C:/Program Files/GTK Or even: G:/GTK Stuff The truth to be said, all paths should be quoted under all OS-es, but nobody does that unless a path with spaces is really likely. For anything on Windows, spaces in filenames is *really* likely :) Out of curiosity/boredom I tried on Linux for Autotools to use ./configure --prefix=/tmp/Geany\ Stuff And it almost went all the way though, except for I needed to add pair of unescaped quotes here: https://github.com/geany/geany/blob/master/plugins/Makefile.am#L106 And the final step of installing the geany binary failed with: test -z /tmp/Geany Stuff/bin || /bin/mkdir -p /tmp/Geany Stuff/bin /bin/bash ../libtool --silent --mode=install /usr/bin/install -c geany '/tmp/Geany Stuff/bin' /usr/bin/install: target `Stuff/bin/geany' is not a directory make[2]: *** [install-binPROGRAMS] Error 1 Which seems strange since `/usr/bin/install -c geany '/tmp/Geany Stuff/bin'` on its own works just fine. Anyway, that's the extent of how much I care about it, and I haven't used Windows in many months, so it doesn't really matter anyway to me. I just figured that it's not often we can fix bugs with 2 characters () so it might be worthwhile :) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Does marker_translucency work?
Hi, I'm writing up some info on colour schemes and through testing it seems that marker_translucency doesn't do anything. Can anyone test to confirm? It says in the manual and filetypes.common file that it's supposed to control the translucency of the line markers (first arg) and the search indicators (second arg), but it seems that the line marker is hardcoded to fully opaque and that the search indicator is hardcoded to a fixed translucency level (not fully opaque). It's entirely possible I'm missing (or misunderstanding) something. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On 12-06-22 09:23 AM, Nick Treleaven wrote: On 19/06/2012 22:25, Matthew Brush wrote: On 12-06-19 10:12 AM, Dimitar Zhekov wrote: Hi, Now that 1.22 is out, how about removing the MSYS build dependency under Win~1? I tried to compile Geany with the default MinGW make, without any MSYS, and there were some easily fixable problems: cd foo $(MAKE) -f makefile.win32 cd ..\.. does not work, probably requires some sh. But if we depend on GNU make (which seems to be the case, since we're using ifdef/else/endif), it's easier and shorter to: $(MAKE) -C foo -f makefile.win32 OK. Linking does not work, because the stock make supports \ only for variables, not commands. But that's even easier to fix: OK. There is also some inconsistency: CP = copy, but cp -r and cp at the end of makefile. The install target can be rewritten as several -$(MD) and non-recursive $(CP) commands, and no MSYS will be required. Sigh. Is there no equivalent of 'cp -r' on Windows? RFC. If we consider this worthy, I can make the required changes. Sounds good. I have started working on this before: https://gist.github.com/1494603 It builds but isn't perfect, like it doesn't do the icon/resource stuff, and doesn't use win32-conf.h properly, but it might be useful for a starting point. It's what I use for testing Geany on Windows. I did respond to this before (maybe with a laundry list of suggestions), but off the top of my head, the main ones for me are: * it doesn't show the commands, so devs won't notice e.g if CFLAGS aren't correctly set * no support for building from MSYS I haven't actually tested the makefile, but the idea of a single file is appealing, e.g. we can avoid duplication for GTK_CFLAGS, etc. I guess for those GTK_CFLAGS and friends, we could put them into a separate make file that gets included in the others, either in localvars thing or a separate common-win32.mk or something. Also, on the topic of improving the win32 makefiles, we should make sure that all paths are quoted because IIRC last time I tried to use them, stuff like this[1] made it blow up when my PREFIX was (for example), `C:/Documents and Settings/...` (ie. spaces in the filename). Cheers, Matthew Brush [1] https://github.com/geany/geany/blob/master/src/makefile.win32#L23 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On 12-06-19 10:12 AM, Dimitar Zhekov wrote: Hi, Now that 1.22 is out, how about removing the MSYS build dependency under Win~1? I tried to compile Geany with the default MinGW make, without any MSYS, and there were some easily fixable problems: cd foo $(MAKE) -f makefile.win32 cd ..\.. does not work, probably requires some sh. But if we depend on GNU make (which seems to be the case, since we're using ifdef/else/endif), it's easier and shorter to: $(MAKE) -C foo -f makefile.win32 Linking does not work, because the stock make supports \ only for variables, not commands. But that's even easier to fix: STLIBS = ../scintilla/scintilla.a ../tagmanager/tagmanager.a ../tagmanager/mio/mio.a $(TARGET): $(OBJS) $(RES) $(STLIBS) $(CXX) $(OBJS) $(RES) -o $(TARGET) $(STLIBS) $(ALL_GTK_LIBS) $(WIN_LIBS) with the added benefit that static library names are not repeated literally. There is also some inconsistency: CP = copy, but cp -r and cp at the end of makefile. The install target can be rewritten as several -$(MD) and non-recursive $(CP) commands, and no MSYS will be required. RFC. If we consider this worthy, I can make the required changes. I have started working on this before: https://gist.github.com/1494603 It builds but isn't perfect, like it doesn't do the icon/resource stuff, and doesn't use win32-conf.h properly, but it might be useful for a starting point. It's what I use for testing Geany on Windows. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [geany/geany] Question on - 7b3b65: Add workaround for users with an invisible selection style
On 12-06-04 08:30 AM, Nick Treleaven wrote: On 04/06/2012 07:59, Lex Trotman wrote: Based on your answer on my ML question is this necessary? Now that we always apply the settings, a selection style of false,false will reset to the Scintilla default The default is to show the selection by changing the background to light gray and leaving the foreground the same as when it was not selected. So false, false shouldn't be invisible. Of course it might be invisible on particular backgrounds, but so might c0c0c0. Or have I still misunderstood something? Try it yourself - here I get an invisible selection if neither override is set. Possibly a Scintilla bug - the Scintilla default is not restored on calling SCI_SETSELBACK when the first argument is 0/FALSE. I didn't look at exactly what was changed, but I can confirm that the selection colours are properly changed now when the scheme is changed, unlike before. The only thing now is I see the message with all geany-themes: Geany-WARNING **: selection style is set to invisible - ignoring! But having the selection fixed is worth it the console noise :) Thanks, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany Newsletter Issue #5
On 12-05-28 02:24 PM, Thomas Martitz wrote: Am 28.05.2012 13:27, schrieb Lex Trotman: This doesn't actually call the C++ constructors/destructors in the way they would be in normally be if the plugin had been statically linked. This simply labels a C function to be called at dlopen time. It may be used to do some initialisation, but you would have to manually call each constructor, ... too error prone, Franks advice to create everything dynamically is sound. I meant to say that global/static constructors/destructors are in fact called when a library is dlopened(), regardless of the language of calling code. I think that blurb in the newsletter was written before it was realized that the whole C++ runtime/magic was already present because of Scintilla. I wrote the paragraphs and IIRC Lex reviewed/revised it, but I can say I'm probably the least qualified to write about how to use C++ :) $ gcc -o libtestcpp.so -shared -fPIC test.cpp -g -lstdc++ -Wl,--no-undefined $ ./test Hello from Test hello from extern C function Bye from Test FWIW, does anyone know why I needed to link libstdc++ explicitely in my testing? Just guessing but maybe it's because of using the `gcc` command instead of `g++`? I only ever experienced needing to link to it explicitly with Geany/Scintilla. In my own pure C++ code it's never needed. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins: Bleeding-edge compatibility
On 12-05-18 01:47 PM, Quentin Glidic wrote: On 18/05/2012 22:37, Frank Lanitz wrote: I'm afraid its not applying. Can you rebuild it for current head? Cheers, Frank Here it is. Thanks both. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins: Bleeding-edge compatibility
On 12-05-09 01:02 PM, Frank Lanitz wrote: On Thu, 19 Apr 2012 17:38:00 +0200 Quentin Glidicsardemff7+ge...@sardemff7.net wrote: On 19/04/2012 16:43, Matthew Brush wrote: An explanation would be useful. For MultiTerm, presumably it's to avoid a clash with GLib.Menu/MenuItem? Is GIO stuff part of the implicit namespace for GLib? Yes, and yes. If the answer to those is yes, it looks fine to apply as is. Even if the answer is no, the patch shouldn't harm anything besides cluttering up the code a little bit. Attached a new patch with a better commit message. With a view onto http://lists.uvena.de/pipermail/geany-devel/2012-May/006824.html Is this fine to append? Yeah it's fine. Thanks, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] tagmanager changes
On 12-05-07 08:32 PM, Lex Trotman wrote: On 8 May 2012 13:27, Matthew Brushmbr...@codebrainz.ca wrote: On 12-05-07 05:03 PM, Lex Trotman wrote: On 8 May 2012 02:04, Nick Treleavennick.trelea...@btinternet.comwrote: On 02/05/2012 05:46, Lex Trotman wrote: 4. Ctags parsers Agree with Nick that the parsers are usable, but if we start modifying them to handle local declarations then they will be totally incompatible with the Ctags project so I guess it doesn't matter other than for getting languages we don't currently parse. ctags c.c already parses local tags No it doesn't AFAICT: I'm guessing he's referring to the upstream CTags c.c, which does have a l kind for local variables (off by default). See `ctags --list-kinds=C`. I'm not sure if the Geany fork has this, was forked before it was added, or if the guy that wrote TM took it out. Ok, I havn't looked at Ctags c.c because IIUC from other comments it isn't really mergable with our c.c. Does upstream c.c use tagmanager, and if so how does it structure scopes? (A good exercise for your compiler :) 1) no 1a) I never could understand CTags scopes, something like a 2-byte value, maybe an index into some array? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] tagmanager changes
On 12-05-08 05:44 AM, Colomban Wendling wrote: Le 08/05/2012 02:03, Lex Trotman a écrit : On 8 May 2012 02:04, Nick Treleavennick.trelea...@btinternet.com wrote: [...] It doesn't look like tm_file_entry_ is really used. Along with your comment below and about project on the next post, sounds like tm code could be reduced significantly. Might help :) Agreed at 100%! If we could cut down TM to remove the code that's actually not used (or not useful for us) would certainly help a lot to towards making it easier to understand. (BTW I think I remember something about Jiří having done something like it a long time ago) +1000 Also, it wouldn't hurt to make the file system structure and coding standard/style as other Geany files. For example: tagmanager/tm_*.[ch] - delete include/ dir, maybe remove tm_ prefix tagmanager/mio/* tagmanager/ctags/* - all non-tm files here And then we could run the files through GNU Indent or similar program to match Geany's coding style. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] tagmanager changes
On 12-05-07 05:03 PM, Lex Trotman wrote: On 8 May 2012 02:04, Nick Treleavennick.trelea...@btinternet.com wrote: On 02/05/2012 05:46, Lex Trotman wrote: 4. Ctags parsers Agree with Nick that the parsers are usable, but if we start modifying them to handle local declarations then they will be totally incompatible with the Ctags project so I guess it doesn't matter other than for getting languages we don't currently parse. ctags c.c already parses local tags No it doesn't AFAICT: I'm guessing he's referring to the upstream CTags c.c, which does have a l kind for local variables (off by default). See `ctags --list-kinds=C`. I'm not sure if the Geany fork has this, was forked before it was added, or if the guy that wrote TM took it out. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] tagmanager changes
Hi Nick,
I think maybe you just didn't realize how much everyone doesn't
understand TagManager because we always bitch about it on IRC in
passing. Actually, you might be the only person who *really* understands
it :)
I'll just rant a little bit about some problems with TM, as I see them
(and as bitched about on IRC), and maybe that can spin off some
discussions on ways we could improve it:
- Not invented here; none of us wrote it and not in Geany's coding
style, file system layout and naming convention, etc. I personally see
it as an upstream project like Scintilla, even though the upstream
project is dead (at least the TM part).
- Seems to be overly complex for what it needs to do (this might not be
true, but it's how it seems at a glance).
- Contains a *whole other fork* of CTags; for me this is the worst part.
It's far too difficult to take upstream improvements on files like c.c,
for example.
- Isn't threaded, blocks the UI for several seconds while parsing many
tags files before Geany can start, and even worse for the project
plugins that parse all the project files on opening. This makes Geany
appear really slow and in some cases *too* slow (ie. several minutes or
more, if there's enough files to parse).
- Isn't re-entrant or thread-safe, uses lots of global state, I guess
this is mostly due to CTags but also I think TM itself has some same
issues. This means it's really hard to get tag parsing out of the main
thread.
- Upstream project doesn't use or support TM anymore, just us. AFAIK
they are using a simpler scheme[1] involving forking out to a CTags
binary and using a (seemingly) more logical database (sqlite) for
storing and accessing tags.
- Doesn't complete local variables, scope completion doesn't seem to
work properly either.
- Doesn't support CTags format files for some reason (though I added
this previously in my fork, so it's certainly do-able).
Of course I don't mean to make it sound like TM is garbage, looking at
the code shows it's quite well engineered/optimized, and I'm confident
that it has lots of good qualities, even if I don't understand them.
Anyways, I'll end ranting here and hope it might give some ideas about
the problems some of us see with TM, and we could work towards fixing,
if we aren't to replace TM altogether.
Cheers,
Matthew Brush
[1] http://git.gnome.org/browse/anjuta/tree/plugins/symbol-db
On 12-04-29 05:07 AM, Nick Treleaven wrote:
On 27/04/2012 06:30, Lex Trotman wrote:
[...]
I don't understand why tagmanager has to be replaced, why not just
replace
the parts you want to improve? Rewriting it is likely to lead to a
new set
of bugs and be hard to review and merge changes from master.
One of the problems with tagmanager is its complexity, leading to
considerable wariness on the part of many of us about changing it
since we don't understand what we might break.
I don't see this myself, I see some complicating issues which could be
resolved (and I'm willing to work on them), but generally a sound design
for what it provides and for extra things we may want to add.
Actually documenting the overall structure of tagmanager and how it is
supposed to work would be a good thing, whats a workspace? what is it
meant to represent, how are scopes represented? etc.
Isn't it clear from the data structures? Look at TMWorkspace. Scopes and
other tag metadata is the same as CTags. Obviously if we had at-a-glance
overall documentation that would be good.
One confusing thing is that a TMTag can be used for an actual tag or for
a file. Probably that could be cleaned up.
- a multi-cache one that, as its name suggests, maintains multiple
caches (sorted tags arrays). it uses a little more memory and is
slower on insertion since it maintains several sorted lists, but a
search on an already existing cache is very fast.
Won't this be slow for adding many tags at once? How is this design
better
than tagmanager?
Perhaps Colomban could confirm, but my first thought is that this is
for nested scopes.
I expect the design is better in some respects (and to be fair I didn't
look for better things), but finding a tag based on its name is
something we are always going to want to be fast. Even for scope
completion, you still need to lookup a tag structure from a name string.
So I think we will always want a sorted array of tags per document that
we can bsearch (or something equally fast).
Also, I've probably sounded quite harsh on Colomban's design, but I'm
commenting on what I think is important. I am genuinely interested in
why his design decisions are better. It's a lot to take in all at once,
so probably needs some explanation. Sorry if I didn't make that clear.
How does tagmanager handle nested scopes, or how would it need to be
modified to do so, considering the example (in C)
{ struct a o; struct a p;
o./* struct a members */
{ struct b o;
o./* struct b members */
p./* struct a members */
}
o./* struct a members */
p./* struct
Re: [Geany-devel] gitignore needs updating?
On 12-04-21 06:12 PM, Lex Trotman wrote: Hi all, I just noticed git status mentions some untracked files # Untracked files: # (use git addfile... to include in what will be committed) # # .lock-wafbuild # po/.intlcache and Matthew mentioned some more on IRC that appear from time to time. I don't think `INSTALL` should be tracked, and also the `config.h.in~` or something is missing from `.gitignore`. Also, `doc/geany.html` shouldn't be tracked, but I guess this one is on purpose, for people who build from Git but can't install `python-docutils` for whatever reason. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins: Bleeding-edge compatibility
On 12-04-19 01:09 AM, Frank Lanitz wrote: Am 16.04.2012 13:33, schrieb Quentin Glidic: Hello, Two minor compatibility patches to keep-up with bleeding-edge stuff. Dear Maintainer of Debugger and Multiterm Can you have a look at this patches and send pull request to geany-plugins master? An explanation would be useful. For MultiTerm, presumably it's to avoid a clash with GLib.Menu/MenuItem? Is GIO stuff part of the implicit namespace for GLib? If the answer to those is yes, it looks fine to apply as is. Even if the answer is no, the patch shouldn't harm anything besides cluttering up the code a little bit. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] public ui_setup_open_button_callback
On 12-04-05 11:56 AM, Dimitar Zhekov wrote: Hi, Currently UIUtilsFuncs contain ui_path_box_new(), so a file-chooser-dialog button can be created programatically in a plugin. But there's no ui_setup_open_button_callback(), so it's impossible to load such a button from a .glade file and setup it, as in Geany. geanyprj uses ui_path_box_new(), and other plugins (saveactions, spellcheck, debugger, ...) create file-chooser-dialog buttons manually, so they seem common. I'm writing a new plugin, and would prefer to use .glade for the interface as much as possible (and practical). IMO, all this path box stuff should be deprecated in favour of the widget provided by the toolkit (GtkFileChooserButton). Using custom stuff like this makes Geany non-standard amongst other GTK+ programs and it doesn't provide the flexibility of the already provided widget, namely being a real GtkWidget and integration with Glade. On the other hand, I also wouldn't be opposed to a proper implementation of a real custom GtkWidget subclass (ex. GeanyPathBox) that can be used in Glade and otherwise conveniently, since I tend to find the text box next to the button to be more user-friendly than the widget currently provided by the toolkit for this purpose. My $0.02, having thought about this before while porting to Glade and having previously written a GeanyPathBox widget for this use. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Porting themes (Was: Re: Request: multithreaded tag generation?)
On 12-03-27 11:43 AM, Harold Aling wrote: Matthew, On Tue, Jan 3, 2012 at 17:29, Matthew Brushmbr...@codebrainz.ca wrote: I'll add your changes to geany-themes shortly, thanks! Can you define 'shortly'? :D short·ly adv. 1. When you remind me :) Just checked out a fresh copy of geany-themes, expecting to find my changed dark.conf in it... Done[1] Thanks, Matthew Brush [1] https://github.com/codebrainz/geany-themes/commit/f0116aae7dd95149530722c2ce5c78ca0e27bf13 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins tests failures
On 12-03-25 08:46 AM, Quentin Glidic wrote: Hello, While running geany-plugins tests, I hit two failures. The first one is that cppcheck is not happy about Vala, and since multiterm is fully in Vala, it fails. Weird, it builds OK here with `--enable-cppcheck` and `make check`. It has a few warnings about the compiled C code but otherwise seems fine. Can you tell what the error/failure message is? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] geany-plugins tests failures
On 12-03-25 10:33 AM, Quentin Glidic wrote: On 25/03/2012 19:22, Matthew Brush wrote: Weird, it builds OK here with `--enable-cppcheck` and `make check`. It has a few warnings about the compiled C code but otherwise seems fine. Can you tell what the error/failure message is? Cheers, Matthew Brush The debugger one: make[4]: Entering directory `/home/sardemff7/Developpement/Geany/geany-plugins/debugger/src' /usr/bin/cppcheck -q --template gcc --error-exitcode=2 . dbm_gdb.c:1483: error: Return value of allocation function g_strdup_printf is not used. The multiterm one: make[3]: Entering directory `/home/sardemff7/Developpement/Geany/geany-plugins/multiterm/src' /usr/bin/cppcheck -q --template gcc --error-exitcode=2 . cppcheck: error: could not find or open any of the paths given. I’m using the latest cppcheck commit. It almost sounds like it can't see the C files compiled by Valac. Is there C files in `multiterm/src/`? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Gathering Release 1.22 incompatibilities
On 12-03-20 06:09 AM, Nick Treleaven wrote: On 20/03/2012 04:46, Lex Trotman wrote: + Filetypes + * Move all named styles into color schemes and keep only mappings in the + filetypes files. Filetypes should no longer contain styling information, + except `filetypes.common` which contains the default color scheme. Breaks + compatibility with old filetypes files. I think the filetypes.* files compatibility was not broken. Rather that overriding filetypes style defaults will break color schemes. It's true that it's not broken, it's just that a number of users will open their freshly installed Geany version and notice that they have no Scintilla styling at all, that the default color schemes don't work, and/or their own/geany-themes color schemes don't work, or some combination of those. I actually was meaning to bring this up, and I think it was discussed in passing on IRC since I've made a branch on geany-themes to implement it. What if the color schemes and filetypes.* files had a version key in them that Geany could check and warn about such potential problems? I was thinking the key could be something to the effect of `geany_version=1.22` in the `[theme_info]` and (a new) `[ft_info]` groups, which would be the recommended minimum version of Geany that will work properly with the file. If the key is missing (ie. existing files) or the Geany version is too low, it would prompt a simple message dialog explaining the problem, with the option to not show it again. Does this sound workable at all? [...] Also, shouldn't the important/breaking things be in the same group at the top? Otherwise when we add the other changes they won't stand out. It's fine with me, I was just following the existing format of the file and didn't fully understand what was meant about them being at the top of the file. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Gathering Release 1.22 incompatibilities
On 12-03-20 06:06 PM, Matthew Brush wrote: [...] I actually was meaning to bring this up, and I think it was discussed in passing on IRC since I've made a branch on geany-themes to implement it. What if the color schemes and filetypes.* files had a version key in them that Geany could check and warn about such potential problems? I was thinking the key could be something to the effect of `geany_version=1.22` in the `[theme_info]` and (a new) `[ft_info]` groups, which would be the recommended minimum version of Geany that will work properly with the file. If the key is missing (ie. existing files) or the Geany version is too low, it would prompt a simple message dialog explaining the problem, with the option to not show it again. Does this sound workable at all? Heh, I just found a Gist I had previously made as a demo/idea for this: https://gist.github.com/2016617 Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Gathering Release 1.22 incompatibilities
On 12-03-19 05:29 PM, Lex Trotman wrote: Agree, I think Colomban's idea of adding incompatible/important changes to the NEWS file as we go, and at the top, would work well. Sounds like we are approaching a plan. This sounds like a fine idea to me. Something like the attached patch is OK? Cheers, Matthew Brush diff --git a/NEWS b/NEWS index 4e7bf87..a4a6a76 100644 --- a/NEWS +++ b/NEWS @@ -3,6 +3,15 @@ Geany 1.22 (unreleased) Editor * Update Scintilla to version 2.29. +Filetypes +* Move all named styles into color schemes and keep only mappings in the + filetypes files. Filetypes should no longer contain styling information, + except `filetypes.common` which contains the default color scheme. Breaks + compatibility with old filetypes files. + +Plugin API +* Rename signal `project_dialog_create` to `project_dialog_open` and + add new signal `project_dialog_close`. Increments plugin ABI. Geany 0.21 (October 2, 2011) ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Default keybinding for Zoom In
Hi, It's always bothered me that Geany uses the wrong keybinding for Zoom In, but I'm starting to think it's completely on accident. The normal keybinding for Zoom In on most applications is Control and Equal (same key as plus symbol). If you look at the default keybinding for Zoom In, it says Controlplus, which sounds right, but it should really say ControlShiftplus, since you have to press Shift to get the plus symbol. The correct default keybinding for Zoom In should be Controlequal, if it's to be like the vast majority of other software that supports zooming. Is anybody opposed to me correcting this? P.S. I'm only talking about US-like keyboards here, since that's all I've ever used. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Fwd: Security issue in Terminal
Hi all, Just forwarding this along from the Xfce list as Geany (and many other programs) also use this same library for the Terminal feature. I'm not convinced it's a big deal, but none-the-less users should be aware of it. See the link in the forwarded message for more information. Cheers, Matthew Brush Original Message Subject: Security issue in Terminal Date: Wed, 07 Mar 2012 11:28:58 -0500 From: David Rosenstrauch darose darose.net Reply-To: Xfce general discussion list x...@xfce.org To: x...@xfce.org Has there already been a bug report filed for this security issue in Terminal? http://www.climagic.org/bugreports/libvte-scrollback-written-to-disk.html Thanks, DR ___ Xfce mailing list x...@xfce.org https://mail.xfce.org/mailman/listinfo/xfce http://www.xfce.org ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Commit messages on merges
On 12-03-04 07:07 AM, Colomban Wendling wrote: Le 04/03/2012 09:28, Frank Lanitz a écrit : On Sun, 04 Mar 2012 03:40:29 +0100 Colomban Wendlinglists@herbesfolles.org wrote: IMO we should not record merges when there is only one single commit or when the commits are unrelated (though the latter should probably be less common) and rather rebase or cherry-pick the commits. However, we must keep the merge when the commits are a whole thing not to lose that information (when several commits are needed to implement a single thing). I agree. And in second case we have to keep care that merge message is informative enough to don't go into complete tree just to understand what have been done there. Personally I started using the git merge command from command line more often instead of github's web interface as its not satisfying my understanding. Same for me, moreover because I prefer to test the PR locally as a simple branch before doing the merge, so it's not much effort than using the GitHub UI, and it's a lot more powerful. Same here, but I don't think it matters whether using `git merge` or the Github GUI to do it, there's still a need to change the default merge message (apparently). Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Commit messages on merges
On 12-03-04 01:29 PM, Frank Lanitz wrote: On Sun, 04 Mar 2012 13:01:27 -0800 Matthew Brushmbr...@codebrainz.ca wrote: On 12-03-04 07:07 AM, Colomban Wendling wrote: Le 04/03/2012 09:28, Frank Lanitz a écrit : On Sun, 04 Mar 2012 03:40:29 +0100 Colomban Wendlinglists@herbesfolles.org wrote: IMO we should not record merges when there is only one single commit or when the commits are unrelated (though the latter should probably be less common) and rather rebase or cherry-pick the commits. However, we must keep the merge when the commits are a whole thing not to lose that information (when several commits are needed to implement a single thing). I agree. And in second case we have to keep care that merge message is informative enough to don't go into complete tree just to understand what have been done there. Personally I started using the git merge command from command line more often instead of github's web interface as its not satisfying my understanding. Same for me, moreover because I prefer to test the PR locally as a simple branch before doing the merge, so it's not much effort than using the GitHub UI, and it's a lot more powerful. Same here, but I don't think it matters whether using `git merge` or the Github GUI to do it, there's still a need to change the default merge message (apparently). Issue on github is, that you aren't able to change the first line ... ... Which isn't necessarily a bad thing. It keeps them standard and the default first line contains useful information like that it was a merge, the PR #, the person who made the PR and their branch name. In any case, I'm fine with doing it however everyone wants. I use gitk to view the history usually, so it's pretty obvious what all has happened. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [geany/geany] 3d4e8b: Merge pull request #25 from techee/project_patches
Hi, The commit here bumps the API and ABI and renames a signal. Just an FYI for any plugin developers, though a quick grep shows only the GProject plugin being affected in the Geany-Plugins project. Cheers, Matthew Brush On 12-02-26 08:50 PM, Matthew Brush wrote: Branch: refs/heads/master Author: Matthew Brushmbr...@codebrainz.ca Committer: Matthew Brushmbr...@codebrainz.ca Date:Mon, 27 Feb 2012 04:50:01 Commit: 3d4e8b41d419255ee1b0764fb60e45ea588bd800 https://github.com/geany/geany/commit/3d4e8b41d419255ee1b0764fb60e45ea588bd800 Log Message: --- Merge pull request #25 from techee/project_patches Project patches Modified Paths: -- doc/pluginsignals.c src/geanyobject.c src/geanyobject.h src/plugindata.h src/project.c Modified: doc/pluginsignals.c 15 files changed, 12 insertions(+), 3 deletions(-) === @@ -156,18 +156,18 @@ static void on_document_open(GObject *obj, GeanyDocument *doc, gpointer user_dat */ signal void (*project_close)(GObject *obj, gpointer user_data); -/** Sent after a project dialog is created but before it is displayed. Plugins +/** Sent after a project dialog is opened but before it is displayed. Plugins * can append their own project settings tabs by using this signal. * @param obj a GeanyObject instance, should be ignored. * @param notebook a GtkNotebook instance that can be used by plugins to append their * settings tabs. * @param user_data user data. */ -signal void (*project_dialog_create)(GObject *obj, GtkWidget *notebook, gpointer user_data); +signal void (*project_dialog_open)(GObject *obj, GtkWidget *notebook, gpointer user_data); /** Sent when the settings dialog is confirmed by the user. Plugins can use * this signal to read the settings widgets previously added by using the - * @c project-dialog-create signal. + * @c project-dialog-open signal. * @warning The dialog will still be running afterwards if the user chose 'Apply'. * @param obj a GeanyObject instance, should be ignored. * @param notebook a GtkNotebook instance that can be used by plugins to read their @@ -176,6 +176,15 @@ static void on_document_open(GObject *obj, GeanyDocument *doc, gpointer user_dat */ signal void (*project_dialog_confirmed)(GObject *obj, GtkWidget *notebook, gpointer user_data); +/** Sent before project dialog is closed. By using this signal, plugins can remove + * tabs previously added in project-dialog-open signal handler. + * @param obj a GeanyObject instance, should be ignored. + * @param notebook a GtkNotebook instance that can be used by plugins to remove + * settings tabs previously added in the project-dialog-open signal handler. + * @param user_data user data. + */ +signal void (*project_dialog_close)(GObject *obj, GtkWidget *notebook, gpointer user_data); + /** Sent once Geany has finished all initialization and startup tasks and the GUI has been * realized. This signal is the very last step in the startup process and is sent once * the GTK main event loop has been entered. Modified: src/geanyobject.c 15 files changed, 12 insertions(+), 3 deletions(-) === @@ -269,11 +269,11 @@ static void create_signals(GObjectClass *g_object_class) NULL, NULL, g_cclosure_marshal_VOID__VOID, G_TYPE_NONE, 0); - geany_object_signals[GCB_PROJECT_DIALOG_CREATE] = g_signal_new ( - project-dialog-create, + geany_object_signals[GCB_PROJECT_DIALOG_OPEN] = g_signal_new ( + project-dialog-open, G_OBJECT_CLASS_TYPE (g_object_class), G_SIGNAL_RUN_FIRST, - G_STRUCT_OFFSET (GeanyObjectClass, project_dialog_create), + G_STRUCT_OFFSET (GeanyObjectClass, project_dialog_open), NULL, NULL, g_cclosure_marshal_VOID__POINTER, G_TYPE_NONE, 1, @@ -287,6 +287,15 @@ static void create_signals(GObjectClass *g_object_class) g_cclosure_marshal_VOID__POINTER, G_TYPE_NONE, 1, G_TYPE_POINTER); + geany_object_signals[GCB_PROJECT_DIALOG_CLOSE] = g_signal_new ( + project-dialog-close, + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + G_STRUCT_OFFSET (GeanyObjectClass, project_dialog_close), + NULL, NULL, + g_cclosure_marshal_VOID__POINTER, + G_TYPE_NONE, 1, + G_TYPE_POINTER); /* Editor signals */ geany_object_signals[GCB_UPDATE_EDITOR_MENU] = g_signal_new ( Modified: src/geanyobject.h 6 files changed, 4 insertions(+), 2 deletions(-) === @@ -41,8 +41,9 @@ GCB_PROJECT_OPEN
Re: [Geany-devel] Commit messages on merges
On 12-02-26 11:20 PM, Frank Lanitz wrote: Hi folks, Just something I thought on last merges based on Jiri's patches. Its hard to understand what this merges do just by reading the commit message. Given, that we want to create the ChangeLog based on git log it will be nearly impossible to create a good ChangeLog/Newsfile if we don't keep care. Not sure how, but can we be more verbose here? Do not show document change notification dialog when MRU switch is in progress When switching between MRU documents, Geany pops up a dialog about document change even for the intermediate non-final documents. This leads to both reload dialog and document switch dialog displayed at the same time and termination of document switching because the newly displayed dialog takes focus. This patch disables reload checks for the intermediate documents and forces reload check for the final document. Do not ignore system() return value to eliminate compiler warning Drop 'already' from the message in project close confirmation dialog Suppose you have project A open and want to open project B. Then the message saying The 'A' project is already open displays. This is slightly confusing and feels like if you were trying to re-open project A even though you are opening different project. The message without 'already' looks clearer in this context. Modify project dialog signals Rename project-dialog-create signal to project-dialog-open because now the dialog exists all the time and the signal name is misleading. Add project-dialog-close signal to indicate that project dialog has been closed and plugins can remove their tabs when needed. In addition, bump plugin API and ABI version. Just to give everyone who hasn't checked the commits an idea of the verbosity that those commit messages has. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Commit messages on merges
On 12-02-26 11:20 PM, Frank Lanitz wrote: Hi folks, Just something I thought on last merges based on Jiri's patches. Its hard to understand what this merges do just by reading the commit message. Given, that we want to create the ChangeLog based on git log it will be nearly impossible to create a good ChangeLog/Newsfile if we don't keep care. Not sure how, but can we be more verbose here? I guess if we can filter out merge commits and only show the real commit information it should be good? (See other message with individual commit messages) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Patch for Feature Request #3481844
On 12-02-25 04:29 PM, Michael Hall wrote: On 02/25/2012 06:00 PM, Colomban Wendling wrote: 2) Is this a general-purpose change or a patch that only should be in Ubuntu? I mean, I don't know of any other distribution using Unity so I'm not 100% sure this should be applied upstream... To my knowledge Unity has been successfully ported to both ArchLinux and OpenSuse, and is in the process of being ported to Fedora as well. It may not be as popular outside of Ubuntu, but it does exist in other distros, so I'd rather get this upstream where everybody can benefit. IMO, it's fine to add it as long as it doesn't cause any issues with non-Unity desktop environments. Have you tested it in Xfce/KDE/GNOME/etc. by any chance or are you pretty sure it won't harm? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Plugins Guidance
On 12-02-22 04:48 PM, Lex Trotman wrote: On 23 February 2012 01:13, Colomban Wendlinglists@herbesfolles.org wrote: Le 21/02/2012 05:15, Lex Trotman a écrit : [...] 2. don't spread menu items through the Geany menus, users don't know where to look and if several plugins add things to the same place the menu may become unworkable. You don't know what other plugins the user will enable at the same time. I'm not sure about this one either, though I understand that too many items everywhere may become a problem. But if the plugin provides a feature like, say, uniqueness (ref. thread in the general ml), the menu would better fit in edit-format or something; and e.g. GeanyGenDoc places an item in editor context menu-insert. Well, its only the plugin developers idea of where it belongs, personally I would not want uniqueness in format. Also if we change the Geany menu all the plugins have to scramble to fix themselves. We could use GtkUIManager more, it's precisely what it's used for (ex. in Gedit), AFAIK. IMO this makes the UI better than fulfilling the tools menu with various stuff, since it's the appropriate place for such an item. Just try getting agreement on appropriate, its a bikeshed. Unless the plugin has a preference to choose tools or somewhere else. That's what HIGs are for, and common sense even :) I understand that if 10k plugins adds items in various menus it'd start to be annoying, but OTOH, is a tool menu with 10k items really better? Well, at least its isolated and the usability of the rest of Geany isn't impacted. I don't think that there is a clear cut solution, but IMHO on balance it is better to keep the mess constrained to one place. IMO, if it's a simple plugin and provides a generic editor feature Geany is missing, it would be fine to put it in the corresponding menu (ex. Edit-Format-Remove Duplicate Lines), but if it's a big plugin with lots of menu items, even if they fit better in the regular menus, they should still be put in a submenu inside the Tools menu. That's my opinion anyway. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Plugins Guidance
On 12-02-21 01:00 PM, Lex Trotman wrote: Another item just came up, see http://lists.uvena.de/geany/2012-February/007831.html where two plugins don't share resources nicely (in this case the limited number of markers available). Both plugins use hard coded integer marker numbers. Looks like all markers are going to have to be marked available by Geany (well except for those we use) and plugins are going to have to test for available ones before defining them, and to reset them available when the plugin is unloaded. This means plugins also have to handle exhaustion of markers. This convention also needs to be documented. More generally what other resources does this apply to? Indicators, GUI elements/widgets/layout (SplitWindow/Devhelp), intents/purposes (GProject/GeanyPrj/Android/Clang), project files (GProject/Others?), scripting plugins (GeanyPy/ZenCoding) and there's probably some more. It might be neat to have some form of controller in Geany that can dish out resources as needed and prevent conflicting plugin types/intents and resources. PS, anyone not wanting to conflict with any of my plugins that use indicators, don't use SCI_INDIC_MAX-1 :) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Some obsolete(?) bug reports
On 02/17/2012 09:42 AM, Dimitar Zhekov wrote: On Mon, 13 Feb 2012 17:14:19 -0800 Matthew Brushmbr...@codebrainz.ca wrote: 3. geany xyz.txt does not load files from session - ID: 2838686 [3] Here it wasn't decided whether of not Geany should restore session. I suggest we discuss this question and finally either fix the bug or mark it as WONTFIX. I don't often use Geany for opening files from the command line and usually I always have a Geany window open so if I do, it's not an issue, so I can't really provide a worthwhile opinion here. As the bug report states, opening a file _with your file manager_ or CLI loses the last [default] session [if no geany is running]. The complaints we usually got were I double-clicked foo.c and lost my session, to which we usually replied use projects. So this affects the GUI, even more than CLI. Yeah, I don't usually do that either. I almost always have an instance of Geany running on my 2nd monitor and if not, I'm usually not surprised by the behaviour since I do use projects mostly unless I'm just quickly editing a file or two. Why not have a vote and finally implement or wontfix it? I volunteer to write the preference, as a graphical or vaiouus preference, if we decide aye. I have no opposition to this, though I wouldn't even know which way to vote. Why not setup one of those online polls and send a message to the mailing list(s) and see what happens? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Some obsolete(?) bug reports
On 02/11/2012 11:18 PM, Eugene Arshinov wrote: Hello. Sorry for bothering you so much. When I looked for existing bug reports related to changing document's filetype to None, I found a couple of reports that seems obsolete. Maybe some of the developers could spend some time to review them and mark them as CLOSED or whatever is applicable. 1. Incorrect indentation guides - ID: 2637071 [1] I opened the attached document and did not see any issues with indentation guides. I could miss something because I rarely use the guies, but... Maybe it was already fixed in Scintilla? Enrico replied to this report in 2009. I think this bug is still present if I understand it correctly. The attached file causes indentation guides to be shown on the blank line that has no indentation at all. 2. Command line option to bring Geany to front - ID: 2276179 [2] Seems that some actions were performed to fix the bug, but the report's author didn't have time to check it. Maybe, as a long time has passed since 2009, the bug report can be closed? BTW, what is described in the report, works fine for me (Geany is brought to front). Enrico replied to this report in 2009, too. Just closed this one. 3. geany xyz.txt does not load files from session - ID: 2838686 [3] Here it wasn't decided whether of not Geany should restore session. I suggest we discuss this question and finally either fix the bug or mark it as WONTFIX. A long time ago I added to the Preferences dialog a checkbox that controlled the behaviour. This was done in the sm branch. If it's decided that a graphical preference is needed, I can extract code from there and make a pull request. However, currently I think that a hidden pref for that is better. Your opinions? I don't often use Geany for opening files from the command line and usually I always have a Geany window open so if I do, it's not an issue, so I can't really provide a worthwhile opinion here. Thanks for tracking down those lingering bug reports! Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Maintainerrequest: Geany-Mini-Script
On 02/05/2012 02:43 AM, Eugene Arshinov wrote: Hi Frank. I sent a pull request [1] which contains the plugin integrated into geany-plugins. Review and pull, if you wish. I also created a repository [2] which contains geany-mini-script plugin at the state in which it was in SVN repo. [1]: https://github.com/geany/geany-plugins/pull/13 [2]: https://github.com/earshinov/geany-mini-script Just out of curiosity, isn't Mini Script kind of redundant with having the Edit-Format-Send Selection To feature? I guess it has a few more options but it seems to do the same thing. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] get build command from a plugin
On 02/03/2012 11:43 AM, Dimitar Zhekov wrote: On Thu, 2 Feb 2012 10:14:15 +1100 Lex Trotmanele...@gmail.com wrote: It would be really good if someone other than me tests it, my test plugin is rather dumb. I tested with the following code in plugin_init(): build_set_menu_item(GEANY_BCS_PROJ, GEANY_GBG_EXEC, 1, GEANY_BC_LABEL, boza); And, after I open a project and load the plugin, Set Build Commands looks like this:attachment Is your Geany up to date with Git? There was a problem with the project dialog and Glade that was exactly like this not very long ago, but it should be fixed in Git now. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] get build command from a plugin
On 02/01/2012 02:34 PM, Lex Trotman wrote: On Thu, Feb 2, 2012 at 5:10 AM, Dimitar Zhekovdimitar.zhe...@gmail.com wrote: On Wed, 1 Feb 2012 11:24:01 +1100 Lex Trotmanele...@gmail.com wrote: On Wed, Feb 1, 2012 at 5:20 AM, Dimitar Zhekovdimitar.zhe...@gmail.com wrote: On Tue, 31 Jan 2012 15:39:52 +1100 I compile Geany with -Wall -W -Wno-unused-parameter (not the normal practice) and received a few warnings: Well, it should be normal practice, thats what HACKING says, I just forgot to set it with a new clean clone, oops. Actually you should add -O2 because a couple of the warnings need the dataflow computation that the optimisation does. I only listed the warnings, -O2 is a sine qua non (albeit -Os -freorder-blocks is better for some systems). The semantics of a command (well actually the label) that is vs NULL is important, a label hides commands from a lower priority source without showing itself in the menu, a NULL does not. [...] Unfortunately there isn't anthing else besides NULL that is sensible to return to indicate out of range. So returning for COMMAND is possible... So I've exposed build_get_group_count() as well so you can get the count and then its your fault if you pass an out of range index :). ...but a count is fine too. :) Let's hope BuildFuncs makes it into the plugin interface, the current lack of build access is weird. Well, my intention is that when Matthew has tested writing I will add it if no other developers object in the meantime. It will be quite a bit before the Android plugin is at the point to using this since I have a whole bunch of other stuff to do first to even get an Android project created and opened. If you want I could probably write a little test plugin just to see if it works, but if there's no rush, I'll get this tested in due course otherwise. P.S. Thanks for adding the feature, it will save me writing tons of documentation explaining how to configure Geany to work with the Android SDK, I can just do it automatically for users now :) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] get build command from a plugin
On 01/28/2012 06:08 AM, Dimitar Zhekov wrote: Hi, How can I $subject? FWIW, I also have a need for this for an Android plugin I'm working on (using Eclipse is sooo painful). So far I've found a need to both get and set the build commands for a project (and the working dir) and also to programmatically cause them to run (IIRC this is already working by a keybindings hack). My current code is basically just duplicating all the project and build stuff under it's own menu since it's not exposed, but it feels clunky and redundant. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] get build command from a plugin
On 01/30/2012 04:16 PM, Lex Trotman wrote: On Tue, Jan 31, 2012 at 10:16 AM, Matthew Brushmbr...@codebrainz.ca wrote: On 01/28/2012 06:08 AM, Dimitar Zhekov wrote: Hi, How can I $subject? FWIW, I also have a need for this for an Android plugin I'm working on (using Eclipse is sooo painful). So far I've found a need to both get and set the build commands for a project (and the working dir) and also to programmatically cause them to run (IIRC this is already working by a keybindings hack). My current code is basically just duplicating all the project and build stuff under it's own menu since it's not exposed, but it feels clunky and redundant. DRY So in addition to the proposal to Dimitar, add function: build_set_menu_item( const GeanyBuildSource src, const GeanyBuildGroup grp, const unsigned cmd, const GeanyBuildCmdEntries field, const gchar *value ) Unfortunately that will update the menu for each field you write, but I can't trust you to call build_menu_update() when you have finished, can I? Also add function: build_activate_menu_item( const GeanyBuildSource src, const GeanyBuildGroup grp, const unsigned cmd ) which can activate *all* the menu items, the keybinding hack can't bind other than the well known commands that were in Geany originally, so you can't activate them ATM. Sounds pretty good, I'll need to examine closer to be sure, but we can always make more changes after once we play with it for a bit. Thanks, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] encoding combo boxes bug - utility functions
On 01/25/2012 06:45 PM, Lex Trotman wrote: [...] Hi Matthew, While in general I agree with you, your examples are of mixed accuracy, see below: [1] Just at a very quick scan through utils.c, things like utils_slist_remove_next() - local static used one place, agree no reason to exist utils_is_uri() - good utility function, well named Indeed well named and probably a little clearer that `strstr(uri, ://) != NULL` but that's probably what I'd write if I didn't know Geany had it's own function for this, or I'd use g_uri_parse_scheme() or something. utils_string_replace() - probably should be static, only used several times in utils itself utils_spawn_async() - I think was used more than one place in the past, also hides the messy #ifdef windoze which is good If the GLIB functions don't work (ie. on win32), we should send a bug report/patch upstream, just as we'd do with Scintilla if we found an obvious bug. We shouldn't have our own fixed implementation, IMO (unless it does something else I'm not aware of, or upstream refused the fix). utils_build_path() - g_build_filename() has better portability semantics, should replace utils_build_path() Yep, why I listed it. utils_make_filename() - reasonable utility function, probably should be used in more places where filename.ext concat is done explicitly I never would've thought to use this function over g_strjoin() and g_build_filename() or something. Having this seems weird to me, despite it being mildly useful and having good doc comment, since the name isn't great and the two things it does are so commonly available separately already in GLIB. But anyway, I made this list in 2 minutes scanning utils.c, so possibly not the best examples. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] encoding combo boxes bug - utility functions
On 01/23/2012 08:30 AM, Nick Treleaven wrote:
On 22/01/2012 22:00, Lex Trotman wrote:
When working with a common well known library like GTK it is better to
use the well known interface directly rather than creating private
partial wrappers.
Contributors who know GTK don't have to learn the private interface
(or complain about what is missing, or just use GTK directly anyway
since they don't know about the private interface) and contributors
who don't know GTK can learn an interface that is useful to them
elsewhere, rather than one that just works in Geany.
You make a valid point, but most contributions are from the core team
that know our utility functions. In this case we're discussing a fairly
trivial function, but if it gets used 10 or 50 times in the code base
I probably don't know 40%+ of Geany's code after casually hacking on it
for well over a year. When reading the code, I have to refer to the
source file for each function called to see what it does, with GTK+ I've
already done this for many cases, and know what it does. When writing
the code, I have to first write it in normal GTK+ and then go through
and make sure I haven't used any functions that are wrapped in the Geany
API/headers and even other static functions in the same file. It sounds
trivial if you are intimate with the source code, but if you aren't it
can make understanding the code you need to understand in order to fix a
bug or add a feature that much harder to follow.
then that's a significant benefit in avoiding temporary variables or
nested expressions, which are harder to read. As I said, if the function
is obvious, there's no harm.
You don't really avoid temp vars, you just put them in another file. And
if an expression is only nested one or two levels deep, it's easier (at
least for me) in many cases to read if the code is inline.
For a (fictional) example:
void some_func(void)
{
GError *err=NULL;
if (!g_some_func(..., err))
{
printf (error: %s\n, err-message);
g_error_free (err-message);
}
...
}
is easier for me to read than:
/* misc.h */
#define EZG(...) { ... actual code from above ... }
separate files
/* some.c */
void some_func(void)
{
EZG(g_some_func, ...);
...
}
Even if it saves you repeating that same 5-6 line idiom a thousand times
throughout the source, unless you wrote both pieces of code, or unless
EZG() is in a well know API like GTK+, then it makes the code harder to
read, IMO, which many more people do many more times than writing it.
In other cases we have functions that save 10 lines of code per call.
This is a massive help that outweighs having to work out what the
function does.
+1.
Another point is that exposing Matt's ui_get_builder before we actually
have code that needs it seems premature. We already know we need to
lookup objects though, and that a short syntax is needed.
It's the same thing, you still expose one function to use, but with
ui_get_builder() you get the entirety of the GtkBuilder API for free and
never have to add another wrapper function for it. If you have
ui_builder_get_object(), if you need another function from the
GtkBuilder API, then you need to add another function, like
ui_builder_add_object(). Now you have two specialty functions functions,
both wrapping ones that are already included with gtk.h.
But anyway, the current function is so trivial, and I know everyone has
a different preference about these things, it's just my two cents...
Cheers,
Matthew Brush
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] encoding combo boxes bug
On 01/22/2012 04:59 AM, Nick Treleaven wrote: On 20/01/2012 21:29, Matthew Brush wrote: @All: I added ui_builder_get_object() to be able to fetch a non-widget (list store here) from prefs.c, but I'm not completely sure it's the prefect fix. If you have any idea on how to improve this, spread them! :) IMO, it'd be better to just move the builder object to the header file (maybe in a suitable struct), so that all files can access it. Then there's no need to add 1 line wrapper functions for every function we use from GtkBuilder's API. This isn't unprecedented, I think there's at least a handful of globals like this in Geany already (even in ui_utils.h). Alternatively, we could add a function called `ui_get_builder()` to get access to the builder to use with GtkBuilder API. Otherwise, it's not too big of a deal, maybe we don't need much more from the GtkBuilder API. I think Colomban's function is fine. I don't understand avoiding adding functions that are obviously useful and cleaner: obj = ui_builder_get_object(name); vs. obj = gtk_builder_get_object(ui_get_builder(), name); The former is easier to read and it's obvious what it does. But the latter exposes the full functionality of the GtkBuilder API without us having to maintain but a single function. For example, consider the following: GtkBuilder *builder = ui_get_builder(); gtk_builder_add_from_string (builder, TOOLBAR_XML, -1, NULL); ... I basically just don't think it's worth maintaining a thin wrapper around common C/GTK+ code/idioms making our own framework to save a line or two of code here and there. Unless you wrote the wrapper function yourself, it makes the code harder to read, IMO. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] encoding combo boxes bug
On 01/20/2012 10:39 AM, Colomban Wendling wrote: Le 20/01/2012 00:07, Lex Trotman a écrit : On Fri, Jan 20, 2012 at 9:58 AM, Lex Trotmanele...@gmail.com wrote: On Thu, Jan 19, 2012 at 11:53 PM, Nick Treleaven nick.trelea...@btinternet.com wrote: Hi, I'm seeing wrong encoding names in the encoding combo boxes on the Files tab of the Prefs dialog. E.g. where it should say UTF-8 I see Hebrew. Another Glade-related bug? Sort of, according to glade combo_new_encoding, combo_open_encoding and combo_eol all share the same underlying list model. So when we initialise them, all the entries go in the same list, so all three show the encodings twice and the end of line entries at the bottom. Two of these need to be pointed to different list models. PS the two encodings combos could probably share the same list, so long as we only initialise it once in prefs.c, but eol needs its own list Thanks for the catch analysis, it's now fixed -- actually I did broke it in ca922e0ddc8022283ec3c1f49aaa15ab7c5ba213, stupid me. @All: I added ui_builder_get_object() to be able to fetch a non-widget (list store here) from prefs.c, but I'm not completely sure it's the prefect fix. If you have any idea on how to improve this, spread them! :) IMO, it'd be better to just move the builder object to the header file (maybe in a suitable struct), so that all files can access it. Then there's no need to add 1 line wrapper functions for every function we use from GtkBuilder's API. This isn't unprecedented, I think there's at least a handful of globals like this in Geany already (even in ui_utils.h). Alternatively, we could add a function called `ui_get_builder()` to get access to the builder to use with GtkBuilder API. Otherwise, it's not too big of a deal, maybe we don't need much more from the GtkBuilder API. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SCSS (Sassy CSS) lexer support
On 01/17/2012 01:54 PM, Lex Trotman wrote: [...] In general I'd say it could be added since a complete pull request is available. Pardon the serial post :) @Ross, Do you have some SCSS examples for testing? @All Devs, Should we make a section on the wiki for code fragments in each language for testing since none of us use all the languages Geany supports. Or should it be a directory in the source? I think it'd be useful, I know I could use them for the themes. What about a separate repository on github or a permanent branch that never gets merged in to the main branch (or released) that has a samples directory or some such? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] GIT commit mails format
On 01/15/2012 12:03 PM, Lex Trotman wrote: [...] What do you think? If we agree to change the commit mails to this format, I'd deploy the script soon. Hi Enrico, Actually I've become used to the standard github commit emails and clicking on the link for the diff. Especially for large changes like geany.html or geany.glade (despite Matthew and Colomban promising the diffs will get smaller with 3.8.1) not being blasted by large diffs is good. I can choose what I want to see, and don't get the two line diff of geany.txt cut off because the huge geany.html diff exceeds the size limit. I don't suppose that you could let registration for the commit ML allow a choice of which we want? Or make it so no diff is shown for autogenerated files like geany.html and geany.glade ? It'd be the best of both worlds then, IMO. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On 01/13/2012 03:31 AM, Lex Trotman wrote: [...] What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the response, hide and show signals on it as a normal GtkDialog? Sounds fine to my limited understanding. This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this. But how much of the internal structure of the dialog are you going to document? Is Jiri expected to find the notebook widget within the dialog or will it be passed some other way? If from the dialog it needs to be documented (or at least its name does). Yeah, I thought about this after I sent the last message. We would need to add the dialog *and* the dialog's notebook to the main_widgets struct, like we do with the other notebooks (doc, sidebar, msgwin). Otherwise we'd have to guarantee a name so it could be accessed through ui_lookup_widget() or do the signals on the wrong object thing like is done for most signals (with the renames Jiri proposed). Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Fixing Glade File (was Re: Whither goest CTRL-Q?)
Hi, For whatever reason in commit c85b89afdd880b7a6aac42f953bab83d3938a4a3 (fixing the project dialog), Glade removed the accelerators (and adjustments) from geany.glade. I'm looking for a clever way to fix this without having to manually edit the Glade XML, add the dropped stuff back manually, or revert and redo all my changes from that commit. Any hints/ideas? P.S. I tried just copying the whole XML block for the project notebook (where all my *intended* changes were) into the non-broken version just before that commit, and it worked somewhat, but there's been changes to this chunk of code in a later commit, so those don't work. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Fixing Glade File (was Re: Whither goest CTRL-Q?)
On 01/13/2012 07:33 PM, Colomban Wendling wrote: Le 14/01/2012 03:24, Matthew Brush a écrit : Hi, For whatever reason in commit c85b89afdd880b7a6aac42f953bab83d3938a4a3 (fixing the project dialog), Glade removed the accelerators (and adjustments) from geany.glade. I'm looking for a clever way to fix this without having to manually edit the Glade XML, add the dropped stuff back manually, or revert and redo all my changes from that commit. Any hints/ideas? P.S. I tried just copying the whole XML block for the project notebook (where all my *intended* changes were) into the non-broken version just before that commit, and it worked somewhat, but there's been changes to this chunk of code in a later commit, so those don't work. Well... I managed to get it done with sed + handwriting, that was a bit boring but not that hard. Hope it's fixed now. Thank you. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On 01/12/2012 04:12 PM, Jiří Techet wrote: On Thu, Jan 12, 2012 at 16:51, Matthew Brushmbr...@codebrainz.ca wrote: On 01/12/2012 01:44 AM, Lex Trotman wrote: [...] There was no change in documented functions, signals or behaviour AFAIK. Ok, if the functionality used is not *documented* to be in the API then it is not protected, but, as the change in behaviour is going to require a change in the plugin interface an API bump will happen by default. No, it won't(didn't) require any changes to the API I don't think. It was never documented that you should rely on the Project dialog being destroyed and cleaning up your notebook page for you. Would you, for example, increment the API and ABI if GeanyPluginX depended on the fact that the main GtkVBox widget in the Glade file was named `vbox1` and we changed it to `vbox_main`? If it was in the interface documentation, yes, else no. In this case GProject was (understandably) relying on undefined internal behaviour of Geany rather than using the signal provided in the API to allow a plugin to remove the notebook page from the projects dialog (not that the docs would lead you to believe this, in fact the opposite). Not sure why it needs to depend on internal behaviour, but I havn't studied the details of what it does. This may a side effect of the ad-hoc inclusion of features in the plugin interface, they are only added when asked for. Since the project dialog may now be created (and only once) before the plugin is conected to the signal, the plugin interface will need to be changed to still allow current operation to continue since AFAICT the only documented way the plugin can get the notebook is the project create signal. I guess you and Jiri should work out the details of what is needed. Nope, plugins can add their notebook page during the `project_dialog_create` signal and remove it during the `project_dialog_confirmed` signal, nothing changed here I don't think. Well, not quite - project_dialog_confirmed is only emitted when the dialog is confirmed but not in the case when it's cancelled in which case there's no indication for the plugin that the dialog was closed (and that the tab should be removed). Actually it was me who introduced the signal because there was nothing which would tell you if OK was pressed (and if I should re-read the values from the tab). As far as I know it is only me who adds his own tab to the dialog and I think nobody was thinking much about this possibility before. OK so what's missing now is the signal when Cancel is pressed. Either we could introduce a new signal for it or change the existing signals which I would prefer because the existing names are confusing now: * rename project-dialog-create to project-dialog-open * rename project-dialog-confirmed to project-dialog-closed and add a boolean parameter telling whether the dialog was confirmed or cancelled (but this could become a problem if Apply is added to the dialog in the future) * bump the API because it really changes now :-) What if we deprecate the old project create/confirm API altogether, add the project preferences dialog to GeanyMainWidgets structure, and just let plugins use the response, hide and show signals on it as a normal GtkDialog? This wasn't possible before when the dialog was created/destroyed each time since the pointer in the main_widgets global would change all the time, but now it'll stay the same right from before `geany-startup-complete` all the way until after plugins are unloaded . We could even say with certainty that this API *won't ever* change, the project dialog in main_widgets would *always* be a (subclass of) GtkDialog and so would only break if GTK+ broke this. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On 01/11/2012 04:11 PM, Jiří Techet wrote: On Mon, Jan 9, 2012 at 01:05, Matthew Brushmbr...@codebrainz.ca wrote: On 12/26/2011 01:37 PM, Jiří Techet wrote: Hi, I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce: 1. Open project properties dialog. 2. Close it. 3. Open it for the second time. Result: the project properties dialog is much smaller and it's empty. I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong. I fixed this in: https://github.com/geany/geany/commit/0755b44db1a238a65d7b3cec7f8b11430c8b2f1e If you don't mind to test around the project preferences dialog a bit to see if you can spot any more problems it would great. In general it seems to be fixed. However, there's one related problem - in GProject I add additional tab to the dialog. At the moment I'm adding the tab every time the dialog appears because before the GtkBuilder changes the dialog was destroyed once it was closed. Now it seems you reuse the same dialog which means I should change the GProject behavior otherwise new and new GProject tabs are added every time the dialog appears. If this new behavior is official then the plugins API version should be bumped because it changes their behavior. Yeah, I guess that couldn't hurt, although according to the docs, this is how the API version is supposed to be used[1]: The Application Programming Interface (API) version, incremented whenever any plugin data types are modified or appended to. Which is why I never touched the API version, since it's quite clear when to increment it[2]. Cheers, Matthew Brush [1] Although I personally dislike this in general since it does not give any indication when new functions are added or removed or like this case where behaviour is changed, nor does it give any correlation between API version and the currently running version of Geany. In other words, it seems basically useless, IMO. [2] Despite the example in the same comment that shows it being used to guard a function, which can't actually be guarded since there's no way to know what API version to check for functions. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: MAINTAINERS file
On 01/11/2012 05:13 AM, Frank Lanitz wrote: Am 10.01.2012 23:46, schrieb Matthew Brush: On 01/07/2012 07:20 AM, Colomban Wendling wrote: Le 07/01/2012 16:00, Frank Lanitz a écrit : On Fri, 6 Jan 2012 23:42:39 +0100 Frank Lanitzfr...@frank.uvena.de wrote: * What's the exact difference between Supported and Maintained? The only difference I see is that supported has the word paid in the description, but I doubt that most of us get paid for this in particular, and I also doubt it changes anything on how good is the support (hobby vs. job). My fault. I wanted to change this but missed it. I wanted to s/supported/paid for ... (Even I don't know anybody at the moment who is getting paid with Geany stuff ;) ) I suggest to use paid instead of supported and change current usage of supported to maintained. I'm still not sure what that fact someone is paid or not changes, but otherwise it looks fine and clearer to me. +1 Whether paid or volunteer, it's still Maintained. I suggest dropping the Paid status altogether if no one has used it by the time all the plugins' info is filled in. I disagree. Currently there might be no plugin maintainer being paid to work on a plugin, but: - this might change (...) - is something user should be able to see to resynch there demandings with reality. Hehehe, well said. OK, it's not a big deal, though I still feel it's not very useful for Geany-Plugins. I'm reading e.g. support@pidgin mailing list and more than once a week I need to facepalm myself because of users don't understand they are not talking to some paid support. I really don't want to end up on Geany with such situation. You aren't kidding! I was reading a bug report[1] on Pidgin's tracker a while back about the auto-sizing of a text box or something and the tone was absolutely incredible, including demands, threats, name-calling and much more. I couldn't work on a project like Pidgin with so many disrespectful users. Cheers, Matthew Brush [1] I think it was: http://developer.pidgin.im/ticket/4986 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On 01/11/2012 11:10 PM, Lex Trotman wrote: On Thu, Jan 12, 2012 at 1:25 PM, Matthew Brushmbr...@codebrainz.ca wrote: On 01/11/2012 04:11 PM, Jiří Techet wrote: On Mon, Jan 9, 2012 at 01:05, Matthew Brushmbr...@codebrainz.cawrote: On 12/26/2011 01:37 PM, Jiří Techet wrote: Hi, I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce: 1. Open project properties dialog. 2. Close it. 3. Open it for the second time. Result: the project properties dialog is much smaller and it's empty. I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong. I fixed this in: https://github.com/geany/geany/commit/0755b44db1a238a65d7b3cec7f8b11430c8b2f1e If you don't mind to test around the project preferences dialog a bit to see if you can spot any more problems it would great. In general it seems to be fixed. However, there's one related problem - in GProject I add additional tab to the dialog. At the moment I'm adding the tab every time the dialog appears because before the GtkBuilder changes the dialog was destroyed once it was closed. Now it seems you reuse the same dialog which means I should change the GProject behavior otherwise new and new GProject tabs are added every time the dialog appears. If this new behavior is official then the plugins API version should be bumped because it changes their behavior. Yeah, I guess that couldn't hurt, although according to the docs, this is how the API version is supposed to be used[1]: The Application Programming Interface (API) version, incremented whenever any plugin data types are modified or appended to. Which is why I never touched the API version, since it's quite clear when to increment it[2]. Cheers, Matthew Brush [1] Although I personally dislike this in general since it does not give any indication when new functions are added or removed or like this case where behaviour is changed, nor does it give any correlation between API version and the currently running version of Geany. In other words, it seems basically useless, IMO. [2] Despite the example in the same comment that shows it being used to guard a function, which can't actually be guarded since there's no way to know what API version to check for functions. Hi Guys, This should be an ABI and API change unfortunately, current functions do not work the way they did so old plugins (eg old GProjects) won't work. API without ABI is for adding new stuff that does not prevent current plugins from working. There was no change in documented functions, signals or behaviour AFAIK. Would you, for example, increment the API and ABI if GeanyPluginX depended on the fact that the main GtkVBox widget in the Glade file was named `vbox1` and we changed it to `vbox_main`? In this case GProject was (understandably) relying on undefined internal behaviour of Geany rather than using the signal provided in the API to allow a plugin to remove the notebook page from the projects dialog (not that the docs would lead you to believe this, in fact the opposite). Since we're loading plugins into the Geany process with basically complete access to everything, then we should bump the API version on every commit, since we could potentially be changing undocumented internal behaviour that the plugins can have access to if they really want. In any case, the docs, especially for `project_dialog_confirmed` should be improved/fixed. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: MAINTAINERS file
On 01/07/2012 07:20 AM, Colomban Wendling wrote: Le 07/01/2012 16:00, Frank Lanitz a écrit : On Fri, 6 Jan 2012 23:42:39 +0100 Frank Lanitzfr...@frank.uvena.de wrote: * What's the exact difference between Supported and Maintained? The only difference I see is that supported has the word paid in the description, but I doubt that most of us get paid for this in particular, and I also doubt it changes anything on how good is the support (hobby vs. job). My fault. I wanted to change this but missed it. I wanted to s/supported/paid for ... (Even I don't know anybody at the moment who is getting paid with Geany stuff ;) ) I suggest to use paid instead of supported and change current usage of supported to maintained. I'm still not sure what that fact someone is paid or not changes, but otherwise it looks fine and clearer to me. +1 Whether paid or volunteer, it's still Maintained. I suggest dropping the Paid status altogether if no one has used it by the time all the plugins' info is filled in. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Adding some Glade widgets
On 01/09/2012 03:02 AM, Lex Trotman wrote: [...] There's probably other ones too. But anyway I thought I'd ask about it since it'd be useful for working in Glade to have first class widgets to add from the catalog and would make Geany's code a little more clean and modular (if not bigger/slightly slower). Bigger slower is bad, more maintainable is good, but do we have enough widget wranglers (ie people who know enough about widgets and the boilerplate and semantics of them? I guess so, at least in the sense that we already have a handful of existing widgets, we just can't use them in Glade currently, so we leave blank spots in Glade and hard-code packing and configuring them in whatever file they're used from (toolbar.c, prefs.c?). Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Adding some Glade widgets
On 01/09/2012 08:21 AM, Nick Treleaven wrote: On 09/01/2012 00:56, Matthew Brush wrote: - GeanyWrapLabel - Nice little existing GtkWidget that fixes broken GtkLabel text wrapping in GTK+ 2. Should work fine in a glade catalog and should even fix wrapping of labels in Glade. This would be really nice to have, I hate having to create wrapping labels manually whilst the other nearby labels can be done in Glade. - GeanyObject, others? Why would we need GeanyObject from Glade? It's a singleton. Sorry, I should've put a ? after GeanyObject, not to imply it's necessarily a candidate, but rather to ask about it. - GeanyScintilla - Subclass of ScintillaObject, all functions in sciwrappers moved to methods of this class. In future, could be combined There was a GtkScintilla project IIRC that did this, but I don't think it's maintained now. Yeah, the developer of that (me), was ambitious and tried to wrap the whole massive Scintilla API, but for Geany I was thinking of just wrapping those parts we actually need/use (ex. what's in sciwrappers). with GeanyEditor since both are somewhat redundant. I think keeping the separation of scintilla utils and editor functions is a good idea (e.g. derive GeanyScintilla from a GtkScintilla class). My thinking was they're both serve the same purpose, so having two separate objects/files with some functions in one part and some functions in another part seems a bit redundant/overlappy. For example, when I'm writing a plugin and need a function related to the editor widget, I first have to check editor.h and then check sciwrappers.h (then Scintilla docs if it's not found in Geany proper). Anyway, that would be extremely disruptive to the plugin API. Very true. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On 12/26/2011 01:37 PM, Jiří Techet wrote: Hi, I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce: 1. Open project properties dialog. 2. Close it. 3. Open it for the second time. Result: the project properties dialog is much smaller and it's empty. I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong. I fixed this in: https://github.com/geany/geany/commit/0755b44db1a238a65d7b3cec7f8b11430c8b2f1e If you don't mind to test around the project preferences dialog a bit to see if you can spot any more problems it would great. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Adding some Glade widgets
Hi, I was wondering about making a Glade XML catalog for Geany widgets, existing and some new ones, so they can be used through the Glade GUI. Some possible widgets for the catalog include: Existing: = - GeanyWrapLabel - Nice little existing GtkWidget that fixes broken GtkLabel text wrapping in GTK+ 2. Should work fine in a glade catalog and should even fix wrapping of labels in Glade. - GeanyEntryAction - Existing helper class for adding an entry (find/goto I guess) to a toolbar, should work fine in a glade catalog. - GeanyMenuButtonAction - Existing helper class for adding a button to a toolbar. I didn't look too much where it's used, but should be fine in a Glade catalog. - GeanyObject, others? Done with functions in UI Utils file (ie. could be little widgets) == - GeanyPathBox - A GtkEntry and GtkButton in a GtkHBox (so it would be a GtkBox subclass). The entry has a clear icon to the right (and so could be a subclass of the next widget I'll mention). The button has a GtkImage packed inside and could be improved by more tightly packing the image in the button (like is done in notebook.c for the tab close button). An alternative to this is to switch to GtkFileChooserButton, but I'm not personally convinced that it's any better than the existing path boxes like there is now. - GeanyClearableEntry - A GtkEntry subclass which has a clear icon packed into the secondary icon position. When the icon is clicked the text of the entry is set to (cleared). This is used all over. - Probably other stuff? Entirely New (future/long term) === - GeanyScintilla - Subclass of ScintillaObject, all functions in sciwrappers moved to methods of this class. In future, could be combined with GeanyEditor since both are somewhat redundant. There's probably other ones too. But anyway I thought I'd ask about it since it'd be useful for working in Glade to have first class widgets to add from the catalog and would make Geany's code a little more clean and modular (if not bigger/slightly slower). Thoughts, comments, else? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Porting themes (Was: Re: Request: multithreaded tag generation?)
On 01/03/2012 06:18 AM, Harold Aling wrote: On Tue, Jan 3, 2012 at 15:16, Matthew Brushmbr...@codebrainz.ca wrote: On 01/03/2012 05:50 AM, Harold Aling wrote: On Tue, Jan 3, 2012 at 13:44, Matthew Brushmbr...@codebrainz.cawrote: I already ported all of the existing old-style color schemes to work with the new filedefs, see the geany-themes[1] project on Github to get them. Some might need a little tweaking, but should for the most part be quite similar to the original ones. Nice! Unfortunately, the 'dark' scheme needs some serious tweaking to make it look like I'm used to (it's very brownish dull right now), but I guess some well-placed copy/paste actions will solve that for me! ;) Armed with a screenshot of the old scheme, dark.conf, an old filetypes.* file and the documentation[1] I'll try to recreate the old dark theme. It'd be great if you could send me your changes after so I could update the one in geany-themes! I will. Unfortunately, it's quite a trial and error process as the documentation isn't very helpful in where a definition is used. For example: 'string_1', 'keyword_3', and lots of others aren't mentioned anywhere. It also would have been nice if there's a old new name list. See the [styling] section in each filedef to see where they map to the old language-specific styles. For example, here's an extract of the PHP style mappings from filetypes.xml:: php_default=default php_simplestring=string_1 php_hstring=string_1 php_number=number_1 php_word=keyword_1 php_variable=preprocessor php_comment=comment php_commentline=comment php_operator=operator php_hstring_variable=string_2 php_complex_variable=keyword_2 The only reason there's ones with like keyword_3 and keyword_4 is that some languages have that many sets of different keywords, and if they all mapped to keyword_1 in the filedefs, it'd mean you'd have to edit the filedefs to change the scheme. This way though, you can just change the style for keyword_4 to be a different one right in the color schemes, for example, in the color scheme:: keyword_4=keyword_1 Changes to:: keyword_4=0xff;0xff;false;true And then whatever languages have a 4th set of keywords would have them highlighted differently from the other sets. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Porting themes (Was: Re: Request: multithreaded tag generation?)
On 01/03/2012 06:45 AM, Harold Aling wrote: On Tue, Jan 3, 2012 at 15:31, Matthew Brushmbr...@codebrainz.ca wrote: On 01/03/2012 06:18 AM, Harold Aling wrote: On Tue, Jan 3, 2012 at 15:16, Matthew Brushmbr...@codebrainz.cawrote: On 01/03/2012 05:50 AM, Harold Aling wrote: On Tue, Jan 3, 2012 at 13:44, Matthew Brushmbr...@codebrainz.ca wrote: I already ported all of the existing old-style color schemes to work with the new filedefs, see the geany-themes[1] project on Github to get them. Some might need a little tweaking, but should for the most part be quite similar to the original ones. Nice! Unfortunately, the 'dark' scheme needs some serious tweaking to make it look like I'm used to (it's very brownish dull right now), but I guess some well-placed copy/paste actions will solve that for me! ;) Armed with a screenshot of the old scheme, dark.conf, an old filetypes.* file and the documentation[1] I'll try to recreate the old dark theme. It'd be great if you could send me your changes after so I could update the one in geany-themes! I will. Unfortunately, it's quite a trial and error process as the documentation isn't very helpful in where a definition is used. For example: 'string_1', 'keyword_3', and lots of others aren't mentioned anywhere. It also would have been nice if there's a oldnew name list. See the [styling] section in each filedef to see where they map to the old language-specific styles. For example, here's an extract of the PHP style mappings from filetypes.xml:: php_default=default php_simplestring=string_1 php_hstring=string_1 php_number=number_1 php_word=keyword_1 php_variable=preprocessor php_comment=comment php_commentline=comment php_operator=operator php_hstring_variable=string_2 php_complex_variable=keyword_2 My filetypes.xml in /usr/local/share/geany doesn't list any mappings but I guess the mappings are defined in the filetypes.html file because of this tag: [styling=HTML] In filetypes.html there's a quite different definition than yours, probably after the change on November 9th[1] Ah right, the ones in my home dir aren't up-to-date. Actually, maybe I didn't update geany-themes after that commit, so thanks for reminding me if I didn't. I'll add your changes to geany-themes shortly, thanks! Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Issue with geanyLaTeX after GtkBuilder: Help needed to debug
On 12/31/2011 02:57 AM, Frank Lanitz wrote: Hi folks, Since about GtkBuilder come in into Geany core we are experiencing some issue with GeanyLaTeX in terms of in some cases the toolbar is not able tobe loaded and Geany is ending up inside a segfault. Most likely its repreducable by activating the toolbar and restarting Geany having a tex-file loaded. The issue seems to be located in near of line https://github.com/geany/geany-plugins/blob/master/geanylatex/src/geanylatex.c#L168 unfortunately I don't have any bloody idea, what might is going wrong. Anyone else could jump in here? Attached is a patch to fix the issue. It's the same bug in Geany where this code was probably copied from, so I'll fix Geany and leave it to you to apply this patch to the plugin. If either Geany or GeanyLatex is fixed the plugin will be fixed, but for correctness I guess they should both be fixed. IIUC what's happening is Geany's variable (toolbar.c:toolbar_markup) is declared const but not static so it's global to the entire program. When the plugin is loaded (at runtime with dlopen) with the same variable name also declared const, the one previously defined in Geany is used instead. If Geany's is declared static, GeanyLatex uses it's own variable because it can't see Geany's, if it's declared static in GeanyLatex, the local scope wins I guess. So what was happening was GeanyLatex was loading Geany's toolbar XML string constant instead of it's own (which obviously is a problem). I'd love to know why this changed all of the sudden though, why it's different from before. Cheers, Matthew Brush diff --git a/geanylatex/src/geanylatex.c b/geanylatex/src/geanylatex.c index e1bab6e..a27c98b 100644 --- a/geanylatex/src/geanylatex.c +++ b/geanylatex/src/geanylatex.c @@ -124,7 +124,7 @@ const guint ui_entries_n = G_N_ELEMENTS(format_icons); /* fallback UI definition */ -const gchar *toolbar_markup = +static const gchar *toolbar_markup = ui toolbar name='glatex_format_toolbar' toolitem action='Wizard'/ ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Replacing the control socket with dbus
On 01/01/2012 11:47 AM, Arthur Skowronek wrote: - the protocol itself is prone to a dry lock in the doclist command - poorly written client code can dead lock geany for a few seconds Can you file bug reports for these? (assuming they aren't just theoretical problems but actual bugs) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Empty project properties dialog
On 12/26/2011 01:37 PM, Jiří Techet wrote: Hi, I'm experiencing a bug where the project properties dialog is empty when opened for the second time. Steps to reproduce: 1. Open project properties dialog. 2. Close it. 3. Open it for the second time. Result: the project properties dialog is much smaller and it's empty. I suspect it's related to the GtkBuiler transition. I haven't looked into it because I guess Matthew knows better what might be wrong. Hi, I haven't yet found a decent way to fix this without re-writing *a lot* of code around the projects dialog, so if anyone has any ideas on a quick fix or wants to fix up properly themselves, feel free :) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Issue with geanyLaTeX after GtkBuilder: Help needed to debug
On 12/31/2011 02:57 AM, Frank Lanitz wrote: Hi folks, Since about GtkBuilder come in into Geany core we are experiencing some issue with GeanyLaTeX in terms of in some cases the toolbar is not able tobe loaded and Geany is ending up inside a segfault. Most likely its repreducable by activating the toolbar and restarting Geany having a tex-file loaded. The issue seems to be located in near of line https://github.com/geany/geany-plugins/blob/master/geanylatex/src/geanylatex.c#L168 unfortunately I don't have any bloody idea, what might is going wrong. Anyone else could jump in here? Can you post a full traceback from gdb with debugging symbols? IIRC the toolbar was already using GtkBuilder and is not in the same .glade file as the rest of the UI (and theoretically shouldn't be affected by it). Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Just another github question: Easy way to pull pull reuqest for testing purposes?
On 12/31/2011 01:31 AM, Frank Lanitz wrote: Hi folks, During the last weeks I merged a couple of pull requests into geany-plugins. During this work I found it a bit annoying not finding a easy way to pull the pull request directly and test it locally and maybe add it to me git repo. Is there any direct way on doing this instead of going to offerer's github page and clone the complete repo? I'm going to take a few minutes to go through it in order to document, in exchange *YOU must post this on the Wiki* (after testing) :) Ok, you have your official `geany-plugins` repository from doing: $ git clone g...@github.com:geany/geany-plugins.git $ cd geany-plugins/ Then say you want to check out pull request #7[1], it's from user `cushy007` on his/her fork, so: $ git remote add -f \ cushy007 https://github.com/cushy007/geany-plugins.git Now you have their remote and have fetched their branches (I think). Then, in this case the requester is working straight on the `master` branch (tsk tsk), so you need to pull it into a different local branch, so maybe: $ git checkout --track -b cushy007-master cushy007/master Which says checkout a new branch named `cushy007-master` from the remote `cushy007` and branch `master` and track it. Now you can try out the changes and make some fixes, maybe with new commits. If it's out of date with the main `master` branch, you can rebase it on top (which will probably make the Pull Request feature not realize you've accepted the pull request on Github): $ git rebase master [hopefully not fix conflicts] But this will change the history compared to the Pull Requester's history, so ideally you will not do this and worst case there will be a merge commit (I don't really understand this but it seems to be how it works). Then get back to the main `master` branch when you're done and merge this Pull Request in: $ git checkout master $ git merge cushy007-master Sometimes if the pull request is not really usable, like the author is not specified, or there's lots of noise, you can just pull in their branch as above, and then switch to the master branch and cherry pick their specific commit: $ git checkout master $ git cherry-pick e6a41b574fdbed04fc5c582d90b26d8d727898dd Which will strip that commit out of their branch and apply it to master (ideally). Then if you need to set the author properly or make changes, you can just do: [make changes] $ git commit --amend --author Real Proper Author a...@email.org Which will again probably clobber their history, but they should've made a better patch :) Then just push it as normal to the main repository: $ git push origin master Finally, go to Github to see if the Pull Request was automatically closed or whether you should close it manually, noting any applicable commits in the comments. At the end, if you don't think you'll use `cushy007`'s remote any more, you can remove it (though it doesn't hurt to leave it): $ git remote rm cushy007 P.S. I'm not a Git master, I just kind of walked through this while writing and using my few experiences with pull requests, so it's probably not 100% the best way. Cheers, Matthew Brush [1] https://github.com/geany/geany-plugins/pull/7 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Issue with geanyLaTeX after GtkBuilder: Help needed to debug
Thanks, Will check it out in a while and see if I can spot anything. Cheers, Matthew Brush On 12/31/2011 03:16 AM, Frank Lanitz wrote: On Sat, 31 Dec 2011 03:04:13 -0800 Matthew Brushmbr...@codebrainz.ca wrote: On 12/31/2011 02:57 AM, Frank Lanitz wrote: Hi folks, Since about GtkBuilder come in into Geany core we are experiencing some issue with GeanyLaTeX in terms of in some cases the toolbar is not able tobe loaded and Geany is ending up inside a segfault. Most likely its repreducable by activating the toolbar and restarting Geany having a tex-file loaded. The issue seems to be located in near of line https://github.com/geany/geany-plugins/blob/master/geanylatex/src/geanylatex.c#L168 unfortunately I don't have any bloody idea, what might is going wrong. Anyone else could jump in here? Can you post a full traceback from gdb with debugging symbols? IIRC the toolbar was already using GtkBuilder and is not in the same .glade file as the rest of the UI (and theoretically shouldn't be affected by it). Dammit. With current geany build I cannot reproduce the crash, only a huge number of warnings Geany-INFO: Loaded: /home/frlan/local/lib/geany/geanylatex.so (GeanyLaTeX) (geany:10190): Gtk-CRITICAL **: IA__gtk_action_get_sensitive: assertion `GTK_IS_ACTION (action)' failed (geany:10190): Gtk-CRITICAL **: IA__gtk_action_get_sensitive: assertion `GTK_IS_ACTION (action)' failed (geany:10190): Gtk-CRITICAL **: IA__gtk_action_get_sensitive: assertion `GTK_IS_ACTION (action)' failed (geany:10190): Gtk-CRITICAL **: IA__gtk_action_get_sensitive: assertion `GTK_IS_ACTION (action)' failed (geany:10190): Gtk-CRITICAL **: IA__gtk_action_get_sensitive: assertion `GTK_IS_ACTION (action)' failed (geany:10190): Gtk-CRITICAL **: IA__gtk_action_get_sensitive: assertion `GTK_IS_ACTION (action)' failed After I activated the toolbar inside plugin configuration dialog I got: Gtk-WARNING **: New: missing action New Program received signal SIGTRAP, Trace/breakpoint trap. 0x7540b888 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 (gdb) bt #0 0x7540b888 in g_logv () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7540bc02 in g_log () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2 0x779ebda2 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #3 0x779eba05 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #4 0x779eba05 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #5 0x779ef431 in gtk_ui_manager_ensure_update () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #6 0x779ef4a9 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #7 0x70ab0ab9 in init_toolbar () at geanylatex.c:172 #8 0x70ab3a47 in on_configure_response (dialog=optimized out, response=optimized out, user_data=optimized out) at geanylatex.c:253 #9 on_configure_response (dialog=optimized out, response=optimized out, user_data=optimized out) at geanylatex.c:183 #10 0x75cd3804 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x75ce578a in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #12 0x75ceee11 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x75ceefb2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x75cd3804 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x75ce578a in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x75ceee11 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #17 0x75ceefb2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x77833dc5 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #19 0x75cd375a in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x75ce4f7a in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x75ceee11 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #22 0x75ceefb2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #23 0x77832bed in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #24 0x778dc418 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #25 0x75cd375a in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #26 0x75ce55bf in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #27 0x75ceebe3 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #28 0x75ceefb2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #29 0x779f5301 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #30 0x778da5d3 in gtk_propagate_event () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #31 0x778da933
Re: [Geany-devel] Just another github question: Easy way to pull pull reuqest for testing purposes?
On 12/31/2011 05:45 AM, Thomas Martitz wrote: Am 31.12.2011 13:03, schrieb Matthew Brush: Now you can try out the changes and make some fixes, maybe with new commits. If it's out of date with the main `master` branch, you can rebase it on top (which will probably make the Pull Request feature not realize you've accepted the pull request on Github): $ git rebase master [hopefully not fix conflicts] Please, DO NOT EVER rebase other people's work if you're going to push it into the main repo. It breaks their history and thus all of their clones. And it probably, as mentioned, breaks github pull request handling as well. If they're working on a topic branch (which they should be), once their topical changes are committed to master, they have only to do: $ git branch -D my_pull_requested_branch $ git pull origin master # to get the real new changes And they still get attribution and the history isn't littered with sloppy commits :) I could be mistaken though, like I said, not a Git expert. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Session Management Interim Solution Proposal
On 12/31/2011 03:27 PM, Lex Trotman wrote:
Hi All,
Seasons greetings to all.
New year new idea.
Since Gnome seems to have irretrievably broken X session management it
does not seem likely that proper session management will be solved in
the near term. Sadly this seems to waste all the good work that the
guys put into the SM branch, thanks for the effort.
I am going to suggest an interim change to Geany that will at least
mean that it will re-start with the same main settings and
preferences. Actually two options.
1. Although I have argued against it in the past, having all settings
save on change would at least ensure that a Geany killed by logout or
shutdown will still restart with preference/session changes intact, or
It's not too bad actually, I've done it before, just keep a callback
handler that runs when the machine is idle, then you'll just get a
little blip here and there of activity on the disk and CPU. Something like:
static void on_idle_save(gpointer user_data)
{
/* Write out to disk here */
g_file_replace_contents[_async] (...);
}
/* Call this whenever settings change */
void queue_config_save(void)
{
static guint id = 0;
if (id 0)
g_source_remove(id);
id = g_idle_add_full(on_idle_save, G_PRIORITY_LOW, NULL, NULL);
}
I don't think you'd notice any performance hit unless your config files
were on another computer or floppy disk or something. If the GIO async
functions are used, I don't think even that would matter since it'd run
in another non-GUI thread.
2. add a user action to save preferences/session.
Meh, this shouldn't be something a user should have to care about IMO.
My problems with 1. are the performance impact of writing the session
file list every time a file is opened, closed or tabs re-ordered and
the risk of corruption that that increase in file activity causes
(especially with multiple instances).
It'd definitively need to be tested, maybe doing something to ensure the
file access is particularly slow (like on a samba share or something)
while testing. I think the GLib/GIO file saving functions are atomic
so there shouldn't be too much issue with multiple instances writing to
the same file.
I guess all this trouble is why GNOME applications are heading towards
GSettings and such.
Cheers,
Matthew Brush
My problem with 2. is I will forget to do it.
Perhaps a mixed solution of preferences always saved, but session only
when the user asks is the way to go.
Any thoughts and suggestions?
Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Replacing the control socket with dbus
On 12/31/2011 08:26 AM, Arthur Skowronek wrote: Hi, http://memegenerator.net/cache/instances/400x/12/12436/12734680.jpg with this little stupid meme I would like to start a discussion about replacing the current control socket living somewhere in the ~/.config/geany directory space with implementing GApplication from recent GLib versions. As it looks to me the current tasks of the control socket are: * ensure some basic uniqueness (open files via the geany command in an already running instance) * provide ability to perform basic operations on a running Geany instance like - opening files - go to a certain position in the file. - obtain a list of documents opened in the current instance These tasks can be accomplished with GApplication too. On top of that we would get rid of: * cluttering the filesystem with sockets * possibility of a dead lock in the doclist command * general freeze while a client is connected to the socket. The downside would be that the required version for GLib would be pushed to 2.28 and this version is not available on the stable branch for all distributions. My suggestion therefore is to put this at least on the Todo list and replace it with the planned feature to use dbus. On top of that I would offer my free time to work on this topic as soon as all requirements are met, if appreciated. As the others have said the two key issues here are 1) too new GTK/GLib version and 2) dependence on DBus which I'm going to guess isn't easily working and installable on Win32/OSX? There's lots of other stuff you can help out with though :) Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] VTE Ctrl-C to kill
On 12/30/2011 10:26 AM, David Gomes wrote: Hey guys, I'm working on a project that uses VTE, and since GNOME crew wasn't so helpful, I was wondering if you did anything particular to allow Ctrl-C to kill the current process in the terminal of Geany. Was it default or did you have to create that custom key binding? Thanks. Use the source[1] Luke! P.S. Geany is probably the only VTE program for me (including my own) where Ctrl+C doesn't do what it's supposed, instead it clears the VTE (which is wrong) and then freezes (which is especially wrong). So you might have better luck looking at the source for GNOME-terminal or Xfce-terminal which both just kill the processes and return immediately to the same prompt. Cheers, Matthew Brush [1] https://github.com/geany/geany/blob/master/src/vte.c#L322 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Is the field type of struct GeanyProject used somewhere
On 12/30/2011 08:28 AM, Johann SAUNIER wrote: Hi, I'm trying to hack geanyprj plugin to add the current project's name in the main window's title bar, the same way gproject does. What I plan to do is using the field name of the GeanyProject structure. This struct contains a field named type that means Identifier whether it is a pure Geany project or modified/extended by a plugin. but I can't find out where it is used. Any idea ? I don't think you're supposed to modify the members like `project-name` even though it's not documented or enforced. I'm not sure how GProject does it but a quick scan of the source suggests it doesn't modify this member (I didn't look too close though). Maybe Jiri can say for sure how GProject does it. For the `project-type` member, I have no idea what it's for, but it's not used by Geany or any plugins from what I can tell. I'd say just ignore it or file a bug report that it should be deprecated or better documented. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
