Re: Next GNUstep release

[Josh Freeman]

Thank you, Ivan, and everyone who contributed to the new versions!  
Congratulations!


Cheers,

Josh


On Apr 13, 2020, at 8:13 PM, Ivan Vucica wrote:


And releases are now done!

Re: Next GNUstep release

[Ivan Vucica]

On Sun, Apr 12, 2020 at 12:19:53PM -0400, Gregory Casamento wrote:
> What is the status of the current release?   I hope this ChangeLog
> discussion is not holding things up.

And releases are now done!

Re: Next GNUstep release

[Ivan Vučica]

Honestly — it's merely not top of my priority list. I consider it unblocked
and will finish the release "soon".

sent from phone

On Sun, Apr 12, 2020, 17:20 Gregory Casamento 
wrote:

> What is the status of the current release?   I hope this ChangeLog
> discussion is not holding things up.
>
> On Sat, Apr 11, 2020 at 11:58 AM Ivan Vučica  wrote:
>
>> On Thu, Apr 9, 2020 at 9:11 AM Riccardo Mottola
>>  wrote:
>> >
>> > Hi,
>> >
>> > > Should we enforce each commit to be larger before publishing? Should
>> > > we enforce commit chains to end up in a merge commit which is
>> > > detailed? Should we enforce updating changelog-equivalent only when a
>> > > particular feature is finished and ready to be added -- but *enforce
>> > > it consistently*?
>> >
>> > No please not minimum length...
>>
>> To clarify, I mean a human raising a fuss and saying "this can't be
>> merged like this, fix the changelog/miniblog/whatever".
>>
>>
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> https://www.patreon.com/bePatron?u=352392 - Become a Patron
>

Re: Next GNUstep release

[Gregory Casamento]

What is the status of the current release?   I hope this ChangeLog
discussion is not holding things up.

On Sat, Apr 11, 2020 at 11:58 AM Ivan Vučica  wrote:

> On Thu, Apr 9, 2020 at 9:11 AM Riccardo Mottola
>  wrote:
> >
> > Hi,
> >
> > > Should we enforce each commit to be larger before publishing? Should
> > > we enforce commit chains to end up in a merge commit which is
> > > detailed? Should we enforce updating changelog-equivalent only when a
> > > particular feature is finished and ready to be added -- but *enforce
> > > it consistently*?
> >
> > No please not minimum length...
>
> To clarify, I mean a human raising a fuss and saying "this can't be
> merged like this, fix the changelog/miniblog/whatever".
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron

Re: Next GNUstep release

[Ivan Vučica]

On Thu, Apr 9, 2020 at 9:11 AM Riccardo Mottola
 wrote:
>
> Hi,
>
> > Should we enforce each commit to be larger before publishing? Should
> > we enforce commit chains to end up in a merge commit which is
> > detailed? Should we enforce updating changelog-equivalent only when a
> > particular feature is finished and ready to be added -- but *enforce
> > it consistently*?
>
> No please not minimum length...

To clarify, I mean a human raising a fuss and saying "this can't be
merged like this, fix the changelog/miniblog/whatever".

Re: Next GNUstep release

[Riccardo Mottola]

Hi,

Ivan Vučica wrote:
> Please also see the other thread for my thoughts so I don't repeat
> them in detail, but just this:
>
> On Mon, Apr 6, 2020 at 2:46 PM David Chisnall  
> wrote:
>>  Compare these two pages:
>>
>> The ChangeLog file:
>> https://github.com/gnustep/libs-base/blob/master/ChangeLog
>>
>> The Git history:
>> https://github.com/gnustep/libs-base/commits/master
>>
>> The second is easier to skim, easier to jump to exact changes, and
>> easier to use to isolate change in a particular area (only care about
>> changes in the tools?  Look here:
>> https://github.com/gnustep/libs-base/commits/master/Tools instead of the
>> main history page).

I completely agree that the ChangeLog is much easier to skim than the
git history! Even if the one of github is nicely formatted.
I wrote separately about the usefullness of grouping files, comments and
possibly methods together.

> Should we enforce each commit to be larger before publishing? Should
> we enforce commit chains to end up in a merge commit which is
> detailed? Should we enforce updating changelog-equivalent only when a
> particular feature is finished and ready to be added -- but *enforce
> it consistently*?

No please not minimum length...

> Again, I don't want to have to have to distinguish between "this is
> adding a new class", "this is fixing a security bug", "this is
> *partially* addressing a security bug", "this is a quick compile fix",
> "this is a large overhaul of the build system" by having to inspect
> each commit in a really long chain of commits. Not necessarily a tree,
> even.
>
> FWIW ChangeLog entries *when written* were more useful for this
> purpose. The problem was *when they weren't written*.

Mostly because they were a little more thought off.

Of course if you just write "fix implementation" and skim a log, you
don't know what.

Suppose the scenario where you implement feature X and by this solve a
bug B1.

1. clean-up some code
2. implement a new method
3. use the new method
4. clean up some other methods and fix bug.
5. add some boilerplate, comments
6. add a test case

I would have made 6 different commits, with 6 messages. But for a
ChangeLog perhaps just 2 commits are useful. One for the new
implementation, citing the file, the method and reference to feature X.
Then a commit with the usage and bug fix for reference fo B1.
Adding a test case, a fix is "not that useful" in the ChangeLog.


This is, of course, theoretical world.

> Git commits as written today are unsustainable.

And about in most projects (FOSS or not) I see.
Perhaps a good average is in mozilla, with longer messages, bug
reference, etc. However, there, the commits are essentially just
merge-in of patches.
So there is a very strict reference bug-bug-number-commit and the commit
are comprehensive, if done in steps numbered (like my case above would
have bug B1 and then commit 1/6, 2/6 etc etc)
We are not so disciplined and it is a bit the opposite of how he always
worked.


> But maintainers, please just decide something and proclaim that this
> is what will be done. It doesn't have to be consistent among packages,
> but *within* a particular release of an individual package, I'd like
> to see consistency. We can't have some people "opt-out" of the chosen
> process. Maintainers need to be the ones to enforce this, including
> possibly writing the log entries ('blogposts'?) themselves.
>

we need to agree on some sort of common line.
Of course, everybody wants to type and update the least possible during
hacking, but then different developers have different tastes and needs
when looking up the changes during bug hunting or releaseing.

Riccardo

Re: Next GNUstep release

[Riccardo Mottola]

Hi!

Richard Frith-Macdonald wrote:
> What I'd like to suggest is sort-of (but not entirely) scrapping ChangeLog, 
> in that we could auto-generate ChangeLog entries from the repository, either 
> by an automated commit hook or (assuming that's not easy to do readily), 
> using a script to get details from the repository just before we make a 
> realease, so that anyone getting a release of the software still gets a 
> comprehensive ChangeLog.
>
> Then we would be saved the overhead of writing ChangeLog entries and could 
> concentrate on:
> 1. meaningful commit entries, which of course we should all be doing anyway 
> ;-)
> 2. writing release notes for any substantive change (rather than ChangeLog 
> entries for even minor changes), to appear in the NEWS when we make a release
>
> If we stop writing ChangeLog entries, we should be able to write release 
> notes and still be spending less time, and of course that would make the 
> process of cutting a release less onerous.

It sounds reasonable. I'd like to see what this ChangeLog could look like.

I still "love" our ChangeLog and miss it in projects where it does not
exist.

It contains two important informations grouped together:

The conext of a Commit plus files, descriptions and if the author is
nice, even the Method.

e.g.

1970-01-01 John Doe
    * NSApplication.h
    * NSApplication.m (runLoop:)
    HookUp  runLoop to some Event.

is a context not found in other tools.
To inspect the "files", in GIT or SVN I end up essentially going on the
web interface and finding it.
But to know which file was modified, with git I use the "blame" or again
skip through the web interface.

The extra information about the method is lost in any case.

Here, instead, I just use grep or view on the ChangeLog, find what I
need on the console in matter of secons once I have found meaning
ful commits, then I still can open the web interface, in spect it, etc.

So a mere log of commit messages is totally useless, since "git log" or
"svn log" provide that (and often the comments are not that meaningful).

Maybe we can find a compromise here.


Riccardo

Re: Next GNUstep release

[Ivan Vučica]

Please also see the other thread for my thoughts so I don't repeat
them in detail, but just this:

On Mon, Apr 6, 2020 at 2:46 PM David Chisnall  wrote:
>  Compare these two pages:
>
> The ChangeLog file:
> https://github.com/gnustep/libs-base/blob/master/ChangeLog
>
> The Git history:
> https://github.com/gnustep/libs-base/commits/master
>
> The second is easier to skim, easier to jump to exact changes, and
> easier to use to isolate change in a particular area (only care about
> changes in the tools?  Look here:
> https://github.com/gnustep/libs-base/commits/master/Tools instead of the
> main history page).

If you carefully look into individual messages over the span of a year
with limited time to examine each change -- you are likely going to
share my experience of finding individual commits are very
non-detailed.

Should we enforce each commit to be larger before publishing? Should
we enforce commit chains to end up in a merge commit which is
detailed? Should we enforce updating changelog-equivalent only when a
particular feature is finished and ready to be added -- but *enforce
it consistently*?

Again, I don't want to have to have to distinguish between "this is
adding a new class", "this is fixing a security bug", "this is
*partially* addressing a security bug", "this is a quick compile fix",
"this is a large overhaul of the build system" by having to inspect
each commit in a really long chain of commits. Not necessarily a tree,
even.

FWIW ChangeLog entries *when written* were more useful for this
purpose. The problem was *when they weren't written*.

It's not necessarily true that the ChangeLog format is useful, but we
either need something like it, or we need to hold ourselves to strict
high standards of how we write commit messages, or we need cover
letters / detailed merge commits, or each new commit *must* have a
*tracking* bug ("issue") entry that we can use to write release news.

Git commits as written today are unsustainable.

> In terms of generating the ChangeLog entries automatically: I used to do
> this when we used svn.  I had a little script that would take an svn log
> and write a ChangeLog entry.  I didn't write the script, and when I
> looked no one had written a version that worked with Git.  I take this
> to mean that there is very little perceived requirement for ChangeLog
> files.  Having a non-canonical copy of information that has a canonical
> home doesn't seem valuable.  If people want it, then they can do a git
> log > MyOwnChangeLog.

This is a nonsolution if git messages keep being to the tune of
"Actually fix the implementation" <-- which implementation? how? why?
what's getting fixed? what was broken in the first place?

ChangeLog, *when written*, have been less of a problem *during this
particular release timeframe*.

>
> >
> > Then we would be saved the overhead of writing ChangeLog entries and could 
> > concentrate on:
> > 1. meaningful commit entries, which of course we should all be doing 
> > anyway;-)
> > 2. writing release notes for any substantive change (rather than ChangeLog 
> > entries for even minor changes), to appear in the NEWS when we make a 
> > release
>
> The second of these is the difficult bit, but it's *incredibly*
> valuable.  For the runtime, I try to update the ANNOUNCE doc as I go,
> but I still end up having to skim the git logs to check if I missed
> anything.  LLVM and FreeBSD both end up with manual steps and chasing
> contributors to update these just prior to release (FreeBSD has a
> 'Release-Notes: Yes' thing you can put in the commit message so that the
> release engineer will look at it for things to put in release notes).
>
> > If we stop writing ChangeLog entries, we should be able to write release 
> > notes and still be spending less time, and of course that would make the 
> > process of cutting a release less onerous.
> >
> > Does this seem a reasonable approach?
>
> +1.

Yes please. Let's do both. Let's write a note whenever you are halfway
or fully done with a new feature, whenever you fix a bug.

Enforce that commits, when merged, include this.

Whether you put it in news.texi, or write these notes in ChangeLog
(referencing exact files or not), or we keep release notes in a new
directory, with files named '-MM-DD-NN' that we flush as part of
the release process, I don't care much.

But maintainers, please just decide something and proclaim that this
is what will be done. It doesn't have to be consistent among packages,
but *within* a particular release of an individual package, I'd like
to see consistency. We can't have some people "opt-out" of the chosen
process. Maintainers need to be the ones to enforce this, including
possibly writing the log entries ('blogposts'?) themselves.

Re: Next GNUstep release

[David Chisnall]

On 06/04/2020 12:56, Richard Frith-Macdonald wrote:

Yes, thanks to Ivan.

I have spent some time thinking about this, and while in the past I've argued 
against dropping ChangeLog (it's more convenient than the git logs, and of 
course is there for peple who download tarballs etc and don't have ready access 
to the repositories), but I think overall I kind of agree now.

It's very onerous to put comments in multiple places, but there is value to 
each of these things:
Technical information in the repository
ChangeLog for easier access
Announce/News for summary of important details.

What I'd like to suggest is sort-of (but not entirely) scrapping ChangeLog, in 
that we could auto-generate ChangeLog entries from the repository, either by an 
automated commit hook or (assuming that's not easy to do readily), using a 
script to get details from the repository just before we make a realease, so 
that anyone getting a release of the software still gets a comprehensive 
ChangeLog.


I think that the place I'd disagree is that the ChangeLog is easier. 
That was probably true with GNA, somewhat true with viewvc (though 
debatable), but it isn't true with modern Git toolking (GitHub, GitLab, 
GOGS and so on).  Compare these two pages:


The ChangeLog file:
https://github.com/gnustep/libs-base/blob/master/ChangeLog

The Git history:
https://github.com/gnustep/libs-base/commits/master

The second is easier to skim, easier to jump to exact changes, and 
easier to use to isolate change in a particular area (only care about 
changes in the tools?  Look here: 
https://github.com/gnustep/libs-base/commits/master/Tools instead of the 
main history page).


The ChangeLog is more useable only for people who don't have web access 
(even if you download the tarball, you can still go to the web site to 
view the history and if you've done a git clone then you can view and 
search it offline easily).  The last of those is actually a valid reason 
for svn ChangeLog files that I missed: with svn, svn log was an online 
operation, so you couldn't do svn log / svn blame without a network 
connection, but you could read a ChangeLog.  With git, that is not a 
concern because log / blame are offline operations.


In terms of generating the ChangeLog entries automatically: I used to do 
this when we used svn.  I had a little script that would take an svn log 
and write a ChangeLog entry.  I didn't write the script, and when I 
looked no one had written a version that worked with Git.  I take this 
to mean that there is very little perceived requirement for ChangeLog 
files.  Having a non-canonical copy of information that has a canonical 
home doesn't seem valuable.  If people want it, then they can do a git 
log > MyOwnChangeLog.




Then we would be saved the overhead of writing ChangeLog entries and could 
concentrate on:
1. meaningful commit entries, which of course we should all be doing anyway;-)
2. writing release notes for any substantive change (rather than ChangeLog 
entries for even minor changes), to appear in the NEWS when we make a release


The second of these is the difficult bit, but it's *incredibly* 
valuable.  For the runtime, I try to update the ANNOUNCE doc as I go, 
but I still end up having to skim the git logs to check if I missed 
anything.  LLVM and FreeBSD both end up with manual steps and chasing 
contributors to update these just prior to release (FreeBSD has a 
'Release-Notes: Yes' thing you can put in the commit message so that the 
release engineer will look at it for things to put in release notes).



If we stop writing ChangeLog entries, we should be able to write release notes 
and still be spending less time, and of course that would make the process of 
cutting a release less onerous.

Does this seem a reasonable approach?


+1.

David

Re: Next GNUstep release

[Gregory Casamento]

Richard,

On Mon, Apr 6, 2020 at 7:56 AM Richard Frith-Macdonald <
rich...@frithmacdonald.me.uk> wrote:

