Replies below. I hope nobody is annoyed that the new guy is emailing so
much :-)
On 11/28/2012 09:50 AM, Colomban Wendling 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).
I guess this is the right place to make suggestions and/or see if
development is being already done toward something?
Yes, development questions and discussions happen here, that's the
correct place :)
I hope nobody minds, since I'm the new guy...
Welcome!
Also, sorry if any of this is repeat
from some bug tracker, existing feature I missed, planned feature, or
otherwise since I don't know the workflow nor features as well.
Here are a few ideas for features and/or plugins (Disclaimer: I come
from gedit, so hope nobody minds I refer to it so much):
That's not a problem, but I hope you don't mind if we don't all know
what it the GEdit feature you might refer to ;)
Understandable :-)
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)
IIRC GTK guys plan to (or already have?) remove this feature from GTK3,
finding it old and useless. So we'd have to re-implement if we want
GTK3 support. Also, I must admit I never used it in any program, and I
can only think of Gimp as a program allowing this -- and even then, it
has an option for this (unchecked by default I think).
Moreover, it has one important issue IMO (at least in Gimp, but I guess
they use the GTK feature): it doesn't ask if trying to assign an already
existing binding, which means if one accidentally maps to an already
existing binding it gets silently overwritten. And a dialog here would
be quite odd... I don't know. Also, at least Gimp doesn't allow
changing the binding of an insensitive item (boring when I tried to
remap Undo/Redo for testing).
That's the beauty of it :-) Just assign without prompting of conflicts
on a program by program basis. It's a shame they're removing that
functionality in GTK3. They seem to be making a lot of decisions
(Gnome, maybe not GTK?) about what people want/don't want lately...
That was an awesome feature most people didn't use, partly because it
was disabled by default on most distros :-(
Maybe if it's just a flag it could be dependent on what it's building
against? Though I hate to support different features for different
dependencies... If they end up keeping that feature, I hope we could use it.
2. External Tools plugin like gedit has that can have a quick-list on
the toolbar (I've written a python plugin for gedit to put it on the
toolbar, and I love being able to change the shortcuts quickly while
selecting the tools I need for a particular project)
Isn't this the same as Custom Commands? (check out the docs if you
don't know about them)
I didn't know about that particular feature, but it is kinda similar.
It seems the various external calls could all be consolidated to one
place, because as is they're everywhere. All of this could be a plugin
instead.
What I mean is these all are similar:
1. Custom Commands
2. Context actions
3. Build Commands (finite list too)
Instead, I think it would be more intuitive to put them all together
like GEdit's External Tools. It's simpler and more powerful I think.
(Don't get me wrong, I wouldn't be trying geany out if I thought gedit
were better in every way. Geany has a lot of customization GEdit
lacked.) For those who haven't used GEdit much, let me point out some
of the features, as well as ideas for improvement:
1. When the command is run, all of the following are passed to it as
shell variables:
1. document path (actually as separate fields, so kinda overkill,
I'd just do the first one below)
1. current document path (Example:
$GEDIT_CURRENT_DOCUMENT_PATH=/home/steve/work/scratch.sh)
2. current document name (Example:
$GEDIT_CURRENT_DOCUMENT_NAME=scratch.sh)
3. current document uri (Example:
$GEDIT_CURRENT_DOCUMENT_URI=file:///home/steve/work/scratch.sh)
4. current document directory:
($GEDIT_CURRENT_DOCUMENT_DIR=/home/steve/work)
2. document scheme (Example: $GEDIT_CURRENT_DOCUMENT_SCHEME=file)
3. document type (Example:
$GEDIT_CURRENT_DOCUMENT_TYPE=application/x-shellscript)
4. all open documents (just need the first one again, yes I have
used this feature too)
1. path (Example:
$GEDIT_DOCUMENTS_PATH=/home/steve/work/TODO.txt
/home/steve/work/home/bin/stats/cron
/home/steve/work/home/bin/stats/bin/process-stats-daily
/home/steve/work/home/bin/stats/bin/process-stats-hourly
/home/steve/work/scratch.sh)
2. uri (Example:
$GEDIT_DOCUMENTS_URI=file:///home/steve/work/TODO.txt
file:///home/steve/work/scratch.sh)
5. selected text (Example: $GEDIT_SELECTED_TEXT=)
6. current word position (Example: $GEDIT_CURRENT_WORD=2696)
7. current line at cursor (Example: $GEDIT_CURRENT_LINE=echo Hello
world;)
8. current line number at cursor (Example:
$GEDIT_CURRENT_LINE_NUMBER=3)
2. Each command has the following configurable:
1. Shortcut key
2. Save the current document, all documents, or not to save
3. Input (kinda unnecessary with the variables stored above)
4. Output - where to put the output:
1. replace highlighted text or at cursor
2. replace current word or line
3. display in the bottom panel
4. append to the current document
5. replace the current document
6. Open a new document with the text
5. What file types to allow/display the command on (languages,
extensions)
6. What state of documents to allow/display the command on
1. local files
2. remote files
3. all documents
4. untitled documents
5. all but untitled documents
We could add some options to:
1. display in context
2. display in menu
Basically, you could set up all build commands, custom commands, and
context actions to work from a single easy to understand UI. The current
build commands only seem to allow a finite set of build tools, and we
don't send as much to the command as far as I can tell. Personally, I
think the more sent as environment variables the better. Having this
feature has allowed me to make quick plugin-like features. It would be
even more powerful if we could control geany from the command line by
allowing an options for commands to use an existing window, such as
going to a line or opening a file.
For example, I created a macro at a job where I could open corresponding
files for any jsp/java/js file of the same name (a convention at that
job). So when I'd hit F12, if I had Example.java open and example.js,
it would find and open example.jsp for me in the same window. Or if
only example.jsp is open, it would open the other two.
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.
I think the geany-plugins' filebrowser plugin already have those
features. Not sure why there are two distinct plugins though.
I meant that we should add those features to the current file browser
plugin. I wasn't able to see those features in the context menu.
4. Inline/embedded search (like gedit2's incremental search). I guess
the toolbar search works that way kinda...
I don't quite know GEdit 2's behavior, but I think indeed the toolbar
search field does this. Is there a problem with it? I agree that some
fancy UI like Firefox's search could be cool, but I also think that if
the user wants more complex search options, she could very well use the
search dialog, and otherwise use the search field. I don't think we
could reasonably put all our search dialog options inline.
I think you're right. I was only thinking for basic case-insensitive
searching, or basically just moving the toolbar one inline on demand,
but where it is is probably better/fine.
5. Highlight all found instances of a string from the search (like
gedit, would apply to string literals, not necessarily regex, from
an inline search).
My be interesting indeed (although I probably wouldn't use it myself).
Note that we already have "mark all" in the search dialog, and a plugin
to highlight a word upon double-click ("addons" I think).
I didn't know about the addon, so I'll have to check it out.
The "mark all" puts a marker in the left margin, which I like to
disable/hide that margin and even if we mark it there, we could still
highlight the actual word itself for visibility.
6. Allow highlighting of all words in a document separate from search
highlighting (like gedit's "Smart Hilighting" plugin).
That's the "mark word" "addons" plugin feature I think :)
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.
8. Is there a way to disable/enable or view/hide the various bottom
pane tools independently. For example, if I never want to use
Scratch, then a way to disable it from loading would be nice.
In the "Various" prefs, the "msgwin_*_visible" settings.
Thanks! Exactly what I was looking for.
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.
Also, the terminal doesn't eat the strokes either, but there is a
setting in the terminal prefs to choose whether it overrides Geany's
bindings or not.
Ok, thanks. I'll look for that.
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.
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).
Anyone reading this know if someone is working on it? Let me know if I
can help :-)
11. Allow executing of highlighted SQL based on a current connection
(among a configurable list). (I did something like this for gedit 2
and 3 and I use it all the time.)
That'd be a candidate either for a custom command and an helper script,
or for a plugin :)
I agree. I'll probably write a similar plugin for geany.
12. Add a toggle button to the toolbar for turning word wrapping on and off.
Probably easy to do and harmless, since the toolbar is configurable.
Ok, maybe I'll add this to a list of things I can look at to get my feet
wet.
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.
I totally agree that GEdit did this terribly. I have a unreleased
plugin for gedit 3 I wrote that adds quick buttons to the status bar
that can be checked in the plugins preferences. That way you can have a
few buttons on the bar to instantly change it. Alternatively, if we did
so in geany, it would probably be better to allow what ones show up in
the list.
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).
That would be awesome. Good point.
14. "Snap Open" dialog. Quickly open files by typing the filename and
filtering down based on a project's base directory (or otherwise
configurable). The dialog should be configurable to skip files for
speed, such as a build directory, .svn/.git and hidden directories, etc.
That'd probably be a great plugin :) I think GProject (or maybe it's
GeanyPRJ?) has a similar feature.
Ah, and if you want this feature, maybe you'd be interested by the
Commander plugin ;) (it allows to browse the menus and open files using
a search entry).
I agree, a plugin is probably a better place for that. I don't want to
bloat geany. I love how light weight it is.
I'll have to look at the commander plugin.
15. Sort alphabetically highlighted lines (see gedit plugin)
That's a candidate for `sort` custom command ;)
Good idea. I didn't know about custom command before.
16. Compact menu option (Like firefox's Compact Menu 2 plugin. I've
done something similar in gedit.)
I don't like this, but a plugin could probably hack around to achieve
this. Ubuntu's Unity does a similar thing for displaying the app menu
in the desktop top bar. Also, GTK3 has an (completely mis-though IMO,
but that's not the question :-') thing to achieve this.
I agree, this is a plugin candidate.
I still want it on the window. I think moving menus to the top (like
Unity) is a terrible idea. If you feel like it, take a gander at my
blog ranting on why the switch to gnome 3 (or Unity) from gnome 2 has
left me in limbo and been a source of discomfort for me. In fact, I
mention in the post how I feel torn between supporting gedit 2 vs 3 vs
pluma. That's why I'm looking at geany :-)
http://steve8track.blogspot.com/2012/09/one-small-step-for-gnome-one-giant-leap.html
Regards,
Colomban
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
You guys have been great already :-) I tried chatting with the MATE
guys about pluma a while back, but I didn't get much response. I'm glad
this group seems friendlier.
Thanks,
Steve
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel