ANNOUNCE: NextSpace 0.95

[Sergii Stoian]

Hello everyone!

I'm pleased to announce the new NextSpace release - 0.95.
This release introduces:

   - Numerous of bugfixes across the entire project;
   - Serious reengineering of Workspace and Window Manager including:
   - switch to Apple's CoreFoundation for internal data structures;
   - event handling of Window Manager was implemented with CFRunLoop,
   CFFileDescriptor and CFNotificationCenter;
   - use XML for configuration files;
   - implemented notification interoperability between Objective C and C
   (external GNUstep applications may send notifications to Window Manager);
   - improved drag and drop between File Viewer and Dock;
   - implemented Cut/Copy/Paste operations for files and directories.
   - Feature completion of Terminal application, including:
   - unlimited scrollback buffer support;
   - process tracking (Activity Monitor), display running program in
   titlebar;
   - miniwindow animation representing activity in minimized window;
   - automatic hide/show of mouse cursor.
   - Workspace tracks for applications and services installation/removal,
   updates files in ~/Library/Services;
   - Greatly improved scripts to build and install project from sources -
   tested on Fedora, Ubuntu 22 and Debian 12.

Look into changelog
<https://github.com/trunkmaster/nextspace/blob/master/Documentation/Changelog-0.95.md>
for details.

This release was built for 3 distributions of RedHat family: CentOS 7,
Debian 12, Ubuntu 22.04, Fedora 39. Download it from:
https://github.com/trunkmaster/nextspace/releases/tag/0.95
-- 
Sergii Stoian,
NEXTSPACE owner, lead developer

Re: GNUstep releases this month?

[Sergii Stoian]

Hi,

> On Jan 19, 2021, at 19:29, Ivan Vučica  wrote:
> 
> On Tue, Jan 19, 2021 at 11:26 AM Riccardo Mottola
>  wrote:
>> my only "itch" which would be a regression is the bug of the icon, the
>> stuff Sergeii did...
> 
> Can you clarify this? What action needs to be taken before the
> release? Can you link to the bug so I can understand this better?

The issue is here https://github.com/gnustep/libs-back/issues/30 
.
I can revert changes if it's necessary.

Sergii

Re: windowmaker - application icon missing at first start

[Sergii Stoian]

Hi Wolfgang,

> On Oct 18, 2020, at 14:38, Wolfgang Lux  wrote:
> 
> Hi Sergii,
>> 
>> 
>> Hi,
>> 
>>> On Oct 17, 2020, at 00:27, Wolfgang Lux  wrote:
>>> 
>>> Hi Riccardo,
>>> 
 I noticed we recently have a strange behaviour, which is slightly
 different from setup (= installation on different computers) to setup I 
 have
 
 The first time I start a GNUstep application with windowmaker (I mean
 the first GNUstep app started ever after X11 start essentially) it has a
 bad icon.
 - on some setup it has a "generic" icon by windowmaker
 - on other setups it has a black looking icon, as only the "mask" of the
 icon, the contours are drawn
>> 
>> Riccardo, could you please provide more info on your specific setups?
>> Do you have “UseWindowMakerIcons” set to “NO” in NSGlobalDomain?
>> 
 
 A restart of the app and then starting any other app, fixes that.
 
 
 This was not happening before.
>>> 
>>> Actually, this has been happening before, but it was fixed about five years 
>>> ago in this commit:
>>> https://github.com/gnustep/libs-back/commit/1e1185abb364f2ffcb5f06f62c1241d419b8b697#diff-c3c9abc7461037f8abf3f590d909cff84c39bc7817b79d7dfd379b38a3756385
>>> 
 I think it is related to at least this
 commit - merge:
 
 https://github.com/mozilla/newtab-dev/raw/6be44da368fb869a3d3e1975f515857352a7d9fc/browser/modules/ProcessHangMonitor.jsm
>>> 
>>> I assume you meant this commit instead
>>> https://github.com/gnustep/libs-back/commit/31b7c4ed2f8efa0127605511aaf4eafef6a3d1c8
>>> And, yes, your suspicion is correct because it exactly comments out the 
>>> earlier fix.
>> 
>> As stated in description to this commit it fixes flickering of appicon at 
>> application start. Quote: “This fix based on the fact that root application 
>> window (ROOT) is mapped in `-orderwindow:::` and this is the event of 
>> application recognition by WindowMaker because it is a first application 
>> window that is mapped.”. That "root application window" is called “group 
>> leader” and saved in every application window structure (WWindow) member 
>> `main_window` inside WM. It holds all required properties to be detected by 
>> WM correctly.
>> 
>> The earlier fix probably masks other unknown problem. My WindowMaker 0.95.7 
>> default configuration tests work like a charm.
>> Wolfgang, do you observe the same behaviour as Riccardo? I yes, could you 
>> please share your setup?
> 
> Sorry, I haven't been using WindowMaker for a while so I can't really 
> contribute anything
> here. However, I can perhaps try to better explain the rationale for the fix. 
> Normally,
> WindowMaker manages the app icon and the menu on the app icon itself. 
> However, it does
> allow GNUstep applications to override that app icon by supplying those on 
> the app icon
> windows. The problem here is that this works only if the app icon is the 
> first window which
> is opened by the GNUstep application. This is not a problem in general, as 
> the first window
> opened by gnustep-gui is the app icon. However, for the very first 
> application in an X11
> session, gnustep-back wants to determine the frame offsets and it does so by 
> opening a set
> of off-screen windows in the _checkStyle: method, which is called from 
> setupRootWindow.
> The important point here is that these windows are created *before* the app 
> icon window is
> created in the -window method. And at the point where the first auxiliary 
> window is
> created WindowMaker creates an app icon for our application itself. Our 
> attempts to set the
> icon and menu through the app icon window created by the -window method 
> then go to the
> wrong window are ignored by WindowMaker. The fix I had committed simply 
> attempts to make
> sure that our app icon window is created before the auxiliary windows. If you 
> see a flickering
> here, you might attempt to improve the fix by creating the app icon only when 
> the backend
> is actually going to call _checkStyle: and create any auxiliary windows.
> 
> Note that in a normal configuration the issue applies only to the first 
> application started
> in an X11 Session, but you can set the default GSIgnoreRootOffsets to YES to 
> have the backend
> determine the frame offsets for every application.
> 
> Hope this helps,
> Wolfgang

Thank you for excellent explanation. You’re absolutely right about _checkStyle: 
- I forgot about it since I’ve created a PR.
Although probably code was changed and it works slightly different now. 
_checkStyle: method is called from _setupRootWindow 
only if GSBackHandlesWindowDecorations is set to YES. At least now I understand 
what we should check in Riccardo's setup.

Riccardo, do you have GSBackHandlesWindowDecorations set to YES?

Sergii

Re: windowmaker - application icon missing at first start

[Sergii Stoian]

Hi,

> On Oct 17, 2020, at 00:27, Wolfgang Lux  wrote:
> 
> Hi Riccardo,
> 
>> I noticed we recently have a strange behaviour, which is slightly
>> different from setup (= installation on different computers) to setup I have
>> 
>> The first time I start a GNUstep application with windowmaker (I mean
>> the first GNUstep app started ever after X11 start essentially) it has a
>> bad icon.
>> - on some setup it has a "generic" icon by windowmaker
>> - on other setups it has a black looking icon, as only the "mask" of the
>> icon, the contours are drawn

Riccardo, could you please provide more info on your specific setups?
Do you have “UseWindowMakerIcons” set to “NO” in NSGlobalDomain?

>> 
>> A restart of the app and then starting any other app, fixes that.
>> 
>> 
>> This was not happening before.
> 
> Actually, this has been happening before, but it was fixed about five years 
> ago in this commit:
>  
> https://github.com/gnustep/libs-back/commit/1e1185abb364f2ffcb5f06f62c1241d419b8b697#diff-c3c9abc7461037f8abf3f590d909cff84c39bc7817b79d7dfd379b38a3756385
> 
>> I think it is related to at least this
>> commit - merge:
>> 
>> https://github.com/mozilla/newtab-dev/raw/6be44da368fb869a3d3e1975f515857352a7d9fc/browser/modules/ProcessHangMonitor.jsm
> 
> I assume you meant this commit instead
>  
> https://github.com/gnustep/libs-back/commit/31b7c4ed2f8efa0127605511aaf4eafef6a3d1c8
> And, yes, your suspicion is correct because it exactly comments out the 
> earlier fix.

As stated in description to this commit it fixes flickering of appicon at 
application start. Quote: “This fix based on the fact that root application 
window (ROOT) is mapped in `-orderwindow:::` and this is the event of 
application recognition by WindowMaker because it is a first application window 
that is mapped.”. That "root application window" is called “group leader” and 
saved in every application window structure (WWindow) member `main_window` 
inside WM. It holds all required properties to be detected by WM correctly.

The earlier fix probably masks other unknown problem. My WindowMaker 0.95.7 
default configuration tests work like a charm.
Wolfgang, do you observe the same behaviour as Riccardo? I yes, could you 
please share your setup?

> Wolfgang
> 
> 

Sergii

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

[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  <mailto:fredkie...@gmx.de>> 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: Multimonitor support

[Sergii Stoian]

On Thu, Feb 20, 2020 at 12:35 PM Johannes Brakensiek <
johan...@brakensiek.info> wrote:

> Hello,
>
> Am 18.02.20 um 23:42 schrieb Sergii Stoian:
> > Thank you for your report. I understand where problem is. I’ll look into
> it.
>
> I'd like to thank Sergii for his great work and his support.
>
> We looked into it and it was my fault as I missed to install
> libxrandr-dev as an additional dependency for this feature under Ubuntu.
>
> Once I installed this before compiling libs-back, the new features
> applied quite well. We're going to look into minor issues I think.
>
> Lot's of thanks again to Sergii!
> Johannes
>

Thank you for your report and kind words, Johannes.

I plan to fix some more bugs in -back and -gui related to the topic:
- get Xlib screen from root window - DisplayHeight/DisplayWidth usage is
not correct and returns old values when monitor layout changes;
- dynamic change of appicon (for non-WindowMaker users) and horizontal menu
position;
- fix position/centering of windows.

Sergii

Re: Multimonitor support

[Sergii Stoian]

Hi,

> On 19 Feb 2020, at 00:23, Johannes Brakensiek  
> wrote:
> 
> Hello,
> 
> Am 08.02.20 um 16:09 schrieb Fred Kiefer:
>> lease feel free to test what did improve for your laptop setup.
>> As I wrote we expect that this get better for everybody. Maybe after a short 
>> hiccup phase in the beginning. I already had to commit a small fix for 
>> Sergii’s changes. But as I don’t have a multi monitor setup, I won’t see any 
>> of the benefits.
>> What should be tested now is for example centering a window on a screen. 
>> This should only take the current monitor into account not the complete 
>> virtual screen.
> 
> I was really looking forward for these changes and wanted to test them.
> 
> I don't know if this is the right place to report issues, but for me multi 
> monitor support seems to not work as expected.
> 
> I compiled and installed libs-gui and libs-back from latest git master.
> 
> I have a second screen on the right of my main screen. This screen is smaller 
> than the main screen and it is positioned a little below the main screen.
> 
> When I open an app, GWorkspace fe., the app icon is placed outside of the 
> view of the main screen (due to the fact that the virtual screen is a little 
> bit greater because the second screen is placed below the first). This just 
> behaves as I was used to it: When I place both screens at the same level next 
> to each other the app icon is shown.
> 
> The same happens to the app menu when you use macOS menu style. If the left 
> screen is placed lower than the right screen I won't see the parts of the 
> menu which contain the clickable items, because they are placed outside of 
> the view of the left screen.
> 
> Same applies to dialogs (fe. when I quit GWorkspace): They are not centered 
> in relation to the sizes of the current monitor but are placed far right - at 
> the center of the virtual screen.
> 
> Is there anything I have to do to make the new changes take effect?
> 
> I'm using Ubuntu Mate 19.10.
> 
> $ X -version
> 
> X.Org X Server 1.20.5
> X Protocol Version 11, Revision 0
> Build Operating System: Linux 4.4.0-165-generic x86_64 Ubuntu
> Current Operating System: Linux 5.3.0-29-generic #31-Ubuntu SMP Fri Jan 17 
> 17:27:26 UTC 2020 x86_64
> Kernel command line: BOOT_IMAGE=/vmlinuz-5.3.0-29-generic 
> processor.max_cstate=2 vt.handoff=7
> Build Date: 08 October 2019  09:43:30AM
> xorg-server 2:1.20.5+git20191008-0ubuntu1 (For technical support please see 
> http://www.ubuntu.com/support)
> Current version of pixman: 0.38.4
> 
> Thank you for your support
> Johannes
> 

Thank you for your report. I understand where problem is. I’ll look into it.

Sergii

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: Multimonitor support

[Sergii Stoian]

> On Feb 8, 2020, at 16:20, Riccardo Mottola  wrote:
> 
> Hi Fred!
> 
> On 03/02/2020 21:15, Fred Kiefer wrote:
>> Sergii has written a great patch that will tremendously improve support for 
>> multiple monitors in GNUstep by using the XRandR extension. There is a 
>> downside to it though, this patch will also remove any multi screen support 
>> that was there before without XRandR. So if you have a multi monitor setup 
>> and your system won’t support XRandR we would like to hear from you and try 
>> to find a solution that is acceptable for all sides. I hope that there is 
>> nobody in this specific situation but it seems easier to ask in advance than 
>> to fix it later.
> 
> 
> Sounds great.
> 
> First question - this refers only to X11, right? Multi-Monitor support (or 
> lack of) under windows are unaffected?

Yes, it’s relevant only to the X11.

> Second question - what was there "before" which would stop working, so which 
> multi-monitor support is "left out" ? A setup to test it.

Old code supports multiple monitors in pre-XRandR fashion (static, see my 
previous mail). Current implementation support dynamic change of monitors 
parameters and layout.

> Currently I use GNUstep and multi-monitor only in a setup with a Laptop + 
> external screen, which means usually a relatively recent OS. Randr 1.2 has 
> been around almost 10 years. If we don't require more modern features, I 
> probably won't hit these limits. A laptop without xrandr is hard to sue, 
> since only with it the external monitor can be dynamically added/removed.
> 
> My more "esoteric" machines are single-monitor setups. Solaris 7 with two 
> Monitors would be a setup? I don't have setups like that.
> 
> 
> Riccardo
> 

Sergii

Re: crash when using local display but not remote

[Sergii Stoian]

> On Feb 4, 2020, at 20:43, Fred Kiefer  wrote:
> 
> 
> 
>> Am 04.02.2020 um 11:21 schrieb Sergii Stoian :
>> 
>> 
>> On Mon, Feb 3, 2020 at 8:59 AM Fred Kiefer  wrote:
>> 
>>> Am 03.02.2020 um 00:53 schrieb Sergii Stoian :
>>> 
>>> On Mon, Feb 3, 2020 at 1:05 AM Fred Kiefer  wrote:
>>> 
>>> I just ran a quick scan with valgrind and this did not detect any obvious 
>>> wrong memory access. Looking at the code once again I see that line 4276 
>>> may be wrong for certain bytesPerRow values. Here the old code that copied 
>>> over line by line is safer. Maybe we could check bytesPerRow versus 
>>> pixelsWide*4 and use the old code if they are not the same?
>>> 
>>> Line 4276 looks like this: "xcursorImage->yhot = hotp.y;" Do you mean 
>>> memcpy call at 4279?
>> 
>> Yes, it was line 4276 in the original merge commit, but has changed since 
>> then.
>> 
>> Could you please explain why old code is safer?
>> 
>> Old code:
>> for (row = 0; row < h; row++)
>>  {
>>memcpy((char*)xcursorImage->pixels + (row * (w * 4)),
>>   data + (row * bytesPerRow),
>>   bytesPerRow);
>>  }
>> 
>> New code:
>> 
>> memcpy((char*)xcursorImage->pixels, data, w * h * colors);
> 
> 
> In general it is safer as the new code expects that the image is fully 
> packed. (You moved the comment with the conversion from unpacked to packed 
> over to the swap function) If bytesPerRow is not equal to w * 4 (there may be 
> a few extra bytes to align stuff a bit), then the new code would not transfer 
> the correct data.  We would end up with random garbage in between. But in 
> this special case the image comes from GSStandardImage and at least for the 
> case where there are alpha values that function should already return a 
> packed image. Thinking about it the old code should only have copied w * 4 
> bytes for each row. The old code could have written a few bytes past the 
> pixels array.

Clear explanation, thank you. It is a usual case when image contains more bytes 
than image size (width * height)?
I feel we need to return back old code with your explanation in comment.
What do you think?

Sergii

Re: Cairo backend seems broken - mainScreen visibleFrame has no size

[Sergii Stoian]

Hi Riccardo,

On Sun, Feb 2, 2020 at 11:18 PM Sergii Stoian  wrote:

> Hi,
>
> On Feb 2, 2020, at 17:44, Riccardo Mottola 
> wrote:
>
> Hi!
> On 2/1/20 11:32 PM, Sergii Stoian wrote:
>
>
>> Yes it helps! now applications start both locally and remotely
>>
>> I got only one kind of error now and only once a the first start of Ink.
>> starting it again, no error, so I do wonder and will keep an eye on it
>> and also test on other computers.
>>
>
> Good. I've done testing myself and found more flows in current
> implementation.
> I start working on solution and almost done. You can find more fixes in
> 'randr' branch of libs-back.
>
>
> I fear the latest changes made window opening slower, I tested also on
> good and up-to-date computers with fine video card.
>
> What do you mean by “opening slower”? Timeout between user action (click,
> key equivalent press) and window appearing?
> Window is drawn slowly on first appear?
>

No further explanation needed. Yesterday I've faced the same problem and
fixed that.


>
>
>> no more X-Windows errors.
>>
>> > Out of curiosity, do you have XRandR enabled and it's not working?
>> > What is the Xorg log messages about it?
>>
>> How can I know? xome option to the "xrandr" command?
>>
>
> Do you observe some good "xrandr" output?
>
>
> in the sense that it reports correct screen size? then yes.
>
> It is true both for local as remote displays.
>
> As I already wrote - I know what the cause of a problem. I’ve almost
> completed new implementation.
> Please wait for commits in ‘randr’ branch.
>
> Riccardo
>
> I've found cause of a problem and fixed that. Could you please try te
lastest code in `randr` branch?

-- 
Sergii Stoian

Re: crash when using local display but not remote

[Sergii Stoian]

On Mon, Feb 3, 2020 at 8:59 AM Fred Kiefer  wrote:

>
> > Am 03.02.2020 um 00:53 schrieb Sergii Stoian :
> >
> > On Mon, Feb 3, 2020 at 1:05 AM Fred Kiefer  wrote:
> >
> > I just ran a quick scan with valgrind and this did not detect any
> obvious wrong memory access. Looking at the code once again I see that line
> 4276 may be wrong for certain bytesPerRow values. Here the old code that
> copied over line by line is safer. Maybe we could check bytesPerRow versus
> pixelsWide*4 and use the old code if they are not the same?
> >
> > Line 4276 looks like this: "xcursorImage->yhot = hotp.y;" Do you mean
> memcpy call at 4279?
>
> Yes, it was line 4276 in the original merge commit, but has changed since
> then.
>

Could you please explain why old code is safer?

Old code:
for (row = 0; row < h; row++)
  {
memcpy((char*)xcursorImage->pixels + (row * (w * 4)),
   data + (row * bytesPerRow),
   bytesPerRow);
  }

New code:

memcpy((char*)xcursorImage->pixels, data, w * h * colors);

-- 
Sergii Stoian

Re: Multimonitor support

[Sergii Stoian]

> On Feb 3, 2020, at 22:15, Fred Kiefer  wrote:
> 
> Dear GNUstepper,
> 
> Sergii has written a great patch that will tremendously improve support for 
> multiple monitors in GNUstep by using the XRandR extension. There is a 
> downside to it though, this patch will also remove any multi screen support 
> that was there before without XRandR. So if you have a multi monitor setup 
> and your system won’t support XRandR we would like to hear from you and try 
> to find a solution that is acceptable for all sides. I hope that there is 
> nobody in this specific situation but it seems easier to ask in advance than 
> to fix it later.
> 
> Cheers
> Fred 

Thank you, Fred.

I want to add couple of words about background of this patch.

I think current support of multiple screens was written in good old days 
(XFree86) when each physical monitor get its own screen ID.
At some point in time Xinerama extension has appeared. It added ability to join 
several monitors into virtual screen. Xinerama has no ability to dynamically 
change screen resolution (pixel dimension) only via the X server configuration 
and restart.
Finally XRandR extension was added to Xorg. It has plenty of possibilities for 
manipulating monitors: dynamic change of monitor resolution, position in 
virtual screen, monitor switch on/off, connect/disconnect etc.

My patch adds XRandR support to GNUstep that brings new capabilities of modern 
framework.

Sergii

Re: crash when using local display but not remote

[Sergii Stoian]

Fred,

On Mon, Feb 3, 2020 at 1:05 AM Fred Kiefer  wrote:

>
> > Am 02.02.2020 um 21:38 schrieb Riccardo Mottola <
> riccardo.mott...@libero.it>:
> >
> > On 1/28/20 11:28 AM, Sergii Stoian wrote:
> >>
> >> I'm not sure, just an idea: this problem may have relation to enabled
> multithreading in X11. Probably due to outdated X server.
> >> Could you please try to comment out line in x11/XGServer.m that
> contains XInitThreads() (line 419) and recompile/reinstall backend?
> >
> >
> > I was able to restrict the offending breakage.
> >
> > As of 14 September (version bump) everything worked fine on the Letux400
> MIPS-LE
> >
> > As of 13 January it is already broken
> >
> > As of 14 January it is still broken giving the memory error on startup.
> (I include obviously the minor ALPHA_THRESHOLD fix)
> >
> >
> > I'm a little bit confused with the commits of 13th and 14th January,
> since they seem to contain similar things!
>
> These are all different commits that belong to the same pull request and
> at the end the branch gets merged. What you see are the single commits plus
> the final merge.
>
> > Somehow, however in the "fixes" for the icon there appears to be a
> memory issue!
>
> This is really hard to tell. Do you have a stack trace or any other
> analysis of the issue? Perhaps scattering log statements in the changed
> functions might help to narrow it down a bit.
>
> I just ran a quick scan with valgrind and this did not detect any obvious
> wrong memory access. Looking at the code once again I see that line 4276
> may be wrong for certain bytesPerRow values. Here the old code that copied
> over line by line is safer. Maybe we could check bytesPerRow versus
> pixelsWide*4 and use the old code if they are not the same?
>

Line 4276 looks like this: "xcursorImage->yhot = hotp.y;" Do you mean
memcpy call at 4279?


> But there are also other possible causes. If your old Letux uses indexed
> colours the old code for _createAppIconPixmaps would be required.
>

-- 
Sergii Stoian

Re: Cairo backend seems broken - mainScreen visibleFrame has no size

[Sergii Stoian]

Hi,

> On Feb 2, 2020, at 17:44, Riccardo Mottola  wrote:
> 
> Hi!
> 
> On 2/1/20 11:32 PM, Sergii Stoian wrote:
>> 
>> Yes it helps! now applications start both locally and remotely
>> 
>> I got only one kind of error now and only once a the first start of Ink. 
>> starting it again, no error, so I do wonder and will keep an eye on it 
>> and also test on other computers.
>> 
>> Good. I've done testing myself and found more flows in current 
>> implementation.
>> I start working on solution and almost done. You can find more fixes in 
>> 'randr' branch of libs-back.
> 
> I fear the latest changes made window opening slower, I tested also on good 
> and up-to-date computers with fine video card.
> 
What do you mean by “opening slower”? Timeout between user action (click, key 
equivalent press) and window appearing?
Window is drawn slowly on first appear? 

>>  
>> no more X-Windows errors.
>> 
>> > Out of curiosity, do you have XRandR enabled and it's not working? 
>> > What is the Xorg log messages about it?
>> 
>> How can I know? xome option to the "xrandr" command?
>> 
>> Do you observe some good "xrandr" output?
> 
> in the sense that it reports correct screen size? then yes.
> 
> It is true both for local as remote displays.
> 
As I already wrote - I know what the cause of a problem. I’ve almost completed 
new implementation. 
Please wait for commits in ‘randr’ branch.

> Riccardo
> 

Sergii

Re: Cairo backend seems broken - mainScreen visibleFrame has no size

[Sergii Stoian]

Hi Riccardo!

On Sat, Feb 1, 2020 at 6:28 PM Riccardo Mottola 
wrote:

> Hi Sergii!
>
> Sergii Stoian wrote:
> > I've added check for number of XRandR outputs. Please test and report
> > if it helps.
>
> Yes it helps! now applications start both locally and remotely
>
> I got only one kind of error now and only once a the first start of Ink.
> starting it again, no error, so I do wonder and will keep an eye on it
> and also test on other computers.
>

Good. I've done testing myself and found more flows in current
implementation.
I start working on solution and almost done. You can find more fixes in
'randr' branch of libs-back.


> wmaker(catchXError(startup.c:118)): warning: internal X error: BadMatch
> (invalid parameter attributes)
>  Request code: 12 X_ConfigureWindow
>  Request minor code: 0
>  Resource ID: 0x63
>  Error serial: 59874
>
> no more X-Windows errors.
>
> > Out of curiosity, do you have XRandR enabled and it's not working?
> > What is the Xorg log messages about it?
>
> How can I know? xome option to the "xrandr" command?
>

Do you observe some good "xrandr" output?


> > P.S.: You haven't answer me about my XInitThreads idea. Have you
> succeded?
>
> Sorry, had no time to test yet. "Real Job" is consuming 99% of CPU time
> :-P But will test that as soonas I can and report back.
>

OK, no problem.

Riccardo
>

-- 
Sergii Stoian

Re: Cairo backend seems broken - mainScreen visibleFrame has no size

[Sergii Stoian]

Hi,

On Fri, Jan 31, 2020 at 6:08 PM Riccardo Mottola 
wrote:

> Hi!
>
> I updated my laptop (NetBSD / amd64 / gcc compiler and runtime) and now
> all GUI apps crash on startup:
>
>
> Starting program: /Local/Tools/Ink
> Xlib:  extension "MIT-SHM" missing on display "localhost:11.0".
> 2020-01-31 14:58:52.354 Ink[14930:130845475800848] styleoffsets ...
> guessing offsets
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7700c986b6b7 in -[XGServer(WindowOps) boundsForScreen:]
> (self=0x7700d4c87010,
>  _cmd=0x7700c9ab4150 <_OBJC_SELECTOR_TABLE+1808>, screen=0) at
> XGServerWindow.m:4528
> 4528  if (output_info->crtc)
> (gdb) bt
> #0  0x7700c986b6b7 in -[XGServer(WindowOps) boundsForScreen:]
> (self=0x7700d4c87010,
>  _cmd=0x7700c9ab4150 <_OBJC_SELECTOR_TABLE+1808>, screen=0) at
> XGServerWindow.m:4528
> #1  0x7700c98600d2 in -[XGServer(WindowOps) _OSFrameToXFrame:for:]
> (self=0x7700d4c87010,
>  _cmd=0x7700c9ab4430 <_OBJC_SELECTOR_TABLE+2544>, o=...,
> window=0x7700d6135c80) at XGServerWindow.m:512
> #2  0x7700c986423d in -[XGServer(WindowOps) window]
> (self=0x7700d4c87010,
>  _cmd=0x7700c9ab4390 <_OBJC_SELECTOR_TABLE+2384>, frame=..., type=2,
> style=64, screen=0) at XGServerWindow.m:1917
> #3  0x7700c9863498 in -[XGServer(WindowOps) _setupRootWindow]
> (self=0x7700d4c87010,
>  _cmd=0x7700c9ab0030 <_OBJC_SELECTOR_TABLE+400>) at
> XGServerWindow.m:1614
> #4  0x7700c98560fb in -[XGServer _initXContext]
> (self=0x7700d4c87010, _cmd=0x7700c9ab0080 <_OBJC_SELECTOR_TABLE+480>)
>  at XGServer.m:469
> #5  0x7700c9856278 in -[XGServer initWithAttributes:]
> (self=0x7700d4c87010,
>  _cmd=0x7700d60b4550 <_OBJC_SELECTOR_TABLE+144>, info=0x0) at
> XGServer.m:487
> #6  0x7700d5c2db71 in +[GSDisplayServer serverWithAttributes:] ()
> from /System/Library/Libraries/libgnustep-gui.so.0.28.0
> #7  0x7700d5a31715 in -[NSApplication _init] () from
> /System/Library/Libraries/libgnustep-gui.so.0.28.0
> #8  0x7700d50f87d1 in -[NSObject performSelector:withObject:] ()
> from /System/Library/Libraries/libgnustep-base.so.1.27.0
> #9  0x7700d5180760 in -[NSObject(NSThreadPerformAdditions)
> performSelector:onThread:withObject:waitUntilDone:modes:]
>  () from /System/Library/Libraries/libgnustep-base.so.1.27.0
> #10 0x7700d518061c in -[NSObject(NSThreadPerformAdditions)
> performSelectorOnMainThread:withObject:waitUntilDone:modes:] () from
> /System/Library/Libraries/libgnustep-base.so.1.27.0
> #11 0x7700d518068b in -[NSObject(NSThreadPerformAdditions)
> performSelectorOnMainThread:withObject:waitUntilDone:] ()
> from /System/Library/Libraries/libgnustep-base.so.1.27.0
> #12 0x7700d5a31b89 in -[NSApplication init] () from
> /System/Library/Libraries/libgnustep-gui.so.0.28.0
> #13 0x7700d5a3167e in +[NSApplication sharedApplication] () from
> /System/Library/Libraries/libgnustep-gui.so.0.28.0
> #14 0x7700d5a11699 in NSApplicationMain () from
> /System/Library/Libraries/libgnustep-gui.so.0.28.0
> #15 0x004019db in gnustep_base_user_main ()
> #16 0x7700d512ac8b in main () from
> /System/Library/Libraries/libgnustep-base.so.1.27.0
> #17 0x004017fc in ___start ()
> #18 0x7f7e8a60cc38 in ?? () from /usr/libexec/ld.elf_so
> #19 0x0001 in ?? ()
> #20 0x7f7fffaecf48 in ?? ()
> #21 0x in ?? ()
>
>
> the structure is null and needs to be checked.
> I also noticed that in case the call fails, there is no fallback. I
> restructured the code a little bit and pushed a fix. At least, now it
> does not crash for me anymore and Ink comes up and shows windows :-)
>
> However, I sstill get issues with X:
>
> 2020-01-31 15:07:47.335 Ink[27979:125763785598736] X-Windows error -
> BadRROutput (invalid Output parameter)
>on display: localhost:11.0
>  type: 0
> serial number: 576
>  request code: 138
>
>
> and even windowmaker when a GS application starts.
>
>
> wmaker(catchXError(startup.c:118)): warning: internal X error: BadMatch
> (invalid parameter attributes)
>  Request code: 12 X_ConfigureWindow
>  Request minor code: 0
>  Resource ID: 0x600003
>  Error serial: 59874
>
>
>
> Regards,
> Riccardo
>

I've added check for number of XRandR outputs. Please test and report if it
helps.
Out of curiosity, do you have XRandR enabled and it's not working? What is
the Xorg log messages about it?

P.S.: You haven't answer me about my XInitThreads idea. Have you succeded?

-- 
Sergii Stoian

Re: Cairo backend seems broken - mainScreen visibleFrame has no size

[Sergii Stoian]

Hi Riccardo,

On Thu, Jan 30, 2020 at 9:35 AM Riccardo Mottola 
wrote:

> Hi,
>
> I just upgraded back and now no app is able to display images and/or
> sizinig windows.
>
> I think there is an issue determining the size and/or resolution of the
> screen. For example, LaternaMagica comes up with an infinte main window.
>
> I fear it might be related to the latest enhancements of Sergey, but
> have to investigate. Can anyone else reproduce?
>
> I get these warnings:
> (moria:gap/user-apps/LaternaMagica) multix% LaternaMagica
> 2020-01-30 07:31:38.889 LaternaMagica[17860:17860] No local time zone
> specified.
> 2020-01-30 07:31:38.889 LaternaMagica[17860:17860] Using time zone with
> absolute offset 0.
> 2020-01-30 07:31:38.888 LaternaMagica[17860:17860] styleoffsets ...
> guessing offsets
> 2020-01-30 07:31:38.935 LaternaMagica[17860:17860] styleoffsets ...
> guessing offsets
> 2020-01-30 07:31:39.144 LaternaMagica[17860:17860] The font specified
> for NSFont, FreeSans, can't be found.
> 2020-01-30 07:31:39.446 LaternaMagica[17860:17860] The font specified
> for NSFont, FreeSans, can't be found.
> 2020-01-30 07:31:39.477 LaternaMagica[17860:17860] The font specified
> for NSFont, FreeSans, can't be found.
> 2020-01-30 07:31:39.492 LaternaMagica[17860:17860] The font specified
> for NSFont, FreeSans, can't be found.
> 2020-01-30 07:31:39.764 LaternaMagica[17860:17860] File NSView.m: 1183.
> In -[NSView setFrame:] given negative width
> 2020-01-30 07:31:39.764 LaternaMagica[17860:17860] File NSView.m: 1183.
> In -[NSView setFrame:] given negative width
> 2020-01-30 07:31:39.765 LaternaMagica[17860:17860] File NSView.m: 1183.
> In -[NSView setFrame:] given negative width
> 2020-01-30 07:31:39.765 LaternaMagica[17860:17860] File NSView.m: 1188.
> In -[NSView setFrame:] given negative height
> 2020-01-30 07:31:39.767 LaternaMagica[17860:17860] Cairo status 'invalid
> value (typically too big) for the size of the input (surface, pattern,
> etc.)' in DPSinitgraphics
>
> PRICE, instead, comes up, shows the same warnings as before in the
> conosole. Additionally, when loading an image:
>
> 2020-01-30 07:36:44.420 PRICE[17955:17955] current screen size: 0.00
> x  0.00
> 2020-01-30 07:36:44.420 PRICE[17955:17955] current window size:
> 118.00 x  28.00
> 2020-01-30 07:36:44.745 PRICE[17955:17955] Cairo status 'invalid value
> (typically too big) for the size of the input (surface, pattern, etc.)'
> in DPSinitgraphics
>
> So this tells me that:
> screenFrameSize = [[NSScreen mainScreen] visibleFrame].size;
> NSLog(@"current screen size: %f x  %f", screenFrameSize.width,
> screenFrameSize.height);
>
> is 0! and this can't be good!
>
> Riccardo
>
> Can't reproduce it.
I've tried LatternaMagica 0.5 with `art` and `cairo` backends using both
'master' and `randr` branch.

-- 
Sergii Stoian

Re: crash when using local display but not remote

[Sergii Stoian]

Hi,

On Tue, Jan 28, 2020 at 9:53 AM Riccardo Mottola 
wrote:

> Hi!
>
> Sergii Stoian wrote:
> >> I’ve installed art on debian buster x64 with the gnustep runtime (2.0)
> from latest source on github.com/gnustep (does it answer your PS, Sergii
> ?)
> > It depends on what version of Debian installed on Riccardo's MIPS
> machine...
> >
>
> I have debian 4.0 and am limited to a 2.4 kernel. The rest is some sort
> of a mix.
> gcc 4.1.2 and its own runtime
>
> I don't think this is an "art" bug, but an xlib/x11 issue, since it
> happened also when I compiled accidentally with the xlib instead of the
> art backend.
>
> For your informatin, I just compiled the art backend again on this small
> machine, with all your latest patches after the merge, and it compiles
> and also works fine if remote X is displayed.
> I usuallky always export display, because the small keyboard is
> unsuitable for typing  the build commands :-P
>
> Riccardo
>

I'm not sure, just an idea: this problem may have relation to enabled
multithreading in X11. Probably due to outdated X server.
Could you please try to comment out line in x11/XGServer.m that contains
XInitThreads() (line 419) and recompile/reinstall backend?

Sergii

Multi-monitor setup support

[Sergii Stoian]

Hi,

Yesterday I've submitted 2 PRs: https://github.com/gnustep/libs-back/pull/18
and https://github.com/gnustep/libs-gui/pull/50. These changes provide
ability for running apps adopt monitor configuration changes (resolution
and layout).

Actually this is first little step to multi-monitor setup support. I want
to end up with set of enhancements to GNUstep:
- Application awareness of monitors parameters (resolution, layout, depth,
DPI) changes. Application should update it's windows positions and
autosaved frames.
- Application/window awareness when window moved across monitors.
- Application menu should move to key window's monitor (move window, switch
key state between windows on different monitors).
- Correct window position restore from autosave frame. Now windows
sometimes moved down relatively to the top part of desktop.

--
Sergii Stoian

Re: crash when using local display but not remote

[Sergii Stoian]

Hi Bertrand,

> On Jan 26, 2020, at 02:09, Bertrand Dekoninck  
> wrote:
> 
> Hi Riccardo !
> I’ve installed art on debian buster x64 with the gnustep runtime (2.0) from 
> latest source on github.com/gnustep (does it answer your PS, Sergii ?)

It depends on what version of Debian installed on Riccardo's MIPS machine...

> I did’n’t try Ink, but Gworkspace works fine (well not its inspectors, of 
> course) locally. I don’t see your error, Ricardo. Has this error something to 
> do with the "Sync extension «  not present on your system xlib ?
> 
> What should I do with valgrind ?
> 
> Bertrand
> 
>> Le 25 janv. 2020 à 00:13, cobjective  a écrit :
>> 
>> Hi, Riccardo!
>> 
>>> On Jan 24, 2020, at 00:51, Riccardo Mottola  
>>> wrote:
>>> 
>>> Hi!
>>> 
>>> to test the latest "libart" stuff I upgraded all GNUStep on the old and 
>>> venerable MIPS Book Letux400
>>> 
>>> I got everything to build! yeah!
>>> 
>>> If I export the display through ssh, everything works and (albeit slow... 
>>> the Letux had the LAN connected through USB on the board) I get a fine 
>>> looking GNUstep!
>>> 
>>> If I use it locally, however, I get an immediate crash:
>>> 
>>> (gdb) r
>>> Starting program: /home/usr-GNUstep/Local/Tools/Ink
>>> [Thread debugging using libthread_db enabled]
>>> [New Thread 16384 (LWP 330)]
>>> Xlib:  extension "SYNC" missing on display ":0.0".
>>> *** glibc detected *** double free or corruption (out): 0x00636300 ***
>>> 
>>> Program received signal SIGABRT, Aborted.
>>> [Switching to Thread 16384 (LWP 330)]
>>> 0x2b898a94 in kill () from /lib/libc.so.6
>>> (gdb) bt
>>> #0  0x2b898a94 in kill () from /lib/libc.so.6
>>> #1  0x2b674b88 in pthread_kill () from /lib/libpthread.so.0
>>> #2  0x2b674c00 in raise () from /lib/libpthread.so.0
>>> #3  0x2b89a190 in abort () from /lib/libc.so.6
>>> #4  0x2b8d6294 in __fsetlocking () from /lib/libc.so.6
>>> #5  0x2b8d6294 in __fsetlocking () from /lib/libc.so.6
>>> Previous frame identical to this frame (corrupt stack?)
>>> 
>>> this does not look very useful and looks like very early memory corruption?
>>> 
>>> I recompiled all back with debug=yes, I hope that still disables 
>>> optimizations correctl. I do not get a better stack. and not a better 
>>> outcome either!
>>> 
>>> Could someone using art on x86 or amd64 try valgrind?
>>> 
>> 
>> 
>> Give more information, please.
>> Why do you think it’s art backend? Did you try other 
>> backends/compiler/linker?
>> What are your build options (runtime, library combo, compiler, linker)?
>> 
>> P.S.: Does it mean you can build art backend without ftfont-old.m (with my 
>> changes to art)?
>> 
>> Sergii
> 

Re: GORM usability enhancements

[Sergii Stoian]

Hi,

On Mon, Jan 6, 2020 at 12:33 AM RIccardo Mottola 
wrote:

