mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
025bd0fab4cd8e4f90c362ec03b51c23e0a55655
libreoffice/vcl/inc/ios/iosinst.hxx

78 lines
2.3 KiB
C++
Raw Normal View History

Re-work the vcl aspects of the iOS port Don't try to use similar code as for OS X to manage windows, events etc. I.e. don't use UIKit in vcl to do that. Instead, just do as in the Android port, use the "headless" vcl backend. Do keep using CoreText, though, not FreeType & fontconfig. Start changing the iOS "Viewer" app to correspond to the Android "desktop" app (so it should be renamed). Work in progress since a long time, several crucial details still missing, but committing for now. Change-Id: Iac5fbf8def415e4d0d21e5200450a373420ad7ee
2013-03-20 09:07:52 +02:00
/* -*- Mode: C++; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- */
/*
* This file is part of the LibreOffice project.
*
* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/.
*
* This file incorporates work covered by the following license notice:
*
* Licensed to the Apache Software Foundation (ASF) under one or more
* contributor license agreements. See the NOTICE file distributed
* with this work for additional information regarding copyright
* ownership. The ASF licenses this file to you under the Apache
* License, Version 2.0 (the "License"); you may not use this file
* except in compliance with the License. You may obtain a copy of
* the License at http://www.apache.org/licenses/LICENSE-2.0 .
*/
#ifndef IOS_SALINST_H
#define IOS_SALINST_H
Render the "headless" frames to the UI view in the LO thread We used to render them in the app main (GUI) thread, which is dangerous, accessing the headless frames in one thread while the LO thread (where the "main" LibreOffice code is running) might be updating and changing them. This fixes some problems like that part of the document did not show up. If I would test the app on a multi-core iPad, presumably I would have seen even more problems. But this also introduces new problems: Now the UI doesn't appear incrementally (for instance, with an actually progressing progress bar during the loading of the document) as it used to. Now it all appeads all of a sudden, everything at once. Which would be fine if it happened very quickly after starting the app, but it doesn't... on the original iPad it takes half a minute. Change-Id: I04068e0d884aa5cb86acefa76449aac4e081b193
2013-03-30 01:39:22 +02:00
#include <pthread.h>
#include <premac.h>
#include <CoreGraphics/CoreGraphics.h>
#include <postmac.h>
#include <tools/link.hxx>
Re-work the vcl aspects of the iOS port Don't try to use similar code as for OS X to manage windows, events etc. I.e. don't use UIKit in vcl to do that. Instead, just do as in the Android port, use the "headless" vcl backend. Do keep using CoreText, though, not FreeType & fontconfig. Start changing the iOS "Viewer" app to correspond to the Android "desktop" app (so it should be renamed). Work in progress since a long time, several crucial details still missing, but committing for now. Change-Id: Iac5fbf8def415e4d0d21e5200450a373420ad7ee
2013-03-20 09:07:52 +02:00
#include "headless/svpinst.hxx"
#include "headless/svpframe.hxx"
class IosSalFrame;
class IosSalInstance : public SvpSalInstance
{
public:
IosSalInstance( SalYieldMutex *pMutex );
virtual ~IosSalInstance();
static IosSalInstance *getInstance();
virtual SalSystem* CreateSalSystem();
void GetWorkArea( Rectangle& rRect );
SalFrame* CreateFrame( SalFrame* pParent, sal_uLong nStyle );
SalFrame* CreateChildFrame( SystemParentData* pParent, sal_uLong nStyle );
Render the "headless" frames to the UI view in the LO thread We used to render them in the app main (GUI) thread, which is dangerous, accessing the headless frames in one thread while the LO thread (where the "main" LibreOffice code is running) might be updating and changing them. This fixes some problems like that part of the document did not show up. If I would test the app on a multi-core iPad, presumably I would have seen even more problems. But this also introduces new problems: Now the UI doesn't appear incrementally (for instance, with an actually progressing progress bar during the loading of the document) as it used to. Now it all appeads all of a sudden, everything at once. Which would be fine if it happened very quickly after starting the app, but it doesn't... on the original iPad it takes half a minute. Change-Id: I04068e0d884aa5cb86acefa76449aac4e081b193
2013-03-30 01:39:22 +02:00
// virtual bool AnyInput( sal_uInt16 nType );
Re-work the vcl aspects of the iOS port Don't try to use similar code as for OS X to manage windows, events etc. I.e. don't use UIKit in vcl to do that. Instead, just do as in the Android port, use the "headless" vcl backend. Do keep using CoreText, though, not FreeType & fontconfig. Start changing the iOS "Viewer" app to correspond to the Android "desktop" app (so it should be renamed). Work in progress since a long time, several crucial details still missing, but committing for now. Change-Id: Iac5fbf8def415e4d0d21e5200450a373420ad7ee
2013-03-20 09:07:52 +02:00
SalFrame *getFocusFrame() const;
Refactor the iOS Viewer app and rename it to "LibreOffice" No, it isn't any closer to being "ready" despite the name, but still, using the current approach, it clearly isn't restricted to be just a viewer. Also drop the verbose LOViewer prefix from class and file names in it. Change-Id: Ib4e8a31d6fa1b35169ee98cf2aa8f0f22957164c
2013-03-28 23:16:12 +02:00
void damaged( IosSalFrame *frame,
const basegfx::B2IBox& rDamageRect);
Render the "headless" frames to the UI view in the LO thread We used to render them in the app main (GUI) thread, which is dangerous, accessing the headless frames in one thread while the LO thread (where the "main" LibreOffice code is running) might be updating and changing them. This fixes some problems like that part of the document did not show up. If I would test the app on a multi-core iPad, presumably I would have seen even more problems. But this also introduces new problems: Now the UI doesn't appear incrementally (for instance, with an actually progressing progress bar during the loading of the document) as it used to. Now it all appeads all of a sudden, everything at once. Which would be fine if it happened very quickly after starting the app, but it doesn't... on the original iPad it takes half a minute. Change-Id: I04068e0d884aa5cb86acefa76449aac4e081b193
2013-03-30 01:39:22 +02:00
Try to handle selection resizing in a more "correct" way Faking mouse clicks is a stupid way to do it of course. Try to do it "right". For now just worked on moving the end handle, but once that works, similar code should be used for the start handle, too. Does not work yet. It is hard to extract out from SwEditWin::MouseButtonDown() exactly what all is relevant, and what isn't, for this use case. Change-Id: I76a226f787facbac645aaff8b4852d693bcf4ccb
2013-10-22 01:06:56 +03:00
// Functions scheduled to be run as "user events" in the LO thread
Revert "Try redrawing in multiple phases to avoid blocking the UI thread too long" This reverts commit 3aae02d02d418222b0b51748008ed5c9c1f1d3c2.
2013-03-31 21:54:33 +03:00
typedef struct {
bool done;
Render the "headless" frames to the UI view in the LO thread We used to render them in the app main (GUI) thread, which is dangerous, accessing the headless frames in one thread while the LO thread (where the "main" LibreOffice code is running) might be updating and changing them. This fixes some problems like that part of the document did not show up. If I would test the app on a multi-core iPad, presumably I would have seen even more problems. But this also introduces new problems: Now the UI doesn't appear incrementally (for instance, with an actually progressing progress bar during the loading of the document) as it used to. Now it all appeads all of a sudden, everything at once. Which would be fine if it happened very quickly after starting the app, but it doesn't... on the original iPad it takes half a minute. Change-Id: I04068e0d884aa5cb86acefa76449aac4e081b193
2013-03-30 01:39:22 +02:00
CGContextRef context;
CGRect rect;
Revert "Try redrawing in multiple phases to avoid blocking the UI thread too long" This reverts commit 3aae02d02d418222b0b51748008ed5c9c1f1d3c2.
2013-03-31 21:54:33 +03:00
} RenderWindowsArg;
DECL_LINK( RenderWindows, RenderWindowsArg* );
Render the "headless" frames to the UI view in the LO thread We used to render them in the app main (GUI) thread, which is dangerous, accessing the headless frames in one thread while the LO thread (where the "main" LibreOffice code is running) might be updating and changing them. This fixes some problems like that part of the document did not show up. If I would test the app on a multi-core iPad, presumably I would have seen even more problems. But this also introduces new problems: Now the UI doesn't appear incrementally (for instance, with an actually progressing progress bar during the loading of the document) as it used to. Now it all appeads all of a sudden, everything at once. Which would be fine if it happened very quickly after starting the app, but it doesn't... on the original iPad it takes half a minute. Change-Id: I04068e0d884aa5cb86acefa76449aac4e081b193
2013-03-30 01:39:22 +02:00
Try to propagate display size change to LO Change-Id: If52c0aa9290c377c08f2cec8c9e36d987c0ed9b6
2013-04-16 01:46:04 +03:00
DECL_LINK( DisplayConfigurationChanged, void* );
Try to handle selection resizing in a more "correct" way Faking mouse clicks is a stupid way to do it of course. Try to do it "right". For now just worked on moving the end handle, but once that works, similar code should be used for the start handle, too. Does not work yet. It is hard to extract out from SwEditWin::MouseButtonDown() exactly what all is relevant, and what isn't, for this use case. Change-Id: I76a226f787facbac645aaff8b4852d693bcf4ccb
2013-10-22 01:06:56 +03:00
typedef struct {
const void *documentHandle;
int x, y;
} SelectionEndMoveArg;
DECL_LINK( SelectionEndMove, SelectionEndMoveArg* );
Render the "headless" frames to the UI view in the LO thread We used to render them in the app main (GUI) thread, which is dangerous, accessing the headless frames in one thread while the LO thread (where the "main" LibreOffice code is running) might be updating and changing them. This fixes some problems like that part of the document did not show up. If I would test the app on a multi-core iPad, presumably I would have seen even more problems. But this also introduces new problems: Now the UI doesn't appear incrementally (for instance, with an actually progressing progress bar during the loading of the document) as it used to. Now it all appeads all of a sudden, everything at once. Which would be fine if it happened very quickly after starting the app, but it doesn't... on the original iPad it takes half a minute. Change-Id: I04068e0d884aa5cb86acefa76449aac4e081b193
2013-03-30 01:39:22 +02:00
pthread_mutex_t m_aRenderMutex;
pthread_cond_t m_aRenderCond;
Re-work the vcl aspects of the iOS port Don't try to use similar code as for OS X to manage windows, events etc. I.e. don't use UIKit in vcl to do that. Instead, just do as in the Android port, use the "headless" vcl backend. Do keep using CoreText, though, not FreeType & fontconfig. Start changing the iOS "Viewer" app to correspond to the Android "desktop" app (so it should be renamed). Work in progress since a long time, several crucial details still missing, but committing for now. Change-Id: Iac5fbf8def415e4d0d21e5200450a373420ad7ee
2013-03-20 09:07:52 +02:00
};
#endif // IOS_SALINST_H
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
Reference in New Issue Copy Permalink