Re: [Geany-devel] Geany Newsletter Issue #5

[Lex Trotman]

Hi Thomas,

Humm, dunno why it didn't work when Matthew and I tried it before, but:

$ cat test.cpp
 #include 
 #include 


extern "C"
{
  PLUGIN_VERSION_CHECK(211)

  PLUGIN_SET_INFO("Test C++","Test C++", "etc", "etc");

  void plugin_init(GeanyData *){}
  void plugin_cleanup(void){}

}

class Test
{
public:
   Test() { std::cout << "Hello from Test" << std::endl; }
   ~Test() { std::cout << "Bye from Test" << std::endl; }
};

static Test test;

$ g++ -c test.cpp -fPIC `pkg-config --cflags ../lib/pkgconfig/geany.pc geany`
$ g++ test.o -o test.so -shared `pkg-config --libs
../lib/pkgconfig/geany.pc geany`
$ cp test.so ../lib/geany
$ geany -c ../config

does call the constructor/destructor for test.  Maybe we got the
mystery incantations wrong :)  It also works using clang++ to compile
test :)

Note, if the plugin isn't loaded the constructor is run when plugin
manager is opened and, if you havn't selected the plugin, the
destructor is run when plugin manager is closed.

When you select the plugin the destructor is run and then the
constructor is run again but this time the destructor is not run when
plugin manager is closed.

So it probably shouldn't do anything in the constructors/destructors
that is slow or that leaves a trace.

[...]
>
> FWIW, does anyone know why I needed to link libstdc++ explicitely in my
> testing?

As shown above Matthew is right, just use g++.

@Frank, sorry, wasn't meaning to blame you ;) just my failing .. ummm
... oh yeah, memory.

Cheers
Lex
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany Newsletter Issue #5

[Matthew Brush]

On 12-05-28 02:24 PM, Thomas Martitz wrote:

Am 28.05.2012 13:27, schrieb Lex Trotman:


This doesn't actually call the C++ constructors/destructors in the way
they would be in normally be if the plugin had been statically linked.

This simply labels a C function to be called at dlopen time. It may
be used to do some initialisation, but you would have to manually call
each constructor, ... too error prone, Franks advice to create
everything dynamically is sound.



I meant to say that global/static constructors/destructors are in fact
called when a library is dlopened(), regardless of the language of
calling code.



I think that blurb in the newsletter was written before it was realized 
that the whole C++ runtime/magic was already present because of 
Scintilla. I wrote the paragraphs and IIRC Lex reviewed/revised it, but 
I can say I'm probably the least qualified to write about how to use C++ :)





$ gcc -o libtestcpp.so -shared -fPIC test.cpp -g -lstdc++
-Wl,--no-undefined


$ ./test
Hello from Test
hello from extern C function
Bye from Test



FWIW, does anyone know why I needed to link libstdc++ explicitely in my
testing?



Just guessing but maybe it's because of using the `gcc` command instead 
of `g++`? I only ever experienced needing to link to it explicitly with 
Geany/Scintilla. In my own pure C++ code it's never needed.


Cheers,
Matthew Brush

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany multicursors patch

[Davide Andreoli]

2012/5/25 Colomban Wendling :
> Le 23/05/2012 21:19, Davide Andreoli a écrit :
>> [...]
>>
>> Ok, I also finished the snippets part, super-easy at the end :)
>> you can find my new 'supersnip' branch at:
>> https://github.com/DaveMDS/geany/tree/supersnip
>> also included the multicursor 3 lines (needed)
>>
>> Here you can read the description, one example and
>> the commit diff for the "super snippets" patch:
>> https://github.com/DaveMDS/geany/commit/c7035d58f2b8b50df96e9cd9fbf6f9e73ec2ce74
>>
>> I think also this one is small enough for the core...29 lines :)
>>
>> [...]
>
> No review yet but a small test: it looks pretty good, but it has a bug:
> when no %wordN% is defined but there is a %cursor%, a second selection
> is created at the very position of the cursor.

:O ok, I broke all the "normal" snippet...incredible I did'n noticed...
fixed with commit:
https://github.com/DaveMDS/geany/commit/d12c85496c64be23a9e6b2d225ff3fc818c87f5e

Thanks for the report!
davemds

>
> Cheers,
> Colomban
> ___
> Geany-devel mailing list
> Geany-devel@uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany Newsletter Issue #5

[Thomas Martitz]

Am 28.05.2012 13:27, schrieb Lex Trotman:


This doesn't actually call the C++ constructors/destructors in the way
they would be in normally be if the plugin had been statically linked.

This simply labels a C function to be called at dlopen time.  It may
be used to do some initialisation, but you would have to manually call
each constructor, ... too error prone, Franks advice to create
everything dynamically is sound.



I meant to say that global/static constructors/destructors are in fact 
called when a library is dlopened(), regardless of the language of 
calling code.


Anyway, I thought an example illustrates it better:


$ cat test.c
#include 
#include 
#include 
int main()
{
void* h = dlopen("/tmp/foo/libtestcpp.so", RTLD_NOW);
if (!h) { printf("no lib %s\n", dlerror()); exit(-1); }
void (*fn)(void) = dlsym(h, "hello");
if (!fn) exit(-2);
fn();
dlclose(h);
return 0;
}


$ gcc -o test test.c -ldl -g


$ cat test.cpp
#include 

namespace std {

class Test
{
public:
Test() { cout << "Hello from Test" << endl; }
~Test() { cout << "Bye from Test" << endl; }
};

static Test test;

}

extern "C" {

#include 

void hello(void)
{
printf("hello from extern C function\n");
}

}


$ gcc -o libtestcpp.so -shared -fPIC test.cpp -g -lstdc++ 
-Wl,--no-undefined



$ ./test
Hello from Test
hello from extern C function
Bye from Test



FWIW, does anyone know why I needed to link libstdc++ explicitely in my 
testing?


Best regards.
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany multicursors patch

[Davide Andreoli]

2012/5/26 Lex Trotman :
> On 26 May 2012 04:50, Colomban Wendling  wrote:
>> Le 23/05/2012 21:19, Davide Andreoli a écrit :
>>> 2012/5/23 Lex Trotman :
 [...]

 IMHO the multiselection is now small enough (3 lines)  that a plugin
 would be overkill :)

 Davide, what is the impact of enabling this, how do existing features
 interact with multiple selections? Do any Geany actions that use
 selections fail when fed a multi-selection? How does paste work? And
 what if I actually select some text (ie ctrl-swipe not just click).
>>>
>>> I did not found any regression nor any strangeness or conflict yet.
>>> Yes, you can make real multiple selections (Ctrl+Alt+Drag) and the behavior
>>> is quite always the expected: 'copy' while multiple selection active will
>>> put in the clipboard all the selected text merged, 'paste' instead will only
>>> paste at the primary selection, 'typing' with multiple selection will do the
>>> same as a single selection (selected text cleared). All other commands
>>> should always work normally on the primary selection(the last one done).
>>
>> After a very small time of testing I see:
>>
>> *) Replace (^H) "inside selection" doesn't work properly when there are
>> multiple selections (the replacement is only done in the last
>> selection), while it works fine with rectangular selections.
>
> Agree this one would be expected to work in all selections, and would
> be very useful.
>
>
>> document_replace_sel() should probably be updated then.

Yes, exactly, thanks for pointing the right direction!
I reimplemented that function to work with multiple selections
commit:
https://github.com/DaveMDS/geany/commit/286b26a08f9bb059677b5c743efe5ecb26b9bb14

It works flawlessy in my test, but this is sensitive area,
please test well !

>>
>> BTW, I'm wondering whether Scintilla has two distinct modes for
>> rectangular/multiple selections or if a rectangular selection is a
>> specialized multiple selection (in which case one single code for
>> handling multisel would be enough on our side).
>>
>
> "Rectangular selections are handled as multiple selections although
> the original rectangular range is remembered so that subsequent
> operations may be handled differently for rectangular selections. For
> example, pasting a rectangular selection places each piece in a
> vertical column." from Scintilla.
>
> Doesn't say how its "remembered" though.
>
>> *) Duplicate line/selection works just fine
>>
>> *) "Toggle case of the selection" is buggy, it puts the newly-cased text
>> altogether on the last selection.  Works fine with rectangular selection.
>
> maybe needs www.scintilla.org/ScintillaDoc.html#SCI_SETMULTIPASTE set

