Hi All,
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.
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.
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).
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.
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.
Cheers Lex
On 12-10-17 05:55 PM, Lex Trotman wrote:
Hi All,
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.
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 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 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 :).
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
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
Am 18.10.2012 02:55, schrieb Lex Trotman:
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.
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.
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).
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.
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.
First of all, I find the idea of Geany becoming the default text editor in some distro. The idea that a distro uses an IDE as a text editor by default is an acknowledgement for our goal to keep Geany lightweight.
I understand they want a simplified user interface. However, as Geany would be exposed to many newcomers, it should be clearly visible that this is not the real Geany (which is vastly more powerful). So IMO the name should express the difference (perhaps "Geany Lite"?). Otherwise the newcomers will think of Geany as a simple text editor, and not a powerful IDE and ultimately use another program for IDE tasks.
However, in the end it would be best and most important to avoid a fork, since that doesn't help us a bit.
PS: I'm also not sure that a new wave of contribution will come from the Linux Mint side, seeing that they consider to fork gedit rather than to improve it collectively with upstream (but perhaps they just became hesitant to work with Gnome people?). He even suggested forking Geany in his very first approach to us.
Best regards.
Am 18.10.2012 09:17, schrieb Thomas Martitz:
First of all, I find the idea of Geany becoming the default text editor in some distro. The idea that a distro uses an IDE as a text editor by default is an acknowledgement for our goal to keep Geany lightweight.
Let me complete the sentence: I find the idea *great*.
I'd like to add also that I would welcome Clem and other Mint/Mate/Cinnamon developers to join a discussion on this list instead of proxying mails through Lex or someone else.
Best regards.
On 18 October 2012 19:01, Thomas Martitz < thomas.martitz@student.htw-berlin.de> wrote:
Am 18.10.2012 09:17, schrieb Thomas Martitz:
First of all, I find the idea of Geany becoming the default text editor in some distro. The idea that a distro uses an IDE as a text editor by default is an acknowledgement for our goal to keep Geany lightweight.
Let me complete the sentence: I find the idea *great*.
I'd like to add also that I would welcome Clem and other Mint/Mate/Cinnamon developers to join a discussion on this list instead of proxying mails through Lex or someone else.
Agree, was going to do that now we have a thread I can reference for them.
Cheers Lex
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 2012-10-18 09:17, schrieb Thomas Martitz:
First of all, I find the idea of Geany becoming the default text editor in some distro. The idea that a distro uses an IDE as a text editor by default is an acknowledgement for our goal to keep Geany lightweight.
I understand they want a simplified user interface. However, as Geany would be exposed to many newcomers, it should be clearly visible that this is not the real Geany (which is vastly more powerful). So IMO the name should express the difference (perhaps "Geany Lite"?). Otherwise the newcomers will think of Geany as a simple text editor, and not a powerful IDE and ultimately use another program for IDE tasks.
Just thinking about running it with a configuration flag, maybe also switchable inside Geany itself. Something like e.g. hide all sidebars which is already available as e.g. keybinding. So you could call something like geany --minimal and on running Geany you're ablt turn it to normal with a shortcut or something like that. Geany --minimal could also be just kind of a link to a minimal configuration file. Putting kind of a banner in top of Geany showing user he is only using a subset of features.
However, in the end it would be best and most important to avoid a fork, since that doesn't help us a bit.
ACK.
PS: I'm also not sure that a new wave of contribution will come from the Linux Mint side, seeing that they consider to fork gedit rather than to improve it collectively with upstream (but perhaps they just became hesitant to work with Gnome people?). He even suggested forking Geany in his very first approach to us.
They are used to "need to forking stuff" as you can see from cinnamon and mate desktops. And its a valid option to be honest -- even I dislike it ;)
Cheers, Frank
On Thu, 18 Oct 2012 11:55:00 +1100 Lex Trotman elextr@gmail.com wrote:
"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)." [and so on]
Of course, it would be nice to have Geany as a default text editor in a distro. From my experience, when a software in a distro, or becomes the default for something, there is a short jump in the number of bug reports, feature requests, and people willing to help. After that, the things settle down, probably with N extra developers, depending on the software size.
Create a minimal Geany without forking and too much effort, IMHO:
1. Create a "minimal" option.
2. Create a list of "advanced" glade widget names (menu items, preferences dialog widgets, ???), such as "menu_build1" and "frame24". Fetch these widgets with gtk_builder_get_object() and hide them.
3. Write "minimal" mode for the find dialogs. They are not glade, but even if they were, simply hiding "Use regular expressions" and "Use escape sequences" will leave a hole on the left part of the dialog.
4. Cut down all "advanced" toolbar items and keybindings. I don't know how they are organized though...
5. Hide the message window, sidebar, line numbers and markers margin by default[1]. There is no way to activate them now.
[1] Personally I'd like that even if we don't write a "minimal" version.
Reply from Clement:
"Regarding the default text editor, I've read the emails on the mailing list with interest. From our point of view, it wouldn't need to change much. Typically we're looking at a generic unbranded "text editor" that works great and is lightweight. Geany fits the bill nicely, pluma also to a lesser extent. There's two different kinds of users at play here, so I wouldn't like not having the full geany in the repositories (i.e. patching geany and dumbing it down by configuration wouldn't be a good solution for all devs using it out there), but I also wouldn't like to have geany itself, as a dev tool, installed by default, since it's a power tool most users wouldn't use (similarly we don't install tools like dconf-editor, remmina..etc..).
Cinnamon is a complete fork, we don't need Gnome Shell and it's not going in a direction we want to follow. Geany is different, it's something that works which we'd love to have a slightly different version of, in supplement to geany itself.
If we were to fork Geany, we wouldn't deviate from it. Basically we would rebase from new versions of Geany and reapply our modifications. Codewise it wouldn't therefore be a complete fork, but a deviation of it. Geany would still be there in our repositories as itself and with all features. The deviation would wear a generic name "Text editor" for instance and we'd credit Geany in our announcements (when introducing this change) and in the editor about window. Bugs would come against the editor and we'd only forward bugs to you when we think you might benefit from seeing them.
In essence, it would be as we patched Geany, but without hiding the original version with the patched version.. thus ending up with both geany in the repositories and the generic editor installed by default.
The reason we fork Gnome components is because we depend on them, the Gnome team ignores our feedback and the needs we have and we have no other means to get things done other than doing them ourselves. I'd be happy to explain the reasons behind all this, maybe on the IRC we if get a chance. You can see how Mint is still Mint whether it's with Gnome 2, MATE or Cinnamon.
MATE itself wasn't forked by us and came out of the necessity to keep Gnome 2 alive. For distributions to provide both Gnome 2 and Gnome 3 and for users to be able to run both DEs, one had to be renamed. The Gnome devs obviously decided that the new DE should be called Gnome and so because they conflicted with each others, Gnome 2 had to be renamed. Perberos took the initiative and called Gnome 2 MATE. We supported this project as much as we could. Today we're able to run both DEs on the same machine. We've got a great relationship with them and I personally joined their team.
We're quite a small team but we're happy to help. We understand feedback very well and we're happy to feed ideas and valuable bug reports upstream. I'll try to get a sample project up and running to show you how this could be done easily and I'd love for us to chat about this. Is the Geany team often on the IRC? do you use Freenode?"
I have already answered #geany to the last question.
My 2c:
1. The "lite" and the "full fat" version do need to be different commands, the lite version is for simple use and has to start without options when used from the command line, and whilst full fat could be an option on the lite version, I'm not sure its preferable, a compile time decision makes life simpler. From a user POV two application names makes more sense I think.
2. The question as I see it is, do we want to make the lite version a part of the Geany codebase, clearly sharing as much as possible. That could be complex if the needs of the two diverge, so how likely is that? That also means two packages, two bug trackers etc. In the end this would be my preferred method if it looks like it will work.
3. Or should the lite version be a separate repository with patches transported between them? Of course needs separate bugtracker though.
4. As Clement says they are a small team, but we need to be realistic that so are we, and we are completely volunteers, but we do have the advantage of knowledge of the code base.
5. One question for Clement would be "whats the timeline you have in mind?"
Cheers Lex
On 12-10-20 06:01 PM, Lex Trotman wrote:
Reply from Clement:
"Regarding the default text editor, I've read the emails on the mailing list with interest. From our point of view, it wouldn't need to change much. Typically we're looking at a generic unbranded "text editor" that works great and is lightweight. Geany fits the bill nicely, pluma also to a lesser extent. There's two different kinds of users at play here, so I wouldn't like not having the full geany in the repositories (i.e. patching geany and dumbing it down by configuration wouldn't be a good solution for all devs using it out there), but I also wouldn't like to have geany itself, as a dev tool, installed by default, since it's a power tool most users wouldn't use (similarly we don't install tools like dconf-editor, remmina..etc..).
Cinnamon is a complete fork, we don't need Gnome Shell and it's not going in a direction we want to follow. Geany is different, it's something that works which we'd love to have a slightly different version of, in supplement to geany itself.
If we were to fork Geany, we wouldn't deviate from it. Basically we would rebase from new versions of Geany and reapply our modifications. Codewise it wouldn't therefore be a complete fork, but a deviation of it. Geany would still be there in our repositories as itself and with all features. The deviation would wear a generic name "Text editor" for instance and we'd credit Geany in our announcements (when introducing this change) and in the editor about window. Bugs would come against the editor and we'd only forward bugs to you when we think you might benefit from seeing them.
In essence, it would be as we patched Geany, but without hiding the original version with the patched version.. thus ending up with both geany in the repositories and the generic editor installed by default.
The reason we fork Gnome components is because we depend on them, the Gnome team ignores our feedback and the needs we have and we have no other means to get things done other than doing them ourselves. I'd be happy to explain the reasons behind all this, maybe on the IRC we if get a chance. You can see how Mint is still Mint whether it's with Gnome 2, MATE or Cinnamon.
MATE itself wasn't forked by us and came out of the necessity to keep Gnome 2 alive. For distributions to provide both Gnome 2 and Gnome 3 and for users to be able to run both DEs, one had to be renamed. The Gnome devs obviously decided that the new DE should be called Gnome and so because they conflicted with each others, Gnome 2 had to be renamed. Perberos took the initiative and called Gnome 2 MATE. We supported this project as much as we could. Today we're able to run both DEs on the same machine. We've got a great relationship with them and I personally joined their team.
We're quite a small team but we're happy to help. We understand feedback very well and we're happy to feed ideas and valuable bug reports upstream. I'll try to get a sample project up and running to show you how this could be done easily and I'd love for us to chat about this. Is the Geany team often on the IRC? do you use Freenode?"
I have already answered #geany to the last question.
My 2c:
- The "lite" and the "full fat" version do need to be different commands,
the lite version is for simple use and has to start without options when used from the command line, and whilst full fat could be an option on the lite version, I'm not sure its preferable, a compile time decision makes life simpler. From a user POV two application names makes more sense I think.
Or I think it's easy enough (I think) to symlink some command, like to link "text-editor" to "geany --light" whether using some shell stuff, or launchers, or whatever.
- The question as I see it is, do we want to make the lite version a part
of the Geany codebase, clearly sharing as much as possible. That could be complex if the needs of the two diverge, so how likely is that? That also means two packages, two bug trackers etc. In the end this would be my preferred method if it looks like it will work.
If it does indeed come down to just hiding widgets, I think we could offer a way to do that. We (or Mint guys) could have a 2nd Glade file which has the visibility of much stuff set to false. Other way is to maintain an array of items to hide on startup. Both of these ideas were shared here I think. I made a quick and dirty patch to show the later form:
http://pastebin.geany.org/ODwZr/
For distro packages, they could be packaged like this:
geany-core - the full geany install minus glade & desktop files geany-light - geany-core plus the light glade & desktop file ** this would be installed by default on Mint geany - geany-core plus the full glade & desktop file
For people who want to use the full (normal) Geany, they could install the "geany" package which could install the full Glade UI and the regular launchers and stuff. But the default is to have only "geany-light" (plus "geany-core") installed.
Geany doesn't have so much overhead that it's worth not installing the bulk of it up front.
- Or should the lite version be a separate repository with patches
transported between them? Of course needs separate bugtracker though.
It could, and then it'd keep distro-specific bugs from reaching Geany trackers (hopefully).
Disclaimer: I don't know s&$t about distro packaging or this stuff.
Cheers, Matthew Brush
Hey,
I didn't really follow the thread in depth, so sorry in advance if I missed something obvious.
If it does indeed come down to just hiding widgets, I think we could offer a way to do that. We (or Mint guys) could have a 2nd Glade file which has the visibility of much stuff set to false. Other way is to maintain an array of items to hide on startup. Both of these ideas were shared here I think. I made a quick and dirty patch to show the later form:
If it is even only about hiding widgets which already can be hidden via menu items/config options (via config even more can be hidden than via the GUI, e.g. each single tab in the messages window at the bottom), then it might be even enough to provide a global geany.conf in $prefix/share/geany, see http://www.geany.org/manual/#global-configuration-file
Regards, Enrico
On 12-10-21 02:49 AM, Enrico Tröger wrote:
Hey,
I didn't really follow the thread in depth, so sorry in advance if I missed something obvious.
If it does indeed come down to just hiding widgets, I think we could offer a way to do that. We (or Mint guys) could have a 2nd Glade file which has the visibility of much stuff set to false. Other way is to maintain an array of items to hide on startup. Both of these ideas were shared here I think. I made a quick and dirty patch to show the later form:
If it is even only about hiding widgets which already can be hidden via menu items/config options (via config even more can be hidden than via the GUI, e.g. each single tab in the messages window at the bottom), then it might be even enough to provide a global geany.conf in $prefix/share/geany, see http://www.geany.org/manual/#global-configuration-file
I think the idea is that not enough of the widgets are currently configurable (eg. the Project and Build main menu items cannot be hidden AFAIK), so this way as it is now is not enough.
But that doesn't mean we couldn't extend which widgets can be hidden via the config file by adding more keys to it. I like this way the best because I can also use it for the (future) Mac bundle (it already has a customized geany.conf in the bundle to change some defaults).
The other options of Mint maintaining a fork to simplify Geany themselves or doing it by means of distro package tricks means any "improvements" couldn't easily be re-used for the Mac bundle (or other DEs using it as a default text editor) and they would have to be "unforked" or duplicated.
Cheers, Matthew Brush
Le 21/10/2012 21:52, Matthew Brush a écrit :
[...]
But that doesn't mean we couldn't extend which widgets can be hidden via the config file by adding more keys to it. I like this way the best because I can also use it for the (future) Mac bundle (it already has a customized geany.conf in the bundle to change some defaults).
(OT, but should really a Geany MacOS port hide some stuff??? Changing the default keybindings to be more MacOS-ish may indeed be sensible, but changing Geany?)
The other options of Mint maintaining a fork to simplify Geany themselves or doing it by means of distro package tricks means any "improvements" couldn't easily be re-used for the Mac bundle (or other DEs using it as a default text editor) and they would have to be "unforked" or duplicated.
I'm sorry if I sound harsh, but why are you (all) saying that, why couldn't such a "fork" be use by somebody else?? It's not like putting Mint-specific code, is it?
I'm not saying forking is the way to go (I'm less and less sure what should be done BTW), but I mean, if one just create a geany-light/-lite project and push that to a publicly-available repository (anywhere, even on linuxmint.com) anybody could clone it and use it, or even package it. It's not a "nah! it's mine! don't touch it!"-thing, is it?
Regards, Colomban
On 12-10-21 01:13 PM, Colomban Wendling wrote:
Le 21/10/2012 21:52, Matthew Brush a écrit :
[...]
But that doesn't mean we couldn't extend which widgets can be hidden via the config file by adding more keys to it. I like this way the best because I can also use it for the (future) Mac bundle (it already has a customized geany.conf in the bundle to change some defaults).
(OT, but should really a Geany MacOS port hide some stuff??? Changing the default keybindings to be more MacOS-ish may indeed be sensible, but changing Geany?)
(There's more stuff, like using the correct fonts, commands, etc. Also, Apple thinks its users are idiots and so most programs seem to come with very simplified defaults, and lacking a decent text editor, a simplified Geany would be very useful for general text editing, further, it's nearly impossible to do development on OSX without having XCode and so having another "full featured" IDE is less useful. That being said, I don't want a "different Geany", just to change the defaults so that you have to explicitly enable "advanced" features/widgets to make it more "Mac-like" by default.)
The other options of Mint maintaining a fork to simplify Geany themselves or doing it by means of distro package tricks means any "improvements" couldn't easily be re-used for the Mac bundle (or other DEs using it as a default text editor) and they would have to be "unforked" or duplicated.
I'm sorry if I sound harsh, but why are you (all) saying that, why couldn't such a "fork" be use by somebody else?? It's not like putting Mint-specific code, is it?
I'm not saying forking is the way to go (I'm less and less sure what should be done BTW), but I mean, if one just create a geany-light/-lite project and push that to a publicly-available repository (anywhere, even on linuxmint.com) anybody could clone it and use it, or even package it. It's not a "nah! it's mine! don't touch it!"-thing, is it?
I said "couldn't *easily* be re-used". Of course you can still use the downstream changes but it's more work compared to having them all in the same place.
Either way, it's all pointless to discuss until someone writes down the changes that are needed and we see whether they belong in Geany or not instead of just theorizing.
Cheers, Matthew Brush
Am 21.10.2012 22:52, schrieb Matthew Brush:
On 12-10-21 01:13 PM, Colomban Wendling wrote:
Le 21/10/2012 21:52, Matthew Brush a écrit :
[...]
But that doesn't mean we couldn't extend which widgets can be hidden via the config file by adding more keys to it. I like this way the best because I can also use it for the (future) Mac bundle (it already has a customized geany.conf in the bundle to change some defaults).
(OT, but should really a Geany MacOS port hide some stuff??? Changing the default keybindings to be more MacOS-ish may indeed be sensible, but changing Geany?)
(There's more stuff, like using the correct fonts, commands, etc. Also, Apple thinks its users are idiots and so most programs seem to come with very simplified defaults, and lacking a decent text editor, a simplified Geany would be very useful for general text editing, further, it's nearly impossible to do development on OSX without having XCode and so having another "full featured" IDE is less useful. That being said, I don't want a "different Geany", just to change the defaults so that you have to explicitly enable "advanced" features/widgets to make it more "Mac-like" by default.)
I disagree with that. Not all MAC users are idiots, and were not here to make them even more dumb (or to classify them as dumb). If Apple does so that's fine for them but we don't have to follow suit.
If you want to provide a text editor (with a simplified UI, like the Mint guys) then that's another beast and you can most probably re-use the modifications done for Mint. But if you want to provide an IDE then provide an IDE (as powerful as possible) without going into classifying users of a certain OS as idiots (and thus dumbing down the IDE).
Best regards.
Hi All,
So our conclusion is that some seem to think it would be a good idea, but no-one has come forward and said "Ok, I will fork it on Github and lead the development of the simplifyable version, anyone wanting to help contact me".
So does this mean the answer for Mint is sorry we are unable to produce the simplified version ourselves, but are of course always willing to discuss it with anyone who does and to consider pull requests?
Cheers Lex
On 22 October 2012 19:51, Thomas Martitz < thomas.martitz@student.htw-berlin.de> wrote:
Am 21.10.2012 22:52, schrieb Matthew Brush:
On 12-10-21 01:13 PM, Colomban Wendling wrote:
Le 21/10/2012 21:52, Matthew Brush a écrit :
[...]
But that doesn't mean we couldn't extend which widgets can be hidden via the config file by adding more keys to it. I like this way the best because I can also use it for the (future) Mac bundle (it already has a customized geany.conf in the bundle to change some defaults).
(OT, but should really a Geany MacOS port hide some stuff??? Changing the default keybindings to be more MacOS-ish may indeed be sensible, but changing Geany?)
(There's more stuff, like using the correct fonts, commands, etc. Also, Apple thinks its users are idiots and so most programs seem to come with very simplified defaults, and lacking a decent text editor, a simplified Geany would be very useful for general text editing, further, it's nearly impossible to do development on OSX without having XCode and so having another "full featured" IDE is less useful. That being said, I don't want a "different Geany", just to change the defaults so that you have to explicitly enable "advanced" features/widgets to make it more "Mac-like" by default.)
I disagree with that. Not all MAC users are idiots, and were not here to make them even more dumb (or to classify them as dumb). If Apple does so that's fine for them but we don't have to follow suit.
If you want to provide a text editor (with a simplified UI, like the Mint guys) then that's another beast and you can most probably re-use the modifications done for Mint. But if you want to provide an IDE then provide an IDE (as powerful as possible) without going into classifying users of a certain OS as idiots (and thus dumbing down the IDE).
Best regards.
______________________________**_________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 12-11-07 06:36 PM, Lex Trotman wrote:
Hi All,
So our conclusion is that some seem to think it would be a good idea, but no-one has come forward and said "Ok, I will fork it on Github and lead the development of the simplifyable version, anyone wanting to help contact me".
So does this mean the answer for Mint is sorry we are unable to produce the simplified version ourselves, but are of course always willing to discuss it with anyone who does and to consider pull requests?
I wrote in response to the original message:
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.
It got the impression (especially from talking to Clem on IRC) that they were not even considering doing anything for quite some time and were not even 100% sure they wanted to use Geany. It sounded more like an open idea that might be something to investigate some time down the road.
Like I said previously, I'll help out, but unless anyone *actually* wants it, it's a waste of time to start wildly hacking away. Further we need more information on *specifically* what is wanted before we even know whether we want to do it as part of Geany or whether they should fork/distro-patch it.
I'd mark it as a "Pending" feature request with NEEDINFO status :)
Cheers, Matthew Brush
Joining in a bit late..
To start with, I think that a 'geany --light' and accompanying *.desktop entries would be an excellent and low-cost addition to Geany.
On Thu, Nov 8, 2012 at 5:36 AM, Matthew Brush mbrush@codebrainz.ca wrote:
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.
If you ever go ahead to tackle this, would the resulting light mode effectively remove the need for a new release of Mousepad? I remember that you did some work on it, but that you didn't get up to a release.
I'd mark it as a "Pending" feature request with NEEDINFO status :)
I think that best in this case would be to come up with a minimal-effort config-only changes to simplify Geany UI. You could use as a baseline the Leafpad/Mousepad/Gedit2 features, and then release the result in the wild. Then I expect that it will be rather straightforward, with input from Geany devels, users and Mint devels, to come up with some sort of consensus of what should be kept/added.
But unless someone makes this initial effort, the idea---however good---will likely rot on the list.
Cheers Liviu
Am 08.11.2012 03:36, schrieb Lex Trotman:
Hi All,
So our conclusion is that some seem to think it would be a good idea, but no-one has come forward and said "Ok, I will fork it on Github and lead the development of the simplifyable version, anyone wanting to help contact me".
My impression from the discussion was different. As I understand we absolutely want to avoid a fork if possible and have the simple mode in our main repository if the required changes are not too invasive. But we cannot determine how invasive they are unless we get more information about what should constitute this "simple mode".
Best regards.
On 8 November 2012 17:11, Thomas Martitz < thomas.martitz@student.htw-berlin.de> wrote:
Am 08.11.2012 03:36, schrieb Lex Trotman:
Hi All,
So our conclusion is that some seem to think it would be a good idea, but no-one has come forward and said "Ok, I will fork it on Github and lead the development of the simplifyable version, anyone wanting to help contact me".
My impression from the discussion was different. As I understand we absolutely want to avoid a fork if possible
Hi Thomas,
Ahhh, Github badly misuses the term fork. A Github fork is just another git clone, just like you have on your machine, but the Github one is public.
Why they chose to use a term like "fork" that has significant negative meanings I don't know.
Using a separate clone like this is the best workflow for big changes since it is based on, but separate from, the main repository and can have its own team separate from the main Geany one. It also has advantages like no accidental commits to the wrong branch in the main repo, anyone can create it and experiment etc. The main geany repository is usually kept as upstream so it can continually be merged to the clone and the result "painlessly" merged back into the main repository later.
and have the simple mode in our main repository if the required changes are
not too invasive. But we cannot determine how invasive they are unless we get more information about what should constitute this "simple mode".
And I agree with both you and Matthew that it needs more definition, so whoever wants to do it, talk to Clem on IRC about what is needed/not needed as the case may be. But if nobody is interested then we shouldn't not reply to Mint, thats just rude, we should say no, or those that are interested, progress it.
Cheers Lex
Best regards. ______________________________**_________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 08.11.2012 07:47, schrieb Lex Trotman:
and have the simple mode in our main repository if the required changes are not too invasive. But we cannot determine how invasive they are unless we get more information about what should constitute this "simple mode".And I agree with both you and Matthew that it needs more definition, so whoever wants to do it, talk to Clem on IRC about what is needed/not needed as the case may be. But if nobody is interested then we shouldn't not reply to Mint, thats just rude, we should say no, or those that are interested, progress it.
_Who_ it does and _when_ he does that probably depends on what the simple mode should look like, i.e. how large the changes need to be. So that should be defined first, before someone volunteers. Why should anyone volunteer to do "something" without an idea what "something" is? Besides, IMO Clem/Linux Mint should approach us, as a whole and not indivduals, and not the other way around to discuss this and define the simple mode. Right now he hasn't appeared in this discussion on this mailing list.
Best regards.
Le 21/10/2012 10:14, Matthew Brush a écrit :
On 12-10-20 06:01 PM, Lex Trotman wrote:
Reply from Clement:
"Regarding the default text editor, I've read the emails on the mailing list with interest. From our point of view, it wouldn't need to change much. Typically we're looking at a generic unbranded "text editor" that works great and is lightweight. Geany fits the bill nicely, pluma also to a lesser extent. There's two different kinds of users at play here, so I wouldn't like not having the full geany in the repositories (i.e. patching geany and dumbing it down by configuration wouldn't be a good solution for all devs using it out there), but I also wouldn't like to have geany itself, as a dev tool, installed by default, since it's a power tool most users wouldn't use (similarly we don't install tools like dconf-editor, remmina..etc..).
[...]
My 2c:
- The "lite" and the "full fat" version do need to be different
commands, the lite version is for simple use and has to start without options when used from the command line, and whilst full fat could be an option on the lite version, I'm not sure its preferable, a compile time decision makes life simpler. From a user POV two application names makes more sense I think.
Or I think it's easy enough (I think) to symlink some command, like to link "text-editor" to "geany --light" whether using some shell stuff, or launchers, or whatever.
As I said before, a "geany -mnt" script is a good start :)
- The question as I see it is, do we want to make the lite version a
part of the Geany codebase, clearly sharing as much as possible. That could be complex if the needs of the two diverge, so how likely is that? That also means two packages, two bug trackers etc. In the end this would be my preferred method if it looks like it will work.
If it does indeed come down to just hiding widgets, I think we could offer a way to do that. We (or Mint guys) could have a 2nd Glade file which has the visibility of much stuff set to false. Other way is to maintain an array of items to hide on startup. Both of these ideas were shared here I think. I made a quick and dirty patch to show the later form:
http://pastebin.geany.org/ODwZr/
For distro packages, they could be packaged like this:
geany-core - the full geany install minus glade & desktop files geany-light - geany-core plus the light glade & desktop file ** this would be installed by default on Mint geany - geany-core plus the full glade & desktop fileFor people who want to use the full (normal) Geany, they could install the "geany" package which could install the full Glade UI and the regular launchers and stuff. But the default is to have only "geany-light" (plus "geany-core") installed.
Geany doesn't have so much overhead that it's worth not installing the bulk of it up front.
I think that before getting wild with implementations we should list what the goal is. If I understand correctly, the Mint guys would like:
1) a re-brand, e.g. different icon/application name 2) all 'developer-like" things hidden/removed
2 is totally doable at runtime, that's just a matter of doing it.
1 however is more tricky, and I really don't think a --brand-name=Text\ Editor option makes any sense. However, it'd be quite easy to make the brand override-able at build time, e.g. #define BRAND "geany" or alike, and let this be overridden by the build system, a -D compiler switch or something. And Autotools let one already change the executable name.
So, what I mean here is that unless we want stock Geany have a "light" option, there's no much point in making this a runtime thing. So what I'd propose if it allows Mint guyes to do what they want is:
* we (Geany) make it easy to change the brand * they (Mint) maintain a tuned Glade file, and build Geany sources a second time with the appropriate flags, e.g. ./configure --program-transform-name='s/geany/text-editor/g' --brand="text-editor" --brand-display="Text Editor". Them either implementing this as a fork with only geany.glade diverging, as a standalone geany.glade (or even as a sed script or something), or more likely as a dpatch (to build a second package out of Geany's sources) doesn't matter much to me.
Would this be enough? If yes, I think it'd probably be the easier for us, while being easy enough for the Mint guys. And BTW, running with -mnt is easy too, just provide a wrapper script.
BTW, if we want to include the light option in stock Geany, we would need to to forgot keeping it up to date when adding new widgets or removing existing ones. And I'm not 100% sure it's realistic we won't forget it given that we probably won't run the light version ourselves ;)
- Or should the lite version be a separate repository with patches
transported between them? Of course needs separate bugtracker though.
It could, and then it'd keep distro-specific bugs from reaching Geany trackers (hopefully).
Not sure what Lex meant, but I don't want to maintain 2 repositories myself.
Regards, Colomban
Le 18/10/2012 21:34, Dimitar Zhekov a écrit :
[...]
- Write "minimal" mode for the find dialogs. They are not glade, but
even if they were, simply hiding "Use regular expressions" and "Use escape sequences" will leave a hole on the left part of the dialog.
I don't think hiding regular expression search is a good thing. Well, maybe it's a somewhat power-user feature, but IMHO it's a really important one, and if it's unchecked by default it shouldn't be any kind of a problem for dummies.
Regards, Colomban