[Geany-Devel] splitwindow2

[Matthew Brush]

On 13-10-10 03:03 AM, Thomas Martitz wrote:
> Hello,
>
> I just wanted to let you know that I'm working on a new splitwindow
> implementation and I would like to have early input. But, also as a
> warning, I'm progressing only slowly because I'm at the final phase of
> my master thesis which currently needs more attention that Geany hacking.
>
> Anyway, we all know about the limitations of the splitwindow plugin.
> They include (not a complete list):
> - the other view can only have one document

You can actually change which document it shows by using the little 
drop-down button at the top. Still, real notebooks would be nicer.

> - you cannot undo/redo: you need to select the tab in the main notebook
> to do that

You can undo using the builtin Scintilla right-click context menu, but 
still would be great to have full keybindings+edit menu functionality.

> - state is not saved/restored across Geany restarts
> - it's completely awkward because the other view shows a doc that's also
> in the main view, editing in the other view will change the main view at
> the same time.

I think this is intended and I find it useful personally. I don't think 
it should be taken out, IMO.

> - you cannot toggle between the views with a keybinding (e.g. ctrl+tab)
> - weird focus behavior
> - more...

...Basically all edit keybindings, the edit/context menu and also 
auto-indentation and similar features implemented inside Geany.

>
> My plan is to reimplement splitwindow using a different approach: by
> having two real, independemt notebooks, one primary and one seconary.
>

Why limit it to two? Even if it ends up being the default/primary mode 
of operation, IMO it'd be a shame to make another hard-coded assumption.[1]

> New docs will be opened in the primary one by default, but can be moved
> to the secondary one at will. This means that no document can be shown
> in both at the same time which makes it a loss less awkward. It also

As mentioned above, this is actually a feature and IMO it should be kept 
unless there is some serious technical reason that makes it impossible. 
Scintilla can easily be showing the same document in two views and it 
keeps them in sync (see SCI_SETDOCPOINTER and friends).

> lets us lift the other limitations:
> - undo/redo will work
> - state can be saved across restarts (config file format will probably
> need some changes for this)
> - toggling with keybindings between views can work
> - you can arbitrarily assign docs to views using different methods
>
> The nice things about splitwindow that should be probably be kept:
> - chose between horizontal and vertical split
> - automatic sizing of the views

Just to be clear, because Lex's message made it sound like it was 
slightly magic; it's just the width/height available divided by two 
right now IIRC (which is fine IMO). With your above item about saving 
state, hopefully it would include the splitter positions, but I guess 
it's not a big deal if not.

> - anything else?
>

Even though I usually rant against hard-coding language specific stuff 
into the core, I think it would be extremely useful to have an option to 
open header/implementation file in the other view. For example if I'm 
editing foo.c, it could look for foo.h (either being open or in same 
directory), and open it in the other view. It could work the other way 
around as well. I think it'd probably only be really useful for C, C++ 
and Obj-C filetypes, although I don't know that many languages, so aybe 
some others could benefit as well.

> Unfortunately Geany's core is pretty hardcoded as to assume one (and
> only one) notebook for documents. This means that for this various
> changes to Geany core are necessasry, some of which may be difficult to
> do without breaking the plugin API/ABI. Some are gonna hate this but I'm
> not currently planning do this as a plugin because the core needs a lot
> of changes anyway for breaking the single notebook assumption. But I'm
> very open for discussion which is why I'm writing this early.
>

I agree it should be a core feature and a lot of users (myself included) 
consider it a critical feature. I think it could be done without 
breaking too much in the plugin API except a few functions like 
document_compare_by_tab_order() and document_get_notebook_page() and 
stuff, but maybe I'm missing something.

> I already have an experimental version up and running that doesn't even
> require all that much changes[1] and it seems to work nicely. See
> this[2] screenshot.
>
> So, any opinions?
>

It sounds like you already are planning some of this, but it would be 
nice to cleanup a lot of the assumptions/hardcoded stuff/weirdness while 
making these fairly intrusive changes. For example:

- The relationship between documents and notebooks they're in, as you 
discussed. As Lex mentioned, it would be nice to not make too much new 
hard-coded assumptions about other documents only being allowed in 
another notebook, but rather making it extensible to support multiple 
windows in the future. Also as I mentioned, it would be nice to not make 
any hard-coded assumptions about only having two split notebooks[1].
- The relationship between documents (models) and Scintilla (views), 
they should be almost completely independent. There shouldn't need to 
have document->editor->scintilla, the document needn't care what view 
it's in, only the reverse. I have no idea where GeanyEditor fits into 
this, I've never understood why it exists; it's not a view, it's not a 
model, and it's not really a controller either, it's like part wrapper 
over Scintilla, part extension of GeanyDocument or something like this I 
guess?
- The lifetimes of documents. I don't see any reason to recycle a fairly 
small structure like GeanyDocument, especially since we basically set it 
up and tear it down each time anyway. I doubt the overhead of freeing an 
old GeanyDocument structure and allocating a new one later is worth the 
contortions it causes in code and the weirdness in the plugin API.
- This follows with above, document_get_current() should *never* return 
NULL. It makes absolutely no sense to me to allow having Geany open 
without a document open. It'd be like having Firefox open with no 
tabs/webpages open. Either it should open a blank untitled document when 
the last one closes (this option exists already IIRC) or Geany itself 
should just close (probably too annoying :) These last two would get rid 
of weirdness like doc->is_valid, DOC_VALID(), "documents" macro wrapping 
documents_array, foreach_document() macro to iterate documents, etc.
- Encapsulating the GeanyDocument so that plugins can't mess with 
read-only members. For example, it makes no sense to allow plugins to 
change doc->read_only, or doc->file_name (one of them actually does 
this). It would be nice to make the API consistent here, like we have 
document_set_text_changed() to mark the document as ditry/clean, but 
there's no getter like document_get_text_changed(), which is 
inconsistent and it allows plugins to seriously break Geany if they 
aren't careful. This one is of course fairly off-topic and could be 
attacked separately afterwards, I just thought it was worth mentioning 
since you talked about needing to break the plugin API, it might be 
useful to improve it during the breakage.

I actually use the current crippled split view *extensively* so I would 
also be really interested in helping out with this. If it was useful we 
could make a branch on the main repository to work from and get more 
visibility with it probably.

Cheers,
Matthew Brush

[1]: I once wrote a toy editor using GTK+/Scintilla (never finished it), 
that supported arbitrary splitting of the views. You would select the 
panel to split and choose to either split horizontally or vertically and 
it would split the panel that is selected into two. You do that again, 
and now it would be split into three, and so on. This way it's not 
making any assumptions about how many views the user might want or their 
screen resolution and stuff. To visualize:

One view:

+---------------------------------------------+
|                                             |
|                                             |
|                                             |
|                                             |
|                                             |
+---------------------------------------------+

Split side-by-side:

+---------------------------------------------+
|                     |                       |
|                     |                       |
|                     |                       |
|                     |                       |
|                     |                       |
+---------------------------------------------+

Split right view top-and-bottom:

+---------------------------------------------+
|                     |                       |
|                     |                       |
|                     |-----------------------|
|                     |                       |
|                     |                       |
+---------------------------------------------+

Split bottom right view side-by-side:

+---------------------------------------------+
|                     |                       |
|                     |                       |
|                     |-----------------------|
|                     |           |           |
|                     |           |           |
+---------------------------------------------+

And so on...