dcplusplus-devel — Developer's list

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

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

Looks reasonable, fewer options = good.

Some comments:
1) WindowManager (singular)
2) It probably doesn't need locking (since all relevant calls are made from
the gui thread)
3) I assume viewOrder is not the ctrl-tab order but the order in which the
window tabs appear? (Don't remember =)
4) I'm not convinced about typeid - I wonder how stable that is across
compiler versions for example - also an msvc build would not use the same as
a gcc build...
5) Do we want search frames to auto-open?

/J

On Fri, Feb 13, 2009 at 7:00 PM, poy <po...@12...> wrote:

> attached patch adds a "Windows" tag in DCPlusPlus.xml where opened child
> views are saved before the program exits; when it starts again, all of the
> windows are restored back.
>
> since our windows have no id, i used typeid instead.
>
> hubs are handled slightly differently than other windows, since their
> address has to be saved, too. i also save the name of the hub although it is
> not used now, so that building a "recent hubs" menu should be easy from
> there.
>
> PMs and search windows are currently ignored; eventually, they should be
> handled the same as hubs.
>
> after this is in, the "auto-open on startup" options and "auto-connect"
> check-boxes in favorite hubs will have to be removed; i haven't cleaned them
> up in the patch.
>
> poy

[dcplusplus-devel] patch: tracking of opened windows

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

attached patch adds a "Windows" tag in DCPlusPlus.xml where opened child 
views are saved before the program exits; when it starts again, all of the 
windows are restored back.

since our windows have no id, i used typeid instead.

hubs are handled slightly differently than other windows, since their 
address has to be saved, too. i also save the name of the hub although it is 
not used now, so that building a "recent hubs" menu should be easy from 
there.

PMs and search windows are currently ignored; eventually, they should be 
handled the same as hubs.

after this is in, the "auto-open on startup" options and "auto-connect" 
check-boxes in favorite hubs will have to be removed; i haven't cleaned them 
up in the patch.

poy 

[dcplusplus-devel] patch: anti-spam improvement

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

attached patch improves the current anti-spam guard for fake connections 
emanating from not-updated NMDC hubs by resolving addresses of protected 
servers instead of using hard-coded IPs.

also, moved it to the NmdcHub class since it's NMDC-specific.

poy 

[dcplusplus-devel] magnet manifest support and filelist sharing

[LRN <lr...@gm...>]

To publish more than one file, you have to either archive them, or
publish a number of links (one link per file).
Magnet URI specs mention a manifest topics - special files that work
roughly as torrents in that they contain a list of hashes (technically,
they contain a list of normal magnet URIs, but in any magnet the main
thing is a hash anyway).
Manifest could be anything (magnet specs are very general and
application-independent). xml file list could be considered a form of
manifest. Another format for manifests is MAGnet MAnifest format (MAGMA).
So i thought it would be cool to have support for something like that in
DC++.

What needs to be done:
1) handle &mt=<manifest topic> keyword in magnet URIs
Mt may be a hash or any valid web link. DC++, for example, should either
1a) start searching for a file with the manifest's hash (if it's a TTH)
and download it, or
1b) download a manifest from the web (use HttpConnection?) if it's a
http:// link.
2) Once file is obtained - parse it and display its contents to the
user, offering to download the files inside.
2a) File could be obtained by 3rdparty application (usually - web
browser), saved to disk and passed to DC++. With *.magma extension it's
easy - just set up the .magma handler in registry. It should looks like
"%program fiels%\bin\DCPlusPlus.exe" manifest "%1". With other file list
formats...dunno. *.xml and *.xml.bz2 both aren't really DC++-specific.
Maybe introduce *.dclist or something like that?
2b) DC++ assumes that commandline consists only of a dchub/adchub/magnet
link, everything else is ignored. Since manifest is passed as just a
file name, it's not possible to identify it by URI prefix (such as
"magnet:?"). Commandline parser has to be changed to recognize various
arguments.
2c) Obviously, DC++ needs magma-parser to parse magma files.
2cI) Magma is just a list of magnets. No information about directory
structure. So, maybe it's better to stick to dclists.

