Re: [Geany-Devel] Document Message/File Monitoring Behaviour (was Re: Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465)
On 12-11-30 09:10 PM, Matthew Brush wrote: Hi again, Attached is a mockup of roughly what I was thinking made in 5 minutes on some website, except I couldn't figure out how to make a warning icon for the infobar and tab label. I also made a mockup for "deleted/moved on disk" infobar. I'll put a link to avoid spamming the list: 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 Cheers, Matthew Brush ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Document Message/File Monitoring Behaviour (was Re: Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465)
On 1 December 2012 16:10, Matthew Brush wrote: > Hi again, > > Attached is a mockup of roughly what I was thinking made in 5 minutes on > some website, except I couldn't figure out how to make a warning icon for > the infobar and tab label. > Yes thats the sort of thing. > I agree with Lex that a warning icon in the tab (next to filename label or > perhaps even replacing the close icon) would be useful to help avoid > clobbering files changed on disk when meaning to save files edited "live" > with "Save All". The thing I realised is that with tabs on top and many files open, some are going to be hidden, so an indication only on the tab may not be visible. That was the idea for the "master warning" indication that shows somewhere always visible if any tab has an undismissed infobar. This is unashamedly stolen from the way aircraft systems work :) Also we could set a flag on the document(s) so that when > you click "Save All", it warns you that you're clobbering file changed on > disk that have non-dismissed messages pending or just focus next > non-dismissed tab. This is all getting complicated, but possibly this is an acceptable solution. Cheers Lex PS Minor niggle with the concept drawing, if we have 4 buttons then they maybe should be in two columns so the infobar isn't so big vertically. > > Cheers, > Matthew Brush > > > > On 12-11-30 06:55 PM, Matthew Brush wrote: >> >> On 12-11-30 02:20 PM, Thomas Martitz wrote: >>> >>> Am 28.11.2012 16:42, schrieb Matthew Brush: On 12-11-28 05:39 AM, Nick Treleaven wrote: > > On 27/11/2012 18:13, Matthew Brush wrote: >> >> On 12-11-27 09:54 AM, Nick Treleaven wrote: >>> >>> On 27/11/2012 17:48, Matthew Brush wrote: We could just drop the Close button altogether since you can already close the document by using the close button in the notebook tab, the close button in the toolbar, the close button in the main menu or by using Ctrl+W (or whatever) accelerator. Unlike the "missing on disk" >>> >>> >>> That takes quite a bit longer when you have several files to reload >>> and >>> you want to close most of them. This situation actually happens often >>> for me, I think pretty much as often as I want to reload documents. >>> >> >> What is your use case for when you want to close a file after it has >> been externally modified on disk? I understand the case for >> "externally >> deleted/moved" just not for "externally changed". > > > 1. switching git branches - different branches need different files > open > in Geany. After switching I often want to close the unnecessary ones. > > 2. sometimes I have the same file open in two instances of Geany - > sometimes I reuse my 1st instance to open an unrelated file for a quick > edit and realize I actually need other files open too, so I start a new > instance. On switching back to the 1st Geany detects the change, but I > don't want it open any more. > > The first item above is the most important. I'm not sure if there are > other cases too, but I definitely use Close quite a lot. BTW I'm > open to > removing it if it actually causes a problem, but a mnemonic clash has > other solutions to try first. > So really it sounds like it's not that it's a needed feature, it's a needed feature because another feature - file monitor notification - is annoying already :) I just couldn't wrap my head around the association between file-on-disk change detection and wanting to close files, but it sounds from your description and Lex's on IRC, that it's almost entirely because of the misfeature of file change detection and when it occurs (tab switching) and that it has already stopped you in your tracks from what you were originally doing and is going to keep doing so as long as the next tab that it switches to after closing is also changed and keeps the blocking dialogs coming. >>> >>> >>> I wonder why you call it a misfeature. While it's disruptive in some >>> situations, it's generally enormously useful to me. >> >> >> "misfeature" is the wrong word, "missed feature" works better and sounds >> similar :) >> >> By "misfeature", I was referring to the fact that the current "file >> monitoring"[1] is tied to document tab navigation to check if the file >> has changed, and this in conjunction with the modal dialogs offers this >> sometimes useful workflow of "ok since you annoyed me anyway, let me >> quickly deal with something now for all documents so you'll stop >> annoying me in the near future", where it switches to the next tab >> because the document to the left was closed and a changed/deleted one >> might be next to get focus, and continues that cycle of maybe nagging, >> closing, switching, maybe nagging, closing, switching, maybe nagging >> later when you s
Re: [Geany-Devel] Document Message/File Monitoring Behaviour (was Re: Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465)
[...] > The reason I was asking in the first place is because I want to eventually > get the document-messages branch into master but I want to make sure it I agree that the infobar is a better way of indicating the file changed and other conditions that the user needs to know, but doesn't need to handle immediately. > doesn't break this workflow (and hopefully improves it). IMO, this > dependency between change detection and modal warnings on tab page change > could be replaced/enhanced by specific actions accessible in the GUI and > with keybindings like "Close All Files Changed on Disk Without Prompting" > and "Save All Files not Externally Modified Without Prompting" (of course my > names suck). This would allow using "real-time" file monitoring and > passively warn the user right away using the document-messages infobar as > well as a different tab label color and maybe even a warning icon next to > the label in the tab. > > Comments and suggestions are welcome, especially how to to lay out the > interface for the infobar, the wording of the message, which actions/buttons > it should have, and any other useful (inter)actions I might be missing, etc. As I said on IRC, the current document-messages branch sets the buffer changed status if it detects the file changed. This occurs asynchronously in the background and this means that if I hit save-all I will save the buffer over the changed file with no warning. The current behaviour where the buffer is not marked changed is safer. As we also discussed, a way of indicating that there are notifications pending on tabs would be very useful, for example a bright orange ! icon added to the tab like gedit does. And maybe a "master caution" for when some of the tabs are off the screen. Finally as also discussed, the file-changed notification bar needs a close button to maintain the current workflow. Personally I don't think the global commands are going to be very useful, there is always one file where I want to do something different from the global (guaranteed by Murphy :), and finding that out after you have saved over or closed it is too late. Being forced to step through means you at least give a nano-thought for each one. Cheers Lex > > Cheers, > Matthew Brush > > [1] As opposed to the GIO file monitoring code that is currently #ifdef'd > out but works pretty good with document-messages branch > ___ > Devel mailing list > Devel@lists.geany.org > https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Document Message/File Monitoring Behaviour (was Re: Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465)
On 12-11-30 02:20 PM, Thomas Martitz wrote: Am 28.11.2012 16:42, schrieb Matthew Brush: On 12-11-28 05:39 AM, Nick Treleaven wrote: On 27/11/2012 18:13, Matthew Brush wrote: On 12-11-27 09:54 AM, Nick Treleaven wrote: On 27/11/2012 17:48, Matthew Brush wrote: We could just drop the Close button altogether since you can already close the document by using the close button in the notebook tab, the close button in the toolbar, the close button in the main menu or by using Ctrl+W (or whatever) accelerator. Unlike the "missing on disk" That takes quite a bit longer when you have several files to reload and you want to close most of them. This situation actually happens often for me, I think pretty much as often as I want to reload documents. What is your use case for when you want to close a file after it has been externally modified on disk? I understand the case for "externally deleted/moved" just not for "externally changed". 1. switching git branches - different branches need different files open in Geany. After switching I often want to close the unnecessary ones. 2. sometimes I have the same file open in two instances of Geany - sometimes I reuse my 1st instance to open an unrelated file for a quick edit and realize I actually need other files open too, so I start a new instance. On switching back to the 1st Geany detects the change, but I don't want it open any more. The first item above is the most important. I'm not sure if there are other cases too, but I definitely use Close quite a lot. BTW I'm open to removing it if it actually causes a problem, but a mnemonic clash has other solutions to try first. So really it sounds like it's not that it's a needed feature, it's a needed feature because another feature - file monitor notification - is annoying already :) I just couldn't wrap my head around the association between file-on-disk change detection and wanting to close files, but it sounds from your description and Lex's on IRC, that it's almost entirely because of the misfeature of file change detection and when it occurs (tab switching) and that it has already stopped you in your tracks from what you were originally doing and is going to keep doing so as long as the next tab that it switches to after closing is also changed and keeps the blocking dialogs coming. I wonder why you call it a misfeature. While it's disruptive in some situations, it's generally enormously useful to me. "misfeature" is the wrong word, "missed feature" works better and sounds similar :) By "misfeature", I was referring to the fact that the current "file monitoring"[1] is tied to document tab navigation to check if the file has changed, and this in conjunction with the modal dialogs offers this sometimes useful workflow of "ok since you annoyed me anyway, let me quickly deal with something now for all documents so you'll stop annoying me in the near future", where it switches to the next tab because the document to the left was closed and a changed/deleted one might be next to get focus, and continues that cycle of maybe nagging, closing, switching, maybe nagging, closing, switching, maybe nagging later when you switch to another tab in 10 minutes, ... The reason I was asking in the first place is because I want to eventually get the document-messages branch into master but I want to make sure it doesn't break this workflow (and hopefully improves it). IMO, this dependency between change detection and modal warnings on tab page change could be replaced/enhanced by specific actions accessible in the GUI and with keybindings like "Close All Files Changed on Disk Without Prompting" and "Save All Files not Externally Modified Without Prompting" (of course my names suck). This would allow using "real-time" file monitoring and passively warn the user right away using the document-messages infobar as well as a different tab label color and maybe even a warning icon next to the label in the tab. Comments and suggestions are welcome, especially how to to lay out the interface for the infobar, the wording of the message, which actions/buttons it should have, and any other useful (inter)actions I might be missing, etc. Cheers, Matthew Brush [1] As opposed to the GIO file monitoring code that is currently #ifdef'd out but works pretty good with document-messages branch ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465
Am 28.11.2012 16:42, schrieb Matthew Brush: On 12-11-28 05:39 AM, Nick Treleaven wrote: On 27/11/2012 18:13, Matthew Brush wrote: On 12-11-27 09:54 AM, Nick Treleaven wrote: On 27/11/2012 17:48, Matthew Brush wrote: We could just drop the Close button altogether since you can already close the document by using the close button in the notebook tab, the close button in the toolbar, the close button in the main menu or by using Ctrl+W (or whatever) accelerator. Unlike the "missing on disk" That takes quite a bit longer when you have several files to reload and you want to close most of them. This situation actually happens often for me, I think pretty much as often as I want to reload documents. What is your use case for when you want to close a file after it has been externally modified on disk? I understand the case for "externally deleted/moved" just not for "externally changed". 1. switching git branches - different branches need different files open in Geany. After switching I often want to close the unnecessary ones. 2. sometimes I have the same file open in two instances of Geany - sometimes I reuse my 1st instance to open an unrelated file for a quick edit and realize I actually need other files open too, so I start a new instance. On switching back to the 1st Geany detects the change, but I don't want it open any more. The first item above is the most important. I'm not sure if there are other cases too, but I definitely use Close quite a lot. BTW I'm open to removing it if it actually causes a problem, but a mnemonic clash has other solutions to try first. So really it sounds like it's not that it's a needed feature, it's a needed feature because another feature - file monitor notification - is annoying already :) I just couldn't wrap my head around the association between file-on-disk change detection and wanting to close files, but it sounds from your description and Lex's on IRC, that it's almost entirely because of the misfeature of file change detection and when it occurs (tab switching) and that it has already stopped you in your tracks from what you were originally doing and is going to keep doing so as long as the next tab that it switches to after closing is also changed and keeps the blocking dialogs coming. I wonder why you call it a misfeature. While it's disruptive in some situations, it's generally enormously useful to me. Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Bug: Conflicting Keyboard shortcut in "reload file" dialog - ID: 3587465
Am 28.11.2012 03:10, schrieb Matthew Brush: On 12-11-27 02:20 PM, Lex Trotman wrote: @Matthew, "oh, I still have that generated file open, oops" I was asking for Nick's real-life use case for this, as opposed your hypothetical ones :) Not that it's any of my business, I was just curious where this specifically comes in handy for him, maybe I'm missing something convenient I could be doing. It's not a hypothetical use case, but a very real one. I encounter this every day in my job. Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Search bar
On 11/29/2012 06:53 PM, Lex Trotman wrote: On 30 November 2012 05:19, Steven Blatnick wrote: I noticed if I do a search from the toolbar and press return, it finds the word, but focus remains in the search bar. Isn't there a way to have it automatically set the focus to the text and then I can use keyboard shortcuts to go from the current instance to the next/prev. I think this would be more intuitive: 1. Keyboard shortcut to the search toolbar. "Switch to searchbar", just add your favourite keybinding, I actually re-defined f to do this not the dialog. I did the same thing :-) 2. Type a word. 3. Press enter and get taken to the first word with the focus on it. The toolbar search searches as you type, so it will highlight the first match after the current cursor position, you don't need to press enter, and in fact enter moves to the next match. You do need to switch focus the first time if you are going to do some editing at the match point. 4. Use other shortcuts to go from next/previous The normal next/previous shortcuts apply, and remain in the editor window, so the focus switch is first fime only. 5. Use the keyboard shortcut again to return to the toolbar to change the search term. See 1. above I did things this way all the time before. In geany, it looks like I have to use another shortcut in between? Well, you want to press enter to get from the searchbar to the edit window, just use the switch focus instead, as I said the search happens as you type, so you are already at the right position. [...] What do you guys think? No change needed to give the equivalent of your workflow, except that the keybinding to switch to the editor isn't enter. Good point. I didn't think of it that way. Personally, I think it still seems a little wonky that it doesn't focus when you hit enter. Cheers Lex Thanks, Steve ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
[Geany-Devel] Support for Abaqus files (inp)
Hello, This is a submission of a patch to support Abaqus files (inp files). A lexer file already existed so I included the support, together with a filetypes.abaqus for the keywords and a TagManager parser for the three main sections (Parts, Assembly and Steps). This patch has been tested and confirmed working on the master branch now. Regards, Baptiste 0001-Add-support-for-Abaqus.patch Description: Binary data ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Proposal from the Mint distro
Joining in a bit late.. To start with, I think that a 'geany --light' and accompanying *.desktop entries would be an excellent and low-cost addition to Geany. On Thu, Nov 8, 2012 at 5:36 AM, Matthew Brush wrote: >> I have no problems with it and I'd be willing to help out with >> implementing the "simplified mode" since it's something I've been thinking >> about before. > If you ever go ahead to tackle this, would the resulting light mode effectively remove the need for a new release of Mousepad? I remember that you did some work on it, but that you didn't get up to a release. > I'd mark it as a "Pending" feature request with NEEDINFO status :) > I think that best in this case would be to come up with a minimal-effort config-only changes to simplify Geany UI. You could use as a baseline the Leafpad/Mousepad/Gedit2 features, and then release the result in the wild. Then I expect that it will be rather straightforward, with input from Geany devels, users and Mint devels, to come up with some sort of consensus of what should be kept/added. But unless someone makes this initial effort, the idea---however good---will likely rot on the list. Cheers Liviu ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
