Re: [Geany-Devel] Proposal: move tag type ctags-geany mapping out of individual parsers

[Jiří Techet]

On Fri, Nov 7, 2014 at 7:20 PM, Nick Treleaven
nick.trelea...@btinternet.com wrote:
 On 07/11/2014 17:26, Colomban Wendling wrote:

 Yep, I was thinking the same a few days ago while discussing a little
 CTags shared library, and had the same idea


 +1


Good, if there's an agreement here, I can have a look at it. But I'll
wait until some of my TM patches get merged. There are a bit too many
of them floating around and I'm slightly getting lost in all of my
branches.

Another thing I have noticed is that it would be good to make
sTagEntryInfo as close to ctags as possible - for instance, the
signature member in Geany is called argList in ctags and
seekPosition is unused and not present in ctags.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Proposal: move tag type ctags-geany mapping out of individual parsers

[Jiří Techet]

On Sat, Nov 8, 2014 at 7:30 PM, Colomban Wendling
lists@herbesfolles.org wrote:

 I did the easy removals/renames in
 https://github.com/b4n/geany/commits/ctags-tag-entry (that's on top of
 TM branch, but easy to change or pick up specific commits) to see how
 easy it'd be -- and this part was trivial.


Yes, it was these easy to do renames I had in mind. Regarding the hard
to do ones, I don't know, I'm not that familiar with ctags - it would
be best to get both in sync - either by changing Geany-ctags or
fishman-ctags.

Cheers,
Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] suggestion: Renaming GProject to ProjectTree

[Jiří Techet]

Hi,

I've just pushed quite a few changes to my GProject plugin
(unfortunately in a single commit because I was making these changes
while working on the tag manager and it was too painful to rebase
multiple commits every time I changed the Geany API). If there are
some problems, please let me know.

Before announcing the changes on the users mailing list, there's one
more change I'd like to make - make the plugin name a little more
descriptive so it's easier to find by users who are looking for a
plugin which displays a file tree in the sidebar. For this reason I'd
like to rename the plugin to ProjectTree.

Please let me know if you have a better idea for the plugin name or if
you think renaming the plugin isn't a good idea.

Thanks,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] suggestion: Renaming GProject to ProjectTree

[Jiří Techet]

On Sat, Dec 13, 2014 at 9:19 PM, Matthew Brush mbr...@codebrainz.ca wrote:
 On 14-12-11 12:32 PM, Jiří Techet wrote:

 Hi,

 I've just pushed quite a few changes to my GProject plugin
 (unfortunately in a single commit because I was making these changes
 while working on the tag manager and it was too painful to rebase
 multiple commits every time I changed the Geany API). If there are
 some problems, please let me know.

 Before announcing the changes on the users mailing list, there's one
 more change I'd like to make - make the plugin name a little more
 descriptive so it's easier to find by users who are looking for a
 plugin which displays a file tree in the sidebar. For this reason I'd
 like to rename the plugin to ProjectTree.

 Please let me know if you have a better idea for the plugin name or if
 you think renaming the plugin isn't a good idea.


 ProjectTree only covers one part of the plugin. What about
 FilteredFileListAndAutoTagger? Or something like that, but shorter :)


Yeah, sounds really great :-). In fact, it should be
FilteredProjectFileTreeAndFileIndexerAndFileSearcherAndHeaderSourceSwapper,
in short FPFTAFIAFSAHSS - unfortunately the first is absurdly long and
the second isn't very descriptive.

I wanted to use the ProjectTree name because one of the questions at
Prague Linux Days was something like I like Geany but I miss the
project file tree in the sidebar and my plugin is an answer to this
(I think quite common) question.

 P.S. I found a bug in GProject where it keeps adding more and more tabs to
 the project dialog. If the GitHub Issues gets turned on for Geany-Plugins
 I'll open a bug report, if it's not fixed yet.

Ugh, I'm not aware of this one - how can I reproduce it? (Maybe try
the latest version from geany-plugins first, there have been many
changes.)

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] suggestion: Renaming GProject to ProjectTree

[Jiří Techet]

On Sun, Dec 14, 2014 at 4:00 PM, Martin Andrews
martin.andr...@redcatlabs.com wrote:
 If people really love the name ProjectTree for the former GProject,
 I'd be happy enough (but for the pain of renaming a bunch of stuff...)
 to rename my plugin ProjectOrganizer or something that doesn't
 conflict.

ProjectOrganizer could actually be a nice name for my plugin as well
since the plugin does some other things (so organizer =
FilteredProjectFileTreeAndFileIndexerAndFileSearcherAndHeaderSourceSwapper).
So if you like the ProjectTree name better for your plugin, just use
it and I can go with the other.


 All the Best
 Martin :-)

 PS: Before I set off to write my own plugin, I looked carefully at the
 options out there, and GProject certainly does a lot.  However, it
 didn't meet my basic requirement of being able to organize project
 files according to purpose - it (and others) wanted to always diagram
 files according to the file system layout (which is normally
 semi-predefined by a build tool).

This is something I did on purpose in my plugin because I made it
primarily for big projects and it's almost impossible to manually
organize thousands of files (and keep them organized while other team
members add/remove/rename files). In my opinion, the file system is
where the files should be organized properly and there shouldn't be
any need to map one file tree to another.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] suggestion: Renaming GProject to ProjectTree

[Jiří Techet]

On Mon, Dec 15, 2014 at 7:44 AM, Martin Andrews
martin.andr...@redcatlabs.com wrote:
 ProjectOrganizer could actually be a nice name for my plugin as well

 Great!

Good, I have created a pull request here renaming GProject to ProjectOrganizer:

https://github.com/geany/geany-plugins/pull/178

I hope I changed all that should have been changed and haven't
forgotten about anything. Regarding *.po files, I just replaced the
old paths in them with new paths using sed but haven't done anything
else. Is it OK to merge or do you see any problems?

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Spawn module API

[Jiří Techet]

On Fri, Jun 26, 2015 at 3:31 AM, Lex Trotman ele...@gmail.com wrote:


 There is also a custom spawn in geanyctags, I didn't look at what it
 did differently.


There isn't - I'm using utils_spawn_sync() inside the spawn_cmd() function.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Profiling Geany with gperftools

[Jiří Techet]

Hi,

as the ctags guys were interested how I profiled some performance issue in
the Python parser, I thought it would be a good idea to write a wiki page
about it because the outputs are very useful for locating various
performance issues. I put it here:

https://wiki.geany.org/howtos/profiling/gperftools

Comments/suggestions are welcome.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Move question from Scintilla list

[Jiří Techet]

On Fri, Jun 26, 2015 at 11:40 AM, Lex Trotman ele...@gmail.com wrote:

 Jiri,

 I have pasted the questions and Neils answers below with my comments
 and I'm sure others may have more info.

  Jiří Techet:
 
   I have a question regarding the use of SCI_COLOURISE. It is used in
 Geany at several places and it's call is rather expensive so I'd like to
 avoid it as much as possible.
 
  Most of the time all of the buffer you see should be styled
 automatically by Scintilla in a lazy way. That means that Scintilla does
 not normally style much beyond the portion currently visible. There are
 times when you want the whole file to be styled, such as when exporting the
 file as HTML/PDF/RTF. There may also be workarounds to problems in
 Scintilla and its possible some of these workarounds are no longer needed.
 
   1. After SCI_SETKEYWORDS - this basically happens after every
 keystroke because we colorize typenames using keywords (we've already
 talked about that if you remember).
 
 Possibly Geany wants the document styled up to some point immediately
 so it can use the style information.

 As best I can tell this one is extraneous, it would just change names
 from/to type colourising which AFAICT doesn't affect anything else,
 they are both code type styles etc.  So long as the visible area is
 colorised by Scintilla so when a newly typed name matches a keyword it
 will highlight, then it doesn't look like doing it manually is useful.


This is the main use of SCI_SETTEXT I was interested in and yes, I also
think this one can be (safely) removed. It isn't called already by
languages not highlighting typenames like e.g. python so there's very
little risk that anything breaks by removing it because it would have
already been broken for all the scripting languages.



 
   2. Immediately after SCI_SETTEXT when loading (or reloading) file.
 
 This may or may not be needed depending on Geany’s features. One
 reason for doing this is if you want to perform a global fold operation
 since folding depends on fold information and thus on styling.

 This one is more likely useful, since lots of features need to know
 the styles of things outside the visible area, for example to avoid
 considering characters in comments and strings when counting braces
 for scopes.


Yes, this one should probably stay. But I would delay it's call until the
document is actually shown to improve Geany start time with many tabs open.

For completeness, there was also another case in my original email:

3. When reloading configuration files which can change various aspects of
Scintilla (keywords, style coloring, etc.)

but since this one is called only when changing config files, it's not
worth worrying about.

(plus one more use in brace_match() but it's a single-character one and
doesn't matter either)

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Move question from Scintilla list

[Jiří Techet]

On Fri, Jun 26, 2015 at 1:21 PM, Jiří Techet tec...@gmail.com wrote:


 
   2. Immediately after SCI_SETTEXT when loading (or reloading) file.
 
 This may or may not be needed depending on Geany’s features. One
 reason for doing this is if you want to perform a global fold operation
 since folding depends on fold information and thus on styling.

 This one is more likely useful, since lots of features need to know
 the styles of things outside the visible area, for example to avoid
 considering characters in comments and strings when counting braces
 for scopes.


 Yes, this one should probably stay.


OK, just checked and things like fold all don't work without it so it
definitely needs to stay.


 But I would delay it's call until the document is actually shown to
 improve Geany start time with many tabs open.


Should have checked before I wrote anything - this is already the case now
so no change needed in this respect.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Windows installer snapshots with GTK 2.24

[Jiří Techet]

On Sat, Jun 27, 2015 at 1:09 AM, Enrico Tröger enrico.troe...@uvena.de
wrote:

 Hi,

 I've built new Windows installers from current GIT master.


 Downloads can be found here:
 http://download.geany.org/snapshots/


 Please note that these are test builds from the current development
 version, don't expect release quality.
 You have been warned :).

 After you installed the snapshots, you can also use the nightly
 builds again on Windows (i.e. copy the archive contents over the
 installation).


 Any feedback is welcome.



Hi Enrico,

seems to be working fine here.

One idea: wouldn't it be good to package the grep binary to the installer
(and if possible somehow set the preferences to the location where it was
installed) so find in files works out of the box? Right now the message you
get when trying to use find in files is:

 search_find_in_files: spawn_with_callbacks() failed: CreateProcess()
failed: The system cannot find the file specified.

which isn't the most user-friendly message and I guess many people will
interpret it as find in files doesn't work on Windows.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Windows installer snapshots with GTK 2.24

[Jiří Techet]

On Sat, Jun 27, 2015 at 1:09 AM, Enrico Tröger enrico.troe...@uvena.de
wrote:

 Hi,

 I've built new Windows installers from current GIT master.


 Downloads can be found here:
 http://download.geany.org/snapshots/


 Please note that these are test builds from the current development
 version, don't expect release quality.
 You have been warned :).

 After you installed the snapshots, you can also use the nightly
 builds again on Windows (i.e. copy the archive contents over the
 installation).


 Any feedback is welcome.


One more minor thing I have noticed is there are some themes included in
the installer but some from geany-themes are missing so you might want to
update them.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins

[Jiří Techet]

On Sun, May 31, 2015 at 10:57 AM, Colomban Wendling 
lists@herbesfolles.org wrote:

 Le 31/05/2015 07:41, Lex Trotman a écrit :
  On 31 May 2015 at 11:46, Lex Trotman ele...@gmail.com wrote:
  On 31 May 2015 at 08:05, Thomas Martitz ku...@rockbox.org wrote:
  Am 30.05.2015 um 03:19 schrieb Matthew Brush:
 
 
  Just because it's such a trivial search algorithm, using strstr() is
 much
  more simple and probably more efficient than using Scintilla's API to
 find
  text, […]
 
  So its almost certainly slower than strstr().
 
  And on my system strstr() is a builtin that can use any hardware
  support available.

 One thing that will make strstr() sound a lot less sexy is that you
 probably actually want to find *words* rather than substrings.  Meaning
 that if the word under the cursor is i, you probably don't want to
 highlight all is in e.g. an identifier highlighting, but only whole
 words.  And while Scintilla search has the logic for this
 (SCFIND_WHOLEWORD), it'd probably be annoying/redundant to re-do with
 the same logic.

 Apart that, yes, strstr() from an optimized libc like glibc will be hard
 to beat without also using very smart optimization combined with use of
 specialized CPU instruction sets.

 Cheers,
 Colomban


Just to clarify, when I mentioned strstr(), I meant it as an example of
using some existing implementation (instead of creating something new)
rather than suggesting strstr() is the best one. If there's something in
Scintilla which would make it easier to implement this feature, just go for
it. If there's some performance problem, it can always be improved
afterwards (but I don't think there will be any).

Regards,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] pull request on GitHub, to add GeanyHighlightSelectedWords, into Geany Plugins

[Jiří Techet]

On Fri, May 29, 2015 at 1:25 AM, Matthew Brush mbr...@codebrainz.ca wrote:


 Ideally you could improve the underlying implementation of an existing one
 if your way is better[0] and they perform the same function. It's really
 confusing for users to figure out what is the right plugin when there's
 too many doing the same thing. The same thing happens with GeanyGDB,
 Debugger, and Scope right now.

 That being said, showing occurrences of the word is such a common and
 fairly useful feature for an IDE, I'd personally rather see the 3-4
 existing plugins obsoleted by a good implementation in core Geany[1].

 Cheers,
 Matthew Brush


+1 on having it directly in Geany.

And IMO, the simplest possible implementation should be used - i.e. using
just strstr() for finding the names and highlighting the whole editor and
not just the visible part and redoing this when scrolling.

KMP is quite an overkill in this case - it would be useful only if

1. The text to locate would be long (which isn't the case because
function/variable names are quite short)
2. The searched text would contain many prefixes from the text to locate
(again not the case - variables/functions can have common prefix but
typically there will be at most one per line and not like every second
character). Most of the time strstr() will find different characters at the
first position and advance to the next character.

If you consider what we are doing when the document changes - i.e. parsing
the document twice, once by scintilla lexer, once by ctags parser - and
this happens on the main thread and nobody notices it, then the search part
in the highlighting will be almost for free.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Windows installer snapshots with GTK 2.24

[Jiří Techet]

On Sun, Jun 28, 2015 at 11:53 AM, Enrico Tröger enrico.troe...@uvena.de
wrote:

 Hi Jiří,

  I've built new Windows installers from current GIT master.
 
  [..]
 
 
  Any feedback is welcome.
 
 
 
  Hi Enrico,
 
  seems to be working fine here.
 
  One idea: wouldn't it be good to package the grep binary to the installer
  (and if possible somehow set the preferences to the location where it was
  installed) so find in files works out of the box? Right now the message
 you
  get when trying to use find in files is:

 great idea!
 Will be included in the next installer, it's just 79kB.
 Luckily, and if I don't miss anything, we don't need to set any paths
 because the default path for grep is just grep and when grep.exe is in
 the bin/ directory next to Geany.exe, it should work out of the box.