I've tried to implement these (patch attached). Alas, my skills in
hardcore C++ aren't as good as i hoped, so you shouldn't assume that
it's bugless or even compiles out of the box. I just don't know how to
do some of the things.
I've more or less made the 1) (also, now magnet parser knows how to
handle multiple keywords, such as "&dn.1=foo&dn.2=bar")
I've tried to do 1a), but filed - file is added the the download queue,
but something wrong happens and it is never downloaded (DC++
continuously requests the file from a peer, but peer says that file is
not available or unknown).
1b) is not implemented
2) is complicated by the fact that everything in DC++ is tied to user
IDs, but there is no specific user behind a manifes or a file list
obtained from &mt. I've used DirectoryListing to show the list.
For 2a) i've done this manually (via registry editor), and only for
.magma extension
For 2b) i've made a simple commandline parser. Barely working, but still
better than string::find()
For 2c) i've  made a magma parser. Magma specs are awkward. Maybe magma
v4.x will be better, but it is not released yet.

As i said, it's just something to think on, not a really working thing.

Also you may consider:
Parsing &kt=<search key words> and initiating a search.
Use &xs=<exact source> to point to a peer cache (AFAIK Gnutella does that)
Use &as=<acceptable source> to download file from a web (&as is never a
hash) when search yields nothing.
Set up a http listener in 451xx port range according to magnet URI
specs. AFAIK only Azureus supports such technique. DC++, being
inherently Windows application, relies more on magnet.exe and the
Windows registry.

Re: [dcplusplus-devel] Immediate File Browser

[MikeJJ <mrm...@gm...>]

> And this works fine if you patiently wait for the download to finish. 
> But I usually don't wait for the list, and start doing other things in 
> DC++ while I wait. And then, suddenly and unasked for, the file list 
> pops up and steals focus from whatever I was doing. Not minding me 
> typing something in a search window, it just throws the tab in my face.
> 
> I think it would be better to have the tab show up directly when I 
> request the file list. Then I could work without worrying about the tab 
> showing up and disrupting me.

That is a nice idea.  
Btw, there is an option to open Filelists in background so that they
don't popup, stealing focus (also one for PM's). :)

MikeJJ

Re: [dcplusplus-devel] Immediate File Browser

[David G. <c0...@cs...>]

poy skrev:
> there seems to be a difference between Linux DC++ and DC++ here; in DC++, a 
> file list download appears in the "transfers" area just like other downloads 
> and all the necessary information is available there.
> hence, the new window would not have anything useful to provide that the 
> "transfers" area, which is always visible, already shows.
>   
Yes, this is true. I know, because I tried it myself in DC++. Now bear 
with me why I want to change the behavior. The default configuration in 
DC++ is to popup a file list when the list is finished. It essentially 
just makes a new tab and selects it.

And this works fine if you patiently wait for the download to finish. 
But I usually don't wait for the list, and start doing other things in 
DC++ while I wait. And then, suddenly and unasked for, the file list 
pops up and steals focus from whatever I was doing. Not minding me 
typing something in a search window, it just throws the tab in my face.

I think it would be better to have the tab show up directly when I 
request the file list. Then I could work without worrying about the tab 
showing up and disrupting me.
> about comments in your wiki;
>   
>> What about those file lists that are not set to be shown on download? They 
>> still won't have any feedback.
>>     
> in DC++ they will.
>   
They will in Linux DC++ too, if you are referring to the transfer view. 
And I don't have any trouble with this functionality, since its not an 
annoyance.
>> Viewing the file list before everything has been downloaded, would be 
>> neat. Would need changes to the DC++ core.
>>     
> this is already implemented in ADC, as the "browse file list" function.
>   
There is a browse file list menu item. But it just downloads partial 
file lists. Which is kind of useful, but rather limited since you can't 
browse any parent directory and it always downloads a complete subtree. 
Here's an idea, how about sending the complete directory hierarchy 
first. Then one could select any directory and the non-recursing file 
listing of that directory is downloaded.

Re: [dcplusplus-devel] Immediate File Browser

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

----- Original Message ----- 
From: "David Grundberg" <c0...@cs...>
To: "Patches & development discussion" 
<dcp...@li...>
Sent: Saturday, September 20, 2008 10:09 PM
Subject: [dcplusplus-devel] Immediate File Browser


> Hello :)
>
> Idea of a new "feature"
>
> The file list browser is immediately shown instead of waiting until the
> file list has been transferred.
>
> The basic idea is that DC++ should act less than traditional DC++
> behavior and more like a web browser, thus being more familiar to new
> users.
>
> More detail at:
> http://openfacts2.berlios.de/wikien/index.php/BerliosProject:LinuxDC%2B%2B_-_Immediate_File_Browser
>
> And the Blueprint at Linux DC++
> https://blueprints.launchpad.net/linuxdcpp/+spec/ldcpp-immediate-file-browser
>
> I'm a Linux DC++ patcher so please bear with the constant Linux DC++
> yammering. The basic idea is fully transferable (I think) to win32 DC++.
>
> Anyway, happy to hear any input.
>
> /David (individ)
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's 
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great 
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the 
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
>


there seems to be a difference between Linux DC++ and DC++ here; in DC++, a 
file list download appears in the "transfers" area just like other downloads 
and all the necessary information is available there.
hence, the new window would not have anything useful to provide that the 
"transfers" area, which is always visible, already shows.

about comments in your wiki;
> What about those file lists that are not set to be shown on download? They 
> still won't have any feedback.
in DC++ they will.
> Viewing the file list before everything has been downloaded, would be 
> neat. Would need changes to the DC++ core.
this is already implemented in ADC, as the "browse file list" function.

poy 

Re: [dcplusplus-devel] Help Translations

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

> Shame there is no nice way of marking strings non-translatable.

well actually, there is! :)
all one has to do is wrap the non-translatable string in an <untranslated> 
tag. not XHTML compliant, but neither po4a nor IE care about it.

now for inlined tags which attributes could be modified "accidentally" by a 
translator (like the "href" of an <a>), but are in the middle of a sentence, 
this solution of course doesn't work since it would split the sentence into 
multiple parts. there might be not-so-easy ways to work around it but i 
don't think it's worth the trouble, unless translators really mess things 
up...

poy 

Re: [dcplusplus-devel] Help Translations

[MikeJJ <mrm...@gm...>]

A few more spelling errors . . . the line numbers might be slightly out,
since it's a multiline translation

manget should be magnet Located in help\faq_install.html:18
bandwith should be bandwidth Located in help\faq_slowdownload.html:25
bandwith should be bandwidth Located in help\faq_slowdownload.html:159
avaliable should be available Located in help\faq_upnp.html:47
menuitem should be menu item Located in help\get_started.html:65
istalled should be installed Located in help\get_started.html:101 
stucture should be structure Located in help\get_started.html:129 
adresses should be addresses Located in help\get_started.html:142
precendence should be precedence Located in help\netiquette.html:14 

Shame there is no nice way of marking strings non-translatable.  
A few others i seen which i think shouldn't be translated are the pure
HTML stuff, e.g. 
<a href="http://dcplusplus.sourceforge.net/featurereq/" target="_blank"
class="external">http://dcplusplus.sourceforge.net/featurereq/</a>

The copyright info and the names in the credits.

And this one, since it might give some translators funny ideas (another
pure HTML one, but this one definitely should not be translatable):
<a
href="https://www.paypal.com/cgi-bin/webscr?cmd=_xclick&business=arnetheduck%40gmail%2ecom&item_name=DCPlusPlus&no_shipping=1&return=http%3a%2f%2fdcplusplus%2esf%2enet%2f&cancel_return=http%3a%2f%2fdcplusplus%2esf%2enet%2f&cn=Greeting&tax=0&currency_code=EUR&bn=PP%2dDonationsBF&charset=UTF%2d8" target="_blank" class="external">https://www.paypal.com/ ...</a>

thanks
MikeJJ

Re: [dcplusplus-devel] Help Translations

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

