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
Matthew Brush <notifications(a)github.com> wrote:
> @elextr FWIW, the files `makefile.win32` and `win32env.mk` (and geanypy.nsis for the installer and README.win32 for the instructions) are needed for `src/makefile.win32` to be useful.
>
> @eht16 Any chance you could get some time to try getting the Waf build system working so it can be built on Windows?
Taking cause from Geanypy, there are 2 small problems with $subject:
- no header fiels are installed, or maybe they are copied somewhere
outside the $prefix. Copying the headers manually is OK.
- geany.pc contains paths with single backslashes, and plugins build
fails with "c:path1path2...: no such file or directory". Replacing
with forward slashes works. All other .pc files I've checked under
win32 use forward slashes.
I haven't tried the latest git though.
--
E-gards: Jimmy
Hi Enrico,
We have had a report on IRC that running geany on the windows command
line will only open files in the Geany install directory unless you
use the full path.
eg C:\somepath> geany somefile.txt
will open installpath\somefile.txt not somepath\somefile.txt.
And with the "Open new documents from the command line" option set it
creates somefile.txt in the install dir since it doesn't exist there.
Suspicion is falling on
https://github.com/geany/geany/commit/775ef628688c69de34640e12666aed5762a80…
As the most experienced windowser (and the committer of that change)
could you look at it please?
Cheers
Lex
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,
Up till now we've tried to stay compatible with ANSI C89 because of
GTK+-stack doing so (unless I missed the real reason?).
I propose we update to allowing C99 for the following reasons:
- restricted character set support in <iso646.h> (originally specifed in
AMD1)
- wide-character library support in <wchar.h> and <wctype.h> (originally
specifed in AMD1)
- restricted pointers
- variable-length arrays
- fexible array members
- complex (and imaginary) support in <complex.h>
- type-generic math macros in <tgmath.h>
- the long long int type and library functions
- increased translation limits
- remove implicit int
- the vscanf family of functions
- reliable integer division
- universal character names
- extended identifers
- binary foating-point literals and printf/scanf conversion specifers
- compound literals
- designated initializers
- // comments
- extended integer types in <inttypes.h> and <stdint.h>
- remove implicit function declaration
- preprocessor arithmetic done in intmax_t/uintmax_t
- mixed declarations and code
- integer constant type rules
- integer promotion rules
- vararg macros
- additional math library functions in <math.h>
- foating-point environment access in <fenv.h>
- IEC 60559 (also known as IEC 559 or IEEE arithmetic) support
- trailing comma allowed in enum declaration
- %lf conversion specifer allowed in printf
- inline functions
- the snprintf family of functions
- boolean type in <stdbool.h>
- idempotent type qualifers
- empty macro arguments
- new struct type compatibility rules (tag compatibility)
- _Prama preprocessing operator
- standard pragmas
- __func__ predefned identifer
- VA_COPY macro
- additional strftime conversion specifers
- LIA compatibility annex
- deprecate ungetc at the beginning of a binary file
- remove deprecation of aliased array parameters
(Source: list is 2nd hand from
http://www.open-std.org/JTC1/sc22/wg14/www/docs/n869/)
And that's just improvements since 1999 (way back when I was in high
school), not to mention more recent changes in the latest C11 standard.
I think for us the most likely consequences are:
- Coding in the new millennium style :)
- Microsoft Visual C++ compiler is not C99 conformant and plans not to
ever be AFAIK (of little consequence since we don't compile with MSVC).
- Allowed to use // style comments
- Allowed to declare loop counter-style variable inside the for loop.
- Use standard C instead of G*-portability wrappers in various place
(bool, fixed-width ints, etc.).
This is just sort of random, but I feel that some our code could be
better if we depended less on G*-stack and more on (>10 year old) ISO
standards.
P.S. Sorry for the bikeshed bait.
Cheers,
Matthew Brush
I'm interested in making a patch to add QML support to Geany, but first
I had a few questions. First of all, is anyone else already working on
this? And if not, if I manage to get it working well would my patch be
worked into the main Geany code so others could get it also? I've been
learning programming for a while, but I've never patched or edited
anyone else’s code, so I'm not making promises how fast I'd be able to
get this done, of course from looking at the hacking page it doesn't
look to complicated to add support for another language, I just wanted
to ask these questions before I even attempted this.
Honestly it'll probably take me longer to figure out how to create and
submit the patch then it will to actually change the code in the source
itself.
Hi,
I would like to propose that we have a policy where any commits that
touches the Glade file, must either contain the file's contents after
saving it through the Glade's UI or include a commit that follows it
with the noisy diff produced by Glade. The problem is, we all keep
hand-editing to avoid crappy diffs, but it gets more and more out of
sync with Glade and makes it even worse for the next guy.
Even right now it's impossible to make a change using Glade without
breaking our custom icons that were added by hand[1] and Glade doesn't
support writing their icon-names[2]. If the person making the changes is
also the one to save the noisy Glade XML diff - even if as a separate
commit after the clean hand-edit - then at least it's their own problem
right away when something breaks and not left for the next sucker down
the road who has non-trivial changes to make using Glade GUI :)
Or do we just want to abandon Glade and stick to hand-editing the 10,000
line GtkBuilder XML file?
P.S. Are we all still agreed to using old 3.8.1 version of Glade? I
think this idea of using same version sounds good, at least we won't be
causing additional noise in diffs due to different versions writing
stuff out in different ways.
Thoughts?
Cheers,
Matthew Brush
[1]
https://github.com/geany/geany/commit/dabae1f94f13a85b672746aa0a177d3534048…
[2] https://bugzilla.gnome.org/show_bug.cgi?id=700652
On Sat, 31 Aug 2013 20:33:50 -0000
Matthew Brush <git-noreply(a)geany.org> wrote:
> Debugger provides own GtkCellRenderer GTypes so its module must
> remain resident
>
> + plugin_module_make_resident(geany_plugin);
> +
Note that when a resident module is unloaded and then reloaded (uncheck
then check [] Debugger), the global variables are not re-initialized.
So, if debugger contains any global "[static] type variable = value",
or relies on globals being 0, they must be initialized explicitly.
--
E-gards: Jimmy
Geany is very fast of course:) But we could make it faster
I use excellent runtime profiler named crxprof. It helped me to find one
bottleneck in geany's starting logic:
main (100.0% | 0.0% self)
\_ configuration_open_files (55.5% | 0.0% self)
| \_ document_open_file_full (55.4% | 0.0% self)
| \_ editor_goto_pos (29.7% | 0.0% self)
| \_ sci_goto_pos (29.5% | 0.0% self)
| \_ ScintillaGTK::WndProc (29.5% | 0.0% self)
| \_ Editor::WndProc (29.5% | 0.0% self)
| \_ Editor::EnsureLineVisible (29.5% | 0.0% self)
| \_ Editor::WrapLines (29.5% | 0.0% self)
| \_ Editor::WrapOneLine (21.2% | 0.0% self)
| \_ Editor::LayoutLine (20.3% | 0.4% self)
| \_ PositionCache::MeasureWidths (19.0% | 0.3% self)
| \_ SurfaceImpl::MeasureWidths (18.7% | 0.4% self)
| \_ pango_layout_get_iter (16.1% | 1.1% self)
| \_ pango_itemize_with_base_dir (5.7% | 0.8% self)
As you see, editor_goto_pos takes 1/3 of _loading_ time!
But it shouldn't be called at least if position if 0, so adding simple
optimization will improve loading speed:
GeanyDocument *document_open_file_full(..)
.............
if(pos)
{
/* set the cursor position according to pos,
cl_options.goto_line and cl_options.goto_column */ pos =
set_cursor_position(doc->editor, pos); /* now bring the file in front */
editor_goto_pos(doc->editor, pos, FALSE);
}
Not best solution but it works for me:
Loading time before optimization: 8.952s
Loading time after optimization: 5.799s
Much better, isn't?
Other proposals about loading speed:
1) Skip unnecessary operations for EACH document because actually user will see
only LAST loaded document. Other operations could be delayed.
2) Put tag manager in separate thread and parse tags not inside GUI thread
because it's really slow. Adding mutex for tag manager shouldn't be hard.
3) Maybe, delay loading of all files? Load and show only last file, load others
only when they need to be displayed. This will allow to have 1000-s of tabs
without a pain. I think people who work on huge projects will understand me.
--
Best regards,
Pavel Roschin aka RPG
> pos=0 is the default when a new document is opened, only documents in the
> previous session will be opened with pos != 0. You need to call
> set_cursor_position() to see if any command line options requested a
> position other than zero, or you will break opening new documents from the
> command line. Note, since the command line options are line and col they
> can't be translated into pos until the document is opened, so they can't
> pass a pos to document_open().
Not sure that my patch broke something but maybe I found more acceptable
solution: add into sci_goto_pos function this:
if(pos == sci_get_current_position(sci))
return;
This has the same effect but it's logically clearly.
--
Best regards,
Pavel Roschin aka RPG