Re: Forked off GUI

[Israel Herraiz]

Excerpts from Jordi Gutiérrez Hermoso's message of Thu Nov 01 21:57:26 +0100 
2012:
> I see. I suppose the Spanish language is an essential feature of the
> website? Makes me wonder if I should work harder to do i18n for the
> Agora website.

It is not. The "forja" is available also in English and other
languages (it's GForge), although some parts might be only in Spanish,
and projects' messages are usually in Spanish.

My project is very Spanish-centric because it is intended for my
students, many of whom are not proficient in English.

> I appreciate the gesture, but at this point it's just symbolic. It's
> no great help to create a new hg clone that's unrelated to the hg
> clone you forked off from.

Ahm, ok. I thought just being Mercurial would make it easier :).

> I have started from your svn repo. You forked off quite a long time
> ago, before we moved the build system to autotools, and before many
> other changes in the GUI, so it will take some time to merge your code
> back in. We definitely cannot replace our code with yours, but I will
> be trying to understand what you did and see how much we can integrate
> back. Depending on what I can find, maybe we can only merge back
> ideas, not code.

Yes, I tried to catch up with Jacob and others work and send patches,
but it was very difficult with so many changes during the summer, and
the divergence is now at its maximum :).

There are some parts though that I think can be easily integrated. I
have sent a separate message replying to your post about the 4.0
goals with some more details.

I have been inspecting the current GUI. I think one of big issues for
the stability of the GUI is how events are managed. Currently, there
is a semaphore that avoids accessing the events queue from two
different threads. However, all the events are processed without any
kind of semaphore or lock. Thus, if we take the workspace view as an
example, if for some reason the workspace takes a little longer to be
updated, the next event updating the workspace view will try to update
it while it's still being updated. That also happens with the commands
history view. A semaphore in all the code updating any of the windows
would avoid some stability problems. Those semaphores would be
additional to the current semaphores avoiding concurrent access to the
events queue.

Also, the model should be changed to avoid refreshing the workspace
view if the model has not changed (currently, it always refreshes
every 0.5 seconds).

I think these two changes are the main differences that could be
useful to improve the stability of the GUI. Other differences are
merely cosmetic, or do not impact on stability (I have finished the
GUI for the debugger for instance, and it is now functional).

I have done those two changes in my code, and after an inspection of
the current GUI code, I think I could easily integrate that. Or at
least, helping someone else integrating that using my code as a base.

Cheers,
Israel