Where is the "Toggle case of the selection" I can't find it :/
it's is some plugin ?

btw I added the SETMULTIPASTE command with the commit:
https://github.com/DaveMDS/geany/commit/d64ea851afc60dc7729eff033a00532340184dd4

So that now "paste" will work at each selections, not just the
'primary'. like rectangular do.


>>
>> *) Almost all selection-based actions (like "Select current line(s)",
>> "toggle line(s) commentation", etc.) only selects the line of the last
>> selection
>>
>>
>> IMO Replace and Toggle Case must be updated to work properly.  The other
>> selection-based commands that doesn't handle the thing really fine would
>> benefit from handling it, but their result isn't as unexpected as the
>> two cited above.
>>
>
> Just document them to only work on single selection would be ok.
>
> Cheers
> Lex
>
>
>>
>> Regards,
>> Colomban
>> ___
>> Geany-devel mailing list
>> Geany-devel@uvena.de
>> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
> ___
> Geany-devel mailing list
> Geany-devel@uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany Newsletter Issue #5

[Frank Lanitz]

Am 28.05.2012 13:27, schrieb Lex Trotman:
> On 28 May 2012 19:59, Thomas Martitz
>  wrote:
>> Am 28.05.2012 11:27, schrieb Frank Lanitz:
>>>
>>> It's important to note that the dynamic library loading mechanism
>>> that loads plugins is C functionality and does not know about C++
>>> constructors. This means that global and static objects in the
>>> plugin will *not* have their constructors called when the plugin is
>>> loaded. Use dynamically created objects as show in the above example.
>>>
>>
>> I'm not sure this is true. libdl should handle this (i.e. call functions
>> point to in the init and fini sections).
>>
>> |__attribute__ ((constructor)) and||__attribute__  ((destructor)) is
>> supported works with as well.
>>
> 
> This doesn't actually call the C++ constructors/destructors in the way
> they would be in normally be if the plugin had been statically linked.
> 
> This simply labels a C function to be called at dlopen time.  It may
> be used to do some initialisation, but you would have to manually call
> each constructor, ... too error prone, Franks advice to create
> everything dynamically is sound.

It's not mine, as I really don't have a clue about this section. Content
was introduced by a patch IIRC by Matthew and you ;)

Cheers,
Frank



signature.asc
Description: OpenPGP digital signature
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany Newsletter Issue #5

[Lex Trotman]

On 28 May 2012 19:59, Thomas Martitz
 wrote:
> Am 28.05.2012 11:27, schrieb Frank Lanitz:
>>
>> It's important to note that the dynamic library loading mechanism
>> that loads plugins is C functionality and does not know about C++
>> constructors. This means that global and static objects in the
>> plugin will *not* have their constructors called when the plugin is
>> loaded. Use dynamically created objects as show in the above example.
>>
>
> I'm not sure this is true. libdl should handle this (i.e. call functions
> point to in the init and fini sections).
>
> |__attribute__ ((constructor)) and||__attribute__  ((destructor)) is
> supported works with as well.
>

This doesn't actually call the C++ constructors/destructors in the way
they would be in normally be if the plugin had been statically linked.

This simply labels a C function to be called at dlopen time.  It may
be used to do some initialisation, but you would have to manually call
each constructor, ... too error prone, Franks advice to create
everything dynamically is sound.

Cheers
Lex

> Best regards.
> |
>
> ___
> Geany-devel mailing list
> Geany-devel@uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

Re: [Geany-devel] Geany Newsletter Issue #5

[Thomas Martitz]

Am 28.05.2012 11:27, schrieb Frank Lanitz:

It's important to note that the dynamic library loading mechanism
that loads plugins is C functionality and does not know about C++
constructors. This means that global and static objects in the
plugin will *not* have their constructors called when the plugin is
loaded. Use dynamically created objects as show in the above example.



I'm not sure this is true. libdl should handle this (i.e. call functions 
point to in the init and fini sections).


|__attribute__ ((constructor)) and||__attribute__  ((destructor)) is supported 
works with as well.

Best regards.
|

___
Geany-devel mailing list
Geany-devel@uvena.de
https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

