For example `10.5`. Some other editors accept that value.
Thanks :-)
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/703
PR in #407
--- Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/703#issuecomment-159305478
_In Addition:_ Somehow the size doesn't match with any other editors somehow, in example Deja Vu Sans Mono 14 in Geany is much bigger in the appearance and size than that of Pluma and Visual Studio Code for Linux (VSCode). I think that's the reason why somehow a float value for font size is needed for compensating. Also, Not only the sizes doesn't match, but also the spacing between the lines are very tight, which could be eye straining for some people
_Thought/Suggestion:_ This is probably due the editor is based on Scintilla, which has a different engine working beneath, I think. Can this be tuned to match "normal" size? And is it possible to add something to control the line height too? This is a editable option in VSCode by the way.
_Tuning:_ The same look for VSCode can be achieved by setting the font size to 11, but still, the font looks more bold, especially the numbering, which, depending on the color theme, can be somehow eye straining (in my humble opinion). In this Image you can see the tight line height more clearly, which is also due to the slightly bolder font, maybe?
Of course, this font is just one of many available other fonts, but I think the core problem of mismatch font size and line height still remain for them too.
I don't have Pluma or VScode, but on my system GTK2 Geany and GTK3 Geany and Xed (the simple editor provided by the distro, which is GTK3 based) all are exactly the same size on the same standard (not hidpi) monitor all with a deja-vu mono font at the same point size. In other words Geany has the same size as other GTK renderers here. Not sure why Pluma (a GTK2 program) would be different unless it manipulates the chosen font size in some way.
I can believe that the VScode renderings will look different because, being web technology based, its not going to be using the GTK renderers. It also may do anti-aliasing differently which can make it look "bolder". Rendering a font is surprisingly not an exact science IIUC.
As is pointed out above there is a PR #407 to add fractional sizes, but it requires the maintainer to approve that the changes they requested have been done, and for it to be tested. You could test it if you can to help it along.
Also, Not only the sizes doesn't match, but also the spacing between the lines are very tight, which could be eye straining for some people
Line spacing is set by colour schemes in their `line_height` setting with the default value being in `filetypes.common` if the scheme is silent, which you can edit by `Menu->Tools->Configuration Files->filetypes.common`
Oh, my bad, of course, it is the custom DPI I set to 120. Okay, the sizes are indeed the same then. Strange though that Pluma still has a DPI independent font size, even though it is GTK. But Geany follows the DPI change made, in my case, by xfce4 config.
But still, the boldness of the numbering bothers me nonetheless. And wouldn't it be better to control the line spacing in the options globally rather than in the individual schemes? I don't really want to tinker around in a scheme file if possible, but I can take this as a workaround.
Strange though that Pluma still has a DPI independent font size, even though it is GTK.
IIUC Pluma is a fork of an old version of GTK2 gedit, maybe before DPI handling was added and anyway GTK2 isn't known for good DPI handling (especially hidpi).
The need for line spacing tends to be font related (for example on my system dejavu is more cramped than hack at the same size) so it would make sense to be a preference rather than a theme setting since themes do not set fonts. I guess people tend to set and leave the line spacing which is why nobody has submitted a PR to move it to the GUI.
The margin line numbers styling is also part of the colourscheme, and in this case thats a good place for it as it allows the scheme to make it match the rest of the editor. As best I can tell, numbers in the margin look the same as numbers in the editor.
So Geany is currently GTK3, right? I am honestly asking, because I'm not sure if the Debian version 1.31 is compiled with GTK2 or GTK3.
The line spacing is fortunately a preference of "filetypes.common", independent of any theme schemings.
Maybe all the "lost or hidden" configurations should be added as default into this file with short descriptions, so you don't really need to add this as a GUI configuration.
Even better, **all** settings of Geany, hidden or not, shall be represented in such an editable file without any GUI, or if needed, something like the "about:config" of Firefox. I'm fully aware that this won't be liked by everyone, but I raise my voice to show that at least someone would like this and that this procedure can save trouble or time, as anyone can add new features or configurations without adding this to the GUI and the features won't be forgotten after adding them to the code. If not, then well, "what a bummer..".
After searching for config flags, I am quite amazed and shocked, how much more possible configurations Geany offers by this filetypes.common, which is not found in the GUI settings..
At last, it is indeed the same font it seems, hmm cannot complain on that one..
So Geany is currently GTK3, right? I am honestly asking, because I'm not sure if the Debian version 1.31 is compiled with GTK2 or GTK3, least of all how it looks like in other distributions.
You can find out in `Help->Debug Messages` it should say which GTK+ on the second line. Geany uses GTK+ 2 by default, but distros/users are free to configure it with `--enable-gtk3`. They both work OK, just the GTK+ 3 build gives all the ridiculous tablet-UI dialogs that plague GTK+ 3.
Even better, all settings of Geany, hidden or not, shall be represented in such an editable file without any GUI, or if needed, something like the "about:config" of Firefox.
That was the purpose of the `Preferences->Various` tab, though I think it may still be missing some preferences.
At last, it is indeed the same font it seems, hmm cannot complain on that one..
I've noticed on many occasions where Scintilla renders differently than native GTK+. The easiest way to see it is to use the `View->Change Font` dialog and compare what's in Scintilla (after pressing the `Apply` button) and what's in the little preview inside the font dialog.
They both work OK, just the GTK+ 3 build gives all the ridiculous tablet-UI dialogs that plague GTK+ 3.
Most dialogs can be configured as crippled or useful, but you need to use a sensible desktop focussed distro like Mint that sets the dialogs settings as close to the old ones as it can [end free plug].
That was the purpose of the Preferences->Various tab, though I think it may still be missing some preferences.
Though it was intended to take prefs out of the user prefs file, not filetypes files and themes, but line spacing does seem to not belong in those. PRs are welcome.
I've noticed on many occasions where Scintilla renders differently than native GTK+.
Well, both use Pango, but maybe Scintilla sets some options different to GTK, and as I said above AA and also how fonts provide hinting and how it is used. And of course fonts that are not properly monospaced are known to throw things off. Certainly my normal font `Hack` and `Deja-vu`, that I checked above, both look identical (on GTK3 and standard dpi screen, your GTK2 on hidpi may differ).
@Johndeep all Geany settings __are__ represented in editable text files. All settings are stored in [Gkeyfiles](https://developer.gnome.org/glib/2.52/glib-Key-value-file-parser.html#glib-K...) which are just like the olde fashioned `.ini` files.
The user prefs, project files, colour schemes and filetype files (including `filetypes.common`) are this format. The only trap is that Geany does not reload them if you edit them while its open, and user and open projects get overwritten on close.
@elextr I already notice the similarity of those configure files, but thanks for pointing it out anyway.
Still, or rather since they are all the same type, if all these settings were sorted and optimized into just two or three settings files (one for single value settings and one for long string values like "last 10 files" in example), which may be represented as a simple flexible categorized list with string and value in Geany, it would be optimal.
To have an actual example (sorry if it is VSCode again), https://code.visualstudio.com/docs/getstarted/settings or like Openbox, http://openbox.org/wiki/Help:Configuration, but without XML, only Gkeyfiles style and maybe prettier (colors, comments and highlighting).
I want to try it out, but since I'm regularly working with Geany, I wonder how I could modify, compile and run it in parallel besides the Debian repos version, any tips? Besides, how do you guys handle the GUI part of Geany? It seems they are coded directly and without any visible aid like Anjuta or the like.
I wonder how I could modify, compile and run it in parallel besides the Debian repos version, any tips?
Clone the source from Git and run `autogen.sh --prefix=$HOME/wherever/you/like`, then `make install`, then run it like `$HOME/wherever/you/like/bin/geany`.
Besides, how do you guys handle the GUI part of Geany? It seems they are coded directly and without any visible aid like Anjuta or the like.
It's a mix. Most of the GUI is done using [Glade](https://github.com/geany/geany/blob/1.31.0/data/geany.glade), but there is also some (too much) which is just hard-coded.
Still, or rather since they are all the same type, if all these settings were sorted and optimized into just two or three settings files (one for single value settings and one for long string values like "last 10 files" in example), which may be represented as a simple flexible categorized list with string and value in Geany, it would be optimal.
If you are suggesting a large reorganisation of the config files you will need a pretty good use-case, I doubt just editability will get it accepted. You also need to consider:
Combining all the filetype files would be difficult since Gkeyfiles have only limited nesting and its already used up in the existing files.
There have been a number of attempts to separate settings and session info (which are currently combined in user `geany.conf` and project files) but there has been no satisfactory resolution of that problem.
Before you propose anything look long and hard at the various options and the use-cases they support (like -c I note below).
Probably best to discuss it before you do a lot of work on it.
I want to try it out, but since I'm regularly working with Geany, I wonder how I could modify, compile and run it in parallel besides the Debian repos version, any tips?
Read the HACKING file. Then read it again.
Configuring with `--prefix` and running with `-c` will get you an isolated Geany in its own directory tree, make a directory and untar geany into it making lets say `/some/where/geany` then cd there and
``` ./configure --prefix=/some/where; make install; cd ../bin; ./geany -c ../config ```
gives you a completely isolated Geany that does not touch the system installed version, and the -c means it doesn't touch your user config either.
Besides, how do you guys handle the GUI part of Geany? It seems they are coded directly and without any visible aid like Anjuta or the like.
Look at the source before asking questions like this, but the answer is mixed, some fixed parts are made with Glade, some variable parts are coded and some fixed parts are coded because that was how they were originally done and nobody has seen a need to switch them to Glade (if its not broken ...).
I'm sorry, I was searching everywhere on the web about "howto dev Geany", but I didn't noticed it is described in the HACKING file.
But indeed, I admit, a revamping of the settings is like going into a lion cave, I don't know how huge this task will be **and** more importantly, will it be accepted at all? So I'm sorry for suggesting this list settings style before trying it out and rather focus at this topic again.
Since the PR for fractional fonts size is still open for two years now, it seems there are.. problems?
Closed #703 via 46d5e7542b8396ed593f2e319f71d153a67684dc.
github-comments@lists.geany.org