Author Topic: The 26 December 2007 build will NOT be out.  (Read 10663 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5208
The 26 December 2007 build will NOT be out.
« on: December 26, 2007, 06:18:22 pm »
no core commits

Offline Wolf

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: The 26 December 2007 build will NOT be out.
« Reply #1 on: December 26, 2007, 09:59:46 pm »
Hello, I just got a nice widescreen LCD monitor to replace my old CRT one, so I can finally try the vertical split option in Code::Blocks. But what I noticed is that you may only split one open file. It would be nice to have a vertical (or horizontal) split on two different files, so I can work on both the class definition and implementation. I do not know where to post suggestions, so I thought the Nightly Builds forum.
Happy holidays.

-- Wolf --

Offline lubos

  • Almost regular
  • **
  • Posts: 131
Re: The 26 December 2007 build will NOT be out.
« Reply #2 on: December 27, 2007, 11:11:15 am »
i think this feature was included in one of the http://developer.berlios.de/projects/cbilplugin/ win binary builds, but it probably had some problems?

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: The 26 December 2007 build will NOT be out.
« Reply #3 on: December 27, 2007, 04:29:21 pm »
Hello, I just got a nice widescreen LCD monitor to replace my old CRT one, so I can finally try the vertical split option in Code::Blocks. But what I noticed is that you may only split one open file. It would be nice to have a vertical (or horizontal) split on two different files, so I can work on both the class definition and implementation.
This is another one of the misfeatures in Code::Blocks which I wish had never been implemented. I wouldn't expect it to work the way you want any time soon, it's not a trivial thing to do right, unluckily. Not without adding more hacks, anyway. A good implementation would require quite a few changes.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline TDragon

  • Lives here!
  • ****
  • Posts: 936
    • Twilight Dragon Media
Re: The 26 December 2007 build will NOT be out.
« Reply #4 on: December 27, 2007, 06:17:06 pm »
This is another one of the misfeatures in Code::Blocks which I wish had never been implemented.
I, conversely, am glad it was implemented. I'm currently using it extensively in fiddling with a program comprised of a single large C source file (lemon). No, not my creation and not a normal scenario, but it does happen.
http://tdm-gcc.tdragon.net/ - TDM-GCC compiler suite for Windows (GCC 5.1.0 2015-06-28, 32/64-bit, no extra DLLs)

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: The 26 December 2007 build will NOT be out.
« Reply #5 on: December 28, 2007, 01:37:59 pm »
I'm not against the feature as such, in fact I'd be most happy having 3 or 4 (preferrably different) editors open side by side (having 3360x1050 resolution, and effectively using only 1/3 of it). But what I don't like is that we are buying a very small benefit (limited feature) with a lot of complexity. Complex things are not good.

What we would need to make it a feature that I'd be glad to have is:
1. the ability to share text and state between two editors, so copies are avoided and no conflicts can occur, no ping-pong, events are processed and sent exactly once and reliably, and the user is only notified once of everything, too
2. two additional lines of code to decide whether a newly opened document shall be a "master" or a "slave"
3. use wxAUI for the editor notebooks instead of wxFlatNotebook, since wxAUI lets you drag and drop (or move programmatically) notebook pages anywhere with little or no fuzz

Now, (2.) and (3.) are easy, it's (1.) which is not trivial at all and which would require us to rethink (and rewrite) quite a lot of stuff, to be done right. But without (1.) it will only ever be a workaround/hack, and with limited features.

I think that having no feature is better than having a limited one, too. If there is no feature, people will just accept that things are the way they are. Having a limited feature, however, every single day you see that it almost works the way you want it, and that makes you feel something is not right every time.
That's the reason why I am not using split editors at all, too. If I was using them, I would of course expect that it just works, nothing else. And I would be disappointed every single time it doesn't.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Wolf

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: The 26 December 2007 build will NOT be out.
« Reply #6 on: December 29, 2007, 07:35:09 pm »
I do not know how Code::Blocks manages the "view", but I know Notepad++, which uses Scintilla too, makes it seem very simple. The views, as they are called by Notepad++, are a group of tabs, or files, where only one can be viewed. So, according to this, Code::Blocks only has one view that can be split in two smaller views (document splitting), but still on the same file. So what it needs is the ability to have multiple views.

thomas, I do not understand your concept of "master" and "slave" for documents. Do you mean that you open up two instances of Code::Blocks, one of them is the master of the others, so it has precedence and is the only one that can compile? With multiple views, you need only one instance running.

As for the ability to share text and state, whenever the file is modified outside of an editor, it asks you (or should) if you want to keep it or reload it. I noticed that in Notepad++, when you change text in a file, it changes it for all the views, that is because (I'll use GTK terms because I do not know Scintilla and wxWidgets) the TextViews all have the same TextBuffer.

As I wrote, I do not know wxWidgets, but from what you wrote, wxAUI seems to be the thing to use to support the multiple views.

Document splitting can be interesting for, at least, the reason stated by TDragon. It is also common to a lot of text-editing software. However, what I am talking about here is just above that. Having two different documents open, two different tab lists, or three or four... I do not know how long this could take to program nor if it is possible with the way Code::Blocks is programmed. It's just a suggestion like another one that can solve the problem of having many instances of Code::Blocks to edit multiple files.

I believe that having no feature means either "we are unable to implement that" or "we don't want to implement that". Having a limited feature, to me, is either "we are working on it, be patient" or "we can't work on this right now, but here's what we've done so far". I personally prefer a limited feature rather than no feature at all. I prefer a car that can't go past 40 MPH rather than no car at all. This is a "nightly build" version, so things don't have to be fully functional before they are included. If you want a fully working non-experimental stable version, use the "stable" or "release" version. What I mean is that this is an open source project, so new features, how limited they are, can be improved by everyone.

"people will just accept that things are the way they are", that sounds like corporative talk. To me, it sounds like "the people do not have a word to say, the way we do things is the way things will be"... Microsoft does that.

I, in no way, wish to be disrespectful to anyone here. I'm sorry if it sounds harsh but, after hearing these words many times in my life and seeing people abandon dreams because of that, I am irritated when I hear people saying or see them writing that. Anyways, multiple views (not document splitting) would be great, even if it is limited to two files open at once.

-- Wolf --

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: The 26 December 2007 build will NOT be out.
« Reply #7 on: December 29, 2007, 10:02:56 pm »
I do not understand your concept of "master" and "slave" for documents.
It would be trivial to open two different documents side by side, simply make two notebook controls placed in the two sides of a split pane, and add one editor to each. This could even be done with wxFlatNotebook, but wxAUINotebook would have the additional advantage that you can just grab a tab and drag it to the other side, and things just work on (which is how I'd expect it to be), and there is no fuzz, no bookkeeping to do, it just works. Only few additional modifications would be necessary.

A bigger problem arises, if two (or more) editors can optionally have the same document. In this case, you must keep track which one is the "real one" ("master") one and which one isn't. You don't want two copies of the same document modified independently, and when you save the text, it's a random outcome which one overwrites which. So, you either have define one as the "master" document, or you have to send messages between the two (three, four, ...) editors so they keep their copies and all state in sync, or you have to implement a solution to share one dataset and one context which can be accessed and atomically modified by any number of "viewers", handles loading and saving, and marshals events between the attached editors and the rest of the application, so nothing is lost, everything works the same, but nothing is done twice or ambiguous. Regarding the mere text, wxScintilla even supports something which is almost exactly what we need (although I've never tried it out), but there is plenty left to do, still.

Quote
"people will just accept that things are the way they are", that sounds like corporative talk. To me, it sounds like "the people do not have a word to say, the way we do things is the way things will be"... Microsoft does that.
To me, it sounds like you're twisting my words. I said something entirely different.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Albenejean

  • Multiple posting newcomer
  • *
  • Posts: 65
Re: The 26 December 2007 build will NOT be out.
« Reply #8 on: December 29, 2007, 10:26:39 pm »
Quote
It would be trivial to open two different documents side by side, simply make two notebook controls placed in the two sides of a split pane, and add one editor to each. This could even be done with wxFlatNotebook, but wxAUINotebook would have the additional advantage that you can just grab a tab and drag it to the other side, and things just work on (which is how I'd expect it to be), and there is no fuzz, no bookkeeping to do, it just works. Only few additional modifications would be necessary.
You should't have wrote that, because..... I want that!!!

Not now, but when you have time ....  :D :D

Quote
I believe that having no feature means either "we are unable to implement that"
It means: we have no time to implement that, and no time to take care of the maintainance (for now).

Quote
"people will just accept that things are the way they are", that sounds like corporative talk. To me, it sounds like "the people do not have a word to say, the way we do things is the way things will be"... Microsoft does that.
CB is opensource, people can have a word to say... If you have enough time and motivation to implement (correctly) that, you can do it and submit a patch.

Offline Wolf

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: The 26 December 2007 build will NOT be out.
« Reply #9 on: December 30, 2007, 06:42:52 am »
It would be trivial to open two different documents side by side, simply make two notebook controls placed in the two sides of a split pane, and add one editor to each. This could even be done with wxFlatNotebook, but wxAUINotebook would have the additional advantage that you can just grab a tab and drag it to the other side, and things just work on (which is how I'd expect it to be), and there is no fuzz, no bookkeeping to do, it just works. Only few additional modifications would be necessary.
Isn't it what Notepad++ did? =P
You can only have two "views", and I personally do not see any use to more than two for C/C++ programming, but it would be a step further if it could indeed support more than two. I never liked magic numbers, and two is a magic number in that case. =P

A bigger problem arises, if two (or more) editors can optionally have the same document. In this case, you must keep track which one is the "real one" ("master") one and which one isn't. You don't want two copies of the same document modified independently, and when you save the text, it's a random outcome which one overwrites which. So, you either have define one as the "master" document, or you have to send messages between the two (three, four, ...) editors so they keep their copies and all state in sync, or you have to implement a solution to share one dataset and one context which can be accessed and atomically modified by any number of "viewers", handles loading and saving, and marshals events between the attached editors and the rest of the application, so nothing is lost, everything works the same, but nothing is done twice or ambiguous. Regarding the mere text, wxScintilla even supports something which is almost exactly what we need (although I've never tried it out), but there is plenty left to do, still.
When you say "editors", do you mean instances of Code::Blocks or just the place where we can write? Well, nevermind, I pretty much answered my own question. The editor is where we edit the text. =P
Using GTK, a single text-buffer may be used for all the editors with the same file. That is if you modify a file in one editor, it will automatically modify it in the others, since it is the same buffer. When you save, you simply save the content of the buffer, so no need of complex master and slave stuff. But you're the project expert, I haven't took a look at the source code yet. The last thing you said about the dataset is pretty much what I'm saying, just in more accurate and complex terms.

To me, it sounds like you're twisting my words. I said something entirely different.
It's what I understood from your words. I did not say you meant that, it is my interpretation. Sorry about that, I was pissed at the time I wrote that. My laptop's HD died, so I lost a lot of data and many programming projects. Backups were done, but not for everything. And I need a new HD. I did not want to offend you, sorry. Reading it again, calm, it does sound different, and I agree with that sentence. If there is no feature, people will just not care, but if it is broken, they'll complain about it. But I still believe limited is better than none. =P

-- Wolf --

EDIT:
It means: we have no time to implement that, and no time to take care of the maintainance (for now).
Would you prefer I write: "we are unable to implement that because we do not have time to" ? =P
I can understand more important things are on the list, I personally do not have much time to work on my projects. I haven't compiled a file in about two months. Then what are you doing here Wolf? No clue, mostly staring at the screen, letting my fingers type.
Good night!
« Last Edit: December 30, 2007, 06:46:38 am by Wolf »