Just tried the latest installer and works great, thanks! Cool it wasn't
necessary to modify the config file when installing.




   search_find_in_files: spawn_with_callbacks() failed: CreateProcess()
  failed: The system cannot find the file specified.
 
  which isn't the most user-friendly message and I guess many people will
  interpret it as find in files doesn't work on Windows.

 True. I guess we can improve the error message but maybe better after
 1.25 to not bother the translators too much by breaking the string
 freeze :).


I have just created a bug report here

https://github.com/geany/geany/issues/541

It can wait for the next release especially as grep works now.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Simplifying file saving options

[Jiří Techet]

Hi,

after some time spent debugging

https://github.com/geany/geany/issues/605

I think the file saving options are a bit confusing and misleading and
should be simplified.

1. Both g_file_set_contents() and g_file_replace_contents() do absolutely
the same thing (saving to temporary file, then renaming the file), the only
difference is the first uses POSIX calls while the second GIO. The
use_gio_unsafe_file_saving name is very confusing because it's not unsafe
in any way.

2. It is now possible to set

use_gio_unsafe_file_saving=true
use_atomic_file_saving=true

and to users it's unclear which of the options will be actually used (it's
the use_atomic_file_saving case because it's checked first in the code).

3. The fallback ordinary file saving when

use_gio_unsafe_file_saving=false
use_atomic_file_saving=false

doesn't bring any benefit compared to the two above - it's similar to
use_atomic_file_saving=true in using POSIX calls, it's just a bit less safe
because it writes directly to the file without the renaming. The GIO
g_file_replace_contents() recreates the file's permissions/ownership
correctly in

https://github.com/GNOME/glib/blob/master/gio/glocalfileoutputstream.c#L734


I would suggest removing the file saving option mentioned in (3) above and
have just a single settings option like

use_gio_file_operations

Opinions?

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Geany-Users] Geany-Plugins website down because of issue at sf

[Jiří Techet]

On Mon, Jul 20, 2015 at 11:19 AM, Lex Trotman ele...@gmail.com wrote:

 Move plugins.geany.org to github pages. https://pages.github.com/
 Attaches right to the repositories where the site source is.


Or to the geany server - what matters is just to be far away from SF
wherever it is...

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Geany-Users] [ANN] Geany 1.25 is out!

[Jiří Techet]

On Sun, Jul 12, 2015 at 11:59 PM, Russell Dickenson 
russelldicken...@gmail.com wrote:

 Congratulations to everyone involved with Geany's development and
 ongoing support. Fantastic work! I love the idea of time-based
 releases, though I would have thought you would choose 6-monthly
 instead of 4-monthly sprints.

 Thank you to Jiří Techet for the OSX build as it looks fantastic and
 works well. A colleague who uses OSX and Linux was recently frustrated
 with trying to find a suitable text editor for OSX, given his love for
 Geany. The advent of the OSX build solved his problem immediately.


Good to hear you find it useful! Let me know if you run into some OS X
specific problems. There are a few GTK-related quirks which would require
patching GTK and which I probably won't fix but things which are inside
Geany itself should be fixable quite easily.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Geany-Users] Geany-Plugins website down because of issue at sf

[Jiří Techet]

On Tue, Jul 21, 2015 at 6:58 AM, Lex Trotman ele...@gmail.com wrote:

 If its gonna be hosted on Geany projects server it needs to be HTTPS
 and that means getting a real certificate accepted by browsers.


HTTPS isn't used for Geany tarballs or binaries from

http://www.geany.org/Download/Releases

so it doesn't have to be used for the plugins either (may be a nice-to-have
but not required IMO).

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Geany-Users] [ANN] Geany 1.26 is out!

[Jiří Techet]

On Sun, Nov 15, 2015 at 2:35 PM, Colomban Wendling <colom...@geany.org>
wrote:

> We are happy to announce a new release of Geany!
>
> For a comprehensive list of changes please see:
> http://www.geany.org/Documentation/ReleaseNotes
>
> Some highlights:
>
>  * New plugin API (Thomas Martitz).
>  * Add support for "proxy" plugins (Thomas Martitz).
>  * Fix spurious "source file has been modified" messages (Jiří Techet).
>  * Update Scintilla to version 3.6.1.
>  * Keeping undo history when reloading files is now enabled by default.
>  * Restore modern design of native file dialogs under Windows.
>  * Update translations: de, el, es, fr, hu, id, kk, pt, sk, sv, ru.
>
> We want to thank all developers, translators and everyone who
> contributed to this release with patches, feedback, bug reports and so
> on.  Thank you!
>
> As usual, all downloads can be found on
> http://www.geany.org/Download/Releases.
>

For those interested, I've just uploaded the OS X binaries here:

http://download.geany.org/geany-1.26_osx.dmg

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [RFC]: No force push policy on Github PRs

[Jiří Techet]

On Wed, Jul 8, 2015 at 5:47 AM, Matthew Brush mbr...@codebrainz.ca wrote:


  I propose that we disallow force pushing, rebasing, squashing, etc.
 on any PR until it is fully ready for final merging. […] ready for
 merging. At that point it _might_ make sense to fudge history and get
 rid of some noisy fixup commits[0].


The question is how to detect the fully ready for final merging moment.
For my patches the workflow typically looks like

1. I submit a patch
2. Colomban reviews it
3. I repush the patch with fixes
4. Colomban merges it

I kind of implicitly assume that after (3) the patch will be ready for
merging (and it typically is) so I do the force push but of course there
may be further comments.

For bigger patch sets one should choose what seems to be most practical.
For instance for

https://github.com/geany/geany/pull/488

where there were many commits and also review comments I decided to create
a separate pull request containing the fixes

https://github.com/geany/geany/pull/505

to preserve the comments in the original pull request. In this case adding
fix commits would make things too messy.

So personally I wouldn't carve any rules in stone and would decide case to
case. For bigger patches with many review comments it's probably best to
ask the reviewer which way he prefers to have the fixes committed.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Devel Digest, Vol 93, Issue 3

[Jiří Techet]

Hi Per,

I have written some notes below how Djynn's project management differs from
ProjectOrganizer and some rationale for why I went that way. In my opinion
the core functionality is quite similar.

On Wed, Dec 16, 2015 at 4:09 PM, Per Löwgren  wrote:

> Hello,
>
> I reply to all of your posts in one message. Hope that's ok.
>
> Basically, the terminology Djynn use is:
> * workspace: a set of projects
>

There's nothing like that in ProjectOrganizer - as I didn't want to
duplicate functionality which is already in Geany, I just kept things
simple in this respect so switching between projects is done using Geany's
standard project opening functionality and recent projects. Maybe we could
increase the number of the shown recent projects so it's easier to open
projects for people with many projects.


> * project: a set of files, organised into a directory tree, that may or
> may not be opened
>

This is the same in ProjectOrganizer. Moreover, ProjectOrganizer stores its
config into the standard Geany project file so there's a single project
file. I believe there are two project files in your case the Djynn one and
the Geany one and this "two-project" thing makes things a bit confusing for
users. Did you know you can store your config options into the Geany
project file using the API?


> * session: a set of opened documents in the editor
>

This is how it's in Geany too, there's just a single session per project -
on project opening your previous session is restored.


>
> In Geany, a project is the configuration of the project, including editing
> and building.
>

Since ProjectOrganizer is an extension of Geany project, there's no
distinction between Geany project and ProjectOrganizer project - they are
one.


In answer to your question: The session manager; it switches between
> sessions, and stores many sessions. When switching between sessions, all
> opened documents are stored in the present session's file; then all opened
> documents are closed; then the documents in the next session are opened.
>

ProjectOrganizer does basically nothing with sessions and uses Geany's
session management.


>
>
> > Sounds like reasonable usage, I think you can just open Geany pull
> request
> > to make these public. To make a function public, you just need to:
> >
> > 1. Prefix the implementation with GEANY_API_SYMBOL.
> > 2. Add some user-visible API documentation with a docstring (see other
> API
> > functions in the code to have an idea how it should look)
> > 3. Move the function declarations above GEANY_PRIVATE in the header.
> >
> > That's about it.
>
> That would work on my computer, but not on Launchpad, or for anyone else.
>

Here I meant you could make a pull request to Geany so it can be merged to
Geany and available for everyone in the next release.

The Project Organizer is an interesting plugin, they are similar, but works
> very differently.
>

I don't think it's so different, IMO the only big extra things in Djynn are
the workspace management and session management.

If we can agree on a common "vision", I'd happily contribute to that.
>

I can describe the vision of PorjectOrganizer. What I tried to make was a
file-aware Geany project (Geany itself doesn't know about the files, it
just stores base directory, build options and some common settings for
project) in a minimalistic way and reuse as much as possible from Geany
itself without duplicating functionality.


> Djynn has regex pattern add files on a per directory basis, i.e. you can
> add a directory and tell to search files according to pattern, and recurse
> into subfolders,
>

There's a single glob file pattern list per project in ProjectOrganizer
defined in project properties. The advantage of a glob pattern over regex
is that Geany uses it too and it can be passed to the Find in Files dialog
so a pattern defined at a single place in the project config is used for
everything.

but you can still have fixed files added too; e.g. you can add files from
> the project source directory, and also add `~/.config/project/file.conf`
> etc.
>

You can attach an arbitrary number of "external directories" to a project
in ProjectOrganizer and have their files displayed in the sidebar (and get
them indexed with the tag manager if needed). It's just not per file but
per directory.

To sum up the differences:

* Djynn can have multiple workspaces, ProjectOrganizer just uses Geany's
single "workspace" (basically the "recent projects" list).

For me this is sufficient, I find the workspace concept a bit too
heavyweight for an editor like Geany. Switching between recent projects
using Geany's built-in functionality is nice and simple.

However, if the project open/close methods are added to the API, some
workspace manager plugin could be made and it could even coexist with the
ProjectOrganizer plugin.

* ProjectOrganizer's project has a single session (like Geany) while Djynn
can have multiple.

I don't know if I'd ever use more sessions 

Re: [Geany-Devel] Devel Digest, Vol 93, Issue 2

[Jiří Techet]

Hi Per,

On Tue, Dec 15, 2015 at 1:49 PM, Per Löwgren  wrote:

>
>
> > Hi,
> >
> > The API has been fixed to not leak symbols, which it did for a few
> > recent versions. The only functions that are public, which is how it's
> > always been, are those documented in the API reference[0]. That you were
> > able to compile and link against private symbols was a bug in Geany. If
> > you need those functions though, they can likely be added to the public
> > API with a pull request.
> >
> > Cheers,
> > Matthew Brush
> >
> >
> > [0]: http://www.geany.org/manual/reference/
>
>
> Hello Matthew,
>
> Apparently filetypes_detect_from_document isn't needed since an instance
> of GeanyFiletype is a member of GeanyDocument, I just noticed, so that
> solved itself.
>

If needed, you can also use filetypes_detect_from_file() which is public.


>
> I can probably find an alternative workaround for document_close_all, e.g.
> iterate document_index(0) until it returns NULL, and call document_close;
> so I think should be ok too.
>

Yep, it should be pretty easy to do this manually so the question is
whether extra API is needed.


> The project functions however, since Djynn is meant to integrate with the
> internal Geany project manager, with functions for opening and closing
> projects. I believe Geany would be enhanced by the possibility for plugins
> to open and close projects. When creating a Djynn-project a Geany-project
> is generated automatically, and when opening and closing Djynn-projects,
> the Geany-projects are opened and closed too. It's been working very well,
> seamlessly and invisibly, and would be a loss if I had to cut out the
> Geany-project integration.
>

Sounds like reasonable usage, I think you can just open Geany pull request
to make these public. To make a function public, you just need to:

1. Prefix the implementation with GEANY_API_SYMBOL.
2. Add some user-visible API documentation with a docstring (see other API
functions in the code to have an idea how it should look)
3. Move the function declarations above GEANY_PRIVATE in the header.

That's about it.


>
> When I began working with Djynn, I actually only wanted a tree-view of the
> project files for my projects. Since I'm working on many projects I needed
> quick access to files from the various projects without having to find them
> with Thunar (it's my preferred file manager). Then merging projects with
> Geany was the natural next step.
>
> I'm not sure if anyone but me is really using my plugin, it's only
> designed for my personal needs, but I'd really be happy if anyone else had
> use for it as well.
>
> Anyway, I'm sure document_close_all could be used by many plugins, but
> filetypes_detect_from_document is not needed. The project functions would
> be much appreciated. That's all on my xmas wishlist :)
>

As it usually works, the best presents have to come from yourself, there
will be just socks and pyjamas under the Christmas tree :-).

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Devel Digest, Vol 93, Issue 2

[Jiří Techet]

On Tue, Dec 15, 2015 at 2:35 PM, Colomban Wendling <
lists@herbesfolles.org> wrote:

> Hi,
>
> >> […]
> >>
> >> The API has been fixed to not leak symbols, which it did for a few
> >> recent versions. The only functions that are public, which is how it's
> >> always been, are those documented in the API reference[0]. That you were
> >> able to compile and link against private symbols was a bug in Geany.
>
> BTW, linking to private API never worked under Windows.
>
> > […]
> >
> > I can probably find an alternative workaround for document_close_all,
> > e.g. iterate document_index(0) until it returns NULL, and call
> > document_close; so I think should be ok too.
> >
> > The project functions however, since Djynn is meant to integrate with
> > the internal Geany project manager, with functions for opening and
> > closing projects. I believe Geany would be enhanced by the possibility
> > for plugins to open and close projects. When creating a Djynn-project a
> > Geany-project is generated automatically, and when opening and closing
> > Djynn-projects, the Geany-projects are opened and closed too. It's been
> > working very well, seamlessly and invisibly, and would be a loss if I
> > had to cut out the Geany-project integration.
>
> I've got what might be a stupid question, but couldn't your plugin
> integrate with Geany projects the other way around, e.g. your plugin
> reacts to project open/close rather than making Geany react to your
> plugin's project open/close?
>

