Moving HTML/RTF/ODT exporter to the "built-in"?

[rickg22]

Hey, I tested the CVS version of the source code exporter plugin. Considering it's kinda basic  (not very bulked), I was wondering if it should go to the "built-in" plugins (i.e. not as contrib) category.

What do you think, Yiannis?

(Oh, BTW, perhaps the "Export" menu items should go under a submenu called "Export...")

[mandrav]

Hey, I tested the CVS version of the source code exporter plugin. Considering it's kinda basic  (not very bulked), I was wondering if it should go to the "built-in" plugins (i.e. not as contrib) category.

What do you think, Yiannis?

The contrib plugins are those who start outside C::B's main development. Think 'contributed'. This fact alone doesn't mark them as alpha/beta/whatnot.
They 're all builtins, except SVN which is developed at berlios by Thomas.

• If you 're talking about the 'untested' category in the setup, yes it can be moved to the "Plugins" category when it's stable (already is, probably ).
• If you 're talking about adding it in the codeblocks*.cbp files, this can be done too.

(Oh, BTW, perhaps the "Export" menu items should go under a submenu called "Export...")

I agree. Initially there was one "Export to HTML" menu entry. Now that there are three entries (and probably more will follow), it makes sense to create a submenu "Export".

[takeshimiya]

True, I'm thinking about a menu like this:

&File
    &Export
        As &HTML...
        As &RTF...
        As &ODT...

[rickg22]

Exactly

[Ceniza]

I've been really busy these days but as far as I get some time I'll make the menu change.

Anyway, nice too see you're noticing the plugin

[Ceniza]

<rickg22> Yiannis: What you think about...?
<mandrav> Yeah, no problem. Do it.
... 3 years later ...
<mandrav> rick: You didn't..., right?
<rickg22> Hmmm... right.
... 3 more years later ...
<mandrav> rick: You still haven't..., right?
<rickg22> Yup.

Why do I think it's not the first time I see that pattern?

Anyway, if you haven't noticed I changed the plugin so it creates a submenu and now has 4 formats: HTML, RTF, ODT and PDF.

I don't mind moving the plugin to the "built-in" plugins (just in case you were also waiting for my "approval" or something).

[rickg22]

Ehh.... um... hee hee  :lol:. Anyway what I meant is, Yiannis is the absolute authority and AFAIK he's the one indicated to do that.

Also... this is what Yiannis said:

If you 're talking about adding it in the codeblocks*.cbp files, this can be done too.

I admit it, we have a problem regarding WHO is supposed to do "this". I always assume it's Yiannis who'll do it, unless he explicitly tells me otherwise. Maybe i'm too stupid interpreting words... *ahem*

Anyway. I'm having a second thought. If we start adding plugins to the main distribution, soon the project file will be gigantic, it's already 100K long.

[takeshimiya]

I don't know, maybe its better to leave as a plugin.

The advantage of being a plugin is that if I want to add another export format I'll don't have to deal with C::B main code. In fact, I'll only need the SDK for doing a change, not the entire C::B sourcecode.

I think it's easier to make a change (ie. patch) for a plugin.


Keeping almost all as a plugin is very welcomed these days in the IDEs.
One of the major claims in advantage of the Eclipse guys is that the IDE is very extensive through plugins, every language supported is a different plugin.

There are advantages in merging a plugin in the main code, but for the type of plugins that tries to "fix" something from the C::B main code, like the FileTabMenu plugin.


EDIT: I've obviously misread the post
Regarding including it in the built-in plugins, I'm not sure, but whatever plugin the core-devs aren't going to mantain it, it's better to have in the contribs then.

The disvantage of the contrib plugins is that they maybe will not be compiled and included by some of the linux package mantainers in their C::B packages.

[mandrav]

Regarding including it in the built-in plugins, I'm not sure, but whatever plugin the core-devs aren't going to mantain it, it's better to have in the contribs then.

That's the point. The fact that it's not in the codeblocks.cbp file is no problem. As you saw with RC2, all contrib plugins are distributed with the setup file (even the not-so-stable plugins).

The disvantage of the contrib plugins is that they maybe will not be compiled and included by some of the linux package mantainers in their C::B packages.

I admit that I didn't try to build this specific plugin under linux. I was left with the impression it's only for windows. If that's not the case, my bad. I should have seen the code.
Plugins which are cross-platform will be included in the autotools build system, as is already the case with the profiler and the codestats.
Plugins that don't make sense in non-windows world (like devpak, winxpmanifest) won't make it in the build system.

[Urxae]

I admit that I didn't try to build this specific plugin under linux. I was left with the impression it's only for windows.

I was wondering what gave you that impression? HTML, RTF and ODT are pretty cross-platform formats last time I checked.
Not that I'm sure the plugin is cross-platform (never even used it on Windows ), but I don't see any reason for it to be.

[mandrav]

:oops: double sorry :oops:
(I was referring to the help plugin)

[Ceniza]

Hmmm, I haven't tested the source exporter plugin under Linux (yet) but it should compile with minor changes or maybe none. I should give it a try soon.

Now, about the help plugin... 02-Aug-05...



"context keyword searching for the word under the caret" is the only thing that will just launch the help file, but the plugin will work anyway. Haven't tested the last minor changes though.

[Ceniza]

I just compiled both the help and source exporter plugins under Linux. Even though I made a few minor changes in the source exporter plugin to make it compile with wxWidgets Unicode.

A problem I found is cbThrow(_("error")) isn't compiling because of an ambiguity, so I disabled it.

I'mn't sure if I'm missing something either in the help plugin or kubuntu 'cause it's not opening the files (I remember it worked last time I tried in Knoppix, from where the previous screenshot comes).

The exporter plugin worked fine for HTML, RTF and PDF, but ODT is causing a SIGSEGV in wxWidgets trying to create a folder using wxZipOutputStream, which works just fine under Windows. I'll just blame wxWidgets on that one.

Well, I just wanted to share the results of those tests.

[edit]
I Just changed the compilation and linking flags for the source exporter plugin and it's working without problems now for all formats.

I'll check the help plugin now...
[/edit]