[Geany-devel] SM Client_ + Legacy_
Hi. First, let me apologize for not noticing the sm option replication. Mea culpa. Now to the point. I went ahead and tested the sm, and ran into a problem: in the X11 session, the geany instances are stored both as Client_ (by sm.c) and Legacy_ (by gtk/gdk, as in 0.18). Normally a gdk_set_sm_client_id(new_client_id) would fix this, but there is a side effect. The XSM window settings (maximized state, desktop# etc.) are applied to the first window open by the session client, and since sm_init() is run after the main geany window is created: 1. Geany always appears on the first desktop. 2. If you choose File - Open or Edit - Preferences, and geany was maximized, the Open or Preferences dialog appears maximized instead. That depends on the dialog, for example, Open may also appear minimized, while Find seems unaffected. Using gdk_set_sm_client_id() and moving sm_init() before main_init() will fix this, and since sm_init() is very limited, that shouldn't break anything... but I'm not sure. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Shift-10 on editor tab
Hi, Shift-F10 in an editor tab pops up a nice list of open documents. I'm proposing to change this shortcut to Shift-MenuKey. I can add, instead of replace, it if Shift-F10 is too important for you, but replacing is easy. What do you think? Thanks, bye. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Shift-10 on editor tab
2010/3/3 Can Koy can...@ymail.com: Hi, Shift-F10 in an editor tab pops up a nice list of open documents. I'm proposing to change this shortcut to Shift-MenuKey. I can add, instead of replace, it if Shift-F10 is too important for you, but replacing is easy. What do you think? Hi Can, I think Shift+F10 is something like a default behaviour which is written down in some guidline or anything like that. Also, many users may already know Shift+F10 as usual keybinding, so replacing it wouldn't be the best solution. So, adding Shift+MenuKey instead of replacing would be my choice. Regards, Dominic ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Shift-10 on editor tab
- Original Message From: Dominic Hopf dma...@googlemail.com To: Geany development list geany-devel@uvena.de Sent: Wed, March 3, 2010 3:33:56 PM Subject: Re: [Geany-devel] Shift-10 on editor tab 2010/3/3 Can Koy : Hi, Shift-F10 in an editor tab pops up a nice list of open documents. I'm proposing to change this shortcut to Shift-MenuKey. I can add, instead of replace, it if Shift-F10 is too important for you, but replacing is easy. What do you think? Hi Can, I think Shift+F10 is something like a default behaviour which is written down in some guidline or anything like that. That guide is Gnome HIG, and Shift-F10 is already NOT behaving as stated in the guide, i.e. show contextual menu (right-click). Also, many users may already know Shift+F10 as usual keybinding, so replacing it wouldn't be the best solution. Replacing it (and make Shift-F10 behave like right-click later if required) would make Geany comply with HIG actually, that's one reason I suggested it. (Shift-F10 is also clumsy compared to Shift-MenuKey, but that's my opinion.) Thanks, bye. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] [Patch] - Fix keyboard accelerator on Resave Missing File dialog.
From: Lex Trotman ele...@gmail.com To: Geany development list geany-devel@uvena.de Sent: Tue, March 2, 2010 4:28:34 AM Subject: Re: [Geany-devel] [Patch] - Fix keyboard accelerator on Resave Missing File dialog. Can, BTW I have never even seen this dialog, so for finding it, and noticing the inconsistency, and trying to do something about it you deserve thanks for the effort. Lex, I'm not searching for things to fix/improve in Geany per se. As I've stated in my introduction mail, I've opted for fulfilling my needs which are mostly about keyboard usage; I favor keep-hands-on-keyboard scheme while editing. That dialog appears when the file corresponding to a document is renamed or deleted outside Geany. Thanks, bye. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Shift-10 on editor tab
Am Mittwoch, den 03.03.2010, 06:20 -0800 schrieb Can Koy: - Original Message From: Dominic Hopf dma...@googlemail.com To: Geany development list geany-devel@uvena.de Sent: Wed, March 3, 2010 3:33:56 PM Subject: Re: [Geany-devel] Shift-10 on editor tab 2010/3/3 Can Koy : Hi, Shift-F10 in an editor tab pops up a nice list of open documents. I'm proposing to change this shortcut to Shift-MenuKey. I can add, instead of replace, it if Shift-F10 is too important for you, but replacing is easy. What do you think? Hi Can, I think Shift+F10 is something like a default behaviour which is written down in some guidline or anything like that. That guide is Gnome HIG, and Shift-F10 is already NOT behaving as stated in the guide, i.e. show contextual menu (right-click). Also, many users may already know Shift+F10 as usual keybinding, so replacing it wouldn't be the best solution. Replacing it (and make Shift-F10 behave like right-click later if required) would make Geany comply with HIG actually, that's one reason I suggested it. (Shift-F10 is also clumsy compared to Shift-MenuKey, but that's my opinion.) Well, AFAIK Geany tries to be as best Gnome HIG as it can, so your suggestion should be appreciated. I personally like being as close to a guideline as possible, so a replacement wouldn't be that problem for me. ;) But let's wait what others think about this. :) Regards, Dominic -- Dominic Hopf dma...@googlemail.com http://dominichopf.de/ Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Edit/Save config files anomaly?
On Tue, Mar 2, 2010 at 10:59 PM, Tony Rick tony...@gmail.com wrote:
At revision 4720.
I'm trying to understand the Tools-Configuration Files Edit/Save behavior,
so that I can mimic that in a plugin that does the same thing for template
files. When I select *snippets.conf* from the *Configuration Files*submenu,
and there is no
*snippets.conf* in *~/.config/geany (app-configdir)*, the default file
from */usr/share/geany (app-datadir)* is obviously opened, but a Status
message is issued indicating that the file is opened in *~/.config/geany
(app-configdir)*. I take this to mean that the override convention
(files in *configdir* overriding files of the same name in *datadir)* is
being enforced in the editor. However, when I save the modified file, using
either the *Save* icon or * File-Save*, I am put into a file save dialog,
as if I had selected* File-Save As*.
Is this the specified behavior? Having the *File-Save As* dialog appear
when *Save* is specified is confusing and inconsistent. It seems to me
that if the override convention is being enforced, selecting *Save* should
write the modified file to the location reported in the Status window
without question, and the save location dialog only offered specifically
when *Save As* is selected. If the override convention is not being
enforced in the editor, then the Status message is misleading. The manual
does not refer specifically to this behavior, only to the fact that *.conf
* can be manually copied to *configdir* and modified, and will then
override the default file. I think it is more consistent to have the
editor enforce the override file location policy by default on *Save*,
allow *File-Save As *to be used as an option at the user's discretion,
and state the override file location policy and the editor's enforcement of
such clearly in the manual.
Here's a simple patch that modifies the Save behavior for config files
edited from the Tools-Configuration Files submenu for your consideration.
Config files that are read from the geany data directory (because they did
not already exist in the local config directory) will be saved to the local
config directory by default.
- tony
Index: ui_utils.c
===
--- ui_utils.c (revision 4720)
+++ ui_utils.c (working copy)
@@ -1729,6 +1729,7 @@
{
const gchar *file_name = user_data;
GeanyFiletype *ft = NULL;
+ GeanyDocument *doc;
if (strstr(file_name, G_DIR_SEPARATOR_S filetypes.))
ft = filetypes[GEANY_FILETYPES_CONF];
@@ -1747,7 +1748,15 @@
if (g_file_test(global_file, G_FILE_TEST_EXISTS))
g_file_get_contents(global_file, global_content, NULL, NULL);
- document_new_file(utf8, ft, global_content);
+ doc = document_new_file(utf8, ft, global_content);
+
+ /* Enforce config file override policy by populating doc-real_path, which in turn
+ * allows document to be saved directly to file_name location.
+ * This is fuzzy, I don't know whether 'global_file' or 'utf8' is the
+ * correct choice here - tony rick 3mar2010
+ */
+ doc-real_path = g_strdup(global_file);
+
utils_free_pointers(4, utf8, base_name, global_file, global_content, NULL);
}
}
___
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
[Geany-devel] Build system 2.0, default configuration dialog
Hi All, As suggested by Nick, this is a new thread to discuss what should be in the default build configuration dialog, the full configurability will be provided by a plugin that replaces the default one. Below is pasted from previous thread. ... I think for the core Execute command(s) a checkbox for whether to run without xterm/VTE per command for GUI programs is good. This gives me an opening to start discussion on what functionality should be exposed by the core configuration dialog, thanks Nick. ;-) I actually went back to 0.18.1 and looked at what is available there, and I think that the following need to be added, but I'm open to suggestions: Hmm, this seems quite complicated. You know we accept current trunk as good, no need to rethink everything. It is actually slightly simpler than current trunk. The current trunk arrangement has one major problem though, the project settings and the non-project settings are configured in separate dialogs, having settings that interact in different places is very poor user interface design (which I accept responsibility for creating). I want to put them in one place. 1. edit each of the make commands individually (0.18.1 has single setting shared by all three) 2. edit project build settings (don't exist in 0.18.1) for make commands only, not filetype 3. edit working directory for each command (doesn't exist in 0.18.1) 4. if above, remove make in base path since its no longer needed 5. for execute commands only, the option to run without terminal, checkbox (new) 6. single shared parsing regex per filetype (hidden setting, not in GUI in 0.18.1, this is used for make commands as well based on current document) It might be less confusing to have another regex for the make commands as well? Actually I made a mistake here, the current trunk does have a separate make regex so keep that Things to not make available (to avoid dialog shock): 1. edit menu item label 2. which commands are parsed and which are not 3. which commands are stopable and which are not 4. extra commands in sections (propose simple dialog allows editing 2 fieltype,3 make,2 execute) 5. change internal command locations (next/prev error, show dialog) 6. project filetype commands (just so the dialog is smaller) 7. parsing regex per command, source or global 8. viewing settings from non-editable sources ie default, system filetypes, plugins/internal ... Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
