GNUstep and compositing?

[Jon "Top Hat" Jones]

I've been searching the net for a few hours now, and I haven't been able to find anything to help me with what I'm wanting to do.

I want to have a GNUstep desktop environment (DE), with the wonderful dock and clip (I love them boxes), but with support for compositing, such as Compiz Fusion.

I have been trying to find out how to add compositing support to a DE, but every search phrase I use inevitably results in links describing how to enable Compiz in a DE that already has support.

The problem is, I DON'T want GNOME, I DON'T want KDE, I DON'T want any DE that uses a "panel", "taskbar", or any other interface that resembles that found in Windows or MacOS.

I am perfectly willing to write the code myself, if someone will point me in the right direction.

On the other hand, if a GNUstep-based DE already exists with compositing support, I would very much appreciate a link to that.

--
mu'o mi'e .aionys.

.i.a'o.e'e ko klama le bende pe denpa bu


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Paul Csanyi]

Hi,

2009/10/31 Jon "Top Hat" Jones <eyeonus@...>

>
> I've been searching the net for a few hours now, and I haven't been able to find anything to help me with what I'm wanting to do.
>
> I want to have a GNUstep desktop environment (DE), with the wonderful dock and clip (I love them boxes), but with support for compositing, such as Compiz Fusion.
>
> I have been trying to find out how to add compositing support to a DE, but every search phrase I use inevitably results in links describing how to enable Compiz in a DE that already has support.
>
> The problem is, I DON'T want GNOME, I DON'T want KDE, I DON'T want any DE that uses a "panel", "taskbar", or any other interface that resembles that found in Windows or MacOS.
>
> I am perfectly willing to write the code myself, if someone will point me in the right direction.
>
> On the other hand, if a GNUstep-based DE already exists with compositing support, I would very much appreciate a link to that.

Have you tried the Window Maker window manager?

--
Regards, Paul Chany
http://csanyi-pal.info


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Paul Csanyi]

Hi,

2009/10/31 Jon "Top Hat" Jones <eyeonus@...>:

>> Have you tried the Window Maker window manager?

> I have. I liked it, but it doesn't support compositing, and according to the
> development team, it never will.

OK but have you tried Compiz?
http://en.wikipedia.org/wiki/Compiz

--
Regards, Paul Chany
http://csanyi-pal.info


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Truls Becken]

Jon "Top Hat" Jones wrote:

> I want to have a GNUstep desktop environment (DE), with the wonderful dock
> and clip (I love them boxes), but with support for compositing, such as
> Compiz Fusion.

[snip]

> I am perfectly willing to write the code myself, if someone will point me in
> the right direction.

I think a standalone Dock.app would be the best approach, so that you
could run any window manager you want and still have a nice, working
dock. It could add capabilities similar to those of wmaker's Clip
and/or the NeXTstep Fiend to make room for more than a single column.

A common question on the mailing list is how to get rid of the app
icons in foreign environments. Currently, the answer is to write a
defaults value, but it would be much nicer if free floating icons did
not exist in the first place. They should only appear when there is a
dock running. Incidentally, this is how it works on Mac OS X, where
you can kill the Dock so that there is no trace left of app icons
until you launch Dock.app again.

This will take some work, will require major changes to gnustep-gui,
and will probably break Window Maker, but I really think it is worth
it. Oh, and I do not mean a half baked solution like the GWorkspace
Dock. It is important to retain the possibility for applications to
add functionality to their app icons.

-Truls


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Aria Stewart]

On Oct 31, 2009, at 8:57 AM, Truls Becken wrote:
>
> This will take some work, will require major changes to gnustep-gui,
> and will probably break Window Maker, but I really think it is worth
> it. Oh, and I do not mean a half baked solution like the GWorkspace
> Dock. It is important to retain the possibility for applications to
> add functionality to their app icons.


I'm really a fan of this approach, too -- it keeps us from making  
people feel like the programs are alien unless you're running a wholly  
gnustep environment.

Also, GNOME could really, really use some of these things so that  
people stop half-baking these things into tray icons.


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Jon "Top Hat" Jones]

I actually started out lloking for something like that, but never found a suitable solution. The only thing I found that was even close a GNOME panel applet that was capable of holding docklets. Not an elegant solution at all, especially as I want to get RID of the panel. A standalone dock.app would be wonderful, especially if it were a single program that could allow multiple instances and a clip flag, so that I could, for example, run ">dock.app& dock.app -clip" and have exactly what I want.
I'd still have the problem with getting rid of the very annoying panel, which apparently is impossible, although there is a workaround I found involving transparency....

