Devel June 2010

devel@lists.geany.org

22 participants
37 discussions

STATA support and cross-compiling
by Alessio Caiazza 29 Jun '10

29 Jun '10

Hi, my name is Alessio and I'm working on STATA support for geany. I've got a "working" implementation so I'm trying to cross compile geany from my linux box in order to allow the coworkers (which are the real STATA dev) to test it on windows. I've followed this [1] instructions but I installed mingw32 with apt-get, after that I updated the paths on cross-configure.sh and cross-make.sh Everything compiles but when I start the application I get a popup complaining about the missing of g_malloc0_n function in libglib-2.0-0.dll. Any hints? Best wishes, Alessio [1] http://www.geany.org/Support/CrossCompile

2 2

build dialog default entries color
by Dimitar Zhekov 25 Jun '10

25 Jun '10

Hi again, Firefox uses fg[GTK_STATE_INSENSITIVE] for the search field. If we consider this acceptable, can someone please change "text" in the patch to "fg" and apply it? -- E-gards: Jimmy

2 1

build dialog default entries color
by Dimitar Zhekov 23 Jun '10

23 Jun '10

Hi, ChangeLog, 2010-06-17: * src/build.c: Make default Build dialog entries grey, not light grey (too hard to read on a white background). Instead of trying various shades of gray (the default commands are almost unreadable on my background, and were absolutely invisible with light gray), why not use the inactive text color? Patch attached. Another option will be to use (bg.r + text.r) / 2, (bg.g + text.g) / 2, (bg.b + text.b) / 2 - this ignores the monitor gamma, but who doesn't. It'll also be nice to recolor the active row when it loses the focus. Currently, once you in a row, it remains in "changed color" until the dialog is closed, even if no changes were made. -- E-gards: Jimmy

2 2

Translation of Build menu labels
by Lex Trotman 21 Jun '10

21 Jun '10

Hi Enrico, On 3 June you committed a change to translate menu item labels. This is the wrong thing to do because: 1. If loaded from user config files the strings are written by users and should not be translated 2. If loaded from a config file with the old [build-settings] section and no [build-menu] section (all but Latex IIRC) then the labels are created in the code of build_load_menu_group and are already translated there. 3. The Latex menu labels won't be translated because the strings don't exist in code anywhere. The msgids are therefore commented out in the po files. AFAICT the change won't do anything, but it exposes a bug in gettext that returns a large message if its passed an empty string, and empty strings are explicitly allowed in the configuration to hide a menu item. What problem were you trying to fix? Cheers Lex

1 0

tm_get_real_path() description
by Dimitar Zhekov 20 Jun '10

20 Jun '10

Hi, The description of tm_get_real_path() claims that "unlike realpath, a reasonable guess is returned even if the file does not exist". However, from what I see, it simply returns realpath(), and IMHO, it shouldn't try to guess something like that. So can we cut the description a bit? -- E-gards: Jimmy

3 2

Re : txt2tags syntax highlight
by Forgeot Eric 20 Jun '10

20 Jun '10

>Did you already get in contact with the Scintilla team as beside the >issue your Lexxer would be also a nice one to be included into >Scintilla itself. not yet, because it's easier for me to recompile Geany rather than to use Scintilla and Scite. But I'll do it soon I think. I've updated the lexer and now it's almost fully fonctional. Now for symbol such as -- which is not correcty terminated (it could be written like this, for example if the author is refering to a command line switch), it won't last beyond the end of the current line, but I'd prefer it to begin to color the text only if there are both symbols around it (like for the URL). Here is a screenshot: http://img641.imageshack.us/img641/2791/geanytxt2tagslexer.png

1 0

Re : txt2tags syntax highlight
by Forgeot Eric 20 Jun '10

20 Jun '10

here is a new patch, with a better support for most of the syntax. The main problem (which can be also found in the Markdown lexer), is when using symbols similar to the one used for --strike-- for example, it will interfere with the rest of the document. At least the coloration shouldn't last after the end of the current line, but I didn't manage to get it this way.

2 1

Re: [Geany-devel] Git switch
by Jiří Techet 19 Jun '10

19 Jun '10

