summaryrefslogtreecommitdiffstats
path: root/ui/base/range
Commit message (Collapse)AuthorAgeFilesLines
* Adds more owners.sky@chromium.org2013-08-051-0/+1
| | | | | | | | | | BUG=none TEST=none TBR=dmazzoni@chromium.org, rsesek@chromium.org, asvitkine@chromium.org Review URL: https://codereview.chromium.org/22268002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@215671 0039d316-1c4b-4281-b951-d872f2087c98
* Use a direct include of strings headers in ui/, part 2.avi@chromium.org2013-06-111-1/+1
| | | | | | | | | | BUG=247723 TEST=none TBR=ben@chromium.org Review URL: https://chromiumcodereview.appspot.com/16431009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@205608 0039d316-1c4b-4281-b951-d872f2087c98
* some fixes and warning disables in ui/ for building on win x64scottmg@chromium.org2013-01-152-5/+5
| | | | | | | | | | | | | - Some |int|s that should be |ptrdiff_t|s. - Icon structures are packing to known size (same signs). - GetWindowLong needs to be GetWindowLongPtr to work on 32 & 64. R=ben@chromium.org, jschuh@chromium.org BUG=167187, 166496 Review URL: https://chromiumcodereview.appspot.com/11889017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@176860 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the rest of #pragma once in one big CL.ajwong@chromium.org2012-07-111-1/+0
| | | | | | | | | For context see this thread: https://groups.google.com/a/chromium.org/forum/?fromgroups#!topic/chromium-dev/RMcVNGjB4II TBR=thakis,pkasting,jam git-svn-id: svn://svn.chromium.org/chrome/trunk/src@146163 0039d316-1c4b-4281-b951-d872f2087c98
* Fix logging of string16s from gfx namespace on Windows.asvitkine@chromium.org2012-05-172-8/+9
| | | | | | | | | | | | I don't why this fixes it, but somehow having a SelectionModel << logging operator in the gfx namespace makes Visual Studio fail to find the << logging operator for string16 arguments. Per discussion with Scott, we decided to remove the << operators altogether and replace them with a ToString() function to be consistent with Rect, Size, etc. TEST=Check that adding a "LOG(INFO) << text();" line to RenderTextWin compiles. Review URL: https://chromiumcodereview.appspot.com/10332205 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@137732 0039d316-1c4b-4281-b951-d872f2087c98
* ui/base/range: Fix the header include guard of range.h since it moved from gfx/.tfarina@chromium.org2012-04-031-3/+4
| | | | | | | | | R=rsesek@chromium.org TBR=sky@chromium.org Review URL: https://chromiumcodereview.appspot.com/9958133 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@130473 0039d316-1c4b-4281-b951-d872f2087c98
* Simplify handling of BiDi cursor movementbenrg@chromium.org2012-03-131-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current caret position and the end of the current selection in a text field are logically the same thing, but the current code represents them separately as SelectionModel::caret_pos_ and SelectionModel::selection_end_, which sometimes have different values, for two reasons: 1. selection_end_ indexes a point between two graphemes (range 0 to N, where N is the text length), but caret_pos_ indexes a grapheme (range 0 to N-1). SelectionModel::caret_placement_ specifies whether the caret is to be displayed at the leading or trailing edge of that grapheme. When the placement is LEADING, selection_end_ and caret_pos_ have the same value, but when it's TRAILING, caret_pos_ points to the start of the grapheme while selection_end_ points to the end. 2. The first and last logical graphemes of the text are not always at the visual boundary (for example, when the text is visually abcFED, the last logical character, F, is in the middle). In order to make the cursor appear at the visual boundary in such cases, the current code attaches it to the leading edge of the D, whereas selection_end_ points after the F. The first case can be fixed by making caret_pos_ point between graphemes like selection_end_. This is enough to determine the caret position except when it is between bidi runs that aren't visually contiguous: in that case, an extra field ("affinity", replacing placement) indicates whether it appears attached to the previous or the next run. The second case can be fixed by pretending that the text is surrounded on both sides by text in the default bidi direction, and allowing the caret to be attached to those runs. This makes EdgeSelectionModel() much simpler: it always returns either (0, previous) or (text_length, next). After these changes, caret_pos_ and selection_end_ always have the same value, so I merged them. For examples of how the old and new SelectionModels compare, look at the changes to ui/gfx/render_text_unittest.cc. The visual behavior of the text field is mostly unaffected by this change. I'm not sure that the current behavior is actually what we want (it's different from WebKit, Windows, and GTK behavior, all of which are different from each other), but that's a separate issue. Visible changes: * RenderText::IsPointInSelection should now behave as expected when clicking on the trailing half of a glyph (it was a TODO). * Clicking on the right half of a glyph used to place the caret to the left of the glyph on Windows. It should now place it on the right. * There was a bug in the Windows cursoring code: with the text "CBAdef" in a LTR locale, pressing End, then Left repeatedly, causes the caret to cycle through the leftmost five visual positions instead of stopping at the left. This should now be fixed. Drive-by changes: * Replaced the selection with a ui::Range and use ui::Range methods like GetMin() and is_reversed() instead of SelectionModel-specific code. * Merged RenderText{Linux,Win}::{EdgeSelectionModel,GetCursorBounds} into RenderText. I didn't merge other methods (such as AdjacentCharSelectionModel) that should eventually be merged but aren't as easy to merge. * Some simplification of the unit tests. BUG=90426 TEST=existing unit tests Review URL: http://codereview.chromium.org/9390022 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@126287 0039d316-1c4b-4281-b951-d872f2087c98
* Rename UI_API to UI_EXPORT.darin@chromium.org2011-08-061-3/+3
| | | | | | | R=rvargas@chromium.org Review URL: http://codereview.chromium.org/7569005 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@95730 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce ui.dll / libui.so for the component build.darin@chromium.org2011-07-171-2/+3
| | | | | | | R=ben@chromium.org Review URL: http://codereview.chromium.org/7328011 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@92819 0039d316-1c4b-4281-b951-d872f2087c98
* Rename range.mm to range_mac.mm.thakis@chromium.org2011-07-046-93/+108
| | | | | | | | | | | | | | | | | | For consistency, move the windows-specific code from range.cc into range_win.cc. Do the same for unit tests. In addition to this being nicer in general, the make build also gets confused if two files have the same path and basename, but different extensions (range.cc, range.mm), which is fixed by this CL. BUG=none TEST=none Review URL: http://codereview.chromium.org/7248068 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@91480 0039d316-1c4b-4281-b951-d872f2087c98
* Contains/Intersects methods for ui::Rangeoshima@google.com2011-05-203-0/+87
| | | | | | | | | | This will be used to implement text style/coloring for TextfieldViews. BUG=none TEST=new unit tests are added in range_unittests.cc Review URL: http://codereview.chromium.org/7039051 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@86040 0039d316-1c4b-4281-b951-d872f2087c98
* Introduce ui::Range, a simple container for integral ranges (like text ↵rsesek@chromium.org2011-03-155-0/+487
selection). BUG=none TEST=ui_base_unittests Review URL: http://codereview.chromium.org/6625085 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@78217 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-01-19 03:36:06 +0000