Hi All,
Attached is a patch providing some cleanups for geany.txt.
NOTE: There are a few TODOs in the file that need to be checked before the geany.html is re-created (Addons plugin compatible :-). These are things that I didn't know the answers to.
I have minimised the reflows I applied, so that the patch didn't become too big, Some more wouldn't hurt but they are not critical.
There are images called out in geany.txt that are missing from the doc/images directory. I have not created those because I can't seem to get a theme that looks like the other images, so someone who can generate screen captures that match the existing ones should do it.
Cheers Lex
On Wed, 23 Sep 2009 12:18:53 +1000, Lex wrote:
Heyho,
Attached is a patch providing some cleanups for geany.txt.
wow. Amazing work.
NOTE: There are a few TODOs in the file that need to be checked before the geany.html is re-created (Addons plugin compatible :-). These are things that I didn't know the answers to.
"Addons plugin compatible"? What do you mean?
There are images called out in geany.txt that are missing from the doc/images directory. I have not created those because I can't seem to get a theme that looks like the other images, so someone who can generate screen captures that match the existing ones should do it.
The only image reference I found was: "TODO add picture of the overall Geany window with all parts visible"
I'll add this image soon. Maybe there are more images for the prefs dialog missing or outdated. Usually, I update the images in SVN shortly before releases because I'm too lazy to update them for every change in the GUI :).
A few remarks/questions I got while reading the patch however the patch is just great!
The Autotools based build system is very mature and has been well tested. -To use it, you just need the Make tool, preferably GNU Make. +To use it, you just need a Unix environment (TODO Mingw on Windows??) and the Make tool, +preferably GNU Make.
Hmm, I think "Unix environment" might sound a bit too heavy. When compiling a release, a somewhat POSIX compatible shell, make and the compilers should be enough (well, not really but this is why we have ./configure to check for what is missing). What I mean is just that Unix environment sounds to me like "You have to install a big new system to get it working". Maybe it's just me, still I'd like to keep the original here. Opinions?
+The position of the tabs can be selected in the interface preferences.
To me, this sounds like the ordering of the tabs (Symbols, Documents vs. Documents, Symbols) can be changed in the interface preferences. However, I don't know a better way off-hand.
+Tags are information that relates symbols in a program with the +source file location of the declaration and definition.
Great idea to first define what we mean when talking about "tags". Yeah.
Plugin documentation
+TODO Is this documentation right?? Doesn't seem to match 0.18 default +plugins.
Shame on me. Some time ago, there were three plugins which provided file saving-related functionality. At some point we merged them into the SaveActions plugin but obviously I forgot to update the documentation. Will do, soon.
I'm fine with anything else and am really impressed and happy about your efforts, Lex. Great job, thank you very much.
Regards, Enrico
2009/9/26 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 23 Sep 2009 12:18:53 +1000, Lex wrote:
Heyho,
Attached is a patch providing some cleanups for geany.txt.
wow. Amazing work.
NOTE: There are a few TODOs in the file that need to be checked before the geany.html is re-created (Addons plugin compatible :-). These are things that I didn't know the answers to.
"Addons plugin compatible"? What do you mean?
Ahhh, I just meant that they show up in the tasks window if your addons plugin has it enabled. I can't do without it, my programs in development are littered with TODOs :-)
There are images called out in geany.txt that are missing from the doc/images directory. I have not created those because I can't seem to get a theme that looks like the other images, so someone who can generate screen captures that match the existing ones should do it.
The only image reference I found was: "TODO add picture of the overall Geany window with all parts visible"
I labelled that one because its a new one without a ..image entry, but some of the files named in existing image entries don't seem to be there either.
I'll add this image soon. Maybe there are more images for the prefs dialog missing or outdated. Usually, I update the images in SVN shortly before releases because I'm too lazy to update them for every change in the GUI :).
Not lazy, perfectly good just-in-time management. (thats what I'd claim anyway) :-)
A few remarks/questions I got while reading the patch however the patch is just great!
The Autotools based build system is very mature and has been well tested. -To use it, you just need the Make tool, preferably GNU Make. +To use it, you just need a Unix environment (TODO Mingw on Windows??) and the Make tool, +preferably GNU Make.
Hmm, I think "Unix environment" might sound a bit too heavy. When compiling a release, a somewhat POSIX compatible shell, make and the
Yes, a POSIX shell that is a better way of saying it than Unix environment, but maybe some other tools too?. The TODO was trying to ask the recommended way for Windows users to get the shell and anything else they need. Oh and grep for find in files etc...
compilers should be enough (well, not really but this is why we have ./configure to check for what is missing). What I mean is just that Unix environment sounds to me like "You have to install a big new system to get it working". Maybe it's just me, still I'd like to keep the original here.
Nah, I didn't mean that, certainly a shell, but from recent mail discussions it seems that some other minor programs are used by the scripts. All I think is needed is to say where the windows user gets them from, they should be naturally available on *ix. It would be preferable if everything is available in one go, thats why I queried about Mingw, or cygwin or similar??
Opinions?
+The position of the tabs can be selected in the interface preferences.
To me, this sounds like the ordering of the tabs (Symbols, Documents vs. Documents, Symbols) can be changed in the interface preferences. However, I don't know a better way off-hand.
All I'm trying to say is, you can choose which edge of the window the tabs appear on. Should have been clearer.
+Tags are information that relates symbols in a program with the +source file location of the declaration and definition.
Great idea to first define what we mean when talking about "tags". Yeah.
Plugin documentation ====================
+TODO Is this documentation right?? Doesn't seem to match 0.18 default +plugins.
Shame on me. Some time ago, there were three plugins which provided file saving-related functionality. At some point we merged them into the SaveActions plugin but obviously I forgot to update the documentation. Will do, soon.
I'm fine with anything else and am really impressed and happy about your efforts, Lex. Great job, thank you very much.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
PS, to see why I had all day inside to finish the documentation see
http://www.abc.net.au/news/photos/2009/09/23/2693741.htm
Cheers Lex
On Sat, 26 Sep 2009 20:05:17 +1000, Lex wrote:
2009/9/26 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 23 Sep 2009 12:18:53 +1000, Lex wrote:
Heyho,
Attached is a patch providing some cleanups for geany.txt.
wow. Amazing work.
NOTE: There are a few TODOs in the file that need to be checked before the geany.html is re-created (Addons plugin compatible :-). These are things that I didn't know the answers to.
"Addons plugin compatible"? What do you mean?
Ahhh, I just meant that they show up in the tasks window if your addons plugin has it enabled. I can't do without it, my programs in development are littered with TODOs :-)
Ah, got it. I usually don't use the tasks window :).
There are images called out in geany.txt that are missing from the doc/images directory. I have not created those because I can't seem to get a theme that looks like the other images, so someone who can generate screen captures that match the existing ones should do it.
The only image reference I found was: "TODO add picture of the overall Geany window with all parts visible"
I labelled that one because its a new one without a ..image entry, but some of the files named in existing image entries don't seem to be there either.
I added pictures for the Geany main window and for the build settings dialog. I couldn't find any other pictures missing.
A few remarks/questions I got while reading the patch however the patch is just great!
The Autotools based build system is very mature and has been well tested. -To use it, you just need the Make tool, preferably GNU Make. +To use it, you just need a Unix environment (TODO Mingw on Windows??) and the Make tool, +preferably GNU Make.
Hmm, I think "Unix environment" might sound a bit too heavy. When compiling a release, a somewhat POSIX compatible shell, make and the
Yes, a POSIX shell that is a better way of saying it than Unix environment, but maybe some other tools too?. The TODO was trying to ask the recommended way for Windows users to get the shell and anything else they need. Oh and grep for find in files etc...
The special Windows stuff is mentioned in the wiki on the website. I'm not sure whether we should really repeat it there again. I think users reading the manual already have Geany installed and so don't need too detailed installation instructions again. This is also true for whether mentioning the need for something like a POSIX-compatible shell, a Unix-like environment or listing each single tool you might need. Users are not that stupid, I think.
compilers should be enough (well, not really but this is why we have ./configure to check for what is missing). What I mean is just that Unix environment sounds to me like "You have to install a big new system to get it working". Maybe it's just me, still I'd like to keep the original here.
Nah, I didn't mean that, certainly a shell, but from recent mail discussions it seems that some other minor programs are used by the scripts. All I think is needed is to say where the windows user gets them from, they should be naturally available on *ix. It would be preferable if everything is available in one go, thats why I queried about Mingw, or cygwin or similar??
As said above, this is mentioned on the website even though it might be outdated again. Especially for the case of build instructions on Windows: from what I noticed in the past, there are only very few users trying to compile Geany on Windows. Not only because it's not exactly as easy as on non-Windows systems (:D) but probably also because it's just uncommon.
+The position of the tabs can be selected in the interface preferences.
To me, this sounds like the ordering of the tabs (Symbols, Documents vs. Documents, Symbols) can be changed in the interface preferences. However, I don't know a better way off-hand.
All I'm trying to say is, you can choose which edge of the window the tabs appear on. Should have been clearer.
Yes, I understood what you mean, I was just in doubt not so experienced Geany users would might get confused. I'd like to use Randy's suggestion as it is clearer, IMO.
Some of the default key combinations cannot be changed, e.g. menu_new TODO which ones? and are they actually prevented or just *should* not be changed or menu_open. These are set by GTK and should be kept, but you can
AFAIK these are the GTK stock menu items and can't be changed, at least not without noticeable efforts/hacks. Do we need to describe this even further?
The other TODOs have been removed and replaced with proper content, I hope :). And finally, it's getting committed soon.
Regards, Enrico
2009/9/28 Enrico Tröger enrico.troeger@uvena.de:
On Sat, 26 Sep 2009 20:05:17 +1000, Lex wrote:
2009/9/26 Enrico Tröger enrico.troeger@uvena.de:
On Wed, 23 Sep 2009 12:18:53 +1000, Lex wrote:
Heyho,
Attached is a patch providing some cleanups for geany.txt.
wow. Amazing work.
NOTE: There are a few TODOs in the file that need to be checked before the geany.html is re-created (Addons plugin compatible :-). These are things that I didn't know the answers to.
"Addons plugin compatible"? What do you mean?
Ahhh, I just meant that they show up in the tasks window if your addons plugin has it enabled. I can't do without it, my programs in development are littered with TODOs :-)
Ah, got it. I usually don't use the tasks window :).
There are images called out in geany.txt that are missing from the doc/images directory. I have not created those because I can't seem to get a theme that looks like the other images, so someone who can generate screen captures that match the existing ones should do it.
The only image reference I found was: "TODO add picture of the overall Geany window with all parts visible"
I labelled that one because its a new one without a ..image entry, but some of the files named in existing image entries don't seem to be there either.
I added pictures for the Geany main window and for the build settings dialog. I couldn't find any other pictures missing.
A few remarks/questions I got while reading the patch however the patch is just great!
The Autotools based build system is very mature and has been well tested. -To use it, you just need the Make tool, preferably GNU Make. +To use it, you just need a Unix environment (TODO Mingw on Windows??) and the Make tool, +preferably GNU Make.
Hmm, I think "Unix environment" might sound a bit too heavy. When compiling a release, a somewhat POSIX compatible shell, make and the
Yes, a POSIX shell that is a better way of saying it than Unix environment, but maybe some other tools too?. The TODO was trying to ask the recommended way for Windows users to get the shell and anything else they need. Oh and grep for find in files etc...
The special Windows stuff is mentioned in the wiki on the website. I'm not sure whether we should really repeat it there again. I think users reading the manual already have Geany installed and so don't need too detailed installation instructions again. This is also true for whether mentioning the need for something like a POSIX-compatible shell, a Unix-like environment or listing each single tool you might need. Users are not that stupid, I think.
Ok, I'm not windows literate so I leave it to your judgement.
compilers should be enough (well, not really but this is why we have ./configure to check for what is missing). What I mean is just that Unix environment sounds to me like "You have to install a big new system to get it working". Maybe it's just me, still I'd like to keep the original here.
Nah, I didn't mean that, certainly a shell, but from recent mail discussions it seems that some other minor programs are used by the scripts. All I think is needed is to say where the windows user gets them from, they should be naturally available on *ix. It would be preferable if everything is available in one go, thats why I queried about Mingw, or cygwin or similar??
As said above, this is mentioned on the website even though it might be outdated again. Especially for the case of build instructions on Windows: from what I noticed in the past, there are only very few users trying to compile Geany on Windows. Not only because it's not exactly as easy as on non-Windows systems (:D) but probably also because it's just uncommon.
+The position of the tabs can be selected in the interface preferences.
To me, this sounds like the ordering of the tabs (Symbols, Documents vs. Documents, Symbols) can be changed in the interface preferences. However, I don't know a better way off-hand.
All I'm trying to say is, you can choose which edge of the window the tabs appear on. Should have been clearer.
Yes, I understood what you mean, I was just in doubt not so experienced Geany users would might get confused. I'd like to use Randy's suggestion as it is clearer, IMO.
Yes thats better.
Some of the default key combinations cannot be changed, e.g. menu_new TODO which ones? and are they actually prevented or just *should* not be changed or menu_open. These are set by GTK and should be kept, but you can
AFAIK these are the GTK stock menu items and can't be changed, at least not without noticeable efforts/hacks. Do we need to describe this even further?
Unfortunately? they can be changed, I just went to keybindings preferences and redefined new as alt-n, both ctrl-n and alt-n worked as new. Then defined ctrl-n as save as and it worked as save as not as new and alt-n still worked as new.. And such changes to keybindings save and re-load.
Thats why I thought it should say you *should* not change them because the program doesn't actually prevent you from doing so and *cannot* means that the program will stop you changing them.
The other TODOs have been removed and replaced with proper content, I hope :). And finally, it's getting committed soon.
Thanks and apologies to translators who have to go through it again :-)
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Mon, 28 Sep 2009 13:58:42 +1000, Lex wrote:
Hey,
Some of the default key combinations cannot be changed, e.g. menu_new TODO which ones? and are they actually prevented or just *should* not be changed or menu_open. These are set by GTK and should be kept, but you can
AFAIK these are the GTK stock menu items and can't be changed, at least not without noticeable efforts/hacks. Do we need to describe this even further?
Unfortunately? they can be changed, I just went to keybindings preferences and redefined new as alt-n, both ctrl-n and alt-n worked as new. Then defined ctrl-n as save as and it worked as save as not as new and alt-n still worked as new.. And such changes to keybindings save and re-load.
Ok, then my memories lied at me :). But at least I was partially right: the displayed accelerators on the stock menu items are not updated, not even after a restart.
Thats why I thought it should say you *should* not change them because the program doesn't actually prevent you from doing so and *cannot* means that the program will stop you changing them.
Yes, but it's just a minor technical difference, I'd say. Though, if you feel like expressing the text more descriptive, patches are much welcome :).
The other TODOs have been removed and replaced with proper content, I hope :). And finally, it's getting committed soon.
Thanks and apologies to translators who have to go through it again :-)
There are no official translations available of the documentation, official here means those we would know of.
Regards, Enrico
Hey,
2009/9/30 Enrico Tröger enrico.troeger@uvena.de:
On Mon, 28 Sep 2009 13:58:42 +1000, Lex wrote:
Hey,
Some of the default key combinations cannot be changed, e.g. menu_new TODO which ones? and are they actually prevented or just *should* not be changed or menu_open. These are set by GTK and should be kept, but you can
AFAIK these are the GTK stock menu items and can't be changed, at least not without noticeable efforts/hacks. Do we need to describe this even further?
Unfortunately? they can be changed, I just went to keybindings preferences and redefined new as alt-n, both ctrl-n and alt-n worked as new. Then defined ctrl-n as save as and it worked as save as not as new and alt-n still worked as new.. And such changes to keybindings save and re-load.
Ok, then my memories lied at me :). But at least I was partially right: the displayed accelerators on the stock menu items are not updated, not even after a restart.
Nick and I had a long discussion about accels not changing in the past when I discovered the <super> problem. I thought that problem had been fixed as part of making accels change when keybindings are changed, without reload being needed. It is possible to change the accel labels even on stock items, you just have to remove the accelerator before adding a new one, see attached <super> problem demo program which uses gtk-open and gtk-new stock items and increments the accelerator each time a menu item is activated. (sorry its in C++ with "quick and dirty test program" style :-)
Note: a little like the subtle difference between should and can below, the GTK documentation says you can't *change* the accels, it doesn't say you can't remove them and add a different one :-)
Thats why I thought it should say you *should* not change them because the program doesn't actually prevent you from doing so and *cannot* means that the program will stop you changing them.
Yes, but it's just a minor technical difference, I'd say. Though, if you feel like expressing the text more descriptive, patches are much welcome :).
Ahhh, sorry, your English is so good that I always forget its not your first language.
At least in this country, and I suspect in all English as a first language countries, children learn early that if they ask "can I do ..." the reply is "you can but you may not" making us very sensitive to the difference between being capable of doing something and being permitted to do it, or in the case of changing default keyboard accels, being advised against it :-)
Patch attached, and I've marked the relevant keys in the table IAW the Gnome HIG (I think I got them all).
The other TODOs have been removed and replaced with proper content, I hope :). And finally, it's getting committed soon.
Thanks and apologies to translators who have to go through it again :-)
There are no official translations available of the documentation, official here means those we would know of.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Wed, 30 Sep 2009 10:37:54 +1000 Lex Trotman elextr@gmail.com wrote:
But at least I was partially right: the displayed accelerators on the stock menu items are not updated, not even after a restart.
Nick and I had a long discussion about accels not changing in the past when I discovered the <super> problem. I thought that problem had been fixed as part of making accels change when keybindings are changed, without reload being needed. It is possible to change the accel labels even on stock items, you just have to remove the accelerator before adding a new one, see attached <super> problem demo
I tried to do this for stock items also but it didn't seem to work, I sent a reply to the list: http://lists.uvena.de/geany-devel/2009-August/001119.html
Regards, Nick
Hi Nick,
Sorry I missed your reply.
There are two problems, one is solvable, the other may be terminal for now.
Solvable, lots of the menu items have NULL widget pointers in kb->menu_item so widget_accelerator_remove and ..._add are not called in keybindings_update_combo.
The other I'm not sure at this point how to solve :-(
For stock items Glade sets the accelerator when creating the menu_item using an accelerator map that you can't get hold of, so you can't delete the setting. There doesn't seem to be any way of telling it to not set the accel for a stock item. I'm not sure what happens if you use the same stock for more than one menu item?? Just one more item on my hate list for Glade :-)
Of course getting rid of glade altogether is a solution since gtk_image_menu_item_new_from_stock can be passed an accel group so if we called it instead of glade we would know what was used, but lots of work required for probably not much gain :-(
Cheers Lex
2009/10/2 Nick Treleaven nick.treleaven@btinternet.com:
On Wed, 30 Sep 2009 10:37:54 +1000 Lex Trotman elextr@gmail.com wrote:
But at least I was partially right: the displayed accelerators on the stock menu items are not updated, not even after a restart.
Nick and I had a long discussion about accels not changing in the past when I discovered the <super> problem. I thought that problem had been fixed as part of making accels change when keybindings are changed, without reload being needed. It is possible to change the accel labels even on stock items, you just have to remove the accelerator before adding a new one, see attached <super> problem demo
I tried to do this for stock items also but it didn't seem to work, I sent a reply to the list: http://lists.uvena.de/geany-devel/2009-August/001119.html
Regards, Nick _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 2 Oct 2009 13:10:27 +1000 Lex Trotman elextr@gmail.com wrote:
Sorry I missed your reply.
No problem.
There are two problems, one is solvable, the other may be terminal for now.
Solvable, lots of the menu items have NULL widget pointers in kb->menu_item so widget_accelerator_remove and ..._add are not called in keybindings_update_combo.
Hmm, seems obvious now ;-)
The other I'm not sure at this point how to solve :-(
For stock items Glade sets the accelerator when creating the menu_item using an accelerator map that you can't get hold of, so you can't delete the setting. There doesn't seem to be any way of telling it to not set the accel for a stock item. I'm not sure what happens if you use the same stock for more than one menu item?? Just one more item on my hate list for Glade :-)
Of course getting rid of glade altogether is a solution since gtk_image_menu_item_new_from_stock can be passed an accel group so if we called it instead of glade we would know what was used, but lots of work required for probably not much gain :-(
I really would rather keep Glade.
Regards, Nick
On Wed, 30 Sep 2009 10:37:54 +1000, Lex wrote:
Hey,
Thats why I thought it should say you *should* not change them because the program doesn't actually prevent you from doing so and *cannot* means that the program will stop you changing them.
Yes, but it's just a minor technical difference, I'd say. Though, if you feel like expressing the text more descriptive, patches are much welcome :).
Ahhh, sorry, your English is so good that I always forget its not your first language.
Haha, I don't think so but thanks :).
Patch attached, and I've marked the relevant keys in the table IAW the Gnome HIG (I think I got them all).
Nice, thanks. I added a few (C) marks more like for F11 (fullscreen) and Ctrl+PageDn/PageUp.
Regards, Enrico
On Saturday 26 September 2009 04:20:46 am Enrico Tröger wrote:
On Wed, 23 Sep 2009 12:18:53 +1000, Lex wrote:
+The position of the tabs can be selected in the interface preferences.
To me, this sounds like the ordering of the tabs (Symbols, Documents vs. Documents, Symbols) can be changed in the interface preferences. However, I don't know a better way off-hand.
Hmm, I guess I know what's being talked about, and I'm sure it wants to be kept short--my first try would be something like:
The tabs can be positioned at the top, bottom, left, or right of the main editing window, by a selection in the interface preferences.
Randy Kramer (who can come up with $0.02 for almost anything ;-)
On Sat, 26 Sep 2009 06:53:42 -0400, Randy wrote:
On Saturday 26 September 2009 04:20:46 am Enrico Tröger wrote:
On Wed, 23 Sep 2009 12:18:53 +1000, Lex wrote:
+The position of the tabs can be selected in the interface preferences.
To me, this sounds like the ordering of the tabs (Symbols, Documents vs. Documents, Symbols) can be changed in the interface preferences. However, I don't know a better way off-hand.
Hmm, I guess I know what's being talked about, and I'm sure it wants to be kept short--my first try would be something like:
The tabs can be positioned at the top, bottom, left, or right of the main editing window, by a selection in the interface preferences.
Sounds great. Thanks.
Randy Kramer (who can come up with $0.02 for almost anything ;-)
:)
Regards, Enrico
On Sunday 27 September 2009 11:24:27 am Enrico Tröger wrote:
On Sat, 26 Sep 2009 06:53:42 -0400, Randy wrote:
The tabs can be positioned at the top, bottom, left, or right of the main editing window, by a selection in the interface preferences.
Sounds great. Thanks.
Enrico,
You're welcome! Of course, feel free to adjust it as appropriate.
Randy Kramer