>
>
> > On 6 Apr 2020, at 09:53, David Chisnall 
> wrote:
> >
> > I second that, thank you Ivan, but Fred your proposed solution is going
> to add more barriers to entry.
> >
> > ChangeLog files made sense when people were submitting patches on the
> mailing list and distributing code in tarballs.
> >
> > They were slightly anachronistic when CVS became standard for F/OSS
> projects and incorporated per-file change messages but they were still
> useful when people used them to describe the relationship between changes
> in multiple files.
> >
> > They were mostly obsolete when projects moved to svn and commits became
> atomic. Commit messages then referred to a set of related changes, rather
> than to single files.  The one remaining argument for them was that VCS
> history may get lost in moves between revision control systems.
> >
> > There was also a minor justification for them based on tooling: commit
> messages for svn were written after code review and some tools did not
> support reviewing the commit message along with the code (things like
> Phabricator did), so you could enforce a ChangeLog message in code review
> but you could not enforce a commit message at the same time.
> >
> > We have now seen projects move from CVS to SVN and then to Git,
> preserving commit messages.  Git commits have evolved a structure that is
> well supported by a load of tooling (vim even gives nice syntax
> highlighting to ensure that you confirm to this structure, all of the Git
> GUIs, including GitHub, are designed to render it), where the first line is
> short and gives a very high-level summary of the changes and the remainder
> gives a detailed overview. No equivalent tooling exists for ChangeLog files.
> >
> > In addition, a branch-and-PR workflow makes it possible to do code
> review of commit messages before merging.  Git makes it easy to edit and
> amend commit messages and force-push a branch, so individual commits can
> have their messages edited before a branch is merged.
> >
> > I would much rather see code review enforcing good commit messages,
> which is a workflow that contributors to any other open source project will
> be familiar with.  I fail to see any benefit in having ChangeLog entries.
> >
> > Note: I *do* see a benefit in having a separate NEWS or ANNOUNCE file
> that captures high-level user-visible improvements.  We don't necessarily
> need PR authors to write that, but the person merging a PR probably should
> if not.  This is far less granular than a commit message and serves a
> separate purpose.
> >
> > David
>
> Yes, thanks to Ivan.
>
> I have spent some time thinking about this, and while in the past I've
> argued against dropping ChangeLog (it's more convenient than the git logs,
> and of course is there for peple who download tarballs etc and don't have
> ready access to the repositories), but I think overall I kind of agree now.
>
> It's very onerous to put comments in multiple places, but there is value
> to each of these things:
> Technical information in the repository
> ChangeLog for easier access
> Announce/News for summary of important details.
>
> What I'd like to suggest is sort-of (but not entirely) scrapping
> ChangeLog, in that we could auto-generate ChangeLog entries from the
> repository, either by an automated commit hook or (assuming that's not easy
> to do readily), using a script to get details from the repository just
> before we make a realease, so that anyone getting a release of the software
> still gets a comprehensive ChangeLog.
>
> Then we would be saved the overhead of writing ChangeLog entries and could
> concentrate on:
> 1. meaningful commit entries, which of course we should all be doing
> anyway ;-)
> 2. writing release notes for any substantive change (rather than ChangeLog
> entries for even minor changes), to appear in the NEWS when we make a
> release
>
> If we stop writing ChangeLog entries, we should be able to write release
> notes and still be spending less time, and of course that would make the
> process of cutting a release less onerous.
>
> Does this seem a reasonable approach?
>
>
I believe this is entirely reasonable.

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron

Re: Next GNUstep release

[Richard Frith-Macdonald]

> On 6 Apr 2020, at 09:53, David Chisnall  wrote:
> 
> I second that, thank you Ivan, but Fred your proposed solution is going to 
> add more barriers to entry.
> 
> ChangeLog files made sense when people were submitting patches on the mailing 
> list and distributing code in tarballs.
> 
> They were slightly anachronistic when CVS became standard for F/OSS projects 
> and incorporated per-file change messages but they were still useful when 
> people used them to describe the relationship between changes in multiple 
> files.
> 
> They were mostly obsolete when projects moved to svn and commits became 
> atomic. Commit messages then referred to a set of related changes, rather 
> than to single files.  The one remaining argument for them was that VCS 
> history may get lost in moves between revision control systems.
> 
> There was also a minor justification for them based on tooling: commit 
> messages for svn were written after code review and some tools did not 
> support reviewing the commit message along with the code (things like 
> Phabricator did), so you could enforce a ChangeLog message in code review but 
> you could not enforce a commit message at the same time.
> 
> We have now seen projects move from CVS to SVN and then to Git, preserving 
> commit messages.  Git commits have evolved a structure that is well supported 
> by a load of tooling (vim even gives nice syntax highlighting to ensure that 
> you confirm to this structure, all of the Git GUIs, including GitHub, are 
> designed to render it), where the first line is short and gives a very 
> high-level summary of the changes and the remainder gives a detailed 
> overview. No equivalent tooling exists for ChangeLog files.
> 
> In addition, a branch-and-PR workflow makes it possible to do code review of 
> commit messages before merging.  Git makes it easy to edit and amend commit 
> messages and force-push a branch, so individual commits can have their 
> messages edited before a branch is merged.
> 
> I would much rather see code review enforcing good commit messages, which is 
> a workflow that contributors to any other open source project will be 
> familiar with.  I fail to see any benefit in having ChangeLog entries.
> 
> Note: I *do* see a benefit in having a separate NEWS or ANNOUNCE file that 
> captures high-level user-visible improvements.  We don't necessarily need PR 
> authors to write that, but the person merging a PR probably should if not.  
> This is far less granular than a commit message and serves a separate purpose.
> 
> David

Yes, thanks to Ivan.

I have spent some time thinking about this, and while in the past I've argued 
against dropping ChangeLog (it's more convenient than the git logs, and of 
course is there for peple who download tarballs etc and don't have ready access 
to the repositories), but I think overall I kind of agree now.

It's very onerous to put comments in multiple places, but there is value to 
each of these things:
Technical information in the repository
ChangeLog for easier access
Announce/News for summary of important details.

What I'd like to suggest is sort-of (but not entirely) scrapping ChangeLog, in 
that we could auto-generate ChangeLog entries from the repository, either by an 
automated commit hook or (assuming that's not easy to do readily), using a 
script to get details from the repository just before we make a realease, so 
that anyone getting a release of the software still gets a comprehensive 
ChangeLog.

Then we would be saved the overhead of writing ChangeLog entries and could 
concentrate on:
1. meaningful commit entries, which of course we should all be doing anyway ;-)
2. writing release notes for any substantive change (rather than ChangeLog 
entries for even minor changes), to appear in the NEWS when we make a release

If we stop writing ChangeLog entries, we should be able to write release notes 
and still be spending less time, and of course that would make the process of 
cutting a release less onerous.

Does this seem a reasonable approach?

Re: Next GNUstep release

[David Chisnall]

I second that, thank you Ivan, but Fred your proposed solution is going 
to add more barriers to entry.


ChangeLog files made sense when people were submitting patches on the 
mailing list and distributing code in tarballs.


They were slightly anachronistic when CVS became standard for F/OSS 
projects and incorporated per-file change messages but they were still 
useful when people used them to describe the relationship between 
changes in multiple files.


They were mostly obsolete when projects moved to svn and commits became 
atomic. Commit messages then referred to a set of related changes, 
rather than to single files.  The one remaining argument for them was 
that VCS history may get lost in moves between revision control systems.


There was also a minor justification for them based on tooling: commit 
messages for svn were written after code review and some tools did not 
support reviewing the commit message along with the code (things like 
Phabricator did), so you could enforce a ChangeLog message in code 
review but you could not enforce a commit message at the same time.


We have now seen projects move from CVS to SVN and then to Git, 
preserving commit messages.  Git commits have evolved a structure that 
is well supported by a load of tooling (vim even gives nice syntax 
highlighting to ensure that you confirm to this structure, all of the 
Git GUIs, including GitHub, are designed to render it), where the first 
line is short and gives a very high-level summary of the changes and the 
remainder gives a detailed overview. No equivalent tooling exists for 
ChangeLog files.


In addition, a branch-and-PR workflow makes it possible to do code 
review of commit messages before merging.  Git makes it easy to edit and 
amend commit messages and force-push a branch, so individual commits can 
have their messages edited before a branch is merged.


I would much rather see code review enforcing good commit messages, 
which is a workflow that contributors to any other open source project 
will be familiar with.  I fail to see any benefit in having ChangeLog 
entries.


Note: I *do* see a benefit in having a separate NEWS or ANNOUNCE file 
that captures high-level user-visible improvements.  We don't 
necessarily need PR authors to write that, but the person merging a PR 
probably should if not.  This is far less granular than a commit message 
and serves a separate purpose.


David

On 05/04/2020 21:49, Fred Kiefer wrote:

Thank you Ivan for the great work you are doing here. And I promise to try to 
lighten the work on the next release by making sure every pull request gets it 
proper ChangeLog entry.

Fred


Am 05.04.2020 um 22:42 schrieb Ivan Vučica :

I have cut new releases:
- gnustep-make 2.8.0
- gnustep-base 1.27.0
- gnustep-gui 0.28.0
- gnustep-back 0.28.0

They've been pushed to GitHub as commits and signed-tags, signed using
GPG key of yours truly. The signed tags, interpreted as releases by
GitHub, have been marked as 'prerelease', and tarballs + GPG
signatures made using the maintainer key have been attached to them.
  https://github.com/gnustep/tools-make/releases/make-2_8_0
   https://github.com/gnustep/libs-base/releases/base-1_27_0
   https://github.com/gnustep/libs-gui/releases/gui-0_28_0
   https://github.com/gnustep/libs-back/releases/back-0_28_0

As a temporary download URL, they're also available at
  https://badc0de.net/gs/2020/
for anyone who does not use GitHub.

Please, have a go at them, and let me know if there are any critical
issues. Please particularly review ANNOUNCE files as these will
customarily go out to info-...@gnu.org. ANNOUNCE files should be the
same ones that have been committed into our Git repositories.

Please validate .sig files in case I made a mistake; that would be
rather embarrassing.

If there are none, one of the evenings next week I will:

- upload tarballs to the default distribution point at ftp.gnustep.org
- flip the 'prerelease' bit on GitHub
- send ANNOUNCE emails to info-...@gnu.org and to discuss-gnus...@gnu.org

as was done for previous releases.

Thank you everyone for your work! While preparing these was a lot of
work, I am also impressed by the amount of changes all across the
board: tons of new classes, tons of work on Android; very very
impressive amount of changes.

Re: Next GNUstep release

[Fred Kiefer]

Thank you Ivan for the great work you are doing here. And I promise to try to 
lighten the work on the next release by making sure every pull request gets it 
proper ChangeLog entry.

Fred

> Am 05.04.2020 um 22:42 schrieb Ivan Vučica :
> 
> I have cut new releases:
> - gnustep-make 2.8.0
> - gnustep-base 1.27.0
> - gnustep-gui 0.28.0
> - gnustep-back 0.28.0
> 
> They've been pushed to GitHub as commits and signed-tags, signed using
> GPG key of yours truly. The signed tags, interpreted as releases by
> GitHub, have been marked as 'prerelease', and tarballs + GPG
> signatures made using the maintainer key have been attached to them.
>  https://github.com/gnustep/tools-make/releases/make-2_8_0
>   https://github.com/gnustep/libs-base/releases/base-1_27_0
>   https://github.com/gnustep/libs-gui/releases/gui-0_28_0
>   https://github.com/gnustep/libs-back/releases/back-0_28_0
> 
> As a temporary download URL, they're also available at
>  https://badc0de.net/gs/2020/
> for anyone who does not use GitHub.
> 
> Please, have a go at them, and let me know if there are any critical
> issues. Please particularly review ANNOUNCE files as these will
> customarily go out to info-...@gnu.org. ANNOUNCE files should be the
> same ones that have been committed into our Git repositories.
> 
> Please validate .sig files in case I made a mistake; that would be
> rather embarrassing.
> 
> If there are none, one of the evenings next week I will:
> 
> - upload tarballs to the default distribution point at ftp.gnustep.org
> - flip the 'prerelease' bit on GitHub
> - send ANNOUNCE emails to info-...@gnu.org and to discuss-gnus...@gnu.org
> 
> as was done for previous releases.
> 
> Thank you everyone for your work! While preparing these was a lot of
> work, I am also impressed by the amount of changes all across the
> board: tons of new classes, tons of work on Android; very very
> impressive amount of changes.
> 

Re: Next GNUstep release

[Ivan Vučica]

I have cut new releases:
- gnustep-make 2.8.0
- gnustep-base 1.27.0
- gnustep-gui 0.28.0
- gnustep-back 0.28.0

They've been pushed to GitHub as commits and signed-tags, signed using
GPG key of yours truly. The signed tags, interpreted as releases by
GitHub, have been marked as 'prerelease', and tarballs + GPG
signatures made using the maintainer key have been attached to them.
  https://github.com/gnustep/tools-make/releases/make-2_8_0
   https://github.com/gnustep/libs-base/releases/base-1_27_0
   https://github.com/gnustep/libs-gui/releases/gui-0_28_0
   https://github.com/gnustep/libs-back/releases/back-0_28_0

As a temporary download URL, they're also available at
  https://badc0de.net/gs/2020/
for anyone who does not use GitHub.

Please, have a go at them, and let me know if there are any critical
issues. Please particularly review ANNOUNCE files as these will
customarily go out to info-...@gnu.org. ANNOUNCE files should be the
same ones that have been committed into our Git repositories.

Please validate .sig files in case I made a mistake; that would be
rather embarrassing.

If there are none, one of the evenings next week I will:

- upload tarballs to the default distribution point at ftp.gnustep.org
- flip the 'prerelease' bit on GitHub
- send ANNOUNCE emails to info-...@gnu.org and to discuss-gnus...@gnu.org

as was done for previous releases.

Thank you everyone for your work! While preparing these was a lot of
work, I am also impressed by the amount of changes all across the
board: tons of new classes, tons of work on Android; very very
impressive amount of changes.

Re: Next GNUstep release

[Ivan Vučica]

Sounds good. I will cut Make too. I’m going to start now.

> On 4 Apr 2020, at 15:27, Riccardo Mottola  wrote:
> 
> Hi,
> 
> Richard Frith-Macdonald wrote:
>>> Sunday would be a good time for me, but I am fine waiting. Also, if it’s 
>>> not a binary-breaking change, I can always cut an additional point release. 
>>> Let me know what you think.
>> I think it's about time to make a release.  I'm looking at the 
>> NSURLComponents stuff some more today, but as it's a new class (not in the 
>> previous release), as long as it compiler reliably (it does) it's not going 
>> to break anything and should not stop us making a release.
>> 
>> 
> 
> I would release "base" as it is in master though, not mergein any
> branches.. I have decently tested it on a couple of platforms with gcc.
> 
> Riccardo

Re: Next GNUstep release

[Riccardo Mottola]

Hi,

Richard Frith-Macdonald wrote:
>> Sunday would be a good time for me, but I am fine waiting. Also, if it’s not 
>> a binary-breaking change, I can always cut an additional point release. Let 
>> me know what you think.
> I think it's about time to make a release.  I'm looking at the 
> NSURLComponents stuff some more today, but as it's a new class (not in the 
> previous release), as long as it compiler reliably (it does) it's not going 
> to break anything and should not stop us making a release.
>
>

I would release "base" as it is in master though, not mergein any
branches.. I have decently tested it on a couple of platforms with gcc.

Riccardo

Re: Next GNUstep release

[Ivan Vučica]

I'll proceed tomorrow then with releasing whatever is in the master branch.

I'll review if Documentation/news.texi (IIRC the source for other news
files) has been updated and if version has been bumped.


sent from phone

On Sat, Apr 4, 2020, 11:21 Richard Frith-Macdonald <
rich...@frithmacdonald.me.uk> wrote:

>
>
> > On 3 Apr 2020, at 01:26, Ivan Vučica  wrote:
> >
> > It’s mainly up to the maintainer to decide to release including whether
> things like that NSURLComponents change are risky. I suppose I should
> perhaps get a final thumbs up from Richard (or you) regarding -base, but
> otherwise it’s just a matter of ‘do I have the time to do it’, which may
> mean ‘do I feel like I’m going to do a good job if I start doing this now’.
> Fred asked for a -gui/-back release.
> >
> > Sunday would be a good time for me, but I am fine waiting. Also, if it’s
> not a binary-breaking change, I can always cut an additional point release.
> Let me know what you think.
>
> I think it's about time to make a release.  I'm looking at the
> NSURLComponents stuff some more today, but as it's a new class (not in the
> previous release), as long as it compiler reliably (it does) it's not going
> to break anything and should not stop us making a release.
>
>

Re: Next GNUstep release

[Richard Frith-Macdonald]

> On 3 Apr 2020, at 01:26, Ivan Vučica  wrote:
> 
> It’s mainly up to the maintainer to decide to release including whether 
> things like that NSURLComponents change are risky. I suppose I should perhaps 
> get a final thumbs up from Richard (or you) regarding -base, but otherwise 
> it’s just a matter of ‘do I have the time to do it’, which may mean ‘do I 
> feel like I’m going to do a good job if I start doing this now’. Fred asked 
> for a -gui/-back release.
>  
> Sunday would be a good time for me, but I am fine waiting. Also, if it’s not 
> a binary-breaking change, I can always cut an additional point release. Let 
> me know what you think.

I think it's about time to make a release.  I'm looking at the NSURLComponents 
stuff some more today, but as it's a new class (not in the previous release), 
as long as it compiler reliably (it does) it's not going to break anything and 
should not stop us making a release.

RE: Re: Next GNUstep release

[Ivan Vučica]

It’s mainly up to the maintainer to decide to release including whether things like that NSURLComponents change are risky. I suppose I should perhaps get a final thumbs up from Richard (or you) regarding -base, but otherwise it’s just a matter of ‘do I have the time to do it’, which may mean ‘do I feel like I’m going to do a good job if I start doing this now’. Fred asked for a -gui/-back release. Sunday would be a good time for me, but I am fine waiting. Also, if it’s not a binary-breaking change, I can always cut an additional point release. Let me know what you think. From: Gregory CasamentoSent: Thursday 2 April 2020 19:28To: Ivan VučicaCc: Niels Grewe; Developer GNUstepSubject: Re: Next GNUstep release I have a pending change to NSURLComponents in NSURL.m, fred is reviewing.  Once that is done I think we should be good to go.  I leave it up to you whether you believe it too risky to include.  Once you have done your release of make, base, gui and back I will release gorm. Yours, GC Sender notified by Mailtrack 04/02/20, 02:26:27 PM  On Thu, Apr 2, 2020 at 11:49 AM Ivan Vučica <i...@vucica.net> wrote:On Thu, Apr 2, 2020 at 4:46 PM Ivan Vučica <i...@vucica.net> wrote:> I'll cut make, base, gui, back. I'm aiming to do it Sunday.Also: I'll try to be present in #gnustep on Freenode. If you suspect Imight need help or just want to chat, please join me.Also: I'll validate that versions have been bumped. I expect we've hadbinary incompatibility changes, but despite Yavor's information, Inever set up the tools to validate this. -- Gregory CasamentoGNUstep Lead Developer / OLC, Principal Consultanthttp://www.gnustep.org - http://heronsperch.blogspot.comhttps://www.patreon.com/bePatron?u=352392 - Become a Patron 

Re: Next GNUstep release

[Gregory Casamento]

I have a pending change to NSURLComponents in NSURL.m, fred is reviewing.
Once that is done I think we should be good to go.  I leave it up to you
whether you believe it too risky to include.

Once you have done your release of make, base, gui and back I will release
gorm.

Yours, GC

[image: Mailtrack]

Sender
notified by
Mailtrack

04/02/20,
02:26:27 PM

On Thu, Apr 2, 2020 at 11:49 AM Ivan Vučica  wrote:

> On Thu, Apr 2, 2020 at 4:46 PM Ivan Vučica  wrote:
> > I'll cut make, base, gui, back. I'm aiming to do it Sunday.
>
> Also: I'll try to be present in #gnustep on Freenode. If you suspect I
> might need help or just want to chat, please join me.
>
> Also: I'll validate that versions have been bumped. I expect we've had
> binary incompatibility changes, but despite Yavor's information, I
> never set up the tools to validate this.
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
https://www.patreon.com/bePatron?u=352392 - Become a Patron

Re: Next GNUstep release

[Ivan Vučica]

On Thu, Apr 2, 2020 at 4:46 PM Ivan Vučica  wrote:
> I'll cut make, base, gui, back. I'm aiming to do it Sunday.

Also: I'll try to be present in #gnustep on Freenode. If you suspect I
might need help or just want to chat, please join me.

Also: I'll validate that versions have been bumped. I expect we've had
binary incompatibility changes, but despite Yavor's information, I
never set up the tools to validate this.

Re: Next GNUstep release

[Ivan Vučica]

Just noting that I've seen this email and I'll try to tackle the
release this weekend.

I'll of course validate what I'm releasing, and update -base if it's
not done by then.

I'll cut make, base, gui, back. I'm aiming to do it Sunday.

On Sun, Mar 29, 2020 at 9:01 PM Niels Grewe  wrote:
>
> On 28.03.20 09:59, Niels Grewe wrote:
> > Hi Fred,
> >
> > On 27.03.20 20:31, Fred Kiefer wrote:
> >> Hi Ivan,
> >>
> >> is it OK to go ahead with the release as planed?
> >> I just provide short descriptions of the changes in gui and back in the
> >> news-texi files. Everybody that contributed in the last year should have
> >> a short look to see whether I missed something or improve the description.
> >> @Richard could you do the same for base? Or if you don't have the time I
> >> might do that as well, just tell me.
> >> @Niels could you handle "make"?
> >
> > Of course! I also have a bit of documentation to update for the runtime
> > ABI related changes, but I'll surely find time to do it this weekend.
>
> I've tied up a few loose ends and prepared the NEWS file for -make, so
> the masters of the GPG keys may work their magic whenever they like.
>
> Cheers,
>
> Niels
>

Re: Next GNUstep release

[Niels Grewe]

On 28.03.20 09:59, Niels Grewe wrote:
> Hi Fred,
> 
> On 27.03.20 20:31, Fred Kiefer wrote:
>> Hi Ivan,
>>
>> is it OK to go ahead with the release as planed?
>> I just provide short descriptions of the changes in gui and back in the
>> news-texi files. Everybody that contributed in the last year should have
>> a short look to see whether I missed something or improve the description.
>> @Richard could you do the same for base? Or if you don't have the time I
>> might do that as well, just tell me.
>> @Niels could you handle "make"?
> 
> Of course! I also have a bit of documentation to update for the runtime
> ABI related changes, but I'll surely find time to do it this weekend.

I've tied up a few loose ends and prepared the NEWS file for -make, so
the masters of the GPG keys may work their magic whenever they like.

Cheers,

Niels

Re: Next GNUstep release

[Niels Grewe]

Hi Fred,

On 27.03.20 20:31, Fred Kiefer wrote:
> Hi Ivan,
> 
> is it OK to go ahead with the release as planed?
> I just provide short descriptions of the changes in gui and back in the
> news-texi files. Everybody that contributed in the last year should have
> a short look to see whether I missed something or improve the description.
> @Richard could you do the same for base? Or if you don't have the time I
> might do that as well, just tell me.
> @Niels could you handle "make"?

Of course! I also have a bit of documentation to update for the runtime
ABI related changes, but I'll surely find time to do it this weekend.

Cheers,

Niels

> I want to thank you all for the great contributions over the last year
> and hope we get these out really soon.
> 
> Cheers,
> Fred
> 
> 
> Am 28.02.20 um 00:37 schrieb Ivan Vučica:
>> On Tue, Feb 11, 2020 at 8:09 AM Fred Kiefer 
>> wrote:
>>> And most importantly, Ivan will you have time to cut all these
>>> releases? Of course we could move that point around a week or two
>>> if that date fits better
>>
>> I've only now seen this.
>>
>> This is ok and please coordinate with me closer to the release date.
>> It's nearly zero effort for me if maintainers keep up to date
>> Documentation/news.texi and other files you can see me updating by
>> hand just before release. Most time-consuming is a) sorting out
>> through 'what changed' and revising news.texi et al, b) getting the
>> GPG signing key to work, c) coordinating what version we should have
>> actually bumped to because we might break Debian automated checks
>> etc.
>>
>> I'm ok doing all these, but more I have to do, more planning do I
>> have to put into dedicating huge blocks of time to a release.
>>
>> (Note, having package maintainers and distro packaging maintainers
>> online -- preferably in a realtime groupchat e.g. on IRC -- when
>> cutting a release would not be a bad thing. This means we can sort
>> out and test any issues within hours rather than days.)
>>
>> On Thu, Feb 27, 2020 at 9:10 PM Riccardo Mottola
>>  wrote:
>>> before a release, I would like these issues to find a solution.
>>>
>>> - understand why we don't work properly on my ThinkPad T23 neither
>>> with the Cairo nor with the xlib backend with similar issues
>>
>> Did you date when things broke and at what change?
>>
>> I'm afraid that when I'm cutting a release I only use a single
>> platform (Ubuntu or Debian amd64 with libobjc2 and clang) with
>> usually one or two backend configs (usually cairo). Sometimes I build
>> with GCC or with GCC runtime. I don't have other environments around,
>> including a working environment on Windows.
>>
>> I don't know what should be release blockers, I'm leaving that to
>> individual package maintainers.
>>
>>> - understand/fix/workaround the libobjc2 which impede me to test
>>> current GNUstep on any FreeBSD 11.x and 12.x I currently have on
>>> i386 and amd64
>>
>> Honestly, I would have expected that libobjc2 FreeBSD should work
>> out of the box given David is/was working on FreeBSD...
>>
> 
> 

Re: Next GNUstep release

[Fred Kiefer]

Hi Ivan,

is it OK to go ahead with the release as planed?
I just provide short descriptions of the changes in gui and back in the
news-texi files. Everybody that contributed in the last year should have
a short look to see whether I missed something or improve the description.
@Richard could you do the same for base? Or if you don't have the time I
might do that as well, just tell me.
@Niels could you handle "make"?

I want to thank you all for the great contributions over the last year
and hope we get these out really soon.

Cheers,
Fred


Am 28.02.20 um 00:37 schrieb Ivan Vučica:
> On Tue, Feb 11, 2020 at 8:09 AM Fred Kiefer 
> wrote:
>> And most importantly, Ivan will you have time to cut all these
>> releases? Of course we could move that point around a week or two
>> if that date fits better
>
> I've only now seen this.
>
> This is ok and please coordinate with me closer to the release date.
> It's nearly zero effort for me if maintainers keep up to date
> Documentation/news.texi and other files you can see me updating by
> hand just before release. Most time-consuming is a) sorting out
> through 'what changed' and revising news.texi et al, b) getting the
> GPG signing key to work, c) coordinating what version we should have
> actually bumped to because we might break Debian automated checks
> etc.
>
> I'm ok doing all these, but more I have to do, more planning do I
> have to put into dedicating huge blocks of time to a release.
>
> (Note, having package maintainers and distro packaging maintainers
> online -- preferably in a realtime groupchat e.g. on IRC -- when
> cutting a release would not be a bad thing. This means we can sort
> out and test any issues within hours rather than days.)
>
> On Thu, Feb 27, 2020 at 9:10 PM Riccardo Mottola
>  wrote:
>> before a release, I would like these issues to find a solution.
>>
>> - understand why we don't work properly on my ThinkPad T23 neither
>> with the Cairo nor with the xlib backend with similar issues
>
> Did you date when things broke and at what change?
>
> I'm afraid that when I'm cutting a release I only use a single
> platform (Ubuntu or Debian amd64 with libobjc2 and clang) with
> usually one or two backend configs (usually cairo). Sometimes I build
> with GCC or with GCC runtime. I don't have other environments around,
> including a working environment on Windows.
>
> I don't know what should be release blockers, I'm leaving that to
> individual package maintainers.
>
>> - understand/fix/workaround the libobjc2 which impede me to test
>> current GNUstep on any FreeBSD 11.x and 12.x I currently have on
>> i386 and amd64
>
> Honestly, I would have expected that libobjc2 FreeBSD should work
> out of the box given David is/was working on FreeBSD...
>

Re: Display issues (Was: Next GNUstep release)

[Riccardo Mottola]

Hi Sergii,

Sergii Stoian wrote:

You forgot to mention one important detail. This problem only shows up with 16 
bit depth. Most likely this happens as some data structure that holds the 
intermediate pixel information rounds the line length to a multiple of 8, 16, 
32 or even 64 and we use one value below that, so we get an offset for each 
line which leads to the displayed garbage. The problem is that I am not able to 
reproduce the issue and don’t know which intermediate structure needs 
adjustment.

It looks strange. Some regions which are roughly filled with XFillRectangle 
should look plain. But they don’t (Riccardo sent me a screenshots). We need to 
be sure the video driver works correctly. The next step is to understand what 
code in GNUstep drives that weird behaviour.


I performed some tests by hacking xorg.conf ... I was a bit rusty at 
that, but a refresh does good. We are forced at home for cornavirus anyway.


I can enable/disable HW acceleration in the driver and force 16 bit or 
24 bit.

This gives us 4 combinations!

1) Accel + 16 bit : GNUstep Broken as per original screenshot
2) NoAccel + 16bit : Everything Works fine!
3) Accel + 24bit: GNUstep slightly broken, like 16 bit but there is 
clearly a repaint where (mouse cursor ruins display, there is clearly a 
driver bug in this mode)

4) NoAccel + 24bit: works

so, clearly HW acceleration makes some difference.
I checked other apps, I did run not only WindowMaker, xterm, gvim, but 
also more difficult apps like emacs and firefox and they do look fine 
without the issues we have in both 16bit and 24 bit acceleration.


Interesting is GNUstep in 24 bit accelerated mode: it looks broken 
similar to 16bit, but in 16 bit a broken window is just broken and 
always look the same from the beginning (refresh, minimize, etc) and 
depends only on the size, in 24 bit it is different!
in 24 bit accel, the window comes up and looks broken like in 16bit then 
immediately draws and looks "decent" (small glitches). However a move or 
a iconize/reopen will make it broken, like in 16bit mode.


My guess is that we do some double-buffering or shadow buffering 
somewhere and the two buffers are not "aligned"


What is common here to both cairo? I don't know if I mentioned, but 
when I tested 16bit-accel, I tested both backends! so it is not "cairo 
specifc". I did not test art because I don't have libart nor art fonts 
in this machine, but if you wish, I could try.


Riccardo

Re: Next GNUstep release

[Riccardo Mottola]

Hi!

Ivan Vučica wrote:

- understand/fix/workaround the libobjc2 which impede me to test current
GNUstep on any FreeBSD 11.x and 12.x I currently have on i386 and amd64

Honestly, I would have expected that libobjc2 FreeBSD should work out
of the box given David is/was working on FreeBSD...


Me too! and of course he is not able to reproduce my issue or I bet he 
would have been quick at fixing things.
However, since I have the issue on more than one system... I'd say it is 
not just one unlucky machine.


Riccardo

Re: Display issues (Was: Next GNUstep release)

[Sergii Stoian]

> On Feb 28, 2020, at 13:17, Fred Kiefer  wrote:
> 
> 
> 
>> Am 28.02.2020 um 11:37 schrieb Riccardo Mottola :
>> Sergii Stoian wrote:
>>> 
 On Feb 27, 2020, at 23:09, Riccardo Mottola  
 wrote:
 
 before a release, I would like these issues to find a solution.
 
 - understand why we don't work properly on my ThinkPad T23 neither with 
 the Cairo nor with the xlib backend with similar issues
>>> Could you please be more specific and describe these issues?
>> 
>> I have an issue I am working on with Fred, I can forward you some mail 
>> because they contain screenshot and I did not spam the mailing list.
>> 
>> Essentially I discovered that many windows contain "garbage" and what we 
>> discovered so far
>> - certain windows width cause garbage do be displayed, resizing the window 
>> may cause it do display correctly
>> - this garbage is compatible with an wrong offset increasing for each row 
>> (you see diagonal lines if  you have a white window with a border)
>> - the issue happens both with cairo and xlib (recent discovery of two days 
>> ago, before we were concentrating on a cairo issue)
>> 
>> it looks like an issue that somwehre a padding/alignment is lost: e.g. 
>> width*bytesPerPixel != bytesPerRow, but where?
>> 
>> I have not seen this issue elsewhere. The T23 is itself a pretty standard 
>> setup: Devuan ascii, GCC runtime, i386. Only the videocard is a little bit 
>> vintage/odd (S3) but it works with any other program except GNUstep :-P
> 
> You forgot to mention one important detail. This problem only shows up with 
> 16 bit depth. Most likely this happens as some data structure that holds the 
> intermediate pixel information rounds the line length to a multiple of 8, 16, 
> 32 or even 64 and we use one value below that, so we get an offset for each 
> line which leads to the displayed garbage. The problem is that I am not able 
> to reproduce the issue and don’t know which intermediate structure needs 
> adjustment.

It looks strange. Some regions which are roughly filled with XFillRectangle 
should look plain. But they don’t (Riccardo sent me a screenshots). We need to 
be sure the video driver works correctly. The next step is to understand what 
code in GNUstep drives that weird behaviour.

Re: Display issues (Was: Next GNUstep release)

[Sergii Stoian]

Hi,

> On Feb 28, 2020, at 12:37, Riccardo Mottola  
> wrote:
> 
> Hi,
> 
> Sergii Stoian wrote:
>> Hi,
>> 
>>> On Feb 27, 2020, at 23:09, Riccardo Mottola  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> before a release, I would like these issues to find a solution.
>>> 
>>> - understand why we don't work properly on my ThinkPad T23 neither with the 
>>> Cairo nor with the xlib backend with similar issues
>> Could you please be more specific and describe these issues?
> 
> I have an issue I am working on with Fred, I can forward you some mail 
> because they contain screenshot and I did not spam the mailing list.
> 
> Essentially I discovered that many windows contain "garbage" and what we 
> discovered so far
> - certain windows width cause garbage do be displayed, resizing the window 
> may cause it do display correctly
> - this garbage is compatible with an wrong offset increasing for each row 
> (you see diagonal lines if  you have a white window with a border)
> - the issue happens both with cairo and xlib (recent discovery of two days 
> ago, before we were concentrating on a cairo issue)
> 
> it looks like an issue that somwehre a padding/alignment is lost: e.g. 
> width*bytesPerPixel != bytesPerRow, but where?
> 
> I have not seen this issue elsewhere. The T23 is itself a pretty standard 
> setup: Devuan ascii, GCC runtime, i386. Only the videocard is a little bit 
> vintage/odd (S3) but it works with any other program except GNUstep :-P
> 
> 
> Riccardo

Could you test it with “vesa” video driver to be sure it’s not a driver problem?