If I understand the project part of the plugin (haven't tried it either),
it tries to simplify switching between projects and organizing projects
into workspaces. In the screenshot here

http://plugins.geany.org/djynn.html

it seems that the second combo serves switching between projects in a
workspace so it's the plugin which decides whether a project should be
opened/closed rather than Geany. This functionality cannot be done with
listening to the signals only so access to project_open()/close() makes
sense here.

The other thing is the plugin itself is a bit too "All the stuff I need in
Geany" and it would be better break the functionality into individual
plugins, or extending existing plugins or adding the functionality directly
to Geany.

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Zombified pull requests

[Jiří Techet]

Hi Lex,

On Wed, Jan 6, 2016 at 4:12 AM, Lex Trotman <ele...@gmail.com> wrote:

> Hi Jiri,
>
> Its a worthwhile thing to talk about. Some specific comments below,
> but first a couple of general ones.
>
> I occasionally talk to some of the Geany devs/contributors in other
> forums and its clear that at this moment Geany isn't their primary
> focus.  That is my situation, which is why I concentrate on ML and
> issue replies, they only take a few minutes at a time, suitable for a
> break from my other activities, but not a significant time usage.  And
> hopefully that saves other devs and contributors from spending time on
> initial obvious errors and omissions in reports.
>

This is clear and I understand completely people don't have that much time
for Geany (myself included). I wasn't actually talking about the time it
takes to get a patch reviewed (which can be longer because people don't
have time for Geany, but this is fine) but rather the pull requests that
seem to be "done" but they are just unmerged.


>
> Note that if I didn't use the latest Git version of Geany for day to
> day work I would almost never test it, so testing PRs means including
> them into the Geany I am using for my other work, which I consider
> risky if I don't know the contributor or the PR is big, so I don't
> test them much.  Primary contributors or devs PRs only.
>
> But I will stop using the latest for day to day work if it becomes
> unreliable, so I depend on all patches being inspected and tested
> before commit.  And by test I don't mean 5 minutes tick and flick, but
> *used* for some time, lets say at least a week.  So PRs for
> features/languages I don't use won't get tested either. Colombans #852
> is an example at the moment, have incorporated it and if it works fine
> for a week I'll commit it.
>

I'm definitely not suggesting to make master a collection of crappy and
crashing code. But IMO if both the patch author and reviewer tried the code
and it doesn't seem to cause any problem and if the patch was reviewed, I
think it receives the best field testing in master. Everyone uses Geany in
a different way and the reviewer won't probably notice a problem that
happens only under some special occasion anyway.

Matthew nicely called the current situation as "too high standards" - I
feel Colomban set such a high bar with his great code reviews that everyone
else is scared to review the code and all the work is left on Colomban.


>
> And since I am not testing PRs much, I am not in a position to commit them
> much.
>
> But not many people other than committers seem to review/test patches.
> It should not be just up to the committers to review and test PRs.  If
> there were more people doing that, then there is less pressure on
> committers to be responsible for the whole thing.  A cheery comment "I
> like this and have been using it for the last month on system XXX with
> no problems" will go a long way to getting stuff committed.
>
> What I do on Asciidoc for PRs that I can't/won't test, is to require
> at least one person, other than the proposer, to acknowledge
> usefulness, and to report tested ok in actual use.  Then I will commit
> it, without trying it myself (Colomban spins in his bed :).  Of course
> if a recommender turns out to be unreliable then they will be
> subsequently ignored, but I haven't had any problems to date.
>
> I suspect many of the comments above apply to other devs/contributors as
> well.
>
> On 6 January 2016 at 06:46, Jiří Techet <tec...@gmail.com> wrote:
> > Hi,
> >
> > happy new year and let's celebrate it with something cheerful - zombies!
>
> :)
>
> >
> > I've noticed there are more and more pull requests on github which don't
> get
> > merged to Geany. It's clear that people are fighting with time to make
> > reviews of pull requests (and Colomban does a great job here!), however,
> it
> > seems to me there are quite many patches where all the hard work has
> already
> > been done (review, patch updates) and the only missing thing is the
> merge -
> > which doesn't happen.
> >
> > I think this is quite unfortunate - there are many patches which might be
> > useful for users; at the same time it might be discouraging for
> contributors
> > to see their patches unmerged.
> >
> > I've been thinking about what may be the cause of this and several things
> > come to my mind:
> >
> > 1. Not enough feedback from other developers. Typically I am for
> instance in
> > the mode "I don't want to add too much noise" so unless I love or hate
> > something, I just don't write anything. I think Colomban's own patches
> > suffer from this most

Re: [Geany-Devel] Zombified pull requests

[Jiří Techet]

Hi Matthew,

On Wed, Jan 6, 2016 at 4:32 AM, Matthew Brush <mbr...@codebrainz.ca> wrote:

> On 2016-01-05 12:46 PM, Jiří Techet wrote:
>
>> Hi,
>>
>> happy new year and let's celebrate it with something cheerful - zombies!
>>
>>
> Wouldn't they only be zombies if we closed them and they re-opened
> themselves? :)


Ah, right, I wasn't fully aware of the zombie lifecycle :-).


>
>
> I've noticed there are more and more pull requests on github which don't
>> get merged to Geany. It's clear that people are fighting with time to make
>> reviews of pull requests (and Colomban does a great job here!), however,
>> it
>> seems to me there are quite many patches where all the hard work has
>> already been done (review, patch updates) and the only missing thing is
>> the
>> merge - which doesn't happen.
>>
>> I think this is quite unfortunate - there are many patches which might be
>> useful for users; at the same time it might be discouraging for
>> contributors to see their patches unmerged.
>>
>> I've been thinking about what may be the cause of this and several things
>> come to my mind:
>>
>> 1. Not enough feedback from other developers. Typically I am for instance
>> in the mode "I don't want to add too much noise" so unless I love or hate
>> something, I just don't write anything. I think Colomban's own patches
>> suffer from this most as he reviews other people's patches but there's no
>> feedback for his own patches.
>>
>> Maybe it would be a good idea if regular Geany contributors go through the
>> pull requests from time to time and just LGTM those that sound reasonable
>> functionality-wise. I'm not talking about full code review here, just a
>> very quick assessment whether the given feature makes sense for Geany (we
>> should distinguish somehow "I made a review of the patch and LGTM" and
>> "the
>> functionality LTGM to be in Geany").
>>
>>
> Agree, I sometimes avoid putting LGTM when I think something is a good
> idea, because I don't want to give the impression that I have (or even
> will) reviewed or tested it. Maybe just a "thumbs up" could mean "good
> idea, though I haven't reviewed or tested it"?


Yeah, sounds better than LGBI's :-)


>
>
> To give an example of such a "functionality review", the fractional font
>> sizes patch
>>
>> https://github.com/geany/geany/pull/407
>>
>> LGTM - even though I probably won't use it myself, I understand it may be
>> useful for someone and it modifies just 23 lines so it's nothing intrusive
>> and can go in from my point of view.
>>
>>
> Agree, and I've actually wanted for this before.
>
> Such a review can be done in a few seconds so if everyone goes through the
>> new pull requests from time to time, the patches will receive some
>> feedback
>> and it will be clearer whether it's something others want it in Geany.
>>
>> 2. Unclear status of some patches. Sometimes it might not be clear in what
>> state the pull request is - I'd suggest adding at least the following two
>> tags:
>>
>> needs-work (reviewed with some comments that need to be addressed)
>> work-in-progress (not meant for review in the current state)
>>
>> This will help to distinguish pull requests awaiting merge and pull
>> requests that aren't there yet.
>>
>>
> Sounds like a good idea, I just added those labels. We also already have
> "reviewed", which I believe means whoever added the label has fully
> reviewed a PR and it's ready to be merged.
>
> 3. Fear that the pull request isn't tested enough. I believe that if a
>> patch did undergo a review and there doesn't seem anything obviously wrong
>> with it, it can be merged to master. I think there's no need for some
>> long-term private testing of a patch before it gets merged - people using
>> the development versions of Geany should be aware it may contain bugs and
>> should know how to deal with them. There are also more eyes so a potential
>> bug is spotted earlier. Of course it makes sense getting more conservative
>> towards the end of the development cycle to stabilise things.
>>
>>
> This is a big one too. Since we don't have a "development" branch (or
> rather "master" is the development branch), we often have too high
> standards, only merging stuff that is 100% finished, debugged and ready to
> release. This kind of defeats the purpose of a development branch.
>
> Assuming there's a general consensus that a PR is a good idea, I agree we
> should

Re: [Geany-Devel] RFC: Merge C and C++ Filetypes (no troll)

[Jiří Techet]

On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz <ku...@rockbox.org> wrote:

> Am 06.01.2016 um 21:12 schrieb Jiří Techet:
>
>>
>>
>> It's indeed at least interesting to consider, because at least for .h
>> headers there really is some mixed stuff all over the place -- even,
>> simply look in Scintilla's source tree.
>>
>>
>> +1 for having the headers parsed/lexed by the C++ parser (with sources it
>> may be a bit dangerous and typically the sources have the right C++
>> extension).
>>
>>
>>
> Not replying to Jiří specifically.
>
> -1. .h is legitimately a C, it's just that many people get it wrong. And I
> don't want C++ keywords highlighted in C headers while they are not
> highlighted it C source files. This is just confusing.
>

I agree with Matthew here - I think the "damage" caused by parsing C
headers with the C++ parser/lexer is much smaller than vice versa. Actually
a few months back a user of my ProjectOrganizer plugin wrote me just
because of that - he had a C++ project with "h" headers and was surprised
that tag generation didn't work for him.

I created (a highly sophisticated) pull request here:

https://github.com/geany/geany/pull/857

Power users can always add *.h back to C types but I think having it in C++
is a better default.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] RFC: Merge C and C++ Filetypes (no troll)

[Jiří Techet]

On Thu, Jan 7, 2016 at 11:14 PM, Lex Trotman <ele...@gmail.com> wrote:

> On 8 January 2016 at 08:00, Jiří Techet <tec...@gmail.com> wrote:
> >
> >
> > On Wed, Jan 6, 2016 at 9:23 PM, Thomas Martitz <ku...@rockbox.org>
> wrote:
> >>
> >> Am 06.01.2016 um 21:12 schrieb Jiří Techet:
> >>>
> >>>
> >>>
> >>> It's indeed at least interesting to consider, because at least for
> .h
> >>> headers there really is some mixed stuff all over the place --
> even,
> >>> simply look in Scintilla's source tree.
> >>>
> >>>
> >>> +1 for having the headers parsed/lexed by the C++ parser (with sources
> it
> >>> may be a bit dangerous and typically the sources have the right C++
> >>> extension).
> >>>
> >>>
> >>
> >> Not replying to Jiří specifically.
> >>
> >> -1. .h is legitimately a C, it's just that many people get it wrong.
> And I
> >> don't want C++ keywords highlighted in C headers while they are not
> >> highlighted it C source files. This is just confusing.
> >
> >
> > I agree with Matthew here - I think the "damage" caused by parsing C
> headers
> > with the C++ parser/lexer is much smaller than vice versa. Actually a few
> > months back a user of my ProjectOrganizer plugin wrote me just because of
> > that - he had a C++ project with "h" headers and was surprised that tag
> > generation didn't work for him.
> >
> > I created (a highly sophisticated) pull request here:
> >
> > https://github.com/geany/geany/pull/857
> >
> > Power users can always add *.h back to C types but I think having it in
> C++
> > is a better default.
>
> As the failing tests show, better have a BIG warning about breaking
> change if we do this.
>

Fixed now.

Actually the tests "failed" because the tested files were C++ headers and
the previously-generated tags files were incorrect because of the used C
parser. So yeah, BEWARE USERS, HEADERS MIGHT BE PARSED CORRECTLY :-)

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Geany-Plugins rework -- RFC

[Jiří Techet]

Hi Frank,

sorry for replying so late. The proposal looks good to me except maybe...

On Sat, Nov 21, 2015 at 2:42 PM, Frank Lanitz  wrote:

> Hi folks,
>
> Since a few releases I'm experiencing some not optimal way of
> development which is surely caused by the long history we already have
> on g-p as well as by the many people around luckily contributing to the
> plugins collection: More and more plugins are going into some kind of an
> orphaned state. There is some maintainer available but not really
> responsive e.g. due to workload at reallife etc. However, at the end
> some of the plugins are still compiling but not effectively working any
> more with recent Geany version or its documentation is really outdated
> -- when I was preparing the commits for waf removing I have seen plugins
> still depending on Geany 0.16 ... I'm pretty sure, if they would, they
> would compile any more ;)
>
> Also the documentation of each plugin are differing in style, size and
> quality much. (and I have to include the plugins I'm maintaining here
> 100% too). At github we already got a bunch of bug reports and pull
> requests for plugins waiting for any response. Also there is a long
> backlog at sf I've been told.
>
> This is what I was thinking of to improve the situation (the overall
> experience for our users)
>
> 1) Deactivating all plugins / out comment all plugins from MAINTAINERS
> 2) Cleaning off NEWS, Changelog etc. from individual plugin folders
> 3) Moving documentation of all plugins into a structure like
>doc/ to get a real fitting (online) manual. At this
>point update documentation and bring them to some markup stil (Rest?
>md? Docbook? I don't care at this point)
>

...this one - similarly to Matthew, I would also prefer having all the
stuff related to a single plugin in the plugin's directory. What's the
problem with the online manual? The build system should know the plugin
directories and be able to pick the documentation files from each of them.

Related to this it would be nice to be able to easily detach a plugin from
the geany-plugins repository so it can be e.g. developed separately between
releases. But I'm not an autotools expert and don't know whether it's
easy/possible to do.


> 4) Moving all plugins into a subfolder like plugins/ to
>clean up / of g-p a little
> 5) Reactivating plugins by a pull request of the actual (old|new)
>maintainer maybe doing steps 2-4 and comment back in the plugin in
>MAINTAINERS. Also I would be happy if at this point po/POTFILES.in
>is reviewed etc.
> 6) Release a cleaned up g-p
> 7) Post 1.27 puring not update plugins from src tree
>
> What do you think about this idea? I would combine this with some
> release goals like complete support of Geany Gtk3 stack (if applicable).
>

In my opinion things like support for Gtk3 for all plugins are out of the
scope of the geany-plugins project as a whole. If the maintainers of the
plugins not supporting Gtk3 yet don't have time to add the support and
nobody else cares enough to add it then what - remove the plugin because of
that even if it works fine with Gtk2? IMO the task of geany-plugins should
be to just know which plugins support Gtk3 and build only those which do.

For me at least geany-plugins is a kind of repository so users can find
various plugins easily and at the same time serves geany developers to make
changes to all the plugins when e.g. some API call changes. But the
individual plugins inside are the responsibility of the individual
maintainers. Of course the question is what to do if a plugin gets
unmaintained - perhaps the best is to keep it as long as it builds and
there aren't any major issues with it.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Devel Digest, Vol 93, Issue 5

[Jiří Techet]

Hi Per,

On Sat, Dec 19, 2015 at 12:43 AM, Per Löwgren  wrote:

> Hi again Jiri,
>
> It was a long meeting, continuing into dinner and drinks, but now I'm home
> and continue my reply to your message. I've turned off the digest-function,
> there should be no more delay in correspondence.
>
> First though, I'd like to say something; when we talk about differences
> between projects, I don't see that as something negative - actually the
> opposite. Differences means the projects can extend each other instead of
> being just similar. So, if PO (Project Organizer) has functionality that D
> (Djynn) does not, then that can make D better, and vice versa; should they
> somehow merge. If you see what I mean?
>

I definitely didn't want to say that PO is "better" or "done" or something
like that - sorry if it sounded that way. I just wanted to describe what
what were the ideas behind the plugin. Of course you can have a different
vision and that's perfectly fine - the two plugins can coexist.

There are basically two options what to do about the plugins:

a. Keep them separate, each doing its project management in a different
way. But in this case you should make a pull request to Geany to get the
project open/close functions public otherwise nobody will use it because it
won't compile with an official Geany release (you said you don't want to
make the pull request but I'd suggest to reconsider your decision). I
haven't for instance tried your plugin yet just because I'd have to modify
Geany first to get your plugin compiled.

b. Find some common subset of the two plugins so there would be a plugins
with a core part of the project management functionality and move the rest
to a separate plugin(s). This is what I had in my mind when replying to
your previous post but I guess our opinions about the core part are pretty
different so right now (a) seems like a better option to me.


