Devel January 2009

devel@lists.geany.org

16 participants
21 discussions

Small search UI suggestion
by Conrad Steenberg 03 Mar '09

03 Mar '09

Hi all Doing an unsuccessful search using the search dialog currently results in a dialog popping up asking "searchstring" was not found. Wrap search and find again? Clicking on the Find button results in a message in the status bar saying "searchstring" not found. Would it be possible to change the search field background to red in this case, to give additional visual feedback that the search was fruitless? In the same way that the search field in the toolbar does it. Thanks! Conrad -- ----------------------------------------------------------------------------- Conrad D. Steenberg Ph.D. conrad.steenberg(a)caltech.edu Scientific Software Engineer http://clarens.caltech.edu Pierce Bio-Engineering Lab Mail Code 114-96 California Institute of Technology Pasadena, CA, 91125

3 2

LexHTML regression
by Jason Oster 15 Feb '09

15 Feb '09

Hi all, I noticed today a new regression in LexHTML; Using comments in XML clobbers the fold structure. The comment 'opening'  decreases the fold level. A simple fix is commenting out the "if (foldHTMLPreprocessor)" on line 858, LexHTML.cxx But be forewarned: I don't know exactly when this regressed or what caused it.

2 2

"Auto-close quotes and brackets" - addition request
by JGuillaume (ioguix) de Rorthais 05 Feb '09

05 Feb '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Happy New Year to you guys ! Best wish to you and Geany :) In reply to this discussion on the geany list: http://lists.uvena.de/pipermail/geany/2008-December/003878.html I did my own version of the patch (in attachment). It still have following some flaws: - - when you insert an autoclosed char and immediatly delete it, the non-autoclose code kicks in anyway (I'm not sure how/where to deal with the delete keys) - - when inserting a quote (double or not), coming back before it and inserting another one, the non-autoclose code kicks in anyway. Should we test the next-char before non-autoclosing ? - - the test for matching bracket seems a bit too greedy as autoclose often doesn't kicks in because of a closing bracket few lines after. Hadn't notice any lag with this code, however I wasn't notice lag with Enrico's patch neither...so someone with an older computer should probably check that. Thanks for your next answer and review :) - -- Guillaume (ioguix) de Rorthais -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkllg9QACgkQxWGfaAgowiIFBgCfa4Wrn7gOUrwUarMMAbgxI+Yy hVwAn1FWzNd8eQeXL0oApICzvTdKGRF6 =WD/5 -----END PGP SIGNATURE-----

4 6

Cleanup in the VC menu
by Thomas Martitz 02 Feb '09

02 Feb '09

The attached patch moves the stuff in the tools->VC menu into Current File Current Directory Current Basedirectory This makes each menu cleaner. Additionally, it allows adding new functionality without messing up the current single menu even more, such as revert for directory and basedirectory, or commit of single files etc in the future. Code-wise it does a little cleanup. The creation of each submenu is in a seperate function, as well as the initialization of the hotkeys. -- Kind regards --------

5 19

Update to build support
by Lex Trotman 02 Feb '09

02 Feb '09

Hi All, Sorry for the long silence, I had a family health problem which had me away from home and with only access to email, no upload or download. Now that I am back I will be able to get on with the build-system updates, once I remember where I was up to ;-). Since I stuffed up copying the source to my laptop nothing has happened in the interim. As I remember we were trying to come to a conclusion about commands for header files for C and C++ which are currently explicitly prevented from performing any compile or build. The C++ work I have done in the meantime has re-inforced my desire to be able to at least compile C++ headers by themselves to get out the syntax typos because they tend to cause a lot of "flow on" errors in the .cpp file and C++ generates such enormous error messages (see http://www.parashift.com/c++-faq-lite/templates.html#faq-35.17 for an example). Also I have noticed that Geany 0.15 is very slow when there are lots of errors, maybe the regex parse is a bit slow, anyway that just makes it more important to compile the .hpp file first. The question seems to be how we handle having different commands for the header files (different to the .cpp files that is) without creating new filetypes for them. My last proposal was for a "variant" of the filetype which allowed different commands. The variant was identified by a subset of the filetypes extensions. This is a slightly general solution configurable in the filetypes or preferences files, or another option is something hard coded specifically for header files, not my favourite :(. Any other suggestions? Cheers Lex

4 16

Branching im geany-plugins SVN
by Frank Lanitz 02 Feb '09

02 Feb '09

Hi guys, As you might have seen, last week I created a branch for redesigning of GeanyVC's menu structure. For creating this, I branched the geanyvc subfolder from trunk. This was ok IMHO for this topic but made me thinking about how a branch could look like in future. I had a couple of ideas and like to start some kind of poll about this topic ;) 1.) Always branch complete trunk with all plugins so e.g. waf is still working. This would make some things more easier e.g. handling with git svn, but would force somebody who did a svn co on the branch to waste space on the hard drive 2.) Creating a folder structure similar to the tags section and then putting the branch into the right folder: |-- branches | |-- backupcopy | |-- filetree | |-- geany-mini-script | |-- geanydbg | |-- geanydebug | |-- geanydoc | |-- geanylatex | |-- geanyprj | |-- geanysendmail | |-- geanyvc | |-- instantsave | `-- spellcheck |-- tags | |-- backupcopy | |-- filetree | |-- geany-mini-script | |-- geanydbg | |-- geanydebug | |-- geanydoc | |-- geanylatex | |-- geanyprj | |-- geanysendmail | |-- geanyvc | |-- instantsave | `-- spellcheck `-- trunk 3.) Branching as needed analog to GeanyVC_menu_redesign, were only code is included, that is really needed for the branch. I'd prefer suggestion 1, but I really like to know your opinion. ;) Cheers, Frank -- http://frank.uvena.de/en/

