Re: Minor suggestions for the build plugin
Kåre Särs <[email protected]> Sat, 10 Feb 2024 12:41:19 +0200
| Newsgroups | gmane.comp.kde.devel.kwrite |
|---|---|
| Message-ID | <4870585.GXAFRqVoOG@sars-xps-13-9370> |
Sorry for the late response... On söndag 4 februari 2024 01:41:46 EET [email protected] 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