xboard-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] gtk and x11 in parallel


From: Arun Persaud
Subject: Re: [XBoard-devel] gtk and x11 in parallel
Date: Mon, 06 Jun 2011 09:34:03 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10

Hello

> We add a directory .../gtk to the source tree of master, just like there
> already is a directory winboard to contain the respective front-end code.
> This seems more logical anyway. This way the old XBoard front-end could
> then continue to exist in master next to the GTK version. The latter could
> start its life as a plain copy of the XBoard front-end, copying all
> 'X-files' there (xboard.c, xhistory.c, xgamelist.c etc.) which is then
> gradually taken over by GTK functions (if we go with the mixed approach).
> 
> The advantage would be that back-end changes (which is mostly what I do
> anyway) automatically get into the GTK version without any merging.

I think a branch would be better in this case:
* for gtk we need to change the configure scripts
* merging backend changes is no problem with git (the problem would be
in places where front- and back-end are not well separated... see below)
* if you add front end code, we now would need to modify 3 location (Xt,
Gtk and Windows) and if we wouldn't update Xt anymore, why not through
it out and replace it with gtk right away?

> Btw, I still think the best path to a GTK version is to first refactor the
> existing XBoard front-end to get rid of most code, and only then start
> porting the little kernel that is left.

If we had the front-end and back-end better separated things would be
indeed easier.... however Gtk might make some features available that Xt
doesn't have and also provide some build-in data-structures that might
be good to use (Glib), so we probably end up changing some backend code
too... this could be done after the transition to Gtk though.

My biggest question would be if we want to do another major release
before starting to switch to Gtk. If not, I would say, we start to
switch to Gtk on the master branch and use the v4.5.x branch for minor
releases in the meantime.

We still could work on better front-end and back-end separation (e.g.
for each window first work on better separation and then change to Gtk)
and as long as we split the commits into two parts, it would be easy to
just cherry pick the backend commits into v4.5.x and do the Xt changes
also in v4.5.x...

cheers
        ARUN



reply via email to

[Prev in Thread] Current Thread [Next in Thread]