Re: GNUstep GUI [Was: Is a move to github in order??]

[David Chisnall]

On 4 Jun 2014, at 21:04, Fred Kiefer <fredkiefer@gmx.de> wrote:

> - Missing or incorrect features in GNUstep GUI?

I hit the bug in NSTextFieldCell that you've since fixed.  That was really 
surprising to me, because it was triggered by nothing more complex than putting 
an editable text field in a table view.  If things that simple don't work, then 
it's really hard to have confidence in the rest of the system.

I also hit several issues with the text system.  When using a scaling factor, 
all of the views are nicely enlarged (great for demos on a projector!), but the 
spacing in between characters goes a bit random.  It looks like there are 
spaces in the middle of words sometimes.

The text system is also really slow.  My application is a 3-pane view.  The 
right pane contains a table view containing the register set at a specific 
point in a trace.  The top-left pane contains a table view containing the trace 
(cycle number, pc address, decoded instruction, notes).  The bottom-left pane 
contains the disassembly of the object corresponding to the pc.

I initially tried using an NSTextView to show the disassembly.  I can take the 
object code, disassemble it, and construct an NSAttributedString in a tiny 
fraction of a second, but scrolling to a specific line number in an NSTextView 
took 1-2 seconds when it contained a large amount of text.  This meant that it 
wasn't fast enough for interactive use.  I had to replace it with an 
NSTableView that 

On the plus side, the table view is pretty responsive.  I've tested the 
application with 2GB streamtraces in a FreeBSD VM and it works okay.

> - Missing support for existing features in Gorm?

I initially wrote it on GNUstep and then ported to OS X.  Last time I did this 
with an application, GORM could export a nib file that IB could read.  Now, 
XCode reports nib files created with GORM as corrupt (if you're lucky - 
sometimes it just crashes trying to read them).  This meant that I had to 
redraw the entire UI in XCode.

On OS X, they've moved to a constraint solver for view positioning.  I found 
the XCode UI for this spectacularly confusing, so didn't mind turning it off 
and going back to the only slightly confusing mechanism from the NeXT days.  
This meant that, to have a UI that worked on both OS X and GNUstep, I ended up 
using the .xib that XCode produced.

GORM can't handle editing a table view that's in a split view in another split 
view.  Sometimes it doesn't like editing the table view that's in a single 
split view.  This meant that every modification I made to the UI involved 
ungrouping everything and then regrouping it again.  XCode / IB have long had 
an outline view of all of the selectable things, and this is much easier to 
work with than trying to click on them and have the interface builder work out 
which of the 6 views under the mouse cursor you mean.  This was a feature I 
remember asking for in GORM in 2007, the first time I encountered this 
limitation.

I wrote a lot of code in this application that Bindings would have made 
redundant.  I don't know how well they're supported in -gui, but they're not 
exposed in GORM at all.

> - Ugly look of the result?

That too.  People's first reaction was 'did you write this in tk?'  I 
eventually started using the Nesedah theme, which has a few rough edges, for 
demos and then people started commenting on the functionality rather than the 
look, but the default look is ugly and dated and we don't have a single theme 
that looks modern and polished.

> - Missing integration with your desktop or other applications?

Copy and paste didn't seem to work for other people, but that was a relatively 
minor thing.  Not being able to easily package it defaulting to using the DE's 
theme-of-choice and in-window menu bars is annoying though.  There are still 
some glitches with in-window menu bars.  

> I really would like to learn from you experience and see whether it is
> worth fixing it. I definitely wont switch over you Qt, you already know
> my position on C++.


With C++11, there is now a subset of the language that is not terrible.  It's 
not as nice to use as Objective-C, but it's no longer an exercise in masochism. 

I tend to use Objective-C++ quite a bit now anyway, as the C++11 standard 
library containers work well with Objective-C objects in ARC mode and provide a 
lot more control than the Objective-C equivalents.  

David

-- Sent from my Apple II