wxTNG: using external libraries

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

wxTNG: using external libraries

Julian Smart
Hi,

Here are some concerns about use of external libraries:

1. By basing our future on libraries like boost, we're
tying ourselves to them and have to commit to their
future direction, whatever that might be. What if their
license changes, or they make some other decision
we don't like? (Then we're stuck maintaining their
old code I guess...)

2. Do these libs support all our platforms? (For example,
embedded ones.)

3. Will we have to drop support for any significant compilers?

4. What about overhead? STL-based apps can increase
in size significantly. How would this affect embedded
apps? What about library and app compilation speed?

5. What about overall coherence of the API? It becomes
a collection of libraries, probably with different
documentation sets that may be a pain to navigate around.
Similarly, we would need to clarify licensing carefully.

6. What happens when the external libraries don't do
things we need them to do? (If we want to change them
we have to straddle several projects, and we might not
get permission.)

7. Existing users have to learn new stuff. Obvious
and not a show-stopper in itself, but listed for completeness.

The main arguments for external libraries are (AFAIK):

1. They're better than our classes. (Sure, but are they
*so* much better? Are people beating their head against
the restrictions and if so, can we have some examples?)

2. It'll be easier for us to maintain. (Except we also
have to maintain bridge classes, and be aware of changes/bugs
in these other libraries.)

3. People don't have to learn new APIs. (What proportion
of potential users are already using the classes we intend to use?)

4. It looks good if we follow standards. (Hm.. Microsoft seem pretty
successful making it up as it goes along, but of course
it's a slightly more powerful organisation :-))

Overall, my main fear is that we erode the project's identity
and coherence and end up with a mish-mash that's more restrictive,
less portable and with a more verbose syntax. Apart from that
it seems obviously the [politically] correct thing to do...

Regards,

Julian



==============================================================================
Julian Smart                           [hidden email]
28/5 Gillespie Crescent, Edinburgh,    http://www.anthemion.co.uk
Midlothian, U.K., EH10 4HU             +44 (0)131 229 5306
Writer's Cafe: power tools for writers http://www.writerscafe.co.uk
HelpBlocks:    HTML help authoring     http://www.helpblocks.com
DialogBlocks:  cross-platform dialogs  http://www.anthemion.co.uk/dialogblocks
==============================================================================



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

ABX
Reply | Threaded
Open this post in threaded view
|

Re: wxTNG: using external libraries

ABX
Julian Smart <[hidden email]>:
> Here are some concerns about use of external libraries:

Taking strings as an example I would prefer something like consistent use of

  wx::string in the API

and if somebody want to use foo::string in user application then deliver

  #include "wx-boost.h"

which could allow us to write code with transparent conversions like

  boost::string new_title;
  win.SetTitle(new_title); // SetTitle(wx::string title) was prototype

because wx-boost.h would contain all the conversions required (or nothing if
wx::string would be in fact boost::string internally). I admit I don't know if
that's possible with single header.

> 3. Will we have to drop support for any significant compilers?

I'm not a phanatic of outside-mainstream compilers but I would like to have
opportunity to inform their developers about features we started to use so
they could decide whether they want to implement missing features and keep
being supported. In other words to give them a chance to do minimal fixes
without any compromise in our code.

> 4. What about overhead?

My worries exactly. I would like to have static apps still downloadable in
reasonable time with not ideal bandwith.

> 6. What happens when the external libraries don't do
> things we need them to do? (If we want to change them
> we have to straddle several projects, and we might not
> get permission.)

Yes, just because wxW principles are important for us, from other toolkits
point of view we can be as important as trivial is changing wxWindows to
wxWidgets name in licence.

ABX


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: wxTNG: using external libraries

Stefan Csomor
In reply to this post by Julian Smart
Hi

> Right. I hope this is possible (wx::String an alias for
> boost::string) but I'm still cringing at the necessity to
> type two colons, which means faster onset of repetitive
> strain injury, as well as being harder on the eye. I think we
> should make it officially sanctioned to write wxString for
> wx::String, wxWindow for wx::Window, etc. and not something
> anyone has to feel slightly guilty about.

I think you should benefit from 'using namespace...' so that you will
only need Window, and of course you/we can typedef...

Best,

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: wxTNG: using external libraries

Julian Smart
In reply to this post by ABX
At 11:44 17/02/2006, you wrote:

>Julian Smart <[hidden email]>:
> > Here are some concerns about use of external libraries:
>
>Taking strings as an example I would prefer something like consistent use of
>
>   wx::string in the API
>
>and if somebody want to use foo::string in user application then deliver
>
>   #include "wx-boost.h"
>
>which could allow us to write code with transparent conversions like
>
>   boost::string new_title;
>   win.SetTitle(new_title); // SetTitle(wx::string title) was prototype

Right. I hope this is possible (wx::String an alias for boost::string)
but I'm still cringing at the necessity to type two colons, which
means faster onset of repetitive strain injury, as well as being harder on
the eye. I think we should make it officially sanctioned to write wxString
for wx::String, wxWindow for wx::Window, etc. and not something
anyone has to feel slightly guilty about.

Regards,

Julian




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: wxTNG: using external libraries

Julian Smart
In reply to this post by Stefan Csomor
At 13:26 17/02/2006, you wrote:

>Hi
>
> > Right. I hope this is possible (wx::String an alias for
> > boost::string) but I'm still cringing at the necessity to
> > type two colons, which means faster onset of repetitive
> > strain injury, as well as being harder on the eye. I think we
> > should make it officially sanctioned to write wxString for
> > wx::String, wxWindow for wx::Window, etc. and not something
> > anyone has to feel slightly guilty about.
>
>I think you should benefit from 'using namespace...' so that you will
>only need Window, and of course you/we can typedef...

True :-) I just wonder what the documentation and headers are going to look
like
with in some cases 50% longer prototypes... hopefully we can assume
"using wx" for the docs at least.

