Hi Steven,
On 29 November 2012 03:50, Colomban Wendling <lists.ban@herbesfolles.org> wrote:
Le 28/11/2012 16:37, Steven Blatnick a écrit :
Lex,
Actually I tried Alt-Up on the file browser and it didn't work for me.
I just tried entering that shortcut into compiz, and it doesn't appear
to be using that shortcut for something else. (Linux Mint 11 64-bit,
gnome 2, using geany from yesterday's git).
Lm13 with Mate works, maybe your DE is swallowing the alt, some do I
think. Or it is GTK version dependent.
[...]
Since Colomban more than adequately answered most I will only comment
on a few of your points.
1. Allow keyboard shortcuts to be changed from the menus. Gnome2 at
least has the option of allowing gtk apps to set their custom
shortcuts by hitting the desired keys while the menu entry is
highlighted. This would make changing the shortcut as simple as
finding the functionality in the first place instead of finding it
again in the shortcuts menu. It would also allow you to quickly
change a shortcut on certain things quickly (see #2 below)
This was always a poorly thought out misfeature (for the reasons
Colomban said plus the accidental invocation factor) that we shouldn't
implement (IMHO).
[...]
3. File Browser plugin allow creation of new file/folder, renaming of
file (even one currently being edited, thereby changing the name on
the editor too), and moving a file to trash. Also, perhaps a
feature to show/hide binary files.
Whats wrong with your DEs file manager, why should every application
(re)implement a full filemanager? </rant> In Gnome2 at least the DE
filemanager is not like the strangulated Gnome 3 one :)
I will say that one of the primary reasons I used gedit and want to
use geany is because of the integrated/native feel with gnome since
it uses gtk, the file open dialog which respects bookmarks, and the
file browser behaves much like a mini version of nautilus.
I think the geany-plugins' filebrowser plugin already have those
features. Not sure why there are two distinct plugins though.
The one distributed with Geany is really just a file *browser*, more
like a persistent open dialog, the other tries to be a file manager,
but how well I'm not sure.
[...]
7. Fixed width tabs option on Preferences->Interface->Notebook
tabs->Tab positions. When I move my tabs on the editor to the left
or right, I would prefer to be able to fix the width on them so
longer file names don't extend the width. I did this with a python
plugin in gedit by allowing the width to be set with a spinner in
preferences and then the plugin adjusts the tab's Label property
"width-request" from -1 to the width desired. (I've already started
looking into the code to do this in geany, but maybe someone else
already is working on this or maybe can do it faster because of
familiarity)
In core Geany it would probably go in notebook_new_tab() from
notebook.c. However, a plugin could probably do it quite easily by
connecting to the signal for new tab created, and modify the label
packing or label size request.
Yeah a plugin to do this would be nice,
when_you_have_a_very_long_filename_it_shrinks_the_editor_too_much.txt
:)
[...]
9. Both the side panel and the bottom panel allow Ctrl+PgUp/PgDown to
change tabs like the editor does (awesome!) but unlike the editor,
they don't wrap around. Also, the bottom panel, the terminal
emulator interrupts the keyboard shortcut, not allowing it to browse
off of it using that keyboard shortcut.
I can't be sure right now for the normal Geany, but without
modifications in this direction my GTK3 branch does loop in all notebooks.
Latest Git wraps here too, maybe it depends on GTK version? Using GTK
2.24.10, GLib 2.32.3.
[...]
10. Allow a dynamic number of compile tools. It appears now I can only
have the number visible in the UI. I realize the UI would have to
be coded instead of in a glade file to do this. Alternatively,
"External Tools" like functionality would, in my opinion, be more
versitile. It allows any program to be called passing it the same
things we pass plus any highlighted text, current line number,
current line, etc.
I can't really answer here (Lex probably could ;)), but I think that
only the UI prevents from a dynamic number of build commands. E.g., I
think the code behind has the ability.
It is all implemented, the UI size will change at *startup* if the
settings (in various) are changed. Read
http://wiki.geany.org/howtos/configurebuildmenu :)
The extra command slots will only appear in the set build commands
dialog until you assign them a name to go on the menu.
Seems a bit unintuitive.
IIRC somebody already started a discussion on changing this UI, not sure
what was the outcome (but either we couldn't find a solution we found
good or nobody felt like doing the required changes).
Not sure what discussion you mean, did I miss something?
[...]
13. Allow the status bar to change the file-type setting for setting
syntax highlighting (gedit style).
This would require a quite massive rewriting of the toolbar code since
currently it's simply a (user-modifiable) formatted string, e.g. it's
one single string, not several label/values (where the value could quite
easily be changed to a combo box or alike). Though, I agree that the
idea is quite neat -- although I find the GEdit implementation terrible
from it having all items in one single menu, making searching for the
appropriate language really hard.
If we chose to implement this, all configurable items shown in the
status bar could benefit from it (indent type, line ending type,
encoding and filetype).
Since you have to click on both, I don't see this adding any value
over using the document menu, lets concentrate on adding useful
features, not more ways of invoking existing ones.
Maybe we could at least move the menu up so it isn't so deep within
sub-menus.