Hello Geany developers,
I just wanted to say a few words about the editor customization (syntax highlighting and the likes)...
While the possibilties of customization are good already (and probably more than enough) I always somehow missed the possibility of defining different fonts/size for different styles...
It's not so important, so I let it go, until I used SciTE for a while...and passed to level of customization that was such a luxury that it was hard to let go...
Now, it might have been obvious to most of you but I figured since Geany use scintilla as well, it must have the same possibilities and sure enough with some hacking of the source, i got where I wanted...see screenshot to have a better idea
http://img201.imageshack.us/img201/4089/geanyscreenshot.png
multi-font/size possibilities, perfect dark background for the folding bar, bigger choice of markers, size of the margins... it's not much but it counts in the long run... and geany is even better than before in my eyes now....
Now, to the main point, I understand the aim of developing a lightweight sober IDE....so right from the bat, confusing the user with millions of possibility of customization might not be suited...
I'm kinda testing the water here...if this extra customization matters to people, I could clean up my hacks...and come up (or anyone willing to) come up with a system to implement it...
in any case, it would be nice to have this possibilites mentionned in Hacking Geany at least...I'm sure some people would be glad to find the infos...
Cheers, Jimmy
Jimmy Paillet schrieb: http://img201.imageshack.us/img201/4089/geanyscreenshot.png
I'm kinda testing the water here...if this extra customization matters to people, I could clean up my hacks...and come up (or anyone willing to) come up with a system to implement it...
in any case, it would be nice to have this possibilites mentionned in Hacking Geany at least...I'm sure some people would be glad to find the infos...
Cheers, Jimmy
I would definitely love it, it looks fantastic. I'm not sure if it counts as bloat if scintilla already implements it.
Btw, what font are you using there? The one with the slightly rotated 'e' I mean
Best regards.
On Mon, 27 Apr 2009 18:58:08 +0200, Jimmy wrote:
Hey Jimmy,
I always somehow missed the possibility of defining different fonts/size for different styles...
I personally hate this as it makes it all inconsistent and especially different font sizes confuses me a lot. But that's just me, I guess there are other people around who will like it.
http://img201.imageshack.us/img201/4089/geanyscreenshot.png
multi-font/size possibilities, perfect dark background for the folding bar, bigger choice of markers, size of the margins... it's not much but it counts in the long run... and geany is even better than before in my eyes now....
Now, to the main point, I understand the aim of developing a lightweight sober IDE....so right from the bat, confusing the user with millions of possibility of customization might not be suited...
I'm kinda testing the water here...if this extra customization matters to people, I could clean up my hacks...and come up (or anyone willing to) come up with a system to implement it...
Yeah, that'd be the very first step: provide a clean patch (ideally based on a recent SVN version).
A few questions which came to my mind: How to represent fonts+sizes in filetypes.*? * By adding two additional fields for font name + size to all existing styles of all existing filetypes? -> that would probably break any existing colour scheme or at least cause lots of work for theme authors * Make the two additional fields optional? -> so everything works as by now but interested users can extend it on their own? This would require good documentation and advertisement of that feature.
In another post you mentioned something like "filetype.toto.extended". While I think at some point it might make sense to split the current filetype.* definition files into settings and style-related, yet another set of files for whatever settings seems to much overhead and make things more complicated than necessary, IMO.
in any case, it would be nice to have this possibilites mentionned in Hacking Geany at least...I'm sure some people would be glad to find the infos...
Not sure. There is already a section "Syntax highlighting". What exactly do you expect to be added?
Regards, Enrico
hey,
2009/4/28 Enrico Tröger enrico.troeger@uvena.de
On Mon, 27 Apr 2009 18:58:08 +0200, Jimmy wrote:
Hey Jimmy,
I always somehow missed the possibility of defining different fonts/size for different styles...
I personally hate this as it makes it all inconsistent and especially different font sizes confuses me a lot. But that's just me, I guess there are other people around who will like it.
Oh yeah, this is a love/hate stuff...the graphic designer in me likes to play around with fonts... As you long as you stick with Monospace fonts (fixed width), you can still get a clean code that aligns properly and all... anyway....
http://img201.imageshack.us/img201/4089/geanyscreenshot.png
multi-font/size possibilities, perfect dark background for the folding bar, bigger choice of markers, size of the margins... it's not much but it counts in the long run... and geany is even better than before in my eyes now....
Now, to the main point, I understand the aim of developing a lightweight sober IDE....so right from the bat, confusing the user with millions of possibility of customization might not be suited...
I'm kinda testing the water here...if this extra customization matters to people, I could clean up my hacks...and come up (or anyone willing to) come up with a system to implement it...
Yeah, that'd be the very first step: provide a clean patch (ideally based on a recent SVN version).
Does anyone have some experiences in Mercurial -> SVN conversion... that'll be a good occasion to try out svn in any case....
A few questions which came to my mind: How to represent fonts+sizes in filetypes.*?
- By adding two additional fields for font name + size to all existing
styles of all existing filetypes? -> that would probably break any existing colour scheme or at least cause lots of work for theme authors
- Make the two additional fields optional?
-> so everything works as by now but interested users can extend it on their own? This would require good documentation and advertisement of that feature.
Second is best yes probably...that wouldn't be handy to oblige everyone to edit their themes to use a new version... if people fancy changing some fonts, instead of having word;#colorfg;#colofbg;false;false they'll just add relevant stuff at the end... word;#colorfg;#colofbg;false;false;!Monaco, 10
In another post you mentioned something like "filetype.toto.extended". While I think at some point it might make sense to split the current filetype.* definition files into settings and style-related, yet another set of files for whatever settings seems to much overhead and make things more complicated than necessary, IMO.
I agree...I just see this as a solution that would cause the least disturbances to the code...
in any case, it would be nice to have this possibilites mentionned in Hacking Geany at least...I'm sure some people would be glad to find the infos...
Not sure. There is already a section "Syntax highlighting". What exactly do you expect to be added?
On second thought not much....I guess what's written here is enough for the brave kind that want of get into this... The scintilla doc is quite dry, there's not some much nice detailed examples floating around... bit so that' s more a scintilla doc thing than geany's, you're right...
Cheers, Jimmy
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Tue, 28 Apr 2009 22:12:04 +0200, Jimmy wrote:
Hey,
I always somehow missed the possibility of defining different fonts/size for different styles...
I personally hate this as it makes it all inconsistent and especially different font sizes confuses me a lot. But that's just me, I guess there are other people around who will like it.
Oh yeah, this is a love/hate stuff...the graphic designer in me likes to play around with fonts... As you long as you stick with Monospace fonts (fixed width), you can still get a clean code that aligns properly and all...
No doubt on that. I personally just don't like it but who cares what I like :).
http://img201.imageshack.us/img201/4089/geanyscreenshot.png
multi-font/size possibilities, perfect dark background for the folding bar, bigger choice of markers, size of the margins... it's not much but it counts in the long run... and geany is even better than before in my eyes now....
Now, to the main point, I understand the aim of developing a lightweight sober IDE....so right from the bat, confusing the user with millions of possibility of customization might not be suited...
I'm kinda testing the water here...if this extra customization matters to people, I could clean up my hacks...and come up (or anyone willing to) come up with a system to implement it...
Yeah, that'd be the very first step: provide a clean patch (ideally based on a recent SVN version).
Does anyone have some experiences in Mercurial -> SVN conversion... that'll be a good occasion to try out svn in any case....
Nope. But if have the sources in a Mercurial repository, just create a patch and send it to the list. Me or anyone else probably will be able to apply it to a current SVN version.
A few questions which came to my mind: How to represent fonts+sizes in filetypes.*?
- By adding two additional fields for font name + size to all
existing styles of all existing filetypes? -> that would probably break any existing colour scheme or at least cause lots of work for theme authors
- Make the two additional fields optional?
-> so everything works as by now but interested users can extend it on their own? This would require good documentation and advertisement of that feature.
Second is best yes probably...that wouldn't be handy to oblige everyone to edit their themes to use a new version... if people fancy changing some fonts, instead of having word;#colorfg;#colofbg;false;false they'll just add relevant stuff at the end... word;#colorfg;#colofbg;false;false;!Monaco, 10
Yo, this would be fine.
In another post you mentioned something like "filetype.toto.extended". While I think at some point it might make sense to split the current filetype.* definition files into settings and style-related, yet another set of files for whatever settings seems to much overhead and make things more complicated than necessary, IMO.
I agree...I just see this as a solution that would cause the least disturbances to the code...
Hmm, not sure how this would affect the code less. Just let's agree on not doing this.
The scintilla doc is quite dry, there's not some much nice detailed examples floating around...
It's more or less just a matter of practise reading the Scintilla docs :).
Regards, Enrico
On Wed, 29 Apr 2009 18:29:59 +0200, Enrico wrote:
http://img201.imageshack.us/img201/4089/geanyscreenshot.png
multi-font/size possibilities, perfect dark background for the folding bar, bigger choice of markers, size of the margins... it's not much but it counts in the long run... and geany is even better than before in my eyes now....
Now, to the main point, I understand the aim of developing a lightweight sober IDE....so right from the bat, confusing the user with millions of possibility of customization might not be suited...
I'm kinda testing the water here...if this extra customization matters to people, I could clean up my hacks...and come up (or anyone willing to) come up with a system to implement it...
Yeah, that'd be the very first step: provide a clean patch (ideally based on a recent SVN version).
Does anyone have some experiences in Mercurial -> SVN conversion... that'll be a good occasion to try out svn in any case....
Nope. But if have the sources in a Mercurial repository, just create a patch and send it to the list. Me or anyone else probably will be able to apply it to a current SVN version.
Ping :).
Regards, Enrico
anyone willing to) come up with a system to implement it...
Yeah, that'd be the very first step: provide a clean patch (ideally based on a recent SVN version).
Does anyone have some experiences in Mercurial -> SVN conversion... that'll be a good occasion to try out svn in any case....
Nope. But if have the sources in a Mercurial repository, just create a patch and send it to the list. Me or anyone else probably will be able to apply it to a current SVN version.
Ping :).
yep...yep :D I was drawn away by something else for a while....
I'm progressing slowly...I have added an entry gchar* to the GeanyLexerStyle struct...to hold a font name... i'm studying how it propagates, how the structure is used by different functions...i'm facing pointer pbs, basically...my font name does not propagate properly through functions...
The way I'm hacking highlighting right now is probably not proper as well... basically in set_sci_style(), i'm passing a bunch of conditional SSM(sci, SCI_STYLESETFONT, style, (sptr_t) some_font_name);
but for example, if I use the change font option in the menu of geany, it's breaking this customization....it's good enough for my use...but not for public release.... if you have a hint for me... :D
cheers jimmy
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 8 May 2009 00:24:01 +0200, Jimmy wrote:
anyone willing to) come up with a system to implement it...
Yeah, that'd be the very first step: provide a clean patch (ideally based on a recent SVN version).
Does anyone have some experiences in Mercurial -> SVN conversion... that'll be a good occasion to try out svn in any case....
Nope. But if have the sources in a Mercurial repository, just create a patch and send it to the list. Me or anyone else probably will be able to apply it to a current SVN version.
Ping :).
yep...yep :D I was drawn away by something else for a while....
Sorry, I didn't mean to hurry you up or to request anything. Just a status update :).
I'm progressing slowly...I have added an entry gchar* to the GeanyLexerStyle struct...to hold a font name... i'm studying how it propagates, how the structure is used by different
Oh, I though you already have that part written as your screenshots looked like it was working already. Sorry.
functions...i'm facing pointer pbs, basically...my font name does not propagate properly through functions...
If you need help for a specific problem, just ask.
but for example, if I use the change font option in the menu of geany, it's breaking this customization....it's good enough for my use...but not for public release.... if you have a hint for me... :D
Ah, that's a problem. Maybe we should add highlighting_set_font() or something which is called by editor_set_font() which then sets the passed font only if there is no font specified for a specific style. This problem only exists because I never expected we need to use different fonts per style.
Regards, Enrico
Ping :).
yep...yep :D I was drawn away by something else for a while....
Sorry, I didn't mean to hurry you up or to request anything. Just a status update :).
don't worry, i didn't takek it as such :D
I'm progressing slowly...I have added an entry gchar* to the GeanyLexerStyle struct...to hold a font name... i'm studying how it propagates, how the structure is used by different
Oh, I though you already have that part written as your screenshots looked like it was working already. Sorry.
yes i have it working...and use it on a daily basis for my work ...but just because I hard-coded my font choice in set_sci_style... and left the fileypes.foo untouched for now.... hackish, but just wanted to find out if it was possible in some way at that time....
functions...i'm facing pointer pbs, basically...my font name does not propagate properly through functions...
If you need help for a specific problem, just ask.
ok...it's probably silly, as i'm not an experienced C programmer...and didn't spend a lot of time on it... but as I told you, I expanded the GeanyLexerStyle structure....
in get_keyfile_style and get_key_file_hex my adds to the filetypes.foo are properly read... and when i print out my new element of the struct it's either null or the fontname I've just entered in the file....
but when i try to access my new entry in a another function (such as set_sci_style), it has been obviously been written over by something else.... i'm sure it's something obvious as when I replace the new entry gchar* fontname by gint font_size.... (and so expecting font size dto be declared instead of a font name) then i got it working as intended... I could just add a number after the italic boolean entry in filetype.foo and it would be picked up as a font size, and transmitted through set_sci_style....
but for example, if I use the change font option in the menu of geany, it's breaking this customization....it's good enough for my use...but not for public release.... if you have a hint for me... :D
Ah, that's a problem. Maybe we should add highlighting_set_font() or something which is called by editor_set_font() which then sets the passed font only if there is no font specified for a specific style. This problem only exists because I never expected we need to use different fonts per style.
I'll look into that...it's not a real nuisance as it is anyway....
Jimmy
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 8 May 2009 18:26:15 +0200, Jimmy wrote:
functions...i'm facing pointer pbs, basically...my font name does not propagate properly through functions...
If you need help for a specific problem, just ask.
ok...it's probably silly, as i'm not an experienced C programmer...and didn't spend a lot of time on it... but as I told you, I expanded the GeanyLexerStyle structure....
in get_keyfile_style and get_key_file_hex my adds to the filetypes.foo are properly read... and when i print out my new element of the struct it's either null or the fontname I've just entered in the file....
but when i try to access my new entry in a another function (such as set_sci_style), it has been obviously been written over by something
Hard to say without any code but it sounds like the char* pointer is either freed in between or it's a static string which is only valid within a function. Just create a diff of your current code and send it to the list or me or some paste bin or whatever.
Regards, Enrico
Hi, I think i can express it clearly now.... this my GeanyLexerStyle:
typedef struct GeanyLexerStyle { gint foreground; /**< Foreground text colour, in @c 0xBBGGRR format. */ gint background; /**< Background text colour, in @c 0xBBGGRR format. */ gboolean bold; /**< Bold. */ gboolean italic; /**< Italic. */ gchar* font_perso; /** A font name*/ gint font_size; } GeanyLexerStyle;
in get_keyfile_style, this struct is filled (as least for c)... thanks to a gchar** list... pointing to the [styling] sections of filetypes.foo
of course at the end of this function, list is free'd....so my pointer font_perso points to crap outside the func...hence my pb... :D when I comment out the free statement, thinhs behave logically...
what do you reckon? free the list variable later on?
jimmy
2009/5/8 Enrico Tröger enrico.troeger@uvena.de
On Fri, 8 May 2009 18:26:15 +0200, Jimmy wrote:
functions...i'm facing pointer pbs, basically...my font name does not propagate properly through functions...
If you need help for a specific problem, just ask.
ok...it's probably silly, as i'm not an experienced C programmer...and didn't spend a lot of time on it... but as I told you, I expanded the GeanyLexerStyle structure....
in get_keyfile_style and get_key_file_hex my adds to the filetypes.foo are properly read... and when i print out my new element of the struct it's either null or the fontname I've just entered in the file....
but when i try to access my new entry in a another function (such as set_sci_style), it has been obviously been written over by something
Hard to say without any code but it sounds like the char* pointer is either freed in between or it's a static string which is only valid within a function. Just create a diff of your current code and send it to the list or me or some paste bin or whatever.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
nevermind...just used a strcpy...went just fine... i'll probably make decent advances now... cheers j
2009/5/8 Jimmy Paillet jimmy.paillet@gmail.com
Hi, I think i can express it clearly now.... this my GeanyLexerStyle:
typedef struct GeanyLexerStyle { gint foreground; /**< Foreground text colour, in @c 0xBBGGRR format. */ gint background; /**< Background text colour, in @c 0xBBGGRR format. */ gboolean bold; /**< Bold. */ gboolean italic; /**< Italic. */ gchar* font_perso; /** A font name*/ gint font_size; } GeanyLexerStyle;
in get_keyfile_style, this struct is filled (as least for c)... thanks to a gchar** list... pointing to the [styling] sections of filetypes.foo
of course at the end of this function, list is free'd....so my pointer font_perso points to crap outside the func...hence my pb... :D when I comment out the free statement, thinhs behave logically...
what do you reckon? free the list variable later on?
jimmy
2009/5/8 Enrico Tröger enrico.troeger@uvena.de
On Fri, 8 May 2009 18:26:15 +0200, Jimmy wrote:
functions...i'm facing pointer pbs, basically...my font name does not propagate properly through functions...
If you need help for a specific problem, just ask.
ok...it's probably silly, as i'm not an experienced C programmer...and didn't spend a lot of time on it... but as I told you, I expanded the GeanyLexerStyle structure....
in get_keyfile_style and get_key_file_hex my adds to the filetypes.foo are properly read... and when i print out my new element of the struct it's either null or the fontname I've just entered in the file....
but when i try to access my new entry in a another function (such as set_sci_style), it has been obviously been written over by something
Hard to say without any code but it sounds like the char* pointer is either freed in between or it's a static string which is only valid within a function. Just create a diff of your current code and send it to the list or me or some paste bin or whatever.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi again, ok, just for fun, here's a patch to a basic functional version...(and the modified files in case patch is not working acording to plans...) it's tiny modifications to src/highlighting.c and src/highlighting.h :D
once the patch applied you should be able to add to styling sections of filetypes.whatever a font name, and a font size... in that fashion: a_style=fg_color;bg_color;bold?;italic?;fontname;font_size
I've attached a filetype example to see how to use... if you leave it the way it is...then you just get the usual highlighting...
I've only tested it with Python and C....
as mentionned earlier, if you change the default font during a session, it will break the custom styling for the duration of the session.... i'll work on that...
later on I'll provide extra options to change margin sizes, markers and such....
let me know if it works
cheers, jimmy
2009/5/8 Jimmy Paillet jimmy.paillet@gmail.com
nevermind...just used a strcpy...went just fine... i'll probably make decent advances now... cheers j
2009/5/8 Jimmy Paillet jimmy.paillet@gmail.com
Hi,
I think i can express it clearly now.... this my GeanyLexerStyle:
typedef struct GeanyLexerStyle { gint foreground; /**< Foreground text colour, in @c 0xBBGGRR format. */ gint background; /**< Background text colour, in @c 0xBBGGRR format. */ gboolean bold; /**< Bold. */ gboolean italic; /**< Italic. */ gchar* font_perso; /** A font name*/ gint font_size; } GeanyLexerStyle;
in get_keyfile_style, this struct is filled (as least for c)... thanks to a gchar** list... pointing to the [styling] sections of filetypes.foo
of course at the end of this function, list is free'd....so my pointer font_perso points to crap outside the func...hence my pb... :D when I comment out the free statement, thinhs behave logically...
what do you reckon? free the list variable later on?
jimmy
2009/5/8 Enrico Tröger enrico.troeger@uvena.de
On Fri, 8 May 2009 18:26:15 +0200, Jimmy wrote:
functions...i'm facing pointer pbs, basically...my font name does not propagate properly through functions...
If you need help for a specific problem, just ask.
ok...it's probably silly, as i'm not an experienced C programmer...and didn't spend a lot of time on it... but as I told you, I expanded the GeanyLexerStyle structure....
in get_keyfile_style and get_key_file_hex my adds to the filetypes.foo are properly read... and when i print out my new element of the struct it's either null or the fontname I've just entered in the file....
but when i try to access my new entry in a another function (such as set_sci_style), it has been obviously been written over by something
Hard to say without any code but it sounds like the char* pointer is either freed in between or it's a static string which is only valid within a function. Just create a diff of your current code and send it to the list or me or some paste bin or whatever.
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Fri, 8 May 2009 20:59:15 +0200, Jimmy wrote:
Hey,
ok, just for fun, here's a patch to a basic functional version...(and the modified files in case patch is not working acording to plans...) it's tiny modifications to src/highlighting.c and src/highlighting.h :D
A few notes: - Don't use strcpy() with fixed sized strings like gchar custom_font[20] this can easily lead to memory corruptions and so crashes. It's easier and safer (while being a little less performant) to use dynamically allocated strings on the heap, e.g. with g_strdup(), so gchar custom_font[20]; strcpy(style->custom_font, list[4]); gets gchar *custom_font; custom_font = g_strdup(list[4]); And don't forget to g_free() these strings afterwards in highlighting_free_styles().
- if (condition) code(); looks nicer than if (condition) code(); but this is just cosmetic.
- I think we should add the "!" to request Pango fonts in the code, I don't think users want to use GDK fonts and mixing both is probably not possible at all and even if, it's not desirable. Furthermore, having the "!" in the filetype definition files seems error-prone because it can be easily forgotten. This is why I suggest to specify only fontnames in the filetype definition files and add the "!" directly when reading the names in get_keyfile_int().
- strlen(style_ptr->custom_font) > 0 can be easier written as NZV(style_ptr->custom_font) which is a little more performant and easier to read (the NZV() macro is defined in src/utils.h).
Regards, Enrico
hi,
2009/5/9 Enrico Tröger enrico.troeger@uvena.de
On Fri, 8 May 2009 20:59:15 +0200, Jimmy wrote:
Hey,
ok, just for fun, here's a patch to a basic functional version...(and the modified files in case patch is not working acording to plans...) it's tiny modifications to src/highlighting.c and src/highlighting.h :D
A few notes:
- Don't use strcpy() with fixed sized strings like gchar custom_font[20]
this can easily lead to memory corruptions and so crashes. It's easier and safer (while being a little less performant) to use dynamically allocated strings on the heap, e.g. with g_strdup(), so gchar custom_font[20]; strcpy(style->custom_font, list[4]); gets gchar *custom_font; custom_font = g_strdup(list[4]); And don't forget to g_free() these strings afterwards in highlighting_free_styles().
yep i knew it was dodgy...ok i'll modify my stuff to get along these lines thanks
- if (condition) code();
looks nicer than if (condition) code(); but this is just cosmetic.
ok
- I think we should add the "!" to request Pango fonts in the code,
I don't think users want to use GDK fonts and mixing both is probably not possible at all and even if, it's not desirable. Furthermore, having the "!" in the filetype definition files seems error-prone because it can be easily forgotten. This is why I suggest to specify only fontnames in the filetype definition files and add the "!" directly when reading the names in get_keyfile_int().
ok...I was just using the scintilla model here... forgetting the ! does not lead to an error, it just don't anti-alias your font... I'm not sure who, but someone might still want to have this control...
- strlen(style_ptr->custom_font) > 0
can be easier written as NZV(style_ptr->custom_font) which is a little more performant and easier to read (the NZV() macro is defined in src/utils.h).
I didn't come across this yet...it's useful thanks
jimmy
Regards, Enrico
-- Get my GPG key from http://www.uvena.de/pub.asc
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On Sat, 9 May 2009 11:46:11 +0200, Jimmy wrote:
- I think we should add the "!" to request Pango fonts in the code,
I don't think users want to use GDK fonts and mixing both is probably not possible at all and even if, it's not desirable. Furthermore, having the "!" in the filetype definition files seems error-prone because it can be easily forgotten. This is why I suggest to specify only fontnames in the filetype definition files and add the "!" directly when reading the names in get_keyfile_int().
ok...I was just using the scintilla model here... forgetting the ! does not lead to an error, it just don't anti-alias your font...
Not an error but most likely not what the user wants.
I'm not sure who, but someone might still want to have this control...
Unlikely. So far we also don't allow to use GDK fonts and enforce Pango fonts. I don't see a reason why someone would like to use GDK fonts, especially because of the notes in the Scintilla docs.
Regards, Enrico