/edit3: MOST THINGS EITHER already implemented in trunk OR added to the bugtracker!/edit: finally it is done. actually i think about seperating this thread into the poll/features and thread for discussion - opinions, anyone?
/edit2: will open a new thread in feature request forum about the features. it will not be stickified though, as it will only be linked to from this very thread.hm.. or will it?
Link to poll:
CLICK ME!Hello everybody,
today i want to put some structure into the development of chdk. chdk continually grows larger (as in larger code base/more features, larger list of compatible cameras, larger group of developers and finally a much larger group of "customers/users"). This is happening for a lot of reasons, however this development also introduces some problems.
To adress some of the problems some threads have been created already (
1 2 3)
Now for the actual intention of this thread: it *should* depict the current
status quo, as in what features are currently in the making, how is the progress and who is doing it. it also should list all the features that either are requested by the community, by other devs (including me), including an estimate on the possibility of such a feature. it *should* also list some kind of "dependency list", as in for example for a slideshow function CHDK needs to know the filetype of the current shown item (need function in asm for this feature to work). it *should* give potential developers an overview over "vacant jobs" or "pending jobs". it should also list if coding will be easy or hard, time consuming or fast, needing good ASM/IDA pro skills or other skills. some features will depend on other features to be implemented first. i hope i can create such a table. i also will supply links to corresponding threads (if existing). Some features are even coded ready yet & just need to be put into trunk. i will
mostly (not only) add features here
I think are POSSIBLE to implement and to some extent - useful. My assumptions are derived from my work with either chdk, the camera itself and my experience as a coder (also from reading so goddamn many posts in this forum). mind you, i am a human and humans often make mistakes. i will also in a lot of cases supply info on how something could be implemented or where (in the code). a feature description in more detail.
i know this would actually better work and of course be more comfortable with a fully fledged bugtracker. this is already in the making.
As for the developers, please comment, rectify, validate my post or add valuable information. This is NOT supposed to be a feature suggestion thread, so please refrain from posts like "i need this and that". this thread *should* be dev only (dev as in: someone who considers himself a dev, be it an "official chdk dev", an inofficial or even someone who is capable of coding but hasnt touched chdk yet), the average user can use the poll to express his opinions though.
If you have found some threads that can be linked to a specific feature, please tell me. also tell me if you have a feature that has to be included in the "must-have" list, and please state why.if you are a developer, please also state your estimation on
feasibility.
As of now i see these main fields:
- Interface Optimizations/Optics/Look & Feel
- Actual Functions
- Information, Help system, Documentation (not *really* a classical DEV field, but should be mentioned anyway)
- Misc. Stuff
okay, i tried to categorize each feature/requirement, and also somehow sort them, but since these are so many, this is was very difficult for me. comments welcome. mind you: the "priority" estimations are based mostly on my OWN personal opinion, they are prone to being different from yours, i NEED comments on these.
PLEASE don't bash me if i havent listed your feature request. Or if i listed it but rated it with a low priority. Or if i listed it and provided wrong information or made wrong assumptions regarding it. Or if you think this thread sucks. Please be reasonable and always provide arguments should you criticise something
Link to poll:
CLICK ME!colors:
red - no implementation yet (needs maintainer & code)
green - implementation ready (has "maintainer"), needs more testing and/or adding to trunk
orange - sort of already written (basic functionality present), needs maintainer & more coding/testing & ideas
brown - the "stupid" jobs that nobody wants to do, usually afford no great skills. still need time & energy though, and some social skills
/edit: i know i didnt do the colors right in every item, i will update them later sometime.
Interface Optimizations/Optics/Look & Feel - to look more "professional" and pleasing to the eye - overall average importance - above low.
01 - osd text size - chdk as of now does NOT allow the changing of the OSD font or size. for some people the font is too small. rating: difficult, alot to change, but possible. priority: well, _I_ can read the font, but i understand it is too small for people -
added to bugtracker02 - symbols in menu - in the making @
here. maintainer: CHDKLover. Status: Pretty much done, needs finetuning maybe. Lot of code additions/changes, thus difficult for adding to trunk - but possible and certainly very useful.
Update: IS IN TRUNK!03 - symbols in OSD - right now CHDK uses very few symbols (battery for example) in the OSD, the more the better, maybe even with colors (more friendly to the eye, professionally looking), like the canon symbols. rating: requires good imagination & some skills using the DRAW functions. NOT important though
added to bugtracker04 - overall "smoothness", "round corners" - again pleasing to the eye. like CHDKLovers mod which enhanced the beauty of the CHDK menu vastly. he introduced draw_round_rect (dont know the exact name right now)
Information, Help system, Documentation - without proper documentation, every product is only worth a quarter of it's full potential - no users, no income (exception: Microsoft, their budget on adverts excels proper documentation
). while this is an opensource project with no income, it still needs users. For this, we need proper documentation and maybe a help system.
05 - on screen help - in the chdk menu, for every item there *should* be an entry telling you what it is for, much like the help-popups in MS windows. these entries should be language-dependent and also be switched off (for the advanced user). depending on the actual implementation the difficulty for this ranges from easy to difficult. possible: yes. would greatly enhance usability.
Update: Microfunguy does something similar in StereoDataMaker, maybe it will find its way into trunk/branch as well added to bugtracker06 - beginner or advanced user - When CHDK is first installed, it should be set to "beginner" mode, activating the on screen help and maybe deactivating some "dangerous" or confusing items (like debug menu). you can also colorcode the "features for the experienced users". useful for new users or your little sister when you give her your camera so that she can play reversi (and NOT change all your chdk settings). maybe add a special "locked" mode, a mode you can only use preselected items (like games), and access to the original canon menus is forbidden (i.e. format is disabled). possible: yes. difficulty: somewhere in the middle between easy and difficult (imho), depending on actual implementation.
added to bugtracker07 - more languages - not really a coders job, but a dev imho has to integrate these into trunk, so that the autobuilds/release will have the languages already included (no need to search the wiki!). easy (well of course you need to speak a language different from english
). also, put some of the best scripts into trunk and subsequently into an autobuilded archive.
Update: INCLUDED IN TRUNK!08 - archives with readme files included - talked about
damn, i can't find the link anymore..., well basically it was like this: include a readme.txt file directly into the archive (for this the makefiles need to be changed and of course a readme must be written in TEXT form, maybe also multilanguage and depending on camera, at least dryos or vxworks), perhaps adding a new command for compilation, like "make batch-zip-doc" (includes docs, lang, and maybe scripts etc - compressed easily). i nominate GrAnd as the maintainer as he is the GrAndmaster of Funk, uhm, of Trunk! possible: yes. difficulty: needs makefile skills and some documentation skills. priority: pretty high i would say.
Update: INCLUDED IN TRUNK!09 - readme files automatically created on sd card - kind of obsolete as soon as the previous item/feature is implemented, still can be of use. autocreation of readmefiles (and maybe even scripts), so they can be read in textreader. this requires them to be HARDCODED into chdk, which in general is NOT a good idea. maybe it is useful for a small "basic guide for chdk noobs". possible: yes. difficulty: easy. priority: very low.
10 - documenting the existing code - well, that has to be done, in order for future devs to not have such a steep learning curve. somebody has to do it though. possible: well, yes, sir! difficulty: easy. skills needed: knowledge of chdk, C and ASM (and makefiles). priority: low (come on, most coders can read sourcecode :p).
added to bugtracker11 - writing readmes, tutorials, faq in wiki - see
1 2 3 - has to be done to minimize confusion and to get more users. easy, yet a "stupid" job, very boring.
12 - translating all this stuff from the previous item - (apart from the dev stuff) into other languages.
Misc. Stuff - stuff that doesnt fit any description
13 - create ONE chdk - this is a personal feature request i hope some devs will find useful: minimize confusion, rename the current trunk/build to just "CHDK". As of now, the last 1000 revisions have all been added to the allbest trunk (or so it is called in public), and the people seem to use either chdk allbest or SDM. so my vote is to rename "CHDK allbest" into just CHDK. So the only thing we need in bugreports in the future is the buildnumber and the cameramodel, not the "chdk flavor". it is very confusing for beginners. no, i dont want to steal Allbests fame or somehow criticise anyone! just make things easier. that said, my role of being mod also forces me to question the existance of all the subforums for all the other builds (most of them are dead, the allbest one can be made the "default one", SDM basically has the yahoo group) - to not clutter up the forum. difficulty: easy. priority:
IMHO quite in the middle. skills: being an SVN admin, makefile skills. Ability to let go of ancient traditions (j/k
). i announce GrAnd as maintainer of this
Update: INCLUDED IN TRUNK! YAY!Actual Functions - this is what it's all about - the actual features of chdk. be it small gadgets (games), functions for photographers (overrides) or things like LCD energy saving options. these items are in NO particular order, mind you. they may be sorted later, depending on difficulty, status or priority.
14 - camera benchmark - not only lcd screen and write speed on sd card. i'm thinking more of speed as in how long does it take to take 10 shots burst? how long will the battery last? how many shots before battery fails? some sort of generic benchmark. before this can be useful, the mode dial override has to be implemented (to simulate the different modes) and also override of the playback/rec switch (this feature will be explained later). it somehow could be implemented as a script, but for this to work one would have to override a lot of settings (review time for example). difficulty: high. priority: very low. useful: probably.
in bugtracker15 - shutter activation through microphone - remote shutter by shouting for example. needs great skills in ASM, as for this the binaries have to be analyzed in IDA pro. Find out if the mic can be activated not only during movie mode, find out if the mic can be accessed regarding its output, gain. on S-series, the gain can be set to one of 5 levels, just a hint. possible: i don't know, maybe. difficulty: high. useful: yes, very much (clap-o-photo). priority: well, if the mic can be accessed, this will not only lead to the remote shutter feature, but to probably a lot more useful features (for example: MUTING the microphone when taking a picture while you are shooting a video on s-series. as of now, the mic records the mechanical shutter, which is annoying when you record a concert of classical music). update: jus read
changeset 395, ewavr found a way to mute the microphone. yay. thus the spwaning of the next feature request:
in bugtracker16 - muting the microphone - in s3is, when you record a video and take shots during that, the shutter is recorded to the audio track of the video. this is very annoying. please EWAVR, find a way to mute the mic in the moment you fullpress the shutter for about a second. there might be other benefits: for example when you want to record JUST a video, with no sound at all - mute the whole video. *Maybe* you can even save some space this way? disable wav recording alltogether... i'm just dreaming here
Maintainer: i announce EWAVR. difficulty: for EWAVR, nothing is impossible
useful: yes. priority: probably low.
in bugtracker
