Devel December 2012

devel@lists.geany.org

15 participants
17 discussions

Remove MSYS dependency of Geany on Win~1
by Dimitar Zhekov 12 Dec '12

12 Dec '12

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

5 37

[RFC] Document Messages and File Notification Behaviour (was: buried down deep somewhere)
by Matthew Brush 09 Dec '12

09 Dec '12

Hi All, I'm making this a new thread since I wanted it not to be buried down so deep and I don't know how to do it properly, sorry if the quotations and stuff get messed up :) I've added some discussion topics inline down below. Apologies in advance that it's a bit long winded but I wanted to make sure to explain it properly so we are all on the same page. On 12-12-03 09:05 AM, Nick Treleaven wrote:> On 03/12/2012 14:18, Colomban Wendling wrote: >> Le 03/12/2012 14:35, Nick Treleaven a écrit : >>> On 01/12/2012 06:16, Matthew Brush wrote: >>>> I also made a mockup for "deleted/moved on disk" infobar. I'll put a >>>> link to avoid spamming the list: >>> >>> Thanks for doing the mockups. Infobars probably would be better than the >>> status quo, but I think both of the mockups are too complicated. There >>> are too many options IMO. >>> >>> I'm not sure if 'Close all externally modified files' is worth having >>> and is a safe workflow, certainly it shouldn't include modified >>> documents. >> >> Agreed. I'm not sure it's useful, at least as-is. If we have "close >> all others", why not "reload all others"? And I'm really not sure it >> makes sense to suppose that one wants to perform the same action on all >> files matching the "externally modified" criteria. > > Exactly, usually I want to reload some and close the others. > The only reason I put that there was to allow the workflow discussed in this thread that you, Lex and Thomas mentioned about closing a bunch of generated files when one of them is detected to change on disk. I personally wouldn't use it and I wouldn't have added to the mockup except as the result of the discussions here :) >>> I don't think we need a Close button. Closing the document can be done >>> in the normal way. Or were you planning on disabling normal closing? >>> That would complicate the UI code. >> >> IIUC, the idea was that closing the document "the normal way" would ask >> again if the user didn't make a choice yet. And although it might >> indeed look duplicate, I think it's important to make it a clearly >> visible option as an answer to the question. It being a button or >> something else I don't have an opinion yet. > > OK. Presumably 'normal' save or reload would also ask the user for > confirmation. Are there any other use cases like these, maybe from plugins? > I've done some experimenting on ways to do this. I propose documents get a new "flag" called "doc->priv->notifications_pending" (or whatever). When a document message is posted, the flag is set to TRUE, the infobar is shown within the tab page and tab's close icon changes to the stock-id of the last (or most "important", see below) message. While the tab's icon is not close (when notifications are pending) and the button is clicked, it simply focuses the document (document_show_tab() or whatever), or puts up a modal dialog saying "The tab you are closing has notifications pending, are you sure you want to close it without reviewing them?" before it lets you close it (also for save/save all?). One question is what should clear the "notifications_pending" flag, be it simply having shown the user the tab, confirming a modal dialog, or using the equivalent of a "Dismiss" button in the info bar. For easier inline discussion, I'll itemize the concepts I just discussed: * Notion that documents have "notifications" and they can be "pending" (not yet seen/acknowledged) * Whether we want to use the tab "close" button icon to indicate the type of the last notification that is pending. Alternatives are (existing orange) different color tab label or an additional icon in the tab to the left of the label. * What happens when you click the "close" button in the tab (or file menu, etc), and there are notifications pending? Does it just focus the document/tab or show a special modal warning dialog or something else? * What clears the "notifications pending" status of a document? Should it be the modal dialog from last item, or a "Dismiss" (name TBD) button in the infobar itself or something else? * What actions are "dangerous" to perform while notifications are pending? It seems like these might only be ones that don't work on the "current document" since it's visible and the user will be looking at the notification at the time of the action. - File Menu and Toolbar: - Close All - Save All - Tab Context/RightClick Menu - Close/Close All - Tab "Close" button One problem I noticed with my document-messages branch is that it treats all notifications the same, be it important disk-change events or from other parts of the code (or eventually plugins maybe). From trial and error, I believe the best approach for this is to have a special top-most notification place where important messages can go, and when one of those is posted, it's stock-id overrides any of the normal notification's stock-id in the tab "close" button. Here's an ASCII digram of the widget layout inside the notebook page: |------------|___________________________________ | main.c [!] | documents.c [i] | notebook.c [x] | |--------------------------------------------------------| - | Warning! [Blah] | VBOX2 | | It hit the fan! [Blah] | | |========================================================| | | Info: [Ok] | | | I'm not so important :( | | VBOX1 ---------------------------------------------------------| VBOX3 | | Info: [Ok] | | | I'm not even important enough for you to see | | | me because I'd take up too much screen space. | | |--------------------------------------------------------| - | #include <stdio.h> |^| | int main() { | | | return 0; | | | } | | | | | | |v| |--------------------------------------------------------| Where VBOXes would be separate places to pack the infobars, be it one real GtkVBox and caring about positions or 2 separate, one for each "message area" in a parent vbox (like in the ASCII mockup) or however. IMO, the "important" messages (disk-change, failures, etc) should only be allowed to be 1 message tall, replacing the last if one is already shown (usually ok for disk-change events since latest change is only important IIUC). The number of "normal" notifications allowed at a time is already configurable in the document-messages branch IIRC. Having only "important" also avoids having to deal with overflows and complicated priorities and such if it was all in one "queue". > BTW should we make a release before these changes? Especially if coupled > with the file-monitor instead of disk poll change, I think this will > need time to stabilize. Perhaps we should delay this to 1.24? > I don't have much opinion about whether to release soon, or before these changes, but I don't think we should merge them into master and then do a release right away :) The stuff in document-messages *definitively* not in a releasable state right now, but it's not much more work to make it usable for getting into master for more rigorous development/review/testing. IMO, before we merge this we should bump GTK+ min version to 2.18 to avoid a few #ifdefs and backwards compat stuff it has now. >>>> Mockup for "document changed on disk": >>>> http://codebrainz.ca/images/infobar-mockup.png >>>> >>>> Mockup for "document deleted (or moved) on disk": >>>> http://codebrainz.ca/images/infobar-mockup-deleted.png >>> >>> I'm not sure that 'Save as' is needed, the user can use 'File->Save As' >>> if needed. (Resave is a good option though). >> >> Agreed. Or simply have only "save" (or similar) that triggers a >> pre-filled save as dialog, so one could just hit "save" in it to save >> under the same name. This would (IMO) fill both use-cases of save and >> save as, and having to agree on the file name on such a case doesn't >> look like a big issue to me. > > +1 > >> Also, as I discussed a bit on IRC (without much success though :D), I'm >> not completely sure if the "dismiss" button (we agreed this probably >> wasn't the best name for it BTW) is useful: I personally don't really >> see why somebody would like to hide the warning while not making a >> decision on what to do with the file. >> Though, that's no big deal. > > Agree, we probably shouldn't allow 'Dismiss'. > Thomas also mentioned on IRC that Gedit makes a document "read-only" when it detects disk-changes, which seems like a completely sane and safe thing to do, although potentially also annoying. Do we want to do this as well, in addition to the stuff being discussed above? Cheers, Matthew Brush

5 10

ANN: Scope
by Dimitar Zhekov 08 Dec '12

08 Dec '12

Hi, Since the end of the world is coming soon [1], here [2] is a little something to play with. Note that it currently reads data/scope.glade on startup (no "make install" yet), so geany must be started from the directory where you unpacked scope. Please read scope.html, TODO and notes before asking questions. Of course, there are two questions that I must answer properly first: 1. Why do we need another gdb front-end? Don't know about you. I needed something that runs under win~1, has decent Locale support and the abilities to change values and execute gdb commands at any time. 2. Is it possible to merge debugger and Scope? No more that we can merge SciTE and Geany. They are both editors, based on Scintilla and using gtk+ under *nix, but that's about it. -- Now about the plugin symbols etc. "project-before-save" signal: highly recommended. When a program is started, Scope marks all source files as read-only (unless they are already). When saving a Geany session (file list) while a program is running, Scope temporarily re-marks the source files as read-write, to avoid them being saved in the session with read-only mark. For the default session, "save-settings" does the job, but for project session, an extra signal is required. The signal can also be used for plugin project preferences which are not part of the project dialog. Currentry, no such preferences can be created. ui_setup_open_button_callback() - recommended. Several plugins define their own version of this, and we had a short discussion in the ML, which ended with the "conclusion" that the button/entry must be properly g-objectified, which nobody is willing to do. [3] - recommended. Without it, the toolbar looks funny. editor_get_default_selection() - optional. There should be other plugins defining their own version, but I haven't checked. utils_str_replace_all() - optional. utils_string_replace_all() and several utils_str_*() functions are accessible, so why not this one? ui_add_config_file_menu_item() - maybe unnecessary. Used to add scope.conf to Tools -> Configuration files. Must be modified to return the menu item created, so the plugin can remove it on plugin_cleanup(). stash_tree_{setup,display,update}() - maybe unnecessary. Used to create a stash tree with the global Scope preferences (except for colors etc.) in Plugin Preferences. Not sufficient, since the color and alpha definitions are missing, but looks nice. :) Note that Scope _will_ run on unmodified Geany 1.22 or later. 2012-08-07 or later is recommended due to changes in scintilla. scope.glade was created with 3.6.7, but mostly edited manually. -- [1] http://www.greatdreams.com/end-world.htm [2] http://sourceforge.net/tracker/?func=detail&aid=3593744&group_id=222729&ati… [3] http://sourceforge.net/tracker/?func=detail&aid=3522755&group_id=153444&ati… -- E-gards: Jimmy

2 4

VTE resetting and handling of ^C and ^D
by Colomban Wendling 08 Dec '12

08 Dec '12

Hey, When looking to the VTE code to fix focusing upon middle click, I also dig into the long-running problems we have on dealing with ^C and ^D. First, we try to kill the child (the shell we launched) using SIGINT, but neither BASH nor DASH seem to honor them this way, so we actually only reset the view, thus leading to report like: * https://sourceforge.net/tracker/index.php?func=detail&aid=2623225&group_id=… (I think improperly marked as fixed) * https://sourceforge.net/tracker/index.php?func=detail&aid=3518151&group_id=… You can check it if you want, either by sending SIGINT to a manually-launched BASH or by checking whether the pid actually quit. Anyway, you'll see nothing gets killed. So, I propose to replace this by a SIGHUP. I attached a patch that does it, and it works; but I'm not 100% sure if it's OK to do so, although I don't see much problem with it. Patch is 0001-VTE-Fix-killing-the-child.patch. The other problem is that we reset the terminal upon ^C -- and worse, upon ^D. OK, ^C is used to send SIGINT to the running child, which generally result in it exiting. But first, one generally expect it to only kill the running child [1], and not the terminal itself; and this is important e.g. if the user still want to read the output (e.g. if a program went wild, it may still have output useful errors). And then, legitimate programs handle SIGINT somewhat gracefully -- the excessive example being Nano which uses ^C as a shortcut. So, I don't think ^C should reset the terminal/kill the shell, but rather be handled by the shell. Now ^D. An user expects ^D to send EOF to the stdin of the running child, whatever this might mean to that child; not to behave like ^C and certainly not to reset the terminal/kill the shell. So, to summarize, I think it's important that both ^C and ^D end up being handled by the shell we run in the VTE, and not by us vainly trying to do something that looks like almost not so bad. I search a bit how I could forward ^C and ^D to the VTE child, and didn't find much in the VTE docs; but Wikipedia told me that ASCII ETX and EOT were commonly respectively used to mean ^C and ^D for UNIX terminals [2] [3]. And indeed, sending those using `vte_terminal_feed_child()` seems to work just fine. I however don't know how portable/reliable this is, so I ask for your knowledge and opinion here. Attached patch is 0002-VTE-Really-send-C-and-D-to-the-terminal-rather-than-.patch. Ah, and note that one can still reset the terminal like before through the context menu. So, have you opinions, ideas, remarks, something to say? Looking forward to read you on the subject :) Regards, Colomban [1] and here we speak of the shell's child, not the VTE child which is the shell. [2] https://en.wikipedia.org/wiki/End-of-text_character [3] https://en.wikipedia.org/wiki/End-of-transmission_character

3 8

Can't build geany-plugins
by Harold Aling 07 Dec '12

07 Dec '12

After dist-upgrading to Ubuntu 12.10, updating to the latest Geany and Geany-plugins doesn't seem to work: $ geany -V geany 1.23 (git >= d019741) (built on Dec 4 2012 with GTK 2.24.13, GLib 2.34.0) $ ./waf configure && ./waf build Setting top to : /home/harold/src/geany-plugins Setting out to : /home/harold/src/geany-plugins/_build_ Checking for waf version in 1.6.1-1.7.0 : ok Checking for 'gcc' (c compiler) : ok Checking for program pkg-config : /usr/bin/pkg-config Checking for 'gtk+-2.0' >= 2.16.0 : yes Checking for 'geany' >= 1.23 : not found The configuration failed (complete log in /home/harold/src/geany-plugins/_build_/config.log) $ cat /home/harold/src/geany-plugins/_build_/config.log ... Checking for 'geany' >= 1.23 ['/usr/bin/pkg-config', '--atleast-version=1.23', 'geany'] not found from /home/harold/src/geany-plugins: The configuration failed Geany is prefixed with /usr/local, just like -plugins defaults to. Is this an Ubuntu error, user error, or is something wrong in the configure waf script of geany-plugins? Cheers! Harold

4 8

Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465
by Amit Sengupta 03 Dec '12

03 Dec '12

hey! It's about the bug http://sourceforge.net/tracker/?func=detail&aid=3587465&group_id=153444&ati… i tried to debug it by changing the buttons to YES No buttons, I figured out that the document.c is the file associated with this bug. original code static void monitor_reload_file(GeanyDocument *doc) { gchar *base_name = g_path_get_basename(doc->file_name); gint ret; ret = dialogs_show_prompt(NULL, GTK_STOCK_CLOSE, GTK_RESPONSE_CLOSE, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, _("_Reload"), GTK_RESPONSE_ACCEPT, _("Do you want to reload it?"), _("The file '%s' on the disk is more recent than\nthe current buffer."), base_name); g_free(base_name); if (ret == GTK_RESPONSE_ACCEPT) document_reload_file(doc, doc->encoding); else if (ret == GTK_RESPONSE_CLOSE) document_close(doc); } Modified code static void monitor_reload_file(GeanyDocument *doc) { gchar *base_name = g_path_get_basename(doc->file_name); gint ret; ret = dialogs_show_prompt(NULL, GTK_STOCK_CLOSE, GTK_RESPONSE_CLOSE, GTK_STOCK_NO, GTK_RESPONSE_NO, GTK_STOCK_YES, GTK_RESPONSE_YES, _("Do you want to reload it?"), _("The file '%s' on the disk is more recent than\nthe current buffer."), base_name); g_free(base_name); if (ret == GTK_RESPONSE_YES) document_reload_file(doc, doc->encoding); else if (ret == GTK_RESPONSE_CLOSE) document_close(doc); } How to test this code locally when I try make install I get this output [amit@localhost geany-1.22]$ make install Making install in tagmanager make[1]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager' Making install in mio make[2]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/mio' make[3]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/mio' make[3]: Nothing to be done for `install-exec-am'. make[3]: Nothing to be done for `install-data-am'. make[3]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/mio' make[2]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/mio' Making install in include make[2]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/include' make[3]: Entering directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/include' make[3]: Nothing to be done for `install-exec-am'. /usr/bin/mkdir -p '/usr/local/include/geany/tagmanager' /usr/bin/mkdir: cannot create directory `/usr/local/include/geany': Permission denied make[3]: *** [install-tagmanager_includeHEADERS] Error 1 make[3]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/include' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager/include' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/amit/Programming/Geany/geany-1.22/tagmanager' make: *** [install-recursive] Error 1 Can anyone please help me with this so that I can test this, also how to submit the code (ie if I get it right) ps: attaching the modified document.c. Thanks Regards Amit

6 26

[PATCH] "allow_always_save" wrong usage
by Quentin Glidic 02 Dec '12

02 Dec '12

Hello, Currently, the allow_always_save preference is checked in document_save_file but it should only matters for the UI items (menu item and toolbar button), as the manual description states. Attached a patch to fix this behavior. “Save” works as expected, auto-save (from Addons) does not force file saving and “Save all” is not sensitive, which was the case before the patch too. Cheers, -- Quentin “Sardem FF7” Glidic

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel December 2012