At the moment the message window is set to resize when the height of the
main window changes. This is a bit annoying when the message window size
is set to fit all the tabs exactly and when shrinking the window, the
tabs don't fit the shrinked message window.
Set the flag not to resize the notebook_info notebook (similar thing is
already done with the sidebar in the horizontal direction so no change
needed there).
Works fine also when the message window is set to be on the right side.
In principle, any scrolled window should have GTK_SHADOW_IN so the scrollbars
are not above the surface and there is a frame around the scrolled area.
The only exception are the elements of the main window where adding
GTK_SHADOW_IN causes there are too many shadows (or lines in 2D themes)
around the windows and the result isn't nice. So use GTK_SHADOW_NONE
for all main editor scrolled windows. (One additional exception is the
Help->Credits page which is gray and the extra frame doesn't look good.)
Replace frame around VTE with GtkViewport to avoid the extra line around.
Raise the second editor from the splitwindow plugin so it's at the same
level as the main editor.
The "rules hint" property is used to tell the theme for which TreeView
even/odd rows should have a different color. This is typically used for
long rows or rows which need to be visually separated for some reason.
Currently the Documents sidebar view uses it which doesn't make much
sense because the row is short and neither of the other tabs in the sidebar
use it.
Also don't default to CR if OS is neither Windows nor Unix (including OS X).
There's no other GTK backend right now so it doesn't matter much but
still if something else appears, it will most probably not have CR line
endings.
3.8.5 is supposed to fix the unstable file output, hopefully making
further edits generate small diffs, not rearranging the whole file for
no good reason.
Note that this commit may introduce UI problems if the output actually
isn't equivalent, the diff making it nearly impossible to review
manually. Keep an eye open for such problems.
Make all encoding combo box display a list with encodings grouped by
categories into sub-menus, making it easier to find the appropriate
encoding than in a big single-level list.
This is what was used in the Open dialog, but not in the Preferences
dialog or the Find in Files dialog. This also makes the encoding
combo boxes behave more like the encoding menus.
Modification of the string "Use Windows File Open/Save dialogs" to
"Use Windows native dialogs".
Signed-off-by: bestel <steven.valsesia@gmail.com>
Signed-off-by: Colomban Wendling <ban@herbesfolles.org>
Although GtkIconFactory implements GtkBuildable properly and works just
fine, Glade can't handle it and keeps removing it upon save. So, drop
the automatic setup to a manual one so the UI description is editable
with Glade again, and which also has the small advantage of not
repeating the stock ID strings.
In the file properties dialog there are a few label for which the
default value is never visible to the user, and then don't need to be
translated. These strings are only useful to recognize and select the
label in e.g. Glade UI.
Rationale:
----------
* Existing View menu already contained Editor-related options
like "Change Font" and Zoom controls, so it makes sense to
group all of the View-related items together.
* Anecdotally, some users have been unable to easily discover
the Color Schemes changer dialog because it was nested under
a submenu.
* Distinction between "Editor" (Scintilla) and "Editor" (All
of Geany) is likely non-obvious to most users, especially
new users exploring the menus.
* There's not very many items to cause scrolling on low-res
monitors, and the View menu still has less items than the
Document menu.
If we provide an AccelGroup when creating a menu item using a sock ID,
it installs the GTK default accelerator, accelerator we can't remove
since we don't know about it. So, don't give an AccelGroup so GTK
don't install it's own accelerator.
This fix also required to properly update the accelerator on some item
we used to ignore since the update didn't work anyway (since the GTK
accelerator was displayed instead).
Note that this doesn't fix the fact the editor popup menu accelerators
are never updated after startup so they don't get updated before
restart after changing a keybinding in the preferences. This is a
separate (and less problematic) issue due to a simple lack of update.
Closes#1912683 and #3599251.
Although using menu items for these is not very practical, it helps
discoverability, and they're more useful and intuitive than 'Transpose
Current Line'.
This copies the current document text and properties into a new
document, similar to the old Save As 'Open file in a new tab'
option, but easier to understand and decoupled from saving.
One notable difference is that the new document does not copy the
filename - the old behaviour was confusing and error-prone for the
user (e.g. editing two documents with the same filename).
With newer GTK+ releases, leaving this field blank causes the "Recent
Files" "feature" to be used rather the the expected current working
directory. No replacement text added to explain the new behaviour since
it would be incorrect with older GTK+ versions, would likely be incorrect
on Windows with native dialogs and it will possibly be reverted in GTK+
in the future.
Recenerate HTML manual, including previous changes from other commits.
Now there is a dialog instead of a menu for selecting the color
schemes, the item under View->Editor can be created with Glade like the
rest of the menu.
