Rockbox Developer Conference - West Edition! 2007
When: June 15th - 17th
Where: Las Vegas, Nevada
Many of us have sat back and looked at the previous Devcon and even this coming one and have been saddened at it being too far or too expensive to attend. Well, it was talked about last year, but this year we decided to do something about it! This page is to be used as a place for storing all of the information instead of having to go through the thread and to have a better picture of it all.
Discussion about it is held on the Dev-mailing list starting with this thread http://www.rockbox.org/mail/archive/rockbox-dev-archive-2007-04/0009.shtml
Post-game wrap-up is here: http://scorche.cleansoap.org/rockbox/dcw.html
The location will be in Las Vegas, Nevada. This is due to an attempt to get as many people as possible to attend and travel costs. It will be held in a suite in the Signature at MGM Grand (http://www.signaturemgmgrand.com/
Address for the Signature is: 145 East Harmon Avenue Las Vegas, Nevada 89109
DevCon-West is to take place on June 15th - 17th.
Here's a list of persons who are planning to show up. Please state your current status in parentheses after your name.
- AustinAppel (Will be there - of course)
- PaulLouden (Noon on Friday, departing ~7:45 Sunday)
- BrandonLow (Flights booked -- arriving @10:55pm on Friday and departing @6:00pm on Monday)
- AdamGashlin (US Air flight 2890 in @ 11pm Friday, US Air 2892 out @10:50pm Sunday)
- DavidHall (Delta flight #843 in @ 11:30am Friday, Delta flight #724 out @ 1:30pm Tuesday)
- ChristopheNicolas(until now, no problem, I should be there around 3pm on Friday)
- JoelSnyder(Southwest Airlines Flight #832 in @ 11:00 am Friday, Southwest Airlines Flight #1554 out @ 11:30 am Sunday)
Since we can code and IRC at home, too, we should focus on helpful group activities.
- Get to know people
- Go out shopping (for snacks, food, electronics, etc)
- Discuss agenda for the rest of the Devcon
- Discuss the ability of people to come for next year's combined DevCon
- If time (and money) allows, go out for a farewell buffet brunch
- Say goodbye
Ideas for discussion:
- Discuss DevCon2007 decisions
- Perhaps working on the flash of the gigabeat. ChristopheNicolas will bring all the tools for this (interface, solder iron , mulitmeter, oscilloscope)
- Enforced licensing of WPSs among other inconsistencies in WPSs (SoapSealofApproval)
- Viewing of Google PP in OS (don't try to understand this, this is something I want to remind myself of later)
- Infrared/micro-DAP module, RockIR (Remote control for sure, hopefully we can make FIR data speeds on the IrDA component during DevCon-West) Btw, maybe we can sell these modules for the Rockbox Fund? Please contribute to the wiki for ideas, I need as much input as possible to make this happen! -- JoelSnyder
- How Neuros' N3 should be made!
(This list is being defined and likely will depend on what happens at DevCon2007
Bring your own laptop and DAP devices of choice. We'd need enough power outlets for wall-wart chargers. A USB hub might be helpful. A webcam for friends who can't attend physically would be great.
- Infrared Module Prototype - JoelSnyder [Sadly, I doubt I will have the DAP made, but I should have some sort of gadget ]
- Decent camera for posterity - anyone? (AdamGashlin has a Canon PowerShot A640 that he'll probably bring along)
From Airport to The Location
From McCarran International Airport:
- Exit the airport North towards Wright Bros. Ln.
- Turn slight right onto Swenson St.
- Turn left onto. E. Tropicana Ave.
- Turn right onto Koval Ln.
- Turn left onto Harmon Ave.
- Turn left into The Signature at MGM Grand.
Due to the valet nature of the hotel, AustinAppel
will not be able to go back and forth between the hotel and the airport. It still might be possible to have some be picked up though.
Be aware that not all taxi drivers know the Signature yet, as it is relatively new (most should by now though). Some know it as "the new towers at MGM Grand".
You'll find that many people will speak at least some
might participate depending where he is at the time and does have a car.
In the suite with AustinAppel
While discussing themes, one of the first topics to come up was the fact that the terms WPS and Theme seem interchangeable, and this can, on certain occasions, cause difficulty, especially when attempting to support something not working as intended, or when a very specific meaning is meant in technical discussion. Because of this we decided that we should do what we can to promote or clarify the distinction between WPS (meaning specifically just the .wps file and associated
bitmaps) and Theme (meaning the .cfg file, and all files it references).
One thing that was not decided is what fundamental elements define a theme (which lines, at a minimum, must a theme contain to be considered a theme) nor the maximum extent of what it encompasses (for example, is the status bar, display of scrollbar, etc, considered to be a part of a theme at this time, or does a .cfg file containing these options go beyond the limit of what a theme is). Both of these are mostly irrelevant though, since it can be summarized roughly to "A WPS is a .wps file, a theme is the common category of .cfg files that loads WPSes and changes the appearance of Rockbox"
Another point that the developers at DevConWest agreed on was that the current wiki system is not able to effectively meet our needs as a theme gallery, especially with increasing copyright concern and the desire to ensure that the themes themselves are functional. As well, it would be ideal to have RBUtil able to retrieve themes from our repository rather than a third party site that is beyond the control of the project. To this end it would be ideal if conversation with RedBreva could lead to something that meets what we felt were ideal requirements, and if not, hopefully find someone interested in developing a new theme gallery on official webspace meeting those requirements. The first requirement, obviously, is that themes are made available in a way that RBUtil can parse and retrieve them.
The others are as follows:
- The gallery would use a standalone .wps validator to ensure that the file will load. The only thing this confirms is that the .wps will load, and not be rejected by the parser. Any theme containing a .wps that does not pass this will be rejected and, if possible, the author will be emailed notifying them of its failure to pass. If not, a list should be created that those maintaining the gallery can check for rejected themes and contact the author.
- Themes must archived in such a way that extracting them into the root of the player preserving folder structure should properly "install" them. This too should be achievable with some sort of validation script or program. Ideally only one step of the 'approval' process should require human intervention.
- Themes must be under a license that allows redistribution. To this end they must contain a .txt file of the same name as the theme archive that contains what license the theme is under, contact information for the author, and any extra licenses should images and fonts used by the themes come from other sources. This is the human step of theme verification: A human being will check that the .txt file exists and appears to meet the requirements, and check that the two screenshots (menu and WPS) of the theme do not have any apparent copyright problems.
Unfortunately we did not manage to create objective copyright guidelines, as we aren't sure where copyright falls on issues such as actual interface layout, vs reproduction of graphics, and probably need a wider set of minds discussing this. The current candidate for suggested license of the themes is the Creative Commons Attribution + ShareAlike (by-sa) license. We felt it would be ideal if there were only one license for themes, but as media included in the theme may be under other licenses that allow similar use, it may be better to instead have a list of requirements from the license, and then list one (or a few) licenses that allow them.
- No fonts should be included in the .zip unless they are not an official font (part of the fonts archive on the extras page). This is to prevent accidental replacement of current versions of fonts with outdated ones.
- The theme must be designed only for an official SVN build of Rockbox (there is a plan for unsupported build themes, which will be discussed a little further down.)
To go along with these restrictions, the current theme wiki pages will be marked as deprecated upon posting of the new gallery. All themes with clear license statements will be migrated and the rest will be left as they are until the original author or someone with the authority to do so submit them to the new gallery with the appropriate license information and any required changes.
All themes will be divided by screen resolution only. To this end, we expect to have to fix some WPS tags to validate, and not break formatting, on targets without the equivalent hardware. For example the patch to make the RTC display hyphens when not present, so as to take up the same amount of space (assuming fixed width fonts, felt to be a fair assumption if the formatting depends on character width anyway). Some other tags may need to be examined (hold switch, virtual LED, etc) before this is complete, but would allow more flexible interchange of themes, and mean the requiring of only a single validator.
Several humans will of course have to monitor the step requiring human validation, but it was felt that as checking the license and screenshots is likely to only take a matter of minutes at most, this should not be a real problem.
For themes that require an unsupported build, there are further requirements and a few changes:
- The validator will not be run, as it is impossible to have one for every combination of patches. All pages will therefore contain warning both on the fact that the themes require patches, and that they have not been tested for whether they work by anyone but the author.
- All themes must include in their .txt file a list of "official" patch names (the name given to the patch file by the author at Flyspray) as well as the Flyspray number under which the patch can be found. Themes requiring patches that are not still open on Flyspray, or that weren’t on Flyspray at all will not be accepted.
The reasoning for this follows: We feel it is good to encourage people to try out new and upcoming features and help bug test the patches. At the same time, we feel that any official gallery should contain only patches hosted by us (and thus findable by the interested user), as well as all unsupported themes should be at least in some way related to the advancement of the official Rockbox as it is the official gallery.
Unfortunately, this means some themes requiring patches currently available may not be able to be added to the official 'unsupported'
These guidelines are of course open to comment, and any one of us will be more than happy to attempt to explain the reasoning that reached each of these conclusions. To follow on this, if RedBreva is not interested in moving rockbox-themes.org in line with whatever the final decision meets, we decided he should be asked to change his sidebar (or remove it) in a significant enough manner that it is very apparent his site is not official, and to attempt to make sure it is clear to users that rockbox-themes.org is not a 'supported' supplier of themes (in the sense that if things there do not work, it is not our responsibility or fault).
Another hot topic was the question: "RBUtil - What is it, and what should it be?" In the end the general consensus was that there's no real value in limiting RBUtil to an installation utility. It's clearly already becoming more than that, and there can be a lot of great value to the end user from it. But there is also the possibility of it becoming large beyond need with music management functions or other incorporated functionality. To that end it was decided that a currently ideal target would be to have it do exactly what the name suggests: Be a utility for bridging the gap between Rockbox and your PC. To this end, some example features that would be nice to see added include font conversion (from TTF ideally, though BDF should be sufficient), database generation, and video conversion. Where the tools already exist within the /tools/ folder, we see no problem with incorporating them directly.
As well with minimalistic additions, such as perhaps otf2bdf or similar, this should also not be a problem. Where a larger freestanding program exists, such as VLC or ffmpeg (or whatever video converter is chosen) RBUtil's functionality should then instead be as a front end (functioning similarly to WinFF's interaction to ffmepg, for example).
RBUtil should not handle music management: All operations should take place either to files or data on the player, or be in some way necessary for Rockbox to make use of the file (such as font or video conversion, music conversion was not discussed but due to Rockbox's incredibly wide support should not be a real concern.) Syncing and other collection management functions (tag editing, etc) should not be among the features it performs as these are best left to programs designed for them, and do not really qualify under the above categories. Beyond this we think it would be wonderful to see RBUtil expand beyond its already impressive state to wherever it may go, as long as the focus is always clearly Rockbox functions.
Badger Badger Badger
AHHHHHH! A snake! A snake! Snake a snake! Ohhhhh....it's a snake.
Summarized to "We agreed that it's a great tool, but it's hard to tell if the benefits of conversion outweigh the effort of moving over, since the current solution does
just work right now."
Although Next DevCon wasn't discussed thoroughly, we felt it might be best to alternate between here in the US and in Europe, rather than trying to have it in the same place each year. That way those who can't afford the trip at the more distant location at least might be able to make it to half of them, and those who are able can attend all. It was suggested and thought a good idea that we might consult a travel agent (or similar specialist) on locations for it, under the assumption that the up front cost might help us discover locations that are significantly cheaper or more accessible than those we might otherwise look at, probably benefiting all future DevCons.
Things worked on
- Gigabeat S (a bit of progress, Toffe and Joely tried to use qemu to run the firmware but had some trouble doing it. Just before leaving the hotel, ptw419's last bootloader wrote on the console port. This means that we can send a message to the console to debug)
- Coloring of different extensions, different user-specified colors in the tree (committed)
- GBS codec (runs realtime on the Gigabeat, and is in the process of being optimized enough to run realtime on other targets)
- Make RTC tags display hyphens instead of nothing on non-rtc targets (committed)
Copyright © by the contributing authors.