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

[Fred Kiefer]

Hi David,

thank you for taking the time to reply in detail and sorry for not
replying back earlier.

On 05.06.2014 10:19, David Chisnall wrote:
> 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.

The main issue here is that GNUstep GUI neven had too many users and
only a few of them take the time to report back problems. For me the
most productive phase in GNUstep GUI development was when Julian Mayer
wanted to get his simple game UI to work with GNUstep and reported every
problem he spotted.

> 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.

This sounds bad and as you already know anything inside the text system
is really hard to fix.
I could not reproduce your specific problem with Ink. It may well be
that the issue is related to the fonts you are using. Although I did get
quite a few other problems when using a GSScaleFactor of 1.5 (flickering
on each key press) and for anything above 3 the menu and the alerts get
unusable.

> 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

Yes, for huge texts the text system gets rather slow.

> 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.

Good to hear.

>> - 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.

If you happen to have one of these corrupt NIB files around, I would be
interested in having a closer look.

> 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.

Even though Grom is a very impressive application, actually my favourite
GNUstep application, I think it is better to write applications that you
want to use on different systems in XCode.

> 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.

That feature has been asked for by a lot of people, we just need
somebody to implement it :-)

> 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.

Yes, this is a short coming of Gorm, GUI already supports a lot of
bindings, although plenty are still missing. You should have developed
with XCode, used bindings there and reported the missing ones in GNUstep.

>> - 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.

As far as I understand it, nobody really likes the default look. It is
just this, the default, that we agreed on, as we could not agree on
anything else. When you write a GNUstep application and want to use it,
switch to your favourite theme.

>> - 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.

Copy and past should normally work, at least for text. I just tried and
both mouse copying and full copy&paste work in both directions between
Ink and a terminal or OpenOffice.

As for in-window menu bars, I don't like them very much, we need
somebody else to support them :-(

>> 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.

Yes, restricting yourself to a sensible subset of the language might
work. It still remains a language that totally lacks consistency.


> 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.