Review Request 115547: Bug fix : Allows further support of special character in project name

[Andreas Pakulat]

> On Feb. 8, 2014, 12:16 a.m., Sven Brauch wrote:
> > Besides the fact that your implementation is ... curious and very hard to understand, I do not think this is the correct way to solve the problem, honestly. The whole idea of percent-encoding application the project name is imo flawed. Percent signs have their own share of problems in the various places where the project name is used.
> > 
> > Instead, I think we should just have a list of allowed characters (I'd in fact go with just 0-9, a-Z and _ and disallow starting with a number, then you can use it everywhere without fear of ending up with anything broken) and check against that on the UI side, aka disallow even creating projects with names not matching that by not allowing to confirm the dialog with an invalid project name.
> > 
> > If people really want projects with names which contain plus signs, they can rename the stuff in the template themselves in my opinion.
> 
> Michael Ferris wrote:
>     I most certainly see how this code is harder to understand, I was too focus on making performant code than readable. I can very easily change that.
>     However, before I make any changes, I would like to know what we actually expect from this.
>     I understand your feeling about the percent encoding and I thought it was curious myself.
>     What I could do, as you suggested, is simply enforce the use of letters digits and underscores which I think would be best.
>     
>     Also, from what I can see the actual location of the project and its name are currently linked together.
>     What could be done is to accept all characters for the project name, but having restrictions for the location.
>
> 
> Sven Brauch wrote:
>     Performant code is very important in many places, but not here. This function is called once per day ™ for a length-20-ish input, which will take something in the microsecond range no matter how you implement it. So the focus should clearly be on readability instead of performance ;)
>     If there's a choice between two equally readable options of which one is faster, the faster one is of course preferrable, but it is not a good idea to sacrifice readability for irrelevant performance gain.
>     
>     In my opinion the fix for this issue would be to remove the whole percent encoding stuff, and go to the UI dialog itself where you enter the name, and just disable the "Next" button (and display a message in a label, the label is already there even, it displays "Empty project name" in the beginning) when the text field contains invalid characters.
>     No clever performance manevuer is required there either, e.g. using QRegExp with \w* sounds like a good plan ;)
>

I've been out of touch with this code for quite some time, but I assume the need for percent-encoding as well as allowing 'more characters' is that people can use arbitrary strings in the project name. If thats correct, I disagree with disallowing using any character for the projects name. Its a user-defined name for his project, there should not be arbitrary limitations on what he can use. Especially not for purely technical reasons that the application can fix itself.

I suggest to solve this without sacrificing readability of the filesystem directory name if the project name contains something outside the allowed character range, in particular I'd do a simple 's/[^a-zA-Z0-9_- .]/_/g'. That is replace anything which is neither a letter, number, space or simple punctuation with an underscore. And show this to the user before the project gets created so he is aware. Maybe the 'letter' and 'number' checks shouldn't be done via a regex but rather through QChar::isLetter&Co to allow non-ascii letters for people living in non-english locales. There's no reason to disallow german umlauts or french accent-characters in the filesystem these days afaik.


- Andreas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115547/#review49232
-----------------------------------------------------------


On Feb. 8, 2014, 12:04 a.m., Michael Ferris wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/115547/
> -----------------------------------------------------------
> 
> (Updated Feb. 8, 2014, 12:04 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Bugs: 282783
>     http://bugs.kde.org/show_bug.cgi?id=282783
> 
> 
> Repository: kdevplatform
> 
> 
> Description
> -------
> 
> Allows the location of the project to have more character then only digits, letters, spaces and %. Still checks for unsupported character and insert the percent encoded value.
> 
> 
> Diffs
> -----
> 
>   plugins/appwizard/projectselectionpage.cpp 6270869 
> 
> Diff: https://git.reviewboard.kde.org/r/115547/diff/
> 
> 
> Testing
> -------
> 
> Create a new project with test:<>*?/\\|!@#$%?&%2A()_+ and the location was test%3A%3C%3E%2A%3F%2F%5C%5C%7C!@#$%^&%2A()_+
> Here we can see all unsupported character have been percent encoded and the rest stayed the same.
> 
> 
> Thanks,
> 
> Michael Ferris
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20140209/82d30c81/attachment.html>