At the moment Scintilla V5 is still regarded as unstable, IIUC it will be V5.1 thats stable "soon".
This issue is to discuss how we should approach the Scintilla V5 changes, the API changes, the Lexilla/Scintilla split, how to make the process scalable, massive single commits are simply not viable.
Then there needs to be a discussion about importing Scintilla/Lexilla it will be done in Geany after the changes to separate Scintilla and Lexilla.
To be blunt, the mechanics of getting the parts Geany uses from the Scintilla repos is the least of a Scintilla upgrade, be it git subprojects or a bash/Python script doesn't matter, its a minor part of the work needed for the upgrade, even now Scintilla and Lexilla are separate. So the simplest for everyone to understand is the best.
The main part of a Scintilla upgrade is the manual work for each lexer:
1. checking if any of the syntactic elements from the lexers have changed,
2. changing the mapping of those to Geany entities in `highlightingmappings.h`
3. adding them to `filetypes.xxx`,
4. checking for any lexer properties that need to be added or removed.
These are manual actions at the moment and make up most of the work creating and reviewing a Scintilla upgrade and are why the upgrades take so long.
IIUC there are some additional scripts or similar that come with Scintilla/Lexilla 5 that may make at least part of that work automatic, identifying changes at least. That needs to be explored to allow supporting the current number of languages to remain viable.
ATM its just too much work and nobody has the time.
Also potentially making Lexilla changes separate from Scintilla would help, IIUC Neil will be issuing them as separate releases in the future, and even better if each filetype could be done by itself. Then whoever is interested in a language can submit a smallish PR that would be easy to review and commit.
Huge commit bombs are simply not viable into the future, thoughts anyone?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2824
These changes allow us to create future release builds for Windows for the x86_64 platform and finally use GTK3.
Also since the GTK bundle creation and the NSIS installer scripts get more flexible, this helps to create fullly automated cross-compiled builds.
Changes in the bundle creation script:
- the GTK (and other dependencies) bundle is now created for the x86_64 platform
- the new parameter "-x" allows to run script on a Linux system using Wine, therefore it is necessary to run the post-install scripts after all packages have been extracted.
- use "-Sdd" for Pacman to ignore dependencies as we resolve them manually
- do not use "tar -x --xz" as Pacman nowadays also downloads .zst packages, instead just download the file and let tar choose the format automatically based on the filename
- install grep with Pacman as the build and target platform are now identical
- update GTK dependencies to match current packages
Changes in the NSIS installer script:
- remove hard-coded paths and installer name from NSIS installer script - This makes the paths for external resources configurable using command line flags (e.g. /DGEANY_THEMES_DIR=/something/geany-themes) and also the resulting installer filename can be set via command line flags
- the "INCLUDE_GTK" command line is removed as we always include the GTK bundle
- the GTK version detection was removed and now we always bundle the GTK3 specific CSS files.
Do NOT merge before 1.37 is released as we should make first a final GTK2/i686 release before switching.
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2590
-- Commit Summary --
* Windows: Create GTK bundle for x86_64 and suppt non-native execution
* Remove hard-coded paths and installer name from NSIS installer script
-- File Changes --
M geany.nsi.in (96)
M scripts/gtk-bundle-from-msys2.sh (106)
-- Patch Links --
https://github.com/geany/geany/pull/2590.patchhttps://github.com/geany/geany/pull/2590.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/2590
This issue is to make our Windows builds (nightly, CI and release builds) easier and better.
And also to satisfy @elextr 's long-time wish to have GTK3 Windows builds :).
My goal is to create Windows builds:
- with GTK3 only
- for x86_64 (aka amd64 aka 64bit) only
- fully automated on a Linux box
I've written a Dockerfile which sets up a cross-compilation environment with mingw64-gcc, wine and a couple other necessary tools. It also bootstraps a minimal MSYS2 environment so packages can be installed with `pacman`.
In the resulting build environment we start a script which does:
- clone Geany repository if necessary (i.e. if it is not bind-mounted into the container)
- cross-compile Geany for Windows 64bit and GTK3
- sign all binaries and installer (if /certificates exist and contains cert.pem and key.pem)
- download Geany-Themes for bundling
- create GTK3 bundle with all dependencies (including grep and sort)
- create the NSIS installer in ${OUTPUT_DIRECTORY}
- test the created NSIS installer and compiled Geany
- test uninstaller and check there is nothing left after uninstalling
This is already working pretty nicely (even digitally signing the binaries!!).
I guess I'll put the Dockerfile and the build script into a new repository.
However there are some tasks left for discussion and to do:
- do you think it is safe to switch to x86_64 builds only? I guess since Windows 7 almost everybody should have a x86_64 installation by default it she didn't anything against it on purpose. But I'm not sure enough and I didn't find proper resources on the net.
- there is a bug on Windows with GTK3 causing the message window to constantly loose some height between starts of Geany (#2591)
- we need to decide which GTK3 theme we use by default:
- the default theme (I think it's Adwaita) looks a bit alien on Windows, see screenshots below
- there is a "win32" theme natively in GTK3 which can be enabled in GTK3's `settings.ini`, it doesn't look quite right either :(.
I would say let's try with the default theme even GUI elements feel a bit huge.
Or we find another good looking theme or someone hacks something. I definitely won't work on this.
Dependant issues and PRs:
- [ ] #2591
- [ ] #2590
- [ ] #2572
Geany GTK3 Default Theme:
 to the person that can get support for the below listed debuggers added to the "debugger" plugin (or create a new plugin), working, and be as well integrated and have the features (where applicable) as the "debugger" plugin.
This bounty expires August 31st, 2021.
- **PDB** (https://docs.python.org/3/library/pdb.html): $250 USD
- **XDebug** (http://xdebug.org/): $250 USD
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1088
Version: GIT 55e0998c
OS: Windows 7
GTK version: 3
After each start of Geany, the message window height is reduced so that it is completely hidden (aka height=0) after three or four starts.
I have no idea yet why this happens but we need to look into this and fix it before releasing Geany with GTK3 on Windows. It does *not* happen with GTK2 builds.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/issues/2591
There is no feedback about a failed GIT commit at all.
No status bar message, no status window message, no message in Help->Debug Messages and no error dialog.
At least one the above should happen to tell the user that the commit did not happen.
IMO there should be a message in Help->Debug Messages at the very least but also some more visible feedback to the user like an error dialog or at least a status bar message.
The only trace you get is the GIT error output on stderr but I guess most people won't want Geany's stderr regularly :).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/837
Using Geanyctags 1.38 on Ubuntu 20.04.
On first use the 'Project > Generate tags' menu command completes correctly and generates a new .tags file for the project. After that, trying to re-generate the tags (repeat 'Generate tags') fails with the following error in the Messages pane:
```
find -L . -not -path '*/\.*' | ctags --totals --fields=fKsSt --extra=-fq --c-kinds=+p --sort=foldcase --excmd=number -L - -f '/home/user/work/test-project.tags'
ctags: "/home/developer/work/geany-plugins-develop.tags" doesn't look like a tag file; I refuse to overwrite it.
```
Looking inside the .tags file, reveals that the first line of it is blank. Removing the blank line allows the regeneration as expected.
Geany info:
```
geany -V
geany 1.36 (git >= 825acb21) (built on 2020-04-28 with GTK 3.22.30, GLib 2.56.4)
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany-plugins/issues/1042
){kind=link}
){kind=link}