> Hi,
>
> On 2019-12-20 11:56:01 +0100 Sergii Stoian  wrote:
>
> > 1. Enhancements in model files (conrtols positionning, autosizing, fonts,
> > menu items rearrangements).
>
> I think *most* of it is fine...Gorm matches quite closely NeXT IB and old
> Mac IB which were quite fine!
> But indeed, some autosizing and some elements are not so optimal.
>

I think *almost all* inspectors need positioning and sizing fixes. I'm
about to finish this task. You can checkout `UsabilityEnhancements` branch
and see the difference for yourself.


> > 2. Sort out focus change between controls and windows (I've noticed some
> > inconviences).
>
> I did very few... but I do notice instead that when doing a connection to
> a target with many object icons, the icon list doesn't scroll properly and
> the target is drawn not below the cursor sometimes (but the connection will
> the correctly happen to the drawn target.. so it is bad, but usable)
>

The main annoyance for me is when you have selected NSTextField inside
NSBox, then you're switching to Inspector for making changes, then clicking
on NSTextField and... you've end up with NSBox selected.


> > 3. Document window changes: fix selection of objects, make object titles
> > editable (get rid of "Set Name" panel), finish and make usable Class
> Editor
> > outline editor (get rid of Class Editor Inspector).
>
> Class Editor Inspector is fine!
>
> For me enhancements would be useful in the object element
> drawing/positioning.
> The automatic guidelines and snapping... is worse than on old Mac IBs...
> but I don't know exactly why, perhaps it is a matter of layers and what is
> preferrably selected as a snap. Mac is quite aggressive and abundant, I
> think.
>
> A really big enhancement would be however undo. In everything it will be
> perhaps difficult (e.g. adding object, editing actions). But being able do
> undo "editing" of the graphical elements: size, positioning, etc... would
> be very useful since it is often trial-and-error.
>

Agree.

Just my 0.02 €
>
> Riccardo
>
>
Sergii

Re: Accidental merge into libs-gui

[Sergii Stoian]

I'm sorry, Fred.
Although my PR #43 marked as merged now. It seems there is no way to reopen
PR that was marked as merged.

BTW, I've failed to find a solution for pulldown popup button ("merged"
PR). The NeXT and Apple styles are too different to do what I want in clean
and elegant way. I'll hold this patch inside NEXTSPACE.
I'll create a separate PR for tiny change regarding menu positioning later.

On Fri, Jan 3, 2020 at 3:33 PM Fred Kiefer  wrote:

> You really had me in a short state of shock when coming back from jogging
> and seeing this merge had happened. Thank you for cleaning up that quickly!
>
> Fred
>
> > Am 03.01.2020 um 13:50 schrieb Sergii Stoian :
> >
> > Fixed.
> > I've used `git rebase -i` and `git push origin master --force`.
> Everything looks correct now.
> >
> > On Fri, Jan 3, 2020 at 2:20 PM Sergii Stoian 
> wrote:
> > Guys,
> >
> > I've made accidental merge into libs-gui (my intention was to merge
> changes into my fork from master). What should I do better to remove this
> merge: `git reset --hard` into commit before merge?
> >
> > Sergii
> >
> >
> > --
> > Sergii Stoian,
> > ProjectCenter lead developer
> > NEXTSPACE owner, lead developer
>
>
>

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer

Re: Accidental merge into libs-gui

[Sergii Stoian]

Fixed.
I've used `git rebase -i` and `git push origin master --force`. Everything
looks correct now.

On Fri, Jan 3, 2020 at 2:20 PM Sergii Stoian  wrote:

> Guys,
>
> I've made accidental merge into libs-gui (my intention was to merge
> changes into my fork from master). What should I do better to remove this
> merge: `git reset --hard` into commit before merge?
>
> Sergii
>


-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer

Accidental merge into libs-gui

[Sergii Stoian]

Guys,

I've made accidental merge into libs-gui (my intention was to merge changes
into my fork from master). What should I do better to remove this merge:
`git reset --hard` into commit before merge?

Sergii

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

[Sergii Stoian]

Good. I'll try try to rework this change.

On Wed, Dec 25, 2019 at 12:54 AM Fred Kiefer  wrote:

> Exactly., that is what Wolfgang and I failed to express in our previous
> mails.
>
> > Am 24.12.2019 um 19:39 schrieb cobjective :
> >
> > Why? If menu draws rounded corners you’ll get it. Oh, I understand.
> Buttons are drawn with rounded corners but menus aren’t. Correct?
> >
> > Sergii
> >
> >> On 24 Dec 2019, at 17:32, Fred Kiefer  wrote:
> >>
> >> Sorry for not being clear enough. Using rounded pull downs or
> different edges is nothing a theme would do. This is official functionality
> that the normal GNUstep drawing must support. We would loose it with your
> change.
> >>
> >> fred
> >>
> >>> Am 24.12.2019 um 16:00 schrieb cobjective :
> >>>
> >>> Fred, focus ring is not the only difference. My screenshots represent
> official GNUstep control appearance. Why we should bother about themes at
> all? It’s theme responsibility to draw its controls. Or did I miss
> something and official GNUstep look tends to be MacOS X like?
> >>>
> >>> Sergii
> >>>
> >>>>> On 24 Dec 2019, at 15:15, Fred Kiefer  wrote:
> >>>>
> >>>> In your images the only difference I see is the focus ring and even
> that I see barely. But the real difference will be shown when using a
> rounded pull down or as Wolfgang pointed out one that uses a different edge.
> >>>> To make it easier for you to see that I just committed an example of
> a rounded pull down button into our examples. (
> https://github.com/gnustep/tests-examples/commit/a4652642fd6c196d7e59af63f587856be9437dfb
> )
> >>>>
> >>>>> Am 24.12.2019 um 12:29 schrieb Sergii Stoian :
> >>>>>
> >>>>> Hi Fred,
> >>>>>
> >>>>> Here are my screenshots. The first (PullDown-old.png) is how pressed
> button looks with current code, the second (PullDown-new.png) with my code.
> >>>>> I hope you'll notice the difference.
> >>>>>
> >>>>> 
> >>>>> 
> >>>>>
> >>>>> On Tue, Dec 24, 2019 at 12:06 PM Fred Kiefer 
> wrote:
> >>>>> HI Sergii,
> >>>>>
> >>>>> here is what a pull down NSPopUpButton looks like on Cocoa:
> >>>>>
> >>>>> 
> >>>>>
> >>>>> This button has three items („Pull Down“, „Item 2“, „Item 3“). Only
> the later two get displayed in the popup menu.
> >>>>> At least for the standard theme we aim for a similar display within
> GNUstep. If you want something else a theme or a user option would be the
> way to go. Or a decision to change the default.
> >>>>>
> >>>>> At the moment I would say that Wolfgang and I are against your
> change and the rest of GNUstep has not stated an opinion. Maybe it would
> help to show different possibilities in pictures.
> >>>>> Could you pease post how a similar button looks with your new code?
> >>>>>
> >>>>> Fred
> >>>>>
> >>>>>>> Am 23.12.2019 um 12:06 schrieb Sergii Stoian  >:
> >>>>>>
> >>>>>> Do we have any decision? What's next? Do I need to do/fix something
> in context of this PR?
> >>>>>>
> >>>>>>> On Sat, Dec 21, 2019 at 12:39 AM Sergii Stoian <
> stoyan...@gmail.com> wrote:
> >>>>>> On 20 Dec 2019, at 18:15, Wolfgang Lux 
> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>> Am 20.12.2019 um 16:11 schrieb Fred Kiefer :
> >>>>>>>> There you just describe that now the popup looks the same whether
> in pull down or in popup state. But what is the reason for this change? As
> I wrote I am happy with getting rid of all this special code, but last time
> I tried to do this it was rejected.
> >>>>>>>
> >>>>>>> I don't recall whether I was involved in that rejection or not,
> but if I wasn't I'd think that it was the correct move.
> >>>>>>>
> >>>>>>> Regarding the different behavior with regard to the title cell, it
> apparently dates back to the heyday of OpenStep (and presumably the
> original NeXTstep as well). The idea seems to be that the title that is
> visible in the pop up button cell when the menu is not visible sho

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

[Sergii Stoian]

Hi Fred,

Here are my screenshots. The first (PullDown-old.png) is how pressed button
looks with current code, the second (PullDown-new.png) with my code.
I hope you'll notice the difference.

[image: PullDown-old.png]
[image: PullDown-new.png]

On Tue, Dec 24, 2019 at 12:06 PM Fred Kiefer  wrote:

