Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: Charon on June 11, 2007, 09:16:08 pm
-
Hi,
i was just working a little bit on my own code and trying to find the right file in the projects-treeview. since i have a few files which names start identical i either have to have this window quite wide or have to scroll left and right in it.
i then realised that there is a bit of wasted space in the treeview!
the root-node "Workspace" shouldn't be really needed since right now its possible to only have one workspace open at the same time.
in the open files list the "problem" is a little bit different. since the title of the window is "Open files list" i think there is no need to have a node called "Opened Files".
i searched the forum for a reason why these nodes have to be there (maybe a future update will allow more than one workspace) but couldn't find any.
attached you can find a patch (when you want to call something a patch that just changes 3 lines...) which will hide the root nodes in the projects and open files list window. it does not remove the "title" of the nodes nor does it remove the icons (yeah both are invisible, but i guess wxWidgets still allocates memory for it). if this patch is welcomed i would be more than happy to remove these too.
of course i made two screenshots so you can compare for yourself.
i just tried this on WinXP SP2 with wxWidgets 2.8.4. if you are concerned that this might break on linux i can test this on Ubuntu 7.04 too.
regards
Markus
[attachment deleted by admin]
-
Hi Charon,
to show the workspace name is necessary. If you collect different projects in a workspace you can save the workspace with a name e.g. ContriPlugins and this name is shown, so it contains additional information. If the name is not shown you can not distinguish between opened projects and a workspace.
To the changes of the open files list I agree, because the root item does not contain additional information.
Bye,
Mario
-
Hi mariocup,
yeah, i guess i didn't think enough about this.
something like the attached picture should be the the right thing then i guess? (it's just a mockup)
actually the same would work for the symbol-browser. the flag wxTR_HIDE_ROOT is already set in the *.xrc but it gets ignored (but it seems like this is a wxWidgets bug). setting it after the wxTreeCtrl is created doesn't work though (SetWindowStyle doesn't work on MWS, it's even documented *yay* :-( )
regards
Markus
[attachment deleted by admin]
-
hi again,
i just reworked my patch and added the name of the workspace.
man its hard to get into wxWidgets again. the last time i worked with it is a few years ago :)
could anyone be so nice and help me with the following two things?
1. the background of the wxStaticText that is used to show the name of the workspace is dark-grey and i can't get it to appear like the background behind the items on the top of the symbols-browser (light-grey)
2. of course the context-menu for the workspace (rename and so on...) doesn't work right now. any hint for an easy way to add this to the wxStaticText?
i don't know if this kind of patch is welcomed, if not just say so. atleast its an easy way for me to get a little bit familiar with the codeblocks code-base :)
regards
Markus
[attachment deleted by admin]
-
note : when right clicking on the workspace there's a menu (save, save as, rename, close). I think you will loose that with the static text.
And on the other hand you don't gain that many space by it.
Now something else, since you are experimenting in that area, what about you can right click on the workspace, or maybe even the project and have as an option 'find file', which will expand the tree and set the selection to the filename you typed in, providing that file is in the project.
-
hi killerbot,
yeah i know its not that much space, but its at least a little bit more and in my opinion it looks more right with the hidden root item.
apart from the uselfullness of this : any idea why the background of it is dark-grey?
concerning the "find file" :
öhm, finished! :D
you can right-click on a node and select "Find file...". a window will appear that asks for the filename.
if the file is found it will get selected (but not opened), else a message is shown that it couldn't be found.
right now its my complete patch. if you think the part concerning the "find file" is ok i will gladly clean it up so my experiment for the hidden root folder isn't included.
regards
Markus
[attachment deleted by admin]
-
very well done.
Ok, I would start with integrating the find file. I see you made it for now on the project level.
I am not so sure about removing the workspace node, because you loose the menu attached to it (the menu where we could add also the find file ...)
So could you attach a cleaned up patch with just the find file. I will merge that in our code base then. Once again, very well done :-)
-
Hi !
That's nice :)
It may be more complex but what I'd prefer is something like in Eclipse (don't misunderstand !! I prefer C::B :D), a text control just below the tree that filters it automatically to show just tree items matching the entered text.
Dje
-
@killerbot:
thanks for your kind words!
i cleaned up the patch so that it only contains the "find files" and of course it already supports workspaces, projects, folder and virtual folders :)
the only type of folder that i couldn't get to work is the one automatically created when using "Categorize by file types" (i.e. "Sources" and "Headers").
i didn't plan to submit my other patch (for removing the workspace node) for review until it works like it should (with the right-click menu).
it was just meant to find out if there is interest in something like this and if somebody can help me with my 2 problems with it. of course it makes only sense if the right-click menu works!
@dje:
nice idea, but i am not good enough yet with wxWidgets and Code::Blocks itself to start on something like this :)
PS.: while creating this patch i almost pulled out all my hair. when i was doing my final test i found out i couldn't select "Categorize by file types" and "Display folders as on disk" anymore. i searched all my added code for mistakes but found none. then i compared my working version with the version in svn in the case i accidently deleted something. nothing.
then it dawned on me. i was still using wxWidgets 2.8.3. upgraded to 2.8.4 and voila, the bug was gone!
[attachment deleted by admin]
-
nice idea, but i am not good enough yet with wxWidgets and Code::Blocks itself to start on something like this :)
Unless you don't know you are :wink:
Dje
-
then it dawned on me. i was still using wxWidgets 2.8.3. upgraded to 2.8.4 and voila, the bug was gone!
There is still something wrong though. I'm running 2.8.4 and I still have this problem.
The check marks on the menu items will not UNCHECK, nor will the tree display change.
-
I already applied the patch [modified it a bit for const correctness] before your cleaned up version ;-)
About the tree with the workspace being removed, I think there's less interest though.
-
Hi,
as in the symbol view and the codesnippets view there is a search field, I would prefer the same implementation/mechanism for selecting files in the project view.
Furthermore I think that a browser view of the filesystem with a search field perhaps with a file extension filter *.cpp would be very nice for developers.
Bye,
Mario
-
it's a pity, if i had known this i wouldn't have to clean it up :-(
at least i learned a little bit of the svn command line client this way!
thanks anyway! i guess i am little bit proud now for my first included patch ^^
but please enlighten me, what did you change for const-correctness? apart from coding-style changes the only real change i can see is the removal of a variable i forgot to delete.
regards
Markus
PS.: deep inside i stll hope for the workspace-node to vanish ;-)
-
example : FindItem method doesn't change anything to the state of the object --> therefor it is a const method.
-
Hi,
Furthermore I think that a browser view of the filesystem with a search field perhaps with a file extension filter *.cpp would be very nice for developers.
Bye,
Mario
mario: download the latest svn of my interpreted languages plugin (http://developer.berlios.de/svn/?group_id=7745) and try out the "File Explorer" (it's a tab in the management pane). The file explorer contains a tree, a combo box to let you specify the root directory of the tree and a wildcard mask (files are restricted to those that match the semi-colon separated list of wildcards). It also integrates with the intepreter actions and I'm in the process of adding normal file explorer commands like mkdir, new file, copy, move, delete, find, grep etc. I'd be happy to work with some of you to get this into C::B proper...
-
PS.: deep inside i stll hope for the workspace-node to vanish ;-)
how about changing the workspace node to a combo box above the tree that lets you choose among your recent workspaces? (that way you will at least save some horizontal space)
-
because i have to work with a file-locking (read only flag) version control system at work,
i always wished, that i could see the read-only state of the opened files by their icons.
now i got a few hours time to implement this feature
maybe anyone is willing to test it (especially with linux)
and share his opinion about
edit:
updated patchfile versus svn rev 4197
[attachment deleted by admin]
-
wow, nice :)
-
because i have to work with a file-locking (read only flag) version control system at work,
i always wished, that i could see the read-only state of the opened files by their icons.
I don't get it: I had that already implemented some time ago...?! :shock:
Isn't that working anymore?!
With regards, Morten.
Edit: Damn && Sorry - I didn't fully read. You did that for *files*. What I did was for project files and workspace files, only. So It's complete now I'd say - nice! :-)
-
I don't get it: I had that already implemented some time ago...?! :shock:
Isn't that working anymore?!
With regards, Morten.
hmmm :shock:
the last svn revisions didn't have this feature.
maybe your changes never got into svn ? (like many others too ... )
-
the last svn revisions didn't have this feature.
Nope - my fault (see "Edit" in the other message. ;-)).
-
the last svn revisions didn't have this feature.
Nope - my fault (see "Edit" in the other message. ;-)).
OK all clear now!
thx, tiwag
-
OK all clear now!
Compiling now with your patch applied - looking forward to it. :-)
BTW: I realised there is quite often the same code in the patch. Isn't it better to make a method out of it then?!
With regards, Morten.
-
OK all clear now!
Compiling now with your patch applied - looking forward to it. :-)
BTW: I realised there is quite often the same code in the patch. Isn't it better to make a method out of it then?!
With regards, Morten.
yes of course ... ( and this rule applies also to most of the already existing code :) )
-
can anyone who uses linux please test the proof of concept code
and report if it works with (which) or without problems ?
if there are no objections i would work further on this and commit to svn.
thanks, tiwag
-
here is the latest patchfile (vs. svn rev 4207) with a code cleanup as suggested
also the find, find next/previous commands are modified,
so that the search results are centered on screen (if possible)
and the shown code on the screen will be unfolded.
the code is well tested and ready to commit, if these features are welcome ... ?
brgds, tiwag
[attachment deleted by admin]
-
here is the latest patchfile (vs. svn rev 4207) with a code cleanup as suggested
also the find, find next/previous commands are modified,
so that the search results are centered on screen (if possible)
and the shown code on the screen will be unfolded.
the code is well tested and ready to commit, if these features are welcome ... ?
brgds, tiwag
Looks ok to me.
-
the code is well tested and ready to commit, if these features are welcome ... ?
Worked with it for some days now under Windows (no experience with other platforms though). Looks good to me, too. Nicely done. :-)
With regards, Morten.
-
thanks for testing and commenting, i've commited the changes.
btw. i found, that proper unfolding of code is necessary also when
jumping to folded code with bookmarks. i'll have a look at it the next days ...
-
btw. i found, that proper unfolding of code is necessary also when
jumping to folded code with bookmarks. i'll have a look at it the next days ...
There are couple of problems related to folding/unfolding. I made some changes to it couple of months back. If you need any help, please feel free to contact me. :)
-
btw. i found, that proper unfolding of code is necessary also when
jumping to folded code with bookmarks. i'll have a look at it the next days ...
There are couple of problems related to folding/unfolding. I made some changes to it couple of months back. If you need any help, please feel free to contact me. :)
i've started another thread regarding problems with folding / unfolding
please post there
http://forums.codeblocks.org/index.php/topic,6345.0.html
thanks,
brgds, tiwag