> Looking through these, there are a some stuff I don't think should be
> translatable.  Like the Http code blocks, the /commands (unless the
> actual command can be changed in DC++ via language files, but if memory
> serves they can't).

there's no easy way to mark strings are non-translatable; besides, some 
parts of /commands definitions still have to be kept translatable, like 
"lines to keep" in "/clear [lines to keep]". also, when translating 
linearly, it's easier if the /command is present to know what command the 
text you're translating applies to...
in theory that could be a translator comment, but neither po4a nor Launchpad 
support them iirc.

other strings that should be immutable are HTML tags that are "inlined" 
(po4a vocab) to keep them in context, like <b>, <span ...>, <a ...>, etc. 
then again, i doubt that replacing them with %1% and such would make them 
any easier to translate... Launchpad has a nifty copy-paste feature that 
allows translating such strings with embedded HTML code without too much 
hassle.

>
> Also:
> Note that this is a Windows feature.
>
> Is at the end of quite a few translations.  Could this be split out,
> into it's own separate translation. ?

that's in the FAQ page for keyboard shortcuts. since many of them aren't 
working atm, i wouldn't bother with them too much... plus, Ctrl+C and co 
work in nix too, no? how about just removing that notice?

poy 

[dcplusplus-devel] Help Translations

[MikeJJ <mrm...@gm...>]

Looking through these, there are a some stuff I don't think should be
translatable.  Like the Http code blocks, the /commands (unless the
actual command can be changed in DC++ via language files, but if memory
serves they can't).

Also:
Note that this is a Windows feature.

Is at the end of quite a few translations.  Could this be split out,
into it's own separate translation. ?

Oh and in help\faq_nosearch.html line 10 ish
critera
is spelt wrong, unless that's another word the Americans have decided to
change the spelling of.  It should be 
criteria

Another query is "addys" okay, everybody knows this is short for address
but should a slang work be in the help file ? (help
\faq_nosearch.html:21)

help\faq_plusplus_tag.html:49 area upload is spelt wrong.  and bandwidth
is spelt wrong twice. 

They maybe more, but that's as far as i've got looking through the
translations.

thanks MikeJJ

P.S. I would commit the typo fixes myself but VirtualBox ain't working
at the moment.  And Bzr in debian, the settings seem to be bzr settings
for the whole pc, not just the project it's in, and i don't want to
screw ought up.

Re: [dcplusplus-devel] Immediate File Browser

[David G. <c0...@cs...>]

I'd say there are several advantages of being more similar to other 
software, like a web browser:

1, Feedback is important. How will the user know that the program didn't 
ignore the command otherwise?

2. Users are smart. They want to be lazy. And the easiest software to 
use is one that resembles something you already learned.

Fredrik Ullner wrote:
> Well, how about the partial file listing in ADC? It's not exactly as 
> you describe, but it will display a file list quite quickly, and it's 
> in DC++...
>  
> On a sidenote, I see no real point in having DC++ "act like a 
> browser". It's not one.
>
>  
> On Sat, Sep 20, 2008 at 11:09 PM, David Grundberg <c0...@cs... 
> <mailto:c0...@cs...>> wrote:
>
>     Hello :)
>
>     Idea of a new "feature"
>
>     The file list browser is immediately shown instead of waiting
>     until the
>     file list has been transferred.
>
>     The basic idea is that DC++ should act less than traditional DC++
>     behavior and more like a web browser, thus being more familiar to new
>     users.
>
>     More detail at:
>     http://openfacts2.berlios.de/wikien/index.php/BerliosProject:LinuxDC%2B%2B_-_Immediate_File_Browser
>
>     And the Blueprint at Linux DC++
>     https://blueprints.launchpad.net/linuxdcpp/+spec/ldcpp-immediate-file-browser
>
>     I'm a Linux DC++ patcher so please bear with the constant Linux DC++
>     yammering. The basic idea is fully transferable (I think) to win32
>     DC++.
>
>     Anyway, happy to hear any input.
>
>     /David (individ)
>
>     -------------------------------------------------------------------------
>     This SF.Net email is sponsored by the Moblin Your Move Developer's
>     challenge
>     Build the coolest Linux based applications with Moblin SDK & win
>     great prizes
>     Grand prize is a trip for two to an Open Source event anywhere in
>     the world
>     http://moblin-contest.org/redirect.php?banner_id=100&url=/
>     <http://moblin-contest.org/redirect.php?banner_id=100&url=/>
>     _______________________________________________
>     dcplusplus-devel mailing list
>     dcp...@li...
>     <mailto:dcp...@li...>
>     https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>
>
>
>
> -- 
> Fredrik Ullner
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>   

Re: [dcplusplus-devel] Immediate File Browser

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

Well, how about the partial file listing in ADC? It's not exactly as you
describe, but it will display a file list quite quickly, and it's in DC++...

On a sidenote, I see no real point in having DC++ "act like a browser". It's
not one.


On Sat, Sep 20, 2008 at 11:09 PM, David Grundberg <c0...@cs...> wrote:

> Hello :)
>
> Idea of a new "feature"
>
> The file list browser is immediately shown instead of waiting until the
> file list has been transferred.
>
> The basic idea is that DC++ should act less than traditional DC++
> behavior and more like a web browser, thus being more familiar to new
> users.
>
> More detail at:
>
> http://openfacts2.berlios.de/wikien/index.php/BerliosProject:LinuxDC%2B%2B_-_Immediate_File_Browser
>
> And the Blueprint at Linux DC++
>
> https://blueprints.launchpad.net/linuxdcpp/+spec/ldcpp-immediate-file-browser
>
> I'm a Linux DC++ patcher so please bear with the constant Linux DC++
> yammering. The basic idea is fully transferable (I think) to win32 DC++.
>
> Anyway, happy to hear any input.
>
> /David (individ)
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> dcplusplus-devel mailing list
> dcp...@li...
> https://lists.sourceforge.net/lists/listinfo/dcplusplus-devel
>



