On 14/04/13 21:02, Pavel Sanda wrote:
> Liviu Andronic wrote:
>> to have a LyX plugin in Pidgin,
>
> You mean for equations? P
Of course, a plugin in Pidgin would seem the natural thing to do, as all the
infrastructure for letting users register and find each other would already be
there.
However, how difficult is it to extrapolate the LyX editor and merge it into
Pidgin ?
This is related to one of the possible further projects I had dropped on the
GSoC thread, i.e., the point 4) in the attached/forwarded e-mail. Would it be
possible to at least confine a subset of LyX within a sound reusable Qt widget
that doesn't depend on a zillion external libraries, converters, tools, the
whole LyX ? Does it make sense at all ?
Of course, my personal use-case is mostly driven by the need for chatting with
equations. Though, being capable to drag'n'drop images or drawings or other
external material in the chat doesn't seem bad either.... but in the end we may
need the whole LyX engine behind the scene....
And also, in the collaborative editing feature, we need anyway users to be able
to find each other etc.... seems more like pulling Pidgin features within the
gigantic LyX, in the end!
Opinions ?
T.
--- Begin Message ---
On 11/04/13 04:27, stefano franchi wrote:
> Bottom line: let your creative juices flow and submit ideas to the list.
Sure: some of these may have been discussed on the ML in various occasions:
0) horizontal scrollbar for large pictures (something is being discussed on the
list now, which is very related, but we don't need only big tables or
equations,
but also big figures to possibly enable the horizontal scrollbar). (ok,
perhaps
too easy, e.g., for a LyX-newbie ?).
1) (need a LyX experienced person): re-engineer the internals of LyX for
handling
UI<->model interactions, namely get rid of text-based encoding of params when
possible (this doesn't prevent anyway the mini-bar to stay there and work,
nor
to send LFUNCs through external command-line clients, simply these will be
moments in which a string encoding will be used, but I don't like that to be
used ALWAYS, for any action. Also, introduce a "return info flow" by which
the
UI can get smth. back from a ::dispatch(), something that now is not
possible,
or is done in weird ways, etc..
2) smooth scrolling: when scrolling a LyX document up and down with the keyboard
(through up, down, page-up, page-down keys, but also when occurring as result
of moving right and left), the WorkArea may scroll smoothly from the current
position to the new position. The problem with the current behaviour is that
the view is changed abruptly, something that is not a problem for small
moves,
while moving across regular text. But, as soon as a table or picture or big
equation comes in the loop, the position is moved a lot, causing visual
annoyance.
I heard especially Mac users to complain about how LyX scrolls up and down.
They're a community particularly used to smoothness in general. They'll love
such a feature.
Note that while doing smooth scrolling, we should NOT be redrawing the whole
screen all the time, but rather scroll it and redraw only the new visible.
This feature may not be energy-saving for laptops, so allow for disabling it
in preferences, or automatically disable it when on battery.
3) improve Advanced F&R, making it fast, usable, non-failing in corner cases,
namely
implement what is now there as a proof of concept. This can be done in 2
ways:
3.a) build a find engine within various insets, able to match parts and
sub-parts
of the LyX document. Criticality is to build a custom regexp engine that
makes sense when matching sub-graphs/portions of LyX docs;
3.b) add an additional mode/flavor of export (e.g., runparams.flavor option),
in which the find options are carried along the runparams, so that
insets
can export only what's useful for the later matching phase.
This way Advanced F&R would get rid of the awful and heavy-weight regexp
post-processing that is there now, to get rid of unneeded elements,
depending
on search options.
4) isolate part of the functionality of LyX (notably the equation editor)
within a
reusable QLyX element, that can be used for building other applications, see
5).
5) LyX enhanced CHAT client. May be built as a stand-alone application, rather
than
having LyX grow with further/too-many functionality. A server would be
needed to
allow users find each other (particularly when behind firewalls).
Development of
the feature is a different issue than who would host the server and when.
I wouldn't expect too traffic to be needed, though.
For this, I had dropped on the list a proof of concept working patch ~1,5
year ago.
6) Enhance LyX with remotely interactive writing capabilities, namely allow
multiple
users to work remotely and interactively on the same document. Solve issues
due to
conflicting editing, having a way to avoid them from the ground up, or have
a GUI
to solve them later.
A server might be needed for this as well, to let users find each other. It
can
be the same server as 5), though.
For this, I had dropped on the list a proof of concept working patch ~1,5
year ago.
7) build a LyX-enhanced LaTeX editor for Firefox as and Add-On, possibly
exploiting
the component in 4). But, nowadays the preferred way to do such things might
be
through pure HTML5 code, w/out any LyX-ing at all -- just an idea!
Comments welcome.
T.
--- End Message ---
