Existing Papercuts

[terminills]

There's a list of 40+ existing papercut bugs that need to be verified if they still exist.

As far as I know they should be verified on ABIv1 due to the fact that it has the newest codebase.

https://sourceforge.net/p/aros/papercuts/115/

Any help would be appreciated.  Please link to any bug you test so it can be confirmed or closed accordingly.

[G-linx]

As far as I know they should be verified on ABIv1 due to the fact that it has the newest codebase.

Hopefully not a can of worms, but perhaps a question for deadwood/kalamatee/et al to comment on (or is it simply abiv0 32bit & abiv1 64bit?)

Myself, either is good for me

[terminills]

As far as I know they should be verified on ABIv1 due to the fact that it has the newest codebase.

Hopefully not a can of worms, but perhaps a question for deadwood/kalamatee/et al to comment on (or is it simply abiv0 32bit & abiv1 64bit?)

Myself, either is good for me

I know what kalamatee would say.  I am not so sure about Deadwood.   The assumption is to go against the latest codebase so that the work isn't being done twice.

However it can be tested against both so you know if it's been fixed yet in Deadwoods backport.

[deadwood]

Hopefully not a can of worms, but perhaps a question for deadwood/kalamatee/et al to comment on (or is it simply abiv0 32bit & abiv1 64bit?)

Myself, either is good for me

I'd say verify on whatever works for you best BUT always put a clear description on what you verified against best with linking to binaries. Some issues can happen on 64-bit that won't happen on 32-bit. Some issues will happen on m68k that will not happen on x86. Always be super-clear where exactly you tested this on.

[magorium]

Any help would be appreciated.  Please link to any bug you test so it can be confirmed or closed accordingly.

For this one, i need no test 

What is it with people requesting 3-th party features to be incorporated into AROS ?

Even stronger, a feature of a "package" that uses exactly one protection scheme for its work namely the 'locking' of the colors for which you had to install/use a special daemon on classic OS (well there is something else but i'm not going to inform the ignorant).

It is by design that the Amiga does not provide these colors, simply because it depends on your chosen resolution/bitmap depth.

So imo this request should not even have been part of the papercuts to begin with.

Secondly, to make the point stronger, it requires a fix with regards to intuition pens, and as stated earlier by deadwood, this requires some work and requires at least a newer backport for ABIv0.

But even then, who is the user who requested this feature and wanting to mess up /my/ icon-color-scheme that i've painstakingly put together ?

And then the bargaining begins ... "we can make it optional" ... "by using a special crafted preference program" .. "or by using a special commandline tool" ... "perhaps we can make a special magic WB distribution around it"

Been there, and done that. It is already possible today (and yesterday and over a decade ago) for AROS to have exactly the same looks as MWB does. If you don't know how then it will indeed be Magic... just as the name implies 

sorry for the rant

[terminills]

Any help would be appreciated.  Please link to any bug you test so it can be confirmed or closed accordingly.

For this one, i need no test 

What is it with people requesting 3-th party features to be incorporated into AROS ?

Even stronger, a feature of a "package" that uses exactly one protection scheme for its work namely the 'locking' of the colors for which you had to install/use a special daemon on classic OS (well there is something else but i'm not going to inform the ignorant).

It is by design that the Amiga does not provide these colors, simply because it depends on your chosen resolution/bitmap depth.

So imo this request should not even have been part of the papercuts to begin with.

Secondly, to make the point stronger, it requires a fix with regards to intuition pens, and as stated earlier by deadwood, this requires some work and requires at least a newer backport for ABIv0.

But even then, who is the user who requested this feature and wanting to mess up /my/ icon-color-scheme that i've painstakingly put together ?

And then the bargaining begins ... "we can make it optional" ... "by using a special crafted preference program" .. "or by using a special commandline tool" ... "perhaps we can make a special magic WB distribution around it"

Been there, and done that. It is already possible today (and yesterday and over a decade ago) for AROS to have exactly the same looks as MWB does. If you don't know how then it will indeed be Magic... just as the name implies 

sorry for the rant

I would worry less about if it requires a backport to abiv0 as if it makes sense that's deadwoods project and he can decide if he wants to backport it.    I would worry more about if it's fixed or handled on the latest codebase.   I'm doing my best not to speak for Deadwood as his project is his however as for AROS as a whole is it a feature request or a bug?   Well I guess that depends on if we started implementing MWB support yet.

[magorium]

I would worry less about if it requires a backport to abiv0 as if it makes sense that's deadwoods project and he can decide if he wants to backport it.

He already explained that we need to wait until a specific backport date. It is in the forums somewhere (sorry i can't be arsed to dig it up atm  ).

I would worry more about if it's fixed or handled on the latest codebase.

For locking colors, it is not (for ABIv0 at least).

I'm doing my best not to speak for Deadwood as his project is his however as for AROS as a whole is it a feature request or a bug?

I am assuming you are talking about the papercut itself here, and in that case that was why I posted my rant: It is a utter bullshit request made by someone who has no clue as of how icons work on (classic) Amiga and thus AROS.

Well I guess that depends on if we started implementing MWB support yet.

There is nothing to implement. It is already possible to do (and as i wrote for over a decade ago). The only 'feature' that currently does not work is 'locking' the pens so that other applications are not able to meddle with these settings. As long as other software behaves it works ootb. And the locking itself can be done with a 3-th party tool (as done on classic) so also does not have to be part of AROS.

papercut can thus be closed.

A how to do is listed on the old aros-exec forums, written by yours truly.

[terminills]

I would worry less about if it requires a backport to abiv0 as if it makes sense that's deadwoods project and he can decide if he wants to backport it.

He already explained that we need to wait until a specific backport date. It is in the forums somewhere (sorry i can't be arsed to dig it up atm  ).

I would worry more about if it's fixed or handled on the latest codebase.

For locking colors, it is not (for ABIv0 at least).

I'm doing my best not to speak for Deadwood as his project is his however as for AROS as a whole is it a feature request or a bug?

I am assuming you are talking about the papercut itself here, and in that case that was why I posted my rant: It is a utter bullshit request made by someone who has no clue as of how icons work on (classic) Amiga and thus AROS.

Well I guess that depends on if we started implementing MWB support yet.

There is nothing to implement. It is already possible to do (and as i wrote for over a decade ago). The only 'feature' that currently does not work is 'locking' the pens so that other applications are not able to meddle with these settings. As long as other software behaves it works ootb. And the locking itself can be done with a 3-th party tool (as done on classic) so also does not have to be part of AROS.

papercut can thus be closed.

A how to do is listed on the old aros-exec forums, written by yours truly.

Then it's a feature request is all.   Someone wanted it it's not a bug it's a feature request that they'd probably like a utility like visualprefs to handle.  I won't judge what people want for features.   I could mention a ton I want that no one cares about and vice versa.

[magorium]

Then it's a feature request is all.

It is indeed a feature request.

Do mind though, a feature request to do the user's (and only that users') bidding of locking the first colors to match those of magic WB. Thus trashing other people's hand-crafted icons.

Someone wanted it it's not a bug it's a feature request that they'd probably like a utility like visualprefs to handle.

Now you are making up things  that are not part of the linked papercut (bargaining)

I won't judge what people want for features.   I could mention a ton I want that no one cares about and vice versa.

It is not that i do not care about it. It is the opposite. I care because it is a feature request of something that is already possible to accomplish on AROS (and to correct myself, for more than over 2 decades it was already possible to accomplish).

The only missing part is the locking and (something that disturbs me) is that you already start to bargain (on behalf of the user) to include the locking of magic WB colors into AROS by incorporating it into some kind of tool for the user to access these settings (so that it can be turned on/off or be configured otherwise). Again the only part missing (because it requires some internal system changes in current code-base from deadwood) is the actual locking. There is nothing wrong with f.e. using a custom tool that sets the colors (again something from yours truly. But also missing the locking part because it is not possible to accomplish atm).

But hey, if you (read, the user who requested it as i am assuming you are currently defending his/her papercut) keep insisting it is a feature request then so be it: A request of feature that is already present 

[terminills]

Then it's a feature request is all.

It is indeed a feature request.

Do mind though, a feature request to do the user's (and only that users') bidding of locking the first colors to match those of magic WB. Thus trashing other people's hand-crafted icons.

Someone wanted it it's not a bug it's a feature request that they'd probably like a utility like visualprefs to handle.

Now you are making up things  that are not part of the linked papercut (bargaining)

I won't judge what people want for features.   I could mention a ton I want that no one cares about and vice versa.

It is not that i do not care about it. It is the opposite. I care because it is a feature request of something that is already possible to accomplish on AROS (and to correct myself, for more than over 2 decades it was already possible to accomplish).

The only missing part is the locking and (something that disturbs me) is that you already start to bargain (on behalf of the user) to include the locking of magic WB colors into AROS by incorporating it into some kind of tool for the user to access these settings (so that it can be turned on/off or be configured otherwise). Again the only part missing (because it requires some internal system changes in current code-base from deadwood) is the actual locking. There is nothing wrong with f.e. using a custom tool that sets the colors (again something from yours truly. But also missing the locking part because it is not possible to accomplish atm).

But hey, if you (read, the user who requested it as i am assuming you are currently defending his/her papercut) keep insisting it is a feature request then so be it: A request of feature that is already present 

As you said the missing part would be the locking hence that would be the feature request.   And YOU keep referring to deadwood's branch back-port or whatever you want to call it.  I'm referring to AROS as a whole I do not think it's a good idea to base papercuts on deadwood's current code-base alone as he's still years behind the current TRUNK.   Eventually he will catch up and there will be potentially 2 fixes for the same problem.    Now I'm not saying don't use deadwoods work I'm saying all bug reports based on it should be verified against TRUNK to see if they still exist.

[magorium]

As you said the missing part would be the locking hence that would be the feature request.

Wholly.... you keep making up things. Mind you that it is very difficult to have a conversation that way 

The user _thinks_ it has to do with locking (? maybe ?). I can tell you it has nothing to do with locking. The user who reported does not have a clue whatsoever (trust me on that one)

And YOU keep referring to deadwood's branch back-port or whatever you want to call it.

Yes, as that is the only version of AROS that currently does not have this locking feature. so in that case why otherwise bother ?

I'm referring to AROS as a whole I do not think it's a good idea to base papercuts on deadwood's current code-base alone

Now you truly lost me there.

1) The papercut clearly mentions icaros desktop, which was ABIv0, is ABIv0 and will always be ABIv0.... well, perhaps maybe V11 in the future (you have to ask paolo). so that obligates me/us to compare against that.
2) the current AROS trunk already supports the locking, so in that case there isn't an issue/feature (let alone a request) to begin with.

as he's still years behind the current TRUNK.

2019 and the fix is in 2020. indeed _years_ away 

Eventually he will catch up and there will be potentially 2 fixes for the same problem.    Now I'm not saying don't use deadwoods work I'm saying all bug reports based on it should be verified against TRUNK to see if they still exist.

Trunk from AROS dev team you mean ? Which platform should i choose from ?
Let me try native raspi. oh sorry does not compute for me
hosted arm ? does not compute for me
Maybe i386 ? sorry does not compute for me
Native x86_64 ? also does not compute for me
I do not have a MAC to test on, but assume it is similar in nature.
Not installing windows (into a vm) only for testing purposes for AROS. I do not use it anymore, so not going to start again 
Aaah, good heavens, i am able to run x86_64 hosted on a linux machine... let's check/test with some software found on icaros desktop ...... ow wait... 

Thus, although your idea of papercuts is a good one (i really loved that idea back then (and still do) and worked hard to support it) i rather wait 'years' for these backports to come over to deadwood's branch. Because only being able to test on a 64-bit hosted version of AROS for papercuts that originally where (mostly) based on Icaros Desktop behaviour is imho not going to work.

But i'll be darned... i posted because i was thinking to make things easier for you to at least be able to remove one papercut from the list (because it is nonsense). Your replies only makes me believe even stronger in that this particular papercut it is a non-issue.

The papercut:

MWB-style icons are displayed with wrong colors. Maybe because the first 8 or 16 pens are not locked?

These icons are still important because of networking with other amiga-like machines and displaying their icons on wanderer! And i'm still using them for nearly all drawer-icons.

MWB-style icons are displayed with wrong colors.

Yups, that is because it is named Magic WB for a reason in that it uses a Magic color scheme.

Maybe because the first 8 or 16 pens are not locked?

Indeed they are not locked. But then they are not set at all. Just as on your classic machine you needed to install MWB in order to invoke some protection measure on your startup-sequence in order to 'create' (set) the correct colorscheme.

These colors (pens) are then locked so that other programs can not overwrite the used colorscheme.

These icons are still important because of networking with other amiga-like machines and displaying their icons on wanderer! And i'm still using them for nearly all drawer-icons.

Greate ! It is always nice to see someone being so supportive of Martin's work and care so much about it.

If you indeed familiar with his workthen you probablyalso know which colors and pens are used for displaying MWB icons correctly.

I suggest you set the correct pens and colors when using AROS to accomplish the same graphical view for these icons.