Re: Display issues (Was: Next GNUstep release)

[Fred Kiefer]

> Am 28.02.2020 um 11:37 schrieb Riccardo Mottola :
> Sergii Stoian wrote:
>> 
>>> On Feb 27, 2020, at 23:09, Riccardo Mottola  
>>> wrote:
>>> 
>>> before a release, I would like these issues to find a solution.
>>> 
>>> - understand why we don't work properly on my ThinkPad T23 neither with the 
>>> Cairo nor with the xlib backend with similar issues
>> Could you please be more specific and describe these issues?
> 
> I have an issue I am working on with Fred, I can forward you some mail 
> because they contain screenshot and I did not spam the mailing list.
> 
> Essentially I discovered that many windows contain "garbage" and what we 
> discovered so far
> - certain windows width cause garbage do be displayed, resizing the window 
> may cause it do display correctly
> - this garbage is compatible with an wrong offset increasing for each row 
> (you see diagonal lines if  you have a white window with a border)
> - the issue happens both with cairo and xlib (recent discovery of two days 
> ago, before we were concentrating on a cairo issue)
> 
> it looks like an issue that somwehre a padding/alignment is lost: e.g. 
> width*bytesPerPixel != bytesPerRow, but where?
> 
> I have not seen this issue elsewhere. The T23 is itself a pretty standard 
> setup: Devuan ascii, GCC runtime, i386. Only the videocard is a little bit 
> vintage/odd (S3) but it works with any other program except GNUstep :-P

You forgot to mention one important detail. This problem only shows up with 16 
bit depth. Most likely this happens as some data structure that holds the 
intermediate pixel information rounds the line length to a multiple of 8, 16, 
32 or even 64 and we use one value below that, so we get an offset for each 
line which leads to the displayed garbage. The problem is that I am not able to 
reproduce the issue and don’t know which intermediate structure needs 
adjustment.

Display issues (Was: Next GNUstep release)

[Riccardo Mottola]

Hi,

Sergii Stoian wrote:

Hi,


On Feb 27, 2020, at 23:09, Riccardo Mottola  wrote:

Hi,

before a release, I would like these issues to find a solution.

- understand why we don't work properly on my ThinkPad T23 neither with the 
Cairo nor with the xlib backend with similar issues

Could you please be more specific and describe these issues?


I have an issue I am working on with Fred, I can forward you some mail 
because they contain screenshot and I did not spam the mailing list.


Essentially I discovered that many windows contain "garbage" and what we 
discovered so far
- certain windows width cause garbage do be displayed, resizing the 
window may cause it do display correctly
- this garbage is compatible with an wrong offset increasing for each 
row (you see diagonal lines if  you have a white window with a border)
- the issue happens both with cairo and xlib (recent discovery of two 
days ago, before we were concentrating on a cairo issue)


it looks like an issue that somwehre a padding/alignment is lost: e.g. 
width*bytesPerPixel != bytesPerRow, but where?


I have not seen this issue elsewhere. The T23 is itself a pretty 
standard setup: Devuan ascii, GCC runtime, i386. Only the videocard is a 
little bit vintage/odd (S3) but it works with any other program except 
GNUstep :-P



Riccardo

Re: Next GNUstep release

[Ivan Vučica]

On Tue, Feb 11, 2020 at 8:09 AM Fred Kiefer  wrote:
> And most importantly, Ivan will you have time to cut all these releases? Of 
> course we could move that point around a week or two if that date fits better

I've only now seen this.

This is ok and please coordinate with me closer to the release date.
It's nearly zero effort for me if maintainers keep up to date
Documentation/news.texi and other files you can see me updating by
hand just before release. Most time-consuming is a) sorting out
through 'what changed' and revising news.texi et al, b) getting the
GPG signing key to work, c) coordinating what version we should have
actually bumped to because we might break Debian automated checks etc.

I'm ok doing all these, but more I have to do, more planning do I have
to put into dedicating huge blocks of time to a release.

(Note, having package maintainers and distro packaging maintainers
online -- preferably in a realtime groupchat e.g. on IRC -- when
cutting a release would not be a bad thing. This means we can sort out
and test any issues within hours rather than days.)

On Thu, Feb 27, 2020 at 9:10 PM Riccardo Mottola
 wrote:
> before a release, I would like these issues to find a solution.
>
> - understand why we don't work properly on my ThinkPad T23 neither with
> the Cairo nor with the xlib backend with similar issues

Did you date when things broke and at what change?

I'm afraid that when I'm cutting a release I only use a single
platform (Ubuntu or Debian amd64 with libobjc2 and clang) with usually
one or two backend configs (usually cairo). Sometimes I build with GCC
or with GCC runtime. I don't have other environments around, including
a working environment on Windows.

I don't know what should be release blockers, I'm leaving that to
individual package maintainers.

> - understand/fix/workaround the libobjc2 which impede me to test current
> GNUstep on any FreeBSD 11.x and 12.x I currently have on i386 and amd64

Honestly, I would have expected that libobjc2 FreeBSD should work out
of the box given David is/was working on FreeBSD...

Re: Next GNUstep release

[Sergii Stoian]

Hi,

> On Feb 27, 2020, at 23:09, Riccardo Mottola  
> wrote:
> 
> Hi,
> 
> before a release, I would like these issues to find a solution.
> 
> - understand why we don't work properly on my ThinkPad T23 neither with the 
> Cairo nor with the xlib backend with similar issues

Could you please be more specific and describe these issues?

> - understand/fix/workaround the libobjc2 which impede me to test current 
> GNUstep on any FreeBSD 11.x and 12.x I currently have on i386 and amd64
> 
> afterwards a "run" on our current applications would be fine. After core 
> release, I think a release of acouple of other apps could be nice. 
> ProjectCenter and some GAP apps should go. I will also finalize a PRICE 
> release in the next weeks.
> 
> Riccardo
> 

Sergii

Re: Next GNUstep release

[Riccardo Mottola]

Hi,

before a release, I would like these issues to find a solution.

- understand why we don't work properly on my ThinkPad T23 neither with 
the Cairo nor with the xlib backend with similar issues
- understand/fix/workaround the libobjc2 which impede me to test current 
GNUstep on any FreeBSD 11.x and 12.x I currently have on i386 and amd64


afterwards a "run" on our current applications would be fine. After core 
release, I think a release of acouple of other apps could be nice. 
ProjectCenter and some GAP apps should go. I will also finalize a PRICE 
release in the next weeks.


Riccardo

Re: Next GNUstep release

[Sergii Stoian]

Hi,

> On Feb 11, 2020, at 15:14, Sergii Stoian  wrote:
> 
> Hi Fed,
> 
> On Tue, Feb 11, 2020 at 10:09 AM Fred Kiefer  > wrote:
> Dear GNUsteppers,
> 
> I would like to schedule a shared new release for the core GNUstep packages 
> (make, base, gui, back) around the end of March. We have a lot of excellent 
> new features and it would be great to bring those out to more distributions 
> and users. We are a bit later than in previous years still we should leave us 
> enough time to prepare that release. I hope that it is possible to merge the 
> Wayland branch before. (And yes, I still didn’t get around to review that. 
> Sorry) And to give other new features like the multi monitor support a bit 
> more testing and polishing. But I would suggest that we do not start or merge 
> other big features during that time. (Smaller changes like the ones Greg is 
> working in gui on should be fine) Any objections? And most importantly, Ivan 
> will you have time to cut all these releases? Of course we could move that 
> point around a week or two if that date fits better.
> 
> Fred
> 
> I'd like to finish new "Main menu follows key window" functionality 
> (libs-gui, randr branch) before feature freeze. It will be a good test for 
> multi-monitor support. 
> I need a couple of days to polish code and finish testing.
> Also I plan to test NSWindow's "AutosaveFrame" feaure testing against 
> implemented multi-monitor support (various scenarios).
> 
> -- 
> Sergii Stoian

I’ve just finished making extensive testing with various multi-monitor layout 
configuration and fixed several quite nasty bugs.
Latest changes to libs-back made at least -placewindow:: method more reliable 
to changes which are made by NSWindow to _frame ivar.
It is especially important when X11 coordinate of a window is not changed but 
OpenStep's must be updated (if monitor layout changed from horizontal to 
vertical).

At this point I consider multiple monitor support as completed. Although some 
checks and testing to “AutosaveFrame” is planned.
Meanwhile encourage you to make testing of multi-monitor layout and notify me 
so I can fix bugs before release.

Sergii

Re: Next GNUstep release

[Riccardo Mottola]

Hi!


Fred Kiefer wrote:

I would like to schedule a shared new release for the core GNUstep packages 
(make, base, gui, back) around the end of March. We have a lot of excellent new 
features and it would be great to bring those out to more distributions and 
users. We are a bit later than in previous years still we should leave us 
enough time to prepare that release. I hope that it is possible to merge the 
Wayland branch before. (And yes, I still didn’t get around to review that. 
Sorry) And to give other new features like the multi monitor support a bit more 
testing and polishing. But I would suggest that we do not start or merge other 
big features during that time. (Smaller changes like the ones Greg is working 
in gui on should be fine) Any objections? And most importantly, Ivan will you 
have time to cut all these releases? Of course we could move that point around 
a week or two if that date fits better.


I think it is fine, although it should be really tested... on different 
configs. There is a lot "happening" lately.
Especially in back things are in flux and had performance or 
compatibility issues. Of course, promising stuff to..



Also make! I was proposing to merge Niels' patch but i see RFM did it. 
So now it only needs to be tested more...


Riccardo

Re: Next GNUstep release

[Sergii Stoian]

Hi Fed,

On Tue, Feb 11, 2020 at 10:09 AM Fred Kiefer  wrote:

> Dear GNUsteppers,
>
> I would like to schedule a shared new release for the core GNUstep
> packages (make, base, gui, back) around the end of March. We have a lot of
> excellent new features and it would be great to bring those out to more
> distributions and users. We are a bit later than in previous years still we
> should leave us enough time to prepare that release. I hope that it is
> possible to merge the Wayland branch before. (And yes, I still didn’t get
> around to review that. Sorry) And to give other new features like the multi
> monitor support a bit more testing and polishing. But I would suggest that
> we do not start or merge other big features during that time. (Smaller
> changes like the ones Greg is working in gui on should be fine) Any
> objections? And most importantly, Ivan will you have time to cut all these
> releases? Of course we could move that point around a week or two if that
> date fits better.
>
> Fred
>

I'd like to finish new "Main menu follows key window" functionality
(libs-gui, randr branch) before feature freeze. It will be a good test for
multi-monitor support.
I need a couple of days to polish code and finish testing.
Also I plan to test NSWindow's "AutosaveFrame" feaure testing against
implemented multi-monitor support (various scenarios).

-- 
Sergii Stoian

Re: Next GNUstep release

[Gregory Casamento]

Fred,

On Tue, Feb 11, 2020 at 3:08 AM Fred Kiefer  wrote:

> Dear GNUsteppers,
>
> I would like to schedule a shared new release for the core GNUstep
> packages (make, base, gui, back) around the end of March. We have a lot of
> excellent new features and it would be great to bring those out to more
> distributions and users. We are a bit later than in previous years still we
> should leave us enough time to prepare that release. I hope that it is
> possible to merge the Wayland branch before. (And yes, I still didn’t get
> around to review that. Sorry) And to give other new features like the multi
> monitor support a bit more testing and polishing. But I would suggest that
> we do not start or merge other big features during that time. (Smaller
> changes like the ones Greg is working in gui on should be fine) Any
> objections?


No objections from me.  I was thinking recently about releasing, so this is
good timing.  I am currently working on the following things:

* NSSpeechRecognizer (nearly done, working)
  branch: NSSpeechRecognizer_branch
* NSFontCollection (about halfway done as I now sort of understand how it
works)
  branch: NSFontCollection_branch
* NSStoryboard/NSStoryboardSegue (just started, but I understand fully what
they do)
  branch: NSStoryboard_branch

>From now to the end of march is plenty of time to finish all of these for
me, so, as long as they all pass review by then, I'm fine.

And most importantly, Ivan will you have time to cut all these releases? Of
> course we could move that point around a week or two if that date fits
> better.
>
> Fred
>

Yours, GC

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Next GNUstep release

[Fred Kiefer]

Dear GNUsteppers,

I would like to schedule a shared new release for the core GNUstep packages 
(make, base, gui, back) around the end of March. We have a lot of excellent new 
features and it would be great to bring those out to more distributions and 
users. We are a bit later than in previous years still we should leave us 
enough time to prepare that release. I hope that it is possible to merge the 
Wayland branch before. (And yes, I still didn’t get around to review that. 
Sorry) And to give other new features like the multi monitor support a bit more 
testing and polishing. But I would suggest that we do not start or merge other 
big features during that time. (Smaller changes like the ones Greg is working 
in gui on should be fine) Any objections? And most importantly, Ivan will you 
have time to cut all these releases? Of course we could move that point around 
a week or two if that date fits better.

Fred

Re: Next GNUstep release?

[Richard Frith-Macdonald]

On 9 Nov 2011, at 19:53, Fred Kiefer wrote:
 
 So far there has been only Riccardo's reply whether there should be a release 
 at all. Those this mean we shouldn't do a shared release now? Then we could 
 thing about just a gui/back release, which shoudl make Riccardo happy.

I like your idea of doing a new combined release to get things in sync... base 
has a variety of minor bugfixes which are worth making a new bugfix release for 
... and if gui/back is tested against trunk make/base it seems sensible to do a 
combined release of the whole lot before the end of the year.

I'm not actually clear on what Riccardo wants here , so I won't try to comment 
on other alternatives, but it seems to me we want to get things back in sync 
properly ASAP.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Pirmin Braun]

Am Thu, 10 Nov 2011 09:33:08 +
schrieb Richard Frith-Macdonald rich...@tiptree.demon.co.uk :

 I'm not actually clear on what Riccardo wants here , so I won't try to 
 comment on other alternatives, but it seems to me we want to get things back 
 in sync properly ASAP.

yes.

-- 
mit freundlichen Gruessen/best regards

Pirmin Braun
seat-1 Software GmbH - Sinziger Str. 29a - 53424 Remagen
+49(0)2642 308288   +49(0)163-6290887 - skype:pirminb
Fax +49(0)2642 308626
http://www.seat-1.com  p...@seat-1.com
http://intars.sourceforge.net

Geschäftsführer: Pirmin Braun, Ralf Engelhardt
Registergericht: Amtsgericht Coburg HRB3136


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Ivan Vučica]

Just a small comment.

On Wed, Nov 9, 2011 at 19:13, Riccardo Mottola
riccardo.mott...@libero.itwrote:

 We are not Apple, nor Microsoft nor whatever. We value freedom, which has
 many aspects. How tedious.


It works both ways: bigger companies can sometimes afford supporting a
somewhat wider variety of options. :)
-- 
Ivan Vučica - i...@vucica.net
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[David Chisnall]

On 9 Nov 2011, at 05:32, Gregory Casamento wrote:

 As I remember it, we agreed on GCC 4.0 and later.

Yup, the rationale was that 2.9x - 3.x was where most of the platforms were 
dropped.  Excluding 3.x gives us a more modern compiler with better language 
support and doesn't lose us any platforms.  Pretty much anything that might 
reasonably be expected to run GNUstep that was supported by 3.x is also 
supported by 4.x.

David

-- Sent from my Apple II
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi,

I don't remember about this and agreeing on that. We spoke about 2.95 
because it had serious limitations and limited c99 compatibility which 
was fine to drop and I agreed on that because the inconvenience of 
maintaining it outweighed the benefits eventually.


I'd be against dropping 3.x support. What's the problem with 3.x vs. 
4.x? 3.2 especially was essentially the second best portable option 
after 2.95. Portability of gcc got quite worse after 3.4.


Given the past code in gnustep, I never had any problems with gcc3, the 
only problems where with 2.95.


Riccardo

PS: additionally I think that the current gui and back release should 
still be 2.95 compatible, they are the natural match for the past base 
release. Especially since the past releases of gui and back are unusable 
with current base. So a coehrent core should be released.


On 11/09/11 13:56, David Chisnall wrote:

On 9 Nov 2011, at 05:32, Gregory Casamento wrote:


As I remember it, we agreed on GCC 4.0 and later.

Yup, the rationale was that 2.9x -  3.x was where most of the platforms were 
dropped.  Excluding 3.x gives us a more modern compiler with better language 
support and doesn't lose us any platforms.  Pretty much anything that might 
reasonably be expected to run GNUstep that was supported by 3.x is also supported 
by 4.x.

David

-- Sent from my Apple II



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[David Chisnall]

On 9 Nov 2011, at 13:15, Riccardo Mottola wrote:

 3.2 especially was essentially the second best portable option after 2.95. 
 Portability of gcc got quite worse after 3.4.

Examples please.  What platforms:

- Are supported by GCC 3.2
- Are not supported by GCC 4.0 or Clang
- Are supported by GNUstep?