I think if installation and compilation is comprehensive and
simple, and we massage the docs so it's largely all in one place,
and we have bridging classes, and the overhead is not significant,
then I could learn to love appropriate use of other libs. But that
overhead issue bugs me somewhat. Hopefully it'll turn out to be
a non-issue...

Regards,

Julian




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: wxTNG: using external libraries

Michael Wetherell
In reply to this post by Julian Smart
On Friday 17 Feb 2006 13:46, Julian Smart wrote:
> I'm still cringing at the necessity to type two colons, which
> means faster onset of repetitive strain injury, as well as being
> harder on the eye. I think we should make it officially sanctioned to
> write wxString for wx::String, wxWindow for wx::Window, etc. and not
> something anyone has to feel slightly guilty about.

You won't need to type two colons on everything, you actually get
cleaner looking code since you usually don't need any prefix.

e.g. in a header you wrap the whole thing in a single namespace block:

namespace wxWidgets {
...
}

then inside there you don't use the prefix, e.g.:

class WXDLLIMPEXP_BASE Event : public Object
{
private:
    Event& operator=(const Event&);

protected:
    Event(const Event&);

public:
    Event(int winid = 0, EventType commandType = EVT_NULL);

Which looks cleaner. Same thing in the implementation .cpp files.

For user code it's different, since they're not adding to our namespace.
So in user .cpp files they can use:
        using wxWidgets::Window;
then they don't need to prefix the names in their code either.

The one place where fully qualified names are needed is where a
wxWidgets type is used in a user header. In that case they can't use
'using', but that's a small number of cases, so overall it's an
improvement.

Regards,
Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: wxTNG: using external libraries

Vadim Zeitlin-3
In reply to this post by Julian Smart
On Fri, 17 Feb 2006 08:54:04 +0000 Julian Smart <[hidden email]> wrote:

JS> Here are some concerns about use of external libraries:

 Let me start by stating a few things which are probably obvious to
everyone but still might be worth mentioning:

0a) The goal is to concentrate our efforts on wx "core competences", that
    is allowing writing full-featured portable C++ programs. Note that I
    don't think we should limit ourselves solely to the GUI stuff (there
    is also wxBase) but IMO we shouldn't be writing container/string
    classes, socket and thread classes and probably database classes
    neither.

 b) The above gives the broad direction but the decision still needs to be
    taken about each individual component separately. If we use some boost
    classes, it doesn't mean that we should use all of them, e.g. boost::
    filesystem::path stuff is an abomination (from personal experience of
    working with it) and is really not better than wxFileName (which has
    its own problems too, of course...). So for every non-GUI class we'll
    have the choice of
        (i) using std or boost class, if any
        (ii) using another third-party library
        (iii) making the class modular and allow it to use multiple
              backends to avoid introducing dependency on another library
        (iv) continuing to use our own class
        (v) submitting our own class into, for example, boost, if it's
            really much better than the existing class or if there are
            no existing alternatives

    And I think that in practice all of the above will be used in different
    contexts so let's not even try to find one solution for everything, it
    won't work

 c) We want to avoid heavy dependencies on too many other libraries,
    especially when they are not optional.


JS> 1. By basing our future on libraries like boost, we're
JS> tying ourselves to them and have to commit to their
JS> future direction, whatever that might be. What if their
JS> license changes,

 This shouldn't be a problem with boost, at least, as their goal is to
develop classes suitable for inclusion into future C++ standard library and
for this the license must be even more liberal than wx one.

JS> or they make some other decision we don't like?

 This is a real possibility, of course. In particular, boost doesn't have
the same vision of backwards compatibility as we do, they're quite ready to
break it (and sometimes pretty much so) if they deem it to be necessary.
All I can say is that we should be careful and only use the classes with
proven history behind them and hope they remain stable.
 
JS> 2. Do these libs support all our platforms? (For example,
JS> embedded ones.)
JS>
JS> 3. Will we have to drop support for any significant compilers?

 I think both of these questions have the same answer: if a library doesn't
