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...