Hello there.
I took back the time to set aside some time to develop in C again, and of course fired up my trusty codeclap debugger :D (and it did helped me tremendously on some quirky parsing bugs I had.)
As I remembered the ergonomy tended to give me some friction, so I used to opportunity to be "fresh again" on codeclap to record myself using it for the first 25 minutes. Here are the notes I had :
By the way, I'm on manjaro with i3wm as a window manager. And this was launched on a fresh codeclap extraction with last version to date on itch.io (9.1)
- For me, police is blurry on launch. I have a 23" 1920x1020.
- I wanted to correct/arrange bluriness by using the custom dpi value. The slider is nice, but it can be hard to set an exact value. It would be nice to have a text field next to the slider.
That being said, the fact that the first thing on launch is the choose your dpi screen means that you know about the problem and that you did what is necessary to mitigate it until it's correct everytime.
- possibility to search (Ctrl-f) into the file. maybe the feature is there, but I didn't found it, event on the keybinding tab
on the expression window :
- possibility to display dynamic array like static array (on the screen capture, vertices.data is an array allocated with malloc and I can't found how to display it like the static array cubePosition)
-the fact that the expression we are editing is highlighted or not is not obvious. thus I often get suprised by the fact that pressing a letter erase the whole expression. I also can't get the intuition on when the expression will be highlighted or not
- Control + left/right arrow should make me move word by word. exact behavior tends to depend on editor whether or not it should stop on camelCase or not, but on "|vector.data" the cursor should advance to the dot I think (before or after) "vector.|data"
- when starting to type an expression, some autocompletion are presented below, pressing down stops the editing of expression and I have to click back on the expression I was editing. I did found an option to change this behavior, but i strongly thinks this should be the default to avoid forcing the user to take the mouse on the auto-complete window to give it focus before selecting the matching autocomplete. (but maybe I missed a better workflow)
Here are most of what i extracted for the 25 minutes footage.
Sorry to come like this with a list of requests. If the footage in itself interests you, I can put it up somewhere and give you a link to download it. I still feel very empowered by codeclap on my C programming, but I guess I always want more ^^
By the way, I found on your bug tracked that there seems to be some awesome activity already boilling. I can't wait for the next release :D
I took back the time to set aside some time to develop in C again, and of course fired up my trusty codeclap debugger :D (and it did helped me tremendously on some quirky parsing bugs I had.)
As I remembered the ergonomy tended to give me some friction, so I used to opportunity to be "fresh again" on codeclap to record myself using it for the first 25 minutes. Here are the notes I had :
By the way, I'm on manjaro with i3wm as a window manager. And this was launched on a fresh codeclap extraction with last version to date on itch.io (9.1)
- For me, police is blurry on launch. I have a 23" 1920x1020.
- I wanted to correct/arrange bluriness by using the custom dpi value. The slider is nice, but it can be hard to set an exact value. It would be nice to have a text field next to the slider.
That being said, the fact that the first thing on launch is the choose your dpi screen means that you know about the problem and that you did what is necessary to mitigate it until it's correct everytime.
- possibility to search (Ctrl-f) into the file. maybe the feature is there, but I didn't found it, event on the keybinding tab
on the expression window :
- possibility to display dynamic array like static array (on the screen capture, vertices.data is an array allocated with malloc and I can't found how to display it like the static array cubePosition)
-the fact that the expression we are editing is highlighted or not is not obvious. thus I often get suprised by the fact that pressing a letter erase the whole expression. I also can't get the intuition on when the expression will be highlighted or not
- Control + left/right arrow should make me move word by word. exact behavior tends to depend on editor whether or not it should stop on camelCase or not, but on "|vector.data" the cursor should advance to the dot I think (before or after) "vector.|data"
- when starting to type an expression, some autocompletion are presented below, pressing down stops the editing of expression and I have to click back on the expression I was editing. I did found an option to change this behavior, but i strongly thinks this should be the default to avoid forcing the user to take the mouse on the auto-complete window to give it focus before selecting the matching autocomplete. (but maybe I missed a better workflow)
Here are most of what i extracted for the 25 minutes footage.
Sorry to come like this with a list of requests. If the footage in itself interests you, I can put it up somewhere and give you a link to download it. I still feel very empowered by codeclap on my C programming, but I guess I always want more ^^
By the way, I found on your bug tracked that there seems to be some awesome activity already boilling. I can't wait for the next release :D
Edited by albatros
on
Reason: Initial post
Hi albatros,
sorry for not responding sooner. I got your mail but didn't have much time during the week. I am continuously trying to come back to UX to fix most of the more annoying "features" so your feedback is very much appreciated.
I have questions to a few of your comments. It may be easy for you to explain but it could also be easier and more helpful to see the actual problem occurring in your video (the mail address you used is fine, I have to fix a filter to not miss it for a day. But you can also just mail [email protected]).
For me it would seem that for this size and resolution you shouldn't require any kind of scaling, do you have any DPI scaling set system-wide? Linux has multiple ways of setting the DPI. Is it still blurry when selecting custom scaling with 96, what is the setting that actually looks correct to you? For what it's worth you can use the mouse wheel (while hovering the slider with the mouse) for smaller steps than can often be achieved using the mouse dragging.
This will be in the upcoming release (for source files). I will look into search functionality in assembly later.
you can display any pointer as an array with ",123" (as suffix, either with a number or a variable). i remember that in the next release there are a few fixes when combining this with other display types like ,str.
Right now i don't think there is any hint to find this, I will probably look into how to integrate this into the right click menu.
pressing any character key will always start editing for the currently highlighted (yellow background) row while deleting the content. this is the same as MSVC does it and I think it speeds up editing. You can enable editing using enter to keep the content, in 0.9.1 the small text field doesn't look pretty but the difference to the highlighted row without active editing should be obvious. At the moment double clicking (which also enabled editing) selects the whole text making deleting everything by accident easy, this will be different in the next version.
But I may be missing something here?
Better text edit capabilities will be in the next update. Text input was very rudimentary in the first release and it took some updates to improve this step by step.
this keeps me up at night,.. just joking but it is one of the specifics that I am still not quite sure of. You don't require the mouse, there is a keyboard shortcut for this "Focus autocomplete overlay" which is Tab by default. This is one of the "features" where I voluntarily stray from the "commonly accepted default" because I really dislike autocomplete suggestions stealing my enter, down or up keys (especially here since it is a table and using these keys). But the default here has to change to something else because most people are just too used to "there is a list under my text field, let me quickly press down to select some item from it". Either to the default to give the autocomplete priority or to a new way introduced in the next update (a "hint" system that only makes available one suggestion and requires a autocomplete key to use this suggestion).
To be realistic codeclap used to be even worse regarding UX and has gotten quite a way from the first releases. But there is always room for improvement, for example file navigation is still quite unintuitive by not having any kind of traditional project or file listing.
It is really nice to hear that codeclap proves useful to you even in a yet "unfinished" state and I hope this will only get better with the next few updates.
You are correct, while work on the next update got delayed a bit due to other work, features for the next update are mostly done. But there is quite an extensive list will smaller fixes, new and old regressions here and there and a set of slightly more complex tests on all platforms. I used to put smaller bugs and glitches aside for a bit but this all needs to be addressed nearing the availability of all the features I had planned for 1.0.
sorry for not responding sooner. I got your mail but didn't have much time during the week. I am continuously trying to come back to UX to fix most of the more annoying "features" so your feedback is very much appreciated.
I have questions to a few of your comments. It may be easy for you to explain but it could also be easier and more helpful to see the actual problem occurring in your video (the mail address you used is fine, I have to fix a filter to not miss it for a day. But you can also just mail [email protected]).
albatros
- For me, police is blurry on launch. I have a 23" 1920x1020.
- I wanted to correct/arrange bluriness by using the custom dpi value. The slider is nice, but it can be hard to set an exact value. It would be nice to have a text field next to the slider.
That being said, the fact that the first thing on launch is the choose your dpi screen means that you know about the problem and that you did what is necessary to mitigate it until it's correct everytime.
For me it would seem that for this size and resolution you shouldn't require any kind of scaling, do you have any DPI scaling set system-wide? Linux has multiple ways of setting the DPI. Is it still blurry when selecting custom scaling with 96, what is the setting that actually looks correct to you? For what it's worth you can use the mouse wheel (while hovering the slider with the mouse) for smaller steps than can often be achieved using the mouse dragging.
albatros
possibility to search (Ctrl-f) into the file. maybe the feature is there, but I didn't found it, event on the keybinding tab
This will be in the upcoming release (for source files). I will look into search functionality in assembly later.
albatros
possibility to display dynamic array like static array (on the screen capture, vertices.data is an array allocated with malloc and I can't found how to display it like the static array cubePosition)
you can display any pointer as an array with ",123" (as suffix, either with a number or a variable). i remember that in the next release there are a few fixes when combining this with other display types like ,str.
Right now i don't think there is any hint to find this, I will probably look into how to integrate this into the right click menu.
albatros
the fact that the expression we are editing is highlighted or not is not obvious. thus I often get suprised by the fact that pressing a letter erase the whole expression. I also can't get the intuition on when the expression will be highlighted or not
pressing any character key will always start editing for the currently highlighted (yellow background) row while deleting the content. this is the same as MSVC does it and I think it speeds up editing. You can enable editing using enter to keep the content, in 0.9.1 the small text field doesn't look pretty but the difference to the highlighted row without active editing should be obvious. At the moment double clicking (which also enabled editing) selects the whole text making deleting everything by accident easy, this will be different in the next version.
But I may be missing something here?
albatros
Control + left/right arrow should make me move word by word. exact behavior tends to depend on editor whether or not it should stop on camelCase or not, but on "|vector.data" the cursor should advance to the dot I think (before or after) "vector.|data"
Better text edit capabilities will be in the next update. Text input was very rudimentary in the first release and it took some updates to improve this step by step.
albatros
when starting to type an expression, some autocompletion are presented below, pressing down stops the editing of expression and I have to click back on the expression I was editing. I did found an option to change this behavior, but i strongly thinks this should be the default to avoid forcing the user to take the mouse on the auto-complete window to give it focus before selecting the matching autocomplete. (but maybe I missed a better workflow)
this keeps me up at night,.. just joking but it is one of the specifics that I am still not quite sure of. You don't require the mouse, there is a keyboard shortcut for this "Focus autocomplete overlay" which is Tab by default. This is one of the "features" where I voluntarily stray from the "commonly accepted default" because I really dislike autocomplete suggestions stealing my enter, down or up keys (especially here since it is a table and using these keys). But the default here has to change to something else because most people are just too used to "there is a list under my text field, let me quickly press down to select some item from it". Either to the default to give the autocomplete priority or to a new way introduced in the next update (a "hint" system that only makes available one suggestion and requires a autocomplete key to use this suggestion).
To be realistic codeclap used to be even worse regarding UX and has gotten quite a way from the first releases. But there is always room for improvement, for example file navigation is still quite unintuitive by not having any kind of traditional project or file listing.
It is really nice to hear that codeclap proves useful to you even in a yet "unfinished" state and I hope this will only get better with the next few updates.
You are correct, while work on the next update got delayed a bit due to other work, features for the next update are mostly done. But there is quite an extensive list will smaller fixes, new and old regressions here and there and a set of slightly more complex tests on all platforms. I used to put smaller bugs and glitches aside for a bit but this all needs to be addressed nearing the availability of all the features I had planned for 1.0.
Edited by spx
on
Wow, I thrilled to hear so much improvements are already on the way :D
No problem for any delay, the mail from on the mantisdb site was already little bit of a shot in the dark ^^
Regarding the dpi, and going more into details, I see that i framed the discution wrong.
The police is more blurry below and above 92, so it's the "right" one I guess. But for me it's already too blurry.
So I up the police and from 113, characters have enough meat/weight/wideness (don't know the right word for it) and the blurriness is felt as around the charactor, not as the whole character is blurry to me.
I see better now why you did it. Then maybe the auto-complete window should be one line(+half?) lower, so the field I would get to when pressing "down" stays into view. That should be enough to look fair, even for those not used to this convention. Plus, the distance to the autocomplete proposals will look less like a dropdown that I can press down to get to, and more like a popup that i can press tab change focus. (or maybe instead just more to the right. As long as the destination of the down arrow stays into view)
I'm sending you right now a link to the blind run I recorded :)
And again, many thankes for all the work you put through !
No problem for any delay, the mail from on the mantisdb site was already little bit of a shot in the dark ^^
Regarding the dpi, and going more into details, I see that i framed the discution wrong.
The police is more blurry below and above 92, so it's the "right" one I guess. But for me it's already too blurry.
So I up the police and from 113, characters have enough meat/weight/wideness (don't know the right word for it) and the blurriness is felt as around the charactor, not as the whole character is blurry to me.
spx
when starting to type an expression, some autocompletion are presented below, pressing down stops the editing of expression and I have to click back on the expression I was editing. I did found an option to change this behavior, but i strongly thinks this should be the default to avoid forcing the user to take the mouse on the auto-complete window to give it focus before selecting the matching autocomplete. (but maybe I missed a better workflow)
this keeps me up at night,.. just joking but it is one of the specifics that I am still not quite sure of. You don't require the mouse, there is a keyboard shortcut for this "Focus autocomplete overlay" which is Tab by default. This is one of the "features" where I voluntarily stray from the "commonly accepted default" because I really dislike autocomplete suggestions stealing my enter, down or up keys (especially here since it is a table and using these keys). But the default here has to change to something else because most people are just too used to "there is a list under my text field, let me quickly press down to select some item from it". Either to the default to give the autocomplete priority or to a new way introduced in the next update (a "hint" system that only makes available one suggestion and requires a autocomplete key to use this suggestion).
I see better now why you did it. Then maybe the auto-complete window should be one line(+half?) lower, so the field I would get to when pressing "down" stays into view. That should be enough to look fair, even for those not used to this convention. Plus, the distance to the autocomplete proposals will look less like a dropdown that I can press down to get to, and more like a popup that i can press tab change focus. (or maybe instead just more to the right. As long as the destination of the down arrow stays into view)
I'm sending you right now a link to the blind run I recorded :)
And again, many thankes for all the work you put through !