On Mon, 10 Oct 2011 16:45:13 -0700 "Ausmus, James" <james.aus...@intel.com> said:
> On Mon, Oct 10, 2011 at 4:20 PM, Carsten Haitzler <ras...@rasterman.com> > wrote: > > On Mon, 10 Oct 2011 09:57:33 -0700 "Ausmus, James" <james.aus...@intel.com> > > said: > > > >> On Fri, Oct 7, 2011 at 7:45 PM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >> > On Fri, 7 Oct 2011 14:16:58 -0700 "Ausmus, James" > >> > <james.aus...@intel.com> said: > >> > > >> >> On Fri, Oct 7, 2011 at 2:20 AM, Tom Hacohen <t...@stosb.com> wrote: > >> >> > I'm away from home/computers until Saturday evening (leaving now), > >> >> > I'll take a look at it soon after. > >> >> > > >> >> > But I have a couple of questions until then: > >> >> > What sizing do you get? what do you expect? The elm minimum height > >> >> > should change according to the font size (unless it's smaller than the > >> >> > finger size, which is then used). > >> >> > >> >> It's taller than the part underneath it that it is set to be relative > >> >> to and smaller than. However, I'm betting that the finger size thing > >> >> is the issue here - any way to override/set the finger size > >> >> dynamically, to be able to get around that limitation in one-off > >> >> situations? > >> > > >> > use a label then, not entry. an entry is there for the purpose of > >> > entering text or selecting it etc. - not just display. thus it forces it > >> > to be at least a finger size in height for single line entries (for > >> > multiple line its a bit nastier so it doesn't currently). the whole > >> > point of finger size it to ensure a person can reliably press on it. if > >> > you have a desktop app finger size should be globally on your system set > >> > to something low - like "5". so you wont have a problem. but elm is > >> > fixing the ui to make it usable for people. you don't need your ui test > >> > department now to tell you to fix it anymore. :) > >> > >> > >> Unfortunately, I need actual text entry, not just display. I agree > >> that, if *everything* else on a given platform is working correctly, > >> then the finger size should already be set at the appropriate value, > >> and everything would work great. However, if there are other > >> platform-level issues/misconfigurations/evolutions in play, I either > >> have to wait for someone else to finish their job, do someone else's > >> job for them, or just have my deliverables look ugly (and most > >> higher-level managers I've dealt with don't usually like the "It's not > >> my fault/job!" answer...). > > > > you can tell your manager to give me a call land i'll set them straight. :) > > Noted... :D > > > > >> Again, I agree with the concept, but not having any way to work around > >> it, *forcing* every possible application to fit within a pre-conceived > >> paradigm of how the platform should work, seems a little > >> over-restrictive and broken... > > > > that's the POINT of a widget set. the POINT of a toolkit. consistency. being > > usable DESPITE the programmer who really isn't considering such usability > > issues. it's the same as theme, fonts, and other factors. it's a global > > config value and to be set globally. if every app goes making its own > > themes, using its own fonts and sizes, then you end up with a mess. sure. > > it CAN be done. you just have to stop using edje and many parts of > > elementary and start manually stuffing things around the screen. the > > complexity of your app will go up a lot. that's INTENTIONAL. it's creating > > a technical barrier making you do immensely more work to "disagree" with > > the designs of the toolkit. it's there to discourage you from > > disagreeing. :) all of the elements obey these paradigms. all widgets that > > are to be interacted with set their minimum sizes based on visible content > > and finger size. edje respects minimum size hints as well thus making your > > entry the size it is. they are all "playing by the rules of the game". > > I whole-heartedly agree with the idea that it should not be easy to > override usability presets. However, making it essentially > *impossible* to override the presets makes the widget set *less* > useful, not more - I think that a toolkit should *strongly* discourage > a developer from going "against the system", but, ultimately, if the > developer really *needs* to do a single thing contrary to the > preconceived paradigm, it should allow them - not trivially, because > that, of course, almost encourages developers who don't know what > they're doing to bypass the "rules" that have been set in place just > to save them from themselves. > > In other words - what you're saying (from what I understand - please > correct me if I'm wrong) is essentially: "We've considered *all* > possible applications and uses of *all* of these widgets, and there is > concretely *never* going to be a valid use case that doesn't fit in > the paradigm of user interaction that we have created. We cover > *everything* that could ever be - no one will *ever* have a valid use > case that falls outside of what we have considered." > > With this particular application, I have this *one* case where, > visually, I need an entry box that is a little shorter than what is > currently (mis-, as the platform and emulation environment are > certainly WIP) configured to be the minimum finger size. I have 99% of > the functionality I need for this app in Edje and Elm. Without *some* > way to implement a single-instance override of this minimum height, I > have to go looking for a different toolkit. I would absolutely prefer > to be *able* to use Edje and Elm, as it keeps everything well > integrated with the platform, dev environment, emulation environment, > input method, etc., but I have a hard requirement that this text entry > visually fit within the vertical area allotted for it. the case here is "yes - we've considered all uses and this is the rule". an entry, by its nature, must be able to be interacted with with a finger (or mouse). for doing selections, copy & paste, placing cursor, etc. THUS by deduction it MUST be at least a "finger in size" to be reliably interacted with. thus elementary enforces that (well for single line entires for height. come think of it it should enforce it for width too, and for multi-line too, i need to fix that. that's indeed a bug). a system with no "mouse/finger" input... would set finger size to a very small value, thus your problem would not exist. so taking that "fact" (that you agree with), the conclusion is, EITHER the "ui designer" is totally wrong in specifying the EXACT geometry of some element on screen that contains an entry and thus has to be interacted with at a size SMALLER than can be sensibly interacted with, OR the person who is responsible for system-wide config hasn't appropriately set up finger size for that display correctly, OR both. so what you're saying is... your ui designer is infallible AND the system config maintainer is perfect, and elementary's insistence on making thngs usable for the end-user is wrong? :) (i'm making a point here. you're basically saying that these 2 elements are fixed unmovable entities and THUS elementary MUST move instead, even though you actually agree with elementary's logic and position? so instead of actually fixing the root cause - designer or system config, you want to ignore the ui design principles you agree with and violate them because the elements that are wrong are "too stubborn to change"?) (note - finger size is not a fixed value. it varies from person to person and situation to situation -there is a sensible value for most people, but for example my father has big fat mits of fingers. he can't vaguely use any modern smartphone ui as his fingers are just too big. since the omniscient designers seem to think that they are totally right and never even consider making an adjustment option for such people, he is effectively excluded from ever using such a device. as would other people in his situation. i have given him and android phone and watching him totally struggle to select items in lists or press buttons reliably. this is a real world case of where elm is trying to help you not screw usability for other people). you're going to have to make a LOGICAL case where this is to be violated. i can tell you right now that there is no way to use elm/edje as you do now and get what you want. no feature exists to let you violate the ui principles, not without doing it very differently. as i mentioned - you can not use edje, and instead manually place the entry yourself. you can use elm_grid to do a totally proportional layout (as it totally ignores min size hints on children). actually as a bit-product of that (unintentional) if you put entry inside a grid, make entry always fill the grid, then you will effectively have min size hints ignored on the children of grid (entry) and thus grid will not percolate min size hints back up to itself. but as i said - you'll have to jump through hoops. and that doesn't absolve you of making a ui that is excluding people from being able to use it (as my above example). i really hate even telling you how to jump through these hoops as i believe you simply make worse applications and ui's in the end. :( seriously. you need to push back to the ui/ux/whatever dept and fix the core issue not work around it. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
