Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Wine/Spider Monkey Panel/Script bugs on Linux (Read 12773 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #75
@paregistrase,

thanks for your testing.

In your previous post GDI+ is not working correctly because it is seen in the screenshots, see right top corner.
Minimize, fullscreen and close buttons are not parsed right, they are displayed as 0 2 r.

In your last post GDI+ is working correctly and the weird yellow color is also a GDI+ bug, this happens in old GDI+ versions...

@marc2k3, at first I thought so too, that it is a GDI+ issue ( and I still think it is ) but I still don't understand why your berrie image does not crash in your Album art.js and is displayed blue.
But in your Thumb.js it does crash, in both test the same GDI+ version was used with a SMP panel. So what's so different between Album art.js and Thumbs.js? Though the cover.jpg with the generic gray ICC profile crashes in both Album art.js and Thumbs.js, that's why I posted this comparison in the first place.

-TT



Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #76
@paregistrase,

thanks for your testing.

In your previous post GDI+ is not working correctly because it is seen in the screenshots, see right top corner.
Minimize, fullscreen and close buttons are not parsed right, they are displayed as 0 2 r.

In your last post GDI+ is working correctly and the weird yellow color is also a GDI+ bug, this happens in old GDI+ versions...

@marc2k3, at first I thought so too, that it is a GDI+ issue ( and I still think it is ) but I still don't understand why your berrie image does not crash in your Album art.js and is displayed blue.
But in your Thumb.js it does crash, in both test the same GDI+ version was used with a SMP panel. So what's so different between Album art.js and Thumbs.js? Though the cover.jpg with the generic gray ICC profile crashes in both Album art.js and Thumbs.js, that's why I posted this comparison in the first place.

-TT

The first serie is with the stock WINE GDI. I didn't notice the wrong window controls. The others fonts seems to work (rating starts, etc)

I made another test in my main foobar installing GDI+ verb



Same as your experience album art and thumbs crash with the cover file.

Biography seems to ignore the file

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #77
So what's so different between Album art.js and Thumbs.js?

There really should be no difference.

Either they both work or they both fail. Knowing the internals, I really don't see how one can work and the other one does not.

This snippet reads the album art first and then uses gdi.Image to load the same image from the path that is also returned.

Code: [Select]
async function get_album_art() {
    let handle = fb.GetFocusItem();
    if (handle) {
        let result = await utils.GetAlbumArtAsyncV2(window.ID, handle, 0);
        if (result.image) {
            album_art = result.image;
            image = gdi.Image(result.path);
            window.Repaint();
        }
    }
}

let album_art = null, image = null;
get_album_art();


function on_paint(gr) {
    if (album_art) {
        try {
            gr.DrawImage(album_art, 0, 0, 300, 300, 0, 0, album_art.Width, album_art.Height);
        } catch(e) {
            console.log("drawing album_art failed", e);
        }
    } else {
        console.log("album_art not valid");
    }
   
    if (image) {
        try {
            gr.DrawImage(image, 0, 300, 300, 300, 0, 0, image.Width, image.Height);
        } catch(e) {
            console.log("drawing image failed", e);
        }
    } else {
        console.log("image not valid");
    }
}

edit: just to clarify, thumbs uses gdi.Image, albumart uses utils.GetAlbumArtAsyncV2

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #78
There really should be no difference.
Either they both work or they both fail. Knowing the internals, I really don't see how one can work and the other one does not.

Yeah

With the cover picture and GDI+ verb both panels crashes. With the stock WINE GDI both works. With GDI+_winxp verb no crash but images are yellowish

And the berries picture doesn't crash in any case but is displayed blueish in stock and GDI+ or yellowish with gdi_xp.


Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #79
Look at this @mark2k3, here is proof:



I can always reload both panels and album art.js will never crash and load the image, but thumbs.js will always crash...

You can try it out for yourself @paregistrase.
You need to add two SMP, click on the first SMP and click configure, select sample > complete\album art.js
The other SMP panel select sample > complete\thumbs.js.

I've used Wine 6.0.1 with prefix32 with GDI+ ( No XP ) installed via latest Winetricks...
In Winecfg, set to Windows 7 compatibility.


-TT


Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #80
Well thumbs does resize the images for creating the thumbnail strip. I'd have thought there wouldn't be much difference between using DrawImage inside on_paint and image.Resize but I guess there is.

Since newer versions of WINE are available (v7 is stable since January), I'd try that.

edit: just testing and wine7 is pretty terrible for default UI without any other components, it's glitchy as **** !!
edit2: wine staging (7.6) is also borked in DUI too but CUI seems OK.

As for the images, they display OK without any gdiplus verb but the min/max/close buttons don't display.

But using these FontAwesome chars work in my own buttons.

minimise: '\uf2d1'
maximise: '\uf2d0'
close: '\uf2d3' 

I think aiming for built in WINE gdiplus without downloading windows 7 SP1 via winetricks is the way to go if possible.

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #81
Hi @marc2k3 =)

