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
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
Hi guys,
I'm considering moving our hard-coded custom styles (notebook tab button
sizing, monospaced search entries and unmatched search entries) to an
external resource file (geany.gtkrc in the datadir) -- patch attached.
The main reason to do this is to make it easier to replace this by a CSS
file for my GTK3 port (attempt). However, we can see a few other
interesting (or not) points:
+ this removes some hard-coded stuff in a few places;
+ this actually removes an overall of 16 lines, and actually 39 lines
of code (those 23 lines being in the resource file);
+ easier to replace with a CSS file in the GTK3 port (and gives the
same advantages than with the RC files);
- that's another file to load.
So the question is, are we happy to load another file at startup,
besides the Glade XML? I don't think it's a performance problem,
moreover the file being probably stored in a near location to the Glade
file, but since we always tried to load as less files as possible, do we
want to add this file?
Since now we need to load the Glade file anyway, I think it's less of a
concern to add additional external files. If we think external files
are OK, maybe we'd like to also move our custom images out of images.c
to normal files in out datadir. Actually, we currently have 7 inline
images (aladin (logo), build, close all, and two save all, and the two
used in the completion popup), but also "normal" icons (for the symbol
list for example).
So, what do you think?
Regards,
Colomban
Hi,
I'm sending my stack of patches against geany again, this time as individual patches. Here's the full list:
[PATCH 01/19] Prevent -Wmissing-prototypes report warning when compiling a plugin
[PATCH 02/19] Add signals for project options dialog opening and closing
[PATCH 03/19] Make the project menu accessible by plugins
[PATCH 04/19] Make it possible to change project patterns by plugins
[PATCH 05/19] Don't be annoying when not necessary
[PATCH 06/19] Make it possible for plugins to change the base directory of msgwindow
[PATCH 07/19] Open the file in the msgwindow even if no linenumber is specified
[PATCH 08/19] When closing tab, return to the document at the top of the MRU list
[PATCH 09/19] Use wider entry for project file path
[PATCH 10/19] New utils function to get relative path from one directory to another
[PATCH 11/19] File name in the project settings dialog shouldn't look it is editable
[PATCH 12/19] Use relative paths in the project files
[PATCH 13/19] Remove the "set" button from the project properties dialog
[PATCH 14/19] Rewrite tab switching queue
[PATCH 15/19] Do not insert --include= when the search pattern entry is empty
[PATCH 16/19] Use project patterns in the FIF dialog
[PATCH 17/19] Make the tab switching dialog a bit more useful
[PATCH 18/19] Use standard include paths for "open selected file"
[PATCH 19/19] Use per document indent sizes
Only some of them are required by gproject - others are just suggestions for improvements. I didn't explicitly distinguish between these two types of patches but it should be pretty clear from the description. There have been some minor changes since my last post - mainly the change of the FIF dialog to contain combo box for pattern selection and there are also some new patches - the detailed description is in the individual emails. Of course many of the patches are suggestions only so further discussion is welcome.
Cheers,
Jiri
Hi all,
just as a note: I plan to move all Geany-related mailing lists from
uvena.de to the geany.org server on Friday, October 5 2012, around 12:00
UTC.
The lists will be down during move for about 1-2 hours.
I'll send a reminder shortly before starting with the actual move next week.
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Hi All,
I sometimes see an error on project close where the previously open files
are not restored, instead the project files are re-opened.
It only occurs very intermittently and I have not been able to find a
repeatable cause.
It has been present for a long time and is still present in the current Git
HEAD.
Has anyone else seen it and have any further information on how to trigger
it?
Cheers
Lex