scintilla-interest archive @ ASPN

[scintilla] Re: using TAB KEY IN table window

Philippe Lhoste (PhiLho@...)

Vissu K a écrit :
> I am creating a application (timesheet) in centura 2.1 with table window 
> with 64 columns (empno, empname, date1, comment1, date2, comment2, 
> .......date31,comment31).
> Normally when TAB key presses  in comment1 it moves input focus to 
> date2. But my user wants to move input focus in nextrow date1.

It seems this message is targeted to another mailing list...

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --	--  --	--  --	--  --	--  --	--  --	--  --

_______________________________________________
Scintilla-interest mailing list
Scintilla-interest@...
http://mailman.lyra.org/mailman/listinfo/scintilla-interest

[scintilla] using TAB KEY IN table window

Vissu K (centuradev@...)

I am creating a application
(timesheet) in centura 2.1 with table window
with 64 columns (empno, empname, date1, comment1, date2, comment2,
.......date31,comment31).
Normally when TAB key presses  in comment1 it moves input focus to date2.
But my user wants to move input focus in nextrow date1.

Thanks for the Comment.

Vissu.

Re: [scintilla] Separating [foreColor, font, font-size, ...] from [backColor] in style

Neil Hodgson (nyamatongwe@...)

Armel Asselin:

> the problem is that I really do not have time currently to dig into
> solutions... which i do not need for myself
> if someone is ready to investigate seriously something which is acceptable
> in main stream Scintilla (I have plenty of ideas but no time), i can send
> ...

   For this to progress, someone has to step up to champion the
feature and be prepared to produce releases in parallel to mainstream
development while all issues are worked out.

> There are also
> modifications in Accessors so as to use the additional bits.

   This may be a problem as the Accessors are an interface to
externally compiled projects such as containers and shared library
lexers so need to maintain binary compatibility.

   Neil
_______________________________________________
Scintilla-interest mailing list
Scintilla-interest@...
http://mailman.lyra.org/mailman/listinfo/scintilla-interest

Re: [scintilla] Separating [foreColor, font, font-size, ...] from [backColor] in style

Armel Asselin (asselin.armel@...)

>> I wonder about something, could
the LineLayout style buffer be 
>> 'run-length'
>> encoded? it is a 'constant' (once loaded, never touched) and we access it
>> from left to right/right to left no? maybe it's heavy stuff though to add 
>> a
>> small iterator on that
>
>   Run length encoding hasn't been a significant win when I have
> looked at it in the past due to short average runs but you could do
> some experiments to see if it is with wider style elements.
the problem is that I really do not have time currently to dig into 
solutions... which i do not need for myself
if someone is ready to investigate seriously something which is acceptable 
in main stream Scintilla (I have plenty of ideas but no time), i can send a 
patch for the CellBuffer stuff (its a bit mixed with the SC_START_ACTION 
notification stuff), note that the modifs touches somewhat Document also 
because Document uses a bit too eagerly internal cell buffer coordinates 
(i.e. pre-multiplied by the number of bytes per char). There are also 
modifications in Accessors so as to use the additional bits.

Armel

_______________________________________________
Scintilla-interest mailing list
Scintilla-interest@...
http://mailman.lyra.org/mailman/listinfo/scintilla-interest

[scintilla] Scintilla 1.70 released

Neil Hodgson (nhodgson@...)

Scintilla 1.70 is now
available from the scintilla.org web site.

    Scintilla 1.70 is a minor enhancement and bug fix release with an 
emphasis on internationalisation. On GTK+, approximate character set 
conversions are used for pasting and other actions and internationalised 
keyboard input is used at all times.

    There are new margin types SC_MARGIN_BACK and SC_MARGIN_FORE. Only 
valid code pages may be set.

    A detailed list of changes is available on the history page.

    Thanks to the contributors of code and documentation and to the testers.

    Neil
_______________________________________________
Scintilla-interest mailing list
Scintilla-interest@...
http://mailman.lyra.org/mailman/listinfo/scintilla-interest

Re: [scintilla] Separating [foreColor, font, font-size, ...] from [backColor] in style

Neil Hodgson (nyamatongwe@...)

Greg Smith:

> Things like GetStyledText will need rethinking. I would assume that it goes
> without saying that existing apps using 1 byte style buffers would continue
> to work without change; if this is not possible, are we heading towards
> Scintilla 2.x.

   Don't worry. Any extended version I distribute will be highly
compatible with the current version. It should behave exactly the same
unless a new creation call or option is used or some API is called.

   GetStyledText will work the same for 8/8 setups although it may
work differently for other configurations. It may even be unavailable
for other configurations if a different API is better suited to those
cases such as separately retrieving document and styling data.

   Breaking compatibility needs more justifying features than just a
wider styling buffer which is why SinkWorld is such an ambitious and
slow project.

   Neil
_______________________________________________
Scintilla-interest mailing list
Scintilla-interest@...
http://mailman.lyra.org/mailman/listinfo/scintilla-interest

RE: [scintilla] Separating [foreColor, font, font-size, ...] from [backColor] in style

Greg Smith (greg@...)

Hi Guys,

I am getting confused. Is the current proposal (as a trial) to:

1) Separate out the style bytes from the text bytes
2) Allow different style sizes (0,1,2,4) bytes
3) Extend APIs in a backwards compatible way

Things like GetStyledText will need rethinking. I would assume that it goes
without saying that existing apps using 1 byte style buffers would continue
to work without change; if this is not possible, are we heading towards
Scintilla 2.x.

Greg Smith


_______________________________________________
Scintilla-interest mailing list
Scintilla-interest@...
http://mailman.lyra.org/mailman/listinfo/scintilla-interest

Re: [scintilla] Separating [foreColor, font, font-size, ...] from [backColor] in style

Neil Hodgson (nyamatongwe@...)

Armel Asselin:

> I wonder about something, could the LineLayout style buffer be 'run-length'
> encoded? it is a 'constant' (once loaded, never touched) and we access it
> from left to right/right to left no? maybe it's heavy stuff though to add a
> small iterator on that

   Run length encoding hasn't been a significant win when I have
looked at it in the past due to short average runs but you could do
some experiments to see if it is with wider style elements.

   Neil
_______________________________________________
Scintilla-interest mailing list
Scintilla-interest@...
http://mailman.lyra.org/mailman/listinfo/scintilla-interest

Re: [scintilla] Separating [foreColor, font, font-size, ...] from [backColor] in style

Armel Asselin (asselin.armel@...)

>> there is one problem though:
most styling API need to accept "long" (so 
>> as
>> to have at least 32 bits) and in the styling buffer somewhere scintilla 
>> uses
>> an array of such 'long', particularly during line layout, it may take 
>> much
>> memory (4 times as before for this buffer)
>> so the first question is this acceptable for the main stream distrib?
>
>   For the LineLayout object, going for 4 byte styles always will
> multiply line layout size by a little less than a factor of 2 as there
> is already an int for each position. I feel this is an unreasonable
> burden to current users memory budgets especially those who have
> turned on whole document layout caching. Allocating style values
> inside LineLayout the same width as in CellBuffer would be more
> reasonable allowing users to control the memory budget. I'm not sure
> the additional capability of 32 bits is worth the cost over 16 bits.
>
>   As I'm concerned about potential problems with this change, it
> would be best to publish a version with the change to it can be
> exercised by more people before integration into the main
> distribution.
hum, hum, so so, maybe we could go for a patch concerning only the 
CellBuffer now, the interfaces would change to 'long's... but it does not 
imply having to change everything behind.
the code is already built to have dynamic number of styles bytes per 
character and the code in CellBuffer for that could be used or put elsewhere 
(probably as inline to avoid speed impact). currently I do not see the 
difference with respect to fixed size implementation but i did not study 
that precisely.

i'll try to find some time to make a patch (the latest version i integrated 
was 1.67) but the cellbuffer stuff should not have other impact... arggh, 
while i write that i realize that it is mixed with my START_ACTION 
notification... ok, i've got to see if i can separate stuff.

I wonder about something, could the LineLayout style buffer be 'run-length' 
encoded? it is a 'constant' (once loaded, never touched) and we access it 
from left to right/right to left no? maybe it's heavy stuff though to add a 
small iterator on that

Armel


_______________________________________________
Scintilla-interest mailing list
Scintilla-interest@...
http://mailman.lyra.org/mailman/listinfo/scintilla-interest

Re: [scintilla] Problems with the PRIMARY clipboard

Neil Hodgson (nyamatongwe@...)

HyperQuantum:

> I can confirm this. I have exactly the same problem in SciTE. I can't
> copy-paste from one tab to another using the middle mouse button. Very
> annoying. I also use the GTK version (KDE).

   This is a known problem:
http://mailman.lyra.org/pipermail/scite-interest/2005-October/006611.html
   I don't intend to work on this.

   Neil
_______________________________________________
Scintilla-interest mailing list
Scintilla-interest@...
http://mailman.lyra.org/mailman/listinfo/scintilla-interest