Le 5 févr. 2013 à 11:42, David Chisnall a écrit : > On 5 Feb 2013, at 02:25, Quentin Mathé wrote: > >> Hey David, >> >> Le 4 févr. 2013 à 13:27, David Chisnall a écrit : >> >>> Hi, >>> >>> I'm trying to get the Etoile menus stuff working, but I get a lot of >>> NSInternalConsistency exceptions and no menu appears. Does this work for >>> anyone else? >> >> >> I don't remember having such exceptions when using the menu bundle + menu >> server combination, but the horizontal menu support has been more or less >> broken for a while. By broken, I mean plagued by many bugs. The menu bundle >> code is very outdated iirc and far from being compatible with the current >> GNUstep AppKit. >> >> I started a rewrite from scratch six months ago, but I still need to finish >> it and commit it. The goal of rewrite is to have: >> - a less flexible but much simpler MenuServer implementation >> - a framework to interact with the menubar and extend it (e.g. menulet), >> this framework could also contain APIs to interact with other system-wide UI >> elements (e.g. Sidebar, Shelf etc.) >> - a better menulet infrastructure using a NSStatusItem-compatible API, and >> supporting customization at runtime >> - no menu bundle >> - the theming code can be put in the theme bundle >> - the GNUstep implementation for the horizontal menu logic can be used >> rather than patching it >> - BSD or MIT licensed code (LGPL code cannot be moved to EtoileFoundation or >> EtoileUI easily) >> >> I hope to have some time during the Spring to make progresses on this front. > > That all sounds great. My motivation for asking is that I'd like to record a > version of my FOSDEM demo to put online, and one of the comments that I got > from several people was that it would be a lot more compelling if it didn't > look so ugly. I'd like to tidy up the Nesedah theme and have nice-looking > menus.
If you feel motivated to work on the theming support, this would be awesome. Getting the theming working is a lot of work though, especially if you want to get a pixel perfect result for Nesedah that matches: http://jesseross.com/clients/gnustep/ui/concepts/23/camaelon_nesedah.png The last time I looked at it, from what I remember now, the following problems had to be solved: - GNUstep doesn't support frame rect vs layout rect distinction, so basically buttons are much smaller than what they should be when switching to Nesedah because of the shadows. The solution is to expose both layout and frame rects in Gorm and draw the shadow outside of the frame (as Apple does it in AppKit and IB). - Nesedah element border frame style tend to vary… For example, a UI element border thickness is 1px, or 2px for top/left sides + 1px for bottom/right sides. For the last combination, theme code has to be written or a new border drawing style added for GNUstep. - For two controls that use the same border style (e.g. bezel) from the viewpoint of GNUstep, Nesedah can require drawing border styles that are not the same. I'm not sure how this can be handled cleanly. Should the GNUstep border style be completely ignored in such a case? - Nesedah doesn't nest or position the UI elements as GNUstep does… For example, a scroller border is drawn on top the scroll view border and not inside. Or the scroll arrows draw their border on top of the scroller border. This means the positioning of scroll view elements has to be more flexible, and figuring out a simple yet flexible theming API for this purpose is a bit tricky. Other controls require similar improvements. For example, iirc GNUstep doesn't support to reproduce the Nesedah positioning of the UI elements in the table view header. - iirc various theme images are missing such square buttons, popup menus etc. Recently I had been thinking it could be easier to get a simpler theme working first. Something along the lines of: http://www.cappuccino-project.org/aristo/ Cheers, Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
