Is it portable? [scanned]
Hi! Just wanted to know if openmoko will be portable, for example to the XDA Neo. Want to get rid of WinMobile on that device. Greetings, Markus Stehr ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Text entry
On 12/1/06, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote: I found this guy's idea quite interesting a while back: http://www.strout.net/info/ideas/hexinput.html This idea is great. I use the Colemak layout [ http://www.colemak.com ] in place of QWERTY. Shai Colemak has done a heap of research on digraphs (two letter combinations) and would probably be a good person to talk to about efficient hex layouts. David Ormsbee may also be interested in talking to him. I've also used the Frogpad [ http://www.frogpad.com ] which I thought was ok. It needs a replaceable battery and a no lag mode for gaming and other applications. The current model would work fairly well for single handed text entry at up to 40WPM. Morse code beats multitap, but probably not T9 for text entry. It may wear out the touch screen. My vote at this stage would be for hex input optimised by Shai. Of course, the advantage of OpenMoko is that we wouldn't have to choose :-) Ben ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: (text/number/info/notes) input with power of multi-touch :)))) Re: multicolour multi-touch screen Re: OpenMoko/Neo1973 is pure (r)evolution :))) - do you recognized the power of "multi-touch gestu
Hey there, This thread have some interesting other key input systems as well and I like David's demo > http://dave.hereticmonkey.com/musings/phone_keyboard.html but correct me if I would be wrong - this are only single touch concepts. They are single touch concepts, but I think that's important for a phone. I think that the text input system for a phone should still work when the user only has one hand available. I see people using their phones like this all the time. They might be standing on the bus, with one hand holding a railing, and the other holding their phone. They might be walking somewhere while carrying luggage or holding something in their other hand. In all these cases, they've only got the use of their thumb to press the buttons. Then again, it's possible that the advantages of using multi-touch for text input will be so great that it's better to just use it and have a different keyboard mode to drop into if you only have one hand available. I am really looking forward to trying this out when somebody codes it up. :-) Sincerely, Dave ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Text entry
> http://dave.hereticmonkey.com/musings/phone_keyboard.html > Just my two cent idea. Criticisms/improvements are certainly welcome. Did you thought about languages other then English? What about national chars? Switching languages during write? Thanks for taking a look at it. :-) I haven't really considered other languages for the simple reason that I know very little about them. The only other language I use is Korean, and that's so totally different from English that the entire layout has to be rethought for it. I just looked up the Polish alphabet and it looks like Latin + some diatrics. At a glance, I could make it so that this keyboard layout could accomodate the diatric symbols (maybe give a different diatric for whichever way you slide your finger off the key). But I don't know anything about letter frequency, when capitalization occurs, what letter combinations are most common, etc. I don't even think I've got it nailed down for English yet. I'm guessing that making a Polish keyboard that doesn't suck will require someone who's proficient in Polish. Switching to a Polish keyboard layout (or any other layout) would be done either with hardware keys, or an onscreen button... Which actually brings up a question of mine. I did a fair amount of programming for the Palm OS, but almost nothing beyond trivial examples for GTK. Is there some common framework/API that OpenMoko will be using to accomodate various text input modes? Sincerely, Dave ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
SD cards - format (normal/mini/micro) multiplexing, power of SDIO: DVB-H (TV), Bluetooth, scanner... in SD (normal) cards
Salve! This weekend I saw a DVB-H receiver in normal-SD format from nxd: http://www.nxp.com/acrobat_download/literature/9397/75015581.pdf *franky* Well I'm not keen to have TV receiving power with my mobile - especialy when DVB-H is in the discussion that I have to pay a fee to my GSM operator to see a terrestical broadcast - It would be nice for weather cards - but TV not focusing on my region and not on the next 2 hours... So I would prefer LongWave MediumWave DRM.org to get the latest news and wether informations for free and remember Digital Radio Mondeal could transmitt data as well - when Videotex + a wethermap is possible to get via radio - where is the need for seeing TV live? Sports? - I would prefer to see this with my friends in a pub. Local weather news via GPRS or DMR (digital PMR). News maybe downloaded (as diff) as txt and converted to audio with mbrola And a free broadcast medium like mediumwave DRM for free asisstant GPS data would be very fine (and could power up DRM popularaity) But not TV, nor DRM broadcast will be the focus on my mail. (I would think about wireless mailbox systems at train stations, in hotels or camping places - in trains, buses or plains - to download (for free) the recording of last news broadcast, the latest wether forcast... instead of making every mobil to a receiver and than the need to do timed recordings to have the latest news on demand) SDIO is technicaly it is an very interesting point - like compact flash SD could be used for more than just memory. So I joined an interesting talk about the DVB-H card - the softwaredevelopment will be done for the mobile producer - some parts are not equal from the view of the mobile producer their DVB-H solution is better then... - they do softwaredevelopment for linux devices - to sell a few (less then 100.000 in a period) are not interesting for the DVB-H card producer - the DVB-H card producer dislike contact with end consumers - (When I started to talk about a used modificatable phone like a PC) At that point the conversation started to become difficult - no not because I mentioned that TV on a mobile is in my eyes not so important - no the Neo1973 does absolutly not fit into classical mobil device "view of the world". It was also not explainable that when I spend 120 Euro for mobile hardware each year, but do not buy a new one after 2 years but e.g. a DVB-H card for my device the same sales with hardware would be made - but on higher level of products and with more use for me. I feel a dogma - the user has to throw away his phone after 1-2 years. Why not making phones upgradable? As I heard, it would be possible to shrink the size of a DVB-H receiver up to mico SD format - but there is no genious concept for the antenna problem. My idea: Do you know the small Wi-Fi antenna connectors on mini-pc boards? When a phone should be upgradable, I would spend a SD card slot inside under the battery lid and place there a mini antenna connector to connect the already build in (cheap) antenna. - DVB-H powerconsumption (or just video playback) is still a problem - the network operator dislike high power consumption what would reducse the possibility to make phone calls ### # Will the Neo have full support of SD SDIO ? # ### see: http://www.sdcard.org/sdio/index.html http://www.sdcard.org/sdio/Simplified SDIO Card Specification.pdf Then Bluetooth, Wifi, Scanner adapter would be possible to use (be considering the risk due non open source driver) So again, having a full size SD slot would be "nice" as also to have 1-3 additional slots multiplexed by a small circuit (like with the GSM-SIM cards) I could imagine a nomal size SD card with one embedded ARM9 processor with flash and ram and one micro SD slot for more memory. This second processor could speed up grafic things inside the neo, or it runs a seperate system and export it with free-nx (based on no machine nx) tothe Neo. This could be also work for protect commercial software by running it on a not so open/hackable linux or bsd (e.g. navigation system with expensive encrypted map data) Or with a "little more" commerical interrest - embedded DRM receiver/encoder with less size, cost and power consumption then DVB-H needs would be already on the market. Sorry when this mail sounds a little disapointed - of course the technicaly potential of DVB-H is cool and FIC should think about to open the Neo1973 for developing with a normal SD adapters to encrease the potential of the OpenMoko/Neo1973 plattform and to encourage the third party hardware producers to offer drivers for linux, but does this play a role for the v1 of the Neo1973? I think it will take a time until the the Neo1973 will reach a critical mass that third party solution producer will recongnize Neo1973 owner as market - but wouldn't a normal SD adapter spee
(text/number/info/notes) input with power of multi-touch :)))) Re: multicolour multi-touch screen Re: OpenMoko/Neo1973 is pure (r)evolution :))) - do you recognized the power of "multi-touch gesture r
Salve! Ohh it is so obvious wich power multi-touch brings into text input systems :) Remember the newton or Palmpilot regongnition sytems drawing a line like a alpha makes a small "a" -now use two finger nails/tips at the same time to draw this line and it could become a big "A". > Summary of multi-colour, multi-touch > - position of touch > - touch area > - touch intensitivity > - touch moving > - combination with other touch points > - and *new* colour of the touch > > have an incredible potential for input/interactivation Even without colour - the coulor was just a middle stepp for me... First let me say that I do not think that one text input system will be fit/the best for every Neo1973 user and also for every situation. Interaction like normal mobile 2=a 22=b 222=c will be a must have like a virtual querty/querz keyboard. This thread have some interesting other key input systems as well and I like David's demo > http://dave.hereticmonkey.com/musings/phone_keyboard.html but correct me if I would be wrong - this are only single touch concepts. - missing physicalicaly buttons would make using the keyboard bind - focusing on the text that I write or that I like to copy would become unpossible - adding a grid around the virtual keys could help focussing my finger on the right places - SMS input "2=a 22=b 222=c" morsing and other methods are anouing, because it has a sinificant time that you need for coding a key - not with one touch I have learnd grafitty quite fast an can still use it today. But what would be possible without hardware buttons, but with multi-touch? -now use two finger nails/tips at the same time to draw this line and it could become a big "A". This is a foretaste/handsel what new concepts would become possible with multi-touch :))) put your four longest finger together and place over the screen, parallel to one side, or 45° twisted: 00 0 00 0 0 0 Now the recognition (0=touch #=no touch) #0 0# 00 0# #0 00 00 0# #0 #0 00 00 0# 00 in both position would be possible for shure (2x7=14 different keys) Pattern like this 00 0# ## #0 0# #0 ## ## ## 0# 00 #0 ## ## 0# #0 (2x8=16) will be likly possible to recongince relative to the other position from this just 3 pattern will be definite 0 00 0 0 2x3=6 Than the 3 finger could be used: 000 0 00 0 0 0 00 0 2x4=8 mabe also at higher or lower level . So at last this would make 24 pattern for shure or separtion of single fingers 0 0 00 or by using 5 fingers like 000 00 No let us use the same pattern with a little distances bettween our finger (narrow & wide) that makes 48 different pattern for shure (64 likly) with one multi-touch with 4 fingers *without* - movement of our finger on the screen - without special areas on the touchscreen Avery pattern can be moved into 8 direction (up,down,right,left,rightuppercorner...) and the movemend could be directly (in different lengh eg. 1/4,1/2,3/4,1) or with a cirle (e.g. 1/4,1/2,3/4,1) so that would make 64 different movemnts. Without combination or going back (up-down) would it be 48*64=3072 (or 4096) pattern. So again comparing with single touch a multi touch sensor would make it possible to use our fingers in relative position to each other and touch with (one or) more fingers simultanious to create special codes on this to use this with or without movement of the touch for -text/information input -dialing -commands (inside a program/window or system wide) -switching between the programs -input for music -other input With such a multi-touch coded imput e.g 0# c #0 d 00 e #0 0# #0 would it possible to input music without special areas on the screen. Turning it with 45° (positiv direction) it could raise the note with a have step up 0 # # 0 cis other direction it could be a have stepp down "ces" - hearable sliding sound when turning while touching - unhearable and with an accurate cis or ces by retouching. narrow,wide (or just more distance level) could encrease the input over 2 or more oktave Imagene to splite the display into 2 ore more major areas - this could become different instruments - the position could influence the sound level (key dynamic) or the sound itself So instead of a virual piano keyboard such multi-touch input could be used for blind playing as well - with 2 voices/instruments bass and saxophone - and other multi-touch commands could be used to manimulate the simulator - changing the instruments, the sound effects Even without learning playing with to hands such a multi-touch-input system would be fun, because it is dual use - you could use it for writing and making music. So I like to propose to use the power of multi touch for key/text/information input to be able to - Do it blind - Do it fast - Do it everywhere on the screen :) Can sombodey explain how much description/publication of an idea i
Conceptual/Data Framework
I've been thinking a lot more about this idea over the weekend:
http://lists.openmoko.org/pipermail/community/2006-December/000512.html
But it's probably time to present these ideas a bit more
comprehensively to elicit constructive feedback.
Terminology:
transform - takes input, processes, outputs.
data stream - the output to input path
To recap, the purpose is to provide a combined scalable framework for
both the transmission and processing of both data-streams and
arbritrarily abstract concepts. The framework would present a
homogenious interface for all applications, and by passing on
computational load to the framework, applications subscribing to the
same transform could share resources efficiently.
An simple example of a shared set of transforms, might be a voice
recorder which operates at the same time as an incoming call, both
requiring the same level of audio-filtering.
An example of a 'concept' may be 'user availability' (e.g. 0-100) or
'network usage' (0-100). In each conceptual instance, text could
further abstract the pure number - user availability of 0 = "no
contact". 1-10 = "high priority only".
A concept can be constructed from a transform in two ways:
1) Subscribing to 'statistics' of the transform. E.g. subscribing for
a callback every second on an audio transform would keep your
application notified of the higher-level downstream status.
2) From one or more existing concepts or system-states.
I'd say conceptually the system (let's call it
swan - "system without a name", for now) could be broken down into two main
areas:
1) The transform-manager which handles calls/subscription requests -
creates/unloads transforms dynamically as needed. So you have a single
entity which knows the structure of the network at any one time.
2) The transforms/plugins themselves
Since an application never interacts directly with the transforms,
they could reside as shared libraries (e.g. /usr/lib/swan/lib*.so)..
whether the transform is a kernel-module, or a library itself
(undecided - preferences?) the application should just be able to do
something similar to:
#include
...
// Transform Manager as a singleton
//
transformManager *tman = transformManager::Instance();
// Creates a hook into the raw microphone audio device, at a rate of 44k,
// and returns data blocks 1000 milli-seconds long.
//
dataFlow *myDataFlow = tman->subscribe("raw audio input", "rate:44000",
"period:1000");
while ( !mainloopEndCondition ) {
while (myDataFlow->unprocessedDataBlocks() > 0) {
// get access to the data
//
dataBlock *myDataBlock = myDataFlow()->getNextDataBlock();
// ... do whatever you want with the data ...
}
// other main loop stuff
...
}
Now, instead of subscribing to "raw audio input" above, your
application subscribes to "myhomepc:raw audio input", then you've got
the basis for a very powerful application. Except the example above
has no error-checking, but still.
Because all transform-related calls would be directed to the Transform
Manager, the application does not need to worry about how to connect
to other remote machines, that code (Local Transform Manager to Remote
Transform Manager comms) only needs to be written once.
Finally, what is the best way to implement the transforms?
What if each transform allocated a shared memory segment for its
output buffer, and each transform was a self-contained thread? When
the output buffer is full, it could relinquish its share, and pass
ownership onto the next upstream transform or application. It then
allocates a new shared memory output buffer and continues the pattern.
For some data-streams, e.g. video/audio processing.. the buffer size
does not change, only the contents - so by passing on shared memory
segments in a controlled manner, it is possible to avoid expensive
copying.
When a transform has >1 subscriber, only one subscriber could
legitimately write to the same shared memory segment - this could be
handled by the transform-manager.
It would be rather easy to write and redistribute transforms, as the
Framework would be providing all the major hooks and the base classes
to handle the multi-threading/memory segment sharing stuff.
Any thoughts/comments/criticisms/xyz does it already statements, welcome :-)
Cheers,
Richard
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: openmoko on other FIC platforms as well?
Hi Koen, On Mon, 2006-12-04 at 10:59 +0100, Koen Kooi wrote: > Software can't magically fix a slow framebuffer. Last I heard you couldn't > trigger full > redraws at 20fps on the s3c2410fb, so all the decoding power in the world > couldn't get you > fluid playback if you can't get it on the screen in time. Do you have a link relating to this? This thread, and the hardware manual link inside (although the tech-info is lifted directly from the manual) seem to state otherwise: http://lists.openmoko.org/pipermail/community/2006-November/000346.html Framerate is quite significant to me :-) Do you know if the discrepancy a driver issue? Cheers, Richard ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Open Moko - GPL?
On 11/29/06, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote: We will have a headphone support. And yes it's mini. Mobile phones have small form factors and lower power usage requirements. All of these contribute to what hardware we select. Again, we are very open to feedback. If enough of you guys want a 3.5mm headphone jack instead of the (mobile standard) 2.5mm, we will definitely take this into consideration for v2. I have looked at 2.5mm->3.5mm converters. It seems the price for the converter is less that the shipping. I hope you in the package will include a 2.5mm->3.5mm converter. /Ole ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: Can The Proprietary GPS Daemon Be Removed?
On 12/3/06, Dave Crossland <[EMAIL PROTECTED]> wrote: On 03/12/06, Richard Franks <[EMAIL PROTECTED]> wrote: > I'm happy to support open source development where appropriate. I > think in this case though, reverse engineering a proprietary driver > for something as single-purpose as a GPS chip is overly aggressive. > And to what end? The point of Free Software is to drive proprietary software out of existence. I'm sorry to hear that you've been told it was anything other than that. That is the reason GNU/Linux exists, and will continue to exist. If this seems strange, I recommend reading the essay "Why Software Should Not Have Owners" at http://www.gnu.org/philosophy/shouldbefree.html It explains why all proprietary software is wrong, and why we cannot tolerate it if we're to live in an ethical, sustainable, friendly way. I am aware of the arguments - I simply, respectfully, disagree with all-or-nothing idealism. I would love to live in a reality where the goals of the FSF were fully reached, but we have to deal with the reality we're dealt too! > If it is without the cooperation of Global Locate, > then surely they can switch off AGPS access if they choose? Please could you re-explain this - I don't understand enough about how AGPS works to understand what you mean. It's my understanding that Global Locate undertake to supply positional data for the AGPS systems they make. > Even with > their blessing, how long would we expect it to take to improve upon > the efforts of their expert full-time development and QA staff who > surely take into account balancing not only individual unit > performance but that of the overall network? Imagine someone arguing that creating a society where we have free elections, where everyone's allowed to vote, isn't worthwhile because it will take a long time to overthrow a tyrant dictator and set up a senate/congress/parliment. They would be missing the point. Skipping dictators/ideals/voting - the point is how long would it take to reverse-engineer and develop a new GPS driver, test it, obtain blessing from Global Locate? If you think longer than a month, then for the first release, it's a moot point as it's simply not going to happen. > What if we used the open-source replacement and accidentally crashed > their servers in the process? What if someone else crashes their > servers on purpose? It is naieve to expect that if you offer a network service to the public, no one will act in bad faith. Spammers and crackers will come knocking. Therefore I would expect anyone offering network services to maintain good security practices. Efforts to create a good-faith Free Software client for a network service should therefore be unable to crash their servers. FC6 download? ;-) If they need to write better servers, they need to write better servers. Traditionally GPS devices exist in closed-embedded environments - which mitigates security concerns somewhat. I think Global Locate deserve credit for seeing the potential of what the OpenMoko/Linux/GPS/Phone combo could acheive. I know of a lot of small companies who live or die based upon 1-2 low-margin hardware products which they develop. Please explain how it is possible to stop someone reverse engineering a protocol and writing a Free Software implementation. I don't believe its theoretically possible. The difference between theory and reality is that in theory there is no difference between the two, in reality there is. Otherwise we'd all be running open-source ATI drivers, no? > Supporting open source initiatives does not mean that one has to > methodologically seek to remove or replace all instances of closed > source. I'm sorry you've misunderstood what's going on here. That is precisely what the GNU/Linux operating system developers are doing. "The idea is not just to produce a scattering of free programs that were nice to use. Rather, the idea is to systematically build free software so that one can escape completely from non-free software. Non-free software is basically antisocial, it subjugates it users, and it should not exist." - http://www.zmag.org/content/showarticle.cfm?ItemID=9350 The point at which it starts approaching religious fundementalism, is the point at which I jump off the train. I support open source, and I'd love to see every bit of software free. But at the end of the day I don't publicly upload all of my companies proprietry software, because in our reality, that would be unethical. When you start talking of ethical absolutes, regardless of social consensus, you're talking religion. When a developer makes proprietary software available to the public, the code and algorithms are published. If a developer wishes for them to be secret, they are foolish to make them available to the public. This is a belief that no company should be allowed to make money from selling software that they create. There's a difference between the NTP patent trolls, and a company
Re: One Application, Multiple Frameworks (was: openmoko on other FIC platforms as well?)
Hello. On Mon, 2006-12-04 at 11:44, Michael 'Mickey' Lauer wrote: > > I see one main problem with openmoko on this devbices. It is designed > > for phone handling not media player handling. > > We should be able to use the base system, but would need a complete > > new gui and framework design. > > In long term I would really prefer to have _one_ device for phone > > calls, contacts, dates, mp3 and perhaps small videos, navigation, etc. > > Entirely correct. We are at a stage in time where we recognize that we > (application developers) have to solve an important problem to make > usability scale between different devices requiring different UI > paradigms motivated by physical differences. Yeah. That is still a hard task. Moving to dbus and hal is on of the right steps here. As you wrote a abstraction from the toolkit layer could be another. Keep in mind that absrtaction are not cheap. > What we are doing right now is adding more and more #ifdef clauses to > applications or making every application a plugin-host for a variety > of frontend (UI) plugins, but I don't think this will be the way to go > in the future. Ugly and hard to maintain for >3 different UIs. Of course you know the pain. :) regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: One Application, Multiple Frameworks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael 'Mickey' Lauer schreef: > We have KDE and GNOME for the desktop, we (will soon) have OpenMoko for the > phone, > we have Maemo for internet tablets and similar appliances, but we > still lack a way to easily write applications that scale UI-wise. Of course, > we can just cross-compile and run the applications, but they don't > adapt to the look&feel and (what's more important) to the UI paradigms > on the target platform. I would certainly appreciate a platform where an application written with the same toolkit (gtk+) will blend without using a zillion custom widgets. Isn't that what theme-engines and GObject are supposed to accomplish? I can see that a gui like gnumeric isn't going to 'blend in' easily, but apps like reversi should. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFc/6CMkyGM64RGpERAs6lAKC0VwkIKT0aM2auPoF5MhC/QXVTdwCgnG0k OSS5h+74PAKxMD72LyWEeAo= =zC1b -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
GreenPhone lesson
Trolltech's Greenphone: A reasonable first effort http://enterprise.linux.com/enterprise/06/11/27/1937202.shtml?tid=122 I hope OpenMoko and Neo1973 will avoid glitches mentioned there. -- Tomek Z. [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: openmoko on other FIC platforms as well?
On 12/4/06, Stefan Schmidt <[EMAIL PROTECTED]> wrote: In long term I would really prefer to have _one_ device for phone calls, contacts, dates, mp3 and perhaps small videos, navigation, etc. I am currently always carrying my phone and camera with me (Siemens S55 and Samsung UCA5 5mpix). I am currently looking at swapping the camera with Samsung NV3 (which is a camera with PMP). I do not see myself buying a separate PMP. I would love if my phone could cover these applications, too, so I only have to carry 1 device (but a 2 mpix camera phone is just not good enough). /Ole ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
One Application, Multiple Frameworks (was: openmoko on other FIC platforms as well?)
> I see one main problem with openmoko on this devbices. It is designed > for phone handling not media player handling. > We should be able to use the base system, but would need a complete > new gui and framework design. > In long term I would really prefer to have _one_ device for phone > calls, contacts, dates, mp3 and perhaps small videos, navigation, etc. Entirely correct. We are at a stage in time where we recognize that we (application developers) have to solve an important problem to make usability scale between different devices requiring different UI paradigms motivated by physical differences. We have KDE and GNOME for the desktop, we (will soon) have OpenMoko for the phone, we have Maemo for internet tablets and similar appliances, but we still lack a way to easily write applications that scale UI-wise. Of course, we can just cross-compile and run the applications, but they don't adapt to the look&feel and (what's more important) to the UI paradigms on the target platform. What we are doing right now is adding more and more #ifdef clauses to applications or making every application a plugin-host for a variety of frontend (UI) plugins, but I don't think this will be the way to go in the future. Eventually -- when we have more experience with the variety of such frameworks -- we need to come up with an additional abstraction layer that allows us to describe all these specifics in a way that applications can transform automatically to the target environment. Regards, :M: -- Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: openmoko on other FIC platforms as well?
Hello. On Sun, 2006-12-03 at 23:29, Sean Moss-Pultz wrote: > On 12/3/06 11:26 PM, "Koen Kooi" <[EMAIL PROTECTED]> wrote: > > > I just noticed this: http://www.fic.com.tw/product/pmp.aspx > > > > Is FIC planning on putting openmoko based (open!) firmware on those as well? > > > > regards, > > We haven't talked in great detail about that yet. Right now we're mainly > focusing on phones. But would you guys be interested in stuff like this, > too? Of course it would be interested to have a open system on this devices, too. I see one main problem with openmoko on this devbices. It is designed for phone handling not media player handling. We should be able to use the base system, but would need a complete new gui and framework design. In long term I would really prefer to have _one_ device for phone calls, contacts, dates, mp3 and perhaps small videos, navigation, etc. I know that this will still take some time time, but I'm looking forward to this. regards Stefan Schmidt signature.asc Description: Digital signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: openmoko on other FIC platforms as well?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas MARCHESSEAU schreef: > Koen Kooi wrote: > slubman schreef: > Le Lundi 4 Décembre 2006 09:16, Gabriel Ambuehl a écrit : > On Sunday 03 December 2006 16:29, Sean Moss-Pultz wrote: > >> We haven't talked in great detail about that yet. Right now we're >> mainly >> focusing on phones. But would you guys be interested in stuff like >> this, >> too? >> > Personally I'd prefer it if the Neo1973 could act as PMP I sure > won't > carry 2 devices with me... > I'm sure the OpenMoko will have some media player, so it will be possible to use it as a PMP. That's one effect of the "Open" platform. > > The software side isn't a big problem, the hardware is. s3c2410fb > isn't what you would > call fast, and certainly not for 16bit vga. > > >> Hi Koen, > >> My team has cross-compiled Mplayer for a Qtopia Linux phone (Wistron , >> taiwain) , its an OMAP1710 ARM9 at 200Mhz (95Bogomipis) , and we can >> handle 220x176 mpeg4 video at 20fps . The omap1710 in my nokia 770 does 400x240 at 25fps using gstreamer. But keep in mind that the s3c2410 doesn't have dsp to offload the decoding to. >> im pretty sure openmoko can do >> much more . Software can't magically fix a slow framebuffer. Last I heard you couldn't trigger full redraws at 20fps on the s3c2410fb, so all the decoding power in the world couldn't get you fluid playback if you can't get it on the screen in time. >> I read somewhere in this Mailling list that OpenMOKO will embed Mplayer >> too, If OpenMoko's team are interrested im ok to have a look on Media >> player possiblity on this device, Our mplayer's optmisation would be >> released soon, all is GPL That would be cool indeed. Are you going to push these upstream to mplayer svn as well? regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFc/F5MkyGM64RGpERArtxAJ0Vdt52FnoqBsn6zRXiQjrsZxQQbwCfcu/N LGnKE05YKU15INa+xeQJOVs= =jdl/ -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: openmoko on other FIC platforms as well?
Koen Kooi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 slubman schreef: Le Lundi 4 Décembre 2006 09:16, Gabriel Ambuehl a écrit : On Sunday 03 December 2006 16:29, Sean Moss-Pultz wrote: We haven't talked in great detail about that yet. Right now we're mainly focusing on phones. But would you guys be interested in stuff like this, too? Personally I'd prefer it if the Neo1973 could act as PMP I sure won't carry 2 devices with me... I'm sure the OpenMoko will have some media player, so it will be possible to use it as a PMP. That's one effect of the "Open" platform. The software side isn't a big problem, the hardware is. s3c2410fb isn't what you would call fast, and certainly not for 16bit vga. Hi Koen, My team has cross-compiled Mplayer for a Qtopia Linux phone (Wistron , taiwain) , its an OMAP1710 ARM9 at 200Mhz (95Bogomipis) , and we can handle 220x176 mpeg4 video at 20fps . im pretty sure openmoko can do much more . I read somewhere in this Mailling list that OpenMOKO will embed Mplayer too, If OpenMoko's team are interrested im ok to have a look on Media player possiblity on this device, Our mplayer's optmisation would be released soon, all is GPL Thomas regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFc+hZMkyGM64RGpERAqPgAJ4kOCMcI8bt0OhR4rzcV017gWhVpwCfalm9 RgDUGfqdeErNpR4TCcovp1I= =Hai2 -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: openmoko on other FIC platforms as well?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 slubman schreef: > Le Lundi 4 Décembre 2006 09:16, Gabriel Ambuehl a écrit : >> On Sunday 03 December 2006 16:29, Sean Moss-Pultz wrote: >>> We haven't talked in great detail about that yet. Right now we're mainly >>> focusing on phones. But would you guys be interested in stuff like this, >>> too? >> Personally I'd prefer it if the Neo1973 could act as PMP I sure won't >> carry 2 devices with me... > > I'm sure the OpenMoko will have some media player, so it will be possible to > use it as a PMP. That's one effect of the "Open" platform. The software side isn't a big problem, the hardware is. s3c2410fb isn't what you would call fast, and certainly not for 16bit vga. regards, Koen -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iD8DBQFFc+hZMkyGM64RGpERAqPgAJ4kOCMcI8bt0OhR4rzcV017gWhVpwCfalm9 RgDUGfqdeErNpR4TCcovp1I= =Hai2 -END PGP SIGNATURE- ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: openmoko on other FIC platforms as well?
Le Lundi 4 Décembre 2006 09:16, Gabriel Ambuehl a écrit : > On Sunday 03 December 2006 16:29, Sean Moss-Pultz wrote: > > We haven't talked in great detail about that yet. Right now we're mainly > > focusing on phones. But would you guys be interested in stuff like this, > > too? > > Personally I'd prefer it if the Neo1973 could act as PMP I sure won't > carry 2 devices with me... I'm sure the OpenMoko will have some media player, so it will be possible to use it as a PMP. That's one effect of the "Open" platform. Greetings. -- slubman (aka Nicolas DOUALOT) mail: [EMAIL PROTECTED] Jabber ID: [EMAIL PROTECTED] site: http://www.slubman.net ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
Re: openmoko on other FIC platforms as well?
On Sunday 03 December 2006 16:29, Sean Moss-Pultz wrote: > We haven't talked in great detail about that yet. Right now we're mainly > focusing on phones. But would you guys be interested in stuff like this, > too? > Personally I'd prefer it if the Neo1973 could act as PMP I sure won't carry 2 devices with me... pgpqncBrxDniw.pgp Description: PGP signature ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community
