Devel June 2012

devel@lists.geany.org

16 participants
26 discussions

Re: [Geany-devel] [geany/geany] Question on - 7b3b65: Add workaround for users with an invisible selection style
by Lex Trotman 08 Jun '12

08 Jun '12

On 4 June 2012 03:04, Nick Treleaven <git-noreply(a)geany.org> wrote: > Branch: refs/heads/master > Author: Nick Treleaven <nick.treleaven(a)btinternet.com> > Committer: Nick Treleaven <nick.treleaven(a)btinternet.com> > Date: Sun, 03 Jun 2012 17:04:03 > Commit: 7b3b65e27df77be862714e2de69aa9f61764a91b > https://github.com/geany/geany/commit/7b3b65e27df77be862714e2de69aa9f61764a… > > Log Message: > ----------- > Add workaround for users with an invisible selection style > > This is likely to be the case for any users that copied the system > selection style line as this was incorrectly set before, but not > applied. > Hi Nick, Based on your answer on my ML question is this necessary? Now that we always apply the settings, a selection style of false,false will reset to the Scintilla default "The default is to show the selection by changing the background to light gray and leaving the foreground the same as when it was not selected". So false, false shouldn't be invisible. Of course it might be invisible on particular backgrounds, but so might c0c0c0. Or have I still misunderstood something? Cheers Lex > > Modified Paths: > -------------- > src/highlighting.c > > Modified: src/highlighting.c > 6 files changed, 6 insertions(+), 0 deletions(-) > =================================================================== > @@ -790,6 +790,12 @@ static void styleset_common(ScintillaObject *sci, guint ft_id) > sci_set_property(sci, "fold.at.else", "1"); > > style = &common_style_set.styling[GCS_SELECTION]; > + if (!style->bold && !style->italic) > + { > + g_warning("selection style is set to invisible - ignoring!"); > + style->italic = TRUE; > + style->background = 0xc0c0c0; > + } > /* bold (3rd argument) is whether to override default foreground selection */ > SSM(sci, SCI_SETSELFORE, style->bold, invert(style->foreground)); > /* italic (4th argument) is whether to override default background selection */ > > > @@ Diff output truncated at 100000 characters. @@ > > > -------------- > This E-Mail was brought to you by github_commit_mail.py (Source: TBD). > _______________________________________________ > Geany-commits mailing list > Geany-commits(a)uvena.de > https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-commits

3 7

Would be nice to have line numbers for the HTML export plugin
by theUser BL 08 Jun '12

08 Jun '12