> > I can describe the vision of PorjectOrganizer. What I tried to make was a
> > file-aware Geany project (Geany itself doesn't know about the files, it
> > just stores base directory, build options and some common settings for
> > project) in a minimalistic way and reuse as much as possible from Geany
> > itself without duplicating functionality.
>
> Yes, we think the same in many ways :) PO is designed for large or huge
> projects with hundreds or thousands of files, and D is designed to handle
> many smaller projects, because that's what I mostly work with. My projects
> rarely have more than a few hundred source files at most. Workspaces isn't
> a very important part of D, rather, like in Eclipse, all projects are
> listed in the tree-view at once and sometimes it becomes too many projects
> to have in one listing, so the workspaces function makes it possible to
> organise projects into groups. I may group all PHP-projects into one
> workspace, and all C projects into one, or my company's projects into one
> workspace, and my private projects into one etc. you get the point. All in
> all, D is designed to give quicker access to project's files, so is PO, and
> if we stick to that as the basic "vision", then anything else is just
> various "solutions" to the same problem: project file access.
>
>
> > There's a single glob file pattern list per project in ProjectOrganizer
> > defined in project properties. The advantage of a glob pattern over regex
> > is that Geany uses it too and it can be passed to the Find in Files
> dialog
> > so a pattern defined at a single place in the project config is used for
> > everything.
>
> Well, I see no problem here, why limit to glob or regex? Why not give the
> choice to use either with a checkbox/radio?
>

Because the patterns from Project->Properties->File Patterns are passed to
grep when you select "project" in the "Find in files" dialog and grep
doesn't use regex for specifying which files to search using the --include
comand-line parameter.

Also the glob patterns are used everywhere else in Geany for file
specification so I didn't want to introduce something different.


>
> PO mirrors the project directory and filters files; D picks directories
> and adds as folders in the project tree, each folder can either filter the
> files in the mirrored directory or pick specific files, naming or
> organising of files and folders does not have to mirror the file system,
> but can be moved anyway you like.
>
>
> > You can attach an arbitrary number of "external directories" to a project
> > in ProjectOrganizer and have their files displayed in the sidebar (and
> get
> > them indexed with the tag manager if needed). It's just not per file but
> > per directory.
>
> Exactly, and PO has some really nice functions for finding in files, which
> D does not, and D doesn't have indexing of symbols.
>
>
> > * Djynn can have multiple workspaces, ProjectOrganizer just uses Geany's
> > single "workspace" (basically the "recent projects" list).
>
> Instead of hundreds of files in each project, 

[Geany-Devel] Anyone still using makefile.win32 for Windows build?

[Jiří Techet]

Hi,

just a quick question - is anyone still using the Windows build based on
the makefile.win32 files? If not, maybe they could be removed completely.
Any objections?

(I ran into this when doing some tag manager source reorganization and the
question is whether it's worth updating the makefile.win32 files.)

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Test] Geany GTK3 Windows binaries for testing

[Jiří Techet]

On Sun, Apr 10, 2016 at 4:00 PM, Enrico Tröger <enrico.troe...@uvena.de>
wrote:

> On 25/03/16 10:55, Enrico Tröger wrote:
> > On 24/03/16 07:03, Thomas Martitz wrote:
> >> Am 23.03.2016 um 15:21 schrieb Jiří Techet:
> >>>
> >>> Some problems I noticed with the Gtk 3 build:
> >>> - any file dialog like File->Open, Project->open, File->Save as etc.
> >>> crashes Geany on my machine
> >>
> >> I think I had this happen when one of the post-install scripts (of glib
> >> iirc) wasn't run when creating the gtk bundle. Some gsetttings-related
> >> stuff is missing.
> >
> > As far as I remember, all post-install scripts ran when I built the
> bundle.
> > Also, as already noted, maybe the bundle creation script deleted some
> > necessary files.
> >
> > I will check this again next week.
>
> New snapshots:
> http://download.geany.org/snapshots/geany-1.28nightly20160410_setup.exe
>
> http://download.geany.org/snapshots/geany-plugins-1.28nightly20160410_setup.exe
>
> The bundle now contains GTK 3.20.
>
> The GTK dialog crashes should be fixed. The cause for the crashes were
> missing GLib schema files which were deleted. I fixed this in
>
> https://github.com/geany/geany/commit/bd8caf2a85719ffac5687e735979d6ae30dfb3b9
> but I guess I missed I included an old build of the GTK bundle into the
> last installers.
>
> @Jiří: for me the tooltips looks OK, without any unusual border.
> Maybe this was fixed in GTK 3.20, or it is caused by something else
> which is not happening on my system.
>

Looks OK on my system as well now. The only issue left is the ugly Adwaita
theme...

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Test] Geany GTK3 Windows binaries for testing

[Jiří Techet]

On Thu, Mar 24, 2016 at 1:04 AM, Matthew Brush <mbr...@codebrainz.ca> wrote:

> On 2016-03-23 07:21 AM, Jiří Techet wrote:
>
>> On Tue, Mar 22, 2016 at 9:02 AM, Enrico Tröger <enrico.troe...@uvena.de>
>> wrote:
>>
>> Hi,
>>>
>>> here are new Windows installers for testing.
>>> They are built from GIT master and this time against GTK3.
>>>
>>> There are two reasons for this:
>>> - test Geany+GTK3 more on Windows
>>> - there seems to be a bug in GTK2 on Windows with that very high
>>> DPI/resolutions: on text input widgets (GTK ones and the Scintilla
>>> widget) the mouse cursor gets very tiny.
>>> This doesn't happen with GTK3.
>>> Jiří showed me the bug and he knows more about the details.
>>>
>>>
>> Hi Enrico,
>>
>> nice - the mouse problem is solved in Gtk 3 for me but I think not so many
>> users have an HiDPI screen so it's not so important. And if there are some
>> more important problems with Gtk 3, better to stick with Gtk 2 for now.
>>
>>
> I never had any mouse-related problems with GTK2, for what it's worth. I
> have 4k monitor on Win10.


What do you have set up for windows display scaling (the dialog e.g. here
https://www.thurrott.com/windows/windows-10/4597/windows-10-feature-focus-display-scaling)?
I need to have 200% because otherwise all the UI elements would be too
small on the HiDPI screen. Now Geany window gets resized alright, just the
"special" mouse cursors like the caret-like cursor in scintilla or back
arrow cursor on scintilla sidebar are not scaled and twice as small (in
both directions which makes the mouse cursor's area effectively 4x smaller).

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Test] Geany GTK3 Windows binaries for testing

[Jiří Techet]

On Thu, Mar 24, 2016 at 3:36 PM, Matthew Brush <mbr...@codebrainz.ca> wrote:

> On 2016-03-24 03:13 AM, Jiří Techet wrote:
>
>> On Thu, Mar 24, 2016 at 1:04 AM, Matthew Brush <mbr...@codebrainz.ca>
>> wrote:
>>
>> On 2016-03-23 07:21 AM, Jiří Techet wrote:
>>>
>>> On Tue, Mar 22, 2016 at 9:02 AM, Enrico Tröger <enrico.troe...@uvena.de>
>>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>>>
>>>>> here are new Windows installers for testing.
>>>>> They are built from GIT master and this time against GTK3.
>>>>>
>>>>> There are two reasons for this:
>>>>> - test Geany+GTK3 more on Windows
>>>>> - there seems to be a bug in GTK2 on Windows with that very high
>>>>> DPI/resolutions: on text input widgets (GTK ones and the Scintilla
>>>>> widget) the mouse cursor gets very tiny.
>>>>> This doesn't happen with GTK3.
>>>>> Jiří showed me the bug and he knows more about the details.
>>>>>
>>>>>
>>>>> Hi Enrico,
>>>>
>>>> nice - the mouse problem is solved in Gtk 3 for me but I think not so
>>>> many
>>>> users have an HiDPI screen so it's not so important. And if there are
>>>> some
>>>> more important problems with Gtk 3, better to stick with Gtk 2 for now.
>>>>
>>>>
>>>> I never had any mouse-related problems with GTK2, for what it's worth. I
>>> have 4k monitor on Win10.
>>>
>>
>>
>> What do you have set up for windows display scaling (the dialog e.g. here
>>
>> https://www.thurrott.com/windows/windows-10/4597/windows-10-feature-focus-display-scaling
>> )?
>> I need to have 200% because otherwise all the UI elements would be too
>> small on the HiDPI screen. Now Geany window gets resized alright, just the
>> "special" mouse cursors like the caret-like cursor in scintilla or back
>> arrow cursor on scintilla sidebar are not scaled and twice as small (in
>> both directions which makes the mouse cursor's area effectively 4x
>> smaller).
>>
>>
> I have no scaling enabled (ie. 100%). If I wanted a 2k monitor, I wouldn't
> have got one with 4k resolution :)
>

That's it then. If you run Windows in VM on a "retina" Mac where each
original pixel consists of 4 smaller pixels then 100% is just unusable
because everything is too small. I can imagine 4k screen with 100% is
usable on a 27' monitor but it isn't on a 15' monitor.

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Test] Geany GTK3 Windows binaries for testing

[Jiří Techet]

On Thu, Mar 24, 2016 at 6:08 PM, Thomas Martitz <ku...@rockbox.org> wrote:

> Am 24. März 2016 16:21:00 MEZ, schrieb "Jiří Techet" <tec...@gmail.com>:
>
>>
>>>> That's it then. If you run Windows in VM on a "retina" Mac where each
>>> original pixel consists of 4 smaller pixels then 100% is just unusable
>>> because everything is too small. I can imagine 4k screen with 100% is
>>> usable on a 27' monitor but it isn't on a 15' monitor.
>>>
>>
>> Correction, MBP has a 5k screen (2880x1800) so it's even worse.
>>
>> Jiri
>>
>> --
>>
>> Devel mailing list
>> Devel@lists.geany.org
>> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>>
>>
> 4k is is 3840x2160 or higher. 5k is even more. 2880x1800 is something else
> 
>

Yeah, right, my bad. Anyway whatever it is, using the native resolution
without scaling makes things too small.
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Test] Geany GTK3 Windows binaries for testing

[Jiří Techet]

On Tue, Mar 22, 2016 at 9:02 AM, Enrico Tröger 
wrote:

> Hi,
>
> here are new Windows installers for testing.
> They are built from GIT master and this time against GTK3.
>
> There are two reasons for this:
> - test Geany+GTK3 more on Windows
> - there seems to be a bug in GTK2 on Windows with that very high
> DPI/resolutions: on text input widgets (GTK ones and the Scintilla
> widget) the mouse cursor gets very tiny.
> This doesn't happen with GTK3.
> Jiří showed me the bug and he knows more about the details.
>

Hi Enrico,

nice - the mouse problem is solved in Gtk 3 for me but I think not so many
users have an HiDPI screen so it's not so important. And if there are some
more important problems with Gtk 3, better to stick with Gtk 2 for now.

Some problems I noticed with the Gtk 3 build:
- any file dialog like File->Open, Project->open, File->Save as etc.
crashes Geany on my machine
- there's a bit strange shadow around the tooltips - see the attached
screenshot
- the Adwaita theme is just ugly (on any platform). Is there any Windows
native-like theme for Gtk 3 (the one used for Gtk 2 builds is pretty good
in this respect).

Cheers,

Jiri


- [image: Inline image 1]
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Storing per-project settings for plugins

[Jiří Techet]

Hello Vasiliy,

there should be no problem with your approach (the extra content of the
config file will be preserved by Geany).

However, Geany offers plugins the possibility to read/write from/to the
project config files natively. When you register for the "project-open"
signal, the callback is invoked every time a project is opened and you
receive GKeyFile * config as a parameter from which you can read the
configuration using

https://developer.gnome.org/glib/stable/glib-Key-value-file-parser.html

Similarly, when you register for "project-save", you can write your
configuration to the GKeyFile signal parameter. You can also force the
emission of the "project-save" signal by calling project_write_config().

You can check my projectorganizer plugin to see how to use the signals (the
signals are registered in prjorg-main.c). You can also check

http://www.geany.org/manual/reference/pluginsignals_8c.html

Cheers,

Jiri

On Wed, Feb 15, 2017 at 4:21 PM, Vasiliy Faronov  wrote:

> Hi,
>
> I have a small Geany plugin that needs some settings per Geany project.
>
> Currently, I do it as follows: the user manually writes a special
> section in the .geany project file, which my plugin reads as a generic
> INI file.
>
> I really like this approach (as a user) because it keeps all Geany
> project-related settings in one file.
>
> But is this approach OK in the eyes of Geany core?
>
>
> --
> Vasiliy
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [FT-plugins] Proposed "Features"

[Jiří Techet]

On Tue, Aug 30, 2016 at 6:41 PM, Matthew Brush <mbr...@codebrainz.ca> wrote:

> On 2016-08-30 08:51 AM, Thomas Martitz wrote:
>
>> Am 30.08.2016 um 01:53 schrieb Matthew Brush:
>>
>>> On 2016-08-29 03:17 PM, Thomas Martitz wrote:
>>>
>>>> Am 29.08.2016 um 17:05 schrieb Jiří Techet:
>>>>
>>>>> [...]
>>>>>
>>>>
>>>> There is also another aspect about the proposal that worries me: a
>>>> plugin shall provide N features for M languages. And X plugins might be
>>>> compete (not even considering the desire that plugins can build upon
>>>> each other). This means (slightly exaggerated) that N*M*X possibilities
>>>> have to be managed by Geany's conflict resolution. I don't want to
>>>> implement that. It seems much simpler to me to collect tags from
>>>> plugins, merge them (maybe throw out duplicates) and pass them to the
>>>> actual feature code all within Geany.
>>>>
>>>>
>>> In principle it's not that hard to manage, as mentioned in my
>>> "Proposed Design" message, Geany just needs to keep the providers in a
>>> list and the callbacks work like GTK/GDK callbacks (and some in Geany)
>>> where the callback's return value determines whether the next provider
>>> is called or not. In that message I attached a mockup of a kind of UI
>>> that could be used to allow users absolute control, and for Geany it's
>>> just a (set of) ordered lists.
>>>
>>
>> You say this should be easy, I say I expect it to be complicated. This
>> is quite the same (just the other way around) with my suggestion to just
>> pass tags to Geany. There you keep claiming that it'll be a massive
>> change why I expect it to be relatively easy to do. At least not harder
>> than changing 6+ core parts in Geany to execute plugin callbacks and
>> make something useful from the results.
>>
>>
> I've tinkered with implementations, it's generally as easy as walking a
> list in a loop, calling a function and breaking early if the function
> returns `FALSE`.
>
> I don't think I claimed it will be a massive change, I think I just said
> it will add more complexity to ft-plugins, as opposed to less, as you
> claimed.
>
> Since the very first response I made to you about TM, I've been open to
> the idea. I raised a few concerns which you never responded to, namely that
> it may not be possible for TM to handle all the tags in Clang's AST (it has
> a very rich and complex AST, heavily optimized by some of the smartest
> people in the C++ world). Also the AST is HUGE and representing it twice in
> memory would at least (if not more than) double the memory footprint.
>
>
>>> What worries me is that we jumped from mere brainstorming to a
>>>> relatively concrete proposal, without evaluating requirements or any
>>>> other research. Or was this evaluation just invisible to me?
>>>>
>>>>
>>> I evaluated and experimented with several different approaches and
>>> discussed various details with some of the main developers (including
>>> you) on IRC. Based on the way that in my opinion, as someone who has
>>> tried and failed to implement the needed features in the past, and as
>>> a Geany developer, I recommended a proposed design for further input.
>>> And here we are :)
>>>
>>
>>
>> Please show me the point in the IRC logs where I agreed with your
>> approach. In fact, I can't remember discussing ft-plugins with you on
>> IRC at all (I just asked at one point how libclang works in more detail).
>>
>>
> I never said I proposed a design on IRC, that's what the "Proposed Design"
> email was about. I discussed approaches and details with some of the
> developers. You and I talked about whether TM might be up to the job of
> representing scope, for example (and you pointed out that it can, crudely,
> by using strings rather than parent/child relationships).
>
> Your evaluation is still invisible to me.
>>
>>
> I evaluated the various approaches myself and by discussing specific
> topics with some devs lately and previously when we talked about ft-plugins
> so that I would be able to propose a design on the mailing list, and here
> we are discussing that. I don't see the problem.
>
>
>>> As I asked in an earlier message, I'd be interested if you could
>>> provide some more concrete examples of what you were thinking with
>>> using TM, which would accomplish the goals mentioned in the Github
>>> Issue and 

