I use the terminal emulator in Geany mainly for Git-commands and Drush.
When pulling the work from collegues using Git, geany pops up a file changed, or deleted warning for all changed or deleted open files which steals focus from the terminal, often right before I press 'enter' to execute a commend, resulting in Geany using the default action for that popup, which I then have to figure out what has happend.
Is it possible to suppress these popups when the terminal has focus?
Cheers!
Harold
On 17 April 2013 20:40, Harold Aling geany@sait.nl wrote:
I use the terminal emulator in Geany mainly for Git-commands and Drush.
When pulling the work from collegues using Git, geany pops up a file changed, or deleted warning for all changed or deleted open files which steals focus from the terminal, often right before I press 'enter' to execute a commend, resulting in Geany using the default action for that popup, which I then have to figure out what has happend.
Is it possible to suppress these popups when the terminal has focus?
The disk status is checked on keypresses (but only once every 30s no matter how fast you type :)
This means that we can tell that the user is interacting with Geany and so stops us popping those dialogs over other apps. But unfortunately the keypress code is independent of any window. It might be possible to check if the VTE is focussed and hold off the file check. It would be a little tricky since the VTE widget may not exist, but with care it could be done.
It just needs "someone" to do it :)
Cheers Lex
Cheers!
Harold _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
I've always thought the dialogs should be embedded anyway, which doesn't steal focus. What I mean is like gedit does, where at the top of the document a box appears before line 1 and says "This file has been modified". Then, people wouldn't have to press it until they wanted to since it would be associated with the document directly.
Thanks,
Steve
On 04/17/2013 05:31 AM, Lex Trotman wrote:
On 17 April 2013 20:40, Harold Aling <geany@sait.nl mailto:geany@sait.nl> wrote:
I use the terminal emulator in Geany mainly for Git-commands and Drush. When pulling the work from collegues using Git, geany pops up a file changed, or deleted warning for all changed or deleted open files which steals focus from the terminal, often right before I press 'enter' to execute a commend, resulting in Geany using the default action for that popup, which I then have to figure out what has happend. Is it possible to suppress these popups when the terminal has focus?The disk status is checked on keypresses (but only once every 30s no matter how fast you type :)
This means that we can tell that the user is interacting with Geany and so stops us popping those dialogs over other apps. But unfortunately the keypress code is independent of any window. It might be possible to check if the VTE is focussed and hold off the file check. It would be a little tricky since the VTE widget may not exist, but with care it could be done.
It just needs "someone" to do it :)
Cheers Lex
Cheers! Harold _______________________________________________ Devel mailing list Devel@lists.geany.org <mailto:Devel@lists.geany.org> https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 17.04.2013 16:49, schrieb Steven Blatnick:
I've always thought the dialogs should be embedded anyway, which doesn't steal focus. What I mean is like gedit does, where at the top of the document a box appears before line 1 and says "This file has been modified". Then, people wouldn't have to press it until they wanted to since it would be associated with the document directly.
Thanks,
You will find many people on this list that agree with you (including me). We've had proposals and even a prototype implementation (IIRC) for this but nothing ended up in Geany mainline. But your use case is a strong argument in favor of this. I too find the popup highly annoying.
Best regards.
On 13-04-18 05:16 AM, Thomas Martitz wrote:
Am 17.04.2013 16:49, schrieb Steven Blatnick:
I've always thought the dialogs should be embedded anyway, which doesn't steal focus. What I mean is like gedit does, where at the top of the document a box appears before line 1 and says "This file has been modified". Then, people wouldn't have to press it until they wanted to since it would be associated with the document directly.
Thanks,
You will find many people on this list that agree with you (including me). We've had proposals and even a prototype implementation (IIRC) for this but nothing ended up in Geany mainline. But your use case is a strong argument in favor of this. I too find the popup highly annoying.
If anyone wants to pick up where I left off and run the bikeshed gauntlet, the branch is still in the Geany repo (document-messages). It should be trivial to update it with the master branch. You'll probably want to check the mailing list archives for reference of what the issues were.
Cheers, Matthew Brush
On 19 April 2013 09:06, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-04-18 05:16 AM, Thomas Martitz wrote:
Am 17.04.2013 16:49, schrieb Steven Blatnick:
I've always thought the dialogs should be embedded anyway, which doesn't steal focus. What I mean is like gedit does, where at the top of the document a box appears before line 1 and says "This file has been modified". Then, people wouldn't have to press it until they wanted to since it would be associated with the document directly.
Thanks,
You will find many people on this list that agree with you (including me). We've had proposals and even a prototype implementation (IIRC) for this but nothing ended up in Geany mainline. But your use case is a strong argument in favor of this. I too find the popup highly annoying.
+1
If anyone wants to pick up where I left off and run the bikeshed gauntlet, the branch is still in the Geany repo (document-messages). It should be trivial to update it with the master branch. You'll probably want to check the mailing list archives for reference of what the issues were.
IIRC the only issues with the display stuff was the fact that it needs GTK 2.18 and should handle multiple occurrances of the same message without creating another info bar whilst there is already one for that message.
All that is stopping moving from 2.16 is Windows IIRC. If someone who has windows could help Enrico do that then I don't see a problem with moving to 2.18 and using the GTKinfobar displays instead of dialogs.
There were other issues in Matthews change around using notifications, but that should be a separate change and not part of the decision to use infobar.
Cheers Lex
Cheers, Matthew Brush
______________________________**_________________ 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 Fri, 19 Apr 2013 09:26:33 +1000 Lex Trotman elextr@gmail.com wrote:
All that is stopping moving from 2.16 is Windows IIRC. If someone who has windows could help Enrico do that then I don't see a problem with moving to 2.18 and using the GTKinfobar displays instead of dialogs.
The problem is gtk+ 2.18 / 2.20 for win~1 are buggy. So it's either 2.16 or 2.22...
As much as I hate platform specific code, could it be wrapped in a plugin, setting, or environment specific? Or is there another more reliable means of associating an embedded dialog with a document, such as using some lower-level calls to avoid the pitfalls of the gtk ones that do things strange in windows?
On 04/19/2013 11:41 AM, Dimitar Zhekov wrote:
On Fri, 19 Apr 2013 09:26:33 +1000 Lex Trotman elextr@gmail.com wrote:
All that is stopping moving from 2.16 is Windows IIRC. If someone who has windows could help Enrico do that then I don't see a problem with moving to 2.18 and using the GTKinfobar displays instead of dialogs.
The problem is gtk+ 2.18 / 2.20 for win~1 are buggy. So it's either 2.16 or 2.22...
Am 19.04.2013 19:41, schrieb Dimitar Zhekov:
On Fri, 19 Apr 2013 09:26:33 +1000 Lex Trotman elextr@gmail.com wrote:
All that is stopping moving from 2.16 is Windows IIRC. If someone who has windows could help Enrico do that then I don't see a problem with moving to 2.18 and using the GTKinfobar displays instead of dialogs.
The problem is gtk+ 2.18 / 2.20 for win~1 are buggy. So it's either 2.16 or 2.22...
What's the problem with later versions? gtk.org offers a fine 2.24 bundle for download (which is even the recommended version).
Best regards.
On Fri, 19 Apr 2013 20:51:46 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 19.04.2013 19:41, schrieb Dimitar Zhekov:
The problem is gtk+ 2.18 / 2.20 for win~1 are buggy. So it's either 2.16 or 2.22...
What's the problem with later versions? gtk.org offers a fine 2.24 bundle for download (which is even the recommended version).
None AFAIK. It depends on what minimum version we want to support.
On 20 April 2013 05:07, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Fri, 19 Apr 2013 20:51:46 +0200 Thomas Martitz thomas.martitz@student.htw-berlin.de wrote:
Am 19.04.2013 19:41, schrieb Dimitar Zhekov:
The problem is gtk+ 2.18 / 2.20 for win~1 are buggy. So it's either 2.16 or 2.22...
What's the problem with later versions? gtk.org offers a fine 2.24 bundle for download (which is even the recommended version).
None AFAIK. It depends on what minimum version we want to support.
Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman elextr@gmail.com wrote:
Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20.
I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany?
On 13-04-20 05:59 AM, Harold Aling wrote:
On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman elextr@gmail.com wrote:
Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20.
I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany?
It is rumored that some percentage (remember 0 is a percent :) of users are apparently stuck on ancient enterprise distros at work, need to use the latest bleeding edge Geany at all times, and are able install it but not GTK+ from source into $HOME. Or so the story goes :)
Cheers, Matthew Brush
On Sat, Apr 20, 2013 at 5:06 PM, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-04-20 05:59 AM, Harold Aling wrote:
On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman elextr@gmail.com wrote:
Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20.
I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany?
It is rumored that some percentage (remember 0 is a percent :) of users are apparently stuck on ancient enterprise distros at work, need to use the latest bleeding edge Geany at all times, and are able install it but not GTK+ from source into $HOME. Or so the story goes :)
Can those people please raise thair hands so that we can count them?
On a side note: more than 0% still use Internet Explorer 7 (or less!). Nobody supports that anymore.
Please do not let 0% block innovation for the other 100% of the Geany users!
On 20/04/2013 16:06, Matthew Brush wrote:
On 13-04-20 05:59 AM, Harold Aling wrote:
On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman elextr@gmail.com wrote:
Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20.
I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany?
It is rumored that some percentage (remember 0 is a percent :) of users are apparently stuck on ancient enterprise distros at work, need to use the latest bleeding edge Geany at all times, and are able install it but not GTK+ from source into $HOME. Or so the story goes :)
I imagine building newer GTK/GLib from source with only old dependencies would be a pain in the arse, having to grab and build all the newer dependencies too. It's also a pain for most users to install and manage multiple versions of libraries. Geany is actually very easy to build as it only requires Gtk/GLib.
Note: I have never built GTK/GLib from source.
On 13-04-20 09:52 AM, Nick Treleaven wrote:
On 20/04/2013 16:06, Matthew Brush wrote:
On 13-04-20 05:59 AM, Harold Aling wrote:
On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman elextr@gmail.com wrote:
Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20.
I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany?
It is rumored that some percentage (remember 0 is a percent :) of users are apparently stuck on ancient enterprise distros at work, need to use the latest bleeding edge Geany at all times, and are able install it but not GTK+ from source into $HOME. Or so the story goes :)
I imagine building newer GTK/GLib from source with only old dependencies would be a pain in the arse, having to grab and build all the newer dependencies too. It's also a pain for most users to install and manage multiple versions of libraries. Geany is actually very easy to build as it only requires Gtk/GLib.
It is a pain, but I'm more skeptical about what percentage of users are in this situation. Just thinking about the specific criteria you'd have to meet to be in this minority of users:
* Running old but still supported enterprise distro * No ability/access to install a separate system GTK+ * Aren't satisfied with the Geany in the repos * Need to run the absolute latest Geany from release or Git * Aren't willing to compile/install GTK+ stack into $HOME but are for Geany, but not for most other popular GTK+ software which requires newer GTK+.
Or, in the case of Windows:
* Need to run absolute latest Geany from release or Git * Required to have a specific old system-wide GTK+ * Unable to install a newer GTK+ specifically for Geany or * Unwilling to used the bundled GTK+ that comes with Geany * Not using lots of other GTK+ software that requires newer GTK+
So for some possibly insignificant number of Geany users (possibly even approaching 0 users), who still technically have a path to use latest Geany, albeit with some hassle (building GTK stack), we (contributors/developers) have to:
* Quadruple check every GTK+ function we call, referring to out of date documentation in some cases, to ensure we don't use API from the last 4 years or * Ensure all new code using API from the last 4 years is #if'd-out so that they work with both latest and ancient GTK+. * Maintain more stuff in the gtkcompat.h header to fake out a bunch of core and plugin code so we can also build against latest GTK+. * Have a separate old GTK+ on our dev. machines besides modern ones to test all changes against (although I don't do this personally).
IMO, the benefits to current and potential contributors and users of updating to a relatively modern min. GTK+ 2 version outweighs the negatives to some unknown small percentage of users.
Even Puppy Linux has had GTK+ 2.24 for the last two releases[1].
</rant>
Cheers, Matthew Brush
My experience based on my consulting customers is that they run old versions or Red Hat mostly, with only security updates added. Even point releases are viewed with suspicion, that is likely to mean they have to hire me to re-compile their crusty old business apps to new libraries since their own devs don't understand them. :)
On 21 April 2013 05:13, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-04-20 09:52 AM, Nick Treleaven wrote:
On 20/04/2013 16:06, Matthew Brush wrote:
On 13-04-20 05:59 AM, Harold Aling wrote:
On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman elextr@gmail.com wrote:
Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20.
I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany?
Yes
It is rumored that some percentage (remember 0 is a percent :) of users are apparently stuck on ancient enterprise distros at work, need to use the latest bleeding edge Geany at all times, and are able install it but not GTK+ from source into $HOME. Or so the story goes :)
Nobody knows how, let alone is allowed, to modify such fundamental software, even in their own home dir.
I imagine building newer GTK/GLib from source with only old dependencies would be a pain in the arse, having to grab and build all the newer dependencies too. It's also a pain for most users to install and manage multiple versions of libraries. Geany is actually very easy to build as it only requires Gtk/GLib.
It is a pain, but I'm more skeptical about what percentage of users are in this situation. Just thinking about the specific criteria you'd have to meet to be in this minority of users:
- Running old but still supported enterprise distro
tick
- No ability/access to install a separate system GTK+
tick, tick
- Aren't satisfied with the Geany in the repos
0.18 or older, no way, tick
- Need to run the absolute latest Geany from release or Git
Release yes, tick
- Aren't willing to compile/install GTK+ stack into $HOME but are for
Geany, but not for most other popular GTK+ software which requires newer GTK+.
You already said that, tick again
Or, in the case of Windows:
- Need to run absolute latest Geany from release or Git
Release yes tick
- Required to have a specific old system-wide GTK+
It will be whatever we bundle, each app has its own bundle
- Unable to install a newer GTK+ specifically for Geany or
Whats a GTK?
- Unwilling to used the bundled GTK+ that comes with Geany
Well, its bundled, so thats it
- Not using lots of other GTK+ software that requires newer GTK+
Whats a GTK?
For windows there is less of a problem since we, and every other app, supply a bundle including GTK. So the windows release can go to 2.24 (the new recommended release) without too much pain.
So for some possibly insignificant number of Geany users (possibly even approaching 0 users), who still technically have a path to use latest Geany, albeit with some hassle (building GTK stack), we (contributors/developers) have to:
The path of building GTK does not exist in corporate, it is not allowed, and web app designers don't know how to do it.
- Quadruple check every GTK+ function we call, referring to out of date
documentation in some cases, to ensure we don't use API from the last 4 years or
tick
- Ensure all new code using API from the last 4 years is #if'd-out so that
they work with both latest and ancient GTK+.
tick
- Maintain more stuff in the gtkcompat.h header to fake out a bunch of
core and plugin code so we can also build against latest GTK+.
tick
- Have a separate old GTK+ on our dev. machines besides modern ones to
test all changes against (although I don't do this personally).
no, but the nightly does for us,
IMO, the benefits to current and potential contributors and users of updating to a relatively modern min. GTK+ 2 version outweighs the negatives to some unknown small percentage of users.
Well, who knows what percentage? We are talking real users, they will not be on this list, and might not be on the user list. They just use software, they are not involved with it like we are.
Even Puppy Linux has had GTK+ 2.24 for the last two releases[1].
And that is irrelevant, a more effective question is, what does Red Hat 6.0 have? (thats a real question, my quick look at their website couldn't identify what it is)
Red Hat 6.0, released in 2010, is still currently in its phase one support and is still considered bleeding edge by many corporates, Red Hat 5.0 is still supported but is outside its phase one so I think its safe to ignore it now.
Cheers Lex
</rant>
Cheers, Matthew Brush
[1] http://distrowatch.com/table.**php?distribution=puppyhttp://distrowatch.com/table.php?distribution=puppy
______________________________**_________________ 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 Sun, Apr 21, 2013 at 1:20 AM, Lex Trotman elextr@gmail.com wrote:
And that is irrelevant, a more effective question is, what does Red Hat 6.0 have? (thats a real question, my quick look at their website couldn't identify what it is)
http://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/
"gtk2-2.18.9-12.el6.src.rpm"
Red Hat 6.0, released in 2010, is still currently in its phase one support and is still considered bleeding edge by many corporates, Red Hat 5.0 is still supported but is outside its phase one so I think its safe to ignore it now.
RHEL 7 is scheduled for the second half of 2013. How long do you think Geany should support RHEL 6 and thus withhold innovation/progress/modernize/etc? Adoption of RHEL 7 will be slow, so at least for another 2-3 years until RHEL 8 is released?
Seems rather strange to me ...
On 21 April 2013 09:40, Harold Aling geany@sait.nl wrote:
On Sun, Apr 21, 2013 at 1:20 AM, Lex Trotman elextr@gmail.com wrote:
And that is irrelevant, a more effective question is, what does Red Hat
6.0
have? (thats a real question, my quick look at their website couldn't identify what it is)
http://ftp.redhat.com/pub/redhat/linux/enterprise/6Client/en/os/SRPMS/
"gtk2-2.18.9-12.el6.src.rpm"
Thanks Harold,
That looks to me like we could go to 2.18 without inflicting too much pain. And that would allow the gtkinfobars. Since we have just done a release, now would be the time to do it.
So Colomban, I officially propose that we move the minumum GTK version to 2.18 as soon as the windows builder is moved to 2.24.
Cheers Lex
Red Hat 6.0, released in 2010, is still currently in its phase one
support
and is still considered bleeding edge by many corporates, Red Hat 5.0 is still supported but is outside its phase one so I think its safe to
ignore
it now.
RHEL 7 is scheduled for the second half of 2013. How long do you think Geany should support RHEL 6 and thus withhold innovation/progress/modernize/etc? Adoption of RHEL 7 will be slow, so at least for another 2-3 years until RHEL 8 is released?
Seems rather strange to me ...
But then you clearly are not in the corporate world, every change costs money, so only do it if you ****have**** to, are you really sure you have to, well you only have half the budget anyway.
But supporting an old version of GTK doesn't really stop us innovating, in most cases we just have to have some #ifdefs.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On Sun, 21 Apr 2013 09:51:39 +1000 Lex Trotman elextr@gmail.com wrote:
So Colomban, I officially propose that we move the minumum GTK version to 2.18 as soon as the windows builder is moved to 2.24.
+1.
Dear all,
Sorry for causing so much commotion. Did not expect this to happen, although I also chipped in on the discussion.
Lessons learned: bumping to GTK+ 2.18 (Linux) and GTK+ 2.24 (Windows) is a good idea.
I personally hope that when it becomes obvious that a newer GTK+ on Linux can save a lot of time/trouble the "0% of users" don't ruin it for the Geany developers. GTK+ 2.24 was released in Januari 2011, so it's already over 2 years old [1].
Back to the popup issue? (without mentioning GTK-versions)
[1] https://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00042.html
On Sun, Apr 21, 2013 at 12:49 PM, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On Sun, 21 Apr 2013 09:51:39 +1000 Lex Trotman elextr@gmail.com wrote:
So Colomban, I officially propose that we move the minumum GTK version to 2.18 as soon as the windows builder is moved to 2.24.
+1.
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 21 April 2013 22:47, Harold Aling geany@sait.nl wrote:
Dear all,
Sorry for causing so much commotion. Did not expect this to happen, although I also chipped in on the discussion.
Lessons learned: bumping to GTK+ 2.18 (Linux) and GTK+ 2.24 (Windows) is a good idea.
Lessons learned, Geany ML threads can run off in some strange directions, but thats good, it means that people are willing to interact and care about where its going. :)
I personally hope that when it becomes obvious that a newer GTK+ on Linux can save a lot of time/trouble the "0% of users" don't ruin it for the Geany developers. GTK+ 2.24 was released in Januari 2011, so it's already over 2 years old [1].
Back to the popup issue? (without mentioning GTK-versions)
Well, sadly its impossible without mentioning them, but to summarise:
1. There seems to be general agreement that a non-dialog notification is a good idea
2. Matthew has a prototype using gtkinfobar which is the GTK solution for non-dialog notifications, its what you see in gedit.
3. gtkinfobar only exists in GTK >= 2.18 but Geany still supports 2.16 (sorry but I have to mention that :)
4. I don't remember exactly where Matthews prototype got to, I don't think there were any real problems with the infobar, more with other stuff which is feeding the infobar, but that can be checked in the meantime while waiting for the GTK version upgrade (there I said it again). I guess it would be nice if someone(s) offered to update the branch to current Geany and to iron out any remaining issues.
5. And someone (that person again) who has a windows mingw dev environment should offer to help checking the windows build with GTK 2.24 and help updating the nightly build to that too.
6. Finally the unmentionable (GTK version) can then be upgraded :)
7. then the infobar can be merged
I don't think I forgot any steps. Oh yeah, volunteers are welcome :)
Cheers Lex
PS and anyone who has a good reason not to do this, please also speak up now, or forever hold your peace.
[1] https://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00042.html
[...]
Sorry for the looooong delay, there's no excuses.
Le 21/04/2013 01:51, Lex Trotman a écrit :
[...]
That looks to me like we could go to 2.18 without inflicting too much pain. And that would allow the gtkinfobars. Since we have just done a release, now would be the time to do it.
So Colomban, I officially propose that we move the minumum GTK version to 2.18 as soon as the windows builder is moved to 2.24.
Agreed. Just FTR, I'm totally fine with most dependency bump if there is a good reason for them. And non-intrusive "dialogs" *is* a good reason :)
So I agree got bump to GTK 2.18, and whatever fits for Windows builds.
Just needs somebody to do the infobar stuff :)
Regards, Colomban
Am 21.04.2013 01:20, schrieb Lex Trotman:
* Need to run the absolute latest Geany from release or GitRelease yes, tick
I can understand all your ticks, except this one.
1) The latest release does still support 2.16 2) I do not believe that it's important to RHEL users living on a 4 years old system to run the upcoming release (which is many months ahead, quite possibly even after the release of RHEL 7). 1.23 is a very fine release for them for current RHEL users. 3) If aren't going to run 1.24 we can bump GTK in git *now*, as they will be stuck on 1.23 anyway.
Best regards.
On 13-04-20 04:20 PM, Lex Trotman wrote:
My experience based on my consulting customers is that they run old versions or Red Hat mostly, with only security updates added. Even point releases are viewed with suspicion, that is likely to mean they have to hire me to re-compile their crusty old business apps to new libraries since their own devs don't understand them. :)
On 21 April 2013 05:13, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-04-20 09:52 AM, Nick Treleaven wrote:
On 20/04/2013 16:06, Matthew Brush wrote:
On 13-04-20 05:59 AM, Harold Aling wrote:
On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman elextr@gmail.com wrote:
Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20.
I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany?
Yes
It is rumored that some percentage (remember 0 is a percent :) of users are apparently stuck on ancient enterprise distros at work, need to use the latest bleeding edge Geany at all times, and are able install it but not GTK+ from source into $HOME. Or so the story goes :)
Nobody knows how, let alone is allowed, to modify such fundamental software, even in their own home dir.
IIUC on Unix-ey systems, your home directory is completely writable by you and using the environment you can compile, install and run any software you want. I'm no sys-admin though.
I imagine building newer GTK/GLib from source with only old dependencies would be a pain in the arse, having to grab and build all the newer dependencies too. It's also a pain for most users to install and manage multiple versions of libraries. Geany is actually very easy to build as it only requires Gtk/GLib.
It is a pain, but I'm more skeptical about what percentage of users are in this situation. Just thinking about the specific criteria you'd have to meet to be in this minority of users:
- Running old but still supported enterprise distro
tick
Tick what? Let me get this straight... you are running an old but still supported enterprise distro...
- No ability/access to install a separate system GTK+
tick, tick
And you don't have root/admin rights...
- Aren't satisfied with the Geany in the repos
0.18 or older, no way, tick
And you can't run any release of Geany from 0.00 to present that uses GTK+ < some proposed newer version...
- Need to run the absolute latest Geany from release or Git
Release yes, tick
And arbitrarily need to run bleeding edge Geany...
- Aren't willing to compile/install GTK+ stack into $HOME but are for
Geany, but not for most other popular GTK+ software which requires newer GTK+.
You already said that, tick again
And aren't able to compile a series of dependencies that takes maybe an afternoon for the first time...
[...]
- Not using lots of other GTK+ software that requires newer GTK+
Whats a GTK?
That library that the GIMP and Pidgin and many other more popular programs use which you'd have to install a newer GTK+ library to use.
For windows there is less of a problem since we, and every other app, supply a bundle including GTK. So the windows release can go to 2.24 (the new recommended release) without too much pain.
So for some possibly insignificant number of Geany users (possibly even approaching 0 users), who still technically have a path to use latest Geany, albeit with some hassle (building GTK stack), we (contributors/developers) have to:
The path of building GTK does not exist in corporate, it is not allowed, and web app designers don't know how to do it.
If you can't build GTK+ in $HOME it's unlikely you can build Geany there.
And why, if you're a web-app designer do you need to install the absolute latest Geany release, heck, you're probably running OSX if you are one, and IIRC macports and friends stay pretty current on GTK+ versions.
- Quadruple check every GTK+ function we call, referring to out of date
documentation in some cases, to ensure we don't use API from the last 4 years or
tick
Tick what? It's a PITA, some old API functions don't even have a "since" version.
- Ensure all new code using API from the last 4 years is #if'd-out so that
they work with both latest and ancient GTK+.
tick
Tick what? It's a huge pain to write stuff twice, once for "ancient" GTK+ and once for regular GTK+.
- Maintain more stuff in the gtkcompat.h header to fake out a bunch of
core and plugin code so we can also build against latest GTK+.
tick
Tick what? It's already caused troubles and is only a band-aid for the inevitable.
- Have a separate old GTK+ on our dev. machines besides modern ones to
test all changes against (although I don't do this personally).
no, but the nightly does for us,
Which makes Enrico or poor user notify us days later of what we broke.
IMO, the benefits to current and potential contributors and users of updating to a relatively modern min. GTK+ 2 version outweighs the negatives to some unknown small percentage of users.
Well, who knows what percentage? We are talking real users, they will not be on this list, and might not be on the user list. They just use software, they are not involved with it like we are.
Exactly, and I'd wager the *vast* majority of Geany's users are:
1) Running Windows, grab latest setup.exe from website 2) Running Linux, grab latest package from repos 3) Running OSX, grab latest package from macports (or friends) 4) Compile from source using a modern distro.
Even if 1 in 1000 of Geany's users fit your "tick" list, that's 0.1% of all users, and I think even that might be a stretch (based on anecdotal evidence watching the bug tracker, mailing list and IRC).
Even Puppy Linux has had GTK+ 2.24 for the last two releases[1].
And that is irrelevant, a more effective question is, what does Red Hat 6.0 have? (thats a real question, my quick look at their website couldn't identify what it is)
It's not irrelevant because Geany is the default text editor on Puppy linux (last I checked) and it used to be one of the reasons not to bump GTK+ versions.
Red Hat 6.0, released in 2010, is still currently in its phase one support and is still considered bleeding edge by many corporates, Red Hat 5.0 is still supported but is outside its phase one so I think its safe to ignore it now.
Wasn't it you who mentioned the trouble of supporting more users in another thread? Why should we make the same compatibility commitment as a publicly traded multi-million dollar corporation? I can assure you if some mega-corp comes along and offers me 20 grand to backport some later fixes, I'll be happy to do so.
I definitively agree that there's someone/a few people out there, in this strange self-imposed situation that are mentioned above, but I'd bet good money it's a such a small minority of Geany's users, possibly even less than 1%, to be worth bending over backwards for.
Cheers, Matthew Brush
[...]
I definitively agree that there's someone/a few people out there, in this strange self-imposed situation that are mentioned above, but I'd bet good money it's a such a small minority of Geany's users, possibly even less than 1%, to be worth bending over backwards for.
The real problem is none of us knows how many actual users there are in any particular system configuration. I am only going on my experience, which as a contractor at least includes a spread of companies.
In the past its always been me introducing Geany, but recently I have been pleasantly surprised to find a few customers already using it on Red Hat.
Hence my concern to keep support for at least the Red Hat version that is still in primary support.
Cheers Lex
Cheers, Matthew Brush
______________________________**_________________ 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 13-04-20 05:48 PM, Lex Trotman wrote:
[...]
I definitively agree that there's someone/a few people out there, in this strange self-imposed situation that are mentioned above, but I'd bet good money it's a such a small minority of Geany's users, possibly even less than 1%, to be worth bending over backwards for.
The real problem is none of us knows how many actual users there are in any particular system configuration. I am only going on my experience, which as a contractor at least includes a spread of companies.
In the past its always been me introducing Geany, but recently I have been pleasantly surprised to find a few customers already using it on Red Hat.
Hence my concern to keep support for at least the Red Hat version that is still in primary support.
But if they're your customers, given your deep familiarity with Geany's source and your likely influence on installed versions of it, could you not backport critical fixes and improvements of which there are very few or run a release closer to the year in which their corporate OS vendor offers support up to for other packages?
Cheers, Matthew Brush
On 21 April 2013 10:56, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-04-20 05:48 PM, Lex Trotman wrote:
[...]
I definitively agree that there's someone/a few people out there, in this
strange self-imposed situation that are mentioned above, but I'd bet good money it's a such a small minority of Geany's users, possibly even less than 1%, to be worth bending over backwards for.
The real problem is none of us knows how many actual users there are in any particular system configuration. I am only going on my experience, which as a contractor at least includes a spread of companies.
In the past its always been me introducing Geany, but recently I have been pleasantly surprised to find a few customers already using it on Red Hat.
Hence my concern to keep support for at least the Red Hat version that is still in primary support.
But if they're your customers, given your deep familiarity with Geany's source and your likely influence on installed versions of it, could you not backport critical fixes and improvements of which there are very few or run a release closer to the year in which their corporate OS vendor offers support up to for other packages?
Well as I said, some have already installed it before I came along, that means that there are more that have Geany and are not my customers. They are the ones I'm talking about supporting.
Cheers Lex
Cheers, Matthew Brush
______________________________**_________________ 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 13-04-20 06:02 PM, Lex Trotman wrote:
On 21 April 2013 10:56, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-04-20 05:48 PM, Lex Trotman wrote:
[...]
I definitively agree that there's someone/a few people out there, in this
strange self-imposed situation that are mentioned above, but I'd bet good money it's a such a small minority of Geany's users, possibly even less than 1%, to be worth bending over backwards for.
The real problem is none of us knows how many actual users there are in any particular system configuration. I am only going on my experience, which as a contractor at least includes a spread of companies.
In the past its always been me introducing Geany, but recently I have been pleasantly surprised to find a few customers already using it on Red Hat.
Hence my concern to keep support for at least the Red Hat version that is still in primary support.
But if they're your customers, given your deep familiarity with Geany's source and your likely influence on installed versions of it, could you not backport critical fixes and improvements of which there are very few or run a release closer to the year in which their corporate OS vendor offers support up to for other packages?
Well as I said, some have already installed it before I came along, that means that there are more that have Geany and are not my customers. They are the ones I'm talking about supporting.
But really, they have Geany latest, can't install new software, have a really old GTK+ version, need features from bleeding edge Geany and can't get you to update them from source or do it themselves?
This sounds like either a completely fictitious or insignificant group of users to me. If they can't make due with older Geany versions, can't update their GTK+ environment, but *can* install Geany from sources, I'd say they're either schizophrenic, lazy, liars or in the 0.001% of total users. In all cases, IMO, they aren't worth serving for free on my buck.
Cheers, Matthew Brush
On 13-04-20 06:12 PM, Matthew Brush wrote:
On 13-04-20 06:02 PM, Lex Trotman wrote:
On 21 April 2013 10:56, Matthew Brush mbrush@codebrainz.ca wrote:
On 13-04-20 05:48 PM, Lex Trotman wrote:
[...]
I definitively agree that there's someone/a few people out there, in this
strange self-imposed situation that are mentioned above, but I'd bet good money it's a such a small minority of Geany's users, possibly even less than 1%, to be worth bending over backwards for.
The real problem is none of us knows how many actual users there are in any particular system configuration. I am only going on my experience, which as a contractor at least includes a spread of companies.
In the past its always been me introducing Geany, but recently I have been pleasantly surprised to find a few customers already using it on Red Hat.
Hence my concern to keep support for at least the Red Hat version that is still in primary support.
But if they're your customers, given your deep familiarity with Geany's source and your likely influence on installed versions of it, could you not backport critical fixes and improvements of which there are very few or run a release closer to the year in which their corporate OS vendor offers support up to for other packages?
Well as I said, some have already installed it before I came along, that means that there are more that have Geany and are not my customers. They are the ones I'm talking about supporting.
But really, they have Geany latest, can't install new software, have a really old GTK+ version, need features from bleeding edge Geany and can't get you to update them from source or do it themselves?
This sounds like either a completely fictitious or insignificant group of users to me. If they can't make due with older Geany versions, can't update their GTK+ environment, but *can* install Geany from sources, I'd say they're either schizophrenic, lazy, liars or in the 0.001% of total users. In all cases, IMO, they aren't worth serving for free on my buck.
Just to be clear, I'm fine with hacking on behalf of the other 99.9..% of users for free on my buck, I just hate wasting hack-time for pointless historical nonsense that affects 0.0n% of legacy users.
Cheers, Matthew Brush
I can't speak for others, but...
I'm not sure what versions of GTK are considered bleeding edge, but I am on linux Mint 11 (2011) since I am still upset with how Gnome3 has screwed linux up and made it's UI regress substantially, but I digress...
Here is my version information if this is helpful: geany 1.23 (git >= df4373c) (built on Mar 8 2013 with GTK 2.24.4, GLib 2.28.6)
It looks like I'm using newer GTK 2, but if by bleeding edge you mean GTK 3, then I haven't made that switch yet. I'm guessing you just mean 2.24 for GTK2 and something separate for GTK 3 (I don't know the versions it has).
Hope this helps,
Steve
________________________________ From: Harold Aling geany@sait.nl To: Geany development list devel@lists.geany.org Sent: Saturday, April 20, 2013 6:59 AM Subject: Re: [Geany-Devel] Don't pop-up messages/steal focus when in terminal
On Sat, Apr 20, 2013 at 1:40 AM, Lex Trotman elextr@gmail.com wrote:
Agree with Thomas, we should go to 2.24 for windows since we supply the bundle, Linux doesn't need to go so far, for eg what GTK did the current red hat and suse enterprise versions release with, expect 2.18 or 2.20.
I might be stepping completely out of line with this remark: Do people with dusty old GTK's use bleeding edge Geany? _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13-04-20 08:12 AM, Steven Blatnick wrote:
I can't speak for others, but...
I'm not sure what versions of GTK are considered bleeding edge,
The references to bleeding edge were about Geany, like latest release or from Git, not bleeding edge GTK+3 (that's a whole other story [1]).
Cheers, Matthew Brush
[1] :)
Le 19/04/2013 19:41, Dimitar Zhekov a écrit :
On Fri, 19 Apr 2013 09:26:33 +1000 Lex Trotman elextr@gmail.com wrote:
All that is stopping moving from 2.16 is Windows IIRC. If someone who has windows could help Enrico do that then I don't see a problem with moving to 2.18 and using the GTKinfobar displays instead of dialogs.
The problem is gtk+ 2.18 / 2.20 for win~1 are buggy. So it's either 2.16 or 2.22...
I don't think it's a problem, the Windows installer can use whatever version better fits it. I'm not even sure why we still use 2.16 for it rather than 2.24?
But anyway, we speak about the *lowest* requirement, one can build it with any newer version that is API compatible, and run it against any version that is ABI compatible.
Regards, Colomban