Shadows does not work about libs-gui HOT 21 OPEN

No baits please

from libs-gui.

I don't want to discuss, really.

I wasn't trying to start an argument. I am working on shadows as you have seen so I just want to keep it positive.

My point when making that post was simply that gnustep doesn't always have to look like NeXTSTEP and openstep. Users have a choice.

At the moment I am looking for how this should be approached in the backend.

from libs-gui.

Yes, at the moment NSShadow is missing most of the real drawing code. If I remember correctly, it would be really hard to implement this as it requires a different drawing concept from the one we have implemented in GNUstep gui at the moment. Any patchers to improve this are welcome.

from libs-gui.

In my opinion, this is not an improvement, it is a bug. A very serious bug. I don't know who will fix it, but without a doubt, having said dozens of times for years that GNUStep is fully customizable, it is not acceptable to use 'enhacement' label to describe this bug.

from libs-gui.

In my opinion, this is not an improvement, it is a bug. A very serious bug. I don't know who will fix it, but without a doubt, having said dozens of times for years that GNUStep is fully customizable, it is not acceptable to use 'enhacement' label to describe this bug.

Very well.

from libs-gui.

In my opinion, this is not an improvement, it is a bug. A very serious bug. I don't know who will fix it, but without a doubt, having said dozens of times for years that GNUStep is fully customizable, it is not acceptable to use 'enhacement' label to describe this bug.

I moved this to a "bug" since you insisted. What leads you to the conclusion that this "bug" is as serious as you believe it to be? Some other frameworks don't have the concept of shadows.

from libs-gui.

The difference between an enhancement and a bug used to be that in the later case we are surprised by something not working as expected. whereas in the first case something was never implemented properly and we know it is missing. Adding it would be an enhancement. If we start to mix these two categories we could give them up altogether.
I think that @optimisme wanted to express that this missing functionality is a big drawback for him when implementing new themes. I understand this, but this is actually a completely different dimension when classifying issues. One that is currently not supported by GitHub.
Anyway this difference seems not so important to me, we will accept changed regardless of whether an issue is classified as bug or as enhancement. Just feel free to write this extension for at least one backend.

from libs-gui.

I do understand his point of view. I may need your help (@fredkiefer) implementing this as I am not sure how to approach the problem.

I know that macOS uses "layers". We don't and I am not sure I am willing to implement and entirely new approach to how we compose our graphics simply to support shadows.

from libs-gui.

I have added a test here

This is currently running on macOS, just to demonstrate the look we need to achieve. I used the code from the first example provided.

@optimisme, It should be possible to build this on GNUstep using buildtool/libs-xcode. The shadow won't show until it's implemented in the backend. :)

from libs-gui.

Okay, running the test on GNUstep illustrates that we also need the "setShadow:/shadow" methods to be implemented on NSView. We get a failure to load the xib because I have implemented the code from the example in -awakeFromNib which gets called during nib loading. I will create a branch on libs-gui and libs-back for these changes.

from libs-gui.

I have opened the draft PR mentioned above and linked this issue. Please see the PR for further updates.

from libs-gui.

Just as an aside, Albert... @optimisme ... this is the best way to get us to help. PLEASE KEEP SUBMITTING BUGS/ISSUES. Thank you for taking my advice.

from libs-gui.

@optimisme Also, wanted to mention... my classification of this earlier as an enhancement was not meant to imply priority. To me, a bug is something that will block a release. Unfortunately, GitHub doesn't have a way to assign severity. Theoretically, we could do it using tags, and we probably should. Just wanted you to understand that I wasn't trying to downplay the importance of supporting this functionality.

from libs-gui.

Just to clarify a few points:

• GNUstep has an implementation for layers, but this only works together with the opal drawing backend. This was implemented some years ago by Ivan and a few other GSoC students and was never fully working.

• From what I remember about NSShadow we have three modes. First to draw a shadow directly as in the first code shown above. This should be fairly easy to get implemented in the cairo backend. Then there are shadows applied to a whole window, this without a composition manager. And then there are shadows on views. Basically these require similar code as the first case but on top of that the redraw mechanism must be aware that views draw outside of their own frame and this is currently missing in GNUstep. Implementing that is doable but will require a bigger rework of our drawing concept.

I am willing to help with advice and review but won't have the time to this rework.

from libs-gui.

Absolutely understood.

from libs-gui.

I think I can integrate the shadows into the backend. What I do will support methods one and three. Shadows on Windows is a much more complex issue as this requires a compositing window manager. It's possible that could be implemented in the wayland backend when that is a bit more mature, but X doesn't support this kind of thing without "compiz" as far as I am aware.

from libs-gui.

First I am making sure that the XIB information is being read correctly when this is done via InterfaceBuilder / Xcode on the mac. Then I will look into what needs to be done when a view has a shadow in the backend during rendering.

from libs-gui.

In my opinion, this is not an improvement, it is a bug. A very serious bug. I don't know who will fix it, but without a doubt, having said dozens of times for years that GNUStep is fully customizable, it is not acceptable to use 'enhacement' label to describe this bug.

One thing I am forced to point out is that I never used those words. I have always maintained that GNUstep can be themed, never "fully customizable." :)

from libs-gui.

I don't want to discuss, really.

from libs-gui.

I am unfamiliar with the GNUstep architecture and the difficulty this bug entails, but given that there is no rush, wouldn’t it be better to put this bug on hold? To implement the layers (which seem essential if in the future CoreAnimation is also to be added). And then add shadows.

from libs-gui.

It might... but...

Strictly speaking layers are not needed to support shadows. Also layer support is backend specific as it is already implemented in the Opal backend. Opal uses our coregraphics implementation on top of Cairo. Currently it is experimental.

I'm still looking into doing it without layers at the moment, but I am going to start looking into working with the opal backend as well to see where that goes.

from libs-gui.