[Geany-Devel] I'm thinking I like Geany...

[Colomban Wendling]

Le 29/11/2012 00:36, Lex Trotman a écrit :
> [...]
> 
>>> 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.
> 
>>
>> 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?

Reading your answer I see I forgot one key word in my sentences:
"dialog".  I was speaking about the "Set build command" dialog, e.g.
that it doesn't provide the ability to add more build commands than the
visible slots, but that the rest did support more.  E.g. that if you
edit the configuration file by hand it would work.  But maybe I'm wrong,
I'm not sure.

And maybe I dreamed this thread, but I think we (who I don't remember)
spoke about how the "set build commands" dialog could be made more
flexible at adding and removing slots.

>>> 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.

Well, it's one click and visible rather than 2 clicks and inside a menu.
 But I totally agree it's not important, but I find it "cool" -- and I
didn't meant "useful" ;)

>>> 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).
>>
> 
> This of course used to be part of the open dialog until the brain dead
> at GTK removed it.

Did they?  I can still type and filter.  If I type in the entry I get a
completion list with the possible filenames, and if I typahead in the
list it still performs a (naive) search in that very list.

However, a more advanced filtering might be interesting, like showing
only project patterns (if any are set -- but this one is easy with the
filter option of the file chooser), with more powerful matching
algorithm like (not necessarily the filename start, plus wildcards, why
not with "magic" matching like "p/fbc" matching "plugins/filebrowser.c",
this kinda stuff), etc.

Cheers,
Colomban