Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: Ceniza on February 21, 2009, 11:18:06 pm

Title: Usability issues
Post by: Ceniza on February 21, 2009, 11:18:06 pm
I said about two weeks ago that I was planning to post a week ago something that I'm just going to post now.

The following "issues" come from my experience working with Visual Studio. The intention is not to become a clone of Visual Studio, but it is still good to see what is happening there.

Issue 1: "Unindent" (has anyone found the right word for it?)

It would be nice if pressing shift+tab removed all white space up to the previous level of indentation, or up to the last non-white space character or the beginning of the line. In other words, given the following piece of text (| signals the cursor position)

this    is    a        |test

pressing shift+tab should transform it into

this    is    a    |test

and again into

this    is    a|test

and again would do no more.

Issue 2: Automatic type deduction when debugging

This one depends on the capabilities of GDB, which I have not checked yet. The idea is as follows: suppose you have a class hierarchy, reduced in this example to Derived inherits from Base. Having a pointer to Base actually pointing to Derived should show this information. In other words, trying to watch the pointer to base should show that it's currently pointing to an instance of Derived, and allow the user to watch the internals of it know that its real type is known. In Visual Studio, for example, this information is shown in brackets, so you would see something like: [Derived].

[SVN rev. 5614]Issue 3: Code completion tooltip messing with debugger tooltip

If both tooltips are enabled, trying to see the value of a variable by hovering the pointer on it will display two tooltips, one on top of the other. In all my tests, the code completion tooltip was always on top of the debugger tooltip. Visual Studio solves this issue by completely disabling code completion's tooltip during a debugging session.


Issue 4: Auto expandable debugger tooltip

When you hover over a variable during a debugging session, a 2 columns tooltip will be shown providing the name of the variable (IIRC) and some brief information about it. On the left of this tooltip there's a + (like those of trees) that automatically expands when the mouse is on it for a few milliseconds. After expansion, another tooltip appears below the previously shown one displaying another level of information. When the variable is an object, this tooltip will show all its attributes and their values. When those attributes are objects, their value will be just some brief information about it, and a + will appear to expand them. This allows you to easily browse complex objects when debugging. Also, if you right click on a tooltip, you get a menu where you can, for example, add that level of expansion to the watched variables window.

Issue 5: Opening files with different encodings

This problem has been discussed, again, recently. Sometimes you try to open a file in CB, but all you get is an empty document. I faced this problem when trying to check the file xmltest.cpp of TinyXML. I was trying different encodings, but I could not find one that would really open the file and display its contents.

Issue 6: Set next instruction

This one has a thread of its own here. I never felt the need to use this feature because I never saw it before. When I started using Visual Studio, I found this little one quite handy in some cases. It's one of those features that have to be used with extreme care, but so are also many other features already present.

Issue 7: Send command to debugger field

I think this one was requested once a long time ago. It would be a seldom used feature, but it would also be handy to have. The debugger output window would be a good place to put it in.


Issue 8: More memory windows

Rarely used also, but having the ability to display more memory address contents during debugging would be handy. I saw up to four in Visual Studio and Delphi shows two by default.

Random thought: Filtering of opened files

A few weeks ago I came up with the idea to have some sort of new tabbed view for opened files that would allow you to do some filtering on the names of these tabs. Filtering could be, for example, all files that start with letter 'I', or all files with the sequence 'logger', all files with extension '.cpp' or even a combination of them. Logical operators could even be considered, also sorting. My first imaginary prototype looked more like an index with a text field and options

* | # | A | B | C | D | E | ... | Z | a-z | z-a | Filter: _________x

I still wonder about its usability benefits, but I wanted to comment about it anyway.

Time for you to share your thoughts.
Title: Re: Usability issues
Post by: ollydbg on February 22, 2009, 02:29:40 am
Quote
Issue 1: "Unindent" (has anyone found the right word for it?)

It would be nice if pressing shift+tab removed all white space up to the previous level of indentation, or up to the last non-white space character or the beginning of the line. In other words, given the following piece of text (| signals the cursor position)

this    is    a        |test

pressing shift+tab should transform it into

this    is    a    |test

and again into

this    is    a|test

and again would do no more.

I have been using Visual studio for many years, but I haven't use this "shift + tab" to do the deleting. :oops: , I always use 'delete' key. :D