Sorry, as it is currently not possible to 'lock' the pencolors atm because some internals of AROS are currently not able to do so thus other programs running on the same (public) screen are able to mess up the colorscheme that you've set up. Advise is to avoid the use of such programs (or run those on another (public) screen until support for locking is added into AROS.

Please keep in mind that even when the locking bits inside AROS do work as intended that there is no permanent solution for your use case as other people like to use their own colorschemes for their icons and we can't please everyone so setting this colorscheme into stone inside AROS is not a solution for/to your request.

Or as suggested by terminills:use AROS trunk and your request to be able to lock pencolors already has been fulfilled.

[terminills]

As you said the missing part would be the locking hence that would be the feature request.

Wholly.... you keep making up things. Mind you that it is very difficult to have a conversation that way 

The user _thinks_ it has to do with locking (? maybe ?). I can tell you it has nothing to do with locking. The user who reported does not have a clue whatsoever (trust me on that one)

And YOU keep referring to deadwood's branch back-port or whatever you want to call it.

Yes, as that is the only version of AROS that currently does not have this locking feature. so in that case why otherwise bother ?

I'm referring to AROS as a whole I do not think it's a good idea to base papercuts on deadwood's current code-base alone

Now you truly lost me there.

1) The papercut clearly mentions icaros desktop, which was ABIv0, is ABIv0 and will always be ABIv0.... well, perhaps maybe V11 in the future (you have to ask paolo). so that obligates me/us to compare against that.
2) the current AROS trunk already supports the locking, so in that case there isn't an issue/feature (let alone a request) to begin with.

as he's still years behind the current TRUNK.

2019 and the fix is in 2020. indeed _years_ away 

Eventually he will catch up and there will be potentially 2 fixes for the same problem.    Now I'm not saying don't use deadwoods work I'm saying all bug reports based on it should be verified against TRUNK to see if they still exist.

Trunk from AROS dev team you mean ? Which platform should i choose from ?
Let me try native raspi. oh sorry does not compute for me
hosted arm ? does not compute for me
Maybe i386 ? sorry does not compute for me
Native x86_64 ? also does not compute for me
I do not have a MAC to test on, but assume it is similar in nature.
Not installing windows (into a vm) only for testing purposes for AROS. I do not use it anymore, so not going to start again 
Aaah, good heavens, i am able to run x86_64 hosted on a linux machine... let's check/test with some software found on icaros desktop ...... ow wait... 

Thus, although your idea of papercuts is a good one (i really loved that idea back then (and still do) and worked hard to support it) i rather wait 'years' for these backports to come over to deadwood's branch. Because only being able to test on a 64-bit hosted version of AROS for papercuts that originally where (mostly) based on Icaros Desktop behaviour is imho not going to work.

But i'll be darned... i posted because i was thinking to make things easier for you to at least be able to remove one papercut from the list (because it is nonsense). Your replies only makes me believe even stronger in that this particular papercut it is a non-issue.

The papercut:

MWB-style icons are displayed with wrong colors. Maybe because the first 8 or 16 pens are not locked?

These icons are still important because of networking with other amiga-like machines and displaying their icons on wanderer! And i'm still using them for nearly all drawer-icons.

MWB-style icons are displayed with wrong colors.

Yups, that is because it is named Magic WB for a reason in that it uses a Magic color scheme.

Maybe because the first 8 or 16 pens are not locked?

Indeed they are not locked. But then they are not set at all. Just as on your classic machine you needed to install MWB in order to invoke some protection measure on your startup-sequence in order to 'create' (set) the correct colorscheme.

These colors (pens) are then locked so that other programs can not overwrite the used colorscheme.

These icons are still important because of networking with other amiga-like machines and displaying their icons on wanderer! And i'm still using them for nearly all drawer-icons.

Greate ! It is always nice to see someone being so supportive of Martin's work and care so much about it.

If you indeed familiar with his workthen you probablyalso know which colors and pens are used for displaying MWB icons correctly.

I suggest you set the correct pens and colors when using AROS to accomplish the same graphical view for these icons.

Sorry, as it is currently not possible to 'lock' the pencolors atm because some internals of AROS are currently not able to do so thus other programs running on the same (public) screen are able to mess up the colorscheme that you've set up. Advise is to avoid the use of such programs (or run those on another (public) screen until support for locking is added into AROS.

Please keep in mind that even when the locking bits inside AROS do work as intended that there is no permanent solution for your use case as other people like to use their own colorschemes for their icons and we can't please everyone so setting this colorscheme into stone inside AROS is not a solution for/to your request.