I'd have to look at the relevant source code for the dock and app, but I doubt it would be horribly difficult to extract the code into a standalone.

On Sat, Oct 31, 2009 at 9:57 AM, Truls Becken <truls.becken@...> wrote:

Jon "Top Hat" Jones wrote:

> I want to have a GNUstep desktop environment (DE), with the wonderful dock
> and clip (I love them boxes), but with support for compositing, such as
> Compiz Fusion.

[snip]

> I am perfectly willing to write the code myself, if someone will point me in
> the right direction.

I think a standalone Dock.app would be the best approach, so that you
could run any window manager you want and still have a nice, working
dock. It could add capabilities similar to those of wmaker's Clip
and/or the NeXTstep Fiend to make room for more than a single column.

A common question on the mailing list is how to get rid of the app
icons in foreign environments. Currently, the answer is to write a
defaults value, but it would be much nicer if free floating icons did
not exist in the first place. They should only appear when there is a
dock running. Incidentally, this is how it works on Mac OS X, where
you can kill the Dock so that there is no trace left of app icons
until you launch Dock.app again.

This will take some work, will require major changes to gnustep-gui,
and will probably break Window Maker, but I really think it is worth
it. Oh, and I do not mean a half baked solution like the GWorkspace
Dock. It is important to retain the possibility for applications to
add functionality to their app icons.

-Truls

--
mu'o mi'e .aionys.

.i.a'o.e'e ko klama le bende pe denpa bu

--
mu'o mi'e .aionys.

.i.a'o.e'e ko klama le bende pe denpa bu


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Germán Arias-2]

Hi Jon, please see this

http://lists.gnu.org/archive/html/discuss-gnustep/2009-10/msg00168.html

If the developers are agree with this, I will add this feature in next
days. Greetings.

El sáb, 31-10-2009 a las 13:56 -0500, Jon "Top Hat" Jones escribió:

>
> I actually started out lloking for something like that, but never
> found a suitable solution. The only thing I found that was even close
> a GNOME panel applet that was capable of holding docklets. Not an
> elegant solution at all, especially as I want to get RID of the panel.
> A standalone dock.app would be wonderful, especially if it were a
> single program that could allow multiple instances and a clip flag, so
> that I could, for example, run ">dock.app& dock.app -clip" and have
> exactly what I want.
> I'd still have the problem with getting rid of the very annoying
> panel, which apparently is impossible, although there is a workaround
> I found involving transparency....
>
> I'd have to look at the relevant source code for the dock and app, but
> I doubt it would be horribly difficult to extract the code into a
> standalone.
>
>

_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Jon "Top Hat" Jones]

Admittedly interesting, but it happens to have everything from the GNUstep family except what I actually want, which is the dock and clip.

On Sat, Oct 31, 2009 at 2:14 PM, Germán Arias <german@...> wrote:

Hi Jon, please see this

http://lists.gnu.org/archive/html/discuss-gnustep/2009-10/msg00168.html

If the developers are agree with this, I will add this feature in next
days. Greetings.

El sáb, 31-10-2009 a las 13:56 -0500, Jon "Top Hat" Jones escribió:

>
> I actually started out lloking for something like that, but never
> found a suitable solution. The only thing I found that was even close
> a GNOME panel applet that was capable of holding docklets. Not an
> elegant solution at all, especially as I want to get RID of the panel.
> A standalone dock.app would be wonderful, especially if it were a
> single program that could allow multiple instances and a clip flag, so
> that I could, for example, run ">dock.app& dock.app -clip" and have
> exactly what I want.
> I'd still have the problem with getting rid of the very annoying
> panel, which apparently is impossible, although there is a workaround
> I found involving transparency....
>
> I'd have to look at the relevant source code for the dock and app, but
> I doubt it would be horribly difficult to extract the code into a
> standalone.
>
>

--
mu'o mi'e .aionys.

.i.a'o.e'e ko klama le bende pe denpa bu


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Riccardo Mottola-4]

Germán Arias wrote:
> Hi Jon, please see this
>
> http://lists.gnu.org/archive/html/discuss-gnustep/2009-10/msg00168.html
>
> If the developers are agree with this, I will add this feature in next
> days. Greetings.
>  

Why can't you just use the Fiend? It is supplied with GWorkspace. It
works purely in gnustep and does not need any special windowmanager. If
you use Windowmaker, you disable the WMaker's one.

Riccardo


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Germán Arias-2]

