Re: developing rockbox page for blind users
Daniel Dalton wrote on 20/09/2007 23:58 : That could go in the setting up cygwin section. It isn't the same as the other guide since it is written for how to do it when your blind and with a screenreader. if he's not reading this, I will ask Sean if he agree that I pu his work on the wiki since i'm registered or if he prefers to do this by himself. You could find useful patches for example p6323 and write about them. The main voicing patches I know of are from sdoyon but I have written some myself. you're definetely right. but, before writing, I've got to manage to apply those patches. With your help, i've really learnt but i was unable to test your patches, due mainly to my players limitations. and, about Stephane's patches, there're kinda hard to apply since they involves many other dependencies I wasn't even able to apply one of them lol . I hope this patch improving bookmark voicing will be committed one day. I've written a few things in french, I could adapt them in english. I hope this list is the rigt place too discuss about this. The only thing I could participate in is the wiki at this time. Rockbox is a great product, but everyone already knows this anyway, it's a good idea Daniel.
Re: developing rockbox page for blind users
On 20/09/2007 10:33 PM, RaZorbacK wrote: sure I am. there're some valuable infos and tutorials what shoudn't be lost. i'm thinking about one in particular by a guy named Sean which is worth putting on the wiki. it's rally well done and it had helped me installing my cygwin without any knowledge. That is the sort of thing I am talking about. That could go in the setting up cygwin section. It isn't the same as the other guide since it is written for how to do it when your blind and with a screenreader. I would participate to this project but i don't have many things to share unfortunately, my linux knowledge are inexistant :) You could find useful patches for example p6323 and write about them. The main voicing patches I know of are from sdoyon but I have written some myself. -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: developing rockbox page for blind users
On 21/09/2007 12:03 AM, Tapio Kelloniemi wrote: > Cygwin support might be appropriate for someone, but I strongly recommend that general instructions for compiling Rockbox would not be repeated there. It was mainly going to be about useful patches for blind users for example p6323. Also it would describe setting up cygwin when you are blind. And then how to use a screenreader to compile rockbox. And then maybe tips on programming for rockbox. I don't know when I will do this but if any blind users can help out that would be good. -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: Licensing and Copyright Issues
DervishD wrote: No, IANAL, but I read Groklaw a lot... ;) Well, that's almost like being a lawyer without having to eat human flesh ... Very funny! I love it! :-) ~ray
Re: Licensing and Copyright Issues (GPL discussion)
Sorry for being so late with this response. It's been a busy week and I really wanted to respond to Daniel's comments... Daniel Stenberg wrote: On Tue, 11 Sep 2007, Ray Lambert wrote: The GPL has a specific reason for existing. It's to protect the hard work of programmers from those people who would use it to their own advantage, to the detriment of the very people that toiled over its creation in the first place. This is essentially what "TiVo-ization" is and it's why so many folks (yourself included) think it's wrong and even immoral (which I agree with); it's basically a form of stealing. Why should you (or anyone) allow any company to "steal" your work in this manner? You shouldn't. That's what the GPL (and, yes, its DRM and patent clauses) protect against. Well, that's your view but not the view of many others. See kerneltrap and the GPLv3 flame fest on the Linux kernel mailing list. You're certainly correct about "many others" but it's not just my view; not by a long shot. It's important to remember who created the GPL and why. I suspect RMS would agree fully with my statement as would most other FSF supporters. Many OSS projects have chosen to use the GPL (including RB) even though their goals may not be directly in line with those of the GPL & FSF. The GPL does carry certain baggage with it, due to its philosophical underpinnings, and that baggage goes along with it whether you like it or want it or not. I suspect that many OSS projects would be happier with a different license, frankly. I don't think it's helpful or appropriate for OSS guys to argue about changing or ignoring the nature of the GPL (especially when its nature is so obvious, due to RMS wearing it on his sleeve). They need to realize that this extra baggage became their own when they chose to use the GPL and either accept it or switch to another license. Companies like Tivo have used GPLv2 fine for many years and they have contributed their changes back and thus helped improving Linux. They use the code under the GPL license, they share their code. In my view, that is the exact spirit of the (GPLv2) license. Yes, but there is more to both things. (BTW, I would agree that "stealing" is probably a bit too strong of a word for tivo. Admittedly I was being a bit flippant. (That's also why I quoted the word.)) GPLv3 modifies that spirit and expands it to another level. You may agree with it, or you may not, but in my view the license has changed spirit and no longer only requires that you get code changes back, it now also requires that you should be able to install your modified versions on any hardware that runs GPLv3 software. I disagree. It does not modify the core meanings or intent in any way. It merely clarifies the terms so as to close loopholes. Tivoisation was the result of a loophole. The Novell/M$ patent deal was the result of a loophole. GPLv3 closes those loopholes and I agree with that goal. Again, these changes perfectly serve the goals of the FSF and RMS. OSS guys can argue about it all they want but, at the end of the day, it's the FSF's license and it should be expected that they're going to maintain it in a manner that supports *their* goals. OSS guys should also remember that it's the GPL and RMS' "extremism" that has made OSS possible by providing virtually ALL of the infrastructure required to make OSS (i.e. compilers, etc.). Can you imagine where OSS would be today without GNU? One should be careful not to throw out the baby with the bath water. And remember, it's more than just *your* personal work. The GPL is trying to protect the entire FOSS ecosystem. In order for that to succeed, we need to all stick together on this. No. We (as in the FOSS community) have had plenty of licenses all the time and the GPLv3 just *adds* a license and the fact that it isn't GPLv2 compatible makes things hard for a large amount of projects. No. The GPL was the first and GPLv3 is not a new license, it *IS* the GPL. If the OSS community choses to move away from the protective principals of the GPL, OSS code *will* eventually be co-opted by businesses with ill intentions. Human nature doesn't change (in our lifetimes) and history does repeat itself. Remember, this all came about because RMS actually *saw* it happen. We don't "stick together" for the sake of it, we do what we think is best as IMHO open source and free software is best made to evolve evolution-like and that requires everyone to make up their own minds and do their own decisions. The best wins in the end. The survival of the fittest. By "sticking together" I meant standing by the core principals of the GPL. I completely agree with the remainder of your statement but one must remember that it's the aspects of the GPL that *protect the code* that allows the evolution to continue freely. Most importantly (w.r.t. working with companies) if
Re: developing rockbox page for blind users
On Thu, Sep 20, 2007 at 09:52:27PM +1000, Daniel Dalton wrote: > Hi, > > What does everyone think of having a wiki page for blind users which > will have the following: > How to code when your blind; > how to setup your environment; > Describes how to apply patches All this is pretty trivial and is described in that famous manual. > and how to use cygwin with a screenreader; This could be useful for window$ developers since using console applications in general might be a problem (don't know for sure though). The reason why I haven't touched window$ (if we ignore ideology here) is that it is so difficult (compared to Linux console). > Maybe linux as well if someone knows about that; No need to explain anything special, everything is well documented in the Wiki (installing the cross compiler, etc.). > Comments? Suggestions? Cygwin support might be appropriate for someone, but I strongly recommend that general instructions for compiling Rockbox would not be repeated there. -- Tapio
Re: XML for language files
Jerry Van Baren wrote: > Jonas Häggqvist wrote: >> It seems that Cygwin does not package any non-core modules >> for Perl, so we're out of luck for any XML parser. > > I'm running cygwin perl for an unrelated purpose and my installation > supports Expat: > use XML::Parser > with no extra work. In fact, it turns out that my installation *does* have XML::LibXML - I was just looking under perl5/5.8/ rather than perl5/vendor_perl/. All's good then, and I'll go on with my plan. -- Jonas Häggqvist rasher(at)rasher(dot)dk
Re: XML for language files
Jonas Häggqvist wrote: Linus Nielsen Feltzing wrote: Jonas Häggqvist wrote: I still doubt translators will care much one way or the other, even if they were to edit the file by hand. For now, I'll go ahead and have a go at implementing genlang using this XML format. One additional question: is the XML parser module included in standard Perl? Or do for example Cygwin users have to install an additional Perl module? Ah, we hit a problem there (discussed on IRC, mirroring it here for completeness). It seems that Cygwin does not package any non-core modules for Perl, so we're out of luck for any XML parser. This means that we should either abandon the idea completely, require users to manually install XML::LibXML (which seems to be the best offering - depends on libxml2 which *is* available in Cygwin) or add it to the rockbox cygwin mirror (this means of course that someone would have to package it). I'm running cygwin perl for an unrelated purpose and my installation supports Expat: use XML::Parser with no extra work. $ find /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/XML/ /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/XML/ /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/XML/Parser /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/XML/Parser/.packlist /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/XML/Parser/Expat /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/XML/Parser/Expat/Expat.bs /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/XML/Parser/Expat/Expat.dll /usr/lib/perl5/vendor_perl/5.8/cygwin/auto/XML/Parser/Expat/libExpat.dll.a gvb
Re: developing rockbox page for blind users
Daniel Dalton écrivait Le 20/09/2007 13:52 : Hi, Any blind users interested in this? sure I am. there're some valuable infos and tutorials what shoudn't be lost. i'm thinking about one in particular by a guy named Sean which is worth putting on the wiki. it's rally well done and it had helped me installing my cygwin without any knowledge. I would participate to this project but i don't have many things to share unfortunately, my linux knowledge are inexistant :)
Re: XML for language files
Linus Nielsen Feltzing wrote: > Jonas Häggqvist wrote: >> I still doubt translators will care much one way or the other, even if >> they >> were to edit the file by hand. For now, I'll go ahead and have a go at >> implementing genlang using this XML format. > > One additional question: is the XML parser module included in standard > Perl? Or do for example Cygwin users have to install an additional Perl > module? Ah, we hit a problem there (discussed on IRC, mirroring it here for completeness). It seems that Cygwin does not package any non-core modules for Perl, so we're out of luck for any XML parser. This means that we should either abandon the idea completely, require users to manually install XML::LibXML (which seems to be the best offering - depends on libxml2 which *is* available in Cygwin) or add it to the rockbox cygwin mirror (this means of course that someone would have to package it). -- Jonas Häggqvist rasher(at)rasher(dot)dk
developing rockbox page for blind users
Hi, What does everyone think of having a wiki page for blind users which will have the following: How to code when your blind; how to setup your environment; Describes how to apply patches and how to use cygwin with a screenreader; Maybe linux as well if someone knows about that; also some useful patches for blind users. Ones that improve the voice feedback. Comments? Suggestions? Is this worth doing? Any blind users interested in this? -- Daniel Dalton http://members.iinet.net.au/~ddalton/ [EMAIL PROTECTED]
Re: XML for language files
Jonas Häggqvist wrote: I still doubt translators will care much one way or the other, even if they were to edit the file by hand. For now, I'll go ahead and have a go at implementing genlang using this XML format. One additional question: is the XML parser module included in standard Perl? Or do for example Cygwin users have to install an additional Perl module? Linus
Re: XML for language files
Daniel Stenberg wrote: > And moving away from doing translations with just a text editor of > course adds quite a bit to the process of translating. Possibly of > course, your online service is the better way to do them anyway and then > we'll get less human edited files and then the downsides of XML's lack > of readablity becomes much less important. That's certainly a valid point, but I understand that not everyone wants to use a webbased editor (no ability to save mid-translation, browsers may crash etc.). Perhaps someone could whip up a desktop application, but I don't think it'll be me. The logic of genlang should be easy to transfer to other languages, since almost all of it will be implemented using the DOM interface. In the end, I don't think it's much of a hassle, even if you have to edit by hand.. > I find these files a lot harder to edit manually. Possibly easier to > check for syntax errors, sure, but there will also be more syntax errors > to detect! ;-) For some uses I agree, but in the case of translating, the editing a translator has to do is 99% of the time simply replacing a text-string with another. I don't see how that's "a lot harder": - e200,ipodvideo,h120: "Foo" + e200,ipodvideo,h120: "Bar" vs. - Foo + Foo Only in rare cases will a translator need to write *any* XML himself. For this reason, I don't see an XML format being a lot harder to edit. Harder yes, but not a lot. > So, in the end I'm open for such a switch if it truly gives us benefits > and it won't add too much pain to the translators. I still doubt translators will care much one way or the other, even if they were to edit the file by hand. For now, I'll go ahead and have a go at implementing genlang using this XML format. -- Jonas Häggqvist rasher(at)rasher(dot)dk
Re: XML for language files
On Thu, 20 Sep 2007, Jonas Häggqvist wrote: The current format was introduced/discussed [1] in June 2006, where Daniel Stenberg proposed the current format in relation to the langv2 rework and a small-scale flamewar about using an XML format erupted. In the end, I think Daniel got tired of arguing without getting anywhere and implemented the current format. Correct. But looking at your example XML, I'll stand by my original stand point that it really isn't meant for human consumption. This format is a lot more awkward for translators to edit if a mere text editor is used for it. And moving away from doing translations with just a text editor of course adds quite a bit to the process of translating. Possibly of course, your online service is the better way to do them anyway and then we'll get less human edited files and then the downsides of XML's lack of readablity becomes much less important. - The file is somewhat harder to read and modify. I won't argue that this is true, but I don't think it's really a huge difference. This is probably the most important problem. I find these files a lot harder to edit manually. Possibly easier to check for syntax errors, sure, but there will also be more syntax errors to detect! ;-) So, in the end I'm open for such a switch if it truly gives us benefits and it won't add too much pain to the translators. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: IRC channel
On 9/20/07, Dave Chapman <[EMAIL PROTECTED]> wrote: > I'm also strongly in favour of keeping a single channel - I'm not that > annoyed by off-topic chat (I can easily ignore it), and very much like > the fact that the Rockbox community is one where there is no strong > distinction between devs and users - every user is encouraged to help > themselves and contribute to the project, and thereby become a "dev". > > Dave. I agree with this. This is how I once started following Rockbox development. I really liked and still likes the non-elitist way Rockbox-devs share information, communicate with users and newbies. I would very much like the irc-channel to stay this way. I believe that noise and off-topic conversations will appear in every channel regardless how they are organised. And it's nice to be met by friendly developers and users in a less developer-only channel, as opposed to join a dev channel and get a sod-off because you happend to not be entirely up to date with irc-lingo and (non-written) rules. I hadn't used irc for ages before i joined the rockbox community, and i guess this applies for others as well. It is also very valuable source of feedback, and i guess irc-newbies will hesitate less when joining a less formal channel when they have something they want to share. Martin
Re: Licensing and Copyright Issues
> Hi all, > > Recently the IRC channel has been rather full of discussion around the > current licensing of Rockbox (GPLV2 is how most people interpret it, > but it *is* a little unclear), and whether or not we should move to > GPLV3 in order to include code from other such projects (espeak is the > primary example here). > > This brings up further interesting questions, not least of which is: > > If we want to move to GPLV3, we need the permission of all Copyright > holders to the Rockbox source code in order to do so. Just another thought (sorry for reawakening this old topic...): We've taken several optimised functions from Linux in the past - those should probably be audited to see if they are GPL V2 only or any future version. If they are V2 only then we will need to roll back to the original Rockbox versions (or get permission from the copyright holders) in order to change our GPL version, and we must make it clear that Rockbox as a whole is V2 only. Dan
Re: IRC channel
On 9/20/07, Austin Appel <[EMAIL PROTECTED]> wrote: > So is it generally thought that I should be stricter then? Yeah. You should change your nick to scorche-meaniepants
RE: IRC channel
>well, it could of course be used only if you're using the web client >and have not registered to freenode -- or is something like this too >hard to implement? > >Otoh, I'm not sure if this is really necessary if we enforce the rules >more strictly. It could be implemented using a bot and a voicing system, but I would think this is WAY unnecessary. So is it generally thought that I should be stricter then?
Re: IRC channel
> The only way to ensure the rules are read is to introduce an IRC > CAPTCHA. This would require the user to have read the rules, and then > respond to an automated question posed by a bot to them when they > first enter the channel. Only when they respond with the correct > answer (presumably something to do with the rules they've just read) > do they get voiced. well, it could of course be used only if you're using the web client and have not registered to freenode -- or is something like this too hard to implement? Otoh, I'm not sure if this is really necessary if we enforce the rules more strictly. - Dominik
Re: IRC channel
> The rules are already pretty tight and are *supposed* to be read before > speaking, but do you have any suggestions for changing them? > http://www.rockbox.org/wiki/IrcGuidelines The only way to ensure the rules are read is to introduce an IRC CAPTCHA. This would require the user to have read the rules, and then respond to an automated question posed by a bot to them when they first enter the channel. Only when they respond with the correct answer (presumably something to do with the rules they've just read) do they get voiced. This is fairly draconian though and I can't see it being popular... A lot of the really large IRC support channels I've been in over the years have had to do this though.
RE: IRC channel
>Maybe the rules need a little tightening first? Could we have the same >rules for support on both IRC and the forums? Enough to say that you >should RTFM before asking a question. The rules are already pretty tight and are *supposed* to be read before speaking, but do you have any suggestions for changing them? http://www.rockbox.org/wiki/IrcGuidelines
Re: IRC channel
I'm also strongly in favour of keeping a single channel - I'm not that annoyed by off-topic chat (I can easily ignore it), and very much like the fact that the Rockbox community is one where there is no strong distinction between devs and users - every user is encouraged to help themselves and contribute to the project, and thereby become a "dev". I also think from a practical point of view, there will be too much overlap between the two channels. And if conversations switch between the two channels, it will be much harder to follow things in the logs. Dave.
Re: IRC channel
> I would think we have a decent amount of ops to cover all times already. If > you wish for me (and other ops) to be stricter, just say so. I already feel > that I am sometimes quite too soft on people (such as DWGR who is now > banned), but I prefer that to being a "jerk". Like I said though...if you > feel a step up is needed, just say so. The problem I find with many of > these annoyances is that they can be quite annoying without technically > breaking any of the rules. Maybe the rules need a little tightening first? Could we have the same rules for support on both IRC and the forums? Enough to say that you should RTFM before asking a question. After this has been clarified, sure, be strict. -- pondlife
Re: IRC channel
> How do you measure "infrequently" ? I don't - without logs it's not easy to. All I know is that on the occasions I've been in there (not many, granted), I've only seen tumbleweed. -- pondlife
Re: IRC channel
Daniel Stenberg wrote: Splitting "users" from "devs" (even the distinction is wierd) will just risk that either users sit in a channel where not enough devs are so they won't get the help they seek, or they come to the dev channel to ask the questions since there's where the devs are etc. And I have no need to join two rockbox channels... I agree with Daniel. When a user needs help, he is better off if the actual developers are there to help him. Let's stick with #rockbox as long as we can. Linus
Re: IRC channel
pondlife écrivait Le 20/09/2007 08:38 : I have not found the "user helping" aspect annoying, and it's sometimes useful to stimulate development ideas. If people are annoying, then a quick RTFM response is perfectly acceptable; if they continue to annoy, why not have a few more channel ops around and kick them for not following the protocols - i.e. a more strict police force. personnally, i'm not a developper, just an user. I've subscribed to this list, because i'm interested in building voice files and translating and I wanted to learn more. Even tough the conversations on the irc channel are often hard to understand for a "normal" user, many people have really helped me to achieve my goal even if my questions were stupid sometime. so, i don't think making other channels would be a good idea. Everyone has to respect each other and as you said it's not so hard to kick the bad guys out. Rockbox-community IMHO, is enough to have support. Again, a great Thanks for the nice job you are doing. cheers, Sof
Re: XML for language files
On Thu, 20 Sep 2007, Jonas Häggqvist wrote: also whats the user attribute? It's a not-yet implemented feature of langv2 and I believe it's related to allowing translation and voice for plugins. Yes, it is meant to allow the language or voice binary to have a speal "chunk" for a particular "user", which can be core or a particular plugin etc. That would then allow the lang system to load a section or a separate file for that particular "user". We haven't yet implemented any tools that care for the "user" part, nor can anything in Rockbox load user-specific parts/files for voices or languages. It is really how we should proceed to make plugins translatable and voicable, but it just hasn't happened yet. -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: IRC channel
> As an aside, look at how infrequently #rockbox-community is used - this is > IMHO purely because it is one feed too far, one window too many to keep an > eye on. How do you measure "infrequently" ? I've been in there since it was first suggested, and I quite like it. If you're measuring the number of people in there, then yes, it's less popular. But really, how many of the hundreds of people in #rockbox ever actually say anything ? Very few. Most of them have been lurking in there since I first joined, and I've never seen them say a word. But back on topic, I'm going to abstain. I don't mind which road we go down. Like Austin, I don't find having another IRC channel open very difficult to manage at all - but equally I don't mind just ignoring the numbskulls in #rockbox either.
Re: IRC channel
On Wed, 19 Sep 2007, Austin Appel wrote: It seems that we have had a big surge in "annoyances" in #rockbox lately. To put it short, do people think the time has come where we need to move to the split model? In my view we're far from a situation where that is needed, and thus I am against it. Splitting "users" from "devs" (even the distinction is wierd) will just risk that either users sit in a channel where not enough devs are so they won't get the help they seek, or they come to the dev channel to ask the questions since there's where the devs are etc. And I have no need to join two rockbox channels... -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
RE: IRC channel
Dominik Riebeling wrote: >While I'm in favor of cutting down the noise in #rockbox let me >propose a slightly different approach: why not just keep #rockbox for >development and extended support and direct all new users to >#rockbox-community and provice "basic" support there? I.e. just make >cgi::irc to join to #rockbox-community (and possibly allow joining >#rockbox) so all of those basic support goes there, and if a user has >more serious problems just deal with it in #rockbox as we did before? I think it would be easier to switch development talk to -dev, because I would think it is much easier for devs to switch channels than users. In addition, on freenode it is customary to think of a project and just add a hash to the front of it to find a project channel. To have a different channel than plain #rockbox would be confusing. As well, doing it this way would ruin the "community" we have going in -community (which gets quite fun at times) and would just end up with someone trying to make another channel to emulate -community. If anything, making #rockbox-support would be better. Steve Bavin wrote: >I have not found the "user helping" aspect annoying, and it's sometimes >useful to stimulate development ideas. This just started as a short talk in -community and I thought I would send out a feeler to gauge other's reactions to the thought. >if they continue to annoy, why not have a few more channel ops around and >kick them for not following the protocols - i.e. a more strict police >force. I would think we have a decent amount of ops to cover all times already. If you wish for me (and other ops) to be stricter, just say so. I already feel that I am sometimes quite too soft on people (such as DWGR who is now banned), but I prefer that to being a "jerk". Like I said though...if you feel a step up is needed, just say so. The problem I find with many of these annoyances is that they can be quite annoying without technically breaking any of the rules. >I think we should minimise, not increase, any divide between users and >developers. The Rockbox team doesn't divide into two neat groups like that >anyway. I agree and users are more than willing to join -dev. This just would provide a space for devs to talk without having to talk through support conversations. >As an aside, look at how infrequently #rockbox-community is used - this is >IMHO purely because it is one feed too far, one window too many to keep an >eye on. It has been used quite a bit (especially in the last 2 weeks or so) and its use is growing. Plus, it is generally considered to be a fun place to be in. I consider its lower user count due to it being just a social channel instead of a more Rockbox-related channel. As for number of windows, I am joined to around 20 IRC channels and don't find it difficult to keep in line with them. You can always ignore a channel for a while as well. To pay attention to every single line said all the time can be quite difficult and is not really recommended for general IRC use. As I said before, this is more just a feeler for the general dev thoughts on the subject and is less of a formal proposal.
