Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Carsten Haitzler (The Rasterman) schrieb: On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. the problem is not differentiating between slide and click - e and elementary have this too. it's that if you drag horizontally for example, your actual events often look something like: ++ +--+ +--+ +-+ ++-++ +--+ + + + +---+ that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Laszlo KREKACS schrieb: On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. In that case you just killed any application which are drawing oriented. So no Xournal, Sketchbook or any such application. why do you think so ? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. In that case you just killed any application which are drawing oriented. So no Xournal, Sketchbook or any such application. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
2009/10/31 Carsten Haitzler ras...@rasterman.com you pressed just once - or you think you did. but you actually had a press, a release, and a press , release etc. again because your pressure went above, below and above the pressure level needed to register a click. What's the pressure level? Is it in the the hardware? Is it possible to adjust it? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, 31 Oct 2009 09:34:17 +0100 Laszlo KREKACS laszlo.krekacs.l...@gmail.com said: On Sat, Oct 31, 2009 at 9:21 AM, Matthias Huber matthias.hu...@wollishausen.de wrote: that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. In that case you just killed any application which are drawing oriented. So no Xournal, Sketchbook or any such application. no you didnt. your stroke would go from the dotty broken one to a continuous one - like your finger actually traced on the screen. the sensors just didnt pick it up. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, 31 Oct 2009 09:21:13 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Carsten Haitzler (The Rasterman) schrieb: On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. the problem is not differentiating between slide and click - e and elementary have this too. it's that if you drag horizontally for example, your actual events often look something like: ++ +--+ +--+ +-+ ++-++ +--+ + + + +---+ that's exact what i told you, what openbox has: they say: if movement number_pixels then its click, if movement = pixels, its slide. and that's what i told you e and elementary have too. the problem is your finger moves the entire length of that line. the actual input events you see are the discontinuous stutters as above. see the + by itself? that's a press +release on the same spot. in your case, one could hava a hysteresis over the time: if a single click comes shortly after a slide, it is part of slide. that's what i said... and it should be done in tslib/x - every toolkit and app should not have to go implement this again and again. the lower layers should sanitise input by the time it gets to x clients. if you measure now the time of the tap, you have all you need for differentiating between all this three events. generally i think, its better to get the btn-release instead of btn-down. (from the view of windowmanager) and you are right: it should be done in tslib or window manager. well not wm. wm's dont intercept or modify events in any way. each x app (the wm, or the app listening to the events on the window where the events are going) gets them. so the choice is. 1. every toolkit+app does it (every game using sdl, every GL app (tho this is hypotherical - this is just the general case, not gta02), elementary, e, gtk, qt - they all need to repeat the same logic to filter these. elementary and e have logic to know the difference between a tap and a drag. the values are configurable and tunable. the problem is all the dirty input. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Sat, 31 Oct 2009 11:38:59 +0100 Michal Brzozowski ruso...@poczta.fm said: 2009/10/31 Carsten Haitzler ras...@rasterman.com you pressed just once - or you think you did. but you actually had a press, a release, and a press , release etc. again because your pressure went above, below and above the pressure level needed to register a click. What's the pressure level? Is it in the the hardware? Is it possible to adjust it? nothing in software i have seen. if it was possible it would have been adjusted long ago... the driver already has code to de-jitter the input (smooth it out) it may as well de-jitter the temporal information too. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Fri, 30 Oct 2009 19:47:27 +0100 Matthias Huber matthias.hu...@wollishausen.de said: Laszlo KREKACS schrieb: To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. Because when sliding, you can have accidental clicks. I know it from the hard way. (I came up a nice usability workaround in paroli exactly for this issue. It works good.) yes i know this also from paroli. but it is solvable i think. openbox has a tunable parameter for distinguish between slide and click. in my oppinion, this is highly usable. i personally find a single click more elegant and usable than double click. the problem is not differentiating between slide and click - e and elementary have this too. it's that if you drag horizontally for example, your actual events often look something like: ++ +--+ +--+ +-+ ++-++ +--+ + + + +---+ if you dont press firmly with a sharp point (stylus, fingernail etc.). you can go to every app and start trying to add filtering to close such gaps, but now you duplicate that code everywhere. IMHO tslib/x should filter it so the input to clients is the intended input by the user. also you will have unintended clicks (drawing press/release over time): + +-+ +-+ you pressed just once - or you think you did. but you actually had a press, a release, and a press , release etc. again because your pressure went above, below and above the pressure level needed to register a click. imho there should be some filtering on the input events that patches these gaps. and that filtering should go in x or tslib. capacitivie screens are much more sensitive and have a different problem - but their events are filtered too as you dont get a point - you get an area that is pressed, so they have a hysterisis on how big the area has to be first to start a press registering and then it has to get much smaller that this area to stop. eg: press start @ 8x8 pixels, press stop at 3x3 pixels. as long as your press area, once registered, is 3x3 pixels, it will continue to be pressed until it gets below. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, 28 Oct 2009 20:42:16 +1100 Carsten Haitzler (The Rasterman) ras...@rasterman.com (CH(R) wrote: On Wed, 28 Oct 2009 11:27:03 +0200 Michael 'Mickey' Lauer mic...@vanille-media.de said: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? good words mickey. good words. :) (i have a todo item for the scrole rto have a page mode. it already has a page mode actually - but its a scrolling one much like iphone's N pages of icons - but it's infra to simple provide some theme elements that you press and they jump up/down/left/right a page and then do the jump - so it's mostly there. it just hasn't been any priority for me - am working on an oldie request to get rotatable objects.. which now works. under flux.. but works and renders... image and text objects so far are working. in theory all other basic object types too, but smart objects - not yet). While i agree i still wonder. i tried latest android on freerunner yesterday - most scrolling nice and smooth. had qtmoko on last week - the same (yes, i read the explanation why it works, but it works). now, in order not to put anybody down, i must say that for example scrolling in shr contact list IS smooth. so my question is: where exactly do we have scrolling issues? think about it. Then i tend to think about the Illume desktop, that is so much unfriendly to scrolling. Raster, i meant to ask before but had no time: if we take etk toolkit and E window manager as for granted for SHR (hopefully with some choices, but still), is there any other desktop module we could use instead of Illume? In your no-speak project, is there anything being developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? Thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
lots of alpha blending - if you have the 16bit engine you get no scale cache (thats 32bit engine only). but worst.. is the font style. check carefully. text has a soft dropshadow. that is drawn by 1. drawing the shadow first and that draw 25 copies of the text with very faint alpha. THEN draw the text on top. that is a pretty big expense. there is no text effect cache in evas at the moment, so this really hits you. turn off the soft dropshadow effect in the theme.. and watch it get 3 or 4 times faster (expedite has a test just for this - on a desktop (in fps) i get 128 and 489 fps respectively just by having no soft shadow on the text). thats pushing on close to 4 times faster. it's an effect - that doesn't come cheaply. the alternative (an actual blur filter) isn't too cheap either. but it's something that can be improved for sure. you want it fast? turn it off. :) Thank you for all the explanation. I think the 32bit engine is the only to go with now. Perhaps the optimization is is already done, maybe not. @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? i started a rewrite- illume2 is in svn. its much cleaner and leaner designed to allow for replacable home screens (ie a home window provides by either another e module or another process). as well as top shelf (inf act any corner/region of the screen) can also be a window provided by.. another module... or another process etc. its much more like the kbd code. it's started. it's not usable. it's on the backburner until a bunch of other tasks are done that are much higher priority. ok, will hope for better times to come developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? can't talk about it :) perhaps we can benefit from it in (near?) future... :) thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Petr Vanek wrote: lots of alpha blending - if you have the 16bit engine you get no scale cache (thats 32bit engine only). but worst.. is the font style. check carefully. text has a soft dropshadow. that is drawn by 1. drawing the shadow first and that draw 25 copies of the text with very faint alpha. THEN draw the text on top. that is a pretty big expense. there is no text effect cache in evas at the moment, so this really hits you. turn off the soft dropshadow effect in the theme.. and watch it get 3 or 4 times faster (expedite has a test just for this - on a desktop (in fps) i get 128 and 489 fps respectively just by having no soft shadow on the text). thats pushing on close to 4 times faster. it's an effect - that doesn't come cheaply. the alternative (an actual blur filter) isn't too cheap either. but it's something that can be improved for sure. you want it fast? turn it off. :) Thank you for all the explanation. I think the 32bit engine is the only to go with now. Perhaps the optimization is is already done, maybe not. @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... i started a rewrite- illume2 is in svn. its much cleaner and leaner designed to allow for replacable home screens (ie a home window provides by either another e module or another process). as well as top shelf (inf act any corner/region of the screen) can also be a window provided by.. another module... or another process etc. its much more like the kbd code. it's started. it's not usable. it's on the backburner until a bunch of other tasks are done that are much higher priority. ok, will hope for better times to come developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? can't talk about it :) perhaps we can benefit from it in (near?) future... :) thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 11:37:06 +0100 Petr Vanek van...@penguin.cz said: @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... i have been trying gry* lately and more less like it. btw can you already change the background image in Illume settings? i still get the Enlightenment was unable to import the image due to conversion errors ? u are probably missing edje_cc from the distro -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 11:12:29 +0100 Bernd Prünster bernd.pruens...@gmail.com said: Petr Vanek wrote: lots of alpha blending - if you have the 16bit engine you get no scale cache (thats 32bit engine only). but worst.. is the font style. check carefully. text has a soft dropshadow. that is drawn by 1. drawing the shadow first and that draw 25 copies of the text with very faint alpha. THEN draw the text on top. that is a pretty big expense. there is no text effect cache in evas at the moment, so this really hits you. turn off the soft dropshadow effect in the theme.. and watch it get 3 or 4 times faster (expedite has a test just for this - on a desktop (in fps) i get 128 and 489 fps respectively just by having no soft shadow on the text). thats pushing on close to 4 times faster. it's an effect - that doesn't come cheaply. the alternative (an actual blur filter) isn't too cheap either. but it's something that can be improved for sure. you want it fast? turn it off. :) Thank you for all the explanation. I think the 32bit engine is the only to go with now. Perhaps the optimization is is already done, maybe not. @Bernd Prünster: you are already very good with this, it would be good to see the difference, if not used already... mind to try the above in gry* ? gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... even that can be slow. in this case, the text will be drawn 5 times to produce that effect. i started a rewrite- illume2 is in svn. its much cleaner and leaner designed to allow for replacable home screens (ie a home window provides by either another e module or another process). as well as top shelf (inf act any corner/region of the screen) can also be a window provided by.. another module... or another process etc. its much more like the kbd code. it's started. it's not usable. it's on the backburner until a bunch of other tasks are done that are much higher priority. ok, will hope for better times to come developed? What do you use on small device? Illume was ditched long time ago, is there not a replacement with attention? Anything you could recommend? can't talk about it :) perhaps we can benefit from it in (near?) future... :) thank you Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
CH(R btw can you already change the background image in Illume settings? i CH(R still get the Enlightenment was unable to import the image due to CH(R conversion errors ? CH(R CH(R u are probably missing edje_cc from the distro thanks, this was it. i have already reported it distro maintainers. Petr ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Carsten Haitzler (The Rasterman) wrote: gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... even that can be slow. in this case, the text will be drawn 5 times to produce that effect. rater, would you mind to elaborate? (is outline the fastest effect if you want to enable the user to set a custom background while maintaining the labels readable?) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
2009/10/28 Michael 'Mickey' Lauer mic...@vanille-media.de: Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? Excellent idea. Certainly as far as the Illume launcher is concerned, I think it would be more usable (instead of having to scroll) to have multiple pages of icons, which you switch between using the same and as for switching between apps. (i.e. each icon page acts like another app) Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, Oct 29, 2009 at 4:46 PM, Neil Jerram neiljer...@googlemail.com wrote: I think it would be more usable (instead of having to scroll) to have multiple pages of icons, which you switch between using the same and as for switching between apps. (i.e. each icon page acts like another app) To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app 2. sliding left/sliding right would change the current page. I would also suggest different background image for each virtual desktop. Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, Oct 28, 2009 at 5:44 AM, ri...@happyleptic.org wrote: Reading an ebook or looking a webpage or a map is better with scrolling I guess. I've been using my FR with ePdfView to read books quite a bit lately, and I always read a full screen of text and then click on the scrollbar to move to the next screen of text. I find it hard to track text on the screen if you are continuously scroll - I think paging is a much better metaphor, at least for ebook reading. A map might be one situation where incremental scrolling is better than paging - I certainly use it a lot on my desktop when using google maps, for instance. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Laszlo KREKACS schrieb: On Thu, Oct 29, 2009 at 4:46 PM, Neil Jerram neiljer...@googlemail.com wrote: I think it would be more usable (instead of having to scroll) to have multiple pages of icons, which you switch between using the same and as for switching between apps. (i.e. each icon page acts like another app) To not confuse with window changing, I would suggest the following scenario: 1. double click for launching an app why double click ? for me, i am using double click for a menu and a single click for starting the app. 2. sliding left/sliding right would change the current page. I would also suggest different background image for each virtual desktop. sliding between desktops is very interesting for me too. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Thu, 29 Oct 2009 15:38:46 +0100 Bernd Prünster bernd.pruens...@gmail.com said: Carsten Haitzler (The Rasterman) wrote: gry* doesnt use dropshadow, it was one of the forst thigs i kicked out, gry* uses a white outline on black text. but thats something thats bugging me. i have to make some tests... even that can be slow. in this case, the text will be drawn 5 times to produce that effect. rater, would you mind to elaborate? (is outline the fastest effect if you want to enable the user to set a custom background while maintaining the labels readable?) yes, but it's still 5x slower to draw than no outline. a suggestion: just put a semi-translucent black box under the text and have white test. this will be readable everywhere and be fastest. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? :M: ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, 28 Oct 2009 11:27:03 +0200 Michael 'Mickey' Lauer mic...@vanille-media.de said: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? good words mickey. good words. :) (i have a todo item for the scrole rto have a page mode. it already has a page mode actually - but its a scrolling one much like iphone's N pages of icons - but it's infra to simple provide some theme elements that you press and they jump up/down/left/right a page and then do the jump - so it's mostly there. it just hasn't been any priority for me - am working on an oldie request to get rotatable objects.. which now works. under flux.. but works and renders... image and text objects so far are working. in theory all other basic object types too, but smart objects - not yet). -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
On Wed, Oct 28, 2009 at 10:27 AM, Michael 'Mickey' Lauer mic...@vanille-media.de wrote: The problem is : on the freerunner we merely need something to display some simple widgets, scroll the screen smoothly (because on a small display you always need to scroll) Why do all of you insist on using scrolling as the only metaphor to present excerpts of large content? Given the physical size of the display and the hardware constraints (touchscreen jitter, for a start... not going to comment on the Glamo) I think this is very questionable. There are other metaphors available that would fit the device's strengths much better. What about paging? Or discrete scrolling. (ie. only scroll by lets say 48px height). Also text only scrolling would be useful to speed up. (most of our scrolling happens on the text). Or dont load the whole text only the first 20 lines of it, and when you hit at the bottom, load the rest of the text. (Im implementing this approach, and I expect better speed of this *workaround* then what elementary provides by default) I do believe that scrolling can be speedup. Especially for texts. I also think that a zoom in/zoom out interface can be also speedier than what the current scrolling is. Ie.you zoom out the texts, and zoom in the other part of it... What I think our hardware shows really its limitation is the animations. But I dont think scrolling falls in that category. Best regards, Laszlo ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
-[ Wed, Oct 28, 2009 at 11:27:03AM +0200, Michael 'Mickey' Lauer ] [scrolling] There are other metaphors available that would fit the device's strengths much better. What about paging? Reading an ebook or looking a webpage or a map is better with scrolling I guess. Apart from that, you are right that paging is easier than scrolling for the hardware and for the user as well (scrolling with a finger is fun but not very precise nor fast - I remember having difficulties with H1 scrolling application list, looking for tangogps ; it requires too much attention, especially while driving :)...) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Insisting on metaphors that exploit the device's weaknesses (Re: Centralization of graphical awesomeness)
Hi [scrolling] There are other metaphors available that would fit the device's strengths much better. What about paging? +1 for paging. mind you, I dont need a button for paging, a gesture could do it. which makes it feel very much like scrolling again, but then more solid. $2c, *-pike ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
