waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Feb 19, 2024 12:20:20 GMT -8
I just compared Clara's screen, my main Win10 22H2 install, a virtualbox Win2000 install, and a virtualbox Win11 23H2 install and they all have the exactly same accurate offsets. One thing in common that they have is Latin alphabet locales, while your is Cyryllic, which may be a factor, somehow. Specially for you I have added two options to set the X, Y offsets for the button. I've also found the reason for the tree item size fuckery. In winapi, there is a mechanism to multiply the height of treeview items by a integer, and on Win10 22H2 that integer is 3. And the default treeview item size is 8 (which is the value you'd get if you send a TVM_GETITEMHEIGHT message with WinSpy). Openshell reduces that by 2. (8 - 2) * 3 = 18, which was the final item height, and it's 2 px too tall, hence the 4th dot inbetween the expando buttons. To fix this, I handle TVM_INSERTITEM in the treeview wndproc and set the iIntegral to 1 for every item. As a bonus, now there is no need for different settings on Win10 and Win11, just set the tree item spacing to 0 and vista style. The question is, how in hell have you had the tree item spacing set to -2 and the spacing was correct? Does Win11 21H2 have different values coded in? I'd rather not know. All I want to know is that the new version looks right. Speaking of, I'll commit the changes to my fork of the WH repository, and if it looks good to you, as it does for me then I'll make a pull request.
|
|
|
|
Post by anixx on Feb 19, 2024 13:31:31 GMT -8
I just compared Clara's screen, my main Win10 22H2 install, a virtualbox Win2000 install, and a virtualbox Win11 23H2 install and they all have the exactly same accurate offsets. One thing in common that they have is Latin alphabet locales, while your is Cyryllic, which may be a factor, somehow. Specially for you I have added two options to set the X, Y offsets for the button. Look at this screenshot of mine:
On the left is real Windows 2000, on the right is my system with your mod. As you can clearly see, the X button is higher with your mod by 1px.
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Feb 19, 2024 13:54:02 GMT -8
The positioning is accurate for me. I checked on ReactOS too just to be sure and it's the same. I don't know why it is not accurate for you. You have the X, Y settings now to amend that situation. I won't be changing this again.
Other than that, is everything good?
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Feb 19, 2024 14:10:00 GMT -8
I'm debating on removing the scroll option. Until some 15 minutes ago I didn't know that windows actually has a option to set the amount of items scrolled by at a time. I had it set to 3 all that time, but for some retarded reason it scrolled by only one at a time in the treeview, with my mod or without. When I set it to 4, it scrolls by 2 items. But in other native treeview controls, such as in regedit, it does scroll by the correct amount. On the other hand on windows 11 it works the way it's intended, and my naive scrolling speed up implementation led to the treeview reaching escape velocity when scrolled. This, and the graphical glitches makes me want to remove that feature. I just discovered that after my fix that sets the iIntegral to 1 for every item, the amount of items scrolled by at a time in the treeview matches the amount set in the settings app. Looks like I've just uncovered yet another glitch in micr  soft windows. |
|
|
|
Post by anixx on Feb 19, 2024 17:30:27 GMT -8
The positioning is accurate for me. I checked on ReactOS too just to be sure and it's the same. I don't know why it is not accurate for you. You have the X, Y settings now to amend that situation. I won't be changing this again.
Other than that, is everything good?
I wonder, what is the position of the 3D button when you hover over it? Does it have space above?
Everything elso is very good, but waiting for the feature of having a menu item.
|
|
|
|
Post by anixx on Feb 19, 2024 17:37:24 GMT -8
The positioning is accurate for me. I checked on ReactOS too just to be sure and it's the same. I don't know why it is not accurate for you. You have the X, Y settings now to amend that situation. I won't be changing this again.
Other than that, is everything good?
Windows 2000 has 6 px on the top (click on the picture):
P.S. It seems, there is a difference on our Win2000 screenshots. Maybe, the distance depends on Window Metrics, etc.
|
|
|
|
Post by anixx on Feb 22, 2024 12:07:25 GMT -8
Report after the last update. Win11 22000.
The items seem to be too dense with setting -2 in Classic Explorer:
With setting 1 Classic Explorer, the spacing is 1px, the final dotted line corner is OK, but otherwise the lines look overlapping:
With setting 2 in CE, the corner of the dotted line has a spur:
I think, spacing 1px was the default in older Windows?
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Feb 22, 2024 12:36:05 GMT -8
The new recommended setting is 0. My mod works on the assumption that this setting is correct, now it's supposed to be the same on Win10 and Win11 alike. I should have updated the description in this thread.
|
|
|
|
Post by anixx on Feb 22, 2024 13:03:52 GMT -8
This screenshot was taken with CE setting 2. The dotted lines in the mod settings were disabled, but TVS_HASLINES style was added. In this case the lines look perfect:
Maybe, instead of custom line draw, just use this style?
|
|
|
|
Post by anixx on Feb 22, 2024 13:10:07 GMT -8
Tried the recommended settings with the interval set to 0. The lines look good. Some icons are tightly close but this is the case with Windows Device Manager, for instance...
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Feb 22, 2024 13:18:33 GMT -8
The reason my mod draws it's own lines at all is because when I made it I had no idea about the iIntegral value. When it is set to 3, as is the case on Windows 10 (but not 11), and TVS_HASLINES enabled, treeview item icons are for some reason partially obstructed with white rectangles, which produces a very ugly look. Therefore, as a cirvumvention, I coded my own dotted lines, which aren't always 100% accurate. Now I tested your report and it seems that icons are no longer obstructed when the iIntegral value is set to 1. This means that I can remove the custom line drawing code.
|
|
Cynosphere
Freshman Member
Posts: 46 
OS: Windows 10 Home 22H2
Theme: Classic (Scheme: Amora Focus)
CPU: AMD Ryzen 7 3700X
RAM: 32 GB
GPU: AMD Radeon RX 7900 XT
|
Post by Cynosphere on Feb 22, 2024 13:40:52 GMT -8
After updating to 1.0.1 Quick Access has seemed to resize itself to 48px tall
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Feb 22, 2024 14:05:54 GMT -8
Looks like its iIntegral value is set somewhere else. I didn't catch this problem because I don't use quick access. At least I can reproduce this, and it will be fixed.
|
|
waldemar21214
Freshman Member
Posts: 94
OS: Windows 10
Theme: Classic
CPU: i5-12400f
RAM: 16 GB DDR4 3600mhz
GPU: PNY 3060TI
|
Post by waldemar21214 on Feb 22, 2024 14:59:49 GMT -8
Released 1.0.2 on my fork It should fix the quick access being too big, and the lines are no longer being drawn by my code. Shadow/Highlight color functionality is retained. One downside is that there will be now gaps in the line if the Expando buttons are disabled while using Classic theme. I have added a explicit warning not to disable the buttons if Classic theme is used. If no problems are reported, I will make a pull request again.
Also BTW, just learning git as I go. Until recently I didn't use git at all, I used "New folder (3)" and "rwwgeqgr4qgggy5hg5h3" or "aaa" instead. I've noticed that when my pull requests to the WH repository get accepted, my fork is one or more commits ahead (those are the commits that I do on my local repo and then push to origin), and one behind of the upstream repo, which is what I presume to be a "pull request accepting" commit, if that makes sense. This leads to me having to do weird tricks to get it sorted so that it matches upstream. I would have assumed that when my pull requests are accepted, the exact same commits from my fork are merged into upstream, and my fork, both on github and local machine, is up do date with upstream from the get go. Is that normal? Or have I brought this upon myself with my subpar git skills?
|
|
|
|
Post by anixx on Feb 22, 2024 20:59:15 GMT -8
Also BTW, just learning git as I go. Until recently I didn't use git at all, I used "New folder (3)" and "rwwgeqgr4qgggy5hg5h3" or "aaa" instead. I've noticed that when my pull requests to the WH repository get accepted, my fork is one or more commits ahead (those are the commits that I do on my local repo and then push to origin), and one behind of the upstream repo, which is what I presume to be a "pull request accepting" commit, if that makes sense. This leads to me having to do weird tricks to get it sorted so that it matches upstream. I would have assumed that when my pull requests are accepted, the exact same commits from my fork are merged into upstream, and my fork, both on github and local machine, is up do date with upstream from the get go. Is that normal? Or have I brought this upon myself with my subpar git skills?
One can debug the mod locally, then go to the windhawk mods repo, click "edit file" own mod, past the latest version and click "commit". After the commit is accepted, delete the branch. Matter of convenience and taste though. |
|
|
|
Post by anixx on Feb 22, 2024 21:04:27 GMT -8
Released 1.0.2 on my fork
I do not see dotted lines at all now...
TVS_HASLINES is not getting set. When I set manually using Window Detective, all looks great.
Found the issue: Classic Explorer settings.
|
|
clara
Sophomore Member
Posts: 118
|
Post by clara on Feb 22, 2024 22:49:10 GMT -8
I do not see dotted lines at all now...
TVS_HASLINES is not getting set. When I set manually using Window Detective, all looks great.
Weird, works for me. Maybe some Windows 11 quirk is at play?
waldemar21214 Visually it looks stunning! One problem persists for me: removing scrolling speed controls doesn't seem to have fixed the tearing issues, at least in my case. |
|
|
|
Post by anixx on Feb 22, 2024 23:54:59 GMT -8
I do not see dotted lines at all now...
TVS_HASLINES is not getting set. When I set manually using Window Detective, all looks great.
Weird, works for me. Maybe some Windows 11 quirk is at play?
I found the cause: in Classic Explorer was set XP style instead of Vista style. |
|
|
|
Post by anixx on Feb 23, 2024 0:05:23 GMT -8
By the way, the scroll speed issue got fixed for me, now the scrolling is as fast as it should be!
|
|
|
|
Post by anixx on Mar 4, 2024 7:39:53 GMT -8
I have a problem with this mod: it does not start work by itself despite being enabled. I have to disble it and re-enable to make it working.
|
|
soft windows.