> HI Sergii,
>
> here is what a pull down NSPopUpButton looks like on Cocoa:
>
>
> This button has three items („Pull Down“, „Item 2“, „Item 3“). Only the
> later two get displayed in the popup menu.
> At least for the standard theme we aim for a similar display within
> GNUstep. If you want something else a theme or a user option would be the
> way to go. Or a decision to change the default.
>
> At the moment I would say that Wolfgang and I are against your change and
> the rest of GNUstep has not stated an opinion. Maybe it would help to show
> different possibilities in pictures.
> Could you pease post how a similar button looks with your new code?
>
> Fred
>
> Am 23.12.2019 um 12:06 schrieb Sergii Stoian :
>
> Do we have any decision? What's next? Do I need to do/fix something in
> context of this PR?
>
> On Sat, Dec 21, 2019 at 12:39 AM Sergii Stoian 
> wrote:
> On 20 Dec 2019, at 18:15, Wolfgang Lux  wrote:
> >
> >
> >> Am 20.12.2019 um 16:11 schrieb Fred Kiefer :
> >> There you just describe that now the popup looks the same whether in
> pull down or in popup state. But what is the reason for this change? As I
> wrote I am happy with getting rid of all this special code, but last time I
> tried to do this it was rejected.
> >
> > I don't recall whether I was involved in that rejection or not, but if I
> wasn't I'd think that it was the correct move.
> >
> > Regarding the different behavior with regard to the title cell, it
> apparently dates back to the heyday of OpenStep (and presumably the
> original NeXTstep as well). The idea seems to be that the title that is
> visible in the pop up button cell when the menu is not visible should be
> backed up by an element of the associated menu. In pop up mode this would
> be the selected item, while in pull down mode it is invariably the first
> element of the menu (since the title of the pull down is not supposed to
> change depending on the user's last selection). I think that's nothing that
> GNUstep can or should change.
>
> This is how it works before and after change.
>
> > That only leaves you with the option whether to display the title item
> when the pull down is visible or to not display it. If you wanted to
> display the title, the only reasonable choice for that would be such that
> the title item appears above the button itself (because otherwise you would
> redundantly display the same information twice).
>
> Correct. This is how it works after change.
>
> > But then that doesn't work that well if you display an icon in the
> button cell rather than text (useful, for instance, when you want to make
> NSToolbar buttons with an attached pull down menu) and the popup button's
> width and/or height do not match the width or height of the menu (items).
> Also beware that the menu does not necessarily need to appear at the bottom
> of the pop up button. You can set the preferredEdge property of the button
> cell to make it appear on one of the sides of the button (or even appear
> attached to the top edge, although I don't see a reason for doing that).
> But of course these are all aesthetic judgements so feel free to disagree.
>
> Good points. I guess these are the cases for further testing, changing and
> separate PR.
>
>
>

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer

Re: GORM usability enhancements

[Sergii Stoian]

Gregory, no problem. I'll refrain from removal of inspector. I'll think
about outline view later.
Currently I'm focused on user interactions with UI elements (selection,
positioning, sizing). I've finished with Palettes panel and menu items
rearrangement. It would be great if you try it and send me feedback.

On Mon, Dec 23, 2019 at 11:49 PM Gregory Casamento 
wrote:

> I don't want to tie people to the outline view.   I already explained the
> rationale of why in the last post.  Classes should be treated like
> everything else and be editable by inspectors.  I, personally, think the
> Outline view in Gorm should be done away with as it would eliminate this
> confusion.
>
> On Fri, Dec 20, 2019 at 12:09 PM Sergii Stoian 
> wrote:
>
>> I think it's quite confusing to do the same things with different tools
>> in one application. Probably some tool will be used more often than other.
>> This is a matter of application usability and learning curve.
>> Could you explain to the evarage user of GORM: what are cases for Class
>> Editor and Class Editor Inspector usage and why?
>> Anyway, it's up to you, Gregory. Thanks.
>>
>> On Fri, Dec 20, 2019 at 6:46 PM Gregory Casamento <
>> greg.casame...@gmail.com> wrote:
>>
>>> I will not approve #3.  The user should have multiple ways of editing
>>> the class.  The outline editor should not be the only way.  It is
>>> consistent to treat a class the same way we do objects via an inspector.
>>>
>>> On Fri, Dec 20, 2019, 11:08 AM Gregory Casamento <
>>> greg.casame...@gmail.com> wrote:
>>>
>>>> Please create a branch to be merged via a pull request.
>>>>
>>>> On Fri, Dec 20, 2019, 5:56 AM Sergii Stoian 
>>>> wrote:
>>>>
>>>>> Hi, everybody.
>>>>>
>>>>> I use GORM application a lot. I think it's most comprehensive GNUstep
>>>>> application.
>>>>> After a while I've noticed roughness in a various places across
>>>>> application. So, finally, I've decided to spend some time and polish GORM
>>>>> from usability point of view. Basically most of the changes will be done 
>>>>> at
>>>>> model files, but I suppose code will be touched also later.
>>>>>
>>>>> My plan is the following:
>>>>> 1. Enhancements in model files (conrtols positionning, autosizing,
>>>>> fonts, menu items rearrangements).
>>>>> 2. Sort out focus change between controls and windows (I've noticed
>>>>> some inconviences).
>>>>> 3. Document window changes: fix selection of objects, make object
>>>>> titles editable (get rid of "Set Name" panel), finish and make usable 
>>>>> Class
>>>>> Editor outline editor (get rid of Class Editor Inspector).
>>>>>
>>>>> I see several options to do this with Git:
>>>>> 1. Push changes into master branch without pull requests. It seems
>>>>> good for model files (1)
>>>>> 2. Create separate branch or fork and merge changes into master after
>>>>> I finish.
>>>>>
>>>>> My questions to community: what option do you think I should go with?
>>>>>
>>>>> --
>>>>> Sergii Stoian
>>>>>
>>>>
>>
>> --
>> Sergii Stoian,
>> ProjectCenter lead developer
>> NEXTSPACE owner, lead developer
>>
>
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/
>


-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer

Re: GORM usability enhancements

[Sergii Stoian]

For everybody interested in topic, I've created a branch
"UsabilityEnhancements".
You can clone it with `git clone https://github.com/gnustep/apps-gorm -b
UsabilityEnhancements` if you want to check for what is going on here.

Feel free to send me a feedback.

On Fri, Dec 20, 2019 at 7:09 PM Sergii Stoian  wrote:

> I think it's quite confusing to do the same things with different tools in
> one application. Probably some tool will be used more often than other.
> This is a matter of application usability and learning curve.
> Could you explain to the evarage user of GORM: what are cases for Class
> Editor and Class Editor Inspector usage and why?
> Anyway, it's up to you, Gregory. Thanks.
>
> On Fri, Dec 20, 2019 at 6:46 PM Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
>> I will not approve #3.  The user should have multiple ways of editing the
>> class.  The outline editor should not be the only way.  It is consistent to
>> treat a class the same way we do objects via an inspector.
>>
>> On Fri, Dec 20, 2019, 11:08 AM Gregory Casamento <
>> greg.casame...@gmail.com> wrote:
>>
>>> Please create a branch to be merged via a pull request.
>>>
>>> On Fri, Dec 20, 2019, 5:56 AM Sergii Stoian  wrote:
>>>
>>>> Hi, everybody.
>>>>
>>>> I use GORM application a lot. I think it's most comprehensive GNUstep
>>>> application.
>>>> After a while I've noticed roughness in a various places across
>>>> application. So, finally, I've decided to spend some time and polish GORM
>>>> from usability point of view. Basically most of the changes will be done at
>>>> model files, but I suppose code will be touched also later.
>>>>
>>>> My plan is the following:
>>>> 1. Enhancements in model files (conrtols positionning, autosizing,
>>>> fonts, menu items rearrangements).
>>>> 2. Sort out focus change between controls and windows (I've noticed
>>>> some inconviences).
>>>> 3. Document window changes: fix selection of objects, make object
>>>> titles editable (get rid of "Set Name" panel), finish and make usable Class
>>>> Editor outline editor (get rid of Class Editor Inspector).
>>>>
>>>> I see several options to do this with Git:
>>>> 1. Push changes into master branch without pull requests. It seems good
>>>> for model files (1)
>>>> 2. Create separate branch or fork and merge changes into master after I
>>>> finish.
>>>>
>>>> My questions to community: what option do you think I should go with?
>>>>
>>>> --
>>>> Sergii Stoian
>>>>
>>>
>
> --
> Sergii Stoian,
> ProjectCenter lead developer
> NEXTSPACE owner, lead developer
>


-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

[Sergii Stoian]

Hi,

Do we have any decision? What's next? Do I need to do/fix something in
context of this PR?

On Sat, Dec 21, 2019 at 12:39 AM Sergii Stoian  wrote:

> On 20 Dec 2019, at 18:15, Wolfgang Lux  wrote:
> >
> >
> >> Am 20.12.2019 um 16:11 schrieb Fred Kiefer :
> >>
> >> ...
> >>
> >> There you just describe that now the popup looks the same whether in
> pull down or in popup state. But what is the reason for this change? As I
> wrote I am happy with getting rid of all this special code, but last time I
> tried to do this it was rejected.
> >
> > I don't recall whether I was involved in that rejection or not, but if I
> wasn't I'd think that it was the correct move.
> >
> > Regarding the different behavior with regard to the title cell, it
> apparently dates back to the heyday of OpenStep (and presumably the
> original NeXTstep as well). The idea seems to be that the title that is
> visible in the pop up button cell when the menu is not visible should be
> backed up by an element of the associated menu. In pop up mode this would
> be the selected item, while in pull down mode it is invariably the first
> element of the menu (since the title of the pull down is not supposed to
> change depending on the user's last selection). I think that's nothing that
> GNUstep can or should change.
>
> This is how it works before and after change.
>
> > That only leaves you with the option whether to display the title item
> when the pull down is visible or to not display it. If you wanted to
> display the title, the only reasonable choice for that would be such that
> the title item appears above the button itself (because otherwise you would
> redundantly display the same information twice).
>
> Correct. This is how it works after change.
>
> > But then that doesn't work that well if you display an icon in the
> button cell rather than text (useful, for instance, when you want to make
> NSToolbar buttons with an attached pull down menu) and the popup button's
> width and/or height do not match the width or height of the menu (items).
> Also beware that the menu does not necessarily need to appear at the bottom
> of the pop up button. You can set the preferredEdge property of the button
> cell to make it appear on one of the sides of the button (or even appear
> attached to the top edge, although I don't see a reason for doing that).
> But of course these are all aesthetic judgements so feel free to disagree.
>
> Good points. I guess these are the cases for further testing, changing and
> separate PR.
>
> >
> > Wolfgang
> >
>
> Sergii



-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

[Sergii Stoian]

On 20 Dec 2019, at 18:15, Wolfgang Lux  wrote:
> 
> 
>> Am 20.12.2019 um 16:11 schrieb Fred Kiefer :
>> 
>> ...
>> 
>> There you just describe that now the popup looks the same whether in pull 
>> down or in popup state. But what is the reason for this change? As I wrote I 
>> am happy with getting rid of all this special code, but last time I tried to 
>> do this it was rejected.
> 
> I don't recall whether I was involved in that rejection or not, but if I 
> wasn't I'd think that it was the correct move.
> 
> Regarding the different behavior with regard to the title cell, it apparently 
> dates back to the heyday of OpenStep (and presumably the original NeXTstep as 
> well). The idea seems to be that the title that is visible in the pop up 
> button cell when the menu is not visible should be backed up by an element of 
> the associated menu. In pop up mode this would be the selected item, while in 
> pull down mode it is invariably the first element of the menu (since the 
> title of the pull down is not supposed to change depending on the user's last 
> selection). I think that's nothing that GNUstep can or should change.

This is how it works before and after change.

> That only leaves you with the option whether to display the title item when 
> the pull down is visible or to not display it. If you wanted to display the 
> title, the only reasonable choice for that would be such that the title item 
> appears above the button itself (because otherwise you would redundantly 
> display the same information twice).

Correct. This is how it works after change.

> But then that doesn't work that well if you display an icon in the button 
> cell rather than text (useful, for instance, when you want to make NSToolbar 
> buttons with an attached pull down menu) and the popup button's width and/or 
> height do not match the width or height of the menu (items). Also beware that 
> the menu does not necessarily need to appear at the bottom of the pop up 
> button. You can set the preferredEdge property of the button cell to make it 
> appear on one of the sides of the button (or even appear attached to the top 
> edge, although I don't see a reason for doing that). But of course these are 
> all aesthetic judgements so feel free to disagree.

Good points. I guess these are the cases for further testing, changing and 
separate PR.

> 
> Wolfgang
> 

Sergii

Re: GORM usability enhancements

[Sergii Stoian]

I think it's quite confusing to do the same things with different tools in
one application. Probably some tool will be used more often than other.
This is a matter of application usability and learning curve.
Could you explain to the evarage user of GORM: what are cases for Class
Editor and Class Editor Inspector usage and why?
Anyway, it's up to you, Gregory. Thanks.

On Fri, Dec 20, 2019 at 6:46 PM Gregory Casamento 
wrote:

> I will not approve #3.  The user should have multiple ways of editing the
> class.  The outline editor should not be the only way.  It is consistent to
> treat a class the same way we do objects via an inspector.
>
> On Fri, Dec 20, 2019, 11:08 AM Gregory Casamento 
> wrote:
>
>> Please create a branch to be merged via a pull request.
>>
>> On Fri, Dec 20, 2019, 5:56 AM Sergii Stoian  wrote:
>>
>>> Hi, everybody.
>>>
>>> I use GORM application a lot. I think it's most comprehensive GNUstep
>>> application.
>>> After a while I've noticed roughness in a various places across
>>> application. So, finally, I've decided to spend some time and polish GORM
>>> from usability point of view. Basically most of the changes will be done at
>>> model files, but I suppose code will be touched also later.
>>>
>>> My plan is the following:
>>> 1. Enhancements in model files (conrtols positionning, autosizing,
>>> fonts, menu items rearrangements).
>>> 2. Sort out focus change between controls and windows (I've noticed some
>>> inconviences).
>>> 3. Document window changes: fix selection of objects, make object titles
>>> editable (get rid of "Set Name" panel), finish and make usable Class Editor
>>> outline editor (get rid of Class Editor Inspector).
>>>
>>> I see several options to do this with Git:
>>> 1. Push changes into master branch without pull requests. It seems good
>>> for model files (1)
>>> 2. Create separate branch or fork and merge changes into master after I
>>> finish.
>>>
>>> My questions to community: what option do you think I should go with?
>>>
>>> --
>>> Sergii Stoian
>>>
>>

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer

Re: GORM usability enhancements

[Sergii Stoian]

Got it, thanks.

On Fri, Dec 20, 2019 at 6:08 PM Gregory Casamento 
wrote:

> Please create a branch to be merged via a pull request.
>
> On Fri, Dec 20, 2019, 5:56 AM Sergii Stoian  wrote:
>
>> Hi, everybody.
>>
>> I use GORM application a lot. I think it's most comprehensive GNUstep
>> application.
>> After a while I've noticed roughness in a various places across
>> application. So, finally, I've decided to spend some time and polish GORM
>> from usability point of view. Basically most of the changes will be done at
>> model files, but I suppose code will be touched also later.
>>
>> My plan is the following:
>> 1. Enhancements in model files (conrtols positionning, autosizing, fonts,
>> menu items rearrangements).
>> 2. Sort out focus change between controls and windows (I've noticed some
>> inconviences).
>> 3. Document window changes: fix selection of objects, make object titles
>> editable (get rid of "Set Name" panel), finish and make usable Class Editor
>> outline editor (get rid of Class Editor Inspector).
>>
>> I see several options to do this with Git:
>> 1. Push changes into master branch without pull requests. It seems good
>> for model files (1)
>> 2. Create separate branch or fork and merge changes into master after I
>> finish.
>>
>> My questions to community: what option do you think I should go with?
>>
>> --
>> Sergii Stoian
>>
>

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

[Sergii Stoian]

On Fri, Dec 20, 2019 at 5:11 PM Fred Kiefer  wrote:

>
>
> > Am 20.12.2019 um 15:20 schrieb Sergii Stoian :
> >
> > On Fri, Dec 20, 2019 at 2:24 PM Fred Kiefer  wrote:
> >
> >
> > > Am 20.12.2019 um 11:34 schrieb Sergii Stoian :
> > >
> > > I've moved discussion to mail list as Fred asked me.
> > >
> > > On Fri, Dec 20, 2019 at 12:18 PM Fred Kiefer 
> wrote:
> > > Some of the changes of this pull request are obviously correct. What I
> doubt is the overall change. Why would we want to display the title item
> (that is the first item in a pull down) in the menu?
> > > This is the main difference between pull down and pop up and it is
> well documented.
> > >
> > > Do you mean GNUstep documentation or Apple?
> >
> > Apple’s documentation. According to this, the first item of a pull down
> is the title and not displayed when showing the menu. This is what GNUstep
> has implemented up to now.
> >
> > Give me a link please to that documentation.
> > Here
> https://developer.apple.com/documentation/appkit/nspopupbutton/1532070-pullsdown?language=objc
> I've git this: "This property does not affect the contents of the menu; it
> affects only the style of the menu.“
>
> Close :-)
>
>
> https://developer.apple.com/documentation/appkit/nspopupbuttoncell/1528475-settitle?language=objc
>
> Ok, this page says how popup button gets its string value. I've change
nothing in this context.

>
> > > I just tired this on Cocoa and the difference is still there.
> > >
> > > What particular difference did you observe from practical point of
> view? What consequences do you expect?
> >
> > As I unterstand it you want to display the title as the first item in
> the menu, but as a disabled one. This will look different than it did
> before.
> >
> > Fred, have you tried libs-gui with my change?
> > The only difference is correct drawing of left and top border of button
> while mouse is down.
> > On the contrary with my change popup button menu looks the same no
> matter what style was selected pulldown or normal.
>
> No, I have not tried to run an application with this code in place. I was
> relying on our comment "Before this change popup menu doesn't display first
> item and was placed to the bottom edge of popup button“ and the changes I
> see in the code.


I'll fix comment.

I really prefer reading code then running it.
>

That's why you can't understand what's changed. :(


> The idea behind the current code is that the title does not belong into
> the menu and gets displayed on the popup button only, how ever that gets
> drawn. And the menu opens up below it.
>
> I clearely understand it. This is true for normal popup button either.
Button cell is not menu item cell in both cases - it gets its title string
from selected menu item and not replaces cell. I see no problem here.

>
> > Having this as a theme or with a user setable option would be fine for
> me. But changing the default here is something that needs to be discussed
> more widely.
> >
> > > Of course changing this would simplify the code here a lot and I would
> love to see that, but this changes the whole appearance of pull down items
> and this needs to be decided on a completely different level.
> > >
> > > So we're here.
> > > Any thoughts, guys?
> >
> > No, I personally don’t have much of a position on this point. Why do you
> want to change the behaviour?
> >
> > I'll describe reasons and intentions in PR:
> https://github.com/gnustep/libs-gui/pull/43.
>
> There you just describe that now the popup looks the same whether in pull
> down or in popup state. But what is the reason for this change?


Did you see this "Although popup menu can't draw dark gray border around
popup button.".
That's the real change and is essential from UX perspective. Anything else
stays untouched.


> As I wrote I am happy with getting rid of all this special code, but last
> time I tried to do this it was rejected.


Let's make it happen finally. :)

--
Sergii Stoian

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

[Sergii Stoian]

On Fri, Dec 20, 2019 at 2:24 PM Fred Kiefer  wrote:

>
>
> > Am 20.12.2019 um 11:34 schrieb Sergii Stoian :
> >
> > I've moved discussion to mail list as Fred asked me.
> >
> > On Fri, Dec 20, 2019 at 12:18 PM Fred Kiefer 
> wrote:
> > Some of the changes of this pull request are obviously correct. What I
> doubt is the overall change. Why would we want to display the title item
> (that is the first item in a pull down) in the menu?
> > This is the main difference between pull down and pop up and it is well
> documented.
> >
> > Do you mean GNUstep documentation or Apple?
>
> Apple’s documentation. According to this, the first item of a pull down is
> the title and not displayed when showing the menu. This is what GNUstep has
> implemented up to now.
>

Give me a link please to that documentation.
Here
https://developer.apple.com/documentation/appkit/nspopupbutton/1532070-pullsdown?language=objc
I've git this: "This property does not affect the contents of the menu; it
affects only the style of the menu."


> > I just tired this on Cocoa and the difference is still there.
> >
> > What particular difference did you observe from practical point of view?
> What consequences do you expect?
>
> As I unterstand it you want to display the title as the first item in the
> menu, but as a disabled one. This will look different than it did before.


Fred, have you tried libs-gui with my change?
The only difference is correct drawing of left and top border of button
while mouse is down.
On the contrary with my change popup button menu looks the same no matter
what style was selected pulldown or normal.


> Having this as a theme or with a user setable option would be fine for me.
> But changing the default here is something that needs to be discussed more
> widely.
>

> > Of course changing this would simplify the code here a lot and I would
> love to see that, but this changes the whole appearance of pull down items
> and this needs to be decided on a completely different level.
> >
> > So we're here.
> > Any thoughts, guys?
>
> No, I personally don’t have much of a position on this point. Why do you
> want to change the behaviour?


I'll describe reasons and intentions in PR:
https://github.com/gnustep/libs-gui/pull/43.

-- 
Sergii Stoian

GORM usability enhancements

[Sergii Stoian]

Hi, everybody.

I use GORM application a lot. I think it's most comprehensive GNUstep
application.
After a while I've noticed roughness in a various places across
application. So, finally, I've decided to spend some time and polish GORM
from usability point of view. Basically most of the changes will be done at
model files, but I suppose code will be touched also later.

My plan is the following:
1. Enhancements in model files (conrtols positionning, autosizing, fonts,
menu items rearrangements).
2. Sort out focus change between controls and windows (I've noticed some
inconviences).
3. Document window changes: fix selection of objects, make object titles
editable (get rid of "Set Name" panel), finish and make usable Class Editor
outline editor (get rid of Class Editor Inspector).

I see several options to do this with Git:
1. Push changes into master branch without pull requests. It seems good for
model files (1)
2. Create separate branch or fork and merge changes into master after I
finish.

My questions to community: what option do you think I should go with?

-- 
Sergii Stoian

Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)

[Sergii Stoian]

I've mode discussion to mail list as Fred asked me.

On Fri, Dec 20, 2019 at 12:18 PM Fred Kiefer 
wrote:

> Some of the changes of this pull request are obviously correct. What I
> doubt is the overall change. Why would we want to display the title item
> (that is the first item in a pull down) in the menu?
> This is the main difference between pull down and pop up and it is well
> documented.
>
Do you mean GNUstep documentation or Apple?

> I just tired this on Cocoa and the difference is still there.
>
What particular difference did you observe from practical point of view?
What consequences do you expect?

> Of course changing this would simplify the code here a lot and I would
> love to see that, but this changes the whole appearance of pull down items
> and this needs to be decided on a completely different level.
>
So we're here.
Any thoughts, guys?

Sergii

Re: Crash in any GUI app

[Sergii Stoian]

Hi, Riccardo!

> On 17 Dec 2019, at 00:57, Riccardo Mottola  wrote:
> 
> Hi!
> 
> I was testing Niels gnustep-make patch and while I discovered the issue with 
> "gnu-gnu-gnu" and clang-libobjc2, I actually found out that also ng-gnu-gnu 
> is not working anymore.
> 
> On FreeBSD - amd64 / clang, I get this stacktrace:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0008013a38dc in -[GSStandardWindowDecorationView updateRects] 
> (self=0x808d66e08, _cmd=0x8018dd400)
> at GSStandardWindowDecorationView.m:98
> 98if (hasTitleBar)
> Current language:  auto; currently minimal
> (gdb) bt
> #0  0x0008013a38dc in -[GSStandardWindowDecorationView updateRects] 
> (self=0x808d66e08, _cmd=0x8018dd400)
> at GSStandardWindowDecorationView.m:98
> #1  0x0008013a46e3 in -[GSStandardWindowDecorationView 
> initWithFrame:window:] (self=0x808d66e08, _cmd=0x8018e0888,
> frame={origin = {x = 0, y = 0}, size = {width = 0, height = 0}}, 
> w=0x808fd9408)
> at GSStandardWindowDecorationView.m:167
> #2  0x0008013a67b9 in +[GSWindowDecorationView 
> newWindowDecorationViewWithFrame:window:] (self=0x808874320,
> _cmd=0x801860e38, frame={origin = {x = 0, y = 0}, size = {width = 0, 
> height = 0}}, aWindow=0x808fd9408)
> at GSWindowDecorationView.m:77
> #3  0x0008012f6862 in -[NSWindow 
> initWithContentRect:styleMask:backing:defer:] (self=0x808fd9408, 
> _cmd=0x801860b48,
> contentRect={origin = {x = 0, y = 0}, size = {width = 0, height = 0}}, 
> aStyle=64, bufferingType=0, flag=0 '\0')
> at NSWindow.m:1077
> #4  0x0008012f6c49 in -[NSWindow 
> initWithContentRect:styleMask:backing:defer:screen:] (self=0x808fd9408,
> _cmd=0x8016db960, contentRect={origin = {x = 0, y = 0}, size = {width = 
> 0, height = 0}}, aStyle=64, bufferingType=0,
> flag=0 '\0', aScreen=0x0) at NSWindow.m:1140
> #5  0x0008010c3e76 in -[NSApplication(Private) _appIconInit] 
> (self=0x808bf0e88, _cmd=0x8016db2a0)
> at NSApplication.m:3884
> #6  0x0008010ba724 in -[NSApplication _init] (self=0x808bf0e88, 
> _cmd=0x8016da940) at NSApplication.m:932
> #7  0x000801ec4c4b in -[NSObject performSelector:withObject:] ()
>from /System/Library/Libraries/libgnustep-base.so.1.27
> #8  0x000801f60546 in -[NSObject(NSThreadPerformAdditions) 
> performSelector:onThread:withObject:waitUntilDone:modes:]
> () from /System/Library/Libraries/libgnustep-base.so.1.27
> #9  0x000801f60256 in -[NSObject(NSThreadPerformAdditions) 
> performSelectorOnMainThread:withObject:waitUntilDone:modes:] () from 
> /System/Library/Libraries/libgnustep-base.so.1.27
> #10 0x000801f602d1 in -[NSObject(NSThreadPerformAdditions) 
> performSelectorOnMainThread:withObject:waitUntilDone:] ()
>from /System/Library/Libraries/libgnustep-base.so.1.27
> #11 0x0008010baa7f in -[NSApplication init] (self=0x808bf0e88, 
> _cmd=0x8016db180) at NSApplication.m:986
> #12 0x0008010ba300 in +[NSApplication sharedApplication] 
> (self=0x808ac57a0, _cmd=0x8016c58c0) at NSApplication.m:858
> #13 0x000801091ccd in NSApplicationMain (argc=1, argv=0x7fffe7b0) at 
> Functions.m:78
> 
> 
> I don't think this has any relations to the runtime options checking, hasn't 
> it?
> 
> Riccardo
> 

I seems like old fixed bug in libobjc2. Look here 
https://github.com/gnustep/libobjc2/issues/96 
.
What version of libobjc2 are you using?

Sergii

Re: Embedded blocks...

[Sergii Stoian]

On Oct 29, 2019, at 15:43, David Chisnall  wrote:

> On 29/10/2019 13:18, Ivan Vučica wrote:
>> Naive question: What’s the problem #ifdefing out the code that depends on 
>> blocks when building on gcc?
> 
> Locally?  Not much.  It means that anyone using clang and a GCC-built GNUstep 
> will have some surprises, but they probably will anyway because the GCC code 
> will support the (very) old ABI and not be useable with modern Objective-C 
> anyway.
> 
> Globally?  It means that we can't take advantage of things like ARC and 
> blocks usefully across GNUstep.  Both have significant developer productivity 
> wins, as does Objective-C++ (which mostly works with recent GCC, but still 
> has some quite rough edges).  If we have loads of developers with ample time 
> and aren't worried about the fact that it's hard to recruit new Objective-C 
> programmers when we force them to use a decade-old version of the language, 
> then that's not an issue either.
> 
> I haven't done much Objective-C recently, but the last time I did I found 
> that I could write about a quarter of the code in Objective-C++[1] with ARC 
> than I'd had to write in Objective-C with retain / release (and got smaller 
> and faster binaries).  After that experience, there's no way that I'd go back 
> to writing the kind of code that GNUstep requires.
> 
> David
> 
> [1] I have a small set of helpers that improve interop:
> 
> - C++ wrappers for -hash, -compare: and -isEqual: that let me use Objective-C 
> objects in C++ collections.
> 
> - A get<> template that calls a -{foo}Value method based on the type (e.g. 
> get(id x) -> [x intValue]).  This allows me to write other C++ templates 
> that convert Objective-C objects to other types usefully.
> 
> - Wrappers for NSString and NSIndexSet that use the native range accessors to 
> implement C++ iterators, so these can be used with range-based for loops 
> (e.g. for (NSUInteger i : {some NSIndexSet}).
> 
> - An RIAA wrapper for posting KVO notifications.  Posts the will-change 
> notification on construction and the did-change notification on destruction, 
> so I never accidentally fail to send one of the pair.
> 
> I also make heavy use of a number of Objective-C features that GCC doesn't 
> support:
> 
> - Generics (type erasing, but they catch simple compile-time type errors).
> 
> - Array and dictionary literals.
> 
> - Blocks
> 
> - ARC
> 
> - Private ivar definitions in the @implementation context.
> 
> All of these either improve my productivity, increase the quality of the 
> code, or both.
> 

I absolutely agree with you, David. 
IMHO political motifs shouldn’t constrain technical decisions (besides licence, 
of course).
Moreover using these nice Objective-C 2.0 features make GNUstep code look much 
more familiar to potential macOS/iOS developers.

Sergii

Re: Commit access?

[Sergii Stoian]

Got it, thank you.

If I understand correctly, even if I have push permissions to GNUstep
repos, the good practice is to create PR before push/merge into head.
Is it correct for all cases or some simple ones may be pushed without PR?

On Wed, Aug 21, 2019 at 1:37 AM Gregory Casamento 
wrote:

> Sergii, What is your github account?
>
> On Tue, Aug 20, 2019 at 18:26 Gregory Casamento 
> wrote:
>
>> If anyone else has signed copyright assignments please let me know your
>> GitHub ids.  This way I can add everyone.
>>
>> On Tue, Aug 20, 2019 at 18:24 Gregory Casamento 
>> wrote:
>>
>>> Sure.  Give me a few minutes.
>>>
>>> On Tue, Aug 20, 2019 at 17:51 Sergii Stoian  wrote:
>>>
>>>> Hi Gregory,
>>>>
>>>> I have signed copyright assignment in 2001. Could you please add me to
>>>> the organization? :)
>>>>
>>>> On Mon, Aug 19, 2019 at 10:12 AM Gregory Casamento <
>>>> greg.casame...@gmail.com> wrote:
>>>>
>>>>> Marcus,
>>>>>
>>>>> I have added you to the organization. :)
>>>>>
>>>>> GC
>>>>>
>>>>> On Mon, Aug 19, 2019 at 2:54 AM Gregory Casamento <
>>>>> greg.casame...@gmail.com> wrote:
>>>>>
>>>>>> We have a copyright assignment on file for Marcus Mueller.  I can add
>>>>>> you, Marcus.  I’ll do that in a few minutes.
>>>>>>
>>>>>> On Fri, Aug 16, 2019 at 12:24 Fred Kiefer  wrote:
>>>>>>
>>>>>>> Hi Marcus,
>>>>>>>
>>>>>>> the simplest thing to do until you get commit access is to fork the
>>>>>>> GNUstep repository into yours and work with pull requests. I will be 
>>>>>>> able
>>>>>>> to merge these but won’t be able to add you as a member.
>>>>>>>
>>>>>>> Fred
>>>>>>>
>>>>>>> > Am 16.08.2019 um 17:57 schrieb Marcus Müller <
>>>>>>> z...@mulle-kybernetik.com>:
>>>>>>> >
>>>>>>> > Hi Devs,
>>>>>>> >
>>>>>>> > I have some trivial compile fixes for FreeBSD that I wanted to
>>>>>>> commit, but just found out that I never received an invite to the 
>>>>>>> GNUstep
>>>>>>> organization on GitHub (after the move from Savannah). Could someone 
>>>>>>> please
>>>>>>> invite me? I'm [znek](https://github.com/znek) on GitHub.
>>>>>>> >
>>>>>>> >
>>>>>>> > Best,
>>>>>>> >
>>>>>>> >   Marcus
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> Gnustep-dev mailing list
>>>>>>> Gnustep-dev@gnu.org
>>>>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>>>>>
>>>>>> --
>>>>>> Gregory Casamento
>>>>>> GNUstep Lead Developer / OLC, Principal Consultant
>>>>>> http://www.gnustep.org - http://heronsperch.blogspot.com
>>>>>> http://ind.ie/phoenix/
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Gregory Casamento
>>>>> GNUstep Lead Developer / OLC, Principal Consultant
>>>>> http://www.gnustep.org - http://heronsperch.blogspot.com
>>>>> http://ind.ie/phoenix/
>>>>> ___
>>>>> Gnustep-dev mailing list
>>>>> Gnustep-dev@gnu.org
>>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergii Stoian,
>>>> ProjectCenter lead developer
>>>> NEXTSPACE owner, lead developer
>>>>
>>> --
>>> Gregory Casamento
>>> GNUstep Lead Developer / OLC, Principal Consultant
>>> http://www.gnustep.org - http://heronsperch.blogspot.com
>>> http://ind.ie/phoenix/
>>>
>> --
>> Gregory Casamento
>> GNUstep Lead Developer / OLC, Principal Consultant
>> http://www.gnustep.org - http://heronsperch.blogspot.com
>> http://ind.ie/phoenix/
>>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/
>