El sáb, 31-10-2009 a las 23:48 +0100, Riccardo Mottola escribió:
>
> Why can't you just use the Fiend? It is supplied with GWorkspace. It
> works purely in gnustep and does not need any special windowmanager. If
> you use Windowmaker, you disable the WMaker's one.
>
> Riccardo

And who will manage the appicon and miniWindows of GWorkspace? GSTaskBar
is a simple tool to manage these (on all desktops) without having to
install another app or another window manager. If someone wants to use a
GNUstep app, just install GNUstep and the application (and sets
GSUseGSTaskBar = YES) and that's all. If you want an application made
with GTK, Qt, Free Pascal, Python, ... just install the libraries and
the application, and voila. GSTaskBar is a solution for the end user who
simply wants to use a GNUstep application without facing problems.



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Wolfgang Lux-3]

Riccardo Mottola wrote:

> Germán Arias wrote:
>> Hi Jon, please see this
>>
>> http://lists.gnu.org/archive/html/discuss-gnustep/2009-10/ 
>> msg00168.html
>>
>> If the developers are agree with this, I will add this feature in  
>> next
>> days. Greetings.
>
> Why can't you just use the Fiend? It is supplied with GWorkspace.  
> It works purely in gnustep and does not need any special  
> windowmanager. If you use Windowmaker, you disable the WMaker's one.

The GWorkspace fiend is not a replacement for WindowMaker's fiend (or  
its dock). It is merely a collection of icon sized windows that start  
the respective application when double clicked, but it does not  
provide an appicon for the running applications.

Wolfgang



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Fred Kiefer]

Germán Arias schrieb:

> El sáb, 31-10-2009 a las 23:48 +0100, Riccardo Mottola escribió:
>> Why can't you just use the Fiend? It is supplied with GWorkspace. It
>> works purely in gnustep and does not need any special windowmanager. If
>> you use Windowmaker, you disable the WMaker's one.
>
> And who will manage the appicon and miniWindows of GWorkspace? GSTaskBar
> is a simple tool to manage these (on all desktops) without having to
> install another app or another window manager. If someone wants to use a
> GNUstep app, just install GNUstep and the application (and sets
> GSUseGSTaskBar = YES) and that's all. If you want an application made
> with GTK, Qt, Free Pascal, Python, ... just install the libraries and
> the application, and voila. GSTaskBar is a solution for the end user who
> simply wants to use a GNUstep application without facing problems.

Looks like I am having some difficulties to understand the difference of
you positions. As far as I understand Riccardo he is offering you an
application that does exactly what you want. Why do you insist on
writing a new one. Of course writing duplicate applications is perfectly
fine for me, but it will be hard to request changes to GNUstep for that
application, when there is another one that works without changing GNUstep.
The only difference that I see is that your GSTaskBar seems to be able
to manage none GNUstep applications as well. Why would that be needed
and how does it work?

Or what is it that I am missing here?

Fred
(completely confused)


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Germán Arias-2]

El dom, 01-11-2009 a las 17:04 +0100, Fred Kiefer escribió:

>
> Looks like I am having some difficulties to understand the difference of
> you positions. As far as I understand Riccardo he is offering you an
> application that does exactly what you want. Why do you insist on
> writing a new one. Of course writing duplicate applications is perfectly
> fine for me, but it will be hard to request changes to GNUstep for that
> application, when there is another one that works without changing GNUstep.
> The only difference that I see is that your GSTaskBar seems to be able
> to manage none GNUstep applications as well. Why would that be needed
> and how does it work?
>
> Or what is it that I am missing here?
>
> Fred
> (completely confused)

My point is that an end user (a boy, a teacher, ...) should not be
confronted with the problem of how to handle the appIcons and
miniWindows on his desktop (Gnome, KDE, xfce, ...) and much less having
to learn about another application (GWorkspace, although I'm sure this
can not handle AppIcons and MiniWindows). If GNUstep provides GSTaskBar,
then the user only needs to adjust GSUseGSTaskBar = YES, and that's all.
And if he want, he can configure it (and of course this is much easier
than learn to use GWorkspace). To default the GSTaskBar can put the
icons and miniwindows at the left some pixels above of the lower left
corner (maybe 100 or 150), and added the new icons to the upwards. With
this position there isn't problem on gnome, and kde, and in many others
desktops. And with a size of 32x32 or 24x24, in this way people with a
resolution of 1024x768 will have small icons. But of course, he can
change this.

How work it? Easy