Re: [Geany-Devel] [FT-plugins] Proposed "Features"

[Jiří Techet]

On Wed, Aug 31, 2016 at 1:22 PM, Thomas Martitz <ku...@rockbox.org> wrote:

> Am 31.08.2016 um 13:03 schrieb Jiří Techet:
>
>
>>
>> On Tue, Aug 30, 2016 at 11:29 PM, Thomas Martitz <ku...@rockbox.org
>> <mailto:ku...@rockbox.org>> wrote:
>>
>> Am 30.08.2016 um 21:10 schrieb Jiří Techet:
>>
>> Geany would then merge the tags, perhaps giving the plugin
>> ones more
>> weight, and store it in TM.
>>
>>
>> I think you underestimate how many tags we're talking
>> here. The
>> example libclang ft-plugin would have to re-walk the
>> entire AST
>> (which is absolutely massive, particularly for C++),
>> convert it to
>> TM tag structures, and then Geany/TM would have to perform
>> some
>> merging logic, would would be more complicated than now if
>> it was
>> to support C++ properly, every single re-parse. My
>> intuition tells
>> me that just won't be fast enough, Clang already jumps through
>> hoops and uses tricks to just build its own AST in-time.
>>
>>
>> I think it would be a disaster performance-wise. The number of
>> AST nodes can be easily 100x more than the amount of tags we
>> have from ctags (we get a single tag for a function now and
>> AST will contain complete tree for the function body) so just
>> this might cost 100x more. In addition all the necessary
>> copies to TM internal representation, having to maintain the
>> tree structure (in TM we use GPtrArrays for everything which
>> are very efficient and during tag merge we try to eliminate
>> even pointer dereferences because those start getting
>> expensive when managing many tags) etc.
>>
>>
>>
>> Let's not outright reject possible solutions based on performance
>> assumptions and guestimations. Performance can be evaluated on an
>> actual implementation. Until then it's simply an invalid argument
>> for this discussion. But FWIW, I don't think performance is the
>> driving aspect.
>>
>>
>> No, performance is a very valid point. Tag updates don't happen in a
>> background thread in Geany but rather on the main thread (and changing this
>> would require lots of modifications as neither ctags, nor TM nor Geany are
>> thread-safe) and all updates have to happen in a really short time period -
>> you cannot make the GUI freeze while the user is typing so you have 100ms
>> at most without any noticeable delay.
>>
>
> I'm saying we can't evaluate performance at this time, because no
> implementation is available. So saying now "uhm I fear it might be too slow
> my guess is that the other one is 100x faster" is just a wild assumption
> that doesn't help except spraying FUD. And outright rejecting a proposal
> based on such assumptions is invalid.
>

100x more nodes of AST than the amount of tags we have isn't any wild
assumption - have a look at the AST picture here:

https://en.wikipedia.org/wiki/Abstract_syntax_tree

and the primitive code below to which it corresponds. The tree has 21
nodes. It's easy to imagine source files with 5x more code per function and
you are at the numbers I'm giving you - we generate 1 tag per function and
the corresponding AST you'll have to walk is 100x bigger.


>
> Please lets evaluate solutions, implement them, and then have an eye on
> performance.


I think I have evaluated this solution and it doesn't seem worth the
effort. Not only because the performance but also I don't know how to store
all the necessary information for any kind of language into TM so code
completion works for any language so that it's compatible with ctags and
any kind of AST. If you do, please tell us but not the way "One solution
can be to have tags hold sufficient information" because it doesn't tell
anything.


>
>
>
>> What's needed from the AST is tags (as you and I mentioned
>> elsewhere, AST is the complete code representation, so much more
>> than what's required currently). Those can be extracted in one
>> pass. I don't see that tags need to be converted back to the
>> original AST.
>>
>>
>> As Matthew said, tags are insufficient for good autocompletion (e.g.
>> consider dynamic languages like Python where you have to infer variable
>> type from the right-hand side of an assignment and based on that generate
>> an autocompletion list).
>>
>
&

Re: [Geany-Devel] [FT-plugins] Allowing plugins to supply filetype specific functionality

[Jiří Techet]

Hi Matthew,

some random thoughts.

I'm not sure I agree with doing lots of changes on a separate branch
basically without any review. While you will be able to commit things fast
to the branch, the most probable outcome will be the branch will get never
merged because either nobody will be able to review the changes during
merge or there will be some disagreement about something that could have
been caught early. And then it's just lost effort.

The individual points here

https://github.com/geany/geany/issues/1195

look like they should be able to do one by one. The most useful seems to be
the code completion so this might be the one to start with. In parallel it
would be good to develop a plugin that uses the new API and get it to a
really usable state - you won't be able to tell what exactly you need for
the plugin unless you have some working code. In parallel you can get some
feedback from users and they will have something useful rather than lots of
half-finished prototype features that aren't really usable.

My other question is who wants to work on this? The issue mentions only
those providing patches should be involved but is there anyone except you
who will contribute patches? I confess this isn't very interesting for me -
I'm not so terribly tied to Geany and if I wanted e.g. a dedicated C++
editor, I'd grab something else - you always get better language support if
the editor is made specifically for your needs. I use Geany as a general
purpose editor but otherwise use also Android Studio and XCode when writing
for Android or iOS. So no patches from me I'm afraid :-(. Apart from that
this is a huge amount of work and I'm just lazy, sorry ;-)

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [FT-plugins] Proposed "Features"

[Jiří Techet]

On Mon, Aug 29, 2016 at 5:14 AM, Matthew Brush  wrote:

> Hi All,
>
> Related to my previous mail, and assuming it is somewhat reasonable, I
> would like to propose a list of initial features that will be useful to
> allow plugins to provide, in no particular order:
>
> 
>
> Syntax Highlighting
> ---
>
> Most likely using an API based on/similar to Scintilla's "container
> lexers".
>
> At the minimum, it could have a callback something like:
>
> gboolean (*highlight)(GeanyPlugin*, GeanyDocument*,
> guint start_pos, guint end_pos, gpointer user_data);
>
> As with Scintilla's "container lexer", it would just tell the provider
> what and where to highlight. It might be pointless providing `end_pos` it
> could probably just highlight a whole line at time (maybe like Scintilla's
> 'style-needed' notification).
>
> If the providers are to setup their own colour schemes and such, then it
> may be required to add a callback such as:
>
> gboolean (*init_styles)(GeanyPlugin*, GeanyDocument*,
> gpointer user_data);
>
> for the plugin to configure all the Scintilla styles as it wishes. This
> will probably require some kind of conflict avoidance scheme if it is to
> support multiple providers providing the same feature. Perhaps it could
> also pass the start style ID the provider can use, and it could tell Geany
> the maximum style that it ended up using.
>
> Sidebar Symbol Tree
> ---
>
> Could provide some API functions to populate the tree by plugins providing
> the needed information. The nesting could be handled by passing a scope
> path similar to GtkTreePath or TagManager's `::` delimited scope string,
> which would be parsed/expanded to apply to the right tree node.
>
> The callback function for the provider might be like:
>
> gboolean (*populate_symbols_tree)(GeanyPlugin*, GeanyDocument*,
> guint cursor_pos, gchar **current_node_path /* out */,
> gpointer user_data);
>
> When the providers are called in to, they could use a function something
> like this:
>
> void tagbar_add_node(const gchar *name, guint line,
> const gchar *signature, const gchar *scope_path,
> GeanySidebarIcon icon);
>
> I haven't looked closely at the existing sidebar/symbols code yet, maybe
> it already provides such a function that could be used. It has also been
> mentioned that this could be done using the TagManager API. Plugins would
> walk their own internal ASTs or tag lists and build up the TM tag array,
> and Geany would use it for updating the symbols tree as it currently does
> (IIUC). I don't know much about TM so I can't really give an example
> callback for such an API.
>
> Auto-Completion/Intellisense
> 
>
> This could be triggered at the exact same time in the same way it is now
> (and re-using the same preferences). It could call a callback function in
> the ft-plugins like:
>
> gboolean (*complete_at)(GeanyPlugin *, GeanyDocument *,
> guint position, const gchar *partial_word,
> GPtrArray completion_list /* out */, gpointer user_data);
>
> The `completion_list` would be filled in with whatever the provider thinks
> could be completed at `position`. It could be made more advanced in the
> future like allowing plugins to give icons, argument lists, documentation
> comment text, etc. For now it could just give strings to directly populate
> Scintilla's auto-complete listbox.
>
> Calltips
> 
>
> To provide calltips, a provider could be called into like:
>
> gboolean (*provide_calltips)(GeanyPlugin*, GeanyDocument*,
> guint position, const gchar *symbol,
> GPtrArray *overloads /* out */, gpointer user_data);
>
> The `overloads` array would populated by the provider with the various
> overloads for the given `symbol` (function). As with auto-completion, at
> first this could just be a list of overloads represented as strings which
> directly populate Scintilla's calltip infos. This could be enhanced in the
> future to provide documentation comment text and placeholder insertion
> points into the editor in the future, but for now should be kept simple
> (see GtkSourceView, XCode, etc).
>
> Go To Declaration/Definition
> 
>
> This could be either single callback passing a parameter to tell whether
> declaration or definition, or two separate callbacks. An example of the
> callbacks could be:
>
> struct SourceLocation { gchar *filename; guint position; };
>
> gboolean (*get_declaration_location)(GeanyPlugin*, GeanyDocument*,
> guint position, const gchar *symbol,
> GPtrArray *results, gpointer user_data);
>
> and likewise for `get_definition_location`. The `results` array could be
> populated with `SourceLocation`s for each possible definition/declaration.
> For example there might be multiple declarations in different `#if` blocks
> you could jump to, for C-like languages. Geany 

Re: [Geany-Devel] OSX ports?

[Jiří Techet]

On Wed, Oct 12, 2016 at 7:19 PM, Chris H <spaml...@xmail.net> wrote:

>
> Quoting Jiří Techet :
> > Hi Chris,
> Hello Jiří, and thanks for the reply...
>
> >
> > On Mon, Oct 10, 2016 at 8:09 AM, Chris H  wrote:
> >
> > >
> > > Quoting Chris H :
> > > Apologies, my mailer truncated my message...
> > > >
> > > > Greetings,
> > > >  Sorry if this has been asked in the past. I've attempted to find
> similar
> > > > topics in the
> > > > list archive. But to no avail. The link on Geany's MailingList page
> > > > (http://news.gmane.org/gmane.editors.geany.devel)
> > > > to search the archives returns 404.
> > > > So my question is; are there any issues building on OSX? I'm
> currently
> > > > maintaining over 100 ports on FreeBSD,
> > > > and use Geany for most of my work, but have recently taken an
> interest in
> > > > OSX, and now feel handicapped without
> > > > it (Geany). While I see that you provide a link to an OSX dmg image
> for
> > > > OSX, It's 64bit only, and is limited to
> > > 10.7 or greater. What I'd like to do, is create a universal binary that
> > > coveres the
> > > whole gambit (10.*). So I guess my question is;
> > > 1) Does Geany compile on OSX out of the box?
> > >
> >
> > No, it doesn't. Geany depends on GTK and transitively on lots of other
> open
> > source libraries which aren't part of OS X. It's not enough to build just
> > Geany - you have to build all these dependencies and add them into the
> > bundle.
> Sure, of course. I just wondered that if I already had all the headers,
> and source
> available (via Homebrew/Xcode), that it might "just work". :-)
>
> >
> > I use
> >
> > https://wiki.gnome.org/Projects/GTK+/OSX
> Yea, I checked that out, as well. But already available through Homebrew.
>
> >
> > to build Geany and make a bundle. Geany has also been extended with the
> > "integration" part to better integrate to OS X to support things like
> > global menus etc. The detailed build process is described here:
> >
> > https://github.com/geany/geany-osx
> Caught that.
>
> >
> > OS X 10.7 is by default the oldest version supported by GTK-OSX but I
> > believe there's some way to support older systems too (I believe there
> was
> > some problem with changed binary format and linking). The question is
> > whether supporting such old systems is worth it - OS X 10.7 isn't
> supported
> > even by Apple and doesn't receive security patches and IMO nobody should
> > use it.
> >
> > Building 386 binaries is somehow possible too with GTK-OSX but again, we
> > are talking about 10 year old computers running unsupported operating
> > system versions. Besides, this would about double the bundle size (which
> > currently is about 60MB because all the dependencies have to be inside)
> and
> > in addition I don't have to any 386 Mac to test which is why I decided
> not
> > to support these.
> Sure. I get that (old system...). But IMHO more was lost, than gained in
> the
> the newer versions (of OSX).


What exactly was lost? I'm not aware of any feature removals and the
security of the OS has been improved a lot over the recent years. And from
what I can say, stability too.


> I'm also quite savvy with all the underpinnings
> of OSX, and had no trouble upgrading, or otherwise patching the system to
> be (at least) as safe, and stable, as the latest version. :-)
>

Wow, that's quite a claim. Even though the kernel sources are available, I
seriously doubt you backport the security fixes from the latest kernels and
recompile the old kernel. For all the remaining stuff like system
frameworks and various daemons you'd have to use assembly and somehow write
the security-related patches in it (the only place I saw someone doing this
was Angela Bennett in "The Net" movie). The "at least" part is even more
interesting as you seem to be even improving the system this way.

Unless you do the above, you are pretty much vulnerable to various attacks.


> It also runs *quite* nicely at 64bit. The only issues I've encountered, is
> with applications that claim to be 64bit exclusive, and simply fail to
> start,
> because they're *not*. Firefox, is a good example. But since it's a UB, I
> simply ticked the 32bit box, and it then runs w/o issue.
> >
> >
> > > 2) If not, is there already any work on this I might expand on, rather
> > > than re-invent the wheel?
> > > FWIW I evaluated MacPorts, but found it less 

Re: [Geany-Devel] OSX ports?

[Jiří Techet]

Hi Chris,

On Mon, Oct 10, 2016 at 8:09 AM, Chris H  wrote:

>
> Quoting Chris H :
> Apologies, my mailer truncated my message...
> >
> > Greetings,
> >  Sorry if this has been asked in the past. I've attempted to find similar
> > topics in the
> > list archive. But to no avail. The link on Geany's MailingList page
> > (http://news.gmane.org/gmane.editors.geany.devel)
> > to search the archives returns 404.
> > So my question is; are there any issues building on OSX? I'm currently
> > maintaining over 100 ports on FreeBSD,
> > and use Geany for most of my work, but have recently taken an interest in
> > OSX, and now feel handicapped without
> > it (Geany). While I see that you provide a link to an OSX dmg image for
> > OSX, It's 64bit only, and is limited to
> 10.7 or greater. What I'd like to do, is create a universal binary that
> coveres the
> whole gambit (10.*). So I guess my question is;
> 1) Does Geany compile on OSX out of the box?
>

