[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: Minor suggestions for the build plugin
From:       Kåre_Särs <kare.sars () mailbox ! org>
Date:       2024-02-10 10:41:19
Message-ID: 4870585.GXAFRqVoOG () sars-xps-13-9370
[Download RAW message or body]

Sorry for the late response...

On söndag 4 februari 2024 01:41:46 EET christoph@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



[prev in list] [next in list] [prev in thread] [next in thread]