Re: [Geany-devel] Separating session file lists from config (again)
On Tue, 2 Oct 2012 13:03:00 +1000 Lex Trotman wrote: > Are all settings saved on apply? not just the prefs/project prefs ones? I > thought there were some that still didn't for one reason or another, maybe > that should be changed as a separate thing anyway, in which case you are > right, the "rush" only applies to session data. Edit -> Preferences -> OK|Apply saves the entire geany.conf: dialog preferences, UI settings and file list. Project -> Properties -> OK saves the entire $project.conf: project settings and file list. File -> Quit does both. Saving dialog preferences and project settings on Quit does not make real sense, but it's the same file, so there is no reason to separate them. Yet they are internally separate (static) functions, see keyfile.c:configuration_save() and project.c:write_config(). -- No interest in having 2+ sessions for a project?.. -- 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 Wed, 12 Sep 2012 11:35:48 +1000 Lex Trotman 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 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 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 di
Re: [Geany-devel] Separating session file lists from config (again)
On Mon, 10 Sep 2012 14:36:32 +1000
Lex Trotman 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 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] Signal Handling
On Sun, 09 Sep 2012 19:41:19 -0700 Matthew Brush 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] patch: separated session/local config
On Sat, 4 Aug 2012 10:58:54 +1000 Lex Trotman 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 DE> and it didn't work but 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 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 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 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 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 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 <>___ 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.
On Sat, 28 Jul 2012 15:30:38 +0200 Emanuel Palm wrote: > Hey guys! Hi, Emanuel. > *1. To single out the application from the crowd.* Of course - but half of my free Win~1 software uses circles or near-circle ellipses with something inside. The proposed icons will be lost among them. > *2. To communicate the ambition that has been, and is being put into the > software.* As a light IDE, Geany is mostly complete. It's supported, but "enthusiastically developing it" would be an overstatement. Though new or improved plugins are not rare. With that in mind, I'd prefer a solid icon, more so that we released Geany version 1 recently, and should have done that at least 10 months ago. > *As of today most professional looking icons/logos are based on simple > curves and/or shapes to make them explicit and harmonious. They use few, > but carefully chosen, colors. [...] Looking at my Linux panel [attachment], the best icons are pseudo-3d, and not that simple. Now, I know that the latest trend is flat UI-s with few colors - just look at Metro - but what may look fresh and simple to novadays programmers reminds me of the early 90-s, when we used such things due to lack of resources. (Care to comment, Lex?:) > *3. To communicate the purpose of the application.* "Programming" is a somewhat abstract concept, and I have yet to see an icon that expresses it. (Except for Matrix Layout, where block schemes were used to describe the control flow.) 4. There is one more practical requirement: the icon should look good in sizes 16, 22, 24, 32, 48 and 64 pixels (size 22 is very often used for 24 too). Both proposed icons are good in >= 48, _v1 is acceptable in 32, and the lower sizes are bad - run GIMP and see for yourself. The current icon 16x16 icon is bad too. To make the small sizes look really good, one must save the svg as png, and then edit it manually. Personally I'd be happy with the current icon, but with the perspective of your _v1 icon (which will simplify it somewhat, the isometric POV makes it too complex), less flashy yellow, larger body, and of course, the bright red gems changes to something else, they're an eyesore. Which means rewriting it completely... -- 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 wrote: > On Tue, 10 Jul 2012 21:20:55 +0300 > Dimitar Zhekov 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 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] Usability fix - saving tab state
On Tue, 10 Jul 2012 23:09:42 +0300 Axel 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] Usability fix - saving tab state
On Tue, 10 Jul 2012 01:41:46 +0300 Axel wrote: > I believe there is a usability flaw in Geany - opened documents' list is > saved only if you exit the editor in 'traditional' way (by clicking exit > button or so). It's completely lost, if the process's killed. This was > irritating for me, as I tend not to close every program when shutting down, > but rather push the 'shutdown' button and get them all killed - and get the > list of opened documents lost. There is a X11 session management patch on Geany sourceforge patch tracker. Applies against 1.22, but not the newest svn. Not guaranteed to work under GNOME, they always have problems with session support. Won't ask you to save any modified files under Xfce, xfsm is buggy too. > Anyway, this wasn't hard to fix - just calling *configuration_save()* upon > opening or closing a file. 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... 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. (not 'you' personally, I mean any user) > Operation itself seems to be cheap (although it's rewriting a config > completely, as I see) - noticed no performance issues on my 1 GB RAM > netbook. It's cheap if your config directory (a) is local and (b) resides on a hard drive or SSD. That's OK for the majority of users, but not all. (N.B. I'm not a leading developer, so the decision will not be 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] Remove MSYS dependency of Geany on Win~1
On Tue, 10 Jul 2012 12:55:58 +0100 Nick Treleaven 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 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 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 14:41:25 +0100 Nick Treleaven 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
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On Thu, 28 Jun 2012 16:28:50 +0200 Thomas Martitz 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 Tue, 26 Jun 2012 21:21:57 +0100 Nick Treleaven 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 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 \ -
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On Fri, 22 Jun 2012 13:08:22 -0700 Matthew Brush wrote: Hi. Here is a small diff (for makefile.win32 and src/makefile.win32 only) that makes Geany 1.22 Win~1 compilation and installation independent of MSYS. Usage: C> mingw32-make -f makefile.win32 C> mingw32-make -f makefile.win32 install Tested with mingw, cmd/tcc. Should work with MSYS make too... but I had to use backslashes in the install: target, and am not sure if/how MSYS make escapes them. Win~1 fully supports forward slashes internally, but the command interpreters have only partial support. > 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 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 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 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 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 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 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 - /plugins/? Currently only lua uses one of those, as /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 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] 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
[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] 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
Re: [Geany-devel] Small additions to stash
On Fri, 06 Apr 2012 14:06:48 +0100 Nick Treleaven 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] public ui_setup_open_button_callback
On Thu, 05 Apr 2012 13:03:20 -0700 Matthew Brush wrote: > On 12-04-05 11:56 AM, Dimitar Zhekov wrote: > > Hi, > > > > Currently UIUtilsFuncs contain ui_path_box_new(), so a > > file-chooser-dialog button can be created programatically in a plugin. > > But there's no ui_setup_open_button_callback(), so it's impossible to > > load such a button from a .glade file and setup it, as in Geany. > > [...] > > IMO, all this path box stuff should be deprecated in favour of the > widget provided by the toolkit (GtkFileChooserButton). [...] GtkFileChooserButton does not support SAVE. Is there any way to "choose" a non-existent file?.. > On the other hand, I also wouldn't be opposed to a proper implementation > of a real custom GtkWidget subclass (ex. GeanyPathBox) that can be used > in Glade and otherwise conveniently, since I tend to find the text box > next to the button to be more user-friendly than the widget currently > provided by the toolkit for this purpose. Neither would I, but GtkFileChooserButton is 3000 lines with the header file... Anyway, currently Geany has ui_path_box_new(), which is accessible from plugins, and ui_setup_open_button_callback(), which is not. The former is inconvinient for a .glade interface, and with 2+ selectors it may be easier for to copy-paste the callback from, say, spellcheck, and use it with builder widgets... -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] public ui_setup_open_button_callback
Hi,
Currently UIUtilsFuncs contain ui_path_box_new(), so a
file-chooser-dialog button can be created programatically in a plugin.
But there's no ui_setup_open_button_callback(), so it's impossible to
load such a button from a .glade file and setup it, as in Geany.
geanyprj uses ui_path_box_new(), and other plugins (saveactions,
spellcheck, debugger, ...) create file-chooser-dialog buttons manually,
so they seem common. I'm writing a new plugin, and would prefer to
use .glade for the interface as much as possible (and practical).
--
E-gards: Jimmy
>From 3a2ffc4931342c193eeb69e2960c11eb6b5fdf06 Mon Sep 17 00:00:00 2001
From: Dimitar Zhekov
Date: Thu, 5 Apr 2012 21:51:15 +0300
Subject: [PATCH] public ui_setup_open_button_callback()
---
plugins/geanyfunctions.h |2 ++
src/plugindata.h |2 ++
src/plugins.c|3 ++-
3 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/plugins/geanyfunctions.h b/plugins/geanyfunctions.h
index d41d77e..7ef54df 100644
--- a/plugins/geanyfunctions.h
+++ b/plugins/geanyfunctions.h
@@ -304,6 +304,8 @@
geany_functions->p_ui->ui_menu_add_document_items_sorted
#define ui_lookup_stock_label \
geany_functions->p_ui->ui_lookup_stock_label
+#define ui_setup_open_button_callback \
+ geany_functions->p_ui->ui_setup_open_button_callback
#define dialogs_show_question \
geany_functions->p_dialogs->dialogs_show_question
#define dialogs_show_msgbox \
diff --git a/src/plugindata.h b/src/plugindata.h
index 77d6964..a5120a3 100644
--- a/src/plugindata.h
+++ b/src/plugindata.h
@@ -482,6 +482,8 @@ typedef struct UIUtilsFuncs
void (*ui_menu_add_document_items_sorted) (GtkMenu *menu, struct GeanyDocument *active,
GCallback callback, GCompareFunc compare_func);
const gchar* (*ui_lookup_stock_label)(const gchar *stock_id);
+ void (*ui_setup_open_button_callback)(GtkWidget *open_btn, const gchar *title,
+GtkFileChooserAction action, GtkEntry *entry);
}
UIUtilsFuncs;
diff --git a/src/plugins.c b/src/plugins.c
index 42bec5d..6e02984 100644
--- a/src/plugins.c
+++ b/src/plugins.c
@@ -248,7 +248,8 @@ static UIUtilsFuncs uiutils_funcs = {
&ui_get_gtk_settings_integer,
&ui_combo_box_add_to_history,
&ui_menu_add_document_items_sorted,
- &ui_lookup_stock_label
+ &ui_lookup_stock_label,
+ &ui_setup_open_button_callback
};
static DialogFuncs dialog_funcs = {
--
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] Small additions to stash
On Thu, 05 Apr 2012 17:20:44 +0100
Nick Treleaven 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
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
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 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 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 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
Re: [Geany-devel] run command in terminal window
On Thu, 8 Mar 2012 14:01:08 + Tim Mason wrote: > I have a couple of simple plugins that open an external console window > (e.g. gnome-terminal or konsole) and run a command. Is there any way > to make the command run in the Terminal window (VTE) instead? No. Geany VTE support is compile-time and even run-time option. However, you can open a new tab in the messages panel from a plugin, and spawn your program in a vte terminal inside it. There would be 2 tabs with terminals, geany-s and yours; no conflicts between them. Oh, and you don't have to g_module_open(vte), just link it. If I had some time and support from the main developers, I would have removed the runtime option. -- 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
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 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 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-.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 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 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
[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
On Mon, 20 Feb 2012 22:40:50 +0100 Jiří Techet wrote: > On Mon, Feb 20, 2012 at 17:51, Dimitar Zhekov > 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
Re: [Geany-devel] Some obsolete(?) bug reports
On Mon, 20 Feb 2012 21:00:44 +0100 Colomban Wendling 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] Some obsolete(?) bug reports
On Mon, 20 Feb 2012 20:00:38 +0100 Colomban Wendling 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 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 Sat, 18 Feb 2012 14:17:17 +0100
Colomban Wendling 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
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] Empty project properties dialog
Hi, Jiří, On Mon, 20 Feb 2012 00:35:24 +0100 Jiří Techet 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
Hi, > 3. "geany xyz.txt" does not load files from session - ID: 2838686 With Lex, Colomban, Enrico and Eugene for it, and Matthew's "don't know", I'll do it tomorrow, using the rewritten load_startup_files. So we will be able to easily make it a pref, should it turn out that lots of people like the current behaviour. :) -- 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, 13 Feb 2012 17:14:19 -0800 Matthew Brush wrote: > > 3. "geany xyz.txt" does not load files from session - ID: 2838686 [3] > > > > Here it wasn't decided whether of not Geany should restore session. I > > suggest we discuss this question and finally either fix the bug or mark > > it as WONTFIX. > > > > I don't often use Geany for opening files from the command line and > usually I always have a Geany window open so if I do, it's not an issue, > so I can't really provide a worthwhile opinion here. As the bug report states, opening a file _with your file manager_ or CLI loses the last [default] session [if no geany is running]. The complaints we usually got were "I double-clicked foo.c and lost my session", to which we usually replied "use projects". So this affects the GUI, even more than CLI. 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 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=detail&aid=3312654&group_id=153444&atid=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 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 Thu, 2 Feb 2012 10:14:15 +1100 Lex Trotman wrote: > It would be really good if someone other than me tests it, my test > plugin is rather dumb. I tested with the following code in plugin_init(): build_set_menu_item(GEANY_BCS_PROJ, GEANY_GBG_EXEC, 1, GEANY_BC_LABEL, "boza"); And, after I open a project and load the plugin, Set Build Commands looks like this: <> Tested with the previous BuildFuncs version (without group_count). Execute command #1 initially exists but with all fields empty. -- In plugin.h BuildFuncs, void (*build_remove_menu_item), and void (*build_set_menu_item) are indented with spaces instead of tabs. -- 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 wrote: > On Wed, Feb 1, 2012 at 5:20 AM, Dimitar Zhekov > wrote: > > On Tue, 31 Jan 2012 15:39:52 +1100 > > > > I compile Geany with -Wall -W -Wno-unused-parameter (not the normal > > practice) and received a few warnings: > > Well, it should be normal practice, thats what HACKING says, I just > forgot to set it with a new clean clone, oops. Actually you should > add -O2 because a couple of the warnings need the dataflow computation > that the optimisation does. I only listed the warnings, -O2 is a sine qua non (albeit -Os -freorder-blocks is better for some systems). > The semantics of a command (well actually the label) that is "" vs > NULL is important, a "" label hides commands from a lower priority > source without showing itself in the menu, a NULL does not. [...] > > Unfortunately there isn't anthing else besides NULL that is sensible > to return to indicate out of range. So returning "" for COMMAND is possible... > So I've exposed build_get_group_count() as well so you can get the > count and then its your fault if you pass an out of range index :). ...but a count is fine too. :) Let's hope BuildFuncs makes it into the plugin interface, the current lack of build access is weird. -- 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 Tue, 31 Jan 2012 15:39:52 +1100 Lex Trotman wrote: > Dimitar, Matthew, > > See git://github.com/elextr/geany.git, the more testing the better :) > I compile Geany with -Wall -W -Wno-unused-parameter (not the normal practice) and received a few warnings: build.c: In function 'build_get_current_menu_item': build.c:576:2: warning: enumeration value 'GEANY_BC_CMDENTRIES_COUNT' not handled in switch [-Wswitch] build.c: In function 'build_set_menu_item': build.c:620:2: warning: enumeration value 'GEANY_BC_CMDENTRIES_COUNT' not handled in switch [-Wswitch] build.c:607:9: warning: unused variable 'str' [-Wunused-variable] These are probably harmless. build_get_current_menu_item() works, and returns the non-expanded values (%e, %f) as I expected. About returning NULL instead of "" for the empty fields, I'm not very sure. How do we separate a completely empty command with a valid cmd, such as the 3rd default C command, and an out-of-range cmd? -- 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 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 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 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 +M: Dimitar Zhekov +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 +M: Dimitar Zhekov +W: http://sheckley.users.sourceforge.net +S: Supported geanylatex P: Frank Lanitz -- 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 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] Session Management Interim Solution Proposal
Hi, all, Some guys with GNOME 2/3/Unify, KDE 3/4 and LXDE, can you please check if the X11R4 session protocol works? Just activate your "save session on logout", run a couple of gtk+ programs (evince/charmap without gnome support, firefox, transmission, ...), then logout, login, and see if the programs are restarted. Information about smaller WM-s with some kind of "session support" is welcome too. -- On Mon, 2 Jan 2012 09:48:36 +1100 Lex Trotman wrote: > Hi Dimitar, > > > Aside from [...] XSMP, which was never implemented properly by > > anyone except maybe the KDE4 guys, there's something called "legacy" > > X11 session protocol. It's OK, except that no "Save foo.c"? questions > > are allowed (this part of XSMP is implemented especially bad anyway). > > Am I right in thinking that what you are saying is that the situation > is a mess, but that you *may* be able to get the legacy mode running? XSMP support is a grief. And looking at GNOME, I'm now unsure which DE-s support X11R4 (let's avoid "legacy", which in gnome means "xsmp"). As of ability, WM_SAVE_YOURSELF is much easier to support than XSMP, and the change will affect almost exclusively sm.c, anything else being 95% identical to the existing sm code. Many years ago, I extended the nedit save yourself handler a bit, in the (never released) 5.6 version. > Won't allow user choice for saving files but will restore session? Yes. -- 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 Interim Solution Proposal
On Sun, 1 Jan 2012 10:27:43 +1100 Lex Trotman wrote: > Hi All, > > Seasons greetings to all. :) > Since Gnome seems to have irretrievably broken X session management it > does not seem likely that proper session management will be solved in > the near term. Sadly this seems to waste all the good work that the > guys put into the SM branch, thanks for the effort. Aside from the exceptionally beautiful, absolutely powerful and unlimitely portable XSMP, which was never implemented properly by anyone except maybe the KDE4 guys, there's something called "legacy" X11 session protocol. It's OK, except that no "Save foo.c"? questions are allowed (this part of XSMP is implemented especially bad anyway). The legacy protocol is supported by all major DE-s, and I think even the automatic builtin restart of gtk+ applications uses it. See also: google: WM_SAVE_YOURSELF, nedit sources, my recent comment to http://sourceforge.net/tracker/?func=detail&aid=3361963&group_id=153444&atid=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] Replacing the control socket with dbus
On Sat, 31 Dec 2011 17:26:50 +0100 Arthur Skowronek 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 wrote: > On Wed, 3 Aug 2011 20:04:18 +0300 > Dimitar Zhekov 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=detail&aid=3399326&group_id=153444&atid=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 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 Mon, 5 Dec 2011 03:21:45 +0800 Nathan Broadbent 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 19:22:55 +0100
Colomban Wendling 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
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 @@
0
-
+
True
- Always wrap search around the document and hide the Find dialog after clicking Find Next/Previous
+ Always wrap search around the document
True
- Always wrap search and hide the Find dialog
+ Always wrap search
+ True
+ GTK_RELIEF_NORMAL
+ True
+ False
+ False
+ True
+
+
+ 0
+ False
+ False
+
+
+
+
+
+ True
+ Hide the Find dialog after clicking Find Next/Previous
+ True
+ Hide the Find dialog
True
GTK_RELIEF_NORMAL
True
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), check_hide_find_dialog, FALSE, FALSE, 0);
+ gtk_tooltips_set_tip (tooltips, check_hide_find_dialog, _("Hide the Find dialog after clicking Find Next/Previous"), NULL);
check_search_use_current_word = gt
Re: [Geany-devel] Default search behavior is irritating
On Sun, 04 Dec 2011 00:48:40 +0100
Colomban Wendling 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
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 @@
0
-
+
True
- Always wrap search around the document and hide the Find dialog after clicking Find Next/Previous
+ Always wrap search around the document
True
- Always wrap search and hide the Find dialog
+ Always wrap search
+ True
+ GTK_RELIEF_NORMAL
+ True
+ False
+ False
+ True
+
+
+ 0
+ False
+ False
+
+
+
+
+
+ True
+ Hide the Find dialog after clicking Find Next/Previous
+ True
+ Hide the Find dialog
True
GTK_RELIEF_NORMAL
True
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), check_hide_find_dialog, FALSE, FALSE, 0);
+ gtk_tooltips_set_tip (tooltips, check_hide_find_dialog, _("Hide the Find dialog after clicking Find Next/Previous"), NULL);
check_search_use_current_word = gtk_check_button_new_with_mnemonic (_("Use the current word under the cursor for Find dialogs"));
gtk_widget_show (check_search_use_current_word);
@@ -5185,7 +5191,8 @@ create_prefs_dialog (void)
GLADE_HOOKUP_OBJECT (prefs_dialog, frame36, "frame36");
GLADE_HOOKUP_OBJECT (prefs_dialog, alignment39, "alignment39");
GLADE_HOOKUP_OBJECT (prefs_dialog, vbox36, "vbox36");
- GLADE_HOOKUP_OBJECT (prefs_dialog, check_ask_suppress_search_dialogs, "check_ask_suppress_search_dialogs");
+ GLADE_HOOKUP_OBJECT (prefs_dialog, check_always_wrap_search, "check_always_wrap_search");
+ GLADE_HOOKUP_OBJECT
Re: [Geany-devel] Default search behavior is irritating
On Sat, 3 Dec 2011 17:24:45 +0800 Nathan Broadbent 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 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 wrote: > > I also think that the actual characters are much more > > appropriate triggers than 'Ctrl+'. 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 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
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 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 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 > [...] 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 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 wrote: > On 2 November 2011 05:19, Dimitar Zhekov wrote: > > On Tue, 1 Nov 2011 12:21:25 +1100 > > Lex Trotman 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 wrote: > On 1 November 2011 11:49, Matthew Brush 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 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 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 wrote: > On Sun, Oct 2, 2011 at 15:36, Dimitar Zhekov wrote: > > > On Thu, 29 Sep 2011 22:52:19 +0200 > > Jiří Techet 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=detail&aid=3417269&group_id=153444&atid=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=detail&aid=3417268&group_id=153444&atid=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 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] Use GtkBuilder
On Thu, 29 Sep 2011 09:16:26 +1000 Lex Trotman 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] New Feature(plugin OR geany self)
On Thu, 29 Sep 2011 18:13:53 +1000 Lex Trotman 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 Mon, 26 Sep 2011 12:33:30 +1000 Lex Trotman wrote: > On 26 September 2011 01:26, Dimitar Zhekov 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 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 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 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 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 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 (
Re: [Geany-devel] Various pref changes not ignored on dialog cancel
On Fri, 16 Sep 2011 11:33:31 +0100 (BST) Nick Treleaven wrote: > > How about adding a PREF_CANCEL action to prefs.c only > > that will call a > > stash_group_cancel() to reset the values? > > I don't think that's a good design, the stash group settings should > not actually be changed until ok/apply. On Thu, 15 Sep 2011 22:48:06 +0200 Colomban Wendling wrote: > > What about traversing the model on reshow to reset it to > > the default values? > > Yes, that would be best. Of course, PREF_CANCEL was stupid. Actually, it should create the StartTreeValue entries on _setup, set them on PREF_DISPLAY, and get them on PREF_UPDATE (the latter is currently implemented). > (This would be similar to how all stash prefs work with > stash_group_display - the widgets are updated with the current > settings). Almost identical. I'll try to write it today. -- 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 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
