Re: [gedit-list] Safely trying out modifications

[Jesse van den Kieboom <jessevdk gnome org>]

Paolo Borelli wrote:
> Hi Doug,
>
> 	as hinted in the previous mail I use jhbuild to build a development
> version of the gnome stack in a separate prefix (/opt/gnome in my case,
> but that's up to you). Even if you do not use jhbuild, by passing
> --prefix to configure you can manually do the same, jhbuild just takes
> care of dealing with the boring stuff like setting up PATH an other env
> variables.
> When installed in a prefix, gedit will not harm your installed system in
> any way, as a matter of fact by installing in the prefix you do not even
> need to become root.
>
> The only thing where things interact is the files in the $HOME of the
> user... to be honest I do not worry about that much: even if things go
> wrong (and they shouldn't) and you have to delete all those files,
> things will be ok, you just lose your preference setting which are
> easily restored. Obviously creating a different user works too.
>   
There are some things that do interact of course, such as customly 
installed plugins and settings through gconf. I usually run the gedit 
git even on production machines (at work and home), then when there is a 
serious bug, I just fix it. I think it should be possible to run gedit 
in a more isolated environment (using a few environment variables), 
without having to resort to a special user, though I haven't tried such 
a thing.

I use the following script to avoid the 'single-instance' stuff when 
developing:

#!/bin/bash

GEDIT_INSTALL_PATH=$HOME/.install

let "i=0"
while true;
do
   TDIR=/tmp/gedit-dev-$i

   if [ ! -d $TDIR ];
   then
       break
   fi

   let "i=$i + 1"
done

mkdir -p $TDIR
echo "Connection directory is: $TDIR

TMPDIR=$TDIR $GEDIT_INSTALL_PATH/bin/gedit $@
rmdir --ignore-fail-on-non-empty $TDIR


> Last but not least, if you have a powerful machine you can always decide
> to experiment with a virtual machine, that way you will be 100% sure to
> not harm your production machine.
>   
Also, note that most (if not all) the things you'd like to do, can be 
done with plugins for which you don't need to modify the gedit core.


Jesse
> Hope that helps,
>
> 	Paolo
>
>
> On Mon, 2009-10-05 at 12:11 -0600, Doug McNutt wrote:
>   
> > Some time ago this question was raised. How can I compile and test a new version of gedit when my distribution doesn't yet offer it and I really want to try new features and make some source code modifications for my own amusement?
> >
> > This kind of comment worries me:
> >
> > At 23:41 +0100 1/30/08, Paolo Borelli wrote:
> >     
> > > Be warned: building locally in a distro old like that can be painful.
> > > You'll need to build a lot of updated dependencies: glib, gtk,
> > > gnome-vfs, gtksourceview etc. 
> > >
> > > As mentioned by others, a somewhat less painful way may be to use a
> > > script like garnome or jhbuild to build the whole thing, but if you're
> > > just interested as a user and not as developer/tester I really suggest
> > > you to simply update to a newer distro.
> > >       
> > I have downloaded the source for 2.28 and, for the first time, I have managed to get through a ./configure and a make. In the past configure was failing while complaining about my 64 bit machine.  But even though I can compile without error I can't dare to perform a root level install. I'm totally dependent on a working version of gedit for day-to-day operation of ubuntu Linux. The idea of overwriting all of the entries in $HOME/.gnome2/gedit/* is something I don't want to contemplate. Besides that, my wife manages the machine and would likely be quite upset if the "standard" ubuntu distribution procedures get bothered by the presence of newer than approved versions.
> >
> > I can set up a second user ID to protect a home directory but I have no idea how to set up new places for the system level preferences and other files that a new version, likely containing runtime errors created by me, would muck with.  I just have to maintain a tested and working version of gedit while I experiment with the new. Other applications I can put in $HOME/bin/ with a prefix request to configure but with gedit that won't do the job because of the built-in references to the likes of $HOME/gnome2/. I'd really like to change the names of the program and all of its links to external files while I work with it.
> >
> > The things I really want to work on - like allowing an environment variable to specify the characters allowed in a "word" for selection by double clicking - will involve gtksourceview and that adds yet another source with modifications. I would really like to have commands that can be executed in one window to change the contents of another and can also be treated as shell commands. I want a selected line or lines in a window to be executable as shell commands when I poke the keyboard enter key while the alphabetic enter key is the return character. Yeah - my history is that of Apple's Macintosh Programmer's Workshop which was a shell for classic machines until OS neXt was introduced. I want its features back and I see gedit as an open source place to start.
> >
> > Surely there are others with the same problems. Hasn't someone prepared a list of links I need to attend to? What do the official developers do when they run with debugging code?
> >
> >     
>
> _______________________________________________
> gedit-list mailing list
> gedit-list gnome org
> http://mail.gnome.org/mailman/listinfo/gedit-list
>
>