Minor suggestions for the build plugin
Kåre Särs
kare.sars at mailbox.org
Sat Feb 10 10:41:19 GMT 2024
Sorry for the late response...
On söndag 4 februari 2024 01:41:46 EET christoph at cullmann.io wrote:
> On 2024-02-03 19:22, Alexander Neundorf wrote:
> > Hi,
>
> > I have a few small things which I'd like to change in the build plugin:
> Hi,
>
> > When making the filter text for the targets shorter (e.g. after
> > selecting and
> > building a target, and then clearing the edit line), the treeview jumps
> > to the
> > beginning of the list of the targets. Although the previously selected
> > target
> > is still selected, this is not visible. I have to scroll down manually
> > to see
> > whether it is still selected.
> > I would much prefer if the selected target would stay visible.
> > This is a one-liner in the lambda connected to
> > targetFilterEdit::textChanged(), I would simply add a
> > scrollTo(currentIndex)
> > there. Ok ?
>
> would make sense for me.
Yep, I would say not scrolling to the selected item is almost a bug...
>
> > If I double click a target which comes from the project plugin, I can
> > still
> > edit it. I think this doesn't make sense, since the change will be
> > overriden
> > the next time the project plugin updates the targets. Ok to make
> > project-
> > targets non-editable ?
>
> Hmm, is editing that common? Perhaps we should always do that and allow
> to
> edit only via context menu.
Last year I actually made it possible to add and edit build commands from the
project. The edited commands are stored in a ".kateproject.build" file in the
root of the project. This was done because a lot of people do not use the
awesome sessons ;) This gives the possibility to create and/or edit build
commands and have them stored.
But these auto-generated targets are not meant to be edited so we could add a
read-only-property for them
>
> > Should non-editable targets be built when double clicking ?
> > Would feel comfortable for me. OTOH then they would behave differently
> > than the
> > other targets. What do you think ?
> >
> > I would like to be able to change the width of the columns manually. It
> > feels
> > really annoying to me when I can't do that. There are some long target
> > names
> > which make the first column very wide, while OTOH I can't see the full
> > commands
> > for them. Basically I have to pull the kate window so it covers all my
> > two
> > screens, only then the command column becomes wide enough.
> > I would much prefer if I could simply drag them manually to the width I
> > want
> > (initially they should be set to something reasonable automatically of
> > course).
> > A quick first try was not good enough, but I could invest a bit more
> > time.
> > Ok, or would you object to that ?
>
> Have no opinion on that.
I am not happy with the current situation with the column widths. there has to
be a better way :) Maybe just resize the columns when the project/session is
read and then leave the columns with manual resize.
>
> > For those small things, should I go the whole branch and merge request
> > route ?
>
> I think a merge request makes the final details better to get right.
>
Yep, PRs are nice!
/Kåre
More information about the KWrite-Devel
mailing list