Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

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

<< < (2/3) > >>

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? :P

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:


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

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 :P
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:

--- Quote ---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.
--- End quote ---

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).


--- Quote ---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.
--- End quote ---

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:

--- Quote from: mandrav on November 09, 2005, 08:52:22 am ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page