[bug #53061] Alert sheets do not disappear when dismissed

[Graham Lee]

Follow-up Comment #2, bug #53061 (project gnustep):

Thank you Fred, I can confirm that this fixes the problem. I don't know why
the two of us saw different behaviour, but sheets now work for me.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53060] [xlib] Significant slowness with some apps, font-related

[Yavor Doganov]

Follow-up Comment #2, bug #53060 (project gnustep):

Normally I woldn't want to touch xlib with a barge pole.  But Debian is likely
to be removing libart in the very near future so we would have to drop the art
backend.  We packaged xlib recently only because I want to have at least two
backends, it's useful for testing purposes.  I would like to package opal but
there are issues with missing libraries (lcms) and the GNUstep opal library
clashing with the VoIP opal library that is used by ekiga.  Both art and xlib
are clearly marked as deprecated in the package descriptions and the
README.Debian file.  

My first approach to this problem was to make GSXftFontInfo inherit from
FCFontInfo (and likewise, GSXftFontEnumerator from FCFontEnumerator,
overriding +faceInfoClass and +fontWithName:).  I probably made some grave
mistake(s) because I get:

can't find text container for glyph (internal error)

from NSLayoutManager.  If you want I can tidy up that patch and can attach it
for you to take a look.  It could spare you some time if my mistake is not
fundamental and there's something little yet essential that I'm missing.

By the way, fontconfig has been a hard dependency for Xft since time
immemoriam so the HAVE_FC branch in the code doesn't make sense to me.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53060] [xlib] Significant slowness with some apps, font-related

[Fred Kiefer]

Update of bug #53060 (project gnustep):

  Status:None => Confirmed  
 Assigned to:None => FredKiefer 

___

Follow-up Comment #1:

Normally I wouldn't want to support the xlib backend. We really don't want it
to be used by anybody any more. I did look into this issue just because of you
and your excellent patches and bug reports. I would be very thankful if you
wont provide a package for xlib and also for art in the future. Or at least
mark them as unsupported.

The problem here is that the applications you listed use special characters to
depict key equivalents in their menus. These characters aren't present in the
standard font that the xlib backend is using when trying to display this
string. So the NSAttributedString class tries to find a replacement font for
each of these characters. I tried this myself with the xlib backend and for
PikoPixel this fails for most of the special characters. IN that process the
code has to try every font available for this backend. For the cairo backend
with FT fonts this is a rather fast process. For xlib this takes almost for
ever.
The trick we use for cairo (and opal) is to leave this hard task to
fontconfig.
With your changes it will be a bit faster and more reliable but this wont
resolve the general problem. The only thing that is supportable and could
resolve this issues that I see is to reuse the fontconfig/FCFontEnumerator
class for GSXFT. This is actually not that hard to do, FCFontEnumerator was
extracted from GSXFT.

I am still a bit tiered from FOSDEM and the journey back. So please be
patient, I hope to come up with something usable in the next few days.



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53061] Alert sheets do not disappear when dismissed

[Fred Kiefer]

Update of bug #53061 (project gnustep):

  Status:None => Ready For Test 
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

I could not directly reproduce the issue with your code. When clicking on a
button in the sheet the sheet first got moved to the left lower corner, just
as you described but for me it was immediately removed from the screen after
that.

What I did is to move the call that closes the sheet before the code that code
that disconnects it from its parent window. Form me now the sheet disappears
at once. I hope that this also resolves your issue. Please report back on
this.

Fred

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #53061] Alert sheets do not disappear when dismissed

[Graham Lee]

URL:
  

 Summary: Alert sheets do not disappear when dismissed
 Project: GNUstep
Submitted by: leeg
Submitted on: Sun 04 Feb 2018 03:52:58 PM UTC
Category: Gui/AppKit
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

Here is a minimal reproducer project: https://github.com/iamleeg/sheet-bug

The app delegate begins an alert sheet on the main window, and handles the
dismiss message. However, when the alert sheet is dismissed, it doesn't
disappear; rather it is drawn in the bottom-left corner of the screen.

I'm using gnustep libs-gui from master on github on Fedora Core 27.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnustep