Re: [anjuta-devel] GDL placeholder
- From: James Liggett <jrliggett cox net>
- To: Sébastien Granjoux <seb sfo free fr>
- Cc: Anjuta Mailing List <anjuta-devel-list gnome org>
- Subject: Re: [anjuta-devel] GDL placeholder
- Date: Tue, 08 May 2012 23:38:34 -0700
On 05/04/2012 01:05 PM, Sébastien Granjoux wrote:
Hi James,
Le 04/05/2012 06:08, James Liggett a écrit :
I have a similar problem with git shell, where if you click on a command
button multiple times, the command panes don't get placed on the bottom
where they should be. They end up in the center instead, which looks
really odd. I have no idea why this happens.
Ok.
I think it would help matters immensely if we tried a more formal
engineering approach with GDL. We could start by putting together a list
of things that GDL should do. Then we get rid of anything that doesn't
fit. This way, we have documented reasons for why certain things are in
the GDL code.
I have only looked at the part which interest me at the moment, the
saving of the windows layout (the GdlDockLayout object). From what I
have seen, the architecture seems good and I don't see much things to
remove. But I have looked only at a small part and indeed the
GdlDockPlaceholder object seems unused, I suppose it can be removed. Do
you have in mind other things those could be removed?
For now, I'd say just try to get rid of GdlDockPlaceholder. I too
wondered what its purpose was and I wanted to get rid of it myself. But,
I didn't do it because I didn't understand how it fit in with GDL's
overall design so I didn't know what the fallout would be. If you dig
into it you can see it's a pretty complicated class that its designer
put a lot of time into. What I don't get is why. Looked at another way,
what functional requirement of GDL does GdlDockPlaceholder address? Sine
no one wrote it down we can only guess now.
These types of questions are good reasons to document things like
requirements and basic design architecture. I'm not suggesting that we
actually write formal specifications for GDL like you would at a
traditional software company, but would a couple of wiki articles hurt?
Granted, writing them isn't very fun, but if we suck it up it could be
worth it in the long run. And please do keep in mind that I don't expect
you to to all of this yourself. This is something that we should all do.
From there, we should put together a short description of GDL's overall
design, with descriptions of which classes do what. The idea here is
that we document everything with GDL so that even long after we're gone,
other people can come in and understand how GDL works, and why we made
the decisions we did. From my experience, the absolute worst part of
hacking on GDL is that we have no idea how it works or how decisions
were made. Rectifying those problems would go a long way toward making
GDL more maintainable and easier to work on.
I'm agree that currently GDL is quite unusable due to the lack of
documentation. But I think I have in mind something less formal, rather
read a piece of code, try to understand it then modify it and document
the result. I prefer to play with a part of the code and understand it
piece by piece.
Normally I'd be the same way but my experience with GDL has so far been
so fruitless because I can't even begin to understand what's going on,
much less what the original design intentions were. Every time I dare to
work on something GDL related I'm stymied because I simply don't get how
the thing works or why, all because whoever wrote this crap didn't
bother to document ANYTHING.
My latest example of this phenomenon came up over the weekend when I was
trying to get git shell to display the Status view by default. The
obvious thing to do (I think) is to tell gdl to show the dock item with
gdl_dock_show_item, but that doesn't work because non-floating docks
like the ones used for git shell views need to have a "default position"
set on them, whatever that is. So I try to call
gdl_dock_item_set_default_position only to find that it requires some
kind of "reference" object, but I have no idea what would work for this.
Giving it a pointer to the dock just gives me another critical and now I
have no idea what to do next because no one knows what the hell any of
this means.
By "formal" all I mean is that when we figure out how something works,
or change or even throw out a part of GDL out and re-write it, we should
write down what we did and why so the next person that comes along
having to deal with it doesn't have to put up with the same problems we
had. Even something as simple as some GtkDoc comments would help. I
think many of us have added some (at least I know that Johannes and I
have done a few functions a long time ago) but we have a long way to go.
I plan to change the GdlDockLayout item to keep track of hidden dock
items. So when saving a layout, instead of clearing the old one, I would
rather mark all windows as hidden and try to merge it with the current
layout.
Well, good luck with that. :) Really, I hope you get farther than I did
with this. Working on GDL really puts me in a bad mood, if you can't
tell. ;)
I'm actually considering following Nacho's lead and dumping GDL for git
shell because it's starting to impede my progress on implementing
features and making it more usable. I don't have anything concrete yet,
and I haven't made any hard decisions right now, but the more I think
about it the more I think it's a good idea.
Thanks for your effort on this, Seb. (And thanks for reading my rant...:-)
James
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]