-- 
Fredrik Ullner

[dcplusplus-devel] Immediate File Browser

[David G. <c0...@cs...>]

Hello :)

Idea of a new "feature"

The file list browser is immediately shown instead of waiting until the 
file list has been transferred.

The basic idea is that DC++ should act less than traditional DC++ 
behavior and more like a web browser, thus being more familiar to new 
users.

More detail at:
http://openfacts2.berlios.de/wikien/index.php/BerliosProject:LinuxDC%2B%2B_-_Immediate_File_Browser

And the Blueprint at Linux DC++
https://blueprints.launchpad.net/linuxdcpp/+spec/ldcpp-immediate-file-browser

I'm a Linux DC++ patcher so please bear with the constant Linux DC++ 
yammering. The basic idea is fully transferable (I think) to win32 DC++.

Anyway, happy to hear any input.

/David (individ)

Re: [dcplusplus-devel] help translation

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

> i've uploaded a first dcpp-help.pot file created with rev 1142 of DC++ and
> po4a 0.34. it is in the "import queue" currently, we'll see how it goes...

it's in now, and some people have already started translating it.

attached is a patch for win32/WinUtil.cpp to have DC++ find the correct help 
file depending on the language; i had to add a few quirks for when the 
selected language is "Default", represented by an empty setting value.
localized help files go to "locale/[language]/help/DCPlusPlus.chm", is it 
ok?

poy 

Re: [dcplusplus-devel] help translation

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

i've uploaded a first dcpp-help.pot file created with rev 1142 of DC++ and 
po4a 0.34. it is in the "import queue" currently, we'll see how it goes...

> Hm, one thing to check is that the build doesn't fail if the scripts are 
> missing...

it shouldn't fail, it should just silently skip the i18n part. i use the 
SCons WhereIs command which checks for the presence of an executable in 
PATH.

poy 

Re: [dcplusplus-devel] help translation

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

> as for translation, the gettext library wasn't originally designed for HTML 
> files; however, the po4a people <http://po4a.alioth.debian.org/> have 
> written Perl scripts that extend the usage of gettext to a bunch of formats, 
> including HTML.
Sounds reasonable

