[Lazarus] Dark themed lazarus

[Anthony Walter via Lazarus]

I finally got an acceptable darked themed version of Lazarus setup.

Loading Image...

Running Linux Cinnamon
Theme is named Arc Darkest
Maxmimus extension added to remove titlebars
Code editor colors mostly ripped from VS Code

Btw, if anyone runs Linux Gtk2 Lazarus, please let me know if feel you the
Object Inspector grid is laggy (actually hits the CPU at 50% on my 2.6 GHz
Core2Duo) when mouse dragging through properties. I wrote a fix that
reduces the amount of work it does when redrawing items, but since the OI
doesn't seem laggy on Windows/Mac/Qt, I hesitate to submit my patch.

[Maciej Izak via Lazarus]

2018-04-05 8:04 GMT+02:00 Anthony Walter via Lazarus <

Post by Anthony Walter via Lazarus
I finally got an acceptable darked themed version of Lazarus setup.

Looks good for me :) any link to patch/tests?

[Mattias Gaertner via Lazarus]

On Thu, 5 Apr 2018 02:04:15 -0400

Post by Anthony Walter via Lazarus
I finally got an acceptable darked themed version of Lazarus setup.
http://cache.getlazarus.org/images/lazarus-dark.png
Running Linux Cinnamon
Theme is named Arc Darkest
Maxmimus extension added to remove titlebars
Code editor colors mostly ripped from VS Code
Btw, if anyone runs Linux Gtk2 Lazarus, please let me know if feel you the
Object Inspector grid is laggy (actually hits the CPU at 50% on my 2.6 GHz
Core2Duo) when mouse dragging through properties. I wrote a fix that
reduces the amount of work it does when redrawing items, but since the OI
doesn't seem laggy on Windows/Mac/Qt, I hesitate to submit my patch.

Can you give more details about the gtk2 patch?

Mattias
--

[Anthony Walter via Lazarus]

About the patch, I am still making some changes, but what I've done is the
this. Currently the object inspector draws every row even if it doesn't
need redrawing. I modified the SetItemIndex method to InvalidateRect the
OldIndex and NewIndex, then only redraw those two rows in DoPaint. I added
a public Fast property for testing so that you can toggle between the old
behavior and new behavior at runtime, allowing users to measure the
difference both in responsiveness and CPU usage.

So far with this change if you click, hold down the mouse, and drag up/down
quickly in the inspector the lag seems greatly reduced, as well as less CPU
usage. I have not testing how this effects Windows/Qt/Mac yet, but as I
said in my OP those platforms/widget sets did not suffer from the same
laggy like behavior. Either way, shortly I'll submit it with a patch, a
stand alone example testing program, and let others try it for themselves.

Next I might tackle the lagginess in drag moving controls on the form
designer. Does that seem like a laggy problem to anyone else?

[Maciej Izak via Lazarus]

2018-04-05 12:16 GMT+02:00 Anthony Walter via Lazarus <

Post by Anthony Walter via Lazarus
Next I might tackle the lagginess in drag moving controls on the form
designer. Does that seem like a laggy problem to anyone else?

Probably you mean : https://bugs.freepascal.org/view.php?id=33486

I was not able to spend enough time on this problem, so any patch is
welcome.

[Anthony Walter via Lazarus]

Maceij, I get the same lag both in the docked form designer and the normal
form designer when it comes to dragging controls around the form. My idea
is to create a bit, and not actually move the controls when you are
dragging, but rather move or resize an overlay window previewing the new
shape. Only when you release the mouse would it hide the overlay and
reposition or resize the selected controls.

As a side enhancement, it would display information about the top, left,
width, and height of the changes inside the overlay as you dragged. Also it
might display the name and class of the control centered within the
overlay. Does that sound reasonable?

[Maciej Izak via Lazarus]

Post by Anthony Walter via Lazarus
As a side enhancement, it would display information about the top, left,
width, and height of the changes inside the overlay as you dragged. Also it
might display the name and class of the control centered within the
overlay. Does that sound reasonable?

Sure! Sorry for late reply, but somehow I overlooked your message. Good
idea, this was also in my TODO but with low priority, so feel free to do
this :).

[Andreas Frieß via Lazarus]

Post by Maciej Izak via Lazarus
2018-04-05 12:16 GMT+02:00 Anthony Walter via Lazarus <

Post by Anthony Walter via Lazarus
Next I might tackle the lagginess in drag moving controls on the
form designer. Does that seem like a laggy problem to anyone else?

Probably you mean : https://bugs.freepascal.org/view.php?id=33486

This Bugreport have not only to do with moving a component. Switching
between code and design is the strangest lag.

Post by Maciej Izak via Lazarus
I was not able to spend enough time on this problem, so any patch is
welcome.
--
Best regards,
Maciej Izak

Andreas

--

[Juha Manninen via Lazarus]

On Thu, Apr 5, 2018 at 1:16 PM, Anthony Walter via Lazarus

Post by Anthony Walter via Lazarus
So far with this change if you click, hold down the mouse, and drag up/down
quickly in the inspector the lag seems greatly reduced, as well as less CPU
usage.

Do you mean to click on a property name in OI, then drag it on top of
other property names?
I don't see any serious lag here on my Atom CPU mini-laptop with Linux
+ LCL-GTK2.
Besides, why would you drag the property names or values? OI does not
support drag-n-drop between properties.
Shortly put: I cannot reproduce.

Post by Anthony Walter via Lazarus
Either way, shortly I'll submit it with a patch, a stand alone
example testing program, and let others try it for themselves.

Yes please.

Juha
--

[Anthony Walter via Lazarus]

Juha, no I mean this, reflecting this, the old way the OI handled changes:

http://cache.getlazarus.org/videos/drag-inspector.mp4

The lag is visceral. Whenever an item index changes, the entire OI is
invalidated. My change repaints 2 items, the previous row, and the new row.
It's must faster.