[Epiphany] 1.2 Plan

[Marco Pesenti Gritti <mpeseng tin it>]

I'm writing a plan for 1.2. I'll put it on the web site and post to
desktop-devel probably. It's unfinished, especially the "Things we
should work on for 1.2" section should improved/extended, I'm sure
people on this list has more ideas.
Feedback very appreciated.

Positive aspects of 1.0 development

- We managed to keep in the whole development cycle a decent
stability level and reached a state where we can fix bugs as they
are reported more than one month before 2.4 due date.
- Improved cooperation with other GNOME projects and teams
- Constantly reviewed user interface, we did not need a
real ui review after ui freeze.
- Overall good usability. We certainly have problems but we are
progressing.
- Decent set of features while keeping the interface clean
and simple.
- Productive community. Not too many flames, shared clear target,
good feedback (bugs etc...), mostly productive discussions.
- Good code base. A lot of improvements from galeon 1.3 codebase, most
notably the Egg port.

To improve

- Better communication with GNOME teams. I think we did progresses
here but in the future important decisions (ex. bookmarks system) need
to be discussed on gnome mailing lists and done with the consensus of
the
GNOME community.
Some people are feeling our way to deal with feature additions too
extreme.
We need to make clear that we are not against features, but that we
want to think very carefull about them, to make sure they are usable
by a large number of people, pretend a good rationale and a sensible
design before adding them.
- Better communication with testers. I think many of the flames on
gnomedesktop has been generated by misunderstandings. Several people
still does not know the reasons of the fork of galeon.
- We tend to introduce bad bugs just before the releases. This is
detrimental
for testing: we need to make sure releases are usable for every day
work.
I think the main cause of this has been the delay in the GNOME release
schedule. Not knowing when you are going to release it's hard to decide
when delaying risky changes. A solution would be probably to use
branches
for stable releases. Obviously if we would write code without bugs, we
would avoid the problem ;) See next point.
- I think we can do a better work avoiding regressions. I plan to modify
commits policy so that everyone (me included) need a review to check in
patches. (We already tried out this, with good results).
- Design should not block on me. There are a lot of things that can be
done
without me reviewing/encouraging the process: ex. find usage contexts,
build lists
of tasks, find documentation about the issues ...
- We need a design methodology so that more people can be involved in
the task and
we have evaluation criteria. This is a gnome wide problem though.
- Design decisions should be documented. It would improve communication,
make
easier next iterations, provide concrete examples of the methodology.
- Connection with mozilla people. Patch takes way too much to be
reviewed.
This is probably partially due to stronger interest in
mozilla-the-browser
problems than in embedding and to the fact that most of the work we need
is on
the shoulders of Blizzard only. But I'm sure getting a bit more involved
would help.

Things we should work on for 1.2

USER INTERFACE

- Bookmarks
1 More rich "automatic" metadata.
2 System integration
3 More powerful way of organizing things. (which could involve
hierachies, depending of GNOME community feelings).
4 Something better than a menu to access them, Seth offered to help on
this.
5 Improve bookmarks toolbars "editing"
(I'm experimenting about 1/2, I may post more info about it later)
- Simpler fonts/colors configuration. Themes support (stylesheets).
- History: we need more filters, at least a date based filter.
- Popups blocking
- Tabs preference(s) need to be improved to avoid current
conflicts/confusion.
- Finish fullscreen design
- Encodings menu should show only the most used items (dynamic), the
others
should be moved out in a dialog.
- Use gnome print dialog
- Allow to specify a download directory.

CODE

- Extensions. The framework is already mostly there. Work needs to be
done
on ui merging and api policies.
- Port to gtk 2.4. Hopefully not much more than s/egg/gtk
- Use new kris gtk autocompletion entry
- Port to DBUS if it's included. We may be able to drop
libgnome/libgnomeui/libbonobo/libbonoboui dependecies.

[1.2 targeted bugs url here]


Marco