You can subscribe to this list here.
2002 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(2) |
Mar
(1) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(4) |
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(28) |
Nov
(89) |
Dec
(37) |
2008 |
Jan
(78) |
Feb
(37) |
Mar
(21) |
Apr
(3) |
May
(10) |
Jun
(3) |
Jul
(13) |
Aug
(7) |
Sep
(9) |
Oct
(3) |
Nov
(4) |
Dec
|
2009 |
Jan
(2) |
Feb
(7) |
Mar
(16) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(8) |
Sep
|
Oct
(5) |
Nov
(4) |
Dec
(1) |
2010 |
Jan
(4) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2012 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
(2) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2022 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Jacek S. <arn...@gm...> - 2009-02-15 22:16:51
|
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 |
From: poy <po...@12...> - 2009-02-13 18:00:38
|
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 |
From: poy <po...@12...> - 2009-01-10 15:47:23
|
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 |
From: LRN <lr...@gm...> - 2009-01-08 17:30:51
|
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. |
From: MikeJJ <mrm...@gm...> - 2008-11-13 02:09:57
|
> 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 |
From: David G. <c0...@cs...> - 2008-11-12 21:50:28
|
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. |
From: poy <po...@12...> - 2008-11-12 16:19:52
|
----- 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 |
From: poy <po...@12...> - 2008-11-12 15:57:46
|
> 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 |
From: MikeJJ <mrm...@gm...> - 2008-10-23 13:03:23
|
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¤cy_code=EUR&bn=PP%2dDonationsBF&charset=UTF%2d8" target="_blank" class="external">https://www.paypal.com/ ...</a> thanks MikeJJ |
From: poy <po...@12...> - 2008-10-23 09:21:48
|
> 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 |
From: MikeJJ <mrm...@gm...> - 2008-10-22 20:31:38
|
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. |
From: David G. <c0...@cs...> - 2008-09-23 07:22:17
|
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 > |
From: Fredrik U. <ul...@gm...> - 2008-09-22 20:25:13
|
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 |
From: David G. <c0...@cs...> - 2008-09-20 22:26:11
|
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) |
From: poy <po...@12...> - 2008-09-13 21:04:58
|
> 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 |
From: poy <po...@12...> - 2008-09-10 07:58:04
|
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 |
From: Jacek S. <arn...@gm...> - 2008-09-09 14:08:00
|
> 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 |
From: poy <po...@12...> - 2008-09-06 07:09:50
|
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 |
From: poy <po...@12...> - 2008-09-01 13:36:38
|
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 |
From: poy <po...@12...> - 2008-09-01 13:33:37
|
>> - 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 |
From: Jacek S. <arn...@gm...> - 2008-08-14 11:26:09
|
> 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 |
From: poy <po...@12...> - 2008-08-13 21:09:17
|
> 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 |
From: Jan V. K. <jan...@ex...> - 2008-08-13 17:26:23
|
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 |
From: poy <po...@12...> - 2008-08-13 14:05:08
|
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 |
From: poy <po...@12...> - 2008-08-04 16:24:35
|
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 |