From zarevucky.jiri at gmail.com Tue Sep 21 20:03:24 2010 From: zarevucky.jiri at gmail.com (=?UTF-8?Q?Ji=C5=99=C3=AD_Z=C3=A1rev=C3=BAcky?=) Date: Tue, 21 Sep 2010 22:03:24 +0200 Subject: [Valencia] Valencia and VTG collaboration / merge Message-ID: <1285099404.2271.32.camel@jury-laptop> Hello everyone. I'm quite sure you guys at Yorba know about Vala Toys for GEdit. It is a GEdit plugin, very similar to Valencia, which does basically the same thing. This duplicity is unhealthy and it is my belief those two should become a single project. I've talked to the VTG developer (hi sejerpz :)) and he too agrees with my view of the situation, and is open to discussion. As for me, I'm just a really interested third party who'd like to see all the effort benefit everyone. I've been using Valencia for a while now and started trying out VTG, which I found out to be more sophisticated (even though some things are better dealt with in Valencia), but basically the same thing! So the main question here is whether you guys are open to such possibilities and what are your opinions. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From dapal at debian.org Wed Sep 22 09:37:15 2010 From: dapal at debian.org (David Paleino) Date: Wed, 22 Sep 2010 11:37:15 +0200 Subject: [Valencia] Language support for Genie Message-ID: <20100922113715.1b62ad84@pingu> Hello, I just packaged Valencia for Debian [1] and, as a previous poster commented, I hope you can merge with VTG :) It would be nice if Valencia also supported Genie. Any other Genie-lover here? :) Thank you, David [1]: http://ftp-master.debian.org/new/gedit-valencia-plugin_0.3.0-1.html -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From adam at yorba.org Wed Sep 22 19:41:11 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 22 Sep 2010 12:41:11 -0700 Subject: [Valencia] Language support for Genie In-Reply-To: <20100922113715.1b62ad84@pingu> References: <20100922113715.1b62ad84@pingu> Message-ID: <4C9A5BD7.2020609@yorba.org> David, thanks for packaging Valencia for Debian! Adding Genie support to Valencia would be a major undertaking, since Valencia contains a Vala parser and we'd have to write a second parser to handle Genie's syntax. The core Valencia team is unlikely to implement that any time soon, but we'd happily accept a patch if someone cares to write one. cheers adam On 09/22/2010 02:37 AM, David Paleino wrote: > Hello, > I just packaged Valencia for Debian [1] and, as a previous poster commented, I > hope you can merge with VTG :) > > It would be nice if Valencia also supported Genie. Any other Genie-lover > here? :) > > Thank you, > David > > [1]: http://ftp-master.debian.org/new/gedit-valencia-plugin_0.3.0-1.html > > > > _______________________________________________ > Valencia mailing list > Valencia at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/valencia From dapal at debian.org Wed Sep 22 19:53:54 2010 From: dapal at debian.org (David Paleino) Date: Wed, 22 Sep 2010 21:53:54 +0200 Subject: [Valencia] Language support for Genie References: <20100922113715.1b62ad84@pingu> <4C9A5BD7.2020609@yorba.org> Message-ID: <20100922215354.5fd859c2@pingu> On Wed, 22 Sep 2010 12:41:11 -0700, Adam Dingle wrote: > David, > > thanks for packaging Valencia for Debian! > > Adding Genie support to Valencia would be a major undertaking, since > Valencia contains a Vala parser and we'd have to write a second parser > to handle Genie's syntax. The core Valencia team is unlikely to > implement that any time soon, but we'd happily accept a patch if someone > cares to write one. I suspected that, after seeing the code for the Vala parser :) However, I'm not yet proficient with Vala (a newbie, really), so I don't believe I would be able to do that. Maybe in future... :) Thanks for your reply! David -- . ''`. Debian developer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 ----|---- http://deb.li/dapal `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From adam at yorba.org Wed Sep 22 20:48:11 2010 From: adam at yorba.org (Adam Dingle) Date: Wed, 22 Sep 2010 13:48:11 -0700 Subject: [Valencia] Valencia and VTG collaboration / merge In-Reply-To: <1285099404.2271.32.camel@jury-laptop> References: <1285099404.2271.32.camel@jury-laptop> Message-ID: <4C9A6B8B.6000905@yorba.org> Jiri, > I'm quite sure you guys at Yorba know about Vala Toys for GEdit. It is a > GEdit plugin, very similar to Valencia, which does basically the same > thing. This duplicity is unhealthy and it is my belief those two should > become a single project. I've talked to the VTG developer (hi > sejerpz :)) and he too agrees with my view of the situation, and is open > to discussion. thanks for the suggestion. I'm the primary designer and coauthor of Valencia. Yes, we're certainly aware that Valencia and Vala Toys for Gedit are projects with similar goals. We could certainly discuss either having these become a single project as you suggest, or otherwise sharing some code between the projects. If we were to merge into a single project, then we'd presumably want to deprecate one code base and move all developers into the other project. But nobody wants to lose any features, so we'd need to implement all missing features in the code base that stays alive. I just tried out VTG for the first time in a while - I built and installed vtg-0.10.2. Here are the features I noticed that are in Valencia that seem to be missing in VTG: 1. Valencia does not require a Vala project to use Autotools. 2. With Valencia, I can simply drag in a .vala file and start browsing its symbols immediately. I don't need to create a project definition at all; Valencia simply notices where the .vala file is and assumes that all .vala files nearby are part of the same project. 3. Valencia seems much more stable than VTG. Within the first few minutes of using VTG, I saw lots of console output including the following and a segmentation fault: (gedit:23758): Gtk-WARNING **: Inserting action group 'ProjectManagerActionGroup' into UI manager which already has a group with this name ... (gedit:23758): GLib-CRITICAL **: g_strrstr: assertion `haystack != NULL' failed ** (gedit:23758): CRITICAL **: vtg_symbol_completion_provider_lookup_visible_symbols_in_scope: assertion `word != NULL' failed ... 4. Valencia displays the name of the class containing the cursor in the Gedit status bar (which is very helpful when you've jumped to a symbol and don't know what class you've ended up in). 5. Valencia can find some symbols that VTG cannot. For example, in Valencia I can click on any local variable or parameter and jump to its definition; I haven't seen this work in VTG. 6. Valencia contains a Search -> Go to Outer Scope command (Ctrl+F12) that jumps to the method or class containing the cursor position; I don't see anything like this in VTG. So if you (or we?) could implement all of these (plus any others I haven't noticed) in VTG then we could think about deprecating Valencia and all using VTG instead. I'll point out that (1) and (2) are especially important to the Valencia developers; we need to use Valencia with Yorba's own projects written in Vala (e.g. Shotwell, Fillmore, Valencia itself) which don't use autotools. (3) is equally important: we need our gedit plugin to be rock-solid and to never emit GLib criticals or warnings. Or, conversely, we could conceivably add VTG's missing features to Valencia and then we could migrate all our efforts to Valencia. I don't know VTG well so I can't easily make a list of its features which are missing in Valencia, but at first glance I see that VTG has autotools support and also appears to have somewhat more sophisticated autocompletion (or, at least, it looks formatted more nicely). If you guys want to make a list of such features than we could certainly discuss this possible direction. Finally, I'll say that the Valencia developers are relatively busy with other projects (Shotwell and Fillmore) now so, sadly, we wouldn't have a ton of time to work on this merge. Valencia works pretty well for our needs and so we're not necessarily looking for large changes now. If you guys are excited about the merge and want to implement the missing features in either program then we would be interested, but we probably couldn't take on much of the work ourselves at this time. Nevertheless, if you remain interested in this then we'd be happy to continue the discussion, either by email or by IRC if you prefer. And in any case I'm glad we're all working on making Vala more useful for everyone. :) adam On 09/21/2010 01:03 PM, Ji?? Z?rev?cky wrote: > Hello everyone. > I'm quite sure you guys at Yorba know about Vala Toys for GEdit. It is a > GEdit plugin, very similar to Valencia, which does basically the same > thing. This duplicity is unhealthy and it is my belief those two should > become a single project. I've talked to the VTG developer (hi > sejerpz :)) and he too agrees with my view of the situation, and is open > to discussion. > > As for me, I'm just a really interested third party who'd like to see > all the effort benefit everyone. I've been using Valencia for a while > now and started trying out VTG, which I found out to be more > sophisticated (even though some things are better dealt with in > Valencia), but basically the same thing! > > So the main question here is whether you guys are open to such > possibilities and what are your opinions. :) > > > > _______________________________________________ > Valencia mailing list > Valencia at lists.yorba.org > http://lists.yorba.org/cgi-bin/mailman/listinfo/valencia From zarevucky.jiri at gmail.com Wed Sep 22 22:12:01 2010 From: zarevucky.jiri at gmail.com (=?UTF-8?Q?Ji=C5=99=C3=AD_Z=C3=A1rev=C3=BAcky?=) Date: Thu, 23 Sep 2010 00:12:01 +0200 Subject: [Valencia] Valencia and VTG collaboration / merge In-Reply-To: <4C9A6B8B.6000905@yorba.org> References: <1285099404.2271.32.camel@jury-laptop> <4C9A6B8B.6000905@yorba.org> Message-ID: <1285193521.7302.79.camel@jury-laptop> Adam Dingle p??e v St 22. 09. 2010 v 13:48 -0700: > thanks for the suggestion. I'm the primary designer and coauthor of > Valencia. Yes, we're certainly aware that Valencia and Vala Toys for > Gedit are projects with similar goals. We could certainly discuss > either having these become a single project as you suggest, or otherwise > sharing some code between the projects. > I glad you like the idea. I was a little afraid you wouldn't. :) > If we were to merge into a single project, then we'd presumably want to > deprecate one code base and move all developers into the other project. > But nobody wants to lose any features, so we'd need to implement all > missing features in the code base that stays alive. I just tried out > VTG for the first time in a while - I built and installed vtg-0.10.2. > Here are the features I noticed that are in Valencia that seem to be > missing in VTG: > > 1. Valencia does not require a Vala project to use Autotools. > > 2. With Valencia, I can simply drag in a .vala file and start browsing > its symbols immediately. I don't need to create a project definition at > all; Valencia simply notices where the .vala file is and assumes that > all .vala files nearby are part of the same project. > I completely agree. As a matter of fact, I'm currently thinking of making VTG more flexible in this regard by implementing a generic project/workspace handling library, partly based on VTG's own code. > 3. Valencia seems much more stable than VTG. Within the first few > minutes of using VTG, I saw lots of console output including the > following and a segmentation fault: > > (gedit:23758): Gtk-WARNING **: Inserting action group > 'ProjectManagerActionGroup' into UI manager which already has a group > with this name > ... > (gedit:23758): GLib-CRITICAL **: g_strrstr: assertion `haystack != NULL' > failed > > ** (gedit:23758): CRITICAL **: > vtg_symbol_completion_provider_lookup_visible_symbols_in_scope: > assertion `word != NULL' failed > ... > I noticed that too earlier, but now it works quite well for me (though I have no idea what changed). We'll surely need to find the cause of these problems. > 4. Valencia displays the name of the class containing the cursor in the > Gedit status bar (which is very helpful when you've jumped to a symbol > and don't know what class you've ended up in). > > 5. Valencia can find some symbols that VTG cannot. For example, in > Valencia I can click on any local variable or parameter and jump to its > definition; I haven't seen this work in VTG. > > 6. Valencia contains a Search -> Go to Outer Scope command (Ctrl+F12) > that jumps to the method or class containing the cursor position; I > don't see anything like this in VTG. > These seem fairly simple. I think it will be easy to add them, including any further missing functionality. By the way, while afrodite directly utilizes libvala for parsing (from my quick look at the sources, correct me if I'm wrong), Valencia is very fast thanks to its custom parser. I think it would be a good idea to reuse that in any case. > So if you (or we?) could implement all of these (plus any others I > haven't noticed) in VTG then we could think about deprecating Valencia > and all using VTG instead. [...] > > Or, conversely, we could conceivably add VTG's missing features to > Valencia [...] I have a third idea. We could move what is good in Valencia to VTG (e.g. the parser), fix all the issues, and then go with VTG but call it Valencia. I personally think Valencia is a way cooler name. :) As for VTG structure itself, for example the Afrodite library should in my opinion be a separate product in the sense of having its own repository and packages. There are already other projects using it (namely Valide and I think MonoDevelop plugin). That means another way to achieve our goal could be to separate the "library parts" of VTG and port Valencia to using them. (consider that a wild guess, I haven't actually studied the codes yet, so I don't know if that would be worth the time) However, developing the project as a loose independent set of relevant libraries with small actual plugin binding them together for GEdit (which VTG partly is already) is a road worth considering, due to the potential for reuse by other plugins/IDEs. > Finally, I'll say that the Valencia developers are relatively busy with > other projects (Shotwell and Fillmore) now so, sadly, we wouldn't have a > ton of time to work on this merge. Valencia works pretty well for our > needs and so we're not necessarily looking for large changes now. If > you guys are excited about the merge and want to implement the missing > features in either program then we would be interested, but we probably > couldn't take on much of the work ourselves at this time. > > Nevertheless, if you remain interested in this then we'd be happy to > continue the discussion, either by email or by IRC if you prefer. And > in any case I'm glad we're all working on making Vala more useful for > everyone. :) > Shotwell and Fillmore are great projects! Keep keeping busy with them. ;) As I said, I'm slowly getting involved, and I do want to make this happen, so me and sejerpz could possibly make the necessary improvements/changes with little to no help. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Toto je digit?ln? podepsan? ??st zpr?vy URL: From michael.silvanus at gmail.com Thu Sep 23 00:30:06 2010 From: michael.silvanus at gmail.com (Michel Alexandre Salim) Date: Thu, 23 Sep 2010 00:30:06 +0000 (UTC) Subject: [Valencia] Valencia and VTG collaboration / merge References: <1285099404.2271.32.camel@jury-laptop> <4C9A6B8B.6000905@yorba.org> Message-ID: On Wed, 22 Sep 2010 13:48:11 -0700, Adam Dingle wrote: > Jiri, > > > I'm quite sure you guys at Yorba know about Vala Toys for GEdit. It > > is a GEdit plugin, very similar to Valencia, which does basically the > > same thing. This duplicity is unhealthy and it is my belief those two > > should become a single project. I've talked to the VTG developer (hi > > sejerpz :)) and he too agrees with my view of the situation, and is > > open to discussion. > > thanks for the suggestion. I'm the primary designer and coauthor of > Valencia. Yes, we're certainly aware that Valencia and Vala Toys for > Gedit are projects with similar goals. We could certainly discuss > either having these become a single project as you suggest, or otherwise > sharing some code between the projects. > > If we were to merge into a single project, then we'd presumably want to > deprecate one code base and move all developers into the other project. > But nobody wants to lose any features, so we'd need to implement all > missing features in the code base that stays alive. I just tried out > VTG for the first time in a while - I built and installed vtg-0.10.2. > Here are the features I noticed that are in Valencia that seem to be > missing in VTG: > > 1. Valencia does not require a Vala project to use Autotools. > > 2. With Valencia, I can simply drag in a .vala file and start browsing > its symbols immediately. I don't need to create a project definition at > all; Valencia simply notices where the .vala file is and assumes that > all .vala files nearby are part of the same project. > > 3. Valencia seems much more stable than VTG. Within the first few > minutes of using VTG, I saw lots of console output including the > following and a segmentation fault: > FWIW, VTG is currently unusable on Fedora 13 and below -- we have a Vala that's too new there for older versions of VTG, but some other components (gtksourceview2) are too old for newer VTG releases. Considering the Valencia editor is much more flexible (Adam's #2) and that some bugs in VTG are only fixed in 0.10.2 (which we can't update to in F-12 and F-13 without causing disruptive other changes), I've been pointing our F-12 and F-13 users to Valencia (currently undergoing review for Fedora) and the general response has been very positive. Best regards, -- Michel Alexandre Salim () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments From adam at yorba.org Thu Sep 23 22:18:42 2010 From: adam at yorba.org (Adam Dingle) Date: Thu, 23 Sep 2010 15:18:42 -0700 Subject: [Valencia] Valencia and VTG collaboration / merge In-Reply-To: <1285200164.2806.51.camel@ramingo.zoo.locale> References: <1285099404.2271.32.camel@jury-laptop> <4C9A6B8B.6000905@yorba.org> <1285200164.2806.51.camel@ramingo.zoo.locale> Message-ID: <4C9BD242.9050101@yorba.org> Andrea and Jiri, unfortunately Andrea's last 2 messages to the Valencia list got sent to me only, but bounced from the list. We don't know why - it might have been a transient network failure. I'll reply here anyway to keep the discussion going. (Andrea's first bounced message appears quoted at the end of this message.) Here are some thoughts based on Jiri and Andrea's comments. 1. Jiri suggested that we could create a merged project using some code from both VTG and Valencia, and then use the name "Valencia" for the merged project. That might be OK, but I would want to transfer the name "Valencia" to the new merged project only *after* all features from the current Valencia have been implemented there, and only after we've tested the merged project and all agree that it's reached a high level of stability. In other words, nobody should refer to the merge-in-progress as "Valencia" or "the new Valencia" before it's completely done, since that could make users very confused. 2. It's good to know that VTG has a smartfolder backend that can handle non-Autotools projects. And I see that I can open a .vala file in VTG and begin browsing symbols immediately - that's nice. Still, it seems that VTG's project model is pretty different from Valencia's at the moment. I think this is the single biggest hurdle to merging VTG and Valencia - everything else should just just be a matter of adding missing features to one program or the other. In Valencia, there are no commands "Open Project", "Close Current Project" and "Change Current Project" like in VTG. Instead, in Valencia, whenever you open a .vala file, Valencia automatically uses the Vala project containing that file. For example, suppose that I open these three files in three different windows (or tabs) in Valencia: /home/adam/london/foo.vala /home/adam/london/extra/bar.vala /home/adam/paris/baz.vala If "london" is a single Vala program, then Valencia will realize that foo.vala and bar.vala belong to that program, and that baz.vala is in a separate program "paris". Valencia knows this because whenever it opens a .vala file, it looks in its ancestor directories (first the parent directory, then the parent's parent and so on) looking for a project root directory. A project root directory contains a file configure.ac or configure.in (for Autotools projects), or a Makefile containing the definition BUILD_ROOT = 1. That's a convention (invented by Valencia) by which a Makefile can indicate that it's the root of a multi-directory project. If Valencia finds no root, then it assumes that the project is a single-directory project and only groups together .vala files in that same directory. (See the section "The project root" in the Valencia documentation at http://trac.yorba.org/wiki/Valencia .) Because of all this, Valencia automatically knows which source files belong to which projects. There's no need for commands to open/close a project; it's all completely implicit. You can have source files from several different projects open at once and it all just works. If you jump to symbols from any Vala file, you're guaranteed to end up in the same project; it's impossible to jump to symbols in a different project. Now, I don't understand how all this works in VTG. In particular, it's not clear to me what the scope of "Change Current Project" is. Does that change the current project only for the current tab, or for the current gedit window, or for all gedit windows? If I'm looking at a file "london/foo.vala", but then I change the current project to be "paris", then when I jump to symbols from "london/foo.vala" might I arrive in Paris? We like Valencia's project model and would prefer to keep it in any merge between VTG and Valencia. So our initial proposal is that the "Open Project" and "Close Current Project" commands should go away in the merge, for example. But perhaps we don't understand the VTG project model well enough. Does the VTG model have some advantages over Valencia's model? If so, what are they? 3. In an email to me, Andrea said By the way I tested Valencia and I'm impressed by the parsing speed, but I don't like the lack of interactiveness of the completion. I'll go in the details in another mail. By design, Valencia never pops up an autocompletion box unless you ask for it explicitly via Control-Space. This is because some of us (including me) find it annoying when a tool offers help unexpectedly. From your message, it sounds like you'd like the completion box to pop up automatically. This could be a user option. 4. In another message, Andrea wrote 1) a custom parser is better for error recovery, the speed is a secondary feature 2) while writing afrodite I realized that the parser is not very important, what matters is the semantic analyzer / symbol resolver: a) it should be incremental. eg. parse these files add them to the AST and resolve all the symbols, then add this other file and resove it too b) we must have the possibility to remove all the symbols belonging to a specific file without redoing a complete parse of the project For these reasons and the lack of time I decided to rely on the vala parser and instead rewrite a custom semantic analyzer / symbol resolver. As you may know, Valencia does not use the valac parser. Instead, Valencia contains its own parser written with the above goals in mind, and also written to be very fast. Valencia stores the symbols for each source file separately. As a result, whenever any source file changes, Valencia can very easily throw out the old symbols and parse new ones. 5. I don't know much about afrodite, so I'm not sure what its advantages and disadvantages are with respect to the Valencia parser. But if we decide that we want to keep Valencia's project model *and* Valencia's parser, then I think you guys should seriously consider using Valencia rather than VTG as the basis of the merge since I think it may make your life easier. But of course you may have your own thoughts on the project model question (#2 above), and that's probably the most important thing for us to resolve at this point if we are hoping to merge. cheers adam On 09/22/2010 05:02 PM, Andrea Del Signore wrote: > On Wed, 2010-09-22 at 13:48 -0700, Adam Dingle wrote: >> Jiri, >> > Hi Adam, Jiri > > first of all I'm glad to see we have the same goals, so let's see if we > can do the merge and how. > > Since it's pretty late now I'll just reply to your comments, but > tomorrow I'll give a try to the Valencia plugin. > >>> I'm quite sure you guys at Yorba know about Vala Toys for GEdit. It >> is a >>> GEdit plugin, very similar to Valencia, which does basically the >> same >>> thing. This duplicity is unhealthy and it is my belief those two >> should >>> become a single project. I've talked to the VTG developer (hi >>> sejerpz :)) and he too agrees with my view of the situation, and is >> open >>> to discussion. >> thanks for the suggestion. I'm the primary designer and coauthor of >> Valencia. Yes, we're certainly aware that Valencia and Vala Toys for >> Gedit are projects with similar goals. We could certainly discuss >> either having these become a single project as you suggest, or >> otherwise sharing some code between the projects. >> >> If we were to merge into a single project, then we'd presumably want >> to deprecate one code base and move all developers into the other >> project. But nobody wants to lose any features, so we'd need to >> implement all missing features in the code base that stays alive. I >> just tried out VTG for the first time in a while - I built and >> installed vtg-0.10.2. Here are the features I noticed that are in >> Valencia that seem to be missing in VTG: >> >> 1. Valencia does not require a Vala project to use Autotools. > Nor VTG does since it can edit a single vala file or a "project". > > Actually libvbf is the utility library behind VTG project support and it > has 2 backends: > > * The autotools one (the one I use most of the time) > * The smartfolder one > > With the smartfolder backend you can open a folder that contains a > cmake, waf script or a simple makefile project and VTG will import all > the vala/vapi files inside it as a "complete project". > > VTG can open any number of projects you want and you can switch between > them in the project view on the left pane or with the "quick pick" > dialog. > >> 2. With Valencia, I can simply drag in a .vala file and start browsing >> its symbols immediately. I don't need to create a project definition >> at all; Valencia simply notices where the .vala file is and assumes >> that all .vala files nearby are part of the same project. > You can do the same in VTG, but that file will go to a default project. > In the end the default project contains all the opened files that don't > belong to any open project. > >> 3. Valencia seems much more stable than VTG. Within the first few >> minutes of using VTG, I saw lots of console output including the >> following and a segmentation fault: > That's true and it's my first priority at the moment. So I think that we > have to first stabilize the completion library, the major cause of > segfaults and then adding the features you lack. > >> (gedit:23758): Gtk-WARNING **: Inserting action group >> 'ProjectManagerActionGroup' into UI manager which already has a group >> with this name >> ... >> (gedit:23758): GLib-CRITICAL **: g_strrstr: assertion `haystack != >> NULL' failed >> >> ** (gedit:23758): CRITICAL **: >> vtg_symbol_completion_provider_lookup_visible_symbols_in_scope: >> assertion `word != NULL' failed >> ... >> >> 4. Valencia displays the name of the class containing the cursor in >> the Gedit status bar (which is very helpful when you've jumped to a >> symbol and don't know what class you've ended up in). > Can be added, moreover VTG as a full sourcecode outliner pane. > >> 5. Valencia can find some symbols that VTG cannot. For example, in >> Valencia I can click on any local variable or parameter and jump to >> its definition; I haven't seen this work in VTG. > I think that you are experiencing some bugs in the completion library. > > I can only add that VTG symbol completion tries to be very "rich", it > doesn't need to press any key to popup and it has initial support for > generics, var declaration etc... > > >> 6. Valencia contains a Search -> Go to Outer Scope command (Ctrl+F12) >> that jumps to the method or class containing the cursor position; I >> don't see anything like this in VTG. > Can be added. > >> So if you (or we?) could implement all of these (plus any others I >> haven't noticed) in VTG then we could think about deprecating Valencia >> and all using VTG instead. I'll point out that (1) and (2) are >> especially important to the Valencia developers; we need to use >> Valencia with Yorba's own projects written in Vala (e.g. Shotwell, >> Fillmore, Valencia itself) which don't use autotools. > I don't know what build system you use at yorba, but we can also think > to write a specific libvbf backend if that makes sense. > >> (3) is equally important: we need our gedit plugin to be rock-solid >> and to never emit GLib criticals or warnings. > I agree we need to stabilize VTG more > >> Or, conversely, we could conceivably add VTG's missing features to >> Valencia and then we could migrate all our efforts to Valencia. I >> don't know VTG well so I can't easily make a list of its features >> which are missing in Valencia, but at first glance I see that VTG has >> autotools support and also appears to have somewhat more sophisticated >> autocompletion (or, at least, it looks formatted more nicely). If you >> guys want to make a list of such features than we could certainly >> discuss this possible direction. > I'll make this list after trying Valencia a bit. > >> Finally, I'll say that the Valencia developers are relatively busy >> with other projects (Shotwell and Fillmore) now so, sadly, we wouldn't >> have a ton of time to work on this merge. Valencia works pretty well >> for our needs and so we're not necessarily looking for large changes >> now. If you guys are excited about the merge and want to implement >> the missing features in either program then we would be interested, >> but we probably couldn't take on much of the work ourselves at this >> time. > That's understandable and I've to add that I can devolve only my free > time on VTG, but we can at least try :) > >> Nevertheless, if you remain interested in this then we'd be happy to >> continue the discussion, either by email or by IRC if you prefer. And >> in any case I'm glad we're all working on making Vala more useful for >> everyone. :) >> >> adam >> > Regards, > Andrea > From synkro at gmx.net Fri Sep 24 16:36:10 2010 From: synkro at gmx.net (synkro) Date: Fri, 24 Sep 2010 18:36:10 +0200 Subject: [Valencia] Valencia and VTG collaboration / merge In-Reply-To: <4C9BD242.9050101@yorba.org> References: <1285099404.2271.32.camel@jury-laptop> <4C9A6B8B.6000905@yorba.org> <1285200164.2806.51.camel@ramingo.zoo.locale> <4C9BD242.9050101@yorba.org> Message-ID: <4C9CD37A.5050407@gmx.net> Hi there! I agree that a single effort for a gedit plugin is the way to go. As gawking bystander I'ss add my two cents. 1) Yes, Valencia is the better name. If a merged project achieves merging all features and rquiremens a then it shall be named so. 2) The separation of parser and the like in VTG (e.g. libaphrodite) is very good and providing code to other projects is very good. Also the clear separation of GUI and back end. 3) I also like the way the Valencia parser and project logic works, that must be retained. 4) Automatic tool pop as in VTG is a must have also. 5) After a short cruise over the Valencia file I have the impression merging there new features in will be one hell of a task because of the tightly crammed vala files. The VTG source on the other hand is very vast while it does not achieve more than Valencia. I feel that bringing VTGs order and features to Valencia is the way to go. Even though I lack any deeper perspective of the code bases. Greets synkro