Hi all,
I just made a test build of Geany Plugins 1.22 for Windows.
A little surprisingly for me, it all worked fine on the first attempt :).
I only had problems loading the Geany-Lua plugin with some strange error
message which I didn't investigate yet:
http://pastebin.geany.org/EUmwJ/
The error message occurs on plugin loading. I'm not sure whether it is
caused by my system or something else.
If anyone wants to test it, any feedback is appreciated.
The installer...
http://www.uvena.de/tmp/geany-plugins-1.22_setup_testbuild.exe
... requires an existing Geany 1.22 installation.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hi All,
Its about that time of year when we have our annual discussion on
separating session data from config/project data :)
By session data I mean the list of currently open files and MRU list.
The advantages (that I can see):
1. Save config/project as its changed and not rushed at quit time (and
the quit save doesn't happen in the absence of a working, portable,
session management capability)
2. Save session data periodically, or as it changes, or whenever,
without touching the config/project files. So the config isn't at
risk if the session save goes wrong.
The only disadvantage for user config (that I can see) is that it adds
one file, say geany.session.conf alongside geany.conf
For project sessions just using another file in the same place as the
project file is more of a problem since project files can be in the
project tree and some people like to save them in VCS. So users would
have to make sure that their git.ignore (or whatever the other VCSes
use) is edited each time so that the session file isn't saved in the
VCS.
A better option, especially since sessions are inherently user
related, is to store them in the user config location (or subdirectory
thereof). But how to link these files to the project files?
The proposal is that each project gets a UUID generated when it is
created (or when its opened without one) which is saved in the project
file. This uuid is the name of the session file in the
${GEANY_CONFIG}/sessions directory. That way, when a project is
opened, it is easy to uniquely find the session file if it exists.
Using things like filenames, project names etc will always have
clashes. Libuuid is used by GTK so it will always be available on all
platforms we use and so making the UUID is one call. (Pity GTK doesn't
expose it though)
The number of session files can be left to grow like weeds, or can be
trimmed to a (configurable) maximum number deleting the oldest when
needed.
This proposal isn't about a proper session management capability,
there isn't one that works on enough platforms to be worth including.
Any thoughts welcome.
Cheers
Lex
Hi!
I saw this code in src/symbols.c at line 1917:
while (sci_get_style_at(sci, start) != fn_style
&& start < max_pos) start++;
If start >= max_pos then sci_get_style_at will be called (with out of
bounds value?) and then the loop will bail out.
I suggest that the condition is reordered as:
while (start < max_pos
&& sci_get_style_at(sci, start) != fn_style)
start++;
Then sci_get_style_at will only be called if start is less than max_pos.
It is just my humble suggestion.
Best regards,
Daniel
Hey all,
this topic has been brought up already a couple of times, for example on
[1].
What do you think about dropping Waf support in Geany and in the
Geany-Plugins project?
While I was defending Waf in Geany, I somewhat changed my mind. Not
because I don't like it anymore, but I increasingly see the efforts in
maintaining two (to be exactly three for Geany) build systems is too
much. Since the make/MSYS build system support seems to get better and
better due to Nick's and Dimitar's work on it, I thought about dropping
the Waf support. It seems nobody knows it well enough and probably
except for a few users nobody is using it.
(And obviously I don't do so much anymore and also lost a bit interest
in maintaining forever.)
The other thing is that Waf causes often problems for distro packages,
especially for the Debian folks [2].
So, I'd go the easy way in this case and just remove Waf. Then we only
need to maintain the autotools based build system for non-Windows
systems and the make based for Windows.
For Geany-Plugins, we would need to get something working on Windows but
maybe we could re-use Geany's make based system for Windows here.
What do you guys think?
[1]
http://sourceforge.net/tracker/index.php?func=detail&aid=3460449&group_id=1…
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=645190
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hi,
Now that 1.22 is out, how about removing the MSYS build dependency
under Win~1? I tried to compile Geany with the default MinGW make,
without any MSYS, and there were some easily fixable problems:
cd foo && $(MAKE) -f makefile.win32 && cd ..\..
does not work, probably requires some sh. But if we depend on GNU make
(which seems to be the case, since we're using ifdef/else/endif), it's
easier and shorter to:
$(MAKE) -C foo -f makefile.win32
Linking does not work, because the stock make supports \ only for
variables, not commands. But that's even easier to fix:
STLIBS
= ../scintilla/scintilla.a ../tagmanager/tagmanager.a ../tagmanager/mio/mio.a
$(TARGET): $(OBJS) $(RES) $(STLIBS)
$(CXX) $(OBJS) $(RES) -o $(TARGET) $(STLIBS) $(ALL_GTK_LIBS)
$(WIN_LIBS)
with the added benefit that static library names are not repeated
literally.
There is also some inconsistency: CP = copy, but "cp -r" and "cp" at
the end of makefile. The install target can be rewritten as several
-$(MD) and non-recursive $(CP) commands, and no MSYS will be required.
RFC. If we consider this worthy, I can make the required changes.
--
E-gards: Jimmy
Hi All,
Along with the previous response on the icon, the following was proposal
was also received from Clement of the Mint distro:
"Another thing I wanted to ask you about, and I'm glad you contacted us, is
about the configuration of Geany as a text editor for users (as opposed to
developers). Geany is brilliant and I personally use it as a developer to
do most of my work in Python, C, PHP and other languages. But it could also
be a great contender for a default text editor in Linux Mint in replacement
of gedit. We're not happy at all with gedit 3, in particular when it comes
to searching and replacing occurrences in a text file. We considered
replacing it with Geany, with an older GTK2 version of gedit or even
forking it to provide a new tool dedicated to text editing.
What is your opinion on this? If we used Geany for this, we would hide all
developer features (symbols, buttons, statusbars..etc) from it. Would you
rather like us shipping a version of geany which by default looks like a
simple text editor (and so devs would have to go in the preferences and
re-enable all the normal features) or fork geany into a new project
dedicated to text editing (i.e. basically a dumbed down version of geany
with features removed). With a fork of course we'd give credit to geany in
our communication and within the tool itself, we'd work with you on making
sure you're happy with the end-result and the editor would have a distinct
generic name ("text editor" for instance) so it would be possible for users
to have both this editor and geany installed side-by-side and to open
documents with either of them. Let me know your thoughts on this. We're not
sure what the best approach is, but whether it happens now or later, we're
pretty sure gedit 3 isn't what we want to use going forward."
To kick the ball off, here is my thoughts on the topic.
First thought is that there is plenty of upside to such cooperation in
terms of attracting more contributors to the developer version of Geany.
The flip side of that is of course that more bugs would be reported and
expected to be fixed. (Bug reports are good, its the *expectation* that
they will be quickly fixed that is the problem.) I would hope that Mint
would be able to contribute to that effort.
I am not sure how much effort it would take to make the Geany UI able to
hide the "developer" features, it will be some complication for sure, but
probably not a big one.
If Mint use a "friendly fork" approach it does reduce the impact this has
on the Geany project, but it will also reduce the possible bugfixes that
come back to Geany (since the fork is different patches may not apply).
If we provide the "plain editor" version as an option on Geany it adds to
the workload, though I would hope that Mint would contribute to that extra
effort.
I am personally undecided at the moment, noting that Mint will do what is
appropriate for their distro, and it is up to us to try to engage with them
ina way that provides the maximum benefit for both groups.
Cheers
Lex
Hey Nick (or anyone else),
What was the exact issue with Async spawning on Windows? I know it's not
working but maybe we/I can come up with a work-around and/or help fix it
upstream. IIRC last time I tried to enable the #ifdef'd out async code
for Windows, there was some glib-async-helper.exe or something like this
and when I ran it it crashed everytime, but this was with a quite recent
Geany and GLIB and maybe I was mixing Geany bundled GTK+ with my own
newer bundle in PATH. Maybe we just need to bundle this utility or
something?
If anyone can give a little info on what the problem is and what was
tried to fix it, I can probably spend some time this weekend to have
(another) shot at fixing it.
P.S. This email has absolutely nothing to do with the commit its
replying to except for being related to process spawning on Windows and
the Geany Win32 expert might read it :)
Cheers,
Matthew Brush
On 12-10-24 09:35 AM, Nick Treleaven wrote:
> [...]
Hello,
Attached a little patch concerning the file saving dialog.
I may have missed some use cases, but it works on all cases mentioned in
the commit message.
The main point is about the âRenameâ, the unsaved file one (last commit
message line) is a bonus.
Cheers,
--
Quentin "Sardem FF7" Glidic
I have been investigating Geany's problems with printing.
I looked at
* Geany 1.22
* Geany - the current git (as of a few days ago when I started this)
* Geany 1.23 (git >= 8855c14), en_US.UTF-8
* SciTE 3.1.0
Geany 1.22 - problems
* When counting pages, tabs are not expanded, giving inaccurate
results - #3475444
* Printing code mishandles non-monospaced fonts - #2804000
* When printing, tabs are expanded to fixed width, not to the next tab
stop - #2629121.
* When user requests to print a specified page, page 1 is printed and
labeled the requested page.
For example, if the user selects to print page 7 only, Geany will print
page 1, but in the heading, the text will read "Page 7 of xx". I didn't
submit this as a developer bug, since it is fixed in the current version.
Geany -- the current git - problems
* Print Preview displays a different number of lines than hard-copy -
#3580269.
* The line separating line numbers from text when printing is
positioned incorrectly - #3580268.
* Printed lines are right-shifted compared to previous Geany versions,
causing wrapping which did not occur in previous Geany versions.
SciTE problems
* Print Preview displays a different number of lines than hard-copy.
The git version of Geany contains a new version of the printing code.
This new version uses the printing code contained within Scintilla.
The Scintilla printing code does not draw a vertical line between the
line number and the text. So the git version of Geany attempts to draw
that line. However, Scintilla provides no method of determining the
width of the line number column (SSM(SCI_GETMARGINWIDTHN) returns the
display margin width, not the printer margin width). So the Geany code
attempts to mimic the calculations Scintilla performs to come up with
the column width. The attempt fails, thus bug #3580268.
The Scintilla printing code adds three spaces between line number and
text. This shifts the text right, and lines which were nearly page width
when printed using the previous versions of Geany now wrap.
As a quick check whether the lines per page mismatch between Print
Preview and hard copy is in Geany's code or Scintilla's, I tested SciTE.
SciTE has the same problem.
Using the git version of Geany, I printed page 1 of a particular test
document, Print Preview listed the document as 18 pages long with 51
lines on the first page (4 lines wrapped) and the hardcopy listed it as
19 pages long with 45 lines on the first page (8 lines wrapped).
Printing the same test with SciTE, Print Preview listed 55 lines on page
1 with 3 lines wrapped, and hardcopy listed 44 lines with 7 lines
wrapped. (SciTE's output does not show the number of pages in the document).
I have investigated the problems with the old (1.22 and before) printer
code, and I believe all can be addressed by modifying the original code,
with the exception of
Printing code mishandles non-monospaced fonts - #2804000
I fixed the bug "When printing, tabs are expanded to fixed width, not to
the next tab stop - #2629121" locally a few weeks ago. That was why I
joined the developers group. I wanted to submit that patch.
I have not noticed any discrepancy between Print Preview and hardcopy
with the (tab expansion patched) old code. And the old code naturally
knows the correct location for the vertical line.
When determining the number of pages in the code, the old code currently
determines the length of each line by multiplying the width of one
character by the number of characters in the line. That is correct as
far as UTF8 is concerned -- it uses a UTF-aware function to determine
number of characters. But it fails to take into consideration the
expansion of tabs.
To fix this problem in the old code, one could replace the page counting
code. Take the lines of code that actually do the printing, put those
lines into a separate function, and call that function twice. First
time, the function would calculate the layout (and thus the number of
pages) but not actually print. Second time, it prints. If only certain
pages are requested, second time it skips lines til a requested page's
first line, then prints the page, then skips lines til the next
requested page, etc.
Once tabs are expanded correctly, this change seems to fix all the
issues except non-monospaced fonts.
An option to deal with that could be to use the new code only for
non-monospaced fonts. For monospaced fonts, use the old code. For
non-monospaced fonts, the issue of Print Preview not matching hardcopy
would remain, but IMO that is a Scintilla bug, and depends on that group
for a fix.
Hi,
sorry if this is a known issue, I couldn't find anything in the mailing list or bugtracker.
I'd like to use Geany for development, but the Macports/Brew versions are very old (v0.21 in macports) and the plugins don't work with those versions. So I've set up all the dependencies and succesfully compiled geany (and the plugins, after some minor compat changes in the sourcecode) and everything seems to run fine, except pasting text (with is a bit of a showstopper…). Copy/Cut, etc work fine and I'm able to cut text from geany and paste it into external editors, but geany seems to ignore pasting (from command line and menu).
I tracked the issue down in the sourcecode and it seems to be scintilla related (although using the newest scintilla version (git master) didn't solve the issue), but unfortunately my GTK knowledge is very limited.
in ScintillaGTK.cxx the Paste() function is being called and the gtk documentation tells me that he 'selection_received' signal now should be fired, leading to ScintillaGTK::SelectionReceived being called, but this is not being called.
With the macports installation, paste seems to work - any hints on what causes this or how to debug it further ?
Regards