[Geany-Devel] splitwindow2

[Lex Trotman]

[...]

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

[...]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20131011/4ef49f88/attachment.html>