I think it would be nice to have line numbers for the HTML export plugin. I am not so familiar with C++, so I post it only as suggestion. But the in Java written RText (http://www.fifesoft.com/rtext/) have with its function a very similar output. Here the important Java file: http://svn.fifesoft.com/viewvc-1.0.5/bin/cgi/viewvc.cgi/RText/trunk/src/org… And for that I have posted an modified version of that file at http://fifesoft.com/forum/viewtopic.php?f=5&t=670 so that line numbers are nicely shown. Possibly it can help you a little bit. It is only a cutted down version of GoogleCode. If it does not help you, here the HTML-outputs: A little Java source file: ---------------------------------------------------------------------------- class Hello { public static void main(String[] args) { System.out.println("Hello World!\n"); } } ---------------------------------------------------------------------------- The HTML-code your plugin creates: ---------------------------------------------------------------------------- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <title>/home/patrick/geanyGitHub/Hello.java</title> <meta http-equiv="content-type" content="text/html;charset=utf-8" /> <meta name="generator" content="Geany 1.22" /> <meta name="date" content="2012-06-08T03:01:55+0200" /> <style type="text/css"> body { font-family: Monospace, monospace; font-size: 10pt; } .style_0 { color: #000000; background-color: #ffffff; } .style_5 { color: #00007f; background-color: #ffffff; font-weight: bold; } .style_6 { color: #ff8000; background-color: #ffffff; } .style_10 { color: #301010; background-color: #ffffff; } .style_11 { color: #000000; background-color: #ffffff; } .style_16 { color: #991111; background-color: #ffffff; font-weight: bold; } .style_19 { color: #0000d0; background-color: #ffffff; font-weight: bold; } </style> </head> <body> class Hello {   public static void main(String[] args) {     System.out.println("Hello World!\n");   } } </body> </html> ---------------------------------------------------------------------------- The output RText creates: ---------------------------------------------------------------------------- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head>  <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>/home/patrick/geanyGitHub/Hello.html</title> <style type="text/css"> .s4 { font-weight: bold; color: #0000ff; } .s5 { color: #ad8000; } .s10 { color: #dc009c; } .s15 { color: #000000; } .s16 { color: #808080; } .s17 { color: #ff0000; } </style> </head> <body> <pre> class Hello { public static void main(String[] args) { System.out.println("Hello World!\n"); } } </pre> </body> </html> ---------------------------------------------------------------------------- And here, what my RText modifications create: ---------------------------------------------------------------------------- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head>  <meta http-equiv="content-type" content="text/html; charset=utf-8" /> <title>[Hello.java]</title> <style type="text/css"> .s6 { font-weight: bold; color: #0000ff; } .s8 { color: #ad8000; } .s13 { color: #dc009c; } .s20 { color: #000000; } .s21 { color: #808080; } .s22 { color: #ff0000; } body{background:#fff;font:82% arial,sans-serif;margin:3px 0 3px 0;min-width:768px} .headbg{margin:0 8px} /* Style sheet for source browsing pages. */ /* File */ .fc pre, .fc td, .fc table {border-collapse:collapse; margin:0; padding:0} #nums, #lines, #nums th, #lines th, #nums td, #lines td { vertical-align:top } pre { font-family: Monaco, 'DejaVu Sans Mono', 'Bitstream Vera Sans Mono', 'Lucida Console', monospace; font-size: 93%; } #nums {padding-right:.5em; width:3.7em} #nums td {text-align:right} #nums a {color:#808080; text-decoration:none} /* line numbers */ #lines td {padding-left:4px;} /* Applies only to sb files and issue attachments */ .fc #nums, .fc #lines { padding-top: 0.5em; } .fc #lines { border-left: 1px solid #dddddd; /* vertial line */ } /* IE Whitespace Fix */ .prettyprint td.source { white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; } </style> </head> <body> <div class="headbg"> <div class="expand"> <div class="fc"> <table><tr><td id="nums"><pre><table width="100%"><tr><td id="1"><a href="#1">1</a></td></tr> <tr><td id="2"><a href="#2">2</a></td></tr> <tr><td id="3"><a href="#3">3</a></td></tr> <tr><td id="4"><a href="#4">4</a></td></tr> <tr><td id="5"><a href="#5">5</a></td></tr> <tr><td id="6"><a href="#6">6</a></td></tr> </table></pre></td><td id="lines"><pre><table><tr><td>class Hello { </td></tr> <tr><td> public static void main(String[] args) { </td></tr> <tr><td> System.out.println("Hello World!\n"); </td></tr> <tr><td> } </td></tr> <tr><td>} </td></tr> <tr><td> </td></tr> </table></pre></td></tr></table> </div></div></div> </body> </html> ---------------------------------------------------------------------------- Hopefully you adding in the future support for line-numbers of your HTML-exports. Would be nice. Greatings theuserbl

2 1

Re: [Geany-devel] tagmanager changes - tree refactoring
by Colomban Wendling 07 Jun '12

07 Jun '12

Le 07/06/2012 17:59, Nick Treleaven a écrit : > On 06/06/2012 15:42, Nick Treleaven wrote: >>> OK, I tried building it and found some fixes are necessary for the >>> Windows makefiles - I'll commit these to a branch. After those changes, >>> it seems to build fine. >> >> Now pushed to: >> https://github.com/ntrel/geany/commits/tm/tree-refactoring >> >> > Thanks for doing this, the structure is much better than before. >> > However, the build changes are quite substantial, so I think it >> might be >> > best not to include them in the 1.22 release in case it introduces any >> > problems. >> > >> > Also, I found the problem with suppressed gcc warnings in tagmanager >> > code - it was the hardcoded -w switch (which I read as -W)! Oh great, tricky to find out! >> > Unfortunately this commit will conflict with the tree refactoring. I >> > will try to resolve the conflicts so we can merge the branch, perhaps >> > after the 1.22 release? >> >> I also have a ctags/c.c fix I'd like to include in the release, so >> please let me know whether to delay it until merging this branch, >> although as I said, it might be better to leave this out of the release. >> I'm still happy to try to fix the conflicts myself, even if we do delay >> the merge. > > I've now merged in master to my branch, same URL - surprisingly git > didn't report any conflicts, I think because it recognizes moved files, > even when there is some changed content, e.g. tagmanager/makefile.win32 > -> tagmanager/ctags/makefile.win32. So all I had to do was make my CFLAG > changes to the new file tagmanager/src/makefile.win32. > > I don't mind if you want to merge my branch before the release, I just > wanted to raise the issue. Or shall I merge it now? No you're right, it's quite large and maybe have hidden problems (although I doubt so but only testing will show off), after the release is better. And it's not something users mind about, so they won't notice either way anyway. So just push your fix to current master and we will merge the branch after the release. As you said, Git seems to be clever enough to deal with the renames anyway so it shouldn't cause too much trouble merging later anyway. And thanks for the tests and fixes :) Regards, Colomban

1 0

String freeze for Geany 1.22
by Frank Lanitz 05 Jun '12

05 Jun '12

Hi translators and friends of Geany, Time is passing by and it's time for doing a new release of Geany! To manage all translation coming in in time we are having a string freeze for upcoming Geany 1.22, which will be release around June, 18th. The list of changes done for this release is long and so a lot of string have changed or were added. I like to ask all translators to check the translations. I'd be very happy if you could send a patch, a pull request or single file with translation to either the geany-i18n mailing list or direct to me within the next two weeks so we can include it to the next release. Deadline will be 2012-06-15. To make it more easy for you I've already uploaded updated versions of the po files (and now this is new) to git master at github. You can either download the direct via web or by cloning the repository from https://github.com/geany/geany This can be done e.g. with git clone https://github.com/geany/geany.git Also at http://i18n.geany.org/ are statistics and daily updated files available. As mentioned before, we are trying to have all translations complete by 2012-06-15. If your language was translated by two or more in past, please double check directly with them or by pinging me, so we don't need to translate same things two or three times. Also please feel to ping me for every question or if you like to start a new translation for an unsupported language. Thanks and happy translating ;) Frank P.S. As we are used to on previous releases also the combined geany-plugins project will have a new stable release. Its currently scheduled two weeks after Geany 1.22 with a string freeze around release date of Geany. If you like to provide also some translation for, it would be much appreciated. ;) -- http://frank.uvena.de/en/