-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Commit access?

[Sergii Stoian]

https://github.com/trunkmaster

On Wed, Aug 21, 2019 at 1:37 AM Gregory Casamento 
wrote:

> Sergii, What is your github account?
>
> On Tue, Aug 20, 2019 at 18:26 Gregory Casamento 
> wrote:
>
>> If anyone else has signed copyright assignments please let me know your
>> GitHub ids.  This way I can add everyone.
>>
>> On Tue, Aug 20, 2019 at 18:24 Gregory Casamento 
>> wrote:
>>
>>> Sure.  Give me a few minutes.
>>>
>>> On Tue, Aug 20, 2019 at 17:51 Sergii Stoian  wrote:
>>>
>>>> Hi Gregory,
>>>>
>>>> I have signed copyright assignment in 2001. Could you please add me to
>>>> the organization? :)
>>>>
>>>> On Mon, Aug 19, 2019 at 10:12 AM Gregory Casamento <
>>>> greg.casame...@gmail.com> wrote:
>>>>
>>>>> Marcus,
>>>>>
>>>>> I have added you to the organization. :)
>>>>>
>>>>> GC
>>>>>
>>>>> On Mon, Aug 19, 2019 at 2:54 AM Gregory Casamento <
>>>>> greg.casame...@gmail.com> wrote:
>>>>>
>>>>>> We have a copyright assignment on file for Marcus Mueller.  I can add
>>>>>> you, Marcus.  I’ll do that in a few minutes.
>>>>>>
>>>>>> On Fri, Aug 16, 2019 at 12:24 Fred Kiefer  wrote:
>>>>>>
>>>>>>> Hi Marcus,
>>>>>>>
>>>>>>> the simplest thing to do until you get commit access is to fork the
>>>>>>> GNUstep repository into yours and work with pull requests. I will be 
>>>>>>> able
>>>>>>> to merge these but won’t be able to add you as a member.
>>>>>>>
>>>>>>> Fred
>>>>>>>
>>>>>>> > Am 16.08.2019 um 17:57 schrieb Marcus Müller <
>>>>>>> z...@mulle-kybernetik.com>:
>>>>>>> >
>>>>>>> > Hi Devs,
>>>>>>> >
>>>>>>> > I have some trivial compile fixes for FreeBSD that I wanted to
>>>>>>> commit, but just found out that I never received an invite to the 
>>>>>>> GNUstep
>>>>>>> organization on GitHub (after the move from Savannah). Could someone 
>>>>>>> please
>>>>>>> invite me? I'm [znek](https://github.com/znek) on GitHub.
>>>>>>> >
>>>>>>> >
>>>>>>> > Best,
>>>>>>> >
>>>>>>> >   Marcus
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> Gnustep-dev mailing list
>>>>>>> Gnustep-dev@gnu.org
>>>>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>>>>>
>>>>>> --
>>>>>> Gregory Casamento
>>>>>> GNUstep Lead Developer / OLC, Principal Consultant
>>>>>> http://www.gnustep.org - http://heronsperch.blogspot.com
>>>>>> http://ind.ie/phoenix/
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Gregory Casamento
>>>>> GNUstep Lead Developer / OLC, Principal Consultant
>>>>> http://www.gnustep.org - http://heronsperch.blogspot.com
>>>>> http://ind.ie/phoenix/
>>>>> ___
>>>>> Gnustep-dev mailing list
>>>>> Gnustep-dev@gnu.org
>>>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Sergii Stoian,
>>>> ProjectCenter lead developer
>>>> NEXTSPACE owner, lead developer
>>>>
>>> --
>>> Gregory Casamento
>>> GNUstep Lead Developer / OLC, Principal Consultant
>>> http://www.gnustep.org - http://heronsperch.blogspot.com
>>> http://ind.ie/phoenix/
>>>
>> --
>> Gregory Casamento
>> GNUstep Lead Developer / OLC, Principal Consultant
>> http://www.gnustep.org - http://heronsperch.blogspot.com
>> http://ind.ie/phoenix/
>>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/
>


-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Commit access?

[Sergii Stoian]

Hi Gregory,

I have signed copyright assignment in 2001. Could you please add me to the
organization? :)

On Mon, Aug 19, 2019 at 10:12 AM Gregory Casamento 
wrote:

> Marcus,
>
> I have added you to the organization. :)
>
> GC
>
> On Mon, Aug 19, 2019 at 2:54 AM Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
>> We have a copyright assignment on file for Marcus Mueller.  I can add
>> you, Marcus.  I’ll do that in a few minutes.
>>
>> On Fri, Aug 16, 2019 at 12:24 Fred Kiefer  wrote:
>>
>>> Hi Marcus,
>>>
>>> the simplest thing to do until you get commit access is to fork the
>>> GNUstep repository into yours and work with pull requests. I will be able
>>> to merge these but won’t be able to add you as a member.
>>>
>>> Fred
>>>
>>> > Am 16.08.2019 um 17:57 schrieb Marcus Müller <
>>> z...@mulle-kybernetik.com>:
>>> >
>>> > Hi Devs,
>>> >
>>> > I have some trivial compile fixes for FreeBSD that I wanted to commit,
>>> but just found out that I never received an invite to the GNUstep
>>> organization on GitHub (after the move from Savannah). Could someone please
>>> invite me? I'm [znek](https://github.com/znek) on GitHub.
>>> >
>>> >
>>> > Best,
>>> >
>>> >   Marcus
>>>
>>>
>>> ___
>>> Gnustep-dev mailing list
>>> Gnustep-dev@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>>>
>> --
>> Gregory Casamento
>> GNUstep Lead Developer / OLC, Principal Consultant
>> http://www.gnustep.org - http://heronsperch.blogspot.com
>> http://ind.ie/phoenix/
>>
>
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>


-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: PCButton - tracking rect

[Sergii Stoian]

Hi Fred,

On Wed, May 22, 2019 at 10:39 AM Fred Kiefer  wrote:

>
>
> > Am 22.05.2019 um 08:53 schrieb Riccardo Mottola <
> riccardo.mott...@libero.it>:
> >
> > Sergii Stoian wrote:
> >> I've wrote tooltips for ProjectCenter PCButton's implementation. After
> that someone has copied this implementation into NSView.
> >> I looked into ProjectCenter sources long time ago. I was convinced that
> PCButton's private tooltips implementation was replaced with NSView's.
> >
> > I removed the custom ToolTip implementation in PCButton and removed the
> custom stuff. Now, very little of PCButton remains, just some graphic
> settings, essentially.
> >
> > The good news is that it works as before.
> >
> > The bad news is that there were certain bugs in the tooltips and they
> remain :) This means.. that the NSView implementation has taken them over 1
> to 1.
> >
> > With windowmaker, some tooltips work, sometimes they don't show, the
> behaviour is
> > - move pointer over button
> > - TT doesn't show
> > - while it doesn't show, the WindowMaker icon gets grey (looses
> Application Icon) and sometimes even jumps (focus lost?)
> > - slight mouse move over the same "target", ToolTip appears and
> WindowMaker shows app icon again, everything fixed
> >
> > I remember discussing this a while back with Fred. Do you notice that
> too? I'm testing with ProjectCenter, I will look for other apps that have
> tooltips, but now PC should be really "standard“.
>
> If I remember correctly the reason for the described behaviour is that the
> tooltip window shows up, but is behind the normal window. This sadly is a
> rather general issue in GNUstep we don’t get the window manager to agree on
> the window stacking.


Do you mean NSWindow.h changes (
https://github.com/gnustep/libs-gui/pull/24/files)? My local setup has this
window level (see below, it differs from master version) and I don't see
any problems right now. Do you?
enum {
// OPENSTEP  // MacOS  // GNUstep
  NSDesktopWindowLevel = -1000, // --// 2  // -1000
  NSNormalWindowLevel  = 0, // 0 // 3  // 0
  NSFloatingWindowLevel= 3, // 3 // 4  // 3
  NSDockWindowLevel= 5, // 5 // 6  // 21
  NSSubmenuWindowLevel = 10,// 10// 5  // 3
  NSTornOffMenuWindowLevel = 10,// --// 5  // 3
  NSMainMenuWindowLevel= 20,// 20// 7  // 20
  NSStatusWindowLevel  = 21,    // --    // 8  // 21
  NSModalPanelWindowLevel  = 100,   // --// 9  // 100
  NSPopUpMenuWindowLevel   = 101,   // --// 10 // 101
  NSScreenSaverWindowLevel = 1000   // --// 12 // 1000
};

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: PCButton - tracking rect

[Sergii Stoian]

Hi Riccardo,

On Wed, May 22, 2019 at 9:53 AM Riccardo Mottola 
wrote:

> Hi Sergii,
>
> Sergii Stoian wrote:
> > I've wrote tooltips for ProjectCenter PCButton's implementation. After
> > that someone has copied this implementation into NSView.
> > I looked into ProjectCenter sources long time ago. I was convinced
> > that PCButton's private tooltips implementation was replaced with
> > NSView's.
>
> I removed the custom ToolTip implementation in PCButton and removed the
> custom stuff. Now, very little of PCButton remains, just some graphic
> settings, essentially.
>
> The good news is that it works as before.
>

Great.

The bad news is that there were certain bugs in the tooltips and they
> remain :) This means.. that the NSView implementation has taken them
> over 1 to 1.
>

That's it.

With windowmaker, some tooltips work, sometimes they don't show, the
> behaviour is
> - move pointer over button
> - TT doesn't show
>

In my case, TT moves with mouse cursor (as it should).

- while it doesn't show, the WindowMaker icon gets grey (looses
> Application Icon) and sometimes even jumps (focus lost?)
>

I didn't quite understand what you mean by "gets gray" - it becomes
stippled/highlighted as when application starts, just tile remains without
application icon or appicon completely disappears?

- slight mouse move over the same "target", ToolTip appears and
> WindowMaker shows app icon again, everything fixed
>

I can't reproduce it. But my setup:
- based on gui/back 0.25.0
- use ART backend;
- parts of WindowMaker I've incorporated into NEXTSPACE's Workspace
contains my fixes and enhancements (including focus handling area);
What is your setup? Could you try to reproduce this with ART backend?
If you use master branch of gui/back you should observe problems with text
drawing (0.25.1 includes NSStringDrawing rewrite and broke ART in that
area) but window management should be OK.
I'm afraid I need a couple of weeks to create alternate setup. I'm busy
with preparing of NEXTSPACE 0.85 release now.

I remember discussing this a while back with Fred. Do you notice that
> too? I'm testing with ProjectCenter, I will look for other apps that
> have tooltips, but now PC should be really "standard".
>

If I remember correctly, we discussed appicon flickering here
https://github.com/gnustep/libs-gui/pull/27.
Also I've changed my WM to not withdrawn/map appicon every time new windows
appears in application.
Anyways it was fix to appicon flickering with Cairo backend. Flickering was
not observed with ART before and after my changes.


> Riccardo
>

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE creator, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: PCButton - tracking rect

[Sergii Stoian]

Hi Riccardo,

I've wrote tooltips for ProjectCenter PCButton's implementation. After that
someone has copied this implementation into NSView.
I looked into ProjectCenter sources long time ago. I was convinced that
PCButton's private tooltips implementation was replaced with NSView's.


On Mon, May 20, 2019 at 1:45 AM Riccardo Mottola 
wrote:

> Hi all,
>
>
> in ProjectCenter's PCButton access to private ivar _tracking_rects is
> done (actually in our header it is PACKAGE_SCOPE , I don't know exactly,
> but it must translate into private).
>
> How could I avoid that? apparently it is a hard error on latest clang,
> but it is ugly anyway.
>
> I found no public method for accessing it.
>
>
> Apparently, this is all done for tooltip management... I wonder if it is
> needed at all, I don't understand what the code is doing special there,
> don't have Buttons standard toolitps?
>
>
> Thank you,
>
> Riccardo
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>


-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: issue compiling Back (undeclared identifier)

[Sergii Stoian]

Hi, Riccardo

You need to recompile reinstall libs-gui from master branch.
`GSAppKitAppHide` is defined in AppKit/NSEvent.h

On Wed, Apr 17, 2019 at 1:53 AM Riccardo Mottola 
wrote:

> Hi,
>
> on the same FreeBSD/amd64 - clang setup, I get an undeclared itendifier
>
>   Compiling file XGServerEvent.m ...
> XGServerEvent.m:730:52: error: use of undeclared identifier
> 'GSAppKitAppHide'
>subtype: GSAppKitAppHide
> ^
> 1 error generated.
> gmake[5]: *** [/System/Library/Makefiles/rules.make:479:
> obj/x11.obj/XGServerEvent.m.o] Error 1
>
>
> It is apparently introduced by commit
> b492ac87cd07046c8d9ca88fcb5e9bb44e39c32c of 5 April. How does it compile
> for others?
>
> Riccardo
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>


-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Commit process to source tree on github

[Sergii Stoian]

Thank you, Fred. I didn't look at the -back yet. Probably, later I'll need
some info about changes you've made.
I'll start with some easier pull requests.


On Mon, Mar 25, 2019 at 12:44 AM Fred Kiefer  wrote:

> Wow, that is an impressive list. I really look forward to review your
> patches. As you probably already noticed I did rework the way we access X
> atoms in back, your old patches will need a bit of a rewrite but that
> shouldn’t be too complicated I hope. If you need any help with that (or
> other stuff) feel free to contact me directly.
>
> Thank you!
> Fred
>
>
> > Am 23.03.2019 um 22:51 schrieb Sergii Stoian :
> >
> > Hi Fred,
> >
> > Thank you. As I've replied to David, I tend to push trivial patches
> directly to HEAD. More complex I'll create as a pull request so we can
> discuss details before merge.
> >
> > Answering your last question: I have a set of tested changes to older
> GNUstep release (you may find them here
> https://github.com/trunkmaster/nextspace/tree/master/Libraries/gnustep).
> > I want to include these changes into current release of GNUstep. The
> main areas are:
> > - focus management and window manager interaction (hide application,
> minimize window), mouse click on titlebar, appicon, inside window;
> > - mouse properties: configurable double-click time, line scroll
> multiplier, left/right menu button (some details:
> https://github.com/trunkmaster/nextspace/issues/8);
> > - applications "-autolaunch" behaviour: do not show menus and do not
> steal focus;
> > - mouse cursors: I've created a cursor theme which is fully compatible
> to Awaita (standard `de facto` I guess). You may find my thoughs here:
> https://github.com/trunkmaster/nextspace/wiki/Mouse-Cursors;
> >
> > Also I have several trivial patches:
> > - prevent blinking of appicon on focus switch/appicon double-click. It's
> quite noticable with cairo backend;
> > - Font panel weird look and feel on WM (no resize bar, items must be
> clicked higher then it drawn)
> > - use title image in miniwindow
> > - etc.
> >
> > In long-term I want to adopt cairo backend as default for NEXTSPACE. I
> want to move some functionality from ART backend.
> > For example, I'd like to have an option and support of font packages
> (.nfont).
> > I want to polish UI: some elements draw lines as gray instead of black
> (I know about half-pixel problem).
> > I'd like to test and enhance NSBrowser behavior. I want to implement
> display resolution changes adoption at backend level. May high DPI some
> day...
> >
> > On Sat, Mar 23, 2019 at 12:05 PM Fred Kiefer  wrote:
> > Hi Sergii,
> >
> > having a pull request to review and approve is always the nicer way to
> work with patches. But if this is too much hassle for you feel free to do a
> direct commit or even to send a patch file to the mailing list. Which area
> are you planing to work on?
> >
> > Cheers,
> > Fred
> >
> > On the road
> >
> > Am 23.03.2019 um 01:42 schrieb Sergii Stoian :
> >
> >> Hello everybody,
> >>
> >> I plan to commit some changes/fixes to GUI and Back.
> >> My last GNUstep commit was long time ago to SVN at gna.org. I'm
> familiar with git and github.
> >>
> >> My question is: what is the correct way to submit patches/fixes?
> >> Should it be a pull request for approval?
> >> May I commit directly to the source tree on github?
> >>
> >> --
> >> Sergii Stoian,
> >> ProjectCenter lead developer
> >> NEXTSPACE owner, lead developer
> >> ___
> >> Gnustep-dev mailing list
> >> Gnustep-dev@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/gnustep-dev
> >
> >
> > --
> > Sergii Stoian,
> > ProjectCenter lead developer
> > NEXTSPACE owner, lead developer
> > ___
> > Gnustep-dev mailing list
> > Gnustep-dev@gnu.org
> > https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Commit process to source tree on github

[Sergii Stoian]

Ivan,

I've just checked my write permission to the libs-base: "Permission to
gnustep/libs-base.git denied to trunkmaster."
It is a trivial change to Resources/Languages/Ukrainian.
Although I see myself as `trunkmaster` in 'Contributors' (by email, I
guess?). My SVN username was 'stoyan'.
Can I have my write permissions back?

BTW, does ChangeLog file entries somewhat generated from git log now or
still should be written manually?

On Sun, Mar 24, 2019 at 10:27 PM Ivan Vučica  wrote:

> I usually create a fork if I need a PR.
>
> By the way, maybe I misunderstood; if you do have push access already and
> you think something is really, really trivial, go ahead and push small
> changes. :-)
>
> On Sun, Mar 24, 2019, 01:18 Sergii Stoian  wrote:
>
>> Hi Ivan,
>>
>> On Sun, Mar 24, 2019 at 2:34 AM Ivan Vučica  wrote:
>>
>>> From experience outside GNUstep: I don't think it's necessarily a bad
>>> practice to do code review on every commit going in (including
>>> trivial), even among core devs. It's perhaps a shame we're not
>>> enforcing code review for /every/ submission.
>>>
>>> Anyway, I think each of the improvements sounds good -- I think it's
>>> very good to upstream your changes, so thank you for doing this. They
>>> do sound like something where it might be a good idea for a second eye
>>> to take a quick look? (I know I wouldn't mind having someone take a
>>> look at my changes, when I make them, as even trivial ones could break
>>> things.)
>>>
>> I understand your concerns absolutely. Everybody make a mistakes. :)
>> Although there are some corner cases were I'll take a courage to commit
>> directly.
>> For example, Ukrainian translation file. Is it OK?
>>
>>>
>>> How about we try with PRs for these (incl for trivial changes) and
>>> then look at flipping the permissions switch for you?
>>>
>> It's good if it's make GNUstep code quality better.
>> I'm a GNUstep developer since 2001, if I recall correctly (including
>> paper signing from FSF).
>> Moreover, I'm a perfectionist for quality in code and feel of a UI/UX.
>> I don't know if somebody else here is everyday user of GNUstep codebase
>> as me (I use NEXTSPACE as production environment for a several months).
>> If something goes wrong I'll see it immediately. :)
>>
>> Anyway, I'll agree with you and will start creating PRs.
>> Do I need to create branch or fork? What would your recommend?
>>
>>>
>>> Once again, thank you for offering these patches!
>>>
>>> On Sat, Mar 23, 2019 at 9:52 PM Sergii Stoian 
>>> wrote:
>>> >
>>> > Hi Fred,
>>> >
>>> > Thank you. As I've replied to David, I tend to push trivial patches
>>> directly to HEAD. More complex I'll create as a pull request so we can
>>> discuss details before merge.
>>> >
>>> > Answering your last question: I have a set of tested changes to older
>>> GNUstep release (you may find them here
>>> https://github.com/trunkmaster/nextspace/tree/master/Libraries/gnustep).
>>> > I want to include these changes into current release of GNUstep. The
>>> main areas are:
>>> > - focus management and window manager interaction (hide application,
>>> minimize window), mouse click on titlebar, appicon, inside window;
>>> > - mouse properties: configurable double-click time, line scroll
>>> multiplier, left/right menu button (some details:
>>> https://github.com/trunkmaster/nextspace/issues/8);
>>> > - applications "-autolaunch" behaviour: do not show menus and do not
>>> steal focus;
>>> > - mouse cursors: I've created a cursor theme which is fully compatible
>>> to Awaita (standard `de facto` I guess). You may find my thoughs here:
>>> https://github.com/trunkmaster/nextspace/wiki/Mouse-Cursors;
>>> >
>>> > Also I have several trivial patches:
>>> > - prevent blinking of appicon on focus switch/appicon double-click.
>>> It's quite noticable with cairo backend;
>>> > - Font panel weird look and feel on WM (no resize bar, items must be
>>> clicked higher then it drawn)
>>> > - use title image in miniwindow
>>> > - etc.
>>> >
>>> > In long-term I want to adopt cairo backend as default for NEXTSPACE. I
>>> want to move some functionality from ART backend.
>>> > For example, I&

Re: Commit process to source tree on github

[Sergii Stoian]

Hi Ivan,

On Sun, Mar 24, 2019 at 2:34 AM Ivan Vučica  wrote:

> From experience outside GNUstep: I don't think it's necessarily a bad
> practice to do code review on every commit going in (including
> trivial), even among core devs. It's perhaps a shame we're not
> enforcing code review for /every/ submission.
>
> Anyway, I think each of the improvements sounds good -- I think it's
> very good to upstream your changes, so thank you for doing this. They
> do sound like something where it might be a good idea for a second eye
> to take a quick look? (I know I wouldn't mind having someone take a
> look at my changes, when I make them, as even trivial ones could break
> things.)
>
I understand your concerns absolutely. Everybody make a mistakes. :)
Although there are some corner cases were I'll take a courage to commit
directly.
For example, Ukrainian translation file. Is it OK?

>
> How about we try with PRs for these (incl for trivial changes) and
> then look at flipping the permissions switch for you?
>
It's good if it's make GNUstep code quality better.
I'm a GNUstep developer since 2001, if I recall correctly (including paper
signing from FSF).
Moreover, I'm a perfectionist for quality in code and feel of a UI/UX.
I don't know if somebody else here is everyday user of GNUstep codebase as
me (I use NEXTSPACE as production environment for a several months).
If something goes wrong I'll see it immediately. :)

