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 cannot undo/redo: you need to select the tab in the main notebook to do that - 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. - you cannot toggle between the views with a keybinding (e.g. ctrl+tab) - weird focus behavior - more...
My plan is to reimplement splitwindow using a different approach: by having two real, independemt notebooks, one primary and one seconary.
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 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 - anything else?
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 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?
[1]: https://github.com/kugel-/geany/tree/splitwindow2 [2]: http://www.alice-dsl.net/simonemartitz/default/splitwindow2.png
Best regards.
On 10 October 2013 21:03, Thomas Martitz < thomas.martitz@student.htw-berlin.de> 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.
Breaks away from the thesis are good, or so I used to tell myself ;-)
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 cannot undo/redo: you need to select the tab in the main notebook to
do that
- 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.
- you cannot toggle between the views with a keybinding (e.g. ctrl+tab)
- weird focus behavior
- more...
My plan is to reimplement splitwindow using a different approach: by having two real, independemt notebooks, one primary and one seconary.
Yes please, editing .hpp and .cpp at the same time will be a great step forward.
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 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
Whilst looking at two places of the same document is also a use-case of split windows, if this restriction allows the initial implementation of a proper split window system more easily then lets start with it. All I would say is try not to make it too hard to expand later.
The nice things about splitwindow that should be probably be kept:
- chose between horizontal and vertical split
- automatic sizing of the views
So long as manual sizing is still available, fine, Geany is not smart enough to always know what width/height I need.
- anything else?
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.
Its gotta happen at some point, so long as the changes are sensible and for a good reason then its ok, but I would probably say that means make the change after the next release, so there is no rush on trying to get a big (well big relative to recent ones) API change tested and into the plugins.
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.
Will look at it and try it as soon as I can, but some guy on IRC keeps prompting for feedback :)
So, any opinions?
For me this is second only to multiple windows as an editing feature that Geany needs, and I expect it is an important step towards multiple windows.
Cheers Lex
Best regards. ______________________________**_________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
Out of curiosity, do you plan to be able to split a single document, or only two separate ones, or both? It sounds like this is for showing two different documents at once, as loading a single document with two views of it would probably have it's own problems associated with it.
On 10/10/2013 04: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 cannot undo/redo: you need to select the tab in the main
notebook to do that
- 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.
- you cannot toggle between the views with a keybinding (e.g. ctrl+tab)
- weird focus behavior
- more...
My plan is to reimplement splitwindow using a different approach: by having two real, independemt notebooks, one primary and one seconary.
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 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
- anything else?
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 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?
Best regards. _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
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...
Am 11.10.2013 00:55, schrieb 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.
Yea, right. I worded it badly. I meant the other view can only hold one document and you can swap that one only using non-standard methods.
- 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.
Oh, I wasn't aware of that. Still crap :)
- 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]
Well, first: I'm not going to be hardcode two notebooks (except where necessary and trivial extend, e.g. for my current "toggle this between notebooks". 99% of the now hardcoded places will work fine, e.g. I'm using gtk_widget_get_parent(sci) to get a doc's notebook and implement a foreach_notebook() macro. So this should make it really trivial to support even more than 2 notebooks.
But still, I personally don't have a need for more than 2 notebooks. Plus I see it will be difficult to support, because you need to nest GtkPaneds. Since you suggest arbitrary splits you can do this only programmatically which sounds like a major headache to me (especially w.r.t. saving/restoring state). For now I want to concentrate on lifting the hardcoded single notebook without ending up in the same situation for two ones and without worrying about the heavy case of arbitrary notebook placing. Then we can continue from there on with more sophisticated stuff.
However if you have already successfully implemented this in a toy editor I welcome you to join the fun.
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).
Do you edit on both views or just read on one part of the doc while editing the other? If this works automagically via scintilla then fine but I can imagine it has more implications/complications apart from Scintilla. Thus for me this has low priority so I would like to get the non-duplicate docs use case working first.
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.
Automatic sizing also includes what to do if one or both of the notebooks becomes empty, a previously empty one becomes non-empty or how to deal with the user making non-50/50 splits. Although I'm not even sure the current splitwindow handles all cases well?
- 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.
This is provided by two plugins already. I think those plugins should be able to show the header on the other notebook once they are adapted for multiple notebooks. I also think of other use cases, e.g. geanyvc opening the file diff/log/blame of the current file in the other notebook.
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.
One problem is that there are some document_* functions which only refer to page numbers. These are ambiguous with two (or more) notebooks. So plugins that call this might act up. For now I changed these functions to use the notebook that's currently focused but I of course added corresponding functions with an explicit notebook parameter too.
There are also many direct uses of main_widgets.notebook, changing these might (or might not) affect plugins.
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 notebook of a doc can be retrieved via gtk_widget_get_parent(doc->editor->sci) without hardcoding. I'm using this where possible.
- 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?
Sorry, I think this item is out of scope for this work. FWIW, I don't quite understand the deal about GeanyEditor either.
- 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.
Seems completely unrelated to splitwindow.
- 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.
Also unrelated.
- 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.
Also unrelated. I agree that big API breakage should be as rare and concentrated as possible (i.e. within a single release) but not as part of a single change. Let's not blow this splitwindow work up with unrelated changes. This would just make review impossible and cost more time to get done.
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.
Fine with me. You can also make PRs on my github until this is set up (but beware that I still amend and rebase) :)
Cheers, Matthew Brush
Thanks for your input.
Best regards. Thomas Martitz
On 13-10-10 05:03 PM, Thomas Martitz wrote:
Am 11.10.2013 00:55, schrieb 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.
Yea, right. I worded it badly. I meant the other view can only hold one document and you can swap that one only using non-standard methods.
Yeah, it's a kind of weird interface, although it works not bad considering.
- 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.
Oh, I wasn't aware of that. Still crap :)
It was somewhat recent-ish. At first we didn't have it because it didn't integrate into gettext translation stuff, so we couldn't translate the menu items, but IIRC it was later decided that it was such a needed feature being able to copy/paste/undo/etc, that at least having a minimal non-translated menu is better than nothing.
- 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]
Well, first: I'm not going to be hardcode two notebooks (except where necessary and trivial extend, e.g. for my current "toggle this between
This sounds good.
notebooks". 99% of the now hardcoded places will work fine, e.g. I'm using gtk_widget_get_parent(sci) to get a doc's notebook and implement a foreach_notebook() macro. So this should make it really trivial to support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla will be packed directly into a notebook. Plugins can easily break this assumption by reparenting the Scintilla widget, and even my document-messages branch moved each Scintilla into a VBox inside each tab so it could pack a GtkInfo bar above it. I think we could get rid of this assumption by designing the code better.
Please don't write another foreach_ macro. Lets make it so we can use normal C code. If you need a macro like foreach_notebook() it's probably because the code it's hiding is crappy underlying code, IMO.
But still, I personally don't have a need for more than 2 notebooks. Plus I see it will be difficult to support, because you need to nest GtkPaneds. Since you suggest arbitrary splits you can do this only programmatically which sounds like a major headache to me (especially w.r.t. saving/restoring state). For now I want to concentrate on lifting the hardcoded single notebook without ending up in the same situation for two ones and without worrying about the heavy case of arbitrary notebook placing. Then we can continue from there on with more sophisticated stuff.
However if you have already successfully implemented this in a toy editor I welcome you to join the fun.
Just to be clear, regarding the split window feature in my toy editor, I only coded the UI logic, not any of the storing config of what panes were open or what documents they had in them and more complicated stuff like this. But the UI was indeed quite neat. SublimeText also has a similarly flexible split pane system.
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).
Do you edit on both views or just read on one part of the doc while editing the other? If this works automagically via scintilla then fine but I can imagine it has more implications/complications apart from Scintilla. Thus for me this has low priority so I would like to get the non-duplicate docs use case working first.
Well for the Scintilla part, it "just works", it's exactly what it was designed for. I'm not sure about any of the other complications apart from Scintilla. Either way, as long as we don't make any assumptions that two views can't be displaying the same document, it's no big deal for now.
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.
Automatic sizing also includes what to do if one or both of the notebooks becomes empty, a previously empty one becomes non-empty or how to deal with the user making non-50/50 splits. Although I'm not even sure the current splitwindow handles all cases well?
When the last tab is closed, close the split. If it's easy to re-split, it doesn't matter. Like user just opens the document, right clicks on the tab and presses the "move to split->vertical" menu item or something like this. As mentioned in the other message, it probably isn't so important to care about splitter positions, as long as they default to 50/50, at least for now.
- 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.
This is provided by two plugins already. I think those plugins should be able to show the header on the other notebook once they are adapted for multiple notebooks. I also think of other use cases, e.g. geanyvc opening the file diff/log/blame of the current file in the other notebook.
You are correct, I agree.
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.
One problem is that there are some document_* functions which only refer to page numbers. These are ambiguous with two (or more) notebooks. So plugins that call this might act up. For now I changed these functions to use the notebook that's currently focused but I of course added corresponding functions with an explicit notebook parameter too.
All of those functions in document_ module shouldn't care the least about GTK+ or even notebooks, IMO. This is the type of stuff I want to cleanup.
There are also many direct uses of main_widgets.notebook, changing these might (or might not) affect plugins.
IMO, if you're going to break the plugin API anyway, I say make it good and we'll fixup core and GP plugins and make a message on the mailing list for other users to know what broke and how to fix it in their own personal plugins.
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.
IMO, least amount of changes is not necessarily a virtue, and can even lead to further gluing of the code together making future changes even harder.
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 notebook of a doc can be retrieved via gtk_widget_get_parent(doc->editor->sci) without hardcoding. I'm using this where possible.
You're still hardcoding, just a different assumption as mentioned above.
- 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?
Sorry, I think this item is out of scope for this work. FWIW, I don't quite understand the deal about GeanyEditor either.
It's not out of scope, but it is way more work than I think you're personally prepared to do. It's basically the reason no one fixed the split window before or worked to moving it into core, because it was too much work with the current way it's coded. If this kind of stuff gets cleaned up first, the split window thing becomes trivial (as well as multi-window, etc). I would've fixed up split window myself 10x by now if I didn't morally have to cleanup all this code to do it correctly.
- 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.
Seems completely unrelated to splitwindow.
It's more part of the overall problems with the way the code currently is, but you're right, it's mostly unrelated and could be addressed separately.
- 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.
Also unrelated.
Also related to cleaning up the code properly first, but not directly maybe with the scope of changes you're proposing.
- 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.
Also unrelated. I agree that big API breakage should be as rare and concentrated as possible (i.e. within a single release) but not as part of a single change. Let's not blow this splitwindow work up with unrelated changes. This would just make review impossible and cost more time to get done.
The fact that it "blows up" into more work is exactly why we should bite bullet instead of keep "just making it work with minimal changes", when the code is factored well, making changes becomes easier. But I digress somewhat (as usual).
I withdraw my request to help out with this because I don't think you're interested in doing some of the bigger underlying changes I was interested in doing before attempting to fixup split window, and I don't want to drag you down. As long as you keep in mind the stuff mentioned, and don't make any additional same type of assumptions that were made and evolved previously, I think it won't be such a big deal to do the stuff I was talking about underneath your changes as a separate initiative later on.
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.
Fine with me. You can also make PRs on my github until this is set up (but beware that I still amend and rebase) :)
I can still make a branch for this but as mentioned above I won't be contributing much to it as it stands. I will be a good tester though because I *really* want a fully functional split window :)
Cheers, Matthew Brush
Thanks for your input.
Sorry to be such a downer, I just really hate seeing this vicious circle of adding more and more code ontop of other code that needs to be refactored, making everything all intertwined and hard to hack on.
Cheers, Matthew Brush
Am 11.10.2013 07:01, schrieb Matthew Brush:
notebooks". 99% of the now hardcoded places will work fine, e.g. I'm using gtk_widget_get_parent(sci) to get a doc's notebook and implement a foreach_notebook() macro. So this should make it really trivial to support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla will be packed directly into a notebook. Plugins can easily break this assumption by reparenting the Scintilla widget, and even my document-messages branch moved each Scintilla into a VBox inside each tab so it could pack a GtkInfo bar above it. I think we could get rid of this assumption by designing the code better.
Okay, I have written a function that walks the tree to find the parent notebook. So this assumption is no more. Thanks for the hint.
Please don't write another foreach_ macro. Lets make it so we can use normal C code. If you need a macro like foreach_notebook() it's probably because the code it's hiding is crappy underlying code, IMO.
I like foreach_*, and many other people do. I guess it's subjective. Plus it will make the transition from "main and secondary notebook" to "array of N notebooks" easier.
But still, I personally don't have a need for more than 2 notebooks. Plus I see it will be difficult to support, because you need to nest GtkPaneds. Since you suggest arbitrary splits you can do this only programmatically which sounds like a major headache to me (especially w.r.t. saving/restoring state). For now I want to concentrate on lifting the hardcoded single notebook without ending up in the same situation for two ones and without worrying about the heavy case of arbitrary notebook placing. Then we can continue from there on with more sophisticated stuff.
However if you have already successfully implemented this in a toy editor I welcome you to join the fun.
Just to be clear, regarding the split window feature in my toy editor, I only coded the UI logic, not any of the storing config of what panes were open or what documents they had in them and more complicated stuff like this. But the UI was indeed quite neat. SublimeText also has a similarly flexible split pane system.
Okay, so you stopped ater the easy parts :P
All of those functions in document_ module shouldn't care the least about GTK+ or even notebooks, IMO. This is the type of stuff I want to cleanup.
There are also many direct uses of main_widgets.notebook, changing these might (or might not) affect plugins.
IMO, if you're going to break the plugin API anyway, I say make it good and we'll fixup core and GP plugins and make a message on the mailing list for other users to know what broke and how to fix it in their own personal plugins.
It's not yet clear to me how bady (or if at all) the API is going to break..
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.
IMO, least amount of changes is not necessarily a virtue, and can even lead to further gluing of the code together making future changes even harder.
But it's better than not getting the job done at all because people want to much at once.
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].
gtk_widget_get_parent(doc->editor->sci) without hardcoding. I'm using this where possible.
You're still hardcoding, just a different assumption as mentioned above.
The notebook of a doc can be retrieved via - 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?
Sorry, I think this item is out of scope for this work. FWIW, I don't quite understand the deal about GeanyEditor either.
It's not out of scope, but it is way more work than I think you're personally prepared to do. It's basically the reason no one fixed the split window before or worked to moving it into core, because it was too much work with the current way it's coded. If this kind of stuff gets cleaned up first, the split window thing becomes trivial (as well as multi-window, etc). I would've fixed up split window myself 10x by now if I didn't morally have to cleanup all this code to do it correctly.
See, if you make this kind of cleanup a hard requirement that no progress is going to happen, for the reasons you mention. Can't we just progress with managable portions of cleanups/workload, considering our already heavily limited developer manpower?
The cleanup you propose would be impossible for me to do anyway, because I have no vision how the end result would look like. Without such a vision I wouldn't know where to start and where to end. As I said, I don't know about the GeanyEditor deal but I don't have a problem with it either. And splitwindow can be done with the current structures. So I maintain that your proposal is out of scope for my work. The same goes for your other cleanup proposals.
- 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.
Also unrelated. I agree that big API breakage should be as rare and concentrated as possible (i.e. within a single release) but not as part of a single change. Let's not blow this splitwindow work up with unrelated changes. This would just make review impossible and cost more time to get done.
The fact that it "blows up" into more work is exactly why we should bite bullet instead of keep "just making it work with minimal changes", when the code is factored well, making changes becomes easier. But I digress somewhat (as usual).
I withdraw my request to help out with this because I don't think you're interested in doing some of the bigger underlying changes I was interested in doing before attempting to fixup split window, and I don't want to drag you down. As long as you keep in mind the stuff mentioned, and don't make any additional same type of assumptions that were made and evolved previously, I think it won't be such a big deal to do the stuff I was talking about underneath your changes as a separate initiative later on.
Right, I'm not interested in doing the bigger cleanups. For three reasons: (a) my time is limited and I want to get splitwindow done more than anything else (w.r.t. to Geany) currently. (b) unlike you I have no vision how the cleanup should look like. (c) I have no problem with the current code base (yet).
You aren't willing to do the cleanups either, as you noted before. So I'm not actually sure what you're after.
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.
Fine with me. You can also make PRs on my github until this is set up (but beware that I still amend and rebase) :)
I can still make a branch for this but as mentioned above I won't be contributing much to it as it stands. I will be a good tester though because I *really* want a fully functional split window :)
I appreciate testing. But right now it's still a long road.
Cheers, Matthew Brush
Thanks for your input.
Sorry to be such a downer, I just really hate seeing this vicious circle of adding more and more code ontop of other code that needs to be refactored, making everything all intertwined and hard to hack on.
Well, it needn't get worse that status quo. See it as part of incremental cleanup. Why are you so pessimistic about that?
Best regards.
On 13-10-11 02:23 AM, Thomas Martitz wrote:
Am 11.10.2013 07:01, schrieb Matthew Brush:
notebooks". 99% of the now hardcoded places will work fine, e.g. I'm using gtk_widget_get_parent(sci) to get a doc's notebook and implement a foreach_notebook() macro. So this should make it really trivial to support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla will be packed directly into a notebook. Plugins can easily break this assumption by reparenting the Scintilla widget, and even my document-messages branch moved each Scintilla into a VBox inside each tab so it could pack a GtkInfo bar above it. I think we could get rid of this assumption by designing the code better.
Okay, I have written a function that walks the tree to find the parent notebook. So this assumption is no more. Thanks for the hint.
You don't need to walk any tree's, if you need to notebook from the scintilla, just store a pointer to the notebook in the scintilla, ex. using g_object_set_data() or more painfully by subclassing it.
Please don't write another foreach_ macro. Lets make it so we can use normal C code. If you need a macro like foreach_notebook() it's probably because the code it's hiding is crappy underlying code, IMO.
I like foreach_*, and many other people do. I guess it's subjective. Plus it will make the transition from "main and secondary notebook" to "array of N notebooks" easier.
What's the problem with just using C code?
for (size_t i=0; i < notebooks_arr->len; i++) { // just normally use elements in the GPtrArray (as example) }
Such macros not only make for weird APIs but also do weird stuff with arguments since it's just textual replacements.
But still, I personally don't have a need for more than 2 notebooks. Plus I see it will be difficult to support, because you need to nest GtkPaneds. Since you suggest arbitrary splits you can do this only programmatically which sounds like a major headache to me (especially w.r.t. saving/restoring state). For now I want to concentrate on lifting the hardcoded single notebook without ending up in the same situation for two ones and without worrying about the heavy case of arbitrary notebook placing. Then we can continue from there on with more sophisticated stuff.
However if you have already successfully implemented this in a toy editor I welcome you to join the fun.
Just to be clear, regarding the split window feature in my toy editor, I only coded the UI logic, not any of the storing config of what panes were open or what documents they had in them and more complicated stuff like this. But the UI was indeed quite neat. SublimeText also has a similarly flexible split pane system.
Okay, so you stopped ater the easy parts :P
Yep :)
All of those functions in document_ module shouldn't care the least about GTK+ or even notebooks, IMO. This is the type of stuff I want to cleanup.
There are also many direct uses of main_widgets.notebook, changing these might (or might not) affect plugins.
IMO, if you're going to break the plugin API anyway, I say make it good and we'll fixup core and GP plugins and make a message on the mailing list for other users to know what broke and how to fix it in their own personal plugins.
It's not yet clear to me how bady (or if at all) the API is going to break..
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.
IMO, least amount of changes is not necessarily a virtue, and can even lead to further gluing of the code together making future changes even harder.
But it's better than not getting the job done at all because people want to much at once.
Yeah, but I wonder. Sometimes just patching on more changes adds to the number of bugs and code weirdness at least as much as just refactoring the code being patched on to. Of course if you just want to tack on a quick feature this is desirable, but if you want to improve the overall code quality, it's arguable.
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].
gtk_widget_get_parent(doc->editor->sci) without hardcoding. I'm using this where possible.
You're still hardcoding, just a different assumption as mentioned above.
The notebook of a doc can be retrieved via - 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?
Sorry, I think this item is out of scope for this work. FWIW, I don't quite understand the deal about GeanyEditor either.
It's not out of scope, but it is way more work than I think you're personally prepared to do. It's basically the reason no one fixed the split window before or worked to moving it into core, because it was too much work with the current way it's coded. If this kind of stuff gets cleaned up first, the split window thing becomes trivial (as well as multi-window, etc). I would've fixed up split window myself 10x by now if I didn't morally have to cleanup all this code to do it correctly.
See, if you make this kind of cleanup a hard requirement that no progress is going to happen, for the reasons you mention. Can't we just progress with managable portions of cleanups/workload, considering our already heavily limited developer manpower?
Yep, that's why my previous message, I'll try not to interfere here too much since no one is interested in the type of stuff I'm talking about probably (cleanup up the code en masse).
The cleanup you propose would be impossible for me to do anyway, because I have no vision how the end result would look like. Without such a vision I wouldn't know where to start and where to end. As I said, I don't know about the GeanyEditor deal but I don't have a problem with it either. And splitwindow can be done with the current structures. So I maintain that your proposal is out of scope for my work. The same goes for your other cleanup proposals.
The patterns and paradigms used in IDE software and editors are not new, we aren't paving new ground here, usually we're just fighting it by not using the tools at our disposal for artificial reasons (totally off-topic).
- 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.
Also unrelated. I agree that big API breakage should be as rare and concentrated as possible (i.e. within a single release) but not as part of a single change. Let's not blow this splitwindow work up with unrelated changes. This would just make review impossible and cost more time to get done.
The fact that it "blows up" into more work is exactly why we should bite bullet instead of keep "just making it work with minimal changes", when the code is factored well, making changes becomes easier. But I digress somewhat (as usual).
I withdraw my request to help out with this because I don't think you're interested in doing some of the bigger underlying changes I was interested in doing before attempting to fixup split window, and I don't want to drag you down. As long as you keep in mind the stuff mentioned, and don't make any additional same type of assumptions that were made and evolved previously, I think it won't be such a big deal to do the stuff I was talking about underneath your changes as a separate initiative later on.
Right, I'm not interested in doing the bigger cleanups. For three reasons: (a) my time is limited and I want to get splitwindow done more than anything else (w.r.t. to Geany) currently. (b) unlike you I have no vision how the cleanup should look like. (c) I have no problem with the current code base (yet).
(a) yep, just throw another patch on it, it's not going to much change situation and it at least adds a highly desirable feature.
(b) I usually just study how other IDEs and editors work and are coded. As mentioned, this is not new territory, we have footprints to follow.
(c) A lot of it is intertangled and is the result of starting with no design and then tacking on another feature, and another feature and so on. Don't get me wrong, it works very well, but anytime you go to make any non-trivial change to the source you end up opening a whole can of worms or just patching on another hack because you don't have a week to refactor the code, I'm as guilty as anyone...
You aren't willing to do the cleanups either, as you noted before. So I'm not actually sure what you're after.
I'm willing to actually *do* the cleanups, I'm just not up to the task of bikeshedding over every line of code in excruciating detail by people who won't even add your remote and test and push you some changes for stuff they don't like (I don't exclude myself here). It's a grueling way to accept contributions, which is why I said I will mostly stay out of the way.
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.
Fine with me. You can also make PRs on my github until this is set up (but beware that I still amend and rebase) :)
I can still make a branch for this but as mentioned above I won't be contributing much to it as it stands. I will be a good tester though because I *really* want a fully functional split window :)
I appreciate testing. But right now it's still a long road.
Cheers, Matthew Brush
Thanks for your input.
Sorry to be such a downer, I just really hate seeing this vicious circle of adding more and more code ontop of other code that needs to be refactored, making everything all intertwined and hard to hack on.
Well, it needn't get worse that status quo. See it as part of incremental cleanup. Why are you so pessimistic about that?
It truly isn't worse than the status quo, I just debate that the status quo needs to continue forever.
Cheers, Matthew Brush
Am 11.10.2013 12:07, schrieb Matthew Brush:
On 13-10-11 02:23 AM, Thomas Martitz wrote:
Am 11.10.2013 07:01, schrieb Matthew Brush:
notebooks". 99% of the now hardcoded places will work fine, e.g. I'm using gtk_widget_get_parent(sci) to get a doc's notebook and implement a foreach_notebook() macro. So this should make it really trivial to support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla will be packed directly into a notebook. Plugins can easily break this assumption by reparenting the Scintilla widget, and even my document-messages branch moved each Scintilla into a VBox inside each tab so it could pack a GtkInfo bar above it. I think we could get rid of this assumption by designing the code better.
Okay, I have written a function that walks the tree to find the parent notebook. So this assumption is no more. Thanks for the hint.
You don't need to walk any tree's, if you need to notebook from the scintilla, just store a pointer to the notebook in the scintilla, ex. using g_object_set_data() or more painfully by subclassing it.
That pointer needs to be updated properly when the doc is moved. I rather save that and walk the tree, it's cheap enough. (g_object_get_data() is a hash-table lookup which isn't exactly free either)
Please don't write another foreach_ macro. Lets make it so we can use normal C code. If you need a macro like foreach_notebook() it's probably because the code it's hiding is crappy underlying code, IMO.
I like foreach_*, and many other people do. I guess it's subjective. Plus it will make the transition from "main and secondary notebook" to "array of N notebooks" easier.
What's the problem with just using C code?
for (size_t i=0; i < notebooks_arr->len; i++) { // just normally use elements in the GPtrArray (as example) }
Such macros not only make for weird APIs but also do weird stuff with arguments since it's just textual replacements.
There is no "notebooks_arr" in the current code. Instead there is a macro which makes it easy to transition to such an array later on.
Seriously, if foreach_* macros are so frowned upon, why is Geany still full of them? I'm literally just following existing Geany-style with that macro.
I personally like these macros, they are easy to understand and nicely short. I've also seen them used in other projects.
The notebook of a doc can be retrieved via - 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?
Sorry, I think this item is out of scope for this work. FWIW, I don't quite understand the deal about GeanyEditor either.
It's not out of scope, but it is way more work than I think you're personally prepared to do. It's basically the reason no one fixed the split window before or worked to moving it into core, because it was too much work with the current way it's coded. If this kind of stuff gets cleaned up first, the split window thing becomes trivial (as well as multi-window, etc). I would've fixed up split window myself 10x by now if I didn't morally have to cleanup all this code to do it correctly.
See, if you make this kind of cleanup a hard requirement that no progress is going to happen, for the reasons you mention. Can't we just progress with managable portions of cleanups/workload, considering our already heavily limited developer manpower?
Yep, that's why my previous message, I'll try not to interfere here too much since no one is interested in the type of stuff I'm talking about probably (cleanup up the code en masse).
I would still love to collaborate with you and other devs, even if I'm not going to make the uncertain (for me, anyway) big cleanup personally.
The cleanup you propose would be impossible for me to do anyway, because I have no vision how the end result would look like. Without such a vision I wouldn't know where to start and where to end. As I said, I don't know about the GeanyEditor deal but I don't have a problem with it either. And splitwindow can be done with the current structures. So I maintain that your proposal is out of scope for my work. The same goes for your other cleanup proposals.
The patterns and paradigms used in IDE software and editors are not new, we aren't paving new ground here, usually we're just fighting it by not using the tools at our disposal for artificial reasons (totally off-topic).
Loose statement, see below.
- 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.
Also unrelated. I agree that big API breakage should be as rare and concentrated as possible (i.e. within a single release) but not as part of a single change. Let's not blow this splitwindow work up with unrelated changes. This would just make review impossible and cost more time to get done.
The fact that it "blows up" into more work is exactly why we should bite bullet instead of keep "just making it work with minimal changes", when the code is factored well, making changes becomes easier. But I digress somewhat (as usual).
I withdraw my request to help out with this because I don't think you're interested in doing some of the bigger underlying changes I was interested in doing before attempting to fixup split window, and I don't want to drag you down. As long as you keep in mind the stuff mentioned, and don't make any additional same type of assumptions that were made and evolved previously, I think it won't be such a big deal to do the stuff I was talking about underneath your changes as a separate initiative later on.
Right, I'm not interested in doing the bigger cleanups. For three reasons: (a) my time is limited and I want to get splitwindow done more than anything else (w.r.t. to Geany) currently. (b) unlike you I have no vision how the cleanup should look like. (c) I have no problem with the current code base (yet).
(a) yep, just throw another patch on it, it's not going to much change situation and it at least adds a highly desirable feature.
(b) I usually just study how other IDEs and editors work and are coded. As mentioned, this is not new territory, we have footprints to follow.
That's a very loose statement. Just saying "like the other IDEs" doesn't give me a vision. I haven't looked at their code so I can't say in what way their code is better than Geany's. You have probably more experience you worked on Mousepad (although not an IDE) and perhaps others? And I'm not going to see what others do just for the sake of change.
(c) A lot of it is intertangled and is the result of starting with no design and then tacking on another feature, and another feature and so on. Don't get me wrong, it works very well, but anytime you go to make any non-trivial change to the source you end up opening a whole can of worms or just patching on another hack because you don't have a week to refactor the code, I'm as guilty as anyone...
Most code bases are like this. I've seen worse.
Best regards.
On 13-10-11 03:29 AM, Thomas Martitz wrote:
Am 11.10.2013 12:07, schrieb Matthew Brush:
On 13-10-11 02:23 AM, Thomas Martitz wrote:
Am 11.10.2013 07:01, schrieb Matthew Brush:
notebooks". 99% of the now hardcoded places will work fine, e.g. I'm using gtk_widget_get_parent(sci) to get a doc's notebook and implement a foreach_notebook() macro. So this should make it really trivial to support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla will be packed directly into a notebook. Plugins can easily break this assumption by reparenting the Scintilla widget, and even my document-messages branch moved each Scintilla into a VBox inside each tab so it could pack a GtkInfo bar above it. I think we could get rid of this assumption by designing the code better.
Okay, I have written a function that walks the tree to find the parent notebook. So this assumption is no more. Thanks for the hint.
You don't need to walk any tree's, if you need to notebook from the scintilla, just store a pointer to the notebook in the scintilla, ex. using g_object_set_data() or more painfully by subclassing it.
That pointer needs to be updated properly when the doc is moved. I
Yep, but it's one single place this could happen.
rather save that and walk the tree, it's cheap enough. (g_object_get_data() is a hash-table lookup which isn't exactly free either)
O(1) is pretty OK to me :)
I actually don't think they use hash table for GObject data lists though, rather it's probably some type of binary tree or such but it's still relatively cheap lookup.
Please don't write another foreach_ macro. Lets make it so we can use normal C code. If you need a macro like foreach_notebook() it's probably because the code it's hiding is crappy underlying code, IMO.
I like foreach_*, and many other people do. I guess it's subjective. Plus it will make the transition from "main and secondary notebook" to "array of N notebooks" easier.
What's the problem with just using C code?
for (size_t i=0; i < notebooks_arr->len; i++) { // just normally use elements in the GPtrArray (as example) }
Such macros not only make for weird APIs but also do weird stuff with arguments since it's just textual replacements.
There is no "notebooks_arr" in the current code. Instead there is a macro which makes it easy to transition to such an array later on.
? I mean to just literally use a real GPtrArray of notebooks, instead of just toggling between a fixed two of these containers.
Seriously, if foreach_* macros are so frowned upon, why is Geany still full of them? I'm literally just following existing Geany-style with that macro.
I personally like these macros, they are easy to understand and nicely short. I've also seen them used in other projects.
I don't doubt it, but what really does it gain over just putting the literal C code? If you are repeating it so much, refactor your code, otherwise, it's just normal part of C. Mutilating C with the preprocessor quite often does not improve the clarity of usability of code.
The notebook of a doc can be retrieved via - 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?
Sorry, I think this item is out of scope for this work. FWIW, I don't quite understand the deal about GeanyEditor either.
It's not out of scope, but it is way more work than I think you're personally prepared to do. It's basically the reason no one fixed the split window before or worked to moving it into core, because it was too much work with the current way it's coded. If this kind of stuff gets cleaned up first, the split window thing becomes trivial (as well as multi-window, etc). I would've fixed up split window myself 10x by now if I didn't morally have to cleanup all this code to do it correctly.
See, if you make this kind of cleanup a hard requirement that no progress is going to happen, for the reasons you mention. Can't we just progress with managable portions of cleanups/workload, considering our already heavily limited developer manpower?
Yep, that's why my previous message, I'll try not to interfere here too much since no one is interested in the type of stuff I'm talking about probably (cleanup up the code en masse).
I would still love to collaborate with you and other devs, even if I'm not going to make the uncertain (for me, anyway) big cleanup personally.
Yeah, the big cleanup is more of a pipe/future dream for me I guess, so I'll just contribute and help out normally rather than get too involved because I've tried to tackle this myself before using the big cleanup approach, and decided it wasn't worth the effort.
The cleanup you propose would be impossible for me to do anyway, because I have no vision how the end result would look like. Without such a vision I wouldn't know where to start and where to end. As I said, I don't know about the GeanyEditor deal but I don't have a problem with it either. And splitwindow can be done with the current structures. So I maintain that your proposal is out of scope for my work. The same goes for your other cleanup proposals.
The patterns and paradigms used in IDE software and editors are not new, we aren't paving new ground here, usually we're just fighting it by not using the tools at our disposal for artificial reasons (totally off-topic).
Loose statement, see below.
- 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.
Also unrelated. I agree that big API breakage should be as rare and concentrated as possible (i.e. within a single release) but not as part of a single change. Let's not blow this splitwindow work up with unrelated changes. This would just make review impossible and cost more time to get done.
The fact that it "blows up" into more work is exactly why we should bite bullet instead of keep "just making it work with minimal changes", when the code is factored well, making changes becomes easier. But I digress somewhat (as usual).
I withdraw my request to help out with this because I don't think you're interested in doing some of the bigger underlying changes I was interested in doing before attempting to fixup split window, and I don't want to drag you down. As long as you keep in mind the stuff mentioned, and don't make any additional same type of assumptions that were made and evolved previously, I think it won't be such a big deal to do the stuff I was talking about underneath your changes as a separate initiative later on.
Right, I'm not interested in doing the bigger cleanups. For three reasons: (a) my time is limited and I want to get splitwindow done more than anything else (w.r.t. to Geany) currently. (b) unlike you I have no vision how the cleanup should look like. (c) I have no problem with the current code base (yet).
(a) yep, just throw another patch on it, it's not going to much change situation and it at least adds a highly desirable feature.
(b) I usually just study how other IDEs and editors work and are coded. As mentioned, this is not new territory, we have footprints to follow.
That's a very loose statement. Just saying "like the other IDEs" doesn't give me a vision. I haven't looked at their code so I can't say in what way their code is better than Geany's. You have probably more experience you worked on Mousepad (although not an IDE) and perhaps others? And I'm not going to see what others do just for the sake of change.
I just mean that the study of such applications is not new, like some canonical texts such as http://en.wikipedia.org/wiki/Design_Patterns, specifically 2.1.
We also have all of those that came before, like borland, ms, anjuta, vim, emacs, eclipse, gedit, mousepad, netbeans, qtcreator, xcode, and 42.0 billion more examples, many of which we can study their source code or even overall architecture and see some good/bad ways to code stuff.
For something more concrete, maybe take Cocoa's document architecture; https://developer.apple.com/library/mac/documentation/DataManagement/Concept...
It might not be Geany-style C, but a lot these ideas are known and used elsewhere, probably even inherited from the first link. I just suggest we could copy some of them too, rather than looser ad-hoc coding :)
(c) A lot of it is intertangled and is the result of starting with no design and then tacking on another feature, and another feature and so on. Don't get me wrong, it works very well, but anytime you go to make any non-trivial change to the source you end up opening a whole can of worms or just patching on another hack because you don't have a week to refactor the code, I'm as guilty as anyone...
Most code bases are like this. I've seen worse.
No comment :)
Cheers, Matthew Brush
Am 11.10.2013 13:12, schrieb Matthew Brush:
I just mean that the study of such applications is not new, like some canonical texts such as http://en.wikipedia.org/wiki/Design_Patterns, specifically 2.1.
We also have all of those that came before, like borland, ms, anjuta, vim, emacs, eclipse, gedit, mousepad, netbeans, qtcreator, xcode, and 42.0 billion more examples, many of which we can study their source code or even overall architecture and see some good/bad ways to code stuff.
For something more concrete, maybe take Cocoa's document architecture; https://developer.apple.com/library/mac/documentation/DataManagement/Concept...
It might not be Geany-style C, but a lot these ideas are known and used elsewhere, probably even inherited from the first link. I just suggest we could copy some of them too, rather than looser ad-hoc coding :)
I think you should formulate your specific vision for Geany, perhaps on the wiki or so. It doesn't help me if you list projects or books which I could possibly look at (which I'm not gonna do because it would take ages to grasp their model and consider advantages and disadvantages) because I don't know what's so horrible about status quo. As a result I lack motivation to evaluate alternatives.
Best regards.
[...]
You don't need to walk any tree's, if you need to notebook from the
scintilla, just store a pointer to the notebook in the scintilla, ex. using g_object_set_data() or more painfully by subclassing it.
That pointer needs to be updated properly when the doc is moved. I rather save that and walk the tree, it's cheap enough. (g_object_get_data() is a hash-table lookup which isn't exactly free either)
A few pointer compares up the tree is likely to be cheaper than the hash and has the advantage that sneaky plugins that move the widgets can't forget to update the pointer, so I'd say leave it as is.
[...]
There is no "notebooks_arr" in the current code. Instead there is a macro
which makes it easy to transition to such an array later on.
Seriously, if foreach_* macros are so frowned upon, why is Geany still full of them? I'm literally just following existing Geany-style with that macro.
I personally like these macros, they are easy to understand and nicely short. I've also seen them used in other projects.
I don't like any macros, and I suspect that the use of them is one of the things on Matthews list :)
But leave it there for now, it will have to be up to the maintainer to decide when its committed, either way won't take much to change.
[...]
Yep, that's why my previous message, I'll try not to interfere here too much since no one is interested in the type of stuff I'm talking about probably (cleanup up the code en masse).
I would still love to collaborate with you and other devs, even if I'm not going to make the uncertain (for me, anyway) big cleanup personally.
Split window functionality should not depend on the "big cleanup". Matthew may have a point that it might be easier after the cleanup, but so far its simple enough. Just keep going :)
[...]
On the plugin API, its gonna break, plugins will have to know about two notebooks, so at least some new functions are needed.
But if you keep to your current arrangement of making the new functions a new name (even if its adding 2 to the end :) whilst keeping the old function, and you are careful about always adding to the end of structures, it may get away without an ABI break. That would be good because it means that old plugins will not break (clearly they won't use any of the new functionality which may hinder their usefullness, but they should not break).
Currently there is a situation where some distros have a version of Geany that does not match the versions of geany-plugins they have, and it would be good to avoid that meaning that users can't use any plugins at all.
Cheers Lex
Best regards.
______________________________**_________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel
[...]
- 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.
If this does not complicate too much, IIRC you found that Scintilla wasn't *that* automatic when the same document was displayed in two views. Also it impacts on areas like saving status, each open file can be displayed in more than one location, have more than one scroll and cursor position etc. Based on your experience you and Thomas should look at how much complication it adds. If its too much maybe make it phase two.
[...]
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).
As above.
[...]
- 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.
The split in half is fine as an *initial* position, so long as it does what I tell it after that :)
@Thomas, no you shouldn't collapse the view if it has no files in it, I may be about to move another one there, don't force the user to do things in an artificial order just to keep their pane size settings.
- 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.
Yes, its a good idea, but in core it should be configurable to some sort of "Open related file(s)". But its not part of the split-window changes and should be a separate change set.
[...]
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:
Cleanups should be separate from feature additions, they should not be mixed together in the one change-set. If you need to do things like you list below to support a feature addition they should be done first as a separate git branch that can be merged without split-window.
- 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?
I think editor exists because it grew to exist, rather than there was some concious design decision based on MVC separation. Thats why it spans that particular breakup.
- 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.
The idea sounds correct, not sure just how much it takes to change it. If split-window doesn't need to change it, it isn't *that* big an issue IMHO. But anyway its not part of split-window.
- 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.
Nice idea, provided its semantics work for multiple views. Does each view get its own "untitled" or what? Anyway should be completely separate change set, its not actually part of split-windows. If it makes split-windows significantly easier, then do it first as a separate thing.
- 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.
Restrictions on the plugins should only be applied to preserve invariants that Geany actually depends on, otherwise we are just pretending we can anticipate all the uses a plugin might need. And if as you say, one plugin is already using those settings, then I guess we missed that use-case :)
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.
I would like to use it extensively, currently I often run two Geany's (with differing config dirs) but of course that has other issues like symbols updates between them and so on.
Cheers Lex
[...]
On 13-10-10 06:51 PM, Lex Trotman wrote:
[...]
- 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.
If this does not complicate too much, IIRC you found that Scintilla wasn't *that* automatic when the same document was displayed in two views. Also it impacts on areas like saving status, each open file can be displayed in more than one location, have more than one scroll and cursor position etc. Based on your experience you and Thomas should look at how much complication it adds. If its too much maybe make it phase two.
The reason no one has worked on the split window much before is exactly because the core of code evolved like you say "if this does not complicate too much" so ends up being non-modular or re-usable and has lots of built in assumptions and stuff gluing the various pieces together. Understandably, no one really wants to spend two days to refactor some code while adding a small feature that would otherwise take a few hours, but it ends up making it very hard to do stuff like split window or separate windows or future stuff we haven't thought of yet. It's like a chicken and egg situation.
[...]
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).
As above.
As above.
- 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.
Yes, its a good idea, but in core it should be configurable to some sort of "Open related file(s)". But its not part of the split-window changes and should be a separate change set.
I think Thomas is right, this could be done by plugins after the changes being discussed.
[...]
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:
Cleanups should be separate from feature additions, they should not be mixed together in the one change-set. If you need to do things like you list below to support a feature addition they should be done first as a separate git branch that can be merged without split-window.
That is *precisely* what I'm driving at, without having said it explicitly. Let's not just patch together a working solution with the bare minimum of work ontop of what exists currently (not that this is at all what is being suggested anywhere), but lets clean it up a lot first, to make stuff like split window trivial to write, just GTK+ widget code at that point. Even GtkApplication makes the multi-window thing trivial if the code is factored correctly. At some point in the future we could use that.
- 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?
I think editor exists because it grew to exist, rather than there was some concious design decision based on MVC separation. Thats why it spans that particular breakup.
I guess it is kind of a controller, but it has some other stuff mixed in which always makes me confused. It might be useful to sort this out as well, since GeanyEditor is closely intertwined with GeanyDocument and Scintilla view, which is exactly what should be cleaned up to make stuff like split view or separate windows easier to write.
- 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.
The idea sounds correct, not sure just how much it takes to change it. If split-window doesn't need to change it, it isn't *that* big an issue IMHO. But anyway its not part of split-window.
As above.
- 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.
Nice idea, provided its semantics work for multiple views. Does each view get its own "untitled" or what? Anyway should be completely separate change set, its not actually part of split-windows. If it makes split-windows significantly easier, then do it first as a separate thing.
As above. We're touching all this code anyway, lets clean it up and make it better while doing such changes. Otherwise we'll just have more stuff stacked ontop of this making it even harder to fix up and causing more big-ish breaks in the future.
- 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.
Restrictions on the plugins should only be applied to preserve invariants that Geany actually depends on, otherwise we are just pretending we can anticipate all the uses a plugin might need. And if as you say, one plugin is already using those settings, then I guess we missed that use-case :)
It goes a long way to make an API consistent though, the mismatch between document_set_text_changed() and doc->changed from an API POV is not very nice, and being able to do `doc->changed = FALSE;` in a plugin might even be dangerous, if not only make the UI inconsistent with it's backing data structure.
Also, when you have something like document_get_text_changed(), you can later re-write to ask Scintilla if it's model has unsaved changes rather than synchronizing them manually. You can also do all kinds of other interesting stuff inside the "getters", but you can't do it later if you just expose direct access to the structure's members, as I'm sure you know.
Cheers, Matthew Brush
Hi Thomas,
I havn't had a chance to use it yet, but I've looked at it, and have left a few comments on the github code. Certainly at this prototype stage its pretty simple :)
Cheers Lex
Le 10/10/2013 12:03, Thomas Martitz a écrit :
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. [...]
I don't have time yet to fully get down to the complicated discussion this went on, but I just wanted to point out I did a little refactoring of the splitwindow plugin some time ago, see https://github.com/b4n/geany/tree/splitwindow-refactoring-m
The UI isn't nice and it's why I didn't merge it yet, but it makes the split view effectively useable.
In practice, what it does is very simple: make sure whatever view you're touching it's actually always the primary Geany one, so it removes any need problem coming from Geany hardcoding some stuff.
Regards, Colomban
On 11 October 2013 21:29, Colomban Wendling lists.ban@herbesfolles.orgwrote:
Le 10/10/2013 12:03, Thomas Martitz a écrit :
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. [...]
I don't have time yet to fully get down to the complicated discussion this went on, but I just wanted to point out I did a little refactoring of the splitwindow plugin some time ago, see https://github.com/b4n/geany/tree/splitwindow-refactoring-m
The UI isn't nice and it's why I didn't merge it yet, but it makes the split view effectively useable.
In practice, what it does is very simple: make sure whatever view you're touching it's actually always the primary Geany one, so it removes any need problem coming from Geany hardcoding some stuff.
I can confirm I tried this and it worked, but I stopped using it. I hope I notified Colomban what the problem was, because I can't remember :-)
But anyway it should be considered as a short term replacement of the plugin.
Cheers Lex
Regards, Colomban _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Am 14.10.2013 21:48, schrieb Thomas Martitz:
Am 10.10.2013 12:03, schrieb Thomas Martitz:
Hello,
I have pushed a new version. It works really well so far. But of course
there's still lots of TODOs but it is already pretty usable.
I have pushed a new version. It should be almost ready to go, so may I ask you to begin reviewing the changes?
I have pushed all direct main_widgets.notebook(s) accesses to notebook.c. The rest of the code can either loop over all notebooks (foreach_notebook()) or get the current notebook (notebook_get_current()). This should make future changes to the notebooks less invasive.
Since the last version I also implemented horizontal-vertical toggle and state-save across restarts (split position and orientation is remembered via geany.conf). I also implemented automatic sizing which (IMO) works particularly nice: if only one of the notebooks has docs it is automatically maximized. If you add docs to an empty notebook the old split (as set by the user) position is restored. So you can add/remove docs as you wish without losing the split position.
New is also drag and drop improvements: you can drag docs between notebooks (if the other one has a doc you need to drag into the tab bar, unfortunately, because the ScintillaObject eats the drop action). Dropping new documents from the file browser into either notebook also works correctly.
Please give it a try and a review, I'm seeking to upstream this.
https://github.com/kugel-/geany/tree/splitwindow2
Best regards.
Am 10.10.2013 12:03, schrieb Thomas Martitz:
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.
I have come pretty far now and opened a pull request[1]. Please review and test! In my use cases it works pretty stably.
[1]: https://github.com/geany/geany/pull/185
Best regards.