David

-- Sent from my Apple II
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi


Examples please.  What platforms:

- Are supported by GCC 3.2
- Are not supported by GCC 4.0 or Clang
- Are supported by GNUstep?
Don't twist the question. It is not a matter of which platform could 
be supported by a newer version of gcc. We are not Apple or some 
commercial company, oh see, Mac 10.99 is out, let's make some 
incompatible SuperApp. We as free software try to give the broadtest 
freedom and this implies limiting as little as possible.
Most people wanted c99, maintaining the burden of special macros was too 
much, we dropped it, fine, I agreed. but jumping directly to gcc 4.0, oh 
pardon, 4.2? If there are no hard, pressing reasons for that, I consider 
it a gratuitous change.


If you just take OpenBSD 4.7, it shipped with gcc 3.3.5. Me are speaking 
of May 2010, not stone age.
Sure, it MAY run gcc 4, it most probably does on x86 too, but why force 
the person to take the hassle?


Take solaris, sunfreeware still offers gcc 3.4.6 . The most commin thing 
you will find even on the latest IRIX boxen is gcc 3.3, because that is 
what SGI gave us. Theoretically, up to gcc 4.6 is supported, I wasn't 
able to build any gcc 4. version yet.


I don't know how gcc support is/was on various platforms.

On windows gcc 3.x is standard on cygwin (even if gcc4 is provided 
extra). Also n mingw in our just previous release (not current) we 
shipped gcc 3..x . Again, it is not stone age.


We don't even know how many platforms we support, why do you want to axe 
them?


We support for example NetBSD 2.0.2 with gcc 3.x on sparc. I have it, it 
works fine and compiles fine. The hardware probably supports newer 
stuff, but current it works.


Supporting a platform is not just latest revision. We are not Apple, 
nor Microsoft nor whatever. We value freedom, which has many aspects. 
How tedious.


Riccardo


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Richard Frith-Macdonald]

On 9 Nov 2011, at 12:56, David Chisnall wrote:

 On 9 Nov 2011, at 05:32, Gregory Casamento wrote:
 
 As I remember it, we agreed on GCC 4.0 and later.
 
 Yup, the rationale was that 2.9x - 3.x was where most of the platforms were 
 dropped.  Excluding 3.x gives us a more modern compiler with better language 
 support and doesn't lose us any platforms.  Pretty much anything that might 
 reasonably be expected to run GNUstep that was supported by 3.x is also 
 supported by 4.x.

Yes, we chose 4.0 as the earliest compiler to support because it gave a good 
feature set to base future code on (and so we wouldn't want to change the 
version we depend on again for a while), while running on as many platforms as 
(by now probably rather more than) any version 3.x compiler.  At least that was 
the theory for the choice, and nobody afaik has claimed/demonstrated anything 
wrong with it.
Is there *any* platform where a 3.? compiler will run and a 4.? compiler won't?



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[David Chisnall]

On 9 Nov 2011, at 18:13, Riccardo Mottola wrote:

 
 Examples please.  What platforms:
 
 - Are supported by GCC 3.2
 - Are not supported by GCC 4.0 or Clang
 - Are supported by GNUstep?
 Don't twist the question

I'm not twisting the question.  Supporting older compilers increases the 
maintenance burden for us.  The question always was, what is the newest 
compiler that we can reasonably expect to be on any platform where people are 
going to want to run GNUstep.  

We decided before the release that GCC 4.x or newer provided the best balance 
between reducing our effort and maintaining support.  

If you wish to maintain a GCC 3.x (or even 2.x) compatibility branch, then no 
one will stop you, but if you want everyone else to put effort into maintaining 
support for a legacy compiler then you need to provide a compelling reason.  

David

--
This email complies with ISO 3103


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Eric Wasylishen]

Hi Fred,
I agree we should do a gui release as soon as possible - if I tested correctly, 
the latest gui release 0.20.0 doesn't work the the latest base, 1.23.0. I would 
like to get the changes you suggest in (font rewrite and filter services), but 
on the other hand, I think doing a release soon is more important - the font 
rewrite could be quite a lot of work -  and we can simply remove the 
ImageMagick and Ghostscript image reps for now.

As for the new cairo backend I added to back, we can either release with it or 
not. The resize flickering is definitely worse, but it supports some 16-bit 
configurations that were previously unsupported, and performs better over SSH.

btw, I have an experimental branch of back at 
svn+ssh://eri...@svn.gna.org/svn/gnustep/libs/back/branches/ericwa-experimental 
, which only supports x11 and cairo with the new surface. The goal is to try to 
clean up XGServerWindow/Event, and get rid of all legacy or magic code. So 
far I deleted a lot of code from XGServerWindow, deleted XWindowBuffer, and got 
rid of styleoffset support. One of the changes I made (I think in 
XGServerWindow ) got rid of the resize flickering, the only problem is, I'm not 
sure exactly what the change was. Anyway, it's encouraging, at least.

Cheers
Eric

On 2011-11-08, at 3:49 PM, Fred Kiefer wrote:

 For over a month I have been suggesting a new release of all GNUstep code 
 components (perhaps including Gorm as well), but got no reply at all. Many of 
 us have been pretty busy fixing the bugs Julian reported and there is still 
 plenty to do in this area. Anyway I would like to start a discussion about 
 this subject.
 
 After the last base release we did not make a gui/back release although some 
 of the changes in base wont work with an old version of gui. This means 
 anybody wanting to use GNUstep with a graphical user interface either has to 
 use a very old release of all components or use SVN. The later is especially 
 bad for distributions as they will have to ship an unclear state of the code.
 
 I will be away the first two weeks of December and would either like to see a 
 release before that or after, but wont be available for last minute bug fixes 
 during that period.
 There are a few changes to gui/back which I would like to see done before the 
 release. One is the conversion of the Ghostscript and the ImageMagick bitmap 
 implementations into filter services. The other is the integration of the 
 real cairo font interface (instead of the currently used toy fonts) as 
 prototyped in Opal. Is there anything important I did forget?
 
 It would be great if everybody could start to test its favourite application 
 to find out whether any of the recent changes introduced new issues. What are 
 the plans for GNUstep make and base? I think there have been enough changes 
 in base that warrant a new release and gui requires some of these changes. 
 For make there are a few open bug reports, maybe some of them could be fixed 
 for the release?
 
 Please remember that this will be the first GNUstep release that requires gcc 
 = 4.0. We decided so at the last base release and gui requires a current 
 base version.
 
 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 https://lists.gnu.org/mailman/listinfo/gnustep-dev


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Fred Kiefer]

To scale this discussion down a bit. The only thing that currently stops 
you from using an older version of gcc. Is the GCC_VERSION variable in 
the Version file of base. I am not aware of any specific change that 
would deliberately break older compilers. It is just that we don't 
officially support them any more. There is nothing stopping you to 
change that variable and try to use GNUstep with an older version of 
gcc. What we wont do is process bug reports that result out of such tests.


As for releasing gui and back for the last base release, we just missed 
the point to do so. It would have been possible right after the last 
base release, but now the code in gui is only tested with the SVN 
version of base and although I am again not aware of anything that 
changed in base that is required by gui, it is left to daring users to 
really test this. What we should aim for is to have a set of modules 
that work together. If the gui version also works well with an older 
base version, fine.


So far there has been only Riccardo's reply whether there should be a 
release at all. Those this mean we shouldn't do a shared release now? 
Then we could thing about just a gui/back release, which shoudl make 
Riccardo happy.


Fred

On 09.11.2011 14:15, Riccardo Mottola wrote:

Hi,

I don't remember about this and agreeing on that. We spoke about 2.95
because it had serious limitations and limited c99 compatibility which
was fine to drop and I agreed on that because the inconvenience of
maintaining it outweighed the benefits eventually.

I'd be against dropping 3.x support. What's the problem with 3.x vs.
4.x? 3.2 especially was essentially the second best portable option
after 2.95. Portability of gcc got quite worse after 3.4.

Given the past code in gnustep, I never had any problems with gcc3, the
only problems where with 2.95.

Riccardo

PS: additionally I think that the current gui and back release should
still be 2.95 compatible, they are the natural match for the past base
release. Especially since the past releases of gui and back are unusable
with current base. So a coehrent core should be released.

On 11/09/11 13:56, David Chisnall wrote:

On 9 Nov 2011, at 05:32, Gregory Casamento wrote:


As I remember it, we agreed on GCC 4.0 and later.

Yup, the rationale was that 2.9x - 3.x was where most of the
platforms were dropped. Excluding 3.x gives us a more modern compiler
with better language support and doesn't lose us any platforms. Pretty
much anything that might reasonably be expected to run GNUstep that
was supported by 3.x is also supported by 4.x.

David

-- Sent from my Apple II






___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

X style offset [Was: Next GNUstep release?]

[Fred Kiefer]

On 09.11.2011 20:05, Eric Wasylishen wrote:

I agree we should do a gui release as soon as possible - if I tested
correctly, the latest gui release 0.20.0 doesn't work the the latest
base, 1.23.0. I would like to get the changes you suggest in (font
rewrite and filter services), but on the other hand, I think doing a
release soon is more important - the font rewrite could be quite a
lot of work -  and we can simply remove the ImageMagick and
Ghostscript image reps for now.


That sounds like a reasonable plan.


As for the new cairo backend I added to back, we can either release
with it or not. The resize flickering is definitely worse, but it
supports some 16-bit configurations that were previously unsupported,
and performs better over SSH.


Not sure about this, on my machine the new surface works reasonable 
fast, although resize is a bit slower then before. But it may be 
different for other machines. We could, as long as we still have the 
code for XWindowBuffer in place, make this a runtime option?



btw, I have an experimental branch of back at
svn+ssh://eri...@svn.gna.org/svn/gnustep/libs/back/branches/ericwa-experimental
, which only supports x11 and cairo with the new surface. The goal is
to try to clean up XGServerWindow/Event, and get rid of all legacy or
magic code. So far I deleted a lot of code from XGServerWindow,
deleted XWindowBuffer, and got rid of styleoffset support. One of the
changes I made (I think in XGServerWindow ) got rid of the resize
flickering, the only problem is, I'm not sure exactly what the change
was. Anyway, it's encouraging, at least.


How does the interaction between GNUstep and X work without knowing the 
style offset? I think we needed that to position windows correctly. I 
will have a look at your branch soon.


Fred

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi,

this sounds good and sensible. I don't have any blocking issues with the 
new backend, I will do further tests this weekend though. Only under 
certain operationswe see flickering and this may be the hint for the 
slowdowns. (try a full-screen slide-show in LaternaMagica.. sometimes it 
evidently flickers)


Riccardo

Eric Wasylishen wrote:

Hi Fred,
I agree we should do a gui release as soon as possible - if I tested correctly, 
the latest gui release 0.20.0 doesn't work the the latest base, 1.23.0. I would 
like to get the changes you suggest in (font rewrite and filter services), but 
on the other hand, I think doing a release soon is more important - the font 
rewrite could be quite a lot of work -  and we can simply remove the 
ImageMagick and Ghostscript image reps for now.

As for the new cairo backend I added to back, we can either release with it or 
not. The resize flickering is definitely worse, but it supports some 16-bit 
configurations that were previously unsupported, and performs better over SSH.

btw, I have an experimental branch of back at 
svn+ssh://eri...@svn.gna.org/svn/gnustep/libs/back/branches/ericwa-experimental , which 
only supports x11 and cairo with the new surface. The goal is to try to clean up 
XGServerWindow/Event, and get rid of all legacy or magic code. So far I 
deleted a lot of code from XGServerWindow, deleted XWindowBuffer, and got rid of 
styleoffset support. One of the changes I made (I think in XGServerWindow ) got rid of 
the resize flickering, the only problem is, I'm not sure exactly what the change was. 
Anyway, it's encouraging, at least.

Cheers
Eric





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi,

Fred Kiefer wrote:

To scale this discussion down a bit. The only thing that currently stops
you from using an older version of gcc. Is the GCC_VERSION variable in
the Version file of base. I am not aware of any specific change that
would deliberately break older compilers. It is just that we don't
officially support them any more. There is nothing stopping you to
change that variable and try to use GNUstep with an older version of
gcc. What we wont do is process bug reports that result out of such tests.

Sounds fine. I shall do some builds.


As for releasing gui and back for the last base release, we just missed
the point to do so. It would have been possible right after the last
base release, but now the code in gui is only tested with the SVN
version of base and although I am again not aware of anything that
changed in base that is required by gui, it is left to daring users to
really test this. What we should aim for is to have a set of modules
that work together. If the gui version also works well with an older
base version, fine.

Well, but we didn't release back then... it becomes a bit inconsistent.
Perhaps we should do some tests against the past base release


So far there has been only Riccardo's reply whether there should be a
release at all. Those this mean we shouldn't do a shared release now?
Then we could thing about just a gui/back release, which shoudl make
Riccardo happy.
I do wonder indeed. Perhaps we are too busy arguing about gcc 
compatibility that we are missing the original point of the thread.


Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Next GNUstep release?

[Fred Kiefer]

For over a month I have been suggesting a new release of all GNUstep 
code components (perhaps including Gorm as well), but got no reply at 
all. Many of us have been pretty busy fixing the bugs Julian reported 
and there is still plenty to do in this area. Anyway I would like to 
start a discussion about this subject.


After the last base release we did not make a gui/back release although 
some of the changes in base wont work with an old version of gui. This 
means anybody wanting to use GNUstep with a graphical user interface 
either has to use a very old release of all components or use SVN. The 
later is especially bad for distributions as they will have to ship an 
unclear state of the code.


I will be away the first two weeks of December and would either like to 
see a release before that or after, but wont be available for last 
minute bug fixes during that period.
There are a few changes to gui/back which I would like to see done 
before the release. One is the conversion of the Ghostscript and the 
ImageMagick bitmap implementations into filter services. The other is 
the integration of the real cairo font interface (instead of the 
currently used toy fonts) as prototyped in Opal. Is there anything 
important I did forget?


It would be great if everybody could start to test its favourite 
application to find out whether any of the recent changes introduced new 
issues. What are the plans for GNUstep make and base? I think there have 
been enough changes in base that warrant a new release and gui requires 
some of these changes. For make there are a few open bug reports, maybe 
some of them could be fixed for the release?


Please remember that this will be the first GNUstep release that 
requires gcc = 4.0. We decided so at the last base release and gui 
requires a current base version.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi,

I think it is a good idea to release guiback. Things are piling up and 
diverging from base, so they are indeed needed. I am feeling some itches 
lately though, but they can surely be solved.


The new cairo surface usage is not prefect, but it is quite good, if 
some of the performance and flicker issues can be addressed, i should 
get definitively released.


gcc 4.0? that's a bit too much. We agreed to drop 2.95 for the need of 
better c99 support and macros, but not 3.x series AFAIR.


Riccardo

Fred Kiefer wrote:
For over a month I have been suggesting a new release of all GNUstep 
code components (perhaps including Gorm as well), but got no reply at 
all. Many of us have been pretty busy fixing the bugs Julian reported 
and there is still plenty to do in this area. Anyway I would like to 
start a discussion about this subject.


After the last base release we did not make a gui/back release 
although some of the changes in base wont work with an old version of 
gui. This means anybody wanting to use GNUstep with a graphical user 
interface either has to use a very old release of all components or 
use SVN. The later is especially bad for distributions as they will 
have to ship an unclear state of the code.


I will be away the first two weeks of December and would either like 
to see a release before that or after, but wont be available for last 
minute bug fixes during that period.
There are a few changes to gui/back which I would like to see done 
before the release. One is the conversion of the Ghostscript and the 
ImageMagick bitmap implementations into filter services. The other is 
the integration of the real cairo font interface (instead of the 
currently used toy fonts) as prototyped in Opal. Is there anything 
important I did forget?


It would be great if everybody could start to test its favourite 
application to find out whether any of the recent changes introduced 
new issues. What are the plans for GNUstep make and base? I think 
there have been enough changes in base that warrant a new release and 
gui requires some of these changes. For make there are a few open bug 
reports, maybe some of them could be fixed for the release?


Please remember that this will be the first GNUstep release that 
requires gcc = 4.0. We decided so at the last base release and gui 
requires a current base version.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

As I remember it, we agreed on GCC 4.0 and later.

On Tuesday, November 8, 2011, Riccardo Mottola r...@gnu.org wrote:
 Hi,

 I think it is a good idea to release guiback. Things are piling up and
diverging from base, so they are indeed needed. I am feeling some itches
lately though, but they can surely be solved.

 The new cairo surface usage is not prefect, but it is quite good, if some
of the performance and flicker issues can be addressed, i should get
definitively released.

 gcc 4.0? that's a bit too much. We agreed to drop 2.95 for the need of
better c99 support and macros, but not 3.x series AFAIR.

 Riccardo

 Fred Kiefer wrote:

 For over a month I have been suggesting a new release of all GNUstep
code components (perhaps including Gorm as well), but got no reply at all.
Many of us have been pretty busy fixing the bugs Julian reported and there
is still plenty to do in this area. Anyway I would like to start a
discussion about this subject.

 After the last base release we did not make a gui/back release although
some of the changes in base wont work with an old version of gui. This
means anybody wanting to use GNUstep with a graphical user interface either
has to use a very old release of all components or use SVN. The later is
especially bad for distributions as they will have to ship an unclear state
of the code.

 I will be away the first two weeks of December and would either like to
see a release before that or after, but wont be available for last minute
bug fixes during that period.
 There are a few changes to gui/back which I would like to see done
before the release. One is the conversion of the Ghostscript and the
ImageMagick bitmap implementations into filter services. The other is the
integration of the real cairo font interface (instead of the currently used
toy fonts) as prototyped in Opal. Is there anything important I did forget?

 It would be great if everybody could start to test its favourite
application to find out whether any of the recent changes introduced new
issues. What are the plans for GNUstep make and base? I think there have
been enough changes in base that warrant a new release and gui requires
some of these changes. For make there are a few open bug reports, maybe
some of them could be fixed for the release?

 Please remember that this will be the first GNUstep release that
requires gcc = 4.0. We decided so at the last base release and gui
requires a current base version.

 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 https://lists.gnu.org/mailman/listinfo/gnustep-dev


 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 https://lists.gnu.org/mailman/listinfo/gnustep-dev


-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release

[Gregory Casamento]

This sounds fine to me.

On Wed, Mar 9, 2011 at 3:37 AM, Richard Frith-Macdonald
rich...@tiptree.demon.co.uk wrote:

 On 7 Mar 2011, at 21:09, Fred Kiefer wrote:

 GNUstep base is making excellent progress in the moment, still I would
 suggest that we keep to our original plan of making a new release soon.

 Yes ... though I'm not sure exactly when soon is.  Certainly this month would 
 be good.

 For this we would need a few days of code freeze to allow for testing of
 a stable code base. What about having another week of happy hacking and
 then a week of bug fixes and a release in two weeks time?

 Sounds reasonable.
 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnustep-dev




-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release

[Richard Frith-Macdonald]

On 7 Mar 2011, at 21:09, Fred Kiefer wrote:

 GNUstep base is making excellent progress in the moment, still I would
 suggest that we keep to our original plan of making a new release soon.

Yes ... though I'm not sure exactly when soon is.  Certainly this month would 
be good.

 For this we would need a few days of code freeze to allow for testing of
 a stable code base. What about having another week of happy hacking and
 then a week of bug fixes and a release in two weeks time?

Sounds reasonable.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Next GNUstep release

[Fred Kiefer]

GNUstep base is making excellent progress in the moment, still I would
suggest that we keep to our original plan of making a new release soon.
For this we would need a few days of code freeze to allow for testing of
a stable code base. What about having another week of happy hacking and
then a week of bug fixes and a release in two weeks time?

Adam, would you be able to do the release in this time frame?

Fred

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release

[Adam Fedor]

On Mar 7, 2011, at 2:09 PM, Fred Kiefer wrote:

 GNUstep base is making excellent progress in the moment, still I would
 suggest that we keep to our original plan of making a new release soon.
 For this we would need a few days of code freeze to allow for testing of
 a stable code base. What about having another week of happy hacking and
 then a week of bug fixes and a release in two weeks time?
 
 Adam, would you be able to do the release in this time frame?
 
I could do it around April 1 (about three weeks).


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Fred Kiefer]

Richard made a final change that allows us to continue doing a gui/back
release. At least as far as I know, we have less known issues then for
previous releases.

Fred

Am 08.05.2010 18:22, schrieb Adam Fedor:
 I plan on making a release of make and base by tomorrow.  Please let me know 
 when I can make a release of gui/back as well.
 
 On May 4, 2010, at 9:50 AM, Gregory Casamento wrote:
 
 Fred,

 I'm still trying to reproduce it, but even so I don't believe it's a
 problem with GUI or anything that should stop the GUI release.

 Please proceed with the release.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Adam Fedor]

OK, I'll make a gui/back release early tomorrow.

On May 9, 2010, at 5:57 AM, Fred Kiefer wrote:

 Richard made a final change that allows us to continue doing a gui/back
 release. At least as far as I know, we have less known issues then for
 previous releases.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Fred Kiefer]

Great! Could everybody please stop committing to these two projects
until then?
I am planing to have another release of GNUstep gui this summer so don't
worry, any changes that didn't make it into this release wont be delayed
as long as they were this time.

To start planing for that next release early, here is my personal to-do
list:
- write more automatic test code for gui and get it to run on as many
different platforms as possible
- fix outstanding bugs
- continue to implement 10.5 functionality
- continue with the clean up of gui (perhaps of back too)
- make cairo the default backend

That next release wont be the big 1.0 release, but it should bring us
very close to that.

Fred

Am 09.05.2010 14:53, schrieb Adam Fedor:
 OK, I'll make a gui/back release early tomorrow.
 
 On May 9, 2010, at 5:57 AM, Fred Kiefer wrote:
 
 Richard made a final change that allows us to continue doing a gui/back
 release. At least as far as I know, we have less known issues then for
 previous releases.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Adam Fedor]

I plan on making a release of make and base by tomorrow.  Please let me know 
when I can make a release of gui/back as well.

On May 4, 2010, at 9:50 AM, Gregory Casamento wrote:

 Fred,
 
 I'm still trying to reproduce it, but even so I don't believe it's a
 problem with GUI or anything that should stop the GUI release.
 
 Please proceed with the release.
 
 GC



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Riccardo,

On Wed, May 5, 2010 at 6:51 PM, Riccardo Mottola mul...@ngi.it wrote:
 Hi,

 Fred Kiefer wrote:

 Thank you for the bug report. For me this isn't a show stopper for the
 next GNUstep release. It only affects Windows and mostly the WinUX theme. It
 may be a show stopper for that theme, but we already decided not to make it
 the default theme on Windows.

 Agreed, that theme should not be a showstopper, but the standard theme
 should work on windows as much as possible.

True.  For this release the WinUX theme is optional since it's
experimental as we previously discussed.

  From my side the only know open issue is still the Gorm segmentation
  fault I get from time to time. As Greg seems to be unable to reproduce 
  this,
  we should go ahead with the release despite of this problem. For GUI the
  current feature freeze is really hindering development.
 Does anybody disagree with that?

 No, but Greg should have the last word.

I informed Fred and the list that I believe this bug to be in Gorm.
It shouldn't effect our ability to do a GUI release at this time.

 Adam, do you think you could do the release this week?

 I'd very like the issue about NSToolbar crashing on SPARC being investigated
 abit, now that I have proven that it reproduces with the ToolbarExample and
 not only with Grr.

I agree that this should be investigated.  I'm wondering if this was
working in the previous release.  If so, then it's a regression and we
should fix it before the release is made.  If not, then we'll have to
decide whether to hold the release in order to fix it.

 Of course fixing the search field in the toolbar would be also very nice.

 Riccardo

Later, GC
-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi,


Fred Kiefer wrote:

Thank you for the bug report. For me this isn't a show stopper for the next 
GNUstep release. It only affects Windows and mostly the WinUX theme. It may be 
a show stopper for that theme, but we already decided not to make it the 
default theme on Windows.

   
Agreed, that theme should not be a showstopper, but the standard theme 
should work on windows as much as possible.

 From my side the only know open issue is still the Gorm segmentation fault I 
get from time to time. As Greg seems to be unable to reproduce this, we should go 
ahead with the release despite of this problem. For GUI the current feature freeze 
is really hindering development.
Does anybody disagree with that?

   

No, but Greg should have the last word.

Adam, do you think you could do the release this week?

   
I'd very like the issue about NSToolbar crashing on SPARC being 
investigated abit, now that I have proven that it reproduces with the 
ToolbarExample and not only with Grr.


Of course fixing the search field in the toolbar would be also very nice.

Riccardo


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Fred Kiefer]

Thank you for the bug report. For me this isn't a show stopper for the next 
GNUstep release. It only affects Windows and mostly the WinUX theme. It may be 
a show stopper for that theme, but we already decided not to make it the 
default theme on Windows.

From my side the only know open issue is still the Gorm segmentation fault I 
get from time to time. As Greg seems to be unable to reproduce this, we should 
go ahead with the release despite of this problem. For GUI the current feature 
freeze is really hindering development.
Does anybody disagree with that?

Adam, do you think you could do the release this week?

Fred


 Original-Nachricht 
 Datum: Tue, 4 May 2010 01:37:26 +0200
 Von: Lars Sonchocky-Helldorf lars.sonchocky-helld...@hamburg.de
 An: Gregory Casamento greg.casame...@gmail.com
 CC: Fred Kiefer fredkie...@gmx.de, GNUstep Developer gnustep-dev@gnu.org
 Betreff: Re: Next GNUstep release?

 Hi Gregory,
 
 I have entered the first (and most annoying) bug of Gorm on Windows  
 XP into the bugtracker:
 
 https://savannah.gnu.org/bugs/?29762
 
 that bug is not only somewhat show stopping but also somewhat  
 difficult to reproduce as it doesn't appear all the time. I can't  
 tell what circumstances make it appear and disappear, I tried at  
 least to narrow this down a little bit. Please let me know if you  
 can't reproduce it.
 
 During the next days I will enter some more bug which are less  
 severe. Most of them would fall into the category cosmetic but are  
 never the less important since they are clearly visible.
 
 
 cheers,
 
   Lars
 
 Am 01.05.2010 um 06:24 schrieb Gregory Casamento:
 
  Yes.
 
  On Friday, April 30, 2010, Lars Sonchocky-Helldorf
  lars.sonchocky-helld...@hamburg.de wrote:
 
  Am 30.04.2010 um 22:39 schrieb Gregory Casamento:
 
 
  Fred,
 
  On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer fredkie...@gmx.de  
  wrote:
 
  I think we should decide what to do with the planed GNUstep release.
 
  There hasn't been much progress over the last week. More bugs got
  reported than fixed over that time. We can either make a release now,
  with a lot of known issues, even some that weren't there a few weeks
  ago. Or delay the release indefinitely.
  Most of the newly reported bugs are for the Windows platform,  
  which we
  didn't support that well on previous releases. Even with all this  
  issues
  GNUstep is a lot more stable there then it used to be.
 
 
  Some of the problems which were reported are not new.  They've been
  there for a while, but are now better documented.
 
 
  I am currently testing Gorm on Windows with the Windows UX Theme a  
  little bit. Are you interested in bug reports on that?
 
  regards,
 
  Lars
 
 
  -- 
  Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
  yahoo/skype: greg_casamento, aol: gjcasa
  (240)274-9630 (Cell)
 
 
 
 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnustep-dev

-- 
GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Adam Fedor]

On May 4, 2010, at 2:44 AM, Fred Kiefer wrote:

 Thank you for the bug report. For me this isn't a show stopper for the next 
 GNUstep release. It only affects Windows and mostly the WinUX theme. It may 
 be a show stopper for that theme, but we already decided not to make it the 
 default theme on Windows.
 
 From my side the only know open issue is still the Gorm segmentation fault I 
 get from time to time. As Greg seems to be unable to reproduce this, we 
 should go ahead with the release despite of this problem. For GUI the current 
 feature freeze is really hindering development.
 Does anybody disagree with that?
 
 Adam, do you think you could do the release this week?
 
 Fred
 
 

Sure.  I will start getting ready for a release.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Fred,

I'm still trying to reproduce it, but even so I don't believe it's a
problem with GUI or anything that should stop the GUI release.

Please proceed with the release.

GC

On Tue, May 4, 2010 at 4:44 AM, Fred Kiefer fredkie...@gmx.de wrote:
 Thank you for the bug report. For me this isn't a show stopper for the next 
 GNUstep release. It only affects Windows and mostly the WinUX theme. It may 
 be a show stopper for that theme, but we already decided not to make it the 
 default theme on Windows.

 From my side the only know open issue is still the Gorm segmentation fault I 
 get from time to time. As Greg seems to be unable to reproduce this, we 
 should go ahead with the release despite of this problem. For GUI the current 
 feature freeze is really hindering development.
 Does anybody disagree with that?

 Adam, do you think you could do the release this week?

 Fred


  Original-Nachricht 
 Datum: Tue, 4 May 2010 01:37:26 +0200
 Von: Lars Sonchocky-Helldorf lars.sonchocky-helld...@hamburg.de
 An: Gregory Casamento greg.casame...@gmail.com
 CC: Fred Kiefer fredkie...@gmx.de, GNUstep Developer gnustep-dev@gnu.org
 Betreff: Re: Next GNUstep release?

 Hi Gregory,

 I have entered the first (and most annoying) bug of Gorm on Windows
 XP into the bugtracker:

 https://savannah.gnu.org/bugs/?29762

 that bug is not only somewhat show stopping but also somewhat
 difficult to reproduce as it doesn't appear all the time. I can't
 tell what circumstances make it appear and disappear, I tried at
 least to narrow this down a little bit. Please let me know if you
 can't reproduce it.

 During the next days I will enter some more bug which are less
 severe. Most of them would fall into the category cosmetic but are
 never the less important since they are clearly visible.


 cheers,

       Lars

 Am 01.05.2010 um 06:24 schrieb Gregory Casamento:

  Yes.
 
  On Friday, April 30, 2010, Lars Sonchocky-Helldorf
  lars.sonchocky-helld...@hamburg.de wrote:
 
  Am 30.04.2010 um 22:39 schrieb Gregory Casamento:
 
 
  Fred,
 
  On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer fredkie...@gmx.de
  wrote:
 
  I think we should decide what to do with the planed GNUstep release.
 
  There hasn't been much progress over the last week. More bugs got
  reported than fixed over that time. We can either make a release now,
  with a lot of known issues, even some that weren't there a few weeks
  ago. Or delay the release indefinitely.
  Most of the newly reported bugs are for the Windows platform,
  which we
  didn't support that well on previous releases. Even with all this
  issues
  GNUstep is a lot more stable there then it used to be.
 
 
  Some of the problems which were reported are not new.  They've been
  there for a while, but are now better documented.
 
 
  I am currently testing Gorm on Windows with the Windows UX Theme a
  little bit. Are you interested in bug reports on that?
 
  regards,
 
          Lars
 
 
  --
  Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
  yahoo/skype: greg_casamento, aol: gjcasa
  (240)274-9630 (Cell)



 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnustep-dev

 --
 GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!
 Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01




-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi,

If these exceptions were
  Uncaught exception NSInvalidArgumentException, reason: 
NSObject(class) does not recognize type
the issue is fixed now (the latest base changes had inadvertently made 
GSObjCAllSubclassesOfClass return all superclasses of the class).

The problem on Linux/x86 is now solved.

I will check the Linux/MIPS ass soon as possible.

Riccardi


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Wolfgang Lux]

Riccardo Mottola wrote:

On my laptop today I cannot start *any* application even after a  
full, clean build of core. On my letux Grr throws exceptions. On  
both machines things worked enough to be of daily use about 1-2  
months ago...


If these exceptions were
  Uncaught exception NSInvalidArgumentException, reason: NSObject 
(class) does not recognize type
the issue is fixed now (the latest base changes had inadvertently  
made GSObjCAllSubclassesOfClass return all superclasses of the class).


Wolfgang



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Fred,

I've been testing for a while with vairous nibs in Gorm since you made
the changes to nib loading and haven't found any ill effects.   Are
you aware of any issues I may have overlooked?

GC

On Fri, Apr 30, 2010 at 4:39 PM, Gregory Casamento
greg.casame...@gmail.com wrote:
 Fred,

 On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer fredkie...@gmx.de wrote:
 I think we should decide what to do with the planed GNUstep release.

 There hasn't been much progress over the last week. More bugs got
 reported than fixed over that time. We can either make a release now,
 with a lot of known issues, even some that weren't there a few weeks
 ago. Or delay the release indefinitely.
 Most of the newly reported bugs are for the Windows platform, which we
 didn't support that well on previous releases. Even with all this issues
 GNUstep is a lot more stable there then it used to be.

 Some of the problems which were reported are not new.  They've been
 there for a while, but are now better documented.

 Of all the other newly reported bugs (and I regard the bug tracker as
 the definite list here) only the one I found yesterday looks like a show
 stopper to me. If the NIB loading changes in gui really broke Gorm, then
 we have to fix that before a release. Greg, could you please look into
 this and give some feedback?

 I will look into the problems which have been reported and let you
 know this weekend (most likely tomorrow or Sunday sometime) what's
 going on.

 If we could get that one issue out of the way I am still all for a
 release. We should have had a release months ago.

 I agree.  We need a release ASAP.

 Fred

 GC
 --
 Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
 yahoo/skype: greg_casamento, aol: gjcasa
 (240)274-9630 (Cell)




-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Fred Kiefer]

