dcplusplus-devel — Developer's list

Re: [dcplusplus-devel] ADC: message timestamp

[Fredrik U. <ul...@gm...>]

How often would this feature be used? I.e., would (should) clients add that
every X message to ensure that they are not lagging (or every X seconds
etc)?

While I can admit that it might be interesting to have real timestamps (if
not simply for the fact that it'd be similar to other protocols), I fail to
see the usefullness for normal clients. (How would the client know when it
should send with timestamp and when it shouldn't?) At most, though, it seems
this feature would only be really useful in a debugging environment.

Also, it might be worthwhile introducing similar functionality in SCH -
though using timestamp as a "I don't care about search results after X
time", but I suppose that might be another whole discussion.

On Sat, Aug 1, 2009 at 2:09 PM, poy <po...@12...> wrote:

> i would like the following param be added to the MSG command of ADC:
>
> TS | Timestamp of the moment when the message was sent, expressed in
> seconds
> since the Unix Epoch (January 1 1970 00:00:00 GMT).
>
> it would be optional, and when absent, clients would assume as they
> currently do that the message was sent at the same time it was received.
>
> poy
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>



-- 
Fredrik Ullner

[dcplusplus-devel] ADC: message timestamp

[poy <po...@12...>]

i would like the following param be added to the MSG command of ADC:

TS | Timestamp of the moment when the message was sent, expressed in seconds 
since the Unix Epoch (January 1 1970 00:00:00 GMT).

it would be optional, and when absent, clients would assume as they 
currently do that the message was sent at the same time it was received.

poy 

Re: [dcplusplus-devel] patch: save user nicks

[poy <po...@12...>]

----- Original Message ----- 
From: "Jacek Sieka" <arn...@gm...>
To: "poy" <po...@12...>; "Patches & development discussion" 
<dcp...@li...>
Sent: Saturday, May 02, 2009 1:57 PM
Subject: Re: [dcplusplus-devel] patch: save user nicks


>I think a sensible rule would be to save only those users that are 
>potentially useful...an easy way
> of doing this is to save all users that have been touched during the 
> session (online, in queue, in
> pm window, etc)...
>
> /J


this patch loads saved nicks in a separate list, and it's the list of useful 
nicks that is saved on closing. when a nick is not found in the "useful 
nicks" list, it is brought over from the saved list.

poy 

Re: [dcplusplus-devel] patch: save user nicks

[Jacek S. <arn...@gm...>]

I think a sensible rule would be to save only those users that are potentially useful...an easy way
of doing this is to save all users that have been touched during the session (online, in queue, in
pm window, etc)...

/J

poy wrote:
> simple patch that saves user nicks to a file called "Users.xml", and
> restores them on restart. avoids having CIDs of disconnected users
> displayed all over the UI.
> 
> the list is never purged; maybe store the time the user was last
> connected, and remove old users based on that time?
> 
> poy
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel

[dcplusplus-devel] patch: save user nicks

[poy <po...@12...>]

simple patch that saves user nicks to a file called "Users.xml", and 
restores them on restart. avoids having CIDs of disconnected users displayed 
all over the UI.

the list is never purged; maybe store the time the user was last connected, 
and remove old users based on that time?

poy 

[dcplusplus-devel] patch: fix file list refresh bug

[Ben <mim...@gm...>]

The attached patch fixes the bug described at
https://bugs.launchpad.net/dcplusplus/+bug/210727. Note that the bug
has changed somewhat since it was first reported. A detailed
description of the behavior in the most recent version can be found at
https://bugs.launchpad.net/dcplusplus/+bug/210727/comments/24.  The
patch prevents any files from being hashed until the file list refresh
is complete, and forces a new XML list to be generated after the last
file is hashed. The code is admittedly pretty ugly, and I'm sure a
better programmer than I could implement the fix much more cleanly,
but it seems to work, and I'd really like to see this bug finally get
fixed.

I hereby transfer copyright to Jacek Sieka on the off chance he
decides to use my implementation for some reason.

Ben

Re: [dcplusplus-devel] scons version requirement change necessary?

[Jacek S. <arn...@gm...>]

mainly because of my latest commit that changes option to variable (it gives annoying scons warnings
on 1.2.0, dunno about older versions). Also because I wasn't sure the boost trick would work with
older sconses...if everything is fine with r1695 and whatever scons you have, please adjust the min
version accordingly.

/J

cologic wrote:
> Version 0.98.5 (what's in Ubuntu 8.10) seems to work fine already:
>> $ bzr diff
>> === modified file 'SConstruct'
>> --- SConstruct  2009-03-17 13:33:26 +0000
>> +++ SConstruct  2009-03-17 16:02:07 +0000
>> @@ -1,4 +1,4 @@
>> -EnsureSConsVersion(1, 2)
>> +EnsureSConsVersion(0, 2)
>>
>>  import os,sys
>>  from build_util import Dev
>>
>> $ bzr revno
>> 1694
>> $ scons --version
>> SCons by Steven Knight et al.:
>>         script: v0.98.5.r3057, 2008/06/09 22:21:00, by knight on bangkok
>>         engine: v0.98.5.r3057, 2008/06/09 22:21:00, by knight on bangkok
>> Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 The SCons Foundation
>> $ scons prefix=i586-mingw32msvc-
>> scons: Reading SConscript files ...
>> hhc.exe not found, skipping chm build
>> Unknown resource compiler.
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> scons: `.' is up to date.
>> scons: done building targets.
> why was the minimum SCons version changed? Even Debian unstable only
> has 1.0.0 packaged so far ( http://packages.debian.org/sid/scons )
> so actually requiring 1.2.x would be inconvenient.
> 
> -cologic
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
> 

[dcplusplus-devel] scons version requirement change necessary?

[cologic <co...@pa...>]

Version 0.98.5 (what's in Ubuntu 8.10) seems to work fine already:
> $ bzr diff
> === modified file 'SConstruct'
> --- SConstruct  2009-03-17 13:33:26 +0000
> +++ SConstruct  2009-03-17 16:02:07 +0000
> @@ -1,4 +1,4 @@
> -EnsureSConsVersion(1, 2)
> +EnsureSConsVersion(0, 2)
> 
>  import os,sys
>  from build_util import Dev
> 
> $ bzr revno
> 1694
> $ scons --version
> SCons by Steven Knight et al.:
>         script: v0.98.5.r3057, 2008/06/09 22:21:00, by knight on bangkok
>         engine: v0.98.5.r3057, 2008/06/09 22:21:00, by knight on bangkok
> Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 The SCons Foundation
> $ scons prefix=i586-mingw32msvc-
> scons: Reading SConscript files ...
> hhc.exe not found, skipping chm build
> Unknown resource compiler.
> scons: done reading SConscript files.
> scons: Building targets ...
> scons: `.' is up to date.
> scons: done building targets.
why was the minimum SCons version changed? Even Debian unstable only
has 1.0.0 packaged so far ( http://packages.debian.org/sid/scons )
so actually requiring 1.2.x would be inconvenient.

-cologic

Re: [dcplusplus-devel] boost vs tr1

[Steven S. <ste...@gm...>]

Sorry, I don't have time to check it at the moment. You can revert it for now
and I'll research it more. Note that the commit contained other fixes for
compiler warnings that should not be reverted unless you have some issue with
them that has not been raised.

-Steven

Jacek Sieka wrote:
> Did you ever check if it was indeed the boost version / include order? I'll be reverting your patch
> soon unless you have further comments...
> 
> /J
> 
> Steven Sheehy wrote:
>> Jacek,
>>
>> With std::tr1 namespace, it did not compile on g++ 4.3.2 and libstdc++ 4.3.2. It
>> was unable to find shared_ptr in tr1, so I switched it to boost. I guess on my
>> system it doesn't use the boost one as a fallback like you mention.
>>
>> -Steven
>>
>> Jacek Sieka wrote:
>>> Hey Steven,
>>> I noticed you changed from tr1 to boost shared_ptr, what's wrong with the one from tr1 (which is
>>> drawn from boost if it's missing from the compiler)?
>>>
>>> /J
>>>
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>>> -Strategies to boost innovation and cut costs with open source participation
>>> -Receive a $600 discount off the registration fee with the source code: SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> dcplusplus-devel mailing list
>>> dcp...@li...
>>> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> dcplusplus-devel mailing list
>> dcp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>>
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel

Re: [dcplusplus-devel] boost vs tr1

[Jacek S. <arn...@gm...>]

Did you ever check if it was indeed the boost version / include order? I'll be reverting your patch
soon unless you have further comments...

/J

Steven Sheehy wrote:
> Jacek,
> 
> With std::tr1 namespace, it did not compile on g++ 4.3.2 and libstdc++ 4.3.2. It
> was unable to find shared_ptr in tr1, so I switched it to boost. I guess on my
> system it doesn't use the boost one as a fallback like you mention.
> 
> -Steven
> 
> Jacek Sieka wrote:
>> Hey Steven,
>> I noticed you changed from tr1 to boost shared_ptr, what's wrong with the one from tr1 (which is
>> drawn from boost if it's missing from the compiler)?
>>
>> /J
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> dcplusplus-devel mailing list
>> dcp...@li...
>> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
> 

Re: [dcplusplus-devel] patch: tracking of opened windows

[cologic <co...@pa...>]

poy wrote:
>> Ok for this patch, but:
>>
>> "ChildList" would probably be more correct (any native speakers?)
> 
> it's in... another one for native speakers, can this be rephrased better:
> "Auto-open windows that were opened before closure"

If the program is doing it, "auto-*" is redundant. I'd use "Remember
opened windows", "Remember opened window state" [somewhat more
general - could hint at e.g. window placement too], or "Re-open
previous windows" [because in a real sense, a closed window doesn't
exist].

-cologic

Re: [dcplusplus-devel] patch: tracking of opened windows

[James R. <si...@wa...>]

>> Ok for this patch, but:
>>
>> "ChildList" would probably be more correct (any native speakers?)
> 
> it's in... another one for native speakers, can this be rephrased better:
> "Auto-open windows that were opened before closure"

"Automatically restore open windows"

-- 
James Ross <si...@wa...> 

Re: [dcplusplus-devel] patch: tracking of opened windows

[poy <po...@12...>]

> Ok for this patch, but:
>
> "ChildList" would probably be more correct (any native speakers?)

it's in... another one for native speakers, can this be rephrased better:
"Auto-open windows that were opened before closure"

>
> In the long term, as steven correctly points out, the windows stuff should 
> probably be removed from
> dcpp and moved somewhere (including settingsmanager etc). One could 
> however argue that since the
> windowmanager is implemented in a pretty general way (with the stringmap), 
> other ui's can make use
> of it as well...

in any case, it should be much easier to ignore the whole WindowManager than 
to ignore each particular auto-connect/auto-open option.

poy 

Re: [dcplusplus-devel] patch: tracking of opened windows

[Jacek S. <arn...@gm...>]

Ok for this patch, but:

"ChildList" would probably be more correct (any native speakers?)

In the long term, as steven correctly points out, the windows stuff should probably be removed from
dcpp and moved somewhere (including settingsmanager etc). One could however argue that since the
windowmanager is implemented in a pretty general way (with the stringmap), other ui's can make use
of it as well...

/J

poy wrote:
>> - find a way to not delete opened file lists; right now re-opening of
>> file
>> lists only works when the "delete file lists" option is not activated.
>> any
>> suggestion?
> 
> attached patch prevents opened file lists from being deleted upon
> closure, it adds their paths to a vector which is then confronted (with
> a nice one-liner using std::set_difference!) to the vector that contains
> file lists to delete.
> 
>> - update the title of the file list window when a hub is connected, right
>> now it only shows the CID because it doesn't know the nick when the
>> window
>> is initially opened.
> 
> did this in the main repo, it was out of the scope of this patch.
> 
> besides, i've changed it so it returns the actual order of tabs instead
> of the ctrl+tab ordering, so tabs re-appear just as they were before.
> it's now all good to me...
> 
> poy
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel

Re: [dcplusplus-devel] patch: tracking of opened windows

[poy <po...@12...>]

> - find a way to not delete opened file lists; right now re-opening of file
> lists only works when the "delete file lists" option is not activated. any
> suggestion?

attached patch prevents opened file lists from being deleted upon closure, 
it adds their paths to a vector which is then confronted (with a nice 
one-liner using std::set_difference!) to the vector that contains file lists 
to delete.

> - update the title of the file list window when a hub is connected, right
> now it only shows the CID because it doesn't know the nick when the window
> is initially opened.

did this in the main repo, it was out of the scope of this patch.

besides, i've changed it so it returns the actual order of tabs instead of 
the ctrl+tab ordering, so tabs re-appear just as they were before.
it's now all good to me...

poy 

Re: [dcplusplus-devel] patch: tracking of opened windows

[poy <po...@12...>]

now supports re-opening of file lists, as long as they are not deleted. 
also:
- fixed some locking issues.
- moved saved params parsing logic from 
MainWindow::on(WindowManagerListener::Window, ...) to each child window 
which now implements a static void parseWindowParams(dwt::TabView* parent, 
const StringMap& params) that defaults to just opening the window for 
standard windows; hubs, PMs, file lists overload it to parse their own 
params.
- simplified opening own file list, now it's all in DirectoryListingFrame.

todo:
- find a way to not delete opened file lists; right now re-opening of file 
lists only works when the "delete file lists" option is not activated. any 
suggestion?
- update the title of the file list window when a hub is connected, right 
now it only shows the CID because it doesn't know the nick when the window 
is initially opened.

poy 

Re: [dcplusplus-devel] patch: tracking of opened windows

[Jacek S. <arn...@gm...>]

Steven Sheehy wrote:
> I don't understand the need to put user interface logic inside of the core.
> WindowManager would be better suited inside of the win32 folder. The DC++ core
> is supposed to be a "library" and thus should not have any knowledge of any user
>  interface this is invoking its APIs or responding to its events. In my opinion,
> the SettingsManager as it is now needs to be redone so that settings that are
> used only in the GUI are moved outside of the core (like we did with win32-only
> translatable strings). This could be done by making a WindowsSettingsManager
> that extends the core SettingsManager and adds extra Windows specific settings.
> If this was done, it would be much more natural to place WindowManager in win32/.

Generally, I'd agree that some of the dcpp/ stuff doesn't belong there, but it's been left as a
matter of convenience. There also some things that make sense for most potential ui's that
technically don't belong in dcpp but that all ui's can benefit from, so they are still there ("show
nick of joining user in chat")...a ui support library would maybe make sense but we also have to
consider increased maintenance and the actual work to move stuff etc...

/J

Re: [dcplusplus-devel] boost vs tr1

[Jacek S. <arn...@gm...>]

I'd suspect you're using an old boost then, or not putting boost/tr1/tr1
first in the include path...
see http://www.boost.org/doc/libs/1_38_0/doc/html/boost_tr1/usage.html

I don't remember when boost.tr1 appeared but my guess would be around 1.35..

On Mon, Mar 2, 2009 at 11:44 PM, Razzloss <raz...@gm...> wrote:

> Hi all,
>
> One of the changes I made to get 0.705 to compile (and had forgotten about
> until this conversation) was in stdinc.h. #include <memory> had to be moved
> to #elif defined(__GLIBCPP__)... block and changed to <tr1/memory>. After
> that std::tr1::shared_ptr should be found.
>
> No idea what this does to the windows compile, so I didn't send changes to
> the
> upstream.
>
> --RZ
>
> On Monday 02 March 2009 20:41:56 Steven Sheehy wrote:
> > Jacek,
> >
> > With std::tr1 namespace, it did not compile on g++ 4.3.2 and libstdc++
> > 4.3.2. It was unable to find shared_ptr in tr1, so I switched it to
> boost.
> > I guess on my system it doesn't use the boost one as a fallback like you
> > mention.
> >
> > -Steven
> >
> > Jacek Sieka wrote:
> > > Hey Steven,
> > > I noticed you changed from tr1 to boost shared_ptr, what's wrong with
> the
> > > one from tr1 (which is drawn from boost if it's missing from the
> > > compiler)?
> > >
> > > /J
> > >
> > >
> -------------------------------------------------------------------------
> > >----- Open Source Business Conference (OSBC), March 24-25, 2009, San
> > > Francisco, CA -OSBC tackles the biggest issue in open source: Open
> > > Sourcing the Enterprise -Strategies to boost innovation and cut costs
> > > with open source participation -Receive a $600 discount off the
> > > registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> > > _______________________________________________
> > > dcplusplus-devel mailing list
> > > dcp...@li...
> > > https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
> >
> >
> ---------------------------------------------------------------------------
> >--- Open Source Business Conference (OSBC), March 24-25, 2009, San
> > Francisco, CA -OSBC tackles the biggest issue in open source: Open
> Sourcing
> > the Enterprise -Strategies to boost innovation and cut costs with open
> > source participation -Receive a $600 discount off the registration fee
> with
> > the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> > _______________________________________________
> > dcplusplus-devel mailing list
> > dcp...@li...
> > https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>

Re: [dcplusplus-devel] boost vs tr1

[Razzloss <raz...@gm...>]

Hi all,

One of the changes I made to get 0.705 to compile (and had forgotten about 
until this conversation) was in stdinc.h. #include <memory> had to be moved 
to #elif defined(__GLIBCPP__)... block and changed to <tr1/memory>. After 
that std::tr1::shared_ptr should be found. 

No idea what this does to the windows compile, so I didn't send changes to the 
upstream.

--RZ

On Monday 02 March 2009 20:41:56 Steven Sheehy wrote:
> Jacek,
>
> With std::tr1 namespace, it did not compile on g++ 4.3.2 and libstdc++
> 4.3.2. It was unable to find shared_ptr in tr1, so I switched it to boost.
> I guess on my system it doesn't use the boost one as a fallback like you
> mention.
>
> -Steven
>
> Jacek Sieka wrote:
> > Hey Steven,
> > I noticed you changed from tr1 to boost shared_ptr, what's wrong with the
> > one from tr1 (which is drawn from boost if it's missing from the
> > compiler)?
> >
> > /J
> >
> > -------------------------------------------------------------------------
> >----- Open Source Business Conference (OSBC), March 24-25, 2009, San
> > Francisco, CA -OSBC tackles the biggest issue in open source: Open
> > Sourcing the Enterprise -Strategies to boost innovation and cut costs
> > with open source participation -Receive a $600 discount off the
> > registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> > _______________________________________________
> > dcplusplus-devel mailing list
> > dcp...@li...
> > https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
> ---------------------------------------------------------------------------
>--- Open Source Business Conference (OSBC), March 24-25, 2009, San
> Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing
> the Enterprise -Strategies to boost innovation and cut costs with open
> source participation -Receive a $600 discount off the registration fee with
> the source code: SFAD http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel

Re: [dcplusplus-devel] boost vs tr1

[Steven S. <ste...@gm...>]

Jacek,

With std::tr1 namespace, it did not compile on g++ 4.3.2 and libstdc++ 4.3.2. It
was unable to find shared_ptr in tr1, so I switched it to boost. I guess on my
system it doesn't use the boost one as a fallback like you mention.

-Steven

Jacek Sieka wrote:
> Hey Steven,
> I noticed you changed from tr1 to boost shared_ptr, what's wrong with the one from tr1 (which is
> drawn from boost if it's missing from the compiler)?
> 
> /J
> 
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel

[dcplusplus-devel] boost vs tr1

[Jacek S. <arn...@gm...>]

Hey Steven,
I noticed you changed from tr1 to boost shared_ptr, what's wrong with the one from tr1 (which is
drawn from boost if it's missing from the compiler)?

/J

[dcplusplus-devel] Translations

[Jacek S. <arn...@gm...>]

Hi,
translation templates updated in anticipation of the next release, have fun...

/J

Re: [dcplusplus-devel] patch: tracking of opened windows

[poy <po...@12...>]

----- Original Message ----- 
From: "Steven Sheehy" <ste...@gm...>
To: "Patches & development discussion" 
<dcp...@li...>
Sent: Friday, February 20, 2009 4:36 AM
Subject: Re: [dcplusplus-devel] patch: tracking of opened windows


>I don't understand the need to put user interface logic inside of the core.
> WindowManager would be better suited inside of the win32 folder. The DC++ 
> core
> is supposed to be a "library" and thus should not have any knowledge of 
> any user
> interface this is invoking its APIs or responding to its events. In my 
> opinion,
> the SettingsManager as it is now needs to be redone so that settings that 
> are
> used only in the GUI are moved outside of the core (like we did with 
> win32-only
> translatable strings). This could be done by making a 
> WindowsSettingsManager
> that extends the core SettingsManager and adds extra Windows specific 
> settings.
> If this was done, it would be much more natural to place WindowManager in 
> win32/.
>
> -Steven


all current auto-open and auto-connect options are in dcpp/ (in 
SettingsManager and FavoriteManager respectively) so for simplicity and to 
avoid restructuring everything i left WindowManager in dcpp/ too.
i originally thought of making the GUI thread listen to settings load/save 
events but it appeared that these can occur when the GUI has already been 
closed, thus making it impractical to find child windows that were opened 
before closure. having WindowManager in dcpp/ just like every other similar 
*manager/*listener is just the most natural with the current architecture.

it would surely be nice to move out auto-open options as well as column 
sizes and other GUI options but that is not the purpose of this patch.

poy 

Re: [dcplusplus-devel] patch: tracking of opened windows

[Steven S. <ste...@gm...>]

I don't understand the need to put user interface logic inside of the core.
WindowManager would be better suited inside of the win32 folder. The DC++ core
is supposed to be a "library" and thus should not have any knowledge of any user
 interface this is invoking its APIs or responding to its events. In my opinion,
the SettingsManager as it is now needs to be redone so that settings that are
used only in the GUI are moved outside of the core (like we did with win32-only
translatable strings). This could be done by making a WindowsSettingsManager
that extends the core SettingsManager and adds extra Windows specific settings.
If this was done, it would be much more natural to place WindowManager in win32/.

-Steven

poy wrote:
> reworked a bit in order to auto-open PMs. added virtual StringMap
> getWindowParams() in MDIChildFrame that child windows can override to
> return their own params (hubs return their address, PMs their CID & base
> hub).
> 
> poy

Re: [dcplusplus-devel] patch: tracking of opened windows

[poy <po...@12...>]

reworked a bit in order to auto-open PMs. added virtual StringMap 
getWindowParams() in MDIChildFrame that child windows can override to return 
their own params (hubs return their address, PMs their CID & base hub).

poy