I'm paranoid and I save files I'm working on a lot. Since I'm stuck with multiple platforms and programs I edit things with, I've settled on Alt-F to reach the file menu and S to save as having the broadest compatibility there.
This doesn't work well with Geany, because "Save" is grayed out if you haven't modified the file yet. So if you haven't made a change yet, that combination of keys leaves one stuck in the menu structure, likely to cause mayhem if you keep typing without noticing what happened. I find applications that change how the menus work in a modal way like this any more than absolutely necessary frustrating, and I'm not aware of any other GNOME applications that work this way.
There's multiple use cases this doesn't support too. I might want to save a file just to update its timestamp, or just to confirm that I have appropriate permissions to change it before I actually begin editing it.
Is there any way to change this behavior? What I normally expect from a programming oriented editor is a visual indication of changed/unchanged, but not for save to ever be disabled. I'm sure there are people that prefer the current behavior, so some sort of settings option ("Disable save if document unchaged") to toggle between the two would seem the ideal way to handle this.
-- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
Am 25.01.2009 00:28, schrieb Greg Smith:
This doesn't work well with Geany, because "Save" is grayed out if you haven't modified the file yet. So if you haven't made a change yet, that combination of keys leaves one stuck in the menu structure, likely to cause mayhem if you keep typing without noticing what happened. I find applications that change how the menus work in a modal way like this any more than absolutely necessary frustrating, and I'm not aware of any other GNOME applications that work this way.
And I'm not aware of any other GNOME application, where CTRL+S to save does not work. I'm not aware of ANY application where this doesn't work.
But yea, I'd like to have the possiblity to save an unmodified file sometimes too (may it just to update the timestamp, so that make recompiles it).
On Sun, 25 Jan 2009, Thomas Martitz wrote:
And I'm not aware of any other GNOME application, where CTRL+S to save does not work. I'm not aware of ANY application where this doesn't work.
I'm old enough to remember when CTRL+S was a forbidden character you went out of your way to avoid pressing because it stopped your serial terminal.
Regardless, I don't quite find it as comfortable (or universal) as using ALT combinations nowadays. ALT+F I can nail perfectly just sliding either thumb off the space bar, I find my error rate on CTRL combinations is a lot higher. CTRL combinations tend to only cover a subset of the stuff on the menus as well, where I can (usually!) get everything I want via the ALT menu interface. There's been some odd GNOME decisions in that area, too, like https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/290777 which forces me to build my own gnome-terminal to get sane behavior for Edit/Paste on Ibex.
-- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Sat, 24 Jan 2009 18:28:41 -0500 (EST), Greg Smith gsmith@gregsmith.com wrote:
I'm paranoid and I save files I'm working on a lot. Since I'm stuck with multiple platforms and programs I edit things with, I've settled on Alt-F to reach the file menu and S to save as having the broadest compatibility there.
This doesn't work well with Geany, because "Save" is grayed out if you haven't modified the file yet. So if you haven't made a change yet, that combination of keys leaves one stuck in the menu structure, likely to cause mayhem if you keep typing without noticing what happened. I find applications that change how the menus work in a modal way like this any more than absolutely necessary frustrating, and I'm not aware of any other GNOME applications that work this way.
Please note: Geany is NOT a Gnome application.
There's multiple use cases this doesn't support too. I might want to save a file just to update its timestamp, or just to confirm that I have appropriate permissions to change it before I actually begin editing it.
For those things I would do in a console: touch filename or ls -l filename
which is more informative and (for me) faster. But well, that's just me :).
Is there any way to change this behavior? What I normally expect from a programming oriented editor is a visual indication of changed/unchanged, but not for save to ever be disabled. I'm sure
Well, I never expected anyone wants a Save action available if there is no need to. To me, it would be just confusing if an editor would allow me to save a file which has no changes. The disabled Save actions and Save All actions are a neat way to indicate that there are no changes (this is especially true for Save All).
there are people that prefer the current behavior, so some sort of
Yes, me.
settings option ("Disable save if document unchaged") to toggle between the two would seem the ideal way to handle this.
Sigh. Yet another option. If we add something like this, I'd prefer it to be a hidden option as it will be probably unlikely that many people will use it.
Regards, Enrico
On Sun, 25 Jan 2009 17:18:45 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
settings option ("Disable save if document unchaged") to toggle between the two would seem the ideal way to handle this.
Sigh. Yet another option. If we add something like this, I'd prefer it to be a hidden option as it will be probably unlikely that many people will use it.
I think this behaviour can be implemented in plugin. Hook open/save and set changed flag for each document.
On Sun, 25 Jan 2009, Yura Siamashka wrote:
I think this behaviour can be implemented in plugin. Hook open/save and set changed flag for each document.
I just tried that:
static void on_document_open(GObject *obj, GeanyDocument *doc, gpointer user_data) { if (doc != NULL) doc->changed=TRUE; }
Two problems:
-When you go to close the document afterwards, it always says "The file 'X' is not saved" which isn't quite true. At least that confirms the above is being called, so I know my plug-in is working.
-Even though I've got that evidence the changed flag is being toggled, the menu structure doesn't seem to change. Save and Save All are still disabled.
I'm not sure if those two discoveries mean that a plug-in based solution can't work for what I want here, or if I just need to make a much better one.
P.S. If someone feels like improving the "Plugin Signals" section of the documentation with a trivial edit, it would have made things easier if the sample on_document_open code snippet there included this addition:
#include "document.h"
That's not already included in demoplugin.c, I had to add that in order to access the GeanyDocument structure. The compiler error you get in that situation is a bit cryptic.
-- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Tue, 27 Jan 2009 21:13:30 -0500 (EST), Greg Smith gsmith@gregsmith.com wrote:
On Sun, 25 Jan 2009, Yura Siamashka wrote:
I think this behaviour can be implemented in plugin. Hook open/save and set changed flag for each document.
I just tried that:
Be patient, I'm going to implement this in Geany.
static void on_document_open(GObject *obj, GeanyDocument *doc, gpointer user_data) { if (doc != NULL) doc->changed=TRUE; }
Two problems:
-When you go to close the document afterwards, it always says "The file 'X' is not saved" which isn't quite true. At least that confirms the above is being called, so I know my plug-in is working.
At this point you noticed that this way of changing it, is just a hack :).
-Even though I've got that evidence the changed flag is being toggled, the menu structure doesn't seem to change. Save and Save All are still disabled.
The menu and toolbar items won't change when changing the 'changed' flag but when document_set_text_changed() is called which itself sets the 'changed' flag.
I'm not sure if those two discoveries mean that a plug-in based solution can't work for what I want here, or if I just need to make a much better one.
At least not as clean as it will be in the core.
P.S. If someone feels like improving the "Plugin Signals" section of the documentation with a trivial edit, it would have made things easier if the sample on_document_open code snippet there included this addition:
#include "document.h"
That's not already included in demoplugin.c, I had to add that in order to access the GeanyDocument structure. The compiler error you
Thanks for the pointer, will fix this later.
Regards, Enrico
On Wed, 28 Jan 2009 17:01:40 +0100, Enrico Tröger enrico.troeger@uvena.de wrote:
On Tue, 27 Jan 2009 21:13:30 -0500 (EST), Greg Smith gsmith@gregsmith.com wrote:
On Sun, 25 Jan 2009, Yura Siamashka wrote:
I think this behaviour can be implemented in plugin. Hook open/save and set changed flag for each document.
I just tried that:
Be patient, I'm going to implement this in Geany.
Done in SVN. The pref is called "allow_always_save" and off by default. How to set hidden preferences is described in the manual http://geany.org/manual/0.15/#hidden-preferences (the new one is still missing in the docs but will be added later)
Regards, Enrico
Enrico Tröger wrote:
Done in SVN. The pref is called "allow_always_save" and off by default. How to set hidden preferences is described in the manual http://geany.org/manual/0.15/#hidden-preferences (the new one is still missing in the docs but will be added later)
Regards, Enrico
Nice, good job :)
On Wed, 28 Jan 2009, Enrico Tröger wrote:
The pref is called "allow_always_save" and off by default.
This part worked perfectly--exactly the behavior I was hoping for. Thanks for adding that feature so fast.
The below is all build/docs feedback.
Now that I get to do my first build from source...on a RHEL system, libtoolize is in another package from the rest of the auto* tools. Your autogen.sh doesn't recognize that possibility though, which means that if you don't have libtoolize|glibtoolize in your path then autogen.sh won't catch it, and instead will fail badly ("command not found" for the call to libtoolize but it keeps going). Here's a patch for autogen.sh that fixes that:
(libtoolize --version) < /dev/null > /dev/null 2>&1 || { (glibtoolize --version) < /dev/null > /dev/null 2>&1 || { echo echo "**Error**: You must have the GNU `libtoolize' installed." echo "You can get it from:" echo " http://www.gnu.org/software/libtool/" DIE=1 } }
Test to show that works in the case where it's missing:
[gsmith@pyramid geany]$ ./autogen.sh
**Error**: You must have the GNU `libtoolize' installed. You can get it from: http://www.gnu.org/software/libtool/
And once I installed the libtool package this check didn't get in the way. (Yes, I do have the sort of job where I have to provide regression tests showing code additions work for what they're supposed to and don't break the original behavior)
In case anybody else is curious how to get Geany to build from source on a RHEL5 that wasn't installed with all the GTK/X development tools, I had to install the following packages before autogen.sh would work:
sudo yum install automake autoconf intltool libtool libtool-ltdl gtk2-devel glib2-devel pango-devel cairo-devel freetype-devel fontconfig-devel libpng-devel xorg-x11-proto-devel libx11-devel libXau-devel libXdmcp-devel atk-devel
Yeah, that was really fun to figure out. I'll be bookmarking this message in the archives so I don't have to go through that again.
How to set hidden preferences is described in the manual http://geany.org/manual/0.15/#hidden-preferences (the new one is still missing in the docs but will be added later)
On said RHEL5 system the config file doesn't end up in ~/.geany/geany.conf as described there; it's actually in ~/.config/geany That alternate location may be worth mentioning in that part of the manual; I'm not familiar enough with this area to know why that is though.
-- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Wed, 28 Jan 2009 15:51:31 -0500 (EST), Greg Smith gsmith@gregsmith.com wrote:
On Wed, 28 Jan 2009, Enrico Tröger wrote:
The pref is called "allow_always_save" and off by default.
This part worked perfectly--exactly the behavior I was hoping for. Thanks for adding that feature so fast.
The below is all build/docs feedback.
Now that I get to do my first build from source...on a RHEL system, libtoolize is in another package from the rest of the auto* tools. Your autogen.sh doesn't recognize that possibility though, which means that if you don't have libtoolize|glibtoolize in your path then autogen.sh won't catch it, and instead will fail badly ("command not found" for the call to libtoolize but it keeps going). Here's a patch for autogen.sh that fixes that:
(libtoolize --version) < /dev/null > /dev/null 2>&1 || { (glibtoolize --version) < /dev/null > /dev/null 2>&1 || { echo echo "**Error**: You must have the GNU `libtoolize' installed." echo "You can get it from:" echo " http://www.gnu.org/software/libtool/" DIE=1 } }
Thanks, committed.
In case anybody else is curious how to get Geany to build from source on a RHEL5 that wasn't installed with all the GTK/X development tools, I had to install the following packages before autogen.sh would work:
sudo yum install automake autoconf intltool libtool libtool-ltdl gtk2-devel glib2-devel pango-devel cairo-devel freetype-devel fontconfig-devel libpng-devel xorg-x11-proto-devel libx11-devel libXau-devel libXdmcp-devel atk-devel
Never worked on a RHEL system, but I guess you don't need things like libpng-devel xorg-x11-proto-devel libx11-devel libXau-devel libXdmcp-devel atk-devel These dependencies should all b pulled in by gtk2-devel. On Debian systems and its derivates, there is a command: apt-get build-dep geany which installs all necessary dependencies to install the given package from source. Not sure whether there is something equivalent for RPM based systems. Plus, obviously, it assumes the package itself is already known to the package management. Anyway, as said, basically automake, autoconf, libtool and gtk2-devel should be enough. If not, I'd sa the package management is sub-optimal :).
How to set hidden preferences is described in the manual http://geany.org/manual/0.15/#hidden-preferences (the new one is still missing in the docs but will be added later)
On said RHEL5 system the config file doesn't end up in ~/.geany/geany.conf as described there; it's actually in ~/.config/geany That alternate location may be worth mentioning in that part of the manual; I'm not familiar enough with this area to know why that is though.
We changed the default configuration directory path some weeks ago. Until 0.15 it was ~/.geany/, so the docs and all are referring to this location. In current SVN, the new location is ~/.config/geany/ to match FDo standards, the docs in SVN and at http://geany.org/manual/dev/#hidden-preferences, already mention the new location. The change was also announced on the mailing list for SVN users (http://lists.uvena.de/pipermail/geany/2008-November/003757.html).
Regards, Enrico
On Thu, 29 Jan 2009, Enrico Tröger wrote:
Never worked on a RHEL system, but I guess you don't need things like libpng-devel xorg-x11-proto-devel libx11-devel libXau-devel libXdmcp-devel atk-devel These dependencies should all b pulled in by gtk2-devel.
Unfortunately they aren't. The order I listed those in is the order I installed them in, more or less, and everything but the first couple came in one at a time after autogen.sh complained. Once I got all the basic build tools installed and pulled in gtk2-devel, autogen.sh ran to the end, but the gtk checks failed. First it wanted pango, then cairo, and so on. I installed each of those then started autogen over to see what it wanted next.
It may be possible to optimize the list I gave a bit, but I'm quite sure installing gtk2-devel isn't nearly enough--Redhat really breaks that area down into small components. Take a look at https://www.centos.org/modules/newbb/viewtopic.php?forum=7&topic_id=7890 if you want a feel for bad it is in this area (it's *modular*, isn't that great!). Found that after an hour of not being able to figure out what provided xrender.pc nowadays in RHEL5.
Good news is that once I did all that, "make install" after building from source worked perfectly--menu item under "Applications/Programming" and everything. Next time I'm on a GUI RHEL4 system I'll figure out what the list you need there is too. Given that Geany is still under heavy modification, I think a doc page describing how to build from source under RHEL/Fedora would be a good addition for you. The instructions you provide worked perfectly for me on Ubuntu, it was really quite painful on RedHat, and I wouldn't expect a lot of people to go through what I did without giving up first.
-- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Thu, 29 Jan 2009 12:50:33 -0500 (EST), Greg Smith gsmith@gregsmith.com wrote:
On Thu, 29 Jan 2009, Enrico Tröger wrote:
Never worked on a RHEL system, but I guess you don't need things like libpng-devel xorg-x11-proto-devel libx11-devel libXau-devel libXdmcp-devel atk-devel These dependencies should all b pulled in by gtk2-devel.
Unfortunately they aren't. The order I listed those in is the order I installed them in, more or less, and everything but the first couple came in one at a time after autogen.sh complained. Once I got all the basic build tools installed and pulled in gtk2-devel, autogen.sh ran to the end, but the gtk checks failed. First it wanted pango, then cairo, and so on. I installed each of those then started autogen over to see what it wanted next.
It may be possible to optimize the list I gave a bit, but I'm quite sure installing gtk2-devel isn't nearly enough--Redhat really breaks that area down into small components. Take a look at
That is the same on other systems, on Debian we also have separate packages for gtk, glib, pango, cairo and then separate packages for their devel versions and for the docs. BUT the important thing is that these package depend on each other in a way that installing the biggest one, the top of the stack, in this case GTK, should automatically also install its dependencies. This works at least for Debian and Ubuntu systems. But well, this is all very unrelated to Geany itself :).
Good news is that once I did all that, "make install" after building from source worked perfectly--menu item under "Applications/Programming" and everything. Next time I'm on a GUI RHEL4 system I'll figure out what the list you need there is too. Given that Geany is still under heavy modification, I think a doc page describing how to build from source under RHEL/Fedora would be a good
Hmm, first of all, I guess it would be the best if you would write those as *you* just had the pain of finding them out plus at least me is not a RHEL/Fedora user.
addition for you. The instructions you provide worked perfectly for
which instructions exactly?
Regards, Enrico
On Wed, 28 Jan 2009 15:51:31 -0500 (EST) Greg Smith gsmith@gregsmith.com wrote:
sudo yum install automake autoconf intltool libtool libtool-ltdl gtk2-devel glib2-devel pango-devel cairo-devel freetype-devel fontconfig-devel libpng-devel xorg-x11-proto-devel libx11-devel libXau-devel libXdmcp-devel atk-devel
Yeah, that was really fun to figure out. I'll be bookmarking this message in the archives so I don't have to go through that again.
Probably very similar (or the same) as the Fedora build dependencies. Most of the later ones should be brought in by yum dependencies e.g. on gtk2-devel anyway.
You can probably get all of them by telling a package installer GUI to install all default development packages (but you may get more than you need).
P.S. Sorry if I'm just saying stuff you know already ;-)
Regards, Nick
On Mon, 2 Feb 2009 12:46:56 +0000 Nick Treleaven nick.treleaven@btinternet.com wrote:
sudo yum install automake autoconf intltool libtool libtool-ltdl gtk2-devel glib2-devel pango-devel cairo-devel freetype-devel fontconfig-devel libpng-devel xorg-x11-proto-devel libx11-devel libXau-devel libXdmcp-devel atk-devel
Yeah, that was really fun to figure out. I'll be bookmarking this message in the archives so I don't have to go through that again.
Probably very similar (or the same) as the Fedora build dependencies. Most of the later ones should be brought in by yum dependencies e.g. on gtk2-devel anyway.
I hadn't read Enrico's response, oops.
Personally I consider it a bug if gtk2-devel doesn't bring in all it's required dependencies, it does on Fedora.
Regards, Nick
On Mon, 2 Feb 2009, Nick Treleaven wrote:
Personally I consider it a bug if gtk2-devel doesn't bring in all it's required dependencies, it does on Fedora.
There is something odd going on here I'll dig into.
rpm -q --requires gtk2-devel
Shows cairo-devel and pango-devel as requirements, and cairo-devel requires freetype-devel and libXrender-devel. That suggests most of the stuff I had to instally manually should have been pulled in just with "yum install gtk2-devel"; not sure why that didn't happen. If I can replicate it on another system I'll get some more information (I was focused just on getting Geany to work that day), otherwise I'll pass along a more slimmed down set of suggested packages.
-- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Sun, 25 Jan 2009, Enrico Tröger wrote:
On Sat, 24 Jan 2009 18:28:41 -0500 (EST), Greg Smith gsmith@gregsmith.com wrote:
There's multiple use cases this doesn't support too. I might want to save a file just to update its timestamp, or just to confirm that I have appropriate permissions to change it before I actually begin editing it.
For those things I would do in a console: touch filename or ls -l filename
There are several situations where the information given by "ls -l" is not actually sufficient to tell you whether you can edit a file. Examples include SELinux and Posix ACL environmentions. Network mounts can be difficult here too if the permissions mapping is done badly or is complicated.
Stepping aside from that, anytime a solution to an editing problem involves dropping to the command line, that suggests to me that there's something that could be improved in the editor.
If we add something like this, I'd prefer it to be a hidden option as it will be probably unlikely that many people will use it.
Within a few minutes of me sending my message, Thomas noted that this would be handy to him as well to update the timestamp so make will run again. That's one of the examples I was thinking of too. I know you would just run touch on the file. While I respect that and that this feature would be considered valuable by some, I think you'd be surprised by how many people would prefer this application to just work the same as most others here. UI consistency across applications is a virtue, and if something that improves that is available I can't imagine why you'd consider hiding it.
-- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
On Sun, 25 Jan 2009 14:00:37 -0500 (EST), Greg Smith gsmith@gregsmith.com wrote:
On Sun, 25 Jan 2009, Enrico Tröger wrote:
On Sat, 24 Jan 2009 18:28:41 -0500 (EST), Greg Smith gsmith@gregsmith.com wrote:
There's multiple use cases this doesn't support too. I might want to save a file just to update its timestamp, or just to confirm that I have appropriate permissions to change it before I actually begin editing it.
For those things I would do in a console: touch filename or ls -l filename
There are several situations where the information given by "ls -l" is not actually sufficient to tell you whether you can edit a file. Examples include SELinux and Posix ACL environmentions. Network mounts can be difficult here too if the permissions mapping is done badly or is complicated.
Stepping aside from that, anytime a solution to an editing problem involves dropping to the command line, that suggests to me that there's something that could be improved in the editor.
Sure, however for me this is as simple as pressing F4 to jump to the embedded terminal. But of course, this was not meant as 'the solution you should use', just as my work flow looks like.
If we add something like this, I'd prefer it to be a hidden option as it will be probably unlikely that many people will use it.
Within a few minutes of me sending my message, Thomas noted that this would be handy to him as well to update the timestamp so make will run again. That's one of the examples I was thinking of too. I know you would just run touch on the file. While I respect that and that this feature would be considered valuable by some, I think you'd be surprised by how many people would prefer this application to just work the same as most others here. UI consistency across applications
This is an argument for both of us. I'm used to see the Save toolbar button (or menu item or whatever) disabled when the document is unchanged. Saying which of the different behaviours is the default hardly depends on the applications you compare.
is a virtue, and if something that improves that is available I can't imagine why you'd consider hiding it.
I just don't want to clutter the prefs dialog with such an option which is maybe unimportant for most users. What about changing the default behaviour to what you want and add a hidden pref for people like me? Though I personally would still feel this as a regression (i.e. removing existing features) but I also realise that people think different than me :).
Just not sure. Nick, any opinion on this?
Regards, Enrico
I just don't want to clutter the prefs dialog with such an option which is maybe unimportant for most users. What about changing the default behaviour to what you want and add a hidden pref for people like me? Though I personally would still feel this as a regression (i.e. removing existing features) but I also realise that people think different than me :).
My two cents, I agree with Enrico, I like to be able to look up at the toolbar and see that everything is saved before I leave my desk or attend to other interruptions so I'd prefer the current behavior to be the default.
Whilst I understand the use of saving to update timestamps etc I think that indicating saved data is a more common and important function that I wouldn't want taken away,
There does not seem to be a consistent GUI solution as an alternative to making the save inactive.
But some indication on the file tab seems to be used by several applications and is reasonably useful if the indication is visible enough. Applications don't agree on how to indicate saving is needed but some options are by colour change, adding one or two * or adding or changing an icon in the tab. One of these should be used if the save actions are permanently available, what do people think?
Cheers Lex
On Tue, 27 Jan 2009 22:52:35 +1100, Lex Trotman elextr@gmail.com wrote:
I just don't want to clutter the prefs dialog with such an option which is maybe unimportant for most users. What about changing the default behaviour to what you want and add a hidden pref for people like me? Though I personally would still feel this as a regression (i.e. removing existing features) but I also realise that people think different than me :).
My two cents, I agree with Enrico, I like to be able to look up at the toolbar and see that everything is saved before I leave my desk or attend to other interruptions so I'd prefer the current behavior to be the default.
Whilst I understand the use of saving to update timestamps etc I think that indicating saved data is a more common and important function that I wouldn't want taken away,
There does not seem to be a consistent GUI solution as an alternative to making the save inactive.
But some indication on the file tab seems to be used by several applications and is reasonably useful if the indication is visible enough. Applications don't agree on how to indicate saving is needed but some options are by colour change, adding one or two * or adding or changing an icon in the tab. One of these should be used if the save actions are permanently available, what do people think?
We already have red-coloured tabs for changed files, red-coloured filenames in the document list in the sidebar, we put a "MOD" flag in the statusbar and finally we prepend the window title with an asterisk. So, we already have all that visual indicators.
(Admittedly, the MOD flag in the statusbar is no real indication, at least it's very easy to miss :D)
Regards, Enrico
2009/1/28 Enrico Tröger enrico.troeger@uvena.de
On Tue, 27 Jan 2009 22:52:35 +1100, Lex Trotman elextr@gmail.com wrote:
I just don't want to clutter the prefs dialog with such an option which is maybe unimportant for most users. What about changing the default behaviour to what you want and add a hidden pref for people like me? Though I personally would still feel this as a regression (i.e. removing existing features) but I also realise that people think different than me :).
My two cents, I agree with Enrico, I like to be able to look up at the toolbar and see that everything is saved before I leave my desk or attend to other interruptions so I'd prefer the current behavior to be the default.
Whilst I understand the use of saving to update timestamps etc I think that indicating saved data is a more common and important function that I wouldn't want taken away,
There does not seem to be a consistent GUI solution as an alternative to making the save inactive.
But some indication on the file tab seems to be used by several applications and is reasonably useful if the indication is visible enough. Applications don't agree on how to indicate saving is needed but some options are by colour change, adding one or two * or adding or changing an icon in the tab. One of these should be used if the save actions are permanently available, what do people think?
We already have red-coloured tabs for changed files, red-coloured filenames in the document list in the sidebar, we put a "MOD" flag in the statusbar and finally we prepend the window title with an asterisk. So, we already have all that visual indicators.
(Admittedly, the MOD flag in the statusbar is no real indication, at least it's very easy to miss :D)
Yeah I missed it, in fact I've now discovered that there is lots of
information down there, wow ;-) but its only for the current file anyway, On my Geany the tab doesn't go red only the text, and this isn't very clear, dark red (actually any dark colour) looks very similar to black if monitor brightness is low.
I still vote for keeping the status quo as default.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany mailing list Geany@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany
On Wed, 28 Jan 2009 14:24:12 +1100, Lex Trotman elextr@gmail.com wrote:
2009/1/28 Enrico Tröger enrico.troeger@uvena.de
On Tue, 27 Jan 2009 22:52:35 +1100, Lex Trotman elextr@gmail.com wrote:
I just don't want to clutter the prefs dialog with such an option which is maybe unimportant for most users. What about changing the default behaviour to what you want and add a hidden pref for people like me? Though I personally would still feel this as a regression (i.e. removing existing features) but I also realise that people think different than me :).
My two cents, I agree with Enrico, I like to be able to look up at the toolbar and see that everything is saved before I leave my desk or attend to other interruptions so I'd prefer the current behavior to be the default.
Whilst I understand the use of saving to update timestamps etc I think that indicating saved data is a more common and important function that I wouldn't want taken away,
There does not seem to be a consistent GUI solution as an alternative to making the save inactive.
But some indication on the file tab seems to be used by several applications and is reasonably useful if the indication is visible enough. Applications don't agree on how to indicate saving is needed but some options are by colour change, adding one or two * or adding or changing an icon in the tab. One of these should be used if the save actions are permanently available, what do people think?
We already have red-coloured tabs for changed files, red-coloured filenames in the document list in the sidebar, we put a "MOD" flag in the statusbar and finally we prepend the window title with an asterisk. So, we already have all that visual indicators.
(Admittedly, the MOD flag in the statusbar is no real indication, at least it's very easy to miss :D)
Yeah I missed it, in fact I've now discovered that there is lots of
information down there, wow ;-) but its only for the current file anyway, On my Geany the tab doesn't go red only the text, and this isn't very clear, dark red (actually any dark colour) looks very similar to black if monitor brightness is low.
Sorry, I wasn't clear enough: the tab label text colour goes red, not the tab itself. Though I don't think we should change this except for maybe making the red colour value configurable.
I still vote for keeping the status quo as default.
Yup, it will stay as it is, plus a hidden option for those who want to change it from the current behaviour.
Regards, Enrico
On Mon, 26 Jan 2009 19:33:48 +0100 Enrico Tröger enrico.troeger@uvena.de wrote:
I just don't want to clutter the prefs dialog with such an option which is maybe unimportant for most users. What about changing the default behaviour to what you want and add a hidden pref for people like me? Though I personally would still feel this as a regression (i.e. removing existing features) but I also realise that people think different than me :).
Just not sure. Nick, any opinion on this?
I think the existing way is fine by default, but maybe a pref would be useful for users that like to update timestamps (seeing as other editors allow that).
(I won't work on it though.)
Regards, Nick