Re: [Geany-devel] Separating session file lists from config (again)
On Wed, 12 Sep 2012 11:35:48 +1000 Lex Trotman ele...@gmail.com wrote: [...] So what should geany.conf contain? If the interface preferences remain there, we still must rush at quit time to save it... Getting buried in specifics far too early, need to get the principles right first, but in general interface things that are changed rarely, like window layouts, would be in geany.conf, things like search data is definitely session. I'm sure there is more discussion here :) Since it's an early discussion, I have a proposition for something I always wanted to have in the other IDE-s: several sessions per project. For example, currently I have one project for Geany sm, another for regenerating my patches (the ones in sf patch tracker except sm, plus some others), and I usually open another (temporary) project when working on something else. Aside from the session, these projects are, and must be, absolutely identical. So: The project menu contains a Sessions item, which displays a dialog to add/remove/switch to a session. Each new project starts with a Default session, which can not be deleted. Whoever prefers a project for each session can simply ignore Sessions. Possible storage: $project.geany contains an UUID. $confdir/UUID contains a list of names sessions and the interface options, including the current session name. The larger a project, the more useful several sessions will be. I'm not sure about several project-less sessions. It will be somewhat confusing - should I use a project, or only a session? - but OTOH, the line between projects and sessions will be drawn once and for all: a project has it's own set of options, while a session is simply a set of files. RFC. (Note: the project files currectly contain the settings from Project - Properties and a session, but no interface options. The plugins can only place their own settings in the projects either, except by using the Project - Properties dialog.) Plugins access to the project files is another discussion. They must be discussed at some later point, we have save-settings and project-save. -- E-gards: Jimmy ___ 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 Tue, 11 Sep 2012 09:17:52 +1000
Lex Trotman ele...@gmail.com wrote:
All settings in Edit - Preferences and Project - Properties are
saved ASA the dialog is confirmed. Some time ago, Build - Set Build
Commands were modified to be saved immediately as well.
The only settings that are really saved on exit are the interface
ones (check/radio menu items, find/FIF settings etc.). The Preferences
and Properties are still saved on exit, but only because nobody cared to
separate them.
The idea is that anything in geany.conf (or project.conf) would be
saved on change.
So what should geany.conf contain? If the interface preferences remain
there, we still must rush at quit time to save it...
2. Save session data periodically, or as it changes, or whenever,
without touching the config/project files. So the config isn't at
risk if the session save goes wrong.
...and if we keep these preferences it in the .session file(s?), we risk
damaging them on some periodic save. Not so bad as losing geany.conf,
of course, but still unpleasant.
( Would be nice, but saving the session only (without the settings)
in the current files is completely possible.
Sadly its not, keyfiles re-write the whole file, not just the bits
that are changed. So to save something by itself it has to be in
another file.
I meant that loading a keyfile, replacing the session entries and saving
it is possible. But yes, that's irrelevant.)
The proposal is that each project gets a UUID generated when it is
created (or when its opened without one) which is saved in the project
file. This uuid is the name of the session file in the
${GEANY_CONFIG}/sessions directory. [...]
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.
[...] So we are only speaking about the users that want the future
settings-only project file [in VCS] but not the session.
Yes, and I would expect that to be everyone who keeps a project file
in *public* VCSes, nobody else in the world cares which files you had
open last time you did something on the project.
If by public you mean somewhere in the internet, I haven't seen a
single OSS that includes with $project.geany, not even Geany itself or
geany plugins.
Surely they can make a little effort to achieve that?..
Clearly you are not one of them or havn't had to try to repair commits
that have included extra files because you forgot to edit .gitignore
or equivalent. :)
No, I use mostly svn. But removing file(s) from finished commits should
not be easy (and Mercurial does not even allow it IIRC). Yet how is
that our problem? And if it is, why should we even allow project files
in the project tree? They can be shipped by mistake equally well.
Moving the projects and sessions in ~/projects, ${GEANY_CONFIG}/projects
or wherever can somehow be justified. But having the projects here-or-
there, and the sessions yet somewhere else via redirection, is a mess.
It's a bit surprising that you, of all people, proposed such a thing.
[...] The situation has improved a bit, now that Xfce will have
proper sm, and handling the quit message under Win~1 is only a matter
of somebody writing it (not me, I don't use Geany inder Win~1). I'm
sure that MAC notifies the programs too, but have no idea how.
The word *portable* still applies, but if you create
dimitars_all_platform_window_management_library_including_osx_windows_gnome_and_unity
then maybe :)
There are ~90 #if[n]def G_OS_WIN32 in Geany source. Expecting the
session save to be operating-system portable is a bit too much.
I have previously asked for somebody to check if SM works under GNOME3
and Unity, but there was no response.
On Sun, 09 Sep 2012 21:50:02 -0700
Matthew Brush mbr...@codebrainz.ca wrote:
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.
Just to clarify, stuff too like window/find dialogs means the
interface options. If they are per session file, each project will have
it's own appearance, something that Geany does not currently support.
(Except with SM, and I find it very useful.)
But why stop half way? Let's have the current geany.conf/foo.geany
for the Preferences and Properties respectively, a *.session file for
the session and active tab [position within the file and the per-file
settings are always stored along with the file name], and an *.interface
file for the interface settings. This is the most logical solution,
corresponding exactly to the different groups of settings. (Should I
add a :) here? Hmmm...)
What? Why not a file per setting, then it would all work fine. Just
make geany.conf a directory and switch to project.geany directories.
:)
If we decide to continue with the single appearance
Re: [Geany-devel] Signal Handling
On Sun, 09 Sep 2012 19:41:19 -0700 Matthew Brush mbr...@codebrainz.ca wrote: On 12-09-09 05:23 PM, Lex Trotman wrote: [...] So can anyone describe a useful use-case for catching SIGTERM and potentially refusing to exit? And also for SIGINT. From what I see, signal_cb (used currently for SIGTERM only) looks like a naive attempt to replace the session management. That will never work, of course - either the WM will send a SIGKILL quickly (in 1-2 seconds), or the entire X will terminate, killing Geany. BTW, I'm happy to inform all Xfce users here that it's session management was fixed and pushed to git, so we may expect it with the next xfce-session versions. Using the Action Buttons plugin with Shutdown or Restart will still not work, but that's a different bug. Or maybe a feature, because the session settings specifically include the text ... on logout. 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. My whole X terminates if I run it from a virtual console and press Ctrl+C, so why should Geany handle the signal? Is this a normal practice for the GUI programs under X than I'm not aware of? And of course, the portability of signal(2) is so bad that only SIG_DFL and SIG_IGN can be trusted. -- E-gards: Jimmy ___ 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 Mon, 10 Sep 2012 14:36:32 +1000
Lex Trotman ele...@gmail.com wrote:
Its about that time of year when we have our annual discussion on
separating session data from config/project data :)
Let's not forget the multiply instances that share their configuration
to (some) extent. We love to discuss them. :)
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)
All settings in Edit - Preferences and Project - Properties are
saved ASA the dialog is confirmed. Some time ago, Build - Set Build
Commands were modified to be saved immediately as well.
The only settings that are really saved on exit are the interface
ones (check/radio menu items, find/FIF settings etc.). The Preferences
and Properties are still saved on exit, but only because nobody cared to
separate them. (There is more to it, but I don't want to start the
multiply instances discussion now.)
2. Save session data periodically, or as it changes, or whenever,
without touching the config/project files. So the config isn't at
risk if the session save goes wrong.
Would be nice, but saving the session only (without the settings) in
the current files is completely possible. In what situation saving the
session will damage Geany configuration, but saving the interface
sessings on exit will not?..
The only disadvantage for user config (that I can see) is that it adds
one file, say geany.session.conf alongside geany.conf
For project sessions just using another file in the same place as the
project file is more of a problem since project files can be in the
project tree and some people like to save them in VCS. So users would
have to make sure that their git.ignore (or whatever the other VCSes
use) is edited each time so that the session file isn't saved in the
VCS.
A better option, especially since sessions are inherently user
related, is to store them in the user config location (or subdirectory
thereof). But how to link these files to the project files?
The proposal is that each project gets a UUID generated when it is
created (or when its opened without one) which is saved in the project
file. This uuid is the name of the session file in the
${GEANY_CONFIG}/sessions directory. [...]
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.
Oh c'mon. Is adding a file to git.ignore so serious problem that we
need to implement redirection and bother to control the list of
session files? The ignore in VCS-es is specifically _designed_ to
ignore files. The users that prefer to keep their foo.geany in the
project directory, but don't want them in the VCS, have already
exlcuded it. The ones that prefer to keep foo.geany in the VCS will not
ignore the .session file either. So we are only speaking about the ones
that want the future settings-only project file, but not the session.
Surely they can make a little effort to achieve that?..
This proposal isn't about a proper session management capability,
there isn't one that works on enough platforms to be worth including.
Unfortunately. The situation has improved a bit, now that Xfce will have
proper sm, and handling the quit message under Win~1 is only a matter
of somebody writing it (not me, I don't use Geany inder Win~1). I'm
sure that MAC notifies the programs too, but have no idea how.
On Sun, 09 Sep 2012 21:50:02 -0700
Matthew Brush mbr...@codebrainz.ca wrote:
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.
So that with periodic save, in the situations that Lex will describe
(#2 above), not only the session, but your interface options will break
too. OTOH, geany.config and the project files will be very stable...
But why stop half way? Let's have the current geany.conf/foo.geany
for the Preferences and Properties respectively, a *.session file for
the session and active tab [position within the file and the per-file
settings are always stored along with the file name], and an *.interface
file for the interface settings. This is the most logical solution,
corresponding exactly to the different groups of settings. (Should I
add a :) here? Hmmm...)
--
E-gards: Jimmy
___
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 Sat, 4 Aug 2012 10:58:54 +1000 Lex Trotman ele...@gmail.com wrote: My problem isn't so much with the patch, it worked fine last time I had a working DE. [...] I expect lots of I turned it on for some DE and it didn't work but firefox, gedit, etc does, fix it waaa waaa waaa if we did that. As a gtk+ application, Geany uses the legacy (X11R5) session protocol, yet we are not receiving such messages. But of course, given the xsmp support sutuation, your concern has merit. Thanks to Eugene's initial implementation, the SM functionality can be en/disabled with --enable-libsm=yes|no in configure or autogen. So I changed the default to no in the latest patch (2012-08-07). -- On Fri, 03 Aug 2012 18:14:40 -0700 Matthew Brush mbr...@codebrainz.ca wrote: 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. On Sat, 4 Aug 2012 11:47:55 +1000 Lex Trotman ele...@gmail.com wrote: So totally agree, Dimitar should be given rights to maintain this instead of the patch if he wants to. That would have been very useful while while Eugene, and later me, were developing the patch. But there are very little changes in the latest two years, I have 3 other patches in the tracker, and another 3 on my machine for a plugin I'm writing... So it's easier for me to regenerate all of them in the same way, and keep their previous version(s) as .diff files, instead of dealing N branches. I changed the latest tracker patches to .git to format though. -- E-gards: Jimmy ___ 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 Thu, 2 Aug 2012 10:57:22 +1000 Lex Trotman ele...@gmail.com wrote: 3. Multiple instances would not benefit from having user session info saved separately unless we also switched to saving the remaining config immediately it was changed, not at shutdown. View - Show Message Window - save configuration, Search - Find - save configuration... hmmm. 4. I have completely ignored session management since I am back on a DE where it doesn't work :) That is the problem with session management, it only works on some DEs and how well it works varies. Indeed. On that note, I'm happy to inform all Xfce users that the long standing bug with asking for unsaved files on logout was fixed. It doesn't seem like any dev noted, so I'll have to ring a few bells, and hopefully get it for the next release. 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. 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. -- E-gards: Jimmy ___ 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 Sat, 28 Jul 2012 18:16:03 +0300 Vladi Belperchinov-Shabanski c...@bis.bg wrote: I keep my ~/.config/geany dir under git so I can distribute my environment prefs on all machines I use. unfortunately there are some config entries which always collide since they are local to the current machine. [...] If you are using Geany under *nix, with a GUI that supports sessions (kde, xfce, maybe gnome), you can do the following: 1. Patch geany for x11 session management - see the patch tracker. 2. Don't Quit it, but logout (shutdown, restart) instead. The sm will save your configuration in a separate .conf file. 3. Using Quit, or Edit - Preferences - OK / Apply, will save your current settings in geany.conf - including the local ones. Hope this can be somewhat useful to you. -- On Mon, 30 Jul 2012 18:12:29 +0200 Colomban Wendling lists@herbesfolles.org wrote: However, maybe splitting session things out might help towards a better support for saving multiple instance configurations, and if we see that such changes would help on that subject too, the noise might be worth. Dimitar, Eugene, Nick, Matthew, Lex..., thoughts? The sm patch supports any number of separate instances, each with it's own configuration. Putting more settings into the project files will help - that's their raison d'etre in the first place. As of multiply instances that share their configuration to some(?) extent, we had this discussion at least twice, and could not reach a conclusion. -- E-gards: Jimmy ___ 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.
Forgot the attachment to my previous mail. -- E-gards: Jimmy attachment: icons.png___ 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 Tue, 10 Jul 2012 23:09:42 +0300 Axel apeka1...@gmail.com wrote: You can have any number of primary and secondary Geany instances open. With simply calling configuration save, on restart you'll get *some* file list... Wait, wait. That's a *competely* different problem. You *can't* allow users to have multiple instances of application which all write to one config file. We had several long discussions on this problem, with no conclusion reached. Try multiply instances in the mailing list archives. If that list is from a secondary (-i) instance, it'll likely only contain a file or two, and you would be better with the list from the last normal Quit Well, it's a flaw - in the end, it's not much better or worse. How you can call Geany an IDE if it looses all the open files in all instances but the last closed one? Either it's a more like a code editor (i.e. Notepad++ - limited to one instance) or it's like a serious IDE (i.e. VS or Eclipse), which, AFAIK store the separate file list for each project. Geany stores separate file list for each project if you quit it normally, or even for each running instance with session management. A list autosave on open/close should check if a project is open and save accordingly, which the patch does not do. It also seems to save the list even if the open dialog is canceled. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] session management [was: Usability fix - saving tab state]
On Tue, 10 Jul 2012 14:55:30 -0700 Matthew Brush mbr...@codebrainz.ca wrote: On Tue, 10 Jul 2012 21:20:55 +0300 Dimitar Zhekov dimitar.zhe...@gmail.com wrote: 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 :) KDE4 has prefect XSMP support, KDE3 was pretty good, don't know about Unity. Xfce is OK if you don't have unsaved files. Shouldn't bugs be filed against these projects (if not done yet) if they don't support the standard X/Linux session management? https://bugzilla.xfce.org/show_bug.cgi?id=5379. The latest Xfce has problems even with a single probram asking whether to save a modified file, so I had to disable that part. AFAIK they all claim to try and support the various standards floating around out there. As of the GNOME guys, they had a lousy support for the legacy (X11R5) session support, dropped it AFAIK, and then deprecated XSMP in favour their own session protocol in 2.24. Don't know about GNOME3. Funny thing, considering that the small Xfce has full support for the legacy protocol, and it's even supported by gtk+ - for example that's how Devhelp or Firefox are restarted on login. 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? gedit has the same problems with Xfce. Aside from the kde applications, there are very few programs with full xsmp support. 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? In no partilular order. Each instance saves it's own file list and preferences in a separate .conf file, based on the instance xsmp ID. Neither geany.conf nor the project files are saved - it works as if you suspend/resume or hybernate/restore (with some exceptions). You can of course do an Edit - Preferences - OK or Project - Properties - OK, that'll save geany.conf or the project file respectively. You can do that even after logout/login. -- On Tue, 10 Jul 2012 21:59:35 -0700 Matthew Brush mbr...@codebrainz.ca wrote: 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. Yes, that's the part that normally breaks. It might get more usage/testing/experimenting in a branch on the main repository compared to the sf.net tracker. That may well be. Though while Geany was on svn, the patches were marked with the svn release number, and thus very easy to apply, and there were two or three svn-marked versions on the ML even before that... The last notable changes were done two years ago. After that it's only tweaking for specific SM-s, more strict xsmp support, which didn't help (sigh), and updates various Geany changes. -- E-gards: Jimmy ___ 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 Tue, 10 Jul 2012 12:55:58 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: I've replaced xcopy with separate copy targets locally. Unfortunately that causes errors with subdirectories so I had to ignore them, which I'd prefer not to do. See attached diff. cp: omitting directory 'foo' errors on any subdirectories with GNU cp. [...] No, the subdir errors are with windows 'copy'. Strange. Under Linux: $ md /tmp/gx $ cp doc/* /tmp/gx $ cp doc/* ~/gx || echo some error cp: omitting directory `doc/images' some error But the patch ignores any copy errors anyway, so it woudn't matter. for cmd: 'CP_R = xcopy /s /y /i' and 'RM_R = del /s' xcopy /i doesn't seem to help here if the destination already exists (I don't think we should remove $DESTDIR). Yes, it works only for non-existing target directory. I tested the patch with cmd.exe and tcc.exe, install and re-install. All work fine, no copy error messages. On re-install, there are mkdir error messages about existing directories, geany.glade is replaced normally. That's with XP SP2 32-bit, MSYS was never installed. -- E-gards: Jimmy ___ 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 Sun, 08 Jul 2012 13:04:54 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: BTW I've run into 2 problems with the install target: 1. cp -r and xcopy treat the destination path differently. Currently MSYS install is broken and will install data files as $DESTDIR/data/data/* - I've replaced xcopy with separate copy targets locally. Unfortunately that causes errors with subdirectories so I had to ignore them, which I'd prefer not to do. See attached diff. cp: omitting directory 'foo' errors on any subdirectories with GNU cp. Wait... the _only_ 'cp' we have under Win~1 GNU cp, right? Instead of the patch, we can define CP_R as 'cp -r --remove-destination'. This non-POSIX option exists since at least fileutils-4.1 from 2001. Well, it'll remove $(DESTDIR)/data before copying, which I would prefer not to do, but there shoudn't be any user files anyway. 2. A weird problem. Installing from cmd.exe doesn't overwrite geany.glade (and maybe some other files) even though it appears to succeed. I only noticed this because I'm missing the View-Editor-Color Schemes menu which was added about a month ago (I tend to test in place rather than install each time). OMG... Then we must choose between copy and xcopy depending on which one works. Or we can define: for cmd: 'CP_R = xcopy /s /y /i' and 'RM_R = del /s' for MSYS: 'CP_R = cp -r' and 'RM_R = rm -r' and replace the '-$(MKDIR) $(DESTDIR)/data' with '-$(RM_R) $(DESTDIR)/data'. That will (a) nullify the differences between 'cp -r' and 'xcopy /s', (b) be a bit shorter than the individual MKDIR/CP commands from the patch, and (c) fix the overriding problem, since the target files will not exist - or maybe reveal something about the reason why it fails. Well, we haven't run out of options yet. I'll test the patch tomorrow. -- E-gards: Jimmy ___ 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 Wed, 04 Jul 2012 12:59:11 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: On 28/06/2012 18:55, Dimitar Zhekov wrote: BTW if you think plugins$(DIRSEP)*.dll looks ugly, we can use: plugins$/*.dll Nice. :) Though what I find a bit unpleasant is using the specific separator for a single install command, not the particular syntax. This is what I intend to do. Then why not put it for all install commands? We'll not depend on the (undocumented AFAIK) behaviour of win~1 mkdir/copy/del to treat slash as a directory separator in some cases, but not in others. 'MAKE =' seems unneeded, any GNU make defines is automatically. Sorry. Missed that. http://www.gnu.org/software/make/manual/html_node/Splitting-Lines.html (GNU)mingw32-make-3.82-5. Obviously treats \ different, since it's not an escape in C:\foo\bar. Anyway, STLIBS is a safe bet. Did you read the link? I'm talking about a backslash as the last character on the line. Yes. What I failed to read is: http://www.gnu.org/software/make/manual/html_node/Wildcard-Pitfall.html#Wildcard-Pitfall which seems to be the only mention that \ can be used for directory separator. So I assumed that mingw32-make deviates from make.info, and that may apply to trailing backslashes too. -- E-gards: Jimmy ___ 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 Thu, 28 Jun 2012 16:28:50 +0200 Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 28.06.2012 15:41, schrieb Nick Treleaven: And then perhaps use $(MAKE) CP=$(CP) RM=$(RM) to pass these variables to the sub-makefiles so they don't need to have copies of the ifdef. They only need CP and RM. Make variables are survive recursive invocations don't they? Not that I know of. Do a ./configure or ./autoges, and look at ./Makefile and src/Makefile. -- E-gards: Jimmy ___ 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 Thu, 28 Jun 2012 14:41:25 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: Yes, using a target for plugins only would be OK. What if we put the an install: target in plugins/makefile.win32? That works, needs no DIRSEP, and is very similar to the *nix installation. To avoid 'C:/Program Files/Geany already exists' on the first install, we will have to use mkdir -p, but that's the default behaviour of the cmd/tcc mkdir anyway. Attached, and the patch is git-ified this time. BTW (not included in the .diff): 'CP = copy' in doc/Makefile.win32 should be 'copy /Y'. 'MAKE =' seems unneeded, any GNU make defines is automatically. But I'm thinking of adding a MSYS variable now to make it easier: -include localwin32.mk ifdef MSYS CP = cp CP_R = cp -r RM = rm DIRSEP = / endif I thought of providing a sample localwin32.msys with the standard MSYS definitions. In all cases, -include localwin32.mk should be the last, to allow overriding. And then perhaps use $(MAKE) CP=$(CP) RM=$(RM) to pass these variables to the sub-makefiles so they don't need to have copies of the ifdef. They only need CP and RM. Then all clean: targets will fail when run from a subdirectory (and the above install: when run from plugins/). So 'make all' in src/ will work, but not 'make clean'. Hmmm... I will. While unlikely, I'll check if 'xcopy /y plugins/*.dll ...' works. I tried that here and it failed. Same here. I think because 'copy' takes /y switches the first path it sees must not use forward slashes. They are OK in the destination though. Or maybe the forward slashes work with copy if the argument matches an existing path exactly, without find first/next file involved. Not that knowing the reason will help us. No, even full paths with forward slash do not work (at least for the first of the file arguments). Same here. Gee. But it doesn't really run the SHELL, just attempts to CreateProcess (copy, ...) because a SHELL is defined. [...] It is weird that (without overriding on the command line) SHELL always is sh.exe, even when cmd.exe is obviously being used. Maybe a MinGW issue. It is as described in the manual, but why use cmd.exe then... Well, there are 2 standard ways to run an executable-or-interpreter- command under Win~1, and both are not very good. GNU make attempts to do that better, going as far as supporting a list of the internal CMD/4NT/TCC commands, and tries to support *nix shells at the same time. The old GNU make version from UnxUtils.zip is the same, so it's not exactly MinGW - more likely the 'stock' (non-MSYS, non-Cygwin) GNU Make for Win~1. Also, I think you /can/ join command lines with a trailing backslash (but your patch change is still better to have STLIBS anyway): http://www.gnu.org/software/make/manual/html_node/Splitting-Lines.html It failed on my mingw32-make, I wound't have bothered if it worked. It seemed to work for me, and the manual seems to say that GNU make interprets the trailing backslash, it doesn't pass it to the shell. I have GNU Make 3.82. YMMV. (GNU)mingw32-make-3.82-5. Obviously treats \ different, since it's not an escape in C:\foo\bar. Anyway, STLIBS is a safe bet. -- E-gards: Jimmy diff --git a/makefile.win32 b/makefile.win32 index 1add16c..4f701c9 100644 --- a/makefile.win32 +++ b/makefile.win32 @@ -10,7 +10,7 @@ # Use localwin32.mk instead of editing variables as it is included in sub # makefiles. # E.g. use localwin32.mk to set PREFIX=C:/libs instead of the default C:\libs -# For MSYS use localwin32.mk to set CP, CP_R, RM, DIRSEP. +# For MSYS use localwin32.mk to set CP, CP_R, RM and MKDIR_P. # By default this should work in a Windows command prompt (cmd.exe). WINDRES = windres.exe @@ -19,9 +19,7 @@ CXX = g++ CP = copy /Y CP_R = xcopy /S /Y RM = del -MKDIR = mkdir -# strip is used to prevent line wrap -DIRSEP := $(strip \) +MKDIR_P = mkdir DESTDIR = C:/Program Files/Geany -include localwin32.mk @@ -55,10 +53,8 @@ clean: deps # mkdir output is ignored in case dir exists # 'copy' seems to only accept / in the destination install: - -$(MKDIR) $(DESTDIR) - -$(MKDIR) $(DESTDIR)/bin + -$(MKDIR_P) $(DESTDIR)/bin $(CP) geany.exe $(DESTDIR)/bin - -$(MKDIR) $(DESTDIR)/lib - $(CP) plugins$(DIRSEP)*.dll $(DESTDIR)/lib - -$(MKDIR) $(DESTDIR)/data + make -C plugins -f makefile.win32 install + -$(MKDIR_P) $(DESTDIR)/data $(CP_R) data $(DESTDIR)/data diff --git a/plugins/makefile.win32 b/plugins/makefile.win32 index 4f2e5da..435f6ae 100644 --- a/plugins/makefile.win32 +++ b/plugins/makefile.win32 @@ -3,7 +3,10 @@ CC = gcc CXX = g++ PREFIX = C:\libs +CP = copy /Y RM = del +MKDIR_P = mkdir +DESTDIR = C:/Program Files/Geany -include ../localwin32.mk .SUFFIXES: .SUFFIXES: .c .o .dll @@ -43,7 +46,7 @@ ifndef GTK210 ALL_GTK_LIBS += -liconv endif -.PHONY: all clean plugins +.PHONY: all clean plugins install all: plugins @@ -66,6 +69,10 @@ plugins: \ clean: -$(RM) deps.mak *.o
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On Tue, 26 Jun 2012 21:21:57 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: I can now apply the -b version, but I had to add 'src/' to the second file in the diff - are you manually concatenating diffs? Yes; the 2nd file lacked 'src/', sorry. Wouldn't it be better to use 'git diff'? My Win~1 tools are very limited, git is not among them, and I didn't dare to run a linux 'git diff' on an NTFS path. I still don't think separate targets is acceptable though. I can at least apply the rest of the patch though. BTW you missed data/templates/files. Wouldn't using a single xcopy be more sensible to reduce bugs and maintenance? Probably. I wanted to stick with a single CP for copying, but ended up with something stupid. I've now committed to master an install target similar to your first patch, but using xcopy for data. I used a DIRSEP variable: $(CP) plugins$(DIRSEP)*.dll $(DESTDIR)/lib A make -C install-plugins will work without DIRSEP. Not ellegant, I'll be the first to admit - but supporting a directory separator variable specifically for a single command, when we can easily do without it, doesn't seem very pretty to me either. Please test. I will. While unlikely, I'll check if 'xcopy /y plugins/*.dll ...' works. I think because 'copy' takes /y switches the first path it sees must not use forward slashes. They are OK in the destination though. Or maybe the forward slashes work with copy if the argument matches an existing path exactly, without find first/next file involved. Not that knowing the reason will help us. -- Note that using a cmd-style shell with SHELL defined to a *nix style shell fails, no matter if makefile.win32 is patched or not. That's a problem of GNU make under Win~1 trying to be too smart, and ending up with things like CreateProcess (copy, ...) error 2. :) I don't get the last part above, but I think this is by design: The program used as the shell is taken from the variable SHELL. If this variable is not set in your makefile, the program /bin/sh is used as the shell. [...] But it doesn't really run the SHELL, just attempts to CreateProcess (copy, ...) because a SHELL is defined. Anyway, I only wanted to make it clear than in such (rare) configuration, mingw32-make is unlikely to work at all: any cmd command (mkdir, del) will be started directly as executable, and of course fail. xcopy should work though. Also, I think you /can/ join command lines with a trailing backslash (but your patch change is still better to have STLIBS anyway): http://www.gnu.org/software/make/manual/html_node/Splitting-Lines.html It failed on my mingw32-make, I wound't have bothered if it worked. -- E-gards: Jimmy ___ 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 Mon, 25 Jun 2012 13:52:12 -0700 Matthew Brush mbr...@codebrainz.ca wrote: 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? Yes, cmd/tcc = cmd.exe or tcc.exe (the free take-command light). For anything on Windows, spaces in filenames is *really* likely :) Well, the purpuse of this patch is to phase out MSYS. We can quote the gtk+ path later... MSYS does treat backslashes as escapes, and I think that is a worse problem than cmd.exe interpreting forward slashes as command options, as it can occur in more situations. I think we should use forward slashes throughout. I expected something like that. OK, the -b version uses forward slashes only. It's stupid and less efficient - not that it matters on novadays machines. The command interpreters seem to tolerate forward slashes for an exact-match path. Unfortunately I can't get your patch to apply against current Git, but I'm not sure why (see attached file for errors). Can you/someone test if it applies (maybe there's something weird happening on my Windows setup)? The original patch had CR+LF line endings, the attached -a version uses LF. But we should try -b anyway. -- Note that using a cmd-style shell with SHELL defined to a *nix style shell fails, no matter if makefile.win32 is patched or not. That's a problem of GNU make under Win~1 trying to be too smart, and ending up with things like CreateProcess (copy, ...) error 2. :) -- E-gards: Jimmy --- makefile.win32.orig Fri Jun 01 00:28:27 2012 +++ makefile.win32 Tue Jun 26 11:18:24 2012 @@ -14,19 +14,18 @@ WINDRES = windres.exe CC = gcc CXX = g++ -CP = copy +MD = mkdir +CP = copy /Y RM = del -MAKE = make +MAKE = mingw32-make -include localwin32.mk -# Note: is needed after cd because each line is executed in a different -# shell. (cd .. is just for clarity). all: config.h - cd tagmanager/mio $(MAKE) -f makefile.win32 cd ../.. - cd tagmanager $(MAKE) -f makefile.win32 cd .. - cd scintilla $(MAKE) -f makefile.win32 cd .. - cd plugins $(MAKE) -f makefile.win32 cd .. - cd src $(MAKE) -f makefile.win32 cd .. + $(MAKE) -C tagmanager/mio -f makefile.win32 + $(MAKE) -C tagmanager -f makefile.win32 + $(MAKE) -C scintilla -f makefile.win32 + $(MAKE) -C plugins -f makefile.win32 + $(MAKE) -C src -f makefile.win32 config.h: win32-config.h $(CP) $ $@ @@ -39,17 +38,37 @@ -$(RM) geany_private.res geany.exe clean: deps - cd tagmanager/mio $(MAKE) -f makefile.win32 clean cd ../.. - cd tagmanager $(MAKE) -f makefile.win32 clean cd .. - cd scintilla $(MAKE) -f makefile.win32 clean cd .. - cd plugins $(MAKE) -f makefile.win32 clean cd .. - cd src $(MAKE) -f makefile.win32 clean cd .. + $(MAKE) -C tagmanager/mio -f makefile.win32 clean + $(MAKE) -C tagmanager -f makefile.win32 clean + $(MAKE) -C scintilla -f makefile.win32 clean + $(MAKE) -C plugins -f makefile.win32 clean + $(MAKE) -C src -f makefile.win32 clean + +.PHONY: install install-plugins install-data install-colorschemes install-templates +DESTDIR=C:/Program Files/Geany + +install-plugins: + -$(MD) $(DESTDIR)/lib + $(CP) *.dll $(DESTDIR)/lib + +install-data: + -$(MD) $(DESTDIR)/data + $(CP) *.* $(DESTDIR)/data + +install-colorschemes: + -$(MD) $(DESTDIR)/data/colorschemes + $(CP) *.* $(DESTDIR)/data/colorschemes + +install-templates: + -$(MD) $(DESTDIR)/data/templates + $(CP) *.* $(DESTDIR)/data/templates -.PHONY: install -DESTDIR='C:/Program Files/Geany' - -# requires admin privileges and MSYS +# requires admin privileges install: - cp -r data $(DESTDIR) - cp plugins/*.dll $(DESTDIR)/lib - cp geany.exe $(DESTDIR)/bin + -$(MD) $(DESTDIR) + -$(MD) $(DESTDIR)/bin + $(CP) geany.exe $(DESTDIR)/bin + $(MAKE) -C plugins -f ../makefile.win32 install-plugins + $(MAKE) -C data -f ../makefile.win32 install-data + $(MAKE) -C data/colorschemes -f ../../makefile.win32 install-colorschemes + $(MAKE) -C data/templates -f ../../makefile.win32 install-templates --- makefile.win32.orig Fri Jun 01 00:28:27 2012 +++ makefile.win32 Tue Jun 26 09:46:52 2012 @@ -77,7 +77,7 @@ # this calls parent clean-local target because del ../file won't work clean: -$(RM) deps.mak *.o - cd .. $(MAKE) -f makefile.win32 clean-local cd src + $(MAKE) -C .. -f makefile.win32 clean-local exec: $(EXECDIR)\geany.exe @@ -85,10 +85,10 @@ binclean: $(RM) $(TARGET) -$(TARGET): $(OBJS) $(RES) ../scintilla/scintilla.a ../tagmanager/mio/mio.a ../tagmanager/tagmanager.a - $(CXX) $(OBJS) $(RES) -o $(TARGET) \ - ../scintilla/scintilla.a ../tagmanager/tagmanager.a ../tagmanager/mio/mio.a \ - $(ALL_GTK_LIBS) $(WIN_LIBS) +STLIBS = ../scintilla/scintilla.a
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On Fri, 22 Jun 2012 13:08:22 -0700 Matthew Brush mbr...@codebrainz.ca wrote: Hi. Here is a small diff (for makefile.win32 and src/makefile.win32 only) that makes Geany 1.22 Win~1 compilation and installation independent of MSYS. Usage: C mingw32-make -f makefile.win32 C mingw32-make -f makefile.win32 install Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had to use backslashes in the install: target, and am not sure if/how MSYS make escapes them. Win~1 fully supports forward slashes internally, but the command interpreters have only partial support. 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? 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. -- E-gards: Jimmy --- ./makefile.win32.orig 2012-06-01 00:28:27.0 +0300 +++ ./makefile.win32 2012-06-25 22:06:49.93750 +0300 @@ -14,19 +14,18 @@ WINDRES = windres.exe CC = gcc CXX = g++ -CP = copy +MD = mkdir +CP = copy /Y RM = del -MAKE = make +MAKE = mingw32-make -include localwin32.mk -# Note: is needed after cd because each line is executed in a different -# shell. (cd .. is just for clarity). all: config.h - cd tagmanager/mio $(MAKE) -f makefile.win32 cd ../.. - cd tagmanager $(MAKE) -f makefile.win32 cd .. - cd scintilla $(MAKE) -f makefile.win32 cd .. - cd plugins $(MAKE) -f makefile.win32 cd .. - cd src $(MAKE) -f makefile.win32 cd .. + $(MAKE) -C tagmanager/mio -f makefile.win32 + $(MAKE) -C tagmanager -f makefile.win32 + $(MAKE) -C scintilla -f makefile.win32 + $(MAKE) -C plugins -f makefile.win32 + $(MAKE) -C src -f makefile.win32 config.h: win32-config.h $(CP) $ $@ @@ -39,17 +38,25 @@ -$(RM) geany_private.res geany.exe clean: deps - cd tagmanager/mio $(MAKE) -f makefile.win32 clean cd ../.. - cd tagmanager $(MAKE) -f makefile.win32 clean cd .. - cd scintilla $(MAKE) -f makefile.win32 clean cd .. - cd plugins $(MAKE) -f makefile.win32 clean cd .. - cd src $(MAKE) -f makefile.win32 clean cd .. + $(MAKE) -C tagmanager/mio -f makefile.win32 clean + $(MAKE) -C tagmanager -f makefile.win32 clean + $(MAKE) -C scintilla -f makefile.win32 clean + $(MAKE) -C plugins -f makefile.win32 clean + $(MAKE) -C src -f makefile.win32 clean .PHONY: install -DESTDIR='C:/Program Files/Geany' +DESTDIR=C:\Program Files\Geany -# requires admin privileges and MSYS +# requires admin privileges install: - cp -r data $(DESTDIR) - cp plugins/*.dll $(DESTDIR)/lib - cp geany.exe $(DESTDIR)/bin + -$(MD) $(DESTDIR) + -$(MD) $(DESTDIR)\bin + $(CP) geany.exe $(DESTDIR)\bin + -$(MD) $(DESTDIR)\lib + $(CP) plugins\*.dll $(DESTDIR)\lib + -$(MD) $(DESTDIR)\data + $(CP) data $(DESTDIR)\data + -$(MD) $(DESTDIR)\data\colorschemes + $(CP) data\colorschemes $(DESTDIR)\data\colorschemes + -$(MD) $(DESTDIR)\data\templates + $(CP) data\templates $(DESTDIR)\data\templates --- ./src/makefile.win32.orig 2012-06-01 00:28:27.0 +0300 +++ ./src/makefile.win32 2012-06-25 21:54:32.03125 +0300 @@ -77,7 +77,7 @@ # this calls parent clean-local target because del ../file won't work clean: -$(RM) deps.mak *.o - cd .. $(MAKE) -f makefile.win32 clean-local cd src + $(MAKE) -C .. -f makefile.win32 clean-local exec: $(EXECDIR)\geany.exe @@ -85,10 +85,10 @@ binclean: $(RM) $(TARGET) -$(TARGET): $(OBJS) $(RES) ../scintilla/scintilla.a ../tagmanager/mio/mio.a ../tagmanager/tagmanager.a - $(CXX) $(OBJS) $(RES) -o $(TARGET) \ - ../scintilla/scintilla.a ../tagmanager/tagmanager.a ../tagmanager/mio/mio.a \ - $(ALL_GTK_LIBS) $(WIN_LIBS) +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) deps.mak: $(CC) -MM $(CFLAGS) *.c deps.mak ___ 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 Fri, 22 Jun 2012 17:23:26 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: $(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? XCOPY can be used. But since we only have the data/ directory with two subdirectories, a COPY is fine too. RFC. If we consider this worthy, I can make the required changes. Sounds good. I'll probably make the changes in Monday. On 20/06/2012 19:04, Dimitar Zhekov wrote: That looks like an entirely new makefile. I was able to compile Geany with small (msys compatible) changes in the existing makefiles, and setting MAKE to mingw32-make in localwin32.mk... Yes, probably we should set MAKE=mingw32-make instead of 'make'. If we don't need MSYS, and there aren't any advantages in using it for compiling and installing Geany, mingw32-make should be the default. -- E-gards: Jimmy ___ 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 Tue, 19 Jun 2012 14:25:11 -0700 Matthew Brush mbr...@codebrainz.ca 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: [...] 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. That looks like an entirely new makefile. I was able to compile Geany with small (msys compatible) changes in the existing makefiles, and setting MAKE to mingw32-make in localwin32.mk... -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Remove MSYS dependency of Geany on Win~1
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. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany multicursors patch
On Thu, 24 May 2012 10:52:29 +1000 Lex Trotman ele...@gmail.com wrote: As I said above we should change the deviant Geany ctrl+click behavior so the super isn't necessary. +1. The current Ctrl+Click goes to definition, or to maching brace, or starts rectangular selection on missing definition, or does nothing on missing matching brace - very annoying. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany multicursors patch
On Sun, 20 May 2012 12:30:12 +0200 Davide Andreoli d...@gurumeditation.it wrote: Hi all! Hi. I implemented this in editor.c (and not as an external plugin) because I have plans to also extend the snippets to support multi editing. Actually the patch is really simple but is just a first test, it is not ready as there are 3 open issue: 1. do you like the feature? :) Yes, but would prefer it as a plugin. Extending it to snippets, well... doesn't seem useful to me. 2. atm the multimode end when you press up/down/left/righti don't like it too much, some other idea? Prefferably on the same events that cancel the rectangle multi line character insertion. 3. is there a way to really show multiple carets? No easy way AFAIK. If you position the cursor on the first of several lines with leading tabs, switch to overwrite and mark the tabs as rectangle, there will be several cursors, each with tab width. So scintilla is actually pretty capable - if you want to get your hands dirty, open it's sources and see how it's done. note: this is my first geany patch... plese be kind :P :) -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] gtk_separator_tool_item_new() patch
Hi, I looked into plugin toolbar support code in more detail, and there seem to be three simple ways to fix the item order: 1. Apply the current patch and tell the plugin authors to add/remove their items at once. They are likely to do so in the first place, because mixed adding/removing means one must keep track of the items, to be able to remove them on plugin_cleanup. It's easier to add everything at once, show/hide as needed, and remove at once. A not shown / hidden item is just as good as not added / removed item. 2. Add an item_count to GeanyAutoSeparator. We already have the means required to track items, but ref_count is for show/hide. Having item count has the advantage of being able to destroy autosep-widget when it drops to 0. ref_count should be renamed to show_count or something. 3. Add a hidden separator item after autosep and always insert before it. Will work like the current positioning, except the 1st item will be OK. May be easier/simpler to implement than #2, but I don't like it. Related to #1, note that mixed removing of items, too, is not supported well by Geany - if you destroy a never shown / hidden item, ref_count will be decremented anyway and autosep may be hidden even if visible items exist. -- On Wed, 09 May 2012 00:19:15 +0200 Colomban Wendling lists@herbesfolles.org wrote: def get_insert_position(plugin): [...] def add_item(plugin, item): [...] It will work, of course, but I think the above are simpler. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] gtk_separator_tool_item_new() patch
On Wed, 09 May 2012 00:19:15 +0200 Colomban Wendling lists@herbesfolles.org wrote: Le 29/04/2012 20:26, Dimitar Zhekov a écrit : Actually there is 1/2 error. The plugin toolbar items are inserted improperly, but added to plugin_items list in the right order. So using Customize Toolbar and adding/removing items or otherwise changing them fixes the order. Patch attached. Not in git format, sorry. If I read the thing correctly, the patch is wrong because it would possibly mixup tool items from different plugins if they aren't added at the same time, wouldn't it? Yes. But Geany does not really support mixed add order: the items are put in toolbar.c's plugin_items exactly in their add_toolbar_item order, so a recreation of the toolbar will mix them if not added at once. BTW, I placed a git patch in tracker bug item 3522755. But you're right that there is a problem. Currently, it creates: | Plugin_1_Item_2 Plugin_1_Item_1 | Plugin_2_Item_1 | Quit It creates Plugin_1_Item_2..N | Plugin_1_Item_1 for each plugin, so: Plugin_1_Item_2 | Plugin_1_Item_1 | Plugin_2_Item_1 | Quit And for 2 plugins and 2 items: Plugin_1_Item_2 | Plugin_1_Item_1 Plugin_2_Item_2 | Plugin_2_Item_1 | Quit. However with your patch, if plugins are added in the order Plugin_1_Item_1, Plugin_2_Item_1, Plugin_1_Item_2, it would give: | Plugin_1_Item_1 | Plugin_2_Item_1 Plugin_1_Item_2 | Quit Which is also wrong (more wrong if I could say). With the patch, we have a proper order if the plugins add their 2+ items at once, and that order matches toolbar.c plugin_items. With the current code, the order of 2+ items is always wrong. They are kept together, allright, unless the toolbar is rebuilt, but the separators are wrong too. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] plugin data / html doc directories?
Hi, In which directories should a plugin keep it's read-only data files and html documentation - datadir|docdir/plugins/name? Currently only lua uses one of those, as datadir/geany-plugins/geanylua, but /usr/local/share/geany/geany-plugins is inconsistent with ~/.config/geany/plugins. BTW, the description of plugin_help() refers to utils_start_browser(), but the function name is utils_open_browser(). -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [PATCH] : FIx window position on start up.
On Thu, 3 May 2012 21:30:46 +1000 Erik de Castro Lopo mle+to...@mega-nerd.com wrote: The included patch checks the window position read from the preferences file, checks to see if its off either the right hand side or bottom of the screen and moves it back into a sensible position. Anyone have any comments on this patch? Yeah? Nay? You look silly and I hate you? I don't think it's a very good idea. First, you switched from your large monitor to the small one, and Geany was repositioned. Next time you log in from the large monitor, it won't be in the lower right corner, and you'll have to move it there. Tit for tat, unless you somehow to maintain real (screen) and virtual (.conf) positions. Second, what's to stop a window manager for using coordinates outside the screen for fullscreen, or even for maximizing? For example border 4, x1 = -4, width = 1288. Third, the problem - if we consider it one - affects all GUI programs, which strongly suggests that it's a window manager's job, if anybody's, to fix such coordinates. Fourth, I'm not sure how this will work for X11 session managed Geany, sm setups the window position differently. Last but not least, why not write a small plugin, and attach the repositioning to geany-startup-complete?.. You don't really need to check prefs.save_winpos - if part of the main window is outside the screen, just move it. The main window is accessible from a plugin, and so are gtk_window_* and gdk_screen_*. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] plugin_add_toolbar_item()
Hi, According to it's description, $subject Inserts a toolbar item before the Quit button, or after the previous plugin toolbar item. A separator is added on the first call to this function [...]. In reality, they are added like this: b c d e f | a Quit. Looking at $subject source, it's obvious that the 2nd and subsequent items are inserted before the separator created with the 1st item. There are two ways to fix this: Keep item counter, and insert the 2nd+ items at separator_position + counter + 1; we must count the removals as well. Always insert before Quit, which will reduce plugin_add_toolbar_item by about 1/3. Practically the two are identical, but the latter is much simpler. If you agree to it, I'll write a patch. Currently $subject is used by 4 plugins; they all add a single item. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] plugin_add_toolbar_item() was my mistake
Hi, Actually, plugin_add_toolbar_item() works properly. Now, if there isn't enough space, the first item(s?) are placed in the drop-down toolbar menu, instead of the last. But that's probably a gtk+ thing. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] gtk_separator_tool_item_new() patch
Hi again, and excuse me for stuffing the list.
Actually there is 1/2 error. The plugin toolbar items are inserted
improperly, but added to plugin_items list in the right order. So
using Customize Toolbar and adding/removing items or otherwise
changing them fixes the order.
Patch attached. Not in git format, sorry.
--
E-gards: Jimmy
--- ./src/pluginutils.c.orig 2011-10-15 19:28:57.0 +0300
+++ ./src/pluginutils.c 2012-04-29 21:17:36.685006711 +0300
@@ -47,7 +47,7 @@
void plugin_add_toolbar_item(GeanyPlugin *plugin, GtkToolItem *item)
{
GtkToolbar *toolbar = GTK_TOOLBAR(main_widgets.toolbar);
- gint pos;
+ gint pos = toolbar_get_insert_position();
GeanyAutoSeparator *autosep;
g_return_if_fail(plugin);
@@ -55,26 +55,15 @@
if (!autosep-widget)
{
- GtkToolItem *sep;
+ GtkToolItem *sep = gtk_separator_tool_item_new();
- pos = toolbar_get_insert_position();
-
- sep = gtk_separator_tool_item_new();
- gtk_toolbar_insert(toolbar, sep, pos);
+ gtk_toolbar_insert(toolbar, sep, pos++);
autosep-widget = GTK_WIDGET(sep);
-
- gtk_toolbar_insert(toolbar, item, pos + 1);
-
toolbar_item_ref(sep);
- toolbar_item_ref(item);
- }
- else
- {
- pos = gtk_toolbar_get_item_index(toolbar, GTK_TOOL_ITEM(autosep-widget));
- g_return_if_fail(pos = 0);
- gtk_toolbar_insert(toolbar, item, pos);
- toolbar_item_ref(item);
}
+
+ gtk_toolbar_insert(toolbar, item, pos);
+ toolbar_item_ref(item);
/* hide the separator widget if there are no toolbar items showing for the plugin */
ui_auto_separator_add_ref(autosep, GTK_WIDGET(item));
}
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Small additions to stash
On Fri, 06 Apr 2012 14:06:48 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: On 05/04/2012 19:02, Dimitar Zhekov wrote: New stash_group_free_strings(), which frees any strings and string arrays in a group. Much easier than to track them individually, as in Geany (though if someone is willing to track the keyfile_groups prefs free-s and remove them, a call may be included in configuration_finalize). Probably it should be named more generally, in case we support e.g. null-terminated integer lists. Maybe stash_group_free_settings(). Renamed and changed the description. Updated patch attached. Thanks, applied. I added a note to the docs that it's not called by stash_group_free(). Ideally we would be using the function in Geany somewhere as an example. Perhaps on the plugins group, since it's short and contains both string (freed in main?..) and string vector. Would require a static variable. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Small additions to stash
On Thu, 05 Apr 2012 17:20:44 +0100
Nick Treleaven nick.trelea...@btinternet.com wrote:
On 04/04/2012 19:58, Dimitar Zhekov wrote:
Hi,
How about some $subject? Namely:
Include stash_group_set_use_defaults() in plugin StashFuncs. I'm not
using it any more, but it's a nice thing to have.
I'm not convinced we should support that publicly. It puts a burden on
the implementation for an unusual use case.
ACK.
New stash_group_free_strings(), which frees any strings and string
arrays in a group. Much easier than to track them individually, as
in Geany (though if someone is willing to track the keyfile_groups
prefs free-s and remove them, a call may be included in
configuration_finalize).
Probably it should be named more generally, in case we support e.g.
null-terminated integer lists. Maybe stash_group_free_settings().
Renamed and changed the description. Updated patch attached.
--
E-gards: Jimmy
From b86a3942379cbca63d11ad4120239db4615f13d0 Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov dimitar.zhe...@gmail.com
Date: Thu, 5 Apr 2012 20:59:57 +0300
Subject: [PATCH] A stash_group_free_settings() function Frees the memory
allocated for setting values in a group
---
plugins/geanyfunctions.h |2 ++
src/plugindata.h |1 +
src/plugins.c|3 ++-
src/stash.c | 21 +
src/stash.h |2 ++
5 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/plugins/geanyfunctions.h b/plugins/geanyfunctions.h
index d41d77e..beaf6fb 100644
--- a/plugins/geanyfunctions.h
+++ b/plugins/geanyfunctions.h
@@ -418,6 +418,8 @@
geany_functions-p_stash-stash_group_display
#define stash_group_update \
geany_functions-p_stash-stash_group_update
+#define stash_group_free_settings \
+ geany_functions-p_stash-stash_group_free_settings
#define symbols_get_context_separator \
geany_functions-p_symbols-symbols_get_context_separator
#define build_activate_menu_item \
diff --git a/src/plugindata.h b/src/plugindata.h
index 77d6964..9e5e7f5 100644
--- a/src/plugindata.h
+++ b/src/plugindata.h
@@ -701,6 +701,7 @@ typedef struct StashFuncs
const gchar *property_name, GType type);
void (*stash_group_display)(struct StashGroup *group, GtkWidget *owner);
void (*stash_group_update)(struct StashGroup *group, GtkWidget *owner);
+ void (*stash_group_free_settings)(struct StashGroup *group);
}
StashFuncs;
diff --git a/src/plugins.c b/src/plugins.c
index 42bec5d..65b229f 100644
--- a/src/plugins.c
+++ b/src/plugins.c
@@ -346,7 +346,8 @@ static StashFuncs stash_funcs = {
stash_group_add_entry,
stash_group_add_widget_property,
stash_group_display,
- stash_group_update
+ stash_group_update,
+ stash_group_free_settings
};
static SymbolsFuncs symbols_funcs = {
diff --git a/src/stash.c b/src/stash.c
index 0427af3..530c11e 100644
--- a/src/stash.c
+++ b/src/stash.c
@@ -335,6 +335,27 @@ StashGroup *stash_group_new(const gchar *name)
}
+/** Frees the memory allocated for setting values in a group.
+ * @param group . */
+void stash_group_free_settings(StashGroup *group)
+{
+ StashPref *entry;
+ guint i;
+
+ foreach_ptr_array(entry, i, group-entries)
+ {
+ if (entry-setting_type == G_TYPE_STRING)
+ g_free(*(gchararray *) entry-setting);
+ else if (entry-setting_type == G_TYPE_STRV)
+ g_strfreev(*(gchararray **) entry-setting);
+ else
+ continue;
+
+ *(gpointer**) entry-setting = NULL;
+ }
+}
+
+
/** Frees a group.
* @param group . */
void stash_group_free(StashGroup *group)
diff --git a/src/stash.h b/src/stash.h
index 949fb2d..7391e71 100644
--- a/src/stash.h
+++ b/src/stash.h
@@ -60,6 +60,8 @@ gboolean stash_group_load_from_file(StashGroup *group, const gchar *filename);
gint stash_group_save_to_file(StashGroup *group, const gchar *filename,
GKeyFileFlags flags);
+void stash_group_free_settings(StashGroup *group);
+
void stash_group_free(StashGroup *group);
--
1.7.9.1
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Small additions to stash
Hi,
How about some $subject? Namely:
Include stash_group_set_use_defaults() in plugin StashFuncs. I'm not
using it any more, but it's a nice thing to have.
New stash_group_free_strings(), which frees any strings and string
arrays in a group. Much easier than to track them individually, as
in Geany (though if someone is willing to track the keyfile_groups
prefs free-s and remove them, a call may be included in
configuration_finalize).
--
E-gards: Jimmy
From 83e14b46a117e9920e514ead6bc0adaf8330abb6 Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov dimitar.zhe...@gmail.com
Date: Wed, 4 Apr 2012 21:38:51 +0300
Subject: [PATCH] include stash_group_set_use_defaults() in plugin StashFuncs
new stash_group_free_strings(), also in plugin StashFuncs
---
plugins/geanyfunctions.h |4
src/plugindata.h |2 ++
src/plugins.c|4 +++-
src/stash.c | 21 +
src/stash.h |2 ++
5 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/plugins/geanyfunctions.h b/plugins/geanyfunctions.h
index d41d77e..3f66707 100644
--- a/plugins/geanyfunctions.h
+++ b/plugins/geanyfunctions.h
@@ -418,6 +418,10 @@
geany_functions-p_stash-stash_group_display
#define stash_group_update \
geany_functions-p_stash-stash_group_update
+#define stash_group_set_use_defaults \
+ geany_functions-p_stash-stash_group_set_use_defaults
+#define stash_group_free_strings \
+ geany_functions-p_stash-stash_group_free_strings
#define symbols_get_context_separator \
geany_functions-p_symbols-symbols_get_context_separator
#define build_activate_menu_item \
diff --git a/src/plugindata.h b/src/plugindata.h
index 77d6964..2df8ffc 100644
--- a/src/plugindata.h
+++ b/src/plugindata.h
@@ -701,6 +701,8 @@ typedef struct StashFuncs
const gchar *property_name, GType type);
void (*stash_group_display)(struct StashGroup *group, GtkWidget *owner);
void (*stash_group_update)(struct StashGroup *group, GtkWidget *owner);
+ void (*stash_group_set_use_defaults)(struct StashGroup *group, gboolean use_defaults);
+ void (*stash_group_free_strings)(struct StashGroup *group);
}
StashFuncs;
diff --git a/src/plugins.c b/src/plugins.c
index 42bec5d..4d36169 100644
--- a/src/plugins.c
+++ b/src/plugins.c
@@ -346,7 +346,9 @@ static StashFuncs stash_funcs = {
stash_group_add_entry,
stash_group_add_widget_property,
stash_group_display,
- stash_group_update
+ stash_group_update,
+ stash_group_set_use_defaults,
+ stash_group_free_strings
};
static SymbolsFuncs symbols_funcs = {
diff --git a/src/stash.c b/src/stash.c
index 0427af3..76411d4 100644
--- a/src/stash.c
+++ b/src/stash.c
@@ -335,6 +335,27 @@ StashGroup *stash_group_new(const gchar *name)
}
+/** Frees the strings and string arrays in a group.
+ * @param group . */
+void stash_group_free_strings(StashGroup *group)
+{
+ StashPref *entry;
+ guint i;
+
+ foreach_ptr_array(entry, i, group-entries)
+ {
+ if (entry-setting_type == G_TYPE_STRING)
+ g_free(*(gchararray *) entry-setting);
+ else if (entry-setting_type == G_TYPE_STRV)
+ g_strfreev(*(gchararray **) entry-setting);
+ else
+ continue;
+
+ *(gpointer**) entry-setting = NULL;
+ }
+}
+
+
/** Frees a group.
* @param group . */
void stash_group_free(StashGroup *group)
diff --git a/src/stash.h b/src/stash.h
index 949fb2d..64b723d 100644
--- a/src/stash.h
+++ b/src/stash.h
@@ -60,6 +60,8 @@ gboolean stash_group_load_from_file(StashGroup *group, const gchar *filename);
gint stash_group_save_to_file(StashGroup *group, const gchar *filename,
GKeyFileFlags flags);
+void stash_group_free_strings(StashGroup *group);
+
void stash_group_free(StashGroup *group);
--
1.7.9.1
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Markers
On Mon, 12 Mar 2012 09:59:45 +1100 Lex Trotman ele...@gmail.com wrote: Maybe you should contact Matthew, during a conversation we had on IRC he revealed a prototype for manageing all such limited resources, not just markers, in a consistent manner. This concerns all plugin developers. @Matthew, can you public the prototype or it's short description on the mailing list, or on another shared resource?.. I wouldn't expect (for example) GeanyLatex to interfere with my C# programming. Similarly I wouldn't expect the debugger plugin to try to work on a language gdb doesn't understand, eg Java. Sounds nice. But for some reason, both Scintilla and Geany use fixed resources, independent of file type. Folding for text files, anyone?.. A per-document allocation, no matter how implemented, also introduces per-document resource exhaustion errors. So we should at least have a policy how such error messages are displayed - they must be both noticable and not too annoying. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Markers
On Sun, 11 Mar 2012 12:33:07 +1100 Lex Trotman ele...@gmail.com wrote: I don't think much is needed: 1. Scintilla already provides the special symbol SC_MARK_AVAILABLE to indicate that the mark is available. I already replied to this [1]. Unless we want each plugin to allocate it's markers for each document, possibly receiving different numbers, we should have a bitmap in Geany. 3. When a plugin needs a marker for a document it should search for one that is available on that document and use that, and set it back to available when it no longer needs it and on unload. There are only 32 to search so it isn't IMHO worth implementing anything faster. Oh, I see. So any plugin with markers must keep track of each document it allocated markers in. This is not going to be fun. why should a C language plugin steal markers froma Python file when the Python plugin also needs them?? To be able to allocate markers #s in plugin_init(), and free them in plugin_cleanup(). To be able to work without tracking document file type changes. [1] http://lists.uvena.de/pipermail/geany-devel/2012-February/006629.html -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Markers
On Sat, 10 Mar 2012 17:43:16 +0400 Alexander Petukhov de...@apetukhov.ru wrote: utils_ui_get_marker(), utils_ui_free_marker(). Is it going with these new functions? Nothing is going on, the thread died. I started with SF bug about markers and also came up to that having such functions would be the best way for dealing with plugin's markers. Fellow developers, how about implementing these? I can do it, they are not hard to write. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] small leak in keyfile.c
Hi,
configuration_reload_default_session() does not free configfile.
Patch attached.
--
E-gards: Jimmy
From 3d30dfbc23c26928ab98950ed6cc89b8eb48e898 Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov dimitar.zhe...@gmail.com
Date: Thu, 8 Mar 2012 18:53:23 +0200
Subject: [PATCH] free configfile in configuration_reload_default_session
---
src/keyfile.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/keyfile.c b/src/keyfile.c
index ddb2d62..49367b6 100644
--- a/src/keyfile.c
+++ b/src/keyfile.c
@@ -978,10 +978,11 @@ void configuration_save_default_session(void)
*/
void configuration_reload_default_session(void)
{
- const gchar *configfile = g_build_filename(app-configdir, geany.conf, NULL);
+ gchar *configfile = g_build_filename(app-configdir, geany.conf, NULL);
GKeyFile *config = g_key_file_new();
g_key_file_load_from_file(config, configfile, G_KEY_FILE_NONE, NULL);
+ g_free(configfile);
configuration_load_session_files(config, FALSE);
--
1.7.9.1
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Markers
On Mon, 27 Feb 2012 08:23:41 +1100 Lex Trotman ele...@gmail.com wrote: [...] My personal preference would be some shared static function that any plugin using markers could access. A simple ui_utils function to find and return the first available marker based on SC_MARK_AVAILABLE would suffice. The absolute minimum we need is for Geany to set unused markers to available. Geany has to do this, it is the only thing *guaranteed* to run before all plugins. Fraser #2 states this, but it won't be enough. In fact, it may be useful only for programs with a single SciObj, such as SciTE. It is not clear to me if it has to be done for each scintilla buffer, each view or once only. For each buffer (each SciObj), I guarantee... Plugins or Geany can then simply search for the next available one. and allocate it by setting it to something other than available. Since a plugin may not need to set [all of] it's markers for each file, and we may even have 0 buffers open, a guint map seems required, and I was probably wrong to suggest AVAILABLE. Can't query/define Scintilla markers without at least 1 SciObj... Since every mark using plugin should do it it is probably better to have a common function in Geany. utils_ui_get_marker(), utils_ui_free_marker(). It can then also generate a message to the user suggesting unloading a plugin if it runs out of markers. Shoudn't the plugin handle this? It may reduce the number of markers used, work without them if non-critical, or do something else. Bookmarks should also be re-written to only use the number of markers as current bookmarks, not grab ten at startup. Ten markers? Wow, that's heavy. Different colors or what? -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Markers
On Sun, 26 Feb 2012 13:08:14 + WILLIAM FRASER william.fra...@virgin.net wrote: There is a problem as I understand it with checking for the SC_MARK_AVAILABLE marker to see if a marker is available... Markers seem by default to be set to 0 (SC_MARK_CIRCLE) by scintilla. By default, all 32 markers are set to SC_MARK_CIRCLE with a black foreground and a white background. 2) change scintilla or geany so that markers are set to SC_MARK_AVAILABLE when it is initialised. Applications may use the marker symbol SC_MARK_AVAILABLE to indicate that plugins may allocate that marker number. So AVAILABLE is specifically designed for our case, and it's Geany that should be changed, not scintilla. Option 2 would be the most versatile in the long run, but would require altering someone else's project purely for our own devices, and it would require anyone using a plugin using markers to have to use the latest version of geany. The old plugins may continue to use their fixed marker numbers, which will show as allocated [1] . They won't deallocate the numbers on _cleanup, but will allocate the same numbers if reloaded. [1] Unless somebody uses a marker without defining it. White circle with black background, anyone?.. My personal preference would be some shared static function that any plugin using markers could access. A simple ui_utils function to find and return the first available marker based on SC_MARK_AVAILABLE would suffice. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] project-before-save signal
Hi, I want to request a $subject, executed unconditionally on project save after config is loaded but before the actual save (similar to configuration-save). It'll serve the following purposes: 1. Let a plugin undo any temporary project / file setting changes it possibly did, before the save takes place. 2. Allow saving project settings which are not part of the project dialog. The current signal, project-save, is executed only on Project Dialog - OK / Apply, but not when a project is closed, and consequently not on Geany quit. 3. Allow saving plugin project settings on project close (and Geany quit) to an empty file, for example project-x11-session-id.geany - same problem as #2. The code is attached, courtesy of Jiří Techet, and works fine. -- Now, #2 and #3 may be solved by making project-save unconditional, but that will break compatibility. #1 can be done by g_key_file_get/ set with the config argument of project-save, provided it's unconditional, but I'd prefer to use a documented plugin interface instead of opening the bag of tricks. -- E-gards: Jimmy From 1da771871d8250ee84c16bc4639391c34d991820 Mon Sep 17 00:00:00 2001 From: Dimitar Zhekov dimitar.zhe...@gmail.com Date: Thu, 23 Feb 2012 20:14:35 +0200 Subject: [PATCH] project-before-save signal --- doc/pluginsignals.c |2 ++ src/geanyobject.c |9 + src/geanyobject.h |2 ++ src/project.c |2 ++ 4 files changed, 15 insertions(+), 0 deletions(-) diff --git a/doc/pluginsignals.c b/doc/pluginsignals.c index 0447fb1..1f41012 100644 --- a/doc/pluginsignals.c +++ b/doc/pluginsignals.c @@ -140,6 +140,8 @@ signal void (*document_close)(GObject *obj, GeanyDocument *doc, gpointer user_da */ signal void (*project_open)(GObject *obj, GKeyFile *config, gpointer user_data); +signal void (*project_before_save)(GObject *obj, GKeyFile *config, gpointer user_data); + /** Sent when a project is saved(happens when the project is created, the properties * dialog is closed or Geany is exited). This signal is emitted shortly before Geany * will write the contents of the GKeyFile to the disc. diff --git a/src/geanyobject.c b/src/geanyobject.c index 23e8af0..bb25ea3 100644 --- a/src/geanyobject.c +++ b/src/geanyobject.c @@ -252,6 +252,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_BEFORE_SAVE] = g_signal_new ( + project-before-save, + G_OBJECT_CLASS_TYPE (g_object_class), + G_SIGNAL_RUN_FIRST, + G_STRUCT_OFFSET (GeanyObjectClass, project_before_save), + NULL, NULL, + g_cclosure_marshal_VOID__POINTER, + G_TYPE_NONE, 1, + G_TYPE_POINTER); geany_object_signals[GCB_PROJECT_SAVE] = g_signal_new ( project-save, G_OBJECT_CLASS_TYPE (g_object_class), diff --git a/src/geanyobject.h b/src/geanyobject.h index 3957b55..e7a652d 100644 --- a/src/geanyobject.h +++ b/src/geanyobject.h @@ -39,6 +39,7 @@ typedef enum GCB_DOCUMENT_ACTIVATE, GCB_DOCUMENT_CLOSE, GCB_PROJECT_OPEN, + GCB_PROJECT_BEFORE_SAVE, GCB_PROJECT_SAVE, GCB_PROJECT_CLOSE, GCB_PROJECT_DIALOG_CREATE, @@ -88,6 +89,7 @@ struct _GeanyObjectClass void (*document_activate)(GeanyDocument *doc); void (*document_close)(GeanyDocument *doc); void (*project_open)(GKeyFile *keyfile); + void (*project_before_save)(GKeyFile *keyfile); void (*project_save)(GKeyFile *keyfile); void (*project_close)(void); void (*project_dialog_create)(GtkWidget *notebook); diff --git a/src/project.c b/src/project.c index ca2bc12..b06c2c3 100644 --- a/src/project.c +++ b/src/project.c @@ -1041,6 +1041,8 @@ static gboolean write_config(gboolean emit_signal) filename = utils_get_locale_from_utf8(p-file_name); g_key_file_load_from_file(config, filename, G_KEY_FILE_NONE, NULL); + g_signal_emit_by_name(geany_object, project-before-save, config); + foreach_slist(node, stash_groups) stash_group_save_to_key_file(node-data, config); -- 1.7.9 ___ 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 Tue, 21 Feb 2012 23:25:02 +0100 Jiří Techet tec...@gmail.com wrote: Hi Dimitar, have a look at the attached patch - I've added the signal but as I don't know exactly when you need to emit it, you'll probably need to modify it. Also I haven't documented the signal as I still don't completely understand its purpose. Feel free to use this patch as a template for the modifications you need to do. Thanks! -- E-gards: Jimmy ___ 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 Mon, 20 Feb 2012 21:00:44 +0100 Colomban Wendling lists@herbesfolles.org wrote: To run a second instance of Geany, do not specify any filenames on the command-line, [...] This should be reworded since it's not true since a long time one need explicit -i, isn't it? Or do I get the sentence wrong? Well, maybe secondary instead of second, since I used subsequent in the previous paragraph. -i is required only if you want to open CL files in a new instance, instead of passing them to an already running one (explained under Command line options before Startup). If you have a Geany, and start another from, say, your DE menu (i.e. without CL), it becomes (new instance) automatically. -- E-gards: Jimmy ___ 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 Mon, 20 Feb 2012 22:40:50 +0100 Jiří Techet tec...@gmail.com wrote: On Mon, Feb 20, 2012 at 17:51, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: Since you are changing the project signals anyway, can you do me a favor and add an unconditional project-before-save signal in write_config, with the same arguments as project-save? Currently we have document-before-save, and save-settings is before configuration saving (though that's not very helpful), but there's no before signal for the projects settings, and I need one for a plugin of mine. Hi Dimitar, what do you need the signal for? The project-save signal is actually emitted before g_key_file_to_data() is called so it is called before it's saved. I use this signal in my plugin too to add my own settings to the project file. To (a) temporarily revert some file settings before a possible save- session-files and (b) ignore emit_signal, since session save does not depend on it. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] gtk builder signals for plugin
Hi, Does anyone know if the gtk builder searching for exported functions and attaching them to xml/.glade signals will work for a plugin? -- E-gards: Jimmy ___ 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
Hi, Jiří, On Mon, 20 Feb 2012 00:35:24 +0100 Jiří Techet tec...@gmail.com wrote: I've created new pull request with the changes here: https://github.com/geany/geany/pull/25 Since you are changing the project signals anyway, can you do me a favor and add an unconditional project-before-save signal in write_config, with the same arguments as project-save? Currently we have document-before-save, and save-settings is before configuration saving (though that's not very helpful), but there's no before signal for the projects settings, and I need one for a plugin of mine. -- E-gards: Jimmy ___ 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 Sat, 18 Feb 2012 14:17:17 +0100
Colomban Wendling lists@herbesfolles.org wrote:
So I'd say aye to Dimitar since he gently volunteered :) Moreover
if it is a preference I don't see any loss; but I'd better see this
preference turned on by default for new configurations if the restore
session one is on.
Here's the patch. There is no additional preference - if Load files
from the last session is checked, they are loaded, and that's it.
Though it'll be easy to make it a pref...
--
E-gards: Jimmy
From 23a085bbf5210572bce051649a0e73f4c5d0bbe3 Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov dimitar.zhe...@gmail.com
Date: Mon, 20 Feb 2012 19:18:21 +0200
Subject: [PATCH] Load the default session even if opening file(s)
A slightly simplified variant of the rewritten load startup files
from Geany patch tracker. Does not check for CLI files when deciding
whether to load the default session.
---
src/main.c | 60 ++--
1 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/src/main.c b/src/main.c
index d17cfba..88034e9 100644
--- a/src/main.c
+++ b/src/main.c
@@ -798,12 +798,10 @@ gboolean main_handle_filename(const gchar *locale_filename)
/* open files from command line */
-static gboolean open_cl_files(gint argc, gchar **argv)
+static void open_cl_files(gint argc, gchar **argv)
{
gint i;
- if (argc = 1) return FALSE;
-
for (i = 1; i argc; i++)
{
gchar *filename = main_get_argv_filename(argv[i]);
@@ -828,7 +826,6 @@ static gboolean open_cl_files(gint argc, gchar **argv)
}
g_free(filename);
}
- return TRUE;
}
@@ -882,39 +879,42 @@ void main_load_project_from_command_line(const gchar *locale_filename, gboolean
static void load_startup_files(gint argc, gchar **argv)
{
- gboolean load_project_from_cl = FALSE;
-
- /* ATM when opening a project file any other filenames are ignored */
- load_project_from_cl = (argc 1) g_str_has_suffix(argv[1], .geany);
- if (load_project_from_cl argc 2)
- g_print(Ignoring extra filenames after %s, argv[1]);
+ gboolean load_session = FALSE;
- if (load_project_from_cl || ! open_cl_files(argc, argv))
+ if (argc 1 g_str_has_suffix(argv[1], .geany))
{
- if (prefs.load_session)
- {
- if (load_project_from_cl)
- {
-main_load_project_from_command_line(argv[1], FALSE);
- }
- else if (cl_options.load_session !cl_options.new_instance)
-load_session_project_file();
+ /* project file specified: load it, but decide the session later */
+ main_load_project_from_command_line(argv[1], FALSE);
+ argc--, argv++;
+ /* force session load if using project-based session files */
+ load_session = project_prefs.project_session;
+ }
- /* when we want a new instance, we still load project session files unless -s
- * was passed */
- if (!cl_options.load_session || (!load_project_from_cl cl_options.new_instance))
-return;
+ /* Load the default session if:
+ * 1. Load files from the last session is active.
+ * 2. --no-session is not specified.
+ * 3. We are a primary instance.
+ * Has no effect if a CL project is loaded and using project-based session files. */
+ if (prefs.load_session cl_options.load_session !cl_options.new_instance)
+ {
+ if (app-project == NULL)
+ load_session_project_file();
+ load_session = TRUE;
+ }
- /* load session files into tabs, as they are found in the session_files variable */
- configuration_open_files();
+ if (load_session)
+ {
+ /* load session files into tabs, as they are found in the session_files variable */
+ configuration_open_files();
- if (gtk_notebook_get_n_pages(GTK_NOTEBOOK(main_widgets.notebook)) == 0)
- {
-ui_update_popup_copy_items(NULL);
-ui_update_popup_reundo_items(NULL);
- }
+ if (gtk_notebook_get_n_pages(GTK_NOTEBOOK(main_widgets.notebook)) == 0)
+ {
+ ui_update_popup_copy_items(NULL);
+ ui_update_popup_reundo_items(NULL);
}
}
+
+ open_cl_files(argc, argv);
}
--
1.7.9
___
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 Mon, 20 Feb 2012 20:00:38 +0100 Colomban Wendling lists@herbesfolles.org wrote: Thanks a lot, committed. Maybe an update of the manual to explain more it needed? Yes... An update is required because the manual explicitly says if you specify CL files, only they will be opened, and refers the user to Recent files. So I altered the Startup section a bit. -- E-gards: Jimmy From 97d8f12958e0a2924b3fb557b01195320e1a9323 Mon Sep 17 00:00:00 2001 From: Dimitar Zhekov dimitar.zhe...@gmail.com Date: Mon, 20 Feb 2012 21:20:48 +0200 Subject: [PATCH] altered Geany manual Startup to reflect that the default session is loaded even if opening file(s) --- doc/geany.txt | 18 +- 1 files changed, 9 insertions(+), 9 deletions(-) diff --git a/doc/geany.txt b/doc/geany.txt index 6cefa87..89b20cc 100644 --- a/doc/geany.txt +++ b/doc/geany.txt @@ -424,17 +424,17 @@ Startup At startup, Geany loads all files from the last time Geany was launched. You can disable this feature in the preferences dialog -(see `General Startup preferences`_). If you specify some -files on the command line, only these files will be opened, but you -can find the files from the last session in the file menu under the -Recent files item. By default this contains the last 10 recently -opened files. You can change the number of recently opened files in -the preferences dialog. +(see `General Startup preferences`_). You can start several instances of Geany, but only the first will -load files from the last session. To run a second instance of Geany, -do not specify any filenames on the command-line, or disable opening -files in a running instance using the appropriate command line option. +load files from the last session. In the subsequent instances, you +can find these files in the file menu under the Recent files item. +By default this contains the last 10 recently opened files. You can +change the number of recently opened files in the preferences dialog. + +To run a second instance of Geany, do not specify any filenames on +the command-line, or disable opening files in a running instance +using the appropriate command line option. Opening files from the command-line in a running instance -- 1.7.9 ___ 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 Mon, 13 Feb 2012 17:14:19 -0800 Matthew Brush mbr...@codebrainz.ca wrote: 3. geany xyz.txt does not load files from session - ID: 2838686 [3] Here it wasn't decided whether of not Geany should restore session. I suggest we discuss this question and finally either fix the bug or mark it as WONTFIX. I don't often use Geany for opening files from the command line and usually I always have a Geany window open so if I do, it's not an issue, so I can't really provide a worthwhile opinion here. As the bug report states, opening a file _with your file manager_ or CLI loses the last [default] session [if no geany is running]. The complaints we usually got were I double-clicked foo.c and lost my session, to which we usually replied use projects. So this affects the GUI, even more than CLI. 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. -- E-gards: Jimmy ___ 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 Sun, 12 Feb 2012 11:18:36 +0400 Eugene Arshinov earshi...@gmail.com wrote: 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. From the discussion, it looks like Enrico fixed this... As of opening Geany per-desktop, the manual contains an example (search for xprop). 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. That was discussed before, for example Proposed patch to fix issues with command line file loading, and weltall even sent a patch [1] for graphical preference. Outdated, of course, since it's a year old, and Geany uses GtkBuilder now... If we're going to finally implement this feature (and several people requested it), I suggest that we apply #3312654 [2] first. The current load_startup_files() is a bit of a mess, and becomes worse with the new preference. The thuth to be said, I had enough discussion on default session loading CL files specified. Let's vote and decide it, shall we?.. [1] http://lists.uvena.de/pipermail/geany-devel/2011-January/003818.html [2] http://sourceforge.net/tracker/?func=detailaid=3312654group_id=153444atid=787793 -- E-gards: Jimmy ___ 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 Sat, 4 Feb 2012 09:23:33 +1100 Lex Trotman ele...@gmail.com wrote: I tested with the following code in plugin_init(): build_set_menu_item(GEANY_BCS_PROJ, GEANY_GBG_EXEC, 1, GEANY_BC_LABEL, boza); Can you post the problem plugin, or better reproduce the problem with demoplugin so we can eliminate other issues. My mistake of some sort. With a clean clone (I'm using patched Geany) and the demoplugin, the problem is gone. -- E-gards: Jimmy ___ 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 Wed, 1 Feb 2012 11:24:01 +1100 Lex Trotman ele...@gmail.com wrote: On Wed, Feb 1, 2012 at 5:20 AM, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Tue, 31 Jan 2012 15:39:52 +1100 I compile Geany with -Wall -W -Wno-unused-parameter (not the normal practice) and received a few warnings: Well, it should be normal practice, thats what HACKING says, I just forgot to set it with a new clean clone, oops. Actually you should add -O2 because a couple of the warnings need the dataflow computation that the optimisation does. I only listed the warnings, -O2 is a sine qua non (albeit -Os -freorder-blocks is better for some systems). The semantics of a command (well actually the label) that is vs NULL is important, a label hides commands from a lower priority source without showing itself in the menu, a NULL does not. [...] Unfortunately there isn't anthing else besides NULL that is sensible to return to indicate out of range. So returning for COMMAND is possible... So I've exposed build_get_group_count() as well so you can get the count and then its your fault if you pass an out of range index :). ...but a count is fine too. :) Let's hope BuildFuncs makes it into the plugin interface, the current lack of build access is weird. -- E-gards: Jimmy ___ 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 Mon, 30 Jan 2012 14:08:59 +1100 Lex Trotman ele...@gmail.com wrote: How can I $subject? At the moment you can't officially access any of the build system from a plugin. [::surprise::] Initially I exposed some of the build system (see comments starting /* * in build.h/c) but concerns were raised that this exposed the implementation so it was removed. I don't see anything starting with /**, and there are lots of /* *... My attempts to proactively define an interface that does not expose any implementation structures was also rejected, so there is officially no way. Hmmm... Have you tried something simple, like: const gchar *build_get_command(ft, index, part) Where: ft = filetype | independent | exec index = 0, 1, ... part = label | command | workdir rval = NULL if index is too big or some other argument is invalid. Of course, it's not much different than the current build_get_*() functions, but doesn't expose any build structures. And I guess people will need the effective value, not some particular source. I guess you need to request the parts you need, and those will be exposed in the usual ad-hoc way. Some home_ft/project specific commands. They're not hard to get, but re-reading the key files is hardly the right thing. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] get build command from a plugin
Hi, How can I $subject? -- E-gards: Jimmy ___ 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 Fri, 06 Jan 2012 10:29:30 +0100 Frank Lanitz fr...@frank.uvena.de wrote: We have just added a MAINTAINERS into git to add a single point to find who is responsible for a plugin. Please be so kind and sending in patches or updating the file on your own [...] Here's a patch. -- E-gards: Jimmy From 210845809a50b43a1c052ace25cdb365b4f923a4 Mon Sep 17 00:00:00 2001 From: Dimitar Zhekov dimitar.zhe...@gmail.com Date: Fri, 6 Jan 2012 19:48:03 +0200 Subject: [PATCH] Added myself as maintainer of geanyextrasel and geanyinsertnum --- MAINTAINERS | 16 1 files changed, 8 insertions(+), 8 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index b271549..6219dd7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -43,10 +43,10 @@ W: S: geanyextrasel -P: -M: -W: -S: +P: Dimitar Zhekov dimitar.zhe...@gmail.com +M: Dimitar Zhekov dimitar.zhe...@gmail.com +W: http://sheckley.users.sourceforge.net +S: Supported geanygdb P: Dominic Hopf @@ -61,10 +61,10 @@ W: http://plugins.geany.org/geanygendoc.html S: Supported geanyinsertnum -P: -M: -W: -S: +P: Dimitar Zhekov dimitar.zhe...@gmail.com +M: Dimitar Zhekov dimitar.zhe...@gmail.com +W: http://sheckley.users.sourceforge.net +S: Supported geanylatex P: Frank Lanitz fr...@frank.uvena.de -- 1.7.7.3 ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Session Management Interim Solution Proposal
On Tue, 3 Jan 2012 09:20:08 +1100 Lex Trotman ele...@gmail.com wrote: Perhaps you already know since you didn't list it, XFCE4 will re-start firefox 5 with the tabs it last had open. Yes. XFCE is of course the DE of choice for developers since Linus switched to it from Gnome. I woudn't attribute that to Linus... I *thought* that geany sm branch worked with it too, but that was on another machine, and I havn't the bandwidth here to download it to test. If you mean the original Eugene's branch, it's xsmp. With xfce, you can use the branch, or the tracker patch which is based on it. But be sure to save your files, or bad things will happen... Best of all, apply the patch, edit sm.c, and remove or comment out the SmcInteractRequest() call in sm_save_yourself_callback(). No file save prompts, but each Geany instance will be restarted with the set of preferences / interface options / open files it had on logout. Perhaps I should try to check SmcVendor() and skip interaction if xfce. My Googling before the OP suggested that Gnome didn't and there were a lot of unhappy people as a result. Seems like they coudn't even implement that correctly and dropped it... -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Replacing the control socket with dbus
On Sat, 31 Dec 2011 17:26:50 +0100 Arthur Skowronek arthu...@redsmile.org wrote: Hi, http://memegenerator.net/cache/instances/400x/12/12436/12734680.jpg No it's not, and we'll probably have to subclass GApplication too. with this little stupid meme I would like to start a discussion about replacing the current control socket living somewhere in the ~/.config/geany directory space [...] You can put it into /tmp (I do) or anywhere else. These tasks can be accomplished with GApplication too. On top of that we would get rid of: * cluttering the filesystem with sockets $ find / -xdev | wc -l 98565 That's a relatively small (~2.2GB) desktop installation, without /home. * possibility of a dead lock in the doclist command AFAIK, only open and openro are widely (really?) used. * general freeze while a client is connected to the socket. Have you tested how long that lasts? If it doesn't freeze for more than 0.1 seconds, there isn't no point, scintilla delays are much more noticable. The downside would be that the required version for GLib would be pushed to 2.28 and this version is not available on the stable branch for all distributions. I guess that'll be about the time we bump the requirements to gtk+ 2.22 or 2.24. We only recently increased them to 2.16 though... My suggestion therefore is to put this at least on the Todo list and replace it with the planned feature to use dbus. I'm not against that, but is it worth? Greetings and a happy new year :) -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] vergeany :)
geanyentryaction.c:9: * the Free Software Foundation; either vergeany 2 of the License, or geanyentryaction.c:10: * (at your option) any later vergeany. geanymenubuttonaction.c:9: * the Free Software Foundation; either vergeany 2 of the License, or geanymenubuttonaction.c:10: * (at your option) any later vergeany. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] statusbar virtual column
On Sat, 10 Dec 2011 10:53:19 +0100 Frank Lanitz fr...@frank.uvena.de wrote: On Wed, 3 Aug 2011 20:04:18 +0300 Dimitar Zhekov dimitar.zhe...@gmail.com wrote: As you may have noticed, when cursor is in the virtual space (beyond eoln), our status bar always shows the last real column. This small patch adds a new %v (and %V) format specification, [...] Has this patch been applied and or commented at some place? No. You can fetch an up-to-date .diff from the patch tracker: http://sourceforge.net/tracker/?func=detailaid=3399326group_id=153444atid=787793 It would have been nice to document the statusbar format specifications in the manual, instead of pointing to src/ui_utils.c... -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany-Plugins: Git-transition
On Tue, 06 Dec 2011 09:06:23 +0100 Frank Lanitz fr...@frank.uvena.de wrote: Hi developers, Jire and I just finally scheduled git transition of the plugins. [...] Nice. Please let me also know you github accounts if available for committing to plugins etc. zhekov -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Default search behavior is irritating
On Sun, 04 Dec 2011 19:22:55 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 04/12/2011 14:44, Dimitar Zhekov a écrit :
It turned out to be quite easy, because the two meanings are actualy
used separately...
Great!
A few comments:
* I better see the new prefs under the [serach] group, with
pref_main_ prefix stripped;
Moved them just above pref_search_current_file_dir and removed
main_. Not sure about the pref_search_ though. All [search]
settings have a dialog prefix or infix, and pref_search_ looks to me
like Preferences dialog, Search section. If that's not the case,
please rename them as you see fit.
The compatibility code became a bit worse.
* The GeanySearchPrefs struct change breaks the plugin ABI since it
changes the offset of the use_current_word field that is in the API
[1]. Since the prefs are not a whole anymore, just put one in place of
suppress_dialogs and add the other somewhere after use_current_word
(the only field in the API).
suppress_dialogs - always_wrap, hide_find_dialog at end.
--
E-gards: Jimmy
From 15fa8c054cb8f620d9b28a348d01649cd7c37f1e Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov dimitar.zhe...@gmail.com
Date: Mon, 5 Dec 2011 21:24:33 +0200
Subject: [PATCH] split always wrap search and hide find dialog pref into
always wrap search and hide find dialog
---
geany.glade | 26 +++---
src/document.c |2 +-
src/interface.c | 19 +--
src/keyfile.c | 14 --
src/search.c|8 +---
src/search.h|3 ++-
6 files changed, 56 insertions(+), 16 deletions(-)
diff --git a/geany.glade b/geany.glade
index ba18b6f..4037970 100644
--- a/geany.glade
+++ b/geany.glade
@@ -3841,11 +3841,31 @@
property name=spacing0/property
child
-widget class=GtkCheckButton id=check_ask_suppress_search_dialogs
+widget class=GtkCheckButton id=check_always_wrap_search
property name=visibleTrue/property
- property name=tooltip translatable=yesAlways wrap search around the document and hide the Find dialog after clicking Find Next/Previous/property
+ property name=tooltip translatable=yesAlways wrap search around the document/property
property name=can_focusTrue/property
- property name=label translatable=yesAlways wrap search and hide the Find dialog/property
+ property name=label translatable=yesAlways wrap search/property
+ property name=use_underlineTrue/property
+ property name=reliefGTK_RELIEF_NORMAL/property
+ property name=focus_on_clickTrue/property
+ property name=activeFalse/property
+ property name=inconsistentFalse/property
+ property name=draw_indicatorTrue/property
+/widget
+packing
+ property name=padding0/property
+ property name=expandFalse/property
+ property name=fillFalse/property
+/packing
+ /child
+
+ child
+widget class=GtkCheckButton id=check_hide_find_dialog
+ property name=visibleTrue/property
+ property name=tooltip translatable=yesHide the Find dialog after clicking Find Next/Previous/property
+ property name=can_focusTrue/property
+ property name=label translatable=yesHide the Find dialog/property
property name=use_underlineTrue/property
property name=reliefGTK_RELIEF_NORMAL/property
property name=focus_on_clickTrue/property
diff --git a/src/document.c b/src/document.c
index dbc1e39..ad437da 100644
--- a/src/document.c
+++ b/src/document.c
@@ -1939,7 +1939,7 @@ gint document_find_text(GeanyDocument *doc, const gchar *text, const gchar *orig
}
/* we searched only part of the document, so ask whether to wraparound. */
- if (search_prefs.suppress_dialogs ||
+ if (search_prefs.always_wrap ||
dialogs_show_question_full(parent, GTK_STOCK_FIND, GTK_STOCK_CANCEL,
_(Wrap search and find again?), _(\%s\ was not found.), original_text))
{
diff --git a/src/interface.c b/src/interface.c
index ce9fbff..126e794 100644
--- a/src/interface.c
+++ b/src/interface.c
@@ -2574,7 +2574,8 @@ create_prefs_dialog (void)
GtkWidget *frame36;
GtkWidget *alignment39;
GtkWidget *vbox36;
- GtkWidget *check_ask_suppress_search_dialogs;
+ GtkWidget *check_always_wrap_search;
+ GtkWidget *check_hide_find_dialog;
GtkWidget *check_search_use_current_word;
GtkWidget *check_fif_current_dir;
GtkWidget *label215;
@@ -3195,10 +3196,15 @@ create_prefs_dialog (void)
gtk_widget_show (vbox36);
gtk_container_add (GTK_CONTAINER (alignment39), vbox36);
- check_ask_suppress_search_dialogs = gtk_check_button_new_with_mnemonic (_(Always wrap search and hide the Find dialog));
- gtk_widget_show (check_ask_suppress_search_dialogs);
- gtk_box_pack_start (GTK_BOX (vbox36), check_ask_suppress_search_dialogs, FALSE, FALSE, 0);
- gtk_tooltips_set_tip (tooltips, check_ask_suppress_search_dialogs, _(Always wrap search around the document and hide the Find dialog after clicking Find Next
Re: [Geany-devel] Default search behavior is irritating
On Mon, 5 Dec 2011 03:21:45 +0800 Nathan Broadbent nathan@gmail.com wrote: 2009-10-14 05:49:13 ntrel: I suppose we could make the option 'Always wrap' and then change the dialog 'close' checkbox to apply to all actions. Sound OK Enrico? 2009-10-21 10:30:46 eht16: Nick, yes, sounds good. I'm glad they didn't make it. Sounds good, technically, but as Colomban pointed out, it's one thing to close the dialog after finding/marking all matches (very likely), and another to close it after the first or subsequent Next/Previous find. I'm a bit tired of the debate though, so I'm happy to just apply Dimitar's patch and close all of these feature request tickets :) You'll need to re-check the prefs after the patch is officially applied, they'll be in another group and renamed. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Default search behavior is irritating
On Sun, 04 Dec 2011 00:48:40 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Le 03/12/2011 20:56, Dimitar Zhekov a écrit :
There is one, and only one thing, that is unquestionably better IMHO:
separate [ ] Always wrap search and hide the Find dialog into [...]
Yep, this sounds sensible to me. It'd be better flexible and I can
understand somebody was one and not the other. So yeah, go ahead :)
It turned out to be quite easy, because the two meanings are actualy
used separately...
--
E-gards: Jimmy
From 85f038b6978e508c81947535a6ac099790a40d58 Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov dimitar.zhe...@gmail.com
Date: Sun, 4 Dec 2011 15:15:59 +0200
Subject: [PATCH] split always wrap search and hide find dialog pref into
always wrap search and hide find dialog
---
geany.glade | 26 +++---
src/document.c |2 +-
src/interface.c | 19 +--
src/keyfile.c | 19 +--
src/search.c|4 +---
src/search.h|3 ++-
6 files changed, 57 insertions(+), 16 deletions(-)
diff --git a/geany.glade b/geany.glade
index ba18b6f..4037970 100644
--- a/geany.glade
+++ b/geany.glade
@@ -3841,11 +3841,31 @@
property name=spacing0/property
child
-widget class=GtkCheckButton id=check_ask_suppress_search_dialogs
+widget class=GtkCheckButton id=check_always_wrap_search
property name=visibleTrue/property
- property name=tooltip translatable=yesAlways wrap search around the document and hide the Find dialog after clicking Find Next/Previous/property
+ property name=tooltip translatable=yesAlways wrap search around the document/property
property name=can_focusTrue/property
- property name=label translatable=yesAlways wrap search and hide the Find dialog/property
+ property name=label translatable=yesAlways wrap search/property
+ property name=use_underlineTrue/property
+ property name=reliefGTK_RELIEF_NORMAL/property
+ property name=focus_on_clickTrue/property
+ property name=activeFalse/property
+ property name=inconsistentFalse/property
+ property name=draw_indicatorTrue/property
+/widget
+packing
+ property name=padding0/property
+ property name=expandFalse/property
+ property name=fillFalse/property
+/packing
+ /child
+
+ child
+widget class=GtkCheckButton id=check_hide_find_dialog
+ property name=visibleTrue/property
+ property name=tooltip translatable=yesHide the Find dialog after clicking Find Next/Previous/property
+ property name=can_focusTrue/property
+ property name=label translatable=yesHide the Find dialog/property
property name=use_underlineTrue/property
property name=reliefGTK_RELIEF_NORMAL/property
property name=focus_on_clickTrue/property
diff --git a/src/document.c b/src/document.c
index dbc1e39..ad437da 100644
--- a/src/document.c
+++ b/src/document.c
@@ -1939,7 +1939,7 @@ gint document_find_text(GeanyDocument *doc, const gchar *text, const gchar *orig
}
/* we searched only part of the document, so ask whether to wraparound. */
- if (search_prefs.suppress_dialogs ||
+ if (search_prefs.always_wrap ||
dialogs_show_question_full(parent, GTK_STOCK_FIND, GTK_STOCK_CANCEL,
_(Wrap search and find again?), _(\%s\ was not found.), original_text))
{
diff --git a/src/interface.c b/src/interface.c
index ce9fbff..126e794 100644
--- a/src/interface.c
+++ b/src/interface.c
@@ -2574,7 +2574,8 @@ create_prefs_dialog (void)
GtkWidget *frame36;
GtkWidget *alignment39;
GtkWidget *vbox36;
- GtkWidget *check_ask_suppress_search_dialogs;
+ GtkWidget *check_always_wrap_search;
+ GtkWidget *check_hide_find_dialog;
GtkWidget *check_search_use_current_word;
GtkWidget *check_fif_current_dir;
GtkWidget *label215;
@@ -3195,10 +3196,15 @@ create_prefs_dialog (void)
gtk_widget_show (vbox36);
gtk_container_add (GTK_CONTAINER (alignment39), vbox36);
- check_ask_suppress_search_dialogs = gtk_check_button_new_with_mnemonic (_(Always wrap search and hide the Find dialog));
- gtk_widget_show (check_ask_suppress_search_dialogs);
- gtk_box_pack_start (GTK_BOX (vbox36), check_ask_suppress_search_dialogs, FALSE, FALSE, 0);
- gtk_tooltips_set_tip (tooltips, check_ask_suppress_search_dialogs, _(Always wrap search around the document and hide the Find dialog after clicking Find Next/Previous), NULL);
+ check_always_wrap_search = gtk_check_button_new_with_mnemonic (_(Always wrap search));
+ gtk_widget_show (check_always_wrap_search);
+ gtk_box_pack_start (GTK_BOX (vbox36), check_always_wrap_search, FALSE, FALSE, 0);
+ gtk_tooltips_set_tip (tooltips, check_always_wrap_search, _(Always wrap search around the document), NULL);
+
+ check_hide_find_dialog = gtk_check_button_new_with_mnemonic (_(Hide the Find dialog));
+ gtk_widget_show (check_hide_find_dialog);
+ gtk_box_pack_start (GTK_BOX (vbox36
Re: [Geany-devel] Default search behavior is irritating
On Sat, 3 Dec 2011 17:24:45 +0800 Nathan Broadbent nathan@gmail.com wrote: my personal preference is to always wrap search, but keep the find dialog open. This is your personal preference only. So may I please request the following modifications to search: - Move the 'Search' preferences to 'Editor' - 'Search Replace', instead of 'General' - 'Miscellaneous' It took you a little while to find these preferences, and Geany has a manual anyway. - Remove the Always wrap search and hide the Find dialog setting. What about the people who prefer to always hide the open dialog? - Add a 'Wrap search' checkbox to the Find dialog, below the 'Close dialog' checkbox. - Make 'Wrap search' checked by default. And that'll irritate anyone who prefers not to wrap, and has to uncheck 'Wrap search' any time (s)he starts Geany. There is one, and only one thing, that is unquestionably better IMHO: separate [ ] Always wrap search and hide the Find dialog into [ ] Always wrap search and [ ] Hide the Find dialog. It can even be implemented in backwards-compatible way, so if the lead developers approve, I'll give it a try. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] (no subject)
On Thu, 1 Dec 2011 14:57:25 -0500 Meyer 3m.me...@gmail.com wrote: I have two possible situations that I need to differentiate between [...] The first situation is the user deletes selected text by overwriting it with a new character. The second is the user deletes selected text by pressing backspace/delete, and then enters a new character. [...] how I could accomplish this? You can't. The underlying scintilla events are identical. I want to be able to select text, and then insert a character (e.g. an apostrophe) before and after the selection just by pressing the apostrophe key. Since the normal behavior when a character is pressed while text is selected is to delete the text and insert a character [...] Ignore keybindings and see extrasel key-press-event. Remember to check scintilla_get_current() against the widget. Somebody (nathan@gmail.com Nathan Broadbent?) recently asked the exactly same question, and probably works on the same thing. Check the mailing list archive. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Greetings from an IDE refugee
On Sat, 26 Nov 2011 19:31:07 +0100 Liviu Andronic landronim...@gmail.com wrote: I also think that the actual characters are much more appropriate triggers than 'Ctrl+key'. You can do that from a plugin, see extrasel key-press-event. Remember to check scintilla_get_current() against the widget. I fully agree with these points: the feature should be included in core Geany, Hmmm... or best in its 'addons' plugin. Being the author of extrasel, I'd still prefer plugins that connect to key press to stay outside addons. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] --readonly handling
On Mon, 21 Nov 2011 15:49:52 +0100
Colomban Wendling lists@herbesfolles.org wrote:
Looks fine to me, could you provide a git-formatted patch (so there
are authorship information in it) please?
Sure.
Actually -Wmissing-field-initializers warns about fields implicitly
initialized to 0, which is not a real problem but that often is
unwanted.
I guess it's safe to expect that our CC will implement the 1990
standard on this. :)
--
E-gards: Jimmy
From d977e7cca730038893c85f020e67ba7b20f99621 Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov dimitar.zhe...@gmail.com
Date: Mon, 21 Nov 2011 20:33:37 +0200
Subject: [PATCH] --read-only cleanup: use the global variable only when
needed, add an initializer for it in the default options.
---
src/document.c |2 +-
src/main.c | 12 +++-
src/socket.c |4 +---
3 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/src/document.c b/src/document.c
index 48c9885..cf3fdcc 100644
--- a/src/document.c
+++ b/src/document.c
@@ -1162,7 +1162,7 @@ GeanyDocument *document_open_file_full(GeanyDocument *doc, const gchar *filename
doc-has_bom = filedata.bom;
store_saved_encoding(doc); /* store the opened encoding for undo/redo */
- doc-readonly = readonly || filedata.readonly || cl_options.readonly;
+ doc-readonly = readonly || filedata.readonly;
sci_set_readonly(doc-editor-sci, doc-readonly);
/* update line number margin width */
diff --git a/src/main.c b/src/main.c
index 17059ab..20d3d71 100644
--- a/src/main.c
+++ b/src/main.c
@@ -497,7 +497,7 @@ static void parse_command_line_options(gint *argc, gchar ***argv)
GError *error = NULL;
GOptionContext *context;
gint i;
- CommandLineOptions def_clo = {FALSE, NULL, TRUE, -1, -1, FALSE, FALSE};
+ CommandLineOptions def_clo = {FALSE, NULL, TRUE, -1, -1, FALSE, FALSE, FALSE};
/* first initialise cl_options fields with default values */
cl_options = def_clo;
@@ -774,7 +774,7 @@ gboolean main_handle_filename(const gchar *locale_filename)
if (g_file_test(filename, G_FILE_TEST_IS_REGULAR))
{
- doc = document_open_file(filename, FALSE, NULL, NULL);
+ doc = document_open_file(filename, cl_options.readonly, NULL, NULL);
/* add recent file manually if opening_session_files is set */
if (doc != NULL main_status.opening_session_files)
ui_add_recent_document(doc);
@@ -887,19 +887,13 @@ void main_load_project_from_command_line(const gchar *locale_filename, gboolean
static void load_startup_files(gint argc, gchar **argv)
{
gboolean load_project_from_cl = FALSE;
- gboolean cl_files_opened = FALSE;
/* ATM when opening a project file any other filenames are ignored */
load_project_from_cl = (argc 1) g_str_has_suffix(argv[1], .geany);
if (load_project_from_cl argc 2)
g_print(Ignoring extra filenames after %s, argv[1]);
- if (!load_project_from_cl)
- cl_files_opened = open_cl_files(argc, argv);
- /* switch readonly mode off for session files, future files and projects */
- cl_options.readonly = FALSE;
-
- if (! cl_files_opened)
+ if (load_project_from_cl || ! open_cl_files(argc, argv))
{
if (prefs.load_session)
{
diff --git a/src/socket.c b/src/socket.c
index 0299479..92432fc 100644
--- a/src/socket.c
+++ b/src/socket.c
@@ -601,13 +601,11 @@ gboolean socket_lock_input_cb(GIOChannel *source, GIOCondition condition, gpoint
{
if (strncmp(buf, open, 4) == 0)
{
- if (strncmp(buf+4, ro, 2) == 0) /* open in readonly? */
-cl_options.readonly = TRUE;
+ cl_options.readonly = strncmp(buf+4, ro, 2) == 0; /* open in readonly? */
while (socket_fd_gets(sock, buf, sizeof(buf)) != -1 *buf != '.')
{
handle_input_filename(g_strstrip(buf));
}
- cl_options.readonly = FALSE; /* disable again for future files */
popup = TRUE;
}
else if (strncmp(buf, doclist, 7) == 0)
--
1.7.7.1
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] --readonly handling
On Thu, 17 Nov 2011 21:07:41 +0100
Thomas Martitz thomas.mart...@student.htw-berlin.de wrote:
Am 17.11.2011 19:20, schrieb Dimitar Zhekov:
Is there any technical reason to check cl_options.readonly in
document.c, and clear it load_startup_files() [...]
In an earlier version it also worked when opening a .geany file (so all
session files would be opened readonly). As opening via socket also goes
through main_handle_filename() (and hopefully nothing else?), I guess
there's no real reason anymore.
Here's a small patch that cleanups readonly handling, and adds the
missing def_clo.readonly initializer, which was a bug. Tested with
normal and socket open.
BTW, -Wmissing-field-initializers displays a huge number of warnings in
highlightingmappings.h (fill_eol and merge), and no warnings in any
other source file (except def_clo above).
--
E-gards: Jimmy
--- ./src/document.c.orig 2011-11-17 19:36:09.0 +0200
+++ ./src/document.c 2011-11-18 19:03:10.0 +0200
@@ -1162,7 +1162,7 @@
doc-has_bom = filedata.bom;
store_saved_encoding(doc); /* store the opened encoding for undo/redo */
- doc-readonly = readonly || filedata.readonly || cl_options.readonly;
+ doc-readonly = readonly || filedata.readonly;
sci_set_readonly(doc-editor-sci, doc-readonly);
/* update line number margin width */
--- ./src/main.c.orig 2011-11-17 19:36:09.0 +0200
+++ ./src/main.c 2011-11-18 19:24:52.0 +0200
@@ -497,7 +497,7 @@
GError *error = NULL;
GOptionContext *context;
gint i;
- CommandLineOptions def_clo = {FALSE, NULL, TRUE, -1, -1, FALSE, FALSE};
+ CommandLineOptions def_clo = {FALSE, NULL, TRUE, -1, -1, FALSE, FALSE, FALSE};
/* first initialise cl_options fields with default values */
cl_options = def_clo;
@@ -774,7 +774,7 @@
if (g_file_test(filename, G_FILE_TEST_IS_REGULAR))
{
- doc = document_open_file(filename, FALSE, NULL, NULL);
+ doc = document_open_file(filename, cl_options.readonly, NULL, NULL);
/* add recent file manually if opening_session_files is set */
if (doc != NULL main_status.opening_session_files)
ui_add_recent_document(doc);
@@ -887,19 +887,13 @@
static void load_startup_files(gint argc, gchar **argv)
{
gboolean load_project_from_cl = FALSE;
- gboolean cl_files_opened = FALSE;
/* ATM when opening a project file any other filenames are ignored */
load_project_from_cl = (argc 1) g_str_has_suffix(argv[1], .geany);
if (load_project_from_cl argc 2)
g_print(Ignoring extra filenames after %s, argv[1]);
- if (!load_project_from_cl)
- cl_files_opened = open_cl_files(argc, argv);
- /* switch readonly mode off for session files, future files and projects */
- cl_options.readonly = FALSE;
-
- if (! cl_files_opened)
+ if (load_project_from_cl || ! open_cl_files(argc, argv))
{
if (prefs.load_session)
{
--- ./src/socket.c.orig 2011-11-17 19:36:09.0 +0200
+++ ./src/socket.c 2011-11-18 19:25:26.0 +0200
@@ -601,13 +601,11 @@
{
if (strncmp(buf, open, 4) == 0)
{
- if (strncmp(buf+4, ro, 2) == 0) /* open in readonly? */
-cl_options.readonly = TRUE;
+ cl_options.readonly = strncmp(buf+4, ro, 2) == 0; /* open in readonly? */
while (socket_fd_gets(sock, buf, sizeof(buf)) != -1 *buf != '.')
{
handle_input_filename(g_strstrip(buf));
}
- cl_options.readonly = FALSE; /* disable again for future files */
popup = TRUE;
}
else if (strncmp(buf, doclist, 7) == 0)
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] --readonly handling
Hi, Is there any technical reason to check cl_options.readonly in document.c, and clear it load_startup_files(), instead of simply invoking document_open_file(filename, cl_options.readonly, ...) from main_handle_filename()? -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Stub project files for sharing
On Wed, 9 Nov 2011 08:11:45 +1100 Lex Trotman ele...@gmail.com wrote: The simple solution is to add only save if changed as a new feature in stash so its easy to use for the settings that need it. If that's the easy solution... Our instance will not know if another instance has changed something, so a backup stash value won't suffice - the keyfile would have to be re-read. Unless we tolerate a mix of settings, that is... And the vte prefs may or may not appear in stash on Geany start, due to the runtime load vte behaviour. (Excuse me if these were already discussed - TL;DR) Whilst the problem is worth solving, neither suggestion is resolved. So in time honoured tradition I'm going to do nothing, until the issues are sorted. +1. :) -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Convert Unix path separators on Windows when opening documents
commit 13597df9dffdcbd3091aac224d20b1924c563bde Author: Nick Treleaven nick.trelea...@btinternet.com [...] Windows does not allow filenames to contain Unix path separators so this should be safe. Windows treats '/' as directory separator starting with DOS 5.0 IIRC. 100% safe to convert, since a directory separator can never be part of the file name. It would be good to convert any '/' in the messages window filenames too, for document_find_*() to work properly. OTOH, it may be easier to write a real utils_filenamecmp() which assumes '/' == '\\' under Win~1. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Proposal: Project settings split - adding geany features
On Thu, 03 Nov 2011 20:03:02 -0700 Matthew Brush mbr...@codebrainz.ca wrote: At a high level, the most sensible thing to do IMO, is to split out state/session information into a separate file (~/.config/geany/.geanysession) for Geany itself, and then mirror this in the project directory (~/project-under-vcs/foobar.geany and ~/project-under-vcs/.geanysession). Why not ~/.config/geany/geany.session and /.../project.geanysession? I woudn't like geany to place a hidden file in the project directory, with no way to move it in the project file directory. Now take everything I just wrote and apply it to two other files; ~/my-project/projectfile.geany and ~/my-project/.geanysession. When a project opens, the project file and project session file overlay on top of the global/default settings/keys from ~/.config/geany/geany.conf and ~/.config/geany/.geanysession. Changes to the sidebar position for example would get written to ~/my-project/.geanysession and a change of indent type would go into ~/my-project/projectfile.geany. Would be nice, unless Edit - Preferences decides to save the full set of options (even unchanged ones) in projectfile.geany. If I decide to change, say, the symbol list font, and have to do that for every project... well, the current configuration seems pretty reasonable. But compating the two option sets, and (ideally) indicating the default (unchanged) settings with gray, as in the build dialog, goes beyound not exactly trivial. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Proposal: Project settings split
On Wed, 2 Nov 2011 09:39:48 +1100 Lex Trotman ele...@gmail.com wrote: On 2 November 2011 05:19, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Tue, 1 Nov 2011 12:21:25 +1100 Lex Trotman ele...@gmail.com wrote: At which point will you delete the unneeded session files?.. When they fall off the recent projects list. For a small number of projects, that can keep the session file for years after the project is gone. Not a big deal though. For many projects, well, you'd better max the recent count... Am 01.11.2011 23:39, schrieb Lex Trotman: The point is to get the session file out of the project tree, so no this defeats the purpose. The point was to get the file list (i.e. what would be in that session file) out of VCS while keeping the project settings in. This works with separate files even if in the same directory, since every reasonable VCS supports ignoring certain files (svn:ignore, .gitignore). Of course. Personally I prefer to keep my projects clean from at least the object files and executables, but the IDEs do not hesistate to put there various .suo, .dsw, autogenerated .mak, entire directories even. Ignoring one more file (or not putting in on VCS in the first place) is hardly of any significance. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Proposal: Project settings split
On Tue, 1 Nov 2011 12:21:25 +1100 Lex Trotman ele...@gmail.com wrote: On 1 November 2011 11:49, Matthew Brush mbr...@codebrainz.ca wrote: On 11-10-31 04:50 PM, Lex Trotman wrote: Sessions should be user-transparent things like window geometry, number of instances opened, last project/files, etc. and maybe should be workspace/profile-specific. Yes, except for instances. Geany itself shouldn't handle those, thats the session manager's problem. The current sm1 will handle that, unless you decide to separate the default session from geany.conf (which makes some sense btw). But of course Gnome session manager is so broken that several current distros removed the option to use it, so I'm not sure when SM might work right. Without a manager it won't work = same as the current non-sm Geany. (OT: I wonder how many developers will stand a Gnome 3 or Unity interface, with the session support removed on top of that). I will have some time next week, so this thread is to get ideas or objections sorted before then. Applying #3312654 may help you a bit. To prevent the config dir getting too cluttered the session files can be kept only as long as the project remains in the recent projects list. (maybe needs a separate length setting, currently uses file_prefs.mru_length) At which point will you delete the unneeded session files?.. From what I've seen, the IDEs indeed keep the settings and file list separate, but in the same directory. So if you delete the entire project directory, both go (if located there). And when you decide to delete a single project file, the session file is just next to it. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [RFC] Geany Plugin Names
On Fri, 28 Oct 2011 22:41:07 -0700 Matthew Brush mbr...@codebrainz.ca wrote: Is anybody opposed to removing the geany and Geany prefix from the plugins in Geany-Plugins. I mean at least for the directory name in the source tree, README/Site, and PLUGIN_SET_INFO() name? -1. When installing binary packages, typing geany in the search box is the easiest way to see all the plugins. Personally I don't feel like installing the entire geany-plugins package (or all xfce panel plugins, all X11 video drivers etc.) If we decide to remove the prefix, Extra Selections should be Extra Selection. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Speed up simplify stash tree display/update
Hi, Now that StashTreeValue has an entry pointer, value-setting_type and value-key_name can be dropped. Also, the stash_tree_action:_get_iter_first, _iter_next should be written as gtk_tree_model_foreach(model, stash_tree_handle_pref, action). It's ~15% slower, but that doesn't matter any more. And of course, stash_foreach_various_pref can be inlined into stash_tree_setup, and call stash_tree_append_pref directly, or even inline it too. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Geany is on Github
On Fri, 07 Oct 2011 08:28:04 -0700 Matthew Brush mbr...@codebrainz.ca wrote: And don't forget to give me your Github usernames! zhekov -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New Feature(plugin OR geany self)
On Sun, 2 Oct 2011 22:15:56 +0200 Jiří Techet tec...@gmail.com wrote: On Sun, Oct 2, 2011 at 15:36, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: On Thu, 29 Sep 2011 22:52:19 +0200 Jiří Techet tec...@gmail.com wrote: By the way, there's a bug in the MRU code [...] Can you please drop a copy of the patch in Geany bug or patch tracker? https://sourceforge.net/tracker/?func=detailaid=3417269group_id=153444atid=787793 Thanks, and for 0001 0003 too. *sign* The day I'll be using unpatched Geany went farther in the future again... ;) Please apply patch https://sourceforge.net/tracker/?func=detailaid=3417268group_id=153444atid=787793 before - it slightly conflicts with the other patch and as I want to have it in Geany too [...] +1, I would have applied it anyway. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New Feature(plugin OR geany self)
On Thu, 29 Sep 2011 22:52:19 +0200 Jiří Techet tec...@gmail.com wrote: By the way, there's a bug in the MRU code. 1. Open Geany with say 3 files, 2. ctrl-tab until you reach the very same file you have currently displayed, 3. release ctrl, 4. ctrl-tab again. Nothing happens until you ctrl-tab one more time. I have a patch for it in my yet-to-be-reviewed patch queue (for more than a year). I remember having this problem when I worked with very few files. Can you please drop a copy of the patch in Geany bug or patch tracker? I also have a patch for the popup window so it shows the current file in bold and the following three files in MRU below it. It helps with predicting which file opens after ctrl-tab next. Nice. :) You could even return to the file before ctrl+tab press if you overshot [...] I could enhance my patch to allow this too if someone finds it useful. Ctrl+Shift+Tab would be very convinient. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New Feature(plugin OR geany self)
On Thu, 29 Sep 2011 18:13:53 +1000 Lex Trotman ele...@gmail.com wrote: Perhaps another method of indicating such as colouring or re-ordering the notebook tabs could be used instead or as well as the sidebar. I remember seeing red color somewhere, for tabs with changed documents, slowly fading to pink for non-recent changes. On save, it went blue, fading to the (light-gray) tab background color. Didn't liked it, though. Amusing, but distracting. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use GtkBuilder
On Thu, 29 Sep 2011 09:16:26 +1000 Lex Trotman ele...@gmail.com wrote: Hi Dimitar, [...] When checking the various preferences or something, I found 2 crashes when vte is compiled but Ok, if thats the case lets ignore the possibility of runtime loading and just compile it in/out. These were fixed, so don't worry. But I only checked the preferences related stuff (for xsm perhaps?), not the entire code. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use GtkBuilder
On Mon, 26 Sep 2011 12:33:30 +1000 Lex Trotman ele...@gmail.com wrote: On 26 September 2011 01:26, Dimitar Zhekov dimitar.zhe...@gmail.com wrote: When we upgrade (someday) to 2.16, why not make VTE a compile time option only? I can understand why somebody would like to compile Geany without vte support, but since all novadays gtk+ terminal emulators are based on vte, making it a run-time option seems like overkill to me. It was a good thing, several years ago... The problem with this is that means that all binary packages now depend on vte. Of course. However: - when using binary packages, you should be prepared for some extra dependencies - again, all novadays gtk+ terminal emulators are libvte based. If you might want to compile it out, then you might not want to install it. Hmmm... Just how many programs have you seen that can be compiled --with-libfoo but started without libfoo? Aside from Geany, I only know of mplayer which can be compiled with win32 dll-s support, but started even if no dll-s are present, for obvious reasons. If you want to install it out, compile it out. Or there would need to be several binary packages, with and without VTE compiled in which is more maintenance. No sane package maintainer will bother. When checking the various preferences or something, I found 2 crashes when vte is compiled but not loaded. That kind of hints how many people use Geany with vte compiled but not installed... With the runtime check VTE does not need to be installed. Indeed. :) Let's hope there aren't any more crashes. Not that anyone will notice them. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use GtkBuilder
On Sun, 25 Sep 2011 01:53:38 -0700 Matthew Brush mbr...@codebrainz.ca wrote: I've also taken the liberty of porting the Terminal/VTE preferences UI to the new Glade 3 format rather than being hard-coded. IIUC if the VTE/terminal is not enabled for whatever reason, the Terminal tab in the preferences dialog just won't be shown. When we upgrade (someday) to 2.16, why not make VTE a compile time option only? I can understand why somebody would like to compile Geany without vte support, but since all novadays gtk+ terminal emulators are based on vte, making it a run-time option seems like overkill to me. It was a good thing, several years ago... That will require some work, of course: replacing if (vf-func != NULL), cleaning up the vte_info and vc checks. I volunteer. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] saving plugin settings in a project file
On Fri, 23 Sep 2011 19:52:24 +0200 Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: Am 21.09.2011 18:01, schrieb Dimitar Zhekov: What you need is debug sessions, and they depend on the executable being debugged. It doesn't make sense to use the same breakpoints, watches etc. for more than one program, or two sets of these for the same program. I disagree with the very last statement. If you're working at the same project in different branches you might want to debug different parts. Are you using several branches with a single executable name? I prefer to keep my source directories clean and generate the object and executable files outside them, but at least each branch has it's own output directory. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] saving plugin settings in a project file
On Wed, 21 Sep 2011 17:18:14 +0400 Alexander Petukhov de...@apetukhov.ru wrote: What I wanted was to have debug settings loaded at the same time I open files I worked with last time. [...] but now I realize that I can store debug settings for a session in plugins own config, where all other plugin level stuff reside and if a user works with a project - store debug settings in a project, [...] What you need is debug sessions, and they depend on the executable being debugged. It doesn't make sense to use the same breakpoints, watches etc. for more than one program, or two sets of these for the same program. I think you can store the debug session settings in the plugin main and only configuration file, with section names dependent on the full executable name, for example it's md5 sum: /home/build/projects/testing/geany - [945b93c3fe68a0fe63ac6e8e528c59a5] ...settings... /home/build/source/fnatools/fnstofna - [1b216f36ac78dd903085214692c821cc] ...settings... etc. Note that the projects sessions do not necessarily match the debug sessions - for example, a project may produce several executable files, and they will not share the same debugging session. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] How about calling the next release 1.0?
On Tue, 20 Sep 2011 12:07:23 +0200 Jiří Techet tec...@gmail.com wrote: How about getting rid of the 0 version prefix and calling the next release 1.0? +1.0 :) Much more reliable that my primary IDE, which is version 5. Though I'd prefer to see stash-tree-display-5923.diff (from the last (Various pref changes not ignored on dialog cancel message) before that. use_safe_file_saving was renamed, so it won't be nice to leave the last known various prefs problem hanging. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] various prefs warning - changing 'various'
On Fri, 16 Sep 2011 19:25:39 -0700 Matthew Brush mbr...@codebrainz.ca wrote: I can't recall ever encountering the word Various in the context of computers/software. I suppose that's the reason it seems weird. I've seen Miscellaneous preferences, and prefer not to see it again. :) Good thing that my mailer has a spell checker. How is that pronounced is beyond me. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Various pref changes not ignored on dialog cancel
Hi,
Attached is the stash_tree_display(). I thought that a row changed
signal will be needed, but it works without it. The renreders always
reget their data when the tree is shown.
No string changes. _append_pref() ignores the new action argument.
--
E-gards: Jimmy
--- ./src/prefs.c.orig 2011-08-14 14:52:08.0 +0300
+++ ./src/prefs.c 2011-09-16 19:19:18.0 +0300
@@ -109,6 +109,7 @@
{
StashGroup *group;
guint i;
+ GtkWidget *widget = ui_lookup_widget(ui_widgets.prefs_dialog, various_treeview);
foreach_ptr_array(group, i, pref_groups)
{
@@ -123,10 +124,14 @@
}
}
- if (action == PREF_UPDATE)
+ switch (action)
{
- GtkWidget *widget = ui_lookup_widget(ui_widgets.prefs_dialog, various_treeview);
- stash_tree_update(pref_groups, GTK_TREE_VIEW(widget));
+ case PREF_DISPLAY:
+ stash_tree_display(pref_groups, GTK_TREE_VIEW(widget));
+ break;
+ case PREF_UPDATE:
+ stash_tree_update(pref_groups, GTK_TREE_VIEW(widget));
+ break;
}
}
--- ./src/stash.c.orig 2011-08-14 14:52:08.0 +0300
+++ ./src/stash.c 2011-09-16 20:07:23.0 +0300
@@ -1008,10 +1008,11 @@
}
-typedef void (*stash_foreach_pref_func)(StashGroup *group, StashPref *entry, gpointer user_data);
+typedef void (*stash_foreach_pref_func)(StashGroup *group, StashPref *entry, gpointer container,
+ PrefAction action);
static void stash_foreach_various_pref(GPtrArray *group_array, stash_foreach_pref_func pref_func,
- gpointer user_data)
+ gpointer container, PrefAction action)
{
StashGroup *group;
guint i;
@@ -1022,39 +1023,22 @@
if (group-various)
{
foreach_array(StashPref, entry, group-entries)
-pref_func(group, entry, user_data);
+pref_func(group, entry, container, action);
}
}
}
-static void stash_tree_append_pref(StashGroup *group, StashPref *entry, GtkListStore *store)
+static void stash_tree_append_pref(StashGroup *group, StashPref *entry, GtkListStore *store,
+ PrefAction action)
{
- gpointer setting;
GtkTreeIter iter;
StashTreeValue *value;
- switch (entry-setting_type)
- {
- case G_TYPE_BOOLEAN:
- setting = GINT_TO_POINTER(*(gboolean *) entry-setting);
- break;
- case G_TYPE_INT:
- setting = GINT_TO_POINTER(*(gint *) entry-setting);
- break;
- case G_TYPE_STRING:
- setting = g_strdup(*(gchararray *) entry-setting);
- break;
- default:
- g_warning(Unhandled type for %s::%s in %s()!, group-name,
-entry-key_name, G_STRFUNC);
- return;
- }
-
value = g_new(StashTreeValue, 1);
value-setting_type = entry-setting_type;
- value-setting = setting;
+ value-setting = NULL;
value-key_name = entry-key_name;
value-group_name = group-name;
@@ -1077,7 +1061,7 @@
store = gtk_list_store_new(STASH_TREE_COUNT, G_TYPE_STRING, G_TYPE_POINTER);
stash_foreach_various_pref(group_array,
- (stash_foreach_pref_func) stash_tree_append_pref, store);
+ (stash_foreach_pref_func) stash_tree_append_pref, store, PREF_DISPLAY);
gtk_tree_sortable_set_sort_column_id(GTK_TREE_SORTABLE(store), STASH_TREE_NAME,
GTK_SORT_ASCENDING);
@@ -1120,14 +1104,62 @@
}
+static void stash_tree_display_pref(StashTreeValue *value, StashPref *entry)
+{
+ switch (entry-setting_type)
+ {
+ case G_TYPE_BOOLEAN:
+ value-setting = GINT_TO_POINTER(*(gboolean *) entry-setting);
+ break;
+ case G_TYPE_INT:
+ value-setting = GINT_TO_POINTER(*(gint *) entry-setting);
+ break;
+ case G_TYPE_STRING:
+ {
+ g_free(value-setting);
+ value-setting = g_strdup(*(gchararray *) entry-setting);
+ break;
+ }
+ default:
+ g_warning(Unhandled type for %s::%s in %s()!, value-group_name,
+entry-key_name, G_STRFUNC);
+ }
+}
+
+
+static void stash_tree_update_pref(StashTreeValue *value, StashPref *entry)
+{
+ gpointer *setting = value-setting;
+
+ switch (entry-setting_type)
+ {
+ case G_TYPE_BOOLEAN:
+ *(gboolean *) entry-setting = GPOINTER_TO_INT(setting);
+ break;
+ case G_TYPE_INT:
+ *(gint *) entry-setting = GPOINTER_TO_INT(setting);
+ break;
+ case G_TYPE_STRING:
+ {
+ gchararray *text = entry-setting;
+ g_free(*text);
+ *text = g_strdup((gchararray) setting);
+ break;
+ }
+ default:
+ g_warning(Unhandled type for %s::%s in %s()!, value-group_name,
+value-key_name, G_STRFUNC);
+ }
+}
+
/* These functions can handle about 200 settings on a 1GHz x86 CPU in ~0.06 seconds.
* For 250+ settings, you'd better write something more efficient. */
-static void stash_tree_update_pref(StashGroup *group, StashPref *entry, GtkTreeModel *model)
+static void stash_tree_handle_pref(StashGroup *group, StashPref *entry, GtkTreeModel *model,
+ PrefAction action)
{
GtkTreeIter iter;
gboolean valid = gtk_tree_model_get_iter_first(model, iter);
StashTreeValue *value;
- gpointer *setting;
while (valid)
{
@@ -1136,23 +1168,14 @@
if (strcmp(group-name, value-group_name) == 0
strcmp(entry-key_name, value-key_name) == 0)
{
- setting = value-setting;
-
- switch (entry-setting_type)
+ switch (action)
{
-
Re: [Geany-devel] various prefs warning
On Thu, 15 Sep 2011 00:30:44 +0200 Colomban Wendling lists@herbesfolles.org wrote: What are the problems with changing use_safe_file_saving? I don't see how the previous value may affect anything. As you say yourself below, it's a dangerous setting because it changes the way the file saving works, and actually breaks links, permissions, etc. So yes, this one is a sensitive setting. Oh, sorry. At the time of the initial various prefs implementation, there were doubts whether changing any of these settings while Geany is running may break something, so that's the first thing which came to my mind... On Thu, 15 Sep 2011 00:30:44 +0200 Colomban Wendling lists@herbesfolles.org wrote: I'm puzzled between adding annoyance to the user and preventing her to touch sensitive settings without a good reason. On Thu, 15 Sep 2011 09:45:55 +1000 Lex Trotman ele...@gmail.com wrote: Sadly I think warnings are useless, [...] This is a tool for programmers remember, ie us :-) On Thu, 15 Sep 2011 15:48:31 +0100 (BST) Nick Treleaven nick.trelea...@btopenworld.com wrote: I don't want to make it hard to use, just more obvious that the user should be careful. I don't think these settings will or should be changed often, so making the access to them a bit harder shoudn't matter much. However, once the user promises to be careful or whatever, let's give him/her the full page, without horizontal space wasted by an expander, or vertical by a label, or some other widget. A two-page scheme will require a bit more work, of course, but I have free time ATM. Nick, if you don't feel like writing it, drop me a note and I'll give it a try. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Various pref changes not ignored on dialog cancel
On Thu, 15 Sep 2011 17:45:25 +0100 (BST) Nick Treleaven nick.trelea...@btopenworld.com wrote: I've found a bug when changing a various pref setting in the prefs dialog, then cancelling the dialog without applying the changes. Next time the dialog is shown the edited values are still present. Yes, for the integer values. We (me and Colomban) know, and discussed it on the patch tracker page. IIRC, it's a bug in the spin renderer - if you click outside the entry, it generates an editing done signal instead of editing cancelled. Fixing it required nasty hacking, and/or was dependent on the gtk+ version... The other option is to use the text renderer for integers (as you can see, the statusbar_template is OK). As a side effect, the initial page creation will be about 20% faster. But we'll lose the cute arrows. :) -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Various pref changes not ignored on dialog cancel
On Thu, 15 Sep 2011 17:45:25 +0100 (BST) Nick Treleaven nick.trelea...@btopenworld.com wrote: I've found a bug when changing a various pref setting in the prefs dialog, then cancelling the dialog without applying the changes. Next time the dialog is shown the edited values are still present. You are right, the problem is that cancelling will not reset the internal stash tree values (the spin renderer is an unrelated bug). How about adding a PREF_CANCEL action to prefs.c only that will call a stash_group_cancel() to reset the values? The other option is to clear the store, but that means recreating the various list [a visibly slow process] each time Edit - Preferences is invoked, while traversing the model is fast. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] SF.net SVN: geany:[5909] trunk/src/utils.c
On Mon, 12 Sep 2011 15:27:07 +0200 Colomban Wendling lists@herbesfolles.org wrote: Actually firefox on Debian (at least mine?) runs Iceweasel, so it's not a concern from our POV. debian$ cat /usr/bin/firefox #!/bin/sh FIREFOX=$(which $0) [ -x $FIREFOX.real ] exec $FIREFOX.real $@ exec iceweasel $@ -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Why Geany doesn't use exactly what is set in marker_search?
On Fri, 09 Sep 2011 10:55:33 -0400 Jean-Philippe Fleury cont...@jpfleury.net wrote: Thanks for these precisions. However, I'm still not able to make marker_translucency have any effect. See the attached screenshot. There are 4 different settings for marker_translucency, but the little yellow arrow and the plus sign appearing in the margin don't change. With the Markers Margin hidden, you don't have arrow or plus, so the entire line is highlighted instead, with background = 2nd argument of marker_line and transluency = 1st argument of marker_translucency. Blending the arrow or plus sign would a bit pointless. For each modification, I closed Geany and opened it again to be sure it was using new settings in my .conf. If you open the standard geany.conf in Geany, the changes are applied immediately on Save. At least the highlighting. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Why Geany doesn't use exactly what is set in marker_search?
On Fri, 9 Sep 2011 20:44:53 +0300 Dimitar Zhekov dimitar.zhe...@gmail.com wrote: With the Markers Margin hidden, you don't have arrow or plus, so the background = 2nd argument of marker_line and transluency = 1st argument of marker_translucency. The above for the line marker (arrow) only. The marked lines (plus) have background = 2nd arguments of marker_mark and marker_translucency. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New messages/output parsing proposition
On Mon, 29 Aug 2011 11:16:05 +1000 Lex Trotman ele...@gmail.com wrote: Whats anon for? [...] To have it colored as error or warning. A bit of FX. :) Bet we get bug reports that users can't click on it :-) I can trust them that much... :) Best ::= one of the matches defined as Best, which are unlikely to produce wrong results. Primary purpose: avoid matching against all filetype expressions on build. Thats easy to avoid, don't do it :) Yes, it can be easily avoided by by writing the expressions to require one of the known extensions for the file type, and classifying the filename-line-column match as Good. So the Best becomes absolute. Only the regex associated with the command should be used, that is whatever is shown in the configuration GUI for the command. I know how the project / filetype / default hierarhy works, but should have been more clear: User regex for the file type ::= project, fallback filetype file Sorry whats a fallback filetype file? The hierarchy is project filetype setting, user filetype file setting, system filetype file setting, default (is currently blank). The home filetype or the system filetype file. What is the default (is currently blank)?.. I searched Geany for global fallback expression(s) short time ago, but all I could find was parse_compiler_error_line(). I should have been clear that I think that the current behavior is wrong, it should be: if there is a regex use it, otherwise use some default fallback. The filetype independent (make) commands are the ones that might run into multiple languages. [...] Better to assume developers working with mixed languages are competent enough to select the right expressions and or them together. I imagine myself navigating thru the build dialog, copy-pasting all filetype expressions that can be relevant to the project, for every project. And then changing all of them on each slightly different outout... And then I'll finally sit back and say: There is nobody to blameth, cause I brouth this on myself. :) Why even write a new parser then? With enough | separated patterns, even the current one will work just fine. It would be nice to have warn/anon/copy, but they are only extras. Well, I am coming to the conclusion after these discussions that you don't need to write a whole new parser (just saved you lots of work :), rather add the ability to use multiple occurrences of named captures to regexes. Without that the | can't work. With enough | expressions, anything will work. I'll can very long, but a regex limit is 64K... Then if you really want the fun, the fallback when no regex is specified could be upgraded from the current hardcoded routine to use your multiple language search, best match, super dooper[1] technology, but with a preference to turn it on/off in case it produces unwanted results. You saved me even more work. With a single regex defined in 54 system filetypes, and 4 mentions of the message parsing in 1320 tracker items, It odesn't look like anybody needs a new parser, much less anyone is going to define complex new-style regex-es. So I'd better head to more practical things: column support and optional underlining for the Messages tab, and optional mark all Find Usage matches. BTW, how about closing 3039654, and writing some comment for 3156609? The list model will be removed. Default Messages regex-es plus the plugin defined ones should soffice. Plugins can't set regexes ATM because none of build.h is in the API, see other thread. This is something to be re-visited. That's for the Messages only, On messages tab. I don't understand what you mean, sorry. In the Message Window, the Messages tab on the left. It's parsing is completely different from the Compiler tab. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] New messages/output parsing proposition
On Sun, 28 Aug 2011 15:32:19 +1000 Lex Trotman ele...@gmail.com wrote: Whats anon for? I guess its nice to make the error red, but we can't click on it to go anywhere since it doesn't have a file so its different to all the other red lines. To have it colored as error or warning. A bit of FX. :) 2. The following expressions are attempted: If I understand it correctly then I strongly disagree with this section. Trying several expressions and choosing a best match is going to make configuration very complex and cause unexpected interactions. For example changing a command resulting in some slightly different output may cause unexpected changes in the best match giving wrong parses and confusion about where it is happening. Best ::= one of the matches defined as Best, which are unlikely to produce wrong results. Primary purpose: avoid matching against all filetype expressions on build. An inflexible matching with slightly different output will give you the expected beaviour: worse parsing, or none at all. Only the regex associated with the command should be used, that is whatever is shown in the configuration GUI for the command. I know how the project / filetype / default hierarhy works, but should have been more clear: User regex for the file type ::= project, fallback filetype file User independent commands regex ::= project, fallback geany.conf Just use build_get_regex(). For compile, that's exactly what I'm going to do. Using a regex that is hidden from the UI or is not associated with the command is bound to cause confusion. Currently msgwin_parse_compiler_error_line() attempts filetypes_parse_error_message(), which uses build_get_regex(), *and* then falls back to parse_compiler_error_line(). So in On compile, I'm reproducing the present logic, extended with best match. The latter really seems like an overkill for a single file, and I'll remove it. The filetype independent (make) commands are the ones that might run into multiple languages. [...] Better to assume developers working with mixed languages are competent enough to select the right expressions and or them together. And always make the proper changes for a slightly different output. Why even write a new parser then? With enough | separated patterns, even the current one will work just fine. It would be nice to have warn/anon/copy, but they are only extras. (?U) makes all matches non-greedy. (?option) affects the text to the end of the current subpattern, or to the entire pattern if specified outside a subpattern. It may be better to set ungreedy by default, (?-U) is still available, but I didn't want to modify the default POSIX-compatible behaviour. The list model will be removed. Default Messages regex-es plus the plugin defined ones should soffice. Plugins can't set regexes ATM because none of build.h is in the API, see other thread. This is something to be re-visited. That's for the Messages only, On messages tab. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Git for plugins (was: Re: geany on github; why not?)
On Thu, 25 Aug 2011 07:27:47 +0200 Frank Lanitz fr...@frank.uvena.de wrote: On Wed, 24 Aug 2011 23:56:52 +0200 Jiří Techet tec...@gmail.com wrote: About plugins - I'd like to see them converted to git too but for me it's much less important. Plugins are usually one-man-show and require much less cooperation than Geany itself and their authors already have SVN access. Due the huge number of contributors at the plugins project and the, well quiet often broken build, a more decentralized process would be good for the plugins. [...] it would be might useful to make more usage of branches and only merge to trunk, when its apply correct and build is not broken and some other points of policy is met Taking into account what Jiří said, perhaps the plugin developers should try to follow the policy in the first place, before commiting to svn? It's not like they are lacking hard disks and have to use a branch for storage space. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] msgwin line and column position
Hi,
There was no more comments in msgwindow double click, and my reasoning
was partially wrong - a big line number may be a result of some lines
being deleted by the user.
Because the patches affect the same code, I combined them here.
So, this -c version:
Parses an optional column # in the compiler messages.
Handles line/column 0 as 1, and too big line/column as EOF/EOLN.
Alters msgwin_goto_messages_file_line() not to pass invalid line # to
navqueue_goto_line() if we know for sure that the file name is valid.
I tested the patch in the last few days. It seems fine, and is quite
simple anyway.
Any other changes well have to wait after the 0.21 release.
--
E-gards: Jimmy
--- ./doc/geany.txt.orig 2011-07-30 14:02:32.0 +0300
+++ ./doc/geany.txt 2011-08-16 20:38:39.0 +0300
@@ -4057,18 +4057,20 @@
Values that are set in the [build-menu] section will override those in this section.
error_regex
-This is a GNU-style extended regular expression to parse a filename
-and line number from build output. If undefined, Geany will fall
+This is a GNU-style extended regular expression to parse a filename, a line
+number and an optional column from build output. If undefined, Geany will fall
back to its default error message parsing.
-Only the first two matches will be read by Geany. Geany will look for
-a match that is purely digits, and use this for the line number. The
-remaining match will be used as the filename.
+Geany will read the first two (or three, if there is a third) matches, and check
+whether the first or second match is purely digits. If so, it'll try to use the
+matches as line [column] filename, or as filename line [column].
-*Example:* ``error_regex=(.+):([0-9]+):[0-9]+``
+*Example:* ``error_regex=([^:]+):([0-9]+):([0-9]+): |([^:]+):([0-9]+): ``
This will parse a message such as:
``test.py:7:24: E202 whitespace before ']'``
+or (if the first part does not match) as:
+``test.py:7 E202 whitespace before ']'``
**Build commands**
--- ./src/filetypes.c.orig 2011-08-14 14:52:08.0 +0300
+++ ./src/filetypes.c 2011-08-18 20:01:20.0 +0300
@@ -1510,13 +1510,14 @@
gboolean filetypes_parse_error_message(GeanyFiletype *ft, const gchar *message,
- gchar **filename, gint *line)
+ gchar **filename, gint *line, gint *col)
{
gchar *regstr;
gchar **tmp;
GeanyDocument *doc;
regex_t *regex;
- regmatch_t pmatch[3];
+ regmatch_t pmatch[4];
+ gint has_column;
if (ft == NULL)
{
@@ -1531,7 +1532,7 @@
regex = ft-priv-error_regex;
*filename = NULL;
- *line = -1;
+ *line = *col = -1;
if (G_UNLIKELY(! NZV(regstr)))
return FALSE;
@@ -1547,35 +1548,48 @@
if (regexec(regex, message, G_N_ELEMENTS(pmatch), pmatch, 0) != 0)
return FALSE;
+ if (pmatch[2].rm_so == -1 pmatch[3].rm_so != -1)
+ {
+ pmatch[2].rm_so = pmatch[3].rm_so;
+ pmatch[2].rm_eo = pmatch[3].rm_eo;
+ has_column = 0;
+ }
+ else
+ {
+ has_column = pmatch[3].rm_so != -1;
+ }
+
if (pmatch[0].rm_so != -1 pmatch[1].rm_so != -1 pmatch[2].rm_so != -1)
{
- gchar *first, *second, *end;
- glong l;
+ gchar *match[3];
+ int line_idx;
- first = get_regex_match_string(message, pmatch, 1);
- second = get_regex_match_string(message, pmatch, 2);
- l = strtol(first, end, 10);
- if (*end == '\0') /* first is purely decimals */
+ match[0] = get_regex_match_string(message, pmatch, 1);
+ match[1] = get_regex_match_string(message, pmatch, 2);
+ match[2] = has_column ? get_regex_match_string(message, pmatch, 3) : NULL;
+
+ if (utils_str_to_pos(match[0], line, TRUE) != NULL) /* first is purely decimals */
{
- *line = l;
- g_free(first);
- *filename = second;
+ line_idx = 0;
+ *filename = match[1 + has_column];
}
else
{
- l = strtol(second, end, 10);
- if (*end == '\0')
- {
-*line = l;
-g_free(second);
-*filename = first;
- }
+ line_idx = 1;
+ if (utils_str_to_pos(match[1], line, TRUE) != NULL)
+*filename = match[0];
else
- {
-g_free(first);
-g_free(second);
- }
+g_free(match[0]);
}
+
+ if (has_column)
+ {
+ if (*filename != NULL)
+utils_str_to_pos(match[line_idx + 1], col, TRUE);
+ g_free(match[line_idx + 1]);
+ }
+
+ g_free(match[line_idx]);
}
return *filename != NULL;
}
--- ./src/filetypes.h.orig 2011-05-20 20:07:51.0 +0300
+++ ./src/filetypes.h 2011-08-15 19:38:35.0 +0300
@@ -205,6 +205,6 @@
gboolean filetype_has_tags(GeanyFiletype *ft);
gboolean filetypes_parse_error_message(GeanyFiletype *ft, const gchar *message,
- gchar **filename, gint *line);
+ gchar **filename, gint *line, gint *col);
#endif
--- ./src/highlighting.c.orig 2011-06-29 21:06:09.0 +0300
+++ ./src/highlighting.c 2011-08-18 19:52:31.0 +0300
@@ -332,16 +332,6 @@
}
-static void convert_int(const gchar *int_str, gint *val)
-{
- gchar *end;
- gint v = strtol(int_str, end, 10);
-
- if (int_str != end)
- *val = v;
Re: [Geany-devel] Use of Scintilla word boundaries for word searches
On Mon, 22 Aug 2011 14:43:35 +0200 Colomban Wendling lists@herbesfolles.org wrote: Uhm, I mean for FIF grep decides about the word boundaries, which may be different to GEANY_WORDCHARS and everything discussed here, no? Yeah, once a new definition. Though this one is, according to the manual: Word-constituent characters are letters, digits, and the underscore. And it doesn't include any non-ASCII characters in the algorithm, making e.g. word search hé match héhé (second byte of the first é being treat as a separator). grep uses plain char and doesn't support UTF-8. But if your héhé fits in an 8-bit code page, and you have the proper LC_CTYPE set, it works. I checked this with cp1251 боза earlier when we discussed word finding (but was 99% sure it'll work). echo '@@боза@@' | grep -w '@боза@' works too, but echo 'а@боза@@' does not, and neither does '9@...' or '_@...' . So it checks the characters before and after the match for not being isalnum() or underscore. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use of Scintilla word boundaries for word searches
On Mon, 22 Aug 2011 19:22:09 +0200 Colomban Wendling lists@herbesfolles.org wrote: grep uses plain char and doesn't support UTF-8. [...] ...but б@боза@@ will match (at least using UTF-8), [...] Neither the character classes nor the upper/lower cases will work properly if you feed an 8-bit char program with UTF-8. grep -i -w produce lots of false positives and/or negatives, and so will the [] sets. Except for the 8859-1 characters, of course. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Use of Scintilla word boundaries for word searches
On Sat, 20 Aug 2011 23:58:47 +1000 Lex Trotman ele...@gmail.com wrote: Can you point me to where Geany loads locale dependent wordchars and where it gets it from? Scintilla does it... oh, wait. Neither scintilla nor scite can find the word in ‘боза’, or even ‘boza’ (grep does, for 8-bit text). *Gee*. On Sat, 20 Aug 2011 16:46:16 +0200 Colomban Wendling lists@herbesfolles.org wrote: Actually (as supposed in another mail), I guess that a word in Scintilla's opinion when doing a word search is everything non-empty between two whitespace characters, so we DO both. Like the famous ...consists of sequences of non-blank characters separated by blanks. :) My patch tries to use this definition of a word for search, and keeps the other (a sequence of wordchars) for symbol stuff. Well, since using Find previous/next selection on a non-selected g_new0(gchar still finds the next/previous g_new0 or gchar (depending on the cursor position), and not the entire text, I guess it's all right... OTOH, finding regcomp ( in (regcomp ( still doesn't succeed. Guess I can't have it both ways. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
