Re: [gedit-list] New gedit roadmap

[Sébastien Wilmet <foss swilmet be>]

Here is the new roadmap:
https://gitlab.gnome.org/GNOME/gedit/blob/master/docs/roadmap.md

It's no longer a table because it's more difficult to edit. And with
sections and paragraphs it's possible to write longer descriptions.

Nothing is set in stone, the format can change. Maybe some colors could
be added for the status (I need to see how to do it in Markdown). The
links to GitLab issues are missing, it can be added later.

So, for the tasks that I have added, it's mostly what I would like to
work on in the future. I don't plan to remove features. My end goal is
to create a software product line for text editors, by developing the
Tepl framework. So, keeping gedit as a general-purpose text editor with
plugins (like most other text editors), and for language-specific
features (like I plan to implement for the C language), develop both a
plugin for gedit + a specialized text editor that Just Works, out of the
box, for that language.

On the road to that end, I will try to have funding. For example, it's a
coincidence that I started to contribute again to gedit, but there is
now this challenge, and I think I will try to participate, with some
work planned in Tepl and gedit:
https://www.gnome.org/news/2019/08/gnome-foundation-launches-coding-education-challenge/

but, I don't have full-time free time. So if the challenge supposes that
developers work full-time and there is a deadline, a solution is to hire
another GTK developer part time to do the challenge with a group of two.

And I have other plans to have other sources of funding, like, launching
a crowdfunding for gedit. In the past I already launched several
crowdfunding, but it was either for a not well-known project
(gnome-latex) or for the hidden part of the iceberg (GtkSourceView,
Tepl, gspell, …), so there was not enough funding for the amount of work
that I did. gedit is a much more visible and well-known project, so it
may work better. But I'm not good at marketing (I think).

What are your plans? What do you think gedit should become? There has
been some thoughts to remove the plugin system, make gedit much simpler,
like a better Notepad. This is/will easily be possible with Tepl, so I
think gedit can remain as is and another app can be created. In gedit,
maybe move some essential plugins like text zooming to the gedit core.

--
Sébastien

On Fri, Aug 30, 2019 at 08:17:19AM -0500, Jim Campbell wrote:
> This approach sounds good, Sébastien. Thank you.
>
> Jim
>
> On Fri, Aug 30, 2019, at 5:53 AM, Sébastien Wilmet wrote:
> > I have updated the roadmap wiki page:
> > https://wiki.gnome.org/Apps/Gedit/RoadMap
> >
> > but it's horrible to edit that page, it's hard to spot the line and
> > column that we want to edit.
> >
> > I have started to write more content for gedit in Git in Markdown, and I
> > think it's much better. The Markdown syntax is nicer, GitLab renders it
> > well, and in Markdown it's also possible to have relative links to other
> > files in the same git repo.
> >
> > And, in git, we are sure to keep the history. Wiki pages with a database
> > system, being able to delete the page etc, it's less certain that the
> > history will be kept. And the roadmap history is a nice summary of the
> > work done (for example I would love to see a detailed roadmap for the
> > done tasks during gedit 1 and gedit 2 development, I was not
> > contributing back then, there are a few pages on the wiki for the new
> > MDI, but not much. But, there is the NEWS file or ChangeLog.).
> >
> > So, I will write a new roadmap in Markdown in Git, and everyone else can
> > add tasks, add more details etc. If you are on the trusted group to edit
> > wiki pages, feel free to push commits on the master branch to edit the
> > roadmap or other documentation files that I've written, I will do
> > post-reviews. In general I prefer doing post-reviews for such things
> > rather than letting the contributor wait until he/she gets a review on
> > gitlab. Worst case the commit is reverted, but usually it's better to
> > just improve the commit with another commit. The same for trivial things
> > like a typo in the source code.
> >
> > --
> > Sébastien
> > _______________________________________________
> > gedit-list mailing list
> > gedit-list gnome org
> > https://mail.gnome.org/mailman/listinfo/gedit-list
> _______________________________________________
> gedit-list mailing list
> gedit-list gnome org
> https://mail.gnome.org/mailman/listinfo/gedit-list