Quote
Issue 3: Code completion tooltip messing with debugger tooltip

If both tooltips are enabled, trying to see the value of a variable by hovering the pointer on it will display two tooltips, one on top of the other. In all my tests, the code completion tooltip was always on top of the debugger tooltip. Visual Studio solves this issue by completely disabling code completion's tooltip during a debugging session.

This is really messing, These two tooltips will overlap each other. So, I do suggest disable code completion tooltips when debugging.

Quote
Issue 5: Opening files with different encodings

This problem has been discussed, again, recently. Sometimes you try to open a file in CB, but all you get is an empty document. I faced this problem when trying to check the file xmltest.cpp of TinyXML. I was trying different encodings, but I could not find one that would really open the file and display its contents.

I report this encoding problem several times. But it still exist :(.

Quote
Issue 7: Send command to debugger field

I think this one was requested once a long time ago. It would be a seldom used feature, but it would also be handy to have. The debugger output window would be a good place to put it in.
This is very important for a deep debugging.

Thanks for sharing your ideas.




Title: Re: Usability issues
Post by: ollydbg on February 22, 2009, 02:37:01 am
I have a Jump issue.

When I press "ALT + left arrow", the caret will jump to the last editing position. then, "ALT + right arrow", it will go forward.

But it doesn't jump back after I jumping with "mouse right click"->"find declaration of XXX".

So, my suggestion is:

Before each "find XXX" jump, the previous editing position will be recorded to the editor.

Thanks.
Title: Re: Usability issues
Post by: dmoore on February 22, 2009, 08:10:14 pm
Issue 5: Opening files with different encodings

This problem has been discussed, again, recently. Sometimes you try to open a file in CB, but all you get is an empty document. I faced this problem when trying to check the file xmltest.cpp of TinyXML. I was trying different encodings, but I could not find one that would really open the file and display its contents.

I can't reproduce this with xmltest.cpp downloaded from sourceforge. Can you post the file and/or encoding settings you are having trouble with. Also, what's your locale set to?
Title: Re: Usability issues
Post by: JGM on February 22, 2009, 10:58:10 pm
Many of the features here could be borrowed from gedit and notepad++. It came to my memory all the plugins that implement this things like filename filtering for gedit. Since im programming now on gedit for my CMS project  :D
Title: Re: Usability issues
Post by: smartmobili on February 23, 2009, 10:51:33 am
Let me hijack this post and add what I would like to see in CB :

A) In a file dialog when you add a library path for instance, please keep the last path because everytime you want to add a new path
you need to restart from home directory.

B) Add notion of target, for instance I am developping for Windows CE and we have different SDK so I would like to have a Combobox allowing
me to choose between those SDK (Windows Mobile, Windows Mobile 6).
From a CB point of view it means to be able to choose two different compilers and to be able to switch
from them easily.
Then those compilers settings should be save in the output project.

C) Possibility to associate compiler(s) with a project, for instance I have declared a new compiler and when I am adding a new option,
GNU GCC compiler is selected by default.
This is not what I want since I am working with another compiler so I have to select again and again my new compiler everytime.
I can see the 'Set as default option' but it seems it will set the default compiler for all projects whil I want it to be the default compiler
only for the project I am working on.



It would so great to have these features.

Title: Re: Usability issues
Post by: MortenMacFly on February 23, 2009, 03:10:54 pm
B) Add notion of target, for instance I am developping for Windows CE and we have different SDK
That's why Code::Blocks features the concept of global variables in combination with usual compiler variables.

C) Possibility to associate compiler(s) with a project, for instance I have declared a new compiler and when I am adding a new option,
...it never worked different than that.. .unless I don't understand what you mean...?!
Title: Re: Usability issues
Post by: Jenna on February 23, 2009, 03:14:15 pm
B) Add notion of target, for instance I am developping for Windows CE and we have different SDK
That's why Code::Blocks features the concept of global variables in combination with usual compiler variables.

If I understand right, it would be enough to have different build targets, with different compilers and different settings for includes, libs, defines etc.
Title: Re: Usability issues
Post by: Ceniza on February 23, 2009, 06:57:14 pm
Issue 5: Opening files with different encodings

