On Thu, 2009-09-03 at 10:20 +1000, Carsten Haitzler wrote: > On Tue, 01 Sep 2009 18:07:12 +0300 Viktor Kojouharov <vkojouha...@gmail.com> > said: > > > On Tue, 2009-09-01 at 17:55 +0300, Viktor Kojouharov wrote: > > > Hi guys, > > > > > > I've attached a patch that adds a spinner widget to elementary. This > > > spinner looks and acts more like the spinners in blender, than the > > > spinner seen in Windows or gtk+. The inc/dec buttons are on the left and > > > right sides, and the user can click and drag across the widget to > > > increase/decrease the value. Clicking on the text changes it to an > > > editable entry. > > > > > > What needs to be done is to have the arrow keys increase/decrease the > > > value when in entry mode as well, as well as having the escape key > > > cancel the change. Not sure if that can be done without making small > > > changes to elm_entry though. > > > > Adding the patch as a zip instead. Seems it didn't make it to the ML > > when it was a tar.bz2 > > hey. not bad. one thing i'd consider is a theme/visual change - when you drag, > something drags with your finger and "expands" in the direction of your drag. > eg: > > normal [# 13 #] > pressed [#[13]#] > dragged to right to 15 [#[15--] > dragged to right to 25 [#[25-----] > dragged to right to 30 [#[30--------] > > so you see it expand away. problem is if this is out of "window bounds" its a > bit useless. but if the spinner is within the window and with space it'd look > nice. also a vertical spinner too.
If I get what you mean, that it might be done quite easily. The draggable part can be made visible so it shows how the users swipes. But its usefulness is a bit problematic. The spinner doesn't have bounds for dragging, so you can continue dragging outside the window bounds, but it can't be represented. Also, the area to represent the dragging will have to be reduced, since dragging backwards will also need to be shown, and thus the dragging has to always start at the middle of the widget, rather than from the start as it is done now. I can only assume that another part can also be made to follow the draggable part, so that the later remains hidden, and the new part represents the movement in any way it wants. > > anyway 1. escape can be done by grabbing "Escape" key - evas has key grabs. > you > can grab it when the widget gets focus and ubgrab when you lose it (this way > it > isnt grabbed from other widgets when then need it). he other way is to expose > special keys like escape from edje_entry and then via elm_entry up. but it > does > need an exit mode there! not working too well! I was thinking of that, but didn't test it since I though having the entry deal with the key events would be better. Will take another look at it. So it depends on what you think is better, expand elm_entry to handle more than the enter key, or do the whole thing using evas key events. > > btw - probably should have inc/dec buttons "exit entry mode" if u ask me. :) > sure, that sounds good :) ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
