[Geany-Devel] Proposal from the Mint distro

[Colomban Wendling]

Le 18/10/2012 04:18, Matthew Brush a écrit :
> On 12-10-17 05:55 PM, Lex Trotman wrote:
>> Hi All,

Hi,

>>
>> Along with the previous response on the icon, the following was proposal
>> was also received from Clement of the Mint distro:
>>
>> "Another thing I wanted to ask you about, and I'm glad you contacted
>> us, is
>> about the configuration of Geany as a text editor for users (as
>> opposed to
>> developers). Geany is brilliant and I personally use it as a developer to
>> do most of my work in Python, C, PHP and other languages. But it could
>> also
>> be a great contender for a default text editor in Linux Mint in
>> replacement
>> of gedit. We're not happy at all with gedit 3, in particular when it
>> comes
>> to searching and replacing occurrences in a text file. We considered
>> replacing it with Geany, with an older GTK2 version of gedit or even
>> forking it to provide a new tool dedicated to text editing.
>>
>> What is your opinion on this? If we used Geany for this, we would hide
>> all
>> developer features (symbols, buttons, statusbars..etc) from it. Would you
>> rather like us shipping a version of geany which by default looks like a
>> simple text editor (and so devs would have to go in the preferences and
>> re-enable all the normal features) or fork geany into a new project
>> dedicated to text editing (i.e. basically a dumbed down version of geany
>> with features removed). With a fork of course we'd give credit to
>> geany in
>> our communication and within the tool itself, we'd work with you on
>> making
>> sure you're happy with the end-result and the editor would have a
>> distinct
>> generic name ("text editor" for instance) so it would be possible for
>> users
>> to have both this editor and geany installed side-by-side and to open
>> documents with either of them. Let me know your thoughts on this.
>> We're not
>> sure what the best approach is, but whether it happens now or later,
>> we're
>> pretty sure gedit 3 isn't what we want to use going forward."
>>
>> To kick the ball off, here is my thoughts on the topic.
>>
>> First thought is that there is plenty of upside to such cooperation in
>> terms of attracting more contributors to the developer version of Geany.
>>
>> The flip side of that is of course that more bugs would be reported and
>> expected to be fixed.  (Bug reports are good, its the *expectation* that
>> they will be quickly fixed that is the problem.)  I would hope that Mint
>> would be able to contribute to that effort.
>>
> 
> The only problem here with more bug reports is that there's more bug
> maintenance. The actual number of non-duplicate, valid,
> non-GTK/Windows/Scintilla/FeatureRequest bugs are minimal and even since
> the beginning of the bug tracker have generally been fixed quite quickly.

Agreed, if the reports would all be nice and proper reports, it'd be
great.  If all we get is a bunch of invalid duplicates, it'd be annoying
and wouldn't help development at all (actually slowing it down a little
by making some of us close irrelevant bugs);  but I think it's
reasonable to suppose a large part of the additional reports would get
proxied by the Mint people, and I hope they are clever enough to
distinguish between useful and garbage reports.

And most of all, I'm not willing to try preventing people from using
Geany just because we'd get more garbage reports.  If everybody starts
to use Geany, hopefully there will also be people getting involved in
the project, even if it's only triaging [1] bugs :)

>> I am not sure how much effort it would take to make the Geany UI able to
>> hide the "developer" features, it will be some complication for sure, but
>> probably not a big one.
>>
> 
> Not much, I did this for my WIP OSX bundle. I just bundle a customized
> geany.conf (and for OSX keybindings.conf)  and a few tweaks in a gtkrc
> file. Already Geany has the ability to mostly do this with existing
> preferences.

I though the same when reading Lex's mail.  Running `geany -c
~/.config/geanylitye -nmt` and having a default configuration hiding the
rest would be a good start, and is truly easy to do with a script.

If they also want to hide stuff like project and build menus, and some
programming-related items, maybe tweaking the .ui file would even be
enough.  Ok, a forked .ui isn't really easy to maintain, but still not
as complex as a real fork.

> I have a couple ideas how we could go further to remove
> more "developer" UI stuff that wouldn't be terribly difficult or cause
> much code changes.

If it's simple enough not to make things harder to maintain, it'd
probably be totally acceptable.

>> If Mint use a "friendly fork" approach it does reduce the impact this has
>> on the Geany project, but it will also reduce the possible bugfixes that
>> come back to Geany (since the fork is different patches may not apply).
>>
> 
> I have no problems if they want to fork Geany but it would cause a loss
> of concentration of efforts so we would both go off adding/changing
> stuff and (as you said) cross-fork efforts become less and less useful
> over time (or at least more painful; see TagManager c.c file :).

+1.  I wouldn't have any problem with a friendly fork but it may easily
end up wasting efforts, where it'd have been easy to work together.

However, it probably also depends on how deep they'd like to go at
removing developer-oriented features.


Tu summarize, I'm not against the idea and I'd wish it could be done so
we all waste as less effort as possible, and hopefully prevent a fork
going a completely different road.


Regards,
Colomban

[1] thanks LaunchPad for this word nobody knows :)

>> If we provide the "plain editor" version as an option on Geany it adds to
>> the workload, though I would hope that Mint would contribute to that
>> extra
>> effort.
>>
> 
> It's not like the workload is overwhelming :)  I don't think it'd be too
> big a deal.
> 
>> I am personally undecided at the moment, noting that Mint will do what is
>> appropriate for their distro, and it is up to us to try to engage with
>> them
>> ina way that provides the maximum benefit for both groups.
>>
> 
> I have no problems with it and I'd be willing to help out with
> implementing the "simplified mode" since it's something I've been
> thinking about before.
> 
> Cheers,
> Matthew Brush