[Geany-Devel] Problems calling ui_update_statusbar from a plugin

Colomban Wendling lists.ban at xxxxx
Sun Nov 1 17:50:19 UTC 2015


On 31/10/2015 14:40, Abel wrote:
> I have a fix for #631 but I was trying to fix this statusbar
> inconsistency thing as well, but I think I will open a new issue for
> that and work on them separately.
> 
> On 31 October 2015 at 13:16, Thomas Martitz <kugel at rockbox.org
> <mailto:kugel at rockbox.org>> wrote:
> 
> 
>     Are you working on the existing splitwindow plugin or are you
>     creating a new one?
> 
>  
> I'm working on the existing one. I prefer to solve some quick &
> essential issues first rather than create a new one

Take a look at https://github.com/geany/geany/pull/724

>     I'm slowly working on a in-core solution, you can find it at
>     https://github.com/kugel-/geany/tree/splitwindow2?files=1
> 
> 
> Last commit is on November of former year? that's really slowly :/
> Anyway, has it been taken any *official* decision of moving on to a
> built-in feature instead of a plugin? On other words, Geany dev team, do
> you have plans of putting splitwindow into core and dropping it as plugin??

Short answer: yes.

Longer answer: I myself have low interest for the feature (read: I don't
use it, and probably wouldn't much), but the quality of the current
splitwindow plugin definitely leaves a lot to be desired.  However, we
all know and agreed that it's probably currently impossible to implement
a perfect "split window" feature as a plugin, so yes, it probably would
have to land in core anyway.  I would probably accept a version of this,
and could be reviewing it.  It however absolutely has to be
*non-intrusive* to the non-split case.

Also, IMO a replacement/large improvement should include the following
in the end:

1. Seamless integration (all features in all splits)
2. (keep) support for multiple views of the same document
3. multiple (arbitrary) splits

Point 1 is obvly the main goal of everyone who ever tried to improve the
situation.

Point 2 would IMO be important, especially to avoid changes in some
views when another changes (i.e. if I want to display document A in view
V, and I already have it in view W, I don't want view W to stop
displaying it).
On this point I'm on disagreement with others, who are happy with the
idea that documents are dispatched on the various areas, rather than
areas are views for documents; so your opinion might vary.  I also won't
strongly oppose either way, as again I probably wouldn't make much use
of the feature myself.

Point 3 would be great, but I guess less of a primary goal.


Regards,
Colomban


More information about the Devel mailing list