This requires a tool called GSTB registered with GSTaskBar name, this
tool only have three methods

- (NSArray *)setWindow: (NSWindow *)aWindow;
- (void)removeWindow: (NSWindow *)aWindow;
- (NSNumber *)getSizeWindow;

the first method provide on an array the X and Y coordinates of the
lower left corner of an icon and the size. Then when NSApplication make
the AppIcon (and GSUseGSTaskBar is YES) this ask for the data at
GSTaskBar process. And when the NSAplication is terminated call the
method removeWindow: to release the position in the taskbar. And the
same on NSWindow when minimize or deminimize a window. Of course there
are changes on NSAppIconView and NSMiniWindowView to change the size of
the images. But I suppose that this is more easy to do with a variable
call _iconSize instead are calling [GSCurrentServer() iconSize] or
GSTaskBar process each time, with this only two methods needs changes. I
don't know how much generic is this way. I will send you a patch if you
want see how I implement this. And I file with the tool. (I have this
now but with an horrible style)



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Fred Kiefer]

Germán Arias schrieb:

> My point is that an end user (a boy, a teacher, ...) should not be
> confronted with the problem of how to handle the appIcons and
> miniWindows on his desktop (Gnome, KDE, xfce, ...) and much less having
> to learn about another application (GWorkspace, although I'm sure this
> can not handle AppIcons and MiniWindows). If GNUstep provides GSTaskBar,
> then the user only needs to adjust GSUseGSTaskBar = YES, and that's all.
> And if he want, he can configure it (and of course this is much easier
> than learn to use GWorkspace). To default the GSTaskBar can put the
> icons and miniwindows at the left some pixels above of the lower left
> corner (maybe 100 or 150), and added the new icons to the upwards. With
> this position there isn't problem on gnome, and kde, and in many others
> desktops. And with a size of 32x32 or 24x24, in this way people with a
> resolution of 1024x768 will have small icons. But of course, he can
> change this.
>
> How work it? Easy
>
> This requires a tool called GSTB registered with GSTaskBar name, this
> tool only have three methods
>
> - (NSArray *)setWindow: (NSWindow *)aWindow;
> - (void)removeWindow: (NSWindow *)aWindow;
> - (NSNumber *)getSizeWindow;
>
> the first method provide on an array the X and Y coordinates of the
> lower left corner of an icon and the size. Then when NSApplication make
> the AppIcon (and GSUseGSTaskBar is YES) this ask for the data at
> GSTaskBar process. And when the NSAplication is terminated call the
> method removeWindow: to release the position in the taskbar. And the
> same on NSWindow when minimize or deminimize a window. Of course there
> are changes on NSAppIconView and NSMiniWindowView to change the size of
> the images. But I suppose that this is more easy to do with a variable
> call _iconSize instead are calling [GSCurrentServer() iconSize] or
> GSTaskBar process each time, with this only two methods needs changes. I
> don't know how much generic is this way. I will send you a patch if you
> want see how I implement this. And I file with the tool. (I have this
> now but with an horrible style)

I think, I understand now. Your new tool is not managing the position of
app icons itself. This is left to the applications themselves. What your
tool does is to provide a position and size for this icon to the
application. When starting up the application asks for this information
and then positions it icon accordingly.
This seems quite nice as it isn't intrusive and should be easy to
implement via DO. What I don't get is the interface you are proposing
for these methods. Why don't you use NSRect and NSSize here?
Also there seems to be the issue of an application stopping before
unregistering it's windows. How will that be handled?




_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[David Chisnall]

On 1 Nov 2009, at 21:12, Fred Kiefer wrote:

> I think, I understand now. Your new tool is not managing the  
> position of
> app icons itself. This is left to the applications themselves. What  
> your
> tool does is to provide a position and size for this icon to the
> application. When starting up the application asks for this  
> information
> and then positions it icon accordingly.


This is what EtoileMenuServer does for the horizontal menu position  
(using DO).  If someone is defining a set of interfaces for this  
already then it would be nice to merge the stuff from EtoileWildMenus  
in at the same time.

David

-- Sent from my STANTEC-ZEBRA



_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Germán Arias-2]

El dom, 01-11-2009 a las 22:12 +0100, Fred Kiefer escribió:
>
> I think, I understand now. Your new tool is not managing the position of
> app icons itself. This is left to the applications themselves. What your
> tool does is to provide a position and size for this icon to the
> application. When starting up the application asks for this information
> and then positions it icon accordingly.
> This seems quite nice as it isn't intrusive and should be easy to
> implement via DO. What I don't get is the interface you are proposing
> for these methods. Why don't you use NSRect and NSSize here?