Anyway, I'll agree with you and will start creating PRs.
Do I need to create branch or fork? What would your recommend?

>
> Once again, thank you for offering these patches!
>
> On Sat, Mar 23, 2019 at 9:52 PM Sergii Stoian  wrote:
> >
> > Hi Fred,
> >
> > Thank you. As I've replied to David, I tend to push trivial patches
> directly to HEAD. More complex I'll create as a pull request so we can
> discuss details before merge.
> >
> > Answering your last question: I have a set of tested changes to older
> GNUstep release (you may find them here
> https://github.com/trunkmaster/nextspace/tree/master/Libraries/gnustep).
> > I want to include these changes into current release of GNUstep. The
> main areas are:
> > - focus management and window manager interaction (hide application,
> minimize window), mouse click on titlebar, appicon, inside window;
> > - mouse properties: configurable double-click time, line scroll
> multiplier, left/right menu button (some details:
> https://github.com/trunkmaster/nextspace/issues/8);
> > - applications "-autolaunch" behaviour: do not show menus and do not
> steal focus;
> > - mouse cursors: I've created a cursor theme which is fully compatible
> to Awaita (standard `de facto` I guess). You may find my thoughs here:
> https://github.com/trunkmaster/nextspace/wiki/Mouse-Cursors;
> >
> > Also I have several trivial patches:
> > - prevent blinking of appicon on focus switch/appicon double-click. It's
> quite noticable with cairo backend;
> > - Font panel weird look and feel on WM (no resize bar, items must be
> clicked higher then it drawn)
> > - use title image in miniwindow
> > - etc.
> >
> > In long-term I want to adopt cairo backend as default for NEXTSPACE. I
> want to move some functionality from ART backend.
> > For example, I'd like to have an option and support of font packages
> (.nfont).
> > I want to polish UI: some elements draw lines as gray instead of black
> (I know about half-pixel problem).
> > I'd like to test and enhance NSBrowser behavior. I want to implement
> display resolution changes adoption at backend level. May high DPI some
> day...
> >
> > On Sat, Mar 23, 2019 at 12:05 PM Fred Kiefer  wrote:
> >>
> >> Hi Sergii,
> >>
> >> having a pull request to review and approve is always the nicer way to
> work with patches. But if this is too much hassle for you feel free to do a
> direct commit or even to send a patch file to the mailing list. Which area
> are you planing to work on?
> >>
> >> Cheers,
> >> Fred
> >>
> >> On the road
> >>
> >> Am 23.03.2019 um 01:42 schrieb Sergii Stoian :
> >>
> >> Hello everybody,
> >>
> >> I plan to commit some changes/fixes to GUI and Back.
> >> My last GNUstep commit was long time ago to SVN at gna.org. I'm
> familiar with git and github.
> >>
> >> My question is: what is the correct way to submit patches/fixes?
> >> Should it be a pull request for approval?
> >> May I commit directly to the source tree on github?
> >>
> >> --
> >&g

Re: Commit process to source tree on github

[Sergii Stoian]

Hi Fred,

Thank you. As I've replied to David, I tend to push trivial patches
directly to HEAD. More complex I'll create as a pull request so we can
discuss details before merge.

Answering your last question: I have a set of tested changes to older
GNUstep release (you may find them here
https://github.com/trunkmaster/nextspace/tree/master/Libraries/gnustep).
I want to include these changes into current release of GNUstep. The main
areas are:
- focus management and window manager interaction (hide application,
minimize window), mouse click on titlebar, appicon, inside window;
- mouse properties: configurable double-click time, line scroll multiplier,
left/right menu button (some details:
https://github.com/trunkmaster/nextspace/issues/8);
- applications "-autolaunch" behaviour: do not show menus and do not steal
focus;
- mouse cursors: I've created a cursor theme which is fully compatible to
Awaita (standard `de facto` I guess). You may find my thoughs here:
https://github.com/trunkmaster/nextspace/wiki/Mouse-Cursors;

Also I have several trivial patches:
- prevent blinking of appicon on focus switch/appicon double-click. It's
quite noticable with cairo backend;
- Font panel weird look and feel on WM (no resize bar, items must be
clicked higher then it drawn)
- use title image in miniwindow
- etc.

In long-term I want to adopt cairo backend as default for NEXTSPACE. I want
to move some functionality from ART backend.
For example, I'd like to have an option and support of font packages
(.nfont).
I want to polish UI: some elements draw lines as gray instead of black (I
know about half-pixel problem).
I'd like to test and enhance NSBrowser behavior. I want to implement
display resolution changes adoption at backend level. May high DPI some
day...

On Sat, Mar 23, 2019 at 12:05 PM Fred Kiefer  wrote:

> Hi Sergii,
>
> having a pull request to review and approve is always the nicer way to
> work with patches. But if this is too much hassle for you feel free to do a
> direct commit or even to send a patch file to the mailing list. Which area
> are you planing to work on?
>
> Cheers,
> Fred
>
> On the road
>
> Am 23.03.2019 um 01:42 schrieb Sergii Stoian :
>
> Hello everybody,
>
> I plan to commit some changes/fixes to GUI and Back.
> My last GNUstep commit was long time ago to SVN at gna.org. I'm familiar
> with git and github.
>
> My question is: what is the correct way to submit patches/fixes?
> Should it be a pull request for approval?
> May I commit directly to the source tree on github?
>
> --
> Sergii Stoian,
> ProjectCenter lead developer
> NEXTSPACE owner, lead developer
>
> _______
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Commit process to source tree on github

[Sergii Stoian]

Hi,

Thank you, David. I understand that nontrivial changes need review and test.
Sure, for such changes I plan to create PR with detailed description.

On Sat, Mar 23, 2019 at 11:57 AM David Chisnall 
wrote:

> Hi,
>
> The best thing to do for nontrivial changes (even if you do have commit
> access) is send a PR, because then someone can do pre-commit review.
>
> David
>
> On 23 Mar 2019, at 00:42, Sergii Stoian  wrote:
>
> Hello everybody,
>
> I plan to commit some changes/fixes to GUI and Back.
> My last GNUstep commit was long time ago to SVN at gna.org. I'm familiar
> with git and github.
>
> My question is: what is the correct way to submit patches/fixes?
> Should it be a pull request for approval?
> May I commit directly to the source tree on github?
>
> --
> Sergii Stoian,
> ProjectCenter lead developer
> NEXTSPACE owner, lead developer
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>
>

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Commit process to source tree on github

[Sergii Stoian]

Hello everybody,

I plan to commit some changes/fixes to GUI and Back.
My last GNUstep commit was long time ago to SVN at gna.org. I'm familiar
with git and github.

My question is: what is the correct way to submit patches/fixes?
Should it be a pull request for approval?
May I commit directly to the source tree on github?

-- 
Sergii Stoian,
ProjectCenter lead developer
NEXTSPACE owner, lead developer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Cairo font configuration

[Sergii Stoian]

Hi Fred,

On Sun, Nov 26, 2017 at 1:48 PM, Fred Kiefer  wrote:

> Hi Ivan,
>
> I think we are all on this list for this reason I reduced the recipients
> list.
>
> Of course cairo uses fontconfig when available. The problem Sergei and
> Riccardo are talking about really exists and it is caused by a known bug in
> the cairo handing of fixed fonts. That is the reason why terminal gets
> mentioned. There fixed fonts are still popular.
> The issue is cairo is reusing and scaling a fixed font even if there is a
> proper version available for the required size. The only workaround I see,
> beside fixing inside of cairo, is to not reuse fixed fonts. But this is to
> costly, rather we would need our own cache for these fonts, duplicating the
> cairo code.
> I could send you references of the relevant cairo and GNUstep code as soon
> as I am back home.
>
> Writing about .nfont packages used in ART backend I meant not only this.
For example, RobotoMono font looks quite weird without antialiasing
(hinting?), LiberationMono looks good. With .nfont package for RobotoMono
I've added "RenderHints_hack = 0x010203;" and after user copy this package
into it's ~/Library/Fonts directory everything works as font package
creator think should be better for user. Liberation Mono has no
"RenderHints_hack" at all. Everybody is happy.
If I want RobotoMono to be drawn antialiased at any size and other fonts
non-antialiased at size less then 12 I need to add configuration (system or
user) on font install.
Sure both ways has right to live but fontconfig way breaks NeXT/Apple style
of doing things that GNUstep follows to.
Did I miss something?

> Fred
>
> On the road
>
> Am 26.11.2017 um 12:26 schrieb Ivan Vučica :
>
>
>
> On Sun, Nov 26, 2017, 09:50 Riccardo Mottola 
> wrote:
>
>> There are some facts I don't like and want to change:
>> * NEXTSPACE is based on quite outdated release of GNUstep (base 1.24.8,
>> gui and back 0.24.1);
>> * It is based on ART backend. I want to use Cairo backend but ART has
>> usefull features (.nfont packages provide ability to set hinting and
>> antialiasing options on per font basis).
>>
>>
>> I understand that! ART continues to be intriguing and it still works
>> after many years, it is fast, fotns look better and the possibility of
>> using non-antialiased fonts is just great. They look far better in
>> Terminal, Code-Editors and for my test also Menus.
>>
>
> Doesn't Cairo use fontconfig?
>
> Or does something in the way GNUstep-back uses it make it ignore the
> fontconfig configuration?
>
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>
>


-- 
Sergii Stoian, ProjectCenter maintainer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

[INFO] NEXTSPACE

[Sergii Stoian]

Hi,

More than 15 years ago I joined the GNUstep development because I like
NeXT's OS design, look and feel. At that time my dream was to return
NeXTSTEP desktop to Linux. After 15+ years my dream still alive. I
understand that GNUstep project goals somewhat changed over these years.
And this is good until project is interesting to broad kind (goals, tastes)
of people involved in it's development.

Finally I've decided to inform dear community about my project of last 2+
years.
I've named is NEXTSPACE. It is SPACE for NeXT applications.
You can find code and brief description of project here
https://github.com/trunkmaster/nextspace.
It is not finished yet. However I use it as my desktop environment on daily
basis.
You can find RPMs in Packages directory:
* libdispatch and libobjc2
* nextspace-core - system specific files: skeleton for user home firectory,
shell profile, udev, polkit, etc.
* nextspace-gnustep - GNUstep libraries with my patches.
The next step is to build Frameworks, then Appplications. You can create
new user with all needed files inside it's home dir. You can start Login
with command 'systemctl start loginwindow' or login to newly created user
from your login application (it should start ~/.xinitrc in user home dir).
That's it.

Some noticeable achievements I've got:
* I integrated Workspace and WindowMaker into Workspace Manager. That's it
- one application. It was made possible by using libdispatch and libobjc2.
For example, when non-GNUstep application starts Workspace's Processess
panel shows it with info grabbed from WindowMaker. Another example: when
you start application by double-clicking in File Viewer and appicon already
exists in Dock icon fly from FileViewer's to docked appicon.
* In general Workspace is ready to be NSWorkspace povider.
* GNUstep and WindowMaker unified look and feel (menus and titlebars,
fonts, miniwindows).
* Media management: Workpace automatically mounts removable media inserted
(UDisks integration).
* Terminal: a lot of improvements. It's better to see it.
* -NXAutoLaunch option implemented. Now applications started with this
option doesn't show menu at all. No focus flickering. Smooth as it should
be.
* Preferences: everything you need to set up must be here. Not only GNUstep
NSGlobalDomain options (localization, fonts) but system specific options
also (display, keyboard, mouse, sound, networking).
* A lot of other things I can't recall now but I write it down someday. ;)

There are some facts I don't like and want to change:
* NEXTSPACE is based on quite outdated release of GNUstep (base 1.24.8, gui
and back 0.24.1);
* It is based on ART backend. I want to use Cairo backend but ART has
usefull features (.nfont packages provide ability to set hinting and
antialiasing options on per font basis).
* DE needs documentation. I plan to discuss NSHelpPanel implementation with
you guys. First of all we need to define format for help files.
* It is developed and tested on CentOS 7. I have no plans in near future to
port it somewhere else. I need to finish what I've started first.

PS: My apologies to community for being off the track so long. Now you know
why.
My current strategy is the following:
1. Finish NEXTSPACE to be feature rich, stable and fast. I guess this step
will be done until next summer.
2. Return to development of ProjectCenter. First of all PC badly needs good
editor, then GORM interoperation and next debugger.
I hope my work will be useful not only for me but for GNUstep project also.

-- 
Sergii Stoian, ProjectCenter maintainer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: What is wrong with this project?

[Sergii Stoian]

Fred, I'm completly understand your feelings.

Your post touched me so deeply, so I decide to write you several words (despite
the fact that I didn't write to mailing list several years). Maybe it helps
you... Maybe it helps others...

I stepped back as ProjectCenter maintainer. Stopped fixing bugs and making
because... it feels like endless and pointless work to me at some point. My
dream that drive me all these years was to have an OPENSTEP desktop
enviroment pixel to pixel and feeling to feeling.
Several last years project aims drifting to current trends in modern
desktop concepts. And It's OK until my dream may come true some day.

And I asked myself some questions:
1. Do I want to go out of project? - No, I don't.
2. What can I do to motivate myself? - I have to work on bringing my dream
to life.
3. Does my goals contarry to GNUstep project goals? - Maybe at some point.
4. What can I do to sort out these contraditions? Discuss it with
community? - Discussing is pointless. I need to write code (create OPENSTEP
desktop environment) and show it to GNUstep community when it will be
usable enough. Maybe it will become new driver/motivator for some
persons/community/project itself. Who knows...
5. How much time it will take? 5 years? 10 years? - I don't care. ;-)

So I decided to go offline and start working on point 4. And I do it for
last 2 years.
Let's analyze how Qt and GTK+ evolves during the same period of time as
GNUstep exists: Qt and GTK+ community have applications! That what toolkits
and developer tools are existing for! That is what motivate developers to
improve and fix applications which make their life easier and funnier.

Maybe it's time to sort out with your motivation(s)?
Get well. Fred (in all senses)!

On Fri, Mar 27, 2015 at 6:02 PM, Fred Kiefer  wrote:

> As most of you GNUsteppers know, I have been active in this project for
> quite some time now. Well, exactly 15 years now. Not much was functional
> at that time. What ever part of GNUstep you tried to us broke down on
> touching and needed fixing. But it was also a time of great progress. In
> a few months we got support for different fonts, better RTF and a lot
> more improvements into the primitive text handling GNUstep had at that
> time. I moved on to NSColor and NSBezierPath, which I both rewrote
> completely. Next I added a whole backend for MS Windows, just for fun.
> Later Alexander Malmberg vanished from the project, Greg became project
> leader and I ended up as maintainer of back and gui. And the years went
> by...
>
>
> Why am I writing about all this? I think it is time now for me to step
> down as the maintainer of the GNUstep back and gui packages. There are
> many reason for this move and I have been thinking about it for some
> time already. What finally triggered that decision was the experience of
> the last few days. I have been ill a bit, which stopped me from going
> out and left more time for GNUstep. I worked on a few issues and
> resolved some tiny problems. But what was the reaction on the mailing
> lists? Nothing or negative. On the days before we had for example about
> a mail per day on the window resize flickering issue. When I (partly)
> resolved it and ask for testers on the mailing list, communication on
> that topic stopped. And when it resumed again it was full of complaints
> about remaining issues that are on special hardware, deprecated backends
> or even completely unrelated.
> Or lets take another recent example. German Arias is working on
> resolving some cursor issues on MS Windows and it is great that he is
> doing so, as that platform gets little love nowadays. He send a patch to
> the mailing list and I commented on it, but didn't get a reply on that.
> Later I saw his commit, with part of my comments addressed, but others
> ignored. Why is that? I don't know and I am tiered of asking. Next he
> send a video displaying tool tips issues that a clearly caused by not
> sending mouse leave events to the window. Should I now write the same
> mail a second time?
>
> For me the feeling of progress in GNUstep is gone. And with it the fun
> of working late nights on GNUstep. And without fun GNUstep is just
> unpayed and unhonored work.
>
> I am sure Greg will come up with a perfect replacement. Somebody who is
> going to review your patches and fix your bugs a lot better than I have
> been doing lately and somebody that has fun doing so. And me? I will
> stick around quietly, maybe work on bits I wanted to fix for a long time
> now and perhaps the fun will come back.
>
> Good luck to all of you,
> Fred
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>



-- 
Sergii Stoian, ProjectCenter maintainer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Changes I've been thinking of...

[Sergii Stoian]

Richard Frith-Macdonald wrote:


On 12 Oct 2009, at 10:50, Sergii Stoian wrote:


Fred Kiefer wrote:

Sergii Stoian schrieb:

2009/10/9 Riccardo Mottola 

Many things you want do not clash with other goals, they only divert
manpower. But keep in consideration that in an opensource project 
people do
whatever they deem interesting or useful, there isn't a central 
planning.
Sure, you're right! I'm start thinking that fork of gui+back for 
some period

of time is not such silly thing...

A fork of an open source project is almost always a bad thing.
Especially in the case where you haven't tries to get your ideas into
the main project first.


I mean for for "some period of time". I gives me some freedom to brake 
things without bothering people. One of the reason that drove me to 
idea of forking gui+back is when I'm developing Project Center I need 
to fix some things after GNUstep svn update. I need some stable 
basement for PC  development. I tired fix things that was not broken 
before.


I understand the frustration with having to deal with breakage like 
that, but I'm going to ask you to think about it a bit more before 
deciding to branch.


Where I work we had the problem with changes to the gnustep code 
breaking our production code, so we took a stable snapshot and worked 
with that for a long time.


This was all OK until we wanted to use some new features, so we updated 
to using a more recent version, and used that version on our test system 
from some weeks before making a release and rolling out to live 
systems.  But then on the live systems our customers managed to 
find/trigger bugs which had been missed on our test system ... so I'm 
now thinking that it's probably actually a lot safer to update the 
test/development systems as frequently as possible so that we maximise 
the amount of time during which any bugs can be discovered and fixed.


My current feeling is that it makes sense to branch, and work with the 
branch to make big changes, but the aim should be to merge that branch 
back into trunk as quickly as possible (and I mean within days or at 
most a couple of weeks, not several weeks or months).  That way, your 
branch doesn't end up depending on behaviors which have changed (usually 
been fixed) in trunk, and you don't get to a state where it's a horrible 
job to merge again.



I think that I will be glad to integrate most of the things that you
come up with into gui and back. So why talk about a fork first?
Sometimes it is worthwhile to test a few ideas on a branch before
integrating them into the trunk of a project, but that is a completely
different approach.


Actually some of the ideas are:
- remove old/unused code from 'back' (xdps, xlib);


Sounds good.


- move general code 'back' to 'gui' (gsc if I remember correctly);


Or perhaps into a library that the backends can link with if they need it?


Backends already linked against gui library, why we need another? Do you 
mean separating all GS* classes (from back and gui) into separate 
library? If so it may have sense to separate AppKit code from GNUstep 
specific one.


- finish font, image, drawing, events in GUI and ART backend (blurred 
lines, text positioning, focus issues with WindowMaker, start of first 
app in session, handling of X server events, text selection etc.).


That's really great X and window manager interaction are the biggest 
technical problem areas I see in GNUstep.


...and no documentation for how it works.

These are the basic things that MUST work correctly. Until then 
developing applications for GNUstep is a pain in back (fix things that 
was not broken before). I intentionally focus on UNIX, X11 and ART 
backend. I want at least one combination of components to work best of 
all (reference platform). I understand that other people has different 
tastes but spreading efforts never lead us to success.



You made great contributions to GNUstep, it would be hard to loose you
to a fork.


Thank you for good words. But please try to understand me: it's sad to 
see how people talks about changing appearance of GNUstep while must 
work functionality is far from 'Right Thing' even with current look.


I don't think you need to worry about that ... frankly, whatever people 
say about appearance is largely irrelevant since it doesn't really 
effect the coding you do.  The only impact is that we want to 
design/implement things so that theming is possible, but as far as the 
backend code goes, that really just means following good design 
principles of making code modular, clean, and simple ..  and that's 
clearly what you want to do anyway.
Certainly nobody is going to try to force you to work on changing the 
appearance of the GUI when you want to work on improving the backend.  
I, for one, am very glad to know that you want to work on the backend 
code as I thi

Re: Changes I've been thinking of...

[Sergii Stoian]

Gregory Casamento wrote:

On Fri, Oct 9, 2009 at 5:33 PM, Sergii Stoian  wrote:


Sure, you're right! I'm start thinking that fork of gui+back for some period
of time is not such silly thing...


Forking would be bad for the project in general.  In my opinion a fork
would only cause confusion.  If what you're referring to here is a
branch within the GNUstep repo, then that's fine... but I fork of the
project isn't really going to be productive.


Sure, this time it's better to say as branch not fork.


Also, I'm wondering what the reason for the fork would be.


See my mail to Fred.


GC


--
Sergii Stoian


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

Re: Changes I've been thinking of...

[Sergii Stoian]

Fred Kiefer wrote:

Sergii Stoian schrieb:

2009/10/9 Riccardo Mottola 

Many things you want do not clash with other goals, they only divert
manpower. But keep in consideration that in an opensource project people do
whatever they deem interesting or useful, there isn't a central planning.

Sure, you're right! I'm start thinking that fork of gui+back for some period
of time is not such silly thing...


A fork of an open source project is almost always a bad thing.
Especially in the case where you haven't tries to get your ideas into
the main project first.


I mean for for "some period of time". I gives me some freedom to brake 
things without bothering people. One of the reason that drove me to idea 
of forking gui+back is when I'm developing Project Center I need to fix 
some things after GNUstep svn update. I need some stable basement for PC 
 development. I tired fix things that was not broken before.



I think that I will be glad to integrate most of the things that you
come up with into gui and back. So why talk about a fork first?
Sometimes it is worthwhile to test a few ideas on a branch before
integrating them into the trunk of a project, but that is a completely
different approach.


Actually some of the ideas are:
- remove old/unused code from 'back' (xdps, xlib);
- move general code 'back' to 'gui' (gsc if I remember correctly);
- finish font, image, drawing, events in GUI and ART backend (blurred 
lines, text positioning, focus issues with WindowMaker, start of first 
app in session, handling of X server events, text selection etc.).


These are the basic things that MUST work correctly. Until then 
developing applications for GNUstep is a pain in back (fix things that 
was not broken before). I intentionally focus on UNIX, X11 and ART 
backend. I want at least one combination of components to work best of 
all (reference platform). I understand that other people has different 
tastes but spreading efforts never lead us to success.



You made great contributions to GNUstep, it would be hard to loose you
to a fork.


Thank you for good words. But please try to understand me: it's sad to 
see how people talks about changing appearance of GNUstep while must 
work functionality is far from 'Right Thing' even with current look.


--
Sergii Stoian


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

Re: Changes I've been thinking of...

[Sergii Stoian]

gt;> And if it will be comfortable to me it can be useful to somebody else.
>>
>>  Sure, it needs to be somethign useful and clean. I don't want to aim at
> GNOME or KDE; but something along the line of Xfce.
>
>> Summarizing this long email: we should focus on achievable goals by
>> narrowing down portability and loosing
>> competition with MacOS for now. Let's agree on strong, clean, simple
>> vision of project future and users will
>> come.
>>
>
> Agreed. We need both users and developers.
>
> But I can also tell you that most development in the past 2 years was good.
> GNUstep improved (much more than it broke). But a bit "too little"
> unfortunately in some areas and thus they are unfinished...
>

I've never said that all of the GNUstep components are bad. -base and -make
just great! There are always some bugs but in general I like them. The most,
if not all, problem areas are concentrated in GUI and backend.  And these
part are what users contact with. So let's not start with visual
re-engineering but finish what already exist (correct look, correct feel,
speed of UI and so on).

-- 
Sergii Stoian, ProjectCenter maintainer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Changes I've been thinking of...

[Sergii Stoian]

On Fri, 09 Oct 2009 18:06:45 +0300, Markus Hitter  wrote:


Am 09.10.2009 um 11:27 schrieb Sergii Stoian:

"World (all stuff outside of GNUstep) acceptance of GNUstep as  
alternative developer framework that will help creating of alternative  
desktop environment."


Now I can't resist to comment either ;-)

"Platforms" aren't just a set of kernel and appropriate drivers these  
days, they are full functioning desktops already. So, while an  
alternative to Xfce / KDE / Gnome might be desireable for some people,  
the very most open source OS users won't bother on GNUstep applications  
if they don't fit into their preferred desktop environment.


Markus, why do you think that users of Xfce/KDE/GNOME should bother on
GNUstep applications at all? I guess user first tries to find app that is  
native to

it's DE. Second he looks for neighbor variants. If you want GNUstep apps to
fit into Xfce/KDE/GNOME then you need to change not only look (scrollbars,
menu style, etc.) but also FEEL of applications. Generally speaking,  
GNUstep

application should look and feel as user's preferred desktop application.
Finally it leads to bloating of code and problems with maintenance  
(considering

our developer resources).
Does GNUstep applications should look & feel as Qt and GTK+ apps? This is  
a dead

end for GNUstep project I guess.

As a Ubuntu user I can seamlessly install (packaged) KDE apps and use  
them next to Gnome apps. The same should be true for GNUstep apps.


Accordingly, work on e.g. a GNUstep terminal app is pointless, as there  
are two dozen other terminal apps out there already.


And browsers, file managers, IDEs, mail clients, editors... That's what I'm
trying to say about. There will be no charm in such approach. NS/OS has  
charm

even today I think.


Strongly preferring WindowMaker is plain counter productive.


Using GNUstep applications in, for example, GNOME is stupid. I see no  
sense in

using 'TextEdit' instead of 'gedit' and so on. Sorry, It's not an argument.
I see WindowMaker as: 1. part of Workspace Manager 2. reference window  
manager

for GNUstep applications.

Insisting on a own clipboard system will do nothing but confuse users.  
Those dock-like miniwindows are simply annoying (for Gnome users).  
Command line stuff is - well many users don't know what a command line  
is, after all.


Integration with the neighbor's desktop is the state of the art. Even  
the biggies like KDE or Gnome can't afford to ignore the others.


GNOME and KDE has similar point of view on how desktop should be organized.
NS/OS has different philosophy. It's not only about look&feel.



Markus


P.S.: Currently I'm using Cocotron. Much less matured, but integrates  
much better. Braindead simple porting from Cocoa, standalone  
applications !


P.P.S.: Sorry for ranting so much. I just wanted to add another  
perspective.


I guess everybody agreed that this is not dispute - it's exchange of  
opinions.


--
Sergii Stoian


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

Re: Changes I've been thinking of...

[Sergii Stoian]

Hi, Gregory. Hi, guys.

I can't resist expressing my opinion on GNUstep changes as I see it.

I've defined several problem areas of GNUstep:

1. Maturity of GNUstep code for developers (functionality, docs, stability)
2. GUI appearance
3. Portability
4. Applications

Gregory, behind all things you've mentioned I see a goal that can be  
expressed by the
following phrase: "World (all stuff outside of GNUstep) acceptance of  
GNUstep as alternative
developer framework that will help creating of alternative desktop  
environment."


Do you really think that improving website, theme (argh!) lead us to rise  
of user attention
to GNUstep? I don't think so. I see a lot of people comparing GNUstep with  
GNOME/KDE ("What's
Etoile? Another desktop environment? Why we should use it?"). IMHO it's  
not our target audience.

In my strong opinion our target audience could be:
- NeXTSTEP/OPENSTEP users who misses NS/OS look, feel and user experience  
in general (I'm one of them);

- developers who knows what OpenStep and Cocoa are;
- technical people who loves WindowMaker;
- researchers, students who can use GNUstep as basement for it's works.

In my opinion GNUstep project needs more forcible approach to reach the  
goal I've phrased above.

I propose to discuss the following approach:

1. Select reference platform for GNUstep development. Make GNUstep work  
ideally on one platform and
   then port it to another. My choice is FreeBSD (Xorg 7.4, ART GUI  
backend) despite the fact that I'm
   Linux user for over 13 years. I have set of strong reasons for this, we  
can discuss it later.
2. Stop chasing MacOS functionality. Let's set our target to for example  
MacOS 10.5 for a several years.

   In other words - polish and finish current implementation.
3. Stop trying to work everywhere. Let's make it working good at one  
place, then go to another. Let's
   speak frankly - we can't compete with Qt. Despite the existing of DO,  
Objective-C and other great things.
4. Make work good ONE FINISHED gui backend on reference platform with all  
needed functionality (OpenGL,

   Fonts, Graphics).
5. Finish gnustep-gui as it is. Problem areas are: text subsystem, fonts,  
graphics to name a few.
6. Create working destop environment for developers at least. Some day I  
realized that I'm working

   inside mess of not interacting things. My plan is:
   - Create Login application
   - Create Preferences
   - Create Workspace Manager (Workspace + WindowMaker), excellent  
integration of GNUstep with it (focus,

 app management, dock interaction).
   - Create Terminal application based on Alex Malmberg application.
   - Create Mail application (GNUmail can be used as starting point).
   - Finish ProjectCenter (anyway it's my responsibility).
7. Make it clean, fast and simple as NS/OS. Personally I'm tired of  
bloated desktop environments (KDE/GNOME).

   I want improved (at reasonable degree) OPENSTEP.

It's not a plan targeting on world domination. It's plan to make  
comfortable development environment as I see it.

And if it will be comfortable to me it can be useful to somebody else.

Summarizing this long email: we should focus on achievable goals by  
narrowing down portability and loosing
competition with MacOS for now. Let's agree on strong, clean, simple  
vision of project future and users will

come.

On Wed, 07 Oct 2009 22:24:01 +0300, Gregory Casamento  
 wrote:



Guys,

There are a number of things which need to change on the project:

We need to:
1) improve our website.  It's been the same for years and doesn't
reflect our progress.
2) improve GNUstep's default theme as well as theming in general.
While I know some people will respond negatively to changing the
default theme from a NeXT-like look to something more modern, I
believe it's one way for us to spark interest in the project is to
update it's look.   The current look should always be available, but
not necessarily the default.
3) Improve our ability to market ourselves in general.

One thing that GNUstep has been lacking in is marketing.   I've been
trying to improve things on that front, but I'm not the best marketer
to say the very least.

Does anyone have any questions or comments regarding this?  I would
like to hear any and all input people have.

Later, GC


--
Sergii Stoian


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

Re: Project Center status, or lack thereof...

[Sergii Stoian]

Hello, Gregory.

Actually
some time ago I've got huge amount of work in real life. So I'll also
want to see somebody providing
maintanance of ProjectCenter. I'll try to continue working on PC as my
real life job let me do it.

My apologies to GNUstep community for silence about PC development status.
Let me put some
information about what is already done in SVN for upcoming 0.5.0 release of
PC (excerpt from ANNOUNCE):

* Added new project types "Framework" and "Resource Set".

* Implemented on demand loading of bundles (project types, editor).

* Impemented localization support for projects.

* Some user interface ehnancements were made (save restore geometry of
subviews in project window splitview, drag and drop for icons).

* Clicking on .m and .h file in project browser expands to file structure
(classes, methods).

* Incorporated ProjectManager's editor with some modifications. Syntax color
highlighting works.

* Rewritte bundle loading mechanizm. All bundle now loaded on demand.

* All windows and panels are now GORM files.

* Fixes for MingW environment (thanks to Adam Fedor).

* Support for separate build directory added.

On 7/8/07, Gregory John Casamento <[EMAIL PROTECTED]> wrote:


All,

I would like to get this fixed at some point.  PC is one of our core
applications and it should work with the latest release, but yet it's not
gnustep-make 2.0 compliant which, basically, renders it useless.  See this
comment:

"As can be seen, I did not create a ProjectCenter packages because the
current release (
0.4.3) does not work with make 2.0!  I do request that a new version be
release to conform to the current make release."

I've been thinking lately about plans to integrate Gorm and
ProjectCenter... to have better communication between them.I would
prefer to have someone to work with on this instead of doing it all myself
as my work load for my company has increased dramatically lately (yes...
running a consulting company takes time and effort).

My sincerest apologies to Serge, but I would appreciate it if anyone who
is interested in maintaining PC would let me know.

Thanks, GJC
--
Gregory Casamento




--
Sergii Stoian, ProjectCenter maintainer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Fwd: NSMatrix, NSCell, NSBrowser,NSBrowserCell proposed patch

[Sergii Stoian]

Hi. Nicola

On 3/22/07, Nicola Pero <[EMAIL PROTECTED]> wrote:


>Hi,
>
>I want to propose changes to gui-trunk (patch attached). In general
>changes are touches NSMattrix and NSCell and is about drawing first
>reponder indicator (dotted frame). What is done:
>
>- NSCell is responsible for showing first responder state;
>- Removed code from NSMatrix which sets attibute of cell to display
>first responder state then draws cell and then set attibute to off;
>- Removed code from NSBrowserCell which draws first responder indicator.
>
>Before this patch (current SVN) NSCell draws first responder indicator
>when it's selected (highlighted) and when it's not slected. That's why
>NSMatrix and the like should switch on and off NSCell's attribute.

I'm sure you have a reason to propose this change ... probably a good idea
to explain it. ;-)

ie, what's wrong with the existing code ? :-)


I think I've explained more in detail in response to Fred's mail.
If you have other questions just ask me. Thank you.

--
Sergii Stoian, ProjectCenter maintainer


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

Fwd: NSMatrix, NSCell, NSBrowser,NSBrowserCell proposed patch

[Sergii Stoian]

Hi,

I want to propose changes to gui-trunk (patch attached). In general
changes are touches NSMattrix and NSCell and is about drawing first
reponder indicator (dotted frame). What is done:

- NSCell is responsible for showing first responder state;
- Removed code from NSMatrix which sets attibute of cell to display
first responder state then draws cell and then set attibute to off;
- Removed code from NSBrowserCell which draws first responder indicator.

Before this patch (current SVN) NSCell draws first responder indicator
when it's selected (highlighted) and when it's not slected. That's why
NSMatrix and the like should switch on and off NSCell's attribute.

Please test the attached code. If there's no objections I'll commit
this code to the trunk.

--
Sergii Stoian, ProjectCenter maintainer
Index: Source/NSBrowser.m
===
--- Source/NSBrowser.m	(revision 24896)
+++ Source/NSBrowser.m	(working copy)
@@ -1842,6 +1842,7 @@
 	  
 	  cs = [sc contentSize];
 	  ms = [matrix cellSize];
+	  if (ms.height < 15) ms.height = 15;
 	  ms.width = cs.width;
 	  [matrix setCellSize: ms];
 	  [sc setDocumentView: matrix];
Index: Source/NSMatrix.m
===
--- Source/NSMatrix.m	(revision 24896)
+++ Source/NSMatrix.m	(working copy)
@@ -2086,21 +2086,7 @@
 	  NSRectFill(cellFrame);
 	}
   
-  if (_dottedRow == row
-  && _dottedColumn == column
-	  && [aCell acceptsFirstResponder]
-  && [_window isKeyWindow]
-	  && [_window firstResponder] == self)
-	{
-	  [aCell setShowsFirstResponder: YES];
-  [aCell drawWithFrame: cellFrame inView: self];
-  [aCell setShowsFirstResponder: NO];
-	}
-  else
-	{
-	  [aCell setShowsFirstResponder: NO];
-  [aCell drawWithFrame: cellFrame inView: self];
-	}
+  [aCell drawWithFrame: cellFrame inView: self];
 }
 }
 
@@ -4112,20 +4098,7 @@
 	  NSRectFill(cellFrame);
 	}
 
-  if (_dottedRow == row && _dottedColumn == column
-	  && [aCell acceptsFirstResponder])
-	{
-	  [aCell
-	setShowsFirstResponder: ([_window isKeyWindow]
- && [_window firstResponder] == self)];
-	}
-  else
-{
-	  [aCell setShowsFirstResponder: NO];
-	}
-  
   [aCell drawWithFrame: cellFrame inView: self];
-  [aCell setShowsFirstResponder: NO];
 }
 }
 
Index: Source/NSCell.m
===
--- Source/NSCell.m	(revision 24896)
+++ Source/NSCell.m	(working copy)
@@ -2017,7 +2017,8 @@
 
   // Draw first responder
   if (_cell.shows_first_responder
-&& [[controlView window] firstResponder] == controlView)
+&& [[controlView window] firstResponder] == controlView
+&& (_cell.is_highlighted || _cell.state))
 {
   // FIXME: Should depend on _cell.focus_ring_type
   [[GSTheme theme] drawFocusFrame: [self drawingRectForBounds: cellFrame] 
Index: Source/NSBrowserCell.m
===
--- Source/NSBrowserCell.m	(revision 24896)
+++ Source/NSBrowserCell.m	(working copy)
@@ -323,9 +323,6 @@
   // Draw the body of the cell
   [self _drawAttributedText: [self attributedStringValue]
 	inFrame: title_rect];
-
-  if (_cell.shows_first_responder == YES)
-NSDottedFrameRect(cellFrame);
 }
 
 - (BOOL) isOpaque
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r24671 - /libs/gui/trunk/Source/NSAlert.m

[Sergii Stoian]

Hi, Matt.

Thank you. I'll update Changelog along with new fix.

Escape key sequence force alert panel to return
as if other button clicked. I guess it is not the best way
to achieve what alert panel is bringing for. Anyway we can disscuss
panel's behaviour. This is also the matter of user safety.

On 2/21/07, Matt Rice <[EMAIL PROTECTED]> wrote:


Also you forgot a ChangeLog entry,

I also believe this change to be dubious in that because key
equivalents
for return and escape exist, doesn't mean that someone wouldn't use
tab/space which they may be used to for other panels which do not have
return/escape key equivalents.

On 2007-02-21 01:31:04 -0800 Fred Kiefer <[EMAIL PROTECTED]> wrote:

> I am not sure, but wouldn't it be better to just switch of the display
> of the first responder frame by calling setShowsFirstResponder: on the
> cell with NO as the argument?
>
> On a not so related issue, you had to set the highlight behaviour for
> these buttons explicitly. What about setting the type of all these
> buttons to be NSMomentaryPushInButton in _makeButtonWithRect:. This
> looks more consistent to me. The default button would still be
> different
> though.
>
> Sergii Stoian schrieb:
>> Author: stoyan
>> Date: Wed Feb 21 01:46:01 2007
>> New Revision: 24671
>>
>> URL: http://svn.gna.org/viewcvs/gnustep?rev=24671&view=rev
>> Log:
>> * Source/NSAlert.m: (-_initWithoutGModel):
>> Make buttons refuse first responder to avoid drawing
>> dashed frame.
>>
>> Modified:
>>  libs/gui/trunk/Source/NSAlert.m
>>





--
Sergii Stoian, ProjectCenter maintainer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r24671 - /libs/gui/trunk/Source/NSAlert.m

[Sergii Stoian]

Hi, Fred.

I think the setRefusesFirstResponder is better because user should click
with mouse on non-default buttons. While default button used for
non-destructive procedure (as to NextStep User Interface Guilde) user can't
select other buttons by accident (read using Tab button).

As for button style: agreed. I'll make changes to svn.

On 2/21/07, Fred Kiefer <[EMAIL PROTECTED]> wrote:


I am not sure, but wouldn't it be better to just switch of the display
of the first responder frame by calling setShowsFirstResponder: on the
cell with NO as the argument?

On a not so related issue, you had to set the highlight behaviour for
these buttons explicitly. What about setting the type of all these
buttons to be NSMomentaryPushInButton in _makeButtonWithRect:. This
looks more consistent to me. The default button would still be different
though.

Sergii Stoian schrieb:
> Author: stoyan
> Date: Wed Feb 21 01:46:01 2007
> New Revision: 24671
>
> URL: http://svn.gna.org/viewcvs/gnustep?rev=24671&view=rev
> Log:
> * Source/NSAlert.m: (-_initWithoutGModel):
> Make buttons refuse first responder to avoid drawing
> dashed frame.
>
> Modified:
> libs/gui/trunk/Source/NSAlert.m
>





--
Sergii Stoian, ProjectCenter maintainer
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r23393 - in /apps/projectcenter/branches/UNSTABLE_0_5: ./ Documentation/ Headers/ProjectCenter/ Headers/Protocols/ Library/ Library/Resources/FileAttributes.gorm/ Library/Resources/P

[Sergii Stoian]

Hi, Adam.On 9/5/06, Adam Fedor <[EMAIL PROTECTED]> wrote:
Can you also put in a svn log and/or ChangeLog of what you did?  It'shelpful for other people working on the project.  I usually theChangeLog as the svn log entry so they are the same.Once I bring PC with new features into some useable shape I'll do it. Thank you.
BTW, I've updated my e-mail on savannah as well as on gna.org.-- Sergii Stoian, ProjectCenter maintainer 
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Documentation AN...

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   06/01/15 22:51:23

Modified files:
dev-apps/ProjectCenter/Documentation: ANNOUNCE ChangeLog 

Log message:
Release 0.4.3

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Documentation/ANNOUNCE.diff?tr1=1.7&tr2=1.8&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Documentation/ChangeLog.diff?tr1=1.43&tr2=1.44&r1=text&r2=text

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter GNUmakefile GNUm... [UNSTABLE_0_5]

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: UNSTABLE_0_5
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/28 23:51:35

Modified files:
dev-apps/ProjectCenter: GNUmakefile GNUmakefile.postamble 
GNUmakefile.preamble PCAppController.m 
PCInfoController.m PCMenuController.m 
dev-apps/ProjectCenter/Documentation: ChangeLog SCHEME TODO 
dev-apps/ProjectCenter/Library: GNUmakefile 
GNUmakefile.postamble 
GNUmakefile.preamble 
PCAddFilesPanel.m PCButton.m 
PCFileCreator.m PCFileManager.m 
PCFileNameField.m 
PCFileNameIcon.m 
PCMakefileFactory.m PCProject.m 
PCProjectBrowser.m 
PCProjectBuilder.m 
PCProjectEditor.m 
PCProjectInspector.m 
PCProjectLauncher.m 
PCProjectLoadedFiles.m 
PCProjectManager.m 
PCProjectWindow.m PCSplitView.m 

Log message:
Merge local changes

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/GNUmakefile.diff?only_with_tag=UNSTABLE_0_5&tr1=1.21.4.3&tr2=1.21.4.4&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/GNUmakefile.postamble.diff?only_with_tag=UNSTABLE_0_5&tr1=1.6.4.1&tr2=1.6.4.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/GNUmakefile.preamble.diff?only_with_tag=UNSTABLE_0_5&tr1=1.13.4.1&tr2=1.13.4.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/PCAppController.m.diff?only_with_tag=UNSTABLE_0_5&tr1=1.10.4.2&tr2=1.10.4.3&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/PCInfoController.m.diff?only_with_tag=UNSTABLE_0_5&tr1=1.5.4.1&tr2=1.5.4.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/PCMenuController.m.diff?only_with_tag=UNSTABLE_0_5&tr1=1.14.4.1&tr2=1.14.4.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Documentation/ChangeLog.diff?only_with_tag=UNSTABLE_0_5&tr1=1.34.4.8&tr2=1.34.4.9&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Documentation/SCHEME.diff?only_with_tag=UNSTABLE_0_5&tr1=1.4.4.1&tr2=1.4.4.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Documentation/TODO.diff?only_with_tag=UNSTABLE_0_5&tr1=1.6.4.4&tr2=1.6.4.5&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/GNUmakefile.diff?only_with_tag=UNSTABLE_0_5&tr1=1.8.4.3&tr2=1.8.4.4&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/GNUmakefile.postamble.diff?only_with_tag=UNSTABLE_0_5&tr1=1.4&tr2=1.4.4.1&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/GNUmakefile.preamble.diff?only_with_tag=UNSTABLE_0_5&tr1=1.6&tr2=1.6.4.1&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCAddFilesPanel.m.diff?only_with_tag=UNSTABLE_0_5&tr1=1.2.4.1&tr2=1.2.4.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCButton.m.diff?only_with_tag=UNSTABLE_0_5&tr1=1.10.4.2&tr2=1.10.4.3&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCFileCreator.m.diff?only_with_tag=UNSTABLE_0_5&tr1=1.6.4.1&tr2=1.6.4.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCFileManager.m.diff?only_with_tag=UNSTABLE_0_5&tr1=1.13.4.2&tr2=1.13.4.3&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCFileNameField.m.diff?only_with_tag=UNSTABLE_0_5&tr1=1.1.2.1&tr2=1.1.2.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCFileNameIcon.m.diff?only_with_tag=UNSTABLE_0_5&tr1=1.1.2.1&tr2=1.1.2.2&r1=text&r2=text
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCMakefileFactory.m.diff?only_with_tag=UNSTABLE_0

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Library PCBundle... [UNSTABLE_0_5]

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: UNSTABLE_0_5
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/28 23:47:21

Added files:
dev-apps/ProjectCenter/Library: PCBundleManager.m 
PCLogController.m 
PCPrefController.m 
PCProjectBuilderPanel.m 
PCProjectLauncherPanel.m 
PCProjectLoadedFilesPanel.m 
dev-apps/ProjectCenter/Library/Resources/LogPanel.gorm: 
data.classes 
data.info 
objects.gorm 
dev-apps/ProjectCenter/Library/Resources/Preferences.gorm: 
   data.classes 
   data.info 
   objects.gorm 
Removed files:
dev-apps/ProjectCenter/Library: CodeParser.h PCAddFilesPanel.h 
PCBuildPanel.h PCBuildPanel.m 
PCBundleLoader.h 
PCBundleLoader.m PCButton.h 
PCDefines.h PCEditor.h 
PCEditor.m 
PCEditorView+Highlighting.h 
PCEditorView+Highlighting.m 
PCEditorView.h PCEditorView.m 
PCFileCreator.h PCFileManager.h 
PCFileNameField.h 
PCFileNameIcon.h PCLaunchPanel.h 
PCLaunchPanel.m 
PCLoadedFilesPanel.h 
PCLoadedFilesPanel.m 
PCMakefileFactory.h 
PCObjCParser.h PCObjCParser.m 
PCProject.h PCProjectBrowser.h 
PCProjectBuilder.h 
PCProjectEditor.h 
PCProjectInspector.h 
PCProjectLauncher.h 
PCProjectLoadedFiles.h 
PCProjectManager.h 
PCProjectWindow.h PCServer.h 
PCServer.m PCSplitView.h 
PCTextFinder+UInterface.h 
PCTextFinder+UInterface.m 
PCTextFinder.h PCTextFinder.m 
PreferenceController.h 
ProjectBuilder.h ProjectCenter.h 
ProjectComponent.h 
ProjectDebugger.h 
ProjectDelegate.h 
ProjectEditor.h ProjectType.h 
Server.h 

Log message:
Cleanup in Library

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCBundleManager.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCLogController.m?only_with_tag=UNSTABLE_0_5&rev=1.2.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCPrefController.m?only_with_tag=UNSTABLE_0_5&rev=1.2.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCProjectBuilderPanel.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCProjectLauncherPanel.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/PCProjectLoadedFilesPanel.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/Resources/LogPanel.gorm/data.classes?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/Resources/LogPanel.gorm/data.info?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Library/Resources/LogPanel.gorm/objects.gorm?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnuste

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules GNUmakef... [UNSTABLE_0_5]

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: UNSTABLE_0_5
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:48:55

Modified files:
dev-apps/ProjectCenter/Modules: GNUmakefile GNUmakefile.bundles 
Added files:
dev-apps/ProjectCenter/Modules/Projects/Aggregate: GNUmakefile 
   PCAggregateProject.h 
   PCAggregateProject.m 
dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources: 
 Info.table 
 PC.project 

dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources/Inspector.gorm: 

data.classes 

data.info 

objects.gorm 
dev-apps/ProjectCenter/Modules/Projects/Application: GNUmakefile 
 
PCAppProject+Inspector.h 
 
PCAppProject+Inspector.m 
 PCAppProject.h 
 PCAppProject.m 
dev-apps/ProjectCenter/Modules/Projects/Application/Resources: 
   
AppController.h 
   
AppController.m 
   
Info.gnustep 
   
Info.table 
   
Main.gsmarkup 
   
MainMenu-GNUstep.gsmarkup 
   
MainMenu-OSX.gsmarkup 
   
PC.project 
   main.m 

dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Inspector.gorm: 

  data.classes 

  data.info 

  objects.gorm 

dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Main.gorm: 

 data.classes 

 data.info 

 objects.gorm 
dev-apps/ProjectCenter/Modules/Projects/Bundle: GNUmakefile 
PCBundleProject.h 
PCBundleProject.m 
dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources: 
  Info.table 
  PC.project 

dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources/Inspector.gorm: 

 data.classes 

 data.info 

 objects.gorm 
dev-apps/ProjectCenter/Modules/Projects/Framework: GNUmakefile 
   PCFrameworkProject.h 
   PCFrameworkProject.m 
dev-apps/ProjectCenter/Modules/Projects/Framework/Resources: 
 Info.table 
 PC.project 

dev-apps/ProjectCenter/Modules/Projects/Framework/Resources/Inspector.gorm: 

data.classes 

data.info 

objects.gorm 
dev-apps/ProjectCenter/Modules/Projects/Library: GNUmakefile 
 PCLibPro

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool/Resources/Inspector.gorm

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:46:22

gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool/Resources/Inspector.gorm

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool/Resources/Inspector.gorm
In directory 
savannah:/tmp/cvs-serv16658/Modules/Projects/Tool/Resources/Inspector.gorm

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool/Resources/Inspector.gorm
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet/Resources/Inspector.gorm

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:45:24

gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet/Resources/Inspector.gorm

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet/Resources/Inspector.gorm
In directory 
savannah:/tmp/cvs-serv16584/Modules/Projects/ResourceSet/Resources/Inspector.gorm

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet/Resources/Inspector.gorm
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Library/Resources/Inspector.gorm

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:43:55

gnustep/dev-apps/ProjectCenter/Modules/Projects/Library/Resources/Inspector.gorm

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Library/Resources/Inspector.gorm
In directory 
savannah:/tmp/cvs-serv16478/Modules/Projects/Library/Resources/Inspector.gorm

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Library/Resources/Inspector.gorm
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework/Resources/Inspector.gorm

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:41:44

gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework/Resources/Inspector.gorm

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework/Resources/Inspector.gorm
In directory 
savannah:/tmp/cvs-serv16381/Modules/Projects/Framework/Resources/Inspector.gorm

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework/Resources/Inspector.gorm
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources/Inspector.gorm

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:40:58

gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources/Inspector.gorm

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources/Inspector.gorm
In directory 
savannah:/tmp/cvs-serv16338/Modules/Projects/Bundle/Resources/Inspector.gorm

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources/Inspector.gorm
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Main.gorm

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:39:44

gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Main.gorm

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Main.gorm
In directory 
savannah:/tmp/cvs-serv16259/Modules/Projects/Application/Resources/Main.gorm

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Main.gorm
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Inspector.gorm

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:39:43

gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Inspector.gorm

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Inspector.gorm
In directory 
savannah:/tmp/cvs-serv16259/Modules/Projects/Application/Resources/Inspector.gorm

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources/Inspector.gorm
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources/Inspector.gorm

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:38:43

gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources/Inspector.gorm

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources/Inspector.gorm
In directory 
savannah:/tmp/cvs-serv15767/Modules/Projects/Aggregate/Resources/Inspector.gorm

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources/Inspector.gorm
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:38:07

gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources
In directory savannah:/tmp/cvs-serv15541/Modules/Projects/Bundle/Resources

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle/Resources
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet/Resources

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:38:08

gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet/Resources

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet/Resources
In directory savannah:/tmp/cvs-serv15541/Modules/Projects/ResourceSet/Resources

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet/Resources
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool/Resources

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:38:09

gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool/Resources

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool/Resources
In directory savannah:/tmp/cvs-serv15541/Modules/Projects/Tool/Resources

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool/Resources 
added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework/Resources

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:38:07

gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework/Resources

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework/Resources
In directory savannah:/tmp/cvs-serv15541/Modules/Projects/Framework/Resources

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework/Resources
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:38:07

gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources
In directory savannah:/tmp/cvs-serv15541/Modules/Projects/Application/Resources

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Application/Resources
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Library/Resources

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:38:08

gnustep/dev-apps/ProjectCenter/Modules/Projects/Library/Resources

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Library/Resources
In directory savannah:/tmp/cvs-serv15541/Modules/Projects/Library/Resources

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Library/Resources
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:38:06

gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources
In directory savannah:/tmp/cvs-serv15541/Modules/Projects/Aggregate/Resources

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate/Resources
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:36:06

gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet
In directory savannah:/tmp/cvs-serv14327/Modules/Projects/ResourceSet

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/ResourceSet 
added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:36:06

gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool

Update of /sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool
In directory savannah:/tmp/cvs-serv14327/Modules/Projects/Tool

Log Message:
Directory /sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Tool 
added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Application

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:36:05

gnustep/dev-apps/ProjectCenter/Modules/Projects/Application

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Application
In directory savannah:/tmp/cvs-serv14327/Modules/Projects/Application

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Application 
added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:36:04

gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate
In directory savannah:/tmp/cvs-serv14327/Modules/Projects/Aggregate

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Aggregate 
added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:36:05

gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework
In directory savannah:/tmp/cvs-serv14327/Modules/Projects/Framework

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Framework 
added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Library

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:36:06

gnustep/dev-apps/ProjectCenter/Modules/Projects/Library

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Library
In directory savannah:/tmp/cvs-serv14327/Modules/Projects/Library

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Library added 
to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:36:05

gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle
In directory savannah:/tmp/cvs-serv14327/Modules/Projects/Bundle

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects/Bundle added 
to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Projects

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:35:51

gnustep/dev-apps/ProjectCenter/Modules/Projects

Update of /sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects
In directory savannah:/tmp/cvs-serv14221/Modules/Projects

Log Message:
Directory /sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Projects 
added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Preferences

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:35:01

gnustep/dev-apps/ProjectCenter/Modules/Preferences

Update of /sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Preferences
In directory savannah:/tmp/cvs-serv13676/Modules/Preferences

Log Message:
Directory /sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Preferences 
added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules Editors/... [UNSTABLE_0_5]

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: UNSTABLE_0_5
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:33:19

Added files:
dev-apps/ProjectCenter/Modules/Editors/ProjectCenter: 
  GNUmakefile 
  
PCEditor+Document.m 
  PCEditor.h 
  PCEditor.m 
  PCEditorView.h 
  PCEditorView.m 
  
SyntaxDefinition.h 
  
SyntaxDefinition.m 
  
SyntaxHighlighter.h 
  
SyntaxHighlighter.m 
  TextFinder.h 
  TextFinder.m 
  TextPattern.h 
  TextPattern.m 
dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/Resources: 

C.syntax 

Info.table 

ObjC.syntax 

Plist.syntax 
dev-apps/ProjectCenter/Modules/Parsers/ProjectCenter: 
  CodeHandler.h 
  GNUmakefile 
  
ObjCClassHandler.h 
  
ObjCClassHandler.m 
  
ObjCCommentHandler.h 
  
ObjCCommentHandler.m 
  
ObjCMethodHandler.h 
  
ObjCMethodHandler.m 
  PCParser.h 
  PCParser.m 
dev-apps/ProjectCenter/Modules/Parsers/ProjectCenter/Resources: 

Info.table 

Log message:
Added Modules/Editors and Modules/Parsers

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/GNUmakefile?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/PCEditor+Document.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/PCEditor.h?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/PCEditor.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/PCEditorView.h?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/PCEditorView.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/SyntaxDefinition.h?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/SyntaxDefinition.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/SyntaxHighlighter.h?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/SyntaxHighlighter.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/TextFinder.h?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/TextFinder.m?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Editors/ProjectCenter/TextPattern.h?only_with_tag=UNSTABLE_0_5&rev=1.1.2.1
ht

[Gnustep-cvs] gnustep/dev-apps/ProjectCenter/Modules/Parsers/ProjectCenter/Resources

[Sergii Stoian]

CVSROOT:/sources/gnustep
Module name:gnustep
Branch: 
Changes by: Sergii Stoian <[EMAIL PROTECTED]>   05/12/27 11:31:09

gnustep/dev-apps/ProjectCenter/Modules/Parsers/ProjectCenter/Resources

Update of 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Parsers/ProjectCenter/Resources
In directory savannah:/tmp/cvs-serv11237/Modules/Parsers/ProjectCenter/Resources

Log Message:
Directory 
/sources/gnustep/gnustep/dev-apps/ProjectCenter/Modules/Parsers/ProjectCenter/Resources
 added to the repository
--> Using per-directory sticky tag `UNSTABLE_0_5'