4 4

RFC: Plugin installation path for documentation
by Enrico Tröger 31 Jan '09

31 Jan '09

Hey, I just thought about how external plugins could/should install their documentation files[1], if any. The usual location would be $prefix/share/doc/pluginname but I think with multiple plugins installed, this could clutter up the doc directory a little bit. At least when the plugins are installed in a global default prefix like /usr. Then users end up with something like /usr/share/doc/externdbg /usr/share/doc/geanylatex /usr/share/doc/geanyvc /usr/share/doc/spellcheck Especially for plugins which are not prefixed by 'geany' (which is by no means necessary IMO) this could be ugly, especially when plugins are packaged by distributions. (currently the geanylua plugin installs documentation in $prefix/share/doc/geany/ which is even worse, plugins should not install anything into Geany's doc or datadir) So, my suggestion would be to make a recommendation for plugin authors to install documentation files into $prefix/share/doc/geany-plugins/${pluginname} example: /usr/share/doc/geany-plugins/externdbg /usr/share/doc/geany-plugins/geanylatex /usr/share/doc/geany-plugins/geanyvc /usr/share/doc/geany-plugins/spellcheck This way, the global doc dir won't be cluttered so much and plugin documentation files will be installed together in a common directory. What do you think? [1] Documentation files mean not only some kind of user documentation but also the usual README, AUTHORS, COPYING, ... files. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc

6 16

Automatically set working dir in geanygdb
by Thomas Martitz 30 Jan '09

30 Jan '09

This patch changes file loading behaivor, as to changing the working dir automatically to the dir of the loaded file, instead of something (to me) random (current behavior). Some apps depend on the working dir being the dir where the executable is. And those who don't don't care about working dir at all, so this is a good change. -- --------------- Best regards, Thomas Martitz ---------------

2 1

Re: [Geany-devel] [ geany-Bugs-2519094 ] GFileMonitor and g_object_ref
by Colomban Wendling 25 Jan '09

25 Jan '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Comment By: Enrico Tröger (eht16) > Completely unrelated to Geany. > HTTP usually doesn't support write operations, right? So how do you want > to write files to it or even mount it? Opening a file through HTTP works with g_file_new_for_uri(), but yes, write operations will fail. > Instead, use dav:// assuming your server supports it. Then you can mount > it as usual and after having mounted it, you can open and edit files on > it. I dunno how to do it "as usual" since I use Nautilus 2.22 for now that AFAIK doesn't really support GIO, and I dunno how to mount a location with GVFS without Nautilus… But yes, I understand the meaning :) > Yes, that's the way. And when we save the file in Geany, we set an ignore > flag to ignore the next 'file has changed' signal. And there probably begin > the problems. > Also, this works only if the file was actually only changed which happens > when saving with Geany. When you save the file with Gedit, it (probably) > won't work because Gedit first saves the file into a temp file, then move > it to the real file. So, the real file is never 'changed' but 'created'. > And the 'created' notification is currently ignored at all. Hum… I've just tried with Gedit modifying an opened file in Geany, and the tab becomes orange, but when I start to modify it again, Geany tells me that the file was not found on the disk, asking me whether I want to save it… and if I say yes, then ask me if I want to overwrite the existing file. Well, not perfect (but I personally don't mind about that since this feature helps me mostly for files modified by a script). > This doesn't really explain your problems, I think. But is one of the > things I meant when saying 'not yet 100% functional'. Let me give it > another try tomorrow and in the meantime just revert to before r3484 :). OK, I see. And yes, just take the time you need and let us (me?) know when we can test your new efforts :) > > > Too bad, I hoped there was something real exotic which would explain the > behaviour :). Hey no, sorry :D > P.S.: quoting in the tracker is awful. Moving to the mailing list? Yeah, great idea! Just ask me if you need any other test or information. Regards, Colomban -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl1BcIACgkQyqbACDEjVWhKpACg3Z8Z3cpGhLD6ZnrMYOpbFwTh mD4AoIZvuldC/BPFpYraJmg+/o+GuRCe =kOgp -----END PGP SIGNATURE-----

3 9

GTK API docs update
by Enrico Tröger 24 Jan '09

24 Jan '09

Hey, just to lt you know I just updated the GTK API docs on http://www.geany.org/manual/gtk/. There are now the latest available versions(*) of GLib, GObject, GDK, GDK-Pixbuf and GTK online and a tarball containing all docs: http://www.geany.org/manual/gtk/gtk-doc-2.8.tar.gz (*) latest versions of the 2.8 series available on http://library.gnome.org/. Regards, Enrico -- Get my GPG key from http://www.uvena.de/pub.asc

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel January 2009