* check if locking the offscreen window succeeds before calling delete on it
* don't return offscreen windows in CountWindows and WindowAt (works now as on R5)
fixes ticket 1522, 1591, 1946, 2318 and propably more
While creating an BBitmap in BApplication the bitmaps window looper would
be added to the applications gLooperList, thus calling Quit() on that window
and later delete on a stale window pointer in BBitmaps dtor. The Lock() check
would fix the problem, but tests on R5 have shown that BApplication hides the
offscreen window in CountWindows() and WindowAt().
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28236 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added some convenient functions, operator etc...
* reused parts of the patch by Stephen Deken, thanks
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27954 a95241bf-73f2-0310-859d-f6bbb57e9c96
This fixes ticket #2802. (Not sure why it only happend on gcc4)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27914 a95241bf-73f2-0310-859d-f6bbb57e9c96
This should have crashed on R5 too, what happend is that deleting
a 'Box' will cause a release of it's EndPoints, thus leaving some
dangling EndPoint pointers in the Wires, which they access to call
disconnect. So deletion order is important here, delete Wires first.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27880 a95241bf-73f2-0310-859d-f6bbb57e9c96
* grab the fLooper pointer in some more functions, just to play save
* remove wrong comment in UnlockLooper, since it's obviously possible to change fLooper
In case we remove the handler from the loopers handler list, we need to grab the looper
pointer first, since calling RemoveHandler(...) will call BHandler::SetLooper(...) thus
setting fLooper to NULL and calling UnlockLooper did nothing, leaving the looper locked.
Thanks Maurice for pointing out that 26383 broke Cortex, the wires where not draw and the
app was locked somehow.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27872 a95241bf-73f2-0310-859d-f6bbb57e9c96
- /me still wonders why we have to use such tiny icons in Deskbar,
fuzzy look and for sure not handicapped people friendly, hmmm...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27832 a95241bf-73f2-0310-859d-f6bbb57e9c96
* remove libpng and libz dependency in case we build for Haiku
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27801 a95241bf-73f2-0310-859d-f6bbb57e9c96
* save the last used output format
* save the last 5 choosen locations
* don't do any window init in silent mode
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27785 a95241bf-73f2-0310-859d-f6bbb57e9c96
* truncate the path label, since a long path would automatically
resize the window to something unusable in that case...
Note: somehow the PopUpMenu does ignore a set max column size
expanding from small to large leaves some drawing artefacts
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27647 a95241bf-73f2-0310-859d-f6bbb57e9c96
i did exactly that way in my code, which messed up the location popup
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27645 a95241bf-73f2-0310-859d-f6bbb57e9c96
* have png and home as default
* still misses some kind of settings...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27642 a95241bf-73f2-0310-859d-f6bbb57e9c96
Obviously we ported the bug over from BeOS, during the FrameResized call the preferred size of
the window was calculated based on the current size of the window, calculating the same size
FrameResized reported. Thus resulting in trying to resize it to the same size ending in an loop.
It seems they worked arround the oversight using the outline resize thing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27426 a95241bf-73f2-0310-859d-f6bbb57e9c96
a user resize, this makes ArtPAint's tool pallete window resize properly
Thanks Stephan for explaining me two time what to look for :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27384 a95241bf-73f2-0310-859d-f6bbb57e9c96
dont overwrite with preferred, it needs to called explicit
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27332 a95241bf-73f2-0310-859d-f6bbb57e9c96
this fixes mostly all windows containing TextControls in ArtPaint and
should fix also ticket #2543
ArtPaint was calling the BTextControl ctor with an empty rect, followed
by ResizeToPreferred, which made in the best case the TextInput visible
but it did not take the label into account. Should help more R5 apps.
Some more tests on R5 have shown that even if you pass an extra large
width, a call to ResizeToPreferred will not respect the passed width.
Also the _BTextInput_ seems to grow with the length of the passed label.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27330 a95241bf-73f2-0310-859d-f6bbb57e9c96
failed on Haiku, this makes e.g. painting in ArtPaint work
Don't know if this is the best place to fix it though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27322 a95241bf-73f2-0310-859d-f6bbb57e9c96
this was most noticable in Deskbar when opening DataTranslations in Expand App Mode
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27291 a95241bf-73f2-0310-859d-f6bbb57e9c96
* more get/ set functions, operators
* date until 1582 are handled in julian calendar
* date above 1582 are handled in gregorian calendar
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27264 a95241bf-73f2-0310-859d-f6bbb57e9c96
while holding down the mouse over the date area in Deskbar.
One probably needs to clean and rebuild Deskbar to get it...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27236 a95241bf-73f2-0310-859d-f6bbb57e9c96
this should fix LinkSender usage like as in Stroke/ FillPolygon in BView
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27226 a95241bf-73f2-0310-859d-f6bbb57e9c96
* tell something if saving a file fails before it gets to TranslationUtils, fixes#2612
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27225 a95241bf-73f2-0310-859d-f6bbb57e9c96
is called after BeginPicture on a freshly created view.
This is necessary because a second invocation on this view with BeginPicture
would have caused ServerPicture::SyncState to write the default drawing state
into the picture. This happens because to BView had now cached the values and
therefor won't go to the app_server and tell about the change. The first call
did not change anything as picture recording is handled in _DispatchPictureMessage
while view changes that modify drawing state are handled in _DispatchViewMessage,
thus leading to default draw state values beeing written.
This fixes invalid ticket #2534.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27218 a95241bf-73f2-0310-859d-f6bbb57e9c96
this makes printing of large images work, fixes task #1067
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27214 a95241bf-73f2-0310-859d-f6bbb57e9c96
this avoids to multiple window popup for page settings and job settings
* Note: this shows the painting regression introduced with r26665, see task #2534
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27211 a95241bf-73f2-0310-859d-f6bbb57e9c96
* pass the target directly to AddItemMenu
* use default paramter to enable the menu item
* fixed messenger leaks for file panel and resizer window messenger
* show the job config panel when the 'Print' menu item is invoked + shortcut
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27204 a95241bf-73f2-0310-859d-f6bbb57e9c96
* return error in case we could not get all values from JobConfig
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26822 a95241bf-73f2-0310-859d-f6bbb57e9c96
* sync against the preview driver
* fixed totally broken multiple pages on single page preview
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26812 a95241bf-73f2-0310-859d-f6bbb57e9c96
* get rid of three of them, i don't know why they where implemented in the first place
* fix broken scrollbar adjustment
* cleanup DocInfoWindow.h and DocInfoWindow.cpp
* make the window resizable and get rid of the tabview
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26690 a95241bf-73f2-0310-859d-f6bbb57e9c96
* adjust all drivers to take that into account
* fix UpdateText() signature in JSDSlider to avoid warning
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26648 a95241bf-73f2-0310-859d-f6bbb57e9c96
* move libprint headers into libs headers folder accordingly
* merge all shared folders sources into kits print, we might build later on a
real print kit, propably also to access cups from an nicely API, atm static
* move all shared headers into private print, also pr_server.h from interface
* adjust build to work with the changed folder layout
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26570 a95241bf-73f2-0310-859d-f6bbb57e9c96
This fixes part 3 of task #1987, TaskManager was using the syncronous version of
of BPopUpMenu wrapped in it's own class to run asyncronous. It did set SetAsyncAutoDestruct
to true and afterwards calling delete an the already deleted menu.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26406 a95241bf-73f2-0310-859d-f6bbb57e9c96
Karsten Heimrich