This problem has been discussed, again, recently. Sometimes you try to open a file in CB, but all you get is an empty document. I faced this problem when trying to check the file xmltest.cpp of TinyXML. I was trying different encodings, but I could not find one that would really open the file and display its contents.

I can't reproduce this with xmltest.cpp downloaded from sourceforge. Can you post the file and/or encoding settings you are having trouble with. Also, what's your locale set to?

I tried that with Code::Blocks 5432 in a Dutch version of Windows XP Professional. Just in case, I attach the xmltest.cpp file that always opened as an empty file.

[attachment deleted by admin]
Title: Re: Usability issues
Post by: dmoore on February 23, 2009, 07:15:47 pm
Issue 5: Opening files with different encodings

This problem has been discussed, again, recently. Sometimes you try to open a file in CB, but all you get is an empty document. I faced this problem when trying to check the file xmltest.cpp of TinyXML. I was trying different encodings, but I could not find one that would really open the file and display its contents.

I can't reproduce this with xmltest.cpp downloaded from sourceforge. Can you post the file and/or encoding settings you are having trouble with. Also, what's your locale set to?

I tried that with Code::Blocks 5432 in a Dutch version of Windows XP Professional. Just in case, I attach the xmltest.cpp file that always opened as an empty file.

opens fine on my winxp box ("US english"). what are your encoding settings in settings -> editor?
Title: Re: Usability issues
Post by: Ceniza on February 23, 2009, 07:51:10 pm
Quote
opens fine on my winxp box ("US english"). what are your encoding settings in settings -> editor?

ISO 8859-something first, then UTF-8. None worked.
Title: Re: Usability issues
Post by: dmoore on February 23, 2009, 07:57:07 pm
ok, I did some more testing.

the file fails to open if:
1/ I set my fallback encoding to utf8.
2/ I set utf8, windows 1252, ISO 8859-1 or default as my default encoding.

on the other hand: with windows 1252, ISO8859-1 or default as a fallback encoding the file opens just fine.

I'm updating my working copy to see if I can get more info out of the debug log.
Title: Re: Usability issues
Post by: dmoore on February 23, 2009, 07:59:11 pm
btw, do you know what the encoding of that file actually is?
Title: Re: Usability issues
Post by: dmoore on February 23, 2009, 08:22:25 pm
using a more recent revision of C::B

1/ I set my fallback encoding to utf8.

still breaks if the "use system locale settings" is not checked (works if it is checked because it uses the fallback)

Morten's error message:
Warning: Using user specified encoding as fallback!
Encoding fallback is: Unicode 8 bit (UTF-8) (ID: 41)
Final encoding detected: Unicode 8 bit (UTF-8) (ID: 41)
Encoding conversion using settings has failed!
Encoding choosen was: Unicode 8 bit (UTF-8) (ID: 41)


Quote
2/ I set utf8, windows 1252, ISO 8859-1 or default as my default encoding.

except for utf8, this now works even without the system settings fallback. (would have to check the svn logs to see what changed)
Title: Re: Usability issues
Post by: Ceniza on February 23, 2009, 09:07:20 pm
btw, do you know what the encoding of that file actually is?

I have no idea. It opens just fine in UltraEdit, but I have not checked if it reports the detected encoding somewhere.
Title: Re: Usability issues
Post by: lexis on February 24, 2009, 11:15:29 am
SciTE reports 8-bit (means ASCII) for xmltest.cpp attached at previous post...
Title: Re: Usability issues
Post by: Jenna on February 24, 2009, 11:36:22 am
SciTE reports 8-bit (means ASCII) for xmltest.cpp attached at previous post...

As far as I know ASCII has just 7-bits, not 8. So the report is just wrong.

