Request [was: Neither iPhone or OpenMoko are revolutionary]
Am 18.01.2007 um 20:23 schrieb Renaissance Man: Hey, no problem. Sorry for being so inconvenient as to have a different view to start with. I know how awful it can be for people like you if others don't think the same way as you to begin with. We certainly have no problem with people that think in other ways. Thats what the freedom in NEO 1973 is all about ! What I do have a problem with is someone who wants me to think as he does. May I ask the list to start, where appropriate, new threads, with more specific subjects? That way it is easier to follow the different discussions that evolved from this thread... Thanks & Cheers, Thomas Seiler ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Power for USB Host
Hello, Found this nice little project: http://ladyada.net/make/mintyboost/make.html 5 volts at 100ma (i.e. for usb memory sticks / card reader) out of 2 normal AA / AAA batteries. It's even possible to use their PCB design, just need to replace the resistors on the D lines with a mini USB cable and plug it into the Neo1973. Now the big question: Are there any usb wifi sticks out there that can work with ~100ma? Cheers, Thomas Seiler ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Itch1: Spell weaving
Hello, I like your idea of spell weaving very much. Unfortunately... Latest word seems to be that Neo1973 will be single touch only and this is hardware limitation. ...which is sad. I suppose the neo1973 is using a resistive touch-screen. (http://en.wikipedia.org/wiki/Touchscreen#Technologies) Therefore we can't hack the existing touch-screen to be multi-touchable. However, I don't give up easily. I have seen that cypress produces a series of mixed signal MCUs (http://de.wikipedia.org/wiki/PSoC). They have everything on-chip that is needed to build a capacitive touch controller. they are not so expensive and the assembler / IDE is free (as in beer). And the performance is not so bad: apple used a PSOC chip for the clickwheel(tm) in the ipod mini series) By going the capacitive road, it should be possible to have multitouch as long as the two touchpoints are not to close together. (this is basically how modern touchpads for notebooks are build) By locking at the size we will probably need to split the display into upper and lower half and have two independent controllers. So in order to hack this up, we would need: Hardware Side: - Someone who can sputter indium-thin-oxide onto a glass-substrate Alternatively we might use an old resistive touch-screen for first experiments. - Someone who can etch a pattern into this. There we need someone with knowledge in chemistry . (the pattern we need can be seen on one of the pictures in the PSOC wikipedia article) - Oh, and we would need solder points inside the Neo1973 (SPI / uart / gpio) to connect an alien MCU like the Cypress PSOC. Software Side: - kernel level device driver that emulates the interface of the old touch-screen. - A new device to access the multi touch information. - X pointer abstraction ? Dont know nothing about X. - Some gesture detection ? Dont know nothing about markov. So is there anyone on this list interested in building such a prototype ? Anyone with experience in working with Indium-Thin-Oxide or other transparent conductors ? Anyone who knows how the x pointer stuff works ? Or how to write a gesture detection algo ? This would really be fun ! Cheers, Thomas Seiler ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Better keyboard?
On Sat, Jul 12, 2008 at 12:22 AM, Jim Morris <[EMAIL PROTECTED]> wrote: > Are there only the two keyboards for freerunner? > > I have tried the matchbox one from the site, and it is way too small for my > old eyes to use. A while back I have implemented a few improvements to the matchbox keyboard: - a different color scheme that is less stressful for the eye - popup to see what is currently pressed. http://docs.openmoko.org/trac/ticket/350 http://www.seili.net/openmoko Cheers, Thomas -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Better keyboard?
Hi Jim, thanks for testing! Indeed, I dont seem to wait for the popup window to be mapped before drawing onto it. This is a bug (tm) of type race condition. (The Freerunner has a faster CPU, and the bug gets visible :-) Bug is identified, will post a fix later today... If you want to fine tune the color scheme, that can be changed quite easily without recompiling the keyboard. The XML keyboard definition files contain a block similar to this: the numbers are HEX encoded RGB triplets, as is used commonly on the web to encode colors. With a color picker tool and a text editor you can change the colors to match your preference. If you have other ideas on how to improve the usability of the keyboard on Freerunner, please let me know. : ) Cheers, Thomas -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Operation without battery (GTA02)
> | What's the advantage of enabling the charger? > > Well without it literally it won't charge the battery from USB power. > It's fine to enable it except when it notices there is no battery there > for some reason. Question: Would it help to query the ADC and check for some battery voltage prior to enabling the charger help to keep the Freerunner switched on in this case? Cheers, Thomas -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone-video problems!! Help !
Hi c_c, thanks for bringing another superb app to the neo! I'm not an X11 expert, just trying to answer some of your questions here... If I babble nonsense, please correct me. > 1. I finally found out that I can create 2 windows using elementary, > 1 for mplayer to play the video in (using -wid) and one for the controls. > I've sized the windows to 640x400 for the window where the video > shows up and 640x80 for the controls. But I can't seem to get to > see the main window (the one that has the controls) at all. It > works fine on my desktop - but I'm not using illume there. The problem is that your windows will end up stacked ontop of each other, and here is why: In X11, you do normally not position your windows on the screen. You have a separate process, the "window manager" or WM, that takes care of this task. That way, the user can finetune the behaviour of this desktop in one place, instead of having to tune each and every app separately. When you create a new window, the window manager will be consulted and will come up with the best position/size for that new window. It will also draw some decorations around it (border, titlebar, icons), so you have a consistent look. On your desktop, where you have plenty of space, the best policy for the WM is to arrange windows such that they don't overlap too much. On the neo however, where screen space is a premium, the default strategy is to maximize and center each window and forget about the borders, titlebars and stuff... Both of your windows will simply be maximized and the one you create later will end up on top of the stack. That way, you loose your controls. > 2. The video playing window is centered on the screen. Is there a way I can > set the positions of these window's? Or do I need to look for a different > solution. There is a way to have absolute control over the window by overriding the window manager: EAPI void ecore_evas_override_set(Ecore_Evas* ee, Evas_Bool override); or in elementary: EAPI void elm_win_override_set(Evas_Object *obj, Evas_Bool override); If you do this, the WM won't touch your window, and you will have to position and size it yourself. Be aware though, that you also will have to take into account any bars (taskbar / titlebar etc...) as you now work with raw screen coords. Usually, you have a normal window that is placed in the usual way by the wm. You learn it's size and raw coordinates on screen and place the overridden window such that it fits inside. > 3. Is there a way to embed a window in the main window of an elementary app? There is the elementary inwin. But this is not a X11 window with it's own wid. As far as I know, there is currently no elementary widget for this. > 4. As far as I can see, mplayer uses the entire window (whose handle is > passed to it with wid) to play the video. Or is it possible to have it use > only > part of the window? Not that I know. But what you can do, is to create a second X11 window, with the override bit set. Position it manually, based on the co-ordinates of your main window, and hand its wid to mplayer. the WM won't add any decoration to it, thanks to the override bit, and mplayer will fill it with the movie, so the second window should not be recognizable as a window. You should be able to get the position and sitze of your main elm_win using something like this: EAPI void evas_object_geometry_get (const Evas_Object *obj, Evas_Coord *x, Evas_Coord *y, Evas_Coord *w, Evas_Coord *h); Then you can simply create a second elm_win with the right coordinates, and set the override bit _before_ you make the window visible. Hope this helps... Cheers, Thomas -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone-video problems!! Help !
> The best would be to have a transparent windows with big icons to > pause/quit, ff and so on, very finger friendly Hm, if you want to get fancy, there is a way to have windows of any shape that are always "on top" as far as the window manager is concerned. Check out: EAPI void ecore_evas_shaped_set(Ecore_Evas* ee, Evas_Bool shaped); or in elementary: EAPI void elm_win_shaped_set(Evas_Object *obj, Evas_Bool shaped); This is really really super slow on the neo, and it might not even work with mplayer overlay windows. But normally, you would be able to make arbitrary shaped windows. (Check out the elementary-test app, there is a transparency test using this...) You might also get some inspiration from this proof-of-concept keyboard code: http://svn.om.vptt.ch/trunk/bubble-keyboard/src/bin/bubble-keyboard.c Hope this is useful... Cheers, Thomas -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone (0.24) Elementary based mplayer frontend
Hi, c_c wrote: >Mirko Lindner wrote: >>The elm theme we install sets the text color in elm-entries to white rather >>than black. > > Ah! That explains it. Hmmm - Well, it looks like I'll have to see if I can >change over > my entry's (there's only 1) background to black. > But there must be a better way - we surely can't have changes applied > system-wide > based on the theme used for one App. I think there is some infrastructure already there, working on the edje group level... Please check the Elementary wiki page: http://trac.enlightenment.org/e/wiki/Elementary Quoting the section about elementary envionment variables... > ELM_THEME - This sets the theme(s) to be used in order from most > preferential, to least, just with the theme name (minus the .edj extension) > with a : character delimiting the name. A simple personal theme would be > mytheme. If you wish to primarily use your personal theme, and then fall > back to another, you can do: mytheme:fallback. > This allows as many levels as you like. It is always assumed that the final > fallback theme is the default theme. A complex example would be: > mytheme:fallback:systemfallback:othersystem. Remember theme names > like "mytheme" mean it assumes a mytheme.edj is in $HOME/.elementary/themes > OR if not found here first, it is in $ELM_DATA_DIR/themes under the same > name. > Themes in your users theme dir always take precedence. A Theme name can > ALSO be a relative or full path to a file. In this case the fill filename > including extensions needs to be given. i.e. > /path/to/file.edj:mytheme:fallback: > ../../relative/path/file.edj:./dir/file.edj. With full or relative paths > searching in order > still happens. Note that there is a convenience shortcut for the users home > directory of ~/. So if a theme element is ~/dir/file.edj then ~/ is expanded > to > the the value of $HOME (the users home directory). The way I understand this is that for every edje groud that is needed to render a widget, elementary will check the *.edjes in the order they are listed in the ELM_THEME env variable. If a group is not found, it will check the next *.edj Digging deeper, there are two undocumented API calls in Elementary.h: EAPI void elm_theme_overlay_add(const char *item); EAPI void elm_theme_extension_add(const char *item); I think these allow the application to add their own themes app dependent *.edj, either _before_ ELM_THEME (that would be elm_theme_overlay_add() ) or _after_ ELM_THEME (that would be elm_theme_extension_add() ) The relevant code is at: http://trac.enlightenment.org/e/browser/trunk/TMP/st/elementary/src/lib/elm_theme.c?rev=#L50 I have not tested this, but the code looks as if it would be in working shape. Hope this is usefull nevertheless... Cheers, Thomas -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Why enlightenment?
Hi, > Why enlightenment? | You see things; and you say, 'Why?' | But I dream things that never were; and I say, "Why not?" |George Bernard Shaw, ;-) Cheers, Thomas -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intone lockup
Hi On Sat, Apr 18, 2009 at 9:17 PM, The Digital Pioneer wrote: > Ahh, the beast isn't tamed yet. Now, when I run Intone, I can play the > music, but as soon as it starts playing it, the GUI locks up and has to be > killed. Hm, to me, this looks as if the gui is expecting an answer from mplayer but for some reason missed it. Thanks to the while-loops that are all over in gui.c, the gui would sit there waiting forever. As such, control flow never returns to the ecore mainloop and the gui aprears to "hang". Intone should not use while loops when reading answers from mplayer, or allow the loops to be broken after an apropriate timeout... Cheers, Thomas -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Elmdentica 0.3.0
Hi Rui, in elementary, you can scale each visual element independently by using the function void elm_object_scale_set (Evas_Object *obj, double scale) on the evas object. The scale factor is applied to all elements of the object, i.e. not only the button size but also the buttons text is scaled. Note however that there is a minimal size of buttons, and other finger touchable things: ELM_FINGER_SIZE. ELM_FINGER_SIZE is an environment variable that gives the diameter of the finger in pixels, and elementary will make sure that buttons will never get smaller than ELM_FINGER_SIZE, such that they stay usable with your fingers..., Hope this helps Cheers, Thomas On Mon, Jun 29, 2009 at 7:29 AM, Rui Miguel Silva Seabra wrote: > On Sun, Jun 28, 2009 at 02:48:01PM -0700, Morten wrote: >> Looking really good! I love that you are using Elementary, it's _so_ much >> nicer from a user perspective, almost a little iphonish =) > > Yeah, but does someone know how to make smaller buttons? > > Rui > > -- > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Audio Jack 2.5 mm
Hi Am 24.04.2007 um 12:58 schrieb Vladimír Lapáček: so why does Neo 1973 use the 2.5mm one? That makes perfectly sense: because the majority of headsets for mobile phones are 2.5mm Isn't the questiont ths: Why doesn't it provide *additionally* a 3.5mm jack ? That would be sweet!!! (and i suspect it woudln't cost much more) Cheers, Thomas ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Audio Jack 2.5 mm
Am 24.04.2007 um 20:20 schrieb Ian Stirling: The USB chip is integrated into the SOC, the sound chip is on another bus. You can get arbitrary sound quality over USB, with a USB DAC. Not when the USB Host Port doesn't supply the power (+5Volts) needed to power that DAC. Cheers, Thomas ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New wishlist item: Side-mounted touch strip sensor
Am 19.06.2007 um 11:39 schrieb <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>: ... An 8-element capacitive sensor would work wonderfully and be easy to fab using either a Quantum QT411 (http://www.qprox.com/products/qslide_qt411.php) or Analog Devices AD7143 (http://www.analog.com/en/prod/0,2877,AD7143,00.html) controller. I would like to throw in the Cypress series of PSoCs (Programmable System on Chips) Its a 8bit uC plus some digital and analog blocks that can be interconnected like a FPGA, all in one single chip. Its very flexible, and tools for assembly level software developpment are freely available. I dont think that the gcc can currently compile for it as a target though. Why this interesting in my opinion: Selfmade keylock-logic ala iphone slide, so we dont wake up continously the samsung main CPU when worn in a pocket or such thing. only after the slide, we generate the interupt. We are free to develop our own logic. More Info: http://www.cypress.com/capsense/index.jsp BTW: this is something that might easily be retrofittet to the Phase 1 devices, once available. Cheers, Thomas I think the current Ipod nano uses them aswell for the clickwheel.___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New wishlist item: Side-mounted touch strip sensor
Am 19.06.2007 um 21:26 schrieb Jordan Anderson: I have a touch strip on my HTC Excalibur, and one of the first things I did was shut it off -- simply handling the phone was causing the volume to go up and down, or my browser to go back. Obviously a personal thing, but with a physical button it's easier to remember that it's there. When using a controller that is programmable, one could have a double- click keylock feature 1) tap 2) release within specific delay 3) tap again within specific delay and specific nearness to the first tap 4) now, while holding the finger, slide. Only if you "unlocked" with the double tab, then the slide is reckognized. just an idea... Cheers, Thomas ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
