Official add-on library packs?

[PB]

Here's a request that I hope can be granted: official add-on library packs.
What do I mean? Well, we've all seen threads here where certain commands
won't be upgraded (eg. gadget coloring) or supported (eg. Windows Registry
manipulation) because they wouldn't be cross-platform. Fair enough (I guess).

So it occurred to me: why not have official add-on packs which are written by
the team but are platform-specific? So we could download an add-on pack of
Registry commands for Windows, but they wouldn't be part of the official app's
setup due to not being cross-platform.

What does the team think of this idea? I can't see any downsides to it.

[freak]

Why have separated packages, separated documentation, etc.. etc.. when we can just add the stuff to the main package ?
We have added non-crossplatform commands to PB where they bring a significant enough advantage to justify adding them, even for one platform only.

gadget coloring:
As i said in the other thread: I have implemented the commands as far as Windows provides the options. I won't implement owner drawn gadgets for this, as its damn ugly on modern versions like XP and Vista. If anything, there should be a coloring addon pack for Linux, but i guess thats not what you are after.

registry:
In my experience, registry commands are needed much less than you might think. And even if they are, the API for this is not much harder to use than any PB library would be. So why bother ?
(In my opinion, you are better off letting the setup tool do the needed registry manipulations and leaving the registry alone from your program itself. But thats just me. If you really need it, the API is there, and its not that complicated.)

[srod]

Or, you can offer to pay me a huge amount of cash and I'll write the library for you!

(Actually, I'd offer Freak a few $$$ to write the library for me and then pretend it was my own work! No one would be any the wiser! )

Seriously, that is not a bad idea PB; would make, for example, the Windows version of PB even more attractive. Of course, as we all know, there are libraries already available for just about every conceivable task anyhow. I'm not talking about PB user-libs but libraries written in c and so on. However, these 'packs' do have a certain attraction!

**EDIT : too slow!

[Mistrel]

Isn't this what DLLs and source includes are for?

[PB]

> Isn't this what DLLs and source includes are for?

Nope. I said "official" add-ons, meaning libs created by the team which won't
break between updates, which can happen with third-party libs sometimes.
The concept was like PowerToys by Windows, ie. apps made by Microsoft
team members but not part of Windows itself until you download them later.
But I see the idea has been poo-pooed, so it's a moot point now. At least we
got a quick official answer about it.

[Mistrel]

I would rather the PB team work on more evolutionary additions to the language rather than take the time to wrap and maintain code we can easily write ourselves.

And who's to say that someone might want one of these OS-specific functions to work a little differently? I know that I modify a lot of code that already works to suit my project.

I see no advantage.

[blueznl]

This may sound funny, but can someone explain to me the advantage of libraries over includes?

[thefool]

@bluez:
1) not everything is written in PB
2) maybe they don't want to share the sources, which is understandable.

I don't know about this idea. I like the fact that i just download the setup wherever i am and everything works like its supposed to. It works fine as-is for me at least

[ts-soft]

This may sound funny, but can someone explain to me the advantage of libraries over includes?

- Libraries have it's own Global VariableScope, private Procedures.
- Contexthelp with F1 and ToolTip in the IDE
- No problems with "Includepath"
- Can written in any language that support static libs
- Reduce compiletime

greetings
Thomas

[thefool]

- Contexthelp with F1 and ToolTip in the IDE
- No problems with "Includepath"

could be done with includes though

[ts-soft]

- Contexthelp with F1 and ToolTip in the IDE
- No problems with "Includepath"

could be done with includes though

In the moment is no way to do this in the original IDE.
You can't open a Helpfile for the Function in the Include with F1 that
show the description of this Function.

[PB]

> I see no advantage

Well, all you gotta do is look through the Wish List section to see all the stuff
not being done because it's not cross-platform. So imagine if the team decided
to do some of them, but for Windows only, so we don't need to use procedures
of our own and drop them into each new app we write. That's the vision I have.

For example: how many of you have colored your gadgets? And how many of
you ended up using the PureCOLOR library because PureBasic's commands don't
color as much as PureCOLOR does? Now, imagine if Fred/Freak made their own
version of PureCOLOR, so that you don't need to rely on a third party who might
not be around in future for whatever reason.

NOW can you see the advantage?

[freak]

Will you stop with the colors already :roll:

For the 3rd time:
There won't be any more color commands for Windows, even in a mega-windows-whatever-pack.
Try PureCOLOR on Vista with enabled skins and you will immediately see why.

> Well, all you gotta do is look through the Wish List section to see all the stuff not being done because it's not cross-platform.

Could you show me some of these ? Because i don't see many being denied for the "not crossplatform" reason, except maybe the registry commands.
(Colors don't count because as i said, they are _NOT_ a crossplatform issue)

[PB]

> For the 3rd time

I was talking to Mistrel, to explain what I meant. I've already accepted that it's not going to happen.

[Mistrel]

> For the 3rd time

I was talking to Mistrel, to explain what I meant. I've already accepted that it's not going to happen.

I would rather the PB team work on more evolutionary additions to the language rather than take the time to wrap and maintain code we can easily write ourselves.

And who's to say that someone might want one of these OS-specific functions to work a little differently? I know that I modify a lot of code that already works to suit my project.

I still see no advantage. It just might not be as convenient for us?

If you really want some of your favorite functions in a PB library then use Tailbite. There is already an immediate solution.