[Geany-Devel] A direction for Geany

[Yosef Or Boczko]

What about redesign the GUI?

Regards,
Yosef Or Boczko

בתאריך ב', נוב 11, 2013 בשעה 9:18 AM, Lex Trotman 
<elextr at 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
> 
> 
> 
> 
> 
>