Re: [Gramps-devel] GUI separation: the next step (long)

[Alex R. <sh...@al...>]

Doug,

On 01/13/2005 05:14:37 PM, Douglas S. Blank wrote:
>=20
> I think you missed my point. I am not going to replicate all of gtk, gnom=
e,
> gobject, and gnome in these alternate GrampsGui files.

I thought not :-)

> Currently, the only recourse one has is to fork the program. This propose=
d
> solution gives us a bottleneck with which we can try to find other soluti=
ons.

Oh, I'm not saying that it's completely without merit. I understand that th=
e
more code there's in common the less gramps-tk has to fork, and then the
less effort it is to keep up with gramps. The whole dilemma is that it buys
convenience for the gramps-tk maintainers by imposing on the gramps
maintainers :-)

Before going further -- I apologize for hurting feelings. I do not mean to
portray gramps-tk as bad guys or diminish usefulness of the project. It's
just, as we have discussed before, the goals of gramps-tk are somewhat
orthogonal to goals of gramps. It they were not, there would not be a
need for a separate gramps-tk, would there?

> > 1. All the code needs to change 'gtk' to 'gui'. Granted, could be done
> >    by a sed script or somesuch, but still things will slip through, as =
they
> >    always do, and such changes usually take some time "to heal" :-)
>=20
> I agree that we would need time to check things out, and it would be sill=
y to
> do them all at once. But GRAMPS could use some test code, and one test wo=
uld
> be to make sure that no program uses the string "gtk.". That would be eas=
y.

Why not instead patch the files that bring you trouble with something like

---   import gtk
+++ import blah as gtk

where "blah" would be a simple module with the placeholder functions?
Such a patch would be easy to maintain, no matter how much gramps
code changes.

Despite seemingly easy switch, having another layer is always increasing
complexity. Another person coming in a few months to work on the code
will have hard time finding out what "gui" is and why... How would our
tutorial on writing reports look, if there's 'gui' module that nobody
knows about? Sure, these inconveniences are not all the huge and could
be dealt with, but would not it be more fair if the burden was on
gramps-tk in this case?

> Aunt Martha is going to have more serious problems than this! I am trying=
 to
> make GRAMPS use fewer resources exactly so that it will work for her. You
> think that this is going to be a bigger issue than mime, gconf, gtk libra=
ries
> changing?=20

Actually, I do. In my view, if Aunt Martha is ever going to run gramps (not
the gramps-tk, but gramps) then it will be on a distro that Just Works (tm)
and where installing gramps is a matter of a single click. She would never
use BSD portage or Gentoo or build from the source on Solaris. She would
use it on a system on which all the dependencies are taken care of.

For example, on Debian (I just know it because that's what I use) an
'apt-get install gramps' gets you a working version. I am told that this
is also the case on Ubuntu, and Linspire, etc. This is not to start a distr=
o
flamewar, but rather to illustrate that Aunt Martha is not going to have
problems with mime types and gconf. She might ask us "why gramps
does not start" when we accidentially screw up the gconf keys ourselves,
as I did in 1.0.6. And then being able to find out what's wrong is very
helpful, especially if I cannot reproduce the problem.

> > That is so true. At the moment, we have 48 open bugs, 44 feature
> > requests, and more things in the TODO list. Guess what I want to do
> > more: help existing users of gramps (including myself), or help in
> > porting it to the non-free environments/OSs?
>=20
> Ok, that really hurt. I am not trying to port it to non-free operating
> systems. That is a side-effect of having fewer resources. But if people s=
tart
> using GRAMPS-gtk because they liked GRAMPS-tk on Windows but wanted a sli=
ghtly
> more powerful version, so much the better. There are a lot of people who =
would
> wander over to Linux if we give them a nice path. Of course, you can deci=
de
> how best you want to get people to experience the freedom of software. Bu=
t
> don't think that your way is the only way.

Sorry for hurting, I did not mean it. I also did not mean to discourage you
or anybody else from porting gramps to win32, OS, and whatnot, even if this
were your goal. I just said that I'm not very interested in that, and that =
I'd
rather fix bugs and add features.

That said, I also don't have a goal to convert as many people as possible f=
rom
win32 to Linux, and to use gramps as a bait. Definitely, my way (as anybody=
's,
for that matter) is not the only way, but it is only logical that I want to=
 do things
my way, isn't it? After all, if I didn't, then it would not be my way :-)))

> Actually, if you just add the GrampsGui.py file and add the
> const.graphics_toolkit line to const.py, we can slowly convert each progr=
am
> over time. Nothing has to change at this point and it won't have any impa=
ct on
> existing code.
>=20
> When things slow down, you can then accept the patches that I have to con=
vert
> one, some, or all of the files. This was actually really easy to change. =
All I
> had to do was "import GrampsGui as gui" rather than "import gtk" and use
> "gui." rather than "gtk." for gtk.*, gnome.*, and gobject.* objects. I'm
> running it now, and it had no effect on the GRAMPS gtk interface.

See related comments below.

> > A simpler way to do what you want that will not affect the current code=
=20
> > base is to provide an alternate "gramps.sh" script. This script is a=20
> > wrapper around the python call, which is essentially:
>=20
> Yes, of course; that is how I run gramps-tk. But I am trying to move to
> getting rid of the "spoons".

Why? If the changes are so simple that they can be done by a simple sed/pyt=
hon
script without much maintanence, what's the urgent need to avoid forking he=
re?
The time needed to swap "gtk" for "gui" in all the source files of gramps w=
ould
be on the order of a second. One file or 100 does not matter all that much.

> > All the backend code could still be in common, but the GUI would be=20
> > separate, and controlled by the shell script.
>=20
> But the backend code isn't in common right now. I can't even import ArgHa=
ndler
> because of dependencies way down. I can define some replacement stubs in
> GrampsGuiTk.py to get around some of the simplier dependencies (like
> gtk.ListStore). Right now there are 22 forked files. But I think we can g=
et
> that down to just a few (over time) with the proposed solution.

So, let's do it your way but keep it as a patch (or sed script), without ne=
cessarily
going into gramps. What is so hard in maintaining simple changes on gramps-=
tk
side?

> I really think that this is the minimalist change in order to share the c=
ommon
> files. I understand if you want to wait to get this next version out the =
door,
> but I think that this would be the only step needed for the gramps-tk pro=
ject
> to be realized (ie, the separation of the core from the gui would be
> comeplete, from our perspective).
>=20
> If someone has a better idea on a series of minimal changes that would al=
low
> these two projects to share the common code, please let me know. Right no=
w the
> only option we have is to copy and change the file. With the proposed
> solution, we can write code to replicate some parts. We may still have to=
 fork
> some, but they would be few in number.

I don't know what to say, really. I feel like we're arguing over a non-issu=
e.
Whether the changes you propose are kept on gramps-tk end or in gramps
CVS, it is going to be a minor inconvenience for either party. I guess it's=
 Don's
decision eventually, but I don't see why we should carry the burden, howeve=
r
small it is. I also don's see how this decision is going to make such a hug=
e
difference to gramps-tk whether we do or not -- forking 2, 12, or 22 files =
is
all pretty much the same.

Alex

--=20
Alexander Roitman   http://ebner.neuroscience.umn.edu/people/alex.html
Dept. of Neuroscience, Lions Research Building
2001 6th Street SE, Minneapolis, MN  55455
Tel (612) 625-7566   FAX (612) 626-9201