Sure, is better.

> Also there seems to be the issue of an application stopping before
> unregistering it's windows. How will that be handled?

Are you referring when an app is closed, and this have windows
miniaturized?. I had not thought of this. But, I think that something
like this is enough on terminate: method

NSWindow *win;
NSEnumerator *windows = [[NSApp windows] objectEnumerator];

while((win = [windows nextObject]))
{
 if([win isMiniaturized])
   {
     Remove window from taskbar
   }
}




_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Truls Becken]

Germán Arias wrote:

>> Also there seems to be the issue of an application stopping before
>> unregistering it's windows. How will that be handled?
>
> Are you referring when an app is closed, and this have windows
> miniaturized?

I believe Fred meant that if an application suddenly dies, the slots
for its AppIcon and MiniWindows will still be registered as occupied.

Another issue is that this protocol does not allow the taskbar to be
moved or hidden, which also means it cannot implement layers. Would it
be feasible to add a way to tell running applications to move or hide
specific icons? How would one avoid screen flicker when moving a dock
that holds icons from a dozen different apps?

Then, if applications displayed icons *only* if a process had
registered for managing them, things would start to look really bright
since fiddling with defaults would no longer be necessary.

-Truls


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Germán Arias-2]

El lun, 02-11-2009 a las 19:57 +0100, Truls Becken escribió:
> I believe Fred meant that if an application suddenly dies, the slots
> for its AppIcon and MiniWindows will still be registered as occupied.

OK, I will try an idea to solve this

>
> Another issue is that this protocol does not allow the taskbar to be
> moved or hidden, which also means it cannot implement layers. Would it
> be feasible to add a way to tell running applications to move or hide
> specific icons?

Well you can configure the position and size of taskbar. But no more

> How would one avoid screen flicker when moving a dock
> that holds icons from a dozen different apps?

I don't understand what are you talking about

>
> Then, if applications displayed icons *only* if a process had
> registered for managing them, things would start to look really bright
> since fiddling with defaults would no longer be necessary.

I think that is better if GSUseGSTaskBar is YES to default (because most
people don't use WindowMaker)




_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Truls Becken]

Germán Arias wrote:

>> Another issue is that this protocol does not allow the taskbar to be
>> moved or hidden, which also means it cannot implement layers. Would it
>> be feasible to add a way to tell running applications to move or hide
>> specific icons?
>
> Well you can configure the position and size of taskbar. But no more

I see now that the taskbar is more like the row of icons at the bottom
screen edge on a NeXT system, and does not try to be a dock.

>> How would one avoid screen flicker when moving a dock
>> that holds icons from a dozen different apps?
>
> I don't understand what are you talking about

This was assuming the user was allowed to move the taskbar (dock) at
any time using the mouse. Since tiles are managed by their respective
applications, I was afraid it would lead to quite a lot of flicker.
Even the GWorkspace Fiend flickers like this, IIRC, because each tile
is a separate window, even though in this case all windows are
controlled by the same application.

>> Then, if applications displayed icons *only* if a process had
>> registered for managing them, things would start to look really bright
>> since fiddling with defaults would no longer be necessary.
>
> I think that is better if GSUseGSTaskBar is YES to default (because most
> people don't use WindowMaker)

I guess GSUseGSTaskBar also plays nice with WindowMaker because of
UseWindowMakerIcons, which with its default value of YES makes sure
GSTB never comes into play. Correct?

There is still the problem that most non-WindowMaker users do not want
to see AppIcons and MiniWindows at all, I think, but having them
organized in a row that respects NETWM struts and the Windows taskbar
definitely is an improvement.

-Truls


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep

[Riccardo Mottola-4]

Hi,
>> Then, if applications displayed icons *only* if a process had
>> registered for managing them, things would start to look really bright
>> since fiddling with defaults would no longer be necessary.
>>    
>
> I think that is better if GSUseGSTaskBar is YES to default (because most
> people don't use WindowMaker)
>  
I think the default should be NO. Standard behaviour should remain
standard. But indeed, Truls idea is even better: No app to manage it, no
problem!
It makes also sense since WIndowmaker users do not want your taskbar and
other users do not want miniwindows at all, so they would not start the
taskbar.
In any case notifications about running applications need to be managed
well. The GWorkspace Dock tries to contact all apps it had running when
it closed...

Riccardo


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@...
http://lists.gnu.org/mailman/listinfo/discuss-gnustep