dcplusplus-devel

[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] 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

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
>   

[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] 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 

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...>]

> 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] 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] 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

[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