Re: [Geany-devel] More Per-Project Configuration Options
Am 10.07.2012 07:37, schrieb Matthew Brush: On 12-07-09 04:57 PM, Braden Walters wrote: Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this. Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a Reset to Global button to reset that individual item so it does not appear in that project's file). I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts). Hi, What about just adding new settings to the project config file without messing with the UI? Those who need them can RTM and see what settings are available, those who are content with what exists currently can go on happily ever after. You can add as many project preferences as you care to code and document this way. I hate needing to edit config files directly. This is not user friendly. If a user sets something in the project config file, it overrides the global config file when that project is open, end of story, no UI tricks needed to tell her this, it's just how it is (documented). The other way(s) discussed seem like they would Eclipse the UI's usability. I actually quite like how Eclipse handles this, it should be considered for Geany too: Each global settings tab (given it can be overridden by a project) has a line at the top saying that it can be overridden on a per-project basis. Then, for each project, each tab in the project preferences have a checkbox at the top that choose whether to inherit from global settings or override all settings in the tab. Unchecking the checkbox immediatly applies the global settings to the project. Checking the box prefills the settings with the values from the current global settings but can be changed obviously. Note that settings are grouped in tabs, so there is not one checkbox per setting, but per tab. This UI makes it easy to discover if stuff can be/is overriden by a project. It makes it easy to revert to global settings. It makes it possible without a massive amount new per-setting checkboxes to decide whether to override. PS: Eclipse's way to handle per-file settings is also quite OK IMO but I guess that's another topic. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On 09/07/2012 19:13, Dimitar Zhekov wrote: On Sun, 08 Jul 2012 13:04:54 +0100 Nick Treleavennick.trelea...@btinternet.com wrote: BTW I've run into 2 problems with the install target: 1. cp -r and xcopy treat the destination path differently. Currently MSYS install is broken and will install data files as $DESTDIR/data/data/* - I've replaced xcopy with separate copy targets locally. Unfortunately that causes errors with subdirectories so I had to ignore them, which I'd prefer not to do. See attached diff. cp: omitting directory 'foo' errors on any subdirectories with GNU cp. Wait... the _only_ 'cp' we have under Win~1 GNU cp, right? Instead of the patch, we can define CP_R as 'cp -r --remove-destination'. This non-POSIX option exists since at least fileutils-4.1 from 2001. Well, it'll remove $(DESTDIR)/data before copying, which I would prefer not to do, but there shoudn't be any user files anyway. No, the subdir errors are with windows 'copy'. It's not good to remove *all* destination files, it is valid to add files to the system config directory, understanding that they may get overwritten on upgrade /if/ a file with the same name is installed. This allows users to share some of the same config files. But this problem can be resolved either with separate copy commands as I attached previously, or maybe by having different install-data targets depending on whether MSYS is defined. 2. A weird problem. Installing from cmd.exe doesn't overwrite geany.glade (and maybe some other files) even though it appears to succeed. I only noticed this because I'm missing the View-Editor-Color Schemes menu which was added about a month ago (I tend to test in place rather than install each time). OMG... Then we must choose between copy and xcopy depending on which one works. Or we can define: Neither one works here ;-) But maybe it's something weird about my system or because I previously installed using MSYS cp. for cmd: 'CP_R = xcopy /s /y /i' and 'RM_R = del /s' xcopy /i doesn't seem to help here if the destination already exists (I don't think we should remove $DESTDIR). for MSYS: 'CP_R = cp -r' and 'RM_R = rm -r' and replace the '-$(MKDIR) $(DESTDIR)/data' with '-$(RM_R) $(DESTDIR)/data'. That will (a) nullify the differences between 'cp -r' and 'xcopy /s', (b) be a bit shorter than the individual MKDIR/CP commands from the patch, and (c) fix the overriding problem, since the target files will not exist - or maybe reveal something about the reason why it fails. Well, we haven't run out of options yet. I'll test the patch tomorrow. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] More Per-Project Configuration Options
On 07/10/2012 02:56 AM, Thomas Martitz wrote: Am 10.07.2012 07:37, schrieb Matthew Brush: On 12-07-09 04:57 PM, Braden Walters wrote: Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this. Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a Reset to Global button to reset that individual item so it does not appear in that project's file). I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts). Hi, What about just adding new settings to the project config file without messing with the UI? Those who need them can RTM and see what settings are available, those who are content with what exists currently can go on happily ever after. You can add as many project preferences as you care to code and document this way. I hate needing to edit config files directly. This is not user friendly. If a user sets something in the project config file, it overrides the global config file when that project is open, end of story, no UI tricks needed to tell her this, it's just how it is (documented). The other way(s) discussed seem like they would Eclipse the UI's usability. I actually quite like how Eclipse handles this, it should be considered for Geany too: Each global settings tab (given it can be overridden by a project) has a line at the top saying that it can be overridden on a per-project basis. Then, for each project, each tab in the project preferences have a checkbox at the top that choose whether to inherit from global settings or override all settings in the tab. Unchecking the checkbox immediatly applies the global settings to the project. Checking the box prefills the settings with the values from the current global settings but can be changed obviously. Note that settings are grouped in tabs, so there is not one checkbox per setting, but per tab. This UI makes it easy to discover if stuff can be/is overriden by a project. It makes it easy to revert to global settings. It makes it possible without a massive amount new per-setting checkboxes to decide whether to override. PS: Eclipse's way to handle per-file settings is also quite OK IMO but I guess that's another topic. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel That actually sounds like a good idea. Here's another idea I had last night. If there is no context menu for any item in the settings, that could be added for each item. If you change anything to where it'd be included in the project configuration and override the global settings, perhaps change the colour of the option's label or create some simple way of making this noticeable. Then, if the user wants to revert to the global settings, he/she could secondary click and select Restore to Global Settings. This would allow full customization (you don't have to do it on a per-tab basis) and it's not very intrusive into the UI. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] More Per-Project Configuration Options
On 12-07-09 11:56 PM, Thomas Martitz wrote: Am 10.07.2012 07:37, schrieb Matthew Brush: On 12-07-09 04:57 PM, Braden Walters wrote: Hi. I noticed a problem that affected me back in 0.2x that thankfully is (mostly) solved in 1.22. When I say mostly, I mean it fixes how the problem affects me right now, but possibly not for others, and I feel this may also affect me again eventually. The problem I noticed is that not all configuration options that may change from project-to-project are actually settings you can change on a per-project basis. The options that concern me the most are those that deal with the format of the saved file (line ending characters, new line at end of file (fixed in 1.22), tabs/spaces (not a problem), file encoding). I'm interested in the developers' opinions on this. Someone in IRC also mentioned that if many more options become configurable per-project, the global application options might be rendered useless (as project settings will override everything). Perhaps this could be solved by having a way to reset individual project options (perhaps a list of all things that have been changed, and a Reset to Global button to reset that individual item so it does not appear in that project's file). I'm curious what the core developers' opinion is on this. If it sounds good, I'd definitely be interested in helping make it possible (although I don't know the Geany code base, I could learn my way around relevant parts). Hi, What about just adding new settings to the project config file without messing with the UI? Those who need them can RTM and see what settings are available, those who are content with what exists currently can go on happily ever after. You can add as many project preferences as you care to code and document this way. I hate needing to edit config files directly. This is not user friendly. I never meant to imply it would be user friendly (ie. like something my Grandma could use), just that it would avoid messing with the UI until most of the coding is actually done. In the future some (or all) of the preferences could be moved to the GUI and we could discuss the colour of the bikeshed at that point once the code is actually working. Besides, it's not like it's unheard of for Geany (or even other editors like ST2) to make you edit config files. If a user sets something in the project config file, it overrides the global config file when that project is open, end of story, no UI tricks needed to tell her this, it's just how it is (documented). The other way(s) discussed seem like they would Eclipse the UI's usability. I actually quite like how Eclipse handles this, it should be considered for Geany too: Last time I tried it I got very confused and was overwhelmed with the sheer volume of user-interface elements I was seeing. It may be logical but it's not very simple, IMO. Each global settings tab (given it can be overridden by a project) has a line at the top saying that it can be overridden on a per-project basis. Then, for each project, each tab in the project preferences have a checkbox at the top that choose whether to inherit from global settings or override all settings in the tab. Unchecking the checkbox immediatly applies the global settings to the project. Checking the box prefills the settings with the values from the current global settings but can be changed obviously. Note that settings are grouped in tabs, so there is not one checkbox per setting, but per tab. This UI makes it easy to discover if stuff can be/is overriden by a project. It makes it easy to revert to global settings. It makes it possible without a massive amount new per-setting checkboxes to decide whether to override. PS: Eclipse's way to handle per-file settings is also quite OK IMO but I guess that's another topic. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Remove MSYS dependency of Geany on Win~1
On Tue, 10 Jul 2012 12:55:58 +0100 Nick Treleaven nick.trelea...@btinternet.com wrote: I've replaced xcopy with separate copy targets locally. Unfortunately that causes errors with subdirectories so I had to ignore them, which I'd prefer not to do. See attached diff. cp: omitting directory 'foo' errors on any subdirectories with GNU cp. [...] No, the subdir errors are with windows 'copy'. Strange. Under Linux: $ md /tmp/gx $ cp doc/* /tmp/gx $ cp doc/* ~/gx || echo some error cp: omitting directory `doc/images' some error But the patch ignores any copy errors anyway, so it woudn't matter. for cmd: 'CP_R = xcopy /s /y /i' and 'RM_R = del /s' xcopy /i doesn't seem to help here if the destination already exists (I don't think we should remove $DESTDIR). Yes, it works only for non-existing target directory. I tested the patch with cmd.exe and tcc.exe, install and re-install. All work fine, no copy error messages. On re-install, there are mkdir error messages about existing directories, geany.glade is replaced normally. That's with XP SP2 32-bit, MSYS was never installed. -- E-gards: Jimmy ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Usability fix - saving tab state
You can have any number of primary and secondary Geany instances open. With simply calling configuration save, on restart you'll get *some* file list... Wait, wait. That's a *competely* different problem. You *can't* allow users to have multiple instances of application which all write to one config file. If that list is from a secondary (-i) instance, it'll likely only contain a file or two, and you would be better with the list from the last normal Quit Well, it's a flaw - in the end, it's not much better or worse. How you can call Geany an IDE if it looses all the open files in all instances but the last closed one? Either it's a more like a code editor (i.e. Notepad++ - limited to one instance) or it's like a serious IDE (i.e. VS or Eclipse), which, AFAIK store the separate file list for each project. Anyway, I don't understand how anything can be a stopper to fixing an * obvious* usability flaw. If it worsens usability for some rare users, it would make sense to implement an option to turn it off. But I see no reasons, why majority should suffer. ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Usability fix - saving tab state
On 12-07-10 11:20 AM, Dimitar Zhekov wrote: On Tue, 10 Jul 2012 01:41:46 +0300 Axel apeka1...@gmail.com wrote: I believe there is a usability flaw in Geany - opened documents' list is saved only if you exit the editor in 'traditional' way (by clicking exit button or so). It's completely lost, if the process's killed. This was irritating for me, as I tend not to close every program when shutting down, but rather push the 'shutdown' button and get them all killed - and get the list of opened documents lost. There is a X11 session management patch on Geany sourceforge patch tracker. Applies against 1.22, but not the newest svn. Not guaranteed to work under GNOME, they always have problems with session support. Won't ask you to save any modified files under Xfce, xfsm is buggy too. So it only works in KDE and Unity? (and maybe TWM :) Shouldn't bugs be filed against these projects (if not done yet) if they don't support the standard X/Linux session management? AFAIK they all claim to try and support the various standards floating around out there. I have no clue about SM, but it seems crazy that it cannot be done. There must be apps out there that work properly cross-desktop, maybe we can copy them? P.S. When logging out/shutting down, what order does it handle Geany instances in? Does it always make sure the first opened instance is the last to get handled so that you don't clobber the open files list for it and stuff? Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Usability fix - saving tab state
On 12-07-10 11:20 AM, Dimitar Zhekov wrote: On Tue, 10 Jul 2012 01:41:46 +0300 Axel apeka1...@gmail.com wrote: I believe there is a usability flaw in Geany - opened documents' list is saved only if you exit the editor in 'traditional' way (by clicking exit button or so). It's completely lost, if the process's killed. This was irritating for me, as I tend not to close every program when shutting down, but rather push the 'shutdown' button and get them all killed - and get the list of opened documents lost. There is a X11 session management patch on Geany sourceforge patch tracker. Applies against 1.22, but not the newest svn. Not guaranteed to work under GNOME, they always have problems with session support. Won't ask you to save any modified files under Xfce, xfsm is buggy too. I pushed it to a sm branch[1] on the git repo just now. I haven't really tested it much but it builds and runs fine after a very trivial fix of the Makefile (and wscript) files. It might get more usage/testing/experimenting in a branch on the main repository compared to the sf.net tracker. Cheers, Matthew Brush [1] https://github.com/geany/geany/tree/sm ___ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
