[Geany-Devel] A direction for Geany

[Frank Lanitz]

Am 11.11.2013 08:18, schrieb Lex Trotman:
> 1. An architecture that allows multi-threading to be used for non-GUI
> tasks.  The most obvious of course is parsing.  At the moment none of
> the parsers support symbols in anything other than the global scope, and
> adding them would significantly increase the parsing effort, but doing
> it in a background thread would make the performance hit less obvious.
>  But there needs to be a careful design of the passing of data from the
> edit buffer to the parser and back to the symbol tables to minimise
> overhead, latency and ensure its non blocking.  With such an
> architecture other complex functionality can then also happen in the
> background without impacting Geany's responsive feel.

I would like that. Also for some plugin tasks it would be great. But
agree that it is not an easy task.

> 2. Language specific assistance, such as indentation, or dynamic error
> marking and intelligent autocompletes.  I consider that these hang off
> the previous capability of better parsing/analysis of the program.
>  Matthew has demonstrated a prototype that provides some of these
> facilities using libclang (for the clang languages only C, C++, Obj-c).
>  But the current Geany architecture does not support plugging such
> things in easily, and with the number of languages that Geany supports,
> I would suggest that its small, light and fast tag would be severely
> threatened if assistance for all languages were plugged in at once.

I'm afraid too. Most likely dependencies will increase as well as memory
footprint. But this is something we get regular asked on our boothes:
More intelligent auto completion stuff. Unfortunately this is one of the
things making the huge IDE so huge.

> 3. Proper portability.  At the moment Geany is really a Linux
> application that has some limited (and buggy) support for Windows.  The
> main editing widget that Geany uses is available for many platforms and
> toolkits.  If Geany had an architecture that separated the target
> specific parts into a "backend" the way Scintilla does, then it would be
> possible to support multiple targets more easily, making Geany less at
> the mercy of one toolkit's direction (that means you deprecating GTK)
> and better able to support different platforms like OSX and Windows.
>  Work such as that Dimitar is doing for spawning on Windows naturally
> then falls into such a backend.

Is qeany.org still available? ;)
Well... I don't think its a good idea to make the toolkit drawing the
editor complete changeable. It will be a huge effort to support the same
features on Qt and Gtk and Windows ... Even some "native" backends would
be really cool. So kind of modules as we already do with some of the
ifdef-sections for Windows.

> 4. Multiple top level windows.  As monitors are cheaper, being able to
> spread views of files to optimally utilise the screen space available
> adds to the users effectiveness.  Most languages support multiple
> modules in different files and many use multiple files for related
> parts, such as C/C++ header and body.  Looking at and editing several
> places/files at once has many uses.  As useful as splitwindows one and
> two are (especially together) they still assume a single rectangular top
> level is available for subdivision.  But different desktop menu layouts
> or having other applications visible at the same time can limit the
> contiguous rectangular space available.  Multiple top levels can make
> better use of non-rectangular space.

I think this would need a more client-server-architecture as maybe
described in point 3. However, I'd like to have multiple Geany instances
working at same session. But I'm a little afraid of the changes needs to
be done for it.

> These are all big changes that don't fall into the current Geany mode of
> "light maintenance and extra features as someone implements them".  For
> big changes like those above however, a clear design and a planned
> process is needed to ensure that the big changes don't clash with each
> other and that they are not derailed by interim smaller changes.

I agree.
Also I think this needs to be discussed in a more face-to-face-session
than wiki or email.

[suggested steps]
These are good.

Cheers,
Frank

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.geany.org/pipermail/devel/attachments/20131112/52a47699/attachment-0001.pgp>