[Geany-devel] Killing Builds
Hi All, As requested by Enrico, a new thread for discussion of issues around killing builds and UI changes. I've pasted a little from previous discussions as a seed. >>I can see that you may want to kill a long build that you started by >>accident or when you realise you forgot to do something first. I've >>done that more than once ;-) > >I guess we all had this issue already. At the time we added the Stop >button for the Run command we also tried implementing this for the Make >commands. But as you both noticed in this thread, it's not that easy. I >don't say it's not possible but it's just not as easy as it may sound. >>commands are set insensitive until completion. To have one menu item >>still enabled and to have it change to stop is going to be quite a bit >>of fiddling unless it is always a fixed menu item or a toolbar button. > >Yes, as you say it, I'm thinking about. We actually could add a >separate Stop button for the toolbar and the Build menu, That would >obsolete a lot of not so nice code in build.c which deals with the >double action of the button. And since the toolbar is pretty easy to >configure these days, that probably would not be a big deal UI-wise. >Though I don't have a strong opinion on that. Just share your thoughts >about this, maybe in a separate new thread. The switching execute menu items is a lot cleaner in the build-system version. At leasts IMHO, shouldn't comment on own code should I.;-) My real concern is that Geany should not have a built-in kill build because of the difficulties associated with killing every child spawned from the build and the risk of the build directories being left in a strange state when the build is killed. This is especially true now that the build sysytem can run anything in any directory. That took up lots of the discussion on the previous thread and I won't repeat it here. Thats why I encouraged Thomas to write an external script that users can configure into Geany and modify if needed. If we coded something into Geany then users can't fix it to solve problems they run into. This also helps with portability, users can create and contribute scripts for many different systems where finding child processes differ or where the particular scripting language doesn't exist. Of course having a specific menu item and toolbar which can be configured to run that script is still ok, I wouldn't have a problem with it in the build menu, it would essentially be an execute menu item with a different label. Probably positioned after the make menu items? Because of the risks mentioned above I believe that this menu item/toolbutton should not be available by default, maybe configured by preference or hidden preference by users who know what they are doing :-) Cheers Lex ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Resetting menu accels - Re: Super modifier in keybindings - Re: Strange Geany behavior
Sorry, Gmail hides the quotes and I forget to delete them. Cheers Lex 2009/8/18 Thomas Martitz : > It would be nice if you would only quote as much as you're referring to. > These full quotes make your emails really hard to read. > > Best regards. > ___ > Geany-devel mailing list > Geany-devel@uvena.de > http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Resetting menu accels - Re: Super modifier in keybindings - Re: Strange Geany behavior
It would be nice if you would only quote as much as you're referring to. These full quotes make your emails really hard to read. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Resetting menu accels - Re: Super modifier in keybindings - Re: Strange Geany behavior
2009/8/18 Enrico Tröger : > On Mon, 17 Aug 2009 12:38:22 +1000, Lex wrote: > >>2009/8/17 Enrico Tröger : >>> On Sun, 16 Aug 2009 13:51:39 +1000, Lex wrote: >>> 2009/8/16 Enrico Tröger : > On Fri, 14 Aug 2009 11:59:27 +1000, Lex wrote: > > >>but I think the following should make it into a menu (actually a >>submenu, since I don't think they are commonly used enough to go >>in a top level menu) and I have suggested which new submenu to put >>them in. >> >>Ctrl-K delete current line popup-edit >>Ctrl-T transpose current line popup-edit >>Ctrl-Shift-X cut line popup-edit >>Ctrl-Shift-C copy line popup-edit >>Alt-Shift-W select word edit-select and >>popup-select Alt-Shift-P select para edit-select >>and popup-select Alt-Shift-L select line >>edit-select and popup-select insert alt whitspace popup-edit >> indent space popup-indent >> undent space popup-indent >> prev indent popup-indent >>Ctrl-B matching brace edit-goto popup-goto >>Ctrl-M toggle marker edit-goto popup-goto >>Ctrl-. next marker " " >>Ctrl-, prev marker " " > > Cool, thanks for this list. Note that this is only for 0.17, I'm not sure how many more 0.18 will add. > However, I fail to make any sense of the third column. Could you > give some hint about what exactly "popup-edit", "popup-select" and > the others mean? Thanks. > My apologies, I was trying to suggest adding a new submenu of either >>> >>> No need to apologise. Maybe I just didn't try hard enough, anyway, >>> now it's pretty clear (and obvious :). >>> >>> popup-edit means new edit submenu of right click popup popup-indent means new indent submenu of right click popup popup-goto means a new goto submenu of right click popup edit-select means a new select submenu of the main edit menu edit-goto means a new goto submenu of the main edit menu Where more than one is listed on the same line I am suggesting putting the item in both. >>> >>> Ok. But to be honest I really don't want to add *anything* more to >>> the right click popup menu. It's already very big. When considering >>> the Gnome HIG, it's way too big. But I think in our case that's ok >>> as long as we don't fill the menu even more. >>> >>> For the Edit menu in the file menu, I think we could add a new >>> submenu like "More Actions" or something which then lists the >>> actions you mentioned maybe in more sub menus sorted by categories >>> (as you did above). This way we would not bloat the existing menus >>> really and still gain the benefit of having menu items for most >>> keybindings. >>> >>> Don't get me wrong, I'm all for it, my only worries are not to bloat >>> the menus too much. >>> >> >>Totally agree with all you said. >> >>Maybe submenus of the popup for the inserts and the finds could help >>shrink it. > > Uhhh, dangerous topic :). > We already had the find items in a submenu but I voted against it as at > least I personally use them a lot from the popup menu and hiding them > in a submenu reduces usuability. This might be a pretty personal > rationale but I really would like to keep these items as they are :). > Though I would agree about the insert items. I also thought about > moving them into a plugin (at least 'insert date' and 'insert > include...') especially because 'insert include' is very specific to > C/C++ and not of any use for other filetypes. But I still didn't come > around to actually do it. > > Maybe we could group the 'insert date', 'insert include...' items into > a new submenu, so we would save one toplevel menu item and then we > could also put various more menu items into this new submenu for > keybindings (i.e. those of your list). > Nick? > > >>To be honest I don't use the popup much, I use keybindings mostly so I >>am probably not best qualified to say whats common use and whats not & >>can go to a submenu. > > Who is qualified to say this at all? Every user has different use cases > of the GUI, the keybindings and everything else. It's always hard to > make such decisions. > Perhaps I could have added, I don't have strong feelings about the popup. So I'm happy for you to do whatever you think is ok, including not putting anything in the popup and instead putting everything in the main edit menu using an insert submenu for the insert items to make space for one or two submenus That would not change the size of level one of the edit menu. PS the GTK bug that is the original topic of this thread is fixed. Cheers Lex > Regards, > Enrico > > -- > Get my GPG key from http://www.uvena.de/pub.asc > > __
Re: [Geany-devel] ANN: New Release: Geany 0.18
On Tue, 18 Aug 2009 03:39:53 +0300, Yura wrote: >On Sun, 16 Aug 2009 20:45:00 +0200 >Enrico Tröger wrote: > >> we are happy to announce a new release of Geany! > >It seems that KP_End and KP_Home keys don't work in 0.18. End and Home >key works fine. In 0.17 End, Home, KP_End and KP_Home works fine. >Tested at work and at home (x86 and amd64). Thanks for reporting. They indeed broke. I think this should be fixed now in SVN by mapping the numpad keys to their "normal" equivalents, the code is based on the same thing happening in Scintilla. If it doesn't work or breaks something else or not all necessary keys were mapped, just tell us, as usual :). Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpQ1aYpBxTXm.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: New Release: Geany 0.18
On Sun, 16 Aug 2009 20:45:00 +0200 Enrico Tröger wrote: > we are happy to announce a new release of Geany! It seems that KP_End and KP_Home keys don't work in 0.18. End and Home key works fine. In 0.17 End, Home, KP_End and KP_Home works fine. Tested at work and at home (x86 and amd64). -- Yura Siamashka ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] ANN: Configurable Build Menu Alpha in SVN
On Sun, 16 Aug 2009 15:00:18 +1000, Lex wrote: Hey guys, I won't respond on all details of this part of the thread due to lack of time and more importantly because of lack of knowledge at some parts. One comment though: a Perl dependency is not an option even not if it were installed on 100% of all users' systems :). >I can see that you may want to kill a long build that you started by >accident or when you realise you forgot to do something first. I've >done that more than once ;-) I guess we all had this issue already. At the time we added the Stop button for the Run command we also tried implementing this for the Make commands. But as you both noticed in this thread, it's not that easy. I don't say it's not possible but it's just not as easy as it may sound. >Due to problems on windows, builds have to be run synchronously on >windows, ie the whole of Geany freezes while the build runs (why? I >don't understand exactly, maybe Enrico can explain it). I think I did explain it in http://lists.uvena.de/pipermail/geany-devel/2009-April/000584.html. If not, just ask again what exactly is not clear, then I'd be happy to explain it in more detail. >That means that cancelling a windows build can't be done from Geany >anyway. Yes, sort of. In theory it should be even easier to kill a synchronous build but the problem is the user can't do this because the GUI is frozen and doesn't react to any input until the build is finished. So yes, you are right, the process can't be killed at all. Anyway, I don't see this as a major issue as the whole synchronous build thing on Windows is not meant to be the final way. It's more or less only a temporary hack until someone shows up with time and/or knowledge (ideally both) on how to do it right on Windows :). >Whilst Linux builds are still asynchronous only one is allowed at a >time so that output isn't mixed up in the error parser. So all build >commands are set insensitive until completion. To have one menu item >still enabled and to have it change to stop is going to be quite a bit >of fiddling unless it is always a fixed menu item or a toolbar button. Yes, as you say it, I'm thinking about. We actually could add a separate Stop button for the toolbar and the Build menu, That would obsolete a lot of not so nice code in build.c which deals with the double action of the button. And since the toolbar is pretty easy to configure these days, that probably would not be a big deal UI-wise. Though I don't have a strong opinion on that. Just share your thoughts about this, maybe in a separate new thread. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpoBMBznOEVb.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Resetting menu accels - Re: Super modifier in keybindings - Re: Strange Geany behavior
On Mon, 17 Aug 2009 12:38:22 +1000, Lex wrote: >2009/8/17 Enrico Tröger : >> On Sun, 16 Aug 2009 13:51:39 +1000, Lex wrote: >> >>>2009/8/16 Enrico Tröger : On Fri, 14 Aug 2009 11:59:27 +1000, Lex wrote: >but I think the following should make it into a menu (actually a >submenu, since I don't think they are commonly used enough to go >in a top level menu) and I have suggested which new submenu to put >them in. > >Ctrl-K delete current line popup-edit >Ctrl-T transpose current line popup-edit >Ctrl-Shift-X cut line popup-edit >Ctrl-Shift-C copy line popup-edit >Alt-Shift-W select word edit-select and >popup-select Alt-Shift-P select para edit-select >and popup-select Alt-Shift-L select line >edit-select and popup-select insert alt whitspace popup-edit > indent space popup-indent > undent space popup-indent > prev indent popup-indent >Ctrl-B matching brace edit-goto popup-goto >Ctrl-M toggle marker edit-goto popup-goto >Ctrl-. next marker " " >Ctrl-, prev marker " " Cool, thanks for this list. >>> >>>Note that this is only for 0.17, I'm not sure how many more 0.18 will >>>add. >>> However, I fail to make any sense of the third column. Could you give some hint about what exactly "popup-edit", "popup-select" and the others mean? Thanks. >>> >>>My apologies, I was trying to suggest adding a new submenu of either >> >> No need to apologise. Maybe I just didn't try hard enough, anyway, >> now it's pretty clear (and obvious :). >> >> >>>popup-edit means new edit submenu of right click popup >>>popup-indent means new indent submenu of right click popup >>>popup-goto means a new goto submenu of right click popup >>>edit-select means a new select submenu of the main edit menu >>>edit-goto means a new goto submenu of the main edit menu >>> >>>Where more than one is listed on the same line I am suggesting >>>putting the item in both. >> >> Ok. But to be honest I really don't want to add *anything* more to >> the right click popup menu. It's already very big. When considering >> the Gnome HIG, it's way too big. But I think in our case that's ok >> as long as we don't fill the menu even more. >> >> For the Edit menu in the file menu, I think we could add a new >> submenu like "More Actions" or something which then lists the >> actions you mentioned maybe in more sub menus sorted by categories >> (as you did above). This way we would not bloat the existing menus >> really and still gain the benefit of having menu items for most >> keybindings. >> >> Don't get me wrong, I'm all for it, my only worries are not to bloat >> the menus too much. >> > >Totally agree with all you said. > >Maybe submenus of the popup for the inserts and the finds could help >shrink it. Uhhh, dangerous topic :). We already had the find items in a submenu but I voted against it as at least I personally use them a lot from the popup menu and hiding them in a submenu reduces usuability. This might be a pretty personal rationale but I really would like to keep these items as they are :). Though I would agree about the insert items. I also thought about moving them into a plugin (at least 'insert date' and 'insert include...') especially because 'insert include' is very specific to C/C++ and not of any use for other filetypes. But I still didn't come around to actually do it. Maybe we could group the 'insert date', 'insert include...' items into a new submenu, so we would save one toplevel menu item and then we could also put various more menu items into this new submenu for keybindings (i.e. those of your list). Nick? >To be honest I don't use the popup much, I use keybindings mostly so I >am probably not best qualified to say whats common use and whats not & >can go to a submenu. Who is qualified to say this at all? Every user has different use cases of the GUI, the keybindings and everything else. It's always hard to make such decisions. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc pgpqUiT3vNWvs.pgp Description: PGP signature ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] sciwrappers.h not compilable ?
On Sun, 16 Aug 2009 22:28:45 +0200 Enrico Tröger wrote: > >#ifndef GEANY_H > >#warning geany.h needs to be included before this file > >#endif > > > >in sciwrappers.h for example. > > We could do this but to get any sense of it we would do this in all > public header files. I also don't think it's worth it, it's ugly and another thing to have to copy & paste into a header file each time we make a new one. Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] sciwrappers.h not compilable ?
On Sun, 16 Aug 2009 23:36:29 +0200 Enrico Tröger wrote: > Ok, I got it now. Sorry. > Still in Geany itself, first include geany.h, for any plugins just > include geanyplugin.h and you are done. > Yes, we could change the code so that headers are safer to be > included more randomly but who does it? > Regarding Geany's core code, basically, it is just geany.h which you > should include at first. Other headers' order doesn't matter much. > > In my first post in this thread I said the order of the includes is > important, that is only partly true and with the new geanyplugin.h it > isn't true anymore at all because you have only one include and so the > order is not important, haha. > > But assuming one doesn't use geanyplugin.h and instead includes various > headers, the order is important in that way that you: > - first include geany.h > - then include other core Geany header as well as Scintilla and > tagmanager headers if necessary > - finally include pluginmacros.h and geanyfunctions.h No, don't include pluginmacros.h, it's deprecated and may be removed soon. > Again, now, just include geanyfunction.h and we don't need to discuss > this further. I agree, that's its purpose, to avoid confusion about which headers and which order to include them in. Regards, Nick ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