2 1

GLib 2.32 and debug messages
by Colomban Wendling 04 Jun '12

04 Jun '12

Hi guys, Since GLib 2.32, log messages at levels INFO or DEBUG aren't output unless G_MESSAGES_DEBUG environment variable is set to either "all" or to include the domain the message comes from [1]. The problem is that it breaks our `-v` option, since we simply turns on outputting INFO-level messages. So, we need a fix or a workaround, something. I see 2 solutions: 1) simply `g_setenv("G_MESSAGES_DEBUG", "all", TRUE)` when given `-v` (e.g. around main.c:131, `if (app->debug_mode) g_setenv(...`) 2) output everything ourselves in `handler_log()` (log.c:115) rather than calling GLib's default handler. The simplest fix is of course 1. Not sure which one is the better though. Anyway, I think we need to do something about this soon. Thoughts? Cheers, Colomban [1] http://developer.gnome.org/glib/unstable/glib-Message-Logging.html#g-log-de… PS: BTW, if I read the `handler_log()` correctly, we block *all* messages when not in debug mode? I mean, warnings, criticals and everything. Do we really want that?

2 3

Selection and colour schemes
by Lex Trotman 04 Jun '12

04 Jun '12

Hi All, I just pushed a "fix" for switching colour schemes from say dark to default leaving selection unchanged. But in reality the code at highlighting.c doesn't actually do what it advertises, the comment says "to override default" which matches the documentation, but in fact what the code does is "to change from what is currently set". Of course if you are changing from default to another colour scheme thats ok, but if you are changing from a colour scheme that has changed this setting then what is set won't be default. I think the code should be: if (common_style_set.styling[GCS_SELECTION].bold) SSM(sci, SCI_SETSELFORE, etc... else SSM(sci, SCI_SETSELFORE, whatever the default is) but I can't find where to get the real default value and have run out of time. Any thoughts or suggestions? Cheers Lex

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

Devel June 2012