I think we should decide what to do with the planed GNUstep release.

There hasn't been much progress over the last week. More bugs got
reported than fixed over that time. We can either make a release now,
with a lot of known issues, even some that weren't there a few weeks
ago. Or delay the release indefinitely.
Most of the newly reported bugs are for the Windows platform, which we
didn't support that well on previous releases. Even with all this issues
GNUstep is a lot more stable there then it used to be.

Of all the other newly reported bugs (and I regard the bug tracker as
the definite list here) only the one I found yesterday looks like a show
stopper to me. If the NIB loading changes in gui really broke Gorm, then
we have to fix that before a release. Greg, could you please look into
this and give some feedback?

If we could get that one issue out of the way I am still all for a
release. We should have had a release months ago.

Fred


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Fred,

On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer fredkie...@gmx.de wrote:
 I think we should decide what to do with the planed GNUstep release.

 There hasn't been much progress over the last week. More bugs got
 reported than fixed over that time. We can either make a release now,
 with a lot of known issues, even some that weren't there a few weeks
 ago. Or delay the release indefinitely.
 Most of the newly reported bugs are for the Windows platform, which we
 didn't support that well on previous releases. Even with all this issues
 GNUstep is a lot more stable there then it used to be.

Some of the problems which were reported are not new.  They've been
there for a while, but are now better documented.

 Of all the other newly reported bugs (and I regard the bug tracker as
 the definite list here) only the one I found yesterday looks like a show
 stopper to me. If the NIB loading changes in gui really broke Gorm, then
 we have to fix that before a release. Greg, could you please look into
 this and give some feedback?

I will look into the problems which have been reported and let you
know this weekend (most likely tomorrow or Sunday sometime) what's
going on.

 If we could get that one issue out of the way I am still all for a
 release. We should have had a release months ago.

I agree.  We need a release ASAP.

 Fred

GC
-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi,

There hasn't been much progress over the last week. More bugs got
reported than fixed over that time. We can either make a release now,
with a lot of known issues, even some that weren't there a few weeks
ago. Or delay the release indefinitely.
   
Not fixed doesn't mean that it is not important. Perhaps some persons 
did not have time? Or perhaps some persons were not able to understand 
and fix the problems they found (like in my case?)

Most of the newly reported bugs are for the Windows platform, which we
didn't support that well on previous releases. Even with all this issues
GNUstep is a lot more stable there then it used to be.
   

Agreed, but smoothing out some stuff here and there

On my laptop today I cannot start *any* application even after a full, 
clean build of core. On my letux Grr throws exceptions. On both machines 
things worked enough to be of daily use about 1-2 months ago...

Of all the other newly reported bugs (and I regard the bug tracker as
the definite list here) only the one I found yesterday looks like a show
stopper to me. If the NIB loading changes in gui really broke Gorm, then
we have to fix that before a release. Greg, could you please look into
this and give some feedback?

   

Ok, so I need to put the stuff I encounter on the bugtraker.

If we could get that one issue out of the way I am still all for a
release. We should have had a release months ago.
   

I'd love to have at least the toolbar issue resolved.
Windows is decent for me, except the big black GWorkspace issue.

I hope to gain more insight this Weekend, if not fixes, at least new 
information.


Riccardo


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Lars Sonchocky-Helldorf]

Am 30.04.2010 um 22:39 schrieb Gregory Casamento:


Fred,

On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer fredkie...@gmx.de  
wrote:

I think we should decide what to do with the planed GNUstep release.

There hasn't been much progress over the last week. More bugs got
reported than fixed over that time. We can either make a release now,
with a lot of known issues, even some that weren't there a few weeks
ago. Or delay the release indefinitely.
Most of the newly reported bugs are for the Windows platform,  
which we
didn't support that well on previous releases. Even with all this  
issues

GNUstep is a lot more stable there then it used to be.


Some of the problems which were reported are not new.  They've been
there for a while, but are now better documented.


I am currently testing Gorm on Windows with the Windows UX Theme a  
little bit. Are you interested in bug reports on that?


regards,

Lars


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Yes.

On Friday, April 30, 2010, Lars Sonchocky-Helldorf
lars.sonchocky-helld...@hamburg.de wrote:

 Am 30.04.2010 um 22:39 schrieb Gregory Casamento:


 Fred,

 On Fri, Apr 30, 2010 at 2:51 AM, Fred Kiefer fredkie...@gmx.de wrote:

 I think we should decide what to do with the planed GNUstep release.

 There hasn't been much progress over the last week. More bugs got
 reported than fixed over that time. We can either make a release now,
 with a lot of known issues, even some that weren't there a few weeks
 ago. Or delay the release indefinitely.
 Most of the newly reported bugs are for the Windows platform, which we
 didn't support that well on previous releases. Even with all this issues
 GNUstep is a lot more stable there then it used to be.


 Some of the problems which were reported are not new.  They've been
 there for a while, but are now better documented.


 I am currently testing Gorm on Windows with the Windows UX Theme a little 
 bit. Are you interested in bug reports on that?

 regards,

         Lars


-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[German Arias]

Gregory Casamento escribió:

An issue arises when the
app doesn't bring up a window by default.  I'm concerned that, if we
bring up a window/menu in the absence of a window that the framework
is making assumptions about what the developer wants.
  
I think the developer must decide whether to provide a separate window 
for the menu, or open a new document (if appli). As I said once before, 
this can be done in a method as applicationWillFinishLaunching: The 
problem with this of course, is to change the theme of an application 
when it is running. The user will need restart the app (or provide a new 
method to do this, and call this method when the theme change to one 
with menu in window).


Of course, this mean that some apps will need changes. But I think this 
is the way. Also, I think the user don't want a menu that appears and 
dissapears with the window's focus. Weeks ago Chris Armstrong sent a 
patch in bugtraker to fix this problem.




___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Wolfgang Lux]

Hi Fred!


Mhm, I already did all of that yesterday...

But there is more to do. We now need to change all the places where we
load NIB (or Gorm or XIB) files to free the top level objects. The  
code

is a lot cleaner now, but as far as memory leaks are concerned we are
almost back to square one. We now leak all the top level objects  
again :-(


I will try to solve this later today, but wouldn't mind if anybody  
beats

me on this before I come back from the cinema.


Not sure if there is a misunderstanding here. With respect to the  
(usual?) case where applications don't explicitly ask for the top  
level objects, my patch did not change anything. The patch only  
affected the case where applications explicitly ask for the top level  
objects and in that case it ensures that those objects are not  
released prematurely (at least compared to Cocoa). So unless you  
mixed in some other changes, I don't see what you want to fix here.


Wolfgang


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Fred Kiefer]

Am 29.03.2010 20:47, schrieb Fred Kiefer:
 But there is more to do. We now need to change all the places where we
 load NIB (or Gorm or XIB) files to free the top level objects. The code
 is a lot cleaner now, but as far as memory leaks are concerned we are
 almost back to square one. We now leak all the top level objects again :-(

Looks like I was wrong here. At least for the well behaved NIB/Gorm
files that come with GNUstep itself we don't leak the top level objects.
This may still be true for other NIB/Gorm files and we need to decide
what to do in this case.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Fred Kiefer]

Am 30.03.2010 08:45, schrieb Wolfgang Lux:
 Mhm, I already did all of that yesterday...

 But there is more to do. We now need to change all the places where we
 load NIB (or Gorm or XIB) files to free the top level objects. The code
 is a lot cleaner now, but as far as memory leaks are concerned we are
 almost back to square one. We now leak all the top level objects again
 :-(

 I will try to solve this later today, but wouldn't mind if anybody beats
 me on this before I come back from the cinema.
 
 Not sure if there is a misunderstanding here. With respect to the
 (usual?) case where applications don't explicitly ask for the top level
 objects, my patch did not change anything. The patch only affected the
 case where applications explicitly ask for the top level objects and in
 that case it ensures that those objects are not released prematurely (at
 least compared to Cocoa). So unless you mixed in some other changes, I
 don't see what you want to fix here.

You are right, this change did not make any difference for the case
where we don't provide an array for the top level objects. It just made
it clearer that in this case we might be leaking these objects.

Just imagine an NSDocument NIB file with plenty of top level objects
that go unhandled. What should we do in this case? Try to be clever in
our own NIB loading code? E.g. provide an array for the top level
objects and free them later on? Most likely this isn't what Cocoa is doing.

For the moment I think it is good enough to ignore the issue until it
shows up to be a real problem.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Wolfgang Lux]

Fred Kiefer wrote:


Just imagine an NSDocument NIB file with plenty of top level objects
that go unhandled. What should we do in this case? Try to be clever in
our own NIB loading code? E.g. provide an array for the top level
objects and free them later on? Most likely this isn't what Cocoa  
is doing.


The answer is simple: As Gregory already noted and is clearly stated  
in Apple's documentation, the owner of the nib file, i.e., the object  
which is loading the nib file, is responsible for releasing the top  
level objects. So the good news here is that (in general) it is not  
GNUstep's business to release those objects and no special magic is  
needed.


Now for the bad news: There is one case where a gui object becomes  
the owner of a nib and thus responsible for releasing the top level  
objects, namely when NSWindowController is loading a nib file.  
NSWindowController already has a _top_level_objects array attribute  
that probably is intended to hold the nib's top level objects, but  
this attribute at present is unused. In principle, a fresh array  
should be created when the nib file is loaded and filled with the  
nib's top level objects. Then, one could release those objects when  
the window is closed. However, since the window is one of the top  
level objects it looks like one must be careful to avoid  
overreleasing the window when it is set to release when closed, which  
happens to be the case in GNUstep when the window controller has an  
associated document.



For the moment I think it is good enough to ignore the issue until it
shows up to be a real problem.


After the first inspection of NSWindowController, it seems to me that  
the correct implementation requires some subtle changes to  
NSWindowController, so I guess this is better done after the upcoming  
release (unless somebody complains strongly about the space leak ...).


Wolfgang



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Riccardo,

On Mon, Mar 29, 2010 at 5:06 PM, Riccardo Mottola mul...@ngi.it wrote:
[ SNIP ]
 Although I generally agree with leaving the default theme as is on Unix,
 where we can theoretically strive for a complete environment, on Windows we
 always will be hosted, thus I consider it correct to have a more windows.
 friendly theme as the default on windows. I consider it an exception. Even
 when using a complete development environment you probably want that. Also,
 if you go as far as having several developer applications installed, you
 will be smart enough to be able to revert to the default theme if you wish.

I believe on Linux and other open source OS's it's up to the package
makers.   They should decide what themes to use based on their
judgement.

 A default theme however must guarantee that any application can be compiled
 and work well without any further porting efforts to adapt it. This is not
 the case with the current WinUXTheme, although it works very well for some
 applications.

This is easy to say, but very difficult to accomplish.

The most glaring difference between the Windows theme and the NeXT
theme is, of course, the floating menus.   An issue arises when the
app doesn't bring up a window by default.  I'm concerned that, if we
bring up a window/menu in the absence of a window that the framework
is making assumptions about what the developer wants.

 I think a good proposal would be, if possible, to make the WinUXTheme as a
 user-selectable component in the NSIS installer, however selecting it should
 write automatically the global preferences so that it will be enabled.

I'm not even sure if the NSIS installer supports this.

 In this release I would make it by default unselected and maybe the next
 release will have it selected by default.

If we don't release the Windows theme this time I would suggest we
hold the release on Windows until it's ready.

 I don't know however if the windows installer can be so smart to write the
 NSGlobalDomain when installing it?

Not sure.

 Riccardo

-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Hey guys...  Matt and I just talked via IM and he reminded me of a
really important point.

The functionality using proxies works fine on 32bit machines, but is
broken on 64 bit machines due to the fact that this bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700

has not seen release yet on most distros.   There is a patched version
of this library on our ftp site.

Should we turn off the NSImage proxy feature if it's on a 64bit system
for this release or, possibly, try to detect the version of libffi?

GC

On Mon, Mar 29, 2010 at 12:13 AM, Gregory Casamento
greg.casame...@gmail.com wrote:
 Actually, all of these work for me.

 If you're using the Windows Classic Theme these things will not show
 since you're not using UXTHEME.DLL since the Classic theme is
 *actually* the built in theme and the .DLL is ONLY used when you use
 something other than the built-in theme (confused yet).

 I'm guessing you were using the Windows Classic Theme.

 For me using the XP theme I get the picture that are on my website at:

 http://heronsperch.blogspot.com

 The issue with the Classic theme is something I'm going to correct this week.

 GC

 On Sun, Mar 28, 2010 at 11:51 PM, Matt Rice ratm...@gmail.com wrote:
 On Sat, Mar 27, 2010 at 3:48 PM, Adam Fedor fe...@qwestoffice.net wrote:

 On Mar 26, 2010, at 1:55 PM, Fred Kiefer wrote:

 Adam, could you once more take up the task of releasing GNUstep? We
 should give it another week or two so that people can complain about
 existing bugs that need to be fixed before the release.

 I'll help make a release whenever it's ready.


 So, i tried it out since theres a release on its way, I noticed 2 things,

 named images (aka system images) do not work, with any backend i've tried,
 so radio buttons, check boxes, tabs in tabviews, and knob things in
 outline views are all invisible.

 the attached patch is an ugly hack that should give you guys an idea
 of the problem.
 something is going in the image proxy code, I really don't understand
 what is so bad about having to restart an app to change the themes.

 the 'Images' button in Gorm in the main window shows no images,
 this last one is because gorm is using NSSystemDomainMask but they're
 being installed into NSLocalDomain GormCore/GormFunctions.m
 systemImagesList() and systemSoundsList() should probably now be using
 NSAllDomainsMask.

 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnustep-dev





 --
 Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
 yahoo/skype: greg_casamento, aol: gjcasa
 (240)274-9630 (Cell)




-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Matt Rice]

On Sun, Mar 28, 2010 at 11:37 PM, Gregory Casamento
greg.casame...@gmail.com wrote:
 Hey guys...  Matt and I just talked via IM and he reminded me of a
 really important point.

 The functionality using proxies works fine on 32bit machines, but is
 broken on 64 bit machines due to the fact that this bug:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700


named colors have this exact same issue and they were (haven't looked
in a while) able to change without resorting to using an NSProxy for
the color,

the idea was that NSView observes the change, sets itself as needing
redisplay, and views which cache colors are responsible to recache it,
or they will keep displaying the old color, or crash if they cached
and failed to retain it, this in my opinion works adequately.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Richard Frith-Macdonald]

On 29 Mar 2010, at 07:37, Gregory Casamento wrote:

 Hey guys...  Matt and I just talked via IM and he reminded me of a
 really important point.
 
 The functionality using proxies works fine on 32bit machines, but is
 broken on 64 bit machines due to the fact that this bug:
 
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700
 
 has not seen release yet on most distros.   There is a patched version
 of this library on our ftp site.

Actually it's the latest official release rather than a patched version.
.
 Should we turn off the NSImage proxy feature if it's on a 64bit system
 for this release or, possibly, try to detect the version of libffi?

That's a good idea ... we could perform the check for 64bit systems only, and 
insist on a working version ... after all broken ffi prevents a whole lot of 
things from working properly, producing obscure bugs anywhere that invocations 
are used ( NSUndoManager, NSConnection, NSTimer etc). 

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Nicola Pero]

On 26 Mar 2010, at 20:55, Fred Kiefer wrote:

Before FOSDEM we were planing a coordinated release of the GNUstep  
core

components. In the meantime a lot has happened. Base was completely
rewritten,


Is gnustep-base really ready for a release so shortly after a large  
rewrite ?


I assume we're talking of an unstable release ? ;-)

Thanks



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[David Chisnall]

On 29 Mar 2010, at 13:44, Nicola Pero wrote:

 On 26 Mar 2010, at 20:55, Fred Kiefer wrote:
 
 Before FOSDEM we were planing a coordinated release of the GNUstep core
 components. In the meantime a lot has happened. Base was completely
 rewritten,
 
 Is gnustep-base really ready for a release so shortly after a large rewrite ?
 
 I assume we're talking of an unstable release ? ;-)

Most of the 'rewriting' was really simplifying.  In terms of line count, I 
wouldn't be surprised if there is less code in base now than in the last stable 
release - although there's a lot more in terms of features.  

In particular, Richard has done a lot of work on the test suite, and many of 
the 'rewritten' parts were fixing bugs that the test suite found.  I've 
certainly found the svn base to be more reliable than nominally-stable base, 
and I think calling it an unstable release just means that no one uses it.  

David

-- Sent from my STANTEC-ZEBRA



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Nicola Pero]

Before FOSDEM we were planing a coordinated release of the GNUstep  
core

components. In the meantime a lot has happened. Base was completely
rewritten,


Is gnustep-base really ready for a release so shortly after a large  
rewrite ?


I assume we're talking of an unstable release ? ;-)


Most of the 'rewriting' was really simplifying.  In terms of line  
count, I wouldn't be surprised if there is less code in base now  
than in the last stable release - although there's a lot more in  
terms of features.


In particular, Richard has done a lot of work on the test suite, and  
many of the 'rewritten' parts were fixing bugs that the test suite  
found.  I've certainly found the svn base to be more reliable than  
nominally-stable base, and I think calling it an unstable release  
just means that no one uses it.


I'm not trying to downplay how great the new software is. :-)

I just wouldn't consider it well-tested yet.  Testing takes time.   
We're mostly relying on crowd-testing,
where we don't have much control over who is testing what.  We just  
hope that if we wait enough,
a good number of people will have tested it in various conditions and  
reported the problems they had.
I think it's worth waiting a month or two after a big rewrite before  
we can claim the software is stable. :-)


See, I wouldn't use the new gnustep-base on mission critical  
production servers myself for a few months
at least - I'm wondering if other people/users/companies would really  
want to ? ;-)


By the way, I don't have a strong opinion on this - if other people  
feel there has been enough testing,

you can make a stable release, I won't get offended or anything. :-)

Thanks


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Wolfgang...

The patch looks good.   Please go ahead and apply it and make the
change in GSNibLoading.m as well, if you wish.

Thanks, GC

On Sun, Mar 28, 2010 at 4:45 PM, Wolfgang Lux wolfgang@gmail.com wrote:
 Gregory Casamento wrote:

 Top level objects in the nib are the responsibility of the controller.
  That is to say that if you load a nib from MyController then any and
 all top level objects in that nib should be released by MyController
 when it deallocates itself.

 Indeed. What I tried to point out (but maybe failed to do properly) is that
 GNUstep does not implement this policy when the controller explicitly asks
 for the top level objects using the NS(Nib)TopLevelObjects key. If one uses
 that key, GNUstep passes ownership of the top level objects exclusively to
 the array that is used to return the objects and when the controller
 releases the top level objects, the application will crash. In fact, it is
 even documented in the code that GSNibLoading and GSGormLoading are
 implemented that way. However, this is incompatible with both Apple's
 documentation and implementation. Attached below is a patch to fix
 GSGormLoading. A similar change will be necessary in GSNibLoading.

 Wolfgang









-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Fred Kiefer]

Mhm, I already did all of that yesterday...

But there is more to do. We now need to change all the places where we
load NIB (or Gorm or XIB) files to free the top level objects. The code
is a lot cleaner now, but as far as memory leaks are concerned we are
almost back to square one. We now leak all the top level objects again :-(

I will try to solve this later today, but wouldn't mind if anybody beats
me on this before I come back from the cinema.

Fred

Am 29.03.2010 18:49, schrieb Gregory Casamento:
 Wolfgang...
 
 The patch looks good.   Please go ahead and apply it and make the
 change in GSNibLoading.m as well, if you wish.
 
 Thanks, GC
 
 On Sun, Mar 28, 2010 at 4:45 PM, Wolfgang Lux wolfgang@gmail.com wrote:
 Gregory Casamento wrote:

 Top level objects in the nib are the responsibility of the controller.
  That is to say that if you load a nib from MyController then any and
 all top level objects in that nib should be released by MyController
 when it deallocates itself.

 Indeed. What I tried to point out (but maybe failed to do properly) is that
 GNUstep does not implement this policy when the controller explicitly asks
 for the top level objects using the NS(Nib)TopLevelObjects key. If one uses
 that key, GNUstep passes ownership of the top level objects exclusively to
 the array that is used to return the objects and when the controller
 releases the top level objects, the application will crash. In fact, it is
 even documented in the code that GSNibLoading and GSGormLoading are
 implemented that way. However, this is incompatible with both Apple's
 documentation and implementation. Attached below is a patch to fix
 GSGormLoading. A similar change will be necessary in GSNibLoading.



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi

I haven't kept up with the state of development/readiness of the windows theme, 
but I really don't agree with forcibly changing the default theme ... I know it 
makes me really irate on the odd occasion when Apple change default behaviors 
on OSX, and I have to look for the  way to revert to previous behaviors.

The theme is the user's choice ... so what should happen is that, on 
installation, the installer should ASK the user which theme they want to use, 
allowing them to select between available themes, but making the windows one 
the first selection (assuming here that for most apps it works well ... people 
can always change theme on a per-app basis anyway).

If the user has already chosen a theme themselves (ie the default is already 
set in NSGlobalDomain) then the theme that they had previously chosen should be 
the first/default option when they are asked to choose a default theme  ... so 
they can just hit the return key to continue using the last theme they selected.
   
Although I generally agree with leaving the default theme as is on Unix, 
where we can theoretically strive for a complete environment, on Windows 
we always will be hosted, thus I consider it correct to have a more 
windows. friendly theme as the default on windows. I consider it an 
exception. Even when using a complete development environment you 
probably want that. Also, if you go as far as having several developer 
applications installed, you will be smart enough to be able to revert to 
the default theme if you wish.


A default theme however must guarantee that any application can be 
compiled and work well without any further porting efforts to adapt 
it. This is not the case with the current WinUXTheme, although it works 
very well for some applications.


I think a good proposal would be, if possible, to make the WinUXTheme as 
a user-selectable component in the NSIS installer, however selecting it 
should write automatically the global preferences so that it will be 
enabled.


In this release I would make it by default unselected and maybe the next 
release will have it selected by default.


I don't know however if the windows installer can be so smart to write 
the NSGlobalDomain when installing it?


Riccardo


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Richard Frith-Macdonald]

On 27 Mar 2010, at 22:33, Riccardo Mottola wrote:

 Hi,
 Additionally, for the Windows packages the default theme should be the
 WinUXTheme and not the NeXT theme on that system.
 
 
 Completely agree.
 
   
 I heartily disagree, even if I am the one that started working on it after 
 the hiatus of Christopher and Fred!
 I understand all the pressure Greg wants, but I still think it is not ready. 
 The apps he thinks about work, but not the one I want to release, one of 
 which I want to release well doesn't. If the application doesn't come up 
 with a main window, the menus have troubles, or if it doesn't open an 
 untitled document (same problem). Several others apps do work, but are very 
 ugly.
 
 
 Possible solutions were discussed, but none implemented yet.
 Also ideas about directly with the app plist were put on the table.
 
 Right now it is too early, I propose to ship it together with system 
 preferences, easy to enable, but not yet default.

I haven't kept up with the state of development/readiness of the windows theme, 
but I really don't agree with forcibly changing the default theme ... I know it 
makes me really irate on the odd occasion when Apple change default behaviors 
on OSX, and I have to look for the  way to revert to previous behaviors.

The theme is the user's choice ... so what should happen is that, on 
installation, the installer should ASK the user which theme they want to use, 
allowing them to select between available themes, but making the windows one 
the first selection (assuming here that for most apps it works well ... people 
can always change theme on a per-app basis anyway).

If the user has already chosen a theme themselves (ie the default is already 
set in NSGlobalDomain) then the theme that they had previously chosen should be 
the first/default option when they are asked to choose a default theme  ... so 
they can just hit the return key to continue using the last theme they selected.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Richard,

On Sun, Mar 28, 2010 at 9:18 AM, Richard Frith-Macdonald
rich...@tiptree.demon.co.uk wrote:
 I haven't kept up with the state of development/readiness of the windows 
 theme, but I really don't agree with forcibly changing the default theme ... 
 I know it makes me really irate on the odd occasion when Apple change default 
 behaviors on OSX, and I have to look for the  way to revert to previous 
 behaviors.

Most Windows users are not familiar with what NeXT was and many of the
things we use in the GNUstep default theme will be foreign to them.
The reason I'm proposing changing this is so that it blends in by
default without user intervention and things just behave like Windows
so that using GNUstep applications is pleasant for them from the
beginning.

As we all know GNUstep isn't widely used on Windows... aside from
stability (which is getting much better) I believe that the default
theme is on of the reasons why this is so.

 The theme is the user's choice ... so what should happen is that, on 
 installation, the installer should ASK the user which theme they want to use, 
 allowing them to select between available themes, but making the windows one 
 the first selection (assuming here that for most apps it works well ... 
 people can always change theme on a per-app basis anyway).

We would need to write this.  Is there a hook for the installer to
execute something?  I'm not sure how this is different from using
SystemPreferences to switch to the default theme after the
installation is done.  The user still has a choice between the
different themes, I'm just saying that we need to present the most
familiar face to them we can, which, on Windows, would be the Windows
theme. :)

 If the user has already chosen a theme themselves (ie the default is already 
 set in NSGlobalDomain) then the theme that they had previously chosen should 
 be the first/default option when they are asked to choose a default theme  
 ... so they can just hit the return key to continue using the last theme they 
 selected.

I agree with this part...  But I really don't think it should be part
of the installation.

 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnustep-dev




-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Wolfgang Lux]

Gregory Casamento wrote:


Top level objects in the nib are the responsibility of the controller.
 That is to say that if you load a nib from MyController then any and
all top level objects in that nib should be released by MyController
when it deallocates itself.


Indeed. What I tried to point out (but maybe failed to do properly)  
is that GNUstep does not implement this policy when the controller  
explicitly asks for the top level objects using the NS(Nib) 
TopLevelObjects key. If one uses that key, GNUstep passes ownership  
of the top level objects exclusively to the array that is used to  
return the objects and when the controller releases the top level  
objects, the application will crash. In fact, it is even documented  
in the code that GSNibLoading and GSGormLoading are implemented that  
way. However, this is incompatible with both Apple's documentation  
and implementation. Attached below is a patch to fix GSGormLoading. A  
similar change will be necessary in GSNibLoading.


Wolfgang



GSGormLoading.patch
Description: Binary data



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Matt Rice]

On Sat, Mar 27, 2010 at 3:48 PM, Adam Fedor fe...@qwestoffice.net wrote:

 On Mar 26, 2010, at 1:55 PM, Fred Kiefer wrote:

 Adam, could you once more take up the task of releasing GNUstep? We
 should give it another week or two so that people can complain about
 existing bugs that need to be fixed before the release.

 I'll help make a release whenever it's ready.


So, i tried it out since theres a release on its way, I noticed 2 things,

named images (aka system images) do not work, with any backend i've tried,
so radio buttons, check boxes, tabs in tabviews, and knob things in
outline views are all invisible.

the attached patch is an ugly hack that should give you guys an idea
of the problem.
something is going in the image proxy code, I really don't understand
what is so bad about having to restart an app to change the themes.

the 'Images' button in Gorm in the main window shows no images,
this last one is because gorm is using NSSystemDomainMask but they're
being installed into NSLocalDomain GormCore/GormFunctions.m
systemImagesList() and systemSoundsList() should probably now be using
NSAllDomainsMask.


foo.diff
Description: Binary data
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Gregory Casamento]

Actually, all of these work for me.

If you're using the Windows Classic Theme these things will not show
since you're not using UXTHEME.DLL since the Classic theme is
*actually* the built in theme and the .DLL is ONLY used when you use
something other than the built-in theme (confused yet).

I'm guessing you were using the Windows Classic Theme.

For me using the XP theme I get the picture that are on my website at:

http://heronsperch.blogspot.com

The issue with the Classic theme is something I'm going to correct this week.

GC

On Sun, Mar 28, 2010 at 11:51 PM, Matt Rice ratm...@gmail.com wrote:
 On Sat, Mar 27, 2010 at 3:48 PM, Adam Fedor fe...@qwestoffice.net wrote:

 On Mar 26, 2010, at 1:55 PM, Fred Kiefer wrote:

 Adam, could you once more take up the task of releasing GNUstep? We
 should give it another week or two so that people can complain about
 existing bugs that need to be fixed before the release.

 I'll help make a release whenever it's ready.


 So, i tried it out since theres a release on its way, I noticed 2 things,

 named images (aka system images) do not work, with any backend i've tried,
 so radio buttons, check boxes, tabs in tabviews, and knob things in
 outline views are all invisible.

 the attached patch is an ugly hack that should give you guys an idea
 of the problem.
 something is going in the image proxy code, I really don't understand
 what is so bad about having to restart an app to change the themes.

 the 'Images' button in Gorm in the main window shows no images,
 this last one is because gorm is using NSSystemDomainMask but they're
 being installed into NSLocalDomain GormCore/GormFunctions.m
 systemImagesList() and systemSoundsList() should probably now be using
 NSAllDomainsMask.

 ___
 Gnustep-dev mailing list
 Gnustep-dev@gnu.org
 http://lists.gnu.org/mailman/listinfo/gnustep-dev





-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Riccardo Mottola]

Hi,

yes I find it due, we spoke about that before Fosdem indeed! This time 
we should really stabilize ad decide that for a period of a fortnight 
(or longer if deemed needed) where only bugfixes are commited! Not 
changes to the runtime or other far-reaching things.

Also, fixes may produce bugs and need to be refixed.

The changes introduced were extremely huge and their effect is just now 
stabilizing.


Currently, the core systems compiles on most platforms I have available, 
spanning from gcc 2.95 to gcc 4.4 and from sparc to MIPS. Recently I 
even got GNU/Hurd compiling! Linux, FreeBSD, OpenBSD, Windows compile.

However, there are bugs and problems.

For example, I'm unable to start anything on Hurd because gdomap/gdnc 
seem to have problems.
GWorkspace crashes everywhere (which it didn't up to a month ago about). 
Also GWorkspace now has strange problems.


I think it would be also good to check our bug list and see if a couple 
of those bugs should be fixed with the release.


Given the recent surge of interest in Windows, I hope that Adam will 
also prepare a Windows release (I would suggest based on gcc/objc1, but 
possibly supporting clang/objc2 too). And let's make that a good release!


After this release, I'd like Richard release a new version of GSWS and I 
will release an application based on it to the public.


So let's check the details!

Riccardo


Fred Kiefer wrote:

Before FOSDEM we were planing a coordinated release of the GNUstep core
components. In the meantime a lot has happened. Base was completely
rewritten, or so it seems from the outside and gui had to play catch up.
Then I toyed around with the NIB loading and broke a few things.
Now things are rather stable again and we should come back to our
original plan. For gui this would be an intermediate release not the 1.0
release I am hoping to see later this year.
What still needs to be done in gui is finishing the switch to #import,
moving on to non fragile ivars will happen later. I first want to see
the results base gets with its approach to that topic.

Adam, could you once more take up the task of releasing GNUstep? We
should give it another week or two so that people can complain about
existing bugs that need to be fixed before the release.

   



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[Wolfgang Lux]

Fred Kiefer wrote:

Before FOSDEM we were planing a coordinated release of the GNUstep  
core

components. In the meantime a lot has happened. Base was completely
rewritten, or so it seems from the outside and gui had to play  
catch up.

Then I toyed around with the NIB loading and broke a few things.
Now things are rather stable again and we should come back to our
original plan. For gui this would be an intermediate release not  
the 1.0

release I am hoping to see later this year.
What still needs to be done in gui is finishing the switch to #import,
moving on to non fragile ivars will happen later. I first want to see
the results base gets with its approach to that topic.

Adam, could you once more take up the task of releasing GNUstep? We
should give it another week or two so that people can complain about
existing bugs that need to be fixed before the release.


Well, just for a start:

Rereading the Apple docs, I've noticed a (long-standing)  
incompatibility in the nib loading code. When one of the nib loading  
functions is called with an external name table and this dictionary  
contains the NS(Nib)TopLevelObjects key, GNUstep passes ownership of  
the top-level objects to the sender. However, this is not the case in  
Cocoa. Have a look at the Cocoa Resource Programming Guide and in  
particular the section Loading Nib Files into Your Program  
Programmatically (http://developer.apple.com/mac/library/ 
documentation/cocoa/Conceptual/LoadingResources/CocoaNibs/ 
CocoaNibs.html#//apple_ref/doc/uid/1051i-CH4-SW24). Try the  
example code from Listing 2-4 with your favorite nib/gorm file and  
you will observe a crash in GNUstep because the top-level objects are  
released once too often.


While testing this, I've also noticed that NSNib.h does not define  
the string constants NSNibOwner and NSNibTopLevelObjects, which were  
introduced together with NSNib in 10.3. Please note that Apple uses  
the values @NSOwner and @NSTopLevelObjects for these constants  
for backward compatibility. This is documented in Apple's NSNib.h  
header file, but I couldn't find it in the online docs. I guess  
following Apple's approach would simplify the nib loading code in a  
few places.


Wolfgang





___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Next GNUstep release?

[David Chisnall]

On 26 Mar 2010, at 19:55, Fred Kiefer wrote:

 What still needs to be done in gui is finishing the switch to #import,
 moving on to non fragile ivars will happen later. I first want to see
 the results base gets with its approach to that topic.

I made some small changes in -gui last night that remove the uses of @defs, 
making it compatible with the non-fragile ABI.  You can now compile -base and 
-gui with the non-fragile ABI.  I've not tried -back yet, but I think it should 
work too.  

David

-- Sent from my STANTEC-ZEBRA

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev