[Geany-Devel] splitwindow2

[Matthew Brush]

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/Conceptual/DocBasedAppProgrammingGuideForOSX/Introduction/Introduction.html

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