VCS status and file-manager

[Johannes Schmid-4]

Hi!

So, I finally got to the point of cleaning up the file-manager and
porting it to GIO. The refresh button is gone now as it listens to
file-system changes automatically and updates the tree.

You will probably notice that it shows the modification time for the
selected file. This is mostly a proof-of-concept in the moment as I want
to show more information there. Especially interesting is the local VCS
status but maybe you can think of some other things.

For the VCS I would propose and interface with the following methods,
preferable in a synchronous version but maybe it's necessary to make the
calls async:

interface Vcs
{
        void add (List files);
        void remove (List files);
        void rename (string uri);

        AnjutaVcsStatus status (string uri);
}

I don't really think that we need "update" and "commit" as interface
methods as the user will most probably invoke those manually. Would be
nice if those who write the version control plugins could design and
implement this interface.

Thanks,
Johannes
       


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[William Fagan]

I think I just replied but it only went to Johannes. Sorry! You will end up seeing this twice probably.

I was just about to ask if there was a way of being alerted on whether or not a file is removed, added or renamed. I would love to implement the interface in your post but I am not moving so fast at the moment. I have been stuck on trying to get log details through the C/Python interface. Some of the stuff Bazaar does in Python is a pain in the ass to implement with the C/Python calls. I was talking to someone though that has a Bazaar plugin that outputs everything to an XML file. So I will have to just parse that. So if things start going smoother for me here this week I will look into it.

On Fri, Jun 13, 2008 at 3:34 PM, Johannes Schmid <jhs@...> wrote:

Hi!

So, I finally got to the point of cleaning up the file-manager and
porting it to GIO. The refresh button is gone now as it listens to
file-system changes automatically and updates the tree.

You will probably notice that it shows the modification time for the
selected file. This is mostly a proof-of-concept in the moment as I want
to show more information there. Especially interesting is the local VCS
status but maybe you can think of some other things.

For the VCS I would propose and interface with the following methods,
preferable in a synchronous version but maybe it's necessary to make the
calls async:

interface Vcs
{
       void add (List files);
       void remove (List files);
       void rename (string uri);

       AnjutaVcsStatus status (string uri);
}

I don't really think that we need "update" and "commit" as interface
methods as the user will most probably invoke those manually. Would be
nice if those who write the version control plugins could design and
implement this interface.

Thanks,
Johannes

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi Johannes,

Johannes Schmid a écrit :

> For the VCS I would propose and interface with the following methods,
> preferable in a synchronous version but maybe it's necessary to make the
> calls async:
> interface Vcs
> {
> void add (List files);
> void remove (List files);
> void rename (string uri);
>
> AnjutaVcsStatus status (string uri);
> }

Currently, the build plugin adds its own menu items in the
file manager. I don't know if this way is better or not.

If yes, the file manager don't need to know a vcs interface.

Else, I think the file manager should try to use the IAnjutaBuilder
interface too. We probably need to add a compile function though.

Regards,

Sébastien

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Naba Kumar-2]

Hi,

On Mon, 2008-06-16 at 19:49 +0200, Sébastien Granjoux wrote:

> Hi Johannes,
>
> Johannes Schmid a écrit :
> > For the VCS I would propose and interface with the following methods,
> > preferable in a synchronous version but maybe it's necessary to make the
> > calls async:
> > interface Vcs
> > {
> > void add (List files);
> > void remove (List files);
> > void rename (string uri);
> >
> > AnjutaVcsStatus status (string uri);
> > }
>
> Currently, the build plugin adds its own menu items in the
> file manager. I don't know if this way is better or not.
>
> If yes, the file manager don't need to know a vcs interface.
>

I think Johannes suggested the interface as a general vcs interface. The
FM will mostly only use the 'status' signal above.

Johannes, I think having commit and update methods are also useful in
cases where a plugin wants to add a file and commit automatically
without involving user in the process. And it might want to update first
before adding or removing a file etc. It would still be useful to have
those operations.

About file-manager using it, how would it know the statues of files if
it was loaded after the vcs plugin? Should it also have method to
request file statuses?

Thanks.

Regards,
-Naba



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi Johannes,

I'm currently changing the build option dialog of the
build-basic-autotool plugin. I have seen that you have added this
recently. Do you see problems with these planned changes ?

- Remove the run "autogenerate" menu item and replace it with a check
box in the configure dialog to run/or not autogen. If configure is not
present in the project directory, it is checked else it is unchecked by
default.

- Allow to choose between several configurations (Default, Debug,
Optimize and Profiling as you have defined) which correspond to a set of
default configure option and a build directory.

- Remove the anjuta_launcher_set_env function to replace it with an
additional gchar *env[] argument to anjuta_launcher_execute_v. It's
similar to other related function g_spawn_async by example. Moreover it
allows me to reuse the same launcher for a program using different
environment variables.

- Add an option in the project manager plugin to use a different
configuration.

Regards,

Sébastien

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Johannes Schmid-4]

Hi Sébastien!

> - Remove the run "autogenerate" menu item and replace it with a check
> box in the configure dialog to run/or not autogen. If configure is not
> present in the project directory, it is checked else it is unchecked by
> default.
>
> - Allow to choose between several configurations (Default, Debug,
> Optimize and Profiling as you have defined) which correspond to a set of
> default configure option and a build directory.
>
> - Remove the anjuta_launcher_set_env function to replace it with an
> additional gchar *env[] argument to anjuta_launcher_execute_v. It's
> similar to other related function g_spawn_async by example. Moreover it
> allows me to reuse the same launcher for a program using different
> environment variables.
>
> - Add an option in the project manager plugin to use a different
> configuration.

Sounds good to me! As I side note: Many users get confused by the
additional "Arguments:" field in the configuration dialog. We should
make clear that it is usually the best to leave it empty.

Thanks and regards,
Johannes


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

Hey Seb,
On Sun, 2008-06-22 at 22:29 +0200, Sébastien Granjoux wrote:
> - Remove the anjuta_launcher_set_env function to replace it with an
> additional gchar *env[] argument to anjuta_launcher_execute_v. It's
> similar to other related function g_spawn_async by example. Moreover it
> allows me to reuse the same launcher for a program using different
> environment variables.
While we're on the subject, is there a reason we're not already using
g_spawn_async_with_pipes in AnjutaLauncher anyway? I had a long
discussion about this with Will today, and I thought it would be prudent
to at least bring it up. Not only could we make it easier to handle
environment variables, it would also be easier to handle working
directories. As it is now, you have to call chdir before you launch your
child, and you have to be very careful that it doesn't change when you
don't expect it to, like if some other plugin might change it behind
your back or something.

IMHO it would be nicer for everybody if AL supported environment
variables and working directories. Plus, using g_spawn_async_with_pipes
means we don't have to do so much work in the launcher.

If you think this is a good idea I'd be willing to port it over when I'm
finished with my git plugin.

Thanks,
James



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi James,

James Liggett a écrit :
> While we're on the subject, is there a reason we're not already using
> g_spawn_async_with_pipes in AnjutaLauncher anyway?

I don't know. This has been written before I enter in the loop.

> Not only could we make it easier to handle
> environment variables, it would also be easier to handle working
> directories.

I'm agree to use g_spawn_asyn_with_pipes if possible. I plan to use a
gchar **array for arguments and environment variables. With the current
interface, I need to make some conversions those will be not needed if
using g_spawn_async_with_pipes. In fact, I have already modified
anjuta_launcher but without using g_spawn_async_with_pipes.

> If you think this is a good idea I'd be willing to port it over when I'm
> finished with my git plugin.

I think so. When you do expect to do this ?

Regards,

Sébastien

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi Johannes,

Johannes Schmid a écrit :
> Sounds good to me! As I side note: Many users get confused by the
> additional "Arguments:" field in the configuration dialog. We should
> make clear that it is usually the best to leave it empty.

Ok, I will try to commit something in one or two weeks.

Regards,

Sébastien

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[James Liggett]

On Mon, 2008-06-23 at 19:46 +0200, Sébastien Granjoux wrote:
>
> > If you think this is a good idea I'd be willing to port it over when I'm
> > finished with my git plugin.
>
> I think so. When you do expect to do this ?
Probably end of next month. Is that too long?

James


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi James,

James Liggett a écrit :
>> I think so. When you do expect to do this ?
> Probably end of next month. Is that too long?

No, that's fine. In the meantime, I will probably commit some changes in
it, keeping the current execvp, but using gchar ** arguments.

Sébastien

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi All,

I'm currently looking at the build-basic-autools plugin.

