On 10.4.2015 г. 18:36, Colomban Wendling wrote:
waf: Fix the checks for openpty() on FreeBSD
ACK. Please, be sure to use the same check for debugger, it probably needs it.
While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right? I can cut an entire module (gtk216.[ch]) from Scope if 2.18 is the minimum required version...
-- E-gards: Jimmy
On 13 April 2015 at 03:20, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On 10.4.2015 г. 18:36, Colomban Wendling wrote:
waf: Fix the checks for openpty() on FreeBSD
ACK. Please, be sure to use the same check for debugger, it probably needs it.
While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right? I can cut an entire module (gtk216.[ch]) from Scope if 2.18 is the minimum required version...
Its still 2.16, but only the documentation checkbox is left on #245 to go to 2.24.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 13 April 2015 at 09:40, Lex Trotman elextr@gmail.com wrote:
On 13 April 2015 at 03:20, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On 10.4.2015 г. 18:36, Colomban Wendling wrote:
waf: Fix the checks for openpty() on FreeBSD
ACK. Please, be sure to use the same check for debugger, it probably needs it.
While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right? I can cut an entire module (gtk216.[ch]) from Scope if 2.18 is the minimum required version...
2.18!!! c'mon, get with it, Geany is now 2.24 :)
(thanks codebrainz)
Cheers Lex
Its still 2.16, but only the documentation checkbox is left on #245 to go to 2.24.
Cheers Lex
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 15-04-12 10:20 AM, Dimitar Zhekov wrote:
[snip]
While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right? I can cut an entire module (gtk216.[ch]) from Scope if 2.18 is the minimum required version...
I just merged PR #245[0], so 2.24 should be good version to use.
Cheers, Matthew Brush
On 13.4.2015 г. 04:11, Matthew Brush wrote:
While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right?
I just merged PR #245[0], so 2.24 should be good version to use.
On 13.4.2015 г. 04:12, Lex Trotman wrote:
2.18!!! c'mon, get with it, Geany is now 2.24 :)
Wow, that may be not a very good news for the Windows users.
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab background with CSS, in 2.24 the (in)active horizontal tabs are always with the same background AFAICT.
In fact, I have not found a way to change neither the active nor the inactive horizontal tab background in 2.24 - even with all backgrounds for all widgets set to red, the horizontal tabs are still light gray.
Using color to distinguish the tabs does the job, albeit worse, but conflicts with Geany red for modified and green for read-only tab. If somebody knows how to change the (in)active horizontal tab background, please drop me a note...
On 13.4.2015 г. 04:05, Matthew Brush wrote:
Remove pre-GTK+ 2.24 preprocessor checks and related code
Looking at the changes, the lowest gtk+ version checked is 2.20, which suggests that for Geany there is no difference between 2.22 and 2.24. Would it be possible to keep the minimum version 2.22? I have heard it has some problems under Windows, but never actually seen any.
-- E-gards: Jimmy
On 14 April 2015 at 03:33, Dimitar Zhekov dimitar.zhekov@gmail.com wrote:
On 13.4.2015 г. 04:11, Matthew Brush wrote:
While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right?
I just merged PR #245[0], so 2.24 should be good version to use.
On 13.4.2015 г. 04:12, Lex Trotman wrote:
2.18!!! c'mon, get with it, Geany is now 2.24 :)
Wow, that may be not a very good news for the Windows users.
Well, the GTK windows guys on the GTK list basically seem to agree that the next good windows version after 2.16 is 2.24, there were various major problems with the versions in between.
So it was chosen because it may be the least worst version for windows.
Cheers Lex
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab background with CSS, in 2.24 the (in)active horizontal tabs are always with the same background AFAICT.
In fact, I have not found a way to change neither the active nor the inactive horizontal tab background in 2.24 - even with all backgrounds for all widgets set to red, the horizontal tabs are still light gray.
Using color to distinguish the tabs does the job, albeit worse, but conflicts with Geany red for modified and green for read-only tab. If somebody knows how to change the (in)active horizontal tab background, please drop me a note...
On 13.4.2015 г. 04:05, Matthew Brush wrote:
Remove pre-GTK+ 2.24 preprocessor checks and related code
Looking at the changes, the lowest gtk+ version checked is 2.20, which suggests that for Geany there is no difference between 2.22 and 2.24. Would it be possible to keep the minimum version 2.22? I have heard it has some problems under Windows, but never actually seen any.
See above.
-- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
On 14.4.2015 г. 01:56, Lex Trotman wrote:
On 14 April 2015 at 03:33, Dimitar Zhekovdimitar.zhekov@gmail.com wrote:
On 13.4.2015 г. 04:11, Matthew Brush wrote:
Wow, that may be not a very good news for the Windows users.
Well, the GTK windows guys on the GTK list basically seem to agree that the next good windows version after 2.16 is 2.24, there were various major problems with the versions in between.
Judging from the broken notepad tab coloring in 2.24, and the extremely slow 3.6.4, which comes without sub-pixel hinting by default, I doubt than any of them uses Windows for more than a 10 minute test.
So it was chosen because it may be the least worst version for windows.
Well, it's not a problem *for me*. I'm compiling from source, and Geany actually depends on 2.22, so replacing the number takes only a minute.
-- E-gards: Jimmy
On 13/04/15 19:33, Dimitar Zhekov wrote:
On 13.4.2015 г. 04:11, Matthew Brush wrote:
While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right?
I just merged PR #245[0], so 2.24 should be good version to use.
On 13.4.2015 г. 04:12, Lex Trotman wrote:
2.18!!! c'mon, get with it, Geany is now 2.24 :)
Wow, that may be not a very good news for the Windows users.
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab
I don't get it. For me it looks like as in the attached screenshot. I don't have a GTK 2.16 build at hand for a direct comparison but the notebook tabs look OK to me in the GTK 2.24 build.
Regards, Enrico
On 14.4.2015 г. 22:37, Enrico Tröger wrote:
On 13/04/15 19:33, Dimitar Zhekov wrote:
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab
I don't get it. For me it looks like as in the attached screenshot. I don't have a GTK 2.16 build at hand for a direct comparison but the notebook tabs look OK to me in the GTK 2.24 build.
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
-- E-gards: Jimmy
On 15-04-15 10:15 AM, Dimitar Zhekov wrote:
On 14.4.2015 г. 22:37, Enrico Tröger wrote:
On 13/04/15 19:33, Dimitar Zhekov wrote:
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab
I don't get it. For me it looks like as in the attached screenshot. I don't have a GTK 2.16 build at hand for a direct comparison but the notebook tabs look OK to me in the GTK 2.24 build.
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
We could re-parent the Scintilla widget into a frame (or whichever is the proper widget) and set its border shadow to "in" or "etched in", which would probably look more appropriate on Windows[0][1][2], and likely still look fine on most non-Windows themes.
Alternatively, we could probably tweak the default windows theme (engine) to make it look more "native".
Cheers, Matthew Brush
[0]: http://www.testech-elect.com/ontime/vstudio.gif [1]: http://cache.filehippo.com/img/ex/626__notepad1.png [2]: http://scitedebug.luaforge.net/scite-debug.png
On Thu, Apr 16, 2015 at 2:41 AM, Matthew Brush mbrush@codebrainz.ca wrote:
We could re-parent the Scintilla widget into a frame (or whichever is the proper widget) and set its border shadow to "in" or "etched in", which would probably look more appropriate on Windows[0][1][2], and likely still look fine on most non-Windows themes.
This is what I originally tried for
https://github.com/geany/geany/pull/411
(and also sidebar and message window) but with flat themes there were suddenly too many lines (double-line border for each of the subwindows) and it only looked good for the Windows theme.
Cheers,
Jiri
On 16.4.2015 г. 03:41, Matthew Brush wrote:
On 15-04-15 10:15 AM, Dimitar Zhekov wrote:
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost [...]
We could re-parent the Scintilla widget into a frame (or whichever is the proper widget) and set its border shadow to "in" or "etched in", which would probably look more appropriate on Windows[0][1][2], and likely still look fine on most non-Windows themes.
The Win~1 users are a minority. Maybe if it can be done depending on the OS...
Alternatively, we could probably tweak the default windows theme (engine) to make it look more "native".
I was unable to set the active/inactive tab backgrounds with any theme settings. In particular, the settings from gtk+ <= 2.22 did not work.
-- E-gards: Jimmy
Am 15.04.2015 um 19:15 schrieb Dimitar Zhekov:
On 14.4.2015 г. 22:37, Enrico Tröger wrote:
On 13/04/15 19:33, Dimitar Zhekov wrote:
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab
I don't get it. For me it looks like as in the attached screenshot. I don't have a GTK 2.16 build at hand for a direct comparison but the notebook tabs look OK to me in the GTK 2.24 build.
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
In my splitwindow2 patches I underline the text label in active tab. So that the user can tell which of the 2 notebooks is active currently (the tabs alone don't show that).
Would that be a worthy fix to your problem?
Best regards
On 16.4.2015 г. 12:37, Thomas Martitz wrote:
Am 15.04.2015 um 19:15 schrieb Dimitar Zhekov:
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost [...] due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
In my splitwindow2 patches I underline the text label in active tab. So that the user can tell which of the 2 notebooks is active currently (the tabs alone don't show that).
Would that be a worthy fix to your problem?
Yes. The ability to have the current tab underlined, italic or bold seems like a good thing to have, irrespective of my problems with 2.24 + Win~1. It probably should be done programmatically?
-- E-gards: Jimmy
On 16/04/15 18:47, Dimitar Zhekov wrote:
On 16.4.2015 г. 12:37, Thomas Martitz wrote:
Am 15.04.2015 um 19:15 schrieb Dimitar Zhekov:
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost [...] due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
In my splitwindow2 patches I underline the text label in active tab. So that the user can tell which of the 2 notebooks is active currently (the tabs alone don't show that).
Would that be a worthy fix to your problem?
Yes. The ability to have the current tab underlined, italic or bold seems like a good thing to have, irrespective of my problems with 2.24 + Win~1. It probably should be done programmatically?
I sort of like the idea. And would agree that it might be not just useful on Windows. Thomas, can this be done in code so it could be enabled/disabled by a setting?
Regards, Enrico
Am 16.04.2015 um 21:47 schrieb Enrico Tröger:
On 16/04/15 18:47, Dimitar Zhekov wrote:
On 16.4.2015 г. 12:37, Thomas Martitz wrote:
Am 15.04.2015 um 19:15 schrieb Dimitar Zhekov:
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost [...] due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
In my splitwindow2 patches I underline the text label in active tab. So that the user can tell which of the 2 notebooks is active currently (the tabs alone don't show that).
Would that be a worthy fix to your problem?
Yes. The ability to have the current tab underlined, italic or bold seems like a good thing to have, irrespective of my problems with 2.24 + Win~1. It probably should be done programmatically?
I sort of like the idea. And would agree that it might be not just useful on Windows. Thomas, can this be done in code so it could be enabled/disabled by a setting?
Sure, but why would you disable it? Is a pref necessary? And at least with my splitwindow2 patch set something like this is needed to determine the focused document (each notebook can have an active doc, but only one of them can be focused at any time).
PS: In case it's not clear, splitwindow2 refers to my patch set that enables splitting the editor into two widgets so that 2 docs are visible at the same time. In contrast to the plugin it does this so that both widget work the same way, so support styling, keybindings and other things properly.
Best regards
Le 16/04/2015 23:14, Thomas Martitz a écrit :
Am 16.04.2015 um 21:47 schrieb Enrico Tröger:
On 16/04/15 18:47, Dimitar Zhekov wrote:
On 16.4.2015 г. 12:37, Thomas Martitz wrote:
Am 15.04.2015 um 19:15 schrieb Dimitar Zhekov:
[…]
In my splitwindow2 patches I underline the text label in active tab. So that the user can tell which of the 2 notebooks is active currently (the tabs alone don't show that).
Would that be a worthy fix to your problem?
Yes. The ability to have the current tab underlined, italic or bold seems like a good thing to have, irrespective of my problems with 2.24 + Win~1. It probably should be done programmatically?
I sort of like the idea. And would agree that it might be not just useful on Windows. Thomas, can this be done in code so it could be enabled/disabled by a setting?
Sure, but why would you disable it?
Because it's damn ugly :) (and serves absolutely no purpose -- for me)
Is a pref necessary?
Yes.
And at least with my splitwindow2 patch set something like this is needed to determine the focused document (each notebook can have an active doc, but only one of them can be focused at any time).
Only if the splitwindow is actually used. And even, underlying the tab might not be the best visual indicator ever, though I can't suggest something easy that would actually work (I'd think a better one would be some kind of slightly deactivated editor, but while doable it's a bit annoying with Scintilla).
On 15-04-16 02:20 PM, Colomban Wendling wrote:
Le 16/04/2015 23:14, Thomas Martitz a écrit :
Am 16.04.2015 um 21:47 schrieb Enrico Tröger:
On 16/04/15 18:47, Dimitar Zhekov wrote:
On 16.4.2015 г. 12:37, Thomas Martitz wrote:
Am 15.04.2015 um 19:15 schrieb Dimitar Zhekov:
[…]
In my splitwindow2 patches I underline the text label in active tab. So that the user can tell which of the 2 notebooks is active currently (the tabs alone don't show that).
Would that be a worthy fix to your problem?
Yes. The ability to have the current tab underlined, italic or bold seems like a good thing to have, irrespective of my problems with 2.24 + Win~1. It probably should be done programmatically?
I sort of like the idea. And would agree that it might be not just useful on Windows. Thomas, can this be done in code so it could be enabled/disabled by a setting?
Sure, but why would you disable it?
Because it's damn ugly :) (and serves absolutely no purpose -- for me)
+1, and it's also something that should be controlled by user/system themes, not the app, IMO.
Is a pref necessary?
Yes.
+1. If people really want it, I'd appreciate to be able to disable it.
And at least with my splitwindow2 patch set something like this is needed to determine the focused document (each notebook can have an active doc, but only one of them can be focused at any time).
Only if the splitwindow is actually used. And even, underlying the tab might not be the best visual indicator ever, though I can't suggest something easy that would actually work (I'd think a better one would be some kind of slightly deactivated editor, but while doable it's a bit annoying with Scintilla).
Or maybe just a special border around the focused scintilla or nothing at all (except the correct window title, and blinking cursor).
Cheers, Matthew Brush
Am 16.04.2015 um 23:20 schrieb Colomban Wendling:
Is a pref necessary?
Yes.
In that case it's not the best solution and we should find an indication that people don't want to outright disable.
The underline gets the job done but I'm not married to it. Can you suggest a better alternative?
And at least with my splitwindow2 patch set something like this is needed to determine the focused document (each notebook can have an active doc, but only one of them can be focused at any time).
Only if the splitwindow is actually used. And even, underlying the tab might not be the best visual indicator ever, though I can't suggest something easy that would actually work (I'd think a better one would be some kind of slightly deactivated editor, but while doable it's a bit annoying with Scintilla).
And it might be barely visible depending on the color scheme. Because of that I think no indication that involves the scintilla widget alone will work for everybody.
Anyway we can discuss this specifically for splitwindow2. Let's not further hijack this thread, I just wanted to throw in that a visual indication other than what GTK does by itself might become necessary anyway.
Best regards.
I don't mind some form of underline, highlight or something to indicate the active tab, and as Thomas says, that future-proofs it if one day we get slipt or multi windows.
It would be good if it had a pref so it could be turned off on those platforms/themes that don't need it. Forcing something non-standard on users isn't the best idea.
Cheers Lex
Le 15/04/2015 19:15, Dimitar Zhekov a écrit :
On 14.4.2015 г. 22:37, Enrico Tröger wrote:
On 13/04/15 19:33, Dimitar Zhekov wrote:
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab
I don't get it. For me it looks like as in the attached screenshot. I don't have a GTK 2.16 build at hand for a direct comparison but the notebook tabs look OK to me in the GTK 2.24 build.
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
FWIW I get the real Windows GTK theme straight out of the GTK2 bundle ( no modification, no nothing, for some reason I didn't even have to set it), and it has a clear separation of the current tab (and feels more native/less ugly). Wouldn't this address your issue? (even better than avoiding using GTK 2.24 altogether) Or do you have another problem with the integrated theme?
Regards, Colomban
On 16.4.2015 г. 14:41, Colomban Wendling wrote:
Le 15/04/2015 19:15, Dimitar Zhekov a écrit :
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost [...] the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
FWIW I get the real Windows GTK theme straight out of the GTK2 bundle ( no modification, no nothing, for some reason I didn't even have to set it), and it has a clear separation of the current tab (and feels more native/less ugly).
Huh... What version of gtk+ is this? I was unable to set the tabs background to anything different than the default gray using .gtkrc-2.0, but maybe it takes the background color(s) from some element(s) of the Windows theme, or the rendering is different depending on the Windows version.
Wouldn't this address your issue? (even better than avoiding using GTK 2.24 altogether) Or do you have another problem with the integrated theme?
The problem is, it doesn't look much different than the Enrico's example, no matter the theme, though I have not tested extensively under 7even. Well, if XP is the problem, I wonder how it'll look under 10? I plan it as my next Windows version.
If that's really dependent on the Windows version, it can break any moment, and I'd prefer the ability (mentioned by Thomas) to have an option for underlining the current tab text (or bold / italic it).
Or should I get the heavy guns and write a plugin that displays line(s) of styled buttons that behave as tabs? The default tabs can be hidden in the interface preferences.
BTW, having tabs on the left/right "solves" the problem, since the background color *is* applied to the vertical tabs. But that would be a bit unusual recommendation for all Win~1 users...
-- E-gards: Jimmy
Le 16/04/2015 19:15, Dimitar Zhekov a écrit :
On 16.4.2015 г. 14:41, Colomban Wendling wrote:
Le 15/04/2015 19:15, Dimitar Zhekov a écrit :
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost [...] the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
FWIW I get the real Windows GTK theme straight out of the GTK2 bundle ( no modification, no nothing, for some reason I didn't even have to set it), and it has a clear separation of the current tab (and feels more native/less ugly).
Huh... What version of gtk+ is this?
It's 2.24.10 from the official bundle, and it uses the "native" engine. Normally you activate it by setting
gtk-theme-name = "MS-Windows"
in etc/gtk-2.0/gtkrc, as stated in the bundle's readme. But for some reason I didn't even had to do that on Windows 7.
I was unable to set the tabs background to anything different than the default gray using .gtkrc-2.0, but maybe it takes the background color(s) from some element(s) of the Windows theme, or the rendering is different depending on the Windows version.
I can't seem to really change the colors when using the "MS-Windows" theme, but I guess it's kinda expected some things aren't really overridable with a "native" theme that uses the Windows theming API or something.
However, using "Raleigh" (the one you seem to use given the look) it's relatively easy (well, not to guess what to change, but to change it). Here's an example changing the *inactive* tabs (because changing the active's background also changes the border around the tab's content and I didn't like it):
style "notebook" { bg[ACTIVE] = "#888888888888" } style "notebook-label" { fg[ACTIVE] = "#eeeeeeeeeeee" } widget "*.GtkNotebook" style "notebook" widget "*.GtkNotebook.*GtkLabel" style "notebook-label"
(not very well tested, might override too much)
Attached screenshot shows the (ugly) result.
Wouldn't this address your issue? (even better than avoiding using GTK 2.24 altogether) Or do you have another problem with the integrated theme?
The problem is, it doesn't look much different than the Enrico's example, no matter the theme, though I have not tested extensively under 7even.
Hum, to my eyes on my capture it looks quite different… and attached is the same on XP, still using the "MS-Windows" theme.
Well, if XP is the problem, I wonder how it'll look under 10? I plan it as my next Windows version.
XP is not the problem, it works just the same. Of course the "MS-Windows" theme looks different as it tried to feel native and the Windows themes are different, but that's all.
[…]
Or should I get the heavy guns and write a plugin that displays line(s) of styled buttons that behave as tabs? The default tabs can be hidden in the interface preferences.
If you like it, sure, but it sounds a bit heavy for something that should be solvable with a theme :)
Regards, Colomban
On 16.4.2015 г. 23:36, Colomban Wendling wrote:
I can't seem to really change the colors when using the "MS-Windows" theme, but I guess it's kinda expected some things aren't really overridable with a "native" theme that uses the Windows theming API or something.
But the vertical tabs still respect bg[ACTIVE]. Gee...
However, using "Raleigh" (the one you seem to use given the look) it's relatively easy (well, not to guess what to change, but to change it). [...]
Alright, I finally got it. To whoever might be interested:
1. The default theme for gtk+ 2.24 under Windows has been changed to "MS-Windows". Raleigh/gtk-2.0/gtkrc still says "This theme is the default theme if no other theme is selected", but that's wrong. The bundle README still contains instructions on how to set the theme to "MS-Windows", which is now unneeded - it would have been better if they changed it with "how to set Raleigh if you want the previous look".
2. The horizontal (only) notebook tabs backgrounds under "MS-Windows" is unchangeable with any gtkrc settings. That applies to 2.24, _2.22_, and probably the previous versions. The backgrounds are taken from the Windows theme, but seem to ignore the settings in Display -> Appearance -> Advanced, or there might be no appropriate setting. And on XP, that may be dependent on Appearance -> Windows XP style vs. Windows Classic style.
Thanks to everyone in the mailing list who was willing to help. It was a waste of time, but at least if someone in the users list complains, we know the answer.
(At some point, I changed the theme to "Emacs" - but only under 2.22, to see how it looks. Have I done that under 2.24, this thread would have been much shorter.)
-- E-gards: Jimmy
On 17/04/15 21:42, Dimitar Zhekov wrote:
On 16.4.2015 г. 23:36, Colomban Wendling wrote:
I can't seem to really change the colors when using the "MS-Windows" theme, but I guess it's kinda expected some things aren't really overridable with a "native" theme that uses the Windows theming API or something.
But the vertical tabs still respect bg[ACTIVE]. Gee...
However, using "Raleigh" (the one you seem to use given the look) it's relatively easy (well, not to guess what to change, but to change it). [...]
Alright, I finally got it. To whoever might be interested:
- The default theme for gtk+ 2.24 under Windows has been changed to
"MS-Windows". Raleigh/gtk-2.0/gtkrc still says "This theme is the default theme if no other theme is selected", but that's wrong. The bundle README still contains instructions on how to set the theme to "MS-Windows", which is now unneeded - it would have been better if they changed it with "how to set Raleigh if you want the previous look".
- The horizontal (only) notebook tabs backgrounds under "MS-Windows" is
unchangeable with any gtkrc settings. That applies to 2.24, _2.22_, and probably the previous versions. The backgrounds are taken from the Windows theme, but seem to ignore the settings in Display -> Appearance -> Advanced, or there might be no appropriate setting. And on XP, that may be dependent on Appearance -> Windows XP style vs. Windows Classic style.
Thanks to everyone in the mailing list who was willing to help. It was a waste of time, but at least if someone in the users list complains, we know the answer.
(At some point, I changed the theme to "Emacs" - but only under 2.22, to see how it looks. Have I done that under 2.24, this thread would have been much shorter.)
Thanks a lot for the clarification.
So, how do we want to proceed?
Provided that Thomas' underline trick works with the MS-Windows theme, we could maybe add this to the Wiki by providing a copy&paste ready gtkrc snippet for Windows users who want to a better visual indication of the active tab?
That would be cleaner and easier than a new preference just for the underlining.
Regards, Enrico
On 19.4.2015 г. 16:43, Enrico Tröger wrote:
On 17/04/15 21:42, Dimitar Zhekov wrote:
Alright, I finally got it. To whoever might be interested:
The default theme for gtk+ 2.24 under Windows has been changed [...]
The horizontal (only) notebook tabs backgrounds under "MS-Windows" is
unchangeable with any gtkrc settings. [...]
So, how do we want to proceed?
Warn the users that the default theme has been changed, and they need gtk-theme-name = "Raleigh" in etc/gtkrc to get the previous behavior (unless they already have set a theme, in which case there will be no difference). Using .gtkrc-2.0 in their home path will also work, for the people who prefer/need to run Win~1 as a regular user.
Provided that Thomas' underline trick works with the MS-Windows theme, we could maybe add this to the Wiki by providing a copy&paste ready gtkrc snippet for Windows users who want to a better visual indication of the active tab?
That would be nice, I have seen editors under Win~1 providing bold as an option for the active tab. However, I don't know a way to address the editor notebook specifically under gtk+ 2, without affecting the sidebar (and any other notebooks at the same hierarchy level). Setting the editor notebook widget name to "GeanyEditorNotebook" does the trick, but breaks compatibility: the current
widget "GeanyMainWindow.GtkVBox.GtkVPaned.GtkHPaned.GtkNotebook*"
addressing does not match GeanyEditorNotebook any more.
So, instead of setting the widget name in Geany, it may be better to write a small plugin that ui_lookups for specified widget id-s, and sets their widget names. That'll make every single geany.glade widget addressable, and let the user decide on what (s)he wants.
-- E-gards: Jimmy
On 15/04/15 19:15, Dimitar Zhekov wrote:
On 14.4.2015 г. 22:37, Enrico Tröger wrote:
On 13/04/15 19:33, Dimitar Zhekov wrote:
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab
I don't get it. For me it looks like as in the attached screenshot. I don't have a GTK 2.16 build at hand for a direct comparison but the notebook tabs look OK to me in the GTK 2.24 build.
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
I'm afraid I still do not completely understand the problem. I personally find the horizontal tabs nicer and easier to find the active tab than it is for the vertical tabs(as in the messages window at the bottom). There I have difficulties to easily see which tab is active.
Is this what you mean or is my reception of visuals just different?
Regards, Enrico
On 16/04/15 21:51, Enrico Tröger wrote:
On 15/04/15 19:15, Dimitar Zhekov wrote:
On 14.4.2015 г. 22:37, Enrico Tröger wrote:
On 13/04/15 19:33, Dimitar Zhekov wrote:
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab
I don't get it. For me it looks like as in the attached screenshot. I don't have a GTK 2.16 build at hand for a direct comparison but the notebook tabs look OK to me in the GTK 2.24 build.
That's exactly what I'm talking about. The white horizontal line, which normally gives nice outline [vertical_tabs], but is almost lost due to the white editor background, combined with the identical unchangeable background for the tabs. Not completely indistinguishable, but much worse than 2.22, and hard on many tabs.
I'm afraid I still do not completely understand the problem. I personally find the horizontal tabs nicer and easier to find the active tab than it is for the vertical tabs(as in the messages window at the bottom). There I have difficulties to easily see which tab is active.
Is this what you mean or is my reception of visuals just different?
Forget it. I finally got it. I just concentrated on your screenshot of the horizontal tabs in GTK 2.22 without realizing that it was from GTK 2.22 and not 2.24. Now I see clearly, that my screenshot also shows the problem.
Sorry for the noise.
Regards, Enrico
On 15 April 2015 at 05:37, Enrico Tröger enrico.troeger@uvena.de wrote:
On 13/04/15 19:33, Dimitar Zhekov wrote:
On 13.4.2015 г. 04:11, Matthew Brush wrote:
While on configuring, the README file still lists gtk+ 2.16 as a minimum requirement for Geany - but it's actually 2.18 with GtkInfoBar now, right?
I just merged PR #245[0], so 2.24 should be good version to use.
On 13.4.2015 г. 04:12, Lex Trotman wrote:
2.18!!! c'mon, get with it, Geany is now 2.24 :)
Wow, that may be not a very good news for the Windows users.
In 2.24, the horizontal tabs under Win~1 have this "flat" or "modern" or whatever look, and you can only distinguish the current tab via a slight 3D effect. And unlike 3.x, where you can easily set the active tab
I don't get it. For me it looks like as in the attached screenshot. I don't have a GTK 2.16 build at hand for a direct comparison but the notebook tabs look OK to me in the GTK 2.24 build.
I agree that tabs displayed as per your screenshot make the active one less than visible at a quick glance, but changing the whole of GTK just to change the theming seems a bit heavy.
Cheers Lex
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Le 12/04/2015 19:20, Dimitar Zhekov a écrit :
On 10.4.2015 г. 18:36, Colomban Wendling wrote:
waf: Fix the checks for openpty() on FreeBSD
ACK. Please, be sure to use the same check for debugger, it probably needs it.
The same commits should already have altered both Scope and Debugger to use the same checks.
Regards, Colomban
