EDGE_FULL_BACKGROUND
seasoned_geek
save.session=1
save.position=1
line.margin.visible=1
line.margin.width=6
font.base=font:Liberation Mono,size:10
font.text=font:DejaVu Serif,size:10
font.embedded.base=font:Serif,size:9
font.embedded.comment=font:Serif,size:9
font.monospace=font:DejaVu Sans Mono,size:9
font.vbs=font:DejaVu Sans Mono,size:9
check.if.already.open=1
caret.line.back=#F7F36D
title.full.path=1
title.show.buffers=1
braces,check=1
edge.mode=4
edge.column=80
edge.colour=#E7FAFA
# #F9E7FA #F3FAE7
statusbar.visible=1
statusbar.text.1=Lines:$(NbOfLines) Cursor $(LineNumber):$(ColumnNumber) $(OverType) $(ReadOnly) EOL:$(EOLMode)
wrap=0
if ((ll->widthLine != 0) && (ll->widthLine != LineLayout::wrapWidthInfinite)) {
farRight = ll->widthLine;
}
Neil Hodgson
The attachment is difficult to apply since is diffing each file individually instead of a patch for the whole change.
> Only spot I was a bit uncertain of was this
>
> int farRight = 500; // just a big number because we could be 2+ monitors wide
> if ((ll->widthLine != 0) && (ll->widthLine != LineLayout::wrapWidthInfinite)) {
> farRight = ll->widthLine;
> }
PRectangle rcSegment = rcLine;
rcSegment.left = vsDraw.theEdge.column * vsDraw.spaceWidth;
surface->FillRectangleAligned(rcSegment, Fill(vsDraw.theEdge.colour));
Neil
Roland Hughes
seasoned_geek: The attachment is difficult to apply since is diffing each file individually instead of a patch for the whole change.
It's all too complex. There appears to be some local problem with the order of left and right on your platform. There's also some unnecessary casting/truncation. It can just use the right side of the requested drawing rectangle and rely on FillRectangleAligned so there isn't a fuzzy partial pixel edge. PRectangle rcSegment = rcLine; rcSegment.left = vsDraw.theEdge.column * vsDraw.spaceWidth; surface->FillRectangleAligned(rcSegment, Fill(vsDraw.theEdge.colour));
Well, what you suggest was my first attempt and it definitely didn't work. There was also a dirth of comments in the code for the necessary functions.
Thanks for looking at it.
-- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) https://theminimumyouneedtoknow.com https://infiniteexposure.net https://johnsmith-book.com
Roland Hughes
I did some poking and the left-right problem isn't a local problem on my system. It's a fundamental bug of Gtk based/built Scintilla.
https://forum.xfce.org/viewtopic.php?id=15530
https://forum.xfce.org/viewtopic.php?id=15809
https://community.frame.work/t/responded-fedora-39-40-beta-gnome-45-46-dual-monitor-window-positioning-issue/47841
When initially hooked up to my NVS 510 card these monitors are "found" in the wrong order.
Like everybody else I drug them around and saved.
People who run even more monitors
Have even more issues with Gtk based applications. It appears Gtk
gets the monitor information from the hardware or OS level, not
the desktop level so it is completely unaware of position and
orientation changes made by the user. As such, rectangle math
cannot be trusted. It is also why the first cut using
FillRectangleAligned() filled in the wrong direction.
Just passing along since this won't be an issue in CsScintilla
--
You received this message because you are subscribed to a topic in the Google Groups "scintilla-interest" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/scintilla-interest/eLXYhJjPf20/unsubscribe.
To unsubscribe from this group and all its topics, send an email to scintilla-inter...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/e3d43ff3-ea0d-4720-9adc-4d62aeaef1b3%40logikalsolutions.com.
Neil Hodgson
> … the hardware or OS level, not the desktop level so it is completely unaware of position and orientation changes made by the user. As such, rectangle math cannot be trusted. It is also why the first cut using FillRectangleAligned() filled in the wrong direction.
If the claim here is that the x-axis is flipped then it's going to fail in a lot more places than just this example.
Neil
Roland Hughes
It does.
People running multiple monitors have mostly stopped using gtk based stuff. This is especially true for NVIDIA users. Driver updates for my 4-port card, for whatever reason, change the port search order. Today, when I booted after applying updates and took the picture for the reply, it found the monitor I want to be on the left (because it is) first. Previously it was always identified as 2 and had to be drug over which is how it was all last week and the day I was working on that code. During that time this code:
PRectangle rcSegment = rcLine; rcSegment.left = vsDraw.theEdge.column * vsDraw.spaceWidth; surface->FillRectangleAligned(rcSegment, Fill(vsDraw.theEdge.colour));
highlighted in the wrong direction. Today it worked because the
monitors were found in the "correct" order at power up.
I don't know how to phrase this properly. Don't know if "flipped"
is the correct word. Gtk has had a decades long problem with
multiple monitors. If you are a one monitor user, Gtk is good for
you.
In a Utopian world all of the extended monitors exist in one quadrant. We will say the right one because it makes it easier to talk about. The first monitor found per the hardware and driver is at (0,0). Yes, things grow negative and all that other stuff. I just want to take it back to 5th grade math class where we tried to do everything in the quadrant that was positive on both rails.
When you change the monitor order so the second is in front of the first found, the desktop appears to re-giz its view of the world putting the second monitor at (0,0) and the first monitor directly after it. Gtk, appears to still use the old (0,0) definition and puts the second monitor on the other side of the Y axis.
If that is what you mean by "flipped", then yeah. Gtk continues on rather oblivious to the actual monitor layout. Either oblivious or improperly updated.
I haven't personally tried this, but I'm told Gtk applications running on Cinnamon/KDE/non-Gtk based desktop really get hosed if you have one of these monitors.
To them (0,0) stays where it was even though the rest of the desktop knows it is now in Portrait mode.
As I recall (and I'm old so could be incorrect) XFCE was a Gtk based desktop. Almost nobody uses it anymore and new distros don't add support for it because it has had this problem forever.
Neil Hodgson
> {simple code} highlighted in the wrong direction.
If that highlights in the wrong direction then other Scintilla features like background colours, selections, and margins will appear incorrect as well.
> Today it worked because the monitors were found in the "correct" order at power up.
> I don't know how to phrase this properly. Don't know if "flipped" is the correct word. Gtk has had a decades long problem with multiple monitors. If you are a one monitor user, Gtk is good for you.
Was the problem here that the margin width and scroll position 'xStart' weren't added in as they are for the EdgeVisualStyle::Line case?
Neil
Roland Hughes
The monitor positions in global coordinates shouldn't matter as GTK provides a window coordinate space to draw in. Was the problem here that the margin width and scroll position 'xStart' weren't added in as they are for the EdgeVisualStyle::Line case?
No. It highlighted FROM column 80 to the left margin instead of the right. Been a problem with Gtk and multiple monitors for a long time. That's why so few Linux distros bother supporting Gtk based desktops anymore.
Problem is worse under some distros, like Arch, which doesn't automatically store "RightOf" when monitors are dragged.
One of the reasons I chose to use Cinnamon edition of Manjaro is the fact it gives you a real desktop which Gnome does not. The other reason was to see just how failed the Wayland experiment is. Yes, that's a Mint forum, but a pretty accurate summary of where things were in January. I can tell you that even with the latest updates on Manjaro Cinnamon the lock screen will not accept any password. Wayland does X11 emulation and it isn't very polite at informing X11 about the current arrangement of monitors. At the time of the problem I did not open the file documented in that post to see if it was missing the "RightOf" line. I suspect it was.
At the time I was creating the Yocto built OS for this device, we had a real PITA. Due to a smoke filled room mafia-type deal between Qt, NXP, and The Yocto Project, they dropped all X-11. You had to use Docker containers and Wayland. We could not, by application, control either screen position or orientation. The YAML for the container would let us control orientation, but not screen position. Instead of a group of dynamically positional "application bricks" they had to be bricks run by a single full screen window inside of a single app.
With this Wayland stuff there is now a disconnect between what the actual desktop knows and what Gtk (or other old libraries) "see" when making raw low-level X-11 calls. I don't expect the emulator to "improve" because the boys and girls pushing Wayland want to purge all X-11. Not wanting to totally dominate the mailing list with this topic, but a good discussion can be found here.
Basically all of the higher end graphics cards/drivers and desktops have compositors and Wayland wants to be "One Compositor to Rule Them All" with a direct connection to the kernel. Well that's just bright and beautiful for the "desktop" user. Ass-U-Me-ing every OpenSource product also abandons X-11 and re-writes with a Wayland UI library all creatures great and small will sleep as one tonight.
In my world, embedded systems for mostly medical devices, we don't need/want/or desire a "desktop" layer be forcibly inserted into the device that is trying to fix your heart or perform some other medical function. Despite all its flaws X-11 was proven, FDA approved (many version) and we knew just what to strip out to make it secure. Many/most of our devices don't even allow in-bound connection from the outside world in any form.
So yes Neil, I knew all of this; it comes up during every project; yet I still flipped left and right to make it work because that is what I had to do. I believe there was and possibly still is a series of calls one can do with X-11 based libraries to determine if this problem exists on the target. Didn't dig into that either.
Neil Hodgson
>> Was the problem here that the margin width and scroll position 'xStart' weren't added in as they are for the EdgeVisualStyle::Line case?
> No. It highlighted FROM column 80 to the left margin instead of the right.
> So yes Neil, I knew all of this; it comes up during every project; yet I still flipped left and right to make it work because that is what I had to do. I believe there was and possibly still is a series of calls one can do with X-11 based libraries to determine if this problem exists on the target. Didn't dig into that either.
Neil
Roland Hughes
Roland:Was the problem here that the margin width and scroll position 'xStart' weren't added in as they are for the EdgeVisualStyle::Line case?No. It highlighted FROM column 80 to the left margin instead of the right.Did you initially add xStart to the x value at which to start the background colour? The feature will not work correctly if the window is scrolled horizontally or the line number or folding margin is displayed unless these features are taken into account.
So yes Neil, I knew all of this; it comes up during every project; yet I still flipped left and right to make it work because that is what I had to do. I believe there was and possibly still is a series of calls one can do with X-11 based libraries to determine if this problem exists on the target. Didn't dig into that either.Flipping left and right makes no logical sense and is not needed on the 3 platforms I tried. Neil
You didn't look at the links.
The desktops don't bother to fill in RightOf or LeftOf in the X config files. Libraries that process those have no earthly idea which monitor really has (0,0) per the desktop. This is a widely know problem with Gtk that has gotten worse under Wayland-Westin.
No need to worry about it. I'm making EDGE_FULL_BACKGROUND, EDGE_MULTI-BACKGROUND, TAB_LIST changes to CsScintilla. It will just be rough if I want to merge anything from Scintilla in going forward but once I get these merged in I have everything I ever wanted/needed for base editor functionality.
Gtk had a good run, but that run is over.
Roland Hughes
Just to round out the discussion, I spun up a Manjaro VM so I could test some PKGBUILD stuff. Applied all updates then tried to install Emacs and run it.
While Emacs installed and runs fine on my Dev box, that was weeks ago.
Info "says" it has an X11 display server, but not really. I think it is finding that feeble Wayland X11 emulator.
Only passing this along as Manjaro and seemingly all other
distros are phasing out "purge-GTK" and X11 support.
It appears one must be at GTK 4.0 and there are some hoops to jump through.
https://docs.gtk.org/gtk4/wayland.html
Manjaro is an Arch derivative so it should "just work"
https://wiki.archlinux.org/title/Wayland
Then again, they do say "testing"
https://forum.manjaro.org/t/cinnamon-6-on-wayland-is-here-and-testing/152490
Even had to set a separate Github up for Wayland bugs.
Lex Trotman
Just to round out the discussion, I spun up a Manjaro VM so I could test some PKGBUILD stuff. Applied all updates then tried to install Emacs and run it.
While Emacs installed and runs fine on my Dev box, that was weeks ago.
Info "says" it has an X11 display server, but not really. I think it is finding that feeble Wayland X11 emulator.
Only passing this along as Manjaro and seemingly all other distros are phasing out "purge-GTK" and X11 support.
It appears one must be at GTK 4.0 and there are some hoops to jump through.
https://docs.gtk.org/gtk4/wayland.html
Manjaro is an Arch derivative so it should "just work"
https://wiki.archlinux.org/title/Wayland
Then again, they do say "testing"
https://forum.manjaro.org/t/cinnamon-6-on-wayland-is-here-and-testing/152490
Even had to set a separate Github up for Wayland bugs.
-- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) https://theminimumyouneedtoknow.com https://infiniteexposure.net https://johnsmith-book.com
--
You received this message because you are subscribed to the Google Groups "scintilla-interest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scintilla-inter...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scintilla-interest/3adfb447-8bd6-44bd-a004-728bf0d95597%40logikalsolutions.com.
Roland Hughes
On 9/2/2024 5:58 PM, Lex Trotman wrote:
> `GDK_BACKEND=wayland geany`
According to what little I read of the doc, that is what you have to do
with ALL Gtk applications on Wayland.
Gnome sucks and has sucked for years. I want a real menu. I have a flip
phone, not an iMbecile phone. Flicking through icons is the absolute
worst interface ever.
Choices were slim.
https://manjaro.org/products/download/x86
KDE is bloated and sucks. I'm also working with CopperSpice for my
OpenSource and the less Qt on the machine the better.
Xfce is Gtk based and hasn't properly supported multiple monitors in
years. (Over decade I believe.)
That leaves Cinnamon.
There appears to no longer be a Mate community edition. One could
install the desktop.
https://wiki.manjaro.org/index.php/Install_Desktop_Environments
But Manjaro has all kinds of warnings because they don't test with
multiple desktops installed.
Thank you for confirming there are issues though!
I don't have great confidence that Gtk will ever "just work" on Wayland
without users having to hack environment variables. At least not for the
next few years. CopperSpice should be releasing their Wayland stuff in
the not too distant future. (Might actually be unannounced and in the
code I pulled down today? Multiple "paid support subscription" customers
were after it and that's how the major non-academic changes get done to
the library.)
Thanks again for chiming in.