I don't understand why the build directory stack is kept in a hash table
in BuildContext. The key of this hash table seems to always be "default".

I suppose it has been done like this to add additional features. Do you
know why it's like this ?

Regards,

Sébastien

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi All,

I'm currently working on build plugin. Most code is now more or less
working and I'm checking it.

In build-basic-autotools.c (update_module_ui), I run into the following
code:

dirname = g_dirname (bb_plugin->current_editor_filename);
module = escape_label (g_basename (dirname));
filename = escape_label (g_basename (bb_plugin->current_editor_filename));

if (directory_has_makefile (dirname))
{
        label = g_strdup_printf (_("_Build (%s)"), module);
        action = anjuta_ui_get_action (ui, "ActionGroupBuild",
            "ActionBuildBuildModule");
        g_object_set (G_OBJECT (action), "sensitive", TRUE,
                  /*"label", label, */NULL);
        g_free (label);
        ...

The generated label is not used (put in comment in g_object_set).

Is someone know why?
Do you think it's better to enable this feature ?
It should display "Compile _module_name_" instead of just "Compile".

Regards,

Sébastien

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Naba Kumar-2]

Hi Seb,

On Tue, 2008-07-15 at 22:56 +0200, Sébastien Granjoux wrote:

> label = g_strdup_printf (_("_Build (%s)"), module);
> action = anjuta_ui_get_action (ui, "ActionGroupBuild",
>   "ActionBuildBuildModule");
> g_object_set (G_OBJECT (action), "sensitive", TRUE,
>  /*"label", label, */NULL);
> g_free (label);
> ...
>
> The generated label is not used (put in comment in g_object_set).
>
> Is someone know why?

It could be because GtkUIManager only uses actions at widgets creation
time (merging) -- like a template or blueprint for the widgets. It would
be useful to have it work like you wanted, but I have no idea why it
wasn't done.

Another approach, although not ideal, would be to get the widget
directly. You can get the widget with:

gtk_ui_manager_get_widget(GTK_UI_MANAGER(anjuta_ui),
                          path_as_defined_in_ui_file);

It is not idea because it only picks up one widget of the possible many
for the given action.

Regards,
-Naba



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi All,

I have just committed my changes in the build plugin allowing to build a
target outside the source directory.

It's a quite big change in this plugin so test it if possible.

I plan to add a few, I hope easier, options in this plugin:
  - parallel make
  - do not stop on error
  - do not translate error messages
  - allow to cancel a build

I have tried to make a nice interface but perhaps someone have better
ideas. I have imagines by example to reorder the menu items:
        Compile
        Build module
        Install module
        Clean module
        ----------
        Build project
        Install project
        Build project tarball
        Clean project
        ----------
        Configure project
        Clean configuration
        Select configuration

       
The build directories are saved in anjuta session file. So if this file
is destroyed, you can have to rerun configure to be able to access your
build directory.

Almost all changes are done in the build plugin. The project manager
plugin just check a build_uri variable to compute the correct target uri.

Regards,

Sébastien

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel

[Sébastien Granjoux]

Hi All,

I have just fixed the bug #530630 in scintilla using
ianjuta_editor_assign instead or
ianjuta_editor_get_position/ianjuta_editor_set_position.

It's due to a modification in scintilla editor that has changed the
argument of ianjuta_iterable_get_position and
ianjuta_iterable_set_position to a number of characters instead of a
number of bytes.

Scintilla is using byte position internally and finding the
corresponding character position is not obvious.

ianjuta_get_position was returning a number of utf8 characters, while
ianjuta_set_position was expecting a number of scintilla characters.
It's very similar, except that the end of line count as 1 for scintilla
in all cases, even if a DOS end of line (2 bytes '\r\n') is used like in
the sample file provided in the bug report.

ianjuta_get_position and ianjuta_set_position need a fix too. How do
should we handle this ?

I think we can keep the byte position for scintilla (reverting the
change which has been done in revision 2576 ?) It will mean that these
functions are useable only within one editor but I think it's not a big
deal. Moreover, there is the iterator interface that should be used
instead and avoid these troubles.

Currently only the search plugin use it but I need to check how it is used.


Regards,

Sébastien

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Anjuta-devel mailing list
Anjuta-devel@...
https://lists.sourceforge.net/lists/listinfo/anjuta-devel