The file contains german umlauts and ß and can therefore not be ASCII.
Title: Re: Usability issues
Post by: lexis on February 24, 2009, 02:31:56 pm
Yes, you are right...
I mean "ASCII" as non unicode or multibyte...
8-bit equals ASCII if byte value <= 0x7F(127)
If byte value > 0x7F then character can be defined according some encoding (CP1251 or CP1252 [since I'm from Russia] or some else).
There no info about particular encoding is in the file.
Title: Re: Usability issues
Post by: ollydbg on May 29, 2009, 04:39:31 pm
@Ceniza
The Issue 3 can be solved.

See my post:

http://forums.codeblocks.org/index.php/topic,10616.msg72724.html#msg72724
Title: Re: Usability issues
Post by: oBFusCATed on May 29, 2009, 08:48:19 pm
There is more serious/annoying issue related to the tooltips (I suppose it is a known one (I think, I've reported it in the past)):

Step to reproduce:
1. Stop at break point
2. Select variable
3. Open the context menu, with the desire to use the "add watch" menu option
4. The tooltip with the current value of that variable is shown and the context menu is closed.

The "add watch" option works but I've to be very fast (I beat the tooltip 1 from 10 tries :( ) :(

Update: after little hacking of the C::B source, I've made a fix for it:

Code
Index: src/include/editorbase.h
===================================================================
--- src/include/editorbase.h    (revision 5611)
+++ src/include/editorbase.h    (working copy)
@@ -218,7 +218,7 @@
 
         /** Clear Undo- (and Changebar-) history */
         virtual void ClearHistory(){}
-       
+
         /** Goto next changed line */
         virtual void GotoNextChanged(){}
 
@@ -233,7 +233,7 @@
 
         /** Enable or disable ScrollWidthTracking */
         virtual void SetScrollWidthTracking(bool trackWidth){}
-       
+
         /** Cut selected text/object to clipboard. */
         virtual void Cut(){}
 
@@ -282,6 +282,8 @@
         /** Select everything in the editor
           */
         virtual void SelectAll() { return; }
+
+        virtual bool IsContextMenuOpened() const;
     protected:
         /** Initializes filename data.
           * @param filename The editor's filename for initialization.
Index: src/sdk/editorbase.cpp
===================================================================
--- src/sdk/editorbase.cpp      (revision 5611)
+++ src/sdk/editorbase.cpp      (working copy)
@@ -389,3 +389,8 @@
         event.Skip();
     }
 }
+
+bool EditorBase::IsContextMenuOpened() const
+{
+    return m_pData->m_DisplayingPopupMenu;
+}
Index: src/plugins/debuggergdb/debuggergdb.cpp
===================================================================
--- src/plugins/debuggergdb/debuggergdb.cpp     (revision 5611)
+++ src/plugins/debuggergdb/debuggergdb.cpp     (working copy)
@@ -2495,6 +2495,9 @@
     if (!ed)
         return;
 
+    if(ed->IsContextMenuOpened())
+        return;
+
     int style = event.GetInt();
     if (style != wxSCI_C_DEFAULT && style != wxSCI_C_OPERATOR && style != wxSCI_C_IDENTIFIER)

Any feedback is welcome ...
Best regards
Title: Re: Usability issues
Post by: ollydbg on May 30, 2009, 03:16:44 am
Yes, many overlaying issues, this is another one I encountered.
I will test your patches soon.
Edit:

Hi, I test your patch, and it works quite well, I think the devs should consider these patches. :D

By the way, I just copy you patch and created a *.patch file, but when I try to apply the patch using TortoiseSVN, it gives a "Chunk size error" message, so, I have to add to your code manually.  :(
Title: Re: Usability issues
Post by: stahta01 on May 30, 2009, 06:43:58 am
Yes, you are right...
I mean "ASCII" as non unicode or multibyte...
8-bit equals ASCII if byte value <= 0x7F(127)
If byte value > 0x7F then character can be defined according some encoding (CP1251 or CP1252 [since I'm from Russia] or some else).
There no info about particular encoding is in the file.

I suggest removing the "Legacy mode test." Lines 1087 to 1104 it looks to be the only none ASCII portion.

Tim S
Title: Re: Usability issues
Post by: killerbot on May 30, 2009, 09:20:14 am
applied the patch (rev 5612). Excellent work :-)
Title: Re: Usability issues
Post by: MortenMacFly on May 30, 2009, 09:04:07 pm
applied the patch (rev 5612). Excellent work :-)
Yepp - nice catch. ;-)
Title: Re: Usability issues
Post by: geiermeier on June 02, 2009, 09:04:38 am
Quote
Issue 7: Send command to debugger field

I think this one was requested once a long time ago. It would be a seldom used feature, but it would also be handy to have. The debugger output window would be a good place to put it in.

I second this one, too. Using the "Send user command to debugger" option is just too cumbersome. It's one of the most annoying things in CB for me.
Title: Re: Usability issues
Post by: ollydbg on June 02, 2009, 05:25:27 pm
Quote
Issue 7: Send command to debugger field

I think this one was requested once a long time ago. It would be a seldom used feature, but it would also be handy to have. The debugger output window would be a good place to put it in.

I second this one, too. Using the "Send user command to debugger" option is just too cumbersome. It's one of the most annoying things in CB for me.

As far As I can remember, this functionality has already implemented, their is a small dialog for you to enter the command directly to GDB. :D
Title: Re: Usability issues
Post by: MortenMacFly on June 02, 2009, 08:12:47 pm
As far As I can remember, this functionality has already implemented, their is a small dialog for you to enter the command directly to GDB. :D
That is correct, but if you want to send a list of commands it's annoying to open this dialog over-and-over again. That's why there should indeed be a "static" input box, e.g. in the debugger's log / whatever window.
Title: Re: Usability issues
Post by: ollydbg on June 03, 2009, 03:14:54 am
@macfly
I second the static input box inside "debugger's log panel" :D.
Title: Re: Usability issues
Post by: oBFusCATed on June 04, 2009, 01:27:13 pm
I vote for "Issue 6: Set next instruction", priceless when you get used to it (gdb implementation might not be 100% working, thought) :lol:

I want to add another annoying issue:
The tooltips steal the keyboard focus from the editor and the shortcuts are not processed anymore  :(
So I have to move the mouse to disable the debugging tooltip, while I'm stepping through the code :(

Where is the problem in wx, cb or gtk? I'm observing this problem on linux (I don't remember if it is pressent on windows)
Title: Re: Usability issues
Post by: Pecan on June 05, 2009, 02:23:41 pm
...
I want to add another annoying issue:
The tooltips steal the keyboard focus from the editor and the shortcuts are not processed anymore  :(
So I have to move the mouse to disable the debugging tooltip, while I'm stepping through the code :(

Where is the problem in wx, cb or gtk? I'm observing this problem on linux (I don't remember if it is pressent on windows)

It occurs on wndows also. but the following will stop it.

(http://img34.imageshack.us/img34/2699/debuggertt.png)

Place statement 2507(above) in the proper line for your version of debuggergdb.cpp .

The member is "void DebuggerGDB::OnValueTooltip(CodeBlocksEvent& event)"

Title: Re: Usability issues
Post by: oBFusCATed on June 05, 2009, 04:36:38 pm
Thanks, I'll try it when I get home.

Yesterday, I've tried to fix it, but I could not understand where is the problem :(
Is there something as Spy++ for wxWidgets,
a tool that can log the messages which are received by the different widgets?
Title: Re: Usability issues
Post by: oBFusCATed on June 09, 2009, 11:56:57 pm
Quote
Issue 7: Send command to debugger field

In this thread, I've posted a patch: http://forums.codeblocks.org/index.php/topic,10676.0.html

Please test, because I don't use this feature at all (but might start:) )
Title: Re: Usability issues
Post by: Ceniza on August 27, 2009, 07:53:47 pm
Mockup for Issue 4:

(http://img368.imageshack.us/img368/5756/cbdebugmockup.png)

BTW, in Visual C++ 10 Beta you can make any of those tooltips stay floating on the editor (as in "they won't disappear once you move the mouse away or click somewhere else"). Really nice way to add "visual watches".
Title: Re: Usability issues
Post by: oBFusCATed on August 27, 2009, 09:20:45 pm
Is this doable with wx?

I can do something on this ... after I finish my current work on the debugger :) ...
This feature is quite useful in vc2005.

Do you have a link to a video that demonstrates the vc10 behaviour?
Title: Re: Usability issues
Post by: MortenMacFly on August 27, 2009, 09:22:12 pm
Is this doable with wx?
Certainly. Probably a floating window that makes use of wxPropertyGrid can be used here, too.
Title: Re: Usability issues
Post by: Ceniza on August 28, 2009, 07:11:13 pm
Do you have a link to a video that demonstrates the vc10 behaviour?

I could not find a video showing that, but you could download the Beta version and give the debugger a try. I find the debugger in VC++ amazing. It has been of huge help at work. A couple of things they got right are: value tooltips allowing you to easily navigate through a variable contents just by hovering the mouse on it (it also allows you to change the value through it), data breakpoints, set next line, mixed C++ & ASM debugging (it's actually ASM debugging showing you also the C++ statements), multiple memory views, ...

IIRC, the only thing I could not find how to do (at least in VC++ 2005) is how to change the value of a register. Although it is something you seldom do, you may want to do it sometime.

On the other hand, VC++ as a text editor is not that good by default. It lacks a couple of minor things that many other simpler, and just plain, text editors have (e.g. matching braces or highlighting the current line).

As a matter of fact, most of the issues I posted here come from my experience with VC++ at work (which I mentioned already). C::B is not a rip-off of VC++, but it is still worth checking what they are doing better and considering whether or not it may be nice to add such functionality to C::B.
Title: Re: Usability issues
Post by: mariocup on August 28, 2009, 10:41:22 pm
Hi Ceniza,

mixed C++ & ASM debugging (it's actually ASM debugging showing you also the C++ statements), multiple memory views, ...

One of the most important features for embedded is in my eyes the mixed mode view: intermix ASM and C/C++ source code.

The GNU debugger provides already the information for mixed mode
Code
interpreter-exec mi "-data-disassemble -f main.cpp -l 2 -- 1"
The passing of --0 or --1 will provide information for mixed mode if it is parsed.

The only think I do not not if scintilla would be able to display such a content or it would require modifications in the core.
Title: Re: Usability issues
Post by: Ceniza on August 29, 2009, 01:26:09 pm
In case it helps to illustrate better what I am talking about, here's a screenshot of VC++ 10 for a similar test scenario:

(http://img193.imageshack.us/img193/9359/vs2010debug.png)

The visualizations in yellow are the ones that stay on top. To put them there, all one has to do is click the icon in front of the value in the visualization that appears when you place the mouse on top of the name of the variable you want to check.

To give another example, here is the way the visualization is implemented in Delphi 2010:

(http://img195.imageshack.us/img195/6729/delphi2010debug.png)
Title: Re: Usability issues
Post by: oBFusCATed on August 29, 2009, 07:44:30 pm
The yellow boxes are the new feature in vc10?

The debugger in VC is the only thing they've done right in the IDE...  :lol:
Title: Re: Usability issues
Post by: Ceniza on August 30, 2009, 08:36:41 am
The yellow boxes are the new feature in vc10?

I think so. I have not used VC2k8 myself, so maybe they were introduced there. At least VC2k5 does not have them.

They have also introduced debugging facilities for threaded programs (although I have not checked those), "spell checking" as you type (it underlines errors in red, but I did not find how to get the actual error message from it (without trying to compile)), a couple of new features for the compiler itself (we do not have to worry about it since we only work on the IDE), and, most likely, a couple more.

The debugger in VC is the only thing they've done right in the IDE...  :lol:

Yes, indeed.
Title: Re: Usability issues
Post by: Ceniza on August 30, 2009, 11:22:07 am
Hi Ceniza,

mixed C++ & ASM debugging (it's actually ASM debugging showing you also the C++ statements), multiple memory views, ...

One of the most important features for embedded is in my eyes the mixed mode view: intermix ASM and C/C++ source code.

The GNU debugger provides already the information for mixed mode
Code
interpreter-exec mi "-data-disassemble -f main.cpp -l 2 -- 1"
The passing of --0 or --1 will provide information for mixed mode if it is parsed.

The only think I do not not if scintilla would be able to display such a content or it would require modifications in the core.

I just checked the interpreter-exec mi command. I had no idea GDB had such a thing. It's just the way to go when writing a plugin that interfaces with it. It makes parsing the output a lot easier, and even more informative. Why do I think the debugger plugin does not use it?

I have the same doubt as you: would Scintilla be of any help here? What if we want syntax highlighting (there are two languages being shown)?

Anyway, it's good to know that GDB does already provide the mechanism to do it.
Title: Re: Usability issues
Post by: oBFusCATed on August 30, 2009, 12:56:20 pm
Maybe the creator of the debugger plugin didn't find the GDB/MI interface or it wasn't stable at the time.

With the MI interface the parsing is easier, but the greatest benefit is that every command can have a unique id (the output of the command had it, too),
so you can send for execution a series of commands and when they finish to process the output.