I wanted to ask if you can help me out to "fix" the drag n drop Wine bug on Linux?
Drag n drop does not work if you drag and drop music files from the desktop or nautilus into the playlist with
SMP's drag n drop code because:

Spoiler (click to show/hide)

TheQwertiest wrote that you can make a workaround:
Quote
I don't think I will change my implementation in Catrox, but if you want to "fix" it in your theme, you just need to remove all the filters for external drop and just set it to 1 (DROPEFFECT_COPY).

I have done that by changing the action.Effect in on_drag_over and on_drag_drop in the sample/DragnDrop.js:
Code: [Select]
action.Effect = g_drop_effect.copy; // filter_effect_by_modifiers(action.Effect);
but it's still not working...

It shows in the console the following with g_drop_effect.copy (1):
Code: [Select]
1. on_drag_enter ( on first mouse playlist drag encounter )
2. on_drag_over ( when still holding left mouse btn and dragging around )
3. on_drag_drop ( on left mouse btn release ) -> calling and executing external_drop()
It drops without doing anything :(

I'm attaching a modified console logged debug version of the basic sample/DragnDrop.js
if you want to take a look, I would appreciate your help, thanks!

Btw, drag and drop works if you try it in the standard playlist view panel...

-TT


Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #82
To test incoming drag/drop from other sources, all you need is this.

Code: [Select]
window.DefineScript('drop', { author: 'me', features: { drag_n_drop: true } });

// this is for the mouse pointer, it should change accordingly
function on_drag_over(action, x, y, mask) {
    var ap = plman.ActivePlaylist;
    if (ap == -1 || plman.IsAutoPlaylist(ap)) {
        // can't drop here
        action.Effect = 0;
    } else {
        // yes we can!
        action.Effect = 1;
    }
}

// handle the actual drop
function on_drag_drop(action, x, y, mask) {
    var ap = plman.ActivePlaylist;
    if (ap == -1 || plman.IsAutoPlaylist(ap)) {
        // can't drop here
        action.Effect = 0;
    } else {
        // yes we can!
        action.Effect = 1;
        action.Playlist = ap;
        action.Base = plman.PlaylistItemCount(ap);
    }
}

If this code does not work, SMP dnd doesn't work on WINE and there's nothing you can do about it until is updated.

Note the values of action.Effect are dependent entirely on whether or not you want to handle the incoming files. This is a simplistic example that refuses if no playlists are active or the the playlist is an autoplaylist. More complicated scenarios would involve checking the mouse position for the insertion point in a playlist or hovering over a list of multiple playlists in a manager of some kind.
   

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #83
Thanks but It did not work, it's basically the same code like the modified sample DragnDrop.js I've attached.

What is really confusing me, is that zeremy's footuner's drag n drop does work in Wine, it's using the JSPlaylist vSMP-Mod by Br3tt.
So, what is the difference between TheQwertiest dnd code and Br3tt's JSPlaylist vSMP-Mod?

Or maybe I'm wrong? Can you try out and tell me I'm incompetent?  :))

Thanks

-TT

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #84
First of all, my days of downloading ubuntu ISOs and firing up virtual machines are behind me.

But the code for JSPlaylist is here...

https://github.com/TheQwertiest/foo_spider_monkey_panel/blob/997ad85febd614d30949e85c8df2c126f58038ed/component/samples/jsplaylist-mod/js/main.js#L2821L2862

No different from the example I posted. action.Effect is set to 1 dependent on mouse position/playlist properties. It really is that simple.

edit: you did read the first sentence of my previous post...

Code: [Select]
To test incoming drag/drop from other sources, all you need is this.

If you're talking about dragging JSplaylist playlist items then that is something else entirely.

I didn't think you were because of this...