No, it doesn't. Geany depends on GTK and transitively on lots of other open
source libraries which aren't part of OS X. It's not enough to build just
Geany - you have to build all these dependencies and add them into the
bundle.

I use

https://wiki.gnome.org/Projects/GTK+/OSX

to build Geany and make a bundle. Geany has also been extended with the
"integration" part to better integrate to OS X to support things like
global menus etc. The detailed build process is described here:

https://github.com/geany/geany-osx

OS X 10.7 is by default the oldest version supported by GTK-OSX but I
believe there's some way to support older systems too (I believe there was
some problem with changed binary format and linking). The question is
whether supporting such old systems is worth it - OS X 10.7 isn't supported
even by Apple and doesn't receive security patches and IMO nobody should
use it.

Building 386 binaries is somehow possible too with GTK-OSX but again, we
are talking about 10 year old computers running unsupported operating
system versions. Besides, this would about double the bundle size (which
currently is about 60MB because all the dependencies have to be inside) and
in addition I don't have to any 386 Mac to test which is why I decided not
to support these.


> 2) If not, is there already any work on this I might expand on, rather
> than re-invent the wheel?
> FWIW I evaluated MacPorts, but found it less than ideal, and upon further
> evaluation, found
> HomeBrew a better candidate.
>

Neither MacPorts nor HomeBrew are suitable - I tried both. The problem is
you don't want to create just a command-line version of the app - you want
it to behave like a standard GUI application with global menu, clickable
icon in the launcher, being able to drag files to the icon to open them
etc. These things aren't possible with MacPorts or HomeBrew (in addition I
believe HomeBrew doesn't have GTK built with Quartz backend and only
provides X backend so there's no support of retina displays).

For MacPorts Geany version there's a wiki page here

https://wiki.geany.org/howtos/osx/running

There's no similar description for HomeBrew but from what I tried, it runs
fine but with the mentioned X backend and all the limitations above.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Future of THANKS/contributors list inside help dialog

[Jiří Techet]

Hi Frank,

On Thu, Mar 9, 2017 at 2:56 PM, Frank Lanitz  wrote:

> Hi,
>
> Currently we have apart of the git list itself two places where we have
> added contributors in past, but which look quiet orphaned nowadays:
>
> The contributors-dialog on Geany->Help:
>
> https://github.com/geany/geany/blob/master/src/about.c
>
> and the THANKS-file inside / of the source tree:
>
> https://github.com/geany/geany/blob/master/THANKS
>
> As we got a huge amount of contributors¹ all should get their kudos and
> now I'm wondering how we can go on in future with it. There are
> contributors for translations, code, documentation, community things
> like support, donations (money) etc.
>

One possibility (apart from what Lex suggests which is OK too) is to list
the names that the AUTHORS file shows:

https://github.com/geany/geany/blob/master/AUTHORS

or better the updated version of AUTHORS from #1148:

https://github.com/geany/geany/pull/1148/commits/b40b6ec9dfebcb7dc6911fbca085b46cfa66b43d

When you have a look here

https://github.com/geany/geany/graphs/contributors

the number of regularly code-contributing developers is quite small - I'd
say it's just the first 9 plus Eugene who contributed a lot in the pre-git
era (maybe there's someone else missing from that time - Enrico could know
better). When you have a look at the rest of the contributor's commits,
they are either 1-feature-related (e.g. SiegeLord's Rust parser), or
translators.

So I think listing these people explicitly plus "thanks to all other
contributors" could be enough. If someone else starts contributing
regularly, he can be added but this doesn't happen so often to be a
maintenance problem.


>
> Cheers,
> Frank
>
> ¹ Openhub https://www.openhub.net/p/geany says we have 42 (hihi)
> contributors last year -- not counting po updates where I committed the
> po files myself.


I think these actually are po updates mostly - even though you commit them,
git shows the author of the patch, not the committer and there definitely
weren't Geany code patches merged from 42 different people last year.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] Future of THANKS/contributors list inside help dialog

[Jiří Techet]

Hi Lex,

On Fri, Mar 10, 2017 at 12:58 AM, Lex Trotman  wrote:

> ...
> >
> > I think these actually are po updates mostly - even though you commit
> them,
> > git shows the author of the patch, not the committer and there definitely
> > weren't Geany code patches merged from 42 different people last year.
>
> Translators ARE contributors, if anybody is listed they should be too.
>
> This is one of my BIG objections to some projects, you are only
> considered worthwhile if you contribute to code.  Documentation,
> translation, testing, those who submit bug reports that we then fix,
> even those who submit feature suggestions that get implemented by
> others, packagers, all of those are worthwhile contributors to
> improving Geany, but not all of them will show up in git. Projects
> that ignore those people just look like unappreciative gits (pun
> intended).  [end rant]


actually after re-reading Frank's email I realized I misunderstood what he
was saying - I thought he said there were 42 contributors last year "not
counting po file updates" (i.e. non-translators, just code contributors)
but he said "not counting po file updates committed by myself" (that is
without a few extra ones he committed on behalf of the translators). So I
was pointing just to what I thought was an error in the counts of code
contributors - I absolutely didn't want to say that translators aren't
contributors and sorry if I made that impression.

What Enrico suggests about exporting git history and adding other
contributors from the past sounds good to me. I think it's almost
guaranteed someone will be missed but the THANKS file will be more
up-to-date than now.

Maybe a suggestion - instead of linking to the THANKS file to github (URLs
can change, etc.), the THANKS file could be installed together with Geany
and the About dialog could just read it and add it as a string to the
Contributors section. I can write the patch.

Cheers,

Jiri
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] OSX plugin development

[Jiří Techet]

Hi Steve,

I slightly remember I got an error like this one in the past but I don't
remember what exactly the problem was. Anyway, it's not good to mix
dependencies from homebrew and jhbuild. If you have some environment
variables set up to link against homebrew libraries, this is what could
cause problems. I created a separate account on my machine from which I do
the Geany build to be sure nothing like that is set up.

If you keep getting the error, you might also consider building python as
part of the build process which is then used instead of the system python
for the rest of the build. This means running

jhbuild bootstrap
jhbuild python
jhbuild build meta-gtk-osx-bootstrap
jhbuild build meta-gtk-osx-core

When doing a change like that, it's best to remove the gtk directory
because it changes dependencies and basically everything has to be rebuilt.

Apart from that everything else should work as described here:

https://github.com/geany/geany-osx

When al the dependencies are built, you should be able to use the same
stuff you use under linux for building your plugin. But be sure to run the
build within a jhbuild shell - you need to run

jhbuild shell

which sets up the environment variables to use the dependencies built by
jhbuild after you should be able to build your plugin in a normal way.

Let me know if you run into more problems.

Cheers,

Jiri

On Fri, Sep 22, 2017 at 12:00 AM,  wrote:

> I’m trying to build plugins in OSX, and I’m a bit out of my element.
>
>
>
> (I’ve had problems with my yahoo email not getting through to this list,
> but I haven’t had a chance to switch email accounts.  I hope this makes it.)
>
>
>
> I’m following the guide on https://github.com/geany/geany-osx
>
>
>
> I get stuck running in step 6:
>
> jhbuild build meta-gtk-osx-bootstrap
> …
>
> checking for python module libxml2... ./configure: line 2422: 83400
> Doneecho "import $py_module"
>
>  83401 Abort trap: 6   | python - >&/dev/null
>
> not found
>
> configure: error: Python module libxml2 is needed to run this package
>
> *** Error during phase configure of itstool: ## Error running
> ../configure --prefix /Users/steve/gtk/inst*** [7/12]
>
>
>
>   [1] Rerun phase configure
>
>   [2] Ignore error and continue to build
>
>   [3] Give up on module
>
>   [4] Start shell
>
>   [5] Reload configuration
>
>   [6] Go to phase "wipe directory and start over"
>
>   [7] Go to phase "clean"
>
>   [8] Go to phase "distclean"
>
>
>
> I’ve installed libxml2 via homebrew, and py-libxml2 and py27-libxml2 via
> macports to no avail.
>
>
>
> I figured out how to build the .o file for one of my plugins:
>
>
>
> gcc -c quick-search.c -fPIC -std=c99 -DGTK -I 
> /Users/steve/projects/geany/geany/plugins/
> -I /Users/steve/projects/geany/geany/src/ -I 
> /Users/steve/projects/geany/geany/tagmanager/src/
> -I /Users/steve/projects/geany/geany/scintilla/include/ `pkg-config
> --cflags glib-2.0` `pkg-config --cflags gtk+-2.0` -I
> /Users/steve/projects/geany/geany/scintilla/
>
>
>
> But not the ..so file.
>
>
>
> Thanks for any help,
>
>
>
> Steve
>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] OSX plugin development

[Jiří Techet]

ive)
>
>   gnome-common @3.18.0_0 (active)
>
>   gobject-introspection @1.54.0_0 (active)
>
>   graphite2 @1.3.9_0 (active)
>
>   harfbuzz @1.5.1_0 (active)
>
>   hicolor-icon-theme @0.17_0 (active)
>
>   intltool @0.51.0_3 (active)
>
>   itstool @2.0.2_2 (active)
>
>   jasper @2.0.14_0 (active)
>
>   jpeg @9b_0 (active)
>
>   libedit @20170329-3.1_1 (active)
>
>   libepoxy @1.4.3_1+python36 (active)
>
>   libffi @3.2.1_0 (active)
>
>   libiconv @1.15_0 (active)
>
>   libidn @1.33_0 (active)
>
>   libpixman @0.34.0_0 (active)
>
>   libpng @1.6.32_0 (active)
>
>   libtool @2.4.6_3 (active)
>
>   libxml2 @2.9.5_0 (active)
>
>   libxslt @1.1.29_1 (active)
>
>   mesa @17.1.6_0+osmesa+python27 (active)
>
>   ncurses @6.0-20170916_0 (active)
>
>   openssl @1.0.2l_0 (active)
>
>   p5.24-encode-locale @1.50.0_0 (active)
>
>   p5.24-file-listing @6.40.0_1 (active)
>
>   p5.24-getopt-long @2.500.0_0 (active)
>
>   p5.24-html-form @6.30.0_1 (active)
>
>   p5.24-html-parser @3.720.0_0 (active)
>
>   p5.24-html-tagset @3.200.0_4 (active)
>
>   p5.24-http-cookies @6.40.0_0 (active)
>
>   p5.24-http-daemon @6.10.0_1 (active)
>
>   p5.24-http-date @6.20.0_1 (active)
>
>   p5.24-http-message @6.130.0_0 (active)
>
>   p5.24-http-negotiate @6.10.0_1 (active)
>
>   p5.24-io-html @1.1.0_0 (active)
>
>   p5.24-io-socket-ssl @2.51.0_0 (active)
>
>   p5.24-libwww-perl @6.260.0_0 (active)
>
>   p5.24-lwp-mediatypes @6.20.0_1 (active)
>
>   p5.24-lwp-protocol-https @6.70.0_0 (active)
>
>   p5.24-mozilla-ca @20160104_0 (active)
>
>   p5.24-net-http @6.170.0_0 (active)
>
>   p5.24-net-libidn @0.120.0_4 (active)
>
>   p5.24-net-ssleay @1.810.0_0 (active)
>
>   p5.24-pathtools @3.620.0_0 (active)
>
>   p5.24-scalar-list-utils @1.490.0_0 (active)
>
>   p5.24-sub-name @0.210.0_0 (active)
>
>   p5.24-sub-uplevel @0.280.0_0 (active)
>
>   p5.24-test-exception @0.430.0_0 (active)
>
>   p5.24-test-nowarnings @1.40.0_1 (active)
>
>   p5.24-test-warn @0.320.0_0 (active)
>
>   p5.24-try-tiny @0.280.0_0 (active)
>
>   p5.24-uri @1.720.0_0 (active)
>
>   p5.24-www-robotrules @6.20.0_1 (active)
>
>   p5.24-xml-parser @2.440.0_0 (active)
>
>   pango @1.40.12_0+quartz+x11 (active)
>
>   pcre @8.41_0 (active)
>
>   perl5.24 @5.24.2_0 (active)
>
>   pkgconfig @0.29.2_0 (active)
>
>   py-libxml2 @2.9.5_0 (active)
>
>   py27-beaker @1.8.1_0 (active)
>
>   py27-libxml2 @2.9.5_0 (active)
>
>   py27-mako @1.0.7_0 (active)
>
>   py27-markupsafe @0.23_0 (active)
>
>   py27-setuptools @36.5.0_0 (active)
>
>   python2_select @0.0_2 (active)
>
>   python27 @2.7.13_1 (active)
>
>   python_select @0.3_7 (active)
>
>   readline @7.0.003_1 (active)
>
>   shared-mime-info @1.7_2 (active)
>
>   sqlite3 @3.20.1_0 (active)
>
>   tiff @4.0.8_0 (active)
>
>   Xft2 @2.3.2_0 (active)
>
>   xorg-compositeproto @0.4.2_0 (active)
>
>   xorg-damageproto @1.2.1_0 (active)
>
>   xorg-dri2proto @2.8_0 (active)
>
>   xorg-fixesproto @5.0_0 (active)
>
>   xorg-glproto @1.4.17_0 (active)
>
>   xorg-inputproto @2.3.2_0 (active)
>
>   xorg-kbproto @1.0.7_0 (active)
>
>   xorg-libice @1.0.9_0 (active)
>
>   xorg-libpthread-stubs @0.3_0 (active)
>
>   xorg-libsm @1.2.2_0 (active)
>
>   xorg-libX11 @1.6.5_0 (active)
>
>   xorg-libXau @1.0.8_0 (active)
>
>   xorg-libxcb @1.12_2+python27 (active)
>
>   xorg-libXcomposite @0.4.4_0 (active)
>
>   xorg-libXcursor @1.1.14_0 (active)
>
>   xorg-libXdamage @1.1.4_0 (active)
>
>   xorg-libXdmcp @1.1.2_0 (active)
>
>   xorg-libXext @1.3.3_0 (active)
>
>   xorg-libXfixes @5.0.3_0 (active)
>
>   xorg-libXi @1.7.8_0 (active)
>
>   xorg-libXinerama @1.1.3_0 (active)
>
>   xorg-libXmu @1.1.2_0 (active)
>
>   xorg-libXrandr @1.5.1_0 (active)
>
>   xorg-libXt @1.1.5_1 (active)
>
>   xorg-libXtst @1.2.3_0 (active)
>
>   xorg-libXxf86vm @1.1.4_0 (active)
>
>   xorg-randrproto @1.5.0_0 (active)
>
>   xorg-recordproto @1.14.2_0 (active)
>
>   xorg-renderproto @0.11.1_0 (active)
>
>   xorg-xcb-proto @1.12_1+python27 (active)
>
>   xorg-xcb-util @0.4.0_0 (active)
>
>   xorg-xextproto @7.3.0_0 (active)
>
>   xorg-xf86vidmodeproto @2.3.1_0 (active)
>
>   xorg-xineramaproto @1.2.1_0 (active)
>
>   xorg-xproto @7.0.31_0 (active)
>
>   xrender @0.9.10_0 (active)
>
>   xz @5.2.3_0 (active)
>
>   zlib @1.2.11_0 (active)
>
>
>
> Sorry for the inconvenience, but any suggestions?
>
>
>
> Thanks,
>
>
>
&