work on important target systems or can't be built with a significant
compiler, then we can't use it. It's important, however, to define which
targets are important and which compilers significant. I don't know about
the targets but I do think we should limit ourselves only to modern C++
compilers, otherwise all this wxTNG effort doesn't make much sense. For me
"modern" means gcc4-comparable and definitely excluds VC6 and gcc < 3.4,
for example.


JS> 4. What about overhead? STL-based apps can increase
JS> in size significantly. How would this affect embedded
JS> apps?

 In theory, using templates smartly shouldn't increase the size.

JS> What about library and app compilation speed?

 This will definitely go out of the window, no doubt about it. It will be
many times slower than now, probably. But this is just the price to pay.

JS> 5. What about overall coherence of the API? It becomes
JS> a collection of libraries, probably with different
JS> documentation sets that may be a pain to navigate around.

 True. Another reason to avoid depending on (or at least isolating the user
from) too many libraries.

JS> Similarly, we would need to clarify licensing carefully.

 I'm more concerened about the build issues...

JS> 6. What happens when the external libraries don't do
JS> things we need them to do? (If we want to change them
JS> we have to straddle several projects, and we might not
JS> get permission.)

 For any important library we want to use we absolutely must discuss with
that library developers beforehand. This includes boost and I do realize we
may have troubles communicating with them. But we need to try...

JS> 7. Existing users have to learn new stuff.

 The idea is to use only libraries common enough so that there are already
a lot of users knowing them and, indeed, to facilitate life for the users
who already use them and wx together in their programs.

JS> The main arguments for external libraries are (AFAIK):
JS>
JS> 1. They're better than our classes. (Sure, but are they
JS> so much better? Are people beating their head against
JS> the restrictions and if so, can we have some examples?)

 wxSocket. Should I say more?

JS> 2. It'll be easier for us to maintain. (Except we also
JS> have to maintain bridge classes, and be aware of changes/bugs
JS> in these other libraries.)

 Still, for non trivial libraries it should be easier in the long term.
Also, in some cases there will be no bridge classes.

JS> 3. People don't have to learn new APIs. (What proportion
JS> of potential users are already using the classes we intend to use?)

 If we consistently choose the best library for the given functionality, we
can be reasonably sure that more of them use it than wx equivalent.

JS> 4. It looks good if we follow standards. (Hm.. Microsoft seem pretty
JS> successful making it up as it goes along, but of course
JS> it's a slightly more powerful organisation :-))

 Yes, if I were Microsoft I'd do the same thing as they did -- that is
created .NET just to have something different and something they could
totally control. We don't have the resources to do what they did though,
nor do I necessarily dream of locking everybody in the way they do.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: wxTNG: using external libraries

Ryan Norton
In reply to this post by Julian Smart
 > IMO we shouldn't be writing container/string
 >    classes, socket and thread classes and probably database classes
 >    neither.

This really gets to the core question of whether one wants wx to be
just a gui framework which happens to use other libraries[1] or a
general purpose framework much like java and/or MFC that either
implements their own stuff or wraps around it with wrapper classes etc..

[1] and then why are we even eager to use external libs besides the
STL. I think maybe a comprimise would be maybe the dictum

Ryan 23.22:
"If you happen to touch on something [like threads] then make a wrapper
API for it for the users, and if it is something you do not touch
[databases] and does not have anything to do with your core goal [a GUI
library] then do not make an API for it."

(Not that I neccesarily agree with that as I would like a general
purpose lib) Then I think whether or not to use external libraries is
simply intuitive as in if there is one available and it is halfway
decent then you use it etc..

 > wxSocket. Should I say more?

Actually, that is probably a bad example simply because even though it
isn't the greatest and the implementation by 90% of accounts is a mess
there really isn't too many (yes, there are a couple) other
alternatives for real cross-platform socket programming with event
integration.

The actual wxProtocols/wxURL are probably a good example, however.

Thanks,
Ryan


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re[2]: wxTNG: using external libraries

Vadim Zeitlin-3
On Fri, 17 Feb 2006 11:30:12 -0800 Ryan Norton <[hidden email]> wrote:

RN>  > IMO we shouldn't be writing container/string classes, socket and
RN>  > thread classes and probably database classes neither.
RN>
RN> This really gets to the core question of whether one wants wx to be
RN> just a gui framework which happens to use other libraries[1] or a
RN> general purpose framework much like java and/or MFC that either
RN> implements their own stuff or wraps around it with wrapper classes etc..

 I think it should be something in the middle but closer to the former.
If a library which does something well already exists and can be used in
wx, I think we should try to use it. If we can't and the feature is useful
enough to have then we have to implement our own support for it.

RN>  > wxSocket. Should I say more?
RN>
RN> Actually, that is probably a bad example simply because even though it
RN> isn't the greatest

 This is a minor understatement.

RN> there really isn't too many (yes, there are a couple) other
RN> alternatives for real cross-platform socket programming with event
RN> integration.

 Well, why do we need _many_? If there is a single one which is good, this
is enough IMHO.

 Regards,
VZ


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]