Or as suggested by terminills:use AROS trunk and your request to be able to lock pencolors already has been fulfilled.

The fix is in 2020, TRUNK is in 2022, Deadwood is at 2019.  His codebase is 3 years behind TRUNK I'm not saying it will take him years I'm saying there's years worth of fixes from where he's at till the current codebase.

We could simply mark it as closed and point to that it's been fixed in TRUNK so that no one has to do the work again?   

As for the papercut mentioning Icaros, if you look at those papercuts they are from a decade ago.     Hence why they need to be verified as being fixed at some point or not.  There was no need for a big long rant when instead you could have simply stated it was fixed in ABIv1 at some point.  That could have been verified.    My goal is to find bugs and to keep developers from doing double and potentially incompatible work.

[magorium]

Or simply mark it as closed and point to that it's been fixed in TRUNK so that no one has to do the work again?

Yes, indeed. You could have concluded that from my first post (...newer backport...)

If you look at those papercuts they are from a decade ago.     Hence why they need to be verified as being fixed at some point or not.

Yes, but ...

There was no need for a big long rant when instead you could have simply stated it was fixed in ABIv1 at some point.

See my first reply and stated earlier in this reply: you could have concluded that yourself.

Perhaps it was better if i literally stated that from the beginning (seems we are both hardheaded t'day  ) .... sorry, but another but coming up...

.. but also when this fix is not present then the wish expressed in the papercut was already possible to accomplish simply becuase the right pens and colors are not set by default so you have to do that yourself f.e. with using my setpencolor tool (or from cavemann, or from...)

That could have been verified.

It could, but even though you see my replies as a rant... the problem as mentioned on what works for me is a real issue (also for others) and thus also for the papercuts.

If you do not wish to take this into consideration then i can tell you beforehand that any attempt to a new round of papercuts is doomed from the start.

My goal is to find bugs and to keep developers from doing double and potentially incompatible work.

Agreed, so potentionally (guestimating there, so please feel free to correct) that rules out any of deadwoods current available distro's because they are based on backports (besides his own improvements/enhancements/fixes that are (sometimes) backported back to AROS trunk.

You can't expect end-users or potential (dev) newcomers to know all this and hope for the best when a papercut is reported. E.g. it would mean a lot of verifying needs to be done (based on what distro the issue was experienced) in order to make sure it is not already fixed in another distro/platform (assuming worse case scenario)

[terminills]

Or simply mark it as closed and point to that it's been fixed in TRUNK so that no one has to do the work again?

Yes, indeed. You could have concluded that from my first post (...newer backport...)

If you look at those papercuts they are from a decade ago.     Hence why they need to be verified as being fixed at some point or not.

Yes, but ...

There was no need for a big long rant when instead you could have simply stated it was fixed in ABIv1 at some point.

See my first reply and stated earlier in this reply: you could have concluded that yourself.

Perhaps it was better if i literally stated that from the beginning (seems we are both hardheaded t'day  ) .... sorry, but another but coming up...

.. but also when this fix is not present then the wish expressed in the papercut was already possible to accomplish simply becuase the right pens and colors are not set by default so you have to do that yourself f.e. with using my setpencolor tool (or from cavemann, or from...)

That could have been verified.

It could, but even though you see my replies as a rant... the problem as mentioned on what works for me is a real issue (also for others) and thus also for the papercuts.

If you do not wish to take this into consideration then i can tell you beforehand that any attempt to a new round of papercuts is doomed from the start.

My goal is to find bugs and to keep developers from doing double and potentially incompatible work.

Agreed, so potentionally (guestimating there, so please feel free to correct) that rules out any of deadwoods current available distro's because they are based on backports (besides his own improvements/enhancements/fixes that are (sometimes) backported back to AROS trunk.

You can't expect end-users or potential (dev) newcomers to know all this and hope for the best when a papercut is reported. E.g. it would mean a lot of verifying needs to be done (based on what distro the issue was experienced) in order to make sure it is not already fixed in another distro/platform (assuming worse case scenario)

I will be happy to verify the ones that are still present in Deadwoods backport.   However if some users could test a bug they find in the latest Icaros against a current nightly that would be greatly appreciated.    The more bugs we find the sooner we can start rewarding bug fixes.

[AMIGASYSTEM]

terminills, the bugs you find in the Distribuzini, you find them in the nights as well, they are the same, I have reported many of them to Deadwoods and continue to do so.

If instead of chatting if he used that time to test the software many more bugs would be found.