2010/6/12 Enrico Tröger <enrico.troeger(a)uvena.de>: > On Wed, 9 Jun 2010 17:09:49 +0100, Nick wrote: > >> On Wed, 09 Jun 2010 15:11:48 +0200 >> Thomas Martitz <thomas.martitz(a)student.htw-berlin.de> wrote: >> >> > Am 09.06.2010 03:40, schrieb Lex Trotman: >> > > Sure its easier if everyone is using git, but ATM this is an SVN >> > > project. >> > >> > Although most, if not all, geany developers use git, don't they? >> >> Do you mean git-svn? The Git repo is not writable. >> >> I don't use Git for Geany, but wouldn't mind if everyone else wants to >> switch to it. > > Me neither. > If we want, we can switch to GIT. > > Since my experience with GIT is very limited so far, I don't mind which > way we want to go and how to organise the repository regarding branch > strategies and such. > The only requirement/wish I have that we don't host the repository on > gitorious or github or such social coding platforms, that sucks. Well, I have no experience with repo.or.cz, but my feeling is that this is just a "classical" type of hosting where contributors cannot easily create their own clones and have them hosted. Myself I'm a hater of anything that has "social" in its title and all the chatting nonsense (facebook, skype, ICQ to name some), but gitorious and github are much more "useful" than "social". This choice will also influence the workflow in which you will use git. If contributors cannot have their branches hosted easily, then the the Linus model (one pusher pulling from contributors) will be harder to realize. Regards, Jiri

10 49

txt2tags syntax highlight
by Forgeot Eric 19 Jun '10

19 Jun '10

Hello, I've managed to make a working lexer for txt2tags. It's based on the markdown one. The patch is in the attachment file. If you accept it, I'll propose it upstream to the scintilla project. On http://geany.org/manual/dev/hacking.html#syntax-highlighting I propose you add something about editing scintilla/include/Scintilla.iface for updating scintilla/include/SciLexer.hBtw, I didn't manage to update the SciLexer.h file from scintilla.iface, so I've manually copied the code in both files.

1 0

Multiple instances of Geany issues
by Lex Trotman 17 Jun '10

17 Jun '10

Hi All, I've created this thread separate from Eugene's and Ditmar's session management threads because my concern is mostly about other parts of Geany and I don't want to be seen as criticising either of them as it was their input that started me thinking. Having multiple Geany instances is a great capability, * I can have two (or more) projects open to share code or to interrupt work on one to do something an another, * I can have Geany on *both* of my screens so I can see different parts of what I'm working on * I can set up my filemanager to open different instances so opening random files won't affect the work I'm doing My concern is that we should make sure that the way Geany works is safe and preferably causes no surprises when multiple instances are sharing files. There are three types of files that Geany instances could share and I think they should be handled differently: * Files being edited (the second of my use cases above). I don't think it is up to Geany to handle users editing the same file in multiple instances, its up to the user to sort it out when time comes to save. A user can always set readonly to protect against themselves. Making --readonly a command line option would be a good addition. * Project files (same project in two instances), since the user doesn't explicitly control the project file I think Geany is going to have to become involved in this case. The only options that I can see in this case are: ** when a project file has changed on disk (by date/time), for Geany to ask if it should save or save as or throw away any changes to project from this instance. This way an instance won't silently overwrite changes made by another instance, and with save as I can procrastinate by saving this instances changes elsewhere until I can decide which I want. ** only the Geany not started with --new-instance can save the project file * Geany.conf (shared by any two or more instances), this is a real potential problem if multiple instances try to save the same file. Discussions in another thread seemed to come to the conclusion that only the Geany that was started without --new-instance should save it preventing races when several instances are closed at once. BUT this is not implemented in the SVN that is about to become 0.19 and in my test a new instance overwrote the main Geany.conf losing session, recent files etc!!! I think that preventing --new-instance from saving project and preference files should be implemented before 0.19 is released otherwise failing to close instances in the right order or missing an instance when logging out will overwrite the preferences. And configuring a filemanager to use --new-instance will overwrite when closed even if no other Geany is running. Later on we can look at the other options and also look at indicating to the user which Geany instances can save, maybe by something after the Geany in the title bar? Cheers Lex

4 58

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel June 2010