Quote
Drag n drop does not work if you drag and drop music files from the desktop or nautilus into the playlist with SMP's drag n drop code because:

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #85
Ok, I'm NOT incompetent at all, I've found what the problems is and I thought I was going crazy  :P

The problem is the SMP v1.6.2-dev+7c0928bf ( I'm using the one with the fixed clipboard you've compiled ) ,
the drag and drop code above DOES work with SMP 1.5.2!

Can you help out with this marc? Find the difference between SMP 1.5.2 and SMP 1.6.2-dev and compile a new fixed one since TheQwertiest is absent?
I would appreciate it if you can!

@TheQwertiest, take a note, thanks.

-TT

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #86
It seems TheQwertiest changed dnd behavior in SMP 1.6.0, see this here:
https://theqwertiest.github.io/foo_spider_monkey_panel/docs/changelog/#160---2021-09-11

Quote
Changed: fb.DoDragDrop() is now executed asynchronously.
Quote
Fixed (?) drag-n-drop sometimes not working (#60).

And for clarification, we are talking about external drag and drop, from desktop/nautilus to the Playlist.
The code was indeed the same as you mentioned, zeremy's footuner is just using SMP 1.5.2, that's why I found out...

-TT

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #87
Can you check 1.6.1 official works? If I build a new copy with clipboard support, it will be based on that.

No new build from me. I can't compile with the latest VS2022 I'm running. Too many errors I don't understand.

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #88
Can you check 1.6.1 official works? If I build a new copy with clipboard support, it will be based on that.

Ok I've tested it and the dnd bug starts with 1.6.0 and 1.6.1 ( Hotfix ) also doesn't work...

Edit: Well thanks for trying marc, I guess @TheQwertiest needs to fix this issue himself.

-TT


Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #90
edit: i have no idea what I'm doing.  :))  :-X

I've also no idea what I'm doing most of the time ;)

Well at least with your help I could debug this problem, so I'm grateful  :D
I hope TheQwertiest comes back soon, fingers crossed...

-TT

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #91
First thing, sorry for the "reposting" but I thing that is a good thing to have this here.
The fonts are a recurrent problem with wine. The Segoe UI in windows display all characters and languages but in wine show a lot of ugly squares.
Everybody (myself included) have tried a lot of method and hacks to make them show good but any ot them cover al use cases.
In a recent conversation with mark in MusicBrainz threah he point me to the solution.
In the first place another dirty hack comes out of my mind, but digging in I think I found a permanent solution.
I found this:
Code: [Select]
By default windows 10 always uses Segoe UI, but when a language is required that is not supported by it, Windows will fall through a prespecified fallback font stack for Segoe UI, which is stored in the Windows NT part of the registry (not the standard Windows part), at:
For Segoe UI, the font stack is:
TAHOMA.TTF,Tahoma
MEIRYO.TTC,Meiryo UI,128,96
MEIRYO.TTC,Meiryo UI
MSGOTHIC.TTC,MS UI Gothic
MSJH.TTC,Microsoft JhengHei UI,128,96
MSJH.TTC,Microsoft JhengHei UI
MSYH.TTC,Microsoft YaHei UI,128,96
MSYH.TTC,Microsoft YaHei UI
MALGUN.TTF,Malgun Gothic,128,96
MALGUN.TTF,Malgun Gothic
MINGLIU.TTC,PMingLiU
SIMSUN.TTC,SimSun
GULIM.TTC,Gulim
YUGOTHM.TTC,Yu Gothic UI,128,96
YUGOTHM.TTC,Yu Gothic UI
SEGUISYM.TTF,Segoe UI Symbol

I search in wine with regedit and this key is not present.
So I add it.
In linux we don't have this wine fonts but you can download them from internet windows 10 fonts or add to the list the Noto fonts corresponding to the language you miss.
After installing Segoe UI and Segoe UI Symbols you must add with regedit this

In HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink

New REG_MULTI_SZ with name "Segoe UI" and as value
Code: [Select]
TAHOMA.TTF,Tahoma
MEIRYO.TTC,Meiryo UI,128,96
MEIRYO.TTC,Meiryo UI
MSGOTHIC.TTC,MS UI Gothic
MSJH.TTC,Microsoft JhengHei UI,128,96
MSJH.TTC,Microsoft JhengHei UI
MSYH.TTC,Microsoft YaHei UI,128,96
MSYH.TTC,Microsoft YaHei UI
MALGUN.TTF,Malgun Gothic,128,96
MALGUN.TTF,Malgun Gothic
MINGLIU.TTC,PMingLiU
SIMSUN.TTC,SimSun
GULIM.TTC,Gulim
YUGOTHM.TTC,Yu Gothic UI,128,96
YUGOTHM.TTC,Yu Gothic UI
SEGUISYM.TTF,Segoe UI Symbol
NOTOSANS-REGULAR.TTF,Noto Sans
NOTOSANSCJK-REGULAR.TTC,Noto Sans CJK JP
NOTOSANSSYMBOLS-REGULAR.TTF,Noto Sans Symbols
You can add as much Noto Sans <language> as you can or your choice fonts.
This way you can use Segoe UI in foobar and scripts and when it need to display a characters that is not in there it will fallback to the added fonts to show it, just like Windows do.
Hope that it will help and resolve the eternal font problem.




Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #92
https://github.com/regorxxx/Playlist-Tools-SMP/wiki/Wine
Reworded it a bit and added it to the wiki, so it's placed along the installation notes of my scripts. Thanks :)

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #93
https://github.com/regorxxx/Playlist-Tools-SMP/wiki/Wine
Reworded it a bit and added it to the wiki, so it's placed along the installation notes of my scripts. Thanks :)

Clear and concise.
8)
Maybe an "after picture"....every good info commercial need one

https://imgur.com/dPqdHNT



Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #94
https://github.com/regorxxx/Playlist-Tools-SMP/wiki/Wine
Reworded it a bit and added it to the wiki, so it's placed along the installation notes of my scripts. Thanks :)
Are you open to editing?

s/sensible/sensitive/ (1 instance)
s/(me)/(to me)/ (1 instance)
s/wine/Wine/ (numerous instances)
s/windows/Windows/ (numerous instances)
s/unix/Unix/ (numerous instances)
s/foobar/Foobar/  (1 instance)
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #95
s/foobar/Foobar/  (1 instance)

Absolutely not. foobar should never be capitalised.

edit: the HA wiki might do it to article URLs but IIRC that's a limitation of the MediaWiki software used to run it. Any instance of foobar2000 written in article titles/content should be lower case.

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #96
Absolutely not. foobar should never be capitalised.

edit: the HA wiki might do it to article URLs but IIRC that's a limitation of the MediaWiki software used to run it. Any instance of foobar2000 written in article titles/content should be lower case.
Really?  OK, but I find that very odd as a style choice.  Capitalising the first letter of a word signals that it is a proper noun, and lack of capitalisation makes it much harder to parse a sentence.  Why make life hard for people, particularly non-native English readers, just to be "trendy"?  I had previously assumed instances of "foobar" were just laziness by the typist.

You could also say, then, that "foobar" should always be "foobar2000".

Meanwhile, I submit, "Foobar" is excusable because it is a proper noun and that's how proper nouns would normally be represented.
It's your privilege to disagree, but that doesn't make you right and me wrong.

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #97
Quote
Are you open to editing?
Done :) Thanks-

Will create a new independent wiki on github recompiling all these tips one of these days. (much better than only on my own)
And there anyone could edit it freely.

 

Re: Wine/Spider Monkey Panel/Script bugs on Linux

Reply #98
Absolutely not. foobar should never be capitalised.
From Type & typography* by Baines & Haslam, p.164:
Quote
A further problem today arises when companies who use lower-case only (or all caps) as part of their identity want them always to appear like that in print.  There is no reason for this: their name is different from their signature and should be set in a standard style.
The point they are making is disambiguation.  I am very much pro disambiguation.

Thus, "Foobar" is a proper noun and should be treated as such (and, without the initial capital, "foobar" is a noun meaning something disposable).  foobar2000 is the signature, with fb2k an unambiguous abbreviation.

But note I fundamentally disagree with Baines & Haslam in other matters covered in their book, particularly the use of additional white space after a full stop within a sentence.  In my opinion (and completely contrary to modern practice – AKA "French Spacing"!), having additional space is an aid to reading – and typographically a wide-space character should be used following a full stop (traditionally an em-space, U+2003), with a double space only being used for convenience (or when the em-space is not available, eg on a typewriter).  In my view French Spacing has only become adopted out of laziness!

* I have not found it referred to in the book, but I suspect the choice of capitalisation in the book's title is deliberately antagonistic and relates to the discussion on heading case... but it's a title, not a heading!
It's your privilege to disagree, but that doesn't make you right and me wrong.