What about redesign the GUI?
Regards,
Yosef Or Boczko
בתאריך ב', נוב 11, 2013 בשעה 9:18 AM, Lex Trotman
<ele...@gmail.com> כתב:
Hi All,
Recently there have been a number of proposals for significant
changes in Geany, different languages, GObjectification and other
various changes.
As good or bad as the individual suggestions may be, they have made
it clear to me that there is no plan for the future of Geany that
allows them to be evaluated effectively.
So I am starting this thread to try to get ideas on where Geany
should be headed.
To start the ball rolling, here are some of the things I see Geany
should aspire to:
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.
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.
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.
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.
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 would suggest the process to be:
1. gather other major ideas for capabilities that Geany should plan
to support
2. develop a design that supports these (or at least the most useful
ones)
3. look at how that design can be implemented, can the existing
design be mutated to it, or is it a clean framework that large parts
of the existing functionality can plug into, or is it a whole clean
implementation. This also includes issues like languages to use (C,
C++, Vala, Haskell etc).
4. depending on the outcome from 3. use a new repository organisation
or at least a new branch in the existing Geany repo to ensure that
the existing Geany is not destabilised by major changes as they take
place.
This is something very different to the way Geany is currently
operating, and I don't know if the community wants to consider such a
more structured approach. If its felt that its worthwhile then I
suggest that steps one and two are best achieved using the wiki and I
will volunteer to set up and maintain page(s) for those phases at
least.
So to summarise, what capabilities should Geany aspire to support,
and what is the process to develop the best software architecture to
support those capabilities.
Cheers
Lex
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
