Re: GSOC Application: Layout Manager for Nemiver

[Dodji Seketeli <dodji seketeli org>]

Hello Fabien,

Thank you for your application.

Allowing a better use of the screen estate seems to be quite a popular
demand among Nemiver users so I expect improvements in this area to have
a substantial short term (at least) impact.

Fabien Parent <parent f gmail com> a écrit:

> I think the goal of this project is not to work on a layout manager for
> Nemiver but is instead to make me a regular contributor of the Nemiver
> project, and the layout manager is just the means to it.

I agree.  Though, I wouldn't neglect the short term impact I was talking
about above :-)

> At this time, every debugging panel is stacked inside a *GtkNotebook*, which
> makes it very hard to have a full idea of what is going on in the program
> you are currently debugging because you can see only one debug panel at the
> time. I want to use all the free space that is currently available to show
> more debug panel at the same time, which will permit to see the complete
> state of your application at a glance.

This would be nice, but as always, there might be gotchas.

The reason why I did choose to show only one "state view" at a time [be
it either variables, or call stack, or registers view] was, well, speed.

Each time the inferior (i.e, the program being debugged) stops, Nemiver
has to query the underlying debugging engine (which is GDB at present)
for state, and it has to do so for every single "state view" that is
currently visible to the user. E.g, if the local variables view *and*
the call stack view are visible at the same time, each time Nemiver
stops, it has to query GDB for all local variables *and* the call stack,
so that it can display those to the user.  When you are a doing single
stepping, those state querying do add up and the whole debugging
experience can quickly become sluggish.

In that area, I have empirically noticed that just querying for nothing
was much faster than, say, querying for everything ;-) That is the
reason why, by default, Only the terminal view is shown to the user;
this was convenient because that view doesn't do any state querying.  In
addition, a state view which widget is not visible doesn't do any
querying to the underlying debugging engine either.

I guess these are papering over the underlying real issue which is
basically that the updating of the user-visible visual state of the
inferior is too slow.  The whole debugging stack (including GDB) might
need fixing there.

So this work you are proposing will not only help to use the screen
estate in a more efficient way, but is also likely to help in fixing the
state updating speed problem -- or at least understand it better.

> However, the project is not to change the current layout of Nemiver but to
> add new layouts to it, because Nemiver must stay adequate for different kind
> of monitor. This is why the project will start by creating a layout manager
> which will allow to create as many layout as we want, and will be able to
> change the current layout of Nemiver without the need of restarting the
> application. Then I will have to port the current debugging perspective to
> this new layout manager. At this point there will be no visible change for
> the user but will allow the creation of new layouts.

Good plan.

> Once the layout manager done, I will start developing a second layout which
> will be optimized for a better usage of the horizontal space. To be able to
> change on the fly the layout of Nemiver, soon after I will implement a
> setting page that let the user choose the layout he wants to use.

OK.  More "settings stuff", I see ;-)

> Afterward I will be using my previous work to add one or two more static
> layout, this shouldn't takes much time compared to the creation of the
> layout manager and the first alternative layout.

OK.

> Finally, the most exciting feature, at least for me, will be the addition of
> a fully dynamic layout based on the library GDL [3] which will allow the
> user to create his own layout based on which debugging panel he is using
> more, on the size of its monitor and on the number of monitor it will be
> using. The GDL based layout will allow the user to detach panels to put them
> on a different monitor than the one showing the source code, the most
> obvious usage of this feature would be to move the console used for input
> and output out of the Nemiver window.

Interesting.


> Timeline
>
> The project can be divided into 3 milestones:
>
>    -
>
>    The creation of the layout manager and migration of the current layout to
>    the layout manager.
>    -
>
>    The creation of alternative static layouts.
>    -
>
>    The creation of a dynamic layout based on GDL.

This looks like a reasonable plan to me.

As I use to say, I wouldn't set the exact dates you proposing below in
stone.  I understand these just as informational.

>
>
>  *25 April - 16 May:*
>
>    -
>
>    Read documentations.
>    -
>
>    Familiarize myself with the Nemiver architecture, code and conventions.
>    -
>
>    Make a first draft of the design of the different layout I will
>    develop.

I hope we'll be discussing the high level design draft on the list as
early as possible.  I wouldn't be concerned about familiarizing yourself
with the code base a lot before starting to propose a design, as I
believe that it is when you try to mess with things that you understand
how they work ;-)

>
>
>  *17 May - 22 May:*
>
>    -
>
>    Work on the Layout Manager design and get feedback from the mentor.

I would merge this with the last item of the previous period.  If we
start interacting earlier, I believe you could start the coding period
earlier too.  I believe the details of the design are going to evolve
throughout the life of the project anyway.

>  *23 May – 9 June (Official coding period starts):*
>
>    -
>
>    Write the Layout Manager
>    -
>
>    Migration of the current layout to the new layout manager

This seems quite short of a period to hack on the damn thing :-)
Hopefully with my comments above we can glean a couple more days for
hacking here.

>  *10 June – 12 June: **Milestone 1*
>
>    -
>
>    Document the existing code

I would hope that commenting the code would happen gradually, as you
progress in your coding tasks.  I wish the whole code base were more
documented to begin with :-)

>
>  *13 June – 26 June:*
>
>    -
>
>    Write the first alternative Layout.
>    -
>
>    Write the Layout Manager preferences user interface.

Indeed.  I find it appropriate to hack on the other layout *and* the
preference stuff at the same time.


>  *27 June – 13 July: **Milestone 2*
>
>    -
>
>    Write a second and third alternative static Layout.

Maybe you could just write a second alternative static layout ...

>
>  *14 July – 21 July:*
>
>    -
>
>    Port the binding GDLmm to GTK+3

... so that you'd have more time left for this.

>  *22 July - 15 August: **Milestone 3*
>
>    -
>
>    Add feature to show/hide debugging panels.
>
>
>    -
>
>    Create a dynamic layout based on GDLmm.

I am feeling that this is going to be challenging, given the short
period of time.  Though, I am not pushing it back, because you wisely
defined useful deliverables to have, before reaching this point.


My general feeling around this project is quite positive.  I am glad
Nemiver has two strong proposals this year :-)

-- 
		Dodji