[Geany-devel] Geany Newsletter Issue #5

[Frank Lanitz]

Geany Newsletter #5
---

1   About Geany
2   New translations and updates
3   Wiki available
4   C++ plugins supported
5   Plugins
5.1 New Plugins
5.1.1   GeanyPyflakes
5.1.2   GeniusPaste
5.2 GeanyPG
6   Geany local
7   Geany Packages for Fedora
8   About this newsletter 


1 About Geany
=

Geany is a small and lightweight Integrated Development Environment.
It was developed to provide a small and fast IDE, which has only a
few dependencies from other packages. Another goal was to be as
independent as possible from a special Desktop Environment like KDE
or GNOME - Geany only requires the GTK2 runtime libraries.

More information about Geany can be found at
`geany.org `_.



2 New translations and updates
==

Since our last newsletter a number of translations has been updated
or newly added to Geany. New translations are:

* Arabian
* Indonesian
* Lithuanian
* Mongolian (back in 2011)

But also translations like German, Kazakh, Hungarian, Italian,
Traditional Chinese and Swedish translations have been updated
during the last roughly four month.


3 Wiki available


We set up a wiki for additional documentation and resources related 
to Geany at http://wiki.geany.org. Anyone can contribute to the wiki 
simply by registering and then logging in.

In the wiki you can find configuration snippets and tips, snippets for
various programming languages and many additional tags files to enhance
Geany's autocompletion features.

Everybody is welcome to add additional useful content to the wiki.


4 C++ plugins supported
===

Geany's public plugin API headers have been updated to support 
inclusion into C++ code. Most of the changes involve adding `extern 
"C" {...}` blocks around the public headers' code (by way of GLIB's 
`G_BEGIN_DECLS` and `G_END_DECLS` macros) to make them easier to 
include, so the C++ code doesn't need to do this.

You can now write plugins in C++ and they will be loadable by Geany 
at run-time. Of course using Geany's API will still involve using C 
in your code, but the rest of your plugin can use whatever C++ 
features you want. You can even use gtkmm [1] in your plugin if you 
want.

Any of the symbols Geany looks up at run-time must not have their 
names mangled by the compiler. To avoid this, put that code inside 
an `extern "C"` block.

Here's an example of Geany's Hello World plugin from the Plugin 
HowTo [2] ported to C++::

#include 

class HelloWorld
{
private:
gchar *hello_message;
GtkWidget *main_menu_item;

public:
HelloWorld(const gchar *message);
~HelloWorld();
void SayHelloWorld();
};

static HelloWorld *hello;

extern "C"
{
GeanyPlugin *geany_plugin;
GeanyData   *geany_data;
GeanyFunctions  *geany_functions;

PLUGIN_VERSION_CHECK(211)
PLUGIN_SET_INFO("HelloWorld C++",
"Just another tool to say hello 
world, this time in C++",
"1.0", "John Doe 
");

void plugin_init(GeanyData *data)
{
hello = new HelloWorld("Hello C++ World");
}

void plugin_cleanup(void)
{
delete hello;
}

static void on_menu_item_clicked(GtkMenuItem *item, gpointer 
user_data)
{
hello->SayHelloWorld();
}
}

HelloWorld::HelloWorld(const gchar *message)
{
hello_message = g_strdup(message);
main_menu_item = gtk_menu_item_new_with_mnemonic("Hello World");
gtk_widget_show(main_menu_item);

gtk_container_add(GTK_CONTAINER(geany->main_widgets->tools_menu), 
main_menu_item);
g_signal_connect(main_menu_item, "activate", 
G_CALLBACK(on_menu_item_clicked), NULL);
}

HelloWorld::~HelloWorld()
{
g_free(hello_message);
gtk_widget_destroy(main_menu_item);
}

void HelloWorld::SayHelloWorld()
{
dialogs_show_msgbox(GTK_MESSAGE_INFO, "%s", hello_message);
}

It's important to note that the dynamic library loading mechanism 
that loads plugins is C functionality and does not know about C++ 
constructors. This means that global and static objects in the 
plugin will *not* have their constructors called when the plugin is 
loaded. Use dynamically created objects as show in the above example.

These changes will be available in the next Geany release but you 
can start using them