Nabble - Anjuta - Dev

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-12-07T10:04:59Z

Hi,

Abderrahim Kitouni a écrit :
>> What's the problem here ? You cannot have GError* parameter in a callback or
>> you need to have user_data as the last argument ?
> user_data needs to be the last one (unless there is a GError** which
> needs to be last)

In this case, it's not a problem to put the user_data argument after the
GError* one.

Regards,

Sébastien

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-12-07T08:22:21Z

Hi!

Am Montag, den 07.12.2009, 14:21 +0100 schrieb Abderrahim Kitouni:
> That's what it takes to keep includes how they are, vala 0.7.x only
> support generating a unique header.

hmm, vala -C --header=ianjuta-editor.h ianjuta-editor.vala worked fine
for me generating a single header file. Probably you will need to build
every vala file on it's own so.

> >> IAnjutaBuilderHandle is defined as a typedef to gpointer
> >> IAnjutaLanguageId is defined as typedef to gint (I'm not sure, but
> >> this may work)
> >
> > Doesn't vala support typedefs?
> not yet it seems. but even if it did, I'm afraid it wouldn't allow a
> typedef to a pointer (for memory management reasons).
>
> I think this isn't much and could be fixed by hand.

Yeah, it's probably ok but typedefs make things a lot more readable
sometimes.

Regards,
Johannes

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

signature.asc (204 bytes) Download Attachment

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-12-07T05:21:07Z

Hi,

2009/12/6 Johannes <jhs@...>:
> Hi!
>
>> We would need vala <= 0.6.x and a file per interface.
>> btw, should I put every interface in a file or (I prefer this) group
>> related interfaces in a single file?
>
> <= 0.6??? I would expect that we depend on the latest java version of
That's what it takes to keep includes how they are, vala 0.7.x only
support generating a unique header.

> course. Actually, I don't care too much how the files are organized.
> Having one file per interface sounds fine.
>
>> I think it's possible to output C doc with a bit of tweaking. but
>> speaking of gtk-doc, do we want to keep the docs as they are now (one
>> section per interface) or it is ok to group related interfaces?
>
> I don't have a very strong opinion here either but grouping related
> interfaces could be useful if it doesn't require any extra work.
>
>> >
>> > The file-manager isn't hardcoding them. Once you write a mercurial
>> > plugin that implement IAnjutaVcs the file-manager will use this if it
>> > can detect that the project uses mercurial.
>> That's the problem, it won't be able to detect that the project is
>> using mercurial. It'll only check for .svn and .git directories
>> (that's what I meant by hardcoding git and subversion). What's the
>> best way to do this? just add mercurial (and wait for someone else to
>> complain)? or add all popular VCS's (I think cvs, hg, bzr and darcs
>> are enough), or (that's what I'm leaning towards but this may seem
>> overkill) add a new variable to the plugin file for the vcs directory.
>
> I though that I had added such a variable but as I checked today I say
> that I didn't do that. Probably it a new variable would be a good idea
> if this is save for all other version control systems, like
> DetectionFile=.git

I've tried to do such thing, but the problem is that the git plugin
gets loaded even if the project doesn't use git.
I'll send the diff later, maybe I'm doing something wrong.
>
>> IAnjutaBuilderHandle is defined as a typedef to gpointer
>> IAnjutaLanguageId is defined as typedef to gint (I'm not sure, but
>> this may work)
>
> Doesn't vala support typedefs?
not yet it seems. but even if it did, I'm afraid it wouldn't allow a
typedef to a pointer (for memory management reasons).

I think this isn't much and could be fixed by hand.

Regards,
Abderrahim

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: please help me

2009-12-07T00:32:46Z

On Mon, 2009-12-07 at 03:01 -0500, Sanjaya Liyanage wrote:
> I am developing a plugin for Anjuta.Now I have developed most of the
> parts,but bad news is I am unable to connect the plugin to
> anjuta.Actually I don't know what the exact way.so I can't test my
> plugin.please help me to resolve this.I know that you all are people
> who like new comers joining with open source.please reply.
Just running make install from the project directory should put the
plugin in a place where Anjuta can find it. Anjuta's install location is
determined during the configure process.

HTH,
James

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

please help me

2009-12-07T00:01:24Z

I am developing a plugin for Anjuta.Now I have developed most of the parts,but bad news is I am unable to connect the plugin to anjuta.Actually I don't know what the exact way.so I can't test my plugin.please help me to resolve this.I know that you all are people who like new comers joining with open source.please reply.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-12-06T23:59:25Z

Hi,

Le 6 décembre 2009 22:51, Sébastien Granjoux <seb.sfo@...> a écrit :
> Hi Abderrahim,
>
> Abderrahim Kitouni a écrit :
>>
>> IAnjutaDebugger*Callback have a GError* parameter after the user_data
>> (Again, this may have a fix, but that's not sure)
>
> What's the problem here ? You cannot have GError* parameter in a callback or
> you need to have user_data as the last argument ?
user_data needs to be the last one (unless there is a GError** which
needs to be last)
>
>> btw, GListCallback and GCharCallback don't seem to be used.
>
> You can remove these two types. I have planned to use them in the debugger
> but I have changed my mind.
Ok

Peace,
Abderrahim

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-12-06T13:51:07Z

Hi Abderrahim,

Abderrahim Kitouni a écrit :
> IAnjutaDebugger*Callback have a GError* parameter after the user_data
> (Again, this may have a fix, but that's not sure)

What's the problem here ? You cannot have GError* parameter in a
callback or you need to have user_data as the last argument ?

> btw, GListCallback and GCharCallback don't seem to be used.

You can remove these two types. I have planned to use them in the
debugger but I have changed my mind.

Regards,

Sébastien

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-12-06T09:04:31Z

Hi!

> We would need vala <= 0.6.x and a file per interface.
> btw, should I put every interface in a file or (I prefer this) group
> related interfaces in a single file?

<= 0.6??? I would expect that we depend on the latest java version of
course. Actually, I don't care too much how the files are organized.
Having one file per interface sounds fine.

> I think it's possible to output C doc with a bit of tweaking. but
> speaking of gtk-doc, do we want to keep the docs as they are now (one
> section per interface) or it is ok to group related interfaces?

I don't have a very strong opinion here either but grouping related
interfaces could be useful if it doesn't require any extra work.

> >
> > The file-manager isn't hardcoding them. Once you write a mercurial
> > plugin that implement IAnjutaVcs the file-manager will use this if it
> > can detect that the project uses mercurial.
> That's the problem, it won't be able to detect that the project is
> using mercurial. It'll only check for .svn and .git directories
> (that's what I meant by hardcoding git and subversion). What's the
> best way to do this? just add mercurial (and wait for someone else to
> complain)? or add all popular VCS's (I think cvs, hg, bzr and darcs
> are enough), or (that's what I'm leaning towards but this may seem
> overkill) add a new variable to the plugin file for the vcs directory.

I though that I had added such a variable but as I checked today I say
that I didn't do that. Probably it a new variable would be a good idea
if this is save for all other version control systems, like
DetectionFile=.git

> IAnjutaBuilderHandle is defined as a typedef to gpointer
> IAnjutaLanguageId is defined as typedef to gint (I'm not sure, but
> this may work)

Doesn't vala support typedefs?

> IAnjutaDebugger*Callback have a GError* parameter after the user_data
> (Again, this may have a fix, but that's not sure)

This could probably be difficult. Maybe talk to seb if the error
handling can be made in a more standard way.

> btw, GListCallback and GCharCallback don't seem to be used.
You can probably remove them then.

Regards,
Johannes

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

signature.asc (204 bytes) Download Attachment

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-12-06T08:16:49Z

Hi,

2009/12/1 Johannes Schmid <jhs@...>:

> Hi!
>
>> Actually, I'd like to have only one provider (or maybe one provider
>> per target), so no need to clean up anything when changing editor but
>> rather when closing project.
>
> Well, you only have one provider, you just always connect it to the
> current editor. I don't see another way of doing that because there
> might be one vala, one C and one Python file open and each need
> different providers.

Ok, this is better explained with a patch, I'll try to prepae one
later this week.

>[...]
> Sorry, misunderstood you. Yes, this menu item will move to the
> document-manager soon.
Thanks.

>
>> > I discussed this with Jürg some time back and Vala didn't support nested
>> > namespaces that time. If this can be done now and libanjuta.idl can be
>> The problem with nested namespaces is that they aren't supported by
>> gobject-introspection (there is a bug about this in bugzilla), but why
>> would they be needed for Anjuta?
>
> Well, I would expect:
>
> namespace IAnjuta
> {
> namespace Editor
> {
> interface Assist
> (...)
> }
> }
> But maybe it can be done without nested namespaces. As long as the
> result is equal to to the output of the idl compiler, I am fine with it.

Nested namespaces aren't what you want ;-) this interface's type is
currently IANJUTA_TYPE_EDITOR_ASSIST so the namespace is IAnjuta (and
not IAnjuta.Editor).

>
>> > changed into libanjuta.vala without having to change any other source
>> > file (API remains the same) than I don't the a real reason we shouldn't
>> I'd prefer to split this into 5-6 files instead of one big
>> libanjuta.vala, as it's more maintainable, but if you prefer just one
>> file, it's ok.
>
> Actually, multiple files sound better. But it would be best if vala
> would output one header file for every interface so that the includes
> don't change.

We would need vala <= 0.6.x and a file per interface.
btw, should I put every interface in a file or (I prefer this) group
related interfaces in a single file?
>
>> > do that now that we have vala as external dependency. In addition, vala
>> > is quite simple to install. Documentation will also be important though!
>> Is it ok to use valadoc, or this would be considered as cheating ;-p
>> (seriously, I think it's possible to do something with gtk-doc)
>
> Well, valadoc doesn't output C documentation but only Vala documentation
> and that's definitly not what we want to have.
I think it's possible to output C doc with a bit of tweaking. but
speaking of gtk-doc, do we want to keep the docs as they are now (one
section per interface) or it is ok to group related interfaces?

>
>> In other news, I was able to run a python anjuta plugin using pygi,
>> still crashing randomly, but it seems promising. I have another
>> complaint about file manager hardcoding Git and Subversion (I want to
>> add mercurial), I'll make a patch for this as well.
>
> The file-manager isn't hardcoding them. Once you write a mercurial
> plugin that implement IAnjutaVcs the file-manager will use this if it
> can detect that the project uses mercurial.
That's the problem, it won't be able to detect that the project is
using mercurial. It'll only check for .svn and .git directories
(that's what I meant by hardcoding git and subversion). What's the
best way to do this? just add mercurial (and wait for someone else to
complain)? or add all popular VCS's (I think cvs, hg, bzr and darcs
are enough), or (that's what I'm leaning towards but this may seem
overkill) add a new variable to the plugin file for the vcs directory.

I finished the first pass (converting to vala syntax) over the
libanjuta.idl, seems mostly fine but I have a couple things that won't
work :

IAnjutaBuilderHandle is defined as a typedef to gpointer
IAnjutaLanguageId is defined as typedef to gint (I'm not sure, but
this may work)
IAnjutaDebugger*Callback have a GError* parameter after the user_data
(Again, this may have a fix, but that's not sure)
btw, GListCallback and GCharCallback don't seem to be used.

Regards,
Abderrahim

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol db async functions

2009-12-01T13:07:34Z

Hi Massimo,

Massimo Cora' a écrit :
> Do you see the 'freeze' behaviour even after the first few seconds?
> I can try to improve that code, but for sure if you run an ansyc_query
> the command-thread and the mutexs automatically manage the queues of
> requests.

I haven't looked in details. I think it's due to two asynchronous
queries. Because, I don't see this behavior with GtkSourceView and when
I run Scintilla, I cannot type anything until all types are highlighted.

> well, symbol-db could cancel queries if libgda was able to do that, and
> if sqlite was too. Currently libgda can cancel async queries only, and
> symbol-db is planned to execute only sync queries.
> I don't think it's worth reimplementing the whole core to do async
> queries. They can take 1-2, 3 seconds in the worst cases and for
> full-scan queries, and I see this behaviour in all the IDEs I've used.

Ok, I'm not sure it's really useful now if it's a big change.

Regards,

Sébastien

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol db async functions

2009-12-01T12:40:13Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Sébastien Granjoux wrote:

> Hi Massimo,
>
>
> I can understand that libgda doesn't allow concurrent access.
>
> But, I think we have to do something anyway, currently Scintilla is
> difficult to use and it would be the same for GtkSourceView if the
> symbol-db is used by another plugin. It's really useful that a call to
> anjuta_symbol_manager_search_*_async never blocks.
>
> I think, the symbol-db plugin can queue the request until the first
> access is completed. So, it can try to get the mutex and if it fails,
> just puts the request on hold in a GList and return. Then when the first
> request is completed, it checks if there are some pending requests in
> the list and start them. It does not simplify the code but I thinks it's
> needed.

I've maybe understood the 'freeze' you're seeing on Anjuta's startup.
It's the project_updating procedure, which is done in the main thread
because usually the user doesn't modify many sources of the project
outside Anjuta itself. The switch between a git branch and another could
instead be the reason of the freeze when you fire up Anjuta: many
sources are changed and then they're seen with a different modification
time, and so rescanned.
It should be done instead in a concurrent thread. I didn't go on that
direction because on startup there are many complicated actions done by
symbol-db, and adding over complexity wasn't my aim.
Do you see the 'freeze' behaviour even after the first few seconds?
I can try to improve that code, but for sure if you run an ansyc_query
the command-thread and the mutexs automatically manage the queues of
requests.

>
> I think Johannes has planned a possibility to cancel requests. He has
> removed it from git, I suppose because a db request cannot be cancelled.
> But if we have this pending requests queue, they can be cancelled. So I
> think it would be useful to have a possibility to cancel a request.
>

well, symbol-db could cancel queries if libgda was able to do that, and
if sqlite was too. Currently libgda can cancel async queries only, and
symbol-db is planned to execute only sync queries.
I don't think it's worth reimplementing the whole core to do async
queries. They can take 1-2, 3 seconds in the worst cases and for
full-scan queries, and I see this behaviour in all the IDEs I've used.

regards,
Massimo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksVfyAACgkQcfVTgMRILk1SKACdEUw+v3Z2n4GuL+My+MqCIABC
V4wAniOVgHKdOEGnIGAo3IsdPJVJNPxU
=zaq3
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: new IAnjutaEditorAssist interface

2009-12-01T10:34:37Z

Hi Johannes,

Johannes Schmid a écrit :
> I wanted to keep the name rather short but I am ok with using
> IAnjutaCompletionProvider if that is clearer.

Ok.

> It's not in use yet. I have added some more doc comment to it though.
> The aim for this method is to be able to force something, like showing
> predefined stuff of the macro plugin that isn't connected to the
> context. I need to implement something as a proof-of-concept for the
> macro plugin and things might change a bit in this area.

Ok, I suppose I will be able to do this with Scintilla too.

> I am not entirely sure what you mean here. Actually, the length of the
> text should be cursor_pos - start_iter.

Yes.

> Anyway, looking at the code it really looks like the iter argument in
> activate() isn't very useful as it will always be the current cursor
> position. I have to look closer though.

Ok, I'm waiting more information here. It's not really a big problem
currently. The most annoying point is the performance of the symbol-db
in this use case.

Regards,

Sébastien

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol db async functions

2009-12-01T10:23:09Z

Hi Massimo,

Massimo Cora' a écrit :
> The async stuff starts a thread that accesses the db: the mutexes are
> limited to the most critical resources, but if you run a full-scan query
> on a db you won't be able to access the same critical code before that
> query has finished (and in most cases a full-scan query is slow).
> This is true for almost all the queries in symbol-db-engine-queries.c.
> The feeling of speed you have with async queries is that the query-code
> is detached from the main glib thread, avoiding the gui to flicker when
> trying to update the interface-and-querying at the same time.

Ok.

> If libgda had ever permitted to access db with multiple concurrent
> threads then yes, I would be able to improve that....

I can understand that libgda doesn't allow concurrent access.

But, I think we have to do something anyway, currently Scintilla is
difficult to use and it would be the same for GtkSourceView if the
symbol-db is used by another plugin. It's really useful that a call to
anjuta_symbol_manager_search_*_async never blocks.

I think, the symbol-db plugin can queue the request until the first
access is completed. So, it can try to get the mutex and if it fails,
just puts the request on hold in a GList and return. Then when the first
request is completed, it checks if there are some pending requests in
the list and start them. It does not simplify the code but I thinks it's
needed.

I think Johannes has planned a possibility to cancel requests. He has
removed it from git, I suppose because a db request cannot be cancelled.
But if we have this pending requests queue, they can be cancelled. So I
think it would be useful to have a possibility to cancel a request.

Best Regards,

Sébastien

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-12-01T07:23:12Z

Hi!

> Actually, I'd like to have only one provider (or maybe one provider
> per target), so no need to clean up anything when changing editor but
> rather when closing project.

Well, you only have one provider, you just always connect it to the
current editor. I don't see another way of doing that because there
might be one vala, one C and one Python file open and each need
different providers.

> > What do you mean by the menu item? How should the editor take care of
> > it? The editor already handles the creation and display of the menu but
> > it can't be responsible for the content.
> Edit->Autocomplete. Without the editor taking care of it, every
> language support plugin would potentially want to have one and Vala
> and C++/Java will conflict since C++/Java won't disable it if the file
> is Vala.

Sorry, misunderstood you. Yes, this menu item will move to the
document-manager soon.

> > I discussed this with Jürg some time back and Vala didn't support nested
> > namespaces that time. If this can be done now and libanjuta.idl can be
> The problem with nested namespaces is that they aren't supported by
> gobject-introspection (there is a bug about this in bugzilla), but why
> would they be needed for Anjuta?

Well, I would expect:

namespace IAnjuta
{
namespace Editor
{
interface Assist
(...)
}
}
But maybe it can be done without nested namespaces. As long as the
result is equal to to the output of the idl compiler, I am fine with it.

> > changed into libanjuta.vala without having to change any other source
> > file (API remains the same) than I don't the a real reason we shouldn't
> I'd prefer to split this into 5-6 files instead of one big
> libanjuta.vala, as it's more maintainable, but if you prefer just one
> file, it's ok.

Actually, multiple files sound better. But it would be best if vala
would output one header file for every interface so that the includes
don't change.

> > do that now that we have vala as external dependency. In addition, vala
> > is quite simple to install. Documentation will also be important though!
> Is it ok to use valadoc, or this would be considered as cheating ;-p
> (seriously, I think it's possible to do something with gtk-doc)

Well, valadoc doesn't output C documentation but only Vala documentation
and that's definitly not what we want to have.

> In other news, I was able to run a python anjuta plugin using pygi,
> still crashing randomly, but it seems promising. I have another
> complaint about file manager hardcoding Git and Subversion (I want to
> add mercurial), I'll make a patch for this as well.

The file-manager isn't hardcoding them. Once you write a mercurial
plugin that implement IAnjutaVcs the file-manager will use this if it
can detect that the project uses mercurial.

Regards,
Johannes

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

signature.asc (204 bytes) Download Attachment

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-12-01T05:13:01Z

Hi,

2009/12/1 Johannes Schmid <jhs@...>:
> No, I just meant that the plugin have to be aware that the editor has
> changed and clean up, etc. Currently it just provides a provider only
> for the current editor which doesn't make any different from the
> user-perspective.
Actually, I'd like to have only one provider (or maybe one provider
per target), so no need to clean up anything when changing editor but
rather when closing project.

> What do you mean by the menu item? How should the editor take care of
> it? The editor already handles the creation and display of the menu but
> it can't be responsible for the content.
Edit->Autocomplete. Without the editor taking care of it, every
language support plugin would potentially want to have one and Vala
and C++/Java will conflict since C++/Java won't disable it if the file
is Vala.

> The Gbf namespace is just something used internally by the
> project-manager and the only thing that appears in libanjuta.idl is the
> new_project() method which is really not needed by a language-support
> plugin. So I guess you could just skip that.
I guess this would work for newer gobject-introspection, but won't
work with the fork included in vala. I'll see what it gives once I
have cleaned up the gir files.

>
> I discussed this with Jürg some time back and Vala didn't support nested
> namespaces that time. If this can be done now and libanjuta.idl can be
The problem with nested namespaces is that they aren't supported by
gobject-introspection (there is a bug about this in bugzilla), but why
would they be needed for Anjuta?

> changed into libanjuta.vala without having to change any other source
> file (API remains the same) than I don't the a real reason we shouldn't
I'd prefer to split this into 5-6 files instead of one big
libanjuta.vala, as it's more maintainable, but if you prefer just one
file, it's ok.

As for API changes, last time I looked at this, the only change I saw
is *_GET_INTERFACE instead of *_GET_IFACE but this souldn't be used
outside of the interfaces themselves.
The thing that would need to be changed though is the includes (Vala
would generate a single header file).

> do that now that we have vala as external dependency. In addition, vala
> is quite simple to install. Documentation will also be important though!
Is it ok to use valadoc, or this would be considered as cheating ;-p
(seriously, I think it's possible to do something with gtk-doc)

>
> In a second step we could sort out where error arguments make sense and
> probably remove some.
Yay (This would reduce warnings about uncaught errors)

>
> I am also all for having GObject-introspection support.
Expect patches soon :-)

In other news, I was able to run a python anjuta plugin using pygi,
still crashing randomly, but it seems promising. I have another
complaint about file manager hardcoding Git and Subversion (I want to
add mercurial), I'll make a patch for this as well.

Regards,
Abderrahim

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-11-30T16:10:18Z

Hi!

> >
> > I think the watch on the current editor because otherwise we would have
> > to take care if the editor is changed in the middle of a completion. And
> > it's the solution that currently working well.
> I don't understand this, if the editor is changed in the middle of
> completion, I (as a user) won't expect to have completion in the new
> editor (which seems to be what you're suggesting).
> I'll try to modify it and see how well it goes.

No, I just meant that the plugin have to be aware that the editor has
changed and clean up, etc. Currently it just provides a provider only
for the current editor which doesn't make any different from the
user-perspective.

> I guess it is possible (it's just setting visible to false on the
> action), but I'd still prefer that the menu item be handled by the
> editor. I feel it's more natural this way

What do you mean by the menu item? How should the editor take care of
it? The editor already handles the creation and display of the menu but
it can't be responsible for the content.

> The problem is that GbfProject introduces a third namespace (which is
> just more work) and glib-mkenums is shocking on some macro, so I
> couldn't update to 2.26 (which didn't change api I'm interested in, so
> it kept working).

The Gbf namespace is just something used internally by the
project-manager and the only thing that appears in libanjuta.idl is the
new_project() method which is really not needed by a language-support
plugin. So I guess you could just skip that.

> I'm not sure whether you would accept to replace the current idl
> compiler with Vala, but this would give more flexibility thus allowing
> some functions not to raise errors (and documenting what errors are
> raised) etc. and allows documenting g-i attributes directly in the
> syntax. (the downside is that I'm not sure gtk-doc could be used for
> documenting them, but I hope valac/gtk-doc can be fixed for this).
> (this will also allow to stress test the gir output of vala)
>

I discussed this with Jürg some time back and Vala didn't support nested
namespaces that time. If this can be done now and libanjuta.idl can be
changed into libanjuta.vala without having to change any other source
file (API remains the same) than I don't the a real reason we shouldn't
do that now that we have vala as external dependency. In addition, vala
is quite simple to install. Documentation will also be important though!

In a second step we could sort out where error arguments make sense and
probably remove some.

I am also all for having GObject-introspection support.

Regards,
Johannes

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

signature.asc (204 bytes) Download Attachment

Re: new IAnjutaEditorAssist interface

2009-11-30T15:58:59Z

Hi!

> I have implemented the code completion for Scintilla using the new
> interface. It's committed but I think it should be improved. Anyway I
> have a few questions and remarks on the new interface.
>

Thanks for fixing this so quickly.

> 1. Like IAnjutaEditorAssist, the interface name IAnjutaProvider is too
> general, I think IAnjutaCompletionProvider will be better.

I wanted to keep the name rather short but I am ok with using
IAnjutaCompletionProvider if that is clearer.

>
> 2. In general, we really need to document IAnjutaProvider and
> IAnjutaEditorAssist, it's not obvious and the comment in libanjuta.idl
> are often not really useful.
>
> 3. I haven't implemented the invoke function. It is an example of what I
> call "useless" comment and I think you haven't use it in your code, so I
> don't really know its use.

It's not in use yet. I have added some more doc comment to it though.
The aim for this method is to be able to force something, like showing
predefined stuff of the macro plugin that isn't connected to the
context. I need to implement something as a proof-of-concept for the
macro plugin and things might change a bit in this area.

> 4. In the completion code of Scintilla, I need to get the length of the
> completion in the implementation of ianjuta_editor_assist_proposals, or
> (as we have the start) the end of the text to complete. This is the
> argument iter of ianjuta_provider_populate called previously. Is it
> possible that the provider keeps this value ? In this case we can even
> remove the iter argument of ianjuta_provider_activate, or is there a
> case where both iterators are not identical. I haven't completely
> understood how completion is working in GtkSourceView so perhaps I miss
> something.

I am not entirely sure what you mean here. Actually, the length of the
text should be cursor_pos - start_iter. Actually at least for the way
it's implemented in GtkSourceView, there cannot be anything between
activate and populate as populate is called for each character typed.

Anyway, looking at the code it really looks like the iter argument in
activate() isn't very useful as it will always be the current cursor
position. I have to look closer though.

Regasrds,
Johannes

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

signature.asc (204 bytes) Download Attachment

Re: Symbol db async functions

2009-11-30T13:53:49Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Sébastien Granjoux wrote:

> Hi Massimo,
>
> I have just implemented the completion using the new IAnjutaEditAssist
> interface on scintilla. It use the asynchronous function of symbol-db
> plugin to get new symbols, so it should be less disturbing for the user.
>
> But with Scintilla, it seems to be the opposite. On startup, the editor
> is displayed but I cannot type anything for several seconds.
>
> I think it could be due to the fact that Scintilla already call the
> symbol-db plugin to highlight types defined in the project. Then when I
> start typing a character, the language support plugin is calling the
> symbol-db asynchronous search function too to get possible completion,
> and I suppose that it blocks here.
>

yes, from what I read I think that this could be the problem.
Symbol-db uses mutexes to access db, as libgda doesn't support
concurrent queries to db from a single program instance to the same db.
I.e. you can access the global db and the project db with just one query
per time each.
The async stuff starts a thread that accesses the db: the mutexes are
limited to the most critical resources, but if you run a full-scan query
on a db you won't be able to access the same critical code before that
query has finished (and in most cases a full-scan query is slow).
This is true for almost all the queries in symbol-db-engine-queries.c.
The feeling of speed you have with async queries is that the query-code
is detached from the main glib thread, avoiding the gui to flicker when
trying to update the interface-and-querying at the same time.
But the 'bottle-neck' of the one access per time to db is always present.
These are the pro and cons of event driven programming...

> Do you know what's happen if 2 plugins calls
> ianjuta_symbol_manager_search_*_async ? Is it possible that the second
> call is blocked, perhaps because you have to wait for the creation of
> some thread object ? If yes could you improve this ?
>

If libgda had ever permitted to access db with multiple concurrent
threads then yes, I would be able to improve that....

> Else, I need to dig a bit in the code to see what's happen. I have
> already committed the changes on Scintilla, so you can see yourself
> what's happen.
>

ok I'll have a look,

regards,
Massimo

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksUPt4ACgkQcfVTgMRILk0M2ACbBEDh1kmSEqlq8q64jUo6MxPY
xo4An0C/OPiKgz7m7rRVRukvEKMOENK+
=Uwvw
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

new IAnjutaEditorAssist interface

2009-11-30T12:57:30Z

Hi Johannes,

Johannes Schmid a écrit :
> Thanks, just saw your commit. Sorry, seems I mixed things up a bit in
> language-support with the interfaces.

No, problem. Fixing this was not really difficult.

> IAnjutaEditorCompletion indeed sounds better. I split the interfaces
> because I think they aren't really connected to to keep the interfaces
> (and the method names) cleaner and shorter.

I'm agree.

I have implemented the code completion for Scintilla using the new
interface. It's committed but I think it should be improved. Anyway I
have a few questions and remarks on the new interface.

1. Like IAnjutaEditorAssist, the interface name IAnjutaProvider is too
general, I think IAnjutaCompletionProvider will be better.

2. In general, we really need to document IAnjutaProvider and
IAnjutaEditorAssist, it's not obvious and the comment in libanjuta.idl
are often not really useful.

3. I haven't implemented the invoke function. It is an example of what I
call "useless" comment and I think you haven't use it in your code, so I
don't really know its use.

4. In the completion code of Scintilla, I need to get the length of the
completion in the implementation of ianjuta_editor_assist_proposals, or
(as we have the start) the end of the text to complete. This is the
argument iter of ianjuta_provider_populate called previously. Is it
possible that the provider keeps this value ? In this case we can even
remove the iter argument of ianjuta_provider_activate, or is there a
case where both iterators are not identical. I haven't completely
understood how completion is working in GtkSourceView so perhaps I miss
something.

For the moment, I use the current editor position, but if between the
call to ianjuta_provider_populate and ianjuta_editor_assist_proposals,
the user has typed more characters, I will complete more characters than
the one used for the completion. Perhaps it's the right behavior but I'm
not sure.

Anyway, I was a bit afraid that this interface was too specific to
GtkSourceView way of doing it. But I haven't found any big issue when
implementing it for Scintilla and it's done in a different way. Not all
functions are supported but that's fine. So overall this interface is
good, it just needs to be documented.

Regards,

Sébastien

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: [GDL] How to place a widget in a placeholder?

2009-11-30T12:34:48Z

Hi,

>> I've written a small example in C. It doesn't work, I would like that
the
>> last two items are displayed, respectively, in the left and in the
bottom
>> notebook.
> To get your example to work as expected, you'll need to load the
> layout (using gdl_dock_layout_load_layout) *after* adding the items to
> the dock. (otherwise there wouldn't be what to lay out ;-))

It works fine now, I had forgotten that the plugins are loaded after...

Thank's!

--
Nicolas Joseph

http://www.valaide.org

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Symbol db async functions

2009-11-30T11:55:34Z

Hi Massimo,

I have just implemented the completion using the new IAnjutaEditAssist
interface on scintilla. It use the asynchronous function of symbol-db
plugin to get new symbols, so it should be less disturbing for the user.

But with Scintilla, it seems to be the opposite. On startup, the editor
is displayed but I cannot type anything for several seconds.

I think it could be due to the fact that Scintilla already call the
symbol-db plugin to highlight types defined in the project. Then when I
start typing a character, the language support plugin is calling the
symbol-db asynchronous search function too to get possible completion,
and I suppose that it blocks here.

Do you know what's happen if 2 plugins calls
ianjuta_symbol_manager_search_*_async ? Is it possible that the second
call is blocked, perhaps because you have to wait for the creation of
some thread object ? If yes could you improve this ?

Else, I need to dig a bit in the code to see what's happen. I have
already committed the changes on Scintilla, so you can see yourself
what's happen.

Regards,

Sébastien

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Reverting patch 597365 ?

2009-11-30T10:31:01Z

Hi!

Am Sonntag, den 29.11.2009, 16:31 +0100 schrieb Sébastien Granjoux:
> Hi,
>
> The call tips are working again in Scintilla.

Thanks, just saw your commit. Sorry, seems I mixed things up a bit in
language-support with the interfaces.

> I have seen that you have splited the old IAnjutaEditorAssist interface
> into IAnjutaEditoTip and a new IAnjutaEditorAssist. It's fine for me,
> but I think it would be better to rename the new IAnjutaEditorAssist as
> IAnjutaEditorCompletion or something similar. As it is now take care of
> auto completion only.

IAnjutaEditorCompletion indeed sounds better. I split the interfaces
because I think they aren't really connected to to keep the interfaces
(and the method names) cleaner and shorter.

Regards,
Johannes

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

signature.asc (204 bytes) Download Attachment

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-11-29T11:31:26Z

Hi!

2009/11/27 Johannes Schmid <jhs@...>:

> Hi!
>
>> > * IAnjutaProvider is the new interface that all plugins that want to
>> > provide auto-completion in the editor must provide.
>> I would prefer adding an editor parameter to IAnjutaProvider.populate,
>> as someone might want to add the provider to more than one editor (a
>> workaround is to add a watch on current editor, but I'd prefer a
>> cleaner solution)
>
> I think the watch on the current editor because otherwise we would have
> to take care if the editor is changed in the middle of a completion. And
> it's the solution that currently working well.

I don't understand this, if the editor is changed in the middle of
completion, I (as a user) won't expect to have completion in the new
editor (which seems to be what you're suggesting).
I'll try to modify it and see how well it goes.

>
>> +1
>> One other thing I'd like to point out is that autocomplete menu item
>> should be provided by the editor (i.e. should be removed from
>> cpp-java). This way, I hope there will be no more conflicts between
>> cpp-java and vala plugins (and cpp-java can be used to indent vala
>> code).
>
> I don't see what you mean here. It's perfectly possible to autocomplete
> C/C++ Code but not Vala code in language-support-cpp-java. It is simply
> if() somewhere around assist_install().

I guess it is possible (it's just setting visible to false on the
action), but I'd still prefer that the menu item be handled by the
editor. I feel it's more natural this way

> Is there are current version of the Vala plugin that works?
yes and no, I'm still maintaining it, but it's not compatible with
latest anjuta (>=2.28).

The problem is that GbfProject introduces a third namespace (which is
just more work) and glib-mkenums is shocking on some macro, so I
couldn't update to 2.26 (which didn't change api I'm interested in, so
it kept working).
I see the newproject branch could solve this problem. but it still
needs some work.

(I'm diverging a bit here, following is mostly a brain dump, but I
want to discuss it)
I'd like to fix the gobject-introspection support in anjuta, I hope
it's fine to include gir files in anjuta repo, since they aren't vala
specific (I'm not sure it matters anymore since vala is now approved
as an external dependency). I have a hacked version of
libanjuta-python by Sebastien Granjoux that uses pybank (now pygi),
the problem was that anjuta relies heavily on interfaces which weren't
supported, but now that pygi is nearly there [1], I'll try to clean it
and publish it.

supporting g-i means documenting the interfaces in libanjuta (well,
annotating them for e.g. caller owns the return value, whether null
can be passed etc.)
g-i still has some limitations (e.g. FILE is not supported), but I
think it's useful enough for writing plugins in python (and why not
javascript)

I'm not sure whether you would accept to replace the current idl
compiler with Vala, but this would give more flexibility thus allowing
some functions not to raise errors (and documenting what errors are
raised) etc. and allows documenting g-i attributes directly in the
syntax. (the downside is that I'm not sure gtk-doc could be used for
documenting them, but I hope valac/gtk-doc can be fixed for this).
(this will also allow to stress test the gir output of vala)

Hope this makes sense,
Abderrahim

[1] https://bugzilla.gnome.org/show_bug.cgi?id=602736

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Reverting patch 597365 ?

2009-11-29T07:31:48Z

Hi,

The call tips are working again in Scintilla.

I have seen that you have splited the old IAnjutaEditorAssist interface
into IAnjutaEditoTip and a new IAnjutaEditorAssist. It's fine for me,
but I think it would be better to rename the new IAnjutaEditorAssist as
IAnjutaEditorCompletion or something similar. As it is now take care of
auto completion only.

Regards,

Sébastien

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Compiling Anjuta with a more recent version of Gtk

2009-11-29T04:08:17Z

Hi,

Sébastien Granjoux a écrit :
> Do you know how to do this ? or perhaps I have missed something.

I have been able to compile Anjuta with a newer version of GTK+ after
copying all needed .la file (libunique, gconf-2, Orbit, vte) in
/usr/local/lib and editing these files to use the new path of (GLib,
GTK+, Pango and ATK).

Several programs look for the shared libraries, all should find the
right libraries but all are using different methods.

* There pkg-config, in the configure script which is using
PKG_CONFIG_PATH variable and the .pc files.
* libtool at link time using LD_LIBRARY_PATH and the content of .la files.
* The linker at run time using LD_LIBRARY_PATH.

Regards,

Sébastien

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Reverting patch 597365 ?

2009-11-28T10:13:11Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sébastien Granjoux wrote:

> Hi,
>
> I'm a bit annoyed by Javier's patch for bug
> https://bugzilla.gnome.org/show_bug.cgi?id=597365.
>
> My problem is that it requires gtk 2.17.10 which has been released
> (2.18.0) only a few months ago . It means that in order to compile
> Anjuta from source, I need to reinstall my system every 6 months or
> recompile from source all the GTK libraries. It makes backporting Anjuta
> more difficult too.
>
> I think that limiting us to library version N-2 is better. It means that
> we can apply Javier's patch in 4 or 5 months. What do you think about this ?
>

To avoid these problems I use debian sid, though probably I can use also
the testing. In this way I can stay up-to-date while having a quite
stable system.
In my opinion developing a gnome module requires the latest packages of
the libraries: a development linux box is then necessary. If you'd like
to rely on a stable system maybe a virtual machine where to run the
developing box is required.

regards,
Massimo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAksRaCwACgkQcfVTgMRILk1MHQCZAYhmRI2CODjkO5bAnapRuU6E
/Q4Anj5vaSNwH4pQWfQprYi8qYKNzm5m
=P40G
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Reverting patch 597365 ?

2009-11-28T10:11:23Z

Hi,

Johannes a écrit :
> The other thing I want to mention that a lot of people and especially
> the release-team often forces to drop deprecated code.

Sure, but at least for the previous changes we have about 2 cycles to do
them. Perhaps it's different with gnome 3.0, but if it's only for this
cycle, I understand.

> Anyway, I would like to hear the opions of the other developers here.
> And as sidenote, there is also another patch that would need to be
> reverted, porting from AnjutaMessageArea to the new GtkMessageArea.

I'm waiting a bit, I'm interested to have more opinions too.

It's not just for me, I can reinstall my system every 6 months. But, if
it's a bit annoying for me, I suppose that a "normal" user will find it
even more annoying and would like to keep the same system for a few years.

Regards,

Sébastien

PS: It's not really a problem for the new project manager, I'm working
on a command line program to check it. But I have planned to update
scintilla plugin and check your new interface this week end.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Compiling Anjuta with a more recent version of Gtk

2009-11-28T09:48:18Z

Hi!

I think it's quite painful to try to update such libraries on your own
and usually much easier to use distribution packages (or update to a
more recent version of the distribution.

The only tool I know to help solving this is jhbuild which automates the
process and can install a complete GNOME from sources in a seperate
directory.

Regards,
Johannes

Am Samstag, den 28.11.2009, 18:43 +0100 schrieb Sébastien Granjoux:

> Hi,
>
> My system has Gtk 2.16 while Anjuta needs 2.17.10. I have tried to see
> how I can install a more recent version of Gtk to compile Anjuta.
>
> I have downloaded and tried to compile Gtk 2.18, then downloaded Glib,
> Atk an Pango. I can compile everything and get Gtk 2.18.
>
> But, I still cannot compile Anjuta because it has some dependencies on
> other libraries still using the old version of Gtk or Glib (GConf, vte,
> libunique...). I think the problem is that these dependencies load the
> old version of Glib or Gtk (in /usr/lib) instead of the new one.
>
> I think, I can solve the problem by recompiling from the source all
> these dependencies but at this point it's probably faster to just
> reinstall the whole system. Moreover, as these libraries are binary
> compatible, it shouldn't be necessary.
>
> Do you know how to do this ? or perhaps I have missed something.
>
> Best Regards,
>
> Sébastien
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Anjuta-devel mailing list
> Anjuta-devel@...
> https://lists.sourceforge.net/lists/listinfo/anjuta-devel

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

signature.asc (204 bytes) Download Attachment

Compiling Anjuta with a more recent version of Gtk

2009-11-28T09:43:37Z

Hi,

My system has Gtk 2.16 while Anjuta needs 2.17.10. I have tried to see
how I can install a more recent version of Gtk to compile Anjuta.

I have downloaded and tried to compile Gtk 2.18, then downloaded Glib,
Atk an Pango. I can compile everything and get Gtk 2.18.

But, I still cannot compile Anjuta because it has some dependencies on
other libraries still using the old version of Gtk or Glib (GConf, vte,
libunique...). I think the problem is that these dependencies load the
old version of Glib or Gtk (in /usr/lib) instead of the new one.

I think, I can solve the problem by recompiling from the source all
these dependencies but at this point it's probably faster to just
reinstall the whole system. Moreover, as these libraries are binary
compatible, it shouldn't be necessary.

Do you know how to do this ? or perhaps I have missed something.

Best Regards,

Sébastien

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Reverting patch 597365 ?

2009-11-28T09:43:21Z

Hi!

Well, the usual policy was to not depend on any of the bigger libs
before they haven't been adapted in all major stable distros. gtk+ 2.18
is now in Ubuntu, Fedora and OpenSuSE so I thought it would be ok to
depend on it.

The other thing I want to mention that a lot of people and especially
the release-team often forces to drop deprecated code.

Anyway, I would like to hear the opions of the other developers here.
And as sidenote, there is also another patch that would need to be
reverted, porting from AnjutaMessageArea to the new GtkMessageArea.

Regards,
Johannes

Am Samstag, den 28.11.2009, 13:08 +0100 schrieb Sébastien Granjoux:

signature.asc (204 bytes) Download Attachment

Reverting patch 597365 ?

2009-11-28T04:08:02Z

Hi,

I'm a bit annoyed by Javier's patch for bug
https://bugzilla.gnome.org/show_bug.cgi?id=597365.

My problem is that it requires gtk 2.17.10 which has been released
(2.18.0) only a few months ago . It means that in order to compile
Anjuta from source, I need to reinstall my system every 6 months or
recompile from source all the GTK libraries. It makes backporting Anjuta
more difficult too.

I think that limiting us to library version N-2 is better. It means that
we can apply Javier's patch in 4 or 5 months. What do you think about this ?

Best Regards,

Sébastien

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: [GDL] How to place a widget in a placeholder?

2009-11-27T14:28:54Z

Hi,

Le 23 novembre 2009 21:27, Nicolas Joseph <nicolas.joseph@...> a écrit :
> Sorry, I'm really incompetent, I don't understand :(
>
> I've written a small example in C. It doesn't work, I would like that the
> last two items are displayed, respectively, in the left and in the bottom
> notebook.
To get your example to work as expected, you'll need to load the
layout (using gdl_dock_layout_load_layout) *after* adding the items to
the dock. (otherwise there wouldn't be what to lay out ;-))
To answer your initial question (adding to a placeholder), I guess you
can use: (disclaimer: I haven't tested)
gdl_dock_object_dock (ph, item, GDL_DOCK_NONE)

HTH,
Abderrahim

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-11-27T10:29:57Z

Hi!

> > * IAnjutaProvider is the new interface that all plugins that want to
> > provide auto-completion in the editor must provide.
> I would prefer adding an editor parameter to IAnjutaProvider.populate,
> as someone might want to add the provider to more than one editor (a
> workaround is to add a watch on current editor, but I'd prefer a
> cleaner solution)

I think the watch on the current editor because otherwise we would have
to take care if the editor is changed in the middle of a completion. And
it's the solution that currently working well.

> +1
> One other thing I'd like to point out is that autocomplete menu item
> should be provided by the editor (i.e. should be removed from
> cpp-java). This way, I hope there will be no more conflicts between
> cpp-java and vala plugins (and cpp-java can be used to indent vala
> code).

I don't see what you mean here. It's perfectly possible to autocomplete
C/C++ Code but not Vala code in language-support-cpp-java. It is simply
if() somewhere around assist_install().
Is there are current version of the Vala plugin that works?

Regards,
Johannes

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

signature.asc (204 bytes) Download Attachment

Re: Symbol-db async queries don't return results (and IAnjutaEditorAssist reorganisation)

2009-11-27T09:05:04Z

Hi,

2009/11/21 Johannes Schmid <jhs@...>:

> Related to this I reorganized the IAnjutaEditorAssist framework:
>
> * IAnjutaEditorTip is the new interface for Calltips that is similar to
> the old one except that some methods have been renamed to fit better.
>
> * IAnjutaEditorAssist provides a way to add providers (see below) to the
> editor that will be queried for completions. It also provides a way for
> the providers to add their proposals to the list.
>
> * IAnjutaProvider is the new interface that all plugins that want to
> provide auto-completion in the editor must provide.

I would prefer adding an editor parameter to IAnjutaProvider.populate,
as someone might want to add the provider to more than one editor (a
workaround is to add a watch on current editor, but I'd prefer a
cleaner solution)

>
> The concept is stolen from the new GtkSourceCompletion framework but it
> shouldn't be too difficult to implement it in Scintilla. There will be
> some optional features on the interface such as showing extra
> informations on completion, showing custom widgets (API-Help) but those
> don't need to be implemented.
>
> The reason for all this it to remove duplicated code from the
> completion-providers and to make it easier to add more providers (for
> other languages and for the macros plugin).

+1
One other thing I'd like to point out is that autocomplete menu item
should be provided by the editor (i.e. should be removed from
cpp-java). This way, I hope there will be no more conflicts between
cpp-java and vala plugins (and cpp-java can be used to indent vala
code).

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

Re: Git UI Status Update

2009-11-23T15:41:40Z

On Mon, 2009-11-23 at 19:50 +0100, Sébastien Granjoux wrote:

> Hi James,
>
> James Liggett a écrit :
> > Well, strictly speaking, it doesn't always have to be visible. The plan
> > was that once I got this into Anjuta, I'd have the command bar and the
> > dock in two separate docks in the main Anjuta UI. The dock would be
> > placed in the center region, where the current log viewer is now. The
> > command bar would be placed to the left. So you could hide either one as
> > you please.
>
> Ok.
>
> > But, I would expect that you probably would want the command bar visible
> > in most cases. The whole point of the command bar is to show you what
> > you can do in the view you're looking at.
>
> Isn't it a problem with Anjuta ? It displays several windows at the same
> time. You can have the git window and the editor windows by example at
> the same time, or do you plan to take care of the central window only.

I'd only planned to look at the center portion. It's just an idea
really; I don't know if it'll pan out in practice.

> Ok, as I don't know it I have just take care of the names.
Sorry to have confused you. I really couldn't come up with a better
name. ;)

Thanks,
James

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel