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] 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] Moving RC styles to a file
On 12-09-29 11:43 AM, Colomban Wendling wrote: Hi guys, I'm considering moving our hard-coded custom styles (notebook tab button sizing, monospaced search entries and unmatched search entries) to an external resource file (geany.gtkrc in the datadir) -- patch attached. The main reason to do this is to make it easier to replace this by a CSS file for my GTK3 port (attempt). However, we can see a few other interesting (or not) points: + this removes some hard-coded stuff in a few places; + this actually removes an overall of 16 lines, and actually 39 lines of code (those 23 lines being in the resource file); + easier to replace with a CSS file in the GTK3 port (and gives the same advantages than with the RC files); - that's another file to load. + less memory required for the whole runtime (ie. file contents can be freed from memory after parsing). So the question is, are we happy to load another file at startup, besides the Glade XML? I don't think it's a performance problem, moreover the file being probably stored in a near location to the Glade file, but since we always tried to load as less files as possible, do we want to add this file? Since now we need to load the Glade file anyway, I think it's less of a concern to add additional external files. If we think external files are OK, maybe we'd like to also move our custom images out of images.c to normal files in out datadir. Actually, we currently have 7 inline images (aladin (logo), build, close all, and two save all, and the two used in the completion popup), but also "normal" icons (for the symbol list for example). So, what do you think? Sounds reasonable to me. If we do want to embed some stuff into the executable later because startup time becomes too slow, there are cleaner and more automated ways that can be done by the build system, like using Resources on Windows or using something similar to exo-csource/xxd or GResource. 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 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] 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
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
[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 01:59 PM, Matthew Brush wrote: 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 Somehow without --disable-perl-regexp it's only 1.15 MB and seems to still have no dependencies that'd need to be shipped with 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] 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
[Geany-devel] Ship with Grep on Windows?
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.). ___ 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=detail&aid=3451427&group_id=153444&atid=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] Improved syntax highlighting for Forth
On 12-08-14 04:59 PM, o...@newmail.ru wrote: Hello to all! I really enjoy using Geany as an IDE for embedded programming. I often use Forth language but syntax highlighting for Forth in Geany recognizes only one "primary" keyword set. So, this is a patch for adding "keyword","defword","preword1","preword2","string" keyword sets (as in Scintilla source) diff --git a/data/filetypes.forth b/data/filetypes.forth [...] Hi, I applied it in this commit: https://github.com/geany/geany/commit/e20a57927dc6b760611c8ea2fb72bd43ffc507b4 I don't know Forth language but the changes look ok and it doesn't break with some sample code pasted from the web :) 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] 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 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-05 04:47 AM, Frank Lanitz wrote: On Sun, 5 Aug 2012 10:21:04 +1000 Lex Trotman wrote: On 5 August 2012 03:40, Matthew Brush 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-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
[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] 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
Re: [Geany-devel] patch: separated session/local config
On 12-08-03 10:05 AM, Dimitar Zhekov wrote: On Thu, 2 Aug 2012 10:57:22 +1000 Lex Trotman wrote: So I think we should keep Dimitars patch available for as long as he cares to maintain it so individual users can add it if they want, but the variability makes it inappropriate to commit to Geany. If the changes were properly guarded out and disabled by default at compile-time, I see no reason not to merge the patch into master. I haven't really reviewed the changes in detail though. IMO, the patch tracker on sf.net is barely a step up from being local to Dimitar's hard-drive in terms of exposure and usefulness to general users. Pretty much infinitely, Geany without sm would be a big downgrade to me. I'm not going to support the git branch though, and it's already out of date. I don't mind keeping the Git branch up to date if it helps keep some exposure on this useful patch, but it seems I don't get emails when the patch tracker is updated, so I dunno. I'm "Monitoring" the patch tracker but apparently I wasn't "Watching" it, so maybe now I'll get emails when there's updates now that I'm "Watching" it (unless I also have to "Like" it or "Friend" it or something). Of course if you want me to take the Git branch down instead, I can do that too. 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] 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] 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] OSX build error: ld: unknown option: --export-dynamic
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. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Dropping Waf support?
On 12-07-16 10:36 AM, Enrico Tröger wrote: Hey all, this topic has been brought up already a couple of times, for example on [1]. What do you think about dropping Waf support in Geany and in the Geany-Plugins project? While I was defending Waf in Geany, I somewhat changed my mind. Not because I don't like it anymore, but I increasingly see the efforts in maintaining two (to be exactly three for Geany) build systems is too much. Since the make/MSYS build system support seems to get better and better due to Nick's and Dimitar's work on it, I thought about dropping the Waf support. It seems nobody knows it well enough and probably except for a few users nobody is using it. (And obviously I don't do so much anymore and also lost a bit interest in maintaining forever.) The other thing is that Waf causes often problems for distro packages, especially for the Debian folks [2]. So, I'd go the easy way in this case and just remove Waf. Then we only need to maintain the autotools based build system for non-Windows systems and the make based for Windows. For Geany-Plugins, we would need to get something working on Windows but maybe we could re-use Geany's make based system for Windows here. What do you guys think? Sounds fine to me as long as it doesn't mess up your great Windows builds. In a perfect world we could also eventually drop (or not rely on) the Windows Make files too since it seems like with a proper Mingw/MSYS setup the Autotools stuff is supposed work I think. I know the last time I tried it didn't work, but it's probably not something that can't be fixed. So +1 to getting rid of Waf, also not because it's bad, just because it's extra work for little benefit (to me at least). 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] 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 wrote: Am 14.07.2012 04:20, schrieb Lex Trotman: On 14 July 2012 07:07, Sean Felipe Wolfe 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 03:59 AM, Thomas Martitz wrote: Am 14.07.2012 12:39, schrieb Lex Trotman: On 14 July 2012 20:21, Thomas Martitz wrote: Am 14.07.2012 04:20, schrieb Lex Trotman: On 14 July 2012 07:07, Sean Felipe Wolfe 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). Cheers, Matthew Brush [1] http://developer.gnome.org/gtk/2.24/GtkNotebook.html#gtk-notebook-set-group-name ___ 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 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] 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 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] 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] Third party plugin publish and third party library bundle problem
On 12-07-06 10:39 PM, Hong Xu wrote: Hi, I have developed the EditorConfig plugin for Geany <https://github.com/editorconfig/editorconfig-geany>. """ EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of *a file format* for defining coding styles and a collection of *text editor plugins* that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readibly and they work nicely with version control systems. Website here <http://editorconfig.org> """ However, I am confused how to publish this plugin. First, http://plugins.geany.org is a place for plugin list. But are the third party plugins allowed here? All the pages seem working for the plugins here: <https://github.com/geany/geany-plugins> including the download page, installation page. Whatever the answer is, can I put my plugin in <https://github.com/geany/geany-plugins> ? This repository seems better maintained than mine. I would assume it's OK, but you'll need to "be approved" by the Geany-Plugins maintainer. Usually if you have a useful plugin that's well coded enough, you just ask like you did and work with the maintainer and other devs to integrate the plugin. You happen to have asked right as the maintainer and other devs are preparing for a majour release, so it kind of explains the silence to your question. The second problem is that, how should I bundle a third party C library with my plugin? If the library is readily available on the target platforms, you depend on it using the build system and link it in (many plugins do this). If it's really obscure or not packaged anywhere then you could just compile its sources into your plugins'. The latter is what the Devhelp plugin does for libdevhelp since it's not packaged for GTK+2 anymore on the target platforms, but it's still quite a stupid thing to do. P.S. If you don't get any further with adding your plugin to the project, wait until you see the release announcement for Geany-Plugins here then you will know when people will be freed up more to help 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] 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 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
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
[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 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 Glidic 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-08 05:44 AM, Colomban Wendling wrote: Le 08/05/2012 02:03, Lex Trotman a écrit : On 8 May 2012 02:04, Nick Treleaven 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 08:32 PM, Lex Trotman wrote: On 8 May 2012 13:27, Matthew Brush wrote: On 12-05-07 05:03 PM, Lex Trotman wrote: On 8 May 2012 02:04, Nick Treleavenwrote: 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-07 05:03 PM, Lex Trotman wrote: On 8 May 2012 02:04, Nick Treleaven 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,
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 add..." 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 Brush 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 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] 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] 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-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-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
Re: [Geany-devel] Default keybinding for Zoom In
On 12-03-18 07:33 PM, Colomban Wendling wrote: [...] OK, it's fine then, it's just what I'm used to using in the programs I use most of the time, except Geany. I don't use zoom in most programs though, so I didn't notice their default keybindings. So you probably got it: I don't think it's a good idea. BTW, for the record, what are the applications using the "normal" keybinding you'd like to see (^=)? A few I have under the hand: * Mozilla products allows both * gnome-terminal only accepts+ (no kp support) A couple more I've tried that do support equals (probably in addition to plus): * Chromium * Evince * GtkImageView (apparently, I didn't try, but going from docs) Anyway, it makes sense not to change it, especially since it's so easy to change as a user. Cheers, Matthew Brush ___ 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 plus, which sounds right, but it should really say plus, since you have to press Shift to get the plus symbol. The correct default keybinding for Zoom In should be equal, 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
Re: [Geany-devel] Gathering Release 1.22 incompatibilities
On 12-03-18 05:20 PM, Lex Trotman wrote: Hi All, I recently ran into Nicks change of the default keybinding-t from transpose to gototag. This made me realise we need to keep a list of incompatibilities to add to the release notes when 1.22 is released. I don't know if I'd consider changing a default keybinding an "incompatibility" as such. IMO, unless something breaks as a result of an upgrade, it's not really incompatible. I would have thought that anything incompatible would have been forgotten by then unless we keep a running list, at the moment all I can think of is the ctrl-t and themes, but I am sure there are others. The only real incompatibilities I can think of are the filedefs/color schemes, changes to the plugin API, and the GTK+ version bump. The list also saves Git blaming to try to see what made the change and if it is deliberate or not. So any suggestions on how we should gather these? and of any more of them. We could, at release-time, just manually scan the ChangeLog (and/or Release Notes) and add an asterisk to each item that changes defaults or breaks compatibility, with a note at the bottom of the list to explain what the asterisk means. 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 Reply-To: Xfce general discussion list 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 01:29 PM, Frank Lanitz wrote: On Sun, 04 Mar 2012 13:01:27 -0800 Matthew Brush 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 Wendling 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] 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 Wendling 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-03 06:28 PM, Colomban Wendling wrote: Le 04/03/2012 02:01, Jiří Techet a écrit : On Mon, Feb 27, 2012 at 08:33, Matthew Brush wrote: 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? [snip] Just to give everyone who hasn't checked the commits an idea of the verbosity that those commit messages has. Is it too verbose? I was trying to add some more detailed info because from my experience even though the patch seems to be clear now, when looking at it one year later I often feel like "what does the hell the patch do?" and "why did I write something like that?". But if it's the preferred way I can move the explanation into the merge comment on github. Nope, it's fine IMO -- and I think Matthew quoted them just to tell Frank that despite the unclear merge message the commits themselves were well explained. Correct, they had some *really* good commit messages. The only problem was with my "default" merge messages I think. By the way, because the patches I submitted weren't related in any way, I think they could have been rebased on top of master instead of doing merge. Agreed, I prefer not to see merges where there's no relation between several (2+) commits. I guess I did it like that because it was a single pull request. I'll ask in the future when I'm not sure. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Where have the thirdparty plugins gone?
On 12-03-01 02:52 PM, Dominic Hopf wrote: Hi everyone, Lex pointed me to the issue, that the pages for the third-party plugins at http://plugins.geany.org/ are empty. I have to admit, that I maybe am not that up-to-date and thus, am not sure what actually happened to those plugins. Last thing I know of them is, that they were in the same SVN repository at SourceForge as Geany-Plugins. After the migration to GitHub they are gone - I guess that is intended. Does anyone know what happened to them? Do they exist anymore and just in another place? Or should I really remove them from the website? Regards, Dominic Hi, For as long as I can remember those 3rd party plugins pages have been blank there. Geany Mini Script was always outside of the "real" plugins source tree in SVN and was removed for Git. IIRC someone has recently shown interest in maintaining it and so IMO it should go into Geany-Plugins proper (ie. not 3rd party) with a working README. I have no idea what the other 2 are for, but like I said, I've noticed them before and IIRC they never had any content there or code in the Geany-Plugins project (at least since I've been around, maybe Git can tell for sure?). 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] 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] [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 Brush Committer: Matthew Brush 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 @@ GC
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 Wendling 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 Brush 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 Trotman 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:<> 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 Zhekov wrote: On Wed, 1 Feb 2012 11:24:01 +1100 Lex Trotman wrote: On Wed, Feb 1, 2012 at 5:20 AM, Dimitar Zhekov 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
[Geany-devel] Ideas for reducing duplicate bug reports
Hi, The subject pretty much explains it. I have a couple theories why there's so many duplicates: - SourceForge.net is kind of hard to use, especially searching - No login required makes it "too easy" for people to quickly post bug reports without thinking too much as soon as they experience a bug Anyway, I just wanted to see if anybody had any ideas for how we could minimize duplicate bug reports since it's a quite a pain to keep up with the all the report as it is, especially with things like GTK+ bugs where a distro upgrades their GTK+ and we get a pile of duplicate bugs about the same non-Geany bugs. Two recent examples come to mind: - GTK+ file chooser dialog bug causes Geany to crash - DBus menu bug causes console spam and non-functioning menus Both of these had more than 3 or 4 duplicate bugs reported already, even when some of the other duplicate reports were already on the first screen you see before you post a bug. Both have been fixed in Git, but bug reporters won't know this unless they first check for duplicates and see that we've fixed it. Ideas would be appreciated. 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 Brush 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] 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] 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/25/2012 08:01 AM, Nick Treleaven wrote:
On 25/01/2012 13:19, Nick Treleaven wrote:
On 24/01/2012 03:30, Matthew Brush wrote:
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.
If the function and its parameters are well named this isn't a big
problem.
BTW I think you don't need to worry about not using the utility
functions, if the equivalent code is not too bad.
Good to know :)
Out of interest, which functions are the most annoying, any in particular?
It's mostly the little ones in utils/ui_utils[1] that wrap common C/GTK+
stuff, like the last two I whined about lately, or as we discussed a
while back, single use static functions that some people find harder to
read compared to putting that code into the function that uses it.
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.
When have I ever suggested doing that?
I may have overreacted there, sorry ;-)
Not at all, it was a bad example indeed, I just wanted some code to show
where the code is obscured by being in another function and file, that's
the only purpose of the example.
I think your EZG macro was a bad example, because:
Yeah, it was just a quick example off the top of my head, I truly
shouldn't have put a macro in the example, since a function would've
shown what I meant without being absurd.
* it has a bad name (I accept NZV has this problem)
Heh, that's why I chose that name :)
Cheers,
Matthew Brush
[1] Just at a very quick scan through utils.c, things like
utils_slist_remove_next(), utils_is_uri(), utils_string_replace(),
utils_spawn_async()*, utils_build_path(), utils_make_filename(), and so on.
* might be needed for win32 or something (shouldn't though)?
___
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 Trotman wrote: On Thu, Jan 19, 2012 at 11:53 PM, Nick Treleaven 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] 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
[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] Whither goest CTRL-Q?
On 01/13/2012 05:04 PM, Ross McKay wrote: Lex Trotman wrote: Which version of Troll, erm oops sorry GTK/Gnome are you using, most of the shortcuts in the file menu are simply picked up as default, and as they are standard no way is provided to change them. My guess is G* has changed its default? Matthew Brush wrote: That was going to be my guess too; something with GTK+/stock items/gtkrc. I don't see a quit keybinding in Geany code (after a quick search). I'm on Fedora 16 x86-64, latest stable updates, and ./waf configure reports: Using GTK version : 2.24.8 Until recently I was struggling along with GNOME 3, and just a week ago I switched to LXDE when upgrading SWMBO's machine to Fedora 16 and GNOME couldn't handle the move (bloody accelerated graphics shmaphics; I'm running the same DE as she is so that I can answer any questions she has). Could that be part of it? I have GNOME 3 installed as well as LXDE, but I'm running the LXDE dm as well as the de. The odd thing is that CTRL-Q was working before the git pull / rebuild, and I can ssh to SWMBO's PC (similar config) and run Geany there and it still has CTRL-Q. If this is environmental, I guess I'll just have to get used to using ALT-F4 again, eh? Naw, it might actually be something in Geany. All my other GTK2 and GTK3 apps have their stock keybindings (you can see the keybinding next to the menu items), except Geany. Maybe something was broke recently? I'd blame my GtkBuilder changes, but if it's been fine until the last pull, I doubt it's that. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Whither goest CTRL-Q?
On 01/13/2012 04:19 PM, Lex Trotman wrote: On Sat, Jan 14, 2012 at 11:06 AM, Ross McKay wrote: G'day, I pulled the latest from git late yesterday, and just noticed that CTRL-Q no longer binds to Quit. a) was this intentional? b) is there a way to put this back? (can't see it in key bindings) Hi Ross, Which version of Troll, erm oops sorry GTK/Gnome are you using, most of the shortcuts in the file menu are simply picked up as default, and as they are standard no way is provided to change them. My guess is G* has changed its default? That was going to be my guess too; something with GTK+/stock items/gtkrc. I don't see a quit keybinding in Geany code (after a quick search). 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
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 Brush 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/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. 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. Because C is a crappy language we can't get the compiler to hide stuff it knows about from plugins. That is why the insistence is on only using *documented* API which we will protect by changing API/ABI. If something is visible due to the limitations of C, but not documented, no API/ABI bump is needed. In any case, the docs, especially for `project_dialog_confirmed` should be improved/fixed. Probably, but what? Namely removing this from the `project_dialog_confirmed` docs: "Warning: The dialog will still be running afterwards if the user chose 'Apply'. " AFAIK there's no Apply button for project dialog and in fact it seems like the ideal place for plugins to remove their notebook page from (I'd need to test to be 100% sure). 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 11:10 PM, Lex Trotman wrote: On Thu, Jan 12, 2012 at 1:25 PM, Matthew Brush wrote: On 01/11/2012 04:11 PM, Jiří Techet wrote: On Mon, Jan 9, 2012 at 01:05, Matthew Brushwrote: 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/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 Lanitz 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 04:11 PM, Jiří Techet wrote: On Mon, Jan 9, 2012 at 01:05, Matthew Brush 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
