[prev in list] [next in list] [prev in thread] [next in thread]
List: kwrite-devel
Subject: Re: Review Request 113403: Automatically loading git repostiories as projects
From: "Dominik Haumann" <dhaumann () kde ! org>
Date: 2014-02-11 15:39:30
Message-ID: 20140211153930.26497.39909 () probe ! kde ! org
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On Jan. 19, 2014, 5:31 p.m., Alexander Neundorf wrote:
> > I'm not sure I like that.
> >
> > When using an out-of-source .kateproject file, as you will be doing if you are \
> > using cmake to generate the .kateproject files, you will have two projects for \
> > the same files open: once the .kateproject file generated by cmake, and once the \
> > autogenerated project (without .kateproject file). Maybe you can change it so \
> > that an empty .kateproject file is at least necessary ?
>
> Christoph Cullmann wrote:
> Yeah, guess not that good idea in that light.
> Perhaps what would be more nice would be a default that an empty .kateproject would \
> try to detect if .git/.svn/.hg and use the files out of it automatically.
> Rafał Rzepecki wrote:
> Actually what I wanted to accomplish was being able to use the Project plugin in \
> any repo without littering the upstream with kate-specific files, as the default \
> repo scan is very useful on it's own. This is important when you work on a project \
> that is not KDE-centric; I've been using this patch for a while now and I simply \
> love how I can open any old file and have the full repository shown in the project \
> tree and in the project tools.
> Perhaps this could be made a configurable option? Or, if the .kateproject \
> generation is the only issue, another option would be to simply watch for this file \
> and use it if it pops up (either with inotify or by checking on manual refresh). \
> Would that be acceptable?
> Alexander Neundorf wrote:
> You could put .kateproject into .gitignore etc.. Would that help ?
>
> Or, as a small step, you could extend it so that if "files" is missing it will \
> detect/git/svn/hg automatically ?
> You can put such a .kateproject file anywhere (e.g. in your build tree), and it \
> will work:
> {
> "name": "TheName",
> "directory": "/the/source/base/dir",
> "files": [ { "git": 1 } ]
> }
>
> .. or have it generated by cmake master (which will become 3.0).
>
>
> Rafał Rzepecki wrote:
> Well, the whole motivation of this patch was to dispose of the step of creating \
> '.kateproject' file. It's a repetitive task I had to do every time I cloned a \
> project and more often than not I found myself not bothering and only doing it when \
> the annoyance of not having the project tools (and having to work with the \
> filesystem browser instead) reached a certain threshold.
> Note I'm usually working with ruby projects these days, so there's not a separate \
> build tree nor a cmake to generate anything; I believe that's the case for most of \
> the interpreted languages.
> Out of curiosity, what's the utility of having a kateproject file in a build \
> directory? The files you open are usually in the source directory anyway, right? \
> This is not the workflow I'm very familiar with, so if you'd explain perhaps I'll \
> better understand how to make both work.
> Dominik Haumann wrote:
> I like the idea of the patch and think it makes a lot of sense. @Alex: can we find \
> a compromise that both works, i.e., the automatically loaded project does not get \
> in the way of e.g. the cmake generated one in the build folder?
> @Alex: What is your workflow of opening a .kateproject in the build folder? I \
> usually never open files in the build folder, that's why I wonder.
> Alexander Neundorf wrote:
> Dominik: run cmake in the buildtree. It will generate a special dummy file, called \
> <NameOfTheProject>.kateproject. Open that in kate. This triggers searching the \
> .kateproject file, which is in the same (build) directory, and which contains the \
> pointer to the source dir. So the project plugin then uses the source dir as base \
> dir, finds all the files from VCS, make commands, etc.
> Alexander Neundorf wrote:
> Rafal: ah, scripting languages, yes.
>
> So how about an empty .kateproject, so a simple "touch .kateproject" will do ?
> As long as you don't add it to git or svn, it shouldn't create cause any issues \
> with version control.
>
> Rafał Rzepecki wrote:
> Ah, so the utility of having a kateproject in the build folder is so that the make \
> commands are set up in there? That makes sense. Correct me if I'm wrong, but I'm \
> still trying to grok your workflow: there is no .kateproject file in the source \
> directory itself, and that's why you don't like this solution — because it will \
> cause duplicate projects (one auto-generated repo-based and another cmake-generated \
> build-dir-based) to show for the same source tree, with one being inherently less \
> useful b/c of lack of build commands set up.
> This can be solved by trying to compare the trees of opened projects and discarding \
> any autogenerated ones that overlap. This is a bit of work, but I can put some \
> effort into this if that's indeed a common case.
> About touching an empty .kateproject: that would scratch my itch a bit, but then \
> again so does keeping my own patch on. By having this feature merged I aimed for \
> higher discoverability of this immensely useful feature that's scarcely documented; \
> indeed I only discovered that the project addon does repository scanning after I \
> started writing my own addon to do that. By automatically opening any old repo as a \
> project a user could discover this functionality by accident, with a bonus "wow, \
> that's sweet" moment, which I believe to be an extremely gratifying experience.
> Alexander Neundorf wrote:
> Yes, you understand correctly.
>
> I also understand the "wow, that's sweet" moment.
>
> I just don't want them to overlap. The idea with discarding the autogenerated ones \
> sounds doable, but a bit fragile.
> How about adding an action or button in the project overview widget (with the \
> combobox at the top and the tree widget below) or in the "Projects" menu like "Auto \
> project", which then searches the directories upwards from the current file (if it \
> is not part of a project) until it finds a .git/.svn/.hg directory and creates the \
> automatic project ?
> Then you would just have to open some file, press the shortcut you assigned, and \
> there you have your project ?
>
> Rafał Rzepecki wrote:
> Hmm, yeah, I like this idea; though ideally there'd be also a switch to flip and \
> have it work automatically, though I won't insist.
> @Dominik, what do you think?
>
> Alexander Neundorf wrote:
> I guess this means "no objections".
>
Yes, sounds like sane and well-defined approach.
Maybe add a small QToolButton next to the reload button that opens a drop down menu \
with appropriate entries? Or what do you have in mind?
- Dominik
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/113403/#review47717
-----------------------------------------------------------
On Jan. 18, 2014, 10:34 p.m., Rafał Rzepecki wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/113403/
> -----------------------------------------------------------
>
> (Updated Jan. 18, 2014, 10:34 p.m.)
>
>
> Review request for Kate and Dominik Haumann.
>
>
> Bugs: 326415
> http://bugs.kde.org/show_bug.cgi?id=326415
>
>
> Repository: kate
>
>
> Description
> -------
>
> Kate project plugin is very useful; so much so that I've found myself creating \
> minimal "{name: foo; files: [{git: 1}]}" .kateproject files again and again. I \
> believe this is a common use case - only use the repo scanning capability without \
> other features of projects.
> To that end, the project plugin could, in absence of a .kateproject file and \
> presence of a git repository, simply load the repo as the project. The attached \
> patch implements this feature.
>
> Diffs
> -----
>
> addons/kate/project/kateproject.cpp f5557c31499c8b52bd9ab3e2f2c35aff6835a990
> addons/kate/project/kateproject.h 3aaed6780b6410b603488eb900f1d4ef38446b42
> addons/kate/project/kateprojectplugin.h 74ef10b694a2169e329b41759642a4b2e2ad259e
> addons/kate/project/kateprojectplugin.cpp a7f71e6a0c7fb60c3f437133cdc1f5c339c998d4
>
> Diff: https://git.reviewboard.kde.org/r/113403/diff/
>
>
> Testing
> -------
>
> I've been using it since I wrote it, seems to work well.
>
>
> Thanks,
>
> Rafał Rzepecki
>
>
[Attachment #5 (text/html)]
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 \
solid;"> <tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/113403/">https://git.reviewboard.kde.org/r/113403/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On January 19th, 2014, 5:31 p.m. UTC, <b>Alexander \
Neundorf</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">I'm not sure I like that.
When using an out-of-source .kateproject file, as you will be doing if you are using \
cmake to generate the .kateproject files, you will have two projects for the same \
files open: once the .kateproject file generated by cmake, and once the autogenerated \
project (without .kateproject file). Maybe you can change it so that an empty \
.kateproject file is at least necessary ? </pre>
</blockquote>
<p>On January 19th, 2014, 6:32 p.m. UTC, <b>Christoph Cullmann</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yeah, guess not that \
good idea in that light. Perhaps what would be more nice would be a default that an \
empty .kateproject would try to detect if .git/.svn/.hg and use the files out of it \
automatically.</pre> </blockquote>
<p>On January 19th, 2014, 6:42 p.m. UTC, <b>Rafał Rzepecki</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Actually what I wanted \
to accomplish was being able to use the Project plugin in any repo without littering \
the upstream with kate-specific files, as the default repo scan is very useful on \
it's own. This is important when you work on a project that is not KDE-centric; \
I've been using this patch for a while now and I simply love how I can open any \
old file and have the full repository shown in the project tree and in the project \
tools.
Perhaps this could be made a configurable option? Or, if the .kateproject generation \
is the only issue, another option would be to simply watch for this file and use it \
if it pops up (either with inotify or by checking on manual refresh). Would that be \
acceptable?</pre> </blockquote>
<p>On January 19th, 2014, 8:14 p.m. UTC, <b>Alexander Neundorf</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">You could put \
.kateproject into .gitignore etc.. Would that help ?
Or, as a small step, you could extend it so that if "files" is missing it \
will detect/git/svn/hg automatically ?
You can put such a .kateproject file anywhere (e.g. in your build tree), and it will \
work:
{
"name": "TheName",
"directory": "/the/source/base/dir",
"files": [ { "git": 1 } ]
}
.. or have it generated by cmake master (which will become 3.0).
</pre>
</blockquote>
<p>On January 20th, 2014, 1:50 a.m. UTC, <b>Rafał Rzepecki</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Well, the whole \
motivation of this patch was to dispose of the step of creating \
'.kateproject' file. It's a repetitive task I had to do every time I \
cloned a project and more often than not I found myself not bothering and only doing \
it when the annoyance of not having the project tools (and having to work with the \
filesystem browser instead) reached a certain threshold.
Note I'm usually working with ruby projects these days, so there's not a \
separate build tree nor a cmake to generate anything; I believe that's the case \
for most of the interpreted languages.
Out of curiosity, what's the utility of having a kateproject file in a build \
directory? The files you open are usually in the source directory anyway, right? This \
is not the workflow I'm very familiar with, so if you'd explain perhaps \
I'll better understand how to make both work.</pre> </blockquote>
<p>On January 20th, 2014, 11 a.m. UTC, <b>Dominik Haumann</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I like the idea of the \
patch and think it makes a lot of sense. @Alex: can we find a compromise that both \
works, i.e., the automatically loaded project does not get in the way of e.g. the \
cmake generated one in the build folder?
@Alex: What is your workflow of opening a .kateproject in the build folder? I usually \
never open files in the build folder, that's why I wonder.</pre> </blockquote>
<p>On January 20th, 2014, 9:41 p.m. UTC, <b>Alexander Neundorf</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Dominik: run cmake in \
the buildtree. It will generate a special dummy file, called \
<NameOfTheProject>.kateproject. Open that in kate. This triggers searching the \
.kateproject file, which is in the same (build) directory, and which contains the \
pointer to the source dir. So the project plugin then uses the source dir as base \
dir, finds all the files from VCS, make commands, etc.</pre> </blockquote>
<p>On January 20th, 2014, 9:44 p.m. UTC, <b>Alexander Neundorf</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Rafal: ah, scripting \
languages, yes.
So how about an empty .kateproject, so a simple "touch .kateproject" will \
do ? As long as you don't add it to git or svn, it shouldn't create cause \
any issues with version control. </pre>
</blockquote>
<p>On January 21st, 2014, 7:36 a.m. UTC, <b>Rafał Rzepecki</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Ah, so the utility of \
having a kateproject in the build folder is so that the make commands are set up in \
there? That makes sense. Correct me if I'm wrong, but I'm still trying to \
grok your workflow: there is no .kateproject file in the source directory itself, and \
that's why you don't like this solution — because it will cause duplicate \
projects (one auto-generated repo-based and another cmake-generated build-dir-based) \
to show for the same source tree, with one being inherently less useful b/c of lack \
of build commands set up.
This can be solved by trying to compare the trees of opened projects and discarding \
any autogenerated ones that overlap. This is a bit of work, but I can put some effort \
into this if that's indeed a common case.
About touching an empty .kateproject: that would scratch my itch a bit, but then \
again so does keeping my own patch on. By having this feature merged I aimed for \
higher discoverability of this immensely useful feature that's scarcely \
documented; indeed I only discovered that the project addon does repository scanning \
after I started writing my own addon to do that. By automatically opening any old \
repo as a project a user could discover this functionality by accident, with a bonus \
"wow, that's sweet" moment, which I believe to be an extremely gratifying \
experience.</pre> </blockquote>
<p>On January 22nd, 2014, 8:58 p.m. UTC, <b>Alexander Neundorf</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yes, you understand \
correctly.
I also understand the "wow, that's sweet" moment.
I just don't want them to overlap. The idea with discarding the autogenerated \
ones sounds doable, but a bit fragile.
How about adding an action or button in the project overview widget (with the \
combobox at the top and the tree widget below) or in the "Projects" menu \
like "Auto project", which then searches the directories upwards from the \
current file (if it is not part of a project) until it finds a .git/.svn/.hg \
directory and creates the automatic project ?
Then you would just have to open some file, press the shortcut you assigned, and \
there you have your project ? </pre>
</blockquote>
<p>On January 22nd, 2014, 11 p.m. UTC, <b>Rafał Rzepecki</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Hmm, yeah, I like this \
idea; though ideally there'd be also a switch to flip and have it work \
automatically, though I won't insist.
@Dominik, what do you think?</pre>
</blockquote>
<p>On January 28th, 2014, 9:19 p.m. UTC, <b>Alexander Neundorf</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I guess this means \
"no objections". </pre>
</blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Yes, sounds like sane \
and well-defined approach. Maybe add a small QToolButton next to the reload button \
that opens a drop down menu with appropriate entries? Or what do you have in \
mind?</pre> <br />
<p>- Dominik</p>
<br />
<p>On January 18th, 2014, 10:34 p.m. UTC, Rafał Rzepecki wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" \
style="background-image: \
url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); \
background-position: left top; background-repeat: repeat-x; border: 1px black \
solid;"> <tr>
<td>
<div>Review request for Kate and Dominik Haumann.</div>
<div>By Rafał Rzepecki.</div>
<p style="color: grey;"><i>Updated Jan. 18, 2014, 10:34 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="http://bugs.kde.org/show_bug.cgi?id=326415">326415</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kate
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">Kate project plugin is very useful; so much so that I've found \
myself creating minimal "{name: foo; files: [{git: 1}]}" .kateproject files \
again and again. I believe this is a common use case - only use the repo scanning \
capability without other features of projects.
To that end, the project plugin could, in absence of a .kateproject file and presence \
of a git repository, simply load the repo as the project. The attached patch \
implements this feature.</pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;">I've been using it since I wrote it, seems to work well.</pre> \
</td> </tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>addons/kate/project/kateproject.cpp <span style="color: \
grey">(f5557c31499c8b52bd9ab3e2f2c35aff6835a990)</span></li>
<li>addons/kate/project/kateproject.h <span style="color: \
grey">(3aaed6780b6410b603488eb900f1d4ef38446b42)</span></li>
<li>addons/kate/project/kateprojectplugin.h <span style="color: \
grey">(74ef10b694a2169e329b41759642a4b2e2ad259e)</span></li>
<li>addons/kate/project/kateprojectplugin.cpp <span style="color: \
grey">(a7f71e6a0c7fb60c3f437133cdc1f5c339c998d4)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/113403/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic