Do we need so many tab pages in the message panel?

[nanyu]

now we have :

1 Code::Blocks (log)
2 Search results
3 Cccc
4 Build log
5 Build messages
6 CppCheck
7 CppCheck messages
8 Debugger
9 Debugger(Debug)
10 Thread search

We should be able to merge some items :

1 Code::Blocks (log)
2 Search results
3 Cccc
4 Build log / Build messages
5 CppCheck
6 Debugger
7 Thread search




[attachment deleted by admin]

[oBFusCATed]

Interesting idea.

Please don't attach images to the forum, because the space on the server is limited and the moderators delete attachments at random, when there is no free space.

[ptDev]

I agree, the message pane UI has become very crowded over the last few years, and many new users may feel overwhelmed.

[Jenna]

I agree, the message pane UI has become very crowded over the last few years, and many new users may feel overwhelmed.

I think a change is not so simple, even if it should be possible and looks interesting at the first look.

I'm currently working on a patch to save the order of the tabs and whether they are visible or not.
That would make the message pane more clear.

[Jenna]

I'm currently working on a patch to save the order of the tabs and whether they are visible or not.
That would make the message pane more clear.

Here it is:
The state of tabs in message-pane is saved together with the perspective changes.
The last selected tab can also be saved, but this is configurable ("Settings -> Environment... -> View -> Save selected tab in message pane on perspective change"). It's the default behaviour, but can make the annoying-dialog that asks whether the user wants to save a perspective-change pop up much more often.

The context menu where the user can toggle the visibility shows the tabs in correct order even if they have been dragged to another place (in almost any cases).
I show loggers and non-loggers without to seperate them, because that is not really needed in my opinion.

The patch is against actual trunk (r6328).

Any feedback welcome.

[attachment deleted by admin]

[ollydbg]

Failed apply the patch on the main.cpp. (Both TortoiseSVN or command line patch.exe were failed, cc_branch, rev 6328). The main.cpp is just merged from trunk.(copy trunk to cc_branch).

Not sure why...

Edit: See the screen shot:


[attachment deleted by admin]

[MortenMacFly]

Not sure why...

Applying the patch on trunk (NOT any branch) works flawlessly using patch. The more I hear about these issues with TortoiseSVN I think you really should consider to use a different SVN client.

[ollydbg]

Applying the patch on trunk (NOT any branch) works flawlessly using patch.

Thanks for the reply.
I just do the applying against the trunk. it works flawlessly using TortoiseSVN.  So, the main reason is: it should against the trunk instead any other branches. These days, I nearly abandon the trunk, because I always used cc_branch.

The more I hear about these issues with TortoiseSVN I think you really should consider to use a different SVN client.

Thanks. I will reconsider the svn client. but seems after trying several alternatives some days ago, the TortoiseSVN I think is still the most powerful svn free ( include open source ) client under windows.

[Jenna]

The patch is against actual trunk (r6328).

I thought it was clear that it is against trunk.
Subversion takes the actual revision number of the whole repo not the one of the used branch.

[oBFusCATed]

Started testing the patch, but first I need to make it apply against the debugger branch...

One question though:
Do we need the InfoPane::num_pages constant? Isn't it better to remove it and always use page.GetCount()?

[Jenna]

We use it to make sure the range from baseID to baseID + numPages can not be used as ID by others.

So we have a range of ID's we can associate with our tabs and recalc the tab-id from the eventID.

It might be possible to do it another way.
I will look into it.

[oBFusCATed]

Yes, And this mechanism will fail if the count of pages > num_pages, which is possible at the moment.

Here is the modified patch for the debugger_branch: http://smrt.is-a-geek.org/codeblocks/patches/message_pane_order2.patch

After simple testing it seems to work...

[Jenna]

Yes, And this mechanism will fail if the count of pages > num_pages, which is possible at the moment.

Here is the modified patch for the debugger_branch: http://smrt.is-a-geek.org/codeblocks/patches/message_pane_order2.patch

After simple testing it seems to work...

I updated the patch to get rid of the num_pages constant.
Only infopane.* have changed since the first patch, so it should be easier to merge it with the debugger-branch patch.

[attachment deleted by admin]

[Jenna]

Are there any experiences (expect for this one) ?

Are there any objections against committing the patch ?

[MortenMacFly]

Are there any experiences

I've used it, too since day one, no issues here.

Are there any objections against committing the patch ?

Not from my side.