Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


On Mon, Mar 7, 2011 at 3:52 PM, Jaime R. Garza <garzaj@gmail.com> wrote:

Well the problem is that I'm not a programmer. :-(

So I can't really make it by myself. :-(

That's why I'm just giving my thoughts and opinions. Probably we could find
a sponsor, the EU commission, for example, sponsors a lot of different
projects, maybe we could make a proposal. The question is how many
programmers will be willing to do this getting money from a sponsor? I could
help making a proposal and so on, but I will not do this until programmers
leading the development of LO give me a clear commitment.


Well this is open source, so the answer you most likely to get is: time and
money.

Limited resources means that if you pay the lead programmers to work idea,
you will halt the development libo since they will have to leave the current
projects to work on your idea.

The other scenario is that you get the money, hire your developers, build
the patch, and try to submit it. If the patch is not possible you can always
fork.

In other words, you don't need permission, feel free to do it any way you
can, and once built you can submit it for approval. Developers can't give u
an approval on something that doesn't exist which goes to my original
comment. Start by doing a proof of concept, and then engage with developers.


Cheers!

On Mon, Mar 7, 2011 at 22:45, Alexandro Colorado <jza@openoffice.org>wrote:



On Mon, Mar 7, 2011 at 3:19 PM, Jaime R. Garza <garzaj@gmail.com> wrote:

Hello Alexandro,

Who can decide within LO to separate officially the engines from the UI?

For me that's now a must! But who needs to be convinced so that this is
actually done?


Well I am not sure LibO mantain the UI, most of these areas still rely on
the original codebase from OOo. The UI is really old code written in the
late 80's. So you will need to do a lot of learning on the requirements from
SALT, VCL, and other layers within the OOo architecture. Which is what I
mean, with actually understanding how OOo works first to think about
proposing hacks and ports. I would recommend you to read the original
developer guide to see how most of the OOo components are build and how the
IDL is structured. Then you can get a sense on the amount of work that would
be needed for a port or an engine extraction.

Unfortunately this is when most proponents stop listening and replying,
until someone new comes with this proposal.




Cheers!


On Mon, Mar 7, 2011 at 22:07, Alexandro Colorado <jza@openoffice.org>wrote:



On Mon, Mar 7, 2011 at 2:43 PM, Jaime R. Garza <garzaj@gmail.com>wrote:

As I have mentioned before, I think, the best solution would be to make
a
HTML5 based LO!


There are some web editors --- open source ones. One is the one EyeOS
uses, and it looks like a word abiword text processor. Of course it only
edits and saves in HTML and PDF. But is a start. Having something like
ODFKit to export to ODT would be the second stage. The thing is that LibO
nor OOo has their engines separated from the UI. URE is too separated even
from the traditional API. So many things are not present in URE. So there is
a lot of piping neediing to go into doing such a thing. Also LibO/OOo is not
only a text editor so de-bundling might be the biggest challenge but again
this is the 10 foot view of the issue.





On Mon, Mar 7, 2011 at 21:27, Alexandro Colorado <jza@openoffice.org>
wrote:

Linux on Arm is not the same as LibreOffice on ARM. My N900 runs
Debian
Linux on Arm, but it has X connected to it. Without it, LibO won't
run.
Thats the issue we had earlier with OOo on OSX.

On Mon, Mar 7, 2011 at 7:58 AM, Chao Sun <sunchao@redoffice.com>
wrote:

Hello Alexandro,



However, I would rather see some code, and not just ideas. My
question
is
when will u launch a proof of concept, or at least try?


We are typing some code now. However, firstly we need to do the
"cross
compile" part. And some issues need to address. I've heard the
"linux on
ARM" has already been done. And if anybody have access to those
assembly
code.  Or have clue where we should headed, please ring the bell.

Cheers
Chao








Cheers!

Jaime

On Fri, Mar 4, 2011 at 11:56, Mirek M. <mazelm@gmail.com>
wrote:

2011/3/4 Jaime R. Garza <garzaj@gmail.com>

In my humble opinion it will be great to have the UI separated
from
all
the
rest. Think of WebKit in the Browser! That would allow to have
a QT
UI,
a
GTK UI, a Multitouch UI, etc.


There are two projects already underway with this goal in mind:
WebODF<http://www.webodf.org/>and
ODFKit <http://gitorious.org/odfkit> (WebODF seems to be an
evolution
of
ODFKit, and although it uses web technologies, it's still
suitable
for
desktop and mobile applications).

On Fri, Mar 4, 2011 at 02:52, Chaosun <sunchao@redoffice.com>
wrote:

Well, I had a quite long chat with tml_ regarding the porting
to
Android
issue. The truth is that we are planning to have a try.
However the
workload
is tremendous due to the loss of UI. Also to fit the
platform, we
need
a
complete redesign on UE.

The possible works would be:

1. Get rid of all the UI related modules such as vcl, sfx2,
framework
and
corresponding services etc.
2. A engine like LibreOffice, no UI, only provides APIs for
further
development.
3. Create a UI for multitouch devices
Just name a few. no one is a easy work. Also, I'd like to
hear from
you.
Please do advice!

Regards
Chao
--
Unsubscribe instructions: E-mail to
discuss+help@documentfoundation.org
Archive:
http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity
***



--
Unsubscribe instructions: E-mail to
discuss+help@documentfoundation.org
Archive:
http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity
***



--
Unsubscribe instructions: E-mail to
discuss+help@documentfoundation.org
Archive:
http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity
***



--
Unsubscribe instructions: E-mail to
discuss+help@documentfoundation.org
Archive:
http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity
***




--
*Alexandro Colorado*
*OpenOffice.org* Español
http://es.openoffice.org

--
Unsubscribe instructions: E-mail to
discuss+help@documentfoundation.org
Archive: http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity ***



--
Unsubscribe instructions: E-mail to
discuss+help@documentfoundation.org
Archive: http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity ***




--
*Alexandro Colorado*
*OpenOffice.org* Español
http://es.openoffice.org

--
Unsubscribe instructions: E-mail to
discuss+help@documentfoundation.org
Archive: http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity ***


--
Unsubscribe instructions: E-mail to
discuss+help@documentfoundation.org
Archive: http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity ***




--
*Alexandro Colorado*
*OpenOffice.org* Español
http://es.openoffice.org





--
*Alexandro Colorado*
*OpenOffice.org* Español
http://es.openoffice.org





-- 
*Alexandro Colorado*
*OpenOffice.org* Español
http://es.openoffice.org

-- 
Unsubscribe instructions: E-mail to discuss+help@documentfoundation.org
Archive: http://listarchives.documentfoundation.org/www/discuss/
*** All posts to this list are publicly archived for eternity ***

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.