Re: [Geany-Devel] OSX plugin development

[Jiří Techet]

Hi Steve,

I found this issue

https://gitlab.kitware.com/cmake/cmake/issues/17101

not sure if it's related.

In your case I suspect either some clash with Homebrew (in this case I
recommend building in a separate account) or that you built part of the
dependencies on previous macOS system and then upgraded to High Sierra
where symbols in system libraries may differ. In this case I'd suggest
deleting the whole gtk directory and starting over to make sure everything
is built on the new system.

Jiri



On Sat, Sep 30, 2017 at 1:09 AM,  wrote:

> Ok, so I got through the dependencies (meta-gtk-osx-core), and ran:
>
>
>
> export LC_ALL=en_US.UTF-8
>
> export LANG=en_US.UTF-8
>
> jhbuild -m geany.modules build geany-bundle
>
> …
>
> *** Building libgit2 *** [14/26]
>
> make -j 9
>
> [  0%] Linking C shared library libgit2.dylib
>
> [ 79%] Built target libgit2_clar
>
> dyld: lazy symbol binding failed: Symbol not found: _utimensat
>
>   Referenced from: /Users/sblatnick/gtk/inst/bin/cmake
>
>   Expected in: /usr/lib/libSystem.B.dylib
>
>
>
> dyld: Symbol not found: _utimensat
>
>   Referenced from: /Users/sblatnick/gtk/inst/bin/cmake
>
>   Expected in: /usr/lib/libSystem.B.dylib
>
>
>
> make[2]: *** [libgit2.dylib] Abort trap: 6
>
> make[2]: *** Deleting file `libgit2.dylib'
>
> make[1]: *** [CMakeFiles/git2.dir/all] Error 2
>
> make: *** [all] Error 2
>
> *** Error during phase build of libgit2: ## Error running make -j
> 9  *** [14/26]
>
>
>
>   [1] Rerun phase build
>
>   [2] Ignore error and continue to install
>
>   [3] Give up on module
>
>   [4] Start shell
>
>   [5] Reload configuration
>
>   [6] Go to phase "wipe directory and start over"
>
>
>
> I’m not sure what is going wrong with building geany itself.
>
>
>
> Thanks,
>
>
>
> Steve
>
>
>
> *From:* Devel [mailto:devel-boun...@lists.geany.org] *On Behalf Of *Jirí
> Techet
> *Sent:* Friday, September 22, 2017 3:02 AM
> *To:* Geany development list 
> *Subject:* Re: [Geany-Devel] OSX plugin development
>
>
>
> Hi Steve,
>
>
>
> I slightly remember I got an error like this one in the past but I don't
> remember what exactly the problem was. Anyway, it's not good to mix
> dependencies from homebrew and jhbuild. If you have some environment
> variables set up to link against homebrew libraries, this is what could
> cause problems. I created a separate account on my machine from which I do
> the Geany build to be sure nothing like that is set up.
>
>
>
> If you keep getting the error, you might also consider building python as
> part of the build process which is then used instead of the system python
> for the rest of the build. This means running
>
>
>
> jhbuild bootstrap
>
> jhbuild python
>
> jhbuild build meta-gtk-osx-bootstrap
>
> jhbuild build meta-gtk-osx-core
>
>
>
> When doing a change like that, it's best to remove the gtk directory
> because it changes dependencies and basically everything has to be rebuilt.
>
>
>
> Apart from that everything else should work as described here:
>
>
>
> https://github.com/geany/geany-osx
>
>
>
> When al the dependencies are built, you should be able to use the same
> stuff you use under linux for building your plugin. But be sure to run the
> build within a jhbuild shell - you need to run
>
>
>
> jhbuild shell
>
>
>
> which sets up the environment variables to use the dependencies built by
> jhbuild after you should be able to build your plugin in a normal way.
>
>
>
> Let me know if you run into more problems.
>
>
>
> Cheers,
>
>
>
> Jiri
>
>
>
> On Fri, Sep 22, 2017 at 12:00 AM,  wrote:
>
> I’m trying to build plugins in OSX, and I’m a bit out of my element.
>
>
>
> (I’ve had problems with my yahoo email not getting through to this list,
> but I haven’t had a chance to switch email accounts.  I hope this makes it.)
>
>
>
> I’m following the guide on https://github.com/geany/geany-osx
>
>
>
> I get stuck running in step 6:
>
> jhbuild build meta-gtk-osx-bootstrap
> …
>
> checking for python module libxml2... ./configure: line 2422: 83400
> Doneecho "import $py_module"
>
>  83401 Abort trap: 6   | python - >&/dev/null
>
> not found
>
> configure: error: Python module libxml2 is needed to run this package
>
> *** Error during phase configure of itstool: ## Error running
> ../configure --prefix /Users/steve/gtk/inst*** [7/12]
>
>
>
>   [1] Rerun phase configure
>
>   [2] Ignore error and continue to build
>
>   [3] Give up on module
>
>   [4] Start shell
>
>   [5] Reload configuration
>
>   [6] Go to phase "wipe directory and start over"
>
>   [7] Go to phase "clean"
>
>   [8] Go to phase "distclean"
>
>
>
> I’ve installed libxml2 via homebrew, and py-libxml2 and py27-libxml2 via
> macports to no avail.
>
>
>
> I figured out how to build the .o file for one of my plugins:
>
>
>
> gcc -c quick-search.c -fPIC -std=c99 -DGTK -I 
> /Users/steve/projects/geany/geany/plugins/
> -I 

Re: [Geany-Devel] OSX plugin development

[Jiří Techet]

Hi Steve,

yeah, I meant a different login.

Oh, you use MacPorts too. I had some problems with MacPorts and jhuild in
the past so that definitely could be it as well.

Jiri

On Sun, Oct 1, 2017 at 6:56 AM, Steven Blatnick 
wrote:

> Thanks again for the quick reply.
>
> When you say to use a separate account, do you mean a different login to
> osx? I'm not sure I can do that since this is a laptop I was issued from
> work that I wish to use geany plugins on. I think my best bet is to
> uninstall any homebrew (and macport?) gtk libraries and try again.
>
> Sorry I made you repeat your initial advice. I should have mentioned I
> didn't think I could try another account. If removing homebrew and deleting
> the gtk directory don't fix it, I suppose using jhbuild python is my next
> best option from your original email.
>
> Thanks,
>
> Steve
>
>
>  Original Message 
> From:Jiří Techet
> Sent:Sat, 30 Sep 2017 13:15:16 -0600
> To:Geany development list
> Subject:Re: [Geany-Devel] OSX plugin development
>
> Hi Steve,
>
> I found this issue
>
> https://gitlab.kitware.com/cmake/cmake/issues/17101
>
> not sure if it's related.
>
> In your case I suspect either some clash with Homebrew (in this case I
> recommend building in a separate account) or that you built part of the
> dependencies on previous macOS system and then upgraded to High Sierra
> where symbols in system libraries may differ. In this case I'd suggest
> deleting the whole gtk directory and starting over to make sure everything
> is built on the new system.
>
> Jiri
>
>
>
> On Sat, Sep 30, 2017 at 1:09 AM,  wrote:
>
>> Ok, so I got through the dependencies (meta-gtk-osx-core), and ran:
>>
>>
>>
>> export LC_ALL=en_US.UTF-8
>>
>> export LANG=en_US.UTF-8
>>
>> jhbuild -m geany.modules build geany-bundle
>>
>> …
>>
>> *** Building libgit2 *** [14/26]
>>
>> make -j 9
>>
>> [  0%] Linking C shared library libgit2.dylib
>>
>> [ 79%] Built target libgit2_clar
>>
>> dyld: lazy symbol binding failed: Symbol not found: _utimensat
>>
>>   Referenced from: /Users/sblatnick/gtk/inst/bin/cmake
>>
>>   Expected in: /usr/lib/libSystem.B.dylib
>>
>>
>>
>> dyld: Symbol not found: _utimensat
>>
>>   Referenced from: /Users/sblatnick/gtk/inst/bin/cmake
>>
>>   Expected in: /usr/lib/libSystem.B.dylib
>>
>>
>>
>> make[2]: *** [libgit2.dylib] Abort trap: 6
>>
>> make[2]: *** Deleting file `libgit2.dylib'
>>
>> make[1]: *** [CMakeFiles/git2.dir/all] Error 2
>>
>> make: *** [all] Error 2
>>
>> *** Error during phase build of libgit2: ## Error running make -j
>> 9  *** [14/26]
>>
>>
>>
>>   [1] Rerun phase build
>>
>>   [2] Ignore error and continue to install
>>
>>   [3] Give up on module
>>
>>   [4] Start shell
>>
>>   [5] Reload configuration
>>
>>   [6] Go to phase "wipe directory and start over"
>>
>>
>>
>> I’m not sure what is going wrong with building geany itself.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Steve
>>
>>
>>
>> *From:* Devel [mailto:devel-boun...@lists.geany.org] *On Behalf Of *Jirí
>> Techet
>> *Sent:* Friday, September 22, 2017 3:02 AM
>> *To:* Geany development list 
>> *Subject:* Re: [Geany-Devel] OSX plugin development
>>
>>
>>
>> Hi Steve,
>>
>>
>>
>> I slightly remember I got an error like this one in the past but I don't
>> remember what exactly the problem was. Anyway, it's not good to mix
>> dependencies from homebrew and jhbuild. If you have some environment
>> variables set up to link against homebrew libraries, this is what could
>> cause problems. I created a separate account on my machine from which I do
>> the Geany build to be sure nothing like that is set up.
>>
>>
>>
>> If you keep getting the error, you might also consider building python as
>> part of the build process which is then used instead of the system python
>> for the rest of the build. This means running
>>
>>
>>
>> jhbuild bootstrap
>>
>> jhbuild python
>>
>> jhbuild build meta-gtk-osx-bootstrap
>>
>> jhbuild build meta-gtk-osx-core
>>
>>
>>
>> When doing a change like that, it's best to remove the gtk directory
>> because it changes dependencies and basically everything has to be rebuilt.
>>
>>
>>
>> Apart from that everything else should work as described here:
>>
>>
>>
>> https://github.com/geany/geany-osx
>>
>>
>>
>> When al the dependencies are built, you should be able to use the same
>> stuff you use under linux for building your plugin. But be sure to run the
>> build within a jhbuild shell - you need to run
>>
>>
>>
>> jhbuild shell
>>
>>
>>
>> which sets up the environment variables to use the dependencies built by
>> jhbuild after you should be able to build your plugin in a normal way.
>>
>>
>>
>> Let me know if you run into more problems.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Jiri
>>
>>
>>
>> On Fri, Sep 22, 2017 at 12:00 AM,  wrote:
>>
>> I’m trying to build plugins in OSX, and I’m a bit out of my element.
>>
>>
>>
>> (I’ve had problems with my yahoo email not 

Re: [Geany-Devel] OSX plugin development

[Jiří Techet]

Wouldn't moving

gtk_widget_grab_focus(GTK_WIDGET(entry));

to quick_search() help? You could try to call it before/after you show the
dialog to see if it helps.

Jiri

On Wed, Oct 11, 2017 at 9:56 PM, <steve8tr...@yahoo.com> wrote:

> Thanks for telling me about the update on the status of ctags/libgit2.
>
>
>
> So I have an inline search plugin that opens a non-decorated dialog with a
> keyboard shortcut, much like searching text in popular browsers like Chrome
> or Firefox.
>
>
>
> The problem is, when I hit my keyboard shortcut, I don’t get focus in the
> GtkEntry like I used to on linux.  However, I was also using an older
> version of geany at the time I worked on this plugin last on linux.
>
>
>
> Here is the source code for my plugin:  https://github.com/sblatnick/
> geany-plugins/blob/dev/quick-search/src/quick-search.c
>
>
>
> Thanks,
>
>
>
> Steve
>
>
>
> *From:* Jiří Techet [mailto:tec...@gmail.com]
> *Sent:* Wednesday, October 11, 2017 12:18 PM
>
> *To:* Steven Blatnick <steve8tr...@yahoo.com>
> *Cc:* Geany development list <devel@lists.geany.org>
> *Subject:* Re: [Geany-Devel] OSX plugin development
>
>
>
> I don't remember doing anything special regarding focus with Geany. What
> exactly happens?
>
>
>
> By the way the jhbuild modules have been updated upstream with the new
> ctags version so when you rebuild ctags, libgit2 should be compiled alright.
>
>
>
> Jiri
>
>
>
> On Wed, Oct 11, 2017 at 6:28 PM, <steve8tr...@yahoo.com> wrote:
>
> THANK YOU.  I just built and used one of my plugins 
>
>
>
> For some reason, the focus is messed up on this plugin.  Do I need to
> handle window focus differently on mac perhaps?
>
>
>
> Thanks,
>
>
>
> Steve
>
>
>
> *From:* Jiří Techet [mailto:tec...@gmail.com]
> *Sent:* Tuesday, October 10, 2017 12:12 PM
>
> *To:* Steven Blatnick <steve8tr...@yahoo.com>
> *Cc:* Geany development list <devel@lists.geany.org>
> *Subject:* Re: [Geany-Devel] OSX plugin development
>
>
>
> Hi Steve,
>
>
>
> it sounds to me like this bug in cmake:
>
>
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/1295
>
>
>
> You might be able to fix it by updating cmake to the latest version. Check
>
>
>
> Source/jhbuild/modulesets/bootstrap.modules
>
>
>
> and update cmake to the latest release. The modules file also contains
> some patch to cmake - not sure if it's needed even with the latest release
> and if it applies - you might need to remove it.
>
>
>
> Alternatively using XCode 8 should help too in this case as it doesn't
> contain the new function and shouldn't confuse cmake.
>
>
>
> I'll report the issue to gtk-osx so it gets updated in the project.
>
>
>
> By the way, this error happens in Geany plugins dependency which means
> Geany is already built at this point. You should be able to run it from
> jhbuild shell and be also able to test your plugin. You could also edit the
> geany.modules file and remove the libgit2 dependency. This means you won't
> be able to compile the git-changebar plugin but everything else should
> compile fine.
>
>
>
> Jiri
>
>
>
> On Tue, Oct 10, 2017 at 6:27 PM, <steve8tr...@yahoo.com> wrote:
>
> So I tried again with a clean directory after removing libgit2 from
> homebrew, but it appears geany-osx is intended to build with 10.13 and I’m
> using 10.12.6.  I’m still getting stuck on libgit2 somehow.
>
>
>
> Here is what I’m seeing:
>
>
>
> ~/projects/geany/geany-osx master$ jhbuild -m geany.modules build
> geany-bundle
> …
>
> /Users/sblatnick/gtk/source/libgit2-0.24.3/src/unix/posix.h:77:9:
> warning: 'futimens' is only available on macOS 10.13 or newer
> [-Wunguarded-availability-new]
>
> return futimens(f, s);
>
>^~~~
>
> /Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/stat.h:373:5:
> note: 'futimens' has been explicitly marked partial here
>
> int futimens(int __fd, const struct timespec __times[2])
> __API_AVAILABLE(macosx(10.13), ios(11.0), tvos(11.0), watchos(4.0));
>
> ^
>
> /Users/sblatnick/gtk/source/libgit2-0.24.3/src/unix/posix.h:77:9: note:
> enclose 'futimens' in a __builtin_available check to silence this warning
>
> return futimens(f, s);
>
>^~~~
>
> 1 warning generated.
>
> [100%] Linking C executable libgit2_clar
>
> [100%] Built target libgit2_clar
>
> make: *** [all] Error 2
>
> *** Error during phase build of libg

Re: [Geany-Devel] OSX plugin development

[Jiří Techet]

Well, I have no more suggestions then except trying various possibilities
and possibly checking what Geany does as e.g. Find dialog works fine.

To get the built Geany themed, go to the geany-osx directory and copy gtkrc
under ~/.gtkrc-2.0 and then copy gtkrc.theme and close.png into the home
directory too. If you also want the icon theme, start jhbuild shell and run

cp -r Faience $PREFIX/share/icons
./replace_icons.sh

Jiri

On Wed, Oct 11, 2017 at 10:51 PM, <steve8tr...@yahoo.com> wrote:

> Unfortunately, no.  I can’t even select the entry if I click on it with my
> mouse.  I’ve also tried various forms of:
>
>- gtk_widget_grab_default
>- GtkWidget’s “grab-notify” to use gboolean was_grabbed in on_out()
>only when false.
>
>
>
> I will have to keep trying things.  It would seem perhaps GTK has been
> updated since I worked on the plugin.
>
>
>
> Looks like the geany version I am using and the one jhbuild built the
> plugin against are very similar, but I should point out that because of
> theming differences, I am using the dmg packaged version:
>
>
>
> ~/projects/geany/geany-plugins/quick-search/src dev$
> /Applications/Geany.app/Contents/MacOS/geany -V
>
> geany 1.31 (built on 2017-07-17 with GTK 2.24.31, GLib 2.52.2)
>
> ~/projects/geany/geany-plugins/quick-search/src dev$ jhbuild shell
>
> Prefix: /Users/sblatnick/gtk/inst
>
> Entered jhbuild shell, type 'exit' to return.
>
> bash-3.2$ geany -V
>
> geany 1.32 (git >= 3fb94c23) (built on 2017-10-10 with GTK 2.24.31, GLib
> 2.52.2)
>
>
>
> Thanks,
>
>
>
> Steve
>
>
>
> *From:* Jiří Techet [mailto:tec...@gmail.com]
> *Sent:* Wednesday, October 11, 2017 2:27 PM
>
> *To:* Steven Blatnick <steve8tr...@yahoo.com>
> *Cc:* Geany development list <devel@lists.geany.org>
> *Subject:* Re: [Geany-Devel] OSX plugin development
>
>
>
> Wouldn't moving
>
>
>
> gtk_widget_grab_focus(GTK_WIDGET(entry));
>
>
>
> to quick_search() help? You could try to call it before/after you show the
> dialog to see if it helps.
>
>
>
> Jiri
>
>
>
> On Wed, Oct 11, 2017 at 9:56 PM, <steve8tr...@yahoo.com> wrote:
>
> Thanks for telling me about the update on the status of ctags/libgit2.
>
>
>
> So I have an inline search plugin that opens a non-decorated dialog with a
> keyboard shortcut, much like searching text in popular browsers like Chrome
> or Firefox.
>
>
>
> The problem is, when I hit my keyboard shortcut, I don’t get focus in the
> GtkEntry like I used to on linux.  However, I was also using an older
> version of geany at the time I worked on this plugin last on linux.
>
>
>
> Here is the source code for my plugin:  https://github.com/sblatnick/
> geany-plugins/blob/dev/quick-search/src/quick-search.c
>
>
>
> Thanks,
>
>
>
> Steve
>
>
>
> *From:* Jiří Techet [mailto:tec...@gmail.com]
> *Sent:* Wednesday, October 11, 2017 12:18 PM
>
>
> *To:* Steven Blatnick <steve8tr...@yahoo.com>
> *Cc:* Geany development list <devel@lists.geany.org>
> *Subject:* Re: [Geany-Devel] OSX plugin development
>
>
>
> I don't remember doing anything special regarding focus with Geany. What
> exactly happens?
>
>
>
> By the way the jhbuild modules have been updated upstream with the new
> ctags version so when you rebuild ctags, libgit2 should be compiled alright.
>
>
>
> Jiri
>
>
>
> On Wed, Oct 11, 2017 at 6:28 PM, <steve8tr...@yahoo.com> wrote:
>
> THANK YOU.  I just built and used one of my plugins 
>
>
>
> For some reason, the focus is messed up on this plugin.  Do I need to
> handle window focus differently on mac perhaps?
>
>
>
> Thanks,
>
>
>
> Steve
>
>
>
> *From:* Jiří Techet [mailto:tec...@gmail.com]
> *Sent:* Tuesday, October 10, 2017 12:12 PM
>
> *To:* Steven Blatnick <steve8tr...@yahoo.com>
> *Cc:* Geany development list <devel@lists.geany.org>
> *Subject:* Re: [Geany-Devel] OSX plugin development
>
>
>
> Hi Steve,
>
>
>
> it sounds to me like this bug in cmake:
>
>
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/1295
>
>
>
> You might be able to fix it by updating cmake to the latest version. Check
>
>
>
> Source/jhbuild/modulesets/bootstrap.modules
>
>
>
> and update cmake to the latest release. The modules file also contains
> some patch to cmake - not sure if it's needed even with the latest release
> and if it applies - you might need to remove it.
>
>
>
> Alternatively using XCode 8 should help too in this case as it doesn't
> contain the new function a

Re: [Geany-Devel] OSX plugin development

[Jiří Techet]

I don't remember doing anything special regarding focus with Geany. What
exactly happens?

By the way the jhbuild modules have been updated upstream with the new
ctags version so when you rebuild ctags, libgit2 should be compiled alright.

Jiri

On Wed, Oct 11, 2017 at 6:28 PM, <steve8tr...@yahoo.com> wrote:

> THANK YOU.  I just built and used one of my plugins 
>
>
>
> For some reason, the focus is messed up on this plugin.  Do I need to
> handle window focus differently on mac perhaps?
>
>
>
> Thanks,
>
>
>
> Steve
>
>
>
> *From:* Jiří Techet [mailto:tec...@gmail.com]
> *Sent:* Tuesday, October 10, 2017 12:12 PM
> *To:* Steven Blatnick <steve8tr...@yahoo.com>
> *Cc:* Geany development list <devel@lists.geany.org>
> *Subject:* Re: [Geany-Devel] OSX plugin development
>
>
>
> Hi Steve,
>
>
>
> it sounds to me like this bug in cmake:
>
>
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/1295
>
>
>
> You might be able to fix it by updating cmake to the latest version. Check
>
>
>
> Source/jhbuild/modulesets/bootstrap.modules
>
>
>
> and update cmake to the latest release. The modules file also contains
> some patch to cmake - not sure if it's needed even with the latest release
> and if it applies - you might need to remove it.
>
>
>
> Alternatively using XCode 8 should help too in this case as it doesn't
> contain the new function and shouldn't confuse cmake.
>
>
>
> I'll report the issue to gtk-osx so it gets updated in the project.
>
>
>
> By the way, this error happens in Geany plugins dependency which means
> Geany is already built at this point. You should be able to run it from
> jhbuild shell and be also able to test your plugin. You could also edit the
> geany.modules file and remove the libgit2 dependency. This means you won't
> be able to compile the git-changebar plugin but everything else should
> compile fine.
>
>
>
> Jiri
>
>
>
> On Tue, Oct 10, 2017 at 6:27 PM, <steve8tr...@yahoo.com> wrote:
>
> So I tried again with a clean directory after removing libgit2 from
> homebrew, but it appears geany-osx is intended to build with 10.13 and I’m
> using 10.12.6.  I’m still getting stuck on libgit2 somehow.
>
>
>
> Here is what I’m seeing:
>
>
>
> ~/projects/geany/geany-osx master$ jhbuild -m geany.modules build
> geany-bundle
> …
>
> /Users/sblatnick/gtk/source/libgit2-0.24.3/src/unix/posix.h:77:9:
> warning: 'futimens' is only available on macOS 10.13 or newer
> [-Wunguarded-availability-new]
>
> return futimens(f, s);
>
>^~~~
>
> /Applications/Xcode.app/Contents/Developer/Platforms/
> MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/sys/stat.h:373:5:
> note: 'futimens' has been explicitly marked partial here
>
> int futimens(int __fd, const struct timespec __times[2])
> __API_AVAILABLE(macosx(10.13), ios(11.0), tvos(11.0), watchos(4.0));
>
> ^
>
> /Users/sblatnick/gtk/source/libgit2-0.24.3/src/unix/posix.h:77:9: note:
> enclose 'futimens' in a __builtin_available check to silence this warning
>
> return futimens(f, s);
>
>^~~~
>
> 1 warning generated.
>
> [100%] Linking C executable libgit2_clar
>
> [100%] Built target libgit2_clar
>
> make: *** [all] Error 2
>
> *** Error during phase build of libgit2: ## Error running make -j
> 9  *** [14/26]
>
>
>
>   [1] Rerun phase build
>
>   [2] Ignore error and continue to install
>
>   [3] Give up on module
>
>   [4] Start shell
>
>   [5] Reload configuration
>
>   [6] Go to phase "wipe directory and start over"
>
> choice: ^CInterrupted
>
>
>
> These are my homebrew and macport packages currently installed:
>
>
>
> ~/projects/geany/geany-osx master$ brew list
>
> adnsgdbmgobject-introspection jq
> libssh2  nettle   pango   readline
>
> atk gdk-pixbuf  graphite2   libassuan
> libtasn1   nmappcreruby-build
>
> autoconfgettext  harfbuzzlibffi
> libtiff  npthpinentryshared-mime-info
>
> cairo   glibhicolor-icon-themelibgcrypt
> libunistring  oniguruma   pixman   sqlite
>
> colordiff   gmp icu4c   libgpg-error
> libusb   openssl  pkg-config
> the_silver_searcher
>
> fontconfig  gnupg   intltoollibksba
> libxml2  openssl@1.1   python

Re: [Geany-Devel] [ANN] Geany 1.32 is out!

[Jiří Techet]

Hi,

I have re-uploaded the macOS installation image for this release. I used an
incorrect signing certificate for the original binary and it made macOS
warn users upon first launch of the app. I unfortunately didn't see it on
my machine because the wrong certificate was in my keychain (noticed by
Frank, thanks). The problem should be fixed now.

Cheers,

Jiri


On Sun, Nov 19, 2017 at 1:53 PM, Enrico Tröger 
wrote:

> We are happy to announce a new release of Geany!
>
> For a comprehensive list of changes please see
> https://www.geany.org/Documentation/ReleaseNotes.
>
> Some highlights:
>
> * Improve snippet support (visual indicators and more, Thomas Martitz).
> * Improve CLI argument help.
> * Add "Close Documents to the Right" feature.
> * Minor accessibility improvements.
> * Fix crash if plugin manager is opened more than once.
> * Update Python, Assembler and PHP filetypes.
> * Updated translations: ca, de, el, es, fr, it, lt, lv, nl, pt, ru,
>   sk, sv, zh_CN
>
> We want to thank all developers, translators and everyone who
> contributed to this release with patches, feedback, bug reports and
> so on. Thank you!
>
> As usual, all downloads can be found on
> https://www.geany.org/Download/Releases.
>
>
> Happy hacking,
> Enrico
>
>
>
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [Geany-Users] [ANN] Geany 1.33 is out!

[Jiří Techet]

Hi,

just a note the Mac version will be late. The build scripts download some
libraries from Sourceforge which currently doesn't allow wget downloads and
returns the following:

We're sorry -- the Sourceforge site is currently in Disaster Recovery mode,
and currently requires
the use of javascript to function.  Please check back later.

Looks like a DDOS:

https://sourceforge.net/error-404.html

Will build the Mac version as soon as it works.

Cheers,

Jiri


On Sun, Feb 25, 2018 at 3:36 PM, Enrico Tröger 
wrote:

> We are happy to announce a new release of Geany!
>
> For a comprehensive list of changes please see
> https://www.geany.org/Documentation/ReleaseNotes.
>
> Some highlights:
>
> * GTK3 theming improvements and documentation
> * CSS: Update Grid properties
> * Add a note for applying the indent settings in the project preferences
> * Enable popup menu on sidebar and message window notebooks
> * Show status message on attempt to execute empty context action
> * Updated translations: de, el, es, fr, it, lv, pl, pt, tr, ru, zh_CN
>
> We want to thank all developers, translators and everyone who
> contributed to this release with patches, feedback, bug reports and
> so on. Thank you!
>
> As usual, all downloads can be found on
> https://www.geany.org/Download/Releases.
>
>
> Happy hacking,
> Enrico
>
>
> ___
> Users mailing list
> us...@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/users
>
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

Re: [Geany-Devel] [ANN] Geany 1.34 is out!

[Jiří Techet]

I've just uploaded the macOS binary here:

https://download.geany.org/geany-1.34_osx.dmg

For this release I had to disable app signing because the app couldn't be
started with it on OS X 10.10 for some reason. This means that after
installing the app you will have to right-click its icon in the
Applications directory and select "Open" the first time you want to run it
to bypass the signature check.

Cheers,

Jiri

On Sun, Dec 16, 2018 at 1:02 PM Colomban Wendling 
wrote:

> We are happy to announce a new release of Geany!
>
> For a comprehensive list of changes please see:
> https://www.geany.org/Documentation/ReleaseNotes
>
> Some highlights:
>
> * GTK version to build against is now automatically detected.
> * Show part of the file path to show unique items in the go to symbol
> popup (Thomas Martitz).
> * Fix high CPU usage with the Scope plugin (Dimitar Zhekov).
> * Update Scintilla to version 3.10.0.
> * Fix display issues on Windows with HiDPI displays.
> * Fix line breaking with multi-byte characters.
> * Update Python 3.7 keywords and PHP 7.2 tags.
> * New translations: da.
> * Updated translations: de, dk, es, fr, hu, it, ja, pt, sv, sk, uk, ru,
> zh_CN, zh_TW.
>
> We want to thank all developers, translators and everyone who
> contributed to this release with patches, feedback, bug reports and so
> on.  Thank you!
>
> As usual, all downloads can be found on
> https://www.geany.org/Download/Releases.
>
> - Colomban
> ___
> Devel mailing list
> Devel@lists.geany.org
> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
>
___
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel

[Geany-Devel] Re: How to generate geany.txt HTML with meson?

[Jiří Techet via Devel]

Hi Nick,

doesn't

meson -Dhtml-docs=enabled builddir

do the job? You can find all the Geany's configuration options in

https://github.com/geany/geany/blob/master/meson_options.txt

Cheers,

Jiri

On Fri, Feb 10, 2023 at 7:09 PM Nick Treleaven via Devel <
devel@lists.geany.org> wrote:

> Hi all,
> Thanks to Thomas Martitz for adding the meson build system.
>
> After much googling I can't work out how to build geany.html. Please let
> me know.
>
> Thanks,
> Nick
> ___
> Devel mailing list -- devel@lists.geany.org
> To unsubscribe send an email to devel-le...@lists.geany.org
>
___
Devel mailing list -- devel@lists.geany.org
To unsubscribe send an email to devel-le...@lists.geany.org