Dear Geany devs,
Some time ago I received the attached patch though this list (from
Enrico?). I really love the added functionality to prevent duplicate
automatically added quotes and brackets.
Can this be added to Geany itself? Ideally this would be activated
with a checkbox in prefs > editor > completions.
-tnx!-
Harold
I've found one more issue with Geany's "Safe file saving" option. When using g_file_set_contents(), file ownership and permissions are replaced with those for a new file. That fully conforms to GLib documentation (http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.html#g-fil…), but is not good sometimes (e.g. editing an executable script file).
I propose to use GIO API (GFile) instead of g_file_set_contents; the patch is attached. This solution, however, raises some questions:
- It does work for my system (Ubuntu 9.10), but will it work for others, especially Windows? It seems that GIO is also available on Win32, but it requires some testing
- This cannot be named "Safe" file saving, as it does not create a backup first (we can call g_file_replace_contents with make_backup = TRUE, but it would not delete this backup file when the operation completes). Maybe there should be some other configuration option to use (or not to use) this setting? Or should I replace "unsafe" file saving with GIO functions instead of replacing "safe"?
Or even more - make this option work like in GEdit (which, I suppose, uses g_file_replace_contents for both cases, with make_backup=TRUE in "safe" case), adding the corresponding checkbox to preferences dialog?
What do you think?
Hi, all,
This is an alternate implementation of Eugene's X11 session support.
The main difference is that the state each running Geany is saved
into a separate temporary Geany configuration file.
Each Geany is restored exactly it was before the session was closed,
including open files, options (including applied but unsaved),
per-document options (even if no project file is open) etc.
There are no races when saving geany.conf, it's not saved at all. If
you want to save the options, so that the next Geany will use them,
just go to the Geany you want the options from and save them,
exactly as you would do before the session was closed.
Should there be "main" and "option-saving" instances, which ones,
and how should they differ from the "secondary" instances? As Eugene
pointed out, this is not related to the session management, at least
with this SM implementation.
The patch applies against the latest svn-4933. Of course, it should
not be included in 0.19, I only finished it today. Some parts of
Eugene's SM were reverted, since they were not required.
--
E-ragds: Jimmy
Hi All,
I've created this thread separate from Eugene's and Ditmar's session
management threads because my concern is mostly about other parts of Geany
and I don't want to be seen as criticising either of them as it was their
input that started me thinking.
Having multiple Geany instances is a great capability,
* I can have two (or more) projects open to share code or to interrupt work
on one to do something an another,
* I can have Geany on *both* of my screens so I can see different parts of
what I'm working on
* I can set up my filemanager to open different instances so opening random
files won't affect the work I'm doing
My concern is that we should make sure that the way Geany works is safe and
preferably causes no surprises when multiple instances are sharing files.
There are three types of files that Geany instances could share and I think
they should be handled differently:
* Files being edited (the second of my use cases above). I don't think it
is up to Geany to handle users editing the same file in multiple instances,
its up to the user to sort it out when time comes to save. A user can
always set readonly to protect against themselves. Making --readonly a
command line option would be a good addition.
* Project files (same project in two instances), since the user doesn't
explicitly control the project file I think Geany is going to have to become
involved in this case. The only options that I can see in this case are:
** when a project file has changed on disk (by date/time), for Geany to ask
if it should save or save as or throw away any changes to project from this
instance. This way an instance won't silently overwrite changes made by
another instance, and with save as I can procrastinate by saving this
instances changes elsewhere until I can decide which I want.
** only the Geany not started with --new-instance can save the project file
* Geany.conf (shared by any two or more instances), this is a real
potential problem if multiple instances try to save the same file.
Discussions in another thread seemed to come to the conclusion that only the
Geany that was started without --new-instance should save it preventing
races when several instances are closed at once. BUT this is not
implemented in the SVN that is about to become 0.19 and in my test a new
instance overwrote the main Geany.conf losing session, recent files etc!!!
I think that preventing --new-instance from saving project and preference
files should be implemented before 0.19 is released otherwise failing to
close instances in the right order or missing an instance when logging out
will overwrite the preferences. And configuring a filemanager to use
--new-instance will overwrite when closed even if no other Geany is running.
Later on we can look at the other options and also look at indicating to the
user which Geany instances can save, maybe by something after the Geany in
the title bar?
Cheers
Lex
Hi.
Here are two trivial patches to add indication to status bar or
title. I think indication is needed as sometimes it's still important
for user to distinguish main and secondary instances. Personally I
vote for indication in title (I changed my mind after I realized
that status bar is too small for it). AFAIK Lex thinks the same.
Best regards,
Eugene.
Hi all.
When several instances of Geany quit in the same time, there is a high
possibility of a conflict. I can reproduce it easily on my machine,
using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and
another "geany" (absence of file names implies -i automatically in
this case). It would be better to open three different files in
the instances, to distinguish them. Then logout or reboot without
quitting geany manually. On my machine, after I (in case of
trunk) or SM code (in case of SM) restart geany, the default session is
always cleared. Expected behaviour: the default session is managed by
the first of the three instances and contains the files, which
were opened in that instance, after restart.
I can see two solutions for this problem. The first is an
additional POSIX process-shared semaphore / mutex for Windows to guard
geany.conf. This should eliminate the problem completely. AFAIK, there
are no wrappers for process synchronization primitives in GLib, so I'll
need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If
such an instance (#1) detects a "main instance" (#2) running, it should
not touch geany.conf. Actually, to deal with the described issue, it
is enough to implement this behaviour only when #1 tries to save
geany.conf while quitting.
The second option is easier to write as it does not require
additional synchronization primitives and it's possible to reuse the
code of socket.c. Actually, I already have this option implemented, to
check whether it indeed solves the problem. But, you see, this
solution can't prevent the race condition completely, in distinction
from the first solution. Moreover, some of you may consider the second
solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you
think?
Best regards,
Eugene.
Hi all,
Just a quick mail to let everyone know we're planning to make a Geany
0.19 release once everything is ready. We're thinking of early June but
this may change ;-)
So if anyone wants to help test the SVN version, now's a good time to
do so:
http://www.geany.org/Download/SVN
That link also has nightly tarballs and some binaries too. The SVN
version may be buggy and as always there are no guarantees, but
IME it's quite stable (I use it every day). Backup your data.
For plugin developers, it would be great if you can test your plugin
against Geany SVN trunk and update it if necessary.
Regards,
Nick
Hi,
I just wondered why my plugin's name and description wasn't translated
since every other part of my plugin was. But a little thinking made me
realize it's completely "normal": of course bindtextdomain() wasn't
already called for my plugin when plugin_set_info() is called, which
explains it all.
And then, how to solve this? The easy and naive solution would be to call
main_locale_init() in the top of plugin_set_info(), but it doesn't work
since geany_functions isn't set at this time. A manual call to
bindtextdomain() and friends of course solves the problem, but we lose the
cool things that both main_locale_init() (simplicity, consistent Windows
support, etc.) and PLUGIN_SET_INFO() brings.
I think something like PLUGIN_SET_TRANSLATABLE_INFO(localedir, package,
name, description, version, author) (or any other better name) would be a
solution: it would call main_locale_init() (or manually do the stuff
main_locale_init() does) and then set the plugin infos.
In facts, it would only need to set geany_functions & friends /before any/
plugin function call -- even plugin_set_info(). OTHO, it pollutes a bit
gettext's "database" by binding (and perhaps loading?) almost useless
translation domains -- since the plugin might not be loaded -- but it
probably can't be avoided if we want translations at this point.
What do you think? Do you see (an)other solution(s) to fix this? Do you
think it worth it (I definitely think so but still)?
Best regards,
Colomban
PS: Ah, and on a similar topic, why does main_locale_init() call
textdomain()? I think it is useless (and probably pointless) since it
might be re-set to another value by another plugin, and anyway a plugin
should probably only use dgettext() (or glib/gi18n-lib.h's _()).
In current SVN with the following C++ source file
class a {
int flags:8;
};
class c {
int d;
};
tagmanager doesn't recognise c as a class or type or anything.
But it recognises c as a class if either a is a struct not a class or
flags isn't a field (ie no :8). It seems to be the combination that
upsets it.
I havn't been able to find where the problem is so far, can anyone
provide any guidance.
Cheers
Lex
PS Oh yes its perfectly good c++, compiles and all.
Hello!
Just a simple fix of a mismatching deallocation.
Best regards,
Daniel
<P><p><font face="Arial, Helvetica, sans-serif" size="2" style="font-size:13.5px">_______________________________________________________________<BR>Parfym och kosmetik upp till 50% billigare hos BeautyPlanet.se - <a style="font-family: Tahoma, sans-serif; font-size: 12px; color: #00f" href="http://secure-dk.imrworldwide.com/cgi-bin/b?ci=aller-kampanj-se&cg=spray&tu…" target="_blank"> Klicka här!</a></font>