> i have committed some ground work to integrate po4a with our help; for now, 
> only the first step is possible, which consists of generating a .pot 
> template file using po4a-gettextize. it's about 300 KB, i've sent it on 
> <http://www.sendspace.com/file/o0czzb>.
> the next steps would be, if i understand the process correctly:
> - to send that dcpp-help.pot (keep it that name, or call it something else?) 
> file on Launchpad;
keep name

> - to create wrappers around po4a-translate that create new HTML files based 
> on translated .po files;
ok

> - to have the help SCons script copy these translated files in a temp 
> directory, so it can build a translated compiled CHM file;
that would be the build directory...I guess the correct way would be to define a builder like it's 
done for the other translations

> - to create wrappers around po4a-updatepo to update these .po files when our 
> HTML files change.
yes - same as with the other files, only build them when scons i18n is enabled...

> i'd like to know if my thinking is correct before going further...
> 
Hm, one thing to check is that the build doesn't fail if the scripts are missing...

> on po4a installation, i assume it is straight-forward on nix systems; i 
> installed it on Windows using Cygwin, only had 1 change to do: had to 
> replace all occurences of "::" by "." in po/pod.cfg.
> i also added a few batch files in Cygwin/bin with the same names as the po4a 
> programs (eg "po4a-gettextize.bat" for "po4a-gettextize"), so that they can 
> be called from outside the Cygwin Shell, each batch file containing:
> @echo off
> bash --login -i -c "cd '%CD%'"
> bash -c '%0 %*'
> echo on
> 
Maybe it works with activeperl? (for people that want to avoid cygwin)

> poy 

[dcplusplus-devel] help translation

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

regarding translation of the DC++ help;

DC++ uses HTML Help for its help system, which is a pretty good choice over 
the alternative (the old WinHelp). this means, of course, that it is formed 
by HTML files.

as for translation, the gettext library wasn't originally designed for HTML 
files; however, the po4a people <http://po4a.alioth.debian.org/> have 
written Perl scripts that extend the usage of gettext to a bunch of formats, 
including HTML.

i have committed some ground work to integrate po4a with our help; for now, 
only the first step is possible, which consists of generating a .pot 
template file using po4a-gettextize. it's about 300 KB, i've sent it on 
<http://www.sendspace.com/file/o0czzb>.
the next steps would be, if i understand the process correctly:
- to send that dcpp-help.pot (keep it that name, or call it something else?) 
file on Launchpad;
- to create wrappers around po4a-translate that create new HTML files based 
on translated .po files;
- to have the help SCons script copy these translated files in a temp 
directory, so it can build a translated compiled CHM file;
- to create wrappers around po4a-updatepo to update these .po files when our 
HTML files change.
i'd like to know if my thinking is correct before going further...

on po4a installation, i assume it is straight-forward on nix systems; i 
installed it on Windows using Cygwin, only had 1 change to do: had to 
replace all occurences of "::" by "." in po/pod.cfg.
i also added a few batch files in Cygwin/bin with the same names as the po4a 
programs (eg "po4a-gettextize.bat" for "po4a-gettextize"), so that they can 
be called from outside the Cygwin Shell, each batch file containing:
@echo off
bash --login -i -c "cd '%CD%'"
bash -c '%0 %*'
echo on

poy 

Re: [dcplusplus-devel] new lines in hub titles

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

forgot the patches...

> patches attached, so that when forbidden chars are encountered:
> - DC++ replaces the name with "InvalidName" and the description with 
> "InvalidDescription".
> - ADCH++ displays a log message and uses the default settings values.
> 
> poy

Re: [dcplusplus-devel] new lines in hub titles

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

>> - ADCH++ should make sure it doesn't send forbidden chars in its INF.
> During startup probably...
>
>> - DC++ should handle bad chars in incoming INFs and either discard theses 
>> INFs or replace bad chars with eg spaces.
> I think it might actually make more sense to set the name / invalid field 
> to a dummy string like "Invalid value" - that'll do more to convince 
> owners not to put these invalid values there in the first place...

patches attached, so that when forbidden chars are encountered:
- DC++ replaces the name with "InvalidName" and the description with 
"InvalidDescription".
- ADCH++ displays a log message and uses the default settings values.

poy 

Re: [dcplusplus-devel] new lines in hub titles

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

