#
7999bc87 |
|
06-Feb-2009 |
Stephan Aßmus <superstippi@gmx.de> |
Tiny style cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29140 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8ab8c63d |
|
21-Sep-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Moved BTextView::UndoBuffer derivatives into the BTextView class as well, hopefully fixing the GCC4 build. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27660 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a682d981 |
|
20-Sep-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Quite a cleanup action to avoid polluting the global namespace with private BTextView classes: * Declared the directly used BTextView helper classes as private BTextView classes and changed all affected files. * Realized that Tracker's BPoseView was (accidentally?) using what used to be _BWidthBuffer_. It had declared it's own class with the same name and same members/size in headers/private/tracker/TextViewSupport.h, but the implementation was nowhere to be found. I can only explain this that the BTextView implementation was then actually linked and used. But the big problem was that it was used without locking (unlike in BTextView)! When many Tracker windows opened during system startup or later and they happened to each request characters not yet in the cache, I imagine things could have gone bad and corrupted memory. Anyways, since I can see the usefulness of the cache, BPoseView uses BTextView::WidthBuffer on purpose now. And I moved the locking inside BTextView::WidthBuffer::StringWidth(). * Adjusted InterfaceDefs.cpp accordingly. * TODO: Move subsequent classes into BTextView namespace as well, ie derived classes that BTextView doesn't directly know about. All stuff in src/kits/ inteface/textview_support/ * Added preliminary and not yet implemented layout friendly BTextView constructors. * I will try to handle the insets imposed by BTextView::fTextRect a bit differently when used inside the new layout management framework. For this, I added BTextView::SetInsets() and GetInsets(). SetInsets() doesn't do anything yet. So far, everything seems to work still... ;-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27654 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c9198a4c |
|
25-Dec-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* I am pretty sure this was a bug... spotted by pure chance, should have caused messed up undo/redo when removing multibyte UTF8 glyphs via forward backspace git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23156 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b30e7f31 |
|
23-Jan-2007 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Use BTextView::Copy/FreeRunArray() instead of memcpy() and free() git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19938 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b31b14e0 |
|
28-Aug-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Renamed BTextView folder to textview_support git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18663 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
7999bc8711fcf6c672eed17306b577292dc98d71 |
|
06-Feb-2009 |
Stephan Aßmus <superstippi@gmx.de> |
Tiny style cleanup. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29140 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
8ab8c63d26d82df2226f531a915cf198e6f1eb36 |
|
21-Sep-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Moved BTextView::UndoBuffer derivatives into the BTextView class as well, hopefully fixing the GCC4 build. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27660 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
a682d9819fae1e26cef1390bb33b5d5c73304642 |
|
20-Sep-2008 |
Stephan Aßmus <superstippi@gmx.de> |
Quite a cleanup action to avoid polluting the global namespace with private BTextView classes: * Declared the directly used BTextView helper classes as private BTextView classes and changed all affected files. * Realized that Tracker's BPoseView was (accidentally?) using what used to be _BWidthBuffer_. It had declared it's own class with the same name and same members/size in headers/private/tracker/TextViewSupport.h, but the implementation was nowhere to be found. I can only explain this that the BTextView implementation was then actually linked and used. But the big problem was that it was used without locking (unlike in BTextView)! When many Tracker windows opened during system startup or later and they happened to each request characters not yet in the cache, I imagine things could have gone bad and corrupted memory. Anyways, since I can see the usefulness of the cache, BPoseView uses BTextView::WidthBuffer on purpose now. And I moved the locking inside BTextView::WidthBuffer::StringWidth(). * Adjusted InterfaceDefs.cpp accordingly. * TODO: Move subsequent classes into BTextView namespace as well, ie derived classes that BTextView doesn't directly know about. All stuff in src/kits/ inteface/textview_support/ * Added preliminary and not yet implemented layout friendly BTextView constructors. * I will try to handle the insets imposed by BTextView::fTextRect a bit differently when used inside the new layout management framework. For this, I added BTextView::SetInsets() and GetInsets(). SetInsets() doesn't do anything yet. So far, everything seems to work still... ;-) git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27654 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
c9198a4ccee6924b7d53bdce767d4b5b40140447 |
|
25-Dec-2007 |
Stephan Aßmus <superstippi@gmx.de> |
* I am pretty sure this was a bug... spotted by pure chance, should have caused messed up undo/redo when removing multibyte UTF8 glyphs via forward backspace git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23156 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b30e7f31c13333ace6207168164032247f313a01 |
|
23-Jan-2007 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Use BTextView::Copy/FreeRunArray() instead of memcpy() and free() git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19938 a95241bf-73f2-0310-859d-f6bbb57e9c96
|
#
b31b14e033ffc2c4850235821c9390a151abd2c9 |
|
28-Aug-2006 |
Stefano Ceccherini <stefano.ceccherini@gmail.com> |
Renamed BTextView folder to textview_support git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18663 a95241bf-73f2-0310-859d-f6bbb57e9c96
|