Devel May 2010

devel@lists.geany.org

18 participants
43 discussions

Include "auto_brace_check_dup" patch?
by Harold Aling 06 Mar '11

06 Mar '11

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

2 7

Safe file saving - permissions issue
by Алексей Антипов 02 Nov '10

02 Nov '10

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?

7 24

altername session management implementation
by Dimitar Zhekov 08 Oct '10

08 Oct '10

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

5 27

Multiple instances of Geany issues
by Lex Trotman 17 Jun '10

17 Jun '10

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

4 58

[PATCH] New instance indication
by Eugene Arshinov 17 Jun '10

17 Jun '10

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.

4 5

Race condition when saving geany.conf
by Eugene Arshinov 10 Jun '10

10 Jun '10

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.

10 47

Planning the 0.19 release
by Nick Treleaven 06 Jun '10

06 Jun '10

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

3 3

About translation of plugin name and description
by Colomban Wendling 03 Jun '10

03 Jun '10

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 _()).

2 9

C++ tagmanager not recognising classes after field
by Lex Trotman 31 May '10

31 May '10

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.

2 3

[Patch] tagmanager/sort.c - g_malloc --> use g_free instead of free
by Daniel Marjamaki 30 May '10

30 May '10

Hello! Just a simple fix of a mismatching deallocation. Best regards, Daniel _______________________________________________________________ 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>

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel May 2010