> there are 3 places where behaviors could/should be changed:
And all three should check I guess...

> - ADCH++ should make sure it doesn't send forbidden chars in its INF.
During startup probably...

> - DC++ should handle bad chars in incoming INFs and either discard theses 
> INFs or replace bad chars with eg spaces.
I think it might actually make more sense to set the name / invalid field to a dummy string like 
"Invalid value" - that'll do more to convince owners not to put these invalid values there in the 
first place...


> - DWT's window and tab controls obviously don't support new lines, so they 
> should replace CRs & LFs with eg spaces.
Hm, I'm not sure this is dwt's responsibility - it should maybe be noted in the docs, but dwt itself 
should safely assume that it's only being passed valid strings...at least if it only results in ugly 
display (not crash)...

And poy is right - the escaping mechanism of ADC works on a lower level and has nothing to do with 
the restrictions placed on the various inf fields.


> poy 

Re: [dcplusplus-devel] new lines in hub titles

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

> I think it is OK if it is sent escaped (\n), otherwise it is a weird
> INF followed with a garbage command (which would also be exploitable
> by allowing injected commands).

ADCH++ does correctly escape commands it sends; there is not the problem. 
but it shouldn't send any \n (new line) or \s (space), or any other char 
with a code point < 32 in the NI (hub name) field of its INF; and no \n (new 
line) or any other char with a code point < 32 in the DE (hub description) 
field of its INF.

related quote from the spec:
NI   | string  | Nickname (or hub name). The hub must ensure that this is 
unique in the hub up to case-sensitivity. Valid are all characters in the 
Unicode character set with code point above 32, although hubs may limit this 
further as they like with an appropriate error message.
DE   | string  | Description. Valid are all characters in the Unicode 
character set with code point equal to or greater than 32.

even if '\' and 's' are above 32, they are in another layer; the char they 
translate into (space - code point 32) isn't allowed in nicks (and by 
extension, in the hub name since it also uses NI).
same for the hub description about new lines (code points 10 or 13) and 
these other chars with a code point < 32.

poy 

Re: [dcplusplus-devel] new lines in hub titles

[Jan V. K. <jan...@ex...>]

On 8/13/08, poy <po...@12...> wrote:
> in ADCH++, it's pretty easy to add a new line to the hub name or
>  description, simply by adding a new line in the settings file in the
>  contents of the "HubName" or "Description" tags.
>  this violates the ADC spec ("code point equal to or greater than 32") and
>  results in messed up title bar and tab title in DC++.

I think it is OK if it is sent escaped (\n), otherwise it is a weird
INF followed with a garbage command (which would also be exploitable
by allowing injected commands).

The client implementation needs to filter newlines if it cannot
present it "correctly" in the title area or otherwise. The hub is
pretty much at liberty to send whatever it likes anyway, and client
implementations need to take that into consideration.

On the other hand, when it comes to other parts of INF messages, such
as nick names, I think it would be more useful for hub implementations
to enforce stricter rules, such as nicks consisting of (only) white
space. But that is user generated content, not hub created.

-- 
Jan Vidar Krey

[dcplusplus-devel] new lines in hub titles

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

in ADCH++, it's pretty easy to add a new line to the hub name or 
description, simply by adding a new line in the settings file in the 
contents of the "HubName" or "Description" tags.
this violates the ADC spec ("code point equal to or greater than 32") and 
results in messed up title bar and tab title in DC++.

there are 3 places where behaviors could/should be changed:
- ADCH++ should make sure it doesn't send forbidden chars in its INF.
- DC++ should handle bad chars in incoming INFs and either discard theses 
INFs or replace bad chars with eg spaces.
- DWT's window and tab controls obviously don't support new lines, so they 
should replace CRs & LFs with eg spaces.

poy 

[dcplusplus-devel] patch: have standard user menus in PM

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

this patch makes PrivateFrame derive from AspectUserInfo, so that standard 
user commands are added and handled automatically.
i had to change a few things in AspectUserInfo because it was designed to 
work only with lists (as in GUI lists); now each window impletementing 
AspectUserInfo has to parse its own list and return a vector of users.

poy